Настройка Linux *

У моего клиента есть пара железных серверов, которые используются для хранения и раздачи статических файлов. Все бы ничего, но любое оборудование требует внимания и регулярного мониторинга. Со временем диски, модули памяти и другие компоненты могут выходить из строя. Причем умирают они не сразу, сначала молча сыплются ошибки в логи, а потом уже поздно что-то предпринимать: даунтайм, kernel panic, fatal error, ретроспектива и панические атаки. Поэтому важно своевременно отслеживать состояние инфраструктуры и реагировать на предупреждения до того, как они перерастут в серьезные инциденты.

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

Выражение «искусственный интеллект всех заменит» заиграло новыми красками. Нет, от естественного интеллекта я не отказываюсь, но конкретно анализом «здоровья» этих железных серверов теперь занимается локальная ИИшница. Сейчас покажу, что удалось запилить, как я прикрутил локальную модель и написал нишевого агента под нужды клиента, чисто для анализа логов с железных серверов.

Я использую Linux 15 лет. Ну, то есть как использую: первые года три я его настраивал, а не использовал. Это разные вещи, и мне понадобилось позорно много времени чтобы это понять.

Сейчас у меня Fedora. Из коробки. С GNOME. Почти без кастомизации. Я набираю в ней код, сижу в браузере, иногда монтирую видео для внутренних демок. Всё работает.

Пятнадцать лет назад я бы от такого описания плевался. Как это «из коробки»? А где i3? Где polybar? Где 400 строк .vimrc? Где кастомный скрипт на баше который при подключении второго монитора переключает раскладку DPI и температуру цвета?

Ну вот, нету. И ничего не сломалось.

Продолжаем серию о Linux. В прошлой части разбирали права доступа, а теперь переходим к одной из самых важных тем в Linux — процессам. Любая программа в системе в конечном итоге существует как процесс: nginx, postgres, docker, sshd, systemd, ваш shell и даже потоки ядра. Понимание того, как процессы создаются, живут, взаимодействуют с ядром и завершаются, — это база для понимания и диагностики Linux-систем. Цель этой статьи — рассказать кратко и простым языком всю нужную информацию как для начинающих, так и для опытных пользователей и админов, чтобы освежить знания. Важно: для практики, если обучаетесь, лучше всего использовать виртуалку с Linux.

Один из ярких воспоминаний детства — просмотр семьёй диафильмов. Выключался свет, и на самодельном экране из простыни мы смотрели сказки. Детское воображение дорисовывало детали, и картинки оживали.

Сейчас в эпоху интернета, мультимедиа и ИИ вроде бы как такой необходимости нет, но слишком сильное чувство ностальгии. Поэтому решил получить ностальгические воспоминания с использованием современных технологий, а заодно и попрактиковаться в использовании энкодеров, разработке программ на Си и настройке Linux на Raspberry Pi.

Если назначить файлу владельца root на хосте — будет ли это тот же самый root внутри контейнера?

Если на хосте существует пользователь gtosss — можно ли переключиться на него внутри контейнера и получить доступ к файлу?

Если создать пользователя gtosss внутри контейнера и выдать ему права на файл — сможет ли хост обратиться к этому файлу под таким же пользователем?

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

Разобрал три конкретных сценария на Ubuntu с Docker и Fedora с Podman: как UID/GID влияют на доступ к файлам, почему root в контейнере может быть root на хосте и что с этим делает user namespace. Эксперименты, cli и доступные объяснения.

Это гайд по настройке через UI нового, разработанного мной, русифицированного приложения для OpenWRT с hiddify-core - HomeProxy Hiddify, он позволяет настроить подключение к NaiveProxy, Mieru, ShadowTLS, Hysteria2, XRay, VLESS (XHTTP), VMESS, Trojan, TUIC и иным протоколам которые поддерживает Hiddify App в т.ч. с помощью подписок (subscription). В статье рассмотрим установку и настройку приложения для раздельного туннелирования на примере списков Re:filter

В статье пойдет речь о SELinux. Главная моя задача — провести быстрый онбординг о том, как работать с политиками доступов. Я хочу показать, что это вовсе не так сложно, как может показаться на первый взгляд. Буквально 15 минут ознакомления с базовыми понятиями дает 80% понимания как работать с SELinux более уверенно.

Статья не совсем про написание политик, скорее про их понимание. Все описанное необходимо, чтобы уверенно пользоваться утилитами, более осмысленно работать с системой, решать проблемы и задачи, с которыми придется столкнуться в процессе эксплуатации SELinux.

Старая сисадминская пословица гласит: люди делятся на две категории — на тех, кто уже делает резервные копии, и тех, кто только будет их делать.

Связка Btrfs + btrbk — это революция в мире бакапа. Ещё никогда не было так просто и быстро создавать дифференциальные резервные копии. Никаких лицензий и подписок — всё полностью бесплатно и встроено в ядро Linux.

Продолжаем серию рубрики Linux. В прошлой серии разобрали пользователей и группы – UID, GID, /etc/passwd. Теперь разберём что ядро делает с этими числами когда процесс пытается открыть файл или войти в директорию. Про права доступа легко выучить команды – chmod 755, chown user file – но не понимать что происходит под капотом. Тогда начинаются странные ситуации: «я же владелец, почему Permission denied?». Цель этой статьи – кратко но в достаточной форме рассказать про права доступа.

Вся статья построена на практике: каждый раздел можно пройти руками. Для большинства примеров достаточно обычного пользователя, для части нужен sudo. Где нужен – отмечено явно. Серия в основном под Ubuntu/Debian.

