Как лучше поддерживать сервер Linux Ubuntu в актуальном состоянии (сборка пакетов, dist-upgrade, alt-репозитории ...)


8

Мы работаем с производственным сервером на основе Ubuntu 9.10 Karmic Koala , ядро ​​практически обновлено (2.6.38.2-grsec-xxxx-grs-ipv6-64), но хранилище пакетов karmic теперь просто устарело, например. Nginx - 0.7.62 - действительно глючит - в то время как последняя стабильная версия 1.0.x !!

Кроме того, Кармик только что достиг конца жизни.

Этот вопрос: передовые методы поддержания актуальности пакетов UNIX? выглядит аналогично, но на самом деле содержит только некоторые предложения о менеджерах пакетов; совсем не то что мне нужно!

Итак, варианты, которые я вижу:

  1. получить новую машину, установить ее с нуля, перенести
  2. обновление дистрибутива
  3. использовать другой репозиторий ( панель запуска / ppa / backport / pinning )
  4. Построй свой собственный

Недостатки 1. вполне очевидны.

Однако я не осмелюсь пойти по пути dist-upgrade, поскольку простои и возможные катастрофические последствия просто невозможно предсказать для производственного сервера, и в настоящее время я в основном перестраиваю собственные требуемые пакеты. Но я уверен, что я мог бы пропустить некоторые.

Мне не совсем понятно, каковы риски (стабильность / совместимость) использования бэкпортов ubuntu, кроме того, официально для 9.10 больше ничего не предусмотрено. Launchpad - это индивидуальная сборка, похожий вопрос - насколько это лучше, чем компилировать вашу собственную.

Сборка пакетов выглядит нормально, но: 1. иногда у меня возникают проблемы с воспроизведением правильных параметров ./configure для повторного использования моих существующих файлов конфигурации 1. Я уверен, что есть тонны пакетов и зависимостей, которые в настоящее время довольно устарели и являются возможным источником ошибок

Наконец ... как насчет «старых» пакетов в недавнем дистрибутиве? Я полагаю, нет другого пути, чем восстановить их сам? Является ли комбинация 2. и 4. наконец лучшим путем?

Есть ли какой-то объективный консенсус в отношении того, что является лучшим способом сделать это, или причины, по которым некоторые из моих вариантов хороши / не хороши?

Если на самом деле нет, я приму, что вопрос закрывается перед созданием бесконечной темы!


1
По причинам, которые вы испытываете в настоящее время, для серверов должны использоваться только версии LTS. В ответ на ваш вопрос, пока вы не можете сделать # 1 или # 2, вы будете застревать с # 4. Я вижу, что # 3 начинает часто выходить из строя, так как проходит больше времени, поскольку зависимости недоступны.
daemonofchaos

на самом деле @KayakJim, хотя мы должны были это выяснить в то время - но, когда нагрузка на сервер была низкой, обслуживание было бы приемлемым, мы не думали достаточно далеко вперед. урок усвоен (надеюсь).
Стефано

Ответы:


4

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

Обновление, как правило, хорошее решение. do-release-upgradeхорошо сделано, и вы должны иметь возможность обновиться без проблем (особенно если вы использовали только официальные пакеты).

Мое любимое решение, хотя может быть путь переустановки. Более конкретно, ваши серверы должны управляться с использованием системы управления конфигурацией, такой как Puppet, Cfengine или Chef. Если все ваши требования к конфигурации / пакету указаны с помощью такого инструмента и ваши данные находятся в безопасности на отдельном разделе, их намного проще быстро переустановить. Вы просто устанавливаете новый дистрибутив, не стирая разделы данных, а затем запускаете инструмент управления конфигурацией для сброса ваших пакетов / конфигураций. Я считаю, что это самый чистый способ, особенно если у вас есть несколько серверов для управления.

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

$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n

Если вы хотите переустановить, вы также можете экспортировать список установленных пакетов:

$ dpkg --get-selections > myinstall.txt

и ваша база данных debconf:

$ debconf-get-selections > debconf.txt # from the debconf-utils package

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

