Linux *

Я не разработчик, но сделал Telegram-бота для Hysteria 2

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

добавить или удалить пользователя, выдать доступ, проверить статус, перезапустить сервис и при этом ничего не сломать

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

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

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

4. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

5. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Постер: Очереди и метрики TCP в Linux (Linux TCP Queues and Metrics)

Полная схема, которая наглядно показывает весь путь TCP-соединения в ядре Linux.

Описаны:

• все основные очереди (SYN-queue, Accept-queue, Send-Q, RX/TX-буферы);

• точки возможных дропов пакетов;

• места тюнинга ключевых параметров (tcp_max_syn_backlog, somaxconn, netdev_max_backlog, tcp_mem и другие);

• наиболее важные метрики TcpExt_*.

Если открывается сжатая картинка, то полную можно найти в гите

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

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

• Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

• Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

• Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

• Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

• Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

• Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

• Автосейв через фоновый демон, периодически снимающий все сессии на диск.

• Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

Всем привет. Я чувствую себя новым человеком! Перешёл на Linux, потому что моя Windows 10 посыпалась после гибернации. Sfc пишет, что всё нормально. Dism — тоже. Тогда мне понадобилось разрешение на запуск: ярлыки, UAC для папок в загрузках, а «Пуск» вообще отказался работать. Лучшим выбором стал Zorin OS, но я устанавливал его два раза. Первый: переход с Windows, второй: после запуска в WinPE для проверки карты памяти (всё-таки Victoria не заработала через Wine) моя разметка диска превратилась в RAW, и мне пришлось заново создавать загрузочную таблицу. Пользуюсь пингвином (маскот Linux) уже два дня, немного непривычно после Win+R, но привыкну. У меня уже был опыт пару недель, и это помогло. Я не жалею, что удалил NTFS-разделы.

Upd1: Linux слишком гибкий. Вот я пытался накопать библиотеку libnss3 для hl2_linux и в итоге снёс gnome и спустя 2 часа ручного восстановления и зубрения пакетов apt я вернул всё как было

Команда проекта ReactOS сообщила о значительном прогрессе в обеспечении совместимости с проприетарными видеодрайверами. Благодаря серии исправлений и внедрению подсистем KMDF (Kernel‑Mode Driver Framework) и WDDM (Windows Display Driver Model) удалось реализовать поддержку примерно 90% драйверов GPU для Windows XP и Windows Server 2003. До внесения изменений запуск многих фирменных драйверов либо заканчивался сбоем, либо работал нестабильно. Теперь же в свежих ночных сборках ветки 0.4.16 наблюдается устойчивая работа драйверов от различных производителей, включая Intel, NVIDIA и AMD.

Среди прочего, продемонстрирована работа ReactOS на реальном оборудовании и загрузка с установленными драйверами для видеокарт уровня Intel GMA 945, Nvidia GeForce 8800 GTS и GTX 750 Ti и AMD Radeon HD 7530G. Отдельно отмечается успешный запуск на мобильной графике, например Nvidia Quadro 1000M, где помимо 2D/3D‑ускорения также функционируют звук и сетевые подключения. В дополнительных тестах также подтверждена работа на более редких и устаревших конфигурациях, включая ноутбук с Radeon Xpress 1100, а также на высокопроизводительных видеокартах, таких как Nvidia GTX Titan X.

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

Разработчик Роман Гущин (Roman Gushchin) из команды мейнтейнеров ядра Linux в Google объявил о доступности новой ИИ-системы Sashiko для проверки кода с помощью искусственного интеллекта. Внутри Google она уже используется для выявления проблем, и теперь она доступна публично и охватывает все сообщения, отправленные в список рассылки ядра Linux. Гущин пояснил, что Sashiko смогла обнаружить около 53% ошибок на основе неотфильтрованного набора из 1000 недавних проблем ядра Linux с меткой «Исправления:».

NixOS: идея, до которой индустрия доросла только сейчас.

Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.

История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.

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

Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.

😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.

Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.

А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.

📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.

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

Зарегистрироваться тут

hmod, chown и принцип минимальных привилегий: права доступа в Linux

Неправильно выставленные разрешения на файл или каталог — один из самых распространенных векторов для эскалации привилегий в  Linux.

В блоге мы разобрали базу, которую полезно держать в голове: символьное и цифровое представление прав, разница между владельцем, группой и остальными, команды chmod и chown с практическими примерами — от chmod 755 до рекурсивной смены владельца через chown -R.

Читайте полный разбор на сайте Рег.облака.

Вот парочка тонкостей, которые касаются гибернации в ОС Linux:

1. Если своп находится внутри LVM, даже зашифрованного через LUKS, подсистема ядра Kernel Lockdown не даст включить гибернацию, если в UEFI включён Secure Boot. Чтобы всё это добро работало, нужно вынести своп таким образом, чтобы оно было напрямую подвязано к LUKS-контейнеру, без LVM.

2. Гибернация в режиме UEFI Secure Boot работает только внутри зашифрованного LUKS-контейнера. Если своп хранится в незашифрованном виде, подсистема Kernel Lockdown не даст включить гибернацию. Это сделано для защиты от подмены данных, а также от получения данных со свопа извне запущенного с ним экземпляра ОС.

10 бесплатных уроков марта по системному администрированию

• 4 марта 20:00
  GREP и другие регулярные выражения Линукс
  ^{Открытый урок курса «Администратор Linux. Профессиональный уровень»}

• 10 марта 20:00
  Использование /31 префикса в IP‑сетях
  ^{Открытый урок курса «Сетевой инженер. Базовый уровень»}

• 11 марта 20:00
  Сети ЦОД — SP (сеть провайдера) и DC (сеть дата-центра). Какой же подход к построению сетей оказался более распространен и почему?
  ^{Открытый урок курса «Проектирование сетей ЦОД»} 

• 12 марта 20:00
  Перенаправление потоков в Линукс
  ^{Открытый урок курса «Администратор Linux. Базовый уровень»}

• 17 марта 20:00
  Работа с данными и сетями в Docker
  ^{Открытый урок курса «DevOps практики и инструменты»}

• 23 марта 19:00
  SSH: безопасный доступ и автоматизация в Линукс
  ^{Открытый урок курса «Администратор Linux. Базовый уровень»}

• 24 марта 20:00
  /proc, /sys, /dev: как Linux превращает железо и процессы в файлы
  ^{Открытый урок курса «Администратор Linux. Профессиональный уровень»}

• 24 марта 20:00
  Технология контейнеризации. Введение в Docker
  ^{Открытый урок курса «DevOps практики и инструменты»}

• 25 марта 20:00
  VxLAN: как связать дата‑центры поверх обычной сети
  ^{Открытый урок курса «Проектирование сетей ЦОД»} 

• 25 марта 20:00
  Механизмы блокировок в PostgreSQL
  ^{Открытый урок курса «PostgreSQL для администраторов баз данных и разработчиков»}

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.

А для тех, кто хочет быстро и на практике подтянуть основы, рекомендуем мини-видеокурс «Linux для начинающих», сейчас всего за 10 рублей.

