Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Server 설명서 / Administration Guide / Troubleshooting / Gathering system information for support
Applies to SUSE Linux Enterprise Server 15 SP6

47 Gathering system information for support

For a quick overview of all relevant system information of a machine, SUSE Linux Enterprise Server offers the hostinfo package. It also helps system administrators to check for tainted kernels (that are not supported) or any third-party packages installed on a machine.

In case of problems, a detailed system report may be created with either the supportconfig command line tool or the YaST Support module. Both collect information about the system such as: current kernel version, hardware, installed packages, partition setup, and much more. The result is a TAR archive of files. After opening a Service Request (SR), you can upload the TAR archive to Global Technical Support. It helps to locate the issue you reported and to assist you in solving the problem.

Additionally, you can analyze the supportconfig output for known issues to help resolve problems faster. For this purpose, SUSE Linux Enterprise Server provides both an appliance and a command line tool for Supportconfig Analysis (SCA).

47.1 Displaying current system information

For a quick and easy overview of all relevant system information when logging in to a server, use the package hostinfo. After it has been installed on a machine, the console displays the following information to any root user that logs in to this machine:

Example 47.1: Output of hostinfo when logging in as 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

In case the output shows a tainted kernel status, see Section 47.6, “Support of kernel modules” for more details.

47.2 Collecting system information with supportconfig

To create a TAR archive with detailed system information that you can hand over to Global Technical Support, use either:

  • the command supportconfig or,

  • the YaST Support module.

The command line tool is provided by the package supportutils which is installed by default. The YaST Support module is also based on the command line tool.

Certain packages integrate Supportconfig plug-ins. When Supportconfig is executed, all plug-ins are executed as well and create one or more result files for the archive. The benefit is that only topics with a specific plug-in are checked. Supportconfig plug-ins are stored in the directory /usr/lib/supportconfig/plugins/.

47.2.1 Creating a service request number

Supportconfig archives can be generated at any time. However, for handing over the Supportconfig data to Global Technical Support, you need to generate a service request number first. You need it to upload the archive to support.

To create a service request, go to https://scc.suse.com/support/requests and follow the instructions on the screen. Write down the service request number.

Note
Note: Privacy statement

SUSE treats system reports as confidential data. For details about our privacy commitment, see https://www.suse.com/company/policies/privacy/.

47.2.2 Upload targets

After having created a service request number, you can upload your Supportconfig archives to Global Technical Support as described in Procedure 47.1, “Submitting information to support with YaST” or Procedure 47.2, “Submitting information to support from command line”. Use one of the following upload targets:

Alternatively, you can manually attach the TAR archive to your service request using the service request URL: https://scc.suse.com/support/requests.

47.2.3 Creating a supportconfig archive with YaST

To use YaST to gather your system information, proceed as follows:

  1. Start YaST and open the Support module.

    Image
  2. Click Create report tarball.

  3. In the next window, select one of the Supportconfig options from the radio button list. Use Custom (Expert) Settings is preselected by default. To test the report function first, use Only gather a minimum amount of info. For additional information on the other options, refer to the supportconfig man page.

    Click Next.

  4. Enter your contact information. It is saved in the basic-environment.txt file and included in the created archive.

  5. To submit the archive to Global Technical Support, provide the required Upload Information. YaST automatically suggests an upload server. To modify it, refer to Section 47.2.2, “Upload targets” for details of which upload servers are available.

    To submit the archive later, leave the Upload Information empty.

  6. Click Next to start the information collection process.

    Image

    After the process is finished, click Next.

  7. To review the collected data, select the desired file from File Name to view its contents in YaST. To remove a file from the TAR archive before submitting it to support, use Remove from Data. Press Next.

  8. Save the TAR archive. If you started the YaST module as root user, YaST prompts to save the archive to /var/log (otherwise, to your home directory). The file name format is scc_HOST_DATE_TIME.tbz.

  9. To upload the archive to support directly, make sure Upload log files tarball to URL is activated. The Upload Target shown here is the one that YaST suggests in Step 5. To modify the upload target, check which upload servers are available in Section 47.2.2, “Upload targets”.

  10. To skip the upload, deactivate Upload log files tarball to URL.

  11. Confirm the changes to close the YaST module.

