Сейчас я настраиваю RHN Satellite, и все работает хорошо. Я нахожусь в процессе создания пользовательских каналов, так как у нас есть определенное программное обеспечение, которое должно быть доступно для всех узлов спутника, например puppet, facter, subversion, php (более новая версия, чем есть в базе).
Я попытался найти документацию по передовой практике по этому поводу. Как они должны быть настроены, как работать с другой архитектурой, как работать с пакетами noarch. Как синхронизировать обновления зависимостей при обновлении пользовательского пакета в пользовательском канале (например, обновлен php, как получить все обновленные зависимости).
Документация по управлению каналами от RHEL (http://www.redhat.com/docs/en-US/Red_Hat_Network_S satellite/5.3/Channel_Management_Guide/html/Channel_Management_Guide-Custom_Channel_and_Package_Management.html) не предоставляет мне достаточно информации о том, как решить любую из этих проблем.
Все советы, рекомендации и информация по этому поводу были бы замечательными!
Есть несколько вещей, которые вы можете сделать, чтобы облегчить себе жизнь. Во-первых, полностью понять Жизненный цикл выпуска Red Hat.
Одна вещь, которую я предлагаю людям, использующим Satellite, - это хранить копии доступных каналов в локальном файле:
# satellite-sync -l > channel_list
Это избавит вас от необходимости ждать, пока спутниковая синхронизация соединится с RHN и загрузит список. После добавления каналов в загрузку рекомендуется перестроить список, так как буква «p» добавляется к каналам, которые вы уже синхронизируете.
Кроме того, работает Спутниковая синхронизация по ночам, не повредит и может значительно упростить задачу. Однако обратите внимание, что синхронизация начнется в любом месте с 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 X.Y и не новее. Хотя это легко сделать с помощью таких пакетов, как выходить в открытый космос создать канал (извините, ссылка на документ, доступный только подписчикам 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.
Если бы это был я, я бы получал их контролируемым образом с помощью reposync или чего-то подобного. Снимайте их каждый месяц или два, или когда вы видите в них важные обновления безопасности, тестируйте их в dev / qa / test / any_you_have_you_can_break_at_will, а затем синхронизируйте их со своими внутренними производственными репозиториями, о которых вы уже сообщили Spacewalk / RHN SS.