Пользовательские каналы RHN Satellite / Spacewalk, лучшая практика?

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

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

# satellite-sync -l > channel_list

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

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

Хорошо, теперь на то, о чем вы спросили. К сожалению, из-за различий в каждой организации, использующей Satellite, нет способа создать всеобъемлющий "передовой опыт". Однако часто предлагается, чтобы организации, использующие каналы клонирования, рассматривали жизненный цикл типа Dev/Qa/Prod. Если канал Dev синхронизируется с каналом RHN (который синхронизируется ночью) на определенной временной шкале, тогда Qa и prod обновляются в определенный момент времени позже, если разработчик пройдет все необходимые тесты обновления. Канал 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 и понимать политику выпуска Vendor. Например, многие люди предполагают, что SAP будет работать только на RHEL AB, где они фактически говорят в своей документации, что они будут работать с любой поддерживаемой в настоящее время версией утвержденной операционной системы. Кроме того, вы можете "обмануть" и не обновлять пакет, который обновляет файл /etc/RedHat-release в вашем канале клонирования, но вы рискуете столкнуться с проблемами поддержки позже, поэтому это не рекомендуется.

При именовании ваших каналов Clone важно помнить, что Satellite будет отображать их, используя простую сортировку строк. Таким образом, если вы хотите, чтобы ваши каналы были легки для понимания в пользовательском интерфейсе, присвойте им имена способом, который работает с простой сортировкой строк. Я рекомендую, чтобы люди называли свои каналы-клоны "clone" или чем-то похожим в начале, и чтобы все связанные дочерние каналы следовали аналогичной схеме. Решение о добавлении архитектуры к названию остается за вами. Таким образом, канал клонирования может быть назван как clone-rhel-5-x86_64 или mycompany-rhel-5 (если я использую одну архитектуру в своей организации). I may also chose not to put RHEL in the name. It is best that you always include enough information to fully understand the nature of the channel.

When you create clone channels you cannot perform kickstart installations against clone channels unless you create kickstart distributions within Satellite first. The directions in the link assume you are importing an ISO, thus you can skip the first half of step 5. When you copy the ISO to your filesystem, you can delete the packages directory. The key thing to remember is you will need to create a kickstart distribution for every version of RHEL you plan to clone. In addition each version of RHEL has a slightly different bootloader and thus it's important to use the latest ones where possible. However if you are planning to use a "frozen" clone of RHEL 5.6, it is not suggested to use a 5.7 installer. When naming your kickstart trees one suggestion would be clone-rhel5-u1, with the number after the u corresponding to the point release. Thus 6.0 would be u0, and 6.3 would be u3. You will not need to import a kickstart tree for every clone channel. The best place to get the ISO is to download it from Red Hat, you can get away with just downloading the first CD or DVD. I have not tried any of the other images so I can't tell you how well they do not do not work.

Lastly, wherever possible script everything you can in terms up updates using the API. Humans are lazy and make mistakes, and often the UI requires a second "confirmation" click which I have watched people skip many times thinking their action was complete. In addition the organizational friction I mentioned above with regards to udpate cycles could be overcome via the API. For instance once a month you could update your Dev channel against the RHN channel using the API. Then you would send everyone an email. One week later the QA channel would be updated against the Dev channel, again everyone would be sent an email. One week later the Prod channel would be updated against the Qa channel. If your channel names are consistant enough or you use consistant names throughout your api script can be generalized to accept a to and from channel such as:

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

This would then update the following channels: prod-rhel5-x86_64 and qa-rhel5-x86_64. Even smarter it would update all child channels as well.

Hopefully that get's you a little further.

*note: My day job is with Red Hat, but the above does not represent any official support information. The above information is only a suggestion to help you better understand RHN Satellite.

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