Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Linux Enterprise Desktop / Guia de Administração / Solução de problemas / Reunindo informações do sistema para suporte
Aplica-se a SUSE Linux Enterprise Desktop 15 SP6

41 Reunindo informações do sistema para suporte

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 Suporte 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 em 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 essa finalidade, o SUSE Linux Enterprise Desktop oferece uma aplicação e uma ferramenta de linha de comando para Supportconfig Analysis (SCA).

41.1 Exibindo informações atuais do sistema

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:

Exemplo 41.1: Saída de hostinfo ao efetuar login como root
Welcome to SUSE Linux Enterprise Server 15 SP2 Snapshot8 (x86_64) - Kernel \r (\l).


Distribution:             SUSE Linux Enterprise Server 15 SP6
Current As Of:            Mon 11 March 2024 10:11:51 AM CET
Hostname:                 localhost
Kernel Version:           6.4.0-150600.9-default
 Architecture:            x86_64
 Installed:               Fri 08 March 2024 04:45:50 PM CET
 Status:                  Not Tainted
Last Installed Package:   Mon 11 March 2024 10:02:13 AM CET
 Patches Needed:          0
 Security:                0
 3rd Party Packages:      6
Network Interfaces
 eth0:                    192.168.2/24 2002:c0a8:20a::/64
Memory
 Total/Free/Avail:        7.4Gi/6.4Gi/6.8Gi (91% Avail)
CPU Load Average:         7 (3%) with 2 CPUs

Caso a saída apresente o kernel com status tainted (contaminado), consulte a Seção 41.6, “Suporte aos módulos do kernel” para ver mais detalhes.

41.2 Coletando informações do sistema com o supportconfig

Para criar um arquivo TAR com informações detalhadas do sistema que você pode enviar ao Suporte Técnico Global, use:

  • o comando supportconfig ou

  • o módulo de Suporte do YaST.

A ferramenta de linha de comando está incluída no pacote supportutils, que é instalado por padrão. O módulo de Suporte do YaST também é baseado na ferramenta de linha de comando.

Determinados pacotes integram os plug-ins Supportconfig. Quando o Supportconfig for executado, todos os plug-ins também serão executados e criarão um ou mais arquivos de resultados para o TAR. A vantagem é que apenas os tópicos com um plug-in específico são verificados. Os plug-ins do Supportconfig são armazenados no diretório /usr/lib/supportconfig/plugins/.

41.2.1 Criando um número de solicitação de serviço

É 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 https://scc.suse.com/support/requests e siga as instruções na tela. Anote o número da solicitação de serviço.

Nota
Nota: Declaração de privacidade

A SUSE trata os relatórios do sistema como dados confidenciais. Para ver detalhes do nosso compromisso de privacidade, acesse https://www.suse.com/company/policies/privacy/.

41.2.2 Destinos de upload

Após criar um número de solicitação de serviço, você poderá fazer upload dos arquivos do Supportconfig para o Suporte Técnico Global, conforme descrito no Procedimento 41.1, “Enviando informações ao suporte com o YaST” ou no Procedimento 41.2, “Enviando informações ao suporte por linha de comando”. Use um dos seguintes destinos de upload:

Você também pode anexar o armazenamento TAR manualmente à sua solicitação de serviço usando o URL da solicitação de serviço: https://scc.suse.com/support/requests.

41.2.3 Criando um arquivo supportconfig com o YaST

