Ответы:
В системах на основе Linux / Debian cron-apt - очень удобный инструмент, который может управлять автоматизацией apt с помощью cron.
Я использую его apt-get updateкаждый день и отправляю мне электронное письмо, если необходимо установить новые обновления.
Относительно вашего третьего вопроса: я всегда запускаю локальный репозиторий. Даже если это только для одной машины, это экономит время в случае, если мне нужно переустановить (я обычно использую что-то вроде aptitude autoclean), а для двух машин это почти всегда окупается.
Для кластеров, которые я администрирую, я обычно не веду явные логи: я позволяю менеджеру пакетов делать это за меня. Однако для этих машин (в отличие от настольных компьютеров) я не использую автоматические установки, поэтому у меня есть свои заметки о том, что я собирался установить на все машины.
Я использую 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-cacher удобен для кэширования пакетов, он будет кешировать в первый раз, когда они нужны, а не заполнять полное зеркало всего хранилища, тем самым экономя диск и пропускную способность. Это также удобно, поскольку он направляет первый запрос пакета напрямую запрашивающей стороне, одновременно кэшируя его, поэтому дополнительная задержка отсутствует.
Запуск локального репозитория - лучший способ точно управлять тем, что находится на ваших локальных серверах. Он также позволяет легко развертывать пользовательские бэкпорты или локальные пакеты. Мне известно, что я делаю локальные «метапакеты», которые являются просто огромным количеством зависимостей, чтобы облегчить локальную установку. (например, 'apt-get install local-mailserver'). Это побочный эффект также позволяет вам «версии» изменения вашей конфигурации. (Для более сложного управления конфигурацией вам понадобится что-то вроде Puppet)
Для наших Windows-боксов у нас есть локальный сервер WSUS и стандартное окно для применения ежемесячных исправлений. Для систем Linux (RHEL) у нас есть кампусный сервер RHN в кампусе, к которому они все присоединены. Это обеспечивает хорошую панель инструментов для каждой присоединяемой системы, которой вы управляете, а также неприменимые обновления для каждой системы. Для тех, кто в Puppet, мы выдвигаем скрипт, который автоматически применяет исправления во время обычного окна и отправляет уведомление по электронной почте с результатами.
Вы можете иметь локальный репозиторий и настроить все серверы так, чтобы он указывал на обновления. Вы не только получаете скорость локальных загрузок, но также можете контролировать, какие официальные обновления вы хотите установить в своей инфраструктуре, чтобы избежать проблем с совместимостью.
Что касается Windows, я использовал службы Windows Server Update Services с очень хорошими результатами.
В OpenSuSE Linux, SLES и Novell OES (все продукты на основе SuSE) у нас есть скрипт, который запускает zypper и ищет пакеты, которые необходимо обновить. Когда он находит его, он отправляет билет в JIRA и назначает его системным администраторам. Когда мы устанавливаем обновления, мы закрываем тикет, который оставляет контрольный журнал, который сообщает нам, когда он был установлен и кем. Это можно согласовать / подтвердить с помощью журналов zypper и sudo, которые централизованы на сервере системного журнала.
OPTIONS="-o Dir::Etc::SourceList=/etc/apt/security.sources.list"и затем в /etc/apt/security.sources.list включаем только репозитории безопасности Debian. Таким образом, я автоматически получаю все обновления безопасности своевременно (каждую ночь) и могу выполнять другие, более рискованные обновления, которые могут сломать вещи вручную.