Чтобы ням обновить? Или не?


14

пожалуйста, прости этот довольно простой вопрос.

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

Около 3-4 месяцев назад я установил в работе сервер CentOS по разным причинам. Мы используем его в качестве сервера разработки для веб-сайтов (к которым имеют доступ наши клиенты), сервера Subversion, и мы также размещаем там вики для внутреннего общения, поэтому он стал довольно важным инструментом для нас. (Возможно, важнее, чем мы думали, когда я это настрою!)

До меня дошло, что Yum хочет обновить около 250 пакетов до последних версий в репозитории.

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

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

Если совет состоит в обновлении, есть ли какие-либо передовые практики, которые можно было бы передать, чтобы сделать процесс максимально безопасным?

Спасибо заранее за любые советы.

ОБНОВЛЕНИЕ - Спасибо за ваши ответы всем. Если бы у меня было достаточно представителей, чтобы поддержать всех, я бы сделал это. ;) Я решил забрать жесткий диск и обновить. К сожалению, на данный момент получить полный системный или неполный сисадмин не вариант, поэтому мне придется решить эту проблему как можно лучше!

Ответы:


12

Быстрое и грязное (т.е. Battlefield Administrator) решение:

  1. Переведите вашу систему в автономный режим (надеюсь, вы сможете) и создайте резервную копию NortonGhost (или что-то подобное) на втором жестком диске.

  2. Загрузите второй жесткий диск (чтобы убедиться, что резервная копия действительно работает) и выполните обновление yum на ЭТОМ диске.

  3. Если все работает ... поздравляю!

  4. Если это что-то напортачило ... иди вперед, вставь свой ОРИГИНАЛЬНЫЙ диск и придумай "План Б".

ОБНОВИТЬ:

Просто подумал, что упомяну, что реальная проблема здесь - «Обновляю ли я свою устаревшую систему и рискую испортить ее?» или "я оставляю свою отлично работающую систему незащищенной и рискую ее взломать / скомпрометировать?"

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

Тогда вы получите лучшее из обоих миров. ;-)


Мое удовольствие ... удачи в резервном копировании / обновлении. Как примечание, я лично делал ням-обновления в CentOS, когда было 200-300 обновлений, и это было просто замечательно. НО ... Я также делал обновления, где он полностью разбился на части, и мне приходилось делать глупые ритуалы вуду / курицы (и много хрена из командной строки), чтобы все снова заработало. Желаю вам скорейшего и успешного обновления. ;-)
KPWINC

10

Да, обновить.

RHEL (и, следовательно, CentOS) стараются не обновлять версии до чего-либо несовместимого, вместо этого они сообщают об ошибках и исправлениях безопасности, поэтому фактические изменения в пакетах минимальны и, скорее всего, не вызовут проблем совместимости.

Если какие-либо файлы конфигурации изменились, пакеты сообщат вам о файле .rpmorig или .rpmnew, который создается. Это зависит от конфигурации самого RPM. Вы можете посмотреть предупреждения о любом из создаваемых объектов и либо вернуть свою старую конфигурацию (" cp foo foo.bak; cp foo.rpmorig foo"), либо просмотреть файлы .rpmnew и включить любые изменения в свою конфигурацию.

Проблема менее заметна, если вы регулярно обновляетесь.

У нас есть много систем, которые обновляются ежеквартально (каждые 3 месяца); и очень редко вижу какие-либо проблемы с обновлениями пакетов. (за исключением систем, выполняющих странные функции ядра для доступа к LUN из SAN)


Мне больше нравится KPWINC ответ. Резервное копирование в первую очередь. Пример: httpd 2.2 был обновлён до 2.4, и внезапно файлы конфигурации перестали работать. Паника и команда разработчиков простаивают в течение нескольких часов, пока проблема не будет диагностирована и устранена.
Хосе Мануэль Гомес Альварес


@Jose Manuel Gomez Alvarez - резервное копирование в первую очередь всегда приятно, но если ваша система перешла с http 2.2 на 2.4, это не соответствовало этому вопросу - CentOS такого не делает, никогда.
Freiheit

6

Хотя да, для обновления потребуется время, и в том же поместье потребуется время для восстановления, если что-то пойдет не так, сколько будет боли / страданий, если данные в этой системе будут удалены с помощью эксплойта / хака?

По большей части обновления из базовых репозиториев CentOS безопасны для установки. Единственный раз, когда у меня возникали проблемы с обновлением CentOS, это когда я запускаю / или мне нужно использовать внешний репозиторий (DAG, RPMForge, Ect ect ..)

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


3

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


3

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

Когда вы применяете обновления, вам нужно убедиться в нескольких вещах:

  1. Время обновления публикуется всем, кто использует систему
  2. У вас есть план как обновить и протестировать каждое приложение
  3. У вас есть план, как отменить обновления, если (когда?) Обновление ломает приложение
  4. И текущие резервные копии существуют на случай, если что-то пойдет не так

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


3

Вот почему сегодня я почти никогда не запускаю производственные системы на реальном оборудовании. Я запускаю их на виртуальных машинах. Затем в течение небольшого простоя (5 минут) я запускаю снимок из самого ESX или, если я использую пользовательскую настройку Xen / Solaris / OpenVZ, я делаю снимок LVM образа сервера. Затем я загружаю оригинал обратно, и теперь у меня есть копия, с которой я могу делать все, что захочу.

Тем не менее, начните с обновления ядра и apache, а затем работайте в обратном направлении. Вам не нужно брать полный список пакетов, о котором сообщает yum, но самые высокие векторы атаки должны быть теми, которые вы исправите быстрее всего.

Каждый раз, когда я взламывал систему Linux, это потому, что я оставил apache, openssh или само ядро ​​без исправлений.


2

Я бы просто обновил пакеты, связанные с безопасностью.


2

У меня точно такая штука появилась год назад или около того ... Я сделал обновление yum на коробке CentOS, работающей на оборудовании Dell, и оно установило ядро, которое не загружалось. На коробке еще ничего не было загружено (в противном случае я был бы более осторожен). Потратил много времени на возня с ним, и кажется, что есть некоторая несовместимость между более новыми ядрами CentOS / Linux и той коробкой Dell. Будьте очень осторожны с вашими обновлениями. Я по-прежнему рекомендую обновление, так как это правильно, но будьте готовы к восстановлению из поврежденной системы!


Отлично, случается, это коробка Dell!
Джон Макколлум
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.