Para usar o YaST para coletar informações do sistema, faça o seguinte:

  1. Inicie o YaST e abra o módulo de Suporte.

    Image
  2. Clique em Criar relatório em arquivo tarball.

  3. Na janela seguinte, selecione uma das opções do Supportconfig na lista de botões de opção. Por padrão, a opção Usar Configurações (Técnicas) Personalizadas está pré-selecionada. Para testar primeiro a função de relatório, use Reunir apenas uma quantidade mínima de informações. Para obter mais informações sobre outras opções, consulte a página de manual de supportconfig.

    Clique em Avançar.

  4. Digite suas informações de contato. Elas são gravadas no arquivo basic-environment.txt e incluídas no arquivo criado.

  5. Para enviar o arquivo ao Suporte Técnico Global, insira as Informações de Upload necessárias. O YaST propõe um servidor de upload automaticamente. Para modificá-lo, consulte a Seção 41.2.2, “Destinos de upload” para saber os detalhes dos servidores de upload que estão disponíveis.

    Para enviar o arquivo mais tarde, deixe o campo Informações de Upload vazio.

  6. Clique em Próximo para iniciar o processo de coleta de informações.

    Image

    Quando o processo for concluído, clique em Próximo.

  7. Para revisar os dados coletados, selecione o arquivo desejado em Nome do Arquivo para ver seu conteúdo no YaST. Para remover um arquivo do armazenamento TAR antes de enviá-lo ao suporte, use Remover dos Dados. Clique em Próximo.

  8. Grave o armazenamento TAR. Se você iniciou o módulo do YaST como usuário root, o YaST exibe um prompt para gravar o armazenamento em /var/log (ou em seu diretório pessoal). O formato do nome do arquivo é scc_HOST_DATE_TIME.tbz.

  9. Para fazer upload do arquivo diretamente para o suporte, verifique se a opção Fazer upload do tarball de arquivos de registro para URL está ativada. O Destino do Upload mostrado aqui é o mesmo sugerido pelo YaST na Passo 5. Para modificar o destino do upload, verifique os servidores de upload que estão disponíveis na Seção 41.2.2, “Destinos de upload”.

  10. Para ignorar o upload, desative a opção Fazer upload do tarball de arquivos de registro para URL.

  11. Confirme as mudanças para fechar o módulo do YaST.

41.2.4 Criando um arquivo supportconfig da linha de comando

O seguinte procedimento mostra como criar um arquivo do Supportconfig, mas sem o enviar diretamente ao suporte. Para fazer seu upload, é necessário executar o comando com algumas opções, conforme descrito no Procedimento 41.2, “Enviando informações ao suporte por linha de comando”.

  1. Abra um shell e mude para root.

  2. Executar supportconfig. Basta executar essa ferramenta sem nenhuma opção. No entanto, as opções mais comuns são exibidas na seguinte lista:

    -E MAIL, -N NAME, -O COMPANY, -P PHONE

    Define os dados de contato: endereço de e-mail (-E), nome da empresa (-O), seu nome (-N) e seu número de telefone (-P).

    -i KEYWORDS, -F

    Limita os recursos que serão verificados. O espaço reservado KEYWORDS é uma lista separada por vírgulas de palavras-chave com distinção entre maiúsculas e minúsculas. Execute o comando supportconfig -F para obter uma lista de todas as palavras-chave.

    -r SRNUMBER

    Define o número da solicitação de serviço durante o upload do arquivo TAR gerado.

  3. Aguarde a ferramenta concluir a operação.

  4. O local padrão do armazenamento é /var/log, com o formato de nome de arquivo scc_HOST_DATE_TIME.tbz

41.2.5 Compreendendo a saída do supportconfig

Se você executar o supportconfig pelo YaST ou diretamente, o script lhe apresentará um resumo do que foi feito.

                     Support Utilities - Supportconfig
                          Script Version: 3.0-98 
                          Script Date: 2017 06 01
[...]
Gathering system information
  Data Directory:    /var/log/scc_d251_180201_1525 1

  Basic Server Health Check...                 Done 2
  RPM Database...                              Done 2
  Basic Environment...                         Done 2
  System Modules...                            Done 2
[...]
  File System List...                          Skipped 3
[...]
  Command History...                           Excluded 4
[...]
  Supportconfig Plugins:                       1 5
    Plugin: pstree...                          Done
[...]
Creating Tar Ball

==[ DONE ]===================================================================
  Log file tar ball: /var/log/scc_d251_180201_1525.txz 6
  Log file size:     732K
  Log file md5sum:   bf23e0e15e9382c49f92cbce46000d8b
=============================================================================

1

O diretório de dados temporários para armazenar os resultados. Esse diretório é armazenado como um arquivo tar. Consulte 6.

2

