В системах на базе Linux / Debian, cron-apt это очень удобный инструмент, который может управлять автоматизацией apt через cron.
Я использую это для apt-get update каждый день и отправляйте мне электронное письмо, если нужно установить новые обновления.
Что касается вашего третьего вопроса: я всегда запускаю локальный репозиторий. Даже если это только для одной машины, это экономит время, если мне нужно переустановить (я обычно использую что-то вроде aptitude autoclean), а для двух машин это почти всегда окупается.
Для кластеров, которые я администрирую, я обычно не веду явных журналов: я позволяю менеджеру пакетов делать это за меня. Однако для этих машин (в отличие от настольных компьютеров) я не использую автоматические установки, поэтому у меня есть заметки о том, что я намеревался установить на все машины.
Подобно cron-apt, я использую аптикрон.
я использую удачная история для истории. Понятия не имею, почему этот полезный инструмент не включен по умолчанию, это первый пакет, с которым я развертываю кукольный.
я бегу / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq в качестве работы cron каждую ночь. Утром я получаю уведомление о том, какие пакеты нужно обновить, а файлы уже загружены на машину.
Затем я обычно делаю снимок машины (большинство наших серверов виртуальные), делаю apt-get dist-upgrade, чек нагиос и убедитесь, что все по-прежнему работает, и удалите снимок.
Наконец, я веду текущий список всех изменений, внесенных на каждый сервер в вики, чтобы отслеживать любые проблемы, которые возникнут позже.
Что касается ограничения избыточных загрузок, я понимаю, что вы можете настроить кеширование веб-прокси (squid?) между вашими серверами и Интернетом, который кэширует файлы .deb при первом обращении к ним. Возможно, это проще, чем настройка локального репозитория пакетов, и дает дополнительное преимущество в виде ускорения общего просмотра веб-страниц.
apt-cacher удобен для кеширования пакетов, он будет кэшировать в первый раз, когда они понадобятся, вместо того, чтобы создавать полное зеркало всего репозитория, тем самым экономя диск и пропускную способность. Это также удобно, поскольку он передает первый запрос пакета напрямую запрашивающей стороне, одновременно кэшируя его, поэтому нет дополнительной задержки.
Запуск локального репозитория - лучший способ точно управлять тем, что находится на ваших локальных серверах. Он также позволяет легко развертывать настраиваемые резервные копии или настраиваемые локальные пакеты. Известно, что я создавал локальные «мета-пакеты», которые представляют собой просто огромное количество зависимостей, чтобы упростить локальную установку. (например, 'apt-get install local-mailserver'). Это также имеет побочный эффект, позволяя вам «версировать» ваши изменения конфигурации. (Для более сложного управления конфигурацией вам понадобится что-то вроде Puppet)
Для наших окон Windows у нас есть локальный сервер WSUS и стандартное окно для применения ежемесячных исправлений. Для систем Linux (RHEL) у нас есть спутниковый сервер RHN в кампусе, к которому они все подключены. Это обеспечивает удобную панель управления каждой присоединенной системой, которую вы администрируете, а также непримененные обновления для каждой системы. Для тех, кто находится в марионетке, мы запускаем сценарий, который автоматически применяет исправления во время обычного окна и отправляет уведомление по электронной почте с результатами.
Вы можете создать локальный репозиторий и настроить все серверы так, чтобы они указывали на него для получения обновлений. Вы не только получаете скорость локальных загрузок, но и можете контролировать, какие официальные обновления вы хотите установить в своей инфраструктуре, чтобы предотвратить любые проблемы совместимости.
Что касается Windows, я использовал Службы обновления Windows Server с очень удовлетворительными результатами.
При использовании такого менеджера пакетов, как Aptitude, вы храните историю обновлений / установок, и если да, то как вы это делаете?
apt ведет журнал в / var / log / apt /, а dpkg использует /var/log/dpkg.log. В частности, dpkg довольно хорошо разбирается.
В OpenSuSE Linux, SLES и Novell OES (все продукты на основе SuSE) у нас есть сценарий, который запускает zypper и ищет пакеты, которые необходимо обновить. Когда он его находит, он отправляет заявку в JIRA и назначает ее системным администраторам. Когда мы устанавливаем обновления, мы закрываем тикет, в результате чего остается контрольный журнал, который сообщает нам, когда и кем оно было установлено. Это можно согласовать / подтвердить с помощью журналов zypper и sudo, которые централизованы на сервере системного журнала.