Отключите интерактивный режим dnf. Это первое. Без него автоматизация не работает как надо. Правка конфигурации минимальна: в /etc/dnf/dnf.conf дописать assumeyes=True. Всё. Диалогов не будет. Система не зависнет в ожидании ответа.
Следующий шаг – dnf-automatic. В Red OS этот модуль уже в составе базовой поставки, но по умолчанию не активен. Запускаем:
dnf install dnf-automatic
Далее – конфигурация. Файл /etc/dnf/automatic.conf. В секции [commands] прописать apply_updates = yes, чтобы обновления не просто скачивались, а ставились. В [emitters] включить emit_via = motd, если надо оповещение через терминал. Можно и через email, но это уже опционально, если настроен MTA.
Важно: не включайте
random_sleepбез нужды. Он задерживает запуск на случайный период. В продакшене это может аукнуться. Особенно в кластере.
Активируем службу. Это must do, без systemd всё вышеописанное мёртво. Используйте:
systemctl enable --now dnf-automatic.timer
Проверка статуса:
systemctl list-timers | grep dnf-automatic
Видите таймер? Значит работает. Не видите – разбирайтесь. Логика проста: нет таймера – нет обновлений.
Хотите конкретное расписание? Правьте /usr/lib/systemd/system/dnf-automatic.timer или создайте override-файл в /etc/systemd/system/. Пример замены: запуск каждый день в 4 утра – OnCalendar=*-*-* 04:00:00.
Помните: любые ручные правки в unit-файлах требуют
systemctl daemon-reexecили хотя быdaemon-reload. Без этого ничего не применится.
Почему всё так? Потому что Red OS следует строгой логике безопасности. Здесь нет места случайностям. Всё предсказуемо, но требует точности.
Не используйте crontab. Это ошибка новичков. systemd.timer – современное, встроенное, логируемое решение. Только оно гарантирует совместимость с текущими механизмами инициализации и ведения журнала.
Нет желания ставить обновления, но хотите оповещения? Меняйте apply_updates = yes на no. Всё остальное оставить. Это удобно для тестирования и анализа.
Вам нужно автоматическое обновление только по security-фиксам? Используйте dnf updateinfo и отбор по типу:
dnf updateinfo list security
Скриптуйте. Комбинируйте с grep и awk. Это уже уровень старшего администратора. Здесь включается своя логика фильтрации. И своя ответственность.
Нельзя просто включить обновление и забыть. Нужно знать, что именно ставится. Нужно логировать, следить, быть в курсе. Red OS вам в этом не поможет. Это зона вашей ответственности.
Содержание статьи
Настройка автоматического обновления пакетов через apt на Ubuntu
Установите unattended-upgrades. Без этого ни одна автоматизация не сработает. Пакет нужен. Пишем:
apt install unattended-upgrades
Далее проверьте, активирован ли он по умолчанию. Часто он уже работает, но слепо верить системе – глупо. Выполните:
dpkg-reconfigure --priority=low unattended-upgrades
Выберите Yes, если хотите, чтобы обновления ставились без участия пользователя. Это не рекомендация. Это обязательное условие.
Файл конфигурации – /etc/apt/apt.conf.d/50unattended-upgrades. Здесь вся логика. Выбирайте источники обновлений. Пример – только безопасность:
// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
"Ubuntu stable";
"Ubuntu ${distro_codename}-security";
};
Для тонкой настройки используйте параметры ниже в том же файле. Пример: автоматическая очистка старых версий:
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Время запуска задаётся в /etc/apt/apt.conf.d/10periodic. Ключевые параметры:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Единица означает ежедневный запуск. Ноль – отключение. Можно поставить «7» – раз в неделю. Решать вам. Только не путайте: Update-Package-Lists – обновление списка, Unattended-Upgrade – установка.
Важно помнить: если нет второго параметра, обновления не применяются даже при включённом первом. Список обновится – установка нет. Ловушка новичков.
Хотите логировать? Логи в /var/log/unattended-upgrades/. Всё там. Успешные, проваленные, пропущенные. Смотрите логи. Не читайте мануалы – читайте логи.
Нужна симуляция без установки? Проверьте, что будет обновляться, не применяя изменения:
unattended-upgrade --dry-run --debug
Это полезно. Особенно если работаете с кастомными репозиториями. Иногда они мешают. Иногда ломают систему.
Внимание! Если используете прокси или зеркала – обязательно проверьте, совпадают ли идентификаторы источников с ожидаемыми. Механизм сравнивает origin, а не URL. Ошибётесь – ничего не обновится.
Автоматизация без понимания логики apt – бомба замедленного действия. Ubuntu прощает ошибки. Но только до первого падения после обновления ядра.
Проверьте, установлены ли initramfs-tools и update-notifier-common. Иногда без них слетает post-install скрипт, и вы даже не узнаете, что ядро не применилась.
Хотите полный контроль? Перенаправьте stderr и stdout в собственный журнал. Cron + custom wrapper. Пример:
0 3 * * * root /usr/bin/unattended-upgrade >> /var/log/custom-upgrade.log 2>&1
Да, это костыль. Но когда штатный механизм вас не устраивает – приходится.
Ничего не делайте руками, если не знаете, что именно делает автомат. Сначала – логика. Потом – команды. И только потом – включение таймера или системной службы.
Конфигурация автоматических обновлений с использованием yum-cron в CentOS
Установите компонент:
yum install yum-cron -y
Проверяйте, что ставится. Без yum-cron система молчит, ничего не делает, даже не сообщает. Это просто таймер. Не больше. Но без него ничего не произойдёт.
Файл управления – /etc/yum/yum-cron.conf. Здесь ключевые параметры. Не трогайте всё подряд. Ищите строки:
apply_updates = yes
Без этой строки обновления только проверяются. Никакой установки. Только отчёт в журнал. Хотите установки – включайте yes.
update_cmd = default
Если нужен только security, меняйте на:
update_cmd = security
Будет применяться только то, что имеет security-метку в metadata. Но! Только если репозитории это поддерживают. Проверяйте. CentOS 7 часто молчит, даже когда есть фиксы.
Внимание! Убедитесь, что директория
/etc/yum/yum-cron.confне перезаписывается при обновлениях. Особенно на CentOS Stream. Лучше делайте копию и смотрите diff после патчей.
Расписание? systemd. Все вопросы туда. Активируйте:
systemctl enable --now yum-cron.service
Работает? Проверьте статус:
systemctl status yum-cron
Ошибки? Ищите в /var/log/cron и /var/log/yum.log. Не в syslog. CentOS пишет всё в свои журналы.
Почта? Если вы не настроили MTA, ничего не получите. Уведомления идут в локальную почту root. Хотите на внешний адрес – прописывайте MAILTO в /etc/crontab. Или настраивайте postfix/sendmail. Но это отдельная головная боль.
Ограничения? Да. yum-cron не понимает зависимости на уровне ядра. Он может обновить kernel, но не перезагрузит. Вы останетесь на старом. Хотите полную автоматизацию – добавляйте перезагрузку скриптом:
if [ -f /var/run/reboot-required ]; then
/sbin/shutdown -r +5
fi
Или cron + systemctl reboot. Сами решайте. Но не рассчитывайте, что yum-cron поднимет сервер без вашего участия.
Важно помнить: CentOS 8 и Stream используют dnf. yum-cron работает, но фактически это обёртка. В новых системах переходите на
dnf-automatic.
Если хотите тонкую настройку, используйте /etc/yum/yum-cron-hourly.conf. Этот файл отвечает за частый запуск. Мало кому нужно, но если вы администрируете прокси с агрессивным кэшированием – пригодится.
Не трогайте параметры random_sleep и debuglevel, если не понимаете зачем. Первый мешает синхронности, второй забивает лог бесполезными строками.
yum-cron – старый, прямолинейный. Но именно этим он и хорош. Ошибся в одном символе – и всё становится видно. Никакой магии. Только текстовые конфиги, системный таймер и понимание, что вы делаете.
Создание и использование cron-скриптов для обновления пакетов в Arch Linux
Не используйте systemd для этого. В Arch всё можно сделать проще. cron – старый добрый метод, работает без сюрпризов. Установите cronie, если ещё не стоит:
pacman -S cronie
Активируйте службу. Без неё ничего не произойдёт:
systemctl enable --now cronie.service
Теперь создайте скрипт. Пусть он живёт в /usr/local/bin/update-arch.sh. Пример:
#!/bin/bash
exec >> /var/log/update-arch.log 2>&1
echo "=== $(date) ==="
pacman -Syu --noconfirm
Выставьте права:
chmod +x /usr/local/bin/update-arch.sh
Проверьте вручную. Если скрипт ломается в интерактивном режиме, cron его тоже не осилит. Команда --noconfirm обязательна. Без неё pacman будет висеть и ждать ответа от пустоты.
Теперь crontab. Правьте через crontab -e. Добавьте строку:
0 4 * * * /usr/local/bin/update-arch.sh
Обновление каждый день в 4 утра. Просто. Без лишней магии.
Важно: лог-файл будет бесконечно расти. Очистку тоже надо автоматизировать. Раз в месяц – минимально. Cron может это сделать:
0 0 1 * * truncate -s 0 /var/log/update-arch.log
Теперь о безопасности. Arch не различает критические и обычные изменения. Всё обновляется сразу. Хотите только security? Не получится. Нет встроенного фильтра. Решение – внешние утилиты, типа arch-audit. Но это уже другая история.
Проблема с зависимостями? Да, бывает. pacman -Syu не всегда стабилен при частичном обновлении. Cron не подскажет. Не заметите – получите битую систему. Хотите контроля? Добавьте e-mail оповещение:
MAILTO=your@email.com
0 4 * * * /usr/local/bin/update-arch.sh
Но сначала настройте почтовый агент. Без него это просто мёртвая строка.
Помните: если обновление тянет новое ядро – перезагрузка обязательна. Cron этого не знает. Пропишите отдельный скрипт, который перезагрузит систему после ключевых апдейтов. Или будьте готовы к сюрпризам на уровне initramfs.
Хочется изоляции? Запускайте скрипт через systemd-nspawn или chroot. Для тестирования. Не лейте всё в продакшн сразу. Arch – не про стабильность. Он про ручное управление.
Итог: cron + pacman – рабочая связка. Простая. Логируемая. Контролируемая. Но требует внимания. Хотите автомат – получайте ответственность.