*nix *

И снова привет! Я Владимир, технический лидер по развитию сервисов Evolution Data Platform в Cloud.ru и фанат древних рабочих станций, которые несли на себе всю тяжесть цифрового мира 90-х под операционной системой UNIX. В первой части мы сделали длинный экскурс в историю компании Sun Microsystems и ее продукции, посмотрели, что находится внутри рабочей станции Sun SPARCStation 5 и хирургическим путем вылечили ее детскую болезнь, которая препятствовала загрузке и работе.

В следующей части статьи мы погрузились в историю средних веков (UNIX-войны начала 90-х), поговорили в целом о мире коммерческого UNIX-а, установили на Sun SPARCStation актуальную операционную систему Solaris, настроили ее и вышли во «всемирную паутину».

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

Как systemd превратил обычный скрипт перезапуска в бесконечный дедлок — почему мониторинг не заметил собственную смерть

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

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

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

Устал смотреть в логи: опять подбор пароля к ssh, опять лезут в несуществующие файлы сайта. Fail2ban ставил — утонул в настройках. Написал своё: обходит свой сайт, запоминает нормальные адреса, по лишним 404 и по ssh режет IP в nftables. Рассказываю — зачем и как ставил. Код покажу там, где самому было интересно.

Эта статья является прямым продолжением этой статьи, посвящённой декларативной разметке диска через disko.

Что мы будем делать сегодня?

Мы с вами разберёмся, что такое флейки, что они из себя представляют, а вместе с этим разберёмся с тем, как Nix устанавливает и хранит пакеты.

Это ЧИСТО ТЕОРЕТИЧЕСКАЯ статья, а не практическая. Иными словами - мы не будем сегодня писать никаких конфигураций или команд. Наша задача на данный момент - разобраться, что такое флейки и какую проблему они решают, прежде чем перейти к непосредственной работе с ними.

Что мы узнаем?

1. Что такое флейки, зачем они нужны и чем отличаются от стандартного nix-channels

2. Как работает установка и хранение пакетов в NixOs

Один публичный IP, один 443-й порт, на нём уже работает сервис с живыми пользователями — и туда же нужно посадить второй. Менять настройки на устройствах пользователей нельзя.

Разбираю, как разделить порт между двумя TLS-сервисами, ничего не расшифровывая: SNI уходит открытым текстом в ClientHello, и nginx умеет читать его директивой ssl_preread, оставаясь для TLS прозрачным. Отдельно — почему всё держится на ветке default, чем за прозрачность платят (бэкенд перестаёт видеть реальные адреса клиентов) и когда у этого решения закончится срок годности.

Не так давно наткнулся на статью Red Hat про разблокировку LUKS-шифрования по SSH. Суть там простая: сервер с зашифрованным корнем перезагружается, замирает в initramfs и ждёт парольную фразу на консоли, за которой никто не сидит. Решение у редхатовцев выглядит довольно простым: поставить пакет dracut-sshd, включить модуль NetworkManager в initramfs, дописать параметры ядра. Несколько команд, и застрявшая машина открывается по SSH с вашего дивана.

И стало мне интересно: а как та же задача решается, если у меня на серваках крутится не RHEL, а наш Альт? Копировать редхатовский рецепт вслепую смысла нет: у Альта собственная система сборки initramfs и свои механизмы ранней загрузки. Тем любопытнее посмотреть, как всё устроено здесь.

TL;DR. Сделать можно. Проверил это на живой виртуалке. Рецепт в итоге вышел на удивление прямолинейный, но с двумя-тремя особенностями, о которых лучше узнать из статьи.

Lenovo Tab M11 на моём столе загружается с внутренней памяти в Kubuntu.

KWin работает через DRM/KMS, Mesa рисует через Panfrost, звук идёт через PipeWire, сетью занимается NetworkManager. Bluetooth виден как обычный hci0, сенсоры — как IIO, камеры — как V4L2. Стилус работает с давлением и наклоном.

Камеры тоже завезли: задняя умеет полноценно фотографировать не только в jpg, но и в RAW, и писать видео 1080p/30fps, а еще обе камеры при этом доступны обычным Linux‑приложениям как /dev/video-rear и /dev/video-front.

