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

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

В системах на основе Linux / Debian cron-apt - очень удобный инструмент, который может управлять автоматизацией apt с помощью cron.

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

Вот краткое и хорошо сделанное введение в этот инструмент .

Относительно вашего третьего вопроса: я всегда запускаю локальный репозиторий. Даже если это только для одной машины, это экономит время в случае, если мне нужно переустановить (я обычно использую что-то вроде 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-cacher удобен для кэширования пакетов, он будет кешировать в первый раз, когда они нужны, а не заполнять полное зеркало всего хранилища, тем самым экономя диск и пропускную способность. Это также удобно, поскольку он направляет первый запрос пакета напрямую запрашивающей стороне, одновременно кэшируя его, поэтому дополнительная задержка отсутствует.

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

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

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

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

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

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

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