LSD — привычный ls, только современнее

LSD — написанная на Rust альтернатива стандартной команде ls. Она делает просмотр файлов в терминале нагляднее: добавляет цвета и иконки, древовидное представление каталогов, расширенное форматирование и гибкую настройку оформления.

Проект работает в Linux, macOS и Windows, устанавливается через пакетные менеджеры и при желании полностью заменяет обычный ls с помощью alias. Для корректного отображения иконок потребуется Nerd Font.

Репыч на Гитхаб

@usr_bin_linux

Можно ли навайбкодить операционную систему как Linux, только быструю?

Я давно подозревал, что фраза «давайте быстро навайбкодим» однажды доберётся от лендингов и SaaS'ов до ядра операционной системы. Дождались.

Автор этой статьи решил проверить, можно ли с помощью Claude Code создать собственную low-latency ОС — как Linux, только быстрее и без лишних микросекунд. Внутри: Rust, C++, планировщик, файловая система, борьба с задержками и тесты PostgreSQL и MariaDB.

Интересно было узнать, где ИИ действительно ускоряет разработку, а где без инженерного опыта он способен уверенно и по-быстрому навайбкодить kernel panic.

Читать статью на Хабре

@usr_bin_linux

Свой игровой сервер на Linux: от systemd до Docker на примере Minecraft и Valheim

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

В статье разбираются два подхода к запуску игровых серверов — классическая установка с systemd и контейнеризация через Docker. В качестве подопытных выступают Minecraft и Valheim: от выбора ресурсов и настройки сети до обновлений, безопасности и стабильной работы.

Читать статью на Хабре

@usr_bin_linux

Лог пустой, а диск заканчивается: что logrotate делает с файлами, которые приложение не закрывает

Классическая загадка Linux-администратора: свежий лог почти пустой, logrotate отрабатывает без ошибок, старые файлы удалены — а свободного места на диске почему-то становится всё меньше.

Спойлер: rm не всегда означает, что данные действительно исчезли. Если приложение продолжает держать файловый дескриптор открытым, оно может писать в уже удалённый файл. В каталоге его больше не видно, но место на диске всё ещё занято. Получается своеобразный «лог-призрак»: глазами его не увидеть, зато файловая система прекрасно чувствует его присутствие.

В статье разбирается, как ротация логов связана с inode и открытыми файловыми дескрипторами, чем отличаются стратегии create и copytruncate, зачем отправлять приложению HUP или USR1 и почему неправильно настроенный postrotate способен привести к потере записей.

Дополнительно рассказывают, как искать удалённые, но всё ещё открытые файлы с помощью:

lsof +L1

А также что учитывать при работе с systemd, Docker и приложениями, которые не умеют самостоятельно переоткрывать лог после ротации.

Читать на Хабре

@usr_bin_linux

Как ограничения научили нас ставить Kubernetes поверх любой операционной системы

Kubernetes хорошо абстрагирует приложения от инфраструктуры, но у каждого worker-узла всё равно остаётся операционная система. Её необходимо устанавливать, обновлять, защищать, настраивать и каким-то образом поддерживать в одинаковом состоянии на десятках или сотнях серверов.

Долгое время Kubernetes разворачивали поверх обычных серверных дистрибутивов Linux. Подход понятный и гибкий, но постепенно каждый узел обрастает пакетами, конфигурационными файлами, systemd-юнитами и изменениями, о происхождении которых через год уже никто не помнит. Так появились специализированные операционные системы для Kubernetes: CoreOS, Flatcar, Bottlerocket, K3OS и Talos OS.

В статье разбирается, чем такие дистрибутивы отличаются от классического Linux и какие идеи делают их удобными для Kubernetes:

🚀 минимальное количество компонентов

🚀 иммутабельная файловая система

🚀 атомарные обновления

🚀 отсутствие пакетного менеджера

🚀 управление через API

🚀 минимизация или полный отказ от SSH-доступа

🚀 декларативная настройка узлов


Отдельная часть посвящена Talos OS — системе, в которой Kubernetes является не дополнительным приложением, а основной причиной существования всей ОС. Никакого привычного SSH, ручного редактирования конфигурации и установки пакетов: управление выполняется через API, а обновление происходит целиком и атомарно.

Читать на Хабре

@usr_bin_linux

Linux 7.3 ускоряет файловые операции и меняет правила распределения ресурсов. Что еще?

