Как часто я должен обновлять наш сервер Linux?

Я отвечаю за управление как нашим рабочим сервером (почта, Интернет, база данных находятся на одном сервере), так и нашим тестовым сервером. Оба построены на Debian. Однако, поскольку я очень новичок в системном администрировании, я устанавливал обновления только потому, что сталкивался с вещами, которые необходимо обновить, чтобы иметь новые функции и получать исправления ошибок. Это довольно специальный процесс прямо сейчас, и я бы хотел, чтобы он стал меньше.

Поэтому мне интересно, как люди, которые знают, что они делают, справляются с этим? Как часто вы выполняете обновления на своих серверах? Отличается ли процесс обновления между тестированием и производством? Всегда ли вы сначала обновляете какие-либо тестовые серверы? И вы делаете полное обновление всего программного обеспечения, или вы просто устанавливаете выбранные обновления?

Я запускаю apt-get update -qq; apt-get upgrade -duyq ежедневно. Это будет проверять наличие обновлений, но не будет делать их автоматически.

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

Помимо проблем с безопасностью обслуживания исправленной системы, я обнаружил, что если я оставлю это слишком долго между исправлениями, я получу целую кучу пакетов, которые хотят обновить, и это пугает меня намного больше, чем просто обновление два раза в неделю или около того. Поэтому я склонен запускать свои обновления еженедельно или, если они имеют высокий приоритет, ежедневно. Это дает дополнительное преимущество, заключающееся в знании того, какой пакет сломал вашу систему (т. Е. Если вы обновляете только пару одновременно)

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

При этом, я думаю, что обновление сломало что-то только один или два раза за последние 4 года, и это было на сильно настроенной системе - так что вам не нужно быть СЛИШКОМ параноиком :)

Вдобавок к предыдущим ответам - пара более конкретно о Debian: вы должны подписаться на debian-security-announce и debian-announce и / или проверить страницу безопасности Debian .

Предполагая, что вы используете стабильную версию Debian, большинство исправлений будут связаны с безопасностью или ошибками, что должно означать, что между версиями любого данного пакета не будет слишком много серьезных изменений. В соответствии с политикой исправлений debian исправления также должны были пройти тестирование в течение некоторого времени, прежде чем сопровождающий переместит их в стабильную ветку. Очевидно, что это не остановит поломки при исправлении, но должно предотвратить их в большинстве случаев.

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

Debian, как правило, является очень стабильной ОС, и вам не следует беспокоиться о ее поломках, однако всегда читайте, что будет обновляться, прежде чем обновляться, и следите за всем, что кажется странным. Я также использую VCS в моем / etc / dir, чтобы гарантировать, что любые изменения в конфигурационном файле можно увидеть с помощью команды 'git diff'.

Я делаю пробный прогон (сначала), чтобы посмотреть, что будет обновлено. Иногда библиотеки (в нашем примере назовем это libfoo) меняют свои API, что нарушает программы, которые мы написали / установили сами. Если какая-то критическая библиотека обновляется, я беру исходный код и пытаюсь восстановить его перед использованием.

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

Если вы системный администратор, вы должны получать RSS-каналы с таких сайтов, как Secunia , которые должны сообщить вам заранее, если ваш дистрибутив будет устанавливать какие-то исправления.

Никогда, просто вслепую обновляй / обновляй. К сожалению, задача узнать, что сломано, ложится на вас, а не на менеджера пакетов дистрибутива, особенно если ваши системы поддерживают программистов.

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

Если у вас есть только два сервера, процесс должен быть намного проще. Хотя я не думаю, что делать «apt-get update / upgrade» - ваш лучший выбор.

Я следил за исправлениями для программного обеспечения, которое вы используете, и принимал решения на основе исправлений в тех выпусках, когда обновлять.

Поскольку у вас есть тестовый сервер, очевидно, всегда проверяйте обновления перед их применением.

Ручные обновления лучше всего упомянуты здесь в том смысле, что вы можете видеть, что происходит. Однако для очень большого количества серверов это может стать непрактичным. Пробный запуск является стандартной практикой, на самом деле, большинство менеджеров пакетов спросят вас, прежде чем продолжить.

