Немного предыстории

Мобильное приложение Badoo существует для основных «нативных» платформ (Android, iOS и Windows Phone) и для мобильного веба. Несмотря на то, что в разработке мы не используем никаких кроссплатформенных фрэймворков, подавляющая часть бизнес-логики в приложениях схожа, и чтобы не дублировать функциональные тесты для всех платформ, мы пишем кроссплатформенные тесты с помощью Cucumber, Calabash и Appium. Это позволяет нам выносить в общую часть и переиспользовать в тестах для всех платформ код, отвечающий за проверку этой самой бизнес-логики. Различной же остается лишь реализация взаимодействия с приложением (более подробно мы рассказывали об этом здесь).

Когда кроссплатформенная автоматизация только начиналась (на iOS и Android), было принято решение использовать в качестве серверов Mac Mini. Это позволило сделать каждую из 8 билд-машин универсальной: на ней можно было собирать и запускать функциональные и юнит-тесты как для приложений на iOS, так и на Android. Такое решение устраивало нас практически всем до тех пор, пока количество функциональных тестов не перевалило за пять сотен для каждой платформы, а прогоны не стали требовать все больше времени. Для того чтобы удержать время прогона в разумных границах, мы постоянно работаем над оптимизацией тестов, а также добавляем новые Android-устройства (для iOS мы добавляем симуляторы по-другому). Со временем у нас появились Mac Mini с более чем 8 смартфонами. Важно отметить, что мы подключаем устройства одной модели к одному серверу, чтобы прогоны тестов были консистентны на одном агенте.

