Linux *

Мониторинг целостности файлов выглядит простым ровно до тех пор, пока не пытаешься сделать его полезным для расследований и одновременно не убить прод. Сканы пропускают «изменил и откатил», inotify не даёт нужного контекста, auditd начинает стоить слишком дорого. В Datadog пошли через eBPF и получили то, чего не хватало: реальные события с привязкой к процессам и контейнерам — а вместе с ними и новую проблему масштаба, когда счёт идёт на миллиарды событий в минуту. В статье разберем, как они перенесли часть логики фильтрации в ядро, научились отсеивать шум ещё до user space и превратили поток телеметрии в сигнал, который можно выдержать.

Прямо сейчас в вашем ядре есть баги, которые не найдут ещё многие годы. Я знаю это, потому что проанализировал 125183 бага с отслеживаемой меткой Fixes: за 20-летнюю историю Git ядра Linux.

Прежде чем баг обнаружат, он в среднем живёт в ядре 2,1 года. Но в некоторых подсистемах ситуация гораздо хуже: для драйверов шины CAN этот срок в среднем составляет 4,2 года, для сетевого протокола SCTP — 4,0 года. Самый долгоживущий баг в моём датасете (переполнение буфера в ethtool) прятался в ядре 20,7 года. Баг, который я проанализирую в статье подробно (утечка refcount в netfilter), прожил 19 лет.

Я создал инструмент, перехватывающий 92% исторических багов в тестовом датасете на этапе коммитов. Ниже я расскажу, какую информацию мне это дало.

Привет всем!

В большинстве книг по Linux, ядро — это такая священная корова или, как говорят, "черный ящик". Мы работаем в командной строке, юзаем утилиты, а где-то там, за занавесом, этот ящик творит чудеса, чтобы всё работало.

Я решил сам разобраться и доказать: ядро Linux — это просто исполняемый файл. Никакой магии. Его можно взять, скомпилировать (или просто скопировать) и запустить, как любой другой бинарник.

Сейчас мы проделаем пару простых но крутых экспериментов. Цель не столько повторить их, сколько построить в голове четкую картину, как вообще Linux устроен и как его компоненты общаются.

Но сперва — а что это вообще за ядро?

В прошлой статье я закончил обзор open source решения для аналитики и, что важно для нас, решения для менеджера тегов - Matomo Tag Manager. В этой статье приступаем к разбору по косточкам самого решения. И начинаем с установки его на сервер. А я продолжаю выступать своего рода евангелистом Matomo Tag Manager в рунете, где он незаслуженно, по моему мнению, обойден стороной.

В этой статье мы разберём Dokploy — open-source платформу для деплоя приложений. Узнаем, какие задачи она решает, какие функции предлагает и чем отличается от популярного конкурента Coolify. В конце вы поймёте, подходит ли Dokploy для ваших проектов.

Помните мою статью про историю моддинга и аппаратную платформу Motorola E398? Если ещё не читали, то рекомендую ознакомиться. А тем временем у @EXL нашёлся редчайший прототип E398, который разработали в России и он работал на Linux! Если интересно почитать его историю и что у него внутри - жду вас под катом.

На Хабре про OSTree обычно вспоминают не как про самостоятельную технологию, а как про "то, на чём держатся" Fedora CoreOS / Silverblue / Kinoite и вообще вся тема immutable / atomic desktop / container-optimized OS. Это видно по типовым материалам: обзор CoreOS с объяснением rpm-ostree и layering, обзор Silverblue, новости/разборы релизов Fedora, где rpm-ostree фигурирует как механизм поставки базовой системы. 

При этом намного хуже покрыта практическая сторона "как сделать свой цикл поставки": поднять свой OSTree-репозиторий, выпускать свои refs и раскатывать их на узлы так, чтобы можно было обновиться и откатиться, а не как герои трагикомедии "обновили пакеты — и внезапно утро не наступило". На фоне обилия статей "как устроен Silverblue/CoreOS" такой сценарий встречается реже. 

Мы раскроем полный цикл от публикации сервера до создания клиентских образов в этой статье.

Создатель Linux официально присоединился к лагерю тех, кто не стесняется генерить код через AI. Подрыв устоев!

Если вы работаете с роботом под Linux, то знаете эту боль: сегодня лидар — /dev/ttyUSB0, завтра — /dev/ttyUSB1, а камеры внезапно меняются местами.

В статье разобран надёжный способ привязать USB-устройства к физическим портам через by-path, создать стабильные имена в /dev и перестать править конфиги после каждой перезагрузки.

