Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Руководство по настройке клиентов

Red Hat Network Satellite 5.4

Red Hat Network Satellite

Редакция 1

Аннотация

Добро пожаловать в руководство по настройке клиентов Red Hat Network Satellite.

Глава 1. Введение

Целью данного руководства является предоставление информации о том, как проще выполнить настройку клиентов RHN Proxy и Satellite.
По умолчанию приложения клиентов Red Hat Network обращаются к центральным серверам Red Hat Network. Для подключения же клиентов к RHN Proxy и Satellite многие настройки придется изменить. Изменение настроек в одной или двух системах является тривиальной задачей, но представьте, если надо изменить настройки сотен или тысяч систем в корпоративном окружении, — в таком случае гораздо выгоднее осуществить массовую переконфигурацию. Это будет рассмотрено далее.
Можно заранее подготовить сценарий для автоматизации задач доступа к прокси-серверу и Satellite (см. Глава 5, rhn-bootstrap). Понимание последствий таких изменений довольно важно, поэтому в начальных разделах рассматривается ручная настройка. На основе полученных знаний вы сможете создать индивидуальное решение для вашей организации.
Многие команды, приведенные в этом руководстве, могут выполняться в указанном порядке. Тем не менее, невозможно рассмотреть все возможные конфигурации сети, поэтому инструкции следует воспринимать лишь как рекомендации и адаптировать их с учетом индивидуальных настроек организации.

Примечание

Информация о настройке клиентов Unix может быть найдена в главе Поддержка Unix в справочном руководстве RHN Satellite.

Глава 2. Приложения клиентов

Чтобы получить доступ к наиболее важным функциям Red Hat Network, таким как, например, регистрация в RHN Satellite, необходимы последние версии приложений клиентов. Получение этих приложений до регистрации клиента в Red Hat Network может оказаться затруднительным. Такой парадокс также будет иметь место при миграции большого числа систем в Red Hat Network. В этой главе мы попробуем определить способы решения этой дилеммы.

Важно

Red Hat настоятельно рекомендует, чтобы в системах клиентов выполнялась последняя версия Red Hat Enterprise Linux.
Если настроены межсетевые экраны, порты 80 и 443 должны быть открыты, чтобы обеспечить корректное взаимодействие с Red Hat Network.

2.1. Установка последних версий пакетов клиентов Red Hat Network

Для реализации основной функциональности Red Hat Network необходимы rhn_register (в Red Hat Enterprise Linux 5) или up2date (в предыдущих версиях Red Hat Enterprise Linux), а также программный агент обновления пакетов (pup). Их надо установить ДО начала использования RHN Proxy и Satellite в вашем окружении.
Существует несколько способов обновления программ клиентов RHN. Один из них включает сохранение RPM-пакетов в месте, доступном для всех клиентов, и их установка с помощью простой команды. В большинстве случаев не понадобится ручное обновление yum, pup, rhn_register (или up2date для более ранних версий Red Hat Enterprise Linux). Эти инструменты смогут подключиться к окружению RHN Proxy и Satellite. В данной секции подразумевается, что версии yum, pup, rhn_register (или up2date для старых версий) не являются самыми последними и не работают в вашем окружении.
Обратите внимание, что только системы Red Hat Enterprise Linux 5 должны быть зарегистрированы в RHN на стадии firstboot, или же можно зарегистрироваться позднее с помощью rhn_register. Начиная с Red Hat Enterprise Linux 3, системы могут использовать возможности регистрации агента обновлений Red Hat.
Здесь и далее подразумевается, что в вашей сети установлен как минимум один сервер RHN Proxy или Satellite. Приведенный пример демонстрирует простой подход к установке yum, pup, rhn_register (или up2date), допуская, что на машинах не выполняется RHN. Администратор заполнил каталог /var/www/html/pub/ копиями пакетов yum, pup, rhn_register (или up2date), которые будут использоваться клиентами, а затем их установил с помощью команды rpm -Uvh. В результате в системе клиента будут установлены соответствующие пакеты (если имя домена, пути и версии RPM заданы правильно):
rpm -Uvh
http://your_proxy_or_sat.your_domain.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/yum-3.2.8-9.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
Архитектуру (в данном случае i386), вероятно, нужно будет изменить в зависимости от обслуживаемых систем.

2.2. Настройка приложений клиентов

Не всем пользователям необходимо безопасное подключение к серверам RHN Satellte и Proxy в пределах организации. Не всем пользователям придется создавать и применять GPG-ключ к пакетам. Более подробно об этом будет рассказано позднее. Пользователи, использующие прокси-сервер и Satellte, должны настроить up2date и, возможно, rhn_register для осуществления перенаправления с Red Hat Network на свой прокси-сервер или Satellte.

Важно

up2date использует порт 443 для HTTPS и 80 для HTTP. По умолчанию yum в Red Hat Enterprise Linux 5 работает только с SSL. Именно поэтому пользователи должны убедиться, что их межсетевые экраны разрешают подключение к порту 443. Чтобы обойти SSL, в /etc/sysconfig/rhn/up2date измените протокол для serverURL с https на http. Аналогично, клиенты должны разрешать подключения к порту 4545 (или 22, если используется sshd) для доступа к возможностям мониторинга.
Изначально rhn_register и up2date обращаются к основным серверам Red Hat Network. Для подключения к RHN Satellte и Proxy потребуется изменить настройки клиентов.
Обратите внимание, что в последних версиях агента обновлений Red Hat можно настроить обращение к нескольким серверам RHN на случай, если основной сервер станет недоступен (см. Раздел 2.2.4, «Восстановление сервера после сбоя»).
Далее будут рассмотрены способы настройки доступа клиентов к RHN Proxy и Satellite. Глава 6, Создание сценария вручную содержит информацию об изменении настроек с помощью сценариев.

2.2.1. Регистрация с помощью ключей активации

Для регистрации и настройки клиентов, обращающихся к RHN Proxy и Satellite, Red Hat рекомендует использовать ключи активации. Они позволяют одновременно выполнить регистрацию, подписку систем и предоставить им полномочия. В секции, посвященной ключам активации справочного руководства RHN Satellite, можно найти подробную информацию.
Процесс регистрации с использованием ключа активации включает четыре основных этапа:
  1. Создайте ключ активации.
  2. Импортируйте свои ключи GPG.
  3. Загрузите и установите RPM сертификата SSL из каталога /pub/ на сервере RHN Proxy или Satellte:
    rpm -Uvh http://your-satellite-FQDN/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
    
  4. Зарегистрируйте систему на RHN Proxy или Satellte:
     rhnreg_ks --activationkey mykey --serverUrl https://your-satellite-FQDN/XMLRPC 
По желанию для этой цели можно создать сценарий, который будет выглядеть так (приведенная команда должна быть введена в одной строке):
wget -0 - http://your-satellite-FQDN/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://your-satellite-FQDN/XMLRPC
Команда содержит имя сценария начальной загрузки, созданного при установке и доступного обоим серверам RHN (см. Глава 5, rhn-bootstrap).

Предупреждение

Red Hat Enterprise Linux 2.1, Red Hat Linux 8.0 и более ранние версии могут испытывать проблемы с ключами активации при передаче настроек сертификата SSL из rhn_register в up2date. Поэтому данные сертификата SSL для таких систем придется настроить вручную. Остальные определения, такие как URL сервера, будут перенесены корректно.

2.2.2. Параметр up2date --configure