47.2.4 Creating a supportconfig archive from command line

The following procedure shows how to create a Supportconfig archive, but without submitting it to support directly. For uploading it, you need to run the command with certain options as described in Procedure 47.2, “Submitting information to support from command line”.

  1. Open a shell and become root.

  2. Run supportconfig. It is enough to run this tool without any options. However, the most common options are displayed in the following list:

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

    Sets your contact data: e-mail address (-E), company name (-O), your name (-N), and your phone number (-P).

    -i KEYWORDS, -F

    Limits the features to check. The placeholder KEYWORDS is a comma separated list of case-sensitive keywords. Get a list of all keywords with supportconfig -F.

    -r SRNUMBER

    Defines your service request number when uploading the generated TAR archive.

  3. Wait for the tool to complete the operation.

  4. The default archive location is /var/log, with the file name format being scc_HOST_DATE_TIME.tbz

47.2.5 Understanding the output of supportconfig

Whether you run supportconfig through YaST or directly, the script gives you a summary of what it did.

                     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

The temporary data directory to store the results. This directory is archived as tar file, see 6.

2

The feature was enabled (either by default or selected manually) and executed successfully. The result is stored in a file (see Table 47.1, “Comparison of features and file names in the TAR archive”).

3

The feature was skipped because files of one or more RPM packages were changed.

4

The feature was excluded because it was deselected via the -x option.

5

The script found one plug-in and executes the plug-in pstree. The plug-in was found in the directory /usr/lib/supportconfig/plugins/. See the man page for details.

6

The tar file name of the archive, by default compressed with xz.

47.2.6 Common supportconfig options

The supportconfig utility is usually called without any options. Display a list of all options with supportconfig -h or refer to the man page. The following list gives a brief overview of common use cases:

Reducing the size of the information being gathered

Use the minimal option (-m):

> sudo supportconfig -m
Limiting the information to a specific topic

If you have already localized a problem that relates to a specific area or feature set only, you should limit the collected information to the specific area for the next supportconfig run. For example, if you detected problems with LVM and want to test a recent change that you did to the LVM configuration. In that case it makes sense to gather the minimum Supportconfig information around LVM only:

> sudo supportconfig -i LVM

Additional keywords can be separated through commas. For example, an additional disk test:

> sudo supportconfig -i LVM,DISK

For a complete list of feature keywords that you can use for limiting the collected information to a specific area, run:

> sudo supportconfig -F
Including additional contact information in the output:
> sudo supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...

(all in one line)

Collecting already rotated log files
> sudo supportconfig -l

This is especially useful in high logging environments or after a kernel crash when syslog rotates the log files after a reboot.

47.2.7 Overview of the archive content

The TAR archive contains all the results from the features. The set of features can be limited through the -i option (see Section 47.2.6, “Common supportconfig options”).

To list the content of the archive, use the following tar command:

# tar xf /var/log/scc_earth_180131_1545.tbz

The following file names are always available inside the TAR archive:

Minimum files in archive
basic-environment.txt

Contains the date when this script was executed and system information like version of the distribution, hypervisor information, and more.

basic-health-check.txt

Contains basic health checks like uptime, virtual memory statistics, free memory and hard disk, checks for zombie processes, and more.

hardware.txt

Contains basic hardware checks like information about the CPU architecture, list of all connected hardware, interrupts, I/O ports, kernel boot messages, and more.

messages.txt

Contains log messages from the system journal.

rpm.txt

Contains a list of all installed RPM packages, the name, where they are coming from, and their versions.

summary.xml

Contains information in XML format like distribution, the version, and product specific fragments.

supportconfig.txt

Contains information about the supportconfig script itself.

y2log.txt

Contains YaST specific information like specific packages, configuration files, and log files.

Table 47.1, “Comparison of features and file names in the TAR archive” lists all available features and their file names. Further service packs can extend the list, as can plug-ins.

Table 47.1: Comparison of features and file names in the TAR archive
FeatureFile name
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
ETCetc.txt
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

47.3 Submitting information to Global Technical Support

Use the YaST Support module or the supportconfig command line utility to submit system information to the Global Technical Support. When you experience a server issue and want the support's assistance, you will need to open a service request first. For details, see Section 47.2.1, “Creating a service request number”.

The following examples use 12345678901 as a placeholder for your service request number. Replace 12345678901 with the service request number you created in Section 47.2.1, “Creating a service request number”.

Procedure 47.1: Submitting information to support with YaST

The following procedure assumes that you have already created a Supportconfig archive, but have not uploaded it yet. Make sure to have included your contact information in the archive as described in Section 47.2.3, “Creating a supportconfig archive with YaST”, Step 4. For instructions on how to generate and submit a Supportconfig archive in one go, see Section 47.2.3, “Creating a supportconfig archive with YaST”.

  1. Start YaST and open the Support module.

  2. Click Upload.

  3. In Package with log files specify the path to the existing Supportconfig archive or Browse for it.

  4. YaST automatically proposes an upload server. To modify it, refer to Section 47.2.2, “Upload targets” for details of which upload servers are available.

    Image

    Proceed with Next.

  5. Click Finish.

Procedure 47.2: Submitting information to support from command line

The following procedure assumes that you have already created a Supportconfig archive, but have not uploaded it yet. For instructions on how to generate and submit a Supportconfig archive in one go, see Section 47.2.3, “Creating a supportconfig archive with YaST”.

  1. Servers with Internet connectivity:

    1. To use the default upload target, run:

      > sudo supportconfig -ur 12345678901
    2. For the secure upload target, use the following:

      > sudo supportconfig -ar 12345678901
  2. Servers without Internet connectivity

    1. Run the following:

      > sudo supportconfig -r 12345678901
    2. Manually upload the /var/log/scc_SR12345678901*tbz archive to one of our FTP servers. Which one to use depends on your location in the world. For an overview, see Section 47.2.2, “Upload targets”.

  3. After the TAR archive arrives in the incoming directory of our FTP server, it becomes automatically attached to your service request.

47.4 Analyzing system information

System reports created with supportconfig can be analyzed for known issues to help resolve problems faster. For this purpose, SUSE Linux Enterprise Server provides both an appliance and a command line tool for Supportconfig Analysis (SCA). The SCA appliance is a server-side tool which is non-interactive. The SCA tool (scatool provided by the package sca-server-report) runs on the client-side and is executed from command line. Both tools analyze Supportconfig archives from affected servers. The initial server analysis takes place on the SCA appliance or the workstation on which scatool is running. No analysis cycles happen on the production server.

Both the appliance and the command line tool additionally need product-specific patterns that enable them to analyze the Supportconfig output for the associated products. Each pattern is a script that parses and evaluates a Supportconfig archive for one known issue. The patterns are available as RPM packages.

You can also develop your own patterns as briefly described in Section 47.4.3, “Developing custom analysis patterns”.

47.4.1 SCA command line tool

The SCA command line tool lets you analyze a local machine using both supportconfig and the analysis patterns for the specific product that is installed on the local machine. The tool creates an HTML report showing its analysis results. For an example, see Figure 47.1, “HTML report generated by SCA tool”.

HTML report generated by SCA tool
Figure 47.1: HTML report generated by SCA tool

The scatool command is provided by the sca-server-report package. It is not installed by default. Additionally, you need the sca-patterns-base package and any of the product-specific sca-patterns-* packages that matches the product installed on the machine where you want to run the scatool command.

Execute the scatool command either as root user or with sudo. When calling the SCA tool, either analyze an existing supportconfig TAR archive or let it generate and analyze a new archive in one go. The tool also provides an interactive console with tab completion. It is possible to run supportconfig on an external machine and to execute the subsequent analysis on the local machine.

Find a few example commands below:

sudo scatool-s

Calls supportconfig and generates a new Supportconfig archive on the local machine. Analyzes the archive for known issues by applying the SCA analysis patterns that match the installed product. Displays the path to the HTML report that is generated from the results of the analysis. It is written to the same directory where the Supportconfig archive can be found.

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

Same as sudo scatool -s, only that the HTML report is written to the path specified with -o.

sudo scatool -a PATH_TO_TARBALL_OR_DIR 

Analyzes the specified Supportconfig archive file (or the specified directory to where the Supportconfig archive has been extracted). The generated HTML report is saved in the same location as the Supportconfig archive or directory.

sudo scatool -a SLES_SERVER.COMPANY.COM 

Establishes an SSH connection to an external server SLES_SERVER.COMPANY.COM and runs supportconfig on the server. The Supportconfig archive is then copied back to the local machine and is analyzed there. The generated HTML report is saved to the default /var/log directory. (Only the Supportconfig archive is created on SLES_SERVER.COMPANY.COM).

sudo scatool-c

Starts the interactive console for scatool. Press →| twice to see the available commands.

For further options and information, run sudo scatool -h or see the scatool man page.

47.4.2 SCA appliance

If you decide to use the SCA appliance for analyzing the Supportconfig archives, configure a dedicated server (or virtual machine) as the SCA appliance server. The SCA appliance server can then be used to analyze Supportconfig archives from all machines in your enterprise running SUSE Linux Enterprise Server or SUSE Linux Enterprise Desktop. You can simply upload Supportconfig archives to the appliance server for analysis. Interaction is not required. In a MariaDB database, the SCA appliance keeps track of all Supportconfig archives that have been analyzed . You can read the SCA reports directly from the appliance Web interface. Alternatively, you can have the appliance send the HTML report to any administrative user via e-mail. For details, see Section 47.4.2.5.4, “Sending SCA reports via e-mail”.

47.4.2.1 Installation quick start

To install and set up the SCA appliance in a fast way from the command line, follow the instructions here. The procedure is intended for experts and focuses on the bare installation and setup commands. For more information, refer to the more detailed description in Section 47.4.2.2, “Prerequisites” to Section 47.4.2.3, “Installation and basic setup”.

Prerequisites
  • Web and LAMP Pattern

  • Web and Scripting Module (you must register the machine to be able to select this module).

Note
Note: root privileges required

All commands in the following procedure must be run as root.

Procedure 47.3: Installation using anonymous FTP for upload

After the appliance is set up and running, no more manual interaction is required. This way of setting up the appliance is therefore ideal for using cron jobs to create and upload Supportconfig archives.

  1. On the machine on which to install the appliance, log in to a console and execute the following commands (make sure to accept the recommended packages):

    > 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. In YaST FTP Server, select Authentication › Enable Upload › Anonymous Can Upload › Finish › Yes to Create /srv/ftp/upload.

  3. Execute the following commands:

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

    The mysql_secure_installation will create a MariaDB root password.

Procedure 47.4: Installation using SCP/tmp for upload

This way of setting up the appliance requires manual interaction when typing the SSH password.

  1. On the machine on which to install the appliance, log in to a console.

  2. Execute the following commands:

    > 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

47.4.2.2 Prerequisites

To run an SCA appliance server, you need the following prerequisites:

  • All sca-appliance-* packages.

  • The sca-patterns-base package. Additionally, any of the product-specific sca-patterns-* for the type of Supportconfig archives that you want to analyze with the appliance.

  • Apache

  • PHP

  • MariaDB

  • anonymous FTP server (optional)

47.4.2.3 Installation and basic setup

As listed in Section 47.4.2.2, “Prerequisites”, the SCA appliance has several dependencies on other packages. Therefore, you need to take preparatory steps before installing and setting up the SCA appliance server:

  1. For Apache and MariaDB, install the Web and LAMP installation patterns.

  2. Set up Apache, MariaDB, and optionally an anonymous FTP server. For more information, see Chapter 42, The Apache HTTP server and Chapter 43, Setting up an FTP server with YaST.

  3. Configure Apache and MariaDB to start at boot time:

    > sudo systemctl enable apache2 mysql
  4. Start both services:

    > sudo systemctl start apache2 mysql

Now you can install the SCA appliance and set it up as described in Procedure 47.5, “Installing and configuring the SCA appliance”.

Procedure 47.5: Installing and configuring the SCA appliance

After installing the packages, use the setup-sca script for the basic configuration of the MariaDB administration and report database that is used by the SCA appliance.

It can be used to configure the following options you have for uploading the Supportconfig archives from your machines to the SCA appliance:

  • scp

  • anonymous FTP server

  1. Install the appliance and the SCA base-pattern library:

    > sudo zypper install sca-appliance-* sca-patterns-base
  2. Additionally, install the pattern packages for the types of Supportconfig archives you want to analyze. For example, if you have SUSE Linux Enterprise Server 12 and SUSE Linux Enterprise Server 15 servers in your environment, install both the sca-patterns-sle12 and sca-patterns-sle15 packages.

    To install all available patterns:

    > sudo zypper install sca-patterns-*
  3. For basic setup of the SCA appliance, use the setup-sca script. How to call it depends on how you want to upload the Supportconfig archives to the SCA appliance server:

    • If you have configured an anonymous FTP server that uses the /srv/ftp/upload directory, execute the setup script with the -f option. Follow the instructions on the screen:

      > sudo setup-sca -f
      Note
      Note: FTP server using another directory

      If your FTP server uses another directory than /srv/ftp/upload, adjust the following configuration files first to make them point to the correct directory: /etc/sca/sdagent.conf and /etc/sca/sdbroker.conf .

    • To upload Supportconfig files to the /tmp directory of the SCA appliance server via scp, call the setup script without any parameters. Follow the instructions on the screen:

      > sudo setup-sca

    The setup script runs a few checks regarding its requirements and configures the needed components. It will prompt you for two passwords: the MySQL root password of the MariaDB that you have set up, and a Web user password with which to log in to the Web interface of the SCA appliance.

  4. Enter the existing MariaDB root password. It will allow the SCA appliance to connect to the MariaDB.

  5. Define a password for the Web user. It will be written to /srv/www/htdocs/sca/web-config.php and will be set as the password for the user scdiag. Both user name and password can be changed at any time later, see Section 47.4.2.5.1, “Password for the Web interface”.

After successful installation and setup, the SCA appliance is ready for use, see Section 47.4.2.4, “Using the SCA appliance”. However, you should modify options such as changing the password for the Web interface, changing the source for the SCA pattern updates, enabling archiving mode or configuring e-mail notifications. For details on that, see Section 47.4.2.5, “Customizing the SCA appliance”.

Warning
Warning: Data protection

As the reports on the SCA appliance server contain security-relevant information, make sure to protect the data on the SCA appliance server against unauthorized access.

47.4.2.4 Using the SCA appliance

You can upload existing Supportconfig archives to the SCA appliance manually or create new Supportconfig archives and upload them to the SCA appliance in one step. Uploading can be done via FTP or SCP. For both, you need to know the URL where the SCA appliance can be reached. For upload via FTP, an FTP server needs to be configured for the SCA appliance, see Procedure 47.5, “Installing and configuring the SCA appliance”.

47.4.2.4.1 Uploading supportconfig archives to the SCA appliance
  • For creating a Supportconfig archive and uploading it via (anonymous) FTP:

    > sudo supportconfig -U “ftp://SCA-APPLIANCE.COMPANY.COM/upload”
  • For creating a Supportconfig archive and uploading it via SCP:

    > sudo supportconfig -U “scp://SCA-APPLIANCE.COMPANY.COM/tmp”

    You will be prompted for the root user password of the server running the SCA appliance.

  • To manually upload one or multiple archives, copy the existing archive files (located at/var/log/scc_*.tbz) to the SCA appliance. As target, use either the appliance server's /tmp directory or the /srv/ftp/upload directory (if FTP is configured for the SCA appliance server).

47.4.2.4.2 Viewing SCA reports

SCA reports can be viewed from any machine that has a browser installed and can access the report index page of the SCA appliance.

  1. Start a Web browser and make sure that JavaScript and cookies are enabled.

  2. As a URL, enter the report index page of the SCA appliance.

    https://sca-appliance.company.com/sca

    If in doubt, ask your system administrator.

  3. You will be prompted for a user name and a password to log in.

    HTML report generated by SCA appliance
    Figure 47.2: HTML report generated by SCA appliance
  4. After logging in, click the date of the report you want to read.

  5. Click the Basic Health category first to expand it.

  6. In the Message column, click an individual entry. This opens the corresponding article in the SUSE Knowledge base. Read the proposed solution and follow the instructions.

  7. If the Solutions column of the Supportconfig Analysis Report shows any additional entries, click them. Read the proposed solution and follow the instructions.

  8. Check the SUSE Knowledge base (https://www.suse.com/support/kb/) for results that directly relate to the problem identified by SCA. Work at resolving them.

  9. Check for results that can be addressed proactively to avoid future problems.

47.4.2.5 Customizing the SCA appliance

The following sections show how to change the password for the Web interface, how to change the source for the SCA pattern updates, how to enable archiving mode, and how to configure e-mail notifications.

47.4.2.5.1 Password for the Web interface

The SCA Appliance Web interface requires a user name and password for logging in. The default user name is scdiag and the default password is linux (if not specified otherwise, see Procedure 47.5, “Installing and configuring the SCA appliance”). Change the default password to a secure password at the earliest possibility. You can also modify the user name.

Procedure 47.6: Changing user name or password for the Web interface
  1. Log in as root user at the system console of the SCA appliance server.

  2. Open /srv/www/htdocs/sca/web-config.php in an editor.

  3. Change the values of $username and $password as desired.

  4. Save the file and exit.

47.4.2.5.2 Updates of SCA patterns

By default, all sca-patterns-* packages are updated regularly by a root cron job that executes the sdagent-patterns script nightly, which in turn runs zypper update sca-patterns-*. A regular system update will update all SCA appliance and pattern packages. To update the SCA appliance and patterns manually, run:

> sudo zypper update sca-*

The updates are installed from the SUSE Linux Enterprise 15 SP6 update repository by default. You can change the source for the updates to an RMT server, if desired. When sdagent-patterns runs zypper update sca-patterns-*, it gets the updates from the currently configured update channel. If that channel is located on an RMT server, the packages will be pulled from there.

Procedure 47.7: Disabling automatic updates of SCA patterns
  1. Log in as root user at the system console of the SCA appliance server.

  2. Open /etc/sca/sdagent-patterns.conf in an editor.

  3. Change the entry

    UPDATE_FROM_PATTERN_REPO=1

    to

    UPDATE_FROM_PATTERN_REPO=0
  4. Save the file and exit. The machine does not require any restart to apply the change.

47.4.2.5.3 Archiving mode

All Supportconfig archives are deleted from the SCA appliance after they have been analyzed and their results have been stored in the MariaDB database. However, for troubleshooting purposes it can be useful to keep copies of Supportconfig archives from a machine. By default, archiving mode is disabled.

Procedure 47.8: Enabling archiving mode in the SCA appliance
  1. Log in as root user at the system console of the SCA appliance server.

  2. Open /etc/sca/sdagent.conf in an editor.

  3. Change the entry

    ARCHIVE_MODE=0

    to

    ARCHIVE_MODE=1
  4. Save the file and exit. The machine does not require any restart to apply the change.

After having enabled archive mode, the SCA appliance will save the Supportconfig files to the /var/log/archives/saved directory, instead of deleting them.

47.4.2.5.4 Sending SCA reports via e-mail

The SCA appliance can e-mail a report HTML file for each Supportconfig analyzed. This feature is disabled by default. When enabling it, you can define a list of e-mail addresses to which the reports should be sent. Define a level of status messages that trigger the sending of reports (STATUS_NOTIFY_LEVEL).

Possible values for STATUS_NOTIFY_LEVEL
$STATUS_OFF

Deactivate sending of HTML reports.

$STATUS_CRITICAL

Send only SCA reports that include a CRITICAL.

$STATUS_WARNING

Send only SCA reports that include a WARNING or CRITICAL.

$STATUS_RECOMMEND

Send only SCA reports that include a RECOMMEND, WARNING or CRITICAL.

$STATUS_SUCCESS

Send SCA reports that include a SUCCESS, RECOMMEND, WARNING or CRITICAL.

Procedure 47.9: Configuring e-mail notifications for SCA reports
  1. Log in as root user at the system console of the SCA appliance server.

  2. Open /etc/sca/sdagent.conf in an editor.

  3. Search for the entry STATUS_NOTIFY_LEVEL. By default, it is set to $STATUS_OFF (e-mail notifications are disabled).

  4. To enable e-mail notifications, change $STATUS_OFF to the level of status messages that you want to have e-mail reports for, for example:

    STATUS_NOTIFY_LEVEL=$STATUS_SUCCESS

    For details, see Possible values for STATUS_NOTIFY_LEVEL.

  5. To define the list of recipients to which the reports should be sent:

    1. Search for the entry EMAIL_REPORT='root'.

    2. Replace root with a list of e-mail addresses to which SCA reports should be sent. The e-mail addresses must be separated by spaces. For example:

      EMAIL_REPORT='tux@my.company.com wilber@your.company.com'
  6. Save the file and exit. The machine does not require any restart to apply the changes. All future SCA reports will be e-mailed to the specified addresses.

47.4.2.6 Backing up and restoring the database

To back up and restore the MariaDB database that stores the SCA reports, use the scadb command as described below. scadb is provided by the package sca-appliance-broker.

Procedure 47.10: Backing up the database
  1. Log in as root user at the system console of the server running the SCA appliance.

  2. Put the appliance into maintenance mode by executing:

    # scadb maint
  3. Start the backup with:

    # scadb backup

    The data is saved to a TAR archive: sca-backup-*sql.gz.

  4. If you are using the pattern creation database to develop your own patterns (see Section 47.4.3, “Developing custom analysis patterns”), back up this data, too:

    # sdpdb backup

    The data is saved to a TAR archive: sdp-backup-*sql.gz.

  5. Copy the following data to another machine or an external storage medium:

    • sca-backup-*sql.gz

    • sdp-backup-*sql.gz

    • /usr/lib/sca/patterns/local (only needed if you have created custom patterns)

  6. Reactivate the SCA appliance with:

    # scadb reset agents
Procedure 47.11: Restoring the database

To restore the database from your backup, proceed as follows:

  1. Log in as root user at the system console of the server running the SCA appliance.

  2. Copy the newest sca-backup-*sql.gz and sdp-backup-*sql.gz TAR archives to the SCA appliance server.

  3. To decompress the files, run:

    # gzip -d *-backup-*sql.gz
  4. To import the data into the database, execute:

    # scadb import sca-backup-*sql
  5. If you are using the pattern creation database to create your own patterns, also import the following data with:

    # sdpdb import sdp-backup-*sql
  6. If you are using custom patterns, also restore /usr/lib/sca/patterns/local from your backup data.

  7. Reactivate the SCA appliance with:

    # scadb reset agents
  8. Update the pattern modules in the database with:

    # sdagent-patterns -u

47.4.3 Developing custom analysis patterns

The SCA appliance comes with a complete pattern development environment (the SCA Pattern Database) that enables you to develop your own, custom patterns. Patterns can be written in any programming language. To make them available for the Supportconfig analysis process, they need to be saved to /usr/lib/sca/patterns/local and to be made executable. Both the SCA appliance and the SCA tool will then run the custom patterns against new Supportconfig archives as part of the analysis report. For detailed instructions on how to create (and test) your own patterns, see https://www.suse.com/c/sca-pattern-development/.

47.5 Gathering information during the installation

During the installation, supportconfig is not available. However, you can collect log files from YaST by using save_y2logs. This command will create a .tar.xz archive in the directory /tmp.

If issues appear early during installation, you may be able to gather information from the log file created by linuxrc. linuxrc is a small command that runs before YaST starts. This log file is available at /var/log/linuxrc.log.

Important
Important: Installation log files not available in the installed system

The log files available during the installation are not available in the installed system anymore. Properly save the installation log files while the installer is still running.

47.6 Support of kernel modules

An important requirement for every enterprise operating system is the level of support you receive for your environment. Kernel modules are the most relevant connector between hardware (controllers) and the operating system. Every kernel module in SUSE Linux Enterprise has a supported flag that can take three possible values:

  • yes, thus supported

  • external, thus supported

  • (empty, not set), thus unsupported

The following rules apply:

  • All modules of a self-recompiled kernel are by default marked as unsupported.

  • Kernel modules supported by SUSE partners and delivered using SUSE SolidDriver Program are marked external.

  • If the supported flag is not set, loading this module will taint the kernel. Tainted kernels are not supported. Unsupported Kernel modules are included in an extra RPM package (kernel-FLAVOR-extra). That package is only available for SUSE Linux Enterprise Desktop and the SUSE Linux Enterprise Workstation Extension. Those kernels will not be loaded by default (FLAVOR=default|xen|...). Besides, these unsupported modules are not available in the installer, and the kernel-FLAVOR-extra package is not part of the SUSE Linux Enterprise media.

  • Kernel modules not provided under a license compatible to the license of the Linux kernel also taint the kernel. For details, see the state of /proc/sys/kernel/tainted.

47.6.1 Technical background

  • Linux kernel: The value of /proc/sys/kernel/unsupported defaults to 2 on SUSE Linux Enterprise 15 SP6 (do not warn in syslog when loading unsupported modules). This default is used in the installer and in the installed system.

  • modprobe: The modprobe utility for checking module dependencies and loading modules appropriately checks for the value of the supported flag. If the value is yes or external the module will be loaded, otherwise it will not. For information on how to override this behavior, see Section 47.6.2, “Working with unsupported modules”.

    Note
    Note: Support

    SUSE does not generally support the removal of storage modules via modprobe -r.

47.6.2 Working with unsupported modules

While general supportability is important, situations can occur where loading an unsupported module is required. For example, for testing or debugging purposes, or if your hardware vendor provides a hotfix.

  • To override the default, copy /lib/modprobe.d/10-unsupported-modules.conf to /etc/modprobe.d/10-unsupported-modules.conf and change the value of the variable allow_unsupported_modules from 0 to 1. Do not edit /lib/modprobe.d/10-unsupported-modules.conf directly; any changes will be overwritten whenever the suse-module-tools package is updated.

    If an unsupported module is needed in the initrd, do not forget to run dracut -f to update the initrd.

    If you only want to try loading a module once, you can use the --allow-unsupported-modules option with modprobe. For more information, see the comments in /lib/modprobe.d/10-unsupported-modules.conf and the modprobe man page.

  • During installation, unsupported modules may be added through driver update disks, and they will be loaded. To enforce loading of unsupported modules during boot and afterward, use the kernel command line option oem-modules. While installing and initializing the suse-module-tools package, the kernel flag TAINT_NO_SUPPORT (/proc/sys/kernel/tainted) will be evaluated. If the kernel is already tainted, allow_unsupported_modules will be enabled. This will prevent unsupported modules from failing in the system being installed. If no unsupported modules are present during installation and the other special kernel command line option (oem-modules=1) is not used, the default still is to disallow unsupported modules.

Remember that loading and running unsupported modules will make the kernel and the whole system unsupported by SUSE.

47.7 More information