Среди пентестеров в настоящее время сложилась такая тенденция, что "внутреннее тестирование" подразумевает под собой исключительно взятие домена: ребята идут на проект с одной целью - взять AD и стать доменными администраторами. Однако, в сети живут не только рабочие станции и ноутбуки пользователей под управлением 💻 Windows. Мало того, что сеть полна зоопарком IoT устройств: принтеры, камеры наблюдения, роутеры, IP-телефония; так еще и внутренние веб-порталы, различные ERP-системы и среды разработки часто преобладают в общей "сетевой" массе.

И, как вы понимаете, во втором случае в дело вступают Веб- и 🐧 Linux пентестеры, так как все вышеперечисленное работает на базе детища Линуса Торвальдса.
В идеале, конечно, чтобы знания и навыки обоих направлений уместились в голове одного специалиста, так как после пробития "вебчика" желательно знать, куда копать дальше, а не передавать находки коллегам.

Вообще, в тестировании линукса также имеется своя методология с горизонтальными и вертикальными эскалациями. Получая первоначальный доступ с минимальными или ограниченными привилегиями, специалист начинает разведку с изучения системы, версии ядра, поиска зашитых логинов/паролей, дополнительных пользователей и т.д. Для автоматизации рутинных действий по энумерации всей системы имеются скрипты, которые проходят по основным моментам - LinEnum и linPEAS.

Среди основных выводов, данные программы показывают такие важные вещи, как SUID и GUID/SGID. SUID (Set User ID) заставляет программу при запуске временно работать с правами владельца файла (часто root), а GUID/SGID (Set Group ID) — с правами группы файла. То есть, если у исполняемого файла стоит бит SUID и его владелец — root, а программу запускает обычный пользователь, то программа запускается от имени рута.

Для помощи в эскалации привилегий группа исследователей разработали GTFOBins — онлайн-каталог встроенных в Unix/Linux утилит (bin’ов), которые при неправильной настройке, в том числе SUID/SGID, можно использовать, чтобы обойти локальные ограничения. Однако ручная проверка 40-50+ сервисов - не самая лучшая идея.

Поэтому, для помощи в "моментальном" получении суперпользователя при неправильной настройке SUID/GUID я разработал оффлайн утилиту AutoSUID. Она построена на базе проекта GTFOBins, имеет предзагруженную библиотеку мисконфигов (работает на системах без интернета) и, самое главное, работает с использованием штатных средств Linux (так как у простого пользователя нет прав на установку дополнительного ПО).
То есть просто закидываете .sh файл на тестируемый сервер и запускаете. Если есть уязвимые приложения, сразу получаете терминал рута (см. картинку). Вобщем, рекомендую!

Однако, если вы начинающий Linux пентестер, я не советую слепо исполнять мой скрипт равно как и LinEnum с LinPeas. Компания Splunk еще в 2021 году указала, что наши утилиты являются прекрасными инструментами для системных администраторов и ИБ при обнаружения потенциальных ошибок в системе. Вместе с тем они также могут быть использованы злоумышленниками для повышения привилегий и иных подозрительных действий.

Поэтому, перво-наперво, я бы рекомендовал изучить "матчасть" и понять, как работают скрипты под "капотом", а уже потом использовать средства автоматизации!

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

Запуск USB-сканера отпечатков пальцев Chipsailing CS9711 на Linux.

Эти сканеры продаются на маркетплейсах по цене 1-2 т.р. Команда lsusb опознаёт их как
ID 2541:0236 Chipsailing CS9711Fingprint. Мейнстримный fprintd этот сканер не поддерживает. Как видно из комментариев к MR, разработчики не могут оценить точность нового алгоритма sigfm для сравнения отпечатков, потому не спешат (а дефолтному уже 15 лет, и он довольно плохо работает с низким разрешением сканера).

На Arch драйвер должен ставиться из AUR, рецепт для Fedora тут, далее - рецепт для Ubuntu.

TL;DR: аккуратно подменяем системную библиотеку libfprint-2.so версией из форка.

1. Скачать и скомпилировать форк libfprint-2 с поддержкой сканера

git clone https://github.com/archeYR/libfprint-CS9711
cd libfprint-CS9711
meson setup build

Последняя команда может выдать ошибку, не найдя в системе пакетов с нужными библиотеками (libgusb-dev, libopencv-dev и т.п.). Надо их поставить и выполнить её снова.

Компилируем:

ninja -C build

Для проверки позапускаем примеры:

cd build/examples
sudo ./enroll
sudo ./verify

Установить библиотеку, если всё хорошо (действовать с острожностью! обратите внимание на комментарии к посту)

cd ..              # предполагаю, что из build/examples никуда не уходили
sudo ninja install

В итоге должен появиться файл /usr/local/lib/x86_64-linux-gnu/libfprint-2.so.2.0.0 (и еще другие, тоже в /usr/local, но они не важны)

2. Установить пакет с демоном распознавания по отпечатку пальца

sudo apt install fprintd

Эта команда установит также пакеты с libfprint-2 из системных репозиториев, без поддержки нашего сканера.

3. Подменить библиотеку libfprint-2

Варианты:

• указать ld.so читать нужную библиотеку перед запуском fprintd

• создать в /usr/lib/x86_64-linux-gnu/ симлинк на правильный файл

• перезаписать библиотеку в /usr/lib/x86_64-linux-gnu

• PPA

У каждого есть плюсы и минусы, последние два рассмотрены не будут.

3.1. Предзагрузка нужной libfprint-2

sudo systemctl edit fprintd

Откроется окно редактора; добавить две строки (там сказано, куда)

[Service]
Environment="LD_PRELOAD=/usr/local/lib/x86_64-linux-gnu/libfprint-2.so"

сохранить файл, закрыть редактор.

3.2. Установка правильной символической ссылки

sudo update-alternatives --install\
  /usr/lib/x86_64-linux-gnu/libfprint-2.so.2\
  libfprint\
  /usr/local/lib/x86_64-linux-gnu/libfprint-2.so.2.0.0 100

В комментах под постом написано, что должна выдать команда ls -l, если всё сделано правильно.

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

sudo systemctl restart fprintd
sudo systemctl status fprintd

Ожидаемый вывод:

● fprintd.service - Fingerprint Authentication Daemon
     Loaded: loaded (/usr/lib/systemd/system/fprintd.service; static)
    Drop-In: /etc/systemd/system/fprintd.service.d
             └─override.conf
     Active: active (running) since Tue 2026-02-24 16:02:45 MSK; 1s ago
          ...
фев 24 16:02:45 machine-name systemd[1]: Starting fprintd.service - Fingerprint Authentication Daemon...
фев 24 16:02:45 machine-name systemd[1]: Started fprintd.service - Fingerprint Authentication Daemon.

4. Зарегистрировать пальцы командой fprintd-enroll

По умолчанию регистрируется правый указательный, остальное написано в man fprintd-enroll

