Red Hat Network
Satellite 5.4
Guia de Configuração
do Cliente
Red Hat Network Satellite
Guia de Configuração do Cliente
Red Hat Network Satellite 5.4 Guia de Configuração do Cliente
Red Hat Network Satellite
Edição 1
Copyright © 2010 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available
at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this
document or an adaptation of it, you must provide the URL for the original version.
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, MetaMatrix, 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.
All other trademarks are the property of their respective owners.
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
Bem vindo ao Guia de Configuração do Red Hat Network Satellite Client
1. Introdução
1
2. Aplicações Cliente
2.1. Empregando os RPMs Cliente Mais Recentes da Red Hat Network .................................
2.2. Configurando as Aplicações Cliente ..............................................................................
2.2.1. Registrando com Chaves de Ativação ................................................................
2.2.2. Usando a Opção up2date --configure ........................................................
2.2.3. Atualizando os Arquivos de Configuração Manualmente ......................................
2.2.4. Implementando a Transferência (failover) de Servidores ......................................
2.3. O Applet do Atualizador de Pacotes ..............................................................................
2.4. Configurando a Red Hat Network Alert Notification Tool com Satellite ..........................
3
3
4
4
5
6
7
7
8
3. Infra-estrutura da SSL
9
3.1. Uma Breve Introdução à SSL ....................................................................................... 9
3.2. A RHN SSL Maintenance Tool .................................................................................. 10
3.2.1. Geração da SSL Explicada .............................................................................. 11
3.2.2. Opções da RHN SSL Maintenance Tool .......................................................... 12
3.2.3. Gerando o Par de Chaves SSL da Autoridade Certificadora (Certificate
Authority) .................................................................................................................. 15
3.2.4. Gerando Conjuntos de Chaves SSL do Servidor Web ........................................ 16
3.3. Empregando o Certificado Público SSL da CA nos Clientes .......................................... 17
3.4. Configurando Sistemas Cliente ................................................................................... 17
4. Importando Chaves Padronizadas GPG
19
5. Usando o RHN Bootstrap
5.1. Preparação ................................................................................................................
5.2. Geração .....................................................................................................................
5.3. Uso do Script .............................................................................................................
5.4. Opções do RHN Bootstrap ........................................................................................
21
21
22
23
23
6. Escrevendo o script da configuração manualmente
27
7. Implementar o Kickstart
29
A. Script de Amostra de Bootstrap
31
B. Histórico de Revisão
35
Índice Remissivo
37
iii
iv
Introdução
Este guia de melhores práticas pretende ajudar os clientes de RHN Satellite Server e RHN Proxy
Server a configurar seus sistemas cliente de maneira mais fácil.
Por padrão, todos os aplicativos de cliente do Red Hat Network são configurados para se
comunicarem com os servidores centrais do Red Hat Network, mas se ao invés disto, os clientes
forem conectados ao RHN Satellite Server e RHN Proxy Server, muitas destas configurações serão
alteradas. Alterar as configurações do cliente em um sistema ou dois pode ser relativamente simples.
Um ambiente empresarial amplo, que contenha milhares de sistemas, se beneficiará com os passos
da reconfiguração em massa, descritos aqui.
Devido à complexidade desta tarefa, os clientes podem usar um script pré-definido que automatiza
muitas destas tarefas necessárias para acessar seus servidores Satellite ou Proxy. Consulte a
Capítulo 5, Usando o RHN Bootstrap para maiores detalhes. A Red Hat acredita ser importante
estar ciente das implicações que estas mudanças acarretam e portanto descreve passo a passo para
a reconfiguração, nos capítulos seguintes. Determine você mesmo qual a solução ideal para sua
empresa.
Embora muitos dos comandos fornecidos neste guia serem aplicáveis da maneira como são
apresentados, é impossível prever todas as configurações de rede possíveis, adotadas pelos clientes.
Portanto, a Red Hat o incentiva a usar estes comandos como referências, levando em consideração
as configurações individuais da sua empresa.
Nota
As informações de configuração do cliente Unix podem ser encontradas no RHN Satellite Server
Reference Guide no capítulo Unix Support.
1
2
Aplicações Cliente
Para poder utilizar a maioria das funcionalidades da Red Hat Network, como por exemplo registrarse em um Satellite, é necessária a configuração das aplicações cliente mais recentes. Pode ser
difícil obter estas aplicações antes do cliente estar registrado na Red Hat Network. Este paradoxo é
especialmente problemático para clientes migrando uma grande quantidade de sistemas mais antigos
para a Red Hat Network. Este capítulo aborda as técnicas para resolver este dilema.
Importante
A Red Hat recomenda que os clientes conectados a um RHN Proxy Server ou RHN Satellite
Server estejam rodando a versão mais recente do Red Hat Enterprise Linux para garantir a
conectividade apropriada.
Além disso, caso os firewalls de cliente sejam configurados, as portas 80 e 443 devem ser
abertas para funcionarem adequadamente com o Red Hat Network.
2.1. Empregando os RPMs Cliente Mais Recentes da Red
Hat Network
O Package Updater (pup), e Red Hat Network Registration Client (rhn_register) no Red Hat
Enterprise Linux 5 (up2date em versões anteriores do Red Hat Enterprise Linux) são pré-requisitos
para usar a maioria das funcionalidades corporativas da Red Hat Network. É crucial instalá-las
nos sistemas cliente antes de tentar usar o RHN Proxy Server ou o RHN Satellite Server em seu
ambiente.
Há diversas estratégias para esta atualização do software cliente da RHN. Uma delas envolve
armazenar os RPMs numa localidade acessível a todos os sistemas cliente e empregar os pacotes
com o comando mais simples possível. Em praticamente todos os casos, não é necessário executar
uma implementação manual do yum, pup, e rhn_register (up2date no caso de versões
anteriores do Red Hat Enterprise Linux). Estas ferramentas cliente não devem apresentar problemas
ao conectar a seu ambiente Satellite ou Proxy da RHN. A discussão abaixo assume que o yum
imediato, pup, e rhn_register (ou up2date) não são os mais recentes e não funcionam em seu
ambiente.
Lembre-se: somente os sistemas rodando Red Hat Enterprise Linux 5 devem estar registrado com
o RHN no firstboot depois da instalação ou usar o rhn_register. Os sistemas rodando Red Hat
Enterprise Linux 3 e 4 podem usar a funcionalidade de registro integrada ao Red Hat Update Agent.
This document presumes that the customer has installed at least one RHN Satellite Server and/or
RHN Proxy Server on their network. The example below demonstrates a simple approach of deploying
yum, pup, and rhn_register (or up2date) for the first time by an administrator assuming the
machines don't already have a working RHN. The administrator has populated the /var/www/html/
pub/ directory with a copy of the yum, pup, and rhn_register (or up2date) RPMs that the client
systems need, and then has simply deployed those RPMs onto the client systems with a simple
rpm -Uvh command. Run from a client, this command installs the RPMs to that client, assuming
the domain name, paths, and RPM versions are correct (note that this command has been split into
multiple lines for print and PDF purposes but should be typed as one line at a shell prompt):
rpm -Uvh
http://your_proxy_or_sat.your_domain.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
3
Capítulo 2. Aplicações Cliente
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
Tenha em mente que a arquitetura (neste caso, i386) talvez precise ser alterada, dependendo dos
sistemas a servir.
2.2. Configurando as Aplicações Cliente
Nem todo cliente precisa ter uma conexão segura ao RHN Satellite Server ou RHN Proxy Server
em sua empresa. Nem todo cliente precisa criar e empregar uma chave GPG para pacotes
personalizados. (Ambos tópicos são abordados em detalhes posteriormente.) Todos os clientes
que usam o RHN Satellite Server ou o RHN Proxy Server devem reconfigurar o Red Hat Update
Agent (up2date) e possivelmente o Red Hat Network Registration Client (rhn_register) para
redirecioná-lo(s) da Red Hat Network para seu RHN Satellite Server ou RHN Proxy Server.
Importante
Apesar disto não ser configurável, note que a porta usada pelo up2date é 80 para HTTP e 443
para HTTP seguro (HTTP). Por default, o yum no Red Hat Enterprise Linux 5 usa somente SSL.
Por este motivo, os usuários devem garantir que seus firewalls permitam conexões através
da porta 443. Para ignorar a SSL, altere o protocolo da serverURL, de https para http
no arquivo /etc/sysconfig/rhn/up2date. Da mesma forma, para usar a funcionalidade
Monitoring da RHN e as detecções requerendo o Red Hat Network Monitoring Daemon, note que
os sistemas cliente devem permitir conexões na porta 4545 (ou na porta 22, se usar sshd).
Por default, o rhn_register e up2date referem aos Servidores principais da Red Hat Network. Os
usuários devem reconfigurar os sistemas cliente para referirem ao seu RHN Satellite Server ou RHN
Proxy Server.
Note that the latest versions of the Red Hat Update Agent can be configured to accommodate
several RHN Servers, thereby providing failover protection in case the primary server is inaccessible.
Refer to Seção 2.2.4, “Implementando a Transferência (failover) de Servidores” for instructions on
enabling this feature.
The next sections describe different methods of configuring the client systems to access your RHN
Satellite Server or RHN Proxy Server. To see how virtually all reconfiguration can be scripted, see
Capítulo 6, Escrevendo o script da configuração manualmente .
2.2.1. Registrando com Chaves de Ativação
A Red Hat recomenda usar as chaves de ativação para registrar e configurar sistemas cliente
que acessam o RHN Proxy Server ou o RHN Satellite Server. As chaves de ativação podem ser
usadas para registrar, atribuir serviços e registrar sistemas em massa. Consulte a seção "Chaves de
Ativação" no Guia de Referência do RHN Satellite Server para instruções sobre uso.
O registro com uma chave de ativação tem quatro passos básicos:
1. Gerar uma Chave de Ativação
2. Importar chaves GPG personalizadas.
3. Fazer o download e instalar o RPM do Certificado SSL do diretório /pub/ do RHN Proxy Server
ou RHN Satellite Server. O comando para este passo pode se parecer com o seguinte:
4
Usando a Opção up2date --configure
rpm -Uvh http://your-satellite-FQDN/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
4. Registrar o sistema em seu RHN Proxy Server ou RHN Satellite Server. O comando para este
passo pode se parecer com:
rhnreg_ks --activationkey mykey --serverUrl https://your-satellite-FQDN/XMLRPC
Alternatively, most of the above steps can be combined in a shell script that includes the following
lines (note that this command has been split into multiple lines for print and PDF purposes but should
be typed as one line at a shell prompt).
wget -0 - http://your-satellite-FQDN/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://your-satellite-FQDN/XMLRPC
The bootstrap script, generated at installation and available for both RHN Satellite Server and RHN
Proxy Server, is such a script. The script and the RHN Bootstrap that generates it are discussed in
detail in Capítulo 5, Usando o RHN Bootstrap.
Atenção
Os sistemas rodando Red Hat Enterprise Linux 2.1 e as versões do Red Hat Linux anteriores
à 8.0 podem ter problemas para usar as Chaves de Ativação na migração da configuração
do certificado SSL do rhn_register e do up2date. Consequentemente, as informações
do certificado SSL nestes sistemas devem ser definidas manualmente. Todas as outras
configurações, tal como a URL do servidor, são transferidas corretamente.
2.2.2. Usando a Opção up2date --configure
O Red Hat Update Agent distribuídos com o Red Hat Enterprise Linux 3 e 4, oferecem interfaces
para configurações diversas. Para obter uma lista completa destas configurações, consulte a página
man do up2date (man up2date na linha de comando).
Para reconfigurar o Red Hat Update Agent, invoque o seguinte comando como root:
up2date --configure
Você verá uma caixa de diálogo oferecendo várias opções que podem ser reconfiguradas.
Na aba Geral, sob Selecionar um Servidor da Red Hat Network para usar,
substitua o valor default pelo nome de domínio totalmente qualificado (fully qualified
domain name, FQDN) do RHN Satellite Server ou RHN Proxy Server, tal como https://
your_proxy_or_sat.your_domain.com/XMLRPC. Mantenha /XMLRPC no final. Quanto terminar,
clique em OK.
5
Capítulo 2. Aplicações Cliente
Figura 2.1. Configuração Gráfica do Red Hat Update Agent
Make sure you enter the domain name of your RHN Satellite Server or RHN Proxy Server correctly.
Entering an incorrect domain or leaving the field blank may prevent up2date --configure
from launching. This may be resolved, however, by editing the value in the up2date configuration
file. Refer to Seção 2.2.3, “Atualizando os Arquivos de Configuração Manualmente” for precise
instructions.
Atenção
Os sistemas rodando Red Hat Enterprise Linux 3 ou 4 têm a funcionalidade de registro embutida
no Red Hat Update Agent e portanto não precisam instalar o Red Hat Network Registration
Client. Os sistemas rodando Red Hat Enterprise Linux 5 não utilizam o up2date, e precisam do
rhn_register para registrar seus sistemas no RHN ou Satellite e do yum e pup para atualizar
seus pacotes.
2.2.3. Atualizando os Arquivos de Configuração Manualmente
Como alternativa à interface GUI descrita na seção anterior, os usuários também podem reconfigurar
o Red Hat Update Agent editando os arquivos de configuração da aplicação.
Para configurar o Red Hat Update Agent nos sistemas cliente conectando ao RHN Proxy Server
ou ao RHN Satellite Server, edite os valores serverURL e noSSLServerURL no arquivo de
configuração /etc/sysconfig/rhn/up2date (como root). Substitua a URL default da Red Hat
Network pelo nome de domínio totalmente qualificado (fully qualified domain name, FQDN) do RHN
Proxy Server ou RHN Satellite Server. Por exemplo:
6
Implementando a Transferência (failover) de Servidores
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
Atenção
A configuração httpProxy em /etc/sysconfig/rhn/up2date não refere-se ao RHN
Proxy Server. É usada para configurar um proxy HTTP opcional para o cliente. Tendo um RHN
Proxy Server, a configuração de httpProxy deve ser deixada em branco (sem nenhum valor
determinado).
2.2.4. Implementando a Transferência (failover) de Servidores
A partir do up2date-4.2.38, o Red Hat Update Agent pode ser configurado para procurar
atualizações em diversos Servidores da RHN. Isto pode ser muito útil na manutenção de atualizações
constantes, caso seu RHN Proxy Server ou RHN Satellite Server principal sofra uma queda e fique
offline.
Para usar esta funcionalidade, primeiro certifique-se de rodar a versão requisitada do
up2date. Então, adicione manualmente os servidores secundários nas opções serverURL e
noSSLServerURL do arquivo de configuração /etc/sysconfig/rhn/up2date (como root).
Adicione os nomes de domínio totalmente qualificados (fully qualified domain names, FQDN) do Proxy
ou Satellite imediatamene após o servidor primário, separados por uma semi-vírgula (;). Por exemplo:
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;
A conexão aos servidores é tentada na ordem provida aqui. Você pode incluir quantos servidores
desejar. Pode, inclusive, listar os Servidores centrais da RHN. Porém, isto só faz sentido se os
sistemas cliente puderem acessar a Internet.
2.3. O Applet do Atualizador de Pacotes
O Red Hat Enterprise Linux 5 apresenta um programa de execução no painel gráfico do desktop, que
verifica periodicamente atualizações do servidor RHN ou Satellite e irá alertar usuários quando uma
nova atualização estiver disponível.
7
Capítulo 2. Aplicações Cliente
Figura 2.2. Applet do Atualizador de Pacotes
O Applet de Atualizador de Pacotes na bandeja de notificações do painel do desktop, verifica se
há atualizações periodicamente. O applet também permite que você realize algumas tarefas de
manutenção de pacotes a partir do applet, clicando no ícone de notificação e escolhendo a partir das
seguintes ações:
• Atualização - Verifique o RHN ou Satellite para novas atualizações
• Visualização de Atualizações - lança o aplicativo do Atualizador de Pacotes para que você possa
ver se há alguma atualização disponível em mais detalhes e configure as atualizações em suas
especificações.
• Aplicação de Atualizações - Download e Instalação de todos os pacotes atualizados.
• Fechar - Fechar o applet
2.4. Configurando a Red Hat Network Alert Notification Tool
com Satellite
A Red Hat Network Alert Notification Tool, o ícone redondo no painel de sua área de trabalho Red
Hat Enterprise Linux 3 ou 4, pode ser configurado nos sistemas rodando Red Hat Enterprise Linux 3
ou mais recente a fim de reconhecer as atualizações disponíveis nos canais personalizados de seu
RHN Satellite Server. Você deve garantir que seu RHN Satellite Server seja configurado para suportar
esta funcionalidade. (O RHN Proxy Server suporta o applet sem modificar o cliente ou servidor.) Os
passos para configurar a Red Hat Network Alert Notification Tool são:
1. Garanta que seu RHN Satellite Server seja da versão 3.4 ou mais recente e que você tenha o
pacote rhns-applet instalado no Satellite. O pacote pode ser encontrado no canal de software
do Satellite RHN para as versões 3.4 e mais novas.
2. Obtenha o pacote rhn-applet-actions com up2date ou através do canal de software
Ferramentas da Red Hat Network (tools). Instale o pacote em todos os sistemas cliente Red Hat
Enterprise Linux 3 e mais novos a fim de ser notificado das atualizações personalizadas com a
Red Hat Network Alert Notification Tool. Os sistemas cliente devem ter os níveis de serviço
Management ou Provisioning.
3. No site da RHN, na versão do Satellite, navegue para a página Detalhes do Sistema de cada
sistema e clique no link da área Applet da RHN para redirecionar a Red Hat Network Alert
Notification Tool para o Satellite.
Na próxima vez que o applet for iniciado, aplicará sua nova configuração e conectará ao RHN
Satellite Server para obter atualizações.
8
Infra-estrutura da SSL
Para os clientes da Red Hat Network, as questões de segurança são de suma importância. Uma
das vantagens da Red Hat Network é sua habilidade em processar cada um dos pedidos através da
Secure Sockets Layer, ou SSL. Para manter este nível de segurança, os clientes que instalarem a
Red Hat Network em suas infra-estruturas devem gerar chaves e certificados SSL personalizados.
É possível criar e empregar chaves e certificados SSL manualmente. Ambos, o RHN Proxy Server
e o RHN Satellite Server, permitem a você criar suas próprias chaves e certificados SSL baseados
na sua CA (Autoridade Certificadora) durante a instalação. Além disso, há um outro utilitário de linha
de comando, RHN SSL Maintenance Tool, para este propósito. Independente do método escolhido,
estas chaves e certificados devem ser empregados a todos os sistemas de sua infra-estrutura
administrada. Em muitos casos, o emprego destas chaves e certificados SSL é automatizado. Este
capítulo descreve os métodos eficazes para conduzir todas estas tarefas.
Por favor note que este capítulo não aborda a SSL com profundidade. A RHN SSL Maintenance
Tool foi desenvolvida para ocultar grande parte da complexidade envolvida na configuração e
manutenção desta infra-estrutura de chave pública (public-key infrastructure, PKI). Para mais
informações, por favor consulte alguma das diversas referências disponíveis na livraria mais próxima.
3.1. Uma Breve Introdução à SSL
A SSL, ou Secure Sockets Layer, é um protocolo que possibilita às aplicações cliente-servidor
passar informações com segurança. A SSL usa um sistema de pares de chaves pública e privada
para criptografar a comunicação entre clientes e servidores. Os certificados públicos podem estar
acessíveis, enquanto as chaves privadas devem estar protegidas. É a relação matemática (uma
assinatura digital) entre uma chave privada e seu certificado público par que tornam este sistema
funcional. Através desta relação, é estabelecida uma conexão de confiança.
Nota
Ao longo deste documento abordamos as chaves privadas e os certificados públicos da SSL.
Tecnicamente, ambos podem ser referenciados como chaves (chaves públicas e privadas).
Mas, ao abordar a SSL, é convencionado referir à metade pública de um par de chaves SSL (ou
conjunto de chaves) como o certificado SSL público.
A infra-estrutura da SSL de uma empresa geralmente é composta destas chaves e certificados SSL:
• Chave privada e certificado público SSL da CA (Autoridade Certificadora) — em geral, é gerado
somente um conjunto por empresa. O certificado público é assinado digitalmente por sua chave
privada. O certificado público é distribuído para todos os sistemas.
• Chave privada e certificado público SSL do servidor Web — um conjunto por servidor de
aplicações. O certificado público é assinado digitalmente por ambos, sua chave privada e a chave
privada SSL da CA. Frequentemente, referenciamos um conjunto de chaves do servidor Web,
devido a existência de um pedido de certificado SSL intermediário que é gerado. Seus detalhes de
uso não são importantes nesta abordagem. Todos os três são empregados num Servidor da RHN.
Eis aqui um cenário: se você possui um RHN Satellite Server e cinco Servidores Proxy da RHN,
gerará um par de chaves SSL da CA e seis conjuntos de chaves SSL do servidor Web. O certificado
público SSL da CA é distribuído a todos os sistemas e usado por todos os clientes para estabelecer
uma conexão aos seus respectivos servidores. Cada servidor possui seu próprio conjunto de chaves
9
Capítulo 3. Infra-estrutura da SSL
SSL, especificamente ligado ao nome da máquina deste servidor e gerado usando suas próprias
chave privada SSL e chave pública SSL da CA combinadas. Assim, é estabelecida uma associação
digitalmente verificável do certificado público SSL e o par de chaves SSL da CA com a chave privada
do servidor. A chave do servidor Web não pode ser compartilhada com outros servidores web.
Importante
A parte mais crítica deste sistema é o par de chaves SSL da CA. A partir desta chave privada
e certificado público, um administrador pode gerar qualquer conjnto de chaves SSL do servidor
Web. Este conjunto de chaves SSL da CA deve estar protegido. Após toda a infra-estrutura de
servidores da RHN estar configurada e operante, é altamente recomendado arquivar o diretório
de criação SSL gerado por esta ferramenta e/ou pelos instaladores numa mídia separada, anotar
a senha da CA e proteger a mídia e a senha num local seguro.
3.2. A RHN SSL Maintenance Tool
A Red Hat Network oferece uma ferramenta de linha de comando para facilitar a administração
de sua infra-estrutura protegida: a RHN SSL Maintenance Tool, comumente conhecida por
seu comando rhn-ssl-tool. Esta ferramenta é disponibilizada como parte do pacote rhnscerts-tools. Este pacote pode ser encontrado nos canais de software do RHN Proxy Server
e RHN Satellite Server mais recentes (assim como na ISO do RHN Satellite Server). A RHN SSL
Maintenance Tool possibilita a você gerar seu próprio conjunto de chaves SSL da Autoridade
Certificadora, assim como os conjuntos de chaves SSL do servidor Web (por vezes chamados de
pares de chaves).
Esta é somente uma ferramenta de criação que gera todas as chaves e certificados SSL necessários.
Também empacota os arquivos no formato RPM para rápida distribuição e instalação em todas as
máquinas cliente. Porém, não as implementa. Esta parte é deixada ao administrador, ou em muitos
casos, é automatizada pelo RHN Satellite Server.
Nota
O rhns-certs-tools, que contém a rhn-ssl-tool, pode ser instalado e executado em
qualquer sistema Red Hat Enterprise Linux corrente com requisitos mínimos. Esta é uma
conveniência para administradores que desejam administrar suas infra-estruturas SSL a partir de
seus computadores ou através de outro sistema além de seu(s) Servidor(es) da RHN.
Aqui estão os casos nos quais a ferramenta é necessária:
• Ao atualizar seu certificado público SSL - isto é raro.
• Ao instalar um RHN Proxy Server versão 3.6 ou mais recente que conecta aos Servidores centrais
da RHN como seu serviço principal - o serviço hospedado não pode ser um repositório de sua
chave e certificado SSL da CA por motivos de segurança, já que são informações particulares de
sua empresa.
• Ao reconfigurar sua infra-estrutura RHN para usar SSL quando previamente não o fazia.
• Ao adicionar Servidores Proxy de versões anteriores à 3.6 em sua infra-estrutura RHN.
• Ao adicionar RHN Satellite Servers múltiplos à sua infra-estrutura RHN - consulte um representante
da Red Hat para instruções sobre esta questão.
10
Geração da SSL Explicada
Aqui estão os casos nos quais a ferramenta não é necessária:
• Durante a instalação de um RHN Satellite Server - todas as configurações da SSL são definidas
durante o processo de instalação. As chaves e certificado SSL são criados e empregados
automaticamente.
• Durante a instalação de um RHN Proxy Server versão 3.6 ou mais recente se conectado a um RHN
Satellite Server versão 3.6 ou mais recente como seu serviço principal - o RHN Satellite Server
contém todas as informações necessárias da SSL para configurar, criar e empregar as chaves e
certificados SSL do RHN Proxy Server.
Os procedimentos de instalação do RHN Satellite Server e do RHN Proxy Server garantem que o
certificado público SSL da CA seja empregado no diretório /pub de cada servidor. Este certificado
público é usado pelos sistemas cliente para conectar ao Servidor da RHN. Consulte a Seção 3.3,
“Empregando o Certificado Público SSL da CA nos Clientes” para mais informações.
Em suma, se a infra-estrutura RHN da sua empresa empregar a última versão do RHN Satellite
Server como o serviço principal, provavelmente não será necessário usar a ferramenta. Caso
contrário, recomendamos se familiarizar com seu uso.
3.2.1. Geração da SSL Explicada
Os principais benefícios de usar a RHN SSL Maintenance Tool são segurança, flexibilidade e
portabilidade. A segurança é oferecida pela criação de chaves e certificados SSL do servidor
Web distintos para cada servidor da RHN; todos assinados por um único par de chaves SSL da
Autoridade Certificadora SSL criado pela sua empresa. A flexibilidade é oferecida pela habilidade da
ferramenta em executar em qualquer máquina que tenha o pacote rhns-certs-tools instalado.
A portabilidade reside numa estrutura criada, que pode ser armazenada em qualquer lugar para sua
proteção, e então instalada onde a necessidade surgir.
Novamente: se o Servidor RHN principal de sua infra-estrutura RHN é o RHN Satellite Server mais
recente, o máximo que você precisa fazer é recuperar sua árvore ssl-build de um arquivo para o
diretório /root e utilizar as ferramentas de configuração providas no site do RHN Satellite Server.
Para utilizar a RHN SSL Maintenance Tool da melhor maneira possível, complete as seguintes
tarefas relativamente nesta ordem. Consulte as seções remanescentes para mais detalhes:
1. Instale o pacote rhns-certs-tools num sistema de sua empresa. Talvez, mas não
necessariamente, num RHN Satellite Server ou num RHN Proxy Server.
2. Crie um par de chaves SSL da Autoridade Certificadora para sua empresa e instale o RPM ou o
certificado público resultante em todos os sistemas cliente.
3. Crie um conjunto de chaves SSL do servidor Web para cada um dos Proxies e Satellites a serem
empregados e instale os RPMs resultantes nos Servidores da RHN, reiniciando o serviço httpd
em seguida:
/sbin/service httpd restart
4. Arquive a árvore de criação (build tree) da SSL - consistindo do diretório de criação principal
e todos os sub-diretórios e arquivos - numa mídia removível, como um disquete (floppy). (Os
requisitos de espaço em disco são insignificantes.)
5. Verifique e então armazene aquele arquivo numa localidade segura, como a descrita para
backups nas seções Requisitos Adicionais dos guias de instalação do Proxy ou do Satellite.
11
Capítulo 3. Infra-estrutura da SSL
6. Memorize e proteja a senha da CA para uso futuro.
7. Remova a árvore de criação do sistema de criação por razões de segurança, mas somente
quando toda a infra-estrutura RHN estiver pronta e configurada.
8. Quando forem necessários conjuntos adicionais de chaves SSL de servidor Web, recupere a
árvore de criação num sistema rodando a RHN SSL Maintenance Tool e repita os passos 3 a 7.
3.2.2. Opções da RHN SSL Maintenance Tool
A RHN SSL Maintenance Tool oferece uma grande variedade de opções de linha de comando para
gerar seu conjunto de chaves SSL da Autoridade Certificadora e administrar os certificados e chaves
SSL do seu servidor. A princípio, a ferramenta oferece três listas de ajuda para as opções na linha
de comando: rhn-ssl-tool --help (geral), rhn-ssl-tool --gen-ca --help (Autoridade
Certificadora) e rhn-ssl-tool --gen-server --help (Servidor Web). A página man da rhn-ssltool também é bastante detalhada e útil: man rhn-ssl-tool.
As duas tabelas abaixo dividem as opções de acordo com a tarefa relacionada; a geração de
conjuntos de chaves SSL do servidor Web ou da CA.
Este conjunto de opções deve ser precedido pelo argumento --gen-ca:
Tabela 3.1. Opções da SSL da Autoridade Certificadora (CA) (rhn-ssl-tool --gen-ca --help)
Opção
Descrição
--gen-ca
Gera um par de chaves e RPM público
da Autoridade Certificadora (CA). Este
deve ser invocado com qualquer uma das
opções remanescentes nesta tabela.
-h, --help
Apresenta a tela de ajuda com uma
lista de opções básicas específicas
para a geração e administração de uma
Autoridade Certificadora (Certificate
Authority).
-f, --force
Criar forçadamente uma nova chave
privada e/ou certificado público da CA.
-p=, --password=SENHA
A senha da CA. Você deverá especificá-la,
caso ainda não o tenha feito. Grave-a de
forma segura.
-d=, --dir=DIRETÓRIO_CRIAÇÃO
Requisitado para a maioria dos comandos
- O diretório no qual os certificados e
RPMs são criados. O default é ./sslbuild.
--ca-key=FILENAME
O nome do arquivo da chave privada da
CA. O default é RHN-ORG-PRIVATESSL-KEY.
--ca-cert=FILENAME
O nome do arquivo do certificado público
da CA. O default é RHN-ORG-TRUSTEDSSL-CERT.
--cert-expiration=CA_CERT_EXPIRE
A data de expiração do certificado público
da CA. O default é o número de dias até
a véspera da data de transição (epoch
rollover ou 18-01-2038)
12
Opções da RHN SSL Maintenance Tool
Opção
Descrição
--set-country=COUNTRY_CODE
A código de duas letras do país. O defaul
é US.
--set-state=STATE_OR_PROVINCE
O estado ou província da CA. O default é
''.
--set-city=CITY_OR_LOCALITY
A cidade ou localidade. O default é ''.
--set-org=ORGANIZATION
A empresa ou corporação, como Red Hat.
O default é Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT
A unidade da empresa, como RHN. O
default é ''.
--set-common-name=HOSTNAME
Não é tipicamente definido para a CA. - O
nome comum.
--set-email=EMAIL
Não é tipicamente definido para a CA. - O
endereço de e-mail.
--rpm-packager=PACKAGER
Empacotador do RPM gerado,
tal como "Admin da RHN ([email protected])."
--rpm-vendor=VENDOR
Distribuidor do RPM gerado, tal como
"Exemplo TI Corp."
-v, --verbose
Apresenta mensagem verbosa.
Acumulativa - adicionar "v"s resulta em
mais detalhes.
--ca-cert-rpm=CA_CERT_RPM
Raramente alterado - nome do RPM que
armazena o certificado da CA (o nome
de arquivo base, não o filename-versionrelease.noarch.rpm).
--key-only
Raramante usada - Gera somente uma
chave privada da CA. Reveja --genca --key-only --help para mais
informações.
--cert-only
Rarament usada - Gera somente o
certificado público da CA. Reveja --genca --cert-only --help para mais
informações.
--rpm-only
Raramente usada - Gera somente um
RPM para ser empregado. Reveja --genca --rpm-only --help para mais
informações.
--no-rpm
Raramante usada - Conduz todos os
passos relacionados à CA exceto a
geração do RPM.
O conjunto de opções a seguir deve ser precedido pelo argumento --gen-server:
Tabela 3.2. Opções SSL do Servidor Web (rhn-ssl-tool --gen-server --help)
Opção
Descrição
--gen-server
Gera o conjunto de chaves, o RPM e o
arquivo tar da SSL do servidor Web.
13
Capítulo 3. Infra-estrutura da SSL
Opção
Descrição
-h, --help
Apresenta a tela de ajuda com uma
lista de opções base, específicas para a
geração e administração de um par de
chaves de servidor.
-p=, --password=SENHA
A senha da CA. Você deverá especificá-la,
caso ainda não o tenha feito. Grave-a de
forma segura.
-d=, --dir=DIRETÓRIO_CRIAÇÃO
Requisitado para a maioria dos comandos
- O diretório no qual os certificados e
RPMs são criados. O default é ./sslbuild.
--server-key=FILENAME
O nome do arquivo da chave privada
SSL do servidor Web. O default é
server.key.
--server-cert-req=FILENAME
O nome do arquivo do pedido do
certificado SSL do servidor Web. O default
é server.csr.
--server-cert=FILENAME
O nome do arquivo do certificado SSL do
servidor Web. O default é server.crt.
--startdate=YYMMDDHHMMSSZ
A data inicial da validade do certificado
do servidor no formato do exemplo: ano,
mês, dia do mês, hora, minuto, segundo
(dois caracteres por valor). Z é de Zulu e é
necessário. O default é uma semana antes
da geração.
--cert-expiration=SERVER_CERT_EXPIRE
A data de expiração do certificado do
servidor. O default é o número de dias até
a véspera da transição (epoch rollover ou
18-01-2038).
--set-country=COUNTRY_CODE
A código de duas letras do país. O defaul
é US.
--set-state=STATE_OR_PROVINCE
O estado ou a província. O default é North
Carolina.
--set-city=CITY_OR_LOCALITY
A cidade ou localidade. O default é
Raleigh.
--set-org=ORGANIZATION
A empresa ou corporação, tal como Red
Hat. O default é Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT
A unidade da empresa, tal como RHN. O
default é unit.
--set-hostname=HOSTNAME
O nome da máquina do Servidor
RHN a receber a chave. O default é
dinamicamente definido para o nome da
máquina de criação.
--set-email=EMAIL
O endereço de e-mail do contato
do certificado. O default é
[email protected].
14
Gerando o Par de Chaves SSL da Autoridade Certificadora (Certificate Authority)
Opção
Descrição
--rpm-packager=PACKAGER
Empacotador do RPM gerado,
tal como "Admin da RHN ([email protected])."
--rpm-vendor=VENDOR
Distribuidor do RPM gerado, tal como
"Exemplo TI Corp."
-v, --verbose
Apresenta mensagem verbosa.
Acumulativa - adicionar "v"s resulta em
mais detalhes.
--key-only
Raramente usada - Gera somente uma
chave privada do servidor. Reveja --genserver --key-only--help para mais
informações.
--cert-req-only
Raramente usada - Gera somente um
pedido de certificado do servidor. Reveja
--gen-server --cert-req-only -help para mais informações.
--cert-only
Raramente usada - Gera somente um
certificado do servidor. Reveja --genserver --cert-only --help para
mais informações.
--rpm-only
Raramente usada - Gera somente um
RPM para ser empregado. Reveja --genserver --rpm-only --help para mais
informações.
--no-rpm
Raramente usada - Conduz todos os
passos relativos ao servidor exceto pela
geração do RPM.
--server-rpm=SERVER_RPM
Raramente alterada - nome do RPM que
contém o conjunto de chaves SSL do
sevidor Web (o nome base do arquivo e
não filename-version-release.noarch.rpm).
--server-tar=SERVER_TAR
Raramente alterada - Nome do arquivo .tar
do conjunto de chaves SSL e certificado
público da CA do servidor, usado somente
pelas rotinas de instalação do RHN
Proxy Server hospedado (o nome base
do arquivo e não filename-versionrelease.tar).
3.2.3. Gerando o Par de Chaves SSL da Autoridade Certificadora
(Certificate Authority)
Antes de criar o conjunto de chaves SSL requisitado pelo servidor Web, você deve gerar um par de
chaves SSL da Autoridade Certificadora (CA). Um certificado público SSL da CA é distribuído aos
sistemas cliente do Satellite ou do Proxy. A RHN SSL Maintenance Tool permite a você gerar o par
de chaves SSL da CA, se necessário, e reutilizá-lo para todas as outras implementações de servidor
RHN subsequentes.
15
Capítulo 3. Infra-estrutura da SSL
O processo de criação automaticamente cria o par de chaves e o RPM público para distribuição
aos clientes. Todos os componentes da CA acabam no diretório de criação especificado na linha de
comando; geralmente em /root/ssl-build (ou /etc/sysconfig/rhn/ssl para Satellites e
Proxies mais antigos). Para gerar um par de chaves SSL da CA, invoque um comando como este:
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"
Substitua os valores do exemplo de acordo com a realidade de sua empresa. Isto resultará nos
arquivos relevantes a seguir, no diretório de criação especificado:
• RHN-ORG-PRIVATE-SSL-KEY — a chave SSL privada da CA
• RHN-ORG-TRUSTED-SSL-CERT — o certificado público SSL da CA
• rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm — o RPM preparado para distribuição
aos sistemas cliente. Contém o certificado público SSL da CA (acima) e instala-o nesta localidade:
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
• rhn-ca-openssl.cnf — o arquivo de configuração da SSL da CA
• latest.txt — sempre lista as versões mais recentes dos arquivos relevantes.
Ao terminar, você está pronto para distribuir o RPM aos sistemas cliente. Consulte a Seção 3.3,
“Empregando o Certificado Público SSL da CA nos Clientes”.
3.2.4. Gerando Conjuntos de Chaves SSL do Servidor Web
Apesar de você precisar de um par de chaves SSL da CA já gerado, é provável que você precise
gerar conjuntos de chaves SSL do servidor com mais frequência, especialmente se empregar mais
de um Proxy ou Satellite. Note que o valor de --set-hostname é diferente para cada servidor. Em
outras palavras, é necessário gerar um conjunto distinto de chaves e certificados SSL para cada
máquina de servidor RHN distinta.
O processo de criação do certificado do servidor funciona como a geração do par de chaves SSL da
CA, com uma exceção: todos os componentes do servidor acabam nos sub-diretórios do servidor
de criação, que refletem o nome da máquina do sistema da criação, tal como /root/ssl-build/
MACHINE_NAME. Para gerar certificados de servidor, invoque um comando como este:
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="[email protected]" \
--set-hostname="rhnbox1.example.com
Substitua os valores do exemplo por aqueles apropriados para sua empresa. Isto resultará nos
seguintes arquivos relevantes num sub-diretório do diretório de criação de uma máquina específica:
• server.key — a chave privada SSL do servidor Web
• server.csr — o pedido do certificado SSL do servidor Web
• server.crt — o certificado público SSL do servidor Web
16
Empregando o Certificado Público SSL da CA nos Clientes
• rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm — o RPM preparado
para distribuição aos Servidores RHN. Seu arquivo src.rpm associado também é gerado. Este RPM
contêm os arquivos da árvore acima e os instalará nestas localidades:
• /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 — o arquivo de configuração da SSL do servidor Web
• latest.txt — sempre lista as versões mais recentes dos arquivos relevantes.
Ao terminar, você está pronto para distribuir e instalar o RPM em seu respectivo Servidor RHN. Note
que o serviço httpd deve ser reiniciado após a instalação:
/sbin/service httpd restart
3.3. Empregando o Certificado Público SSL da CA nos
Clientes
Ambos processos de instalação, do RHN Proxy Server e do RHN Satellite Server, facilitam
relativamente o emprego nos clientes gerando um certificado público e um RPM SSL da CA. Estes
processos de instalação tornam-nos publicamente disponíveis ao inserir uma cópia de um ou ambos
no diretório /var/www/html/pub/ do Servidor RHN.
Este diretório público pode ser facilmente inspecionado através de qualquer navegador web: http://
proxy-ou-sat.exemplo.com/pub/.
O certificado público SSL da CA neste diretório pode ser baixado para um sistema cliente usando
wget ou curl. Por exemplo:
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
Alternativamente, se o RPM do certificado público SSL da CA residir no diretório /pub, pode ser
instalado num sistema cliente diretamente:
rpm -Uvh \
http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm
Confirme o nome real do certificado ou RPM antes de rodar estes comandos.
3.4. Configurando Sistemas Cliente
Uma vez empregado o RPM ou o certificado raw no sistema cliente, o administrador deste sistema
deve, em seguida, alterar os arquivos de configuração do Red Hat Update Agent e do Red Hat
Network Registration Client (se necessário) para usar o arquivo do certificado público SSL da CA e
conectar ao RHN Proxy Server ou ao RHN Satellite Server apropriado. A localidade geralmente aceita
para este certificado público é no diretório /usr/share/rhn.
17
Capítulo 3. Infra-estrutura da SSL
Tanto o RHN Proxy Server como o RHN Satellite Server possuem o RHN Bootstrap instalado
por default, que pode reduzir significativamente estes passos repetitivos e simplificar o processo
de registro e configuração dos sistemas cliente. Por favor consulte o Capítulo 5, Usando o RHN
Bootstrap para mais detalhes.
18
Importando Chaves Padronizadas GPG
Para os clientes que planejam construir e distribuir seus próprios RPMs de forma segura, recomendase que todos os RPMs padronizados sejam assinados usando a Guarda de Privacidade (GPG) do
GNU. Você poderá encontrar mais informações sobre como gerar chaves GPG e construir pacotes
assinados GPG em Red Hat Network Channel Management Guide.
Depois que os pacotes forem assinados, a chave pública deve ser implementada em todos os
sistemas, importando estes RPMs. Esta tarefa é realizada utilizado dois passos, criar um local central
para a chave pública, assim todos os clientes poderão recuperá-la, e o segundo passo: adicionar a
chave ao chaveiro do GPG local para cada sistema.
O primeiro passo é comum e pode ser gerenciado usando um Website, recomendado para
implementar os aplicativos do cliente RHN. (Consulte o Seção 2.1, “Empregando os RPMs Cliente
Mais Recentes da Red Hat Network”.) Para fazer isto, crie uma pasta pública em um servidor da Web
e coloque uma assinatura pública GPG nela:
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
A chave pode então ser baixada pelos sistemas de cliente, usando Wget:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
A opção -O- envia resultados para saídas padrão, enquanto a opção -q configura o Wget para rodar
em modo silencioso. Lembre-se de substituir a variante YOUR-RPM-GPG-KEY pelo nome do arquivo
de sua Chave.
Quando a chave estiver disponível no sistema de arquivo do cliente, importe-o para o chaveiro do
GPG local. Sistemas operacionais diferentes requerem métodos diferentes.
Para o Red Hat Enterprise Linux 3 ou versões anteriores, use o seguinte comando:
rpm --import /path/to/YOUR-RPM-GPG-KEY
Para o Red Hat Enterprise Linux 2.1, use o seguinte comando:
gpg $(up2date --gpg-flags) --import /path/to/YOUR-RPM-GPG-KEY
Quando a chave GPG tiver sido adicionada ao cliente com êxito, o sistema deve ser capaz de validar
RPMs padronizados assinados com a chave correspondente.
19
20
Usando o RHN Bootstrap
A Red Hat Network oferece uma ferramenta que automatiza grande parte da reconfiguração manual
descrita nos capítulos anteriores, RHN Bootstrap. Esta ferramenta desempenha uma função
essencial no Programa de Instalação do RHN Satellite Server, possibilitando a geração do script
bootstrap durante a instalação.
Os clientes RHN Proxy Server e os clientes com a configuração do Satellite atualizada, necessitam
de uma ferramenta de bootstrap que possa ser usada de forma independente. O RHN Bootstrap,
invocado pelo comando /usr/bin/rhn-bootstrap, serve este propósito e vem instalado por
default tanto no RHN Satellite Server como no RHN Proxy Server.
Se usado corretamente, o script gerado por esta ferramenta pode rodar em qualquer sistema cliente
para conduzir as seguintes tarefas:
• Redirecionar aplicações cliente ao Proxy ou Satellite da RHN
• Importar chaves GPG personalizadas
• Instalar certificados SSL
• Registrar o sistema na RHN, além de grupos de sistemas e canais determinados com a ajuda das
chaves de ativação
• Executar atividades diversas pós-configuração, inclusive atualização de pacotes, reinicializações e
mudanças na configuração da RHN
No entanto, os clientes devem se atentar para os riscos inerentes ao usar um script para conduzir
a configuração. Ferramentas de segurança como certificados SSL são instaladas pelo próprio
script; sendo assim, estas ainda não existem nos sistemas e não podem ser usadas para processar
transações. Isto dá margem para que alguém aja como o Satellite e transmita dados maléficos; risco
que é atenuado pelo fato da maioria dos Satellites e sistemas cliente operarem por trás de firewalls e
terem restrições de tráfego externo. O registro é conduzido via SSL e portanto é protegido.
The bootstrap script bootstrap.sh is automatically placed in the /var/www/html/pub/
bootstrap/ directory of the RHN Server. From there it can be downloaded and run on all client
systems. Note that some preparation and post-generation editing is required, as identified in the
following sections. Refer to Seção 5.4, “Opções do RHN Bootstrap” for the tool's complete list of
options. Finally, refer to the Apêndice A, Script de Amostra de Bootstrap for an example script.
5.1. Preparação
Como a RHN Bootstrap (rhn-bootstrap) depende de outros componentes da infra-estrutura da
Red Hat Network para configurar os sistemas cliente apropriadamente, estes componentes devem ser
preparados antes da geração do script. A lista seguinte aponta as medidas iniciais sugeridas.
• Gerar as chaves de ativação a serem invocadas pelo(s) script(s). As chaves de ativação podem
ser usadas para registrar sistemas Red Hat Enterprise Linux, atribuir-lhes um serviço da RHN e
registrá-los a canais e grupos de sistemas específicos; tudo em apenas uma ação. Note que você
deve ter o serviço Management disponível para usar uma chave de ativação, enquanto a inclusão
de chaves de ativação múltiplas, de uma só vez, requer serviços Provisioning. Gere as chaves de
ativação através da página Chaves de Ativação (Activation Keys) na categoria Sistemas do site
da RHN (os Servidores centrais da RHN para o Proxy ou o nome de domínio totalmente qualificado
do Satellite). Consulte os capítulos Red Hat Update Agent e Site da RHN do Guia de Referência da
RHN para instruções sobre a criação e uso.
21
Capítulo 5. Usando o RHN Bootstrap
• Red Hat recommends your RPMs be signed by a custom GNU Privacy Guard (GPG) key. Make
the key available so you may refer to it from the script. Generate the key as described in the RHN
Channel Management Guide and place the key in the /var/www/html/pub/ directory of the RHN
Server, per Capítulo 4, Importando Chaves Padronizadas GPG.
• If you wish to use the script to deploy your CA SSL public certificate, have the certificate or the
package (RPM) containing that certificate available on that RHN Server and include it during script
generation with the --ssl-cert option. Refer to Capítulo 3, Infra-estrutura da SSL for details.
• Have the values ready to develop one or many bootstrap scripts, depending on the variety of
systems to be reconfigured. Since RHN Bootstrap provides a full set of reconfiguration options,
you may use it to generate different bootstrap scripts to accommodate each type of system. For
instance, bootstrap-web-servers.sh might be used to reconfigure your Web servers, while
bootstrap-app-servers.sh can handle the application servers. Consult Seção 5.4, “Opções do
RHN Bootstrap” for the complete list.
5.2. Geração
Agora que todos os componentes necessários estão no devido lugar, você pode usar o RHN
Bootstrap para gerar os scripts requisitados. Autentique-se no seu RHN Satellite Server ou RHN
Proxy Server como root e invoque o comando rhn-bootstrap seguido pelas opções e valores
desejados. Se nenhuma opção for inclusa, é criado um arquivo bootstrap.sh no sub-diretório
bootstrap/ que contêm os valores essenciais derivados do servidor, incluindo nome da máquina,
certificado SSL (se existir), as configurações da SSL e GPG, além de uma chamada do arquivo
client-config-overrides.txt.
A Red Hat recomenda, no mínimo, que seus scripts também acomodem as chaves de ativação GPG
e as opções de configuração avançada da seguinte maneira:
• Use the --activation-keys option to include keys, taking into account the entitlement
requirements identified in Seção 5.1, “Preparação”.
• Use a opção --gpg-key para identificar a localidade da chave e nome do arquivo durante a
geração do script. Caso contrário, use a opção --no-gpg para desativar esta verificação nos
sistemas cliente. A Red Hat recomenda manter esta medida de segurança.
• Inclua a etiqueta --allow-config-actions para habilitar a administração remota da
configuração em todos os sistemas cliente almejados pelo script. Esta funcionalidade é útil para
reconfigurar sistemas múltiplos simultaneamente.
• Inclua a etiqueta --allow-remote-commands para habilitar o uso do script remoto em todos
os sistemas cliente. Assim como a administração da configuração, esta funcionalidade auxilia a
reconfiguração de sistemas múltiplos.
Quando terminar, seu comando se parecerá com:
rhn-bootstrap --activation-keys KEY1,KEY2 \
--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \
--allow-config-actions \
--allow-remote-commands
Obviously, include the actual key names. Refer to Seção 5.4, “Opções do RHN Bootstrap” for the
complete list of options.
22
Uso do Script
5.3. Uso do Script
Finalmente, quando você finalizar a preparação do script, está pronto para rodá-lo. Autentiquese no RHN Satellite Server ou no RHN Proxy Server, navegue para o diretório /var/www/html/
pub/bootstrap/ e invoque o seguinte comando, alterando o nome da máquina e nome do script,
conforme necessário pelo tipo de sistema:
cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash
Uma alternativa menos segura é usar wget ou curl para obter e rodar o script em todos os sistemas
cliente. Autentique-se em cada uma das máquinas cliente e invoque o seguinte comando, alterando o
script e nome da máquina de acordo:
wget -qO - \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Ou, com o curl:
curl -Sks \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Quando o script rodar em cada um dos sistemas cliente, todos devem estar configurados para usar o
Servidor da RHN.
5.4. Opções do RHN Bootstrap
O RHN Bootstrap oferece diversas opções de linha de comando para criar scripts do boostrap.
Garanta que as opções desta tabela estejam disponíveis na versão da ferramenta instalada em seu
Servidor da RHN, invocando o comando rhn-bootstrap --help ou revendo sua página man.
Tabela 5.1. Opções do RHN Bootstrap
Opção
Descrição
-h, --help
Apresenta a tela de ajuda com uma
lista de opções específicas para gerar
o script do bootstrap.
--activation-keys=ACTIVATION_KEYS
a(s) chave(s) de ativação conforme
definidas no site da RHN; entradas
múltiplas devem ser separadas por
uma vírgula sem espaços
--overrides=OVERRIDES
Nome do arquivo de overrides da
configuração. O default é client-configoverrides.txt.
--script=SCRIPT
Nome do arquivo do script do
bootstrap. O default é bootstrap.sh.
--hostname=HOSTNAME
O nome de domínio totalmente
qualificado (fully qualified domain
name, FQDN) do servidor ao qual os
sistemas cliente se conectarão.
23
Capítulo 5. Usando o RHN Bootstrap
Opção
Descrição
--ssl-cert=SSL_CERT
A localidade do certificado SSL público
da sua empresa; um pacote ou um
certificado raw. Será copiado para
a opção --pub-tree. Um valor ""
forçará uma busca de --pub-tree.
--gpg-key=GPG_KEY
A localidade da chave GPG pública da
sua empresa, se usada. Será copiada
para a localidade especificada pela
opção --pub-tree.
--http-proxy=HTTP_PROXY
A configuração do proxy HTTP
dos sistemas cliente, no formato
máquina:porta. Um valor ""
desativa esta configuração.
--http-proxy-username=HTTP_PROXY_USERNAME
Se usar um proxy HTTP com
autenticação, especifique um nome
de usuário. Um valor "" desativa esta
configuração.
--http-proxy-password=HTTP_PROXY_PASSWORD
Se usar um proxy HTTP com
autenticação, especifique uma senha.
--allow-config-actions
Boleana; incluir esta opção configura
o sistema para permitir todas as ações
de configuração via RHN. Isto requer
instalar determinados pacotes rhncfg*, possivelmente através de uma
chave de ativação.
--allow-remote-commands
Boleana; incluir esta opção configura
o sistema para permitir comandos
remotos arbitrários via RHN. Isto
requer a instalação de determinados
pacotes rhncfg-*, possivelmente
através de uma chave de ativação.
--no-ssl
Não recomendada - Boleana; incluir
esta opção desliga a SSL no sistema
cliente.
--no-gpg
Não recomendada - Boleana; incluir
esta opção desliga a verificação GPG
no sistema cliente.
--no-up2date
Não recomendada - Boleana; incluir
esta opção garante que o up2date
não será executado após o sistema ter
sido afetado pelo bootstrap.
--pub-tree=PUB_TREE
Alteração não recomendada - A árvore
do diretório público onde o certificado
e pacote SSL da CA serão inseridos;
o diretório e scripts do bootstrap. O
default é /var/www/html/pub/.
24
Opções do RHN Bootstrap
Opção
Descrição
--force
Não recomendada - Boleana; incluir
esta opção força a geração do script
do bootstrap, ignorando avisos.
-v, --verbose
Apresenta mensagens verbosas.
Acumulativa. -vvv traz mensagens
extremamente verbosas.
25
26
Escrevendo o script da configuração
manualmente
Observe que este capítulo fornece uma alternativa para usar o RHN Bootstrap para gerar o script do
bootstrap. Com todas estas instruções, você conseguirá criar seu próprio script de bootstrap desde o
início.
Todas as técnicas iniciais partilham do mesmo tema: a implementação dos arquivos necessários, em
um local centralizado para ser recuperado e instalado executando comandos simples e programáveis
em cada cliente. Neste capítulo, juntaremos todas estas peças para criar um único script que possa
ser invocado por qualquer sistema de sua empresa.
Ao combinar todos estes comandos a partir de capítulos anteriores da forma mais ordenada possível,
obteremos o seguinte script. Tenha em mente que as versões Red Hat Enterprise Linux 3 ou 4, não
possuem o rhn_register:
# 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
Lembre-se que o sexto passo é documentado aqui, pois ele se refere aos sistemas rodando o Red
Hat Linux 3 ou versões anteriores a esta.
O script é composto por um processo limpo e repetitivo, que deve configurar plenamente qualquer
cliente do Red Hat Network em potencial, que esteja se preparando para registrar-se em um RHN
Proxy Server ou RHN Satellite Server. Lembre-se que os valores da chave, tais como o URL de seu
RHN Server, seu diretório público e sua chave GPG atual deve ser inserida nos espaços reservados
listados abaixo dentro do script. Da mesma forma, dependendo de seu ambiente, podem ser
27
Capítulo 6. Escrevendo o script da configuração manualmente
necessárias algumas modificações adicionais. Apesar deste script funcionar quase que literalmente,
ele deve ser usado como um guia.
Como seus componentes, este script pode ser localizado centralmente. Ao colocar este script na
pasta /pub/ do servidor, executar o comando wget -O- nele, e realizar um pipe do resultado em
uma sessão do shell, pode ocorrer de executar todo o processo do bootstrap com um único comando
de cada cliente:
wget -O - http://proxy-or-sat.example.com.com/pub/bootstrap_script | bash
Aviso
A execução de um script de shell diretamente a partir da entrada em pipe sob a conexão da
Web, pode acarretar alguns riscos inerentes. Por isso, neste caso, é muito importante garantir a
segurança do servidor da fonte.
Este comando de uma linha pode então ser invocado por todos os sistemas em uma rede. Se o
administrador possuir acesso SSH para todos os sistemas em questão, iterar em uma lista destes
sistemas e executar o comando de maneira remota em todos eles, deve ser uma tarefa muito
simples. Este script seria também perfeito como um adicional ao pós seção de um script kickstart
existente.
28
Implementar o Kickstart
Evidentemente, a melhor hora para realizar mudanças de configurações em um sistema é quando
o sistema estiver sendo construído pela primeira vez. Para os clientes que já usam o kickstart
efetivamente, é ideal acrescentar o script do bootstrap à este processo.
Uma vez que todos os problemas de configurações forem resolvidos, registre o sistema com os
Servidores do Red Hat Network, usando a ferramenta rhnreg_ks, a qual é fornecida com o
up2date e os RPMs do rhn_register. Este capítulo discute o uso adequado do rhnreg_ks para
registrar sistemas.
A ferramenta rhnreg_ks usa as chaves de ativação para registrar, fornecer direitos à serviços e
realizar a subscrição dos sistemas em canais específicos com somente um movimento. Para saber
mais sobre as chaves de ativação, consulte oRed Hat Update Agent e os capítulos do RHN Website
do Red Hat Network Management Reference Guide.
O seguinte arquivo do kickstart comentado é um exemplo perfeito de como um sistema pode ser
configurado do início ao fim, usando o 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
29
Capítulo 7. Implementar o Kickstart
@ 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
30
Apêndice A. Script de Amostra de
Bootstrap
O script /var/www/html/pub/bootstrap/bootstrap.sh gerado pelo programa de instalação
do RHN Satellite Server fornece a habilidade para reconfigurar os sistemas cliente para acessar seu
RHN Server de maneira mais fácil. Ele foi disponibilizado para os clientes de RHN Satellite Server e
RHN Proxy Server através das ferramentas do RHN Bootstrap. Após adequar o script para seu uso
particular, ele poderá rodar em todas as máquinas cliente.
Reveja a amostra e seus comentários, iniciando pela marca de cerquilha (#) para obter mais detalhes.
Siga os passos em Capítulo 5, Usando o RHN Bootstrap para preparar o script para uso.
#!/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 -qOhttps://<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!"
31
Apêndice A. Script de Amostra de Bootstrap
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
exit
"If this bootstrap script was created during the initial installation"
"of an RHN Satellite, the ACTIVATION_KEYS, and ORG_GPG_KEY values will"
"probably *not* be set (see below). If this is the case, please do the"
"following:"
" - copy this file to a name specific to its use."
" (e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.)"
" - on the website create an activation key or keys for the system(s) to"
" be registered."
" - edit the values of the VARIABLES below (in this script) as"
" appropriate:"
" - ACTIVATION_KEYS needs to reflect the activation key(s) value(s)"
"
from the website. XKEY or XKEY,YKEY"
" - ORG_GPG_KEY needs to be set to the name of the corporate public"
"
GPG key filename (residing in /var/www/html/pub) if appropriate."
"Verify that the script variable settings are correct:"
" - CLIENT_OVERRIDES should be only set differently if a customized"
"
client-config-overrides-VER.txt file was created with a different"
"
name."
" - ensure the value of HOSTNAME is correct."
" - ensure the value of ORG_CA_CERT is correct."
"Enable this script: comment (with #'s) this block (or, at least just"
"the exit below)"
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
32
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 [ !
echo
exit
fi
if [ !
echo
exit
fi
-f "client_config_update.py" ] ; then
"ERROR: client_config_update.py was not downloaded"
1
-f "${CLIENT_OVERRIDES}" ] ; then
"ERROR: ${CLIENT_OVERRIDES} was not downloaded"
1
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
33
Apêndice A. Script de Amostra de Bootstrap
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-"
34
Apêndice B. Histórico de Revisão
Revisão 1-7
Fri Feb 27 2009
35
36
Índice Remissivo
Símbolos
--configure
uso do, 5
A
activation keys
registering with, 4
B
bootstrap.sh
arquivo amostra, 31
preparation and use, 21
C
RHN SSL Maintenance Tool
geração explicada, 11
gerando o CA, 15
gerando o certificado do servidor, 16
opções, 12
rhn-ssl-tool , 10
rhn-ssl-tool
geração explicada, 11
gerando o CA, 15
gerando o certificado do servidor, 16
opções, 12
RHN SSL Maintenance Tool , 10
S
SSL (Secure Sockets Layer)
introdução, 9
Certificado SSL
gerando, 10
instalação de, 17
Certificados SSL
configuração de, 17
client applications
configuration of, 4
installation of, 3
client configuration
Red Hat Update Agent , 5
configuração
manual, 6
realizando o script completo, 27
configuration
server failover, 7
G
GPG keys
importando de, 19
K
kickstart
uso do, 29
R
Red Hat Network Alert Notification Tool
configuration for Satellite, 8
Red Hat Update Agent
configurando para usar o RHN Proxy Server or
RHN Satellite Server, 6
RHN Bootstrap
command line options, 23
generating the script, 22
preparando, 21
usando, 21
using the script, 23
37
38