В новом релизе Linux разработчики сосредоточились не только на поддержке свежего оборудования, но и на производительности файловых систем, управлении ресурсами и изоляции процессов.

Среди изменений:

🚀 отдельные операции fsync в Btrfs ускорены до пяти раз

🚀 улучшена работа Ext4, FUSE, io_uring и zero-copy

🚀 новый контроллер cgroup dmem помогает управлять видеопамятью и другими ресурсами устройств

🚀 разные группы процессов теперь могут использовать собственные BPF-планировщики

🚀 появились новые механизмы изоляции failfs и fchroot() для построения песочниц

🚀 добавлена начальная поддержка Apple M3 Pro, Max и Ultra, а также новых GPU и периферийных устройств

🚀 в ksmbd появились расширения для Apple Time Machine и дополнительные настройки шифрования SMB

Подробный разбор Linux 7.3 — в статье на Хабре

@usr_bin_linux

Как проверить Linux-сервер на соответствие требованиям безопасности и не утонуть в чек-листах

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

В статье разбираются инструменты, которые помогают автоматизировать проверку Linux на соответствие CIS Benchmarks, ISO 27001, PCI DSS и другим требованиям:

🚀 Lynis — быстрый комплексный аудит системы с понятными рекомендациями

🚀 OpenSCAP — формализованные проверки по SCAP-профилям и подробные HTML-отчёты

🚀 systemd-analyze security — оценка изоляции сервисов и настроек sandboxing в systemd

🚀 DevSec Hardening Framework — готовые роли Ansible, Chef и Puppet для усиления защиты

🚀 Cinc Auditor — подход compliance as code и удалённые проверки серверов по SSH

У инструментов разные задачи, поэтому на практике их разумно комбинировать — например, Lynis для общего аудита, OpenSCAP для проверки по конкретному профилю, а systemd-analyze security для анализа отдельных сервисов.

Отдельно рассматривается применение open source при подготовке к аттестации ФСТЭК. Такие инструменты не заменяют сертифицированные средства защиты, но хорошо подходят для предварительного аудита, постоянного контроля конфигурации и устранения проблем до официальной проверки.

Читать статью на Хабре

@usr_bin_linux

Восстановили взломанный Proxmox из резервной копии? Это ещё не значит, что атакующий ушёл

История массовых атак на Proxmox VE в августе–сентябре 2026 года напоминает хороший технический детектив. Злоумышленники получали административный доступ без пароля, устанавливали майнеры и eBPF-руткиты, проникали в виртуальные машины и заранее создавали несколько способов вернуться после восстановления инфраструктуры.

Особенно показателен инцидент с кластером из 22 гипервизоров. Администраторы восстановили файловые системы, сменили пароли и SSH-ключи, но атакующие вскоре снова появились внутри. Причин оказалось две:

🚀 руткит скрывал вредоносные файлы от стандартных утилит, поэтому rsync --delete просто не видел, что нужно удалить

🚀 созданные злоумышленниками пользователи и десятки API-токенов сохранились в общей конфигурации Proxmox, синхронизируемой через pmxcfs

В статье подробно разбирается критическая уязвимость CVE-2023-54391, позволявшая обойти аутентификацию через API Proxmox, методы сокрытия майнеров и типичные ошибки при восстановлении.

Главный вывод выходит далеко за рамки Proxmox: после компрометации root недостаточно удалить вредоносное ПО и восстановить файлы. Необходимо заново установить доверие ко всей системе — проверить кластерную конфигурацию, пользователей, API-токены, ACL, SSH-ключи и гостевые машины, а восстановление выполнять из независимой доверенной среды.
И конечно, административный интерфейс гипервизора не должен смотреть в Интернет. VPN, отдельная управляющая сеть, MFA, внешнее журналирование, независимый мониторинг и защищённые от удаления резервные копии здесь не паранойя, а базовая гигиена.

Читать разбор на Хабре

@usr_bin_linux

Куда на самом деле ходят процессы на сервере?

RustNet — терминальный сетевой монитор, который показывает активные TCP-, UDP- и QUIC-соединения и по возможности связывает их с конкретными процессами.

В интерактивном TUI можно увидеть состояние соединений, адреса, порты и объем трафика, отфильтровать данные по процессу или протоколу, а также определить HTTP, DNS, SSH, QUIC и TLS-соединения по SNI. Интерфейс работает через SSH, поэтому инструмент удобно использовать при диагностике удаленных серверов.

