systemdjournalctl: consultar o diário do systemdudev
Para uma rápida visão geral de todas as informações de sistema relevantes de uma máquina, o SUSE Linux Enterprise Desktop oferece o pacote hostinfo. Ele também ajuda os administradores do sistema a verificarem se há Kernels contaminados (que não são suportados) ou quaisquer pacotes de terceiros instalados na máquina.
Em caso de problemas, é possível criar um relatório detalhado do sistema com a ferramenta de linha de comando supportconfig ou o módulo de do YaST. Os dois coletam informações sobre o sistema, como a versão atual do kernel, o hardware, os pacotes instalados, a configuração da partição, etc. O resultado é um armazenamento de arquivos TAR. Após abrir uma Solicitação de Serviço (SS), você poderá fazer upload do armazenamento TAR para o Suporte Técnico Global. Ele ajuda a localizar o problema que você relatou e a orientá-lo para uma solução.
Você também pode verificar se há problemas conhecidos na saída do supportconfig para ajudar a resolvê-los mais rapidamente. Para esta finalidade, o SUSE Linux Enterprise Desktop oferece uma aplicação e uma ferramenta de linha de comando para Supportconfig Analysis (SCA).
Para uma visão geral rápida e fácil de todas as informações do sistema relevantes, use o pacote hostinfo ao efetuar login no servidor. Após ser instalado na máquina, o console exibirá as seguintes informações para qualquer usuário root que efetuar login nessa máquina:
hostinfo ao efetuar login como root #Hostname: earth Current As Of: Wed 12 Mar 2014 03:57:05 PM CET Distribution: SUSE Linux Enterprise Server 12 -Service Pack: 0 Architecture: x86_64 Kernel Version: 3.12.12-3-default -Installed: Mon 10 Mar 2014 03:15:05 PM CET -Status: Not Tainted Last Updated Package: Wed 12 Mar 2014 03:56:43 PM CET -Patches Needed: 0 -Security: 0 -3rd Party Packages: 0 IPv4 Address: ens3 192.168.1.1 Total/Free/+Cache Memory: 983/95/383 MB (38% Free) Hard Disk: /dev/sda 10 GB
Caso a saída apresente o Kernel com status tainted (contaminado), consulte a Seção 2.5, “Suporte aos módulos do Kernel” para mais detalhes.
Para criar um armazenamento TAR com informações detalhadas do sistema que você possa enviar ao Suporte Técnico Global, use a ferramenta de linha de comando supportconfig diretamente ou o módulo de do YaST. A ferramenta de linha de comando está incluída no pacote supportutils, que é instalado por padrão. O módulo de do YaST também é baseado na ferramenta de linha de comando.
É possível gerar armazenamentos do supportconfig a qualquer momento. No entanto, para enviar os dados do supportconfig ao Suporte Técnico Global, é necessário gerar primeiro um número de solicitação de serviço. Você precisa dele para fazer upload do armazenamento para o suporte.
Para criar uma solicitação de serviço, acesse http://www.novell.com/center/eservice e siga as instruções na tela. Anote o seu número de solicitação de serviço de 11 dígitos.
A SUSE e a Novell tratam os relatórios do sistema como dados confidenciais. Para ver detalhes do nosso compromisso de privacidade, acesse http://www.novell.com/company/legal/privacy/.
Após criar um número de solicitação de serviço, você poderá fazer upload dos armazenamentos supportconfig para o Suporte Técnico Global, conforme descrito no Procedimento 2.1, “Submetendo informações ao suporte com o YaST” ou no Procedimento 2.2, “Submetendo informações ao suporte por linha de comando”. Use um dos seguintes destinos de upload:
Clientes nos EUA: ftp://ftp.novell.com/incoming
EMEA, Europa, Oriente Médio e África: ftp://support-ftp.suse.com/in
Você também pode anexar o armazenamento TAR manualmente à sua solicitação de serviço usando o URL da solicitação de serviço: http://www.novell.com/center/eservice.
Para usar o YaST para coletar informações do sistema, faça o seguinte:
Inicie o YaST e abra o módulo de .
Clique em .
Na janela seguinte, selecione uma das opções de supportconfig na lista de botões de opção. Por padrão, a opção está pré-selecionada. Para testar primeiro a função de relatório, use . Para obter algumas informações básicas sobre outras opções, consulte a página de manual de supportconfig.
Continue com .
Digite suas informações de contato. Elas são gravadas em um arquivo chamado basic-environment.txt e incluídas no armazenamento que será criado.
Para submeter o armazenamento ao Suporte Técnico Global no fim do processo de coleta de informações, a opção é obrigatória. O YaST propõe um servidor de upload automaticamente. Para modificá-lo, consulte a Seção 2.2.2, “Destinos de upload” para saber os detalhes de quais servidores de upload estão disponíveis.
Para submeter o armazenamento mais tarde, deixe a opção vazia por enquanto.
Continue com .
A coleta de informações é iniciada.
Quando o processo for concluído, continue com .
Revise a coleta de dados: Selecione o de um registro para ver seu conteúdo no YaST. Para remover arquivos do armazenamento TAR antes de submetê-lo ao suporte, use . Continue com .
Grave o armazenamento TAR. Se você iniciar o módulo do YaST como usuário root, por padrão, o YaST vai propor gravar o armazenamento em /var/log (ou em seu diretório pessoal). O formato do nome de arquivo é nts_HOST_DATA_HORÁRIO.tbz.
Para fazer upload do armazenamento diretamente para o suporte, verifique se a opção está ativada. O mostrado aqui é aquele proposto pelo YaST no Passo 5. Para modificar o destino do upload, encontre as informações detalhadas sobre quais servidores de upload estão disponíveis na Seção 2.2.2, “Destinos de upload”.
Para ignorar o upload, desative a opção .
Confirme as mudanças para fechar o módulo do YaST.
O seguinte procedimento mostra como criar um armazenamento supportconfig, mas sem o submeter diretamente ao suporte. Para fazer seu upload, é necessário executar o comando com algumas opções, conforme descrito no Procedimento 2.2, “Submetendo informações ao suporte por linha de comando”.
Abra um shell e torne-se root.
Execute supportconfig sem qualquer opção. Isso reúne as informações padrão do sistema.
Aguarde a ferramenta concluir a operação.
O local padrão do armazenamento é /var/log, com o formato de nome de arquivo nts_HOST_DATA_HORÁRIO.tbz
O utilitário supportconfig é geralmente chamado sem nenhuma opção. Exiba uma lista de todas as opções com supportconfig -h ou consulte a página de manual. A seguinte lista apresenta uma breve visão geral de alguns casos de uso comuns:
Usar a opção mínima (-m):
supportconfig -m
Se você já localizou um problema com a saída padrão do supportconfig e descobriu que ele está relacionado apenas a determinada área ou conjunto de recursos, convém limitar as informações coletadas à área especifica na próxima execução do supportconfig. Por exemplo, se você detectar problemas com o LVM e quiser testar uma recente mudança feita na configuração do LVM, convém coletar o mínimo de informações do supportconfig apenas sobre o LVM:
supportconfig -i LVM
Para ver a lista completa de palavras-chave de recursos que você pode usar para limitar as informações coletadas a determinada área, execute
supportconfig -F
supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...
(tudo em uma linha)
supportconfig -l
Isso é útil principalmente em ambientes de alto registro ou após uma falha do kernel quando o syslog gira os arquivos de registro após uma reinicialização.
Use o módulo de do YaST ou o utilitário de linha de comando supportconfig para submeter as informações do sistema ao Suporte Técnico Global. Se você tiver um problema com o servidor e quiser a ajuda do suporte, precisará abrir primeiro uma solicitação de serviço. Para obter os detalhes, consulte a Seção 2.2.1, “Criando um número de solicitação de serviço”.
Os seguintes exemplos usam 12345678901 como marcador para o número da sua solicitação de serviço. Substitua 12345678901 pelo número da solicitação de serviço que você criou na Seção 2.2.1, “Criando um número de solicitação de serviço”.
O seguinte procedimento considera que você já tenha criado um armazenamento supportconfig, mas ainda não tenha feito upload dele. Verifique se você incluiu suas informações de contato no armazenamento, conforme descrito na Seção 2.2.3, “Criando um armazenamento supportconfig com o YaST”, Passo 4. Para ver instruções de como gerar e submeter de uma só vez um armazenamento supportconfig, consulte a Seção 2.2.3, “Criando um armazenamento supportconfig com o YaST”.
Inicie o YaST e abra o módulo de .
Clique em .
Em , especifique o caminho para o armazenamento supportconfig existente ou use .
O YaST propõe um servidor de upload automaticamente. Para modificá-lo, consulte a Seção 2.2.2, “Destinos de upload” para saber os detalhes de quais servidores de upload estão disponíveis.
Continue com .
Clique em .
O seguinte procedimento considera que você já tenha criado um armazenamento supportconfig, mas ainda não tenha feito upload dele. Para ver instruções de como gerar e submeter de uma só vez um armazenamento supportconfig, consulte a Seção 2.2.3, “Criando um armazenamento supportconfig com o YaST”.
Servidores com conectividade à Internet:
Para usar o destino de upload padrão, execute:
supportconfig -ur 12345678901
Para o destino de upload seguro, use o seguinte:
supportconfig -ar 12345678901
Servidores sem conectividade à Internet
Execute o seguinte:
supportconfig -r 12345678901
Faça upload do armazenamento /var/log/nts_SR12345678901*tbz manualmente para um de nossos servidores FTP. O servidor que deverá ser usado depende da sua localização global. Para uma visão geral, consulte a Seção 2.2.2, “Destinos de upload”.
Depois que o armazenamento TAR estiver no diretório de entrada do nosso servidor FTP, ele será automaticamente anexado à sua solicitação de serviço.
É possível analisar os relatórios do sistema criados com o supportconfig para ver se há problemas conhecidos e agilizar sua solução. Para esta finalidade, o SUSE Linux Enterprise Desktop oferece uma aplicação e uma ferramenta de linha de comando para Supportconfig Analysis (SCA). A aplicação SCA é uma ferramenta não interativa executada no servidor. A ferramenta SCA (scatool) é executada no cliente por linha de comando. As duas ferramentas analisam os armazenamentos supportconfig dos servidores afetados. A análise inicial do servidor ocorre na aplicação SCA ou na estação de trabalho em que a scatool é executada. Nenhum ciclo de análise é realizado no servidor de produção.
Tanto a aplicação quanto a ferramenta de linha de comando também precisam de padrões específicos do produto, que as permitem analisar a saída do supportconfig dos produtos associados. Cada padrão é um script que analisa e avalia um armazenamento supportconfig referente a um problema conhecido. Os padrões estão disponíveis como pacotes RPM.
Por exemplo, para analisar armazenamentos supportconfig que foram gerados em uma máquina com o SUSE Linux Enterprise 11, é necessário instalar o pacote sca-patterns-sle11 juntamente com a ferramenta SCA (ou na máquina que deseja usar como servidor da aplicação SCA). Para analisar armazenamentos supportconfig gerados em uma máquina com o SUSE Linux Enterprise 10, o pacote sca-patterns-sle10 é necessário.
É possível também desenvolver seus próprios padrões, conforme descrito resumidamente na Seção 2.4.3, “Desenvolvendo padrões de análise personalizados”.
A ferramenta de linha de comando SCA permite analisar uma máquina local usando o supportconfig e os padrões de análise referentes ao produto específico que está instalado na máquina local. A ferramenta cria um relatório HTML que mostra os resultados da análise. Para obter um exemplo, consulte a Figura 2.1, “Relatório HTML gerado pela ferramenta SCA”.
O comando scatool está incluído no pacote sca-server-report. Ele não é instalado por padrão. Você também precisa do pacote sca-patterns-base e de qualquer um dos pacotes sca-patterns-* específicos do produto correspondentes ao produto instalado na máquina em que deseja executar o comando scatool.
Execute o comando scatool como usuário root ou com sudo. Ao chamar a ferramenta SCA, é possível analisar um armazenamento TAR supportconfig existente ou deixar que ela gere e analise um novo armazenamento de uma vez. A ferramenta também oferece um console interativo (com preenchimento de tabulação) e a possibilidade de executar o supportconfig em uma máquina externa e de executar as análises subsequentes na máquina local.
Veja a seguir alguns exemplos de comandos:
sudo scatool -s
Chama o supportconfig e gera um novo armazenamento supportconfig na máquina local. Analisa o armazenamento para ver se há problemas conhecidos aplicando os padrões de análise da SCA correspondentes ao produto instalado. Exibe o caminho para o relatório HTML que é gerado com base nos resultados da análise. Normalmente, ele é gravado no mesmo diretório do armazenamento supportconfig.
sudo scatool -s -o /opt/sca/reports/
Igual ao sudo scatool , só que o relatório HTML é gravado no caminho especificado com -s-o.
sudo scatool -a CAMINHO_PARA_TARBALL_OU_DIR
Analisa o arquivo de armazenamento supportconfig especificado (ou o diretório indicado no qual o armazenamento supportconfig foi extraído). O relatório HTML gerado é gravado no mesmo local do armazenamento ou diretório do supportconfig.
sudo scatool -a servidor_sles.empresa.com
Estabelece uma conexão SSH com o servidor externo servidor_sles.empresa.com e executa o supportconfig no servidor. Em seguida, o armazenamento supportconfig é copiado novamente na máquina local e analisado nela. O relatório HTML gerado é gravado no diretório padrão /var/log. (Apenas o armazenamento supportconfig é criado em servidor_sles.empresa.com).
sudo scatool -c
Inicia o console interativo da scatool. Pressione →| duas vezes para ver os comandos disponíveis.
Para mais opções e informações, execute sudo scatool -h ou consulte a página de manual de scatool.
Se você usar a aplicação SCA para analisar armazenamentos supportconfig, precisará configurar um servidor dedicado (ou máquina virtual) como servidor da aplicação SCA. Depois disso, o servidor da aplicação SCA poderá ser usado para analisar armazenamentos supportconfig em todas as máquinas da sua empresa que tenham o SUSE Linux Enterprise Server ou o SUSE Linux Enterprise Desktop. Basta fazer upload dos armazenamentos supportconfig para o servidor da aplicação para análise. Não é necessária nenhuma interação. Em um banco de dados MariaDB, a aplicação SCA monitora todos os armazenamentos supportconfig que foram analisados. É possível ler os relatórios da SCA diretamente da interface da Web da aplicação. Se você preferir, a aplicação poderá enviar o relatório HTML por e-mail para qualquer usuário administrativo. Para obter os detalhes, consulte a Seção 2.4.2.5.4, “Enviando relatórios da SCA por e-mail”.
Para instalar e configurar rapidamente a aplicação SCA por linha de comando, siga as instruções na Seção 2.4.2.1, “Inicialização Rápida da Instalação”. O procedimento é para especialistas e está centrado na instalação limpa e nos comandos de configuração. Para obter mais informações, consulte a descrição mais detalhada da Seção 2.4.2.2, “Pré-requisitos” até a Seção 2.4.2.3, “Instalação e configuração básica”.
Padrão da Web e LAMP
Módulo da Web e de Criação de Scripts (você deve registrar a máquina para selecionar esse módulo).
root necessários
Todos os comandos do procedimento a seguir devem ser executados como root.
Depois que a aplicação estiver funcionando, não será necessária mais nenhuma interação manual. Portanto, esta forma de configurar a aplicação é ideal ao usar tarefas cron para criar e fazer upload de armazenamentos supportconfig.
Na máquina de instalação da aplicação, efetue login no console e execute os seguintes comandos:
zypper install sca-appliance-* sca-patterns-* vsftpd systemctl enable apache2.service systemctl start apache2.service systemctl enable vsftpd.service systemctl start vsftpd.service yast ftp-server
No Servidor FTP do YaST, selecione › › › › para .
Execute os seguintes comandos:
systemctl enable mysql.service systemctl start mysql.service mysql_secure_installation setup-sca -f
A mysql_secure_installation cria uma senha de root do MariaDB.
Esta forma de configurar a aplicação requer interação manual para digitar a senha SSH.
Na máquina de instalação da aplicação, efetue login no console.
Execute os seguintes comandos:
zypper install sca-appliance-* sca-patterns-* systemctl enable apache2.service systemctl start apache2.service sudo systemctl enable mysql.service systemctl start mysql.service mysql_secure_installation setup-sca
Para executar um servidor da aplicação SCA, são necessários os seguintes pré-requisitos:
Todos os pacotes sca-appliance-*.
O pacote sca-patterns-base. Adicionalmente, qualquer um dos sca-patterns-* específicos do produto, de acordo com o tipo de armazenamento supportconfig que você deseja analisar com a aplicação.
Apache
PHP
MariaDB
Servidor FTP anônimo (opcional)
Conforme listado na Seção 2.4.2.2, “Pré-requisitos”, a aplicação SCA possui várias dependências em outros pacotes. Portanto, você precisa fazer algumas preparações antes de instalar e configurar o servidor da aplicação SCA:
No Apache e no MariaDB, instale os padrões de instalação da Web e LAMP.
Configure o Apache, o MariaDB e, opcionalmente, um servidor FTP anônimo.
Configure o Apache e o MariaDB para iniciarem no momento da inicialização:
sudo systemctl enable apache2.service mysql.service
Inicie os dois serviços:
sudo systemctl start apache2.service mysql.service
Agora você pode instalar a aplicação SCA e configurá-la conforme descrito no Procedimento 2.5, “Instalando e configurando a aplicação SCA”.
Após instalar os pacotes, use o script setup-sca para a configuração básica do banco de dados de administração e relatório MariaDB, que é usado pela aplicação SCA.
Ele pode ser usado para configurar as seguintes opções disponíveis para fazer upload dos armazenamentos supportconfig de suas máquinas para a aplicação SCA:
scp
servidor FTP anônimo
Instale a aplicação e a biblioteca de padrões com base na SCA:
sudo zypper install sca-appliance-* sca-patterns-base
Instale também os pacotes de padrões de acordo com os tipos de armazenamentos supportconfig que você deseja analisar. Por exemplo, se você tem servidores SUSE Linux Enterprise Server 11 e SUSE Linux Enterprise Server 12 em seu ambiente, instale os dois pacotes sca-patterns-sle11 e sca-patterns-sle12.
Para instalar todos os padrões disponíveis:
zypper install sca-patterns-*
Para a configuração básica da aplicação SCA, use o script setup-sca. O modo como ele é chamado depende de como você deseja fazer upload dos armazenamentos supportconfig para o servidor da aplicação SCA:
Se você configurar um servidor FTP anônimo que usa o diretório /srv/ftp/upload, execute o script de configuração com a opção -f e siga as instruções na tela:
setup-sca -f
Se o seu servidor FTP usa um diretório diferente do /srv/ftp/upload, ajuste os seguintes arquivos de configuração para apontarem para o diretório correto: /etc/sca/sdagent.conf e /etc/sca/sdbroker.conf .
Para fazer upload dos arquivos supportconfig para o diretório /tmp do servidor da aplicação SCA usando o comando scp, chame o script de configuração sem nenhum parâmetro e siga as instruções na tela:
setup-sca
O script de configuração executa algumas verificações referentes a seus requisitos e configura os subcomponentes necessários. Ele pede duas senhas: a senha de root MySQL do MariaDB que você configurou e uma senha de usuário da Web usada para efetuar login na interface da Web da aplicação SCA.
Digite a senha de root existente do MariaDB. Isso permite que a aplicação SCA se conecte com o MariaDB.
Defina uma senha para o usuário da Web. Ela será gravada em /srv/www/htdocs/sca/web-config.php e definida como a senha do usuário scdiag. Tanto o nome de usuário quanto a senha podem ser mudados a qualquer momento. Consulte a Seção 2.4.2.5.1, “Senha da interface da Web”.
Após a instalação e configuração bem-sucedidas, a aplicação SCA estará pronta para uso. Consulte a Seção 2.4.2.4, “Usando a aplicação SCA”. No entanto, é possível modificar algumas opções, como mudar a senha da interface da Web, mudar a fonte das atualizações dos padrões da SCA, habilitar o modo de arquivamento ou configurar notificações por e-mail. Para ver os detalhes sobre isso, consulte a Seção 2.4.2.5, “Personalizando a aplicação SCA”.
Como os relatórios no servidor da aplicação SCA incluem informações relacionadas à segurança sobre as máquinas em que os armazenamentos supportconfig foram analisados, proteja os dados do servidor da aplicação SCA contra acesso não autorizado.
É possível fazer upload dos armazenamentos supportconfig existentes para a aplicação SCA manualmente ou criar novos armazenamentos supportconfig e fazer upload deles para a aplicação SCA em uma etapa. O upload pode ser feito por FTP ou SCP. Nos dois, é necessário saber o URL para acessar a aplicação SCA. Para upload por FTP, um servidor FTP precisa ser configurado para a aplicação SCA. Consulte o Procedimento 2.5, “Instalando e configurando a aplicação SCA”.
Para criar um armazenamento supportconfig e fazer seu upload por FTP (anônimo):
sudo supportconfig -U “ftp://sca-appliance.company.com/upload”
Para criar um armazenamento supportconfig e fazer seu upload por SCP:
sudo supportconfig -U “scp://sca-appliance.company.com/tmp”
Você deverá informar a senha de usuário root do servidor que executa a aplicação SCA.
Para fazer upload de um ou vários armazenamentos manualmente, copie os arquivos de armazenamento existentes (normalmente em /var/log/nts_*.tbz) para a aplicação SCA. Como destino, use o diretório /tmp do servidor da aplicação ou o diretório /srv/ftp/upload (se FTP estiver configurado para o servidor da aplicação SCA).
É possível ver os relatórios da SCA de qualquer máquina que tenha um browser instalado e acesso à página de índice de relatórios da aplicação SCA.
Inicie o browser da Web e verifique se o JavaScript e os cookies estão habilitados.
Como URL, insira a página de índice de relatórios da aplicação SCA.
https://sca-appliance.company.com/sca
Se estiver em dúvida, pergunte ao administrador do sistema.
Você deverá informar o nome de usuário e a senha para efetuar login.
Após o login, clique na data do relatório que deseja ler.
Clique primeiro na categoria (Saúde Básica) para expandi-la.
Na coluna (Mensagem), clique em uma entrada. O artigo correspondente é aberto no SUSE Knowledgebase. Leia a solução proposta e siga as instruções.
Se a coluna (Soluções) do mostrar qualquer outra entrada, clique nela. Leia a solução proposta e siga as instruções.
Consulte o SUSE Knowledgebase (http://www.suse.com/support/kb/) para ver resultados diretamente relacionados ao problema identificado pela SCA. Resolva o problema.
Procure resultados que possam ser usados proativamente para evitar futuros problemas.
As seguintes seções mostram como mudar a senha da interface da Web, como mudar a fonte das atualizações dos padrões da SCA, como habilitar o modo de arquivamento e como configurar notificações por e-mail.
A interface da Web da aplicação SCA requer nome de usuário e senha para login. O nome de usuário padrão é scdiag e a senha padrão é linux (caso não tenham sido especificados de outra forma. Consulte o Procedimento 2.5, “Instalando e configurando a aplicação SCA”). Mude a senha padrão para uma senha segura na primeira oportunidade. É possível também modificar o nome de usuário.
Efetue login como usuário root no console do sistema do servidor da aplicação SCA.
Abra o /srv/www/htdocs/sca/web-config.php em um editor.
Mude os valores de $username e $password conforme desejado.
Grave o arquivo e saia.
Por padrão, todos os pacotes sca-patterns-* são atualizados regularmente por uma tarefa cron root que executa o script sdagent-patterns durante a noite, que, por sua vez, executa zypper update sca-patterns-*. Uma atualização regular de sistema atualiza todos os pacotes de padrões e da aplicação SCA. Para atualizar a aplicação SCA e os padrões manualmente, execute:
sudo zypper update sca-*
Por padrão, as atualizações são instaladas do repositório de atualização do SUSE Linux Enterprise 12. Você poderá mudar a fonte das atualizações para um servidor SMT, se desejado. Quando sdagent-patterns executa zypper update sca-patterns-*, ele acessa as atualizações do canal de atualização configurado no momento. Se esse canal estiver em um servidor SMT, os pacotes serão acessados de lá.
Efetue login como usuário root no console do sistema do servidor da aplicação SCA.
Abra o /etc/sca/sdagent-patterns.conf em um editor.
Mudar a entrada
UPDATE_FROM_PATTERN_REPO=1
para
UPDATE_FROM_PATTERN_REPO=0
Grave o arquivo e saia. Não é necessário reiniciar a máquina para aplicar a mudança.
Todos os armazenamentos supportconfig serão apagados da aplicação SCA depois de serem analisados e de seus resultados serem armazenados no banco de dados MariaDB. Para fins de solução de problemas, no entanto, convém manter cópias dos armazenamentos supportconfig da máquina. Por padrão, o modo de arquivamento está desabilitado.
Efetue login como usuário root no console do sistema do servidor da aplicação SCA.
Abra o /etc/sca/sdagent.conf em um editor.
Mudar a entrada
ARCHIVE_MODE=0
para
ARCHIVE_MODE=1
Grave o arquivo e saia. Não é necessário reiniciar a máquina para aplicar a mudança.
Após habilitar o modo de arquivamento, a aplicação SCA gravará os arquivos supportconfig no diretório /var/log/archives/saved, em vez de apagá-los.
A aplicação SCA pode enviar um arquivo HTML de relatório por e-mail referente a cada supportconfig analisado. Por padrão, este recurso está desabilitado. Ao habilitá-lo, é possível definir uma lista de endereços de e-mail para os quais enviar os relatórios e especificar um nível de mensagens de status que aciona o envio dos relatórios (STATUS_NOTIFY_LEVEL).
STATUS_NOTIFY_LEVEL #Desativar o envio de relatórios HTML.
Enviar apenas relatórios da SCA que incluam CRITICAL (Crítico).
Enviar apenas relatórios da SCA que incluam WARNING (Aviso) ou CRITICAL.
Enviar apenas relatórios da SCA que incluam RECOMMEND (Recomendado), WARNING ou CRITICAL.
Enviar relatórios da SCA que incluam SUCCESS (Êxito), RECOMMEND, WARNING ou CRITICAL.
Efetue login como usuário root no console do sistema do servidor da aplicação SCA.
Abra o /etc/sca/sdagent.conf em um editor.
Pesquise a entrada STATUS_NOTIFY_LEVEL. Por padrão, ela está definida como $STATUS_OFF (notificações por e-mail desabilitadas).
Para habilitar as notificações por e-mail, mude $STATUS_OFF para o nível de mensagens de status para o qual deseja gerar relatórios por e-mail, por exemplo:
STATUS_NOTIFY_LEVEL=$STATUS_SUCCESS
Para obter os detalhes, consulte Valores possíveis para STATUS_NOTIFY_LEVEL.
Para definir a lista de destinatários que devem receber os relatórios:
Pesquise a entrada EMAIL_REPORT='root'.
Substitua root pela lista de endereços de e-mail aos quais enviar os relatórios da SCA. Os endereços de e-mail devem ser separados por espaços. Por exemplo:
EMAIL_REPORT='tux@my.company.com wilber@your.company.com'
Grave o arquivo e saia. Não é necessário reiniciar a máquina para aplicar as mudanças. Todos os relatórios futuros da SCA serão enviados por e-mail aos endereços especificados.
Para fazer backup e restaurar o banco de dados MariaDB que armazena os relatórios da SCA, use o comando scadb, conforme descrito a seguir.
Efetue login como usuário root no console do sistema do servidor que executa a aplicação SCA.
Coloque a aplicação no modo de manutenção executando:
scadb maint
Inicie o backup com:
scadb backup
Os dados são gravados em um armazenamento TAR: sca-backup-*sql.gz.
Se você usa o banco de dados de criação de padrões para desenvolver seus próprios padrões (consulte a Seção 2.4.3, “Desenvolvendo padrões de análise personalizados”), faça backup também destes dados:
sdpdb backup
Os dados são gravados em um armazenamento TAR: sdp-backup-*sql.gz.
Copie os seguintes dados para outra máquina ou para um meio de armazenamento externo:
sca-backup-*sql.gz
sdp-backup-*sql.gz
/usr/lib/sca/patterns/local (necessário apenas se você criar padrões personalizados)
Ative novamente a aplicação SCA com:
scadb reset agents
Para restaurar o banco de dados do backup, faça o seguinte:
Efetue login como usuário root no console do sistema do servidor que executa a aplicação SCA.
Copie os armazenamentos TAR sca-backup-*sql.gz e sdp-backup-*sql.gz mais recentes para o servidor da aplicação SCA.
Para descompactar os arquivos, execute:
gzip -d *-backup-*sql.gz
Para importar os dados para o banco de dados, execute:
scadb import sca-backup-*sql
Se você usa o banco de dados de criação de padrões para criar seus próprios padrões, importe também os seguintes dados com:
sdpdb import sdp-backup-*sql
Se você usa padrões personalizados, restaure também /usr/lib/sca/patterns/local dos dados do backup.
Ative novamente a aplicação SCA com:
scadb reset agents
Atualize os módulos de padrão no banco de dados com:
sdagent-patterns -u
A aplicação SCA vem com um ambiente completo de desenvolvimento de padrões (o Banco de Dados de Padrões da SCA), que permite desenvolver padrões personalizados. Os padrões podem ser desenvolvidos em qualquer linguagem de programação. Para disponibilizá-los para o processo de análise do supportconfig, eles devem ser gravados em /usr/lib/sca/patterns/local e ser executáveis. Tanto a aplicação quanto a ferramenta SCA executam os padrões personalizados nos novos armazenamentos supportconfig como parte do relatório de análise. Para obter instruções detalhadas sobre como criar (e testar) seus próprios padrões, visite http://www.suse.com/communities/conversations/sca-pattern-development/.
Um requisito importante para todo sistema operacional empresarial é o nível de suporte que você recebe do ambiente. Os módulos do Kernel são o conector mais relevante entre o hardware (“controladoras”) e o sistema operacional. Cada módulo do Kernel no SUSE Linux Enterprise possui um flag supported (suportado) que pode ter três valores:
“yes (sim)”, portanto, suportado
“externo”, portanto, suportado
“” (vazio, não definido) e unsupported (não suportado)
As seguintes regras são válidas:
Por padrão, todos os módulos de um Kernel autorrecompilado são marcados como não suportados.
Os módulos do Kernel suportados pelos parceiros do SUSE e distribuídos pelo SUSE SolidDriver Program são marcados como “externos”.
Se o flag supported não estiver definido, o carregamento do módulo contaminará o Kernel. Kernels contaminados não são suportados. Os módulos do Kernel não suportados estão incluídos em um pacote RPM adicional (kernel-TIPO-extra) e não são carregados por padrão (TIPO=default|xen|...). Esses módulos não suportados também não estão disponíveis no instalador, e o pacote kernel-TIPO-extra não faz parte da mídia do SUSE Linux Enterprise.
Os módulos do Kernel não incluídos em uma licença compatível com a licença do Kernel do Linux também contaminarão o Kernel. Para obter detalhes, consulte /usr/src/linux/Documentation/sysctl/kernel.txt e o estado de /proc/sys/kernel/tainted.
Kernel do Linux: O valor de /proc/sys/kernel/unsupported usa o padrão 2 no SUSE Linux Enterprise 12 (do not warn in syslog when loading unsupported modules, não avisar no syslog ao carregar módulos não suportados). Esse padrão é usado no instalador e no sistema instalado. Consulte /usr/src/linux/Documentation/sysctl/kernel.txt para obter mais informações.
modprobe: O utilitário modprobe de verificação de dependências de módulos e carregamento dos módulos apropriados confirma se o valor do flag é supported (suportado). Se o valor for “sim” ou “externo”, o módulo será carregado, do contrário, não. Para obter informações sobre como anular este comportamento, consulte a Seção 2.5.2, “Trabalhando com módulos não suportados”.
Em geral, o SUSE não suporta a remoção de módulos de armazenamento por modprobe -r.
Embora a capacidade de suporte geral seja importante, algumas situações podem exigir o carregamento de um módulo não suportado (por exemplo, para fins de teste ou depuração, ou se o fornecedor de hardware disponibilizar um hotfix).
Para anular o padrão, edite /etc/modprobe.d/10-unsupported-modules.conf e mude o valor da variável allow_unsupported_modules
para 1. Se for necessário um módulo não suportado no initrd, lembre-se de executar dracut para atualizar o initrd.
-f
Para apenas tentar carregar um módulo uma vez, é possível usar a opção --allow-unsupported-modules com modprobe. Para obter mais informações, consulte a página de manual de modprobe.
Durante a instalação, módulos não suportados podem ser adicionados por meio de discos de atualização de driver, e eles serão carregados. Para impor o carregamento de módulos não suportados durante a inicialização e posteriormente, use a opção de linha de comando do Kernel oem-modules. Durante a instalação e inicialização do pacote suse-module-tools, o flag do Kernel TAINT_NO_SUPPORT (/proc/sys/kernel/tainted) será avaliado. Se o Kernel já foi contaminado, allow_unsupported_modules será habilitado. Isso impede que módulos não suportados acessem o sistema que está sendo instalado. Se não houver nenhum módulo não suportado durante a instalação e não for usada a outra opção de linha de comando especial do Kernel (oem-modules=1), o padrão ainda será de não permitir módulos não suportados.
Lembre-se de que carregar e executar módulos não suportados tornam o Kernel e todo o sistema não suportados pelo SUSE.
man supportconfig: A página de manual de supportconfig.
man supportconfig.conf: A página de manual do arquivo de configuração supportconfig.
man scatool: A página de manual de scatool.
man scadb: A página de manual de scadb.
man setup-sca: A página de manual de setup-sca.
https://mariadb.com/kb/en/: A documentação do MariaDB.
http://www.suse.com/communities/conversations/sca-pattern-development/: Instruções sobre como criar (e testar) seus próprios padrões da SCA.
http://www.suse.com/communities/conversations/basic-server-health-check-supportconfig/: Uma verificação da saúde básica do servidor com o supportconfig.
https://www.novell.com/communities/coolsolutions/cool_tools/create-your-own-supportconfig-plugin/: Criar seu próprio plug-in Supportconfig.
http://www.suse.com/communities/conversations/creating-a-central-supportconfig-repository/: Criar um repositório central do Supportconfig.