Агент обновлений Red Hat в Red Hat Enterprise Linux 3 и 4 предоставляет интерфейс, облегчающий конфигурацию. Полный список настроек можно найти на справочной странице (команда man up2date).
Чтобы изменить настройки агента обновлений RHN, в режиме root выполните
 up2date --configure 
Откроется окно настроек. На вкладке Общие в поле выбора сервера Red Hat Network введите полностью квалифицированное имя домена RHN Proxy или Satellite (например, https://proxy_or_sat.your_domain.com/XMLRPC). Не удаляйте /XMLRPC в конце строки. Нажмите OK.
Графическая настройка агента обновлений Red Hat

Рисунок 2.1. Графическая настройка агента обновлений Red Hat

Проверьте правильность имени домена прокси-сервера и Satellite. Если имя домена пустое или неверное, то up2date --configure может не запуститься. Это можно исправить, отредактировав значение в файле конфигурации up2date (см. Раздел 2.2.3, «Обновление файлов конфигурации вручную»).

Предупреждение

В Red Hat Enterprise Linux 3 и 4 функции регистрации предоставляет up2date, поэтому устанавливать клиент регистрации Red Hat Network не требуется. Системы Red Hat Enterprise Linux 5 не используют up2date, поэтому для регистрации потребуется rhn_register, а для обновления пакетов — yum и pup.

2.2.3. Обновление файлов конфигурации вручную

Если вы предпочитаете настроить up2date вручную, это можно сделать, напрямую отредактировав файл конфигурации.
Чтобы настроить up2date на подключение к RHN Proxy и Satellite, в файле /etc/sysconfig/rhn/up2date измените значения serverURL и noSSLServerURL (в режиме root). Замените существующую ссылку полностью квалифицированным именем домена RHN Proxy или Satellite:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC

Предупреждение

httpProxy в /etc/sysconfig/rhn/up2date НЕ относится к прокси-серверу RHN, а используется для определения дополнительного прокси-сервера HTTP для клиента. Оставьте поле httpProxy пустым.

2.2.4. Восстановление сервера после сбоя

Начиная с up2date-4.2.38, программу можно настроить так, чтобы поиск обновлений осуществлялся на серверах RHN. Это используется для поддержки обновлений, если основной сервер RHN Proxy и Satellite отключается от сети.
Чтобы воспользоваться этой возможностью, сначала проверьте версию up2date. Затем в файле /etc/sysconfig/rhn/up2date, в настройках serverURL и noSSLServerURL, вручную укажите вторичные серверы (в режиме root). После основного сервера укажите полностью квалифицированные имена доменов RHN Proxy и Satellite, разделив их точкой с запятой. Пример:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC; 
https://your_secondary.your_domain.com/XMLRPC;

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC; 
https://your_secondary.your_domain.com/XMLRPC;
Попытки подключения к серверам будут предприняты в указанном порядке. Можно включить произвольное число серверов и даже указать центральные серверы RHN. Это имеет смысл, если, конечно, системы клиентов подключены к Интернету.

2.3. Апплет обновления пакетов

Red Hat Enterprise Linux 5 включает в свой состав программу для периодической проверки наличия обновлений в RHN или на Satellite с последующим уведомлением пользователей.
Апплет обновления пакетов

Рисунок 2.2. Апплет обновления пакетов

Значок апплета обновлений расположен в области уведомлений. Помимо проверки наличия обновлений, апплет выполняет несколько других функций. Нажмите значок и выберите действие:
  • Обновить — проверка наличия обновлений в RHN или на Satellite.
  • Просмотр обновлений — запуск утилиты обновления пакетов, которая позволяет просмотреть доступные обновления и настроить их согласно требованиям.
  • Применить обновления — загрузка и установка обновленных пакетов.
  • Выход — закрыть апплет.

2.4. Настройка уведомлений RHN для Satellite

Доступ к программе уведомлений Red Hat Network можно получить, нажав значок на панели рабочего стола Red Hat Enterprise Linux 3 или 4. Начиная с Red Hat Enterprise Linux 3, ее можно настроить для определения доступных обновлений в пользовательских каналах RHN Satellite, но для этого требуется, чтобы RHN Satellite тоже поддерживал эту возможность. RHN Proxy поддерживает апплет и не требует модификации клиента или сервера. Ниже приведен порядок настройки программы уведомлений Red Hat Network.
  1. Убедитесь, что текущая версия RHN Satellite — 3.4 или более поздняя, и на сервере установлен пакет rhns-applet. Для версий, начиная с 3.4, пакет можно получить из программного канала RHN Satellite.
  2. Получите пакет rhn-applet-actions из канала утилит Red Hat Network или с помощью up2date. Установите его во всех системах клиентов (Red Hat Enterprise Linux 3 и более поздних), чтобы в будущем получать уведомления об обновлениях. Клиенты должны обладать полномочиями управления и обеспечения.
  3. На сайте RHN Satellite перейдите на страницу Свойства системы и нажмите ссылку в секции апплета RHN, чтобы перенаправить программу уведомлений на Satellite.
При следующем запуске апплета настройки вступят в силу, и будет выполнено подключение к RHN Satellite с целью получения обновлений.

Глава 3. Инфраструктура SSL

Для пользователей Red Hat Network вопросы безопасности имеют огромное значение. Преимуществом Red Hat Network является возможность обработки индивидуальных запросов по SSL (Secure Sockets Layer). Так, пользователи, устанавливающие Red Hat Network, должны создать собственные ключи и сертификаты SSL.
Создание и применение ключей и сертификатов SSL является довольно трудоемким процессом. И RHN Proxy, и Satellite позволяют создать ключи и сертификаты в процессе установки на основе CA (Certificate Authority). Дополнительно можно воспользоваться текстовой программой поддержки SSL. Независимо от того, какой метод вы предпочтете, ключи и сертификаты должны быть применены ко всем системам вашей инфраструктуры, что в большинстве случаев выполняется автоматически. В этой главе будут рассмотрены наиболее эффективные способы решения этих задач.
Следует отметить, что принципы SSL здесь не будут рассматриваться подробно. Программа поддержки SSL была разработана так, чтобы скрыть все сложную функциональность настройки и поддержки инфраструктуры общих ключей.

3.1. Краткий обзор SSL

Протокол SSL (Secure Sockets Layer) позволяет осуществлять безопасный обмен информацией между приложениями клиента и сервера. SSL использует пары открытых и закрытых ключей для шифрования данных. Доступ к общим сертификатам можно оставить открытым, в то время как закрытые ключи надо хранить в безопасном месте. Цифровая подпись, которая формируется в результате математического соотношения между частным ключом и соответствующим общим сертификатом, является основным компонентом, используемым для шифрования и дешифрования.

Примечание

В ходе этого документа будут обсуждаться закрытые ключи и открытые сертификаты SSL. В принципе, и то, и другое, можно называть ключами (закрытый и открытый). Но обычно открытый ключ называют сертификатом.
Стандартная инфраструктура SSL для организации включает следующие ключи и сертификаты:
  • Закрытый ключ и сертификат SSL CA (Certificate Authority) — для организации создается только один набор. Открытый сертификат подписывается с помощью закрытого ключа и передается всем системам.
  • Закрытый ключ и открытый сертификат веб-сервера — один набор для сервера приложений. Открытый сертификат подписывается с помощью своего закрытого ключа и закрытого ключа CA SSL. Термин набор ключей веб-сервера подразумевает, что будет дополнительно сгенерирован промежуточный запрос сертификата SSL. Подробности этого процесса выходят за пределы данной дискуссии, стоит лишь заметить, что все три компонента будут развернуты на сервере RHN.
Представим ситуацию: в наличии имеется один Satellite и пять прокси-серверов. При этом надо сгенерировать одну пару ключей CA SSL и шесть наборов ключей SSL для веб-сервера. Открытый сертификат CA SSL будет направлен всем системам и будет использоваться клиентами для установки соединения с серверами. Каждый сервер обладает собственным набором SSL-ключей, который привязан к имени узла сервера. Набор ключей создается на основе своего закрытого ключа SSL и закрытого ключа CA SSL. Так, будет установлена связь между открытым сертификатом SSL веб-сервера, парой ключей CA SSL и закрытым ключом сервера. Набор ключей сервера не может быть доступен другим серверам.

Важно

Пара ключей CA SSL является критическим компонентом системы. На основе закрытого ключа и открытого сертификата администратор может пересоздать набор ключей SSL для любого веб-сервера. Настоятельно рекомендуется создать архив каталога SSL и сохранить его на отдельный носитель, записать пароль CA и разместить все это в безопасном месте вместе с парой ключей.

3.2. rhn-ssl-tool

Для облегчения управления инфраструктурой Red Hat Network предоставляет утилиту rhn-ssl-tool, которая входит в состав пакета rhns-certs-tools. Этот пакет может быть получен из канала RHN Proxy и Satellite или из ISO-образа RHN Satellite. rhn-ssl-tool позволяет создать собственную пару ключей CA SSL, а также наборы ключей SSL веб-сервера.
Эта утилита создаст необходимые ключи и сертификаты, запакует файлы в RPM для последующей передачи и установки в системах клиентов. Установка осуществляется администратором или же автоматизируется сервером Satellite.

Примечание

Пакет rhns-certs-tools может быть установлен и исполнен в любой системе, удовлетворяющей минимальным требованиям. Это позволяет управлять инфраструктурой SSL из любой системы, а не только с сервера RHN.
Ситуации, в которых может пригодиться эта утилита:
  • При обновлении открытого сертификата CA, что случается довольно редко.
  • При установке RHN Proxy 3.6 или более поздних версий, который будет подключаться к центральным серверам RHN, так как служба hosted не может хранить сертификат и ключ CA SSL в силу того, что они принадлежат только вашей организации.
  • При начальной настройке SSL в вашей инфраструктуре RHN.
  • При добавлении в инфраструктуру RHN Proxy, версия которого предшествует 3.6.
  • При добавлении в инфраструктуру нескольких серверов RHN Satellite. Прежде чем приступить, проконсультируйтесь с представителем Red Hat.
Примеры ситуаций, когда в утилите нет необходимости:
  • В процессе установки RHN Satellite, когда осуществляются все настройки SSL. Сертификат и ключи SSL будут созданы и применены автоматически.
  • В процессе установки RHN Proxy 3.6 и более поздних версий, который будет подключаться к RHN Satellite 3.6+. RHN Satellite включает информацию SSL, необходимую для конфигурации, сборки и применения сертификатов и ключей SSL на прокси-сервере.
В ходе установки обоих типов серверов открытый сертификат CA SSL будет сохранен в каталог /pub на сервере. Этот сертификат используется клиентами для подключения к серверу RHN (см. Раздел 3.3, «Установка открытых сертификатов CA в системах клиентов»).
Если в инфраструктуре организации развернута последняя версия RHN Satellite, то, возможно, вам и не понадобится эта утилита. В противном случае рекомендуется ознакомиться с ее работой.

3.2.1. Генерация SSL

Основными достоинствами rhn-ssl-tool является безопасность, гибкость использования и мобильность. Безопасность достигается за счет создания отдельных SSL-ключей и сертификатов для каждого сервера RHN и их подписи с помощью одной пары ключей CA. Под гибкостью подразумевается возможность выполнения утилиты на любой машине, где установлен пакет rhns-certs-tools. Наконец, мобильность заключается в том, что структура сборки может быть сохранена в произвольном месте и установлена позднее.
Наконец, при наличии последней версии RHN Satellite может понадобиться извлечь структуру ssl-build из архива в каталог /root и воспользоваться средствами конфигурации сайта RHN Satellite.
Чтобы обеспечить максимальную эффективность работы этой утилиты, следуйте приведенной далее последовательности действий.
  1. Установите rhns-certs-tools в системе в пределах вашей организации, не обязательно на RHN Proxy или Satellite.
  2. Создайте пару ключей CA SSL и установите соответствующий пакет RPM или открытый сертификат во всех системах клиентов.
  3. Создайте набор ключей SSL для каждого RHN Proxy и Satellite и установите соответствующие пакеты RPM на серверах RHN. Перезапустите httpd:
     /sbin/service httpd restart 
  4. Создайте архив дерева сборки SSL, включающего каталог сборки, а также все подкаталоги и файлы, включая съемные носители, такие как гибкие диски. При этом требования дискового пространства не имеют значения.
  5. Проверьте целостность архива и сохраните его в безопасном месте. Возможные расположения описаны в секции Дополнительные требования руководств по установке прокси-сервера и Satellite.
  6. Запишите пароль CA и храните его в безопасном месте.
  7. В целях безопасности удалите дерево сборки из системы, но только после завершения настройки инфраструктуры RHN.
  8. Если требуются дополнительные наборы ключей SSL, восстановите дерево сборки с помощью программы поддержки SSL и повторите шаги с 3 по 7.

3.2.2. Параметры rhn-ssl-tool

Программа поддержки SSL может использовать множество параметров для генерации пары ключей CA SSL и управления ключами и сертификатами SSL. Три варианта просмотра информации включают rhn-ssl-tool --help (общая информация), rhn-ssl-tool --gen-ca --help (СА), rhn-ssl-tool --gen-server --help (веб-сервер). Страница помощи rhn-ssl-tool содержит дальнейшую информацию. Для ее просмотра выполните команду man rhn-ssl-tool.
В последующих таблицах параметры сгруппированы согласно задачам — генерация наборов ключей SSL веб-сервера или CA.
Следующему набору параметров должен предшествовать аргумент --gen-ca.

Таблица 3.1. Параметры CA SSL (rhn-ssl-tool --gen-ca --help)

Параметр Описание
--gen-ca Генерация пары ключей CA SSL и общего RPM. Предшествует другим параметрам, перечисленным далее в этой таблице.
-h, --help Вывод справки с перечнем основных параметров, используемых при генерации и управлении CA.
-f, --force Принудительное создание нового закрытого ключа CA и открытого сертификата.
-p=, --password=ПАРОЛЬ Пароль CA. Будет запрошен, если пароль не указан. Храните его в безопасном месте.
-d=, --dir=КАТАЛОГ_СБОРКИ Обязателен для многих команд. Каталог сборки сертификатов и RPM-пакетов. По умолчанию используется ./ssl-build.
--ca-key=ФАЙЛ Имя файла закрытого ключа CA. По умолчанию используется RHN-ORG-PRIVATE-SSL-KEY.
--ca-cert=ФАЙЛ Имя файла общего сертификата CA. По умолчанию используется RHN-ORG-TRUSTED-SSL-CERT.
--cert-expiration=ДАТА Дата истечения общего сертификата CA. По умолчанию срок действия истекает 18 января 2038 г.
--set-country=КОД_СТРАНЫ Двухзначный код страны. Значение по умолчанию — US.
--set-state=ОБЛАСТЬ Область CA. Значение по умолчанию — ''.
--set-city=ГОРОД Город. Значение по умолчанию — ''.
--set-org=ОРГАНИЗАЦИЯ Организация, например: Red Hat. Значение по умолчанию — Example Corp. Inc.
--set-org-unit=ОТДЕЛ Отдел организации, например: RHN. Значение по умолчанию — ''.
--set-common-name=ИМЯ Имя. Обычно не задается для CA.
--set-email=АДРЕС Электронный адрес. Обычно не задается для CA.
--rpm-packager=УПАКОВАНО Создатель пакета RPM, например: "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=ПРОИЗВОДИТЕЛЬ Производитель пакета RPM, например: "IS/IT Example Corp."
-v, --verbose Подробный вывод. Повторное указание "v" приведет к выводу более детальной информации.
--ca-cert-rpm=RPM Обычно не изменяется. Базовое имя файла RPM-пакета с сертификатом CA. Не используйте полное имя в формате «файл-версия-выпуск.noarch.rpm».
--key-only Обычно не используется. Генерация только закрытого ключа CA. Страница --gen-ca --key-only --help содержит более подробную информацию.
--cert-only Обычно не используется. Генерация только открытого сертификата CA. Страница --gen-ca --key-only --help содержит более подробную информацию.
--rpm-only Обычно не используется. Генерация RPM-пакета для его последующего развертывания. Страница --gen-ca --key-only --help содержит более подробную информацию.
--no-rpm Обычно не используется. Выполнение всех шагов CA за исключением создания RPM.
Следующим опциям должен предшествовать аргумент --gen-server.

Таблица 3.2. Параметры веб-сервера SSL (rhn-ssl-tool --gen-server --help)

Параметр Описание
--gen-server Генерация набора ключей SSL, RPM-пакета и архива tar. За ним должны следовать другие параметры, приведенные в этой таблице.
-h, --help Просмотр справки с перечнем основных параметров, используемых для генерации и управления парами ключей.
-p=, --password=ПАРОЛЬ Пароль CA. Будет запрошен, если пароль не указан. Храните его в безопасном месте.
-d=, --dir=КАТАЛОГ_СБОРКИ Обязателен для многих команд. Каталог сборки сертификатов и RPM-пакетов. По умолчанию используется ./ssl-build.
--server-key=ФАЙЛ Имя файла закрытого ключа SSL. По умолчанию используется server.key.
--server-cert-req=ФАЙЛ Имя файла запроса SSL-сертификата веб-сервера. По умолчанию используется server.csr.
--server-cert=ФАЙЛ Имя файла SSL-сертификата веб-сервера. По умолчанию используется server.crt.
--startdate=ГГММДДЧЧММССZ Дата вступления сертификата сервера в силу в порядке «год, месяц, день, час, минуты, секунды» (2 символа на одно значение). Указание Z обязательно. По умолчанию сертификат вступит в силу через неделю после его генерации.
--cert-expiration=ДАТА Дата истечения сертификата сервера. По умолчанию сертификат будет действительным до 18 января 2038 г.
--set-country=КОД_СТРАНЫ Двухзначный код страны. Значение по умолчанию — US.
--set-state=ОБЛАСТЬ Область или регион. Значение по умолчанию — North Carolina.
--set-city=ГОРОД Город. Значение по умолчанию — Raleigh.
--set-org=ОРГАНИЗАЦИЯ Организация, например: Red Hat. Значение по умолчанию — Example Corp. Inc.
--set-org-unit=ОТДЕЛ Отдел организации, например: RHN. Значение по умолчанию — ''.
--set-hostname=ИМЯ Имя сервера RHN, который получит ключ. По умолчанию будет использовать имя узла системы, где осуществляется сборка.
--set-email=АДРЕС Электронный адрес администратора. По умолчанию используется admin@example.corp.
--rpm-packager=УПАКОВАНО Создатель пакета RPM, например: "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=ПРОИЗВОДИТЕЛЬ Производитель пакета RPM, например: "IS/IT Example Corp."
-v, --verbose Подробный вывод. Повторное указание "v" приведет к выводу более детальной информации.
--key-only Обычно не используется. Создание только закрытого ключа сервера. Добавьте --gen-server --key-only --help для получения более подробной информации.
--cert-req-only Обычно не используется. Создание только запроса сертификата сервера. Добавьте --gen-server --cert-req-only --help для получения более подробной информации.
--cert-only Обычно не используется. Создание только сертификата сервера. Выполните команду --gen-server --cert-only --help для получения более подробной информации.
--rpm-only Обычно не используется. Создание только RPM-пакета. Добавьте --gen-server --rpm-only --help для получения более подробной информации.
--no-rpm Обычно не используется. Выполнение всех действий кроме создания RPM.
--server-rpm=RPM Обычно остается неизменным. Имя RPM с набором ключей SSL веб-сервера (базовое имя, а не полное имя в формате «файл-версия-выпуск.noarch.rpm»).
--server-tar=TAR Обычно остается неизменным. Имя архива .tar, содержащего набор SSL-ключей сервера и открытый сертификат CA, которые используются только в процессе установки прокси-сервера RHN (базовое имя файла, а не полное имя в формате «файл-версия-выпуск.tar»).

3.2.3. Создание пары ключей SSL CA

Перед созданием набора ключей, который потребуется веб-серверу, сначала надо создать пару ключей CA (Certificate Authority). Общий сертификат передается всем системам клиентов RHN Proxy и Satellite. Программа поддержки SSL позволяет создать пару ключей CA SSL и использовать ее для последующих развертываний серверов RHN.
В процессе сборки будет автоматически создана пара ключей и RPM-пакет для передачи клиентам. Все компоненты CA будут сохранены в каталоге, указанном в командной строке, обычно это — /root/ssl-build или /etc/sysconfig/rhn/ssl для более ранних версий RHN Proxy и Satellite. Команда создания пары ключей будет выглядеть так:
rhn-ssl-tool --gen-ca --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example Inc." \
--set-org-unit="SSL CA Unit"
Измените значения, чтобы они отражали настройки вашей организации. В указанном каталоге будут созданы следующие файлы:
  • RHN-ORG-PRIVATE-SSL-KEY — закрытый ключ CA SSL.
  • RHN-ORG-TRUSTED-SSL-CERT — открытый сертификат CA SSL.
  • rhn-org-trusted-ssl-cert-версия.noarch.rpm — RPM-пакет для передачи клиентам. Содержит общий сертификат CA SSL (см. выше), который будет установлен в /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.
  • rhn-ca-openssl.cnf — файл конфигурации CA SSL.
  • latest.txt — список последних версий файлов.
Теперь RPM-пакет можно передать системам клиентов (см. Раздел 3.3, «Установка открытых сертификатов CA в системах клиентов»).

3.2.4. Создание наборов ключей SSL для веб-сервера

Вероятно, вы будете достаточно часто выполнять генерацию наборов ключей SSL сервера, особенно при развертывании нескольких RHN Proxy и Satellite. Стоит обратить внимание, что значение --set-hostname будет отличаться для каждого сервера. Другими словами, необходимо сгенерировать уникальный набор сертификатов ключей SSL и установить их на серверах RHN.
Процесс создания сертификата аналогичен генерации пары ключей CA SSL с одним исключением — все компоненты сервера будут располагаться в каталоге /root/ssl-build/имя_машины. Команда генерации сертификатов серверов будет выглядеть приблизительно так:
rhn-ssl-tool --gen-server --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example	Inc." \
--set-org-unit="IS/IT" --set-email="admin@example.com" \
--set-hostname="rhnbox1.example.com
Измените значения переменных, чтобы они отражали настройки вашей организации. В указанном каталоге будут созданы следующие файлы:
  • server.key — закрытый ключ SSL сервера.
  • server.csr — запрос SSL-сертификата веб-сервера.
  • server.crt — открытый SSL-сертификат веб-сервера.
  • rhn-org-httpd-ssl-key-pair-машина-версия-выпуск.noarch.rpm — RPM-пакет для передачи серверам RHN. Также будет создан соответствующий файл src.rpm. Сам пакет будет включать три перечисленных файла, которые будут установлены в
    • /etc/httpd/conf/ssl.key/server.key
    • /etc/httpd/conf/ssl.csr/server.csr
    • /etc/httpd/conf/ssl.crt/server.crt
  • rhn-server-openssl.cnf — файл конфигурации SSL веб-сервера.
  • latest.txt — список последних версий файлов.
Теперь RPM-пакет можно передать на соответствующий сервер RHN и установить. После установки не забудьте запустить httpd:
 /sbin/service httpd restart 

3.3. Установка открытых сертификатов CA в системах клиентов

Процессы установки RHN Proxy и Satellite облегчают развертывание на клиентах за счет генерации открытого сертификата CA SSL и RPM-пакета и предоставления к ним доступа при их копировании в /var/www/html/pub/ на сервере RHN.
Для доступа к этому каталогу просто введите адрес http://proxy-or-sat.example.com/pub/ в окне браузера.
Сертификат CA SSL можно получить с помощью wget и curl.
curl -O	http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
wget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Если же RPM общего сертификата CA SSL расположен в /pub, его можно напрямую установить в системе клиента:
rpm -Uvh \
http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm
Проверьте имя сертификата или RPM перед выполнением команд.

3.4. Настройка клиентов

После установки сертификата в системе клиента необходимо изменить файлы конфигурации агента обновлений Red Hat и клиента регистрации Red Hat Network, чтобы иметь подключения к RHN Proxy или Satellite. Обычно открытый сертификат расположен в каталоге /usr/share/rhn.
На RHN Proxy и Satellite по умолчанию устанавливается сценарий начальной загрузки RHN, который существенно облегчает процесс регистрации и настройки клиентов (см. Глава 5, rhn-bootstrap).

Глава 4. Импортирование ключей GPG

Если пользователи планируют создавать и распространять RPM-пакеты самостоятельно, рекомендуется их подписать с помощью GPG (GNU Privacy Guard). Создание ключей GPG и сборка подписанных таким образом пакетов рассматривается в руководстве по управлению каналами Red Hat Network.
Необходимо скопировать открытый ключ во все системы, импортирующие подписанные пакеты. Это включает два этапа: создание центрального хранилища для открытого ключа, чтобы клиенты могли его получить, и добавление ключа в локальную связку GPG системы.
Первый шаг можно выполнить через веб-интерфейс (см. Раздел 2.1, «Установка последних версий пакетов клиентов Red Hat Network»). Создайте каталог с открытым доступом на веб-сервере и поместите туда открытый ключ:
cp /путь/к/RPM-GPG-КЛЮЧА /var/www/html/pub/
Теперь ключ может быть получен клиентами с помощью wget:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/RPM-GPG-КЛЮЧА
-O- отправляет результаты в стандартный вывод, а -q принуждает выполнение wget в тихом режиме. Замените RPM-GPG-КЛЮЧА именем файла ключа.
Теперь добавьте ключ в локальную связку. В разных операционных системах это может выполняться по разному.
Например, начиная с Red Hat Enterprise Linux 3, используется команда
rpm --import /путь/к/RPM-GPG-КЛЮЧА
Для Red Hat Enterprise Linux 2.1 выполните
gpg $(up2date --gpg-flags) --import /путь/к/RPM-GPG-КЛЮЧА
После успешного добавления GPG-ключа в систему клиента она сможет самостоятельно проверять подпись получаемых пакетов.

Глава 5. rhn-bootstrap

Утилита rhn-bootstrap позволяет автоматизировать процесс настройки, подробно рассмотренный в предыдущих разделах. Она является ключевым компонентом программы установки сервера Satellite и позволяет генерировать сценарий bootstrap в процессе установки.
/usr/bin/rhn-bootstrap устанавливается по умолчанию на серверах RHN Proxy и Satellite.
Как уже упоминалось, эта утилита генерирует сценарий, который может исполняться в любой системе клиента и выполнять следующее:
  • перенаправление приложений клиентов серверам RHN Proxy и Satellite;
  • импорт произвольных ключей GPG;
  • установка сертификатов SSL;
  • регистрация систем и каналов в RHN с помощью ключей активации;
  • различные задачи после конфигурации, такие как обновление пакетов, перезагрузка, изменение настроек RHN.
Не следует забывать о рисках, связанных с использованием сценариев для настройки. Так, например, SSL-сертификаты устанавливаются сценарием, поэтому изначально в системе их нет, что позволяет потенциальным злоумышленникам представиться как Satellite и начать передавать произвольные данные. Эту проблему смягчает тот факт, что Satellite и клиенты обычно защищены межсетевым экраном и не взаимодействуют с внешним трафиком. Процесс регистрации также защищен, поскольку он выполняется по SSL.
Сценарий bootstrap.sh помещается в каталог /var/www/html/pub/bootstrap/ на сервере RHN. Его можно загрузить и выполнить в системах клиентов, для чего потребуется некоторая подготовка, что будет рассмотрено позднее. Раздел 5.4, «Параметры rhn-bootstrap» содержит полный список параметров, а Приложение A, Пример сценария bootstrap.sh — пример сценария.

5.1. Подготовка

Так как помимо rhn-bootstrap в настройке клиентов принимают участие и другие компоненты RHN, их следует подготовить ДО генерации сценария. Последовательность действий по подготовке приведена далее.
  • Создайте ключи активации, к которым будет обращаться сценарий. Ключи могут использоваться для одновременной регистрации систем Red Hat Enterprise Linux, предоставления им уровня обслуживания RHN, их подписки к каналам и системным группам. Обратите внимание, что для использования ключей активации необходимы полномочия управления, в то время как для включения нескольких ключей активации — полномочие обеспечения. Генерация ключей выполняется на странице Ключи активации секции Системы сайта RHN (либо центральных серверов RHN для прокси, либо при указании полностью квалифицированного имени домена Satellite). Разделы, посвященные агенту обновлений RHN и сайту RHN справочного руководства RHN, содержат инструкции по созданию и использованию ключей.
  • Red Hat рекомендует подписывать RPM-пакеты ключом GPG. Откройте доступ к этому ключу, чтобы к нему можно было обращаться из сценария. Создайте ключ (см. руководство по управлению каналами RHN) и поместите его в каталог /var/www/html/pub/ на сервере RHN (см. Глава 4, Импортирование ключей GPG).
  • Если вы планируете применить общий сертификат CA SSL с помощью сценария, убедитесь, что сертификат или пакет с сертификатом расположен на сервере RHN и с помощью опции --ssl-cert включите его в генерацию сценария (см. Глава 3, Инфраструктура SSL).
  • С использованием различных значений можно генерировать отдельные сценарии bootstrap для разных типов систем. Например, bootstrap-web-servers.sh можно применять для настройки веб-серверов, а bootstrap-app-servers.sh — программных серверов (см. Раздел 5.4, «Параметры rhn-bootstrap»).

5.2. Генерация

Сценарии создаются с помощью команды rhn-bootstrap. Авторизуйтесь как root на RHN Proxy или Satellite и выполните rhn-bootstrap, указав необходимые параметры и их значения. Если параметры не указаны, то будет создан каталог bootstrap/, содержащий полученные с сервера значения, включая имя узла, сертификат SSL (если существует), настройки SSL и GPG, вызов файла client-config-overrides.txt.
Red Hat рекомендует, чтобы сценарии также использовали следующие ключи активации, ключи GPG, расширенные параметры конфигурации:
  • Параметр --activation-keys для включения ключей, принимая во внимание требования полномочий (см. Раздел 5.1, «Подготовка»).
  • Параметр --gpg-key, чтобы определить путь к файлу ключа в процессе генерации сценария. Или же укажите --no-gpg для отключения проверки в системах клиентов. Red Hat не рекомендует отключать проверку.
  • --allow-config-actions включает удаленное управление конфигурацией во всех системах клиентов, обрабатываемых сценарием. Обычно применяется при одновременной перенастройке нескольких систем.
  • --allow-remote-commands включает использование удаленного сценария во всех системах клиентов. Обычно применяется при одновременной перенастройке нескольких систем.
Окончательная команда будет выглядеть приблизительно так:
	rhn-bootstrap --activation-keys KEY1,KEY2 \
		--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \
		--allow-config-actions \
		--allow-remote-commands
Приведенные здесь имена ключей следует заменить действительными. Раздел 5.4, «Параметры rhn-bootstrap» содержит полный список параметров.

5.3. Вызов сценария

Завершив подготовку сценария, можно его исполнить. Авторизуйтесь на RHN Proxy или Satellite, перейдите в каталог /var/www/html/pub/bootstrap/ и выполните следующую команду (изменив имя узла и сценария):
cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash
Менее безопасный подход состоит в использовании wget или curl для получения и исполнения сценария каждым клиентом. Выполните вход в систему клиента и выполните команду (изменив имя узла и сценария):
wget -qO - \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Или с помощью curl:
curl -Sks \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
По завершении исполнения сценария во всех системах клиентов они должны быть настроены на работу с сервером RHN.

5.4. Параметры rhn-bootstrap

rhn-bootstrap может использовать множество параметров для создания сценариев bootstrap. Следующая таблица содержит описание параметров, но сначала необходимо проверить, доступны ли они в версии rhn-bootstrap, установленной на вашем сервере RHN. Для этого выполните rhn-bootstrap --help или просмотрите страницу помощи man.

Таблица 5.1. Параметры rhn-bootstrap

Параметр Описание
-h, --help Просмотр экрана помощи с перечнем параметров генерации сценария bootstrap.
--activation-keys=КЛЮЧИ_АКТИВАЦИИ Определенные на сайте RHN ключи активации. Список ключей разделяется запятой без пробелов и может занимать несколько строк.
--overrides=ИМЯ Переопределение настроек. По умолчанию используется client-config-overrides.txt.
--script=СЦЕНАРИЙ Имя сценария начальной загрузки. По умолчанию используется bootstrap.sh.
--hostname=ИМЯ Полностью квалифицированное имя домена сервера, к которому будут подключаться клиенты.
--ssl-cert=СЕРТИФИКАТ_SSL Путь к открытому сертификату SSL вашей организации (пакету или файлу сертификата). Этот путь будет скопирован в --pub-tree. Значение "" вызовет принудительный поиск --pub-tree.
--gpg-key=КЛЮЧ Путь к открытому GPG-ключу организации. Он будет скопирован в каталог, определенный параметром --pub-tree.
--http-proxy=прокси Это значение задается в форме имя_узла:порт. Значение "" отключает этот параметр.
--http-proxy-username=ИМЯ_ПОЛЬЗОВАТЕЛЯ_ПРОКСИ Если используется прокси-сервер с аутентификацией, укажите имя пользователя. Значение "" отключает этот параметр.
--http-proxy-password=ПАРОЛЬ_ПРОКСИ_HTTP Если используется прокси-сервер с аутентификацией, укажите пароль.
--allow-config-actions Логическое значение. Активация этого параметра позволит выполнять все действия конфигурации в RHN. Это потребует установки некоторых пакетов rhncfg-*, для чего может понадобиться ключ активации.
--allow-remote-commands Логическое значение. Активация этого параметра позволит выполнять произвольные команды в RHN. Это потребует установки некоторых пакетов rhncfg-*, для чего, вероятно, понадобится ключ активации.
--no-ssl Не рекомендуется. Логическая величина. Активация этого параметра отключит SSL в системе клиента.
--no-gpg Не рекомендуется. Логическая величина. Активация этого параметра отключит проверку GPG в системе клиента.
--no-up2date Не рекомендуется. Логическая величина. Активация этого параметра отключит выполнение up2date после установки в системе сценария bootstrap.
--pub-tree=ПУТЬ Не рекомендуется изменять. Файловая структура с открытым доступом, где будет сохранен сертификат CA SSL и соответствующий пакет. По умолчанию используется /var/www/html/pub/.
--force Не рекомендуется. Логическая величина. Активация этого параметра принудит генерацию сценария начальной загрузки несмотря на предупреждения.
-v, --verbose Подробный вывод. Последовательное указание параметра (например, -vvv) усиливает степень подробности вывода.

Глава 6. Создание сценария вручную

Действия, описанные в данной главе, позволяют создать сценарий вручную, что представляет альтернативу автоматическому созданию сценария с помощью rhn-bootstrap.
Начальные шаги включают перенос необходимых файлов в центральное хранилище, откуда их можно будет получить и установить в системах клиентов с использованием сценариев. В ходе данной главы мы попробуем создать сценарий, который можно будет выполнить в любой системе в пределах организации.
Объединив в один сценарий команды, рассмотренные в предыдущих главах, получится примерно следующее (обратите внимание, rhn_register не существует в Red Hat Enterprise Linux 3 и 4):
# First, install the latest client RPMs to the system.
rpm -Uvh \
	http://proxy-or-sat.example.com.com/pub/rhn_register-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/rhn_register-gnome-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-3.0.7-1.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-gnome-3.0.7-1.i386.rpm

# Second, reconfigure the clients to talk to the correct server.

perl -p -i -e 's/s/www\.rhns\.redhat\.com/proxy-or-sat\.example\.com/g' \
	/etc/sysconfig/rhn/rhn_register \
	/etc/sysconfig/rhn/up2date


# Third, install the SSL client certificate for your company's 
# RHN Satellite Server or RHN Proxy Server.
rpm -Uvh http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-*.noarch.rpm

# Fourth, reconfigure the clients to use the new SSL certificate.
perl -p -i -e 's/^sslCA/#sslCA/g;' \
	/etc/sysconfig/rhn/up2date /etc/sysconfig/rhn/rhn_register
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/up2date
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/rhn_register


# Fifth, download the GPG key needed to validate custom packages.
wget -O - -q http://proxy-or-sat.example.com.com/pub/YOUR-RPM-GPG-KEY


# Sixth, import that GPG key to your GPG keyring.
rpm --import /path/to/YOUR-RPM-GPG-KEY
Шестой шаг приведен для Red Hat Linux 3 и более поздних версий.
Этот сценарий позволяет полностью подготовить клиент Red Hat Network к регистрации на серверах прокси и Satellite. Ключевые значения, такие как ссылки на сервер RHN, общий каталог и GPG-ключ должны располагаться в каталогах, указанных в сценарии. Дополнительно, в зависимости от окружения могут потребоваться другие изменения, поэтому приведенный сценарий стоит рассматривать лишь как основу.
Сценарий можно разместить в центральном хранилище. Если его сохранить в каталоге /pub/ на сервере и выполнить wget -O-, перенаправив вывод в сеанс оболочки, то для выполнения процесса начальной загрузки понадобится всего лишь одна команда от клиента:
wget -O - http://proxy-or-sat.example.com.com/pub/bootstrap_script | bash

Предупреждение

Запуск сценария из ввода, перенаправленного по веб-соединению, представляет угрозу безопасности. Поэтому необходимо обеспечить безопасность исходного сервера.
Эта команда может быть выполнена в любой системе в сети. Если у администратора есть SSH-доступ ко всем системам, можно просто заключить исполнение этой команды в цикл и запустить его удаленно. Сценарий также можно поместить в секцию %post существующего сценария кикстарта.

Глава 7. Реализация кикстарта

Вполне очевидно, что конфигурацию системы лучше всего изменять при ее изначальной сборке. Пользователи, которые уже успешно используют кикстарт, могут воспользоваться сценарием начальной загрузки.
Разобравшись с конфигурацией, систему можно зарегистрировать на локальных серверах Red Hat Network. Для этого используйте утилиту rhnreg_ks, входящую в состав пакетов up2date и rhn_register.
Для регистрации, выделения полномочий и подписки систем к каналам rhnreg_ks использует ключи активации. Главы, посвященные агенту обновлений Red Hat и сайту RHN справочного руководства по управлению Red Hat Network содержат информацию о ключах активации.
Следующий пример файла кикстарта демонстрирует полную конфигурацию с помощью Red Hat Network.
# Generic 7.2 kickstart for laptops in the Widget Corporation (widgetco)

# Standard kickstart options for a network-based install. For an
# explanation of these options, consult the Red Hat Linux Customization 
# Guide.

lang en_US
langsupport --default en_US en_US
keyboard defkeymap
network --bootproto dhcp
install
url --url ftp://ftp.widgetco.com/pub/redhat/linux/7.2/en/os/i386
zerombr yes
clearpart --all
part /boot	 --size 128 --fstype ext3 --ondisk hda
part /			 --size 2048 --grow --fstype ext3 --ondisk hda
part /backup --size 1024 --fstype ext3 --ondisk hda
part swap		--size 512 --ondisk hda
bootloader --location mbr
timezone America/New_York
rootpw --iscrypted $1$78Jnap82Hnd0PsjnC8j3sd2Lna/Hx4.
auth --useshadow --enablemd5 --krb5realm .COM --krb5kdc auth.widgetco.com \
	--krb5adminserver auth.widgetco.com
mouse --emulthree genericps/2
xconfig --card "S3 Savage/MX" --videoram 8192	--resolution 1024x768 \
	--depth 16 --defaultdesktop=GNOME --startxonboot --noprobe \
	 --hsync 31.5-48.5 --vsync 40-70

reboot

# Define a standard set of packages.	Note: Red Hat Network client 
# packages are found in Base.	This is quite a minimal set of packages;
# your mileage may vary.

%packages
@ Base
@ Utilities
@ GNOME
@ Laptop Support
@ Dialup Support
@ Software Development
@ Graphics and Image Manipulation
@ Games and Entertainment
@ Sound and Multimedia Support


# Now for the interesting part.

%post
( # Note that we run the entire %post section as a subshell for logging.

# Remember that nifty one-line command for the bootstrap script that we
# went through? This is an ideal place for it. And assuming that the
# script has been properly configured, it should prepare the system
# fully for usage of local Red Hat Network Servers.

wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash

# The following is an example of the usage of rhnreg_ks, the kickstart
# utility for rhn_register. This demonstrates the usage of the 
# --activationkey flag, which describes an activation key. For example,
# this activation key could be set up in the Web interface to join this 
# system to the "Laptops" group and the local Widgetco "Laptop Software" 
# channel. Note that this section applies only to Proxy users, as this 
# step is handled by the Satellite bootstrap script. 
#
# For more information about activation keys, consult the Red Hat Network
# Management Reference Guide.

/usr/sbin/rhnreg_ks --activationkey=6c933ea74b9b002f3ac7eb99619d3374

# End the subshell and capture any output to a post-install log file.
) 1>/root/post_install.log 2>&1

Приложение A. Пример сценария bootstrap.sh

Сценарий /var/www/html/pub/bootstrap/bootstrap.sh, который создается программой установки RHN Satellite, позволяет перенастроить системы клиентов для облегчения доступа к серверу RHN. По желанию его можно изменить, чтобы его можно было исполнять на всех машинах клиентов.
Глава 5, rhn-bootstrap содержит информацию о том, как подготовить сценарий к использованию.

#!/bin/bash
echo "RHN Server Client bootstrap script v3.6"

# This file was autogenerated. Minor manual editing of this script (and
# possibly the client-config-overrides.txt file) may be necessary to complete
# the bootstrap setup. Once customized, the bootstrap script can be triggered
# in one of two ways (the first is preferred):
#
#	 (1) centrally, from the RHN Server via ssh (i.e., from the
#			 RHN Server):
#				cd /var/www/html/pub/bootstrap/
#				cat bootstrap-<edited_name>.sh | ssh root@<client-hostname> /bin/bash
#
#	 ...or...
#
#	 (2) in a decentralized manner, executed on each client, via wget or curl:
#				wget -qO-
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash
#				 ...or...
#				curl -Sks
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash

# SECURITY NOTE:
#	 Use of these scripts via the two methods discussed is the most expedient
#	 way to register machines to your RHN Server. Since "wget" is used
#	 throughout the script to download various files, a "Man-in-the-middle"
#	 attack is theoretically possible.
#
#	 The actual registration process is performed securely via SSL, so the risk
#	 is minimized in a sense. This message merely serves as a warning.
#	 Administrators need to appropriately weigh their concern against the
#	 relative security of their internal network.

# PROVISIONING/KICKSTART NOTE:
#	 If provisioning a client, ensure the proper CA SSL public certificate is
#	 configured properly in the post section of your kickstart profiles (the
#	 RHN Satellite or hosted web user interface).

# UP2DATE/RHN_REGISTER VERSIONING NOTE:
#	 This script will not work with very old versions of up2date and
#	 rhn_register.


echo
echo
echo "MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED!"
echo
echo "If this bootstrap script was created during the initial installation"
echo "of an RHN Satellite, the ACTIVATION_KEYS, and ORG_GPG_KEY values will"
echo "probably *not* be set (see below). If this is the case, please do the"
echo "following:"
echo "	- copy this file to a name specific to its use."
echo "		(e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.)"
echo "	- on the website create an activation key or keys for the system(s) to"
echo "		be registered."
echo "	- edit the values of the VARIABLES below (in this script) as"
echo "		appropriate:"
echo "		- ACTIVATION_KEYS needs to reflect the activation key(s) value(s)"
echo "			from the website. XKEY or XKEY,YKEY"
echo "		- ORG_GPG_KEY needs to be set to the name of the corporate public"
echo "			GPG key filename (residing in /var/www/html/pub) if appropriate."
echo
echo "Verify that the script variable settings are correct:"
echo "		- CLIENT_OVERRIDES should be only set differently if a customized"
echo "			client-config-overrides-VER.txt file was created with a different"
echo "			name."
echo "		- ensure the value of HOSTNAME is correct."
echo "		- ensure the value of ORG_CA_CERT is correct."
echo
echo "Enable this script: comment (with #'s) this block (or, at least just"
echo "the exit below)"
echo
exit 1

# can be edited, but probably correct (unless created during initial install):
# NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine.
ACTIVATION_KEYS=insert_activation_key_here
ORG_GPG_KEY=insert_org_gpg_pub_key_here

# can be edited, but probably correct:
CLIENT_OVERRIDES=client-config-overrides.txt
HOSTNAME=your_rhn_server_host.example.com

ORG_CA_CERT=RHN-ORG-TRUSTED-SSL-CERT
ORG_CA_CERT_IS_RPM_YN=0

USING_SSL=1
USING_GPG=1

REGISTER_THIS_BOX=1

ALLOW_CONFIG_ACTIONS=0
ALLOW_REMOTE_COMMANDS=0

FULLY_UPDATE_THIS_BOX=1

#
# -----------------------------------------------------------------------------
# DO NOT EDIT BEYOND THIS POINT -----------------------------------------------
# -----------------------------------------------------------------------------
#

# an idea from Erich Morisse (of Red Hat).
# use either wget *or* curl
# Also check to see if the version on the 
# machine supports the insecure mode and format
# command accordingly.
if [ -x /usr/bin/wget ] ; then
		output=`/usr/bin/wget --no-check-certificate 2>&1`
		error=`echo $output | grep "unrecognized option"`
		if [ -z "$error" ] ; then
				FETCH="/usr/bin/wget -q -r -nd --no-check-certificate"
		else
				FETCH="/usr/bin/wget -q -r -nd"
		fi
		
else
		if [ -x /usr/bin/curl ] ; then
				output=`/usr/bin/curl -k 2>&1`
				error=`echo $output | grep "is unknown"`
				if [ -z "$error" ] ; then
						FETCH="/usr/bin/curl -SksO"
				else
						FETCH="/usr/bin/curl -SsO"
				fi
		fi
fi

HTTP_PUB_DIRECTORY=http://${HOSTNAME}/pub
HTTPS_PUB_DIRECTORY=https://${HOSTNAME}/pub
if [ $USING_SSL -eq 0 ] ; then
		HTTPS_PUB_DIRECTORY=${HTTP_PUB_DIRECTORY}
fi
echo
echo "UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES"
echo "-------------------------------------------------"
echo "* downloading necessary files"
echo "	client_config_update.py..."
rm -f client_config_update.py
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/client_config_update.py
echo "	${CLIENT_OVERRIDES}..."
rm -f ${CLIENT_OVERRIDES}
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/${CLIENT_OVERRIDES}

if [ ! -f "client_config_update.py" ] ; then
		echo "ERROR: client_config_update.py was not downloaded"
		exit 1
fi
if [ ! -f "${CLIENT_OVERRIDES}" ] ; then
		echo "ERROR: ${CLIENT_OVERRIDES} was not downloaded"
		exit 1
fi

echo "* running the update scripts"
if [ -f "/etc/sysconfig/rhn/rhn_register" ] ; then
		echo "	. rhn_register config file"
		/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/rhn_register \
		 ${CLIENT_OVERRIDES}
fi
echo "	. up2date config file"
/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/up2date \
 ${CLIENT_OVERRIDES}

if [ ! -z "$ORG_GPG_KEY" ] ; then 
		echo
		echo "* importing organizational GPG key"
		rm -f ${ORG_GPG_KEY}
		$FETCH ${HTTPS_PUB_DIRECTORY}/${ORG_GPG_KEY}
		# get the major version of up2date
		res=$(rpm -q --queryformat '%{version}' up2date | sed -e 's/\..*//g')
		if [ $res -eq 2 ] ; then
				gpg $(up2date --gpg-flags) --import $ORG_GPG_KEY
		else
				rpm --import $ORG_GPG_KEY
		fi
fi

echo
echo "* attempting to install corporate public CA cert"
if [ $USING_SSL -eq 1 ] ; then
		if [ $ORG_CA_CERT_IS_RPM_YN -eq 1 ] ; then
				rpm -Uvh ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
		else
				rm -f ${ORG_CA_CERT}
				$FETCH ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
				mv ${ORG_CA_CERT} /usr/share/rhn/
		fi
fi

echo
echo "REGISTRATION"
echo "------------"
# Should have created an activation key or keys on the RHN Server's
# website and edited the value of ACTIVATION_KEYS above.
#
# If you require use of several different activation keys, copy this file and
# change the string as needed.
#
if [ -z "$ACTIVATION_KEYS" ] ; then
		echo "*** ERROR: in order to bootstrap RHN clients, an activation key or keys"
		echo "			must be created in the RHN web user interface, and the"
		echo "			corresponding key or keys string (XKEY,YKEY,...) must be mapped to"
		echo "			the ACTIVATION_KEYS variable of this script."
		exit 1
fi

if [ $REGISTER_THIS_BOX -eq 1 ] ; then
		echo "* registering"
		/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS"
		echo
		echo "*** this system should now be registered, please verify ***"
		echo
else
		echo "* explicitely not registering"
fi

echo
echo "OTHER ACTIONS"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "up2date up2date; up2date -p; up2date -uf (conditional)"
else
		echo "up2date up2date; up2date -p"
fi
echo "but any post configuration action can be added here.	"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "* completely updating the box"
else
		echo "* ensuring up2date itself is updated"
fi
/usr/sbin/up2date up2date
/usr/sbin/up2date -p
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		/usr/sbin/up2date -uf
fi
echo "-bootstrap complete-"

Приложение B. История изменений

История переиздания
Издание 1-2.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Издание 1-22012-07-18Anthony Towns
Rebuild for Publican 3.0
Издание 1-7Fri Feb 27 2009

Предметный указатель

Символы

--configure
использование, Параметр up2date --configure
агент обновлений Red Hat
настройка для взаимодействия с RHN Proxy и Satellite, Обновление файлов конфигурации вручную
апплет уведомлений RHN
настройка для Satellite, Настройка уведомлений RHN для Satellite
кикстарт
использование, Реализация кикстарта
ключи GPG
импорт, Импортирование ключей GPG
ключи активации
регистрация, Регистрация с помощью ключей активации
конфигурация
восстановление сервера, Восстановление сервера после сбоя
ручная, Обновление файлов конфигурации вручную
настройка
сценарий, Создание сценария вручную
настройка клиента
агент обновлений , Параметр up2date --configure
приложения клиентов
настройка, Настройка приложений клиентов
установка, Установка последних версий пакетов клиентов Red Hat Network
программа поддержки SSL
rhn-ssl-tool , rhn-ssl-tool
генерация, Генерация SSL
генерация сертификата сервера, Создание наборов ключей SSL для веб-сервера
сертификаты SSL
генерация, rhn-ssl-tool
настройка, Настройка клиентов
установка, Установка открытых сертификатов CA в системах клиентов

B

bootstrap.sh
подготовка и использование, rhn-bootstrap
пример файла, Пример сценария bootstrap.sh

R

rhn-bootstrap
выполнение сценария, Вызов сценария
генерация сценария, Генерация
использование, rhn-bootstrap
параметры командной строки, Параметры rhn-bootstrap
подготовка, Подготовка
rhn-ssl-tool
RHN SSL Maintenance Tool , rhn-ssl-tool
генерация, Генерация SSL
генерация CA, Создание пары ключей SSL CA
генерация сертификата сервера, Создание наборов ключей SSL для веб-сервера
параметры, Параметры rhn-ssl-tool
создание CA, Создание пары ключей SSL CA

S

SSL
введение, Краткий обзор SSL

Юридическое уведомление

Copyright © 2010 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.