Red Hat Network Satellite 5.4 Guia de Configuração do Cliente

Transcrição

1 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente Red Hat Network Satellite Edição 1 Landmann

2 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente Red Hat Network Satellite Edição 1 Landmann rlandmann@redhat.co m

3 Nota Legal Copyright 2010 Red Hat, Inc. T his 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. T he 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 Bem vindo ao Guia de Configuração do Red Hat Network Satellite Client

4 Índice Índice. Capítulo Introdução Capítulo Aplicações Cliente Empregando os RPMs Cliente Mais Recentes da Red Hat Network Configurando as Aplicações Cliente Registrando com Chaves de Ativação Usando a Opção up2date --configure Atualizando os Arquivos de Configuração Manualmente Implementando a T ransferência (failover) de Servidores O Applet do Atualizador de Pacotes Configurando a Red Hat Network Alert Notification T ool com Satellite 9. Capítulo Infra-estrutura da... SSL Uma Breve Introdução à SSL A RHN SSL Maintenance Tool Geração da SSL Explicada Opções da RHN SSL Maintenance Tool Gerando o Par de Chaves SSL da Autoridade Certificadora (Certificate Authority) Gerando Conjuntos de Chaves SSL do Servidor Web Empregando o Certificado Público SSL da CA nos Clientes Configurando Sistemas Cliente 19. Capítulo Importando Chaves Padronizadas GPG Capítulo Usando o. RHN..... Bootstrap Preparação Geração Uso do Script Opções do RHN Bootstrap 23. Capítulo Escrevendo o.. script da... configuração manualmente Capítulo Implementar o. Kickstart Script de... Amostra de... Bootstrap Histórico de... Revisão Índice Remissivo Símbolos 37 A 37 B 37 C 37 G 38 K 38 R 38 S 39 1

5 2 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente

6 Capítulo 1. Introdução Capítulo 1. 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. 3

7 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente Capítulo 2. Aplicações Cliente Para poder utilizar a maioria das funcionalidades da Red Hat Network, como por exemplo registrar-se 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 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. T his 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. T he administrator has populated the /var/www/htm l/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

8 Capítulo 2. Aplicações Cliente T enha em mente que a arquitetura (neste caso, i386) talvez precise ser alterada, dependendo dos sistemas a servir 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.) T odos 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 T ransferência (failover) de Servidores for instructions on enabling this feature. T he next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. T o see how virtually all reconfiguration can be scripted, see Capítulo 6, Escrevendo o script da configuração manualmente 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: rpm -Uvh 5

9 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente 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 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 bash && rhnreg_ks --activation-key my_key --serverurl T he 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. T odas as outras configurações, tal como a URL do servidor, são transferidas corretamente 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 (m an 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 ain.com/xmlrpc. Mantenha /XMLRPC no final. Quanto terminar, clique em OK. 6

10 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. T his 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 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: serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= 7

11 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente 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) Implementando a Transferência (failover) de Servidores A partir do up2date , 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= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= 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 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 a partir do applet, clicando no ícone de notificação e escolhendo a partir das 8

12 Capítulo 2. Aplicações Cliente 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 T ool 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 T ool. 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 T ool 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. 9

13 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente 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, 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 T ool, 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 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. T ecnicamente, 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. T odos 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 SSL, especificamente ligado ao nome da máquina deste servidor e gerado usando suas próprias chave 10

14 Capítulo 3. Infra-estrutura da SSL 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 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 rhns-certs-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 T ool 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. T ambé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. 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 11

15 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente 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 Geração da SSL Explicada Os principais benefícios de usar a RHN SSL Maintenance T ool 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 T ool 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. T alvez, 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. 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 12

16 Capítulo 3. Infra-estrutura da SSL 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: m an 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: 13

17 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente T abela 3.1. Opções da SSL da Autoridade Certificadora (CA) (rhn-ssl-tool --gen-ca -- help) Opção --gen-ca -h, --help -f, --force -p=, --password=senha Descrição 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. 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). Criar forçadamente uma nova chave privada e/ou certificado público da CA. 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 é./ssl-build. --ca-key=filename --ca-cert=filename --cert-expiration=ca_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit --set-com m on-nam e=hostname --set-em ail= --rpm-packager=packager --rpm-vendor=vendor -v, --verbose O nome do arquivo da chave privada da CA. O default é RHN-ORG-PRIVAT E-SSL- KEY. O nome do arquivo do certificado público da CA. O default é RHN-ORG-TRUSTED- SSL-CERT. 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 ) A código de duas letras do país. O defaul é US. O estado ou província da CA. O default é ''. A cidade ou localidade. O default é ''. A empresa ou corporação, como Red Hat. O default é Example Corp. Inc. A unidade da empresa, como RHN. O default é ''. Não é tipicamente definido para a CA. - O nome comum. Não é tipicamente definido para a CA. - O endereço de . Empacotador do RPM gerado, tal como "Admin da RHN (adminrhn@exemplo.com.br)." Distribuidor do RPM gerado, tal como "Exemplo TI Corp." Apresenta mensagem verbosa. 14