Обновление регулярно имеет тенденцию быть лучшим, хотя это может быть немного уравновешивающим действием. Частые обновления означают меньше за один раз и меньше ошибаются сразу. Если что-то пойдет не так, кандидатов будет меньше. Пакеты также немного лучше обновляются небольшими шагами, как правило, когда программист обновляет свои версии, переходя с последней версии на следующую, будет ли различаться вопрос о том, будут ли они уделять внимание после последней версии, хотя это имеет значение в основном для программного обеспечения, которое быстро развивается.

Не все обновления не являются разрушительными. Вы должны следить за этим. Некоторые перезапустят службы, что приведет к простою.

В идеальном случае у вас может быть следующее:

• Средство простейшего переключения серверов (A / B или Tick Tock). Это означает, что вы обновляете один, пока он находится на стенде, а затем просто меняете трафик с текущего на новый. Это может быть более сложным для таких служб, как базы данных.
• Возможность тестирования обновлений. У вас должны быть тестовые серверы, которые являются практически клонами производства (но без подключения к каким-либо производственным сервисам). Это позволит вам сначала протестировать обновления.
• Хорошая стратегия резервного копирования, инкрементная идеально. Ты никогда не узнаешь. Всегда лучше быть в безопасности, чем потом сожалеть.
• Имейте в виду, в какое время больше всего активности и какое время простоя допустимо.
• Знать, как откатить обновление или конкретный пакет.
• Имейте свои собственные зеркала пакета, чтобы обновления были последовательными и предсказуемыми для всех серверов. Это первый шаг к достойной автоматической системе, которой вы можете доверять. Это означает, что вы можете обновить зеркало, запустить обновление на одном или нескольких тестовых компьютерах, а затем, если это хорошо, автоматически отключить его. Я отлично провел время, удачно управляя примерно 800 машинами EPOS.
• Хороший уровень последовательности, чтобы вы могли знать, что если что-то будет работать здесь, оно будет работать там.

Некоторые из них могут быть в разной степени излишними для небольших установок, но об этом следует помнить.

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

Хотя это относительно редко, они иногда допускают ошибки и нарушают совместимость между версиями младших пакетов.

Мне нравится, что cron-apt автоматизирует этот процесс, но, как указал @dinomite по другому вопросу, касающемуся обновлений, настройка его специально для автоматизации обновлений, связанных с безопасностью, является очень разумной идеей - вы можете вручную обновить то, что вам нужно. Я использовал cron-apt для всех обновлений, но фактически изменил это, основываясь на его ответе. Если вам это нравится, вы, вероятно, должны проголосовать за его ответ, а не за этот.

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

В том же ключе, что и cron-apt, вы должны взглянуть на пакет unattended-upgrades http://packages.debian.org/lenny/unattended-upgrades .

Его очень легко настроить, и вы сможете автоматически загружать и применять обновления безопасности, но оставляйте другие обновления для обновления вручную (или по вашему усмотрению обновляйте все!).

Официальное руководство по серверу Ubuntu содержит достаточно подробный раздел, посвященный использованию пакета автоматических обновлений https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html.

Примечание: в зависимости от вашего уровня предосторожности / паранойи, вы можете сначала выполнить последовательное обновление для группы тестовых серверов, а затем, если проблем нет, разрешить обновление ваших производственных ящиков, хотя лично я не сталкивался с какими-либо проблемами с обновлениями безопасности. разрушение до сих пор (стук по дереву) ...

Существует также опция конфигурации, чтобы отправлять вам по почте результаты каждого обновления безопасности, как только оно будет применено. Кроме того, если во время обновления были представлены какие-либо диалоговые или интерактивные подсказки, которые потребуют ручной настройки системным администратором, он также упомянет об этом.

Я лично отключаю автоматические обновления и не выполняю регулярно какие-либо обновления пакетов на серверах в моих средах, если: (a) в моей системе нет важных рекомендаций CERT для одного из пакетов; (б) мне нужно обновить отдельные пакеты по конкретным причинам; (c) ОС или пакеты подходят к концу цикла, они больше не будут поддерживаться, и мы должны продолжать иметь поддержку. Я рассуждаю так, что обновление не зная, что меняется и почему оставляет слишком много места для чего-то ломающегося. Я занимаюсь такими вещами вот уже 14 лет, и это хорошо работает.

Помимо упомянутого материала, вы должны использовать какой-то инструмент мониторинга (Nagios или что-то еще, что плавает на вашей лодке), чтобы предупредить вас об обновлениях.

Что касается того, как часто идет: Как только доступно обновление!