O recurso foi habilitado (por padrão ou selecionado manualmente) e executado com êxito. O resultado é armazenado em um arquivo (consulte a Tabela 41.1, “Comparação de recursos e nomes de arquivo no TAR”).

3

O recurso foi ignorado porque foram mudados arquivos de um ou mais pacotes RPM.

4

O recurso foi excluído porque ele foi desmarcado por meio da opção -x.

5

O script encontrou um plug-in e executa o plug-in pstree. O plug-in foi encontrado no diretório /usr/lib/supportconfig/plugins/. Consulte a página de manual para obter detalhes.

6

O nome do arquivo tar do armazenamento, por padrão, compactado com xz.

41.2.6 Opções comuns do supportconfig

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 dos casos de uso comuns:

Reduzindo o tamanho das informações coletadas

Usar a opção mínima (-m):

> sudo supportconfig -m
Limitando as informações a determinado tópico

Se você já localizou um problema relacionado apenas à determinada área ou conjunto de recursos, convém limitar as informações coletadas à área específica na próxima execução do supportconfig. Por exemplo, se você detectou problemas com a LVM e deseja testar uma mudança recente que você fez na configuração da LVM. Nesse caso, convém coletar as informações mínimas do Supportconfig apenas sobre a LVM:

> sudo supportconfig -i LVM

É possível separar as palavras-chave adicionais com vírgulas. Por exemplo, um teste de disco adicional:

> sudo supportconfig -i LVM,DISK

Para ver a lista completa de palavras-chave de recursos que você pode usar para limitar as informações coletadas a determinada área, execute:

> sudo supportconfig -F
Incluindo informações de contato adicionais na saída:
> sudo supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...

(tudo em uma linha)

Coletando os arquivos de registro que já foram girados
> sudo 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.

41.2.7 Visão geral do conteúdo do arquivo

O arquivo TAR contém todos os resultados dos recursos. É possível limitar o conjunto de recursos por meio da opção -i (consulte a Seção 41.2.6, “Opções comuns do supportconfig”).

Para listar o conteúdo do arquivo, use o seguinte comando tar:

# tar xf /var/log/scc_earth_180131_1545.tbz

Os seguintes nomes de arquivo sempre estão disponíveis no arquivo TAR:

Arquivos mínimos no armazenamento
basic-environment.txt

Contém a data em que este script foi executado e informações do sistema, como versão da distribuição, informações do hipervisor, etc.

basic-health-check.txt

Contém verificações básicas de saúde, como tempo de atividade, estatísticas de memória virtual, memória livre e disco rígido, verifica se há processos zumbis etc.

hardware.txt

Contém verificações básicas de hardware, como informações sobre a arquitetura da CPU, lista de todos os hardwares conectados, interrupções, portas de E/S, mensagens de boot do kernel, etc.

messages.txt

Contém mensagens de registro do diário do sistema.

rpm.txt

Contém uma lista de todos os pacotes RPM instalados, o nome, a origem e as versões deles.

summary.xml

Contém informações no formato XML, como distribuição, versão e fragmentos específicos do produto.

supportconfig.txt

Contém informações sobre o próprio script supportconfig.

y2log.txt

Contém informações específicas do YaST, como pacotes específicos, arquivos de configuração e arquivos de registro.

A Tabela 41.1, “Comparação de recursos e nomes de arquivo no TAR” lista todos os recursos disponíveis e seus nomes de arquivo. Outros pacotes de serviço podem estender a lista, assim como os plug-ins.