5. Включить вход по отпечатку

sudo pam-auth-update

поставить звёздочку на Fingerprint Authentication и нажать Ok.

Это вот так поменяет файл /etc/pam.d/common-auth:

-auth   [success=1 default=ignore]      pam_unix.so nullok
+auth   [success=2 default=ignore]      pam_fprintd.so max-tries=5 timeout=10 # debug
+auth   [success=1 default=ignore]      pam_unix.so nullok try_first_pass

Проверено на Kubuntu 24.04.4 LTS.

Ссылки по теме:
https://man7.org/linux/man-pages/man8/ld.so.8.html
https://manpages.ubuntu.com/manpages/noble/man5/pam.conf.5.html

Я сделала тему оформления для Xfce в стиле Lomiri. Мне очень нравится дизайн Lomiri - графическое окружение на Linux, которое до 2020 года называлось Unity 8. Поскольку я очень часто пользуюсь Xfce и для него не хватает дизайна в стиле Lomiri, я решила проявить инициативу.

Я использовала Linux Mint 22.3 с последней версией Xfce 4.20. Я сделала пару коммитов и теперь тема оформления Xfce доступна всем на Linux. Можете скачать с Гитхаба.

Приветствую, Хабравчане!

Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?

У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.

Я хочу написать о нем статью, но не в стиле ностальгический обзор ретро-игр такого в сети полно. Моя цель вдохнуть в него жизнь и проверить, пригоден ли этот 23-летний дедушка для современной разработки.

На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?

Запасной вариант, если основному ПК не хватит инструкций.

В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.

На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.

Что планирую потестить:

1. C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.

2. Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).

3. C++: Сравнить скорость сборки проекта с модулями и без них.

4. Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.

5. IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.

Прошу совета у сообщества: накидайте идей! Какие бенчмарки прогнать? Какой софт или специфические проекты попробовать собрать, чтобы нащупать предел возможностей?

Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!

Update: Поправил текст, ошибки и очепятки.

Обновил "Краткий справочник по «всем-всем» командам Linux" - добавил еще ~100 команд - предыдущее обновление было практически год назад.

Итого стало: 1335 команд 😲

Немного статистики "Было --> Стало" команд, начинающихся c ...:

>: 10⚖️ -> 10
A: 67➕➕➕➕➕➕➕➕ -> 75
B: 43⚖️ -> 43
C: 67➕➕➕➕➕➕➕➕➕ -> 76
D: 61➕ -> 62
E: 32➕➕➕ -> 35
F: 104➕➕➕ -> 107
G: 72➕ -> 73
H: 28➕ -> 29
I: 42➕➕➕➕ -> 46
J: 8⚖️ -> 8
K: 25➕➕ -> 27
L: 72➕➕ -> 74
M: 69➕ -> 70
N: 45➕➕➕➕ -> 49
O: 37⚖️ -> 37
P: 84➕➕➕➕➕➕➕➕➕➕ -> 94
Q: 15➕ -> 16
R: 44⚖️ -> 44
S: 134➕➕➕➕➕➕➕➕➕➕➕➕➕➕ -> 148
T: 45⚖️ -> 45
U: 37➕➕➕➕ -> 41
V: 33⚖️ -> 33
W: 24➕ -> 25
X: 41➕➕➕➕ -> 45
Y: 8➕ -> 9
Z: 13➕ -> 14

Ну и немного статистики по категориям команд:

🔵 881 - пользовательские
  🔴 396 - админские
  ⚫ 58 - встроенные в bash

  ☑️ 88 - TUI-приложение
  ✅ 302 - GUI-приложение
  ➡️ 40 - команды-фильтры

  📁 253 - дополнительно устанавливаемые
  🧰 87 - прикладное ПО
  🏢 86 - серверные службы
  📈 187 - мониторинг
  🎚️ 163 - конфигуратор
  🕙 34 - устаревающее

💿 178 - дистрибутиво-специфичные:
77 - ⊚AstraLinux
39 - ⊚ALT
21 - ⊚Debian
16 - ⊚RedHat
15 - ⊚SUSE
13 - ⊚RedOS
12 - другие (Ubuntu, Kali, Arch, Mageia, ...)

Вот🤔

Искусственный интеллект — это настолько крупное событие, что на клавиатурах сразу и везде нужна отдельная клавиша для вызова Copilot. По крайней мере, таким мир ПК хотела бы видеть сама Microsoft. Хотя среди формальных требований для сертификации компьютеров под Windows 11 наличия клавиши Copilot нет, уже в 2024 году пользователи начали замечать клавиатурную новинку.

Вот только никто не сказал, что делать всем остальным, кто на эти компьютеры будет ставить Linux или FreeBSD.

Подобным вопросом задался Дэниэль Колашоне, специализирующийся на производительном системном софте инженер программного обеспечения. Колашоне — известный разработчик; он работал в Google и Microsoft, где занимался производительностью ядер, соответственно, Android и Windows Phone. Дэниэль активно коммитит в open source, к примеру, в рендеринг Emacs он добавил плавность и убрал мерцание.

Благодаря гарантийной программе Колашоне заменили ноутбук на ThinkPad X1 Carbon. На клавиатуре чуда техники компании Lenovo красовалась клавиша Copilot. Дэниэль возжелал иметь на этом ThinkPad правый Ctrl вместо новой клавиши и решил переназначить клавишу программно. Тут-то разработчик и наткнулся на проблемы.

Дело в том, что в IBM-совместимых компьютерах нажатия клавиш клавиатуры отслеживает контроллер клавиатуры, который отсылает в специальный порт 60h скан-коды нажатых клавиш, и лишь после этого в дело вступает операционная система. Как выяснил Дэниэль, нажатие клавиши Copilot издаёт скан-коды зажатия левой клавиши Meta, зажатия левой клавиши Shift и зажатия клавиши F23, затем отпускания трёх клавиш в обратном порядке. Говоря проще, для операционки клавиша Copilot выглядит как быстро выстреливаемый макрос Windows + Shift + F23.

Из-за выбранных компонентов комбинации переназначить клавишу Copilot невозможно. Этот изъян уже известен и много обсуждался. Для решения проблемы надо перехватить и нейтрализовать нажатия Meta и Shift, что сделать не так-то просто.

Колашоне тоже столкнулся с этой проблемой, но для начала ему пришлось пропатчить Linux. Как рассказал разработчик, скан-код 0x6e (клавиша F23) настолько необычен, что иначе операционка его не распознавала. Затем, чтобы при нажатии на новую клавишу вызывался Ctrl, он настроил Wayland следующим образом: когда поступает нажатие левой Meta или левой Shift, нужно подождать несколько миллисекунд, будет ли нажатие F23. Если да, то будет синтезировано нажатие правой клавиши Ctrl, нет — модификаторы будут переданы как есть.

Выкрутиться удалось, пусть и ценой ненужной обработки нажатий клавиш клавиатуры и дополнительной задержки ввода. И всё ради клавиши Copilot, для которой могло бы хватить уже и без того редкой и необычной F23, замечает Колашоне.

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