Дополнительные возможности:

🚀 просмотр слушающих сокетов и сетевой активности процессов

🚀 пассивная аналитика DNS-запросов

🚀 экспорт трафика в PCAP и PCAPNG для Wireshark

🚀 headless-режим с JSON для скриптов и мониторинга

🚀 снижение привилегий после запуска и платформенная изоляция

🚀 поддержка Linux, macOS, Windows и FreeBSD

Хороший вариант, когда ss, netstat и lsof уже не дают полной картины, а запускать Wireshark или разбирать tcpdump пока не хочется.

Для захвата пакетов потребуются соответствующие системные права, а на Windows — Npcap.

Репыч на Гитхаб

@usr_bin_linux

Когда одного AI-агента уже мало

Tmux-Orchestrator — экспериментальный набор скриптов для организации нескольких Claude Code-агентов в tmux. Один агент выступает оркестратором, другие становятся менеджерами проектов и инженерами, получают отдельные задачи и работают параллельно в разных терминальных сессиях.

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

В репозитории реализованы:

🚀 иерархия «оркестратор → менеджеры проектов → инженеры»

🚀 параллельная работа с несколькими кодовыми базами

🚀 обмен сообщениями между агентами через окна tmux

🚀 планирование повторных проверок и продолжение задач

🚀 регулярные Git-коммиты, ветки и точки восстановления

🚀 наблюдение за работой агентов в реальном времени

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

Репыч на Гитхаб

@usr_bin_linux

Linux, TCP и 53 минуты до root — в эфире рубрика «Чтиво на выходные»

Что происходит, когда десятилетняя ошибка в сетевом стеке Linux встречается с AI-моделью, способной превратить уязвимость в рабочий эксплойт меньше чем за час?

Автор статьи подробно разбирает CVE-2026-98432 — use-after-free в обработке TCP-соединений, появившийся еще в ядре 4.4. Уязвимый код срабатывает до передачи данных приложению: атакующему достаточно взаимодействовать с открытым IPv4-портом.

Внутри — объяснение:

🚀 как устроено TCP-рукопожатие и request socket

🚀 откуда возникает гонка между ядрами процессора

🚀 как освобожденная память превращается в утечку данных и запись за границы объекта

🚀 почему исправление заняло всего две строки

🚀 как AI ускоряет путь от найденного бага до рабочего remote-root эксплойта

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

Получается неприятный разрыв: эксплойты создаются быстрее, а процессы обновления инфраструктуры остаются прежними.

Читать на Хабре

@usr_bin_linux

Швейцарский нож сетевого инженера — теперь в одном веб-интерфейсе

Networking Toolbox объединяет более сотни инструментов для диагностики сетей, расчетов и проверки конфигураций.

Внутри есть:

🚀 калькуляторы IPv4/IPv6-подсетей и VLSM

🚀 операции с CIDR: разделение, объединение, сравнение и поиск свободных диапазонов

🚀 генераторы и валидаторы DNS-записей

🚀 инструменты для DNSSEC, SPF, DKIM, DMARC и CAA

🚀 анализ HTTP-заголовков, редиректов, CORS и cookie

🚀 проверка TLS-сертификатов, версий протокола и наборов шифров

🚀 BGP-, ASN-, RDAP- и GeoIP-запросы

🚀 инструменты для DHCP, MAC-адресов и Option 43

Проект выполнен как offline-first-приложение: многие расчеты работают локально в браузере, без передачи исходных данных сторонним сервисам. Проверки DNS, TLS, BGP и удаленных узлов, конечно, потребуют сетевого доступа.

Networking Toolbox можно открыть на публичном сайте или развернуть внутри собственной инфраструктуры. Самый быстрый вариант:

docker run -p 3000:3000 lissy93/networking-toolbox

Репыч на Гитхаб

@usr_bin_linux

Как инженеры на самом деле восстанавливают Linux-серверы

Автор статьи собрал статистику прохождения учебных инцидентов в Linux-окружении: пользователи получали сервер со сломанным сервисом и самостоятельно искали причину — без готовой последовательности команд.
За месяц участники взяли в работу 366 инцидентов. Успешно завершились 192 попытки, а медианное время восстановления составило 7 минут 49 секунд. При этом среди тех, кто дошел до проверки результата, доля успешных решений приблизилась к 78%.