Tabela 41.1: Comparação de recursos e nomes de arquivo no TAR
RecursoNome do arquivo
APPARMORsecurity-apparmor.txt
AUDITsecurity-audit.txt
AUTOFSfs-autofs.txt
BOOTboot.txt
BTRFSfs-btrfs.txt
DAEMONSsystemd.txt
CIMOMcimom.txt
CRASHcrash.txt
CRONcron.txt
DHCPdhcp.txt
DISKfs-diskio.txt
DNSdns.txt
DOCKERdocker.txt
DRBDdrbd.txt
ENVenv.txt
ETCetctxt
HAha.txt
HAPROXYhaproxy.txt
HISTORYshell_history.txt
IBib.txt
IMANnovell-iman.txt
ISCSIfs-iscsi.txt
LDAPldap.txt
LIVEPATCHkernel-livepatch.txt
LVMlvm.txt
MEMmemory.txt
MODmodules.txt
MPIOmpio.txt
NETnetwork-*.txt
NFSnfs.txt
NTPntp.txt
NVMEnvme.txt
OCFS2ocfs2.txt
OFILESopen-files.txt
PRINTprint.txt
PROCproc.txt
SARsar.txt
SLERTslert.txt
SLPslp.txt
SMTsmt.txt
SMARTfs-smartmon.txt
SMBsamba.txt
SRAIDfs-softraid.txt
SSHssh.txt
SSSDsssd.txt
SYSCONFIGsysconfig.txt
SYSFSsysfs.txt
TRANSACTIONALtransactional-update.txt
TUNEDtuned.txt
UDEVudev.txt
UFILESfs-files-additional.txt
UPupdates.txt
WEBweb.txt
Xx.txt

41.3 Enviando informações ao suporte técnico global

Use o módulo de Suporte 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 41.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 41.2.1, “Criando um número de solicitação de serviço”.

Procedimento 41.1: Enviando informações ao suporte com o YaST

O seguinte procedimento considera que você já tenha criado um arquivo 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 41.2.3, “Criando um arquivo supportconfig com o YaST”, Passo 4. Para ver instruções de como gerar e enviar de uma só vez um arquivo Supportconfig, consulte a Seção 41.2.3, “Criando um arquivo supportconfig com o YaST”.

  1. Inicie o YaST e abra o módulo de Suporte.

  2. Clique em Fazer Upload.

  3. Em Pacote com arquivos de registro, especifique o caminho para o arquivo Supportconfig existente ou use a opção Procurar.

  4. O YaST propõe um servidor de upload automaticamente. Para modificá-lo, consulte a Seção 41.2.2, “Destinos de upload” para saber os detalhes dos servidores de upload que estão disponíveis.

    Image

    Continue com Próximo.

  5. Clique em Concluir.

Procedimento 41.2: Enviando informações ao suporte por linha de comando

O seguinte procedimento considera que você já tenha criado um arquivo Supportconfig, mas ainda não tenha feito upload dele. Para ver instruções de como gerar e enviar de uma só vez um arquivo Supportconfig, consulte a Seção 41.2.3, “Criando um arquivo supportconfig com o YaST”.

  1. Servidores com conectividade à Internet:

    1. Para usar o destino de upload padrão, execute:

      > sudo supportconfig -ur 12345678901
    2. Para o destino de upload seguro, use o seguinte:

      > sudo supportconfig -ar 12345678901
  2. Servidores sem conectividade à Internet

    1. Execute o seguinte:

      > sudo supportconfig -r 12345678901
    2. Faça upload manualmente do armazenamento /var/log/scc_SR12345678901*tbz para um dos nossos servidores FTP. O servidor que deverá ser usado depende da sua localização global. Para uma visão geral, consulte a Seção 41.2.2, “Destinos de upload”.

  3. 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.

41.4 Analisando as informações do sistema

É possível analisar os relatórios do sistema criados com o supportconfig para ver se há problemas conhecidos e agilizar sua solução. Para essa 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 incluída no pacote sca-server-report) é executada no lado do cliente e por linha de comando. As duas ferramentas analisam os arquivos 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 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 arquivo Supportconfig referente a um problema conhecido. Os padrões estão disponíveis como pacotes RPM.

É possível também desenvolver seus próprios padrões, conforme descrito resumidamente na Seção 41.4.3, “Desenvolvendo padrões de análise personalizados”.

41.4.1 Ferramenta de linha de comando SCA

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 41.1, “Relatório HTML gerado pela ferramenta SCA”.

Relatório HTML gerado pela ferramenta SCA
Figura 41.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 arquivo TAR supportconfig existente ou deixar que ela gere e analise um novo arquivo de uma vez. A ferramenta também oferece um console interativo com complementação de guia. É possível executar o supportconfig em uma máquina externa e realizar as análises subsequentes na máquina local.

Veja alguns comandos de exemplo abaixo:

