Bem-vindo ao Guia de Referência do Red Hat Satellite 5.6. O Guia de Referência do Red Hat Satellite o guiará através dos recursos avançados do servidor do Satellite.
Copiar o linkLink copiado para a área de transferência!
A audiência alvo para este guia inclui os administradores de sistema dos quais possuem por objetivo gerenciar atualizações para sistemas com uma rede interna.
Copiar o linkLink copiado para a área de transferência!
Além das opções providas no site do Red Hat Satellite, existem duas ferramentas de linha de comando para administrar os arquivos de configuração de um sistema: o Red Hat Network Configuration Client (Red Hat Network Cliente de Configuração) e o Red Hat Configuration Manager (Red Hat Network Gerenciador de Configuração). Há uma ferramenta complementar, Red Hat Network Actions Control (Red Hat Network Controle de Ações), usada para habilitar e desabilitar a administração de configuração nos sistemas cliente. Se você ainda não tem estas ferramentas instaladas, pode encontrá-las no canal filho Red Hat Network Tools (Ferramentas Red Hat Network) de seu sistema operacional.
Nota
Sempre que um arquivo de configuração é implementado através de um website, é criado um backup do arquivo anterior incluindo seu caminho completo no diretório /var/lib/rhncfg/backups/ do sistema em questão. O backup mantém seu nome de arquivo, porém com uma extensão .rhn-cfg-backup anexada.
Copiar o linkLink copiado para a área de transferência!
A aplicação Red Hat Network Actions Control (rhn-actions-control) é usada para habilitar e desabilitar a administração de configuração de um sistema. Os sistemas clientes não podem ser administrados desta maneira por padrão. Com esta ferramenta, os Administradores de Sistema podem habilitar ou desabilitar modos específicos de ações permitidas, como implementar um arquivo de configuração ao sistema ou carregar (upload) um arquivo do sistema, utlizando o diff para descobrir o que é administrado num sistema contra o que está disponível no momento ou então permitir rodar comandos remotos arbitrários. Estes modos diversos são habilitados/desabilitados ao inserir/remover arquivos e diretórios no diretório /etc/sysconfig/rhn/allowed-actions/. Devido às permissões padrões do diretório /etc/sysconfig/rhn/, O Controle de Ações do Red Hat Network deverá ser executado por alguém com acesso root.
Copiar o linkLink copiado para a área de transferência!
Há uma página man disponível, como ocorre com a maioria das ferramentas da linha de comando. Simplesmente decida quais as ações agendadas do Red Hat Network devem ser habilitadas para administradores de sistemas. Estas opções habilitam os vários modos de ações agendadas:
Expand
Tabela 1.1. opções rhn-actions-control
Opção
Descrição
--enable-deploy
Permite ao rhncfg-client empregar arquivos.
--enable-diff
Permite ao rhncfg-client executar diff em arquivos.
--enable-upload
Permite ao rhncfg-client fazer upload de arquivos.
--enable-mtime-upload
Permite ao rhncfg-client fazer upload do mtime.
--enable-all
Permite ao rhncfg-client habilitar tudo.
--enable-run
Habilita script.run
--disable-deploy
Desabilita a implementação.
--disable-diff
Desabilita o diff
--disable-upload
Desabilita o upload
--disable-mtime-upload
Desabilita o upload do mtime
--disable-all
Desabilita todas as opções
--disable-run
Desabilita o script.run
--report
Relata se os modos estão habilitados ou desabilitados
-f, --force
Força a operação sem questionar
-h, --help
exibe a mensagem de ajuda e fecha
Quando o modo é definido, seu sistema fica pronto para o gerenciamento de configuração através do Red Hat Satellite. O rhn-actions-control --enable-all é uma opção comum.
Copiar o linkLink copiado para a área de transferência!
Como o nome implica, o Red Hat Network Configuration Client (rhncfg-client) é instalado e executado através de um sistema cliente separado. A partir deste, você pode obter o conhecimento sobre como o Red Hat Network emprega os arquivos de configuração nos clientes.
O Red Hat Network Configuration Client oferece estes modos principais: listar (list), obter (get), canais (channels), diff e verificar (verify).
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Estes são os arquivos de configuração que se aplicam ao seu sistema. Entretanto, pode haver arquivos duplicados em outros canais. Por exemplo: invoque o seguinte comando:
rhncfg-manager list config-channel-14
rhncfg-manager list config-channel-14
Copy to ClipboardCopied!Toggle word wrapToggle overflow
e observe o seguinte resultado:
Files in config channel 'config-channel-14' /etc/example-config.txt /etc/rhn/rhn.conf
Files in config channel 'config-channel-14' /etc/example-config.txt /etc/rhn/rhn.conf
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Então, você pode se perguntar onde foi parar a segunda versão do /etc/example-config.txt. A posição do arquivo /etc/example-config.txt no config-channel-17 era mais alta que a posição do mesmo arquivo no config-channel-14. Consequentemente, a versão do arquivo de configuração no config-channel-14 não é empregada no sistema, apesar do arquivo ainda constar do canal. O comando rhncfg-client não lista o arquivo porque não será empregado neste sistema.
Copiar o linkLink copiado para a área de transferência!
Para fazer o download do arquivo de configuração mais importante para a máquina, execute o comando:
rhncfg-client get /etc/example-config.txt
rhncfg-client get /etc/example-config.txt
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Você deve observar um resultado parecido com:
Implementando /etc/example-config.txt
Implementando /etc/example-config.txt
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Veja o conteúdo do arquivo com less ou um outro paginador. Note que o arquivo é selecionado como o mais importante baseado na posição do canal de configuração que o contém. Isso é feito na aba Configuration (Configuração) da página System Details (Detalhes do Sistema).
Copiar o linkLink copiado para a área de transferência!
Para ver as diferenças entre os arquivos de configuração empregados no sistema e aqueles armazenados no Red Hat Network, submeta o comando:
rhncfg-client diff
rhncfg-client diff
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O resultado se parece com:
rhncfg-client diff
--- /etc/test
+++ /etc/test 2013-08-28 00:14:49.405152824 +1000
@@ -1 +1,2 @@
This is the first line
+This is the second line added
[root@testsatellite root]# rhncfg-client diff
--- /etc/test
+++ /etc/test 2013-08-28 00:14:49.405152824 +1000
@@ -1 +1,2 @@
This is the first line
+This is the second line added
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além disso, você pode incluir a opção --topdir para comparar arquivos de configuração do Red Hat Network com aqueles situados numa localização arbitrária (e não usada) do sistema cliente, como:
rhncfg-client diff --topdir /home/test/blah/ /usr/bin/diff: /home/test/blah/etc/example-config.txt: No such file or directory /usr/bin/diff: /home/test/blah/var/spool/aalib.rpm: No such file or directory
[root@ root]# rhncfg-client diff --topdir /home/test/blah/ /usr/bin/diff: /home/test/blah/etc/example-config.txt: No such file or directory /usr/bin/diff: /home/test/blah/var/spool/aalib.rpm: No such file or directory
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O arquivo example-config.txt está modificado localmente, enquanto o aalib.rpm não.
A tabela seguinte lista as opções do rhncfg-client verify:
Expand
Tabela 1.3. opções do rhncfg-client verify
Opção
Descrição
-v, --verbose
Aumenta a quantidade de detalhes do resultado. Apresenta as diferenças do modo, permissões do proprietário e do grupo, do arquivo de configuração específico.
Copiar o linkLink copiado para a área de transferência!
Ao contrário do Red Hat Network Configuration Client, the Red Hat Network Configuration Manager (rhncfg-manager) é desenvolvido para manter o repositório central de arquivos e canais de configuração do RHN e não aqueles localizados nos sistemas cliente. Esta ferramenta oferece uma alternativa de linha de comando às funcionalidades de administração de configuração do site do Red Hat Network, assim como a habilidade de elaborar scripts para partes ou para toda a manutenção relacionada.
Seu uso é direcionado aos Administradores de Configuração e requer um nome de usuário e senha do Red Hat Network que tenham as permissões apropriadas definidas. O nome de usuário pode ser especificado em /etc/sysconfig/rhn/rhncfg-manager.conf ou na seção [rhncfg-manager] de ~/.rhncfgrc.
Quando o Red Hat Network Configuration Manager é executado como root, tenta trazer valores de configuração necessários do Red Hat Update Agent. Quando executado com qualquer outro usuário além de root, talvez seja preciso efetuar alterações de configuração no arquivo ~/.rhncfgrc. O arquivo da sessão é guardado no cache de ~/.rhncfg-manager-session a fim de evitar a autenticação para cada comando.
O tempo limite padrão do Red Hat Network Configuration Manager, é 30 minutos. Para alterar este valor, adicione a opção server.session_lifetime e o novo valor ao arquivo /etc/rhn/rhn.conf no servidor rodando o administrador, como:
server.session_lifetime = 120
server.session_lifetime = 120
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O Red Hat Network Configuration Manager oferece estes modos principais: adicionar (add), criar canal (create-channel), diferenciação (diff), diferenciação entre revisões (diff-revisions), download de canal (download-channel), obter (get), listar (list), listar canais (list-channels), remover (remove), remover canal (remove-channel), revisões (revisions), atualizar (update) e fazer upload de canal (upload-channel).
Cada modo oferece seu próprio conjunto de permissões, que pode ser visto ao executar o comando seguinte:
rhncfg-manager mode --help
rhncfg-manager mode --help
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Substitua mode pelo nome do modo a ser inspecionado:
rhncfg-manager diff-revisions --help
rhncfg-manager diff-revisions --help
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além da etiqueta do canal e do caminho para o arquivo necessário, você deve usar as opções disponíveis para modificar o arquivo durante sua adição. Por exemplo, você pode alterar o caminho e o nome do arquivo, incluindo a opção --dest-file no comando. Por exemplo:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O resultado se parece com:
Alocando para o canal example-channel
Arquivo local >/path/to/file -> arquivo remoto /new/path/to/file.txt
Alocando para o canal example-channel
Arquivo local >/path/to/file -> arquivo remoto /new/path/to/file.txt
Copy to ClipboardCopied!Toggle word wrapToggle overflow
A tabela seguinte lista as opções do rhncfg-manager add:
Expand
Tabela 1.4. opções do rhncfg-manager add
Opção
Descrição
-c CHANNEL --channel=CHANNEL
Faz o upload de arquivos para este canal de configuração
-d DEST_FILE --dest-file=DEST_FILE
Faz o upload do arquivo conforme este caminho
--delim-start=DELIM_START
Inicia o delimitador para intercalar variáveis
--delim-end=DELIM_END
Finaliza o delimitador para intercalar variáveis
-i, --ignore-missing
Ignora arquivos locais faltando
--selinux-context=SELINUX_CONTEXT
Sobrescreve o contexto do SELinux
-h, --help
exibe a mensagem de ajuda e fecha
Nota
Por padrão, o tamanho máximo de arquivo para arquivos de configuração é 128KB. Se você precisar modificar este valor, encontre ou crie a seguinte linha no arquivo /etc/rhn/rhn.conf:
web.maximum_config_file_size=128
web.maximum_config_file_size=128
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além disso, encontre ou crie a seguinte linha no arquivo /etc/rhn/rhn.conf:
maximum_config_file_size=128
maximum_config_file_size=128
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Em ambos locais, mude o valor de 128 para qualquer limite que você deseja em bytes.
Copiar o linkLink copiado para a área de transferência!
Para comparar versões diferentes de um arquivo dentre canais e revisões, use a opção -r para indicar qual revisão do arquivo deve ser comparada e a opção -n para identificar os dois canais a serem verificados. Consulte a Seção 1.1.3.11, “Determinando o Número de Revisões do Arquivo” para instruções. Especifique somente o nome de um arquivo aqui, já que você está comparando o arquivo a uma outra versão do mesmo. Por exemplo:
Copiar o linkLink copiado para a área de transferência!
Para descobrir quantas revisões (as revisões vão de 1 a N, sendo N um número inteiro maior que 0) de um arquivo/caminho existem num canal, execute o seguinte comando:
Copiar o linkLink copiado para a área de transferência!
Para criar uma nova revisão de um arquivo num canal (ou adicionar a primeira revisão neste canal, caso nenhuma exista antes para o caminho provido), execute o seguinte comando:
Copiar o linkLink copiado para a área de transferência!
O direito ao Monitoring da Red Hat Network permite a você executar diversas ações desenvolvidas para manter seus sistemas rodando apropriada e eficientemente. Através deste, você pode monitorar os recursos do sistema, serviços de rede, bancos de dados e também aplicações padrões e personalizadas.
O Monitoramento oferece informações em tempo real e a história de alterações do estado, assim como dados métricos específicos. Ele fornece notificação de falhas de sistema e degradação de desempenho antes que ele se torne crítico. Ele também fornece informações que assiste o planejamento de capacidade e a correlação de eventos. Por exemplo: os resultados de uma detecção registrando o uso da CPU entre sistemas assistiria ao balancear as cargas nestes sistemas.
Existem dois componentes para monitoramento do sistema: o monitoramento de sistema e o monitoramento scout. O sistema de monitoramento é instalado no Satellite e realiza funções em segundo plano, como armazenar dados de monitoramento e como agir nele. O monitoramento scout executa todas as probes e coleta dados de monitoramento. O monitoramento scout pode ser habilitado para executar em um Satellite ou em sistemas Red Hat Satellite Proxy. O monitoramento scout no Proxy lhe permite trabalhar sem carga no Satellite, fornecendo escalabilidade para as probes.
O Monitoramento permite estabelecer os métodos de conexão, instalar probes em sistemas, rever periodicamente os estados de todas as probes e gerar relatórios com dados históricos de um sistema ou serviço. Esta seção procura identificar tarefas comuns associadas ao direito de Monitoramento. Lembre-se: praticamente todas as alterações que afetam sua infra-estrutura Monitoring devem ser finalizadas ao atualizar sua configuração através da página Scout Config Push.
Copiar o linkLink copiado para a área de transferência!
Antes de tentar implementar o serviço de Monitoramento do Red Hat Network em sua infra-estrutura, assegure-se que você tenha todas as ferramentas necessárias. No mínimo, você precisa:
Direitos ao Monitoramento - Estes direitos são necessários para todos os sistemas a serem monitorados. O Monitoramento é suportado somente em sistemas Red Hat Enterprise Linux.
Red Hat Satellite com Monitoramento - Sistemas com Monitoring devem ser conectados a um Satellite com um sistema operacional base do Red Hat Enterprise Linux 5 ou posteriores.
Administrador de Monitoramento - Esta função (role) deve ser agregada a usuários que instalem detecções (probes), criem métodos de notificação ou alterem a infra-estrutura de monitoramento de qualquer forma. Lembre-se, o Satellite Administrator automaticamente herda todas as funções dentro de uma organização e pode portanto conduzir estas tarefas. Agregue esta função através da página User Details (Detalhes do Usuário) do usuário em questão.
Red Hat Network monitoring daemon - Este daemon é necessário, juntamente à chave SSH, para o agente (scout) em sistemas monitorados para executar os processos internos. Você pode, no entanto, rodar estas probes usando o daemon SSH (sshd) do sistema. Consulte a Seção 1.2.2, “Configurando o Red Hat Network Monitoring Daemon (rhnmd) ” para obter instruções de instalação e uma lista rápida das probes que requerem esta conexão segura. Consulte o Apêndice A, Probes (detecções) para uma lista completa das probes disponíveis.
Habilitar Monitoramento
O Monitoramento é desativado por padrão e precisa ser ativado antes que possa ser usado.
Efetue o login como um usuário com previlégios de Administrador do Satellite e vá até Admin → Configuração do Red Hat Satellite . Clique em Enable Monitoring e depois em Atualizar para salvar.
Reinicie os serviços para captar as mudanças. Vá para a aba reiniciar para reiniciar o Satellite. Isto fará que o Satellite fique off line por alguns minutos.
Verifique se a aba Monitoring está disponível sob o Red Hat Satellite Configuration para confirmar que o monitoring está habilitado.
Navegue até Admin → Configuração do Red Hat Satellite → Monitoramento. Clique em Habilitar Monitoramento Scout para habilitar o scout. Clique em Atualizar Config para salvar.
Nota
É recomendado que você deixe os valores de configuração como valores padrões. Sendmail precisa ser configurado para usar notificações.
Copiar o linkLink copiado para a área de transferência!
Para usufruir de seus direitos a Monitoramento ao máximo, a Red Hat sugere instalar o Red Hat Network monitoring daemon em seus sistemas clientes. Baseado no OpenSSH, o rhnmd possibilita ao Satellite comunicar-se seguramente com o sistema cliente para acessar processos internos e recuperar o estado da detecção.
Por favor note que o Red Hat Network monitoring daemon requer que os sistemas monitorados permitam conexões na porta 4545. Ao invés disso, você pode evitar abrir esta porta e instalar o daemon de uma só vez, usando o sshd. Consulte o Seção 1.2.2.2, “Configurando o SSH” para mais detalhes.
Alguns probes requerem um daemon. É necessária uma conexão criptografada, através do Red Hat Network monitoring daemon ou do sshd, nos sistemas cliente, para rodar as seguintes probes:
Linux::CPU Usage (Linux::Utilização do CPU)
Linux::Disk IO Throughput (Linux::Produção de E/S do Disco )
Linux::Disk Usage (Linux::Uso do Disco )
Linux::Inodes
Linux::Interface Traffic (Linux::Tráfego da Interface)
Linux:Load (Linux::Carga)
Linux::Memory Usage (Linux::Uso da Memória)
Linux::Process Counts by State (Linux::Contagem de Processos por Estado)
Linux::Process Count Total (Linux::Contagem Total de Processos)
Linux::Process Health (Linux::Saúde dos Processos)
Linux::Process Running (Linux::Processo em Andamento)
Linux::Swap Usage (Linux::Uso de Swap)
Linux::TCP Connections by State (Linux::Conexões TCP por Estado)
Linux::Users (Linux::Usuários)
Linux::Virtual Memory (Linux::Memória Virtual)
LogAgent::Log Pattern Match (LogAgent::Correspondência de Padrões em Registros)
LogAgent::Log Size (LogAgent::Tamanho do Registro)
Network Services::Remote Ping (Serviços de Rede::Ping Remoto)
Oracle::Client Connectivity (Oracle::Conectividade do Cliente)
General::Remote Program (Geral::Programa Remoto)
General::Remote Program with Data (Geral::Programa Remoto com Dados)
Note que todas as probes no grupo Linux têm este requisito.
Copiar o linkLink copiado para a área de transferência!
Instale o Red Hat Network monitoring daemon a fim de preparar os sistemas para o monitoramento usando as probes identificadas pelo rhnmd. Note que os passos desta seção são opcionais se você pretende usar sshd para permitir conexões seguras entre a infra-estrutura de monitoramento do Red Hat Network e os sistemas monitorados. Consulte a Seção 1.2.2.2, “Configurando o SSH” para mais instruções.
O pacote rhnmd pode ser encontrado no canal Red Hat Network Tools para todas as versões do Red Hat Enterprise Linux. Para instalá-lo:
Registre os sistemas a serem monitorados no canal Red Hat Network Tools associado ao sistema. Isto pode ser feito separadamente através da sub-aba System Details → Channels → Software ou para sistemas múltiplos de uma vez através da aba Channel Details → Target Systems aba.
Após registrados, abra a aba Channel Details → Packages e localize o pacote rhnmdrhnmd (sob 'R').
Clique no nome do pacote para abrir a página Package Details. Clique na aba Target Systems, selecione os sistemas desejados e clique em Install Packages.
Inicie o Red Hat Network monitoring daemon em todos os sistemas cliente, usando o comando:
service Red Hat Networkmd start
service Red Hat Networkmd start
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Ao adicionar probes que requeiram o daemon, aceite os valores default de Red Hat NetworkMD User e Red Hat NetworkMD Port: nocpulse e 4545, respectivamente.
Copiar o linkLink copiado para a área de transferência!
Se você deseja evitar instalar o Red Hat Network monitoring daemone abrir a porta 4545 nos sistemas cliente, pode configurar o sshd para oferecer uma conexão criptografada, necessária entre os sistemas e o Red Hat Network. Isto é especialmente recomendado se você já está com o sshd rodando. Para configurar o daemon para uso do monitoramento:
Certifique-se de que o pacote SSH esteja instalado nos sistemas a serem monitorados:
rpm -qi openssh-server
rpm -qi openssh-server
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Identifique o usuário a ser associado com o daemon. Pode ser qualquer usuário disponível no sistema, desde que a chave SSH necessária possa ser inserida no arquivo ~/.ssh/authorized_keys do usuário.
Identifique a porta usada pelo daemon, de acordo com o arquivo de configuração /etc/ssh/sshd_config. A porta default é a 22.
Copiar o linkLink copiado para a área de transferência!
Independentemente de usar o Red Hat Networkmd ou o sshd, você deve instalar a chave pública SSH do Red Hat Network monitoring daemon nos sistemas a serem monitorados para completar a conexão segura. Para instalá-la:
Navegue para a página Monitoring → Scout Config Push do site do Red Hat Network e clique no nome do Servidor Red Hat Network que monitorará o sistema cliente. A chave SSH id_dsa.pub está visível na página resultante.
Copie o string de caracteres (começando em ssh-dss e terminando com o nome da máquina do Satellite.
Selecione Sistemas do menu esquerdo e clique nas caixas de marcação próximas aos sistemas para os quais você quer enviar a chave SSH. Clique no botão Gerenciar no topo para terminar.
A partir do Gerenciador de Conjuntos do Sistema (System Set Manager), clique em Executar comandos remotos e então na caixa de texto Script, digite a seguinte linha:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Ajuste a data e hora que você quer para a ação acontecer, então clique em Agendar Comando Remoto.
Após inserir a chave e estar acessível, todas as probes (detecções) que a requerem devem permitir as conexões ssh entre a infra-estrutura de Monitoramento e o sistema monitorado. Então, você pode agendar probes requisitando o daemon de monitoramento para rodar nos sistemas recém-configurados.
Copiar o linkLink copiado para a área de transferência!
Se seu Red Hat Satellite servirá sistemas cliente com o direito à Monitoramento (Monitoring) nos quais você deseja rodar probes MySQL, você deve configurar o pacote mysql no Red Hat Satellite . Consulte o Apêndice A, Probes (detecções) para ver a lista de todas as probes disponíveis.
Registre o Satellite no canal base do Red Hat Enterprise Linux e instale o pacote mysql utilizando up2date, yum ou Red Hat Network Hosted.
Depois de finalizado, seu Satellite pode ser usado para organizar as probes de MySQL.
Copiar o linkLink copiado para a área de transferência!
Além de visualizar o estado das probes na interface do Red Hat Network, você pode ser notificado sempre que uma detecção tiver seu estado alterado. Isso é especialmente importante ao monitorar sistemas de produção de missão crítica. Por este motivo, a Red Hat recomenda a utilização desta funcionalidade.
Para ativar as notificações de probes no Red Hat Network, você deve ter identificado um servidor de troca de correspondência e um domínio durante a instalação de seu Red Hat Satellite e ter configurado o sendmail para receber e-mails apropriadamente. Consulte a seção Instalação do Guia de Instalação do Red Hat Satellite para mais detalhes.
Copiar o linkLink copiado para a área de transferência!
As notificações são enviadas através de um método de notificação ou seja, um endereço de e-mail ou pager associado a um usuário específico do Red Hat Network. Apesar do endereço ser ligado a uma conta de usuário específica, pode servir a diversos administradores através de um codenome (alias) ou lista de e-mails. Além disso, cada conta de usuário pode conter múltiplos métodos de notificação. Para criar um método de notificação:
Autentique-se no Satellite como o Satellite Administrator ou Administrador de Monitoramento.
Navegue até Usuários e selecione o username. Na página Detalhes de Usuário clique em Métodos de Notificação → criar novo método.
Indique uma etiqueta intuitiva e descritiva para o nome do método, como email diário para DBA e forneça o endereço correto do e-mail. Lembre-se: as etiquetas de todos os métodos de notificação estão disponíveis numa lista durante a criação da detecção, portanto devem ser únicas dentro de sua empresa.
Selecione a caixa de verificação, se você quiser que mensagens abreviadas sejam enviadas por email. Ester formato mais curto contém somente o estado da detecção, nome do sistema, nome da detecção, hora da mensagem e ID do envio. O formato padrão, mais longo, exibe dados adicionais no cabeçalho da mensagem, detalhes da detecção e do sistema e instruções para a resposta.
Ao terminar, clique em Criar Método (Create Method). O novo método é apresentado na aba User Details → Notification Methods e a página Notificação sob a categoria Monitoramento. Clique em seu nome para editá-lo ou apagá-lo.
Ao adicionar probes, selecione a caixa Probe Notifications e então selecione o novo método de notificação no menu suspenso. Os métodos de notificação atribuídos às probes não podem ser apagados até que sejam desassociados da detecção.
Copiar o linkLink copiado para a área de transferência!
Se você criar métodos de notificação e associá-los a probes, deve estar preparado para recebê-las. Estas notificações chegam na forma de breves mensagens de texto enviadas para endereços de e-mail especificados. Aqui está um exemplo de uma notificação por e-mail:
Subject: CRITICAL: [hostname]: Satellite: Users at 1
From: "Monitoring Satellite Notification" (rogerthat01@redhat.com)
Date: Mon, 26 Aug 2013 13:42:28 -0800
To: user@organization.com
This is Red Hat Monitoring Satellite notification 01dc8hqw.
Time: Mon Aug 26, 21:42:25 PST
State: CRITICAL
System: [hostname] ([IP address])
Probe: Satellite: Users
Message: Users 6 (above critical threshold of 2)
Notification #116 for Users
Run from: Red Hat Monitoring Satellite
Subject: CRITICAL: [hostname]: Satellite: Users at 1
From: "Monitoring Satellite Notification" (rogerthat01@redhat.com)
Date: Mon, 26 Aug 2013 13:42:28 -0800
To: user@organization.com
This is Red Hat Monitoring Satellite notification 01dc8hqw.
Time: Mon Aug 26, 21:42:25 PST
State: CRITICAL
System: [hostname] ([IP address])
Probe: Satellite: Users
Message: Users 6 (above critical threshold of 2)
Notification #116 for Users
Run from: Red Hat Monitoring Satellite
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Como você pode ver, as notificações por e-mail mais longas contêm praticamente tudo o que você precisará saber sobre a detecção associada. Além do comando da detecção, da hora de execução, do sistema monitorado e do estado, a mensagem contém o Send ID (ID de envio), um string único de caracteres representando a mensagem e detecção específicas. Na mensagem acima, o ID de envio é 01dc8hqw.
Nota
Como as notificações podem ser geradas sempre que uma probe (detecção) tem seu estado alterado, simples alterações em sua rede podem resultar no recebimento de muitas notificações. As notificações podem ser redirecionadas par auma caixa de entrada específica para notificações para evitar problemas com correio prioritário. A próxima seção discute sobre o redirecionamento de notificações.
Copiar o linkLink copiado para a área de transferência!
Ao receber uma notificação, você pode redirecioná-la incluindo regras avançadas de notificação num e-mail de reconhecimento. Ative o redirecionamento de resposta de email abrindo /etc/aliases e adicione a seguinte linha:
rogerthat01: "| /etc/smrsh/ack_queuer.pl"
rogerthat01: "| /etc/smrsh/ack_queuer.pl"
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Uma vez que o parâmetro tiver sido configurado. Apenas responda à notificação e inclua a opção desejada. Estas são as opções de redirecionamento ou tipos de filtro possíveis:
ACK METOO - Envia a notificação ao(s) destino(s) de redirecionamento, além do destino default.
ACK SUSPEND - Suspende a notificação por um determinado período.
ACK AUTOACK - Não altera o destino da notificação, mas automaticamente reconhece os alertas coincidentes assim que são enviados.
ACK REDIR - Envia a notificação ao(s) destino(s) de redirecionamento ao invés do destino default.
O formato da regra deve ser tipo_filtro tipo_probe duração endereço_email, onde o tipo_filtro indica um dos comandos avançados anteriores, o tipo_detecção indica check or host, duração indica o tempo de redirecionamento e o endereço_email é o recipiente pretendido. Por exemplo:
ACK METOO host 1h boss@domain.com
ACK METOO host 1h boss@domain.com
Copy to ClipboardCopied!Toggle word wrapToggle overflow
As maiúsculas não são necessárias. A duração pode ser expressa em minutos (m), horas (h) ou dias (d). Os endereços de e-mail são necessários somente para notificações de redirecionamento (REDIR) e suplementares (METOO).
A descrição da ação contida no e-mail resultante tem como default o comando indicado pelo usuário. A razão listada é um resumo da ação, como email ack redirect by user@domain.com, onde user é o remetente do e-mail.
Nota
Você pode interromper (halt) ou redirecionar quase todas as notificações de detecção, respondendo aos e-mails de notificação com uma variação do comando ack suspend host. No entanto, não é possível interromper (halt) as notificações das probes do Satellite ao responder a uma detecção com ack suspend host ou com outra resposta de redirecionamento. Estas probes requerem que você altere as notificações na interface web do Satellite.
Copiar o linkLink copiado para a área de transferência!
Algumas relações entre métodos e probes podem complicar este processo. Aqui estão os passos a seguir para remover um método de notificação:
Autentique-se no Satellite como o Satellite Administrator ou Administrador de Monitoramento.
Navegue até a página Monitoring → Notifications e clique no nome do método a ser removido.
Em User → User Details → Notification Methods clique em delete method. Se o método não estiver associado a quaisquer probes, você receberá uma página de confirmação. Clique em Confirm Deletion. O método de notificação será removido.
Nota
Já que ambos o nome do método de notificação e o endereço, podem ser editados, considere atualizar o método ao invés de removê-lo. Isso redireciona as notificações de todas as probes usando o método, sem precisar editar cada detecção e criar um novo método de notificação.
Se o método é associado a uma ou mais probes, é exibida uma lista de probes usando o método e os sistemas aos quais as probes estão ligadas, ao invés de uma página de confirmação. Clique no nome da detecção para ir direto à aba System Details → Probes.
Selecione outro método de notificação e clique em Update Probe.
Retorne para a página Monitoring → Notifications e remova o método de notificação.
Copiar o linkLink copiado para a área de transferência!
Agora que o Red Hat Network monitoring daemon foi instalado e os métodos de detecção criados, você pode começar a instalar probes em seus sistemas com direitos a Monitoramento. Se um sistema tem direitos a Monitoramento, aparecerá uma aba Probes em sua página Detalhes do Sistema. É aqui que você efetuará a maior parte do trabalho relacionado às funções de probes(detecção).
Copiar o linkLink copiado para a área de transferência!
Detecções são criadas através do Servidor da Red Hat Satellite. Depois que as detecções foram criadas, elas são propagadas aos sistemas com monitoramento específico registrado no Satellite. Siga estes passos abaixo para adicionar uma detecção no servidor Satellite:
Autentique-se no site do Satellite como Satellite Administrator ou Administrador de Grupos de Sistemas(System Group Administrator).
Navegue até a aba System Details → Probes e clique em create new probe.
Na página Criação de Probe de Sistema (System Probe Creation), complete todos os campos necessários. Primeiro, selecione o Grupo de Comando de Probe (Probe Command Group). Isto altera a lista de probes, de outros campos e requisitos disponíveis. Consulte o Apêndice A, Probes (detecções) para obter uma lista completa das probes por grupo de comando. Lembre que algumas probes requerem a instalação do Red Hat Network monitoring daemon no sistema cliente.
Selecione o Probe Command (comando de probe) e o Monitoring Scout (agente de monitoramento) desejados, geralmente Red Hat Monitoring Satellite, mas possivelmente um Red Hat Proxy Server. Indique uma descrição breve e única para a probe.
Selecione a caixa de verificação Notificação de Probes (Probe Notifications) para receber notificações quando a detecção tiver seu estado alterado. Use o menu suspenso Intervalo de Checagem de Probe (Probe Check Interval) para determinar a freqüência de envio das notificações. Selecionando 1 minute (e a caixa de verificação Probe Notification), você receberá notificações a cada minuto que a probe ultrapassar os limites CRITICAL (crítico) ou WARNING (aviso). Consulte a Seção 1.2.4, “Habilitando Notificações” para saber como criar métodos de notificação e reconhecer suas mensagens.
Use os campos RHNMD User e RHNMD Port, se aparecerem, para forçar a detecção a comunicar-se através do sshd, ao invés do Red Hat Network Monitoring Daemon. Consulte a Seção 1.2.2.2, “Configurando o SSH” para mais detalhes. Caso contrário, aceite os valores default nocpulse e 4545, respectivamente.
Se o campo Timeout (Tempo limite) aparecer, reveja o valor default e ajuste-o conforme suas necessidades. A maioria dos (mas não todos) timeout resulta num estado UNKNOWN (desconhecido). Se as medidas da detecção são baseadas em tempo, garanta que o timeout não seja menor que o tempo alocado para os limites. Caso contrário, as medidas não terão propósito, já que a detecção terá seu tempo limite antes que os limites de estado sejam cruzados.
Use os campos restantes para estabelecer os limites de alerta da detecção, se for o caso. Os valores de CRITICAL e WARNING determinam em que ponto a detecção tem seu estado alterado. Consulte a Seção 1.2.5.2, “Estabelecendo Limites” para saber as recomendações relativas a estes limites.
Ao terminar, clique em Criar Probe (Create Probe). Lembre-se: você deve submeter a alteração de configuração de seu Monitoramento na página Scout Config Push para isso ter efeito.
Para apagar uma detecção, navegue para sua página Current State (estado atual) clicando no nome da detecção na aba System Details → Probes e depois clique em delete probe. Por fim, confirme a remoção.
Copiar o linkLink copiado para a área de transferência!
Muitas das probes oferecidas pelo Red Hat Network contêm limites de alerta que, quando ultrapassados, indicam uma mudança de estado da detecção. Por exemplo: a detecção Linux::CPU Usage (uso da CPU) permite que você defina os limites de CRITICAL e WARNING em relação à porcentagem de CPU usada. Se o sistema monitorado reportar 75 por cento de sua CPU usada e o limite WARNING estiver definido para 70 por cento, a detecção irá para o estado WARNING. Algumas probes oferecem diversos limites como este.
Para tirar o máximo proveito de seu direitos a Monitoramento e evitar notificações falsas, a Red Hat recomenda executar suas probes sem notificações durante um tempo para estabelecer um desempenho base a cada um de seus sistemas. Apesar dos valores padrões oferecidos talvez servirem a você, cada empresa possui um ambiente diferente, que pode precisar de alterações dos limites.
Copiar o linkLink copiado para a área de transferência!
Além de monitorar todos seus sistemas cliente, você também pode usar o Red Hat Network para monitorar seu próprio Servidor Red Hat Network, seja um Servidor Satellite ou Proxy. Para monitorar seu Servidor RHN, encontre um sistema monitorado pelo servidor e clique na aba System Details → Probes deste sistema.
Clique em create new probe (criar nova detecção) e selecione o Probe Command Group (Grupo de Comando de Detecção) Satellite. Então, complete os campos restantes como você faria para qualquer outra detecção. Consulte a Seção 1.2.5.1, “Administrando probes” para mais instruções.
Apesar do Servidor do Satellite ou Proxy parecer ser monitorado pelo sistema cliente, na verdade a detecção é executada pelo servidor nele mesmo. Os limites e notificações funcionam normalmente.
Nota
Todas as probes que requerem conexões ao Red Hat Network monitoring daemon não podem ser usadas no Red Hat Satellite ou num Red Hat Satellite Proxy Server no qual o software de Monitoramento está rodando. Isto inclui a maioria das probes no grupo de comando Linux, assim como as probes (detecções) do Agente de Registros e do Programa Remoto. Use as probes do grupo de comando Satellite para monitorar Red Hat Satellite s e Red Hat Satellite Proxy Servers. No caso de agentes do Proxy, as probes (detecções) são listadas sob o sistema para o qual estão reportando dados.
Copiar o linkLink copiado para a área de transferência!
Se você clicar na aba Monitoring na barra de navegação superior, aparecem a categoria e os links de Monitoring. Estas páginas, que requerem o direito à Monitoring, possibilitam que você veja os resultados das probes que determinou nos sistemas com o direito à Monitoring e administre a configuração da sua infra-estrutura de monitoramento.
Inicie o monitoramento de um sistema através da aba Probes (Detecções), na página System Details (Detalhes do Sistema). Veja o Apêndice A, Probes (detecções) para uma lista completa de probes disponíveis.
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
A página de Probe Status exibe por padrão quando você clica no Monitoring na barra de navegação superior.
A página Probe Status (Estado da Probe) apresenta a contagem resumida das probes em vários estados e oferece uma interface simples para localizar rapidamente as probes problemáticas. Note que os totais da detecção nas abas do topo da página talvez não coincidam com os números de probes exibidas nas tabelas abaixo. A contagem do topo inclui as probes de todos os sistemas de sua empresa, enquanto as tabelas exibem as probes somente dos sistemas aos quais você tem acesso, através da função System Group Administrator. Além disso, a contagem das probes exibidas aqui podem estar fora de sincronia por aproximadamente um minuto de diferença.
A lista seguinte descreve cada estado e identifica os ícones associados:
- Critical - A detecção ultrapassou o limíte crítico.
- Aviso (Warning) - A proble ultrapassou o límite de Atenção.
- Desconhecido (Unknown) - A probe não é capaz de reportar com precisão dados métricos ou estados.
- Pendente (Pending) - A probe foi agendada mas não foi ainda executada ou está incapaz de rodar.
- OK - A probe está sendo executado com sucesso.
A página Probe Status (Estado da Detecção) contém abas para cada um dos estados possíveis, além de uma aba que lista todas as probes. Cada tabela contém colunas indicando o estado da detecção, o sistema monitorado, as detecções usadas e a data e hora em que o estado foi atualizado pela última vez.
Clicar no nome do sistema nestas tabelas, te leva à aba Probes (Detecções) da página System Details (Detalhes do Sistema). Clicar no nome da detecção te leva à sua página Current State (Estado Atual). A partir dali, você pode editar a detecção, apagá-la e gerar relatórios baseados em seus resultados.
Dados e informações de estado de detecção do Monitoring que antes era disponível apenas através da interface Web pode agora ser exportado como um arquivo CSV. Clique nos links Baixar CSV encontrados nas páginas do Monitoring para baixar os arquivos CSV contendo informações relevantes. Os dados exportados podem incluir, mas não estão limitados à:
Estado do Probe
Todas as probes em um certo estado (OK, WARN, UNKNOWN, CRITICAL, PENDING)
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
As probes que ultrapassaram seus limites críticos (CRITICAL) ou atingiram este estado através de outras maneiras. Por exemplo, algumas probes tornam-se críticas (ao invés de desconhecidas) ao ultrapassarem seu tempo limite (timeout period).
Copiar o linkLink copiado para a área de transferência!
Importante
É necessário possuir direitos de serviços de Monitoring para este recurso
As probes incapazes de coletar as medidas necessárias para determinar seu estado. A maioria, mas não todas, das probes entram num estado desconhecido quando excedem seu tempo limite. Isto pode significar que o tempo limite deve ser extendido ou que a conexão ao sistema monitorado não pode ser estabelecida.
Também é possível que os parâmetros de configuração da detecção não estejam corretos e seus dados não possam ser encontrados. Finalmente, este estado pode indicar a ocorrência de um erro no software.
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
As probes cujos dados não foram recebidos pelo Red Hat Network. Este estado é esperado de uma detecção que foi recentemente agendada, mas ainda não foi executada. Se todas as probes recaem num estado pendente, sua infra-estrutura de monitoramento pode estar falhando.
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
Identifica o estado da detecção selecionada e quando esta foi executada pela última vez, além de oferecer a capacidade de gerar um relatório sobre a detecção. Apesar desta página ser parte integrante do monitoramento, é acessada sob a aba Probes (Detecções), na página System Details (Detalhes do Sistema), já que sua configuração é específica ao sistema sendo monitorado.
Para ver um relatório dos resultados da detecção, escolha uma duração relevante usando os campos date (data) e decida se você deseja visualizar os dados das medidas (metric data), o histórico de alteração do estado (state change history) ou ambos. Para obter os dados das medidas, selecione a(s) medida(s) que você deseja ver reportadas e decida (usando as caixas de verificação) se os resultados devem ser exibidos num gráfico, registro de erros (error log) ou ambos. Em seguida, clique em Generate report (Gerar Relatório) no rodapé da página. Se não houver dados para as medidas da detecção, você verá a seguinte mensagem NO DATA SELECTED TIME PERIOD AND METRIC (nenhum dado encontrado para o período de tempo e medidas).
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
Identifica os métodos de contato estabelecidos para sua empresa. Estes métodos incluem endereços de e-mail ou de pager, designados a receber alertas das probes.
Há vários métodos de notificação disponíveis à sua empresa, listados na tela Notificação padrão. Os métodos estão listados de acordo com os usuários para os quais se aplicam.
Para criar um novo método de notificação, clique no nome do usuário ao qual a notificação será aplicada. Aparece, então, a página User Details ⇒ Notification Methods do usuário. Clique no título do método de notificação para editar suas propriedades.
Copiar o linkLink copiado para a área de transferência!
Os filtros da notificação permitem criar regras de longo prazo que suspendem, redirecionam ou automaticamente reconhecem notificações padrão ou enviam notificações suplementares. Isto pode ser útil na administração da comunicação de probes detalhadas ou freqüentes.
Copiar o linkLink copiado para a área de transferência!
Esta é a tela dpadrão da aba Notification Filters (Filtros da Notificação). Lista todos os filtros ativos disponíveis à sua empresa. Clique no nome do filtro para editar suas propriedades.
Para criar um filtro da notificação, clique no link create new notification filter (criar novo filtro de notificação) no canto superior direito da tela. Configure cada opção listada abaixo e clique no botão Save Filter (Salvar Filtro) para criá-lo.
Description (Descrição): Indique um valor que distingua este filtro dos outros.
Type (Tipo): Determine a ação do filtro: redirecionar, reconhecer (acknowledge), suspender ou suplementar a notificação recebida.
Send to (Enviar para): As opções Redirect Notification e Supplemental Notification no passo dois requerem um endereço de e-mail para o qual enviar as notificações. As opções restantes não requerem um endereço de e-mail.
Scope (Alcance): Determine quais componentes do monitoramento estão sujeitos ao filtro.
Organization/Scout/Probe: Esta opção permite selecionar a empresa, agente(s) ou detecçã(ões) aos quais este filtro se aplica. Para selecionar itens múltiplos da lista, segure a tecla Ctrl enquanto clicar nos nomes do itens. Para selecionar uma gama de itens, segure a tecla Shift enquanto clicar no primeiro e último itens da gama.
Probes in State (Probes em Estado): Selecione qual(is) estado(s) da detecção se relacionam ao filtro. Por exemplo: você pode optar por criar uma notificação suplementar somente para probes críticas. Desmarque a caixa à esquerda dos estados que o filtro deve ignorar.
Notifications sent to (Notificações enviadas para): Este é o método de envio da notificação, caso não houver nenhum filtro. Você pode, por exemplo, redirecionar a outras pessoas as notificações que normalmente são enviadas a um usuário que saiu de férias, deixando todas as outras notificações da detecção inalteradas.
Match Output (Resultado de Correspondencia): Selecione os resultados precisos da notificação indicando uma expressão regular aqui. Se o resultado da "Mensagem:" da notificação não coincidir com a expressão regular, o filtro não é aplicado.
Recurring (Recorrente): Selecione se o filtro deve rodar continuamente ou de maneira recorrente. Um filtro recorrente roda múltiplas vezes durante um período mais curto que a duração do filtro. Por exemplo: um filtro recorrente pode rodar 10 minutos por hora entre o horário de início e de fim do filtro. Um filtro não-recorrente roda continuamente entre o horário de início e de fim do filtro.
Beginning (Início): Indique uma data e hora para o início da operação do filtro.
Ending (Fim): Indique uma data e hora para o fim da operação do filtro.
Recurring Duration (Duração Recorrente): Por quanto tempo uma instância recorrente do filtro está ativa. Este campo, aplicável somente a filtros recorrentes, inicia na hora Beginning(Início) indicada acima. Todas as notificações geradas fora da duração especificada não são filtradas.
Recurring Frequency (Frequencia de Recorrencia): A freqüência da ativação do filtro.
Os filtros de notificação não podem ser apagados. No entanto, um filtro pode ser cancelado ao configurar a data final no passado. (Note que a data final deve ser igual ou posterior à data inicial, caso contrário a alteração falha.) Um outro método é selecionar um conjunto de filtros na página Active (Ativos) e clicar no botão Expire Notification Filters (Filtros de Notificação de Validade) no canto inferior direito. Estes filtros então são cancelados e aparecem na aba Expired Filters (Filtros Expirados).
Copiar o linkLink copiado para a área de transferência!
Esta aba lista todos os filtros da notificação com data final expirada. Os filtros expirados são armazenados indefinidamente; isto permite à empresa reciclar filtros úteis conforme necessário e oferece um registro histórico para a resolução de problemas.
Copiar o linkLink copiado para a área de transferência!
Os Conjuntos de Detecções (Probe Suites) permitem configurar e aplicar uma ou mais probes a um sistema ou a um grupo de sistemas. Os Conjuntos de Probes podem ser configurados uma vez e aplicados a diversos de sistemas de uma só vez. Isto resulta em economia de tempo e consistência para clientes com direito à Monitoramento.
Para criar e aplicar um Conjunto de Probes, primeiro crie um conjunto vazio e então configure as probes membros. Por fim, aplique o Conjunto aos sistemas selecionados.
Na página Monitoramento ⇒ Conjunto de Probes, selecione o link create probe suite (criar conjunto de probes). Indique um nome distinguível para o Conjunto de Probes. Você também pode escolher adicionar uma breve descrição deste conjunto. Clique no botão Create Probe Suite (criar conjunto de probes) para continuar.
Adicione e configure as probes que compõem este Conjunto. Clique no link create new probe (criar nova probe) no canto superior direito.
Configure a detecção e clique no botão Criar Probe no canto inferior direito. Repita este processo até adicionar todas as probes (detecções) desejadas.
Nota
O Sendmail deve ser configurado corretamente no seu Red Hat Satellite e cada sistema cliente no qual o conjunto de probes é aplicado deve ter o daemon rhnmd instalado e ativo. Consulte o Guia de Instalação do Red Hat Satellite para informações adicionais.
Na aba "Systems", adicione os sistemas aos quais o Conjunto de Probes se aplica. Clique no link add systems to probe suite no canto superior direito da tela para continuar.
A página seguinte exibe uma lista de todos os sistemas com serviços de Monitoramento. Selecione a caixa à esquerda do(s) sistema(s) ao(s) qual(is) deseja aplicar o Conjunto de Probes, selecione o agente de monitoramento (monitoring scout) e clique no botão Add systems to probe suite para completar a criação do Conjunto de Probes.
Você pode apagar ou retirar probes do conjunto. Retirar uma detecção desassocia as probes do conjunto e converte-as em probes específicas dos sistemas. Isto significa que as alterações nas probes retiradas afetam somente aquele sistema. Apagar uma detecção remove-a do Conjunto para todos os sistemas.
Para remover probes do Conjunto:
Na página Monitoramento⇒ Conjunto de Probes, clique no título do Conjunto de Probes que deseja alterar.
Selecione a sub-seção Probes.
Selecione a caixa próxima à detecção que deseja remover.
Clique no botão Delete probes from Probe Suites (Apagar probes do Conjunto de Probes).
Você também pode remover um sistema do Probe Suite (Conjunto de Probes). Há duas maneiras de fazê-lo. O primeiro método é desassociar o sistema do Conjunto de Probes. Neste caso, o sistema ainda tem as mesmas probes atribuídas. No entanto, agora você tem a habilidade para configurar estas probes separadamente sem afetar nenhum outro sistema.
Para desassociar um sistema do conjunto:
Na página Monitoramento ⇒ Conjunto de Probes, clique no título do Conjunto de Probes que deseja alterar.
Selecione a sub-seção Sistemas.
Selecione a caixa próxima ao(s) sistema(s) que deseja remover do Conjunto de Probes.
Clique no botão Detach System(s) from Probe Suite (Retirar o(s) Sistema(s) do Conjunto de Detecções)
O segundo método é remover o sistema do conjunto. Neste método, o sistema é removido do conjunto e todas as probes ativas são apagadas do sistema.
Nota
Esta ação apaga todas as probes do sistema no Conjunto de Probes, assim como todos os dados históricos Time Series e Event Log. Esta ação é irreversível.
Para remover um sistema do Conjunto de Probes e apagar todas as probes associadas ao sistema:
Na página Monitoramento⇒ Conjunto de Probes, clique no título do Conjunto de Probes que deseja alterar.
Selecione a sub-seção Sistemas.
Selecione a caixa próxima ao(s) sistema(s) que deseja remover do Conjunto de Probes.
Clique no botão Remove System(s) from Probe Suite (Remover Sistema(s) do Conjunto de Probes).
Finalmente, assim como é o caso com probes individuais, você também pode baixar um arquivo CSV contendo informação a respeito de conjuntos de probes. Clique no link Baixar CSV na parte inferior da página Monitoring ⇒ Conjuntos de Probes para baixar o arquivo.
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
Exibe o estado da sua infra-estrutura de monitoramento. Cada vez que você efetuar uma alteração na sua configuração de monitoramento, tal como adicionar uma detecção a um sistema ou editar os limites de uma detecção, você deve reconfigurar sua infra-estrutura de monitoramento. Faça isso selecionando a caixa de verificação do Servidor do Red Hat Network e clicando em Push Scout Configs. A tabela desta página identifica a data e hora de 'pushes' requisitados e completos.
Clicar no nome de um servidor abre sua Chave Pública SSH do Red Hat Network Monitoring Daemon. Isto permite a você copiar e colar a chave SSH nos sistemas monitorados pelo agente (scout). Isto é preciso para que o daemon Red Hat Network Monitoring Daemon se conecte ao Satellite.
Copiar o linkLink copiado para a área de transferência!
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
A página se encontra no Configuração Geral do Monitoring no Admin → Red Hat Satellite Configuration → Monitoring. Ela coleta informações universalmente aplicáveis à sua infra-estrutura de Monitoring. Modificar qualquer coisa nesta página causa a reinicialização dos serviços de Monitoring no Red Hat Satellite , assim como agenda eventos para a reinicialização dos serviços Monitoring em todos os Red Hat Satellite Proxy Servers com Monitoring que conectam a este Satellite. Isto é feito para que os serviços Monitoring nestes servidores recarreguem sua configuração imediatamente.
Normalmente, os defaults providos nos outros campos são aceitáveis, já que derivam da instalação de seu Satellite. No entanto, você pode usar os campos desta página para alterar a configuração de seu Monitoring. Por exemplo: você pode alterar seu servidor de e-mail aqui. Esta página também permite a você mudar o destino de todos os e-mails administrativos do Satellite. Quando terminar, clique em Update Config (Atualizar Configuração).
Copiar o linkLink copiado para a área de transferência!
Inter-Satellite Synchronization (ISS) permite que um Satellite sincronize o conteúdo e permissões de outra instância do Satellite em um relacionamento peer-to-peer. No entanto, na seguinte seção, um Satellite que recebe conteúdo será referido como um "Satellite Slave" e um Satellite que age como a fonte onde o conteúdo é obtido, é chamado de "Satellite Mestre". Ao utilizar ISS para sincronizare o conteúdo, a instância do Satellite Escravo (Slave) pode ter uma configuração diferente do Mestre para entidades sem conteúdo como Usuários e Organizações. O Administrador do Satellite na instância do Escravo é grátis, e muda entidades independentemente do que ocorrer na instância Mestre.
Nota
Mestre e Escravo são termos de legacia que carregam as conotações de não serem forçados pelo protocolo ISS. Por favor mantenha seus significados restringidos em mente, como descrito acima, enquanto estuda esta seção.
O recurso do ISS pode ser utilizado em diferentes formas dependendo da necessidade da organização. Existem configurações do ISS onde dois Satellites podem agir como ambos mestres e escravos ao mesmo tempo. Esta seção contém uma seção sobre o uso de casos, e como melhor configurar o ISS para adequar à sua empresa.
Requerimentos do ISS
Estas são as condições necessárias para poder utilizar o ISS:
Dois ou mais servidores Red Hat Satellite
Pelo menos um Red Hat Satellite populado com pelo menos um canal
Privilégios de Administrador do Satellite em todos os sistems Satellite para ISS
Copiar o linkLink copiado para a área de transferência!
ISS pode ser configurado manualmente ou por uma ferramenta chamada spacewalk-sync-setup. Ambos os métodos são efetivos, e poderia ser deixado à escolha do usuário sobre qual utilizar.
Copiar o linkLink copiado para a área de transferência!
Procedimento 1.1. Configurando o Servidor Satellite Mestre
Com o Satellite 5.6, o ISS permite que o Satellite Escravo duplique a hierarquia do trust da empresa e as permissões de canal padronizado a partir de configurações sobre o mestre. Isto é alcançado exportando informações sobre empresas específicas do Satellite Mestre para o Satellite Escravo receptivo. O Administrador do Satellite no Satellite Escravo pode então escolher mapear as Empresas do Master para Empresas Escravs específicas. Futuras operações do satellite-sync usam estas informações para atribuir a propriedade do canal padronizado à Empresa Escrava que é mapeada à Empresa Mestre específica. Também é possível mapear os relacionamentos do trust entre Empresas Mestre expostas a combinar empresas Escrava, criando relacionamentos equivalentes no Escravo.
Na Interface da Web:
Autentique-se como o Administrador do Satellite
Clique em Admin → ISS Configuration → Master Setup.
Do canto direito superior, clique em Add New Slave.
Preencha as seguintes informações:
Nome do Domínio Totalmente Qualificado Escravo (FQDN)
Permitir Escravo Sincronizar? - Escolher este campo permite que o Satellite Escravo acesse este Master Satellite. Caso contrário, o ontato com este Escravo será negado.
Sincronizar todas as orgs para Escravo? - Escolher este campo irá sincronizar todas as empresas para o Satellite Escravo.
Nota
Escolher a opção Sincronizar todas as Empresas para o Escravo? na página de Configuração do Mestre irá sobrescrever qualquer empresa selecionada especificamente na tabela de Empresa Local abaixo.
Clique Create.
(Opcional) Clique em qualquer empresa local para ser exportado para o Satellite Escravo.
Clique Allow Orgs.
Nota
No Satellite 5.5, o Satellite Mestre usado para o parâmetro iss_slaves no arquivo /etc/rhn/rhn.conf para identificar qual escravo deve contatar o Satellite Mestre. O Satellite 5.6 usa a informação na página de Configuração do Mestre para determinar esta informação.
Na linha de Comando:
Habilite o recurso de sincronização inter-satellite (ISS) no arquivo /etc/rhn/rhn.conf:
disable_iss=0
disable_iss=0
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Salve o arquivo de configuração, e reinicie o serviço httpd:
service httpd restart
service httpd restart
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Procedimento 1.2. Configurar Servidores Slaves
Os servidores do Satellite Escravo são as máquinas que receberão conteúdo sincronizado a partir do Servidor Mestre.
Para tranferir seguramente o conteúdo aos servidores slave, você precisará do certificado ORG-SSL do servidor master. Você pode baixar o certificado por HTTP do diretório /pub/ de qualquer satellite. O arquivo é chamado Red Hat Network-ORG-TRUSTED-SSL-CERT, mas pode ser renomeado e colocado em qualquer lugar no sistema de arquivos local do slave, tal como o diretório /usr/share/Red Hat Network/.
Autentique-se no Satellite Escravo como Administrador do Satellite.
Clique Admin → ISS Configuration → Slave Setup.
Do canto direito superior, clique em Add New Mestre.
Preencha as seguintes informações:
Nome de Domínio Totalmente Qualificado do Mestre (FQDN)
Default Mestre?
Nome de arquivo deste Certificado CA do Mestre - Use o caminho completo do certificado CA baixado no passo inicial deste procedimento.
Clique Add New Master.
Procedimento 1.3. Realizando uma Sincronização Inter-Satellite
Uma vez que os servidores master e slave estiverem configurados, você pode realizar a sincronização entre eles.
Inicie a sincronização rodando o comando satellite-sync:
satellite-sync -c your-channel
satellite-sync -c your-channel
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Nota
Opções de linha de comando que são fornecidas manualmente com o comando satellite-sync irão sobrepor qualquer configuração personalizada no arquivo /etc/Red Hat Network/Red Hat Network.conf.
Procedimento 1.4. Mapeando as Empresas Exportadas do Satellite Mestre para as Empresas do Satellite Escravo
Pré-requisito
Depois de seguir os procedimentos antes deste, o Satellite Mestre deve exibir a Configuração do Escravo do Satellite Escravo sob Admin → ISS Configuration → Slave Setup. Caso não aconteça isso, por favor verifique novamente os passo acima.
Um mapeamento entre os nomes organizacionais no Satellite Mestre conta com as permissões de acesso do canal serem definidas no Satellite Mestre e propagadas quando o conteúdo é sincronizado em um Satellite Escravo. Nem todas as organizações e detalhes de canais precisam ser mapeados para todos os Satellites Slaves, Administradores de Satellite podem selecionar quais permissões e organizações podem ser sincronizadas, permitindo ou omitindo mapeamentos.
Para concluir o mapeamento, siga este procedimento no Satellite Escravo:
Autentique-se como o Administrador do Satellite
Clique no Admin → ISS Configuration → Slave Setup.
Selecione um Satellite Mestre clicando em seu nome.
Use a caixa suspensa para mapear o nome de organização mestre exportada para uma empresa local coincidente no Satelite Escravo.
Clique em Update Mapping.
Na linha de comando, emita o satellite-sync em cada canal padronizado para obter a estrutura do trust correta e permissões do canal:
satellite-sync -c your-channel
satellite-sync -c your-channel
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copiar o linkLink copiado para a área de transferência!
spacewalk-sync-setup permite aos usuários especificar um mestre e exemplo Satellite Slave e usa arquivos de configuração para configurar as informações descritas tanto no mestre e configuração Slave. Ele pode criar um conjunto de arquivos de configuração padrão, se solicitado. Essencialmente, ele automatiza a configuração mapeada e instalada anteriormente para relacionamentos Master-Slave.
Pré-requisitos
Para que a configuração automatizada seja bem sucedida:
O pacote spacewalk-util precisa ser instalado no sistema que irá emitir o comando spacewalk-sync-setup.
Organizações existentes com permissões personalizadas no Satellite Master devem estar presentes.
Organizações existentes dentro do Satellite Slave devem estar presentes.
Procedimento 1.5. Configurando o Servidor Satellite Mestre
Habilite o recurso de sincronização inter-satellite (ISS) no arquivo /etc/rhn/rhn.conf:
disable_iss=0
disable_iss=0
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Salve o arquivo de configuração, e reinicie o serviço httpd:
service httpd restart
service httpd restart
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Procedimento 1.6. Configurar Servidores Slaves
Servidores Satellites Slaves são as máquinas que terão seu conteúdo sincronizado ao servidor master.
Para tranferir seguramente o conteúdo aos servidores slave, você precisará do certificado ORG-SSL do servidor master. Você pode baixar o certificado por HTTP do diretório /pub/ de qualquer satellite. O arquivo é chamado Red Hat Network-ORG-TRUSTED-SSL-CERT, mas pode ser renomeado e colocado em qualquer lugar no sistema de arquivos local do slave, tal como o diretório /usr/share/Red Hat Network/.
Autentique-se no Satellite Escravo como Administrador do Satellite.
Clique Admin → ISS Configuration → Slave Setup.
Do canto direito superior, clique em Add New Mestre.
Preencha as seguintes informações:
Nome de Domínio Totalmente Qualificado do Mestre (FQDN)
Default Mestre?
Nome de arquivo deste Certificado CA do Mestre - Use o caminho completo do certificado CA baixado no passo inicial deste procedimento.
Clique Add New Master.
Procedimento 1.7. Mapeando as Empresas do Satellite Mestre para as Empresas do Satellite Escravo com o pacewalk-sync-setup
Autentifique-se em um sistema. Não importa se é um Satellite Master ou Satellite Slave ou um sistema diferente, desde que o sistema possa acessar o XMLRPC API público do Master e Slave Satellites.
Emita um spacewalk-sync-setup em uma interface de linha de comando:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Onde:
--ms=MASTER, --master-server=MASTER é o FQDN do Master para se conectar ao
--ml=MASTER_LOGIN, --master-login=MASTER_LOGIN é o login do Satellite Administrator login para o Master Satellite
--mp=MASTER_PASSWORD, --master-password=MASTER_PASSWORD é a senha do login do Satellite Administrator no Master Satellite
--ss=SLAVE, --slave-server=SLAVE é o FQDN do Slave Satellite para conectar.
--sl=SLAVE_LOGIN, --slave-login=SLAVE_LOGIN é o login do Satellite Administrator para o Slave Satellite
--sp=SLAVE_PASSWORD, --slave-password=SLAVE_PASSWORD é a senha para o login do Satellite Administrator login no Slave Satellite
--ct, --create-templates é a opção para criar arquivo de configuração do master e slave para o par master/slave que apontamos
--apply informa a instância do Satellite a realizar as mudanças especificadas pelos arquivos de configuração para as instâncias de Satellite específicas.
Nota
Para mais opções de configuração:
spacewalk-sync-setup --help
spacewalk-sync-setup --help
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copiar o linkLink copiado para a área de transferência!
Sincronização Inter-Satellite também pode ser usada para importar conteúdo para qualquer organização específica. Isto pode ser feito localmente, ou usando a sincronização remota. Esta função é útil para um Satellite desconectado com várias organizações, onde os conteúdos são recuperados através de despejos de canal ou exportando a partir de satélites conectados e, em seguida, importá-lo para o satélite desconectado. Sincronização organizacional pode ser usado para exportar canais personalizados a partir de satélites conectados. Ele também pode ser usado para mover efectivamente o conteúdo entre múltiplas organizações.
A sincronização organizacional segue um conjunto de regras claras para manter a integridade da organização fonte:
Se o conteúdo fonte pertence a uma organização NULL (que é conteúdo Red Hat), isto fará padrão à organização NULL, mesmo se uma organização destino é especificada. Isto certifica que o conteúdo especificado está sempre na organização NULL privilegiada.
Se uma organização estiver especificada na linha de comando, o conteúdo será importado dessa organização.
Se nenhuma organização é especificada, então será padrão a organização 1.
A seguir estão três exemplos de cenários onde IDs organizacionais (orgid) são usados para sincronizar satellites:
Exemplo 1.1. Importar Conteúdo do Master para o Satellite Slave
Este exemplo importa conteúdo do master para o satellite slave:
Copiar o linkLink copiado para a área de transferência!
O Inter-Satellite Syncronization (ISS) pode ser usado de diversas maneiras, dependendo das necessidades de sua organização. Esta seção fornece exemplos de como você pode escolher o uso do ISS, e os métodos para configurar e operar nesses casos.
Exemplo 1.4. Staging Satellite (Preparação do Satellite)
Este exemplo usa um satellite como um staging satellite (teste) para preparar o conteúdo e realizar controle de qualidade dos pacotes para ter certeza que eles estão corretos para uso em produção. Quando o conteúdo é aprovado para produção, o satellite em produção pode sincronizar o conteúdo do satellite em teste.
Este exemplo usa o satellite master como um canal de desenvolvimento, do qual o conteúdo é distribuído para todos os satellites slaves. Alguns dos satellites slave possuem conteúdos extra que não estão presentes nos canais do satellite master. Estes pacotes são preservados, mas todas alterações do satellite master são sincronizadas aos slaves.
Neste ambiente, os dois servidores Red Hat Satellite agem como Master e salve entre si e podem sincronizar o conteúdo entre si. O servidor Satellite, onde o satellite-sync é executado irá obter o conteúdo de outro servidor do Satellite e os dados sincronizados dependerá das opções de execução com satellite-sync . Sem nenhuma opção, a sincronização tentará atualizar tudo o que foi previamente sincronizado.
Veja Seção 1.3.1.1, “Configuração de manual” Para configurar um Satellite Master. Configurar ambos os servidores do Satellite como um Master irá criar uma sincronização bi-direcional.
Copiar o linkLink copiado para a área de transferência!
Este capítulo documenta o procedimento de instalação das funcionalidades do Red Hat Network e identifica suas diferenças quando usadas para administrar sistemas clientes baseados no UNIX. O Red Hat Network oferece suporte para ajudar seus clientes a migrar do UNIX para o Linux. Devido ao escopo limitado desta tarefa, as funcionalidades oferecidas para administrar clientes UNIX não são tão detalhadas quanto àquelas disponíveis para administrar sistemas Red Hat Enterprise Linux.
As seções seguintes especificam as variantes do UNIX suportadas, as funcionalidades do Red Hat Network suportadas pelo sistema de administração UNIX, os pré-requisitos para administrar um sistema UNIX pelo Red Hat Network, assim como o procedimento de instalação para clientes UNIX.
Copiar o linkLink copiado para a área de transferência!
As seguintes funcionalidades, partes integrantes do Red Hat Network, estão inclusas no acordo do nível de serviço suporte ao UNIX:
O Daemon de Serviços do Red Hat Network (Red Hat Networksd), que ativa o Red Hat Network_check, conforme um intervalo configurável
O Red Hat Network Configuration Client (Red Hat Networkcfg-client), que executa todas as ações de configuração agendadas pelo Satellite
O Red Hat Network Configuration Manager (rhncfg-manager), que permite a administração via linha de comando dos canais de configuração do Red Hat Network
O programa Red Hat Network_check, que faz checkin no Satellite e executa todas as ações agendadas pelo servidor
Todas as funcionalidades do nível Gerenciamento (Management), como agrupamento de sistemas, comparação de perfis de pacotes e o uso do Gerenciador de Conjunto de Sistemas (System Set Manager) para administrar sistemas múltiplos de uma só vez
Uma funcionalidade de Provisionamento (Provisioning) chamada Comando Remoto (Remote Command), que possibilita a usuários agendar comandos de nível root em qualquer cliente administrado através do site do Satellite, se o cliente permitir esta ação
Copiar o linkLink copiado para a área de transferência!
As seguintes funcionalidades do Red Hat Network funcionam diferentemente num ambiente UNIX:
O Red Hat Update Agent para o UNIX oferece uma gama bem menor de opções que seu semelhante do Linux e baseia-se no conjunto de ferramentas nativo do sistema operacional para a instalação de pacotes, ao invés do rpm. Consulte a Seção 2.1.4.2.4, “Atualizando pela Linha de Comando” para uma lista precisa de opções.
A aplicação Red Hat Network Push foi modificada de maneira similar para fazer o upload de tipos de arquivo UNIX nativos, incluindo pacotes, patches e clusters de patches.
Já que os arquivos de pacotes, atualizações (patches) e conjuntos de atualizações do Solaris são diferentes dos arquivos rpm, o mecanismo de upload para canais é ligeiramente diferente. Há dois aplicativos no pacote Red Hat Networkpush para Solaris:
O primeiro, solaris2mpm, é um utilitário do Red Hat Network que cria um arquivo MPM para cada arquivo de atualização ou pacote do Solaris. O formato Neutro do arquivo MPM permite que o Satellite possa interpretar e gerenciar os arquivos que sejam carregados.
O segundo, Red Hat Networkpush, foi extendido para poder lidar com arquivos MPM e RPM. Fora isso, este aplicativo funciona de forma idêntica à versão Linux do Red Hat Networkpush.
A categoria Canais do site do Red Hat Network foi ampliada para acomodar o armazenamento e instalação de arquivo nativos do UNIX.
Copiar o linkLink copiado para a área de transferência!
As seguintes funcionalidades do Red Hat Network não estão disponíveis no sistema de suporte ao UNIX:
Todas as funcionalidades do nível de Provisionamento (Provisioning), como kickstart e reversão de pacotes, com exceção da administração de arquivos de configuração.
Todas as opções relativas a Erratas, já que o conceito de Atualizações de Erratas não é compreendido pelo UNIX
Arquivos fonte para pacotes
Os arquivos answer não são suportados. O suporte para tais arquivos está planejado para versões futuras.
Também não há suporte para o IPv6 para os sistemas Solaris.
Além disso, os arquivos RHAT*.pkg foram relocados enquanto a instalação não é suportada.
Copiar o linkLink copiado para a área de transferência!
Você deve configurar o Satellite para o suporte a clientes UNIX antes dos arquivos necessários serem disponibilizados para implementação nos sistemas clientes. Isto pode ser feito de duas maneiras, dependendo do fato de você ter instalado seu servidor Satellite ou não:
Durante a instalação do Satellite:
Habilite o suporte ao UNIX no Satellite selecionando a caixa "Enable Solaris Support" (Habilitar Suporte ao Solaris) durante o processo de instalação; ex.:
Figura 2.1. Habilitando o Suporte ao UNIX Durante a Instalação do Satellite
Após o Satellite ser instalado:
Habilite o suporte ao UNIX configurando o Satellite após a instalação. Para tanto, selecione Admin (Satellite Tools) no menu superior e então selecione Configuração do Satellite (Satellite Configuration) na barra de navegação esquerda. Na tela seguinte, marque a caixa Habilitar Suporte ao Solaris (Enable Solaris Support), conforme o exemplo:
Figura 2.2. Habilitando o Suporte ao UNIX Após a Instalação do Satellite
Clique no botão Atualizar Configuração para confirmar a mudança.
Finalmente, crie um canal base ao qual os seus sistemas clientes podem se subscrever. Red Hat Network não oferece conteúdo UNIX, você não pode usar o satellite-sync para criar o canal.
Para criar um canal Solaris, faça o login na interface Web do Satellite como um Satellite Administrator ou uma Licensa de Certificado (Certificate Authority). Navegue até a aba Canal e então Gerenciar Canais de Software na barra de navegação esquerda. Clique no link criar novo canal na parte superior direita da tela resultante. Forneça um nome e uma etiqueta para o seu novo canal e selecione ou Sparc Solaris ou i386 Solaris como a arquitetura, dependendo da arquitetura do seu cliente.
Copiar o linkLink copiado para a área de transferência!
Antes de seus sistemas clientes baseados em UNIX se beneficiarem do Red Hat Network, eles devem ser preparados para conexão:
Faça o download e instale o gzip e as bibliotecas necessárias.
Faça o download do tarball do aplicativo Red Hat Network a partir do Satellite para o cliente e instale o conteúdo.
Depois disso, implemente os certificados SSL necessários para uma conexão segura.
Configure os aplicativos cliente para se conectar ao Red Hat Satellite
Depois de concluído, seus sistemas estarão prontos para começar a receber as atualizações do Red Hat. A próxima seção explica estes passos em detalhes.
Copiar o linkLink copiado para a área de transferência!
Esta seção o guiará no processo de instalação e download de aplicativos de terceiros e os aplicativos Red Hat Network a partir do Satellite no cliente UNIX.
A prioridade é o Red Hat Update Agent for UNIX (up2date), que fornece uma ligação entre seu sistema cliente e o Red Hat Network. A versão específica do UNIX do Red Hat Update Agent é limitada quanto à sua funcionalidade comparado ao Linux, mas ainda assim permite registro de sistema e facilita instalações de pacote e reparos de erros. Consulte a Seção 2.1.4, “Registro e Atualizações de Clientes da Unix” para obter uma descrição completa sobre as opções de ferramentas.
Nota
Pode ser útil inserir o comando bash quando se registrar pela primeira vez no cliente Solaris. Se o shell do BASH estiver disponível, ele fará com que o comportamento do sistema se pareça o máximo possível com o Linux.
Copiar o linkLink copiado para a área de transferência!
Instalação dos aplicativos Red Hat Network não pode continuar a não ser que o seguinte utilitário e bibliotecas estejam presentes:
gzip
libgcc
openssl
zlib
O utilitário gzip é fornecido pelo pacote SUNW-gzip e pode ser baixado a partir do link http://www.sunfreeware.com.
Nas versões recentes do Solaris, as bibliotecas necessárias são fornecidas pelos pacotes instalados nativamente a seguir:
SUNWgccruntime
SUNWopenssl*
SUNWzlib
Para versões mais antigas do Solaris, os pacotes a seguir poderão ser baixados a partir do site http://www.sunfreeware.com:
SMClibgcc ou SMCgcc
SMCossl
SMCzlib
Para verificar se o pacote está instalado no cliente, use o comando pkginfo. Por exemplo, para procurar por um pacote que contenha "zlib" no nome, rode o seguinte comando:
pkginfo | grep zlib
# pkginfo | grep zlib
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Nota
Os nomes de arquivo do pacote diferem do nome do pacote instalado. Por exemplo, o arquivo do pacote libgcc<version>-sol<solaris-version>-sparc-local.gz se torna SMClibgcc após a instalação.
Copiar o linkLink copiado para a área de transferência!
Para habilitar o cliente Solaris para usar as bibliotecas instaladas no passo anterior, você deve adicionar sua localização ao caminho de busca da biblioteca. Para fazer isto, primeiro verifique o caminho de busca da biblioteca atual":
crle -c /var/ld/ld.config
# crle -c /var/ld/ld.config
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Observe o Caminho da Biblioteca Padrão atual. Depois disso, modifique o caminho para incluir também os componentes demonstrados abaixo. Observe que a opção -l reseta o valor, ao invés de acrescentar, portanto se eles já haviam valores configurados em seu sistema, preceda-os para o parâmetro -l.
Copiar o linkLink copiado para a área de transferência!
Faça o download do tarball apropriado dos pacotes a partir do diretório /var/www/html/pub/ de seu Satellite. Se você estiver apto a usar o navegador da Web, o GUI, como o Mozilla, navegue no diretório /pub do Satellite e salve o tarball correto em seu cliente:
http://your-satellite.example.com/pub/Red Hat Network-solaris-bootstrap-<version>-<solaris-arch>-<solaris-version>.tar.gz
http://your-satellite.example.com/pub/Red Hat Network-solaris-bootstrap-<version>-<solaris-arch>-<solaris-version>.tar.gz
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se você precisar fazer o download do tarball a partir da linha de comando, pode ser possível usar ftp para transferir para o arquivo a partir do Satellite para o Cliente.
Ao usar o gzip, descomprima o tarball. Você deve ter os seguintes pacotes:
RHATpossl
RHATrhnrcfg
RHATrhnrcfga
RHATrhnrcfgc
RHATrhnrcfgm
RHATRed Hat Networkc
RHATRed Hat Networkl
RHATrpush
RHATsmart
SMClibgcc e SMCosslg também podem estar inclusos no tarball.
Copiar o linkLink copiado para a área de transferência!
Mude para o diretório descomprimido e use a ferramenta de instalação nativa da variante UNIX para instalar cada pacote. Por exemplo, no Solaris, use o comando pkgadd. Responda "yes" (Sim) para quaisquer solicitações durante a instalação do pacote.
Aqui segue como uma instalação deve geralmente proceder:
pkgadd -d RHATpossl-0.6-1.p24.6.pkg all
pkgadd -d RHATpythn-2.4.1-2.rhn.4.sol9.pkg all
pkgadd -d RHATrhnl-1.8-7.p23.pkg all
...
# pkgadd -d RHATpossl-0.6-1.p24.6.pkg all
# pkgadd -d RHATpythn-2.4.1-2.rhn.4.sol9.pkg all
# pkgadd -d RHATrhnl-1.8-7.p23.pkg all
...
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Nota
Use a opção -n para pkgadd, para rodar o comando em um modo não interativo. No entanto, isto pode resultar na falha da instalação de alguns pacotes, silenciosamente, no Solaris 10.
Continue até que cada pacote esteja instalado no caminho Red Hat-específico: /opt/redhat/rhn/solaris/.
Copiar o linkLink copiado para a área de transferência!
Para disponibilizar os pacotes Red Hat Network em cada registro, você precisa adicioná-los ao seu PATH. Para fazer isto, adicione estes comandos ao seu script de registro:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para habilitar o acesso às páginas man de comando cliente Red Hat Network, adicione-os ao seu MANPATH. Para fazer isto, adicione os seguintes comandos ao seu script de registro:
Copiar o linkLink copiado para a área de transferência!
To ensure secure data transfer, Red Hat strongly recommends the use of SSL. The Red Hat Satellite eases implementation of SSL by generating the necessary certificates during its installation. The server-side certificate is automatically installed on the Satellite itself, while the client certificate is placed in the /pub/ directory of the Satellite's Web server.
Para instalar o certificado, siga estes passos para cada cliente:
Faça o download do certificado SSL a partir do diretório /var/www/html/pub/ do Red Hat Satellite em um sistema cliente. O certificado será nomeado com algo semelhante ao RHN-ORG-TRUSTED-SSL-CERT. É acessível via web no seguinte URL: https://your-satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT.
Mova o certificado SSL cliente para o diretório específico do Red Hat Network para sua variante de UNIX. Para Solaris, isto pode ser concluído com um comando similar ao:
mv /path/to/Red Hat Network-ORG-TRUSTED-SSL-CERT /opt/redhat/Red Hat Network/solaris/usr/share/Red Hat Network/
mv /path/to/Red Hat Network-ORG-TRUSTED-SSL-CERT /opt/redhat/Red Hat Network/solaris/usr/share/Red Hat Network/
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Depois de concluído, o novo certificado cliente será instalado no diretório apropriado para seu sistema UNIX. Se você tiver vários sistemas para preparar para gerenciamento do Red Hat Network, você pode fazer um script para este processo todo.
Agora você deve reconfigurar os aplicativos cliente Red Hat Network para se referir aos certificados SSL recentemente instalados. Consulte a Seção 2.1.3.3, “Configurando clientes” para instruções.
Copiar o linkLink copiado para a área de transferência!
O passo final antes de registrar seus sistemas clientes com o Red Hat Network é reconfigurar seus aplicativos Red Hat Network para usar o novo certificado SSL e obter as atualizações a partir do Red Hat Satellite . Ambas mudanças podem ser feitas editando o arquivo de configuração do Red Hat Update Agent, que fornece registro e atualiza a funcionalidade.
Siga estes passos em cada sistema cliente:
Como root, mude para o diretório de configuração Red Hat Network para o sistema. Para Solaris, o caminho completo é /opt/redhat/rhn/solaris/etc/sysconfig/rhn/.
Abra o arquivo de configuração up2date em um editor de texto.
Encontre a entrada serverURL e ajuste seu valor para nome de domínio totalmente qualificado (FQDN) de seu Red HatSatellite :
serverURL[comment]=Remote server URL
serverURL=https://your-satellite.example.com/XMLRPC
serverURL[comment]=Remote server URL
serverURL=https://your-satellite.example.com/XMLRPC
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Assegure-se de que os aplicativos se referem ao Red Hat Satellite até quando o SSL estiver desligado, configurando também o valor noSSLServerURL para o Satellite:
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your-satellite.example.com/XMLRPC
noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your-satellite.example.com/XMLRPC
Copy to ClipboardCopied!Toggle word wrapToggle overflow
sslCACert[comment]=The CA cert used to verify the ssl server
sslCACert=/opt/redhat/Red Hat Network/solaris/usr/share/Red Hat Network/Red Hat Network-ORG-TRUSTED-SSL-CERT
sslCACert[comment]=The CA cert used to verify the ssl server
sslCACert=/opt/redhat/Red Hat Network/solaris/usr/share/Red Hat Network/Red Hat Network-ORG-TRUSTED-SSL-CERT
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Seus sistemas cliente estão agora prontos para registro com o Red Hat Network e gerenciamento pelo seu Satellite.
Copiar o linkLink copiado para a área de transferência!
Agora que você instalou os pacotes específicos do Red Hat Network, implementou a SSL e reconfigurou seus sistemas clientes para conectar ao Red Hat Satellite , você está pronto para iniciar o registro dos sistemas e obter atualizações.
Copiar o linkLink copiado para a área de transferência!
Esta seção descreve o processo de registro dos sistemas UNIX no Red Hat Network. 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 Red Hat Network, 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.
Para registrar sistemas UNIX com o seu Red Hat 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.
Após criar a chave, clique em seu nome na lista Chaves de Ativação (Activation Keys) para aprimorar sua configuração no Red Hat Network, associando canais de software e de configuração e grupos de sistemas.
Abra um terminal no sistema cliente a ser registrado 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:
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 fontes. Por esta razão, esta seção procura destacar as diferenças no uso das ferramentas do Red Hat Network em sistemas UNIX. Nota: o Red Hat Network 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 Red Hat Network 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 Red Hat Satellite Getting Started 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.
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 Red Hat Network 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 Red Hat Network 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.
Copiar o linkLink copiado para a área de transferência!
O Red Hat Network 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 Red Hat Network 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.
Copiar o linkLink copiado para a área de transferência!
Conforme mencionado brevemente na seção Seção 2.1.1.4, “Diferenças nas Funcionalidades”, o solaris2mpm faz parte do Red Hat Network Push para Solaris. 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:
solaris2mpm RHATrpush-3.1.5-21.pkg RHATrpush-3.1.5-23.pkg
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-21.sparc-solaris.mpm
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-23.sparc-solaris.mpm
# solaris2mpm RHATrpush-3.1.5-21.pkg RHATrpush-3.1.5-23.pkg
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-21.sparc-solaris.mpm
Opening archive, this may take a while
Writing out RHATrpush-3.1.5-23.sparc-solaris.mpm
Copy to ClipboardCopied!Toggle word wrapToggle overflow
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
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Pacth clusters são "explodidos". - arquivos .mpm são gerados para cada patch no cluster, tanto quanto um nível superior "meta", o arquivo .mpm contém informações sobre o cluster como um todo.
Segue abaixo as opções do solaris2mpm:
Expand
Tabela 2.2. 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.
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:
% rhnpush -v --server testbox.example.com --username myuser -c solaris-8 \
RHATrpush-3.1.5-*.mpm
Red Hat Network password:
Connecting to http://testbox.example.com/APP
Uploading package RHATrpush-3.1.5-21.sparc-solaris.mpm
Uploading package RHATrpush-3.1.5-23.sparc-solaris.mpm
% rhnpush -v --server testbox.example.com --username myuser -c solaris-8 \
RHATrpush-3.1.5-*.mpm
Red Hat Network password:
Connecting to http://testbox.example.com/APP
Uploading package RHATrpush-3.1.5-21.sparc-solaris.mpm
Uploading package RHATrpush-3.1.5-23.sparc-solaris.mpm
Copy to ClipboardCopied!Toggle word wrapToggle overflow
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 Red Hat Network Push para carregá-los no canal que criado para eles.
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 Sistemas, selecione os pacotes nas listas (Atualização) Upgrade ou (Instalar) Install da aba Packages (Pacotes) ou Patches e clique em Install/Upgrade Selected Packages (Instalar/Atualizar Pacotes Selecionados).
Para rodar um comando remoto enquanto instalar o pacote, clique em Executar Comando Remoto ao invés de Confirmar. Consulte a Seção 2.1.5, “Comandos Remotos” para instruções.
Para instalar pacotes ou patches em sistemas múltiplos de uma só vez, selecione os sistemas e clique em Gerenciador de Conjunto de Sistemas (System Set Manager) na barra de navegação esquerda. Em seguida, na aba Packages (Pacotes), selecione os pacotes nas listas Upgrade ou Install e clique em Install/Upgrade Packages (Instalar/Atualizar Pacotes). Para completar a ação, agende as atualizações.
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 Red Hat Network, inicia automaticamente durante a inicialização do sistema. Em sistemas Solaris, o rhnsdnã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
Copy to ClipboardCopied!Toggle word wrapToggle overflow
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:
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 podem ser executadas 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 2.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:
Expand
Tabela 2.4. Argumentos da Linha de Comando do Agente de Atualizações
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 Red Hat Network.
--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 usados para atualizações usando etiquetas de canais.
--get
Obtém o pacote especificado sem resolver as dependências.
Copiar o linkLink copiado para a área de transferência!
Junto ao suporte ao UNIX, o Red Hat Network oferece a flexibilidade de invocar comandos remotos em sistemas cliente através do site do Satellite. Esta funcionalidade permite a você rodar praticamente qualquer aplicação ou script (compatível) em qualquer sistema de seu domínio sem nunca precisar abrir um terminal.
Copiar o linkLink copiado para a área de transferência!
A flexibilidade desta ferramenta traz um grande risco e a responsabilidade de reduzir tal risco. Para todos os propósitos práticos, esta funcionalidade concede um prompt BASH root para qualquer um com acesso administrativo ao sistema no website.
No entanto, isto pode ser controlado através do mesmo mecanismo config-enable usado para determinar quais sistemas podem ter seus arquivos de configuração administrados pelo Red Hat Network.
Em suma, você deve criar um diretório e um arquivo no sistema UNIX que informem ao Red Hat Network que é aceitável rodar comandos remotos na máquina. O diretório dever ser nomeado como script; o arquivo dever ser nomeado como run e ambos devem estar alocados no diretório /etc/sysconfig/Red Hat Network/allowed-actions/ específico de sua variante do UNIX.
Por exemplo: no Solaris, invoque este comando para criar o diretório:
mkdir -p /opt/redhat/Red Hat Network/solaris/etc/sysconfig/Red Hat Network/allowed-actions/script
mkdir -p /opt/redhat/Red Hat Network/solaris/etc/sysconfig/Red Hat Network/allowed-actions/script
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para criar o arquivo requisitado no Solaris, invoque este comando:
touch /opt/redhat/Red Hat Network/solaris/etc/sysconfig/Red Hat Network/allowed-actions/script/run
touch /opt/redhat/Red Hat Network/solaris/etc/sysconfig/Red Hat Network/allowed-actions/script/run
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copiar o linkLink copiado para a área de transferência!
Você pode agendar um comando remoto de diversas maneiras: num sistema separado, em sistemas múltiplos de uma só vez e acompanhando uma ação de pacotes.
Para rodar um comando remoto num sistema separado, abra a página System Details (Detalhes do Sistema) e clique na sub-aba Remote Command (Comando Remoto). Note que esta sub-aba apenas aparece se o sistema tiver direito à Provisionamento (Provisioning). Nesta página, estabeleça a configuração para o comando. Você pode identificar um usuário, um grupo e um período limite específicos, assim como o próprio script. Selecione uma data e uma hora para iniciar a tentativa do comando e então clique no link Schedule Remote Command (Agendar Comando Remoto).
Da mesma forma, você pode invocar um comando remoto em sistemas múltiplos de uma vez através do System Set Manager (Gerenciador de Conjunto de Sistemas). Selecione os sistemas, navegue para o System Set Manager (Gerenciador de Conjunto de Sistemas), clique na aba Misc (Diversos) e role a página até a seção Remote Command (Comando Remoto). Aqui você pode rodar um comando remoto nos sistemas selecionados de uma só vez.
Para rodar um comando remoto junto a uma ação de pacotes, agende a ação através da aba Packages (Pacotes) da página System Details (Detalhes do Sistema) e clique em Run Remote Command (Rodar Comando Remoto) enquanto confirma a ação. Use os botões no topo da página para determinar se o comando deve rodar antes ou depois da ação de pacotes, estabeleça a configuração do comando e clique em Schedule Package Install/Upgrade (Agendar Instalação/Atualização de Pacotes).
Note que instalar pacotes múltiplos que possuem comandos remotos diferentes requer o agendamento das instalações separadamente ou a combinação dos comandos num único script.
Copiar o linkLink copiado para a área de transferência!
O Red Hat Network Package Manager é uma ferramenta de linha de comando que permite que uma empresa sirva pacotes locais associados com um canal do Red Hat Network privado através o Red Hat Network Proxy Server. Para atualizar somente os pacotes da Red Hat oficiais para o Red Hat Network Proxy Server, não instale o Red Hat Network Package Manager.
Para usar o Red Hat Network Package Manager, instale o pacote spacewalk-proxy-package-manager e suas dependências.
Somente as informações de pacotes têm upload aos Servidores da Red Hat Network. Os cabeçalhos são necessários para que a Red Hat Network possa resolver as dependências de pacotes para os sistemas cliente. Os arquivos de pacotes em si (*.rpm) são armazenados no Red Hat Network Proxy Server .
O Red Hat Network Package Manager usa a mesma configuração que o Proxy, definida no arquivo de configuração /etc/Red Hat Network/Red Hat Network.conf.
Segue um resumo de todas as opções de linha de comando do Red Hat Network Package Manager, Red Hat Network_package_manager:
Expand
Tabela 3.1. opções do Red Hat Network_package_manager
Opção
Descrição
-v, --verbose
Aumentar a verbosidade.
-dDIR, --dir=DIR
Processar os pacotes do diretório DIR.
-cCANAL, --channel=CANAL
Administrar este canal - deve estar presente diversas vezes.
-nNÚMERO, --count=NÚMERO
Processa este número de cabeçalhos por chamada - o default são 32.
-l, --list
Listar o nome, número da versão, número do lançamento e arquitetura de cada pacote no(s) canal(is) especificado(s).
-s, --sync
Verificar se o diretório local está sincronizado com o servidor.
-p, --printconf
Imprime a configuração atual e fecha.
-XEXPRESSÃO, --exclude=EXPRESSÃO
Excluir arquivos que possuem a expressão - pode estar presente diversas vezes.
--newest
Forçar somente os pacotes mais novos que aqueles já forçados ao servidor para o canal especificado.
--stdin
Ler os nomes dos pacotes pelo stdin.
--nosig
Forçar pacotes não assinados. Por padrão, o Red Hat Network Package Manager tenta forçar somente os pacotes assinados.
--username=NOMEDEUSUÁRIO
Especificar seu nome de usuário na Red Hat Network. Se você não indicar um nome de usuário com esta opção, o sistema o pedirá.
--password=SENHA
Especificar sua senha na Red Hat Network Se você não prover uma com esta opção, o sistema a pedirá.
--source
Fazer upload dos cabeçalhos dos pacotes fonte.
--dontcopy
No passo pós-upload, não copiar os pacotes para sua localização final na árvore de pacotes.
--test
Imprimir somente os pacotes a serem forçados.
--no-ssl
Não recomendado - Desativar a SSL.
-?, --usage
Descrever brevemente as opções.
--copyonly
Copiar o arquivo listado no argumento ao canal especificado. Útil quando um canal do proxy carece de um pacote e você não deseja reimportar todos os pacotes do canal. Ex.:, Red Hat Network_package_manager-cCHANNEL--copyonly/CAMINHO/DO/ARQUIVO/FALTANDO
-h, --help
Exibe a tela de ajuda com uma lista de opções.
Nota
Estas opções de linha de comando também estão descritas na página man do Red Hat Network_package_manager: man Red Hat Network_package_manager.
Para que o Red Hat Network Package Manager conseguir servir os pacotes locais, os passos a seguir precisam ser seguidos:
Criando um Canal Privado
Carregue os pacotes locais no canal.
Os passos serão discutidos mais tarde nas próximas seções.
Copiar o linkLink copiado para a área de transferência!
Antes dos pacotes locais poderem ser providos através do Red Hat Network Proxy Server , é necessário um canal privado para armazená-los. Execute os seguintes passos para criar um canal privado:
Autentique-se na interface da Web doRed Hat Network em https://rhn.redhat.com ou no servidor da Red Hat Satellite local na rede.
Clique em Canais (Channels) na barra de navegação superior. Se a opção Administrar Canais (Manage Channels) não estiver presente na barra de navegação esquerda, garanta que este usuário tenha o conjunto de permissões para edição do canal. Faça isso através da categoria Usuários (Users), acessível pela barra de navegação superior.
Na barra de navegação esquerda, clique em Administrar Canais de Software (Manage Software Channels) e então no botão criar novo canal (create new channel) no canto superior direito da página.
Selecione um canal pai e uma arquitetura de canal base, então indique um nome, etiqueta, sumário e descrição do novo canal privado. A etiqueta do canal deve: ter no mínimo seis caracteres, começar por uma letra e conter somente caracteres em caixa baixa, dígitos, hífens (-) e pontos(.). Além disso, indique também a URL da chave GPG do canal. Apesar deste campo não ser obrigatório, é recomendado para uma melhor segurança. Para obter instruções da geração das chaves GPG, consulte o Guia de Administração de Canais Red Hat Network.
Copiar o linkLink copiado para a área de transferência!
Nota
Você deve ser um Administrador de Organização para fazer o upload de pacotes a canais privados da Red Hat Network. O script pedirá que você indique seu nome de usuário e senha da Red Hat Network.
Após criar o canal privado, faça o upload dos cabeçalhos dos pacotes de seus RPMs fonte e binários ao Servidor da Red Hat Network e copie os pacotes para o Red Hat Network Proxy Broker Server. Para fazer o upload dos cabeçalhos dos pacotes dos RPMs binários, invoque o seguinte na linha de comando:
Red Hat Network_package_manager -c "label_of_private_channel" pkg-list
Red Hat Network_package_manager -c "label_of_private_channel" pkg-list
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Este comando irá carregar o cabeçalho do pacote para o nome do canal especificado, e o pacote para o /var/spool/Red Hat Network-proxy/Red Hat Network.
pkg-list é a lista de pacotes para upload. Alternativamente, use a opção -d para especificar o diretório local que contém os pacotes a serem adicionados ao canal. Garanta que o diretório contenha somente os pacotes a serem inclusos e nenhum outro arquivo. O Red Hat Network Package Manager também pode ler a lista de pacotes a partir do standard input (usando --stdin).
Para fazer o upload dos cabeçalhos de pacotes dos RPMs fonte:
Red Hat Network_package_manager -c "label_of_private_channel" --source pkg-list
Red Hat Network_package_manager -c "label_of_private_channel" --source pkg-list
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se você tiver mais de um canal especificado (usando -c ou --channel), os cabeçalhos de pacotes do upload serão linkados a todos os pacotes listados.
Nota
Se o nome de um canal não é especificado, os pacotes não são adicionados a nenhum canal. Os pacotes podem, então, ser adicionados a um canal usando a interface Web da Red Hat Network, onde você também pode modificar os canais privados existentes.
Após o upload dos pacotes, você pode verificar imediatamente se estão presentes na interface Web da Red Hat Network. Clique em Canais na barra de navegação superior, Administrar Canais de Software na barra de navegação esquerda e então no nome do canal personalizado. Em seguida, clique na sub-seção Pacotes. Todos os RPMs devem estar listados.
Você também pode verificar se o diretório local está sincronizado com a imagem dos canais no Servidor da Red Hat Network, na linha de comando:
Red Hat Network_package_manager -s -c "label_of_private_channel"
Red Hat Network_package_manager -s -c "label_of_private_channel"
Copy to ClipboardCopied!Toggle word wrapToggle overflow
A opção -s listará todos os pacotes que estão faltando (pacotes carregados no Red Hat Network Server que não estão presentes no diretório local). Você precisa ser um Administrador de Empresas para utilizar este comando. O script irá solicitar que você insira o username e senha.
Se você está usando o Red Hat Network Package Manager para atualizar pacotes locais, deve navegar no site da Red Hat Network para registrar o sistema no canal privado.
Copiar o linkLink copiado para a área de transferência!
Este capítulo traz uma visão geral da criação de pacotes a serem entregues pela Red Hat Network. Os tópicos abordados incluem por que usar o RPM, como criar pacotes para a Red Hat Network e como assinar pacotes adequadamente.
Copiar o linkLink copiado para a área de transferência!
A Red Hat Network usa a tecnologia Administrador de Pacotes RPM (RPM Package Manager, RPM) para determinar quais softwares devem ser adicionados e atualizados em cada sistema cliente. Os pacotes obtidos pela Red Hat Network geralmente têm o formato RPM. No entanto, também são disponibilizadas imagens ISO inteiras através da aba Software no site da Red Hat Network, mas não para as instalações Servidor Red Hat Satellite. Se o seu Satellite tem o suporte ao Solaris habilitado, você pode usar o Red Hat Network Push para fazer o upload dos pacotes Solaris aos canais personalizados usados por clientes Solaris.
RPM é uma ferramenta que oferece aos usuários um método simples para instalação, desinstalação, atualização e verificação de pacotes de software. Também permite aos desenvolvedores empacotar o código fonte e versões compiladas de um programa para outros desenvolvedores e usuários finais.
Copiar o linkLink copiado para a área de transferência!
O RPM oferece as seguintes vantagens:
Atualizações Fáceis
Usando o RPM, você pode atualizar componentes de um sistema separadamente sem precisar reinstalar completamente. Quando a Red Hat lança uma nova versão do Red Hat Enterprise Linux, não é necessário que os usuários a reinstalem para atualizá-la. O RPM permite atualizações inteligentes, totalmente automatizadas e disponibilizadas em seu sistema. Os arquivos de configuração em pacotes são preservados durante as atualizações de modo que os usuários não percam suas configurações personalizadas. Não há necessidade de arquivos especiais para a atualização de um pacote porque o mesmo arquivo RPM é usado para instalar e atualizar o pacote.
Busca de Pacotes
O RPM provém opções de busca que permitem procurar no banco de dados inteiro por todos os pacotes ou apenas por determinados arquivos. Você também pode facilmente descobrir a qual pacote um arquivo pertence e de onde o pacote originou. Os arquivos contidos no pacote estão num arquivo comprimido, com um cabeçalho binário personalizado contendo informações sobre o pacote e seu conteúdo. O RPM faz uma busca simples e rápida nos cabeçalhos.
Verificação do Sistema
Um outro recurso permite a verificação de pacotes. Se você está preocupado com um arquivo relacionado à um pacote removido, verifique o estado dos arquivos providos por este pacote. A verificação o notifica sobre quaisquer anomalias. Se houver erros, você pode reinstalar os arquivos facilmente. Os arquivos de configuração modificados são preservados durante a instalação.
Recursos do Pristine
O objetivo principal da criação do RPM é permitir o uso dos recursos do software original, conforme distribuído pelos seus autores originais. Com o RPM, os recursos do original podem ser empacotados junto a quaisquer reparos (patches) que foram usados, além das instruções completas para a construção (build). Esta é uma grande vantagem por diversos motivos. Por exemplo: se uma nova versão de um programa é lançada, não é necessário começar do zero para compilá-la. Você pode observar o patch para ver o que precisa fazer. Todos os defaults e alterações já compiladas feitas para que o software seja criado apropriadamente são facilmente visíveis usando esta técnica.
Manter os recursos originais pode parecer importante somente a desenvolvedores, porém resulta num software de melhor qualidade para usuários finais também.
Copiar o linkLink copiado para a área de transferência!
Uma vantagem do RPM é sua habilidade em definir as dependências e identificar os conflitos com acuracidade. A Red Hat Network baseia-se neste aspecto do RPM, oferecendo um ambiente automatizado, ou seja, nenhuma intervenção manual pode ocorrer durante a instalação de um pacote. Sendo assim, ao criar RPMs para distribuir através da Red Hat Network, é imprescindível seguir estas regras:
Entenda o RPM. É essencial ter um conhecimento fundamental dos principais recursos do RPM para criar pacotes apropriadamente. Para mais informações sobre o RPM, comece pelos seguintes recursos:
Ao criar um RPM para um canal filho, crie o pacote numa nova instalação do Red Hat Enterprise Linux com a mesma versão do canal base do filho. Mas antes, certifique-se de aplicar todas as atualizações pela Red Hat Network.
O pacote RPM deve instalar sem usar as opções --force ou --nodeps. Se você não puder instalar um RPM de forma limpa no seu sistema build, a Red Hat Network não poderá instalá-lo num sistema.
O nome do pacote RPM deve ter o formato NVR (nome, versão, lançamento) e deve conter a arquitetura do pacote. O formato apropriado é nome-versão-lançamento.arq.rpm. Por exemplo: um nome válido para um pacote RPM é nomepacote-0.84-1.i386.rpm, onde o nome é nomepacote, a versão é 0.84, lançamento 1 e a arquitetura é i386.
O pacote RPM deve ser assinado pelo seu mantenedor. Pacotes não-assinados podem ser distribuídos pela Red Hat Network, mas o atualizador yum deve ser forçado a aceitá-los. É altamente recomendável assinar pacotes; veja mais detalhes na Seção 4.2, “Assinaturas Digitais para os pacotes do Red Hat Network”.
Se o pacote for alterado de alguma forma, inclusive na assinatura ou recompilação, a versão ou lançamento devem ser incrementalmente aumentados. Ou seja, o NVRA (incluindo arquitetura) de cada RPM distribuído através da Red Hat Network deve corresponder a um único build para evitar ambiguidades.
Nenhum pacote RPM pode se tornar obsoleto.
Se um pacote é dividido em pacotes distintos, seja muito cuidadoso com as dependências. Não divida um pacote existente, a não ser que haja uma boa razão para tanto.
Nenhum pacote pode basear-se na pré-instalação, pós-instalação, pré-desinstalação, ou pós-desinstalação interativas. Se o pacote requer intervenção direta do usuário, não funcionará na Red Hat Network.
Nenhum script de pré-instalação, pós-instalação, pré-desinstalação e pós-desinstalação deve gravar nada no stderr ou stdout. Redirecione as mensagens para /dev/null se não forem necessárias. Caso contrário, salve-as num arquivo.
Quando criar o arquivo de especificações, use as definições do grupo em /usr/share/doc/rpm-<versão>/GRUPOS. Se não há nenhuma ocorrência exata, selecione a próxima ocorrência que achar melhor.
Use a funcionalidade de dependência do RPM para garantir que o programa rode após instalado.
Importante
Não crie um RPM armazenando arquivos e então desarmazenando-os no script de pós-instalação. Isso elimina o propósito do RPM.
Se os arquivos do armazenamento não forem inclusos na lista, não serão verificados ou examinados em busca de conflitos. Na grande maioria dos casos, o próprio RPM pode empacotar e desempacotar arquivos mais efetivamente. Por exemplo: não crie arquivos num %post que você não limpar %postun.
Copiar o linkLink copiado para a área de transferência!
Todos os pacotes distribuídos através da Red Hat Network devem ter uma assinatura digital. Esta é criada através de uma chave privada única e pode ser verificada com sua chave pública correspondente. Após criar um pacote, o SRPM (Source RPM ou RPM Fonte) e o RPM podem ser assinados digitalmente com uma chave GnuPG. Antes do pacote ser instalado, a chave pública é usada para verificar se o pacote foi assinado por uma entidade confiável e se não foi alterado desde que foi assinado.
Copiar o linkLink copiado para a área de transferência!
O par de chaves GnuPG consiste de chaves privadas e públicas.
Digite o seguinte comando como usuário root na solicitação do terminal:
gpg --gen-key
gpg --gen-key
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O Keypairs GPG não deve ser criado por usuários que não sejam usuários root. Este usuário pode bloquear páginas de memória, assim as informações nunca são salvas no disco.
Após executar o comando para gerar um conjunto de chaves, você vê uma tela introdutória contendo opções da chave, similar a:
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Escolha a opção: (2) DSA and ElGamal. Esta permite criar uma assinatura digital e criptografar/descriptografar com dois tipos de tecnologias. Digite 2 e então pressione Enter.
Em seguida, escolha a extensão da chave. Quanto mais longa sua chave, mais resistente a ataques você estará. É recomendado criar uma chave de, no mínimo, 2048 bits.
A próxima opção pede a você especificar o período de validade de sua chave. Se escolher uma data de expiração, lembre-se que todos usando sua chave pública também devem ser informados sobre sua expiração e receber uma nova chave pública. É recomendado não selecionar uma data de expiração. Em seguida, você precisa confirmar sua decisão:
A chave não irá expirar nunca. Está correto (y/n)?
A chave não irá expirar nunca. Está correto (y/n)?
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Pressione y para confirmar sua decisão.
Sua próxima tarefa é prover um ID de usuário contendo seu nome, e-mail, endereço e comentário opcional. Cada um é solicitado separadamente. Ao terminar, você verá um sumário das informações indicadas.
Após aceitar suas escolhas, indique uma senha.
Nota
Assim como as senhas de suas contas, esta senha é essencial para a mais alta segurança na GnuPG. Componha sua senha com letras em caixa alta e baixa, use números e/ou inclua pontuações.
Após indicar e verificar sua senha, suas chaves são geradas. Aparece uma mensagem parecida com:
We need to generate a lot of random bytes. It is a good idea to perform some
other action (type on the keyboard, move the mouse, utilize the disks)
during the prime generation; this gives the random number generator a
better chance to gain enough entropy.
+++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++ +++.
++++++++++++++++++++++++++++++++++++++..........................++++
We need to generate a lot of random bytes. It is a good idea to perform some
other action (type on the keyboard, move the mouse, utilize the disks)
during the prime generation; this gives the random number generator a
better chance to gain enough entropy.
+++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++ +++.
++++++++++++++++++++++++++++++++++++++..........................++++
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Quando a atividade das telas terminar, suas chaves novas são colocadas no diretório .gnupg dentro do diretório home do usuário root. Este é um local padrão de chaves geradas pelo usuário root.
Para listar as chaves root, use o comando:
gpg --list-keys
gpg --list-keys
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O output é similar a:
gpg: key D97D1329 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2013-08-28
pub 2048D/D97D1329 2013-08-27 [expires: 2013-08-28]
Key fingerprint = 29C7 2D2A 5F9B 7FF7 6411 A9E7 DE3E 5D0F D97D 1329
uid Your Name<you@example.com>
sub 2048g/0BE0820D 2013-08-27 [expires: 2013-08-28]
gpg: key D97D1329 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2013-08-28
pub 2048D/D97D1329 2013-08-27 [expires: 2013-08-28]
Key fingerprint = 29C7 2D2A 5F9B 7FF7 6411 A9E7 DE3E 5D0F D97D 1329
uid Your Name<you@example.com>
sub 2048g/0BE0820D 2013-08-27 [expires: 2013-08-28]
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para obter sua chave pública, use o seguinte comando:
gpg --export -a 'Your Name' > public_key.txt
gpg --export -a 'Your Name' > public_key.txt
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Sua chave pública é gravada no arquivo public_key.txt.
Esta chave pública é muito importante. É a chave que deve ser empregada em todos os sistemas cliente que recebem software personalizado através do yum. As técnicas para empregar esta chave numa empresa inteira são cobertas no Guia de Configuração do Cliente Red Hat Network.
Copiar o linkLink copiado para a área de transferência!
Antes de poder assinar os pacotes, é necessário configurar seu arquivo ~/.rpmmacros incluindo o seguinte:
%_signature gpg
%_gpg_name B7085C8A
%_signature gpg
%_gpg_name B7085C8A
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Substitua o ID da chave _gpg_name, B7085C8A, pelo ID da chave do chaveiro GPG que você usa para assinar pacotes. Este valor dita ao RPM qual assinatura usar.
Para assinar o pacote package-name-1.0-1.noarch.rpm, use o seguinte comando:
rpm --resign package-name-1.0-1.noarch.rpm
rpm --resign package-name-1.0-1.noarch.rpm
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Indique sua senha. Para garantir que seu pacote seja assinado, use o seguinte comando:
rpm --checksig -v package-name-1.0-1.noarch.rpm
rpm --checksig -v package-name-1.0-1.noarch.rpm
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copiar o linkLink copiado para a área de transferência!
Para os clientes que planejam construir e distribuir seus próprios RPMs de forma segura, recomenda-se 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 Seção 4.2.1, “Gerando um Par de Chaves GnuPG”.
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 Red Hat Network.
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
Copy to ClipboardCopied!Toggle word wrapToggle overflow
A chave pode então ser baixada pelos sistemas de cliente, usando Wget:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
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
rpm --import /path/to/YOUR-RPM-GPG-KEY
Copy to ClipboardCopied!Toggle word wrapToggle overflow
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.
Copiar o linkLink copiado para a área de transferência!
Este capítulo traz dicas para determinar a causa e a solução para a maioria dos erros associados ao Red Hat Satellite. Se precisar de ajuda adicional, contate o suporte do Red Hat Network no site https://access.redhat.com/support/. Autentique-se usando sua conta com o direito Satellite para visualizar sua lista completa de opções.
Para começar a resolução de problemas genéricos, examine o arquivo ou arquivos de registro relacionados ao componente exibindo as falhas. Um exercício útil é invocar o comando tail -f em todos os arquivos de registro e então rodar yum list. Em seguida, você deve examinar as entradas novas dos registros para encontrar pistas potenciais.
Copiar o linkLink copiado para a área de transferência!
P:
Meu Espaço em Disco preencheu rapidamente. O que aconteceu e o que devo fazer?
R:
Um problema comum é o espaço cheio em disco (full disk space). Um sinal quase certeiro é a aparência de pausas (halts) na gravação dos arquivos de registro. Se o registro parou durante uma gravação, como no meio da palavra, os discos rígidos devem estar cheios. Para confirmar isto, rode este comando e verifique as porcentagens na coluna Use%:
df -h
# df -h
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além dos arquivos de registro, você pode obter informações valiosas pelo status de seu Red Hat Satellite e seus diversos componentes. Isto pode ser feito com o comando:
/usr/sbin/rhn-satellite status
# /usr/sbin/rhn-satellite status
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além disso, você pode obter o status dos componentes, como o servidor Apache Web e Red Hat Network Task Engine, separadamente. Por exemplo: para visualizar o status do servidor Apache Web, rode o comando:
service httpd status
# service httpd status
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copiar o linkLink copiado para a área de transferência!
P:
O SELinux continua me enviando mensagens quando estou tentando instalar. Porque?
R:
Se você se deparar com qualquer problema com as mensagens do SELinux (tal como mensagens de negação do AVC) enquanto estiver instalando o Red Hat Satellite, certifique-se de ter os arquivos audit.log disponíveis, assim os funcionários de Suporte da Red Hat poderão lhe dar uma assistência. Você pode encontrar o arquivo em /var/log/audit/audit.log e anexar o arquivo ao seu tíquete de Suporte para que os engenheiros lhe forneçam a devida assistência.
P:
Eu alterei o /var/satellite para a montagem NFS e agora o SELinux está impedindo que isto funcione adequadamente. O que eu preciso fazer?
R:
Os Parâmetros do SELinux precisam ser modificados na nova montagem do NFS para que o SELinux receba permissão para o tráfego. Faça isto utilizando este comando:
/usr/sbin/setsebool -P spacewalk_nfs_mountpoint on
# /usr/sbin/setsebool -P spacewalk_nfs_mountpoint on
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Caso você esteja usando o Red Hat Enterprise Linux 6, você precisará também rodar o comando abaixo:
/usr/sbin/setsebool -P cobbler_use_nfs on
# /usr/sbin/setsebool -P cobbler_use_nfs on
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Meu Satellite está falhando. Alguma ideia do porque?
R:
Não inscreva o Red Hat Satellite a nenhum dos seguintes canais filho disponíveis nos servidores centrais do Red Hat Network:
Red Hat Developer Suite
Red Hat Application Server
Red Hat Extras
Canais de Produto do JBoss
A subscrição a esses canais e atualização no Satellite poderá instalar versões incompatíveis, novas de componentes de software críticos, levando à falha do Satellite.
Copiar o linkLink copiado para a área de transferência!
P:
Por que o servidor Apache Web não está rodando?
R:
Se o servidor do Apache Web não estiver rodando, as entradas de seu arquivo /etc/hosts podem estar incorretas.
P:
Como descubro qual é o estado do Red Hat Network Task Engine?
R:
Para obter o status do Red Hat Network Task Engine, rode o comando:
service taskomatic status
# service taskomatic status
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Como descubro qual estado está o Banco de Dados do Satellite?
R:
Para obter os status do Banco de Dados Incorporado do Satellite, se houver, execute o comando:
db-control status
# db-control status
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
O que faço se a capacidade push do Red Hat Network Satellite parar de funcionar?
R:
Se a funcionalidade push do Red Hat Satellite parar de funcionar, podem existir registros antigos com falhas. Pare o daemon problemático antes de remover estes arquivos. Para tanto, invoque o seguinte comando como root:
service jabberd stop
rm -f /var/lib/jabberd/db/_db*
service jabberd start
# service jabberd stop
# rm -f /var/lib/jabberd/db/_db*
# service jabberd start
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Copiar o linkLink copiado para a área de transferência!
P:
Não posso conectar! Como descubro o que está errado?
R:
As medidas seguintes podem ser usadas para resolver erros de conexão genéricos:
Tente conectar ao banco de dados do Red Hat Satellite na linha de comando usando o string da conexão, conforme encontrado no /etc/rhn/rhn.conf:
sqlplus username/password@sid
# sqlplus username/password@sid
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Garanta que o Red Hat Satellite esteja usando o Network Time Protocol (NTP) e configurado com o fuso horário apropriado. Isto também se aplica a todos os sistemas cliente e à máquina separada do banco de dados no Red Hat Satellite com o Banco de Dados.
Copy to ClipboardCopied!Toggle word wrapToggle overflow
está instalado no Red Hat Satellite e se o rhn-org-trusted-ssl-cert-*.noarch.rpm ou o certificado (cliente) CA SSL público bruto está instalado em todos os sistemas cliente.
Verifique se os sistemas clientes estão configurados para usar o certificado apropriado.
Se usar também um ou mais Servidores Red Hat Satellite Proxy, garanta que cada certificado SSL do Proxy esteja preparado corretamente. O Proxy deve ter ambos, o par de chaves SSL de seu próprio servidor e o certificado (cliente) público SSL da CA, instalados, já que servirá nas duas capacidades. Consulte o capítulo SSL Certificates do Guia de Configuração do Cliente Red Hat Satellite para instruções específicas.
Assegure-se de que os sistemas de cliente não estão utilizando firewalls próprios, bloquendo as portas requeridas como identificado na seção Red Hat Satellite Installation Guide's Additional Requirements
P:
O que faço se importar ou sincronizar um canal falhar e eu não possa recuperar isso?
R:
Se a importação/sincronização de um canal falhar e você não puder recuperá-la de nenhuma outra maneira, rode este comando para apagar o cache:
rm -rf temporary-directory
# rm -rf temporary-directory
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Nota
A seção Red Hat Satellite Installation Guide em Preparing for Import from Local Media especifica /var/rhn-sat-import/ como o diretório temporário.
Em seguida, reinicie a importação ou sincronização.
P:
Estou recebendo o erro "SSL_CONNECT". O que faço agora?
R:
Um problema de conexão comum, indicado por erros SSL_CONNECT, é o resultado da instalação de um Satellite numa máquina cuja hora foi configurada inapropriadamente. Durante o processo de instalação do Satellite, os certificados SSL são criados com horas incorretas. Se a hora do Satellite é então corrigida, a data e hora de início do certificado podem ser configuradas no futuro, tornando-o inválido.
Para resolver isso, verifique a data e hora nos clientes e no Satellite com o seguinte comando:
date
# date
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Os resultados devem ser praticamente idênticos em todas as máquinas e dentro das janelas de validação "notBefore" e "notAfter" dos certificados. Verifique as datas e horas do certificado do cliente com o seguinte comando:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Por padrão, o certificado do servidor tem vida útil de um ano, enquanto os certificados do cliente são válidos por 10 anos. Se você descobrir que os certificados estão incorretos, pode aguardar a hora de início da validação, se possível, ou criar novos certificados com as horas de todos os sistemas definidas como GMT, preferencialmente.
Copiar o linkLink copiado para a área de transferência!
P:
Quais são os diferentes arquivos de log?
R:
Praticamente toda a resolução de problemas deve começar pela verificação do(s) arquivo(s) de registro associado(s). Estes provêm informações valiosas sobre as atividades do dispositivo ou do aplicativo que podem ser usadas para monitorar o desempenho e garantir a configuração apropriada. Consulte a Tabela 5.1, “Arquivos de Registro (Log Files)” para o caminho para todos arquivos de log relevantes:
Podem haver arquivos de log numerados (tais como /var/log/rhn/rhn_satellite_install.log.1, /var/log/rhn/rhn_satellite_install.log.2, etc.) dentro do diretório /var/log/rhn/. Estes são os logs do rotated, que são arquivos de log criados com uma extensão do .<NUMBER> quando o arquivo atual rhn_satellite_install.log preenche até um tamanho especificado pelo daemon do logrotate(8) e o conteúdo gravado em um arquivo de log roteado. Por exemplo, o rhn_satellite_install.log.1 contém o arquivo de log roteado mais antigo, enquanto o rhn_satellite_install.log.4 contém o log roteado mais recente.
Expand
Tabela 5.1. Arquivos de Registro (Log Files)
Componente/Tarefa
Localidade do Arquivo de Registro
Apache Web server
diretório /var/log/httpd/
Red Hat Satellite
diretório /var/log/rhn/
Red Hat Satellite Installation Program
/var/log/rhn/rhn_satellite_install.log
Instalação de banco de dados- Banco de Dados Incorporado
/var/log/rhn/install_db.log
População do banco de dados
/var/log/rhn/populate_db.log
Ferramenta de Sincronização Red Hat Satellite
/var/log/rhn/rhn_server_satellite.log
Infraestrutura de Monitoração
diretório /var/log/nocpulse/
Notificação de Monitoração
diretório /var/log/notification/
Red Hat Network DB Control - Banco de Dados Incorporado
/var/log/rhn/rhn_database.log
Mecanismo da Tarefa do Red Hat Network Task Engine (taskomatic)
/var/log/messages
yum
/var/log/yum.log
transações XML-RPC
/var/log/rhn/rhn_server_xmlrpc.log
P:
Como uso o spacewalk-report?
R:
Existem instâncias onde os administradores podem precisar de um sumário formatado e conciso de seus recursos do Red Hat Satellite, seja para tomar o inventário de seus direitos, sistemas subscritos ou usuários e empresas. Ao invés de reunir tais informações manualmente utilizando o Satellite interface, Red Hat Satellite inclui o comando spacewalk-report que reúne e exibe informações vitais do Satellite de uma só vez.
Nota
Para utilizar o spacewalk-report você precisar ter o pacote spacewalk-reports instalado.
O spacewalk-report permite que os administradores organizem e exibam relatórios sobre o conteúdo, sistemas, histórico de evento de sistema e recursos de usuários pelo Satellite. Usando spacewalk-report, você pode receber relatório em:
System Inventory - Lista todos os sistemas registrados no Satellite.
Entitlements - Lista todas as empresas no Satellite e ordenadas pelo sistema ou direitos de canais.
Errata - Lista todas as erratas relevantes aos sistemas registrados e ordena erratas pela severidade assim como sistemas que aplicam à erratum em particular.
Usuários - Lista todos os usuários registrados no Satellite e lista todos os sistemas associados com um usuário específico.
Histórico do Sistema - Lista todos, ou um subconjunto, os eventos de sistema ocorridos.
Para obter um relatório no formato CVS, rode o seguinte comando no prompt do sistema de seu servidor Satellite.
spacewalk-report report_name
# spacewalk-report report_name
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Os seguintes relatórios estão disponíveis:
Expand
Tabela 5.2. spacewalk-report Reports
Relatórios
Invocado como
Descrição
Inventário do Sistema
inventário
Lista dos sistemas registrados no servidor, junto com informações do hadware e software
Direitos
entitlements
Lista todas as empresas no Satellite com seus sistemas ou direitos de canal
Errata nos canais
errata-channels
Lista da errata nos canais
Todas Erratas
errata-list-all
Conclua a lista de todas as erratas
Erratas para sistemas
errata-systems
Lista erratas aplicáveis e qualquer sistema registrado que tenha sido afetado
Usuários no sistema
usuários
Lista todos os usuários registrados no Satellite
Sistemas administrados
users-systems
Lista todos os sistemas que podem ser administrados pelos usuários individuais
Árvores Kickstart
kickstartable-trees
Lista as árvores aptas a serem iniciadas
Histórico do Sistema
system-history
Lista o histórico do evento do sistema
Canais do histórico do sistema
system-history-channels
Lista o histórico do evento do sistema
Configuração do histórico do sistema
system-history-configuration
Histórico do evento da configuração do sistema
Direitos do histórico do sistema
system-history-entitlements
Histórico do evento do direito do sistema
Errata do histórico do sistema
system-history-errata
Lista o histórico do evento da errata do sistema
Inicialização do histórico do sistema
system-history-kickstart
Lista a inicialização do sistema e histórico do evento de provisionamento
Pacotes do histórico do sistema
system-history-packages
Lista o histórico do evento do pacote do sistema
Para mais informações sobre um relatório individual, execute o spacewalk-report com --info ou --list-fields-info e os nomes de relatórios. A descrição e lista de campos possíveis no relatório será demonstrada.
Para informações futuras, o manpage do spacewalk-report(8) assim como o parâmetro do --help do programa spacewalk-report pode ser usado para obter informações adicionais sobre as invocações do programa e suas opções.
P:
Como descubro qual versão do esquema de banco de dados tenho?
R:
Para determinar a versão do esquema de seu banco de dados, rode o comando:
rhn-schema-version
# rhn-schema-version
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Como descubro quais tipos de conjuntos de caracteres eu tenho?
R:
Para obter os tipos de conjunto de caracteres do banco de dados de seu Satellite, rode o comando:
rhn-charsets
# rhn-charsets
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Porque o administrador não está recebendo um email?
R:
Se o administrador não estiver recebendo e-mails do Red Hat Satellite, confirme se os endereços de email corretos foram configurados para a opção traceback_mail em /etc/rhn/rhn.conf.
P:
Como eu mudo o enviador do mail traceback?
R:
Se a correspondência traceback está marcada de dev-null@rhn.redhat.com e você deseja que o endereço seja válido para sua empresa, inclua a opção web.default_mail_from e o valor apropriado em /etc/rhn/rhn.conf.
Copiar o linkLink copiado para a área de transferência!
P:
Estou recebendo um erro "Error validating satellite certificate" durante a instalação do Red Hat Satellite. Como eu conserto isso?
R:
Um erro "Error validating satellite certificate" durante a instalação do Red Hat Satellite é causado por ter um HTTP proxy no ambiente. Isto pode ser confirmado olhando o arquivo install.log, e localizando o seguinte erro:
ERROR: unhandled exception occurred:
Traceback (most recent call last):
File "/usr/bin/rhn-satellite-activate", line 45, in ?
sys.exit(abs(mod.main() or 0))
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 585, in main
activateSatellite_remote(options)
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 291, in activateSatellite_remote
ret = s.satellite.deactivate_satellite(systemid, rhn_cert)
File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 603, in __call__
return self._send(self._name, args)
File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 326, in _request
self._handler, request, verbose=self._verbose)
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 171, in request
headers, fd = req.send_http(host, handler)
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 698, in send_http
self._connection.connect()
File "/usr/lib/python2.4/site-packages/rhn/connections.py", line 193, in connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
socket.timeout: timed out
ERROR: unhandled exception occurred:
Traceback (most recent call last):
File "/usr/bin/rhn-satellite-activate", line 45, in ?
sys.exit(abs(mod.main() or 0))
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 585, in main
activateSatellite_remote(options)
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 291, in activateSatellite_remote
ret = s.satellite.deactivate_satellite(systemid, rhn_cert)
File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 603, in __call__
return self._send(self._name, args)
File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 326, in _request
self._handler, request, verbose=self._verbose)
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 171, in request
headers, fd = req.send_http(host, handler)
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 698, in send_http
self._connection.connect()
File "/usr/lib/python2.4/site-packages/rhn/connections.py", line 193, in connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
socket.timeout: timed out
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para resolver o problema:
Execute o script de instalação no modo desconectado, e pule a instalação do banco de dados a qual já foi feita:
./install.pl --disconnected --skip-db-install
# ./install.pl --disconnected --skip-db-install
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Abra /etc/rhn/rhn.conf com seu editor de textos preferido, e adicione ou modifique a seguinte linha:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Remova a seguinte linha:
disconnected=1
disconnected=1
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se você estiver usando uma proxy para a conexão ao Red Hat Network, você também precisará adicionar ou modificar as seguintes linhas para refletir as configurações de proxy.
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Reative o Satellite no modo conectado, usando o comando rhn-satellite-activate como usuário root, incluindo o caminho e o nome de arquivo do certificado satellite:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Alternativamente, tente executar o script install.pl no modo conectado, mas com a opção--answer-file=answer file. Certifique-se que o arquivo answer tem as informação HTTP proxy especificadas como a seguir:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Estou tendo um erro "ERROR: server.mount_point not set in the configuration file" quando eu tento ativar ou sincronizar o Red Hat Satellite. Como conserto isso?
R:
Um erro "ERROR: server.mount_point not set in the configuration file" durante a ativação ou sincronização do Red Hat Satellite pode ocorrer se o parâmetro de configuração mount_point no /etc/rhn/rhn.conf não aponta a um caminho de diretório, ou o caminho do diretório apontados não está presente ou não possui permissão de acesso ao diretório.
Para resolver o problema, cheque o valor do parâmetro de configuração mount_point no /etc/rhn/rhn.conf. Se ele estiver configurado para o valor padrão do /var/satellite, verifique que os diretórios /var/satellite e /var/satellite/redhat existem. Para todos os valores, cheque que o caminho do arquivo está certo, e que as permissões estão configuradas corretamente.
P:
Porque o cobbler check dá um erro dizendo que precisa de uma versão diferente do cobbler check
R:
Às vezes, executando o comando cobbler check pode dar um erro similar ao seguinte:
cobbler check
The following potential problems were detected:
#0: yum-utils need to be at least version 1.1.17 for reposync -l, current version is 1.1.16
# cobbler check
The following potential problems were detected:
#0: yum-utils need to be at least version 1.1.17 for reposync -l, current version is 1.1.16
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Este é um problema conhecido no pacote reposync do Cobbler. O erro é falso e pode ser ignorado seguramente. Este erro será resolvido nas futuras versões do Red Hat Satellite.
P:
Estou recebendo um erro "unsupported version" quando eu tento ativar o certificado Red Hat Satellite. Como conserto isso?
R:
Se seu certificado Red Hat Satellite se tornou corrompido, você poderia receber um dos seguintes erros:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Invalid satellite certificate
Invalid satellite certificate
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para resolver esse problema, contate os serviços de suporte da Red Hat para um novo certificado.
P:
Estou recebendo "Internal Server Error" sobre o ASCII quando eu tento editar o perfil de kickstart. O que está acontecendo?
R:
Se você recentemente adicionou alguns parâmetros kernel ao seu perfil de kickstart, pode acontecer que quando tentar View a List of Kickstart Profiles você receba o seguinte Internal Server Error:
'ascii' codec can't encode character u'\u2013'
'ascii' codec can't encode character u'\u2013'
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Este erro ocorre porque algum texto dentro do perfil não está sendo reconhecido corretamente.
Para resolver o problema:
SSH diretamente no Servidor Satellite como usuário root:
ssh root@satellite.fqdn.com
# ssh root@satellite.fqdn.com
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Encontre o perfil de kickstart que está causando o problema olhando nas datas dos aquivos no /var/lib/cobbler/config/profiles.d e localizando o arquivo que foi editado mais recentemente:
ls -l /var/lib/cobbler/config/profiles.d/
# ls -l /var/lib/cobbler/config/profiles.d/
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Abra o perfil no seu editor de texto preferido, e localize o seguinte texto:
\u2013hostname
\u2013hostname
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Mude para:
--hostname
--hostname
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Salve as mudanças ao perfil e feche o arquivo.
Reinicie os serviços Red Hat Satellite para captar o perfil atualizado.
rhn-satellite restart
Shutting down rhn-satellite...
Stopping RHN Taskomatic...
Stopped RHN Taskomatic.
Stopping cobbler daemon: [ OK ]
Stopping rhn-search...
Stopped rhn-search.
Stopping MonitoringScout ... [ OK ]
Stopping Monitoring ... [ OK ]
Stopping httpd: [ OK ]
Stopping tomcat5: [ OK ]
Shutting down osa-dispatcher: [ OK ]
Shutting down Oracle Net Listener ... [ OK ]
Shutting down Oracle DB instance "rhnsat" ... [ OK ]
Shutting down Jabber router: [ OK ]
Done.
Starting rhn-satellite...
Starting Jabber services [ OK ]
Starting Oracle Net Listener ... [ OK ]
Starting Oracle DB instance "rhnsat" ... [ OK ]
Starting osa-dispatcher: [ OK ]
Starting tomcat5: [ OK ]
Starting httpd: [ OK ]
Starting Monitoring ... [ OK ]
Starting MonitoringScout ... [ OK ]
Starting rhn-search...
Starting cobbler daemon: [ OK ]
Starting RHN Taskomatic...
Done.
# rhn-satellite restart
Shutting down rhn-satellite...
Stopping RHN Taskomatic...
Stopped RHN Taskomatic.
Stopping cobbler daemon: [ OK ]
Stopping rhn-search...
Stopped rhn-search.
Stopping MonitoringScout ... [ OK ]
Stopping Monitoring ... [ OK ]
Stopping httpd: [ OK ]
Stopping tomcat5: [ OK ]
Shutting down osa-dispatcher: [ OK ]
Shutting down Oracle Net Listener ... [ OK ]
Shutting down Oracle DB instance "rhnsat" ... [ OK ]
Shutting down Jabber router: [ OK ]
Done.
Starting rhn-satellite...
Starting Jabber services [ OK ]
Starting Oracle Net Listener ... [ OK ]
Starting Oracle DB instance "rhnsat" ... [ OK ]
Starting osa-dispatcher: [ OK ]
Starting tomcat5: [ OK ]
Starting httpd: [ OK ]
Starting Monitoring ... [ OK ]
Starting MonitoringScout ... [ OK ]
Starting rhn-search...
Starting cobbler daemon: [ OK ]
Starting RHN Taskomatic...
Done.
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Retorne à interface web. Note que interface pode levar algum tempo para resolver os serviços. Deve retornar ao normal depois de algum tempo.
P:
Estou recebendo erros "Host Not Found" ou "Could Not Determine FQDN". O que eu faço agora?
R:
Como os arquivos de configuração do Red Hat Network se apoiam exclusivamente nos nomes de domínio totalmente qualificados (fully qualified domain names, FQDN), é imperativo que os aplicativos chave sejam capazes de resolver o nome do Red Hat Satellite num endereço IP. O Red Hat Update Agent (Agente de Atualização da Red Hat), o Red Hat Network Registration Client (Cliente de Registro do Red Hat Network) e servidor do Apache Web tendem a apresentar este tipo problema quando as aplicativos do Red Hat Network trazem erros "host not found" ( máquina não encontrada) e quando o servidor Web traz "Could not determine the server's fully qualified domain name" (Não foi possível determinar o nome do domínio totalmente qualificado do servidor) na ocasião de falha ao iniciar.
Este problema origina-se tipicamente do arquivo /etc/hosts. Você pode confirmar isto examinando o /etc/nsswitch.conf, que define os métodos e a ordem na qual os nomes de domínio são resolvidos. Geralmente, o arquivo /etc/hosts é verificado primeiro, em seguida, o Network Information Service (NIS) se usado, e depois o DNS. Um destes precisa ser bem sucedido para o servidor do Apache Web iniciar e para os aplicativos cliente do Red Hat Network funcionarem.
Para resolver este problema, indentifique o conteúdo do arquivo /etc/hosts. Deve se parecer com:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Primeiro, remova as informações da máquina violadora num editor de texto, como:
127.0.0.1 localhost.localdomain.com localhost
127.0.0.1 localhost.localdomain.com localhost
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Em seguida, salve o arquivo e tente rodar novamente os aplicativos cliente do Red Hat Network ou o Apache Web. Se ainda falharem, identifique explicitamente o endereço IP do Satellite no arquivo, como:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Substitua este valor pelo endereço IP real do Satellite. Isto deve resolver o problema. Tenha em mente que, se o endereço IP específico é estipulado, o arquivo precisará ser atualizado quando a máquina obtiver um novo endereço.
P:
Estou recebendo "This server is not an entitled Satellite" quando eu tento sincronizar o servidor Red Hat Satellite. Como eu conserto isso?
R:
Se o satellite-sync reporta que o servidor não está ativado como um Red Hat Satellite, ele não está registrado ao respectivo canal Red Hat Satellite. Se for um sistema recém instalado, certifique-se de que o certificado satellite está ativado ao sistema. Se ele foi ativado antes, então ele foi desativado.
Verifique os canais filho do sistema para descobrir se eles estão subscritos a qualquer canal do Red Hat Satellite. Visualize os canais subscritos com o seguinte comando:
yum repolist
# yum repolist
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Ative o mesmo certificado Satellite novamente no seu Satellite, usando este comando como usuário root:
Copiar o linkLink copiado para a área de transferência!
P:
Estou tendo problemas com a interface de usuário do Red Hat Satellite. Quais arquivos de log eu devo checar?
R:
Se você tem erros vizualizando, agendando, ou trabalhando com kickstarts na interface de usuário do Red Hat Satellite Server, cheque o arquivo de log /var/log/tomcat6/catalina.out.
Para todos os outros erros da interface de usuário, cheque o arquivo de log /var/log/httpd/error_log.
Copiar o linkLink copiado para a área de transferência!
P:
Estou tendo um erro que diz Error downloading kickstart file (Erro ao baixar o arquivo de kickstart). Qual é o problema e como conserto isso?
R:
Este erro é geralmente o resultado de um problema de rede. Para localizar o problema, rode o comando cobbler check, e leia o resultado, que deve mostrar algo como:
cobbler check
The following potential problems were detected:
#0: reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?
#1: yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils?
#2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
# cobbler check
The following potential problems were detected:
#0: reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?
#1: yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils?
#2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se o cobbler check não fornecer uma resposta, cheque o seguinte:
Verifique se httpdestá sendo executado: service httpd status
Verifique se o cobblerd está sendo executado: service cobblerd status
Verifique se você pode pegar o arquivo de kickstart usando wget de um host diferente:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Estou tendo um erro num pacote de instalação que diz The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened.. Qual é o problema e como eu conserto isso?
R:
Máquinas clientes pegarão conteúdo do Red Hat Satellite baseados no parâmetro --url no kickstart. Por exemplo:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se você receber erros do Anaconda dizendo que não pode encontrar imagens ou pacotes, cheque de que a URL no kickstart gere uma reposta 200 OK. Você pode fazer isso tentando wget no arquivo localizado na URL:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se você obter uma outra resposta além de 200 OK, cheque os logs de erro para encontrar qual é o problema. Você pode também checar o arquivo Anaconda real que se foi tentado baixar procurando o arquivo access_log:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se as requisições não estão aparecendo no arquivo access_log, o sistema pode estar tendo problemas com a configuração de rede. Se as requisições estão aparecendo mas estão gerando erros, cheque os logs de erro.
Você pode também tentar manualmente baixar os arquivos para ver se o pacote está disponível:
Copiar o linkLink copiado para a área de transferência!
P:
Estou recebendo emails com "WEB TRACEBACK" no campo assunto. O que eu devo fazer sobre isso?
R:
Um email de traceback típico é parecido com o seguinte:
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From:Red Hat Satellite <dev-null@redhat.com>
To: admin@example.com
java.lang.RuntimeException: XmlRpcException calling cobbler.
at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.java:54)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed.
at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434)
at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
... 4 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://someserver.example.com:80/cobbler_api
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1236)
at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
... 7 more
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From:Red Hat Satellite <dev-null@redhat.com>
To: admin@example.com
java.lang.RuntimeException: XmlRpcException calling cobbler.
at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.java:54)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed.
at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434)
at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
... 4 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://someserver.example.com:80/cobbler_api
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1236)
at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
... 7 more
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Isso indica que houve um problema do Cobbler comunicando com o serviço taskomatic. Tente checar o seguinte:
Verifique se httpd está sendo executado: # service httpd status
Verifique se cobbler está sendo executado: # service cobbler status
Verifique que não há regras de firewall que preveniriam conexões localhost
Copiar o linkLink copiado para a área de transferência!
P:
O comando rhnreg_ks está falhando quando eu o uso, dizendo ERROR: unable to read system id (incapaz de ler o id do sistema). Qual é o problema?
R:
No final do arquivo de kickstart, há uma seção %post que registra a máquina ao Red Hat Satellite:
begin Red Hat management server registration
mkdir -p /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/*
rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-c8d01e2f23c6bbaedd0f6507e9ac079d
end Red Hat management server registration
# begin Red Hat management server registration
mkdir -p /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/*
rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-c8d01e2f23c6bbaedd0f6507e9ac079d
# end Red Hat management server registration
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Interpretar isto na ordem que foi adicionado, ele irá:
Criar um diretório para acomodar o cert SSL padronizado utilizado pelo Red Hat Satelite.
Pegue o certificado SSL para usar durante o registro.
Busque e substitua as sequências de certificado SSL do arquivo de configuração rhn-register, e então registrar ao Red Hat Satellite, usando o certificado SSL e a chave de ativação. Todo perfil de kickstart inclui uma chave de ativação que certifica que o sistema está atribuído com os canais base e filhos corretos, e receba os direitos de uso do sistema corretos. Se for um reprovisionamento de um sistema existente, a chave de ativação certificará também que está associada com o perfil de sistema anterior.
Se o comando rhnreg_ks falhar você poderá ver erros como este no arquivo de log ks-post.log:
ERROR: unable to read system id.
ERROR: unable to read system id.
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Estes erros também ocorrerão se você tentar realizar um rhn_check e o sistema não tiver sido registrado para o Red Hat Satellite.
A melhor maneira para resolver estes problemas é vizualizar o arquivo de kickstart e copiar e colar os quatro passos diretamente na linha de comando depois que o kickstart estiver completo. Isto produzirá mensagens de erro que são mais detalhadas para lhe ajudar a localizar o problema.
Copiar o linkLink copiado para a área de transferência!
P:
Qual é a estrutura de diretório para os kickstarts?
R:
O caminho base onde os arquivos de kickstart são armazenados é /var/lib/rhn/kickstarts/. Dentro deste diretório, os kickstarts brutos estão no subdiretório upload, e os kickstarts gerados pelo assistente estão no subdiretório wizard:
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg
Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg
Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
Copy to ClipboardCopied!Toggle word wrapToggle overflow
P:
Qual é a estrutura de diretório para snippets do Cobbler?
R:
Snippets do Cobbler estão armazenados no /var/lib/rhn/kickstarts/snippets. O Cobbler acessa os snippets usando o link simbólico /var/lib/cobbler/snippets/spacewalk.
Copiar o linkLink copiado para a área de transferência!
P:
Existe qualquer ferramenta de diagnóstico que ajudem a determinar a causa de erros do monitoring?
R:
Apesar de todas as atividades relacionadas ao Monitoring serem conduzidas através da interface do Satellite, a Red Hat oferece algumas ferramentas de diagnóstico na linha de comandos que podem ajudá-lo a determinar a causa de erros e problemas. Para usar estas ferramentas, você deve tornar-se o usuário nocpulse no Satellite conduzindo a monitoramento.
Primeiro, autentique-se no Satellite como root. Então, alterne para o usuário nocpulse com o seguinte comando:
su - nocpulse
su - nocpulse
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para resolver completamente os problemas de uma detecção, primeiramente você deve obter seu ID. Você pode obter esta informação rodando rhn-catalog no Servidor Red Hat Satellite como o usuário nocpulse. O output será similar a:
2 ServiceProbe on example1.redhat.com (199.168.36.245): test 2
3 ServiceProbe on example2.redhat.com (199.168.36.173): rhel2.1 test
4 ServiceProbe on example3.redhat.com (199.168.36.174): SSH
5 ServiceProbe on example4.redhat.com (199.168.36.175): HTTP
2 ServiceProbe on example1.redhat.com (199.168.36.245): test 2
3 ServiceProbe on example2.redhat.com (199.168.36.173): rhel2.1 test
4 ServiceProbe on example3.redhat.com (199.168.36.174): SSH
5 ServiceProbe on example4.redhat.com (199.168.36.175): HTTP
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O ID da detecção é o primeiro número, enquanto o nome da detecção (conforme indicado na interface do Satellite) é a última informação da linha. No exemplo acima, o ID de detecção 5 corresponde à detecção chamada HTTP.
Futuramente, você pode passar as opções --commandline (-c) e --dump (-d) junto a um ID de detecção para que rhn-catalog obtenha mais detalhes sobre a detecção, como neste exemplo:
rhn-catalog --commandline --dump 5
rhn-catalog --commandline --dump 5
Copy to ClipboardCopied!Toggle word wrapToggle overflow
A opção --commandline submete os parâmetros de comando definidos para a detecção, enquanto --dump recupera todo o resto, incluindo limites de alerta e intervalos e métodos de notificação.
O comando acima resultará num output similar a:
5 ServiceProbe on example4.redhat.com (199.168.36.175 ):
linux:cpu usage
Run as: Unix::CPU.pm --critical=90 --sshhost=199.168.36.175
--warn=70 --timeout=15 --sshuser=nocpulse
--shell=SSHRemoteCommandShell --sshport=4545
5 ServiceProbe on example4.redhat.com (199.168.36.175 ):
linux:cpu usage
Run as: Unix::CPU.pm --critical=90 --sshhost=199.168.36.175
--warn=70 --timeout=15 --sshuser=nocpulse
--shell=SSHRemoteCommandShell --sshport=4545
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Agora que você tem o ID, pode usá-lo com rhn-rhnprobe para examinar o output da probe.
P:
Como eu interpreto o output de rhn-runprobe?
R:
Agora que você obteve o ID da detecção com rhn-catalog, use-o em conjunto com o rhn-runprobe para examinar o output completo da detecção. Note que o rhn-runprobe funciona no modo teste por default ou seja, nenhum resultado é inserido no banco de dados. Aqui estão suas opções:
Expand
Tabela 5.3. Opções do rhn-runprobe
Opção
Descrição
--help
Lista as opções disponíveis e fecha.
--probe=PROBE_ID
Executa a detecção com este ID.
--prob_arg=PARAMETER
Sobrescreve todos os parâmetros de detecção do banco de dados.
--module=PERL_MODULE
Nome do pacote com o código alternativo a executar.
--log=all=LEVEL
Determina o nível de registro de um pacote ou prefixo de pacotes.
--debug=LEVEL
Determina o nível de depuração numérico.
--live
Executa a detecção, além de enfileirar dados e enviar notificações (se necessário).
Você deve incluir, no mínimo, as opções e os valores de --probe e de --log. A opção --probe toma o ID da detecção como seu valor e a opção --log toma o valor "all" (para todos os níveis de execução) e um nível de verbosidade numérico como seus valores. Aqui está um exemplo:
rhn-runprobe --probe=5 --log=all=4
rhn-runprobe --probe=5 --log=all=4
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O comando acima requer o output da detecção do probeID 5, para todos os níveis de execução, com alto nível de verbosidade.
Mais especificamente, você pode prover os parâmetros do comando, derivados do rhn-catalog. Exemplo:
Copiar o linkLink copiado para a área de transferência!
P:
Como eu registro meus sistemas em um ambiente de Organizações Múltiplas quando eu não tenho direitos a serviços suficientes no meu Certificado Satellite?
R:
Existem algumas situações nas quais você precisa liberar os direitos e você não tem muito tempo para fazer isto e pode não ter acesso à cada organização para que você mesmo faça isso. Existe uma opção no Multi-Org Satellites que permite que o administrador do Satellite reduza a conta de um direito da organização abaixo de seu uso. Este método deve ser realizado depois que se registrar na organização do administrativo.
Por exemplo, registrado na organização administrativa, se seu certificado não está seguro com os 5 direitos de gerenciamento de sistema e acredita não conseguir cobrir todos os sistemas registrados em seu Satellite, os 5 sistemas quase recentemente registrados à esta organização terão seus direitos desativados. Este processo está descrito abaixo:
No arquivo /etc/rhn/rhn.conf defina web.force_unentitlement para 1.
Reinicie o Satellite
Reduzir os direitos alocados à organizações desejadas pela aba de Subscrição de cada organização ou por abas de Organizações de direitos individuais.
Diversos sistemas na organização devem estar agora em um estado sem direitos. O número de sistemas em estado sem direitos na organização será igual à diferença entre o número total de direitos que você removeu da organização do número de serviços que a organização não aplicou aos sistemas.
Por exemplo, se você removeu 10 direitos da organização no passo 3 e a organização possui 4 direitos que não foram usados pelo sistema, os 6 sistemas na organização entrarão no estado sem direitos.
Depois que você tiver o número suficiente de direitos requeridos, você deve conseguir ativar seu certificado novo do Satellite. Observe que modificar a variante web.force_unentitlement é necessário somente para reduzir os direitos alocados da organização abaixo do que eles estiverem utilizando. Se uma organização possuir mais direitos do que estejam usando ativamente, você não precisará estabelecer esta variante para removê-los.
P:
Eu tenho direitos à serviços extras em meu Certificado Satellite que não estão sendo utilizados. O que acontece com estes direitos?
R:
Se você receber um certificado novo do Satellite e possuir mais direitos do que eles estejam consumindo em seu Satellite, qualquer direito extra deverá ser atribuído à organização do administrativo. Se você se registrar na interface da web como um administrador do Satellite, você conseguirá alocar estes direitos à outras organizaçãoes. Os direitos alocados previamente à outras organizações não serão afetados.
Copiar o linkLink copiado para a área de transferência!
P:
Após configurar o Red Hat Network Package Manager como posso determinar se os pacotes locais foram adicionados com sucesso ao canal Red Hat Network ?
R:
Use o comando rhn_package_manager -l -c "nome_do_canal_privado" para listar os pacotes do canal privado, conhecidos pelos Servidores Satellite. Ou então visite o site da interface do Satellite.
Após incluir um sistema registrado num canal privado, você também pode executar o comando yum --disablerepo="8" --enablerepo="your_repo_name" list available no sistema registrado e procurar os pacotes do canal privado da RHN.
P:
Como posso saber se os clientes estão conectando ao servidor Squid?
R:
O arquivo /var/log/squid/access.log registra todas as conexões ao servidor Squid.
P:
O Red Hat Update Agent nos sistemas clientes não está conectando através do Red Hat Satellite Proxy . Como posso resolver este erro?
R:
Certifique-se de ter a última versão do Red Hat Update Agent instalada nos sistemas cliente. A versão mais recente contém as funcionalidades necessárias para conectar através de um Red Hat Satellite Proxy Server e pode ser obtida através da Red Hat Network emitindo o comando yum update yum como root ou a partir do http://www.redhat.com/support/errata/.
O Red Hat Satellite Proxy é uma extensão do Apache. Veja a seção Log Files do Red Hat Satellite Proxy Installation Guide para obter o local do seu arquivo log.
P:
A configuração do meu Red Hat Network Satellite Proxy não funciona. Por onde devo começar a resolver esta questão?
R:
Assegure-se que o arquivo /etc/sysconfig/rhn/systemid seja de propriedade (owner) do usuário root.apache com permissões 0640.
Leia os arquivos log. Uma lista está disponível na seção Log Files do Red Hat Satellite Proxy Installation Guide.
P:
Como eu resolvo problemas gerais no Red Hat Satellite Proxy?
R:
Para começar a resolver problemas genéricos, examine o(s) arquivo(s) de registro (log files) relacionado(s) ao componente apresentando falhas.
Um problema comum é o disco cheio (full disk space). Um sinal quase certeiro deste problema é a apresentação da gravação interrompida (halted writing) nos arquivos de registro. Se o registro parou durante uma gravação, como por exemplo no meio de uma palavra, você provavelmente está com os discos cheios. Para confirmar isto, rode este comando e verifique as porcentagens na coluna Use% (uso):
df -h
df -h
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além dos arquivos de registro, você também pode obter informações valiosas através do estado dos vários componentes. Isto pode ser feito para o Apache Web server e para o Squid.
Para obter o estado do Apache Web server, rode o comando:
service httpd status
service httpd status
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Para obter o estado do Squid, rode o comando:
service squid status
service squid status
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Se o administrador não estiver recebendo e-mails do Red Hat Satellite Proxy, confirme se os endereços de email corretos foram configurados para a opção traceback_mail em /etc/rhn/rhn.conf.
P:
A configuração do meu Red Hat Network Satellite Proxy encontrou um erro "Host não foi Encontrado "/" Não foi possível Determinar o FQDN". O que devo fazer?
R:
Como os arquivos de configuração do Red Hat Network se apoiam exclusivamente nos nomes de domínio totalmente qualificados (fully qualified domain names, FQDN), é imperativo que os aplicativos chave sejam capazes de resolver o nome do Red Hat Satellite Proxy num endereço IP. O Red Hat Update Agent (Agente de Atualização da Red Hat), o Red Hat Network Registration Client (Cliente de Registro do Red Hat Network) e servidor do Apache Web tendem a apresentar este tipo problema quando as aplicativos do Red Hat Network trazem erros "host not found" ( máquina não encontrada) e quando o servidor Web traz "Could not determine the server's fully qualified domain name" (Não foi possível determinar o nome do domínio totalmente qualificado do servidor) na ocasião de falha ao iniciar.
Este problema origina-se do arquivo /etc/hosts. Confirme isto examinando o /etc/nsswitch.conf, que define os métodos e a ordem na qual os nomes de domínio são resolvidos. Geralmente, o arquivo /etc/hosts é verificado primeiro, em seguida, o Network Information Service (NIS) se usado, e depois o DNS. Um destes precisa ser bem sucedido para o servidor do Apache Web iniciar e para os aplicativos cliente do Red Hat Network funcionarem.
Para resolver este problema, indentifique o conteúdo do arquivo /etc/hosts. Deve se parecer com:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Em um editor de texto, remova as informações da máquina host do arquivo, ele deve se parecer com este:
127.0.0.1 localhost.localdomain.com localhost
127.0.0.1 localhost.localdomain.com localhost
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Em seguida, salve o arquivo e tente rodar novamente os aplicativos cliente do Red Hat Network ou o Apache Web. Se ainda falharem, identifique explicitamente o endereço IP do Proxy no arquivo, como:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Substitua este valor pelo endereço IP real do Proxy. Isto deve resolver o problema. Tenha em mente que se o endereço IP específico for estipulado, o arquivo deverá ser atualizado quando a máquina obtiver um novo endereço.
P:
Estou tendo problemas com o Red Hat Satellite Proxy e erros de conexão de rede. O que devo fazer?
R:
Se você acredita que há problemas relacionados a conexões falhas, siga estas instruções:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
está instalado no Red Hat Satellite Proxy e se o rhn-org-trusted-ssl-cert-*.noarch.rpm ou o certificado (cliente) CA SSL público bruto está instalado em todos os sistemas cliente.
Verifique se os sistemas clientes estão configurados para usar o certificado apropriado.
Se usar um ou mais Servidores Satellite Proxies da Red Hat, garanta que o certificado SSL de cada Proxy seja preparado corretamente. Se usar um Red Hat Satellite Proxy em conjunto com um Red Hat Satellite, o Proxy deve ter ambos instalados - o par de chaves SSL do servidor e o certificado (cliente) público SSL da CA, já que servirá ambas funcionalidades. Consulte o capítulo Certificados SSL do Guia de Configuração do Cliente Red Hat Satellite para instruções específicas.
Se o Red Hat Satellite Proxy se conecta através de um Proxy HTTP, garanta que a URL listada seja válida. Por exemplo: o campo HTTP Proxy URL não deve conter referências a protocolos, como http:// ou https://. Somente o nome da máquina e porta devem ser inclusas, no formato nomedamáquina:porta, como por exemplo portadecomunicação_corporativa.exemplo.com:8080.
Assegure-se de que os sistemas de cliente não estão utilizando firewalls próprios, bloquendo as portas requeridas como identificado na seção Additional Requirements do Red Hat Satellite Proxy Installation Guide.
P:
Estou tendo problemas com os erros de entrega do pacote e danos de objeto. O que devo procurar?
R:
Se a entrega de um pacote falhar ou se um objeto parece estar corrompido, e não há relação com erros de conexão, você deve considerar limpar os caches. O Red Hat Satellite Proxy tem dois caches que você deve observar: um para o Squid e outro para autenticação.
O cache do Squid está localizado no /var/spool/squid/. Para limpá-lo:
Interrompa o Servidor da Web Apache: service httpd stop
Interrompa o Squid server: service squid stop
Remova o conteúdo do diretório: rm -fv /var/cache/rhn/*
Reinicie ambos serviços:
service squid start
service httpd start
service squid start
service httpd start
Copy to ClipboardCopied!Toggle word wrapToggle overflow
A mesma tarefa pode ser concluída mais rapidamente limpando o diretório e reiniciando o squid, mas este método pode muito provavelmente resultar em diversas mensagens do Red Hat Network traceback.
O mecanismo de caching interno usado para a autenticação pelo Proxy também pode precisar de uma limpeza em seu cache. Para tanto, invoque o seguinte comando:
rm -fv /var/cache/rhn/*
rm -fv /var/cache/rhn/*
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Nota
Se você ainda não esgotou todas estas possibilidades da resolução de problemas ou deseja deferí-las aos profissionais do Red Hat Network, a Red Hat recomenda que você usufrua do suporte que acompanha o Red Hat Satellite. A maneira mais eficiente de fazê-lo é agregar os parâmetros de configuração, arquivos de registro e as informações do banco de dados de seu Satellite e enviar este pacote diretamente à Red Hat.
O Red Hat Network oferece uma ferramenta de linha de comando especificamente para este propósito: o Satellite Diagnostic Info Gatherer (Coletador de Informações de Diagnóstico do Satellite), comumente conhecido pelo seu comando satellite-debug. Para usar esta ferramenta, invoque o comando como root. Você verá partes das informações coletadas e também um único arquivo tarball criado, como:
satellite-debug
Collecting and packaging relevant diagnostic information.
Warning: this may take some time...
* copying configuration information
* copying logs
* querying RPM database (versioning of Red Hat Satellite, etc.)
* querying schema version and database character sets
* get diskspace available
* timestamping
* creating tarball (may take some time): /tmp/satellite-debug.tar.bz2
* removing temporary debug tree
Debug dump created, stored in /tmp/satellite-debug.tar.bz2
Deliver the generated tarball to your Red Hat Network contact or support channel.
# satellite-debug
Collecting and packaging relevant diagnostic information.
Warning: this may take some time...
* copying configuration information
* copying logs
* querying RPM database (versioning of Red Hat Satellite, etc.)
* querying schema version and database character sets
* get diskspace available
* timestamping
* creating tarball (may take some time): /tmp/satellite-debug.tar.bz2
* removing temporary debug tree
Debug dump created, stored in /tmp/satellite-debug.tar.bz2
Deliver the generated tarball to your Red Hat Network contact or support channel.
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Ao terminar, envie um e-mail com o novo arquivo do diretório /tmp/ a seu representante da Red Hat para um diagnóstico imediato.
Adicionalmente, a Red Hat fornece um comando de linha chamado SoS Report, comumente conhecido pelo seu comando sosreport. Esta ferramenta coleta os parâmetros de configuração de sua Proxy, arquivos de log e informação de banco de dados e os envia diretamente à Red Hat.
Para usar esta ferramenta para informação do Red Hat Satellite, você deve ter o pacote sos instalado. Digite sosreport -o rhn como root no servidor Satellite para criar um relatório. Por exemplo:
sosreport -o rhn
sosreport (version 1.7)
This utility will collect some detailed information about the
hardware and setup of your Red Hat Enterprise Linux system.
The information is collected and an archive is packaged under
/tmp, which you can send to a support representative.
Red Hat will use this information for diagnostic purposes ONLY
and it will be considered confidential information.
This process may take a while to complete.
No changes will be made to your system.
Press ENTER to continue, or CTRL-C to quit.
[root@satserver ~]# sosreport -o rhn
sosreport (version 1.7)
This utility will collect some detailed information about the
hardware and setup of your Red Hat Enterprise Linux system.
The information is collected and an archive is packaged under
/tmp, which you can send to a support representative.
Red Hat will use this information for diagnostic purposes ONLY
and it will be considered confidential information.
This process may take a while to complete.
No changes will be made to your system.
Press ENTER to continue, or CTRL-C to quit.
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Você é então requisitado pelo primeiro e último nome e então um número do tíquete de suporte (também conhecido como número Issue Tracker).
Isso pode levar alguns minutos para o sistema gerar e arquivar o relatório em um arquivo comprimido. Ao terminar, envie um e-mail com o arquivo do diretório /tmp/ para seu representante Red Hat para o diagnóstico imediato.
Copiar o linkLink copiado para a área de transferência!
Os sistemas de monitoramento com o direito à Monitoramento podem ter probes (detecções) aplicadas a eles para constantemente confirmar sua saúde e operabilidade total. Esta seção lista as probes disponíveis divididas por grupo de comando, como o Apache.
Muitas probes que monitoram aspectos internos de seus sistemas (como o Linux::Disk Usage) ao invés de aspectos externos (como o probe do Network Services::SSH), requerem a instalação do daemon de monitoramento do Red Hat Network (rhnmd). Este requisito é notado dentro da referência individual da probe.
Cada probe tem sua própria referência nesta seção que identifica os campos necessários (marcados com um *), valores padrões e os limites que podem ser definidos para ativar os alertas. Da mesma forma, o início da seção de cada grupo de comando contém informações aplicáveis a todas as probes deste grupo. A Seção A.1, “Diretrizes das Probes” cobre as regras gerais; as seções restantes examinam as probes separadamente.
Nota
Quase todas as probes usam o Protocolo de Controle de Transmissão (TCP) como seu protocolo de transporte. As exceções são notadas nas referências da própria probe.
Copiar o linkLink copiado para a área de transferência!
As diretrizes gerais a seguir detalham o significado de cada estado da probe e oferecem instruções para configurar os limites de suas probes.
A lista seguinte oferece uma breve descrição do significado de cada estado de probe:
Desconhecido
As probes que não são capazes de coletar os resultados necessários para determinar o estado da probe. A maioria (mas não todas) das probes chega neste estado quando ultrapassa seu período timeout (tempo limite). As probes neste estado também podem ter sido configuradas incorretamente.
Pendente (Pending)
As probes cujos dados não foram recebidos pelo Red Hat Network Satellite . É normal novas probes recaírem neste estado. No entanto, se isso ocorrer com todas as probes, a infra-estrutura de monitoramento pode estar falhando.
OK
As probes efetuadas com sucesso, sem nenhum erro. Este é o estado desejado para todas as probes.
Aviso
As probes que ultrapassaram seus limites WARNING (aviso).
Crítico
As probes que ultrapassaram seus limites críticos (CRITICAL) ou atingiram este estado através de outras maneiras. Algumas probes tornam-se críticas ao ultrapassarem seu tempo limite (timeout period).
Ao adicionar probes, selecione limites significativos que, ao serem ultrapassados, notificam a você e seus administradores sobre problemas na sua infra-estrutura. Os períodos de timeout são inseridos em segundos ou conforme indicado. As exceções destas regras são mencionadas nas referências específicas das probes.
Importante
Algumas probes têm limites baseados em tempo. Para que os limites de CRITICAL e WARNING funcionem conforme pretendidos, seus valores não podem ultrapassar o tempo alocado para o período de expiração. Caso contrário, será retornado um estado desconhecido (UNKNOWN) para todas as instâncias da latência extendida, assim anulando os limites. Por este motivo, a Red Hat recomenda garantir que os períodos de expiração ultrapassem todos os limites de tempo.
Execute suas probes sem notificações por um tempo, a fim de estabelecer o desempenho base de cada um de seus sistemas. Mesmo que os valores padrões providos para as probes atendam às suas necessidades, cada empresa tem um ambiente diferente, que pode precisar de limites diferentes.
Copiar o linkLink copiado para a área de transferência!
As probes desta seção podem ser aplicadas às instâncias do Servidor da Web do Apache. Apesar dos valores padrões presumirem que você aplicará estas probes usando HTTP padrão, você também pode usá-los através de conexões seguras alterando o protocolo da aplicação para https e a porta para 443.
Copiar o linkLink copiado para a área de transferência!
A probe Apache::Processes monitora os processo executados num Servidor da Web Apache e coleta as seguintes medidas:
Data Transferred Per Child (dados transferidos por filho) - Registra as informações de transferência de dados sobre os filhos separadamente. Um processo filho é aquele criado a partir de um processo pai ou outro processo.
Dados Transferidos Por Slot - A quantidade acumulada de dados transferidos por um processo filho que reinicia. O número de slots é configurado no arquivo httpd.conf usando a configuração MaxRequestsPerChild.
A diretiva ExtendedStatus do arquivo httpd.conf do servidor Web deve ser definida como On para esta probe funcionar apropriadamente.
Copiar o linkLink copiado para a área de transferência!
A Apache::Uptime armazena o tempo acumulado desde que o servidor Web foi iniciado pela última vez. Nenhum resultado é coletado por esta probe, que é desenvolvida para ajudar a registrar acordos de nível de serviço (service level agreements, SLAs).
Copiar o linkLink copiado para a área de transferência!
As probes desta seção (com exceção do Conjunto de Conexões JDBC) podem ser configuradas para monitorar as propriedades de qualquer servidor BEA WebLogic 6.x e mais recente (Administration ou Managed) rodando numa máquina, até mesmo num ambiente em cluster. O monitoramento de um cluster é feito ao enviar todos os pedidos SNMP para o Servidor de Administração (Administration Server) do domínio e então solicitando dados individuais aos seus Servidores Gerenciados (Managed Servers).
Para obter este nível mais alto de granularidade, o parâmetro BEA Domain Admin Server deve ser usado para diferenciar entre o Servidor de Administração (Administration Server) recebendo pedidos SNMP e o Servidor Gerenciado (Managed Server) passando pela probe específica. Se a máquina a ser detectada é o Servidor de Administração (Administration Server), então o parâmetro BEA Domain Admin Server pode ser deixado em branco e ambos, os pedidos SNMP e a probe, serão enviados somente a este.
Se a máquina a ser detectada é um Servidor Gerenciado (Managed Server), então o endereço IP do Servidor de Administração (Administration Server) deve ser provido no parâmetro BEA Domain Admin Server e o nome do Servidor Gerenciado (Managed Server) deve ser incluso no parâmetro BEA Server Name e anexo no final do campo SNMP Community String. Isto faz com que os pedidos SNMP sejam enviados à máquina do Servidor de Administração (Administration Server), conforme solicitado, mas redireciona a probe específica à máquina do Servidor Gerenciado (Managed Server).
É importante notar também que o string community, necessário para rodar probes em máquinas de Servidor Gerenciado (Managed Server), deve estar na forma community_prefix@managed_server_name para que o pedido SNMP retorne resultados para o Servidor Gerenciado (Managed Server) desejado. Finalmente, o SNMP deve ser ativado em cada sistema monitorado. O suporte ao SNMP pode ser ativado e configurado através do Console do WebLogic.
Consulte a documentação que acompanha seu servidor BEA ou as informações do site da BEA para obter mais detalhes sobre as convenções de nomenclatura do string community da BEA.
Copiar o linkLink copiado para a área de transferência!
A probe BEA WebLogic::JDBC Connection Pool monitora o conjunto de conexões do Banco de Dados Java (Java Database Connection, JDBC) num Servidor de Administração (Admin Server) de domínio somente (sem Servidores Gerenciados) e coleta os seguintes resultados:
Conexões (Connections) - O número de conexões ao JDBC.
Taxa de Conexões (Connections Rate) - A velocidade na qual as conexões são feitas ao JDBC, medida em conexões por segundo.
Waiters - O número de sessões aguardando para conectar ao JDBC.
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Expand
Tabela A.6. Configuração da BEA WebLogic::JDBC Connection Pool
Copiar o linkLink copiado para a área de transferência!
A probe BEA WebLogic::Server State monitora o estado corrente de um servidor Web Weblogic BEA. Se a probe for incapaz de fazer uma conexão ao servidor, resulta num estado CRITICAL (crítico).
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Expand
Tabela A.7. Configuração da BEA WebLogic::Server State
Copiar o linkLink copiado para a área de transferência!
As probes desta seção são desenvolvidas para monitorar aspectos básicos de seus sistemas. Ao aplicá-las, certifique-se de que seus limites de tempo não ultrapassem o tempo alocado para o período timeout (tempo limite). Caso contrário, a probe retorna um estado UNKNOWN (desconhecido) em todas as instâncias de latência extendida, conseqüentemente anulando os limites.
Copiar o linkLink copiado para a área de transferência!
A probe General::Remote Program permite a você executar qualquer comando ou script no seu sistema e obter um string do estado. Note que a mensagem resultante será limitada a 1024 Bytes.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.9. Configuração da General::Remote Program
Copiar o linkLink copiado para a área de transferência!
A probe General::Remote Program with Data permite a você executar qualquer comando ou script no seu sistema e obter um valor, assim como um string de estado. Para usar esta probe, você deve incluir código XML no corpo de seu script. Esta probe suporta as seguintes etiquetas XML:
<perldata> </perldata>
<hash> </hash>
<item key =" "> </item>
O programa remoto precisará retornar um output com alguma repetição do seguinte código para STDOUT:
Copy to ClipboardCopied!Toggle word wrapToggle overflow
O valor necessário para data é o ponto de dados a ser inserido no banco de dados para tendência a time-series. A status_message é opcional e pode ser qualquer string de texto desejado, com comprimento máximo de 1024 Bytes. Os programas remotos que não incluem uma status_message ainda reportam o valor e estado retornados.
Requisitos O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para executar esta probe. O XML é sensível a caixa alta e baixa. O nome da chave do item data não pode ser alterado e deve coletar o valor de um número.
Expand
Tabela A.10. Configuração da General::Remote Program with Data
Copiar o linkLink copiado para a área de transferência!
A probe General::SNMP Check testa seu servidor SNMP, especificando um identificador único do objeto (single object identifier, OID) na forma pontuada (tal como 1.3.6.1.2.1.1.1.0) e um limite associado ao valor retornado. Coleta os seguintes resultados:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor SNMP responder a um pedido de conexão.
Requisitos - O SNMP deve estar rodando no sistema monitorado para executar esta probe. Somente números inteiros podem ser usados nos valores dos limites.
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Copiar o linkLink copiado para a área de transferência!
A probe General::TCP Check testa seu servidor TCP ao verificar se este pode conectar-se a um sistema através do número de porta especificado. Coleta os seguintes resultados:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor TCP responder a um pedido de conexão.
A probe passará o string especificado no campo Send ao efetuar uma conexão. A probe antecipa uma resposta do sistema, que deve incluir o substring especificado no campo Expect. Se o string esperado não for encontrado, a probe retorna um estado CRITICAL (crítico).
Copiar o linkLink copiado para a área de transferência!
A probe General::UDP Check testa seu servidor UDP ao verificar se este pode conectar-se a um sistema através do número de porta especificado. Coleta os seguintes resultados:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor UDP responder a um pedido de conexão.
A probe passará o string especificado no campo Send ao efetuar uma conexão. A probe antecipa uma resposta do sistema, que deve incluir o substring especificado no campo Expect. Se o string esperado não for encontrado, a probe retorna um estado CRITICAL (crítico).
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Copiar o linkLink copiado para a área de transferência!
A probe General::Uptime (SNMP) grava o tempo desde a última vez que o dispositivo foi iniciado. Usa o identificador único de objeto (object identifier, OID) do SNMP para obter este valor. O único estado de erro que retornará será UNKNOWN (desconhecido).
Requisitos - O SNMP deve estar rodando no sistema monitorado e o acesso ao OID deve ser ativado para efetuar esta probe.
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Expand
Tabela A.14. Configuração da General::Uptime (SNMP)
Copiar o linkLink copiado para a área de transferência!
As probes desta seção monitoram aspectos essenciais de seus sistemas Linux, do uso da CPU à memória virtual. Aplique-as em sistemas críticos para obter avisos antes das falhas.
Ao contrário de outros grupos de probes, que podem ou não precisar do daemon de monitoramento do Red Hat Network, toda probe Linux precisa que o daemon rhnmd esteja rodando no sistema monitorado.
Copiar o linkLink copiado para a área de transferência!
A probe Linux::Disk IO Throughput monitora um determinado disco e coleta o seguinte resultado:
Taxa de Acesso (Read Rate) - A quantidade de dados acessados, em kilobytes por segundo.
Taxa de Gravação (Write Rate) - A quantidade de dados gravados, em kilobytes por segundo.
Para obter o valor do campo Disk number or disk name necessário, invoque iostat no sistema a ser monitorado e verifique o nome atribuído ao disco que você deseja. O valor padrão 0 geralmente provê estatísticas do primeiro disco rígido conectado diretamente ao sistema.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para executar esta probe. Além disso, o parâmetro Disk number or disk name deve ser do mesmo formato visto quando o comando iostat é submetido. Se o formato não é idêntico, a probe configurada entra num estado UNKNOWN (desconhecido).
Expand
Tabela A.16. Configuração da Linux::Disk IO Throughput
Copiar o linkLink copiado para a área de transferência!
A probe Linux::Inodes monitora o sistema de arquivo específico e coleta o seguinte resultado:
Inodes - A porcentagem de inodes em uso corrente.
Um inode é uma estrutura de dados contendo informações sobre arquivos num sistema de arquivo Linux. Há um inode para cada arquivo e cada arquivo é unicamente identificado pelo sistema de arquivo no qual reside e por seu número de inode neste sistema.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Copiar o linkLink copiado para a área de transferência!
A probe Linux::Interface Traffic mede a quantidade de tráfego de entrada e saída da interface específica (tal como eth0) e coleta os seguintes resultados:
Taxa de Input (Input Rate) - O tráfego de entrada na interface específica, em bytes por segundo.
Taxa de Output (Output Rate) - O tráfego de saída da interface específica, em bytes por segundo.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.19. Configuração da Linux::Interface Traffic
Copiar o linkLink copiado para a área de transferência!
A probe Linux::Process Counts by State identifica o número de processos nos seguintes estados:
Bloqueado (Blocked) - Um processo comutado para a fila de espera (waiting queue) e cujo estado foi alterado para waiting.
Extinto (Defunct) - Um processo que foi terminado (porque foi morto/killed por um sinal ou porque invocou exit()) e cujo processo pai ainda não recebeu a notificação de sua terminação ao executar alguma forma de chamada wait() do sistema.
Parado (Stopped) - Um processo que foi parado antes de completar sua execução.
Dormente (Sleeping) - Um processo que está no estado de sono interruptível (Interruptible sleep), podendo ser posteriormente reintroduzido na memória, reiniciando a execução no ponto em que parou.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.22. Configuração da Linux::Process Counts by State
Copiar o linkLink copiado para a área de transferência!
A probe Linux::Process Health monitora os processos especificados pelo usuário e coleta os seguintes resultados:
Uso da CPU (CPU Usage) - O uso da CPU para um determinado processo em milissegundos por segundo. Este resultado reporta a coluna time do resultado do comando ps, que é o tempo acumulado de uso da CPU pelo processo. Isto torna o resultado independente do intervalo da probe, permite a definição de limites sãos e gera gráficos utilizáveis (ex.: um pico repentino no uso da CPU também mostra um pico no gráfico).
Grupos de Processos Filho (Child Process Groups) - O número de processos filho gerados pelo processo pai especificado. Um processo filho herda a maioria de seus atributos, como arquivos abertos, de seu pai.
Threads - O número de threads em execução de um determinado processo. Um thread é a unidade básica de utilização da CPU e consiste de um contador de programa, um conjunto de registro e um espaço stack. Um thread também é chamado de processo lightweight.
Memória Física Usada (Physical Memory Used) - A quantidade de memória física (ou RAM) usada pelo processo especificado, em kilobytes.
Memória Virtual Usada (Virtual Memory Used) - A quantidade de memória virtual usada pelo processo especificado em kilobytes ou o tamanho do processo em memória real mais troca.
Especifique o processo através do nome do comando ou I.D. do processo (PID). Indicar um PID sobrescreve a indicação do nome do comando. Se nem o nome do comando ou I.D. do processo for especificado, aparece o erro Command not found e a probe recai no estado CRITICAL (crítico).
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.24. Configuração da Linux::Process Health
Copiar o linkLink copiado para a área de transferência!
A probe Linux::Process Running verifica se o processo especificado está funcionando apropriadamente. Conta os processos ou grupos de processos, dependendo da seleção da caixa de verificação Count process groups.
Por padrã, a caixa de verificação é selecionada, assim indicando que a probe deve contar o número de líderes dos grupos de processos, independente do número de filhos. Isto permite a você verificar, por exemplo, verificar que duas instâncias do Servidor da Web Apache estão rodando independente do número (dinâmico) de processos filho. Se desselecionada, a probe conduz uma contagem simples do número de processos (filhos e líderes) coincidentes ao processo especificado.
Especifique o processo através do nome do comando ou I.D. do processo (PID). Indicar um PID sobrescreve a indicação do nome do comando. Se nem o nome do comando ou I.D. do processo for especificado, aparece o erro Command not found e a probe recai no estado CRITICAL (crítico).
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.25. Configuração da Linux::Process Running
Copiar o linkLink copiado para a área de transferência!
A probe Linux::TCP Connections by State identifica o número total de conexões TCP, assim como a quantidade de cada nos seguintes estados:
TEMPO_ESPERA (TIME_WAIT) - O socket está esperando após ser fechado para a transmissão do desligamento remoto, portanto ainda pode haver pacotes na rede.
FECHA_ESPERA (CLOSE_WAIT)- O lado remoto foi desligado e agora aguarda o socket fechar.
FIN_ESPERA (FIN_WAIT) - O socket é fechado e agora a conexão está sendo desligada.
ESTABELECIDA (ESTABLISHED) - O socket tem uma conexão estabelecida.
SYN_RCVD - O pedido de conexão foi recebido pela rede.
Esta esta probe ser útil para encontrar e isolar o tráfego de rede a endereços IP específicos ou para examinar conexões de rede no sistema monitorado.pode
Os parâmetros de filtragem da probe permitem a você restringir seu escopo. Esta probe usa um comando netstat -ant para obter dados. Os parâmetros Local IP address e Local port usam os valores da coluna Local Address do output; e os parâmetros Remote IP address e Remote port usam os valores da coluna Foreign Address (Endereço de Porta Remoto) do output para reportar.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.27. Configuração da Linux::TCP Connections by State
Campo
Valor
Lista de padrões de filtragem do endereço IP local
Filtro do número da porta local
Lista de padrões de filtragem do endereço IP remoto
Copiar o linkLink copiado para a área de transferência!
As probes desta seção monitoram os arquivos de registro de seus sistemas. Você pode usá-las para fazer buscas em registros e acompanhar o tamanho dos arquivos. Para rodar as probes LogAgent, o usuário nocpulse deve receber acesso de leitura (read) a seus arquivos de registro.
Note que os dados da primeira execução destas probes não são medidos comparados aos limites para evitar notificações falsas causadas por dados métricos incompletos. As medições começam na segunda execução.
Copiar o linkLink copiado para a área de transferência!
A probe LogAgent::Log Pattern Match usa expressões regulares para buscar texto localizado no arquivo de registro monitorado e coleta os seguintes resultados:
Ocorrências de Expressões Regulares (Regular Expression Matches) - O número de ocorrências desde a última execução da probe.
Taxa de Ocorrência das Expressões Regulares (Regular Expression Match Rate) - O número de ocorrências por minuto desde a última execução da probe.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para executar esta probe. Além disso, o usuário nocpulse deve receber acesso de leitura (read access) a seus arquivos de registro.
Além do nome e localidade do arquivo de registro a monitorar, você deve indicar uma expressão regular para ser encontrada. Esta expressão deve ser formatada para o egrep, que é equivalente a grep -E e suporta expressões regulares extendidas. Este é o conjunto de expressões regulares do egrep:
^ beginning of line
$ end of line
. match one char
* match zero or more chars
[] match one character set, e.g. '[Ff]oo'
[^] match not in set '[^A-F]oo'
+ match one or more of preceding chars
? match zero or one of preceding chars
| or, e.g. a|b
() groups chars, e.g., (foo|bar) or (foo)+
^ beginning of line
$ end of line
. match one char
* match zero or more chars
[] match one character set, e.g. '[Ff]oo'
[^] match not in set '[^A-F]oo'
+ match one or more of preceding chars
? match zero or one of preceding chars
| or, e.g. a|b
() groups chars, e.g., (foo|bar) or (foo)+
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Atenção
Não inclua aspas simples (') na expressão. Fazer isso causa a falha silenciosa do egrep e o tempo limite da probe.
Expand
Tabela A.30. Configuração da LogAgent::Log Pattern Match
Copiar o linkLink copiado para a área de transferência!
A probe LogAgent::Log Size monitora o crescimento do arquivo de registro e coleta os seguintes resultados:
Tamanho (Size) - O tamanho que o arquivo de registro aumentou em bytes desde a última execução da probe.
Taxa de Output (Output Rate) - O número de bytes por minuto que o arquivo de registro aumentou desde a última execução da probe.
Linhas (Lines) - O número de linhas gravadas no arquivo de registro desde a última execução da probe.
Taxa de Linhas (Line Rate) - O número de linhas gravadas por minuto no arquivo de registro desde a última execução da probe.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para executar esta probe. Além disso, o usuário nocpulse deve receber acesso de leitura (read access) a seus arquivos de registro.
Copiar o linkLink copiado para a área de transferência!
As probes desta seção monitoram aspectos do banco de dados MySQL usando o binário mysqladmin. Não é necessário nenhum privilégio específico a usuários para estas probes.
Note que o pacote mysql-server deve estar instalado no sistema conduzindo o monitoramento para estar probes serem completas. Consulte a seção MySQL Installation do Red Hat Satellite Installation Guide para mais instruções.
Copiar o linkLink copiado para a área de transferência!
A probe MySQL::Database Accessibility testa a conectividade através de uma conta de banco de dados sem privilégios de banco de dados. Se nenhuma conexão é feita, resulta num estado CRITICAL (crítico).
Expand
Tabela A.32. Configuração da MySQL::Database Accessibility
Copiar o linkLink copiado para a área de transferência!
As probes desta seção monitoram vários serviços pertencentes a uma rede em funcionamento. Ao aplicá-las, garanta que seus limites de tempo não excedam o tempo alocado para o período limite (timeout). Caso contrário, um estado UNKNOWN (desconhecido) é retornado em todas as instâncias de latência extendida, assim anulando os limites.
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::DNS Lookup usa o comando dig para tentar obter o nome do domínio ou do sistema especificado no campo Host or Address to look up. Coleta o seguinte resultado:
Tempo do Pedido (Query Time) - O tempo em milissegundos necessário para executar o pedido dig.
Isso é útil ao monitorar o estado de seus servidores DNS. Para monitorar um de seus servidores DNS, forneça um nome de domínio/máquina conhecido, como um grande mecanismo de busca ou site corporativo.
Expand
Tabela A.37. Configuração da Network Services::DNS Lookup
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::FTP usa os sockets de rede para testar a disponibilidade da porta FTP. Coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor TCP responder a um pedido de conexão.
Esta probe suporta a autenticação. Forneça um nome de usuário e senha nos campos apropriados para usar esta funcionalidade. O valor opcional de Expect é o string a ser procurado após uma conexão bem-sucedida ao servidor FTP. Se o string esperado não for encontrado, a probe retorna um estado CRITICAL (crítico).
Expand
Tabela A.38. Configuração da Network Services::FTP
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::IMAP Mail determina se pode conectar ao serviço IMAP no sistema. Especificar uma porta opcional sobrescreve a porta padrão 143. Coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor IMAP responder a um pedido de conexão.
O valor Expect necessário é o string a ser procurado após uma conexão bem-sucedida ao servidor IMAP. Se o string esperado não for encontrado, a probe retorna um estado CRITICAL (crítico).
Expand
Tabela A.39. Configuração da Network Services::IMAP Mail
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::Mail Transfer (SMTP) determina se é possível conectar à porta SMTP no sistema. Especificar um número de porta opcional sobrescreve a porta padrão 25. Coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor SMTP responder a um pedido de conexão.
Expand
Tabela A.40. Configuração da Network Services::Mail Transfer (SMTP)
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::Ping determina se o Servidor Red Hat Satellite pode invocar ping ao sistema monitorado ou a um endereço IP específico. Também verifica a perda de pacotes (packet loss) e compara a média da viagem completa (round trip average) com os níveis dos limites de Warning (Aviso) e Critical (Crítico). O valor necessário Packets to send permite a você controlar quantos pacotes ICMP ECHO são enviados ao sistema. Esta probe coleta os seguintes resultados:
Média da Viagem Completa (Round-Trip Average) - O tempo, em milissegundos, para o pacote ICMP ECHO viajar para e do sistema monitorado.
Perda de Pacote (Packet Loss) - A porcentagem de dados perdidos em trânsito.
Apesar de opcional, o campo IP Address pode ser instrumental na coleta de resultados para sistemas que têm endereços IP múltiplos. Por exemplo: se o sistema é configurado com endereços IP virtuais múltiplos ou usa a Network Address Translation (NAT) para suportar endereços IP externos e internos, esta opção pode ser usada para verificar um endereço IP secundário, ao invés do endereço primário associado ao nome da máquina.
Note que esta probe conduz o comando ping de um Servidor Red Hat Satellite e não do sistema monitorado. Preencher o campo IP Address não testa a conectividade entre o sistema e o endereço IP especificado, mas sim entre o Servidor Red Hat Network e o endereço IP. Sendo assim, indicar o mesmo endereço IP para probes de Ping em sistemas diferentes, executa exatamente a mesma tarefa. Para conduzir um comando ping de um sistema monitorado a um endereço IP individual, use a probe Remote Ping. Consulte a Seção A.8.7, “Network Services::Remote Ping (Serviços de Rede::Ping Remoto)”.
Expand
Tabela A.41. Configuração da Network Services::Ping
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::POP Mail determina se pode conectar à porta POP3 no sistema. É necessário especificar o número de uma porta; especificar o número de outra porta sobrescreve a porta padrão 110. Esta probe coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor POP responder a um pedido de conexão.
O valor necessário Expect é o string a ser procurado após uma conexão bem-sucedida ao servidor POP. A probe procura pelo string na primeira linha da resposta do sistema. O padrão é +OK. Se o string esperado não é encontrado, a probe retorna um estado CRITICAL (crítico).
Expand
Tabela A.42. Configuração da Network Services::POP Mail
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::Remote Ping determina se o sistema monitorado pode invocar ping num endereço IP específico. Também monitora a perda de pacotes e compara a média da viagem completa aos níveis dos limites Warning (Aviso) e Critical (Crítico). O valor necessário Packets to send permite a você controlar quantos pacotes ICMP ECHO são enviados ao endereço. Esta probe coleta os seguintes resultados:
Média da Viagem Completa (Round-Trip Average) - O tempo, em milissegundos, para o pacote ECHO viajar para e do endereço IP.
Perda de Pacote (Packet Loss) - A porcentagem de dados perdidos em trânsito.
O campo IP Address identifica o endereço exato a ser pingado. Ao contrário do campo opcional similar na probe Ping padrão, este campo é necessário. O sistema monitorado direciona o ping a um terceiro endereço, ao invés do Servidor Red Hat Satellite. Como a probe Remote Ping testa a conectividade pelo próprio sistema monitorado, um outro endereço IP deve ser especificado. Para invocar pings do Servidor Red Hat Satellite a um endereço IP ou de sistema, use a probe Ping padrão. Consulte a Seção A.8.5, “Network Services::Ping”.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Expand
Tabela A.43. Configuração da Network Services::Remote Ping
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::RPCService testa a disponibilidade de programas RPC (remote procedure call) num determinado endereço IP. Coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor RPC responder a um pedido de conexão.
Os programas de servidor RPC (que oferecem chamadas de função através daquela rede RPC) se auto-registram na rede RPC ao declarar um ID de programa e um nome de programa. NFS é um exemplo de serviço que funciona através do mecanismo RPC.
Programas clientes que desejam usar os recursos dos programas do servidor RPC, o fazem ao pedir, à máquina na qual o programa de servidor reside, para prover acesso às funções RPC no número ou nome do programa RPC. Estas conversas podem ocorrer através do TCP ou UDP (mas quase sempre via UDP).
Esta probe permite que você teste a disponibilidade de programas simples. Você deve especificar o nome ou número do programa, o protocolo através do qual a conversa ocorre e o tempo limite normal.
Expand
Tabela A.44. Configração da Network Services::RPCService
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::Secure Web Server (HTTPS) determina a disponibilidade do servidor Web seguro e coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor HTTPS responder a um pedido de conexão.
Esta probe confirma que pode conectar à porta HTTPS na máquina especificada e obter a URL especificada. Se nenhuma URL é especificada, a probe atrai o documento root. A probe procura por uma mensagem HTTP/1. do sistema, a não ser que você altere este valor. Especificar o número de outra porta sobrescreve a porta padrão 443.
Esta probe suporta a autenticação. Forneça um nome de usuário e senha nos campos apropriados para usar esta funcionalidade. Ao contrário da maioria das probes, esta retorna um estado CRITICAL (crítico), se não puder contatar o sistema durante o tempo limite.
Expand
Tabela A.45. Configuração da Network Services::Secure Web Server (HTTPS)
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::SSH determina a disponibilidade do SSH na porta especificada e coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor SSH responder a um pedido de conexão.
Ao contatar o servidor SSH e receber uma resposta válida, a probe exibe as informações da versão do servidor e do protocolo. Se a probe receber uma resposta inválida, exibe uma mensagem retornada pelo servidor e gera um estado WARNING (aviso).
Expand
Tabela A.46. Configuração da Network Services::SSH
Copiar o linkLink copiado para a área de transferência!
A probe Network Services::Web Server (HTTP) determina a disponibilidade do servidor Web e coleta o seguinte resultado:
Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor HTTP responder a um pedido de conexão.
Esta probe confirma se é possível conectar à porta HTTP na máquina especificada e recupera a URL especificada. Se nenhuma URL for especificada, a probe atrairá o documento root. Então, a probe procura uma mensagem HTTP/1. do sistema, a não ser que você altere aquele valor. Especificar outro número de porta sobrescreverá a porta padrão 80. Ao contrário da maioria das outras probes, esta retornará um estado CRITICAL se não puder contatar o sistema durante o período de tempo limite.
Esta probe suporta a autenticação. Forneça um nome de usuário e senha nos campos devidos para usar esta funcionalidade. Além disso, o campo Virtual Host (máquina virtual) pode ser usado para monitorar um conjunto de documentos separado alocado na mesma máquina física, apresentada como um servidor independente. Se seu servidor Web não estiver configurado para usar máquinas virtuais (geralmente, esse é o caso), deve deixar este campo em branco. Se você não tiver máquinas virtuais configuradas, indique o nome de domínio da primeira máquina aqui. Adicione quantas probes forem necessárias para monitorar todas as máquinas virtuais no computador.
Expand
Tabela A.47. Configuração da Network Services::Web Server (HTTP)
Copiar o linkLink copiado para a área de transferência!
As probes desta seção podem ser aplicadas às instâncias do banco de dados Oracle com as mesmas versões daquelas suportadas. As probes Oracle requerem a configuração do banco de dados e associações feitas ao invocar o seguinte comando:
$ORACLE_HOME/rdbms/admin/catalog.sql
$ORACLE_HOME/rdbms/admin/catalog.sql
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Além disso, para estas probes funcionarem apropriadamente, o usuário Oracle configurado na probe deve ter os privilégios mínimos CONNECT e SELECT_CATALOG_ROLE.
Algumas probes Oracle focam no ajuste de dispositivos para ganhos de desempenho a longo prazo, ao invés da prevenção de quedas. Conseqüentemente, a Red Hat recomenda agendá-las com menos freqüência, entre cada hora e a cada dois dias. Isto provem uma melhor representação estatística, desenfatizando as anomalias que podem ocorrer em intervalos de tempo mais curtos. Isto se aplica às seguintes probes: Buffer Cache, Data Dictionary Cache, Disk Sort Ratio, Library Cache e Redo Log.
Para os limites temporais CRITICAL (crítico) e WARNING (aviso) funcionarem conforme planejado, seus valores não podem exceder o período de tempo limite (timeout). Caso contrário, um estado UNKNOWN (desconhecido) é retornado em todos os casos de latência extendida, assim anulando os limites. Por este motivo, a Red Hat recomenda garantir que os períodos de tempo limite excedam todos os limites temporais. Nesta seção, isto refere-se especificamente à probe TNS Ping.
Por fim, os clientes usando estas probes Oracle num banco de dados com o Servidor Multi-Threaded (MTS) da Oracle, devem contatar o suporte da Red Hat; a fim de obterem itens adicionados ao arquivo /etc/hosts do Servidor Red Hat Network e garantir que o nome DNS seja resolvido corretamente.
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Blocking Sessions monitora uma instância Oracle e coleta o seguinte resultado:
Sessões Bloqueadoras (Blocking Sessions) - O número de sessões evitando que outras submetam alterações ao banco de dados Oracle, conforme apontado pelo valor de Time Blocking provido por você. Somente as sessões que tem bloqueado outras neste período, medido em segundos, serão contadas como sessões bloqueadoras.
Expand
Tabela A.50. Configuração da Oracle::Blocking Sessions
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Buffer Cache computa a Proporção de Hits do Cache do Buffer (Buffer Cache Hit Ratio) para otimizar o tamanho do Cache do Buffer do Banco de Dados da área global do sistema (system global area, SGA). Coleta os seguintes resultados:
Obtenção de Blocos do Banco de Dados (Db Block Gets) - O número de blocos acessados através de obtenções de blocos únicos (não através do mecanismo get consistente).
Obtenções Consistentes (Consistent Gets) - O número de acessos ao buffer do bloco para recuperar os dados num modo consistente.
Acessos Físicos (Physical Reads) - O número acumulado de blocos acessados pelo disco.
Proporção de Hits do Cache do Buffer (Buffer Cache Hit Ratio) - A taxa na qual o banco de dados acessa o buffer, ao invés do disco rígido, para obter dados. Um taxa baixa sugere a adição de mais RAM ao sistema.
Expand
Tabela A.51. Configuração da Oracle::Buffer Cache
Campo
Valor
SID Oracle*
Nome de Usuário Oracle*
Senha Oracle*
Porta Oracle
1521
Tempo Limite*
30
Máximo de Aviso da Proporção de Hits ao Cache do Buffer
Máximo Crítico da Proporção de Hits ao Cache do Buffer
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Client Connectivity determina se o banco de dados está ligado e é capaz de receber conexões do sistema monitorado. Esta probe abre uma conexão rhnmd ao sistema e invoca um comando sqlplus connect no sistema monitorado.
O parâmetro Expected DB name (nome esperado do banco de dados) é o valor esperado de V$DATABASE.NAME. Este valor é sensível a caixa alta e baixa. Um estado CRITICAL (crítico) é retornado se este valor não for encontrado.
Requisitos - O daemon de monitoramento do Red Hat Network (rhnmd) deve estar rodando no sistema monitorado para executar esta probe. Além disso, o usuário nocpulse deve receber acesso de leitura (read access) a seus arquivos de registro.
Expand
Tabela A.52. Configuração da Oracle::Client Connectivity
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Data Dictionary Cache computa a Proporção de Hits do Cache do Dicionário de Dados (Data Dictionary Cache Hit Ratio) a fim de otimizar o SHARED_POOL_SIZE em init.ora. Coleta os seguintes resultados:
Proporção de Hits do Dicionário de Dados (Data Dictionary Hit Ratio) - A taxa de hits para tentativas de busca no cache do dicionário de dados. Em outras palavras, a taxa na qual o banco de dados acessa o dicionário, ao invés do disco rígido, para obter dados. Uma taxa baixa sugere a adição de mais RAM ao sistema.
Obtenções (Gets) - O número de blocos acessados através de obtenções de blocos únicos (e não através do mecanismo get consistente).
Perdas do Cache (Cache Misses) - O número de acesso ao buffer do bloco para recuperar dados num modo consistente.
Expand
Tabela A.53. Configuração da Oracle::Data Dictionary Cache
Campo
Valor
SID Oracle*
Nome de Usuário Oracle*
Senha Oracle*
Porta Oracle*
1521
Tempo Limite*
30
Máximo de Aviso da Proporção de Hits ao Dicionário de Dados
Máximo Crítico da Proporção de Hits ao Dicionário de Dados
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Disk Sort Ratio monitora uma instância do banco de dados Oracle e coleta o seguinte resultado:
Proporção da Ordem do Disco (Disk Sort Ratio) - A taxa de ordenações do Oracle que eram muito grandes para serem completas na memória e, portanto, foram ordenadas usando um segmento temporário.
Expand
Tabela A.54. Configuração da Oracle::Disk Sort Ratio
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Idle Sessions monitora um instância do banco de dados Oracle e coleta o seguinte resultado:
Sessões Ociosas (Idle Sessions) - O número de sessões ociosas do Oracle, conforme determinado pelo valor necessário Time Idle provido por você. Somente as sessões que estavam ociosas durante este período, medido em segundos, são contadas como ociosas.
Expand
Tabela A.55. Configuração da Oracle::Idle Sessions
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Library Cache computa a Proporção de Perdas do Cache da Library (Library Cache Miss Ratio) a fim de otimizar o SHARED_POOL_SIZE em init.ora. Coleta os seguintes resultados:
Proporção de Perdas do Cache da Library (Library Cache Miss Ratio) - A taxa de ocorrência das perdas de senha do cache de uma biblioteca. Isso acontece quando uma sessão executa uma afirmação que já resolveu, mas descobre que esta afirmação não está mais no conjunto compartilhado (shared pool).
Execuções (Executions) - O número de vezes que uma senha foi solicitada para objetos neste espaço de nomes (namespace).
Perdas do Cache (Cache Misses) - O número de senhas que devem agora recuperar o objeto do disco. Estes pins são feitos de objeto com pins anteriores, do tempo em que o manuseio do objeto foi criado.
Expand
Tabela A.57. Configuração da Oracle::Library Cache
Campo
Valor
SID Oracle*
Nome de Usuário Oracle*
Senha Oracle*
Porta Oracle*
1521
Tempo Limite*
30
Máximo Crítico da Proporção de Perdas do Cache da Library
Máximo de Aviso da Proporção de Perdas do Cache da Library
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Locks monitora uma instância do banco de dados Oracle e coleta o seguinte resultado:
Bloqueios Ativos (Active Locks) - O número corrente de bloqueios ativos, conforme determinado pelo valor da tabela v$locks. Os administradores de bancos de dados devem estar cientes do alto número de bloqueios presentes numa instância de banco de dados.
Os bloqueios são usados para evitar conflitos entre usuários ou processos múltiplos atualizando os mesmos dados no banco de dados. Esta probe é útil para alertar os administradores de bancos de dados quando houver um número alto de bloqueios presentes numa determinada instância.
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Redo Log monitora uma instância do banco de dados Oracle e coleta os seguintes resultados:
Taxa de Pedidos de Espaço no Registro Redo (Redo Log Space Request Rate) - O número médio de pedidos de espaço no registro redo (refazer) por minuto, desde a inicialização do servidor.
Taxa de Tentativas de Alocação do Buffer Redo (Redo Buffer Allocation Retry Rate) - O número médio de tentativas de alocação do buffer por minuto, desde a inicialização do servidor.
Os resultados retornados e os limites pelos quais são medidas são números representando a taxa de alteração nos eventos por minuto. A taxa de alteração destas medidas devem ser monitoradas, pois o crescimento rápido pode indicar problemas que requerem probe.
Expand
Tabela A.59. Configuração da Oracle::Redo Log
Campo
Valor
SID Oracle*
Nome de Usuário Oracle*
Senha Oracle*
Porta Oracle*
1521
Tempo Limite*
30
Máximo Crítico da Taxa dos Pedidos de Espaço no Registro Redo
Máximo de Aviso da Taxa dos Pedidos de Espaço no Registro Redo
Máximo Crítico da Taxa de Tentativas de Alocação do Buffer Redo
Máximo de Aviso da Taxa de Tentativas de Alocação do Buffer Redo
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Table Extents monitora uma instância do banco de dados Oracle e coleta os seguintes resultados:
Extensões Alocadas - Qualquer Tabela (Allocated Extents-Any Table) - O número total de extensões de qualquer tabela.
Extensões Disponíveis - Qualquer Tabela (Available Extents-Any Table) - A porcentagem de extensões disponíveis de qualquer tabela.
No Oracle, as extensões de tabela permitem que esta cresça. Quando uma tabela está cheia, é extendida para um espaço determinado quando a tabela é criada. As extensões são configuradas por tabela, com o tamanho da extensão e um número máximo de extensões.
Por exemplo: uma tabela que começa com 10 MB de espaço e é configurada com o tamanho de extensão de 1 MB e máximo de 10 extensões, pode aumentar para, no máximo, 20 MB (sendo extendida em 1 MB dez vezes). Esta probe pode ser configurada para alertar pelo (1) número de extensões alocadas (ex.: "go critical when the table has been extended 5 or more times") ou (2) a tabela é extendida após atingir uma determinada porcentagem de suas extensões máximas (ex.: "go critical when the table has exhausted 80% or more of its max extents").
Os campos necessários Table Owner e Table Name contêm o valor padrão %, que coincide com qualquer nome ou proprietário de tabela.
Expand
Tabela A.60. Configuração da Oracle::Table Extents
Copiar o linkLink copiado para a área de transferência!
A probe Oracle::Tablespace Usage monitora um instância do banco de dados Oracle e coleta o seguinte resultado:
Espaço Disponível Usado (Available Space Used) - A porcentagem de espaço disponível em cada tablespace que foi usado.
Tablespace é o conjunto de espaço compartilhado no qual reside um conjunto de tabelas. Esta probe alerta o usuário quando o espaço disponível total cai abaixo do limite. O tablespace é medido em bytes, portanto as extensões não contam diretamente neste (apesar de cada extensão remover espaço disponível do conjunto compartilhado).
O campo necessário Tablespace Name é sensível a caixa alta e baixa e contém o valor padrão %, que coincide com qualquer nome de tabela.
Expand
Tabela A.61. Configuração da Oracle::Tablespace Usage
Copiar o linkLink copiado para a área de transferência!
As probes desta seção podem ser aplicadas ao próprio Red Hat Satellite para monitorar sua saúde e desempenho. Como estas probes rodam localmente, não são necessários aplicações ou protocolos de transporte específicos.
Copiar o linkLink copiado para a área de transferência!
A probe Red Hat Satellite ::Latency monitora a latência das probes num Satellite e coleta o seguinte resultado:
Média de Latência da Detecção (Probe Latency Average) - O intervalo em segundos entre o momento em que uma probe torna-se pronta para ser executada e o tempo em que é realmente executada. Sob condições normais, este geralmente é menos de um segundo. Quando um Satellite é sobrecarregado (porque tem muitas probes em relação aos seus tempos médios de execução), este número aumenta.
Expand
Tabela A.66. Red Hat Satellite:: Configurações do Latency
Copiar o linkLink copiado para a área de transferência!
A probe Red Hat Satellite ::Process Counts monitora o número de processos num Satellite e coleta os seguintes resultados:
Bloqueados (Blocked) - O número de processos que foram enviados à fila de espera e estão no estado de espera (waiting).
Filho (Child) - O número de processos gerados por outros processos já rodando na máquina.
Extinto (Defunct) - O número de processos que foram terminados (porque foram mortos por um sinal ou por invocarem o comando exit()) e cujos processos pai ainda não receberam notificações de suas terminações executando alguma forma de chamada wait() do sistema.
Parados (Stopped) - O número de processos que foram parados antes que suas execuções fossem ser completas.
Dormente (Sleeping) - Um processo que está no estado de sono interruptível (Interruptible sleep), podendo ser posteriormente reintroduzido na memória, reiniciando a execução no ponto em que parou.
Expand
Tabela A.69. Red Hat Satellite::Configurações do Process Counts
Copiar o linkLink copiado para a área de transferência!
A probe Red Hat Satellite ::Process Health monitora os processos de clientes específicos e coleta os seguintes resultados:
Uso da CPU (CPU Usage) - A porcentagem de uso da CPU por um determinado processo.
Grupos de Processos Filho (Child Process Groups) - O número de processos filho gerados pelo processo pai especificado. Um processo filho herda a maioria de seus atributos, como arquivos abertos, de seu pai.
Threads - O número de threads em execução de um determinado processo. Um thread é a unidade básica de utilização da CPU e consiste de um contador de programa, um conjunto de registro e um espaço stack. Um thread também é chamado de processo lightweight.
Memória Física Usada (Physical Memory Used) - A quantidade de memória física usada pelo processo especificado, em kilobytes.
Memória Virtual Usada (Virtual Memory Used) - A quantidade de memória virtual usada pelo processo especificado em kilobytes ou o tamanho do processo em memória real mais troca.
Especifique o processo através do nome do comando ou I.D. do processo (PID). Indicar um PID sobrescreve a indicação do nome do comando. Se nem o nome do comando ou I.D. do processo for especificado, aparece o erro Command not found e a probe recairá no estado CRITICAL (crítico).
Expand
Tabela A.71. Red Hat Satellite::Configurações de Process Health
Copiar o linkLink copiado para a área de transferência!
A probe Red Hat Satellite ::Process Running verifica se o processo especificado está rodando. Especifique o processo através do nome do comando ou I.D. do processo (PID). Indicar um PID sobrescreve a entrada do nome do comando. Se a probe não puder verificar o comando ou PID, resulta num estado Critical (crítico).
Expand
Tabela A.72. Red Hat Satellite::Configurações do Process Running
Copiar o linkLink copiado para a área de transferência!
A probe Red Hat Satellite ::Swap monitora a porcentagem do espaço swap livre disponível num Satellite. Um estado CRITICAL (crítico) resulta se o valor cair abaixo do limite crítico. Um estado WARNING (aviso) resulta se o valor recai abaixo do limite de Aviso.
Expand
Tabela A.73. Red Hat Satellite:: Configurações do Swap
Copiar o linkLink copiado para a área de transferência!
A probe Red Hat Satellite ::Users monitora o número de usuários correntes autenticados num Satellite.Um estado CRITICAL resulta se o valor exceder o limite crítico.Um estado WARNING resulta te o valor exceder o limite de Aviso.
Expand
Tabela A.74. Red Hat Satellite:: Configurações de Usuários
Copiar o linkLink copiado para a área de transferência!
Histórico de Revisões
Revisão 4-32.2.400
2013-10-31
RüdigerLandmann
Rebuild with publican 4.0.0
Revisão 4-32.2
Thu Aug 30 2013
GlauciaCintra
pt-BR translation completed
Revisão 4-32.1
Fri Aug 30 2013
TerryChuang
Tradução de arquivos sincronizados com a versão 4-32 de fontes do XML
Revisão 4-32
Thu Aug 29 2013
DanMacpherson
Primeira implementação de feedback de revisão de QE
Revisão 4-31
Tue Aug 27 2013
DanMacpherson
Pequenas mudanças
Revisão 4-30
Tue Aug 27 2013
DanMacpherson
Implementação de QE Final
Revisão 4-29
Tue Aug 27 2013
DanMacpherson
Reparando o texto da tela
Revisão 4-28
Tue Aug 27 2013
DanMacpherson
Removendo as marcações do computeroutput
Revisão 4-27
Tue Aug 27 2013
DanMacpherson
Implementação do feedback a partir do BZ#1001385
Revisão 4-26
Tue Aug 27 2013
DanMacpherson
Implementando o feedback do QE a partir do BZ#1001385
Revisão 4-25
Tue Aug 27 2013
DanMacpherson
Correções de Erros pequenos para o BZ#1001378
Revisão 4-24
Tue Aug 27 2013
DanMacpherson
Implementação do feedback do QE no BZ#1001378 e BZ#1001379
Revisão 4-23
Tue Aug 27 2013
DanMacpherson
Implementação do Feedback do QE para BZ#1001376
Revisão 4-22
Thu Aug 15 2013
DanMacpherson
Correções de datilografia da revisão do Controle de Qualidade
Revisão 4-21
Sun Jul 28 2013
DanMacpherson
Segunda implementação de feedback de revisão técnica
Revisão 4-20
Wed Jul 24 2013
DanMacpherson
Correções para BZ#987245
Revisão 4-19
Tue Jul 23 2013
DanMacpherson
Primeira implementação de feedback de revisão técnica
Revisão 4-18
Thu Jul 12 2013
DanMacpherson
Atualizações Beta finais
Revisão 4-17
Thu Jul 12 2013
DanMacpherson
Atualizações Beta
Revisão 4-16
Thu Jul 11 2013
AtheneChan
Seção Splice editada
Conteúdo adicionado do ISS extra.
Revisão 4-15
Fri Jul 5 2013
AtheneChan
BZ#906577 Edição do ISS a partir das revisões do desenvolvedor
Revisão 4-14
Fri Jul 5 2013
AtheneChan
BZ#906577 Informação adicional sobre os novos recursos do ISS foram incluídos.
Revisão 4-13
Fri June 28 2013
AtheneChan
Foram atualizadas todas as seções baseadas em mudanças UI atualizadas.
Foram modificadas todas as "Red Hat Satellite Proxy" baseado na mudança de nome da marca.
BZ#906577 Foram adicionadas informações do Intersatellite-sync ao livro.
Revisão 4-12
Tue June 4 2013
AtheneChan
BZ#969091 Foi modificado o nome de arquivo desatualizado de /etc/Red Hat Network/Red Hat Network_web.conf para /etc/Red Hat Network/Red Hat Network.conf.
Revisão 4-11
Fri May 17 2013
AtheneChan
Procedimentos de livro editado baseado na interface de usuário.
Em fase de revisão.
Revisão 4-10
Thu Apr 25 2013
AtheneChan
BZ#908911 Todas as referências up2date foram modificadas para as versões atuais.
BZ#927113, 950295 abstrato do livro foi atualizado
BZ#927546, 924221 Edições menores para termos padronizados
Conteúdo editado para o próximo lançamento de versão.
Revisão 4-9
Thu Feb 28 2013
AtheneChan
Tabela de Conteúdos editada na preparação para o próximo lançamento da versão.
Revisão 4-8
Wed Jan 2 2013
AtheneChan
BZ#862950 Espaço entre o "(pup)" e "aquele" foram incluídos.
Revisão 4-7
Wed Sept 19 2012
DanMacpherson
Empacotamento final para o 5.5
Revisão 4-6
Thu Aug 16 2012
AtheneChan
BZ#847993 nome do arquivo foi modificado no exemplo na seção 5.2.4
Revisão 4-5
Thu Aug 16 2012
AtheneChan
BZ#773647 foram atualizados os parágrafos pertencentes ao "criar uma nova conta" screenshot
BZ#846691 foi atualizado o link "comprar" na seção 1.1
Revisão 4-4
Wed Aug 15 2012
AtheneChan
BZ#773647 foi atualizado o screenshot "criar uma nova conta"
Revisão 4-3
Thu Aug 9 2012
AtheneChan
Documentos em processo de "stage" para a revisão
Revisão 3-2
Fri Aug 3 2012
AtheneChan
BZ#844849 Parágrafo reestruturado.
Revisão 3-1
Tue Jun 17 2012
AtheneChan
Conteúdo obsoleto foi removido. Preparado para o Lançamento 5.5
BZ#837703 Foi adicionada uma nota da Chave GPG Padronizada
Revisão 3-0
Thurs May 24 2012
AtheneChan
BZ#783340 - "s390x" to "IBM System z" Atualizado
Revisão 2-6
Mon Jan 9 2012
LanaBrindley
BZ#707591 - Capítulo de virtualização - atualizar instruções
BZ#746640 - Capítulo de virtualização - informação de kickstart adicionado
Revisão 2-5
Wed Jan 4 2012
LanaBrindley
BZ#707568 & BZ#707570 - Capítulo de virtualização - nomes de canais
BZ#744653 - Capítulo de virtualização - erros de digitação
BZ#744656 - Capítulo de virtualização - atualizar instruções do RHEL6
BZ#750481 - Foi atualizado o método para modificar o tamanho do arquivo max
BZ#766424 - Capítulo do Kickstart - texto atualizado
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.
Tornando o open source mais inclusivo
A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.
Sobre a Red Hat
Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.