Любой, кто ставил софт в Linux, набирал apt install или pacman -S. Внешне разница косметическая: одни команды длинные, другие короткие. Но за этими командами стоят две принципиально разные инженерные философии.

Почему pacman ощутимо быстрее, но при этом опаснее в руках новичка? Почему Arch категорически запрещает частичные обновления, а Debian их даже не замечает? И почему один менеджер задаёт вопросы про конфиги, а другой молча подкладывает .pacnew?

Разбираем, что происходит внутри при установке пакета: форматы архивов, базы данных, решатели зависимостей, скрипты и хуки. Погружаемся в устройство apt/dpkg и pacman/libalpm глубже, чем в большинстве туториалов.

Представьте картину: вы руководитель склада на пищевом производстве, вам нужно распечатать и раздать сотрудникам задания, а рабочий МФУ в очередной раз уходит в «циклическую кому». Добавьте в уравнение ещё одну переменную: в компании попросту нет не то что ИТ‑отдела — эникея, которому можно было бы поручить дебаг. И эта вакханалия происходит изо дня в день у всего нашего офиса.

Полгода на Arch, одно обновление ядра и AmneziaWG выходит из строя. Snapper молчит, бэкап сломан. Решил попробовать NixOS…

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

Восстановление данных буду делать с помощью второго PostgreSQL контейнера. Если кратко - данные WAL и base_backup будут прокидываться с помощью volume и контейнер будет стартовать с новыми данными.

Пока что рабочий стенд будет ограничиваться PostgreSQL 17 в Docker (без S3, Kubernetes, автоматизации и т.п), потом возможно сделаю дополнительные статьи, охватывающие более сложные production случаи.

Строчка, которая встречается в скриптах повсеместно:

mysql -u admin -pSecretPass123 -e "select 1"

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

Изначально с Capabilities я лично столкнулся в своем проекте ServeHub-2, когда настраивал контейнеры в docker-compose. Если быть более конкретным, я настраивал WG-easy с использованием AmneziaWG, которому нужны были привилегии, связанные с загрузкой модулей ядра и настройками интерфейсов. До этого я слышал о Capabilities, но не знал что это такое, поэтому решил подробнее в этом разобраться.

Сначала разберу общее понятие, что вообще такое Capabilities (далее буду кратко писать CAP), потом постепенно перейду к примерам.

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