sudo scatool-s

Chama o supportconfig e gera um novo arquivo 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. Ele é gravado no mesmo diretório do armazenamento Supportconfig.

sudo scatool -s -o /opt/sca/reports/ 

Igual a sudo scatool -s, exceto que o relatório HTML é gravado no caminho especificado com -o.

sudo scatool -a PATH_TO_TARBALL_OR_DIR 

Analisa o arquivo de armazenamento Supportconfig especificado (ou o diretório indicado no qual o arquivo Supportconfig foi extraído). O relatório HTML gerado é gravado no mesmo local do arquivo ou diretório do Supportconfig.

sudo scatool -a SLES_SERVER.COMPANY.COM 

Estabelece uma conexão SSH com um servidor externo SLES_SERVER.COMPANY.COM e executa o supportconfig no servidor. Em seguida, o arquivo 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 SLES_SERVER.COMPANY.COM.)

sudo scatool-c

Inicia o console interativo da scatool. Pressione →| duas vezes para ver os comandos disponíveis.

Para obter mais informações e opções, execute sudo scatool -h ou consulte a página de manual do scatool.

41.4.2 Aplicação SCA

Se você usar a aplicação SCA para analisar arquivos Supportconfig, configure 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 arquivos 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 arquivos 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 arquivos 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 41.4.2.5.4, “Enviando relatórios da SCA por e-mail”.

41.4.2.1 Inicialização Rápida da instalação

Para instalar e configurar rapidamente a aplicação SCA por linha de comando, siga as instruções neste documento. O procedimento é voltado 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 41.4.2.2, “Pré-requisitos” até a Seção 41.4.2.3, “Instalação e configuração básica”.

Pré-requisitos
  • 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).

Nota
Nota: Privilégios de root necessários

Todos os comandos do procedimento a seguir devem ser executados como root.

Procedimento 41.3: Instalação usando FTP anônimo para upload

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 arquivos Supportconfig.

  1. Na máquina de instalação da aplicação, efetue login no console e execute os seguintes comandos (certifique-se de aceitar os pacotes recomendados):

    > sudo zypper install sca-appliance-* sca-patterns-* \
    vsftpd yast2 yast2-ftp-server
    > sudo systemctl enable apache2
    > sudo systemctl start apache2
    > sudo systemctl enable vsftpd
    > sudo systemctl start vsftpd
    > sudo yast ftp-server
  2. No Servidor FTP do YaST, selecione Autenticação › Habilitar Upload › Anônimo Pode Fazer Upload › Concluir › Sim para Criar /srv/ftp/upload.

  3. Execute os seguintes comandos:

    > sudo systemctl enable mysql
    > sudo systemctl start mysql
    > sudo mysql_secure_installation
    > sudo setup-sca -f

    A mysql_secure_installation cria uma senha de root do MariaDB.

Procedimento 41.4: Instalação usando SCP/tmp para upload

Esta forma de configurar a aplicação requer interação manual para digitar a senha SSH.

  1. Na máquina de instalação da aplicação, efetue login no console.

  2. Execute os seguintes comandos:

    > sudo zypper install sca-appliance-* sca-patterns-*
    > sudo systemctl enable apache2
    > sudo systemctl start apache2
    > sudo sudo systemctl enable mysql
    > sudo systemctl start mysql
    > sudo mysql_secure_installation
    > sudo setup-sca

41.4.2.2 Pré-requisitos

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. Além disso, qualquer um dos sca-patterns-* específicos do produto, de acordo com o tipo de arquivo Supportconfig que você deseja analisar com a aplicação.

  • Apache

  • PHP

  • MariaDB

  • Servidor FTP anônimo (opcional)

41.4.2.3 Instalação e configuração básica

Conforme listado na Seção 41.4.2.2, “Pré-requisitos”, a aplicação SCA possui várias dependências em outros pacotes. Portanto, você precisa seguir as etapas preparatórias antes de instalar e configurar o servidor da aplicação SCA:

  1. No Apache e no MariaDB, instale os padrões de instalação da Web e LAMP.

  2. Configure o Apache, o MariaDB e, opcionalmente, um servidor FTP anônimo.

  3. Configure o Apache e o MariaDB para iniciarem no momento da inicialização:

    > sudo systemctl enable apache2 mysql
  4. Inicie os dois serviços:

    > sudo systemctl start apache2 mysql