Интереснее всего сравнение сценариев:

🚀 CrashLoopBackOff исправили в 90% попыток

🚀 ошибку 502 Bad Gateway — в 85,7%

🚀 высокую загрузку CPU — в 69%

🚀 недоступную базу данных — в 49,1%

🚀 Too many open files — в 42,9%

🚀 проблемы с OOM Killer — только в 40%

Статистика показывает любопытную вещь: конкретный симптом вроде CrashLoopBackOff или 502 сразу задает направление расследования. А сообщение «приложение не запускается» оставляет слишком много вариантов — конфигурация, права, зависимости, окружение или системные ресурсы.

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

Читать статью на Хабре

@usr_bin_linux

Too many open files — но где эти файлы?

Ошибка Too many open files часто заставляет администратора искать огромные логи и забытые файлы. Однако файловые дескрипторы расходуют не только файлы, но и сокеты, каналы и другие ресурсы процесса.

В статье на примере разбирают:

🚀 почему сервис может исчерпать лимит, создавая одни только сокеты

🚀 чем фактический лимит процесса отличается от результата ulimit -n в SSH-сессии

🚀 как проверить дескрипторы и ограничения через /proc/PID/fd и /proc/PID/limits

🚀 почему увеличение LimitNOFILE может лишь отсрочить повторное падение

🚀 как отличить недостаточный лимит от утечки ресурсов

🚀 чем ошибки EMFILE и ENFILE отличаются друг от друга

Читать статью на Хабре

@usr_bin_linux

🦀 KiviDB — многопоточная альтернатива Redis и Valkey на Rust

KiviDB — высокопроизводительное in-memory хранилище, которое использует все доступные ядра процессора и поддерживает протоколы RESP2 и RESP3. Благодаря совместимости с Redis для подключения можно использовать существующие клиенты, библиотеки и привычный redis-cli.

Возможности проекта:

🚀 шардированная многопоточная архитектура

🚀 основные структуры данных и Redis-совместимые команды

🚀 полнотекстовый поиск с фильтрацией по текстовым, числовым и теговым полям

🚀 встроенный векторный поиск с индексами FLAT и HNSW

🚀 Redis Stack-совместимые команды семейства FT.*

🚀 сохранение данных через снимки и опциональный append-only file

🚀 поддержка Lua-скриптов и TLS при сборке с соответствующими функциями

🚀 готовый образ Docker и оператор для Kubernetes

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

Проект можно запустить параллельно с Redis: по умолчанию KiviDB использует порт 6380.

docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING

KiviDB на GitHub

@usr_bin_linux

⚓️ Когда обычных способов использовать sed уже недостаточно

Обычно sed применяют, чтобы заменить строку в конфигурационном файле или быстро обработать поток текста. Но поскольку его команды вместе с регулярными выражениями образуют Тьюринг-полный язык, теоретически на нём можно написать что угодно.

Автор статьи решил проверить это утверждение и реализовал на sed полноценный «Морской бой» — с псевдослучайной расстановкой кораблей, интерактивным вводом и достаточно сильным компьютерным противником. Статья большая, техническая и местами совершенно безумная — в самом хорошем смысле.

По пути пришлось научить потоковый редактор:

🚀 выполнять двоичное сложение, вычитание, умножение и деление

🚀 генерировать псевдослучайные числа

🚀 организовывать циклы, ветвления и повторное использование кода

🚀 хранить и изменять состояние игрового поля

🚀 проверять корректность расстановки кораблей

🚀 анализировать результаты выстрелов и выбирать следующий ход

В результате получился не просто необычный эксперимент, а подробный разбор вычислений на регулярных выражениях и внутренних механизмов sed: pattern space, hold space, меток и переходов.

Читать статью на Хабре

@usr_bin_linux

До 80% экономии на GPU и эксплуатации: знакомьтесь, «Штурвал ML/AI»

У «Штурвал» появилась отдельная редакция, которая запускает ML- и AI-нагрузки в Kubernetes, эффективно использует GPU и управляет всем жизненным циклом моделей — от экспериментов до продакшена.

Что умеет «Штурвал ML/AI»:
◾️объединять GPU в общий пул и распределять ресурсы между командами;
◾️предоставлять готовый ML-стек на базе Kubeflow и MLflow;
◾️запускать обучение и инференс в одном кластере;
◾️обновлять ML-компоненты вместе с кластером;
◾️обеспечивать безопасность и контроль доступа.

