• TOP'ай сюда

      Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

      top

      Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

      atop


      Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

      В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

      Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.
      Читать дальше →
    • Как стареть в IT

      • Перевод
      После нескольких лет насмешек над предрассудками в области информационных технологий я — будучи белым мужчиной с совсем не седыми, густыми волосами — начинаю сталкиваться с предубеждением по отношению к моему возрасту. Это правда, дискриминация по возрасту реальна.

      С 2008 года количество жалоб на дискриминацию по возрасту выросло до 25 000 в год. Можно возразить, что мы везде вынуждены «крутиться» сейчас и всегда найдётся кто-то, кто пожалуется на какую-то несправедливость. Конечно, ОК! Давайте не будем принимать во внимание жалобы. Просто посмотрим на средний возраст сотрудников известных IT-компаний. Фейсбук: 28. LinkedIn: 29. Гугл: 30. Чтобы увидеть объективно — средний возраст работника в США составляет 42 года. Это намного выше среднего возраста в названных выше компаниях. Даже сам Марк Цукерберг однажды публично высказался на каком-то мероприятии в Стэнфорде: «Я хочу подчеркнуть важность быть молодым и технически подготовленным. Молодые люди просто умнее.»
      Читать дальше →
    • Как не надо делать защиту от эксплойтов на примере Norton Security

        Зимним вечером придя с работы, захотелось мне проверить работоспособность своей старой лабы (2012 года) на тему эксплуатации Use-After-Free в ActiveX под Internet Explorer . Собственно на новом ноуте у меня была Windows 10, и последний IE со всеми этими вашими isolated heap и тд. И вот я запустил свой сплойт, как вдруг вышел облом от туда, откуда не ждали, на новом ноуте у меня стоял Norton Security, который пафосно детектировал 0day и стопанул:



        Вечер обещал быть томным. предыдущий опыт работы с NextGen защитами подсказывал мне, что ребята из Symatec сделали все «дешево и быстро», а значит можно попробовать обойти эту защиту не сильно парясь. В общем, как показала практика, этот подход по защите от сплойтов ОЧЕНЬ типовой и обходится практически универсальным и единым методом. Другими словами, при детальном подходе к эксплойту — один и тот же код будет работать и против Norton Security и против других систем защиты, которые используют такой же механизм обороны (ну и конечно против систем, где защиты нет). Посмотрим же в чем «архитектурная» ошибка выбранного Symantec метода защиты…

        Читать дальше →
      • Ресайз картинок в браузере. Все может стать еще хуже

           


          Знакомьтесь, это Маня. Маню поразил страшный недуг и теперь она нуждается в вашей помощи. Маня росла обычной девочкой, жизнерадостным счастливым ребенком. Но чуть больше года назад врачи поставили ей страшный диагноз — алиазинг. И она стала выглядеть вот так.



          Как выяснилось, виной тому стала жадность и алчность производителей браузеров, которые решили сэкономить на алгоритмах ресайза изображений и применить самые низкокачественные фильтры. Тогда Маню удалось спасти — она прошла курс последовательных не кратных двум уменьшений, что снизило алиазинг и вернуло её былую резкость. Но теперь ей снова угрожает опасность.

          Читать дальше →
        • Архитектура WhatsApp, которую Facebook купил за $19 миллиардов

          • Перевод

          В очередной раз хочу предложить свой перевод статьи, на этот раз автор Тодд Хофф, и его статья посвященна архитектуре WhatsApp на момент его покупки Facebook.


          Ремарка: в начале статьи содержится рассуждение автора оригинала о том, зачем Facebook купил WhatsApp за баснословные 19 миллиардов. Если это вам не интересно — просто пролистайте, описание архитектуры будет ниже.


          Рик Рид в его предстоящем мартовском докладе, озаглавленном "Миллиард с большой 'М': Следующий уровень масштабирования в WhatsApp" раскрывает сногсшибательную статистику WhatsApp:


          Что имеет сотни узлов, тысячи ядер, сотни терабайт RAM и надеется обслужить миллиарды смартфонов, которые вскоре станут реальностью по всему миру? Основанная на Erlang и FreeBSD архитектура WhatsApp. Мы столкнулись со многими трудностями при удовлетворении постоянно растущего спроса на наш сервис обмена сообщениями, но мы продолжаем расширять нашу систему с точки зрения размера (> 8000 ядер) и с точки зрения скорости (>70М сообщений Erlang в секунду).
          Читать дальше →
        • Palantir: торговля оружием и распространение пандемии

            Как данные в руках разведчиков аналитиков Palantir превращаются из неструктурированных в структурированные.

            Вместе с компанией Edison продолжаем расследование возможностей системы Palantir.


            Palantirчастная американская компания, четвертый по капитализации (после Uber, Xiaomi и Airbnb) стартап в мире (данные на начало 2016 года). Основные заказчики — ЦРУ, военные, ЦКЗ и крупные финансовые организации.

            По-моему, как-то так видели пользу информационных технологий «отцы-основатели» Вэнивар Буш («As We May Think»), Дуглас Энгельбарт («The Mother of All Demos») и Джозеф Ликлайдер («Интергалактическая компьютерная сеть» и «Симбиоз человека и компьютера»), о которых я писал немного ранее.

            Под катом — два кейса (2010 года).
            • Первый — анализ распространения вируса во время национальной пандемии на основе пятнадцати миллионов записей обращений в больницу и трехсот пятидесяти семи тысячах записей о смерти.
            • Второй — анализ сотни отчетов из расследования по глобальной сети торговцев оружием.

            (За помощь с переводом спасибо Ворсину Алексею)

            Читать дальше →
          • Ошибка в ядре Linux отправляет поврежденные TCP/IP-пакеты в контейнеры Mesos, Kubernetes и Docker

            • Перевод
            image
            А обнаружена она была на серверах Twitter

            Ядро Linux имеет ошибку, причиной которой являются контейнеры. Чтобы не проверять контрольные суммы TCP, для сетевой маршрутизации контейнеры используют veth-устройства (такие как Docker на IPv6, Kubernetes, Google Container Engine и Mesos). Это приводит к тому, что в ряде случаев приложения ошибочно получают поврежденные данные, как это происходит при неисправном сетевом оборудовании. Мы проверили, что эта ошибка появилась, по крайней мере, три года назад и до сих пор «сидит» в ядрах. Наш патч был проверен и введен в ядро, и в настоящее время обеспечивает ретроподдержку стабильного релиза 3.14 в различных дистрибутивах (таких как Suse и Canonical). Если Вы в своей системе используете контейнеры, я рекомендую Вам воспользоваться этим патчем или установить ядро вместе с ним, когда это станет доступным.

            Примечание: это не относится к сетям с NAT, по умолчанию используемых для Docker, так как Google Container Engine практически защищен от ошибок «железа» своей виртуализированной сетью. Еще Джейк Бауэр (Jake Bower) считает, что эта ошибка очень похожа на ошибку Pager Duty, обнаруженную ранее.

            Как это все началось


            В один из выходных ноября группа саппорт-инженеров Твиттера просматривала логи. Каждое неработающее приложение выдавало «невероятные» ошибки в виде строк странных символов или пропусков обязательных полей. Взаимосвязь этих ошибок не была очевидна из-за природы распределенной архитектуры Твиттера. Вся ситуация осложнялась еще и тем, что в любой распределенной системе данные, когда-то испорченные, могут вызвать ошибки еще довольно продолжительное время (они сохраняются в кэшах, записываются на дисках, в журналах и т.д.).

            После суток непрерывной работы по поиску неисправности на уровне приложений, команде удалось локализовать проблему до отдельных рэковых стоек. Инженеры определили, что значительное увеличение числа выявленных ошибок контрольной суммы TCP произошло непосредственно перед тем, как они дошли до адресата. Казалось, что этот результат «освобождал от вины» софт: приложение может вызвать перегрузку сети, а не повреждение пакета!
            Читать дальше →
            • +42
            • 14,6k
            • 5
          • ZeroNet — По настоящему распределенная сеть — год спустя

              image

              Примерно год назад я писал об этой сети ZeroNet — Распределенные сайты через Bittorrent и Bitcoin тогда еще хабр был торт и в комментариях были обсуждения о том насколько сеть распределена. Да, год назад действительно были вопросы, но теперь всё изменилось.

              Внутри:
              • Что это такое этот ваш ZeroNet
              • Что изменилось за год
              • Почему она полезно с точки зрения защиты от цензурирования
              • Почему она полезна в качестве импорто замещения и «защиты сувереннитета»
              • Что есть в сети?

              Читать дальше →
            • Как делать парсинг текста голым хардвером, без процессора и без софтвера

                Кто-то парсирует текстовый файл программой на Питоне, другой пишет скрипт с регулярными выражениями на Перле, Си-программист стыдливо возится с буферами и указателями, иногда применяя Yacc и Lex.

                А можно ли парсировать текст голым железом? Вообще без программы?

                — А как это?, — спросил меня знакомый, — С помощью Ардуино?

                — Внутри Ардуино стоит вполне фон-неймановский процессор и работает программа, — ответил я, — Нет, еще более голое железо.

                — А-а-а-а, этот, микрокод?, — догадался мой товарищ и взглянул на меня победно.

                — Нет, термин «микрокод» использовался для специфической организации процессоров в 1970-е годы, потом его использование сошло на нет, — ответил я и добавил, — Правда есть еще микрооперации в интеловских процессорах, в которые перекодируется x86, но это тоже другое. Нет, я имею в виду парсинг текста устройством, состоящим из логических элементов И-ИЛИ-НЕ и Д-триггерами, как на картинке ниже.

                — Невозможно! — воскликнул мой приятель, — в таком устройстве где-то сбоку должен сидеть процессор и хитро подмигивать!

                — Почему это невозможно?, — парировал я, — Вот машину Тьюринга знаешь? Парсирует текст на ленте, а сбоку никакие интелы и ардуино не подмигивают.

                — Нуу, машина Тьюринга, — протянул приятель, — это абстракция, типа Демона Максвелла.

                — Никакой абстракции, сейчас увидишь работающую схему, парсирующую текст, — сказал я и прибавил, — но сначала расскажу, зачем мне вообще это понадобилось.

                mfp_srec_parser_fragment
                Читать дальше →
              • Безопасность прошивок на примере подсистемы Intel Management Engine



                  В предыдущей статье был описан ход исследования безопасности прошивок промышленных коммутаторов. Мы показали, что обнаруженные архитектурные недостатки позволяют легко подделывать образы прошивок, обновлять ими свитчи и исполнять свой код на них (а в некоторых случаях — и на подключающихся к свитчам клиентах). В дополнение, мы описали возможности закрепления внедряемого кода на устройствах. Подчеркнули низкое качество кода прошивок и отсутствие механизмов защиты от эксплуатации бинарных уязвимостей.
                  Мы обещали привести реальный пример сильной модели безопасности прошивок, где модификация исполнимого кода является очень нетривиальной задачей для потенциального злоумышленника.

                  Встречайте – подсистема Intel Management Engine, самая загадочная составляющая архитектуры современных x86-платформ.

                  Читать дальше →