12.4. Registro e Atualizações
Agora que você instalou os pacotes específicos do RHN, implementou a SSL e reconfigurou seus sistemas cliente para conectar ao RHN Satellite, está pronto para iniciar o registro dos sistemas e obter atualizações.
12.4.1. Registrando Sistemas Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Esta seção descreve o processo de registro dos sistemas UNIX no RHN. Você deve usar o
rhnreg_ks
para tanto. O uso de chaves de ativação para registrar seus sistemas é opcional. Estas chaves permitem que você pré-determine a configuração no RHN, como canais base e grupos de sistemas, e aplicar estas automaticamente aos sistemas durante seu registro.
Como a geração e o uso das chaves de ativação é coberto extensivamente em outros capítulos, esta seção concentra-se nas diferenças na implementação destas atividades em variantes do UNIX. Consulte a Seção 7.4.6.1, “Administrando Chaves de Ativação” para uma descrição completa deste processo.
Para registrar sistemas UNIX com o seu RHN Satellite, execute as seguintes tarefas, nesta ordem:
- Autentique-se na interface Web do Satellite e clique na aba Sistemas na barra de navegação superior, seguido de Chaves de Ativação na barra de navegação esquerda. Em seguida, clique no link criar nova chave no canto superior direito da página.
- Na página seguinte, selecione o canal base que você criou no final da Seção 12.2, “Preparação/Configuração do Servidor Satellite”.
- Após criar a chave, clique em seu nome na lista Activation Keys para aprimorar sua configuração no RHN, associando canais de software e de configuração e grupos de sistemas.
- Abra um terminal no sistema cliente a registrar e alterne o usuário para root.
- Use o
rhnreg_ks
com a opção--activationkey
para registrar o cliente com o Satellite. A seqüência de caracteres representando a chave pode ser copiada diretamente da lista Chaves de Ativação no website. O comando será parecido com o seguinte:rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af
rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Retorne ao site, clique no nome da chave de ativação e verifique se o sistema novo aparece na aba Activated Systems.
12.4.2. Obtendo Atualizações Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Atualizações de pacotes no UNIX são efetuadas de maneira bem diferente do Linux. Por exemplo, o Solaris baseia-se em Clusters de Patches para atualizar pacotes múltiplos de uma só vez, enquanto os sistemas operacionais da Red Hat usam atualizações de erratas para associar atualizações a pacotes específicos. Além disso, o Solaris usa arquivos de resposta (answer files) para automatizar as instalações interativas de pacotes, algo que o Linux não compreende. A Red Hat, por sua vez, oferece o conceito de pacotes fonte. Por esta razão, esta seção procura destacar as diferenças no uso das ferramentas do RHN em sistemas UNIX. Nota: o RHN não suporta os arquivos de resposta do Solaris na versão atual, mas tal suporte está planejado para versões posteriores.
Apesar das diferenças inerentes, como a falta de Erratas, as interfaces de administração dos canais e pacotes no site do RHN para o Satellite funcionam de maneira semelhante nos sistemas UNIX. Todos os canais de software desenvolvidos para as variantes do UNIX podem ser criados praticamente da mesma forma que os canais personalizados descritos no RHN Channel Management Guide. A diferença mais significativa é a arquitetura. Ao criar um canal de software para UNIX, selecionea arquitetura do canal base apropriada aos sistemas sendo servidos.
Conseqüentemente, a Red Hat recomenda que você divida seus pacotes em canais base e canais filho, dependendo de sua natureza. Por exemplo: no Solaris, os pacotes de instalação devem estar no canal base, enquanto os patches e Clusters de Patches devem estar num canal filho do canal base do Solaris. Os pacotes extras de instalação podem estar num canal filho Extras separado.
O RHN trata os patches de maneira similar; são listados e instalados da mesma maneira e com a mesma interface dos pacotes normais. Os patches são 'numerados' pelo Solaris e terão nomes como "patch-solaris-108434". A versão de um patch do Solaris é extraída dos metadados do Solaris original, e o release é sempre 1.
Clusters de Patches são conjuntos de patches instalados como uma unidade. O RHN mantém o registro da última vez em que um Cluster de Patches foi instalado com sucesso num sistema. No entanto, os Clusters de Patches não são acompanhados no cliente como entidades instaladas, portanto não aparecem na lista de pacotes ou de pacotes instalados. Os nomes dos Clusters de Patches se assemelham a "patch-cluster-solaris-7_Recommended". A versão é um string da data, como "20040206", e o release é sempre 1 e o marco sempre 0.
12.4.2.1. Carregando Pacotes no Satellite Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
O RHN não oferece conteúdo UNIX. Quaisquer arquivos de pacotes, atualizações (patches) e conjuntos de atualizações (patch clusters) do Solaris devem ser carregados no Satellite a partir do sistema cliente em um formato que o Satellite entenda. O pacote pode então ser gerenciado e distribuído para outros sistemas. O RHN criou o
solaris2mpm
para converter arquivos de pacotes, atualizações e conjuntos de atualizações do Solaris para um formato que o Satellite possa usar.
12.4.2.1.1. solaris2mpm Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Conforme mencionado brevemente na seção Seção 12.1.4, “Diferenças nas Funcionalidades”, o
solaris2mpm
faz parte do para o Solaris RHN Push. O conteúdo que é servido em um canal Solaris no Satellite deve primeiro ser convertido para o formato .mpm.
Um arquivo .mpm contém uma descrição dos dados do pacote e o pacote ou atualização em si. O comando solaris2mpm deve ser executado no cliente, nunca no Satellite.
Nota
O solaris2mpm requer que espaço livre igual a três vezes o tamanho de qualquer pacote, atualização, ou conjunto de atualizações que esteja sendo convertido. Normalmente, espaço em
/tmp/
será usado para esta finalidade. Entretanto, a opção --tempdir
permite que você especifique outro diretório se necessário.
Múltiplos arquivos podem ser especificados na linha de comando do solaris2mpm. Abaixo encontra-se um exemplo:
Uma vez que nenhum outro diretório foi especificado, os arquivos .mpm resultantes foram colocados no diretório /tmp/. Note que o nome dos arquivos .mpm resultantes inclui a arquitetura do cliente no qual o arquivo foi criado, ou seja, Sparc Solaris, neste caso. O formato genérico de nomes de arquivos .mpm é:
name-version-release.arch.mpm
name-version-release.arch.mpm
Conjuntos de atualizações (patch clusters) são "inflados" — arquivos .mpm são gerados para cada arquivo de atualização no conjunto, assim como um "meta" arquivo .mpm de nível superior contendo informação sobre o conjunto de atualizações como um todo.
Abaixo estão as opções do solaris2mpm:
Opção | Descrição |
---|---|
--version
|
Exibe o número da versão do aplicativo e fecha
|
-h, --help
|
Exibe esta informação e fecha
|
-?, --usage
|
Exibe informação sobre como usar o aplicativo e fecha
|
--tempdir=<tempdir>
|
Diretório temporário a ser usado
|
--select-arch=<arch>
|
Seleciona a arquitetura (i386 ou Sparc) para pacotes de multi-arquitetura.
|
12.4.2.1.2. rhnpush com arquivos .mpm Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
A versão Solaris do
rhnpush
funciona como o utilitário padrão, mas com a funcionalidade adicional de poder lidar com arquivos .mpm Abaixo está um exemplo de utilização:
Nota
Arquivos .mpm de conjuntos de atualizações devem ser servidos ou ao mesmo tempo ou após — nunca antes — do que arquivos .mpm para as atualizações contidas naquele conjunto.
Use o solaris2mpm em cada um dos pacotes, atualizações, ou conjuntos de atualizações que você deseja gerenciar através do Satellite, e então use o RHN Push para carregá-los no canal que você criou para eles.
12.4.2.2. Atualizando Através do Site Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Para instalar pacotes ou patches num sistema separado, clique no nome do sistema na categoria Systems, selecione os pacotes nas listas Upgrade ou Install da aba Packages ou Patches e clique em .
Para rodar um comando remoto enquanto instalar o pacote, clique em Seção 12.5, “Comandos Remotos” para instruções.
ao invés de . Consulte a
Para instalar pacotes ou patches em sistemas múltiplos de uma só vez, selecione os sistemas e clique em System Set Manager na barra de navegação esquerda. Em seguida, na aba Packages, selecione os pacotes nas listas Upgrade ou Install e clique em . Para completar a ação, agende as atualizações.
12.4.2.3. rhnsd Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Em sistemas Red Hat Enterprise Linux. o daemon
rhnsd
, o qual faz com que os sistemas clientes autentiquem-se no RHN, inicia automaticamente durante a inicialização do sistema. Em sistemas Solaris, o rhnsd
não inicia durante a inicialização do sistema, e pode ser iniciado na linha de comandos da seguinte maneira:
rhnsd --foreground --interval=240
rhnsd --foreground --interval=240
A localização padrão do
rhnsd
é /opt/redhat/rhn/solaris/usr/sbin/rhnsd
. As opções disponíveis para o rhnsd
no Solaris estão listadas abaixo:
Opção | Descrição |
---|---|
-f, --foreground
|
Executa em primeiro plano
|
-i, --interval=MINS
|
Conecta no Red Hat Network a cada MINS minutos
|
-v, --verbose
|
Registra todas as ações no syslog
|
-h, --help
|
Exibe esta lista de ajuda
|
-u, --usage
|
Exibe esta lista de ajuda
|
-V, --version
|
Exibe a versão do programa
|
12.4.2.4. Atualizando pela Linha de Comando Copiar o linkLink copiado para a área de transferência!
Copiar o linkLink copiado para a área de transferência!
Como no site, o uso do Red Hat Update Agent na linha de comando é afetado pelas limitações da administração de pacotes do UNIX. Sendo assim, a maioria das funções centrais ainda pode ser executada através do comando
up2date
. A diferença mais significativa é a ausência de todas as opções relacionadas aos arquivos fonte. Consulte a Tabela 12.4, “Argumentos da Linha de Comando do Agente de Atualizações” para ver uma lista precisa das opções disponíveis nos sistemas UNIX.
A versão de linha de comando do Red Hat Update Agent aceita os seguintes argumentos nos sistemas UNIX:
Argumento | Descrição |
---|---|
--version | Exibe as informações da versão do programa. |
-h , --help | Exibe esta mensagem de ajuda e fecha. |
-v , --verbose | Exibe resultado adicional. |
-l , --list | Lista as versões mais recentes de todos os pacotes instalados. |
-p , --packages | Atualiza os pacotes associados a este Perfil de Sistema. |
--hardware | Atualiza o perfil de hardware deste sistema no RHN. |
--showall | Lista todos os pacotes disponíveis para download. |
--show-available | Lista todos os pacotes disponíveis não instalados no momento. |
--show-orphans | Lista todos os pacotes instalados, que não fazem parte dos canais aos quais o sistema está registrado. |
--show-channels | Exibe os nomes dos canais junto aos nomes dos pacotes, quando for apropriado. |
--installall | Instala todos os pacotes disponíveis. Use com --channel . |
--channel=CHANNEL | Especifica quais canais devem ser usado para atualizações usando etiquetas de canais. |
--get | Obtém o pacote especificado sem resolver as dependências. |