В конце статьи будет бонус который даст вам возможность изучить права доступа в Linux ещё доступнее и возможно проще.

Обновление статьи: 2026-05-14

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

Собрал в одном месте всё, что нужно знать о правах в Linux, простым и понятным языком: символьная и восьмеричная нотация, SUID/SGID/Sticky bit, SELinux-контекст, DAC, MAC, RBAC, ABAC, команды ls/stat/chmod/chown/find — с примерами и схемами, к которым легко вернуться.

Миграция на Podman — вопрос достаточно интересный. И ответ на него достаточно простой — берете и мигрируете, там делов-то!

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

Если у вас есть конфигурационный файл docker‑compose.yml, то в большинстве случаев его можно запустить через Podman без переписывания. Так вы, с одной стороны, сохраните привычный воркфлоу, а с другой — получите преимущества rootless‑контейнеров. В Docker же для запуска compose-файлов раньше использовалась внешняя утилита Docker Compose, но спустя время Docker внедрил возможность запускать такие файлы нативно через Docker Compose plugin.

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

В Podman аналогично есть Podman Compose — подкоманда, которая запускает внешний провайдер. В качестве такого провайдера может выступать Docker Compose / docker‑compose. Вот во всем этом сегодня и разберемся.

Десять устройств дома, и каждому нужен прозрачный доступ к моей удалённой инфраструктуре. Ставить клиент защищённого канала на телевизор и колонку — невозможно, на телефон — клиент «молча» отключается, и трафик идёт мимо канала.

Я настроил прозрачный прокси-шлюз на роутере: VLESS+Reality+XTLS-Vision через TPROXY на OpenWrt. Сплит-роутинг по GeoIP и доменам, автообновление списка серверов из подписки каждые 30 минут, балансировка по задержке, procd с автоперезапуском. В статье — полный путь от коробочного Cudy TR3000 до рабочей системы: nftables, policy routing, base64-декодер на awk и все баги, которые я нашёл по дороге.

Часть 2: https://habr.com/ru/articles/1028954/

Когда ваше приложение состоит из нескольких сервисов, например бэкенда, БД и кэша, невольно возникает вопрос — а как гарантировать, что они запустятся в правильно порядке и вообще увидят друг друга? В Docker это решается с помощью depends_on, тут ничего нового. А вот в Podman подход немного другой. Ну кто бы сомневался!

Когда мы запускаем контейнер, в большинстве случаев предварительно нужно указать настройки: порт, пароль, режим работы, адрес базы и т. д. Зачастую такие параметры жестко прописывают в самом коде, но это плохой стиль и вообще идея так себе. В будущем вы можете «затроить» и все это слить в git-репозиторий. А как мы знаем, хранить чувствительные данные в там нельзя.

Удобнее и гибче использовать переменные окружения. Те самые, которые environment variables. С помощью переменных можно настраивать поведение контейнера, использовать разные конфигурации (dev/stage/prod), безопасно передавать чувствительные данные. Как видите, одни плюсы.

Работа с переменными в Podman строится практически так же, как в Docker. Есть некоторые нюансы, но о них расскажу чуть позже. Сейчас давайте потыкаем на практике и посмотрим, что же происходит.

Начиная работать с Podman, я задал себе вопрос — функционирует ли healthcheck в Podman так же, как в Docker? Да и нет. В этой статье разберем, зачем он вообще нужен, какие бывают типичные ошибки при запуске контейнера с healthcheck, выясним детали о systemd и Quadlet.

Некоторое время назад, Роскомнадзор, в очередной раз, решил усложнить мне жизнь, а именно - стал блокировать и разрывать VPN-соединения по протоколу SSTP (Secure Socket Tunneling Protocol), при помощи которого я подключался к устройствам в своей домашней сети. Протокол SSTP относительно медленный, но к числу его преимуществ можно отнести то что он не требует наличия "белого" IP-адреса, т.к. он использует SSL / TLS канал и способен работать через Keenetic Cloud с использованием доменного имени, зарегистрированного в облачной службе KeenDNS.

Блокировки и разрывы SSTP-подключений продолжались примерно 2 или 3 недели и потом прекратились, однако невозможность всё это время нормально использовать свою домашнюю сети (где у меня, например, находится экспериментальный стенд) побудила меня искать альтернативные способы подключения к себе домой.

В этой статье будет рассказано о том, как развернуть на выделенном виртуальном сервере (VPS / VDS) свой личный VPN-сервер, работающий по протоколу AmneziaWG, а затем сконфигурировать развернутый VPN-сервер и домашний роутер фирмы Keenetic таким образом, чтобы внешние клиенты, подключившись к VPN-серверу получали доступ к устройствам в домашней сети.

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

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

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

Вводные:

1) у вас есть крохотная виртуалка на которой крутится nginx и пара сайтов. Конечно https и скорее всего let's encrypt — короче стандартный набор рядового девелопера.

2) вы бы хотели поднять телеграм-прокси, но так чтобы трафик на него был максимально похож на обычный https, а это значит 443 порт — но вы хотите чтобы nginx и ваши сайты продолжили работать как и раньше.

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

Купил портативный проектор HY-300 — оказался не самым "ярким" представителем. Через ADB и root добрался до прошивки, нашёл скрипт testgamma, который при каждой загрузке занижает яркость до 70%. Разобрался как работает gamma LUT в видеопроцессоре VOP, какие параметры реально влияют на картинку, а какие — пустышки. Пошаговая инструкция по выжиманию максимума из проектора.