Спутник RHN / пользовательские каналы Выхода в открытый космос, лучшая практика?

Если бы это был я, то я выбрал бы их управляемым способом с reposync или некоторыми такой. Раскрывайте их каждый месяц или два, или когда Вы видите, что важные обновления системы защиты обнаруживаются в них, тестируют их в dev/qa/test/whatever_you_have_you_can_break_at_will, затем синхронизируют их к Вашему внутреннему производству repos, что Вы уже сказали Spacewalk/RHN SS о.

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

Я предлагаю людям, использующим Satellite, хранить копии доступных каналов в локальном файле:

# satellite-sync -l > channel_list

Это избавит вас от необходимости ждать, пока спутниковая синхронизация соединится с RHN и загрузит список. После добавления каналов к загрузке восстановление списка является хорошей идеей, так как буква «p» добавляется к каналам, которые вы уже синхронизируете.

Кроме того, запуск Satellite Sync на ночной основе будет не повредит и может значительно облегчить задачу. Однако обратите внимание, что синхронизация начнется в любом месте с 01:00 до 2:30 по вашему местному часовому поясу и может продолжаться в течение любого периода времени после этого. Убедитесь, что какие-либо резервные копии спутниковой базы данных не выполняются одновременно. При необходимости вы можете сократить время сна в работе cron. Это сделано для того, чтобы все не попадали в RHN ровно в час ночи в своих часовых поясах.

Хорошо, теперь о том, о чем вы спрашивали. К сожалению, из-за различий в каждой организации, использующей Satellite, невозможно создать всеобъемлющий «передовой опыт». Однако часто предлагается, чтобы организации, использующие каналы клонирования, относились к типу жизненного цикла Dev / Qa / Prod. Если канал Dev синхронизируется с каналом RHN (который синхронизируется каждую ночь) на определенной временной шкале, тогда Qa и prod обновляются в определенный момент времени позже, если Dev проходит все требуемые тесты обновлений. Затем канал Prod будет обновлен, когда канал Qa пройдет тестирование. Предположим, вы обновляете канал Dev ежемесячно, а через неделю вы обновляете канал Qa по сравнению с каналом Dev, если с обновлениями не возникает проблем. Затем канал Prod будет обновлен через неделю после этого, если не будет проблем. Возникают две проблемы: одна: как обрабатывать аварийные обновления для критических уязвимостей и как справляться с организационными трениями. Во-вторых, многим организациям нужен уровень контроля, который дает этот трехуровневый метод, однако многие могут не захотеть придерживаться графика 1 месяц / 1 неделя / 1 неделя. Таким образом, для вас может быть более подходящим иметь одно- или двухуровневую систему, смоделированную аналогичным образом.

Также предлагается поместить все дополнительные пакеты в дочерние каналы. Таким образом, если у вас есть версия марионетки, которую вы используете, поместите ее в канал верхнего уровня, созданный вами, а затем создайте клон этого канала в качестве дочернего для канала Dev. Вам также необходимо создать клон этого дочернего элемента для Qa и Prod, который будет исходным клоном со следующего уровня выше (Dev -> RHN, Qa -> Dev, Prod -> Qa). Это важно, потому что это упрощает пользовательский интерфейс, если вам нужно выполнить обновление канала с помощью пользовательского интерфейса. Также предлагается клонировать канал RHN-Tools для всех каналов клонирования.

Также могут возникнуть ситуации, когда группы внутри вашей организации требуют, чтобы все их системы были RHEL XY и не новее. Хотя это легко сделать с помощью таких пакетов, как spacewalk-create-channel (извините, ссылка на документ, доступный только для подписчиков RH), ваши группы будут в опасности, потому что они не будут получать последние обновления . Вот где важно понимание цикла выпуска Red Hat и политики выпуска выпуска. Например, многие люди предполагают, что SAP будет работать только с RHEL A. B, где они фактически говорят в своей документации, что они будут работать с любой поддерживаемой в настоящее время версией утвержденной операционной системы. Кроме того, вы можете «обмануть» и не обновлять пакет, который обновляет файл / etc / RedHat-release в вашем канале клонирования, но вы рискуете столкнуться с проблемами поддержки позже, поэтому это не рекомендуется.

При присвоении имени вашему клону каналы, важно помнить, что Satellite будет отображать их с помощью простой строковой сортировки. Таким образом, если вы хотите, чтобы ваши каналы было легко понять в пользовательском интерфейсе, назовите их так, чтобы это работало с простой строковой сортировкой. Я рекомендую людям вначале называть свои клонированные каналы словом «клон» или чем-то подобным и чтобы все связанные дочерние каналы следовали аналогичной схеме. Решение добавить архитектуру к имени остается за вами. Таким образом, канал клонирования может называться clone-rhel-5-x86_64 или mycompany-rhel-5 (если я использую одну архитектуру в своей организации). Я также могу не использовать RHEL в названии. Лучше, чтобы вы всегда включали достаточно информации, чтобы полностью понять природу канала.

Когда вы создаете клонированные каналы, вы не можете выполнять кикстарт-установку для клонированных каналов, если не создадите сначала распределений кикстарта в Satellite . Указания в ссылке предполагают, что вы импортируете ISO, поэтому вы можете пропустить первую половину шага 5. Когда вы копируете ISO в файловую систему, вы можете удалить каталог пакетов. Важно помнить, что вам нужно будет создать кикстарт-дистрибутив для каждой версии RHEL, которую вы планируете клонировать. Кроме того, каждая версия RHEL имеет свой загрузчик, поэтому он По возможности важно использовать самые последние версии. Однако, если вы планируете использовать «замороженный» клон RHEL 5.6, не рекомендуется использовать установщик 5.7. При именовании ваших деревьев кикстарта одним предложением будет clone-rhel5-u1 с номером после u, соответствующим моменту выпуска. Таким образом, 6.0 будет u0, а 6.3 будет u3. Вам не нужно импортировать дерево кикстарта для каждого канала клонирования. Лучшее место для получения ISO - это загрузить его из Red Hat, вы можете уйти, просто загрузив первый CD или DVD. Я не пробовал никаких других изображений, поэтому я не могу сказать вам, насколько хорошо они не работают.

Наконец, где только возможно, скрипируйте все, что вы можете в плане обновлений, используя API. Люди ленивы и совершают ошибки, и часто пользовательский интерфейс требует второго «подтверждения». щелкните, который я наблюдал, как люди пропускали много раз, думая, что их действие было завершено. Кроме того, организационные трения, о которых я упоминал выше в отношении циклов обновления, можно преодолеть с помощью API. Например, раз в месяц вы можете обновлять свой канал Dev по каналу RHN с помощью API. Затем вы отправите всем электронное письмо. Через неделю канал QA будет обновлен относительно канала Dev, снова всем будет отправлено электронное письмо. Через неделю канал Prod будет обновлен относительно канала Qa. Если имена ваших каналов достаточно согласованы или вы используете согласованные имена во всем сценарии api, их можно обобщить, чтобы принимать входящие и исходящие каналы, например:

# update-channel --to prod --from qa

Это приведет к обновлению следующих каналов: prod-rhel5-x86_64 и qa-rhel5- x86_64. Еще умнее он обновит и все дочерние каналы.

Надеюсь, вы продвинетесь немного дальше.

* примечание: Моя повседневная работа связана с Red Hat, но приведенное выше не представляет никакой официальной информации о поддержке. Приведенная выше информация является лишь рекомендацией, которая поможет вам лучше понять RHN Satellite.