Когда вы спрашиваете о пакетах Launchpad, я предполагаю, что вы имеете в виду PPA. Есть тонны разных PPA. Некоторые экспериментальные, некоторые стабильные. Некоторые поддерживаются официальными разработчиками Ubuntu, некоторые поддерживаются людьми, которые едва знают, как сделать пакет правильно. Трудно сказать в общем, если пакеты, которые вы найдете на PPA, хороши, общего правила нет. Лучшим советом в этом случае может быть слишком взглянуть на владельца PPA, чтобы получить представление о возможном качестве их пакетов.


Конечно, мы не думали о Puppet & Co. в то время. Но на самом деле вы делаете очень хорошее замечание, что, если мы пойдем по пути переустановки, лучше правильно подготовить простую для репликации установку. PS. "особенно если вы использовали только официальные пакеты", конечно, нет, к несчастью!
Стефано

Тогда первый шаг, который вы, возможно, захотите сделать, - это определить неофициальные пакеты. maintenance-checkможет помочь вам в этом (см. мое редактирование).
ℝaphink

Выбранный ответ для дополнительных советов, в том числе с использованием систем управления Conf и проверки технического обслуживания, а также о PPA. Я только что понял, изучив последние репозитории, что пакеты не всегда актуальны, например. даже в 11.04 версия nginx является OLD (0.8.54-4), и они никогда не перейдут на 1.0.x в этом дистрибутиве. Любой совет для таких ситуаций?
Стефано

1
@Stefano: Ubuntu использует ту же политику, что и Debian, которая заключается в том, что программное обеспечение не обновляется в основных репозиториях после выпуска (точнее, после зависания функции). Это действительно может привести к старым версиям программного обеспечения во все еще поддерживаемом выпуске (особенно, если программное обеспечение выпускается быстро). Вы можете использовать backports для получения новых версий, но вы, вероятно, потеряете в стабильности и безопасности обновлений. Для этого нет идеального решения, если только вы не хотите поддерживать свои собственные бэкпорты, что, как я уже говорил, довольно дорого.
ℝaphink

2

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

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

В этом случае у вас есть два варианта:

  1. Запустите поддерживаемый дистрибутив и получите обновления для вашего программного обеспечения, или

  2. Бэкпорт все исправления в ваш неподдерживаемый дистрибутив, что, честно говоря, не представляется возможным.

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

Лучшее решение - перейти на LTS-версию Ubuntu, которая на некоторое время предоставит вам поддержку для указанных версий пакетов. Со временем некоторые пакеты будут устаревшими, но ваша среда будет иметь исправления безопасности и будет стабильной (без изменений версии пакета). По моему опыту, стабильность известной рабочей среды обычно более ценна, чем новые функции.

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


спасибо @ Павел-Бродацкий. Сервер однозначно выставлен! Я понимаю вашу точку зрения на стабильность по сравнению с функциями. Проблема в том, что стабильность часто сопровождается основными шагами версии. Например. Серия nginx 1.0. * более стабильна, чем серия 0.8, включенная даже в последнюю версию. Любое предложение по этому поводу?
Стефано

1
Если он в настоящее время достаточно хорош, то применяется правило «если не сломано, не исправляйте». После этого это бизнес-расчет: добавленная стабильность позволит вам сэкономить больше, чем будет стоить вам поддерживать набор пакетов самостоятельно. Если это просто nginx или nginx и несколько библиотек, то компиляция, тестирование и развертывание - это то, что можно сделать. В этом случае, однако, было бы целесообразно внимательно следить за разработкой пакетов, чтобы быстро закрыть любые обнаруженные ошибки.
Павел Бродацкий

2

Единственный реальный путь вперед - это обновление дистрибутива. Я могу понять, что вы нервничаете по этому поводу, поскольку к настоящему времени вы будете прыгать на несколько выпусков вперед (11.04 только что выпущен).

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

Если вы не можете позволить себе простои, миграция - ваш единственный выход. Забудьте о пиннинге и бэкпортах, которые будут поддерживать вас в течение ограниченного периода времени. И вариант «катайся сам» даже не стоит рассматривать. Просто мои 2 копейки.

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