Лучшие практики для поддержания пакетов UNIX в актуальном состоянии?

Что касается вашего третьего вопроса: я всегда запускаю локальный репозиторий. Даже если это только для одной машины, это экономит время в случае, если мне нужно переустановить (я обычно использую что-то вроде aptitude autoclean), а для двух машин это почти всегда окупается.

Для кластеров, которые я администрирую, я обычно не веду явные логи: я позволяю менеджеру пакетов делать это за меня. Однако для этих машин (в отличие от настольных компьютеров) я не использую автоматические установки, поэтому у меня есть свои заметки о том, что я собирался установить на все машины.

Подобно cron-apt, я использую apticron.

Я использую apt-history для истории. Я понятия не имею, почему этот полезный инструмент не включен по умолчанию, это первый пакет, который я развернул с помощью puppet.

Я запускаю /usr/bin/apt-get update -qq;/usr/bin/apt-get dist-upgrade -duyq как задание cron каждую ночь. Утром я получаю уведомление о том, какие пакеты нужно обновить, и файлы уже были загружены на машину.

Затем я обычно делаю снимок машины (большинство наших серверов являются виртуальными), выполняю apt-get dist-upgrade, проверяю nagios и проверяю, все ли работает, и удаляю снимок.

Наконец, я веду рабочий список всех изменений, внесенных на каждом сервере в вики, чтобы отслеживать любые проблемы, возникающие позже.

Что касается ограничения избыточных загрузок, я понимаю, что вы можете установить кеширующий веб-прокси (squid?) Между вашими серверами и Интернетом, который будет кэшировать файлы.deb при первом обращении к ним. Возможно, это проще, чем настройка локального репозитория пакетов, и имеет дополнительное преимущество, заключающееся в ускорении общего просмотра веб-страниц.

Запуск локального репозитория - лучший способ точно управлять тем, что находится на ваших локальных серверах. Он также позволяет легко развертывать пользовательские бэкпорты или локальные пакеты. Мне известно, что я делаю локальные "метапакеты", которые являются просто огромным количеством зависимостей, чтобы облегчить локальную установку. (например, 'apt-get install local-mailserver'). Это побочный эффект также позволяет вам "версии" изменения вашей конфигурации. (Для более сложного управления конфигурацией вам понадобится что-то вроде Puppet)

Для наших Windows-боксов у нас есть локальный сервер WSUS и стандартное окно для применения ежемесячных исправлений. Для систем Linux (RHEL) в кампусе есть спутниковый сервер RHN, к которому они все присоединены. Это обеспечивает хорошую панель инструментов для каждой присоединяемой системы, которой вы управляете, а также неприменимые обновления для каждой системы. Для тех, кто в Puppet, мы выдвигаем скрипт, который автоматически применяет исправления во время обычного окна и отправляет уведомление по электронной почте с результатами.

apt-cacher удобен для кэширования пакетов, он будет кешировать в первый раз, когда они нужны, а не заполнять полное зеркало всего хранилища, тем самым экономя диск и пропускную способность. Это также удобно, поскольку он направляет первый запрос пакета напрямую запрашивающей стороне, одновременно кэшируя его, поэтому дополнительная задержка отсутствует.

В OpenSuSE Linux, SLES и Novell OES (все продукты на основе SuSE) у нас есть скрипт, который запускает zypper и ищет пакеты, которые необходимо обновить. Когда он находит его, он отправляет билет в JIRA и назначает его системным администраторам. Когда мы устанавливаем обновления, мы закрываем тикет, который оставляет контрольный журнал, который сообщает нам, когда он был установлен и кем. Это можно согласовать / подтвердить с помощью журналов zypper и sudo, которые централизованы на сервере системного журнала.

При использовании менеджера пакетов, такого как Aptitude, сохраняете ли вы историю обновления / установки, и если да, то как вы это делаете?

apt ведет журнал в /var/log/apt/, а dpkg использует /var/log/dpkg.log. В частности, dpkg довольно хорошо разбирается.

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

Что касается Windows, я использовал службы Windows Server Update Services с очень хорошими результатами.