Android? Отправлен за 101-й километр.

Такого плана в начале у меня не было.

Вы наверняка сталкивались с этим эффектом: монтируете sshfs, rclone mount или gocryptfs — и после этого файловый менеджер, редактор, архиватор и бэкапилка работают с появившимся каталогом так, будто перед ними самая обычная файловая система. Хотя байты могут жить на сервере, в S3, внутри шифрованного каталога или вообще рождаться на лету.

Как программа из userspace умудряется встать между open() и данными так, чтобы остальная система ничего особенного не заметила? Сегодня разберёмся. Заваривайте чай покрепче (ядро любит крепкий), устраивайтесь поудобнее — поговорим про FUSE.

Сразу одна оговорка, чтобы не заложить мину в фундамент статьи: не всякая «сетевая папка» или подключённый телефон в файловом менеджере — это FUSE. GNOME GVfs, KDE KIO и MTP умеют показывать похожую картину на уровне приложений. FUSE идёт глубже: он подключается к файловому стеку ядра, поэтому смонтированное дерево видят обычные программы через привычные open(2), read(2), stat(2) и компанию.

Продолжая поиски интересных курсов(в этот раз не авито), я наткнулся на необычный материал по контейнеризации. Обычно всё выглядит одинаково: Docker, команды, образы, и в конце внезапно появляются Ansible и Kubernetes. Как будто без них нельзя объяснить, что такое контейнер. Или авторы просто пытаются запихнуть побольше в один курс, чтобы казалось, будто его стоимость оправдана. Ну да ладно.

А мне хотелось чего-то другого. Помните книгу про внутреннее устройство Linux Кетова?
Ещё в 2022 году мне понравилось, как подавался материал про контейнеризацию — от самых её зачатков (chroot) до самого Docker. Вот именно такое я хотел увидеть у кого-нибудь, но с актуализированной информацией.

И такой курс нашёлся на Степике(не реклама если что). Автор как раз пошёл от самого начала: chroot, пространства имён, контрольные группы, ручной запуск контейнера без Docker, и только потом — сам Docker со всеми его фишками. По сути, это получилась современная версия той самой главы из книги Кетова про контейнеризацию.

Один сломанный bash-скрипт. Семь настоящих багов — от косметических (устаревшие имена файлов в комментариях) до фатальных: сводная таблица, которая всегда показывает нули, что бы на самом деле ни произошло.

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

Забегая вперёд — ровно настолько, чтобы не испортить интригу: на старте модели расходятся куда сильнее, чем можно было бы ожидать. Ни одна модель не нашла всё. И слепые зоны у них не совпадают. Собственно, поэтому эксперимент и имеет смысл ставить, а не рассуждать о нём в теории.

Представьте: пятница, 17:45, вы уже мысленно в пивной. И тут тишина... Мониторинг орет красным. Ваш Proxmox кластер из 4 нод превратился в группу статуй. Ни одна VM не отвечает, команды qm list висят, а в логах — таинственные вопросительные знаки на месте дисков.

😱 Диагноз: NFS-сервер упал, а монтирование было с опцией hard. Все ноды дружно вошли в D-state (непрерываемый сон) и отказались просыпаться.

Мораль: hard монтирование в NFS — это как клей Moment. Склеивает намертво. И оторвать потом невозможно.

Эта статья является прямым продолжением этой статьи, посвящённой декларативной разметке диска через disko.

Что мы будем делать сегодня?

Мы с вами составим минимально-рабочий конфиг для нашей системы. Под "минимально-рабочим" я имею в виду: без графического окружения(XFCE, GNOME и прочее), углублённых настроек(установка zsh, например). Мы настроим: загрузчик, сеть, пользователя, звук, локализацию, подключим наш файл disko-config.nix.

Каждый, кто хоть раз устанавливал Linux вручную, знает этот ритуал: загрузиться с Live‑образа, запустить fdisk или parted, создать таблицу разделов, отформатировать их в btrfs/ext4, создать субтома, а затем вручную примонтировать всё это в /mnt.

Конечно, такой подход можно использовать и при установке NixOs. Но вопрос — зачем?

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

В этой статье мы этим вопросом и займёмся, а поможет нам в этом известная утилита disko. Мы напишем чистый декларативный конфигурационный файл в ДВУХ вариантах:

Задача:

Есть "коробка" с работающей 24/7 OmniOS. Со временем в "коробке" накопилось столько всего важного, что стоимость этой информации превысила стоимость самой "коробки". Наиболее вероятная угроза информации - это фатальный сбой файловой системы при сбоях электропитания. Нужно научить OmniOS "слушать" сообщения от ИБП и самостоятельно выключаться пока ИБП выдает напряжение.

Ну что же — то, чего все ожидали (не путать с «ждали») случилось. Многие российские сайты и сервисы начали переходить на сертификаты Минцифры — и у пользователей начали ломаться работавшие ранее сервисы, пользователи начали получать сообщения, что подлинность ресурса не может быть проверена. Кто‑то просто не смог продлить свой сертификат, у других сертификаты вообще были отозваны — но, в конечном итоге, это приводит к одному и тому же результату — из-за проблем с сертификатом сайты некоторых российских компаний перестают открываться через HTTPS (каковой де‑факто уже давно стал стандартом), а получить новые сертификаты становится проблемой.

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

День выдался долгий и по‑настоящему безрадостный. Сегодня произошло то, чего мы больше всего не любим: Туннельный Котик перестал помогать многим людям, и мы, вероятно, потеряли изрядную долю доверия.Больнее всего это ударило по самым старым и лояльным пользователям — тем, кто был с нами практически с самого начала. Брешь всё ещё приходится латать, и заниматься этим придётся не один день.

Больнее всего это ударило по самым старым и лояльным пользователям — тем, кто был с нами практически с самого начала. Брешь всё ещё приходится латать, и заниматься этим придётся не один день.

Но раз уж вечер располагает к разговору — самое время ответить на вопрос, который нам регулярно задают: зачем вообще нужен ещё один проект, если есть множество готовых VPN‑сервисов и решений вроде AmneziaWG? Можно в конце концов поднять свой собственный VPN, а кто не умеет — тот, в общем, сам виноват.

В целом всё это верно. За исключением того, что мы решаем совершенно другую задачу.

Технология eBPF (extended Berkeley Packet Filter) берет свое начало от классического BPF, разработанного в начале 1990-х годов как механизма фильтрации сетевых пакетов, который впоследствии был реализован в Linux и других UNIX-подобных системах. Со временем возможности BPF значительно расширились, и появился eBPF — универсальная виртуальная машина, позволяющая безопасно выполнять пользовательские программы непосредственно внутри ядра без необходимости разрабатывать отдельные модули ядра. Сегодня eBPF применяется далеко не только для обработки сетевого трафика. Он используется для трассировки, мониторинга производительности, обеспечения безопасности, балансировки нагрузки, реализации сетевых политик и многих других задач. Перед загрузкой программа проходит проверку специальным верификатором ядра, гарантируя ее завершаемость, корректность обращений к памяти и соблюдение требований безопасности ядра. Благодаря этому eBPF позволяет расширять функциональность ядра без необходимости писать или загружать собственные модули ядра…

Claude Code History Viewer читает ~/.claude/projects и превращает машинный JSONL в нормальный интерфейс: диалоги с тулколлами и сабагентами, глобальный поиск, статистика по токенам и стоимости, плюс истории ещё 27 клиентов вроде Codex CLI и Cursor. Показываю, как поднять его headless-режим в Docker на сервере без иксов (готовый бинарь + тонкий образ), что показывает Global Overview на 3,4 ГБ истории, как дёргать те же команды по HTTP через POST /api/<имя> и на какие мелочи я наступил — от обрезанного в логе токена до лимита памяти 512 МБ в официальном compose.

Недавно мне потребовалось перенести корпоративный портал Bitrix24 на новую BitrixVM.

По документации всё выглядело достаточно просто:

Бывает задача: «каталог лежит в корне, надо чтобы он был отдельно, гигов на пять». Вот как это делается .