По расчетам разработчика, платформа помогает сократить затраты на GPU и эксплуатацию до 80%.

Поддерживаются NVIDIA A100, H100 и L40S, а также Astra Linux, РЕД ОС, Rosa, Alt Linux, Ubuntu и Debian.

Подробнее о «Штурвал ML/AI» тут

🐳 Docker без магии: что происходит между docker build и docker run

Docker часто начинают использовать с копирования готового docker-compose.yml. Контейнеры запускаются — всё хорошо. Но позже могут возникнуть трудности: данные исчезают после пересоздания, образ неожиданно меняется, сборка занимает вечность, а секреты случайно оказываются внутри публичного image.

В статье подробно разбираются основы Docker:

🚀 чем контейнер отличается от образа и виртуальной машины

🚀 как изоляция строится на namespaces и cgroups

🚀 как устроены слои образа и механизм Copy-on-Write

🚀 что происходит на разных этапах жизненного цикла контейнера

🚀 чем volumes отличаются от bind mounts

🚀 зачем нужен .dockerignore и как он защищает от попадания секретов в образ

🚀 почему не стоит использовать тег latest в продуктивной среде

🚀 чем отличаются CMD, ENTRYPOINT, ARG и ENV

🚀 как правильно располагать инструкции в Dockerfile, чтобы использовать кэш слоёв

🚀 зачем нужны multi-stage builds и HEALTHCHECK

Материал подойдёт начинающим спецам. А тем, кто уже на опыте, пригодится как структурированная шпаргалка.

Читать статью на Хабре

@usr_bin_linux

🐧 Как работает mount в Linux

Монтирование файловых систем относится к тем темам, с которыми рано или поздно сталкивается каждый Linux-администратор. Нужно подключить новый диск, примонтировать флешку, исправить /etc/fstab или понять, почему раздел упорно сообщает target is busy.

В статье разобраны:

🚀 источники и точки монтирования

🚀 команды lsblk, blkid, findmnt и df

🚀 ручное подключение и безопасное размонтирование устройств

🚀 поиск процессов, удерживающих файловую систему

🚀 режимы ro, rw, noexec, nosuid и другие параметры

🚀 автоматическое монтирование через /etc/fstab

🚀 использование UUID вместо изменяемых имён вроде /dev/sda1

Читать статью

@usr_bin_linux

Kora — настольная ОС на Linux для ИИ-энтузиастов

В 2027 году должна выйти новая настольная ОС Kora, ориентированная не на массового пользователя, а на разработчиков, создателей контента и тех, кто ежедневно работает сразу с несколькими ИИ-моделями.

Главная идея проекта — объединить облачные и локальные модели внутри одной среды. Пользователь сможет начать работу с OpenAI, продолжить с инструментами Anthropic, а часть задач передать локальной модели, сохранив общий контекст.

Среди заявленных возможностей:

🚀 «нейронная файловая система» с семантическим поиском по содержимому документов

🚀 единый контекст для разных ИИ-провайдеров

🚀 локальное хранение памяти и пользовательских данных

🚀 поддержка x86-64 и компьютеров на Snapdragon

🚀 запуск Windows-приложений через слои совместимости

🚀 собственные приложения и SDK для разработчиков

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

Kora строится на Linux и рассчитана как минимум на системы с 64 ГБ оперативной памяти.

Читать подробнее в статье

@usr_bin_linux

🔐 Быстрый аудит безопасности Linux-сервера одним Bash-скриптом

vps-audit — скрипт для первичной проверки безопасности и производительности Linux-сервера.

Скрипт проверяет:

🚀 настройки SSH, включая вход под root и авторизацию по паролю

🚀 состояние UFW, firewalld, iptables или nftables

🚀 наличие и конфигурацию Fail2ban и CrowdSec

🚀 открытые порты и запущенные сервисы

🚀 неудачные попытки авторизации

🚀 доступность системных обновлений

🚀 парольные политики, SUID-файлы и журналирование sudo

🚀 загрузку CPU, использование памяти и свободное место на дисках

Результаты выводятся в консоль со статусами PASS, WARN и FAIL, а затем сохраняются в текстовый отчёт с рекомендациями. Пороговые значения можно настроить под собственную инфраструктуру.

vps-audit на GitHub

@usr_bin_linux