Agora você pode instalar a aplicação SCA e configurá-la conforme descrito no Procedimento 41.5, “Instalando e configurando a aplicação SCA”.

Procedimento 41.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 arquivos Supportconfig de suas máquinas para a aplicação SCA:

  • scp

  • servidor FTP anônimo

  1. Instale a aplicação e a biblioteca de padrões com base na SCA:

    > sudo zypper install sca-appliance-* sca-patterns-base
  2. Instale também os pacotes de padrões de acordo com os tipos de arquivos Supportconfig que você deseja analisar. Por exemplo, se você tem servidores SUSE Linux Enterprise Server 12 e SUSE Linux Enterprise Server 15 em seu ambiente, instale os dois pacotes sca-patterns-sle12 e sca-patterns-sle15.

    Para instalar todos os padrões disponíveis:

    > sudo zypper install sca-patterns-*
  3. 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 arquivos Supportconfig para o servidor da aplicação SCA:

    • Se você configurou um servidor FTP anônimo que usa o diretório /srv/ftp/upload, execute o script de configuração com a opção -f. Siga as instruções na tela:

      > sudo setup-sca -f
      Nota
      Nota: Servidor FTP que usa outro diretório

      Se o servidor FTP usar um diretório diferente de /srv/ftp/upload, ajuste os seguintes arquivos de configuração primeiro para que eles apontem 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. Siga as instruções na tela:

      > sudo setup-sca

    O script de configuração executa algumas verificações referentes a seus requisitos e configura os componentes 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.

  4. Digite a senha de root existente do MariaDB. Isso permite que a aplicação SCA se conecte com o MariaDB.

  5. 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 para o usuário scdiag. Tanto o nome de usuário quanto a senha podem ser mudados a qualquer momento. Consulte a Seção 41.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 41.4.2.4, “Usando a aplicação SCA”. No entanto, você deve modificar 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 41.4.2.5, “Personalizando a aplicação SCA”.

Atenção
Atenção: Proteção de dados;

Como os relatórios no servidor da aplicação SCA incluem informações relacionadas à segurança, proteja os dados no servidor da aplicação SCA contra acesso não autorizado.

41.4.2.4 Usando a aplicação SCA

É possível fazer upload dos arquivos Supportconfig existentes para a aplicação SCA manualmente ou criar novos arquivos 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 41.5, “Instalando e configurando a aplicação SCA”.

41.4.2.4.1 Fazendo upload de arquivos supportconfig para a aplicação SCA
  • Para criar um arquivo Supportconfig e fazer upload dele por FTP (anônimo):

    > sudo supportconfig -U “ftp://SCA-APPLIANCE.COMPANY.COM/upload”
  • Para criar um arquivo Supportconfig e fazer upload dele 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 (localizados em /var/log/scc_*.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 o FTP estiver configurado para o servidor da aplicação SCA).

