Обновления Arch Linux на сервере без неожиданностей: pinning пакетов, pacman hooks и контроль изменений конфигов
Arch Linux как роллинг-релиз приносит на сервер быстрые обновления, но вместе с ними – риск внезапных изменений поведения сервисов, форматов конфигураций и зависимостей. На рабочем виртуальном сервере (VPS/VDS), где важны предсказуемость и управляемые окна обслуживания, задача обычно формулируется так: обновлять систему регулярно, но так, чтобы сюрпризы выявлялись до простоя, а изменения конфигов не «терялись» среди пакетов.
Ниже описан практический сценарий, который сводит риск к разумному минимуму без попыток «сделать Arch стабильным дистрибутивом». Упор сделан на три механизма: фиксацию (pinning) критичных пакетов, pacman hooks (ALPM hooks) для автоматических проверок и отчетов, а также дисциплину работы с изменениями конфигураций (.pacnew/.pacsave) и историей /etc.
Базовый принцип: обновление как контролируемая транзакция
В серверной эксплуатации полезно относиться к pacman -Syu не как к рутинной команде, а как к транзакции, для которой существуют входные условия и постконтроль. Типовой «контур предсказуемости» выглядит так:
- Перед обновлением: убедиться, что прошлые изменения конфигов разобраны, диска достаточно, список обновлений понятен, критичные версии временно зафиксированы
- Во время транзакции pacman: исключить частичные обновления и непредвиденные действия (например, автоматические рестарты не там и не тогда)
- После обновления: получить отчет, увидеть .pacnew/.pacsave, понять, нужен ли рестарт сервисов или перезагрузка, зафиксировать изменения /etc
На практике именно «обвязка» вокруг pacman, а не сам pacman, определяет, насколько спокойно проходят обновления на VPS/VDS.
Подготовка: инструменты, без которых контроль неудобен
Для большинства описанных приемов достаточно базовой системы и пакета pacman-contrib:
pacman -S pacman-contrib
Он добавляет утилиты, которые часто становятся стандартом для серверов:
- pacdiff – поиск и разбор .pacnew/.pacsave
- paccache – управление кэшем пакетов (важно для отката)
- checkservices – подсказка, какие systemd-сервисы стоит перезапустить после обновлений
Отдельно стоит продумать место для тестового контура. В реальных внедрениях часто используется отдельный недорогой виртуальный сервер для «прогона» обновлений и проверки прикладных сервисов на копии конфигов. Такой стенд нередко поднимается у любого провайдера аренды VPS; в качестве примера встречается VPS.house, если требуется быстро развернуть дополнительную машину в Москве под короткое окно тестирования.
Pinning пакетов: как фиксировать версии без самообмана
Pinning на Arch Linux почти всегда означает не «навсегда остаться на версии X», а отложить конкретное обновление до момента, когда изменения будут проверены, конфиги подготовлены, миграции выполнены. Это важное ограничение: долгий «замороз» в роллинг-релизе рано или поздно упирается в несовместимость зависимостей и безопасность.
1. IgnorePkg и IgnoreGroup в /etc/pacman.conf
Самый простой и распространенный механизм – директивы IgnorePkg и IgnoreGroup:
/etc/pacman.conf
IgnorePkg = postgresql postgresql-libs
IgnoreGroup =
После этого pacman -Syu будет пропускать указанные пакеты при апгрейде. Это удобно для «пауз» на время миграции (например, перехода между мажорными версиями СУБД), но важно учитывать последствия:
- Риск зависимости: другой пакет может потребовать более новую версию зафиксированного. Тогда pacman либо предложит удалить конфликтующий пакет, либо остановит транзакцию
- Риск ABI: если фиксируется библиотека, остальной мир может ожидать новый ABI. Такие пины на сервере применяются аккуратно и короткими периодами
- Безопасность: игнорирование обновления часто означает пропуск патчей; срок «заморозки» должен быть ограничен
Дополнение к практике: фиксировать целесообразнее прикладные компоненты (СУБД, интерпретаторы, крупные фреймворки) и избегать долгого удержания базовых крипто/системных библиотек, если отсутствует четкий план обновления.
2. Разовое игнорирование из командной строки
Для единичной ситуации иногда подходит флаг --ignore:
pacman -Syu --ignore postgresql,postgresql-libs
Метод удобен, когда заморозка нужна на один прогон обновлений. Минус – человеческий фактор: «разово» легко становится «случайно постоянно» в разных скриптах и привычках администраторов.
3. Заморозка репозитория по дате через Arch Linux Archive
Если задача состоит в том, чтобы сохранить всю систему в «срезе» определенной даты (например, стабильное окружение на месяц), полезен Arch Linux Archive (ALA). Смысл подхода – использовать репозитории на конкретный день, чтобы пакеты и зависимости оставались согласованными.
Схема подключения обычно выглядит так (пример даты условный):
/etc/pacman.d/mirrorlist
Server = https://archive.archlinux.org/repos/2025/01/01/$repo/os/$arch
Ограничения ALA, которые важно понимать заранее:
- Безопасность: «срез» репозитория – это также «срез» уязвимостей; обновление «по расписанию» должно быть частью политики
- Смешивание источников (часть пакетов из ALA, часть из актуальных зеркал) быстро приводит к частичным обновлениям и конфликтам. В подобных сценариях лучше фиксировать все репозитории одним срезом
- Ключи и подписи: старые пакеты подписаны корректно, но иногда требуется актуальный archlinux-keyring, чтобы не упираться в ошибки валидации. Это не «обход», а нормальная эксплуатационная необходимость
ALA полезен не только для «заморозки», но и для контролируемого отката, когда нужной версии уже нет в кэше пакетов.
4. Локальный репозиторий для удерживаемых пакетов
Если один или несколько пакетов должны оставаться на заданной версии дольше, чем комфортно для IgnorePkg, используют локальный репозиторий. В нем хранится «разрешенная» версия пакета, а pacman предпочитает ее как обычный источник.
В общих чертах подход выглядит так:
- скачать нужный .pkg.tar.zst (например, из кэша или ALA)
- создать каталог локального репозитория, добавить пакет и сформировать базу repo-add
- подключить репозиторий в /etc/pacman.conf выше стандартных
Плюс – лучше управляемая «полка» разрешенных версий. Минус – администрирование такого репозитория и необходимость понимать, какие зависимости удерживаются вместе с целевым пакетом.
Pacman hooks: автоматический «предохранитель» вокруг обновлений
Pacman hooks (ALPM hooks) – механизм запуска команд по событиям транзакции: до/после установки, обновления или удаления пакетов. Для сервера hooks ценны тем, что превращают ручные чек-листы в повторяемую процедуру и снижают риск забыть важный шаг.
Хуки обычно размещаются в /etc/pacman.d/hooks. Файлы имеют расширение .hook, порядок выполнения регулируется именем (часто используют числовой префикс) и условиями срабатывания.
Минимальный обязательный хук: pre-flight перед транзакцией
Одна из частых причин неожиданностей – накопленные .pacnew/.pacsave и нехватка места на диске в момент обновления (особенно на небольших VPS, где /var и / занимают один раздел). Обе проблемы можно «отсекать» до начала транзакции.
/etc/pacman.d/hooks/00-preflight.hook
[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Package
Target = *
[Action]
Description = Pre-flight: проверка .pacnew/.pacsave и свободного места
When = PreTransaction
Exec = /usr/local/sbin/pacman-preflight
Пример скрипта:
/usr/local/sbin/pacman-preflight
#!/bin/sh
set -eu
# 1. Запретить транзакцию, если в /etc остались неразобранные .pacnew/.pacsave
if find /etc \( -name '*.pacnew' -o -name '*.pacsave' \) -print -quit | grep -q .; then
echo 'Найдены .pacnew/.pacsave в /etc. Перед обновлением требуется разбор изменений.'
find /etc \( -name '*.pacnew' -o -name '*.pacsave' \) -print
exit 1
fi
# 2. Минимальный запас места (пример: 1 ГБ на / и 1 ГБ на /var)
need_kb=1048576
for mnt in / /var; do
avail=$(df -Pk «$mnt» | awk 'NR==2 {print $4}')
if [ «$avail» -lt «$need_kb» ]; then
echo «Недостаточно места на $mnt: доступно ${avail}KB, требуется минимум ${need_kb}KB.»
exit 1
fi
done
exit 0
Такой «затвор» решает одну конкретную эксплуатационную проблему: обновления не начинают выполняться, пока не устранены типовые причины постфактум-аварий.
Хук для логирования состава обновления
Для расследования инцидентов и для контроля изменений удобно автоматически фиксировать, какие пакеты обновлялись. Это особенно актуально на VPS/VDS, где доступ к консоли может быть ограничен, а история действий должна оставаться на диске.
/etc/pacman.d/hooks/10-log-transaction.hook
[Trigger]
Operation = Upgrade
Type = Package
Target = *
[Action]
Description = Log: список обновленных пакетов
When = PostTransaction
Exec = /usr/local/sbin/pacman-log-upgrade
NeedsTargets
Скрипт может писать в отдельный файл, не полагаясь только на /var/log/pacman.log:
/usr/local/sbin/pacman-log-upgrade
#!/bin/sh
set -eu
log=/var/log/pacman-upgrades.log
ts=$(date -Is)
echo «--- $ts» >> «$log»
for t in «$@»; do
echo «$t» >> «$log»
done
echo >> «$log»
Даже в таком простом виде появляется удобный «человеческий» список: что именно обновлялось в конкретное окно обслуживания.
Хук, который отмечает необходимость перезагрузки
После обновления ядра, systemd или glibc часто требуется перезагрузка или, как минимум, перезапуск затронутых сервисов. Автоматическая перезагрузка на сервере обычно недопустима, но полезно оставить маркер, который будет виден в мониторинге или при следующем входе.
/etc/pacman.d/hooks/20-reboot-flag.hook
[Trigger]
Operation = Upgrade
Type = Package
Target = linux
Target = linux-lts
Target = systemd
Target = glibc
[Action]
Description = Flag: возможно требуется перезагрузка
When = PostTransaction
Exec = /usr/local/sbin/pacman-flag-reboot
/usr/local/sbin/pacman-flag-reboot
#!/bin/sh
set -eu
touch /var/run/reboot-required
echo «$(date -Is) – обновлены компоненты, после которых возможна необходимость перезагрузки» >> /var/run/reboot-required
Дальше маркер обрабатывается как угодно: проверкой в системе мониторинга, баннером MOTD, регулярным job-скриптом.
Хук с «напоминанием» о рестарте сервисов (без агрессивной автоматики)
Соблазн «автоматически перезапускать всё» после обновления велик, но на сервере это часто ведет к неожиданным кратковременным простоям и сложной отладке. Более безопасный компромисс – выводить список сервисов, которым требуется рестарт, а само решение оставлять окну обслуживания.
В пакете pacman-contrib есть checkservices. Его можно запускать вручную после обновления или интегрировать в post-transaction hook, который пишет отчет в лог.
/etc/pacman.d/hooks/30-checkservices-report.hook
[Trigger]
Operation = Upgrade
Type = Package
Target = *
[Action]
Description = Report: сервисы, которым может потребоваться рестарт
When = PostTransaction
Exec = /usr/local/sbin/pacman-checkservices-report
/usr/local/sbin/pacman-checkservices-report
#!/bin/sh
set -eu
out=/var/log/pacman-checkservices.log
echo «--- $(date -Is)» >> «$out»
if command -v checkservices >/dev/null 2>&1; then
checkservices >> «$out» 2>&1 || true
else
echo «checkservices не найден (установить pacman-contrib).» >> «$out»
fi
echo >> «$out»
Такой отчет помогает быстро увидеть, почему после «тихого» обновления внезапно понадобился рестарт nginx, php-fpm или PostgreSQL.
Контроль изменений конфигов: .pacnew/.pacsave как источник большинства «сюрпризов»
Pacman аккуратно относится к локальным изменениям конфигураций: если файл из пакета изменился, а локальный уже отличается, pacman не затирает его молча. Вместо этого создаются:
- .pacnew – новый вариант конфигурации из пакета, который не был автоматически применен
- .pacsave – сохраненный старый файл (обычно при удалении/замене)
Серверные проблемы часто начинаются не в момент обновления, а позже: новая версия сервиса ожидает опцию в конфиге, а она лежит в .pacnew и не была перенесена в рабочий файл. Поэтому работа с .pacnew/.pacsave должна быть частью регламента.
Быстрый инвентарь: найти и оценить масштаб
Минимальная проверка:
find /etc -name '*.pacnew' -o -name '*.pacsave'
Для удобного разбирательства подходит pacdiff:
pacdiff --output
Команда выведет список файлов, требующих внимания. Для интерактивного слияния часто используют vimdiff:
DIFFPROG=vimdiff pacdiff
Практический совет для удаленных VPS/VDS: запуск интерактивного разбора стоит делать в tmux или screen, чтобы не потерять сессию при проблемах сети.
Стратегия, которая экономит время: версионирование /etc
Когда конфиги меняются регулярно (nginx, systemd unit drop-ins, sshd, fail2ban, базы), полезно хранить историю /etc в системе контроля версий. Это решает две задачи:
- позволяет быстро увидеть, что и когда менялось
- упрощает разбор .pacnew: изменения сравниваются не «на глаз», а в рамках диффов и коммитов
Распространенный инструмент – etckeeper (поддерживает git). Общая схема внедрения:
pacman -S etckeeper git
Далее:
etckeeper init
etckeeper commit «baseline»
Секреты и ключи требуют внимания: для приватных ключей и чувствительных файлов обычно настраивается исключение через правила etckeeper или gitignore, чтобы не «засветить» их в истории и резервных копиях репозитория.
Автокоммит изменений /etc после обновления через pacman hook
Чтобы не забывать фиксировать изменения, etckeeper можно привязать к обновлениям pacman. Идея: после транзакции создать коммит с понятным сообщением.
/etc/pacman.d/hooks/40-etckeeper.hook
[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Package
Target = *
[Action]
Description = etckeeper: зафиксировать изменения в /etc после транзакции pacman
When = PostTransaction
Exec = /usr/local/sbin/pacman-etckeeper-commit
/usr/local/sbin/pacman-etckeeper-commit
#!/bin/sh
set -eu
if command -v etckeeper >/dev/null 2>&1; then
etckeeper commit «pacman transaction $(date -Is)» || true
fi
Плюс подхода – минимальный человеческий фактор: история /etc пополняется автоматически, а при разборе инцидента легко посмотреть, какие конфиги изменились вокруг проблемного окна обновлений.
Сценарий «обновление без неожиданностей»: пошаговый регламент
Ниже приведен практический регламент, ориентированный на типовой сервер Arch Linux на VPS/VDS (веб, база, почта, прокси, VPN). Он не претендует на универсальность, но закрывает большинство повторяющихся проблем.
Проверка входных условий
До обновления стоит убедиться, что pre-flight проверки пройдут: нет залежавшихся .pacnew/.pacsave, на диске достаточно места, есть актуальные резервные копии. Если инфраструктура поддерживает снапшоты виртуальной машины (часто встречается у сервисов аренды VDS), логично сделать снапшот перед крупным обновлением; это особенно полезно при обновлении ядра или СУБД.Просмотр списка обновлений без применения
Для первичной оценки полезно посмотреть ожидаемые апдейты:pacman -Qu --print-format '%n %v -> %V'
Если среди обновлений есть «тяжелые» мажорные версии (СУБД, интерпретаторы, web-серверы), обычно планируется отдельное окно обслуживания и, при необходимости, временный pinning.
Временная фиксация критичных пакетов (при необходимости)
Если обновление конкретного компонента должно быть отложено, изменения вносятся в /etc/pacman.conf через IgnorePkg с обязательной пометкой в документации/тикете. Важно фиксировать не только основной пакет, но и тесно связанный набор (например, postgresql + postgresql-libs).Запуск обновления в управляемой сессии
На удаленном сервере команда запускается в tmux/screen:pacman -Syu
Частичные обновления (например, отдельное pacman -Sy без последующего -u) в экосистеме Arch считаются опасной практикой, так как ломают согласованность зависимостей.
Постконтроль: .pacnew/.pacsave, сервисы, перезагрузка
После транзакции проверяются:- отчеты хуков (лог обновлений, список потенциальных рестартов сервисов)
- наличие /var/run/reboot-required (если используется маркер)
- новые .pacnew и их перенос в рабочие конфиги через pacdiff
После разбора конфигов выполняется выборочный рестарт сервисов, затем проверка:
systemctl --failed
journalctl -p 3 -xb --no-pagerУборка и подготовка к откату
Кэш пакетов – один из самых простых механизмов отката на Arch. Полное удаление кэша ради «экономии места» часто оборачивается невозможностью быстро вернуть рабочую версию. Более безопасный вариант – оставить 1-2 предыдущих версии:paccache -rk2
Для тестового прогона регламента часто поднимается отдельный «стендовый» VPS, на котором обновление проводится раньше продакшена. Такой подход особенно полезен, если обновляются PHP/Node.js, базы данных или компоненты с большим количеством модулей. В подобных сценариях иногда используется виртуальный сервер под тест обновлений на короткий срок, чтобы прогнать «боевую» конфигурацию и оценить последствия обновления до окна обслуживания.
Типовые проблемы и как их предотвращают описанные меры
Проблема 1: новый формат конфигурации, но сервис не стартует
Классика серверной эксплуатации Arch – обновление пакета приносит обновленный конфиг в виде .pacnew, а сервис остается на старом конфиге и начинает ругаться на «устаревшие директивы» или отсутствующие опции. Pre-flight хук, блокирующий обновление при наличии .pacnew/.pacsave, решает это организационно: новая транзакция не начнется, пока старые хвосты не разобраны.
Проблема 2: обновление прошло, но часть процессов использует старые библиотеки
После обновления библиотек некоторые долгоживущие процессы могут продолжать работать со старыми маппингами до рестарта. Отчет checkservices помогает выявить кандидатов на рестарт. Маркер «reboot-required» дополнительно дисциплинирует, если обновлялись компоненты, требующие перезагрузки для полного эффекта.
Проблема 3: «замороженный» пакет ломает зависимость при очередном -Syu
IgnorePkg удобен, но имеет предел. Если остальная система начинает требовать новые зависимости, pacman остановит обновление или предложит изменения, недопустимые на сервере. Здесь помогает два подхода: либо сокращать срок pinning и планировать миграцию, либо фиксировать согласованный срез репозиториев через ALA на ограниченный период (например, до завершения изменения в приложении).
Короткая памятка по безопасным обновлениям Arch Linux на сервере
- Pinning – инструмент отсрочки, а не стратегия «жить на старом»
- Pacman hooks лучше использовать как «предохранители» и генераторы отчетов, а не как автоматический перезапуск всего подряд
- .pacnew/.pacsave должны рассматриваться как обязательная часть процесса обновления, а не как «когда-нибудь потом»
- История /etc в git (через etckeeper или аналог) резко упрощает аудит изменений и расследование инцидентов
- Кэш пакетов полезнее «свободного места», если цель – быстрый откат после неудачного апдейта
Итог
Arch Linux на сервере может обновляться предсказуемо, если обновления превращены в управляемый процесс. Фиксация пакетов дает время на подготовку к мажорным изменениям, pacman hooks автоматизируют пред- и постпроверки, а дисциплина работы с .pacnew/.pacsave и контроль /etc устраняют главный источник «тихих» поломок. В результате даже на виртуальном сервере с ограниченными ресурсами обновления остаются регулярными и проверяемыми, а неожиданные простои становятся редким исключением, а не нормой.
Комментариев 0