Когда один & ломает Ctrl+C

В статье разобран инженерный разбор ошибки, в которой Ctrl+C сначала выключал виртуальную машину, а после исправления перестал прерывать даже обычный sleep.

Автор прошел весь путь управляющего символа: хостовый терминал → Java → виртуальный UART → KVM → TTY-подсистема Linux → процесс. Виновником в итоге оказался не KVM и не обработка IRQ, а фоновый запуск BusyBox shell: процесс унаследовал игнорирование SIGINT.

Любопытный пример того, как диагностировать сложные проблемы на границах нескольких систем: проверять каждый слой отдельно и прямыми экспериментами исключать исправные участки цепочки.

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

@usr_bin_linux

Как превратить Python-скрипт на VPS в нормальный сервис

nohup, screen и надежда на то, что скрипт никогда не упадёт, — не лучший вариант для эксплуатации. В этой статье рассказывается, как организовать запуск небольших Python-приложений средствами самого Linux — без Docker, Supervisor и отдельной системы мониторинга.

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

🚀 запуск и автоматический перезапуск через systemd;

🚀 хранение секретов и ограничение прав процесса;

🚀 сбор и ротация логов с помощью journald;
уведомления о сбоях в Telegram вместе с фрагментом журнала;

🚀 запуск задач по расписанию через systemd timers вместо cron.

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

@usr_bin_linux

🎮 Чтиво на выходные: как Марио покорял ZX Spectrum

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

Статья рассказывает, как Марио пытался добраться до ZX Spectrum: от ранних портов Donkey Kong и Mario Bros. до клонов, отменённой The Great Giana Sisters и проектов отечественных энтузиастов. Попытки создать собственного Марио продолжались более 20 лет и породили немало любопытных игр.

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

Наливайте чай — впереди 22 минуты приятной ностальгии.

Как Марио ZX Spectrum покорял

@usr_bin_linux

Имиджборда в терминале: возвращение к интернету без лент и алгоритмов

Автор создал Bord — открытую анонимную площадку, основной клиент которой работает прямо в терминале. Интерфейс напоминает Midnight Commander: слева расположены доски, справа — треды и сообщения. Поддерживаются клавиатура, мышь, поиск, цветовые темы и даже изображения.

За ретро-интерфейсом скрывается современная архитектура:

— клиент и сервер написаны на Go;

— TUI построен на Bubble Tea, Bubbles и Lip Gloss;

— HTTP используется как источник данных, а SSE — для уведомлений об изменениях;

— SQLite работает в режиме WAL;

— API описан через OpenAPI;

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

Проект для тех, кто скучает по форумам, IRC и старому интернету.

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

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

@usr_bin_linux

Как защитить Linux-сервер и не потерять к нему доступ в процессе настройки?

В репозитории How To Secure A Linux Server собраны способы базового усиления безопасности Linux. Также объясняются назначения настроек и возможные последствия их применения.

В руководстве разобраны:

🚀 защита SSH, вход по ключам и двухфакторная аутентификация;

🚀 ограничение доступа к sudo и su;

🚀 настройка межсетевого экрана UFW;

🚀 защита от атак с помощью Fail2Ban, CrowdSec и PSAD;

🚀 автоматическая установка обновлений безопасности;

🚀 аудит системы, контроль целостности файлов и поиск руткитов;

🚀 мониторинг открытых портов, журналов и подозрительной активности;
усиление параметров ядра Linux.

Есть и вариант автоматизации с помощью Ansible.

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

@usr_bin_linux

Зачем нужен Ansible, если серверов всего два и есть SSH?

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

В статье на простом примере с двумя Ubuntu-серверами и Nginx показано:

— чем декларативное описание состояния отличается от набора SSH-команд;

— как устроены Control Node, Inventory и Playbook;

— почему Ansible не требует установки постоянного агента;

— как развернуть одинаковую конфигурацию сразу на нескольких серверах;

— что такое идемпотентность и почему повторный запуск Playbook не ломает уже настроенную систему.

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

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

@usr_bin_linux

SSH-клиент — без Chromium и с собственным UI-движком

EvertySSH — open source SSH-клиент, написанный на Rust. Проект появился из желания собрать в одном приложении всё необходимое для повседневной работы с серверами:

— несколько SSH-сессий во вкладках и разделение экрана;

— сохранённые подключения и генерация ключей;

— история команд с привязкой к серверу и сессии;

— библиотека часто используемых сниппетов;

— восстановление рабочего контекста после сетевых ошибок;

— поддержка полноэкранных консольных приложений.

Вместо Chromium или WebView автор использует собственный интерфейсный движок EvertyUI, а терминальный экран реализует как отдельную машину состояний с поддержкой ANSI-последовательностей, курсора, цветов и альтернативного буфера.

Есть ограничение: клиент пока не проверяет ключ сервера через known_hosts, поэтому использовать его в критической инфраструктуре преждевременно. Ну, может еще добавят.

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

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

@usr_bin_linux

Что делают боты, когда всё-таки подбирают пароль к SSH?

Автор развернул honeypot на базе Cowrie и замаскировал его под мощный сервер для обучения нейросетей: 128 ядер, терабайт памяти и четыре NVIDIA H100. Затем намеренно позволил автоматическим ботам подобрать пароль.

Всего за 12,5 часа ловушка получила 1846 подключений, 1524 команды и 219 попыток скачать файлы. После входа боты добавляли свои SSH-ключи, меняли пароль root, удаляли конкурирующие майнеры, закреплялись через cron и загружали вредоносное ПО.

Получился живой разбор автоматизированных атак на публичные серверы — от разведки до превращения взломанной машины в часть ботнета. В конце есть практический чек-лист по защите SSH и поиску следов компрометации.

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

@usr_bin_linux

Ubuntu готовится к большим переменам

Вышла Ubuntu 26.10 Stonking Stingray, и это обновление интересно не только новым GNOME и косметическими изменениями. Canonical продолжает серьёзно перестраивать системные компоненты и постепенно формирует облик будущей Ubuntu 28.04 LTS.

Среди нововведений:

🚀 локальный голосовой ввод Myna без отправки аудио в облако;

🚀 ядро Linux 7.3 и поддержка будущих Intel Nova Lake и AMD Zen 6;

🚀 завершение перехода стандартных файловых утилит на Rust;

🚀 замена dbus-daemon на dbus-broker;

🚀 Sequoia PGP для проверки подписей APT-пакетов;

🚀 улучшения шифрования, аутентификации и корпоративного управления.

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

@usr_bin_linux

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