Речь про vi...😱 

Как выйти из vi? Никак. Это не редактор, это пожизненный контракт.

Я открыл vi один раз в 2009 году. С тех пор у меня один и тот же терминал, потому что я всё ещё пытаюсь выйти.

Если ты случайно запустил vi на проде — проще выкинуть сервер, чем найти правильную комбинацию клавиш.

Это тот самый редактор, который в обычной жизни можно спокойно не трогать годами… А потом ты оказываешься в air-gap, где:

• нет vscode

• нет nano

• нет mc

• иногда даже less нет и кажется, что у тебя есть только vi и судьба

И вот ты открываешь конфиг… и мозг такой: эээээ мы не умеем, всё, до свидания.

Давай разберёмся, как перестать бояться vi и научиться выживать с ним спокойно.

Почему vi вызывает ступор? Потому что он не работает как обычные редакторы. Ты нажимаешь клавиши - а текст не печатается. Пытаешься выйти - не выходит. И где-то рядом уже открывается вкладка “как выйти из vi”, но интернет… в другой реальности.

Главное, что нужно понять - в vi есть несколько режимов:

1. Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.

2. Insert mode - это режим, где можно реально редактировать и вводить текст.

3. Command mode (через :) - cохранение, выход, всякие служебные команды и тд

Минимальный набор клавиш, чтобы выжить:

• Войти в редактирование -> i, a, o

• Вернуться обратно в команды -> Esc

• Сохранить файл -> :w

• Выйти -> :q

• Сохранить и выйти -> :wq

• Выйти без сохранения -> :q!

Полезные команды, которые реально пригодятся:

• удалить строку -> dd

• вставить строку ниже -> o

• отменить действие -> u

• повторить последнее действие -> .

• поиск: / и дальше текст который ищем

Пример: быстро поправить конфиг и уйти живым

vi /etc/hostname

Дальше всё по шагам:

1. нажми i и внеси правки

2. нажми Esc

3. введи :wq

4. готово - конфиг сохранён, ты победил

А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

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

Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.

Для таких случаев существует крошечная, но очень полезная утилита
spacer: https://github.com/samwho/spacer

Она вставляет визуальные разделители прямо в поток вывода и отлично работает в реальном времени. Без магии, без лишних настроек - просто аккуратно отделяет "было" от "стало".

В итоге это неожиданно удобно:

• при отладке,

• при сопровождении сервисов,

• при поиске изменений в логах после конкретных действий.

Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это  дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.

В отчете вы получите:

• Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP

• Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров

• Дисковое пространство - занятое место, inodes, SMART статус

• Тест скорости дисков - скорость записи/чтения (100MB тест)

• Сетевые интерфейсы - статус, ошибки, активные соединения

• Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета

• Процессы - топ по CPU и памяти, zombie процессы

• Системные логи - критические ошибки, OOM события, kernel warnings

• Системные службы - проверка упавших служб

• Безопасность - неудачные входы, активные SSH сессии

• Docker - статус контейнеров и их ресурсы

Пример запуска (можно без sudo - но там не будет всех показателей):

curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
sudo ./linux-diag-script.sh

# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash

Бонусом в скрипте встроена возможность получать Telegram уведомления и сам отчет при обнаружении проблем. Для этого надо создать бота и добавить в выполнение скрипта в cron.