18 Capítulo 3. Infra-estrutura da SSL --ca-cert-rpm =CA_CERT_RPM --key-only --cert-only --rpm-only --no-rpm Acumulativa - adicionar "v"s resulta em mais detalhes. Raramente alterado - nome do RPM que armazena o certificado da CA (o nome de arquivo base, não o filename-versionrelease.noarch.rpm). Raramante usada - Gera somente uma chave privada da CA. Reveja --gen-ca - -key-only --help para mais informações. Rarament usada - Gera somente o certificado público da CA. Reveja --genca --cert-only --help para mais informações. Raramente usada - Gera somente um RPM para ser empregado. Reveja --gen-ca - -rpm-only --help para mais informações. 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: 15

19 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente T abela 3.2. Opções SSL do Servidor Web (rhn-ssl-tool --gen-server --help) Opção --gen-server -h, --help -p=, --password=senha Descrição Gera o conjunto de chaves, o RPM e o arquivo tar da SSL do servidor Web. 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. 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 é./ssl-build. --server-key=filename --server-cert-req=filename --server-cert=filename --startdate=yymmddhhmmssz --cert-expiration=server_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit --set-hostnam e=hostname --set-em ail= --rpm-packager=packager O nome do arquivo da chave privada SSL do servidor Web. O default é server.key. O nome do arquivo do pedido do certificado SSL do servidor Web. O default é server.csr. O nome do arquivo do certificado SSL do servidor Web. O default é server.crt. 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. 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 ). A código de duas letras do país. O defaul é US. O estado ou a província. O default é North Carolina. A cidade ou localidade. O default é Raleigh. A empresa ou corporação, tal como Red Hat. O default é Example Corp. Inc. A unidade da empresa, tal como RHN. O default é unit. 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. O endereço de do contato do certificado. O default é admin@example.corp. Empacotador do RPM gerado, tal como 16

20 Capítulo 3. Infra-estrutura da SSL --rpm-vendor=vendor -v, --verbose --key-only --cert-req-only --cert-only --rpm-only --no-rpm --server-rpm =SERVER_RPM --server-tar=server_tar "Admin da RHN Distribuidor do RPM gerado, tal como "Exemplo TI Corp." Apresenta mensagem verbosa. Acumulativa - adicionar "v"s resulta em mais detalhes. Raramente usada - Gera somente uma chave privada do servidor. Reveja --genserver --key-only--help para mais informações. Raramente usada - Gera somente um pedido de certificado do servidor. Reveja - -gen-server --cert-req-only -- help para mais informações. Raramente usada - Gera somente um certificado do servidor. Reveja --genserver --cert-only --help para mais informações. Raramente usada - Gera somente um RPM para ser empregado. Reveja --genserver --rpm-only --help para mais informações. Raramente usada - Conduz todos os passos relativos ao servidor exceto pela geração do 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). 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-version-release.tar) 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. O processo de criação automaticamente cria o par de chaves e o RPM público para distribuição aos clientes. T odos 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: 17

21 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente 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-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 cliente. 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 cliente. Consulte a Seção 3.3, Empregando o Certificado Público SSL da CA nos Clientes 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-hostnam e é 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/sslbuild/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- ="admin@ example.com" \ --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 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. 18

22 Capítulo 3. Infra-estrutura da SSL 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/htm l/pub/ do Servidor RHN. Este diretório público pode ser facilmente inspecionado através de qualquer navegador web: 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 wget 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 \ Confirme o nome real do certificado ou RPM antes de rodar estes comandos 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. 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. 19

23 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente Capítulo 4. 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 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. 20

24 Capítulo 5. Usando o RHN Bootstrap Capítulo 5. 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/htm l/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 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 Sistem as 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. Red Hat recommends your RPMs be signed by a custom GNU Privacy Guard (GPG) key. Make the 21

25 Red Hat Network Satellite 5.4 Guia de Configuração do Cliente 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/htm l/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 bootstrapapp-servers.sh can handle the application servers. Consult Seção 5.4, Opções do RHN Bootstrap for the complete list 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-rem ote-com m ands 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 Uso do Script Finalmente, quando você finalizar a preparação do script, está pronto para rodá-lo. Autentique-se no RHN Satellite Server ou no RHN Proxy Server, navegue para o diretório 22