Red Hat Training
A Red Hat training course is available for Red Hat Satellite
Guia de Referência
Red Hat Satellite 5.6
Um guia para os recursos avançados do Red Hat Satellite
Edição 1
Resumo
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.
Prefácio
1. Audiê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.
Capítulo 1. Informações do Red Hat Satellite
Esta seção cobre diversos tópicos sobre a configuração avançada do Red Hat Satellite.
1.1. Ferramentas de Administração de Configuração na Linha de Comandos
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.
1.1.1. Red Hat Network Actions Control
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.
1.1.1.1. Opções gerais da linha de comandos
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:
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.
1.1.2. Red Hat Network Configuration Client
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).
1.1.2.1. Listando Arquivos de Configuração
Para listar os arquivos de configuração da máquina e das etiquetas dos canais de configuração que as contém, execute o comando:
rhncfg-client list
O resultado se parece com a lista seguinte:
Config Channel File config-channel-17 /etc/example-config.txt config-channel-17 /var/spool/aalib.rpm config-channel-14 /etc/rhn/rhn.conf
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
e observe o seguinte resultado:
Files in config channel 'config-channel-14' /etc/example-config.txt /etc/rhn/rhn.conf
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.
1.1.2.2. Obtendo um Arquivo de Configuração
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
Você deve observar um resultado parecido com:
Implementando /etc/example-config.txt
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).
1.1.2.3. Visualizando Canais de Configuração
Para visualizar as etiquetas e nomes dos canais de configuração que se aplicam ao sistema, submeta o comando:
rhncfg-client channels
Você deve observar um resultado parecido com:
Config channels: Label Name ----- ---- config-channel-17 config chan 2 config-channel-14 config chan 1
A tabela seguinte lista as opções do
rhncfg-client get:
Tabela 1.2. opções do rhncfg-client get
| Opção | Descrição |
|---|---|
| --topdir=TOPDIR | Tornar todas as operações de arquivo relativas a este string. |
| --exclude=EXCLUDE | Exclui um arquivo de ser implementado com o 'get' / Pode ser utilizado diversas vezes. |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.2.4. Diferenciando entre arquivos de configuração
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
O resultado se parece com:
[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
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:
[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
1.1.2.5. Verificando arquivos de configuração
Para determinar rapidamente se os arquivos de configuração do cliente são diferentes daqueles associados no Red Hat Network, submeta o comando:
rhncfg-client verify
O resultado se parece com:
modificado /etc/example-config.txt /var/spool/aalib.rpm
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:
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. |
| -o, --only | Somente exibir arquivos que diferem |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3. Red Hat Network Configuration Manager
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
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
Substitua mode pelo nome do modo a ser inspecionado:
rhncfg-manager diff-revisions --help
Você pode ver esta lista de opções para o modo adicionar (add) na Tabela 1.4, “opções do
rhncfg-manager add”.
1.1.3.1. Criando um Canal de Configuração
Para criar um canal de configuração para sua empresa, execute o comando:
rhncfg-manager create-channel channel-label
Se for necessário, indique seu nome de usuário e senha do Red Hat Network. O resultado é semelhante a este:
Red Hat Network username: rhn-user Password: Creating config channel channel-label Config channel channel-label created
Após criar o canal de configuração, use os modos remanescentes listados acima para popular e manter aquele canal.
1.1.3.2. Adicionando Arquivos a um Canal de Configuração
Para adicionar um arquivo a um canal de configuração, especifique a etiqueta do canal, assim como o arquivo local para upload. Por exemplo:
rhncfg-manager add --channel=channel-label /path/to/file
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:
rhncfg-manager add --channel=channel-label --dest-file=/new/path/to/file.txt/path/to/file
O resultado se parece com:
Alocando para o canal example-channel Arquivo local >/path/to/file -> arquivo remoto /new/path/to/file.txt
A tabela seguinte lista as opções do
rhncfg-manager add:
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
Além disso, encontre ou crie a seguinte linha no arquivo
/etc/rhn/rhn.conf:
maximum_config_file_size=128
Em ambos locais, mude o valor de 128 para qualquer limite que você deseja em bytes.
1.1.3.3. Diferenciando entre os Arquivos de Configuração mais Recentes
Para ver as diferenças entre os arquivos de configuração no disco e as revisões mais recentes de um canal, execute o comando:
rhncfg-manager diff --channel=channel-label --dest-file=/path/to/file.txt \ /local/path/to/file
Você deve observar um resultado parecido com:
--- /tmp/dest_path/example-config.txt config_channel: example-channel revision: 1 +++ /home/test/blah/hello_world.txt 2003-12-14 19:08:59.000000000 -0500 @@ -1 +1 @@ -foo +hello, world
A tabela seguinte lista as opções do
rhncfg-manager diff:
Tabela 1.5. opções do rhncfg-manager diff
| Opção | Descrição |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Obtém arquivo(s) deste canal de configuração |
| -r REVISION, --revision=REVISION | Usa esta revisão |
| -d DEST_FILE, --dest-file=DEST_FILE | Faz o upload do arquivo conforme este caminho |
| -t TOPDIR, --topdir=TOPDIR | Torna todos os arquivos relativos a este string |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3.4. Diferenciando entre Versões Diversas
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:
rhncfg-manager diff-revisions -n=channel-label1 -r=1 -n=channel-label2 -r=1 /path/to/file.txt
O resultado se parece com:
--- /tmp/dest_path/example-config.txt 2004-01-13 14:36:41 \ config channel: example-channel2 revision: 1 --- /tmp/dest_path/example-config.txt 2004-01-13 14:42:42 \ config channel: example-channel3 revision: 1 @@ -1 +1,20 @@ -foo +blah +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQA9ZY6vse4XmfJPGwgRAsHcAJ9ud9dabUcdscdcqB8AZP7e0Fua0NmKsdhQCeOWHX +VsDTfen2NWdwwPaTM+S+Cow= +=Ltp2 +-----END PGP SIGNATURE-----
A tabela seguinte lista as opções do
rhncfg-manager diff-revisions:
Tabela 1.6. opções do rhncfg-manager diff-revisions
| Opção | Descrição |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Usa este canal de configuração |
| -r REVISION, --revision=REVISION | Usa esta revisão |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3.5. Fazendo o Download de Todos Arquivos de um Canal
Para fazer o download de todos os arquivos de um canal para o disco, crie um diretório e execute o seguinte comando:
rhncfg-manager download-channel channel-label --topdir .
O resultado se parece com:
Copying /tmp/dest_path/example-config.txt -> \ blah2/tmp/dest_path/example-config.txt
A tabela seguinte lista as opções do
rhncfg-manager download-channel:
Tabela 1.7. opções do rhncfg-manager download-channel
| Opção | Descrição |
|---|---|
| -t TOPDIR, --topdir=TOPDIR | O diretório ao qual todas os caminhos de arquivo são relativos. Esta opção deve ser definida. |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3.6. Obtendo o Conteúdo de um Arquivo
Para direcionar o conteúdo de um arquivo específico para stdout, execute o comando:
rhncfg-manager get --channel=channel-label \ /tmp/dest_path/example-config.txt
Você deve observar o conteúdo do arquivo como resultado.
1.1.3.7. Listando Todos Arquivos de um Canal
Para listar todos os arquivos de um canal, execute o comando:
rhncfg-manager list channel-label
Você deve observar um resultado parecido com:
Arquivos no canal de configuração `example-channel3': /tmp/dest_path/example-config.txt
A tabela seguinte lista as opções do
rhncfg-manager get:
Tabela 1.8. opções do rhncfg-manager get
| Opção | Descrição |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Obtém arquivo(s) deste canal de configuração |
| -t TOPDIR, --topdir=TOPDIR | Torna todos os arquivos relativos a este string |
| -r REVISION, --revision=REVISION | Obter esta revisão do arquivo |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3.8. Listando Todos Canais de Configuração
Para listar todos os canais de configuração da sua empresa, execute o comando:
rhncfg-manager list-channels
O resultado se parece com:
Available config channels: example-channel example-channel2 example-channel3 config-channel-14 config-channel-17
Note que este comando não lista os canais
local_override ou server_import.
1.1.3.9. Removendo um Arquivo de um Canal
Para remover um arquivo de um canal, execute o comando:
rhncfg-manager remove --channel=channel-label /tmp/dest_path/example-config.txt
Se for necessário, indique seu nome de usuário e senha do Red Hat Network. Você deve observar um resultado semelhante a:
Red Hat Network username: rhn-user Password: Removing from config channel example-channel3 /tmp/dest_path/example-config.txt removed
A tabela seguinte lista as opções do
rhncfg-manager remove:
Tabela 1.9. opções do rhncfg-manager remove
| Opção | Descrição |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Remove arquivos deste canal de configuração |
| -t TOPDIR, --topdir=TOPDIR | Torna todos os arquivos relativos a este string |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3.10. Apagando um Arquivo de Configuração
Para eliminar um canal de configuração de sua empresa, execute o comando:
rhncfg-manager remove-channel channel-label
O resultado se parece com:
Removing config channel example-channel Config channel example-channel removed
1.1.3.11. Determinando o Número de Revisões do Arquivo
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:
rhncfg-manager revisions channel-label /tmp/dest_path/example-config.txt
O resultado se parece com:
Analisando arquivos no canal de config example-channel \ /tmp/dest_path/example-config.txt: 1
1.1.3.12. Atualizando um Arquivo de um Canal
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:
rhncfg-manager update \ --channel=channel-label --dest-file=/path/to/file.txt /local/path/to/file
O resultado se parece com:
Pushing to channel example-channel: Local file example-channel/tmp/dest_path/example-config.txt -> \ remote file /tmp/dest_path/example-config.txt
A tabela seguinte lista as opções do
rhncfg-manager update:
Tabela 1.10. opções do rhncfg-manager update
| 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 |
| -t TOPDIR, --topdir=TOPDIR | Torna todos os arquivos relativos a este string |
| --delim-start=DELIM_START | Inicia o delimitador para intercalar variáveis |
| --delim-end=DELIM_END | Finaliza o delimitador para intercalar variáveis |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.1.3.13. Upload de Arquivos Múltiplos
Para fazer o upload de arquivos múltiplos do disco local para um canal de configuração de uma vez, execute o comando:
rhncfg-manager upload-channel --topdir=topdir channel-label
O resultado se parece com:
Using config channel example-channel4 Uploading /tmp/ola_world.txt from blah4/tmp/ola_world.txt
A tabela seguinte lista as opções do
rhncfg-manager upload-channel:
Tabela 1.11. opções do rhncfg-manager upload-channel
| Opção | Descrição |
|---|---|
| -t TOPDIR, --topdir=TOPDIR | O diretório ao qual todas os caminhos de arquivo são relativos |
| -c CHANNEL, --channel=CHANNEL | Lista dos canais aos quais as informações de configuração serão salvas (uploaded). Os canais são delimitados por ','. Exemplo: --channel=foo,bar,baz |
| -h, --help | Exibe a mensagem de ajuda e fecha |
1.2. Monitoramento
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.
1.2.1. Pré-requisitos
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é → . Clique em Enable Monitoring e depois em para salvar.
- Reinicie os serviços para captar as mudanças. Vá para a aba para reiniciar o Satellite. Isto fará que o Satellite fique off line por alguns minutos.
- Verifique se a aba está disponível sob o para confirmar que o monitoring está habilitado.
- Navegue até → → . Clique em para habilitar o scout. Clique em para salvar.
Nota
É recomendado que você deixe os valores de configuração como valores padrões. Sendmail precisa ser configurado para usar notificações.
1.2.2. Configurando o Red Hat Network Monitoring Daemon (rhnmd)
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.
1.2.2.1. Instalando o Red Hat Network Monitoring Daemon
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 → → ou para sistemas múltiplos de uma vez através da aba → aba.
- Após registrados, abra a aba → 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 .
- Instale a chave pública SSH em todos os sistemas cliente a serem monitorados, conforme descrito na Seção 1.2.2.3, “Instalando a chave SSH”.
- Inicie o Red Hat Network monitoring daemon em todos os sistemas cliente, usando o comando:
service Red Hat Networkmd start - Ao adicionar probes que requeiram o daemon, aceite os valores default de Red Hat NetworkMD User e Red Hat NetworkMD Port:
nocpulsee4545, respectivamente.
1.2.2.2. Configurando o SSH
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 - 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_keysdo usuário. - Instale a chave pública SSH em todos os sistemas cliente a serem monitorados, conforme descrito na Seção 1.2.2.3, “Instalando a chave SSH”.
- Inicie o
sshdem todos os sistemas cliente, usando o comando:service sshd start - Ao adicionar probes que requeiram o daemon, insira os valores derivados dos passos 2 e 3 nos campos Red Hat NetworkMD User e Red Hat NetworkMD Port.
1.2.2.3. Instalando a chave SSH
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:
- 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 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:
#!/bin/sh cat <<EOF >> ~nocpulse/.ssh/authorized_keys
Então, pressione Enter cole a chave SSH e adicione EOF. O resultado deve ser parecido com o seguinte:#!/bin/sh cat <<EOF>> ~nocpulse/.ssh/authorized_keys ssh-dss AABBAB3NzaC3kc3MABCCBAJ4cmyf5jt/ihdtFbNE1YHsT0np0SYJz7xk hzoKUUWnZmOUqJ7eXoTbGEcZjZLppOZgzAepw1vUHXfa/L9XiXvsV8K5Qmcu70h0 1gohBIder/1I1QbHMCgfDVFPtfV5eedau4AAACAc99dHbWhk/dMPiWXgHxdI0vT2 SnuozIox2klmfbTeO4Ajn/Ecfxqgs5diat/NIaeoItuGUYepXFoVv8DVL3wpp45E 02hjmp4j2MYNpc6Pc3nPOVntu6YBv+whB0VrsVzeqX89u23FFjTLGbfYrmMQflNi j8yynGRePIMFhI= root@satellite.example.com EOF
- Ajuste a data e hora que você quer para a ação acontecer, então clique em .
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.
1.2.3. Configurando o pacote mysql para as probes.
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.
1.2.4. Habilitando Notificações
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.
1.2.4.1. Criando Métodos de Notificação
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 → .
- Indique uma etiqueta intuitiva e descritiva para o nome do método, como
email diário para DBAe 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 . O novo método é apresentado na aba → 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.
1.2.4.2. Recebendo Notificações
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
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.
1.2.4.3. Redirecionando Notificações
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"
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
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.
1.2.4.4. Apagando Métodos de Notificação
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 → e clique no nome do método a ser removido.
- Em → → 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 . 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 → .
- Selecione outro método de notificação e clique em .
- Retorne para a página → e remova o método de notificação.
1.2.5. Sobre as Detecções (Probes)
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).
1.2.5.1. Administrando probes
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 → 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 defaultnocpulsee4545, 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 . 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 → e depois clique em delete probe. Por fim, confirme a remoção.
1.2.5.2. Estabelecendo Limites
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.
1.2.5.3. Monitorando o Servidor do Satellite
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 → 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.
1.2.6. Monitoring
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.
1.2.6.1. Estado de detecção
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)
- Um histórico de eventos de detecção
1.2.6.1.1. Status do Probe ⇒ Critico
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).
1.2.6.1.2. Status do Probe ⇒ Warning
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
As probes que ultrapassaram seus limites WARNING (aviso).
1.2.6.1.3. Status do Probe ⇒Desconhecido
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.
1.2.6.1.4. Status do Probe ⇒ Pendente
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.
1.2.6.1.5. Status do Probe ⇒ OK
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
As probes efetuadas com sucesso, sem nenhum erro. Este é o estado desejado para todas as probes.
1.2.6.1.6. Status do Probe ⇒ Todos
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
Os probes agendados nos sistemas em sua conta, listados em ordem alfabética por nome do sistema.
1.2.6.1.7. Estado Atual
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 (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).
1.2.6.2. Notificação
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.
1.2.6.2.1. Notificação ⇒ Filtros
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.
1.2.6.2.1.1. Notification ⇒ Notification Filters ⇒ Active Filters
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 (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 (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).
1.2.6.2.1.2. Notificatção ⇒ Filtros de Notificação ⇒ Filtros Expirados
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.
1.2.6.3. Conjuntos de Probes
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 (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 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 daemonrhnmdinstalado 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 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 (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 (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 (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.
1.2.6.4. Forçar Agente de Configuração
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
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.
1.2.6.5. Configuração Geral de Monitoramento
Importante
Para visualizar esta aba é necessário possuir direitos de serviços de Monitoring
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 (Atualizar Configuração).
1.3. Satellites múltiplos
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
1.3.1. Inter-Satellite Synchronization (Sincronização entre Satellites)
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.
1.3.1.1. Configuração de manual
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 → → .
- Do canto direito superior, clique em .
- 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 .
- (Opcional) Clique em qualquer empresa local para ser exportado para o Satellite Escravo.
- Clique .
Nota
No Satellite 5.5, o Satellite Mestre usado para o parâmetroiss_slavesno arquivo/etc/rhn/rhn.confpara 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
- Salve o arquivo de configuração, e reinicie o serviço
httpd:service httpd restart
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-SSLdo servidor master. Você pode baixar o certificado por HTTP do diretório/pub/de qualquer satellite. O arquivo é chamadoRed 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 → → .
- Do canto direito superior, clique em .
- 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 .
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
Nota
Opções de linha de comando que são fornecidas manualmente com o comandosatellite-syncirã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 → → . 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 → → .
- 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 .
- Na linha de comando, emita o
satellite-syncem cada canal padronizado para obter a estrutura do trust correta e permissões do canal:satellite-sync -c your-channel
1.3.1.2. Configuração Automatizada
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
- Salve o arquivo de configuração, e reinicie o serviço
httpd:service httpd restart
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-SSLdo servidor master. Você pode baixar o certificado por HTTP do diretório/pub/de qualquer satellite. O arquivo é chamadoRed 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 → → .
- Do canto direito superior, clique em .
- 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 .
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-setupem uma interface de linha de comando:spacewalk-sync-setup --ms=[Master_FQDN] \ --ml=[Master_Sat_Admin_login] \ --mp=[Master_Sat_Admin_password] \ --ss=[Slave FQDN] --sl=[Slave_Sat_Admin_login] \ --sp=[Slave_Sat_Admin_password> \ --create-templates --apply
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
O resultado deste comando será este:INFO: Connecting to [admin@master-fqdn] INFO: Connecting to [admin@slave-fqdn] INFO: Generating master-setup file $HOME/.spacewalk-sync-setup/master.txt INFO: Generating slave-setup file $HOME/.spacewalk-sync-setup/slave.txt INFO: Applying master-setup $HOME/.spacewalk-sync-setup/master.txt INFO: Applying slave-setup $HOME/.spacewalk-sync-setup/slave.txt
- Na linha de comando, emita o
satellite-syncem cada canal padronizado para obter a estrutura do trust correta e permissões do canal:satellite-sync -c your-channel
1.3.2. Sincronização Organizacional
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çãoNULL, mesmo se uma organização destino é especificada. Isto certifica que o conteúdo especificado está sempre na organizaçãoNULLprivilegiada. - 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:
satellite-sync --parent-sat=master.satellite.example.com -c channel-name --orgid=2
Exemplo 1.2. Importar Conteúdo de um Dump Exportado de uma Organização
Este exemplo importa conteúdo de um dump exportado de uma organização específica:
$ satellite-sync -m /dump -c channel-name --orgid=2
Exemplo 1.3. Importar conteúdo do Red Hat Network Hosted
Este exemplo importa conteúdo de um Hosted Red Hat Network (considerando que o sistema está registrado e ativado):
$ satellite-sync -c channel-name
1.3.3. Casos de Uso do Inter-Satellite Synchronization (Sincronização entre Satellites)
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.
- Rode o comando
satellite-syncpara sincronizar os dados com rhn_parent (normalmente Red Hat Network Hosted):satellite-sync -c your-channel
- Rode o seguinte comando para sincronizar os dados de um staging server (servidor em teste):
satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel
Exemplo 1.5. Slaves sincronizados
Neste exemplo, o satellite master fornece dados diretamente aos slaves e mudanças são sincronizadas regularmente.
Exemplo 1.6. Conteúdo Personalizado do Slave
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.
Exemplo 1.7. Sincronia bi-direcional
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.
Capítulo 2. Informações específicas do Solaris e do Red Hat Satellite
Esta é uma seção sobre o uso dos sistemas Red Hat Satellite com Solaris.
2.1. Guia de Suporte ao UNIX
2.1.1. Introdução
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.
2.1.1.1. Variantes do UNIX Suportadas
As seguintes variantes, versões e arquiteturas do UNIX são suportadas pelo Red Hat Satellite :
Tabela 2.1. Versões, Arquiteturas e Solaris Suportados
| Versão Solaris | sun4m | sun4d | sun4u | sun4v | sun4us | x86 |
|---|---|---|---|---|---|---|
| Solaris 8 | yes | no | yes | n/a | no | no |
| Solaris 9 | yes | n/a | yes | n/a | no | yes |
| Solaris 10 | n/a | n/a | yes | yes | no | yes |
2.1.1.2. Pré-requisitos
Estes itens são necessários para obter suporte ao UNIX:
- Red Hat Satellite 5.0 ou posteriores
- Um certificado Satellite com direitos de Administração (management)
- Direitos de Gerenciamento (Management) para cada cliente UNIX
- Os pacotes do Red Hat Network para UNIX, incluindo python, pyOpenSSL e os pacotes Cliente do Red Hat Network.
- Os pacotes Sunfreeware adicionais que trazem bibliotecas de suporte.
Nota
Alguns destes pacotes são distribuídos através do Red Hat Satellite . Consulte a Seção 2.1.3.1, “Baixando e Instalando os Pacotes Adicionais.” para ver a lista completa.
2.1.1.3. Funcionalidades Inclusas
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 oRed 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
2.1.1.4. Diferenças nas Funcionalidades
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 Networkpushpara 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 doRed 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.
2.1.1.5. Funcionalidades Excluídas
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.
2.1.2. Preparação/Configuração do Servidor Satellite
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 (Satellite Tools) no menu superior e então selecione (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 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-syncpara 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.
2.1.3. Preparação de Sistema Cliente Unix
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
gzipe 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.
2.1.3.1. Baixando e Instalando os Pacotes Adicionais.
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.
2.1.3.1.1. Instale Pacotes de Terceiros
Instalação dos aplicativos Red Hat Network não pode continuar a não ser que o seguinte utilitário e bibliotecas estejam presentes:
gziplibgccopensslzlib
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:
SUNWgccruntimeSUNWopenssl*SUNWzlib
Para versões mais antigas do Solaris, os pacotes a seguir poderão ser baixados a partir do site http://www.sunfreeware.com:
SMClibgccouSMCgccSMCosslSMCzlib
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
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.
2.1.3.1.2. Configurando o Caminho de Busca de Biblioteca
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
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.
Em sparc:
# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib
Em x86:
# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib:/usr/sfw/lib
2.1.3.1.3. Baixando os Pacotes Cliente Red Hat Network
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
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:
RHATposslRHATrhnrcfgRHATrhnrcfgaRHATrhnrcfgcRHATrhnrcfgmRHATRed Hat NetworkcRHATRed Hat NetworklRHATrpushRHATsmart
SMClibgcc e SMCosslg também podem estar inclusos no tarball.
2.1.3.1.4. Instalando os Pacotes do Red Hat Network
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 ...
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/.
2.1.3.1.5. Incluindo os Pacotes do Red Hat Network no PATH
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:
# PATH=$PATH:/opt/redhat/rhn/solaris/bin # PATH=$PATH:/opt/redhat/rhn/solaris/usr/bin # PATH=$PATH:/opt/redhat/rhn/solaris/usr/sbin # export PATH
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:
# MANPATH=$MANPATH:/opt/redhat/rhn/solaris/man # export MANPATH
Como forma alternativa, você também pode acessar as páginas man a partir da linha de comando, com o seguinte comando:
# man -M /opt/redhat/rhn/solaris/man <man page>
Por último, adicione as Bibliotecas da Red Hat ao seu PATH, assim como você fez com
libgcc, openssl ezlib.
crle -c /var/ld/ld.config -l <current library paths>:/opt/redhat/Red Hat Network/solaris/lib
2.1.3.2. Implementando os Certificados SSL Cliente
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 aoRHN-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/
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.
2.1.3.3. Configurando clientes
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
up2dateem um editor de texto. - Encontre a entrada
serverURLe 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
- Assegure-se de que os aplicativos se referem ao Red Hat Satellite até quando o SSL estiver desligado, configurando também o valor
noSSLServerURLpara o Satellite:noSSLServerURL[comment]=Remote server URL without SSL noSSLServerURL=http://your-satellite.example.com/XMLRPC
- Com o arquivo de configuração
up2dateainda aberto, encontre a entradasslCACerte ajuste seu valor para o nome e local do certificado SSL descrito na Seção 2.1.3.2, “Implementando os Certificados SSL Cliente ”, por exemplo: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
Seus sistemas cliente estão agora prontos para registro com o Red Hat Network e gerenciamento pelo seu Satellite.
2.1.4. Registro e Atualizações de Clientes da Unix
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.
2.1.4.1. Registrando Sistemas Unix
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.
- Na página seguinte, selecione o canal base que você criou no final da Seção 2.1.2, “Preparação/Configuração do Servidor Satellite”.
- 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_kscom a opção--activationkeypara registrar o cliente com o Satellite. A seqüência de caracteres representando a chave pode ser copiada diretamente da lista Chaves de Ativação no website. O comando será parecido com o seguinte:rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af
- Retorne ao site, clique no nome da chave de ativação e verifique se o sistema novo aparece na aba Activated Systems.
2.1.4.2. Obtendo Atualizações
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.
2.1.4.2.1. Carregando Pacotes no Satellite
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.
2.1.4.2.1.1. solaris2mpm
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
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
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:
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.
|
2.1.4.2.1.2. rhnpush com arquivos .mpm
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
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.
2.1.4.2.2. Atualizando Através do Site
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 (Instalar/Atualizar Pacotes Selecionados).
Para rodar um comando remoto enquanto instalar o pacote, clique em ao invés de . 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 (Instalar/Atualizar Pacotes). Para completar a ação, agende as atualizações.
2.1.4.2.3. rhnsd
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 rhnsd não inicia durante a inicialização do sistema e pode ser iniciado na linha de comandos da seguinte maneira:
rhnsd --foreground --interval=240
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:
Tabela 2.3. Opções do rhnsd
| Opção | Descrição |
|---|---|
-f, --foreground
|
Executa em primeiro plano
|
-i, --interval=MINS
|
Conecta no Red Hat Network a cada MINS minutos
|
-v, --verbose
|
Registra todas as ações no syslog
|
-h, --help
|
Exibe esta lista de ajuda
|
-u, --usage
|
Exibe esta lista de ajuda
|
-V, --version
|
Exibe a versão do programa
|
2.1.4.2.4. Atualizando pela Linha de Comando
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:
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. |
2.1.5. Comandos Remotos
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.
2.1.5.1. Habilitando Comandos
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
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 2.1.5.2. Invocando Comandos
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 (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 (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 (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.
Capítulo 3. Informações sobre o Red Hat Satellite Proxy
Esta é uma seção sobre o uso do Red Hat Satellite Proxy com o Gerenciador do Pacote do Red Hat Network.
3.1. Utilizando o Red Hat Network Package Manager e Servindo Pacotes Locais através do Red Hat Network Proxy
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:
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.
3.1.1. Criando um Canal Privado.
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 (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.
- Clique em .
3.1.2. Upload de Pacotes
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
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
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"
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.
Capítulo 4. Administração de Pacotes Personalizados
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.
4.1. Construindo Pacotes para o Red Hat Network
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.
4.1.1. Benefícios do RPM
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.
4.1.2. Red Hat Network RPM Guidelines
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
--forceou--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/nullse 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.
4.2. Assinaturas Digitais para os pacotes do Red Hat Network
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.
4.2.1. Gerando um Par de Chaves GnuPG
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-keyO 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?
- Escolha a opção: (2) DSA and ElGamal. Esta permite criar uma assinatura digital e criptografar/descriptografar com dois tipos de tecnologias. Digite
2e 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)?
- 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. +++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++ +++. ++++++++++++++++++++++++++++++++++++++..........................++++
Quando a atividade das telas terminar, suas chaves novas são colocadas no diretório.gnupgdentro 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
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]
Para obter sua chave pública, use o seguinte comando:
gpg --export -a 'Your Name' > public_key.txt
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.
4.2.2. Assinando pacotes
Antes de poder assinar os pacotes, é necessário configurar seu arquivo
~/.rpmmacros incluindo o seguinte:
%_signature gpg %_gpg_name B7085C8A
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
Indique sua senha. Para garantir que seu pacote seja assinado, use o seguinte comando:
rpm --checksig -v package-name-1.0-1.noarch.rpm
Nota
Antes de executar o comando
rpm --checksig -v importe a chave gpg. Veja Seção 4.3, “Importando Chaves Padronizadas GPG” na próxima seção para obter mais informações.
Você deve ver a frase Good signature from "Seu Nome" no resultado, sendo Seu Nome substituído pelo nome associado à chave que assina.
4.3. Importando Chaves Padronizadas GPG
Para os clientes que planejam construir e distribuir seus próprios RPMs de forma segura, recomenda-se que todos os RPMs padronizados 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/
A chave pode então ser baixada pelos sistemas de cliente, usando Wget:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
A opção
-O- envia resultados para saídas padrão, enquanto a opção -q configura o Wget para rodar em modo silencioso. Lembre-se de substituir a variante YOUR-RPM-GPG-KEY pelo nome do arquivo de sua Chave.
Quando a chave estiver disponível no sistema de arquivo do cliente, importe-a para o chaveiro do GPG local. Sistemas operacionais diferentes requerem métodos diferentes.
Para o Red Hat Enterprise Linux 3 ou versões anteriores, use o seguinte comando:
rpm --import /path/to/YOUR-RPM-GPG-KEY
Quando a chave GPG tiver sido adicionada ao cliente com êxito, o sistema deve ser capaz de validar RPMs padronizados assinados com a chave correspondente.
Nota
Ao utilizar os RPMs padronizados e canais, sempre crie uma chave GPG padronizada para estes pacotes. O local da chave GPG também precisa ser adicionado ao perfil do Kickstart.
A chave GPG padronizada precisa ser adicionada aos sistemas clientes ou a instalação do Kicskstart pode falhar.
Capítulo 5. Solução de problemas
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.
- 5.1. Espaço em Disco
- 5.2. Instalação e Atualização
- 5.3. Serviços
- 5.4. Conectividade
- 5.5. Autenticando e Reportando
- P: Quais são os diferentes arquivos de log?
- P: Como uso o spacewalk-report?
- P: Como descubro qual versão do esquema de banco de dados tenho?
- P: Como descubro quais tipos de conjuntos de caracteres eu tenho?
- P: Porque o administrador não está recebendo um email?
- P: Como eu mudo o enviador do mail traceback?
- 5.6. Erros
- P: Estou recebendo um erro "Error validating satellite certificate" durante a instalação do Red Hat Satellite. Como eu conserto isso?
- 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?
- P: Porque o cobbler check dá um erro dizendo que precisa de uma versão diferente do cobbler check
- P: Estou recebendo um erro "unsupported version" quando eu tento ativar o certificado Red Hat Satellite. Como conserto isso?
- P: Estou recebendo "Internal Server Error" sobre o ASCII quando eu tento editar o perfil de kickstart. O que está acontecendo?
- P: Estou recebendo erros "Host Not Found" ou "Could Not Determine FQDN". O que eu faço agora?
- P: Estou recebendo "This server is not an entitled Satellite" quando eu tento sincronizar o servidor Red Hat Satellite. Como eu conserto isso?
- 5.7. Interface web
- 5.8. Anaconda
- 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?
- 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?
- 5.9. Tracebacks
- 5.10. Registro
- 5.11. Kickstarts e Snippets
- 5.12. Monitoring
- 5.13. Satellites de Multi-Organização e Certificado Satellite
- 5.14. Configuração e Instalação do Proxy
- 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 ?
- P: Como posso saber se os clientes estão conectando 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?
- P: A configuração do meu Red Hat Network Satellite Proxy não funciona. Por onde devo começar a resolver esta questão?
- P: Como eu resolvo problemas gerais no Red Hat Satellite Proxy?
- 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?
- P: Estou tendo problemas com o Red Hat Satellite Proxy e erros de conexão de rede. O que devo fazer?
- P: Estou tendo problemas com os erros de entrega do pacote e danos de objeto. O que devo procurar?
5.1. Espaço em Disco
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
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
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
5.2. Instalação e Atualização
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
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
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.
5.3. Serviços
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
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
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
5.4. Conectividade
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
- 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.
- Confirme o pacote correto:
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpmestá instalado no Red Hat Satellite e se orhn-org-trusted-ssl-cert-*.noarch.rpmou 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
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
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:
# openssl x509 -dates -noout -in /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
Verifique as datas e horas do certificado do servidor do Satellite com o seguinte comando:
# openssl x509 -dates -noout -in /etc/httpd/conf/ssl.crt/server.crt
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.
5.5. Autenticando e Reportando
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.
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
Os seguintes relatórios estão disponíveis:
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
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
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.
5.6. Erros
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
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
- Abra
/etc/rhn/rhn.confcom seu editor de textos preferido, e adicione ou modifique a seguinte linha:server.satellite.rhn_parent = satellite.rhn.redhat.com
Remova a seguinte linha:disconnected=1
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.server.satellite.http_proxy = <hostname>:<port> server.satellite.http_proxy_username = <username> server.satellite.http_proxy_password = <password>
- Reative o Satellite no modo conectado, usando o comando
rhn-satellite-activatecomo usuário root, incluindo o caminho e o nome de arquivo do certificado satellite:# rhn-satellite-activate --rhn-cert=/path/to/file.cert
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:
rhn-http-proxy = <hostname>:<port> rhn-http-proxy-username = <username> rhn-http-proxy-password = <password>
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
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:
ERROR: <Fault -2: 'unhandled internal exception: unsupported version: 96'>
RHN_PARENT: satellite.rhn.redhat.com
Error reported from RHN: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
ERROR: unhandled XMLRPC fault upon remote activation: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
ERROR: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
Invalid satellite certificate
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'
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
- Encontre o perfil de kickstart que está causando o problema olhando nas datas dos aquivos no
/var/lib/cobbler/config/profiles.de localizando o arquivo que foi editado mais recentemente:# ls -l /var/lib/cobbler/config/profiles.d/
- Abra o perfil no seu editor de texto preferido, e localize o seguinte texto:
\u2013hostname
Mude para:--hostname
- 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.
- 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:
127.0.0.1 this_machine.example.com this_machine localhost.localdomain \ localhost
Primeiro, remova as informações da máquina violadora num editor de texto, como:
127.0.0.1 localhost.localdomain.com localhost
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:
127.0.0.1 localhost.localdomain.com localhost 123.45.67.8 this_machine.example.com this_machine
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
Ative o mesmo certificado Satellite novamente no seu Satellite, usando este comando como usuário root:
# rhn-satellite-activate -vvv --rhn-cert=/path/to/certificate
5.7. Interface web
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.
5.8. Anaconda
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
Se o
cobbler check não fornecer uma resposta, cheque o seguinte:
- Verifique se
httpdestá sendo executado:service httpd status - Verifique se o
cobblerdestá sendo executado:service cobblerd status - Verifique se você pode pegar o arquivo de kickstart usando
wgetde um host diferente:wget http://satellite.example.com/cblr/svc/op/ks/profile/rhel5-i386-u3:1:Example-Org
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:
url --url http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
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:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3 --2011-08-19 15:06:55-- http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3 Resolving satellite.example.com... 10.10.77.131 Connecting to satellite.example.com|10.10.77.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 0 [text/plain] Saving to: `ks-rhel-i386-server-5-u3.1' 2011-08-19 15:06:55 (0.00 B/s) - `ks-rhel-i386-server-5-u3.1' saved [0/0]
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:
# grep chkconfig /var/log/httpd/access_log 10.10.77.131 - - [19/Aug/2011:15:12:36 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 5-u3/Server /chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19" 10.10.76.143 - - [19/Aug/2011:15:12:36 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig- 1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19" 10.10.76.143 - - [19/Aug/2011:15:14:20 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig- 1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19" 10.10.77.131 - - [19/Aug/2011:15:14:20 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
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:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm
5.9. Tracebacks
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
Isso indica que houve um problema do Cobbler comunicando com o serviço
taskomatic. Tente checar o seguinte:
- Verifique se
httpdestá sendo executado:# service httpd status - Verifique se
cobblerestá sendo executado:# service cobbler status - Verifique que não há regras de firewall que preveniriam conexões
localhost
5.10. Registro
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
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.
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.
5.11. Kickstarts e Snippets
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
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.
Snippets: /var/lib/rhn/kickstarts/snippets/$org_id/$snippet_name
Importante
Os RPMs do Red Hat Satelliter supõem que os diretórios kickstart e snippet Cobbler estejam em seus locais padrões, não os mude.
5.12. Monitoring
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
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
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
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
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:
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
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:
rhn-runprobe 5 --log=all=4 --sshuser=nocpulse --sshport=4545
Isto trará um output detalhado descrevendo a tentativa de execução da detecção. Os erros são claramente identificados.
5.13. Satellites de Multi-Organização e Certificado Satellite
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.confdefinaweb.force_unentitlementpara 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.
5.14. Configuração e Instalação do Proxy
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
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
Para obter o estado do Squid, rode o comando:
service squid status
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:
127.0.0.1 this_machine.example.com this_machine localhost.localdomain \ localhost
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
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:
127.0.0.1 localhost.localdomain.com localhost 123.45.67.8 this_machine.example.com this_machine
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:
- Confirme o pacote correto:
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpmestá instalado no Red Hat Satellite Proxy e se orhn-org-trusted-ssl-cert-*.noarch.rpmou 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
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/* 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.
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:
[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.
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.
Apêndice A. Probes (detecções)
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.
A.1. Diretrizes das Probes
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.
A.2. Apache 1.3.x e 2.0.x
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.
A.2.1. Apache::Processos
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.confusando a configuraçãoMaxRequestsPerChild.
A diretiva
ExtendedStatus do arquivo httpd.conf do servidor Web deve ser definida como On para esta probe funcionar apropriadamente.
Tabela A.1. Configuração da Apache::Processes
| Campo | Valor |
|---|---|
| Protocolo da Aplicação* | http |
| Porta* | 80 |
| Nome de Caminho* | /server-status |
| Agente do Usuário* | NOCpulse-ApacheUptime/1.0 |
| Nome do Usuário | |
| Senha | |
| Tempo Limite* | 15 |
| Megabytes Máximos Críticos Transferidos Por Filho | |
| Megabytes do Aviso Máximos Transferidos Por Filho | |
| Megabytes Máximos Críticos Transferidos Por Slot | |
| Megabytes Máximos do Aviso Transferidos Por Slot |
A.2.2. Apache::Traffic
A probe Apache::Probe do Traffic monitora as requisições em um Servidor da Web Apache e coleta as seguintes medidas:
- Pedidos Correntes - O número de pedidos sendo processados pelo servidor no momento da execução da probe.
- Taxa de Pedidos - Os acessos ao servidor por segundo desde a última vez que a probe foi executada.
- Tráfego - Os kilobytes de tráfego que o servidor processou por segundo desde a última vez que a probe foi executada.
A diretiva
ExtendedStatus do arquivo httpd.conf do servidor Web deve ser definida como On para esta probe funcionar apropriadamente.
Tabela A.2. Configuração da Apache::Traffic
| Campo | Valor |
|---|---|
| Protocolo da Aplicação* | http |
| Porta* | 80 |
| Nome de Caminho* | /server-status |
| Agente do Usuário* | NOCpulse-ApacheUptime/1.0 |
| Nome do Usuário | |
| Senha | |
| Tempo Limite* | 15 |
| Máximo de Pedidos Correntes Críticos (número) | |
| Máximo de Pedidos Correntes do Aviso (número) | |
| Taxa Máxima Crítica de Pedidos (eventos por segundo) | |
| Taxa Máxima de Pedidos do Aviso (eventos por segundo) | |
| Tráfego Máximo Crítico (kilobytes por segundo) | |
| Tráfego Máximo do Aviso (kilobytes por segundo) |
A.2.3. Apache::Uptime
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).
Tabela A.3. Configuração da Apache::Uptime
| Campo | Valor |
|---|---|
| Protocolo da Aplicação* | http |
| Porta* | 80 |
| Nome de Caminho* | /server-status |
| Agente do Usuário* | NOCpulse-ApacheUptime/1.0 |
| Nome do Usuário | |
| Senha | |
| Tempo Limite* | 15 |
A.3. BEA WebLogic 6.x e mais recente
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.
A.3.1. BEA WebLogic::Execute Queue
A probe BEA WebLogic::Execute Queue monitora a fila de execução do WebLogic e oferece os seguintes resultados:
- Segmentos de Execução Ociosos (Idle Execute Threads) - o número de threads de execução num estado ocioso.
- Comprimento da Fila (Queue Length) - O número de pedidos na fila.
- Taxa de Pedidos (Request Rate) - O número de pedidos por segundo.
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Tabela A.4. Configuração da BEA WebLogic::Execute Queue
| Campo | Valor |
|---|---|
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Queue Name* | padrão |
| Máximo de Threads de Execução Ociosas Crítico | |
| Máximo de Threads de Execução Ociosas do Aviso | |
| Comprimento Crítico Máximo da Fila | |
| Comprimento Máximo da Fila do Aviso | |
| Taxa Máxima de Pedidos Críticos | |
| Taxa Máxima de Pedidos do Aviso |
A.3.2. BEA WebLogic::Heap Free
A probe BEA WebLogic::Heap Free coleta os seguintes resultados:
- Heap Free - A porcentagem de espaço de pilha livre.
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Tabela A.5. Configuração da BEA WebLogic::Heap Free
| Campo | Valor |
|---|---|
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Heap Livre Máxima Crítica | |
| Heap Livre Máxima do Aviso | |
| Heap Livre Mínima do Aviso | |
| Heap Livre Mínima Crítica |
A.3.3. BEA WebLogic::JDBC Connection Pool
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).
Tabela A.6. Configuração da BEA WebLogic::JDBC Connection Pool
| Campo | Valor |
|---|---|
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Nome do Conjunto JDBC* | Conjunto de Conexões MyJDBC |
| Conexões Máximas Críticas | |
| Conexões Máximas do Aviso | |
| Taxa Máxima de Conexões Críticas | |
| Taxa Máxima de Conexões do Aviso | |
| Waiters Máximo Crítico | |
| Waiters Máximo do Aviso |
A.3.4. BEA WebLogic::Server State
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).
Tabela A.7. Configuração da BEA WebLogic::Server State
| Campo | Valor |
|---|---|
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* |
A.3.5. BEA WebLogic::Servlet
A probe BEA WebLogic::Servlet monitora o desempenho de um determinado servlet implementado num servidor WebLogic e coleta os seguintes resultados:
- Tempo de Alta Execução (High Execution Time) - O maior tempo, em milissegundos, que o servlet leva para executar desde que o sistema foi iniciado.
- Tempo de Baixa Execução (Low Execution Time) - O menor tempo, em milissegundos, que o servlet leva para executar desde que o sistema foi iniciado.
- Média de Moção do Tempo de Execução (Execution Time Moving Average) - Uma média de movimento do tempo de execução.
- Média do Tempo de Execução (Execution Time Average) - Uma média padrão do tempo de execução.
- Taxa de Recarregamento (Reload Rate) - O número de vezes que o servlet específico é recarregado por minuto.
- Taxa de Invocação (Invocation Rate) - O número de vezes que o servlet específico é invocado por minuto.
O protocolo de transporte desta probe é o User Datagram Protocol (UDP).
Tabela A.8. Configuração da BEA WebLogic::Servlet
| Campo | Valor |
|---|---|
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Nome do Servlet* | |
| Tempo Máximo de Alta Execução Crítica | |
| Tempo Máximo de Alta Execução do Aviso | |
| Média Máxima Crítica da Moção do Tempo de Execução | |
| Média Máxima da Moção do Tempo de Execução do Aviso |
A.4. Geral
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.
A.4.1. General::Remote Program (Geral::Programa Remoto)
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.
Tabela A.9. Configuração da General::Remote Program
| Campo | Valor |
|---|---|
| Comando* | |
| Estado de Saída OK* | 0 |
| Estado de Saída do Aviso* | 1 |
| Estado de Saída Crítico* | 2 |
| Tempo limite (timeout) | 15 |
A.4.2. General::Remote Program with Data (Geral::Programa Remoto com Dados)
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:
<perldata> <hash> <item key="data">10</item> <item key="status_message">status message here</item> </hash> </perldata>
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.
Tabela A.10. Configuração da General::Remote Program with Data
| Campo | Valor |
|---|---|
| Comando* | |
| Estado de Saída OK* | 0 |
| Estado de Saída do Aviso* | 1 |
| Estado de Saída Crítico* | 2 |
| Tempo limite (timeout) | 15 |
A.4.3. General::SNMP Check
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).
Tabela A.11. Configuração da General::SNMP Check
| Campo | Valor |
|---|---|
| OID do SNMP* | |
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 2 |
| Tempo Limite* | 15 |
| Valor Máximo Crítico | |
| Valor Máximo do Aviso | |
| Valor Mínimo do Aviso | |
| Valor Mínimo Crítico |
A.4.4. General::TCP Check
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).
Tabela A.12. Configuração da General::TCP Check
| Campo | Valor |
|---|---|
| Enviar | |
| Esperar | |
| Porta* | 1 |
| Tempo Limite* | 10 |
| Latência Máxima Crítica | |
| Latência Máxima de Aviso |
A.4.5. General::UDP Check
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).
Tabela A.13. Configuração da General::UDP Check
| Campo | Valor |
|---|---|
| Porta* | 1 |
| Enviar | |
| Esperar | |
| Tempo Limite* | 10 |
| Latência Máxima Crítica | |
| Latência Máxima de Aviso |
A.4.6. General::Uptime (SNMP)
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).
Tabela A.14. Configuração da General::Uptime (SNMP)
| Campo | Valor |
|---|---|
| String Community do SNMP* | public |
| SNMP Port* | 161 |
| SNMP Version* | 2 |
| Tempo Limite* | 15 |
A.5. Linux
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.
A.5.1. Linux::CPU Usage (Linux::Utilização do CPU)
A probe Linux::CPU Usage monitora a utilização da CPU de um sistema e coleta o seguinte resultado:
- Porcentagem Usada da CPU (CPU Percent Used) - A média de cinco segundos da porcentagem de uso da CPU na execução da probe.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.15. Configuração da Linux::CPU Usage
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Máxima Porcentagem Crítica Usada da CPU | |
| Máxima Porcentagem de Aviso de Uso da CPU |
A.5.2. Linux::Disk IO Throughput (Linux::Produção de E/S do Disco )
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).
Tabela A.16. Configuração da Linux::Disk IO Throughput
| Campo | Valor |
|---|---|
| Número ou Nome do Disco* | 0 |
| Tempo Limite* | 15 |
| Máximo Crítico de KB acessados/segundo | |
| Máximo de Aviso de KB acessados/segundo | |
| Mínimo de Aviso de KB acessados/segundo | |
| Mínimo Crítico de KB acessados/segundo | |
| Máximo Crítico de KB gravados/segundo | |
| Máximo de Aviso de KB gravados/segundo | |
| Mínimo de Aviso de KB gravados/segundo | |
| Mínimo Crítico de KB gravados/segundo |
A.5.3. Linux::Disk Usage (Linux::Uso do Disco )
A probe Linux::Disk Usage monitora o espaço em disco num sistema de arquivo específico e coleta os seguintes resultados:
- Sistema de Arquivo Usado (File System Used) - A porcentagem do sistema de arquivo em uso corrente.
- Espaço Usado (Space Used) - A porção do sistema de arquivo em uso corrente, em megabytes.
- Espaço Disponível (Space Available) - A porção disponível corrente do sistema de arquivo, em megabytes.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.17. Configuração da Linux::Disk Usage
| Campo | Valor |
|---|---|
| Sistema de Arquivo* | /dev/hda1 |
| Tempo Limite* | 15 |
| Porcentagem Máxima Crítica de Uso do Sistema de Arquivo | |
| Porcentagem Máxima de Aviso de Uso do Sistema de Arquivo | |
| Espaço Máximo Crítico Usado | |
| Espaço Máximo de Aviso Usado | |
| Espaço Mínimo Disponível de Aviso | |
| Espaço Mínimo Disponível Crítico |
A.5.4. Linux::Inodes
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.
Tabela A.18. Configuração da Linux::Inodes
| Campo | Valor |
|---|---|
| Sistema de Arquivo* | / |
| Tempo Limite* | 15 |
| Porcentagem Máxima Crítica de Inodes Usados | |
| Porcentagem Máxima de Aviso de Inodes Usados |
A.5.5. Linux::Interface Traffic (Linux::Tráfego da Interface)
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.
Tabela A.19. Configuração da Linux::Interface Traffic
| Campo | Valor |
|---|---|
| Interface* | |
| Tempo Limite* | 30 |
| Taxa Máxima Crítica de Input | |
| Taxa Máxima de Aviso de Input | |
| Taxa Mínima de Aviso de Input | |
| Taxa Mínima Crítica de Input | |
| Taxa Máxima Crítica de Output | |
| Taxa Máxima de Aviso de Output | |
| Taxa Mínima de Aviso de Output | |
| Taxa Mínima Crítica de Output |
A.5.6. Linux:Load (Linux::Carga)
A probe Linux::Load monitora a CPU de um sistema e coleta o seguinte resultado:
- Carga (Load) - A carga média na CPU do sistema ao longo de vários períodos.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.20. Configuração da Linux::Load
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Média Crítica de 1 minuto de Carga da CPU | |
| Média de Aviso de 1 minuto de Carga da CPU | |
| Média Crítica de 5 minutos de Carga da CPU | |
| Média de Aviso de 5 minutos de Carga da CPU | |
| Média Crítica de 15 minutos de Carga da CPU | |
| Média de Aviso de 15 minutos de Carga da CPU |
A.5.7. Linux::Memory Usage (Linux::Uso da Memória)
A probe Linux::Memory Usage monitora a memória de um sistema e coleta o seguinte resultado:
- RAM Disponível (RAM Free) - A quantidade de memória de acesso randômico (random access memory, RAM) disponível num sistema, em megabytes.
Você também pode incluir a memória recuperável neste resultado indicando
yes ou no no campo Include reclaimable memory.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.21. Configuração da Linux::Memory Usage
| Campo | Valor |
|---|---|
| Incluir memória recuperável | no |
| Tempo Limite* | 15 |
| Máximo do Aviso de RAM Disponível | |
| Máximo Crítico de RAM Disponível |
A.5.8. Linux::Process Counts by State (Linux::Contagem de Processos por Estado)
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 chamadawait()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 (
Interruptiblesleep), 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.
Tabela A.22. Configuração da Linux::Process Counts by State
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Máximo Crítico de Processos Bloqueados | |
| Máximo de Aviso dos Processos Bloqueados | |
| Máximo Crítico de Processos Extintos | |
| Máximo de Aviso de Processos Extintos | |
| Máximo Crítico de Processos Parados | |
| Máximo de Aviso de Processos Parados | |
| Máximo Crítico de Processos Dormentes | |
| Máximo de Aviso de Processos Dormentes | |
| Máximo Crítico de Processos Filho | |
| Máximo de Aviso de Processos Filho |
A.5.9. Linux::Process Count Total (Linux::Contagem Total de Processos)
A probe Linux::Process Count Total monitora um sistema e coleta o seguinte resultado:
- Contagem de Processos (Process Count) - O número total de processos correntes rodando no sistema.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.23. Configuração da Linux::Process Count Total
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Contagem Máxima Crítica de Processos | |
| Contagem Máxima de Aviso dos Processos |
A.5.10. Linux::Process Health (Linux::Saúde dos Processos)
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.
Tabela A.24. Configuração da Linux::Process Health
| Campo | Valor |
|---|---|
| Nome do Comando | |
| Arquivo do ID do processo (PID) | |
| Tempo Limite* | 15 |
| Uso Máximo Crítico da CPU | |
| Uso Máximo de Aviso da CPU | |
| Máximo Crítico de Grupos de Processos Filho | |
| Máximo de Aviso de Grupos de Processos Filho | |
| Máximo Crítico de Threads | |
| Máximo de Aviso de Threads | |
| Máximo Crítico de Memória Física Usada | |
| Máximo de Aviso de Memória Física Usada | |
| Máximo Crítico de Memória Virtual Usada | |
| Máximo de Aviso de Memória Virtual Usada |
A.5.11. Linux::Process Running (Linux::Processo em Andamento)
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.
Tabela A.25. Configuração da Linux::Process Running
| Campo | Valor |
|---|---|
| Nome do Comando | |
| Arquivo PID | |
| Conta grupos de processos | (verificados) |
| Tempo Limite* | 15 |
| Número Máximo Crítico Rodando | |
| Número Mínimo Crítico Rodando |
A.5.12. Linux::Swap Usage (Linux::Uso de Swap)
A probe Linux::Swap Usage monitora as partições swap rodando num sistema e reporta o seguinte resultado:
- Swap Disponível (Swap Free) - A porcentagem disponível da memória swap corrente.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.26. Configuração da Linux::Swap Usage
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Máximo do Aviso de Swap Disponível | |
| Máximo Crítico de Swap Disponível |
A.5.13. Linux::TCP Connections by State (Linux::Conexões TCP por Estado)
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.
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 | |
| Filtro do número da porta remota | |
| Tempo Limite* | 15 |
| Máximo Crítico Total de Conexões | |
| Máximo de Aviso Total de Conexões | |
| Máximo Crítico de Conexões TIME_WAIT | |
| Máximo de Aviso de Conexões TIME_WAIT | |
| Máximo Crítico de Conexões CLOSE_WAIT | |
| Máximo de Aviso de Conexões CLOSE_WAIT | |
| Máximo Crítico de Conexões FIN_WAIT | |
| Máximo de Aviso de Conexões FIN_WAIT | |
| Máximo Crítico de Conexões ESTABLISHED | |
| Máximo de Aviso de Conexões ESTABLISHED | |
| Máximo Crítico de Conexões SYN_RCVD | |
| Máximo de Aviso de Conexões SYN_RCVD |
A.5.14. Linux::Users (Linux::Usuários)
A probe Linux::Users monitora os usuários de um sistema e reporta o seguinte resultado:
- Usuários - O número de usuários correntes autenticados.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.28. Configuração da Linux::Users
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Máximo Crítico de Usuários | |
| Máximo de Aviso de Usuários |
A.5.15. Linux::Virtual Memory (Linux::Memória Virtual)
A probe Linux::Virtual Memory monitora a memória total do sistema e coleta o seguinte resultado:
- Memória Virtual (Virtual Memory) - A porcentagem da memória total do sistema - memória de acesso randômico (RAM) mais swap - que está livre.
Requisitos - O daemon de monitoramento do Red Hat Network (
rhnmd) deve estar rodando no sistema monitorado para efetuar esta probe.
Tabela A.29. Configuração da Linux::Virtual Memory
| Campo | Valor |
|---|---|
| Tempo Limite* | 15 |
| Mínimo de Aviso de Memória Virtual Livre | |
| Mínimo Crítico de Memória Virtual Livre |
A.6. LogAgent
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.
A.6.1. LogAgent::Log Pattern Match (LogAgent::Correspondência de Padrões em Registros)
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)+
Atenção
Não inclua aspas simples (') na expressão. Fazer isso causa a falha silenciosa do
egrep e o tempo limite da probe.
Tabela A.30. Configuração da LogAgent::Log Pattern Match
| Campo | Valor |
|---|---|
| Arquivo de registro* | /var/log/messages |
| Expressão regular básica* | |
| Tempo Limite* | 45 |
| Máximo Crítico de Ocorrências | |
| Máximo de Aviso de Ocorrências | |
| Mínimo de Aviso de Ocorrências | |
| Mínimo Crítico de Ocorrências | |
| Taxa Máxima Crítica de Ocorrências | |
| Taxa Máxima de Aviso de Ocorrências | |
| Taxa Mínima de Aviso de Ocorrências | |
| Taxa Máxima Crítica de Ocorrências |
A.6.2. LogAgent::Log Size (LogAgent::Tamanho do Registro)
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.
Tabela A.31. Configuração da LogAgent::Log Size
| Campo | Valor |
|---|---|
| Arquivo de registro* | /var/log/messages |
| Tempo Limite* | 20 |
| Tamanho Máximo Crítico | |
| Tamanho Máximo de Aviso | |
| Tamanho Mínimo de Aviso | |
| Tamanho Mínimo Crítico | |
| Taxa Máxima Crítica de Output | |
| Taxa Máxima de Aviso de Output | |
| Taxa Mínima de Aviso de Output | |
| Taxa Mínima Crítica de Output | |
| Máximo Crítico de Linhas | |
| Máximo de Aviso de Linhas | |
| Mínimo de Aviso de Linhas | |
| Mínimo Crítico de Linhas | |
| Taxa Máxima Crítica de Linhas | |
| Taxa Máxima de Aviso de Linhas | |
| Taxa Mínima de Aviso de Linhas | |
| Taxa Mínima Crítica de Linhas |
A.7. MySQL 3.23 - 3.33
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.
A.7.1. MySQL::Database Accessibility
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).
Tabela A.32. Configuração da MySQL::Database Accessibility
| Campo | Valor |
|---|---|
| Nome de usuário* | |
| Senha | |
| Porta MySQL | 3306 |
| Banco de dados* | mysql |
| Tempo limite (timeout) | 15 |
A.7.2. MySQL::Opened Tables
A probe MySQL::Opened Tables monitora o servidor MySQL e coleta o seguinte resultado:
- Tabelas Abertas (Opened Tables) - As tabelas que foram abertas desde a inicialização do servidor.
Tabela A.33. Configuração da MySQL::Opened Tables
| Campo | Valor |
|---|---|
| Nome do Usuário | |
| Senha | |
| Porta MySQL* | 3306 |
| Tempo limite (timeout) | 15 |
| Máximo Crítico de Objetos Abertos | |
| Máximo de Aviso de Objetos Abertos | |
| Mínimo de Aviso de Objetos Abertos | |
| Mínimo Crítico de Objetos Abertos |
A.7.3. MySQL::Open Tables
A probe MySQL::Open Tables monitora o servidor MySQL e coleta o seguinte resultado:
- Abrir Tabelas (Open Tables) - O número de tabelas abertas quando a probe é executada.
Tabela A.34. Configuração da MySQL::Open Tables
| Campo | Valor |
|---|---|
| Nome do Usuário | |
| Senha | |
| Porta MySQL* | 3306 |
| Tempo limite (timeout) | 15 |
| Máximo Crítico de Objetos Abertos | |
| Máximo de Aviso de Objetos Abertos | |
| Mínimo de Aviso de Objetos Abertos | |
| Mínimo Crítico de Objetos Abertos |
A.7.4. MySQL::Query Rate
A probe MySQL::Query Rate monitora o servidor MySQL e coleta o seguinte resultado:
- Taxa de Pedidos (Query Rate) - O número médio de pedidos por servidor do banco de dados.
Tabela A.35. Configuração da MySQL::Query Rate
| Campo | Valor |
|---|---|
| Nome do Usuário | |
| Senha | |
| Porta MySQL* | 3306 |
| Tempo limite (timeout) | 15 |
| Taxa Máxima Crítica de Pedidos | |
| Taxa Máxima de Aviso de Pedidos | |
| Taxa Mínima de Aviso de Pedidos | |
| Taxa Mínima Crítica de Pedidos |
A.7.5. MySQL::Threads Running
A probe MySQL::Threads Running monitora o servidor MySQL e coleta o seguinte resultado:
- Threads Rodando (Threads Running) - O número total de threads rodando no banco de dados.
Tabela A.36. Configuração da MySQL::Threads Running
| Campo | Valor |
|---|---|
| Nome do Usuário | |
| Senha | |
| Porta MySQL* | 3306 |
| Tempo limite (timeout) | 15 |
| Máximo Critico de Threads Rodando | |
| Máximo de Aviso de Threads Rodando | |
| Mínimo de Aviso de Threads Rodando | |
| Mínimo Crítico de Threads Rodando |
A.8. Network Services
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.
A.8.1. Network Services::DNS Lookup
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.
Tabela A.37. Configuração da Network Services::DNS Lookup
| Campo | Valor |
|---|---|
| Máquina ou Endereço a procurar | |
| Tempo Limite* | 10 |
| Tempo Máximo Crítico do Pedido | |
| Tempo Máximo de Aviso do Pedido |
A.8.2. Network Services::FTP
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).
Tabela A.38. Configuração da Network Services::FTP
| Campo | Valor |
|---|---|
| Esperar | FTP |
| Nome do Usuário | |
| Senha | |
| Porta FTP* | 21 |
| Tempo Limite* | 10 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.3. Network Services::IMAP Mail
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).
Tabela A.39. Configuração da Network Services::IMAP Mail
| Campo | Valor |
|---|---|
| Porta IMAP* | 143 |
| Esperar* | OK |
| Tempo Limite* | 5 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.4. Network Services::Mail Transfer (SMTP)
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.
Tabela A.40. Configuração da Network Services::Mail Transfer (SMTP)
| Campo | Valor |
|---|---|
| Porta SMTP* | 25 |
| Tempo Limite* | 10 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.5. Network Services::Ping
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)”.
Tabela A.41. Configuração da Network Services::Ping
| Campo | Valor |
|---|---|
| Endereço IP (IP do sistema é padrão) | |
| Pacotes a enviar* | 20 |
| Tempo Limite* | 10 |
| Média Máxima Crítica da Viagem Inteira | |
| Média Máxima de Aviso da Viagem Inteira | |
| Perda Máxima Crítica de Pacote | |
| Perda Máxima de Aviso de Pacote |
A.8.6. Network Services::POP Mail
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).
Tabela A.42. Configuração da Network Services::POP Mail
| Campo | Valor |
|---|---|
| Porta* | 110 |
| Esperar* | +OK |
| Tempo Limite* | 10 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.7. Network Services::Remote Ping (Serviços de Rede::Ping Remoto)
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.
Tabela A.43. Configuração da Network Services::Remote Ping
| Campo | Valor |
|---|---|
| Endereço IP* | |
| Pacotes a enviar* | 20 |
| Tempo Limite* | 10 |
| Média Máxima Crítica da Viagem Inteira | |
| Média Máxima de Aviso da Viagem Inteira | |
| Perda Máxima Crítica de Pacote | |
| Perda Máxima de Aviso de Pacote |
A.8.8. Network Services::RPCService
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.
Tabela A.44. Configração da Network Services::RPCService
| Campo | Valor |
|---|---|
| Protocol (TCP/UDP) | udp |
| Nome do Serviço* | nfs |
| Tempo Limite* | 10 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.9. Network Services::Secure Web Server (HTTPS)
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.
Tabela A.45. Configuração da Network Services::Secure Web Server (HTTPS)
| Campo | Valor |
|---|---|
| Caminho do URL | / |
| Esperar Cabeçalho | HTTP/1 |
| Esperar Conteúdo | |
| Agente do Usuário* | NOCpulse-check_http/1.0 |
| Nome do Usuário | |
| Senha | |
| Tempo Limite* | 10 |
| Porta HTTPS* | 443 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.10. Network Services::SSH
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).
Tabela A.46. Configuração da Network Services::SSH
| Campo | Valor |
|---|---|
| Porta SSH* | 22 |
| Tempo Limite* | 5 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.8.11. Network Services::Web Server (HTTP)
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.
Tabela A.47. Configuração da Network Services::Web Server (HTTP)
| Campo | Valor |
|---|---|
| Caminho do URL | / |
| Máquina Virtual | |
| Esperar Cabeçalho | HTTP/1 |
| Esperar Conteúdo | |
| Agente do Usuário* | NOCpulse-check_http/1.0 |
| Nome do Usuário | |
| Senha | |
| Tempo Limite* | 10 |
| Porta HTTP* | 80 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.9. Oracle 8i, 9i, 10g, and 11g
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
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.
A.9.1. Oracle::Active Sessions
A probe Oracle::Active Sessions monitora uma instância Oracle e coleta os seguintes resultados:
- Sessões Ativas (Active Sessions) - O número de sessões ativas baseado no valor de
V$PARAMETER.PROCESSES. - Sessões Disponíveis (Available Sessions) - A porcentagem de sessões ativas baseada no valor de
V$PARAMETER.PROCESSES.
Tabela A.48. Configuração da Oracle::Active Sessions
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Tempo Limite* | 30 |
| Máximo Crítico de Sessões Ativas | |
| Máximo de Aviso de Sessões Ativas | |
| Máximo Crítico de Sessões Disponíveis Usadas | |
| Máximo de Aviso de Sessões Disponíveis Usadas |
A.9.2. Oracle::Availability
A probe Oracle::Availability determina a disponibilidade do banco de dados pelo Red Hat Satellite.
Tabela A.49. Configuração da Oracle::Availability
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Tempo Limite* | 30 |
A.9.3. Oracle::Blocking Sessions
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.
Tabela A.50. Configuração da Oracle::Blocking Sessions
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Tempo de Bloqueio (segundos)* | 20 |
| Tempo Limite* | 30 |
| Máximo Crítico de Sessões Bloqueadoras | |
| Máximo de Aviso de Sessões Bloqueadoras |
A.9.4. Oracle::Buffer Cache
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.
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 |
A.9.5. Oracle::Client Connectivity (Oracle::Conectividade do Cliente)
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.
Tabela A.52. Configuração da Oracle::Client Connectivity
| Campo | Valor |
|---|---|
| Endereço IP ou Nome da Máquina Oracle* | |
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| ORACLE_HOME* | /opt/oracle |
| Nome do BD Esperado* | |
| Tempo Limite* | 30 |
A.9.6. Oracle::Data Dictionary Cache
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.
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 |
A.9.7. Oracle::Disk Sort Ratio
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.
Tabela A.54. Configuração da Oracle::Disk Sort Ratio
| 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 Ordem do Disco | |
| Máximo de Aviso da Proporção de Ordem do Disco |
A.9.8. Oracle::Idle Sessions
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.
Tabela A.55. Configuração da Oracle::Idle Sessions
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Tempo Ocioso (segundos)* | 20 |
| Tempo Limite* | 30 |
| Máximo Crítico de Sessões Ociosas | |
| Máximo de Aviso de Sessões Ociosas |
A.9.9. Oracle::Index Extents
A probe Oracle::Index Extents monitora uma instância do Oracle e coleta o seguinte resultado:
- Extensões Alocadas (Allocated Extents) - O número de extensões alocadas para qualquer índice.
- Extensões Disponíveis (Available Extents) - A porcentagem de extensões disponíveis de qualquer índice
O campo necessário Index Name contém um valor padrão
% que coincide com qualquer nome do índice.
Tabela A.56. Configuração da Oracle::Index Extents
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Proprietário do Índice* | % |
| Nome do Índice* | % |
| Tempo Limite* | 30 |
| Máximo Crítico de Extensões Alocadas | |
| Máximo de Aviso de Extensões Alocadas | |
| Máximo Crítico de Extensões Disponíveis | |
| Máximo de Aviso de Extensões Disponíveis |
A.9.10. Oracle::Library Cache
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.
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 |
A.9.11. Oracle::Locks
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.
Tabela A.58. Configuração da Oracle::Locks
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Tempo Limite* | 30 |
| Máximo Crítico de Bloqueios Ativos | |
| Máximo de Aviso de Bloqueios Ativos |
A.9.12. Oracle::Redo Log
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.
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 |
A.9.13. Oracle::Table Extents
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.
Tabela A.60. Configuração da Oracle::Table Extents
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Proprietário da Tabela* | % |
| Nome da Tabela* | % |
| Tempo Limite* | 30 |
| Máximo Crítico de Extensões Alocadas | |
| Máximo de Aviso de Extensões Alocadas | |
| Máximo Crítico de Extensões Disponíveis | |
| Máximo de Aviso de Extensões Disponíveis |
A.9.14. Oracle::Tablespace Usage
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.
Tabela A.61. Configuração da Oracle::Tablespace Usage
| Campo | Valor |
|---|---|
| SID Oracle* | |
| Nome de Usuário Oracle* | |
| Senha Oracle* | |
| Porta Oracle* | 1521 |
| Nome do Tablespace* | % |
| Tempo Limite* | 30 |
| Máximo Crítico de Espaço Disponível Usado | |
| Máximo de Aviso de Espaço Disponível Usado |
A.9.15. Oracle::TNS Ping
A probe Oracle::TNS Ping determina se um ouvinte do Oracle está vivo e coleta o seguinte resultado:
- Latência do Serviço Remoto (Remote Service Latency) - O tempo, em segundos, que leva para o servidor Oracle responder a um pedido de conexão.
Tabela A.62. Configuração da Oracle::TNS Ping
| Campo | Valor |
|---|---|
| Porta do Ouvinte TNS* | 1521 |
| Tempo Limite* | 15 |
| Latência Máxima Crítica do Serviço Remoto | |
| Latência Máxima de Aviso do Serviço Remoto |
A.10. Red Hat Satellite
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.
A.10.1. Red Hat Satellite::Espaço de Disco
A probe Red Hat Satellite ::Disk Space monitora o espaço livre de um Satellite e coleta os seguintes resultados:
- Sistemas de Arquivo Usados (File System Used) - A porcentagem do sistema de arquivo em uso corrente.
- Espaço Usado (Space Used) - O tamanho do arquivo usado pelo sistema de arquivo corrente.
- Espaço Disponível (Space Available) - O tamanho de arquivo disponível ao sistema de arquivo corrente.
Tabela A.63. Red Hat Satellite:: Configurações do Espaço de Disco
| Campo | Valor |
|---|---|
| Localidade do Dispositivo* | /dev/hda1 |
| Máximo Crítico do Sistema de Arquivo Usado | |
| Máximo de Aviso do Sistema de Arquivo Usado | |
| Espaço Máximo Crítico Usado | |
| Espaço Máximo de Aviso Usado | |
| Máximo Crítico do Espaço Disponível | |
| Máximo de Aviso do Espaço Disponível |
A.10.2. Red Hat Satellite::Execution Time
A probe Red Hat Satellite ::Execution Time monitora o tempo de execução das probes executadas por um Satellite e coleta o seguinte resultado:
- Tempo Médio de Execução da Detecção (Probe Execution Time Average) - Os segundos necessários para a execução total de uma probe.
Tabela A.64. Red Hat Satellite:: Configurações do Execution Time
| Campo | Valor |
|---|---|
| Máximo Crítico do Tempo Médio de Execução da Detecção | |
| Máximo de Aviso do Tempo Médio de Execução da Detecção |
A.10.3. Red Hat Satellite::Interface Traffic
A probe Red Hat Satellite ::Interface Traffic monitora o tráfego da interface de um Satellite e coleta os seguintes resultados:
- Taxa de Input (Input Rate) - A quantidade de tráfego que o dispositivo recebe, em bytes por segundo.
- Taxa de Output (Output Rate) - A quantidade de tráfego que o dispositivo envia, em bytes por segundo.
Tabela A.65. Red Hat Satellite::Configurações do Interface Traffic
| Campo | Valor |
|---|---|
| Interface* | eth0 |
| Tempo limite (segundos)* | 30 |
| Taxa Máxima Crítica de Input | |
| Taxa Máxima Crítica de Output |
A.10.4. Red Hat Satellite::Latency
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.
Tabela A.66. Red Hat Satellite:: Configurações do Latency
| Campo | Valor |
|---|---|
| Máximo Crítico da Latência Média da Detecção | |
| Máximo de Aviso da Latência Média da Detecção |
A.10.5. Red Hat Satellite::Load
A probe Red Hat Satellite ::O Load monitora a carga da CPU num Satellite e coleta o seguinte resultado:
- Carga (Load) - A carga média da CPU durante os períodos de 1, 5 e 15 minutos.
Tabela A.67. Red Hat Satellite:: Configurações da Load
| Campo | Valor |
|---|---|
| Máximo Crítico da Média de 1 Minuto | |
| Máximo de Aviso da Média de 1 Minuto | |
| Máximo Crítico da Média de 5 Minutos | |
| Máximo de Aviso da Média de 5 Minutos | |
| Máximo Crítico da Média de 15 Minutos | |
| Máximo de Aviso da Média de 15 Minutos |
A.10.6. Red Hat Satellite::Probe Count
The Red Hat Satellite::a Probe Count monitora a latência das probes num Satellite e coleta o seguinte resultado:
- Detecções (Probes) - O número de probes rodando num Satellite.
Tabela A.68. Red Hat Satellite::Configurações do Probe Count
| Campo | Valor |
|---|---|
| Máximo Crítico da Contagem de Probes (Detecções) | |
| Máximo de Aviso da Contagem de Probes (Detecções) |
A.10.7. Red Hat Satellite::Process Counts
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 chamadawait()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 (
Interruptiblesleep), podendo ser posteriormente reintroduzido na memória, reiniciando a execução no ponto em que parou.
Tabela A.69. Red Hat Satellite::Configurações do Process Counts
| Campo | Valor |
|---|---|
| Máximo Crítico de Processos Bloqueados | |
| Máximo de Aviso dos Processos Bloqueados | |
| Máximo Crítico de Processos Filho | |
| Máximo de Aviso de Processos Filho | |
| Máximo Crítico de Processos Extintos | |
| Máximo de Aviso de Processos Extintos | |
| Máximo Crítico de Processos Parados | |
| Máximo de Aviso de Processos Parados | |
| Máximo Crítico de Processos Dormentes | |
| Máximo de Aviso de Processos Dormentes |
A.10.8. Red Hat Satellite::Processos
A probe Red Hat Satellite :: Probe de Processos monitora o número de processos num Satellite e coleta os seguintes resultados:
- Processos (Processes) - O número de processos rodando simultaneamente na máquina.
Tabela A.70. Red Hat Satellite::Configurações de Processos
| Campo | Valor |
|---|---|
| Máximo Crítico de Processos | |
| Máximo de Aviso de Processos |
A.10.9. Red Hat Satellite::Process Health
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).
Tabela A.71. Red Hat Satellite::Configurações de Process Health
| Campo | Valor |
|---|---|
| Nome do Comando | |
| Arquivo do ID do processo (PID) | |
| Tempo Limite* | 15 |
| Uso Máximo Crítico da CPU | |
| Uso Máximo de Aviso da CPU | |
| Máximo Crítico de Grupos de Processos Filho | |
| Máximo de Aviso de Grupos de Processos Filho | |
| Máximo Crítico de Threads | |
| Máximo de Aviso de Threads | |
| Máximo Crítico de Memória Física Usada | |
| Máximo de Aviso de Memória Física Usada | |
| Máximo Crítico de Memória Virtual Usada | |
| Máximo de Aviso de Memória Virtual Usada |
A.10.10. Red Hat Satellite::Process Running
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).
Tabela A.72. Red Hat Satellite::Configurações do Process Running
| Campo | Valor |
|---|---|
| Nome do Comando | |
| Arquivo do ID do processo (PID) | |
| Número Máximo Crítico Rodando | |
| Número Mínimo Crítico Rodando |
A.10.11. Red Hat Satellite::Swap
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.
Tabela A.73. Red Hat Satellite:: Configurações do Swap
| Campo | Valor |
|---|---|
| Porcentagem Mínima Crítica de Swap Livre | |
| Porcentagem Mínima de Aviso de Swap Livre |
A.10.12. Red Hat Satellite::Usuários
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.
Tabela A.74. Red Hat Satellite:: Configurações de Usuários
| Campo | Valor |
|---|---|
| Máximo Crítico de Usuários | |
| Máximo de Aviso de Usuários |
Apêndice B. Histórico de Revisões
| Histórico de Revisões | ||||||||
|---|---|---|---|---|---|---|---|---|
| Revisão 4-32.2.400 | 2013-10-31 | |||||||
| ||||||||
| Revisão 4-32.2 | Thu Aug 30 2013 | |||||||
| ||||||||
| Revisão 4-32.1 | Fri Aug 30 2013 | |||||||
| ||||||||
| Revisão 4-32 | Thu Aug 29 2013 | |||||||
| ||||||||
| Revisão 4-31 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-30 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-29 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-28 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-27 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-26 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-25 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-24 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-23 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisão 4-22 | Thu Aug 15 2013 | |||||||
| ||||||||
| Revisão 4-21 | Sun Jul 28 2013 | |||||||
| ||||||||
| Revisão 4-20 | Wed Jul 24 2013 | |||||||
| ||||||||
| Revisão 4-19 | Tue Jul 23 2013 | |||||||
| ||||||||
| Revisão 4-18 | Thu Jul 12 2013 | |||||||
| ||||||||
| Revisão 4-17 | Thu Jul 12 2013 | |||||||
| ||||||||
| Revisão 4-16 | Thu Jul 11 2013 | |||||||
| ||||||||
| Revisão 4-15 | Fri Jul 5 2013 | |||||||
| ||||||||
| Revisão 4-14 | Fri Jul 5 2013 | |||||||
| ||||||||
| Revisão 4-13 | Fri June 28 2013 | |||||||
| ||||||||
| Revisão 4-12 | Tue June 4 2013 | |||||||
| ||||||||
| Revisão 4-11 | Fri May 17 2013 | |||||||
| ||||||||
| Revisão 4-10 | Thu Apr 25 2013 | |||||||
| ||||||||
| Revisão 4-9 | Thu Feb 28 2013 | |||||||
| ||||||||
| Revisão 4-8 | Wed Jan 2 2013 | |||||||
| ||||||||
| Revisão 4-7 | Wed Sept 19 2012 | |||||||
| ||||||||
| Revisão 4-6 | Thu Aug 16 2012 | |||||||
| ||||||||
| Revisão 4-5 | Thu Aug 16 2012 | |||||||
| ||||||||
| Revisão 4-4 | Wed Aug 15 2012 | |||||||
| ||||||||
| Revisão 4-3 | Thu Aug 9 2012 | |||||||
| ||||||||
| Revisão 3-2 | Fri Aug 3 2012 | |||||||
| ||||||||
| Revisão 3-1 | Tue Jun 17 2012 | |||||||
| ||||||||
| Revisão 3-0 | Thurs May 24 2012 | |||||||
| ||||||||
| Revisão 2-6 | Mon Jan 9 2012 | |||||||
| ||||||||
| Revisão 2-5 | Wed Jan 4 2012 | |||||||
| ||||||||
| Revisão 2-4 | Fri Sep 23 2011 | |||||||
| ||||||||
| Revisão 2-3 | Mon Aug 15 2011 | |||||||
| ||||||||
| Revisão 2-2 | Wed Jun 15 2011 | |||||||
| ||||||||
| Revisão 2-1 | Fri May 27 2011 | |||||||
| ||||||||
| Revisão 2-0 | Fri May 6 2011 | |||||||
| ||||||||
| Revisão 1-29 | Fri March 25 2011 | |||||||
| ||||||||
| Revisão 1-28 | Thu March 24 2011 | |||||||
| ||||||||
| Revisão 1-27 | Mon Feb 14 2011 | |||||||
| ||||||||
| Revisão 1-26 | Wed Feb 9 2011 | |||||||
| ||||||||
| Revisão 1-25 | Mon Jan 31 2011 | |||||||
| ||||||||
Nota Legal
Copyright © 2013 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, 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.
