Я управляю примерно 30 серверами Ubuntu с помощью марионетки. Я видел много ссылок на cron-apt и apticron как на подходы к обновлению своих пакетов, но мне не удалось найти способ централизованно управлять процессом. С cront-apt / apticron мне все равно нужно будет входить в систему на каждом хосте и запускать aptitude update для выполнения обновления. Не говоря уже о проверке уведомлений со всех 30 машин при каждом обновлении основного пакета.
Там должен быть лучший способ. Какие-либо предложения?
Сотрудник обнаружил и кратко изучил apt-dater, который является «диспетчером удаленного обновления пакетов на основе терминала».
Вы используете интерфейс на основе curses для управления обновлениями на всех ваших хостах или группах хостов и т. Д. Поддерживает ведение журнала всего сеанса APT, включая любые ошибки, которые могут возникнуть, и т. Д.
На управляемых машинах полагается на ssh и sudo.
видеть http://www.ibh.de/apt-dater/
Сам не использовал, поэтому не могу одобрить его, но звучит близко к тому, что вы ищете.
Поскольку вы уже используете Puppet, самый простой способ сделать это (и лучший для целей контроля / отслеживания изменений) - указать желаемую версию пакетов, которые вы хотите установить, в манифесте марионетки. Вы следите за списком объявлений о безопасности, и когда что-то, что вы используете, приходит через него, вы просто обновляете Puppet, чтобы сказать «установите эту новую версию этого пакета». Предполагая, что вы используете контроль версий в своих манифестах, тогда вы узнаете, когда была изменена «политика», и отчеты Puppet покажут вам, когда именно было внесено изменение (так что вы можете легко сопоставить это с любыми последующими событиями журнала).
Пейзаж могут быть вам интересны. Это «официальный» инструмент управления для управления крупными развертываниями Ubuntu, и Canonical, вероятно, очень хочет получить ваши деньги за его использование.
РЕДАКТИРОВАТЬ:
Во-первых, отказ от ответственности; Я не использовал зеркалирование для Debian или Ubuntu, поэтому я не знаком с программным обеспечением.
Во-вторых, примите мои извинения, что apt-mirror будет "слишком тяжелым" решением. Первоначальная идея заключалась в том, что у вас будет отдельная тестовая машина (или тестовая среда, возможно, виртуальная машина?) Для развертывания обновления. Как только вы будете удовлетворены производительностью обновления, вы должны вытащить / поместить пакет в свое «развернутое» зеркало (будет локальное зеркало из официальных источников и вторичное зеркало только для обновлений, которые вы хотите развернуть). Затем удаленные машины запускали обновление в заранее установленное время и извлекали его из вашего «развернутого» зеркала на каждую машину, задание cron, состоящее из:
apt-get update && apt-get upgrade --quiet --assume-yes
К сожалению, когда я начал читать подробности, мне показалось, что apt-mirror будет тянуть все виды вещей, а не только те пакеты, которые вам нужны. Итак, я собираюсь отказаться от этой идеи, хотя в этой концепции есть свои достоинства.
Взгляните на clusterssh (apt-get install clusterssh):
$ cssh server1 server2 server3 ...
Не задумываясь об этом раньше, моя первая идея была бы чем-то похожим на то, что предлагает Эйвери, особенно если у вас уже есть тестовая среда.
По сути, вы настраиваете свои производственные машины на автоматическое обновление с вашего собственного локального репо, и вы обновляете это репо только после того, как обновили тестовую среду до новейшей версии того, что вы запускаете.
Apticron плохо масштабируется, он предназначен для работы в довольно небольших средах, но у него есть несколько хороших моментов:
Иногда назад я писал низкоуровневую / грязную автоматизацию Ткань скрипт (fabfile) на соответствие аналогичным требованиям, вы можете проверить его по адресу: