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 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. Isso 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).
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:
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 SP2 Current As Of: Wed 25 Mar 2020 12:09:20 PM PDT Hostname: localhost Kernel Version: 5.3.18-8-default Architecture: x86_64 Installed: Thu 19 Mar 2020 11:25:13 AM PDT Status: Not Tainted Last Installed Package: Wed 25 Mar 2020 11:42:24 AM PDT Patches Needed: 0 Security: 0 3rd Party Packages: 219 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
ouo 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.
Dependendo dos pacotes instalados no sistema, alguns desses pacotes integrarão plug-ins do 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. O benefício desse recurso é que apenas os tópicos que contêm um plug-in específico para eles são marcados. 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.
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:
América do Norte: FTP ftp://support-ftp.us.suse.com/incoming/, FTPS ftps://support-ftp.us.suse.com/incoming/
EMEA, Europa, Oriente Médio e África: FTP ftp://support-ftp.emea.suse.com/incoming, FTPS ftps://support-ftp.emea.suse.com/incoming
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:
Inicie o YaST e abra o módulo de
.Clique em
.Na janela seguinte, selecione uma das opções do 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 mais informações sobre outras opções, consulte a página de manual desupportconfig
.Clique em
.Digite suas informações de contato. Elas são gravadas no arquivo
basic-environment.txt
e incluídas no arquivo criado.Para enviar o arquivo ao Suporte Técnico Global, insira as Seção 41.2.2, “Destinos de upload” para saber os detalhes dos servidores de upload que estão disponíveis.
necessárias. O YaST propõe um servidor de upload automaticamente. Para modificá-lo, consulte aPara enviar o arquivo mais tarde, deixe o campo
vazio.Clique em
para iniciar o processo de coleta de informações.Quando o processo for concluído, clique em
.Para revisar os dados coletados, selecione o arquivo desejado em
para ver seu conteúdo no YaST. Para remover um arquivo do armazenamento TAR antes de enviá-lo ao suporte, use . Clique em .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
.Para fazer upload do arquivo diretamente para o suporte, verifique se a opção 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”.
está ativada. O mostrado aqui é o mesmo sugerido pelo YaST naPara ignorar o upload, desative a opção
.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”.
Abra um shell e registre-se como
root
.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.
Aguarde a ferramenta concluir a operação.
O local padrão do armazenamento é
/var/log
, com o formato de nome de arquivoscc_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 =============================================================================
O diretório de dados temporários para armazenar os resultados. Esse diretório é armazenado como um arquivo tar. Consulte 6. | |
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 armazenamento TAR”). | |
O recurso foi ignorado porque foram mudados arquivos de um ou mais pacotes RPM. | |
O recurso foi excluído porque ele foi desmarcado por meio da opção | |
O script encontrou um plug-in e executa o plug-in | |
O nome do arquivo tar do armazenamento, por padrão, compactado com |
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,DISKPara 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 -lIsso é ú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. Dependendo do que você selecionou (tudo ou apenas um pequeno conjunto), o TAR pode conter mais ou menos arquivos. É 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:
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ções de 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 armazenamento 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.
Recurso | Nome do arquivo |
---|---|
APPARMOR | security-apparmor.txt |
AUDIT | security-audit.txt |
AUTOFS | fs-autofs.txt |
BOOT | boot.txt |
BTRFS | fs-btrfs.txt |
DAEMONS | systemd.txt |
CIMOM | cimom.txt |
CRASH | crash.txt |
CRON | cron.txt |
DHCP | dhcp.txt |
DISK | fs-diskio.txt |
DNS | dns.txt |
DOCKER | docker.txt |
DRBD | drbd.txt |
ENV | env.txt |
ETC | etctxt |
HA | ha.txt |
HAPROXY | haproxy.txt |
HISTORY | shell_history.txt |
IB | ib.txt |
IMAN | novell-iman.txt |
ISCSI | fs-iscsi.txt |
LDAP | ldap.txt |
LIVEPATCH | kernel-livepatch.txt |
LVM | lvm.txt |
MEM | memory.txt |
MOD | modules.txt |
MPIO | mpio.txt |
NET | network-*.txt |
NFS | nfs.txt |
NTP | ntp.txt |
NVME | nvme.txt |
OCFS2 | ocfs2.txt |
OFILES | open-files.txt |
print.txt | |
PROC | proc.txt |
SAR | sar.txt |
SLERT | slert.txt |
SLP | slp.txt |
SMT | smt.txt |
SMART | fs-smartmon.txt |
SMB | samba.txt |
SRAID | fs-softraid.txt |
SSH | ssh.txt |
SSSD | sssd.txt |
SYSCONFIG | sysconfig.txt |
SYSFS | sysfs.txt |
TRANSACTIONAL | transactional-update.txt |
TUNED | tuned.txt |
UDEV | udev.txt |
UFILES | fs-files-additional.txt |
UP | updates.txt |
WEB | web.txt |
X | x.txt |
41.3 Enviando informações ao suporte técnico global #
Use o módulo de 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”.
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”.
Inicie o YaST e abra o módulo de
.Clique em
.Em
, especifique o caminho para o arquivo Supportconfig existente ou use a opção .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.
Continue com
.Clique em
.
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”.
Servidores com conectividade à Internet:
Para usar o destino de upload padrão, execute:
>
sudo
supportconfig -ur 12345678901Para o destino de upload seguro, use o seguinte:
>
sudo
supportconfig -ar 12345678901
Servidores sem conectividade à Internet
Execute o seguinte:
>
sudo
supportconfig -r 12345678901Faç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”.
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 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
incluída no pacote sca-server-report) é executada no lado do cliente 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”.
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 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 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_DIRAnalisa 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.COMEstabelece 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 mais opções e informações, execute sudo scatool -h
ou consulte a página de manual de 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”.
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 arquivos Supportconfig.
Na máquina em que a aplicação será instalada, efetue login em um 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-serverNo Servidor FTP do YaST, selecione
› › › › para .Execute os seguintes comandos:
>
sudo
systemctl enable mysql>
sudo
systemctl start mysql>
sudo
mysql_secure_installation>
sudo
setup-sca -fA 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:
>
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 dossca-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 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
eLAMP
.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 mysqlInicie 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”.
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
Instale a aplicação e a biblioteca de padrões com base na SCA:
>
sudo
zypper install sca-appliance-* sca-patterns-baseInstale 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
esca-patterns-sle15
.Para instalar todos os padrões disponíveis:
>
sudo
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 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 -fNota: Servidor FTP que usa outro diretórioSe 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 comandoscp
, 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.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árioscdiag
. 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”.
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.
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.
Figura 41.2: Relatório HTML gerado pela aplicação SCA #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 na Base de Dados de Conhecimento SUSE. 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 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.
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.
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.
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 SP5. 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á.
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.
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.
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.
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, é possível definir uma lista de endereços de e-mail para os quais enviar os relatórios. Defina um nível de mensagens de status que aciona o envio dos relatórios (STATUS_NOTIFY_LEVEL
).
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.
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 a 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.
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.
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 maintInicie o backup com:
#
scadb backupOs 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 41.4.3, “Desenvolvendo padrões de análise personalizados”), faça backup também destes dados:
#
sdpdb backupOs 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
esdp-backup-*sql.gz
mais recentes para o servidor da aplicação SCA.Para descompactar os arquivos, execute:
#
gzip -d *-backup-*sql.gzPara importar os dados para o banco de dados, execute:
#
scadb import sca-backup-*sqlSe 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-*sqlSe 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 agentsAtualize 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 ser 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/blog/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
.
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
(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-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
|...). Esses módulos não suportados também não estão disponíveis no instalador, e o pacotekernel-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 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
.
41.6.1 Informações técnicas #
Kernel do Linux: o valor de
/proc/sys/kernel/unsupported
é padronizado como2
no SUSE Linux Enterprise 15 SP5 (do not warn in syslog when loading unsupported modules
). Esse padrão é usado no instalador e no sistema instalado. Consulte o/usr/src/linux/Documentation/sysctl/kernel.txt
para obter mais informações.modprobe
: O utilitáriomodprobe
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 41.6.2, “Trabalhando com módulos não suportados”.Nota: SuporteEm 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ávelallow_unsupported_modules
de0
para1
. 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
commodprobe
. Para obter mais informações, consulte os comentários em/lib/modprobe.d/10-unsupported-modules.conf
e a página de manual domodprobe
.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 pacotesuse-module-tools
, o flag do kernelTAINT_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.
41.7 Mais informações #
man supportconfig
: A página de manual dosupportconfig
.man supportconfig.conf
: A página de manual do arquivo de configuração Supportconfig.man scatool
: A página de manual doscatool
.man scadb
: A página de manual doscadb
.man setup-sca
: A página de manual dosetup-sca
.https://mariadb.com/kb/en/: A documentação do MariaDB.
https://www.suse.com/c/blog/sca-pattern-development/: Instruções sobre como criar (e testar) seus próprios padrões da SCA.
https://www.suse.com/c/blog/basic-server-health-check-supportconfig/: Uma verificação da saúde básica do servidor com o supportconfig.
https://community.microfocus.com/img/gw/groupwise/w/groupwise/34308/create-your-own-supportconfig-plugin: Criar seu próprio plug-in Supportconfig.
https://www.suse.com/c/blog/creating-a-central-supportconfig-repository/: Criar um repositório central do Supportconfig.