Я регулярно проверяю различные открытые проекты, чтобы продемонстрировать возможности статического анализатора кода PVS-Studio (C, C++, C#). Настало время компилятора GCC. Бесспорно, GCC — это очень качественный и оттестированный проект, поэтому найти в нём хотя бы несколько ошибок уже большое достижение для любого инструмента. К моей радости, PVS-Studio справился с этой задачей. Никто не застрахован от опечаток и невнимательности. Именно поэтому PVS-Studio может стать вашей дополнительной линией обороны на фронте бесконечной войны с багами.

Преамбула

Некоторе время назад перед нами стала задача спроектировать и развернуть систему для потокового видео. Суть была в массовом запуске/остановке инстанций, на которых происходит обратная сборка потокового видео и стриминг на множество media cdn провайдеров (youtube, livestream, ustream итд ) а также на собственные rtmp и ts точки назначения. Каждая инстанция требовала настройки перед запуском т.к. содержала специфическую для каждого клиента информацию. Также было понятно, что система должна работать в большом количестве регионов (как минимум во всех точках, где присутствует Амазон, а как максимум — в любом месте где можно арендовать сервер). Также основное требование — запуск инстанции в течении 1-2 секунд максимум, чтобы это было прозрачно для пользователя.

Сейчас мы активно готовим вторую конференцию Linux Piter и, пока формируется список докладчиков, давайте вспомним как прошла её первая часть.

В этой статье я хочу рассказать о проверке проекта ReOpenLDAP. Этот проект был реализован для решения проблем, возникших при эксплуатации OpenLDAP в инфраструктуре ПАО МегаФон — крупнейшего в России оператора мобильной связи. Сейчас ReOpenLDAP успешно работает в филиалах МегаФон по всей России, поэтому было бы интересно проверить столь высоконагруженный проект при помощи статического анализатора PVS-Studio.

Команда GnuPG Project опубликовала сообщение о том, что в популярной библиотеке Libgcrypt содержится критическая уязвимость. Ошибка была обнаружена экспертами Технологического института немецкого города Карлсруэ Феликсом Дёрре (Felix Dörre) и Владимиром Клебановым.

Уязвимость содержится в генераторе случайных чисел Libgcrypt — она позволяет атакующему, который получил 4640 битов из генератора легко предсказать следующие 160 бит его вывода. Это открывает возможность для взлома ключей шифрования. Ошибка присутствует в Libgcrypt и GnuPG версий, выпущенных до 17 августа 2016 года, для всех платформ. Как указано в сообщении GnuPG Project, этот баг существует с 1998 года.

Каждый должен делать свою работу качественно и в срок. Допустим, вам нужно сделать веб-сервис классификации картинок на базе обученной нейронной сети с помощью библиотеки caffe. В наши дни качество — это асинхронные неблокирующие вызовы, возможность параллельного исполнения нескольких заданий при наличии свободных процессорных ядер, мониторинг очередей заданий… Библиотека RQ позволяет реализовать все это в сжатые сроки без изучения тонны документации.

Сделаем веб-сервис на одном сервере, ориентированный на несильно нагруженные проекты и сравнительно длительные задания. Естественно, его применение не ограничивается этими вашими нейронными сетями.

Несколько лет назад я уже выкладывал статью о том как из роутера сделать сетевую звуковую карту. Тот вариант требовал наличия активного источника звука и колонок. Переносной вариант выглядел бы слишком громоздким, потому было решено приобрести готовый продукт. По причине доступности и как самое дешевое из возможных вариантов (50 евро) я выбрал renkforce IR 1.

Из ключевых характеристик мне были важны следующие:

• DLNA (возможность прямого воспроизведения через pulseaudio)
• WiFi (802.11bg)
• AUX
• Пульт
• Хороший звук
• Экран
• Возможность создавать свой плейлист
• USB

Это заметка о любви. О любви статического анализатора кода PVS-Studio к замечательной открытой операционной системе Linux. Эта любовь молода, трогательная и ранима. Этой любви нужно помочь укрепиться. Вы поможете, если заранее запишитесь в добровольцы для тестирования beta-версии PVS-Studio for Linux.

Отчёт о новых функциях свободного графического редактора

Мы только что выпустили вторую dev-версию GIMP в серии 2.9.x, ставшую результатом полугода работы. GIMP 2.9.4 представляет собой мощное обновление:

• обновленный интерфейс;
• серьёзные улучшения в управлении цветом;
• готовый к использованию инструмент MyPaint Brush;
• симметричное рисование;
• сплит-превью для фильтров на GEGL.

Вдобавок, исправлены десятки багов и сделаны многочисленные мелкие улучшения в графическом редакторе.

GIMP 2.9.4 достаточно надёжен для использования в продакшне, но требуется ещё кое-что доделать. Поэтому выпуск стабильной версии 2.10 потребует некоторого времени. Пожалуйста, смотрите дорожную карту со списком основных изменений, которые готовятся в версии GIMP 2.10.

Раз Swift компилируется в нативный код, то почему бы не попробовать на нём написать модуль ядра? Всех заинтересовавшихся просьба под кат!

Так уж вышло, что запуск cron в Docker-контейнере — дело весьма специфическое, если не сказать сложное. В сети полно решений и идей на эту тему. Вот один из самых популярных (и простых) способов запуска:

cron -f

Но такое решение (и большинство других тоже) обладает рядом недостатков, которые сходу обойти достаточно сложно:

• неудобство просмотра логов (команда docker logs не работает)
• cron использует свой собственный Environment (переменные окружения, переданные при запуске контейнера, не видимы для cron заданий)
• невозможно нормально (gracefully) остановить контейнер командой docker stop (в конце концов в контейнер прилетает SIGKILL)
• контейнер останавливается с ненулевым кодом ошибки

Бывает, что приложению требуется узнать точное время приема или отправки сетевого пакета. Например, для синхронизации часов (см. PTP, NTP) или тестирования задержек в сети (см. RFC2544).

Наивным решением будет запоминать в приложении время сразу после получения пакета от ядра (или перед отправкой ядру):

  recv(sock, buffer, length, flags);
  clock_gettime(CLOCK_REALTIME, timespec);

Ясно, что полученное таким образом время может заметно отличаться от момента, когда пакет был получен сетевым устройством. Для получения более точного времени нужна поддержка от операционной системы, драйвера и/или сетевого устройства.

Начиная с версии 2.6.30 Линукс поддерживает опцию сокета SO_TIMESTAMPING. Она позволяет пользовательскому сокету получать временные метки для отправляемых и принимаемых пакетов. Временные метки могут быть сняты самим ядром, драйвером или сетевым устройством (см. список поддерживающих устройств и драйверов). О том, что это вообще такое и как этим пользоваться, стоит почитать в Documentation/networking/timestamping.txt

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

UPDATE из будущего: Не используйте этот подход! Для поиска логов намного лучше подходит простой поиск по регулярному выражению или подстроке встроенными средствами ClickHouse. Эта статья была написана давно, как интересный эксперимент, и у меня на тот момент не. было полного понимания того, как ClickHouse работает и как его лучше всего готовить. Я вас предупредил. Привет участникам телеграм-чатика «ClickHouse не тормозит»!

В этой статье я расскажу о том, как разработать систему для индексирования и полнотекстового поиска error-логов (или любых других логов) на основе СУБД от Яндекса под названием ClickHouse. Про саму базу Яндекс писал на Хабре сначала когда база была закрытой, а потом когда они её заопенсорсили. База данных в первую очередь предназначена для аналитики и для реализации сервиса Яндекс.Метрика, но может на самом использоваться для чего угодно, если вам подходит загружать данные пачками, удалять их тоже огромными пачками и никогда не обновлять отдельные строки.

Что мы будем делать

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

CREATE TABLE Messages (
    message_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    created_ts DATETIME,
    message_text BLOB
)

Мы научимся быстро отдавать результаты поиска по такому логу (то есть, всегда отсортированные по времени) и индексировать его в режиме реального времени.

Предлагаю вашему вниманию перевод статьи What are Docker none:none images? из блога Project Atomic.

Последние несколько дней я потратил на упражнения с образами Docker <none>:<none>. Чтобы объяснить, что они собой представляют, и что могут натворить, я пишу этот пост, в котором ставлю вопросы:

1. Что собой представляют образы Docker <none>:<none> ?
2. Что собой представляют обособленные (dangling) образы ?
3. Почему я вижу кучу образов <none>:<none>, когда делаю docker images -a ?
4. В чем разница между docker images и docker images -a ?

Прежде чем я начну отвечать на вопросы, запомните, что есть два вида образов <none>:<none>: хорошие и плохие.

Одним из современных технических мейнстримов является блокчейн. В этой статье я расскажу как можно быстро развернуть Emercoin блокчейн на RedHat/CentOS 7 и Ubuntu 16.04 LTS.

В процессе разработки, например, для Intel Edison или Galileo, может случиться так, что нужного для экспериментов устройства под рукой не оказалось. Похожее происходит и тогда, когда «железо» есть, но установленная на нём ОС не поддерживает всех необходимых для проекта возможностей. Что делать?

Один из вариантов решения этой проблемы – запуск целевой операционной системы на виртуальной машине. На ней можно компилировать, развёртывать и тестировать программы. Сегодня поговорим о том, как создавать образы Yocto Linux, подходящие для запуска в виртуальных средах, например, в простом программном эмуляторе QEMU. Кроме того, подобные образы можно использовать в системах с гипервизорами, скажем, в Microsoft Hyper-V на Windows.

После выхода Ubuntu 16.04 (новый LTS релиз), systemd стал реальностью всех основных дистрибутивов Linux, использующихся на серверах. Это означает, что можно закладываться на расширенные возможности systemd, не рискуя оставить часть пользователей приложения «за бортом».

Этот пост о том, как реализовать многоворкерное приложение средствами systemd.

Abstract: Использование шаблонов сервисов и target'ов для запуска нескольких инстансов сервиса (реализация «воркеров»). Зависимость PartOf. Немного про [install] секцию у unit'ов.

Вступление

Многие языки программирования с плохой или никакой многопоточностью (Python, Ruby, PHP, довольно часто C/C++) используют концепцию «воркера». Вместо того, чтобы городить сложные отношения между тредами внутри приложения, они запускают несколько однопоточных копий приложения, каждое из которых берёт на себя кусок нагрузки. Благодаря опции SO_REUSEPORT есть даже возможность «вместе» слушать на одном и том же порту, что покрывает большинство задач, в которых возникает потребность в воркерах (собственно, обычные серверные приложения, реализующие API или обслуживающие веб-сайт).

Но такой подход требует наличия «супервизора», который отвечает за запуск копий, следит за их состоянием, обрабатывает ошибки, завершает при всякого рода stop/reload и т.д. При кажущейся тривиальности — это совершенно не тривиальная задача, полная нюансов (например, если один из воркеров попал в TASK_UNINTERRUPTIBLE или получил SIGSTOP, то могут возникнуть проблемы при restart у не очень хорошо написанного родителя).

Есть вариант запуска без супервизора, но в этом случае задача reload/restart перекладывается на администратора. При модели «один процесс на ядро» перезапуск сервиса на 24-ядерном сервере становится кандидатом в автоматизацию, которая в свою очередь требует обработки всех тех же самых SIGSTOP и прочих сложных нюансов.

Одним из вариантов решения проблемы является использование шаблонов сервисов systemd вместе с зависимостью от общего target'а.

Трудно недооценить роль GPIO, особенно в мире встраиваемых систем ARM. Помимо того, что это крайне популярный материал для всех руководств для начинающих, GPIO обеспечивают способ для управления многими периферийными устройствами, выступают в качестве источника ценных прерываний, или даже могут быть единственным доступным способом общения с миром для SOC.

Основываясь на собственном скромном опыте, могу сказать, что прерывания далеко не самая освященная тема в сообществе Linux. Из-за своих особенностей, а так же сильной привязки к аппаратной части, все обучающие материалы посвященные прерываниям лишены реального и легко воспроизводимого примера. Данный факт мешает пониманию того, что очень часто прерывания и GPIO неразделимы, особенно в области встраиваемого Linux. Многие начинают верить, что GPIO это очень простая и скучная вещь (которая кстати и стала таковой благодаря подсистеме sysfs).

Предисловие

Недавно мною было замечено, что при просмотре мультикастового IPTV через Wi-Fi часть трафика теряется. После детального изучения проблемы было выяснено, что такое поведение объясняется природой мультикаст-трафика, а именно – MAC-адрес получателя пакета. Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.

Штатными средствами проблема решается либо созданием отдельной точки доступа для клиента, либо созданием статического маршрута для определенных мультикаст-групп, или же выведением клиента в отдельный VLAN. Вся “сила” таких решений проявится, когда в сети будет несколько IPTV-приставок, желающих посмотреть один и тот же канал, плюс необходимость их в интернете добавит сложность к настройке роутера. Свое решение данной проблемы предлагаю ниже.