Red Hat Equipe da Documentação
Red Hat Network Satellite 5.5
Guia de Configura
��o do
Cliente
Red Hat Network Satellite
Edição 3
Red Hat Network Satellite 5.5 Guia de Configura��o do Cliente
Red Hat Network Satellite
Edição 3
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, 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.
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.
Resumo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Índice
Capítulo 1. IntroduçãoCapítulo 2. Aplicações em Máquinas Clientes
2.1. Empregando os RPMs Clientes Mais Recentes da Red Hat Network 2.2. Configurando as Aplicações Clientes
2.2.1. Registrando Clientes no Servidor Red Hat Network RHN Satellite 2.2.2. Registrando com Chaves de Ativação
2.2.3. Usando a Opção up2date --configure
2.2.4. Atualizando os Arquivos de Configuração Manualmente 2.2.5. Implementando a Transferência (failover) de Servidores 2.3. O Applet do Atualizador de Pacotes
Capítulo 3. Infra-estrutura da SSL 3.1. Uma Breve Introdução à SSL 3.2. O RHN SSL Maintenance Tool
3.2.1. Gerando os Certificados SSL
3.2.2. Opções da RHN SSL Maintenance Tool
3.2.3. Gerando o Par de Chaves SSL da Autoridade Certificadora (Certificate Authority) 3.2.4. Gerando Conjuntos de Chaves SSL do Servidor Web
3.3. Empregando o Certificado Público SSL da CA nos Clientes 3.4. Configurando Sistemas Cliente
Capítulo 4 . Importando Chaves Padronizadas GPG Capítulo 5. Usando o RHN Bootstrap
5.1. Preparando para uma instalação de RHN Bootstrap 5.2. Gerando os Scripts do RHN Bootstraps
5.3. Utilizando o Script do RHN Bootstrap 5.4. Configurando as opções do RHN Bootstrap
Capítulo 6. Escrevendo o script da configuração RHN Bootstrap manualmente Capítulo 7. Implementar o Kickstart
Exemplo de Script Bootstrap Revision History Índice Remissivo Símbolos A B C G K R S 3 4 4 5 5 6 6 7 8 8 10 10 11 12 13 17 18 19 19 20 21 21 22 23 23 26 28 31 37 37 37 38 38 38 38 38 39 39 Índice
Capítulo 1. Introdução
Este guia de melhores práticas pretende ajudar clientes do RHN Satellite Server e RHN Proxy Server a configurarem seus sistemas de cliente.
Por padrão, todos os aplicativos de cliente Red Hat Network são configurados para comunicar com os Servidores centrais Red Hat Network. Quando os clientes se conectam ao RHN Satellite Server ou RHN Proxy Server, a configuração padrão muda. Este documento pretende ajudar, oferecendo passos de reconfiguração em massa que ajudarão ambientes corporativos, contendo diversos sistemas, endereçando as mudanças de configuração padrão.
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 o
Capítulo 5, Usando o RHN Bootstrap para maiores detalhes. A Red Hat acredita que é 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 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.
Capítulo 2. Aplicações em Máquinas Clientes
Para poder utilizar a maioria das funcionalidades da Red Hat Network, como por exemplo registrar-se em um Satellite, é necessário a configuração das aplicações em clientes 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 aos Servidores RHN Proxy ou RHN Satellite, executem a última versão do Red Hat Enterprise Linuse para garantia de uma 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 Clientes Mais Recentes da Red Hat
Network
O Package Updater (pup), yum,o yum RHN Plugin (yum-rhn-plugin) e o Red Hat Network Registration Client (rhn_register) no Red Hat Enterprise Linux 5e 6 são pré-requisitos para utilizar a maioria das funções do Red Hat Network corporativo. É necessário instalá-los nos sistemas cliente antes de tentar utilizar os Servidores RHN Proxy ou RHN Satellite 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 clientes 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. Estas ferramentas clientes não devem apresentar problemas ao conectar a seu ambiente RHN Satellite ou Proxy. A discussão abaixo assume que o yum imediato, pup, e rhn_register não são os mais recentes e não funcionam em seu
ambiente.
Observe que os sistemas executando o Red Hat Enterprise Linux 5 e 6 devem ser registrados com o RHN no firstboot após a instalação ou utilizando o comando rhn_register.
Este documento presume que o cliente instalou ao menos um Servidor RHN Satellite e/ou Proxy em suas redes. O exemplo abaixo demonstra que uma simples implementação do yum, pup, e
rhn_register (ou up2date) pela primeira vez por um administrador, considerando que as máquinas não tenham um RHN funcionando:
rpm -Uvh
http://satellite.example.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm http://satellite.example.com/pub/yum-3.2.8-9.el5.i386.rpm
http://satellite.example.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
O administrador já pré-populou o diretório /var/www/html/pub/ no ambiente do RHN Satellite ou RHN Proxy com a cópia dos RPMs yum, pup, e rhn_register que os sistemas do cliente precisam, e depois ao executar o comando acima. Os RPMs já foram implementados nos sistemas cliente com um comando simples rpm -Uvh. O comando rpm -Uvh, quando executado de um cliente, instala os RPMs no cliente, presumindo-se que o nome do domínio, caminhos e versões do RPM são corretos (note que o comando foi dividido em diversas linhas para impressão e PDF mas deveria ter digitado como uma só
linha ao ser solicitado no terminal):
Tenha em mente que a arquitetura (neste caso, i386) talvez precise ser alterada, dependendo dos sistemas a servir.
2.2. Configurando as Aplicações Clientes
Apesar de poucos clientes terem de se conectar de forma segura em um Servidor RHN Satellite ou RHN Proxy dentro de suas empresas, e poucos clientes precisarem construir e implementar a chave GPG para pacotes de clintes, todos os clientes que utilizam os Servidores RHN Satellite ou RHN Proxy devem reconfigurar o Red Hat Update Agent (up2date) e possivelmente o Red Hat Network Registration Client (rhn_register) para redirecioná-lo da Red Hat Network para seus Servidores RHN Satellite ou RHN Proxy.
Importante
Apesar disto não ser configurável, note que a porta usada pelo up2date é 80 para HTTP e 443 para HTTP seguro (HTTPS). Por padrão, 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 clientes devem permitir conexões na porta 4545 (ou na porta 22, se usar sshd).
Por padrão, o rhn_register e up2date referem aos Servidores principais da Red Hat Network. Os usuários devem reconfigurar os sistemas clientes para referirem ao seu Servidor RHN Satellite ou RHN Proxy.
Note que as versões mais recentes do Red Hat Update Agent podem ser configuradas para acomodar diversos Servidores do RHN, provendo assim proteção contra quedas, no caso do servidor primário estar inacessível. Consulte a Seção 2.2.5, “Implementando a Transferência (failover) de Servidores” para obter instruções da ativação desta funcionalidade.
As próximas seções descrevem os métodos para configurar os sistemas clientes para acessarem seu Servidor RHN Satellite ou RHN Proxy. Para ver como virtualmente toda reconfiguração pode ser feita através de scripts, veja o Capítulo 6, Escrevendo o script da configuração RHN Bootstrap manualmente .
2.2.1. Registrando Clientes no Servidor Red Hat Network RHN Satellite
Para registrar um sistema com o Servidor RHN Satellite, um nome de domínio totalmente qualificado (FQDN) é necessário o cert SSL do Servidor RHN Satellite. Uma vez que estes requerimentos forem atendidos, proceda com os seguintes passos:
1. Baixe o certificado SSL para o cliente: cd /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT 2. Edite o arquivo /etc/sysconfig/rhn/up2date:
serverURL=https://satellite.example.com/XMLRPC noSSLServerURL=http://satellite.example.com/XMLRPC sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT 3. Registre a máquina:
rhn_register
2.2.2. Registrando com Chaves de Ativação
A Red Hat recomenda usar as chaves de ativação para registrar e configurar sistemas clientes que acessam o Servidor RHN Proxy ou RHN Satellite. 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.
Ao registrar com a chave de ativação:
1. Gere uma Chave de Ativação (Consulte a seção "Chaves de Ativação" no RHN Satellite Server Reference Guide)
2. Importar chaves GPG personalizadas.
3. Fazer o download e instalar o RPM do Certificado SSL do diretório /pub/ do Servidor RHN Proxy ou RHN Satellite. O comando para este passo pode se parecer com o seguinte:
rpm -Uvh http://satellite.example.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
4. Registrar o sistema com um Servidor RHN Proxy ou RHN Satellite: rhnreg_ks --activationkey mykey --serverUrl https://satellite.example.com/XMLRPC
Como forma alternativa, a maioria dos passos pode ser combinada em um script de terminal que inclui as seguintes linhas:
wget -0 - http://satellite.example.com/pub/bootstrap.sh | bash && rhnreg_ks --activation-key my_key --serverUrl
https://satellite.example.com/XMLRPC
Note que o comando foi dividido em diversas linhas para impressão e PDF mas deve ser digitada como uma só linha na solicitação do terminal.
O script bootstrap, gerado na instalação e disponível para os Servidores RHN Satellite e Proxy, é um destes. O script e o RHN Proxy Server que o geram são abordados em detalhes no Capítulo 5, Usando
o RHN Bootstrap.
2.2.3. Usando a Opção up2date --configure
O Red Hat Update Agent distribuído com o Red Hat Enterprise Linux 3 e 4, oferece interfaces para configurações diversas. Para obter uma lista completa destas configurações, consulte a página man do up2date (m an up2date na linha de comando).
Para reconfigurar o Red Hat Update Agent, invoque o seguinte comando como usuário root:
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 padrão pelo nome de domínio totalmente qualificado (fully qualified domain name, FQDN) dos Servidores RHN Satellite ou RHN Proxy Server, tal como
https://your_proxy_or_sat.your_dom ain.com /XMLRPC. Mantenha /XMLRPC no final. Quanto terminar, clique em OK.
Figura 2.1. Configuração Gráfica do Red Hat Update Agent
Certifique-se de indicar o nome de domínio do seus Servidores RHN Satellite ou RHN Proxy Server, corretamente. Indicar um domínio incorreto ou deixá-lo em branco pode evitar que o up2date --configure seja iniciado. Isto pode ser resolvido, no entanto, editando o valor no arquivo de configuração up2date. Consulte o Seção 2.2.4, “Atualizando os Arquivos de Configuração Manualmente” para obter instruções precisas.
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 d 6 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.4. 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 clientes conectando aos Servidores RHN Proxy ou RHN Satellite, edite os valores serverURL e noSSLServerURL no arquivo de configuração /etc/sysconfig/rhn/up2date (como root). Substitua a URL padrão da Red Hat Network pelo nome de domínio totalmente qualificado (fully qualified domain name, FQDN) dos Servidores RHN Proxy ou RHN Satellite. Por exemplo:
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 servidor RHN Proxy, a configuração de httpProxy deve ser deixada em branco (sem nenhum valor
determinado).
2.2.5. 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 Servidor RHN Proxy ou RHN Satellite principal sofra uma queda e fique offline. Para utilizar este recurso:
1. Assegure-se de que você está executando a versão requerida ou uma mais recente do up2date assim como executando o Red Hat Enterprise Linux 5 ou 6.
2. Adicione manualmente os servidores secundários nas configurações do serverURL e noSSLServerURL no arquivo de configuração (como usuário root)
/etc/sysconfig/rhn/up2date.
3. Adicione nomes de domínios totalmente qualificados (FQDN) para o Proxy ou Satellite imediatamente após o servidor primário, separado por ponto e vírgula (;). Por exemplo:
serverURL[comment]=Remote server URL
serverURL=https://satellite.example.com/XMLRPC; https://your_secondary.your_domain.com/XMLRPC;
noSSLServerURL[comment]=Remote server URL without SSL noSSLServerURL=http://satellite.example.com/XMLRPC; http://your_secondary.your_domain.com/XMLRPC;
Existe a tentativa de conexão entre os servidores na ordem fornecida aqui. Inclua o máximo de servidores quanto for necessário.
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.
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 clicando no ícone de notificação e escolhendo a partir das seguintes ações: Atualizar - Verifica o RHN ou Satellite por novas atualizações
Visualizar 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 configura as atualizações em suas
especificações.
Aplicar Atualizações - Baixa e Instala todos os pacotes atualizados. Sair - Fecha o applet
Capítulo 3. 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 servidores RHN Proxy e RHN Satellite, 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 pareado que tornam este sistema funcional. Através desta relação, é estabelecida uma conexão confiável.
Nota
As chaves privadas SSL e certificados públicos serão discutidos ao long deste documento. Ambos podem ser chamados de chaves, uma pública e outra privada. No entanto, ao discutir sobre o SSL, é conveniente se referir a parte pública de um par de chaves SSL (ou um conjunto de chaves) como o certificado público SSL.
A infra-estrutura de SSL de uma organização 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 organização. 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.
Aqui segue um cenário: se você possui um Servidor Satellite e cinco RHN Proxy da RHN, você 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 SSL, especificamente ligado ao nome da máquina deste servidor e gerado usando suas próprias chaves
privadas 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 conjunto 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. O 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 Management Tool, comumente conhecida por seu comando rhn-ssl-tool. Esta ferramenta é disponibilizada como parte do pacote rhns-certs-tools. Este pacote pode ser encontrado nos canais de software do RHN Proxy Server e RHN Satellite mais
recentes (assim como na ISO do Servidor RHN Satellite). A RHN SSL Management 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 clientes. 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 a Autoridade do Certificado (CA) certificado público
Ao instalar um servidor RHN Proxy 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 organização.
Ao reconfigurar sua infra-estrutura RHN para usar SSL quando previamente não o fazia.
Ao adicionar o RHN Satellite múltiplos à sua infra-estrutura RHN - consulte um representante da Red Hat para instruções sobre esta questão.
Aqui estão os casos nos quais a ferramenta não é necessária:
Durante a instalação de um servidor RHN Satellite - 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 and the RHN Proxy 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 clientes 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 sumo, se a Infraestrutura da RHN de uma empresa implementa a versão mais recente do Servidor RHN Satellite como seu serviço de alto nível, deve haver pouca necessidade da ferramenta.
3.2.1. Gerando os Certificados SSL
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 criados pela sua organização. 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 em um sistema de sua organização. Talvez, mas não necessariamente, num servidor RHN Satellite Server or RHN Proxy.
2. Crie um certificado único de par de chaves Autoridade de Certificado SSL para a empresa e instale o RPM resultando no RPM ou certificado público em todos os sistemas cliente. Consulte o Seção 3.2.3, “Gerando o Par de Chaves SSL da Autoridade Certificadora (Certificate Authority)” para mais informações.
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.
4. Reinicie o serviço httpd:
/sbin/service httpd restart
5. 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.)
6. 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. 7. Memorize e proteja a senha da CA para uso futuro.
8. 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.
Nota
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 tool --gen-server --help (Servidor Web). A página man da rhn-ssl-tool também é bastante detalhada e útil: man rhn-ssl-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 Força a criação 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 padrão é ./ssl-build. --ca-key=FILENAME O nome do arquivo da chave privada da
CA. O padrão é RHN-ORG-PRIVATE-SSL-KEY.
--ca-cert=FILENAME O nome do arquivo do certificado público da CA. O padrão é RHN-ORG-TRUSTED-SSL-CERT .
--cert-expiration=CA_CERT_EXPIRE A data de expiração do certificado público da CA. O padrão é o número de dias até a véspera da data de transição (epoch rollover ou 18-01-2038)
--set-country=COUNTRY_CODE A código de duas letras do país. O padrão é US.
--set-state=STATE_OR_PROVINCE O estado ou província da CA. O padrão é ''. --set-city=CITY_OR_LOCALITY A cidade ou localidade. O padrão é ''. --set-org=ORGANIZATION A empresa ou organização, tal como Red
Hat. O padrão é Example Corp. Inc. --set-org-unit=SET_ORG_UNIT A unidade organizacional, como RHN. O
padrão é ''.
--set-com m on-nam e=HOSTNAME Não é tipicamente definido para a CA. - O nome comum.
--set-em ail=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
(admin-rhn@exemplo.com.br)."
--rpm -vendor=VENDOR Distribuidor do RPM gerado, tal como "Exemplo TI Corp."
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-version-release.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 --gen-ca --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.
-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 padrão é ./ssl-build. --server-key=FILENAME O nome do arquivo da chave privada SSL
do servidor Web. O padrão é server.key. --server-cert-req=FILENAME O nome do arquivo do pedido do certificado
SSL do servidor Web. O padrão é server.csr.
--server-cert=FILENAME O nome do arquivo do certificado SSL do servidor Web. O padrão é 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 padrão é uma semana antes da geração.
--cert-expiration=SERVER_CERT_EXPIRE A data de expiração do certificado do servidor. O padrão é 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 padrão é US.
--set-state=STATE_OR_PROVINCE O estado ou a província. O padrão é North Carolina.
--set-city=CITY_OR_LOCALITY A cidade ou localidade. O padrão é Raleigh. --set-org=ORGANIZATION A empresa ou organização, tal como a Red
Hat. O padrão é o Example Corp. Inc. --set-org-unit=SET_ORG_UNIT A unidade organizacional, tal como RHN. O
padrão é unit.
--set-hostnam e=HOSTNAME O nome da máquina do Servidor RHN a receber a chave. O padrão é
dinamicamente definido para o nome da máquina de criação.
--set-em ail=EMAIL O endereço de e-mail do contato do certificado. O padrão é
admin@example.corp.
"Admin da RHN (admin-rhn@exemplo.com.br)."
--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 --gen-server --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 --gen-server --cert-only --help para mais informações.
--rpm -only Raramente usada - Gera somente um RPM para ser empregado. Reveja --gen-server --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 Servidor RHN Proxy hospedado (o nome base do arquivo e não filename-version-release.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 clientes 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á-las para todas as outras implementações de servidor RHN subsequentes.
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 organização. Isto resultará nos arquivos relevantes a seguir, no diretório de criação especificado:
RHN-ORG-PRIVAT E-SSL-KEY — a chave SSL privada da CA RHN-ORG-T RUST ED-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 clientes. Contém o certificado público SSL da CA (acima) e instala-o nesta localidade: /usr/share/rhn/RHN-ORG-T RUST ED-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 clientes. 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
Neste ponto, um par de chaves CA SSL já deveria ter sido gerado. No entanto, existe a possibilidade de gerar conjuntos de chaves do servidor da Web SSL mais frequentemente, especialmente se mais de um Proxy ou Satellite for implementado. Um conjunto distinto de chaves SSL e certificados deve ser gerado e instalado para cada hostname de servidor RHN distinto, por isso a nota que o valor para --set-hostnam e é diferente para cada servidor.
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="admin@example.com" \
--set-hostname="rhnbox1.example.com
Substitua os valores do exemplo por aqueles apropriados para sua organização. 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
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 servidor RHN Proxy e RHN Satellite 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/htm l/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 Registraction Client (se necessário) para usar o arquivo do certificado público SSL da CA e conectar ao Servidor RHN Proxy ou RHN Satellite apropriado. A localidade geralmente aceita para este certificado público é no diretório /usr/share/rhn.
Tanto o Servidor RHN Proxy ou RHN Satellite possuem o RHN Bootstrap instalado por padrão, que pode reduzir significativamente estes passos repetitivos e simplificar o processo de registro e configuração dos sistemas clientes. Por favor consulte o Capítulo 5, Usando o RHN Bootstrap para mais detalhes.
Capítulo 4. Importando Chaves Padronizadas GPG
Para os clientes que planejam construir e distribuir seus próprios RPMs de forma segura, recomenda-se que todos os RPMs padronizados recomenda-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 utilizando 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 Clientes 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-a 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
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.
Nota
Ao utilizar os RPMs padronizados e canais, sempre crie uma chave GPG padronizada para estes pacotes. O local da chave GPG também precisa ser adicionado ao perfil do Kickstart. A chave GPG padronizada precisa ser adicionada aos sistemas clientes ou a instalação do Kicskstart pode falhar.
Capítulo 5. Usando o RHN Bootstrap
O RHN Bootstrap 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 RHN Satellite Server Installation Program, 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 padrão tanto no RHN Satellite Server e 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 clientes operarem por trás de firewalls e terem restrições de tráfego externo. O registro é conduzido via SSL e portanto é protegido.
O script bootstrap.sh do bootstrap é automaticamente inserido no diretório
/var/www/htm l/pub/bootstrap/ do Servidor da RHN. De lá, pode ser baixado e executado em todos os sistemas clientes. Note que é necessário uma preparação e edição pós-geração, conforme identificadas na seções seguintes. Consulte a Seção 5.4, “Configurando as opções do RHN
Bootstrap” para obter uma lista completa das opções da ferramenta. Por fim, consulte o 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, “Configurando as opções do RHN Bootstrap” for the tool's complete list of options. Finally, refer to the Apêndice A, Exemplo de Script Bootstrap para ver um exemplo de script.
5.1. Preparando para uma instalação de RHN Bootstrap
Como a RHN Bootstrap (rhn-bootstrap) depende de outros componentes da infra-estrutura da Red Hat Network infrastructure para configurar os sistemas clientes 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 do Red Hat Update Agent e RHN Website do Guia de Referência da RHN para instruções sobre a criação e uso.
A Red Hat recomenda que seus RPMs sejam assinados com uma chave do GNU Privacy Guard (GPG) personalizada. Disponibilize a chave para que você possa referenciá-la no script. Gere as chaves, conforme descrito no Guia de Administração de Canais RHN e insira a chave no diretório /var/www/htm l/pub/ do Servidor da RHN, conforme abordado no Capítulo 4, Importando Chaves
Padronizadas GPG.
Se você deseja usar o script para empregar seu certificado SSL público da CA, disponibilize o certificado ou o pacote (RPM) contendo este certificado naquele Servidor da RHN e inclua-o durante a geração do script com a opção --ssl-cert. Consulte o Capítulo 3, Infra-estrutura da SSL para mais detalhes.
Tenha os valores prontos para criar um ou mais scripts do bootstrap, dependendo da variedade de sistemas a serem configurados. Como o RHN Bootstrap oferece uma gama completa de opções de reconfiguração, você pode usá-la para gerar scripts diferentes do bootstrap para acomodar cada tipo de sistema. Por exemplo: o bootstrap-web-servers.sh pode ser usado para reconfigurar seus servidores Web, enquanto o bootstrap-app-servers.sh pode lidar com os servidores de aplicações. Consulte a Seção 5.4, “Configurando as opções do RHN Bootstrap” para obter a lista completa.
5.2. Gerando os Scripts do RHN Bootstraps
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 a opção --activation-keys para incluir as chaves, levando em consideração os requisitos do serviço identificados na Seção 5.1, “Preparando para uma instalação de RHN Bootstrap”. 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 clientes. 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 clientes 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 clientes. Assim como a administração da configuração, esta funcionalidade auxilia a reconfiguração de sistemas múltiplos.
rhn-bootstrap --activation-keys KEY1,KEY2 \
--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \ --allow-config-actions \
--allow-remote-commands
Obviamente, inclua os nomes reais das chaves. Consulte a Seção 5.4, “Configurando as opções do RHN Bootstrap” para a lista completa de opções.
5.3. Utilizando o Script do RHN Bootstrap
Finalmente, quando você finalizar a preparação do script, está pronto para rodá-lo. Autentique-se no RHN Satellite Server or RHN Proxy Server, navegue para o diretório
/var/www/htm l/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 clientes. Autentique-se em cada uma das máquinas clientes 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 clientes, todos devem estar configurados para usar o Servidor da RHN.
5.4. Configurando as opções do RHN Bootstrap
O RHN Bootstrap oferece diversas opções de linha de comando para criar scripts do boostrap. Apesar das descrições destas opções possam ser encontradas dentro da tabela seguinte, assegure-se que elas estejam disponíveis na versão da ferramenta instalada em assegure-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 Substitui a configuração do nome do arquivo.. O padrão é client-config-overrides.txt
--script=SCRIPT Nome do arquivo do script do bootstrap. O padrão é bootstrap.sh. --hostnam e=HOSTNAME O nome de domínio totalmente
qualificado (fully qualified domain name, FQDN) do servidor ao qual os
sistemas clientes se conectarã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 clientes, no formato m áquina:porta. Um valor "" desativa esta configuração. --http-proxy-usernam e=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-rem ote-com m ands 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 padrão é /var/www/html/pub/.
--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.
Capítulo 6. Escrevendo o script da configuração RHN
Bootstrap 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 os comandos aprendidos no capítulo anterior e colocá-los na ordem mais sensível possível, conseguimos produzir o script abaixo:
# 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
Nota
Lembre-se que o sexto passo é documentado aqui, pois ele se refere aos sistemas rodando o Red Hat Enterprise 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. 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 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, seria muito fácil repetir por uma lista destes sistemas e executar o comando remotamente em todos sistemas. Este script seria também perfeito como um adicional ao pós seção de um script kickstart existente.
Capítulo 7. 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 Servers , 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 o Red Hat Update Agent e 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
@ 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
Exemplo de Script 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 clientes para acessar seu RHN Server de maneira mais fácil. Ele foi disponibilizado para os clientes de RHN Satellite Server and 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 clientes.
Reveja a amostra e seus comentários, iniciando pela marca de cerquilha (#) para obter mais detalhes. Siga os passos no 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 -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