41.4.2.4.2 Vendo relatórios da 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.

  1. Inicie o browser da Web e verifique se o JavaScript e os cookies estão habilitados.

  2. 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.

  3. Você deverá informar o nome de usuário e a senha para efetuar login.

    Relatório HTML gerado pela aplicação SCA
    Figura 41.2: Relatório HTML gerado pela aplicação SCA
  4. Após o login, clique na data do relatório que deseja ler.

  5. Clique primeiro na categoria Basic Health (Saúde Básica) para expandi-la.

  6. Na coluna Message (Mensagem), clique em uma entrada. O artigo correspondente é aberto na Base de Dados de Conhecimento SUSE. Leia a solução proposta e siga as instruções.

  7. Se a coluna Solutions (Soluções) do Relatório da Supportconfig Analysis mostrar qualquer outra entrada, clique nela. Leia a solução proposta e siga as instruções.

  8. Consulte a Base de Dados de Conhecimento SUSE (https://www.suse.com/support/kb/) para ver resultados diretamente relacionados ao problema identificado pela SCA. Resolva o problema.

  9. Procure resultados que possam ser usados proativamente para evitar futuros problemas.

41.4.2.5 Personalizando a aplicação SCA

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.

41.4.2.5.1 Senha da interface da Web

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 41.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.

Procedimento 41.6: Mudando nome de usuário ou senha da interface da Web
  1. Efetue login como usuário root no console do sistema do servidor da aplicação SCA.

  2. Abra o /srv/www/htdocs/sca/web-config.php em um editor.

  3. Mude os valores de $username e $password conforme desejado.

  4. Grave o arquivo e saia.

41.4.2.5.2 Atualizações dos padrões da SCA

Por padrão, todos os pacotes sca-patterns-* são atualizados regularmente por um 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 15 SP6. Você poderá mudar a fonte das atualizações para um servidor RMT, 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 RMT, os pacotes serão acessados de lá.

Procedimento 41.7: Desabilitando atualizações automáticas dos padrões da SCA
  1. Efetue login como usuário root no console do sistema do servidor da aplicação SCA.

  2. Abra o /etc/sca/sdagent-patterns.conf em um editor.

  3. Mudar a entrada

    UPDATE_FROM_PATTERN_REPO=1

    para

    UPDATE_FROM_PATTERN_REPO=0
  4. Grave o arquivo e saia. Não é necessário reiniciar a máquina para aplicar a mudança.

41.4.2.5.3 Modo de arquivamento

Todos os arquivos 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 arquivos Supportconfig de uma máquina. Por padrão, o modo de arquivamento está desabilitado.

Procedimento 41.8: Habilitando o modo de arquivamento na aplicação SCA
  1. Efetue login como usuário root no console do sistema do servidor da aplicação SCA.

  2. Abra o /etc/sca/sdagent.conf em um editor.

  3. Mudar a entrada

    ARCHIVE_MODE=0

    para

    ARCHIVE_MODE=1
  4. 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.

41.4.2.5.4 Enviando relatórios da SCA por e-mail

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, você pode definir uma lista de endereços de e-mail para os quais os relatórios devem ser enviados. Defina um nível de mensagens de status que acione o envio de relatórios (STATUS_NOTIFY_LEVEL).

Valores possíveis para STATUS_NOTIFY_LEVEL
$STATUS_OFF

Desativar o envio de relatórios HTML.

$STATUS_CRITICAL

Enviar apenas relatórios da SCA que incluam CRITICAL (Crítico).

$STATUS_WARNING

Enviar apenas relatórios da SCA que incluam WARNING (Aviso) ou CRITICAL.

$STATUS_RECOMMEND

Enviar apenas relatórios da SCA que incluam RECOMMEND (Recomendado), WARNING ou CRITICAL.

$STATUS_SUCCESS

Enviar relatórios da SCA que incluam SUCCESS (Êxito), RECOMMEND, WARNING ou CRITICAL.

Procedimento 41.9: Configurando notificações por e-mail para relatórios da SCA
  1. Efetue login como usuário root no console do sistema do servidor da aplicação SCA.

  2. Abra o /etc/sca/sdagent.conf em um editor.

  3. Pesquise a entrada STATUS_NOTIFY_LEVEL. Por padrão, ela está definida como $STATUS_OFF (notificações por e-mail desabilitadas).

  4. 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 a Valores possíveis para STATUS_NOTIFY_LEVEL.

  5. Para definir a lista de destinatários que devem receber os relatórios:

    1. Pesquise a entrada EMAIL_REPORT='root'.

    2. 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'
  6. 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.

41.4.2.6 Fazendo backup e restaurando o banco de dados

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. O scadb está incluído no pacote sca-appliance-broker.

Procedimento 41.10: Fazendo backup do banco de dados
  1. Efetue login como usuário root no console do sistema do servidor que executa a aplicação SCA.

  2. Coloque a aplicação no modo de manutenção executando:

    # scadb maint
  3. Inicie o backup com:

    # scadb backup

    Os dados são gravados em um armazenamento TAR: sca-backup-*sql.gz.

  4. Se você usa o banco de dados de criação de padrões para desenvolver seus próprios padrões (consulte a Seção 41.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.

  5. 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)

  6. Ative novamente a aplicação SCA com:

    # scadb reset agents
Procedimento 41.11: Restaurando o banco de dados

Para restaurar o banco de dados do backup, faça o seguinte:

  1. Efetue login como usuário root no console do sistema do servidor que executa a aplicação SCA.

  2. Copie os arquivos TAR sca-backup-*sql.gz e sdp-backup-*sql.gz mais recentes para o servidor da aplicação SCA.

  3. Para descompactar os arquivos, execute:

    # gzip -d *-backup-*sql.gz
  4. Para importar os dados para o banco de dados, execute:

    # scadb import sca-backup-*sql
  5. 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
  6. Se você usa padrões personalizados, restaure também /usr/lib/sca/patterns/local dos dados do backup.

  7. Ative novamente a aplicação SCA com:

    # scadb reset agents
  8. Atualize os módulos de padrão no banco de dados com:

    # sdagent-patterns -u

41.4.3 Desenvolvendo padrões de análise personalizados

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 definidos como executáveis. Tanto a aplicação quanto a ferramenta SCA executam os padrões personalizados nos novos arquivos 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 https://www.suse.com/c/sca-pattern-development/.

41.5 Coletando informações durante a instalação

Durante a instalação, o supportconfig não está disponível. No entanto, você pode coletar arquivos de registro do YaST usando save_y2logs. Esse comando criará um armazenamento .tar.xz no diretório /tmp.

Se aparecerem problemas no começo da instalação, talvez seja possível coletar informações do arquivo de registro criado por linuxrc. linuxrc é um comando pequeno que é executado antes de o YaST ser iniciado. Esse arquivo de registro está disponível em /var/log/linuxrc.log.

Importante
Importante: Arquivos de registro de instalação não disponíveis no sistema instalado

Os arquivos de registro disponíveis durante a instalação não estão mais disponíveis no sistema instalado. Grave apropriadamente os arquivos de registro de instalação enquanto o instalador ainda está em execução.

41.6 Suporte aos módulos do kernel

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:

  • sim, portanto supported

  • externo, portanto supported

  • (vazio, não definido), portanto unsupported

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 da 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-FLAVOR-extra). Esse pacote apenas está disponível para o SUSE Linux Enterprise Desktop e a SUSE Linux Enterprise Workstation Extension. Por padrão, esses kernels não são carregados (FLAVOR=default|xen|...). Além disso, esses módulos não suportados não estão disponíveis no instalador, e o pacote kernel-FLAVOR-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 Linux também contaminarão o kernel. Para obter detalhes, consulte o estado do /proc/sys/kernel/tainted.