Подходит для роботов (да и не только), Linux (проверено на Ubuntu Server) и ROS2.

Если что, это не кликбейт. История довольно проста: в один из рабочих дней (работаю экспертом по компьютерной экспертизе) мне "на стол" попал сервер на ALT. Всё стандартно:

1) делаю чек железа, дабы исключить модули аппаратного шифрования / аппаратные токены и т.д.

2) делаю диагностику всей системы на момент первого запуска, для внесения в отчёт. Данная диагностика должна включать в себя первичную информацию о: диске; памяти; сети; базовых службах (ssh, cron и тд.) и о системе в целом.

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

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

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

Не скажу за всех, но периодически вспоминать нюансы по сборке образа и тратить на это время бесит. Пусть будет туториал.

В руках у меня оказалась невзрачная черная коробочка — KM8p, сердцем которой бился восьми ядерный кристалл s912, с двумя гигабайтами оперативной памяти и восемью гигабайтами встроенного хранилища. Задача — вдохнуть в нее жизнь, установив легковесную графическую среду xfce, единственную, что под силу этой скромной оперативе.

Мой путь лежал через дистрибутив armbian, версию 26.02.0-trunk. Но это был не простой установочный образ, а целый лабиринт, полный не очевидных ловушек и правил, будто составленных загадочным архитектором.

Вот и настало время финальной части повествования, в которой я расскажу о практическом результате той эпопеи что растянулась на несколько лет.

Ситуация: рабочая машина под управлением Windows находится в корпоративной сети за NAT. Извне хода в сеть нет. К рабочему компьютеру необходим удалённый доступ с домашнего компьютера на Linux. Работа AnyDesk оставляет желать лучшего.

Всем доброго времени суток, не так давно появилась необходимость вывести звук на несколько наушников подключенных по bluetooth к ноутбуку, система Ubuntu 22.04, ядро 6.8.0. Пересмотрел много информации, но почти все не то, куча ошибок, зависаний и тд. Решил обобщить все что было прочитано и попробовано и что в итоге вышло.

Начнем с того, что нужно посмотреть какие модули установлены в системе для PulseAudio:

Как заставить китайскую механическую клавиатуру (Zifriend, SAMA, Gamestop, Cyberlinx) работать в Linux, хотя производитель этого не обещал.

История о том, как я «подружил» свою Cyberlinx ZA63 с Linux Ubuntu, когда официально поддержки нет. Для всех, кто думал, что клавиатуры «просто работают» везде или столкнулся с такой же проблемой.

Начал я проходить курсы системных администраторов Linux. Ну и одним из заданий стала установка Netbox с «нуля». Первым делом — как всегда — открыл официальную документацию Netbox‑а. Тут есть подробнейшая инструкция (кстати, довольно информативная), как его установить, смотри.

Но на определённых этапах установки стали появляться совершенно непредвиденные проблемы. То, что в главном конфиге пароль нужно указывать дважды и то, как его вообще устанавливать — это уже мои недосмотры, а вот то, что для первой установки после создания базы /venv/bin нужно инициализировать статический контент — это я нашёл где‑то совершенно случайно, и понял что оно работает, что называется, методом «волшебного тыка».

Саму установку делал под «чистым» debian. Такие условия у курсов... Но — на мой скромный взгляд — установка под «Убунтой» полностью идентична, а в Npm и Dnf based системах всё должно работать так же. Никаких специфичных пакетов тут нет.

Вам когда-нибудь нужно было зайти в BIOS или UEFI, чтобы сменить порядок загрузки, включить виртуализацию или проверить оборудование? Многие пользователи знают лишь один способ — в первые секунды после включения компьютера нажать Del, F2 или другую «волшебную» клавишу. Но что делать, если клавиатура не работает, используется удалённое подключение, или вы просто не успеваете нажать нужную кнопку из-за быстрой загрузки системы?

Оказывается, на современных операционных системах можно программно перезагрузиться прямо в интерфейс прошивки, используя лишь командную строку или терминал. В этой статье мы рассмотрим, как это сделать в Windows, Linux и выясним, какие возможности есть в macOS.

Генератор паролей из /dev/random: от one-liner'а к Rust CLI

В этой статье хочу поделиться процессом написания собственного генератора паролей, использующего энтропию /dev/random. От pipe команды до Rust утилиты.

Привет, Хабр! Холодным зимним вечером мне понадобилось настроить статический ip-адрес на CentOS 7. В этой статье я делюсь своим опытом по настройке статического ipv4. И путем от Destination Host Unreachable до полностью работающего интернета.