1. Найди [@BotFather](https://t.me/BotFather) в Telegram

2. Отправь команду /newbot

3. Следуй инструкциям и получи токен бота (например: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)

4. Получи Chat ID:

       - Отправь сообщение боту

       - Откройте:  https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates

       - Найди "chat":{"id": - это твой Chat ID

Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.

# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1

Актуальная версия скрипты доступна на GitHub Gist.  Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.

Пишите что еще можно добавить - я добавлю.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Делюсь находкой...

Если тебе надо быстро потыкать что-то из Linux / контейнеров / сетей / namespaces / cgroups, но при этом не хочется поднимать VM, ставить Docker, ковырять окружение, то iximiuz labs playgrounds - это прям топ штука.

Это набор готовых интерактивных лаб, где ты заходишь в браузере и просто:

• запускаешь контейнеры

• смотришь namespace’ы

• играешься с сетью

Причём самое классное, что там не “прочитай статью”, а прям сценарий + терминал + что делать. То есть зашёл → запустил → увидел результат → понял, как оно работает.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

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

Давайте я просто покажу примеры использования с кратким описанием и все сами поймете.

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

# Проверим uptime на хостах начиная с 1 по 5, исключив 3
$ pdsh -w node[1-5] -x node3 uptime

# Перезагрузим все хосты, кроме node3 и node7
$ pdsh -w node[1-10] -x node3,node7 'sudo reboot'

Если вы достаточно организованы, чтобы вести список хостов - можно даже использовать файл с заранее определенными хостами

# File: my_hosts.txt
# node1
# node2
# db[01-05]

pdsh -w "^my_hosts.txt" 'uptime'

Вы скажете:

Так тебе же ничего не мешает использовать для этих целей Ansible! Например, так:

ansible -i 'node1,node2,node3' all -m shell -a 'uptime'

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

Когда одного pdsh мало - берите PSSH

pssh - отличная альтернатива pdsh

# Одновременное обновление пакетов на всех хостах
pssh -h production_servers.txt -l admin -t 300 "sudo apt update && sudo apt upgrade -y"

pscp - массовое копирование на сервера

# Залить скрипт мониторинга на все хосты
pscp -h all_hosts.txt monitor_script.sh /usr/local/bin/

prsync - параллельное копирование через rsync

# Обновить статические файлы только если они изменились
prsync -h cdn_nodes.txt -a "-avz" static/ /var/www/static/

pslurp - собрать файлы с серверов на локальную тачку

# Собрать логи со всех серверов в отдельные папки
pslurp -h servers.txt -l user -L ./collected_logs /var/log/app/error.log app_error.log

Эти инструменты не заменят полноценные системы управления конфигурациями вроде Ansible или chef, но для быстрых задач, срочных исправлений или массового сбора информации - они незаменимы.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Создание нового пользователя Linux: команды, права и базовые практики безопасности

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

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

Все детали — в базе знаний Рег.облака.

Устранена проблему, из-за которой установщики Adobe Creative Cloud для Windows не могли работать в Linux через Wine из-за некоторых несовместимостей Wine с MSXML3 и MSHTML. После этого открытого фикса Adobe Photoshop 2021 и Photoshop 2025 могут быть установлены и запущены в Linux через Wine.

Установка Ubuntu 24.04

Опыт обновления до Ubuntu 24.04 / установки Ubuntu 24.04 с точки зрения обычного пользователя.

На ноутбуке в течение нескольких лет была установлена Ubuntu 20.04, которая работала стабильно и надежно. В начале 2026 года было принято решение обновиться до 24.04. Казалось, это несложно: нажать кнопку обновить до 22.04 в Software Updater, затем так же обновить до 24.04, что и было сделано. ChatGPT и Deepseek предварительно были опрошены на предмет рисков при обновлениях системы. Оба заверили, что должно пройти нормально, с оговорками что есть некоторые риски и описанием их возможных причин. Стоит отметить, что оба рекомендовали рассмотреть вариант установки «чистой» Ubuntu 24.04. Был выбран вариант обновлений.

Проблем при обновлениях не возникло. Они появились позже: стали тормозить, зависать и крашиться многие приложения.

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

В итоге было решено установить «чистую» Ubuntu 24.04. Был сделан бэкап, скачан образ с официального сайта и с помощью приложения Startup Disk Creator создан загрузочный диск Ubuntu 24.04 на флешке. Перезагружаем/включаем ноутбук с вставленной флешкой, периодически нажимаем F12 или другую клавишу (в зависимости от модели ноутбука) в процессе включения, выбираем пункт «Try or Install Ubuntu». Загружается система с установщиком.

И здесь возникла другая проблема: установщик Ubuntu 24.04 зависал на 3-м или 4-м шаге, после нажатия очередного "Next" (где-то на выборе локации). Было сделано несколько попыток, с подключением к Wi-Fi и без подключения к сети, ничего не помогало. Оказалось, что это известная проблема, описанная даже на сайте поддержки Lenovo. Конкретная рекомендация по решению была найдена в одном из комментарием под топиком на форуме Ubuntu: включить режим самолета на ноутбуке сразу после включения (перед запуском установщика). После этого установщик отработал без проблем.

Рекомендации для тех, кто хочет обновиться до Ubuntu 24.04: чистая установка системы – лучший вариант. Также рекомендую с осторожностью добавлять сторонние репозитории (PPA), это может нарушить зависимости в системе.

Представлен проект CapacityTester — утилита с графическим интерфейсом для выявления реальной ёмкости носителей информации. Решение кроссплатформенное, написано на C++ и создано с использованием фреймворка Qt.

Есть два режима работы CapacityTester:

1. Аналогичный используемому при работе консольных утилит f3write/f3read (пакет f3 — Fight Flash Fraud), когда свободное место на носителе (с файловой системой) заполняется специально сформированными файлами. На носителях большого объёма требуется длительное время для проверки.

2. Деструктивный режим, когда данные пишутся напрямую на носитель, и фейковая ёмкость может быть выявлена быстрее (у f3 тоже, вроде бы, есть аналогичный режим, но это не точно).

Помимо авторских сборок, у программы есть пакет в репозиториях Altlinux и PKGBUILD в AUR.

Как я пошел на курсы ALT Linux и что из этого вышло.

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

Часть 1: Выбор пути. ALT против Astra и шок от цен.

Всё началось с желания проверить и структурировать знания по отечественным Linux-системам, с которыми приходится работать. Изначально смотрел в сторону Astra Linux, но глазам сразу бросилась разница в цене. ALT Linux предлагал обучение на более доступных условиях, а поскольку в работе я касаюсь обеих ОС, выбор стал очевидным. Начал изучать предложения на официальном сайте. И вот тут — первый удар. Стоимость курсов в некоторых учебных центрах заставила меня серьезно задуматься: «А нужна ли мне эта подготовка, если вроде бы и так всё знаю?» Но любопытство победило. Я решил тестировать, попробовать .

Часть 2: Организация. Поиск курсов и «неспешные» менеджеры.

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

Совет №1: настройтесь на ожидание. Ответ пришел далеко не сразу, прошло несколько дней. Видимо, такова специфика. Но как только контакт состоялся, всё пошло быстро: договор, оплата, зачисление — и вот я уже студент.

Часть 3: Учёба.

Проверенный университетский формат. Мне прислали ссылку и дату старта. Формат напомнил университет: · Лекции — в записи. Смотрел в свободное время, очень удобно. Практика — раз в неделю, онлайн с преподавателем. На ней разбирали лабораторные и отвечали на вопросы. Первая ступень — это два курса: «Альтадмин 1» и «Альтадмин 2». Каждый длится около 4 недель и включает лекции, 4 лабы и итоговый тест. Всё прозрачно и понятно. Обратная связь и преподаватель: Здесь мне повезло. Преподаватель отвечал на вопросы на учебной платформе молниеносно. Чувство юмора у него было своеобразное, но это мелочь. Главное — экспертиза и готовность помочь были на высоте.

Часть 4: Впечатления и нюансы. Кому стоит идти?

В целом курсы «зашли», и я их рекомендую, но с важными оговорками.

Плюсы:

1. Структурированный, практический материал.

2. Быстрая обратная связь.

3. Гибкий формат (запись + живая практика).

Нюансы (о которых стоит знать):

1. Для полного новичка может быть мало теории. Если никогда не работали с Linux, придется активно гуглить. Но все ключевые задачи на практиках разбираются.

2. В лабах встречаются «подводные камни». Иногда в условиях всплывают неочевидные ошибки или недоговоренности. Но иногда о них предупреждают. Если у вас есть даже небольшой опыт, вы с ними справитесь. Для меня это даже стало плюсом — пришлось глубже копать.Иногда версии virtual box показывали сюрпризы,то версии дистрибутивов Linux. Воооообщем разбирался.

Часть 5: Разочарование в сертификации.

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

Итоги и выводы

1. Качество обучения — на хорошем уровне. Если нужны структура и практика, курсы отличные.

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

3. Главный минус — невозможность для физлица получить полноценный вендорный сертификат после обучения. Уточняйте этот момент ДО оплаты курсов. Мой опыт получился познавательным, но с послевкусием. Надеюсь, мой рассказ поможет вам сделать выбор.

Слышу уже от второго человека, что язык Rust не дает нормально работать с указателями в связанных списках, деревьях и графах (в моей вселенной ЯП без этого - это как свадьба без невесты). Взял ChatGPT, задал промпт: "write a code to insert a node into a doubly linked list in rust". Оно сгенерило нечто с кучей дополнительных слов, которых не было ни в Си, ни в Паскале 40 лет назад: borrow, as_ref, and_then, upgrade, map, downgrade, Some, clone, borrow_mut. Это все реально нужно или они там совсем озверели?

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

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

1. Диалог на равных.
   Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

2. Проверка логики, а не памяти.
   Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

3. Ценность универсальных знаний.
   Универсальные знания долгое время позволяли быстро находить решение практически любой проблемы от хардверной, до нарушения самых элементарных паттернов проектирования в коде и эффективно их устранять. Мне нравятся задачи, где проблема может быть скрыта на любом уровне и нравятся клиенты, понимающие, как я могу снять их головную боль обеспечив работоспособность ПО в любой среде и условиях.

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

1. Лайвкодинг.
   В 40 лет написание кода для меня — процесс интимный... хотя я практикую парное программирование в реальной команде и это мне нравится, но в предвкушении собеседований иногда хочется "психануть" и на предложение выбрать время для лайвокдинга сказать — "предлагаю парное программирование с одним из ваших специалистов, ведь для меня тоже важно, с кем я буду вести разработку". (Не пробовал так отвечать, но попробую, как только выдастся случай).

2. Вакансии-обманки.
   Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

4. Отсутствие пунктуальности.
   Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

5. Узкая специализация.
   Раньше, как мне кажется, ценилась универсальность, способность разработчика понимать инфраструктуру, а инженера/админа — код. Сегодня индустрия уходит в жесткую сегментацию, видимо, для более точного просчёта рисков. А я считаю, что именно универсальность — это страховка проекта от того, что решение будет принято в вакууме одного стека, без учета общей картины.

Еще один вариант маршрутизации трафика через два сетевых интерфейса на основе списка доменных имен.

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

Краткое содержание: ставим локальный dns resolver с плагином на python, который, при разрешении имени в адрес, устанавливает маршрут через альтернативный интерфейс, если адрес соответствует регулярному выражению. Для использования решения требуется умение сконфигурировать и запустить сервис в вашем любимом дистрибутиве/сервис-менеджере, готового пакета для установки нет.

При написании кода использовалась статья Составляем DNS-запрос вручную, огромное спасибо автору и переводчику.

Для реализации идеи нужен ДНС сервер, который позволяет достаточно просто писать плагины/хуки. Первым попавшимся на глаза был PowerDNS Recursor, который позволяет писать плагины на lua. И первая реализация была для него. Но lua это больше про компактность, чем про удобство, например, поддержку регулярных выражений можно так назвать только из вежливости. Тем не менее, всё работало как предполагалось, и достаточно надежно, пока не был найден Unbound DNS который позволяет писать плагины на python, и, в итоге, был написан аналог на питоне, который и предлагаю вашему вниманию.

Все файлы доступны на github. Файлов всего 5 и все достаточно короткие.

Файл reroute.conf: пример файла конфигурации ДНС сервера. 192.168.0.1 и 172.16.17.1 — это адреса маршрутизаторов для первого и второго интерфейсов, соответственно. /etc/unbound/reroute.py — собственно плагин выполняющий основную работу. Из существенных моментов: chroot необходимо отключить, чтобы могли нормально работать скрипты на python и сервис должен работать от root чтобы добавлять маршруты.

Файл reroute.py — плагин, который выполняет необходимые дествия, reroute_conf.py — файл конфигурации для плагина, можно записать оба параметра прямо в плагин и обойтись без него. Вся работа выполняется в функции do_reroute, весь остальной код взят, практически без изменений, из документации unbound dns.

Файл rrdomains.txt — список регулярных выражений в формате python regex, при совпадении с которыми для всех ip-адресов разрешаемого доменного имени выполняется установка альтернативного маршрута.

Файл bashrc содержит определение функции reroute. Если во время работы наткнулись на сайт, для которого необходима маршрутизация через второй интерфейс, можно воспользоваться быстрым перенаправлением с помощью команды reroute в терминале. Или добавить доменное имя или регулярное выражение для него в rrdomains.txt и перезапустить dns сервер.

На этом всё, успешного маршрутизирования!

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

@Regnar, навеяло статьёй…

Свалился на меня «последний из 32-битных могикан», но машинка прямо финал возможностей архитектуры — насколько я понял, видит спокойно 8 гигов рамы (PAE во все поля?), слотов не пожалели, в общем, в такое чудо бы камень хотя бы на 2 ядра, но, увы…

Я его практически не смотрел ещё и ХЗ когда посмотрю (вроде не совсем мёртвая), но превентивно задам вопрос. Допустим, поставил я туда 32-битный BunsenLabs. Допустим, я хочу запустить какое-нибудь 64-битное приложение, которое в 32 битах давно уже не обновляется. Допустим, мне пофиг, что там в плане скорости (очень важное допущение, потому что оно как бы понятно, что там будет).

Насколько это реально — настроить для него резервативию… презервацию… короче, специально обученный загон с софтовой эмуляцией 64 бит? Существуют ли решения? Чтобы их установить и отконфигурировать, обязательно пройти все круги ада, как в той статье?

Практического смысла это по понятной причине не несёт — просто пятничное.

Почему я снова вернулся на Debian после Ubuntu 24.04 и Fedora 42

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

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

Я решил обновиться с Ubuntu 22.04 до 24.04 - казалось бы, логичный шаг: свежий LTS, новые пакеты, улучшения в GNOME. Но спустя пару недель я понял, что дистрибутив нужно менять. Расскажу, почему.

Медленная работа с большим количеством файлов

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

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

Да, баг могут исправить, но в тот момент он мешал работать каждый день.

Fedora: понравилась, но не подошла под задачи

Первым я решил попробовать Fedora 42.
Впечатления были отличные:

• система работает быстро,

• GNOME выглядит аккуратнее без патчей Canonical,

• Wayland ощущается максимально плавным,

• окружение ощущается «современным из коробки».

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

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

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

Почему я выбрал Debian 13

В этом году как раз вышел Debian 13 с GNOME 48, я решил попробовать его.

И для себя получил:

• стабильность, к которой привык,

• современный GNOME без патчей,

• огромный набор пакетов в репозиториях,

• отсутствие лишних предустановленных компонентов,

• а главное — всё, что мне нужно, установилось без танцев.

В итоге Debian остаётся для меня тем самым балансом:

Итог

Ubuntu 24.04 — неплохой релиз, но сейчас он не подходит под мои задачи.

Fedora оставила отличные впечатления — она бы идеально подошла мне «для души».
Но для работы мне нужна система, где всё устанавливается из репозиториев, ничего не ломается после обновлений и не приходится искать обходные решения.

Так я и остановился на Debian 13 с GNOME 48 — и пока это лучший вариант для моего сценария.

А прочитать статью про мой ноутбук, который я приобрел для Линукс за 25000 рублей, вы можете по ссылке:

https://kodprog.ru/noutbuk-dlya-linuks-za-25000

Почему мне не понравился Arch Linux

Однажды я решил попробовать Arch Linux — в качестве эксперимента, чтобы понять, подходит ли он мне как основная система. Спойлер: нет. Хотя я понимаю, почему Arch нравится многим, лично мне он не зашёл. Расскажу коротко — без холивара, просто субъективный опыт.

1. Слишком много ручной настройки

Да, это философия Arch — «собери систему под себя».
Но когда даже базовые вещи требуют:

• поиска пакета вручную,

• чтения вики,

• настройки конфигов,

в какой-то момент это начинает отвлекать от работы.

Мне хотелось просто пользоваться системой, а не постоянно её собирать.

2. Установка превращается в квест

Я понимаю, что сейчас есть Archinstall, но это всё равно:

• больше шагов,

• больше точек, где можно ошибиться,

• больше нюансов, которые надо держать в голове.

Для сравнения: Ubuntu/Debian/Fedora ставятся буквально за 10–15 минут без сюрпризов.
Arch — это отдельный процесс, который каждый раз занимает время, силы и концентрацию.

3. Постоянные обновления и риск поломок

Rolling release — это круто, но это также:

• риск, что обновление завтра что-то сломает,

• необходимость держать в голове зависимости,

• желание обновляться реже, но при этом понимание, что массово обновлять ещё опаснее.

Мне нужен более предсказуемый рабочий инструмент, а не адреналиновый аттракцион.

4. Много времени уходит на поиск информации

Arch Wiki — одна из лучших в мире, но:

• почти каждое действие требует чтения документации,

• часто нужно искать решения на форумах,

• иногда конфликты пакетов решаются вручную.

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

5. Минимализм оказался минусом

Arch устанавливается «голым».
Ты ставишь:

• окружение,

• драйверы,

• кодеки,

• шрифты,

• инструменты,

• конфигурируешь систему практически с нуля.

Кому-то это даёт свободу.
Мне — лишние часы, которые можно было потратить на реальную работу.

Итог

Я понимаю, за что любят Arch — скорость, свежие пакеты, гибкость. Но для моего сценария использования он требует слишком много времени и внимания. В итоге я вернулся к Debian/Ubuntu: они просто работают, а я могу заниматься задачами, а не конфигами.

Привет, Хабр! Наступила очередная пятница, поэтому я несу полезные материалы на выходные для тех, кто хочет получше освоить Ubuntu. Информация по ссылкам довольно базовая, для начинающих. Все бесплатно, без регистрации и смс. Поехали!

• Настройка файрвола в Ubuntu с помощью утилиты UFW — что за утилита, зачем она нужна, какие есть основные команды и правила работы, как подключить/отключить и так далее.

• Установка и настройка FTP-сервера на Ubuntu — разбираемся с установкой, настройкой, созданием пользователей, настройкой SSL/TLS и проверками подключений. Все разбираем на примере VSFTPD (Very Secure FTP Daemon).

• Установка и настройка прокси-сервера 3proxy на Debian/Ubuntu — пошаговая инструкция на случай, если вам нужен маленький и простой прокси-сервер.

• Установка и настройка Jitsi Meet на Ubuntu 22.04 — рассмотрим настройку публичного сервера видеоконференций Jitsi Meet, доступного из интернета, с выпуском TLS-сертификата и обязательной авторизацией.

• Установка и использование PostgreSQL в Ubuntu 22.04 — 10-минутный гайд по тому, как как развернуть PostgreSQL на виртуальной машине и научиться работать с базовыми функциями сервиса.

Привет, Хабр! Новая пятница — новые знания для начинающий специалистов! Сегодня у нас небольшая подборка инструкций по работе с командами в Linux. Пригодится будущим и начинающим системным администраторам. Как всегда, все материалы доступны бесплатно и без регистрации. Поехали!

• Что делает команда chmod и как ее использовать в Linux — разбираем синтаксис команды, ее параметры и ключи, а также основные методы изменения прав доступа.

• Команда grep в Linux — снова изучаем синтаксис, знакомимся с регулярными выражениями, смотрим на примеры использования команды.

• Команды kill и killall в Linux — подробная инструкция по принудительному завершению и настройке процессов, а также управлению их приоритетами.

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

Юрьев день для ИТ-бюджета: скидка 40% на ОС «МСВСфера», «Инферит ИТМен» и FinOps-платформу «Клаудмастер»

В акции участвуют следующие направления «Инферит»:

ОС «МСВСфера»: Российская операционная система на основе RHEL для серверов и рабочих мест. Включена в реестр ПО, имеет сертификат ФСТЭК России и подходит для госсектора и бизнеса.

«Инферит ИТМен»: Система инвентаризации и контроля ИТ-инфраструктуры. Автоматизирует учет оборудования и ПО, помогает контролировать лицензионную чистоту.

«Клаудмастер»: FinOps-платформа для управления и оптимизации облачных расходов. Доступна в формате SaaS и On-premise.

Как принять участие?

Чтобы получить скидку и зафиксировать цену, необходимо до 30 декабря 2025 года оставить заявку на сайтах продуктов:

ОС «МСВСфера»

«Инферит ИТМен»

«Клаудмастер»

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

Несколько "каверзных", вопросов для собеседования по Linuх, "подсказанных" практикой

Всем привет!

Наверное, мало кто любит проходить, или проводить собеседования, особенно второе, но, если приходится это делать, хочется что бы вопросы на нем были более “жизненными”, нежели “назовите все ключи команды ls” (сам использую 2-3, “в стрессе” вспомню еще 5-7) и, менее теоретическими, нежели “какими ключом шифруем а каким подписываем сообщение” (обычно эти операции скрыты за интерфейсом и сделать ошибку трудно)

Потому, хочу поделиться подходящими задачками, из своей практики:

Вопрос 1. Объясните вывод на экране, что будет, если повторить команду в третий раз, как избежать такого поведения?

# cp -r /etc /etc_copy
# du -hs /etc_copy
5.0M    /etc_copy

# cp -r /etc /etc_copy
# du -hs /etc_copy
10M     /etc_copy

Осознал этот забавный факт при очередной итерации развертывая kubernetes через kubespray 

Вопрос 2. Команде ping необходимы права для открытия raw socket , почему это не мешает ее использовать “обычным” пользователям?

С времен FreeBSD был уверен, что для этого используется setuid бит, но, оказалось, что в Linux не так:

student@debian:~$ ls -l $(which ping)
-rwxr-xr-x 1 root root 90568 Nov 27  2022 /usr/bin/ping

Обнаружил это, разбираясь, почему не работает модуль icmp в prometheus/blackbox_exporter , с тех пор стараюсь не забывать про POSIX capabilities  и cap_net_raw, в частности

Вопрос 3. Объясните, почему повторный запуск команды приводит к сообщению Permission denied?

debian# tcpdump -niany -w file.dmp not port 22
...
4 packets received by filter
0 packets dropped by kernel

debian# tcpdump -niany -w file.dmp not port 22
...
tcpdump: file.dmp: Permission denied

Расследование приведет к знакомству с AppArmor  - реализацией Linux Security Modules 

Вопрос 4. Объясните вывод на экране:

student@server:~$ su
Password:

server:/home/student# shutdown
bash: shutdown: command not found

Несколько раз встречал такую ошибку на занятиях , что позволяло еще раз рассказать про переменные окружения, команду “su -” и, что лучше вместо нее использовать sudo

Наверное, достаточно задачек из моего субъективного опыта, буду рад, интересным примерам из Вашего, в комментариях, Спасибо!

Вышел релиз программного обеспечения topalias 3.0.0

Установка:
pip3 install -U --upgrade topalias
pipx install --force topalias
python3 -m pip install -U --upgrade topalias
python3.10 -m pip install -U --upgrade topalias

Запуск утилиты topalias:
topalias
python3 -m topalias
python3.10 -m topalias
python3 topalias/cli.py

Изменения:
Поддерживается Ubuntu 25.10/Python 3.13, Kubuntu 22.04/Python 3.10, KDE neon Rolling

Просьба проверить на актуальной версии Python 3.15 в KDE neon

Ссылка на дистрибутив KDE neon Rolling: https://distrowatch.com/table.php?distribution=kdeneon

topalias - утилита для генерации коротких алиасов по истории bash/zsh

На GitHub опубликована открытая утилита для генерации коротких алиасов на основании истории работы в bash или zsh. Утилита анализирует файлы ~/.bash_aliases, ~/.bash_history и ~/.zsh_history с историей выполнения команд в терминале Linux, после чего предлагает короткие аббревиатуры (акронимы) для длинных, долго набираемых и сложно запоминаемых, но часто используемых команд. Также поддерживается вывод статистики по истории работы в командной строке.

Если вы работаете в терминале десятки раз в день, алиасы — это мощный инструмент повышения эффективности. Но с ростом количества проектов и конфигураций .bashrc/.zshrc алиасов становится много: часть дублируется, часть устарела, некоторые перекрывают системные команды. topalias решает три задачи:

• дать метрику использования алиасов (какие используются чаще всего);

• упростить создание/удаление/пакетное управление алиасами;

• находить конфликтные или опасные алиасы и предлагать безопасные альтернативы.

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

Ключевые возможности

• Сбор статистики использования алиасов на основе shell-history.

• Команда top — список наиболее часто используемых алиасов.

• Интерактивный режим (TUI) для обзора, включения/выключения и редактирования.

• Поддержка bash, zsh и fish.

• Экспорт/импорт в виде конфигурационных файлов и git-репозиториев.

• Поиск конфликтов (алиас затеняет системную команду) и предупреждения.

• Генератор «умных» алиасов: на основе частых цепочек команд предлагает сокращения.

• Пакетная миграция между машинами (pack/unpack).

• Небольшой daemon/cron для частого обновления статистики (опционально).

# клонируем репозиторий

git clone https://github.com/CSRedRat/topalias.git

cd topalias

# установка в виртуальное окружение (рекомендуется)

python -m venv .venv

source .venv/bin/activate

pip install -e .

# инициализация в shell (одна строчка, добавьте в .bashrc/.zshrc)

topalias init --shell auto >> ~/.topalias-shell-rc && source ~/.topalias-shell-rc

Примечание: init генерирует небольшую обёртку для history-hook, чтобы собирать данные об использовании алиасов без заметной нагрузки.

Подписывайтесь на канал в Telegram: https://t.me/ruopsdev

Второй канал на Телеграм: https://t.me/journal_rbc_pro

• Просмотр самых часто используемых алиасов:

topalias top
topalias top --limit 20 # или с лимитом

• Найти алиас по фрагменту:

topalias find git

• Создать алиас:

topalias add ga='git add --all'

• Удалить алиас:

topalias rm ga

• Интерактивный режим (TUI):

topalias ui

• Экспорт текущих алиасов в файл:

topalias export --format bash > ~/.topalias-export.sh

Импорт из файла:

topalias import ~/.topalias-export.sh

Если вы часто выполняете цепочку:

git add . && git commit -m "WIP" && git push

topalias предложит вариант:

topalias suggest
# suggestion: gpush = git add . && git commit -m "WIP" && git push
topalias add gpush='git add . && git commit -m "WIP" && git push'

Проверим, не перекрывает ли алиас системную команду:

topalias check-conflicts
# output:
# - ls -> aliased to "ls --color=auto" (OK)
# - df -> aliased to "du -h" (DANGER: shadows system df)

Сохраняем пакет алиасов и переносим на другой компьютер:

topalias pack --name work-aliases > work-aliases.tar.gz
# на другом хосте
topalias unpack work-aliases.tar.gz
topalias import unpacked/work-aliases.sh

Самый простой способ сообщить об успешном подключении по SSH

Всем привет! Вообще-то, обычно решают обратную задачу - сообщить о неудачных попытках подключения по SSH, а еще лучше - сразу заблокировать. С этим прекрасно справляет, например, Fail2ban, но, рассказ не о нем. Может оказаться полезно получать уведомления именно об успешных подключениях, особенно, в тот момент, когда сам НЕ подключаешься. Так же, хочется сделать это с наименьшими усилиями, без написания скриптов, без установки специфического ПО, что бы было легко "скопипастить" решение на множество систем. Так же, хочется знать не тoлько о подключениях, получивших shell, но и о удаленном выполнении команд, или копировании файлов по протоколу SSH.

Все есть в этом решении:

$ sudo apt install curl

$ sudo nano /etc/pam.d/sshd

оставьте, все, что было в этом файле и добавьте в конец:

session optional pam_exec.so /bin/bash -c (echo${IFS}Subject:ssh-${PAM_USER}@$(hostname)-${PAM_RHOST};/usr/bin/env)|/usr/bin/curl${IFS}smtp://mailhub.yourcorp.ru${IFS}--mail-from${IFS}noc@yourcorp.ru${IFS}--mail-rcpt${IFS}yourlogin@yourcorp.ru${IFS}--upload-file${IFS}-

Да, этого достаточно!

Как оказалось, curl умеет отправлять почту, в сообщении будут присутствовать все подробности, кто, когда, откуда подключился, и, даже, когда отключился. Правда, в этом решении требуется корпоративный почтовый сервер (mailhub.yourcorp.ru в нашем "однострочнике"), готовый принять письмо без аутентификации. Это допустимо, если он же является конечным сервером с ящиком пользователя, или, есть разрешение пересылки писем из корпоративной сети (в этом случае можно использовать любой другой почтовый адрес, вместо yourlogin@yourcorp.ru). Однако, такой сервер не всегда имеется, и решение не годится для персонального использования.

В этом случае, предлагаю Вам вебинар , демонстрирующий решение той же задачи, с отправкой сообщений в Telegram

На этом все, спасибо, буду рад ответить на вопросы!

🔥 Как это было! Итоги Ansible Security CTF

14 октября мы собрались в уютном Failover Bar (г. Санкт-Петербург) 🏠, чтобы по-настоящему прокачать свои навыки в DevOps и кибербезопасности 🚀

Огромное спасибо всем участникам нашего интенсива "Ansible Security CTF – Защищай и Атакуй!" – вы сделали этот вечер незабываемым! 🙏

Что мы делали:
🛡 Писали Ansible playbooks, чтобы мгновенно закрывать уязвимости
🔎 Активно сканировали, подбирали пароли, искали флаги с помощью nmap, hydra и curl
💬 Общались, обменивались опытом и заводили новые знакомства!

🎉 Поздравляем победителей и напоминаем, что еще месяц в Failover Bar можно потренироваться на кейсах из интенсива! 💡В этом вам поможет бот 🤖 для CTF - https://t.me/DebugProCTF_bot

📆 Не хотите пропустить следующие мероприятия? Подписывайтесь на бота 🤖 DebugSkills - https://t.me/DebugProBot

👀 Ссылка на запись мастер-класса тут - https://vkvideo.ru/playlist/-232485571_2/video-232485571_456239019?linked=1

👀 Все фото в нашем канале - https://t.me/DebugSkills