41.6.1 Informações técnicas

  • Kernel Linux: O valor de /proc/sys/kernel/unsupported é padronizado como 2 no SUSE Linux Enterprise 15 SP6 (do not warn in syslog when loading unsupported modules). Esse padrão é usado no instalador e no sistema instalado.

  • 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. 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 41.6.2, “Trabalhando com módulos não suportados”.

    Nota
    Nota: Suporte

    Em geral, o SUSE não suporta a remoção de módulos de armazenamento por modprobe -r.

41.6.2 Trabalhando com módulos não suportados

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 seu fornecedor de hardware disponibilizar um hotfix.

  • Para anular o padrão, copie /lib/modprobe.d/10-unsupported-modules.conf para /etc/modprobe.d/10-unsupported-modules.conf e mude o valor da variável allow_unsupported_modules de 0 para 1. Não edite o /lib/modprobe.d/10-unsupported-modules.conf diretamente. As mudanças serão sobregravadas sempre que o pacote suse-module-tools for atualizado.

    Se for necessário um módulo não suportado no initrd, lembre-se de executar dracut -f para atualizar o initrd.

    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 os comentários em /lib/modprobe.d/10-unsupported-modules.conf e a página de manual do 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 a 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 módulos não suportados durante a instalação, e a outra opção de linha de comando especial do kernel (oem-modules=1) não for usada, o padrão ainda será de impedir 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.

41.7 Mais informações