adm_support.xml

<?xml version="1.0"?>
<!DOCTYPE chapter [
  <!ENTITY % entities SYSTEM "generic-entities.ent">
  %entities;
]>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:its="http://www.w3.org/2005/11/its" version="5.0" xml:id="cha-adm-support">

 <title>Gathering system information for support</title>
 <info>
  <meta name="description" its:translate="yes">Learn about accessing detailed system information, creating problem reports, and analyzing SupportConfig output with SUSE tools</meta>
  <abstract>
   <para>
    For a quick overview of all relevant system information of a machine,
    &productname; offers the
    <systemitem class="systemname">hostinfo</systemitem> package. It also helps
    system administrators to check for tainted kernels (that are not supported)
    or any third-party packages installed on a machine.
   </para>

   <para>
    In case of problems, a detailed system report may be created with either
    the <command>supportconfig</command> command line tool or the &yast;
    <guimenu>Support</guimenu> 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.
   </para>

   <para>
    Additionally, you can analyze the <command>supportconfig</command> output
    for known issues to help resolve problems faster. For this purpose,
    &productname; provides both an appliance and a command line tool for
    <literal>Supportconfig Analysis</literal> (SCA).
   </para>
  </abstract>
  <dm:docmanager xmlns:dm="urn:x-suse:ns:docmanager">
   <dm:bugtracker/>
   <dm:translation>yes</dm:translation>
  </dm:docmanager>
 <revhistory xml:id="rh-cha-adm-support">
   <revision>
     <date>2026-04-07</date>
     <revdescription>
       <para/>
     </revdescription>
   </revision>
 </revhistory>
</info>
<!-- support: sitar / onstar, siga, supportconfig -->
 <sect1 xml:id="sec-admsupport-hostinfo">
  <title>Displaying current system information</title>

  <para>
   For a quick and easy overview of all relevant system information when
   logging in to a server, use the package
   <systemitem class="systemname">hostinfo</systemitem>. After it has been
   installed on a machine, the console displays the following information to
   any &rootuser; user that logs in to this machine:
  </para>

  <example xml:id="ex-support-hostinfo">
   <title>Output of <command>hostinfo</command> when logging in as &rootuser;</title>
<screen>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:                    &exampledomain2ip;/24 &exampledomain2ipv6;/64
Memory
 Total/Free/Avail:        7.4Gi/6.4Gi/6.8Gi (91% Avail)
CPU Load Average:         7 (3%) with 2 CPUs
</screen>
  </example>

  <para>
   In case the output shows a <literal>tainted</literal> kernel status, see
   <xref linkend="sec-admsupport-kernel"/> for more details.
  </para>
 </sect1>
 <sect1 xml:id="sec-admsupport-supportconfig">
  <title>Collecting system information with supportconfig</title>
  <para>
   To create a TAR archive with detailed system information that you can hand
   over to Global Technical Support, use either:
  </para>
  <itemizedlist>
   <listitem>
    <para>the command <command>supportconfig</command> or, </para>
   </listitem>
   <listitem>
    <para>the &yast; <guimenu>Support</guimenu> module.</para>
   </listitem>
  </itemizedlist>
  <para>
   The command line tool is provided by the
   package <systemitem>supportutils</systemitem> which is installed by default.
   The &yast; <guimenu>Support</guimenu> module is also based on the command
   line tool.
  </para>
  <para>
   Depending on which packages are installed on your system, some of these
   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. That has the benefit that the only topics checked are those
   that contain a specific plug-in for them. Supportconfig plug-ins are stored
   in the directory <filename>/usr/lib/supportconfig/plugins/</filename>.
  </para>

  <sect2 xml:id="sec-admsupport-supportconfig-sr">
   <title>Creating a service request number</title>
   <para>
    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.
   </para>
   <para>
    To create a service request, go to
    <link xlink:href="https://scc.suse.com/support/requests"/> and follow the
    instructions on the screen. Write down the service request number.
   </para>
   <note>
    <title>Privacy statement</title>
    <para>
     &suse; treats system reports as confidential data. For
     details about our privacy commitment, see <link xlink:href="https://www.suse.com/company/policies/privacy/"/>.
    </para>
   </note>
  </sect2>

  <sect2 xml:id="sec-admsupport-supportconfig-upload">
   <title>Upload targets</title>
   <para>
    After having created a service request number, you can upload your
    Supportconfig archives to Global Technical Support as described in
    <xref linkend="pro-admsupport-submit-yast"/> or
    <xref linkend="pro-admsupport-submit-cli"/>. Use one of the following
    upload targets:
   </para>
   <itemizedlist mark="bullet" spacing="normal">
    <listitem>
     <para>
     <!-- TODO: Fix outdated links -->
      North America: FTP <link xlink:href="ftp://support-ftp.us.suse.com/incoming/"/>, FTPS <link xlink:href="ftps://support-ftp.us.suse.com/incoming/"/>
     </para>
    </listitem>
    <listitem>
     <para>
      EMEA, Europe, the Middle East, and Africa: FTP
      <link xlink:href="ftp://support-ftp.emea.suse.com/incoming"/>, FTPS <link xlink:href="ftps://support-ftp.emea.suse.com/incoming"/>
     </para>
    </listitem>
   </itemizedlist>
   <para>
    Alternatively, you can manually attach the TAR archive to your service
    request using the service request URL:
    <link xlink:href="https://scc.suse.com/support/requests"/>.
   </para>
  </sect2>

  <sect2 xml:id="sec-admsupport-yast">
   <title>Creating a supportconfig archive with &yast;</title>
   <para>
    To use &yast; to gather your system information, proceed as follows:
    <remark>2008-11-20 toms: YaST asks the user to open a URL as
     root(!). This happens when the users clicks on "Open" (Open
     Support Center/ This will start a browser with
     Support Center Portal). I do not think we should describe this
     and only *use* the above URL as a normal user for security
     reasons.</remark>
   </para>
   <procedure>
    <step>
     <para>
      Start &yast; and open the <guimenu>Support</guimenu> module.
     </para>
     <informalfigure>
      <mediaobject>
       <imageobject role="fo">
        <imagedata fileref="yast2_support_main.png" width="70%"/>
       </imageobject>
       <imageobject role="html">
        <imagedata fileref="yast2_support_main.png" width="60%"/>
       </imageobject>
      </mediaobject>
     </informalfigure>
    </step>
    <step>
     <para>
      Click <guimenu>Create report tarball</guimenu>.
     </para>
    </step>
    <step>
     <para>
      In the next window, select one of the Supportconfig options from the
      radio button list. <guimenu>Use Custom (Expert) Settings</guimenu> is
      preselected by default. To test the report function first,
      use <guimenu>Only gather a minimum amount of info</guimenu>. For
      additional information on the other options, refer to the
      <command>supportconfig</command> man page.
     </para>
     <para>
      Click <guimenu>Next</guimenu>.
     </para>
    </step>
    <step xml:id="st-supportconfig-contact">
     <para>
      Enter your contact information. It is saved in the
      <filename>basic-environment.txt</filename> file and included in the
      created archive.
     </para>
    </step>
    <step xml:id="st-supportconfig-upload-target">
     <para>
      To submit the archive to Global Technical Support, provide the required <guimenu>Upload
      Information</guimenu>. &yast; automatically suggests an
      upload server. To modify it, refer to
      <xref linkend="sec-admsupport-supportconfig-upload"/> for details of
      which upload servers are available.
     </para>
     <para>
      To submit the archive later, leave the
      <guimenu>Upload Information</guimenu> empty.
     </para>
    </step>
    <step>
     <para>
      Click <guimenu>Next</guimenu> to start the information collection process.
     </para>
     <informalfigure>
      <mediaobject>
       <imageobject role="fo">
        <imagedata fileref="yast2_support_conf.png" width="90%"/>
       </imageobject>
       <imageobject role="html">
        <imagedata fileref="yast2_support_conf.png" width="80%"/>
       </imageobject>
      </mediaobject>
     </informalfigure>
     <para>
      After the process is finished, click <guimenu>Next</guimenu>.
     </para>
    </step>
    <step>
     <para>
      To review the collected data, select the desired file from <guimenu>File
      Name</guimenu> to view its contents in &yast;. To remove a file from the
      TAR archive before submitting it to support, use <guimenu>Remove from
      Data</guimenu>. Press <guimenu>Next</guimenu>.
     </para>
    </step>
    <step>
     <para>
      Save the TAR archive. If you started the &yast; module as &rootuser;
      user, &yast; prompts to save the archive to <filename>/var/log</filename>
      (otherwise, to your home directory). The file name format is
      <filename>scc_<replaceable>HOST</replaceable>_<replaceable>DATE</replaceable>_<replaceable>TIME</replaceable>.tbz</filename>.
     </para>
    </step>
    <step>
     <para>
      To upload the archive to support directly, make sure <guimenu>Upload log
      files tarball to URL</guimenu> is activated. The <guimenu>Upload
      Target</guimenu> shown here is the one that &yast; suggests in <xref linkend="st-supportconfig-upload-target"/>. To modify the upload target,
      check which upload servers are available in <xref linkend="sec-admsupport-supportconfig-upload"/>.
     </para>
    </step>
    <step>
     <para>
      To skip the upload, deactivate <guimenu>Upload log files
      tarball to URL</guimenu>.
     </para>
    </step>
    <step>
     <para>
      Confirm the changes to close the &yast; module.
     </para>
    </step>
   </procedure>
  </sect2>

  <sect2 xml:id="sec-admsupport-cli">
   <title>Creating a supportconfig archive from command line</title>
   <para>
    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
    <xref linkend="pro-admsupport-submit-cli"/>.
   </para>
   <procedure>
    <step>
     <para>
      Open a shell and become <systemitem class="username">root</systemitem>.
     </para>
    </step>
    <step>
     <para>
      Run <command>supportconfig</command>. It is enough to
      run this tool without any options. However, the most common options
      are displayed in the following list:
     </para>
     <variablelist>
      <varlistentry>
       <term><option>-E <replaceable>MAIL</replaceable></option></term>
       <term><option>-N <replaceable>NAME</replaceable></option></term>
       <term><option>-O <replaceable>COMPANY</replaceable></option></term>
       <term><option>-P <replaceable>PHONE</replaceable></option></term>
       <listitem>
        <para>
         Sets your contact data: e-mail address (<option>-E</option>), company
         name (<option>-O</option>), your name (<option>-N</option>), and
         your phone number (<option>-P</option>).
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><option>-i <replaceable>KEYWORDS</replaceable></option></term>
       <term><option>-F</option></term>
       <listitem>
        <para>
         Limits the features to check. The placeholder <replaceable>KEYWORDS</replaceable>
         is a comma separated list of case-sensitive keywords. Get a list
         of all keywords with <command>supportconfig -F</command>.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term><option>-r <replaceable>SRNUMBER</replaceable></option></term>
       <listitem>
        <para>
         Defines your service request number when uploading the generated
         TAR archive.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>
    </step>
    <step>
     <para>
      Wait for the tool to complete the operation.
     </para>
    </step>
    <step>
     <para>
      The default archive location is <filename>/var/log</filename>, with the
      file name format being
      <filename>scc_<replaceable>HOST</replaceable>_<replaceable>DATE</replaceable>_<replaceable>TIME</replaceable>.tbz</filename>
     </para>
    </step>
   </procedure>
  </sect2>

  <sect2 xml:id="sec-admsupport-supportconfig-log">
   <title>Understanding the output of <command>supportconfig</command></title>
   <para>
    Whether you run <command>supportconfig</command> through &yast; or directly,
    the script gives you a summary of what it did.
   </para>
   <screen>                     Support Utilities - Supportconfig
                          Script Version: 3.0-98 <!--<co xml:id="co-admsupport-script-version"/>-->
                          Script Date: 2017 06 01<!-- <xref linkend="co-admsupport-script-version"/>-->
[...]
Gathering system information
  Data Directory:    /var/log/scc_d251_180201_1525 <co xml:id="co-admsupport-script-datadir"/>

  Basic Server Health Check...                 Done <co xml:id="co-admsupport-script-done"/>
  RPM Database...                              Done <xref linkend="co-admsupport-script-done"/>
  Basic Environment...                         Done <xref linkend="co-admsupport-script-done"/>
  System Modules...                            Done <xref linkend="co-admsupport-script-done"/>
[...]
  File System List...                          Skipped <co xml:id="co-admsupport-script-skipped"/>
[...]
  Command History...                           Excluded <co xml:id="co-admsupport-script-excluded"/>
[...]
  Supportconfig Plugins:                       1 <co xml:id="co-admsupport-script-plugin"/>
    Plugin: pstree...                          Done
[...]
Creating Tar Ball

==[ DONE ]===================================================================
  Log file tar ball: /var/log/scc_d251_180201_1525.txz <co xml:id="co-admsupport-script-archive"/>
  Log file size:     732K
  Log file md5sum:   bf23e0e15e9382c49f92cbce46000d8b
=============================================================================</screen>
   <calloutlist>
    <!--<callout arearefs="co-admsupport-script-version">
     <para>
      The version and the date of the <command>supportconfig</command> command.
      Higher versions can support more features.
     </para>
    </callout>-->
    <callout arearefs="co-admsupport-script-datadir">
     <para>
      The temporary data directory to store the results. This directory is
      archived as tar file, see <xref linkend="co-admsupport-script-archive"/>.
     </para>
    </callout>
    <callout arearefs="co-admsupport-script-done">
     <para>
      The feature was enabled (either by default or selected manually) and
      executed successfully. The result is stored in a file (see <xref linkend="tab-admsupport-features-and-filenames"/>).
     </para>
    </callout>
    <callout arearefs="co-admsupport-script-skipped">
     <para>
      The feature was skipped because files of one or more RPM packages
      were changed.
     </para>
    </callout>
    <callout arearefs="co-admsupport-script-excluded">
     <para>
      The feature was excluded because it was deselected via the <option>-x</option>
      option.
     </para>
    </callout>
    <callout arearefs="co-admsupport-script-plugin">
     <para>
      The script found one plug-in and executes the plug-in
      <command>pstree</command>. The plug-in was found in the directory
      <filename class="directory">/usr/lib/supportconfig/plugins/</filename>.
      See the man page for details.
     </para>
    </callout>
    <callout arearefs="co-admsupport-script-archive">
     <para>
      The tar file name of the archive, by default compressed with <command>xz</command>.
     </para>
    </callout>
   </calloutlist>
  </sect2>

  <sect2 xml:id="sec-admsupport-options">
   <title>Common supportconfig options</title>
   <para>
    The <command>supportconfig</command> utility is usually called without any
    options. Display a list of all options with
    <command>supportconfig</command> <option>-h</option> or refer to the man
    page. The following list gives a brief overview of common use cases:
   </para>
   <variablelist>
    <varlistentry>
     <term>Reducing the size of the information being gathered</term>
     <listitem>
      <para>
       Use the minimal option (<option>-m</option>):
      </para>
<screen>&prompt.sudo;supportconfig -m</screen>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Limiting the information to a specific topic</term>
     <listitem>
      <para>
       If you have already localized a problem <!--with the default
       <command>supportconfig</command> output and have found--> that relates
       to a specific area or feature set only, you should limit the collected
       information to the specific area for the next
       <command>supportconfig</command> 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:
      </para>
<screen>&prompt.sudo;supportconfig -i LVM</screen>
      <para>
       Additional keywords can be separated through commas. For example,
       an additional disk test:
      </para>
      <screen>&prompt.sudo;supportconfig -i LVM,DISK</screen>
      <para>
       For a complete list of feature keywords that you can use for limiting
       the collected information to a specific area, run:
      </para>
<screen>&prompt.sudo;supportconfig -F</screen>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Including additional contact information in the output:</term>
     <listitem>
<screen>&prompt.sudo;supportconfig -E tux@example.org -N "Tux Penguin" -O<!--
      --> "Penguin Inc." ...</screen>
      <para>
       (all in one line)
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Collecting already rotated log files</term>
     <listitem>
<screen>&prompt.sudo;supportconfig -l</screen>
      <para>
       This is especially useful in high logging environments or after a kernel
       crash when syslog rotates the log files after a reboot.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </sect2>
  <sect2 xml:id="sec-admsupport-log">
   <title>Overview of the archive content</title>
   <para>
    The TAR archive contains all the results from the features. Depending on
    what you have selected (all or only a small set), the archive can contain
    more or less files.
    The set of features can be limited through the <option>-i</option>
    option (see <xref linkend="sec-admsupport-options"/>).
   </para>
   <para>
    To list the content of the archive, use the following <command>tar</command>
    command:
   </para>
   <screen>&prompt.root;<command>tar</command> xf /var/log/scc_&exampleclient;_180131_1545.tbz</screen>
   <para>
    The following file names are always available inside the TAR archive:
   </para>
   <variablelist>
    <title>Minimum files in archive</title>
    <varlistentry>
     <term><filename>basic-environment.txt</filename></term>
     <listitem>
      <para>Contains the date when this script was executed and system information
       like version of the distribution, hypervisor information, and more.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>basic-health-check.txt</filename></term>
     <listitem>
      <para>
       Contains basic health checks like uptime, virtual memory statistics,
       free memory and hard disk, checks for zombie processes, and more.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>hardware.txt</filename></term>
     <listitem>
      <para>
       Contains basic hardware checks like information about the CPU architecture,
       list of all connected hardware, interrupts, I/O ports, kernel boot messages,
       and more.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>messages.txt</filename></term>
     <listitem>
      <para>
       Contains log messages from the system journal.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>rpm.txt</filename></term>
     <listitem>
      <para>Contains a list of all installed RPM packages, the name,
      where they are coming from, and their versions.</para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>summary.xml</filename></term>
     <listitem>
      <para>Contains information in XML format like distribution,
      the version, and product specific fragments.</para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>supportconfig.txt</filename></term>
     <listitem>
      <para>
       Contains information about the <command>supportconfig</command> script
       itself.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><filename>y2log.txt</filename></term>
     <listitem>
      <para>
       Contains &yast; specific information like specific packages, configuration
       files, and log files.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
   <para>
    <xref linkend="tab-admsupport-features-and-filenames"/> lists all available
    features and their file names. Further service packs can extend the list,
    as can plug-ins.
   </para>
   <table xml:id="tab-admsupport-features-and-filenames">
    <title>Comparison of features and file names in the TAR archive</title>
    <tgroup cols="2">
     <thead>
      <row>
       <entry>Feature</entry>
       <entry>File name</entry>
      </row>
     </thead>
     <tbody>
      <row>
       <entry><parameter>APPARMOR</parameter></entry>
       <entry><filename>security-apparmor.txt</filename></entry>
      </row>
      <row>
       <entry><parameter>AUDIT</parameter></entry>
       <entry><filename>security-audit.txt</filename></entry>
      </row>
      <row>
       <entry><parameter>AUTOFS</parameter></entry>
       <entry><filename>fs-autofs.txt</filename></entry>
      </row>
      <row>
       <entry><parameter>BOOT</parameter></entry>
       <entry><filename>boot.txt</filename></entry>
      </row>
      <row>
       <entry><parameter>BTRFS</parameter></entry>
       <entry><filename>fs-btrfs.txt</filename></entry>
      </row>
      <row>
       <entry><parameter>DAEMONS</parameter></entry>
       <entry><filename>systemd.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>CIMOM</parameter></entry>
         <entry><filename>cimom.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>CRASH</parameter></entry>
         <entry><filename>crash.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>CRON</parameter></entry>
         <entry><filename>cron.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>DHCP</parameter></entry>
         <entry><filename>dhcp.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>DISK</parameter></entry>
         <entry><filename>fs-diskio.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>DNS</parameter></entry>
         <entry><filename>dns.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>DOCKER</parameter></entry>
         <entry><filename>docker.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>DRBD</parameter></entry>
         <entry><filename>drbd.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>ENV</parameter></entry>
         <entry><filename>env.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>ETC</parameter></entry>
         <entry><filename>etc.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>HA</parameter></entry>
         <entry><filename>ha.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>HAPROXY</parameter></entry>
         <entry><filename>haproxy.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>HISTORY</parameter></entry>
         <entry><filename>shell_history.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>IB</parameter></entry>
         <entry><filename>ib.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>IMAN</parameter></entry>
         <entry><filename>novell-iman.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>ISCSI</parameter></entry>
         <entry><filename>fs-iscsi.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>LDAP</parameter></entry>
         <entry><filename>ldap.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>LIVEPATCH</parameter></entry>
         <entry><filename>kernel-livepatch.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>LVM</parameter></entry>
         <entry><filename>lvm.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>MEM</parameter></entry>
         <entry><filename>memory.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>MOD</parameter></entry>
         <entry><filename>modules.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>MPIO</parameter></entry>
         <entry><filename>mpio.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>NET</parameter></entry>
         <entry><filename>network-*.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>NFS</parameter></entry>
         <entry><filename>nfs.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>NTP</parameter></entry>
         <entry><filename>ntp.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>NVME</parameter></entry>
         <entry><filename>nvme.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>OCFS2</parameter></entry>
         <entry><filename>ocfs2.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>OFILES</parameter></entry>
         <entry><filename>open-files.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>PRINT</parameter></entry>
         <entry><filename>print.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>PROC</parameter></entry>
         <entry><filename>proc.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SAR</parameter></entry>
         <entry><filename>sar.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SLERT</parameter></entry>
         <entry><filename>slert.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SLP</parameter></entry>
         <entry><filename>slp.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SMT</parameter></entry>
         <entry><filename>smt.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SMART</parameter></entry>
         <entry><filename>fs-smartmon.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SMB</parameter></entry>
         <entry><filename>samba.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SRAID</parameter></entry>
         <entry><filename>fs-softraid.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SSH</parameter></entry>
         <entry><filename>ssh.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SSSD</parameter></entry>
         <entry><filename>sssd.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SYSCONFIG</parameter></entry>
         <entry><filename>sysconfig.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>SYSFS</parameter></entry>
         <entry><filename>sysfs.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>TRANSACTIONAL</parameter></entry>
         <entry><filename>transactional-update.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>TUNED</parameter></entry>
         <entry><filename>tuned.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>UDEV</parameter></entry>
         <entry><filename>udev.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>UFILES</parameter></entry>
         <entry><filename>fs-files-additional.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>UP</parameter></entry>
         <entry><filename>updates.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>WEB</parameter></entry>
         <entry><filename>web.txt</filename></entry>
      </row>
      <row>
         <entry><parameter>X</parameter></entry>
         <entry><filename>x.txt</filename></entry>
      </row>
     </tbody>
    </tgroup>
   </table>
  <remark>toms 2018-04-05: Make the table be aware of what packages brings
     what plugin?</remark>
  </sect2>
 </sect1>
 <sect1 xml:id="sec-admsupport-submit">
  <title>Submitting information to Global Technical Support</title>

  <para>
   Use the &yast; <guimenu>Support</guimenu> module or the
   <command>supportconfig</command> 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
   <xref linkend="sec-admsupport-supportconfig-sr"/>.
  </para>

  <para>
   The following examples use <replaceable>12345678901</replaceable> as a
   placeholder for your service request number. Replace
   <replaceable>12345678901</replaceable> with the service request number you
   created in <xref linkend="sec-admsupport-supportconfig-sr"/>.
  </para>

  <procedure xml:id="pro-admsupport-submit-yast">
   <title>Submitting information to support with &yast;</title>
   <para>
    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
    <xref linkend="sec-admsupport-yast"/>,
    <xref linkend="st-supportconfig-contact" xrefstyle="select:label nopage"/>.
    For instructions on how to generate and submit a Supportconfig archive in
    one go, see <xref linkend="sec-admsupport-yast"/>.
   </para>
   <step>
    <para>
     Start &yast; and open the <guimenu>Support</guimenu> module.
    </para>
   </step>
   <step>
    <para>
     Click <guimenu>Upload</guimenu>.
    </para>
   </step>
   <step>
    <para>
     In <guimenu>Package with log files</guimenu> specify the path to the
     existing Supportconfig archive or <guimenu>Browse</guimenu> for it.
    </para>
   </step>
   <step xml:id="st-supportcfg-submit-upltarget">
    <para>
     &yast; automatically proposes an upload server. To modify it,
     refer to <xref linkend="sec-admsupport-supportconfig-upload"/> for details
     of which upload servers are available.
    </para>
    <informalfigure>
     <mediaobject>
      <imageobject role="fo">
       <imagedata fileref="yast2_support_conf_upload.png" width="70%"/>
      </imageobject>
      <imageobject role="html">
       <imagedata fileref="yast2_support_conf_upload.png" width="60%"/>
      </imageobject>
     </mediaobject>
    </informalfigure>
    <para>
     <remark>taroth 2014-04-11: this does not make sense to me - why does the
      YaST module *not* ask for the SR number now? and lets you continue after
      specifying an upload target (but no RC or customer info)? I would
      expect it to *check* if an SR has been entered and otherwise show an error
      message - filed http://bugzilla.suse.com/show_bug.cgi?id=880943 for this, unfortunately it
      was rejected for technical reasons</remark>
     Proceed with <guimenu>Next</guimenu>.
    </para>
   </step>
   <step>
    <para>
     Click <guimenu>Finish</guimenu>.
    </para>
   </step>
  </procedure>

  <procedure xml:id="pro-admsupport-submit-cli">
   <title>Submitting information to support from command line</title>
   <para>
    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
    <xref linkend="sec-admsupport-yast"/>.
   </para>
   <step>
    <para>
     Servers with Internet connectivity:
    </para>
    <substeps performance="required">
     <step>
      <para>
       To use the default upload target, run:
      </para>
<screen>&prompt.sudo;supportconfig -ur <replaceable>12345678901</replaceable></screen>
     </step>
     <step>
      <para>
       For the secure upload target, use the following:
      </para>
<!--taroth 2014-04-04: bnc#871918-->
<screen>&prompt.sudo;supportconfig -ar <replaceable>12345678901</replaceable></screen>
     </step>
    </substeps>
   </step>
   <step>
    <para>
     Servers <emphasis>without</emphasis> Internet connectivity
    </para>
    <substeps performance="required">
     <step>
      <para>
       Run the following:
      </para>
<screen>&prompt.sudo;supportconfig -r <replaceable>12345678901</replaceable></screen>
     </step>
     <step>
      <para>
       Manually upload the
       <filename>/var/log/scc_<replaceable>SR12345678901</replaceable>*tbz</filename>
       archive to one of our FTP servers. Which one to use depends on your
       location in the world. For an overview, see
       <xref linkend="sec-admsupport-supportconfig-upload"/>.
      </para>
     </step>
    </substeps>
   </step>
   <step>
    <para>
     After the TAR archive arrives in the incoming directory of our FTP server,
     it becomes automatically attached to your service request.
    </para>
   </step>
  </procedure>
 </sect1>
<!-- taroth 2014-04-24:   http://fate.suse.com/315699,
  http://bugzilla.suse.com/show_bug.cgi?id=871928-->
 <sect1 xml:id="sec-admsupport-sca">
  <title>Analyzing system information</title>

  <para>
   System reports created with <command>supportconfig</command> can be analyzed
   for known issues to help resolve problems faster. For this purpose,
   &productname; provides both an appliance and a command line tool for
   <literal>Supportconfig Analysis</literal> (SCA). The SCA appliance is a
   server-side tool which is non-interactive. The SCA tool
   (<command>scatool</command> provided by the package
   <package>sca-server-report</package>) 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 <command>scatool</command> is
   running. No analysis cycles happen on the production server.
  </para>

  <para>
   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.
  </para>

  <para>
   You can also develop your own patterns as briefly described in
   <xref linkend="sec-admsupport-sca-patterns"/>.
  </para>

  <sect2 xml:id="sec-admsupport-sca-tool">
   <title>SCA command line tool</title>
   <para>
    The SCA command line tool lets you analyze a local machine using both
    <command>supportconfig</command> 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
    <xref linkend="fig-scatool-html"/>.
   </para>
   <figure xml:id="fig-scatool-html">
    <title>HTML report generated by SCA tool</title>
    <mediaobject>
     <imageobject role="fo">
      <imagedata fileref="sca_tool_report_html.png" width="100%"/>
     </imageobject>
     <imageobject role="html">
      <imagedata fileref="sca_tool_report_html.png" width="100%"/>
     </imageobject>
    </mediaobject>
   </figure>
   <para>
    The <command>scatool</command> command is provided by the
    <package>sca-server-report</package> package. It is
    not installed by default. Additionally, you need the
    <package>sca-patterns-base</package> package and any
    of the product-specific
    <package>sca-patterns-*</package> packages that
    matches the product installed on the machine where you want to run the
    <command>scatool</command> command.
   </para>
   <para>
    Execute the <command>scatool</command> command either as &rootuser; user or
    with <command>sudo</command>. When calling the SCA tool, either
    analyze an existing <command>supportconfig</command> 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
    <command>supportconfig</command> on an external machine and to execute the
    subsequent analysis on the local machine.
   </para>
   <para>
    Find some example commands below:
   </para>
   <variablelist>
    <varlistentry>
     <term><command>sudo scatool</command><option>-s</option>
     </term>
     <listitem>
      <para>
       Calls <command>supportconfig</command> 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.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><command>sudo scatool&nbsp;</command><option>-s</option>&nbsp;<option>-o</option>&nbsp;<replaceable>/opt/sca/reports/</replaceable>&nbsp;
     </term>
     <listitem>
      <para>
       Same as <command>sudo scatool</command> <option>-s</option>, only that
       the HTML report is written to the path specified with
       <option>-o</option>.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><command>sudo scatool&nbsp;</command><option>-a</option>&nbsp;<replaceable>PATH_TO_TARBALL_OR_DIR</replaceable>&nbsp;
     </term>
     <listitem>
      <para>
       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.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><command>sudo scatool&nbsp;</command><option>-a</option>&nbsp;<replaceable>SLES_SERVER.COMPANY.COM</replaceable>&nbsp;
     </term>
     <listitem>
      <para>
       Establishes an SSH connection to an external server
       <replaceable>SLES_SERVER.COMPANY.COM</replaceable> and runs
       <command>supportconfig</command> 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
       <filename>/var/log</filename> directory. (Only the Supportconfig archive
       is created on <replaceable>SLES_SERVER.COMPANY.COM</replaceable>).
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><command>sudo scatool</command><option>-c</option>
     </term>
     <listitem>
      <para>
       Starts the interactive console for <command>scatool</command>. Press
       <keycap function="tab"/> twice to see the available commands.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
   <para>
    For further options and information, run <command>sudo scatool -h</command>
    or see the <command>scatool</command> man page.
   </para>
  </sect2>

  <sect2 xml:id="sec-admsupport-sca-appliance">
   <title>SCA appliance</title>
   <para>
    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
    &sls; or &sled;. 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
    <xref linkend="sec-admsupport-sca-appliance-config-mail"/>.
   </para>
   <sect3 xml:id="sec-admsupport-sca-appliance-installquick">
    <title>Installation quick start</title>
    <para>
     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
     <xref linkend="sec-admsupport-sca-appliance-pre"/> to
     <xref linkend="sec-admsupport-sca-appliance-install"/>.
    </para>
    <itemizedlist mark="bullet" spacing="normal">
     <title>Prerequisites</title>
     <listitem>
      <para>
       Web and LAMP Pattern
      </para>
     </listitem>
     <listitem>
      <para>
       Web and Scripting Module (you must register the machine to be able to
       select this module).
      </para>
     </listitem>
    </itemizedlist>
    <note>
     <title>&rootuser; privileges required</title>
     <para>
      All commands in the following procedure must be run as &rootuser;.
     </para>
    </note>
    <procedure>
     <title>Installation using anonymous FTP for upload</title>
     <para>
      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.
     </para>
     <step>
      <para>
       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):
      </para>
<screen>&prompt.sudo;zypper install sca-appliance-* sca-patterns-* \
vsftpd yast2 yast2-ftp-server
&prompt.sudo;systemctl enable apache2
&prompt.sudo;systemctl start apache2
&prompt.sudo;systemctl enable vsftpd
&prompt.sudo;systemctl start vsftpd
&prompt.sudo;yast ftp-server</screen>
     </step>
     <step>
      <para>
       In &yast; FTP Server, select <menuchoice>
       <guimenu>Authentication</guimenu> <guimenu>Enable Upload</guimenu>
       <guimenu>Anonymous Can Upload</guimenu> <guimenu>Finish</guimenu>
       <guimenu>Yes</guimenu> </menuchoice> to <guimenu>Create
       /srv/ftp/upload</guimenu>.
      </para>
     </step>
     <step>
      <para>
       Execute the following commands:
      </para>
<screen>&prompt.sudo;systemctl enable mysql
&prompt.sudo;systemctl start mysql
&prompt.sudo;mysql_secure_installation
&prompt.sudo;setup-sca -f</screen>
      <para>
       The mysql_secure_installation will create a MariaDB &rootuser; password.
      </para>
     </step>
    </procedure>
    <procedure>
     <title>Installation using SCP/tmp for upload</title>
     <para>
      This way of setting up the appliance requires manual interaction when
      typing the SSH password.
     </para>
     <step>
      <para>
       On the machine on which to install the appliance, log in to a console.
      </para>
     </step>
     <step>
      <para>
       Execute the following commands:
      </para>
<screen>&prompt.sudo;zypper install sca-appliance-* sca-patterns-*
&prompt.sudo;systemctl enable apache2
&prompt.sudo;systemctl start apache2
&prompt.sudo;sudo systemctl enable mysql
&prompt.sudo;systemctl start mysql
&prompt.sudo;mysql_secure_installation
&prompt.sudo;setup-sca</screen>
     </step>
    </procedure>
   </sect3>
   <sect3 xml:id="sec-admsupport-sca-appliance-pre">
    <title>Prerequisites</title>
    <para>
     To run an SCA appliance server, you need the following prerequisites:
    </para>
    <itemizedlist mark="bullet" spacing="normal">
     <listitem>
      <para>
       All <systemitem>sca-appliance-*</systemitem> packages.
      </para>
     </listitem>
     <listitem>
      <para>
       The <systemitem class="resource">sca-patterns-base</systemitem> package.
       Additionally, any of the product-specific
       <systemitem class="resource">sca-patterns-*</systemitem> for the type of
       Supportconfig archives that you want to analyze with the appliance.
      </para>
     </listitem>
     <listitem>
      <para>
       Apache
      </para>
     </listitem>
     <listitem>
      <para>
       PHP
      </para>
     </listitem>
     <listitem>
      <para>
       MariaDB
      </para>
     </listitem>
     <listitem>
      <para>
       anonymous FTP server (optional)
      </para>
     </listitem>
    </itemizedlist>
   </sect3>
   <sect3 xml:id="sec-admsupport-sca-appliance-install">
    <title>Installation and basic setup</title>
    <para>
     As listed in <xref linkend="sec-admsupport-sca-appliance-pre"/>, the SCA
     appliance has several dependencies on other packages. Therefore you need
     do so some preparations before installing and setting up the SCA appliance
     server:
    </para>
    <procedure>
     <step>
      <para>
       For Apache and MariaDB, install the <systemitem>Web</systemitem> and
       <systemitem>LAMP</systemitem> installation patterns.
      </para>
     </step>
     <step>
      <para>
       Set up Apache, MariaDB, and optionally an anonymous FTP server.
       <phrase os="sles"> For more information, see
       <xref linkend="cha-apache2"/> and <xref linkend="cha-ftp"/>. </phrase>
      </para>
     </step>
     <step>
      <para>
       Configure Apache and MariaDB to start at boot time:
      </para>
<screen>&prompt.sudo;systemctl enable apache2 mysql</screen>
     </step>
     <step>
      <para>
       Start both services:
      </para>
<screen>&prompt.sudo;systemctl start apache2 mysql</screen>
     </step>
    </procedure>
    <para>
     Now you can install the SCA appliance and set it up as described in
     <xref linkend="pro-sca-appl-install"/>.
    </para>
    <procedure xml:id="pro-sca-appl-install">
     <title>Installing and configuring the SCA appliance</title>
     <para>
      After installing the packages, use the <command>setup-sca</command>
      script for the basic configuration of the MariaDB administration and
      report database that is used by the SCA appliance.
     </para>
     <para>
      It can be used to configure the following options you have for uploading
      the Supportconfig archives from your machines to the SCA appliance:
     </para>
     <itemizedlist mark="bullet" spacing="normal">
      <listitem>
       <para>
        <command>scp</command>
       </para>
      </listitem>
      <listitem>
       <para>
        anonymous FTP server
       </para>
      </listitem>
     </itemizedlist>
     <step>
      <para>
       Install the appliance and the SCA base-pattern library:
      </para>
<screen>&prompt.sudo;zypper install sca-appliance-* sca-patterns-base</screen>
     </step>
     <step>
      <para>
       Additionally, install the pattern packages for the types of
       Supportconfig archives you want to analyze. For example, if you have
       &sls; 12 and &sls; 15 servers in your environment, install both the
       <systemitem>sca-patterns-sle12</systemitem> and
       <systemitem>sca-patterns-sle15</systemitem> packages.
      </para>
      <para>
       To install all available patterns:
      </para>
<screen>&prompt.sudo;zypper install sca-patterns-*</screen>
     </step>
     <step>
      <para>
       For basic setup of the SCA appliance, use the
       <command>setup-sca</command> script. How to call it depends on how you
       want to upload the Supportconfig archives to the SCA appliance server:
      </para>
      <itemizedlist mark="bullet" spacing="normal">
       <listitem>
        <para>
         If you have configured an anonymous FTP server that uses the
         <filename>/srv/ftp/upload</filename> directory, execute the setup
         script with the <option>-f</option> option. Follow the instructions
         on the screen:
        </para>
<screen>&prompt.sudo;setup-sca -f</screen>
        <note>
         <title>FTP server using another directory</title>
         <para>
          If your FTP server uses another directory than
          <filename>/srv/ftp/upload</filename>, adjust the following
          configuration files first to make them point to the correct
          directory: <filename>/etc/sca/sdagent.conf</filename> and
          <filename>/etc/sca/sdbroker.conf</filename> .
         </para>
        </note>
       </listitem>
       <listitem>
        <para>
         To upload Supportconfig files to the
         <filename>/tmp</filename> directory of the SCA appliance server via
         <command>scp</command>, call the setup script without any parameters.
         Follow the instructions on the screen:
        </para>
<screen>&prompt.sudo;setup-sca</screen>
       </listitem>
      </itemizedlist>
      <para>
       The setup script runs a few checks regarding its requirements and
       configures the needed components. It will prompt you for two passwords:
       the MySQL &rootuser; 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.
      </para>
     </step>
     <step>
      <para>
       Enter the existing MariaDB &rootuser; password. It will allow the SCA
       appliance to connect to the MariaDB.
      </para>
     </step>
     <step>
      <para>
       Define a password for the Web user. It will be written to
       <filename>/srv/www/htdocs/sca/web-config.php</filename> and will be set
       as the password for the user
       <systemitem class="username">scdiag</systemitem>. Both user name and
       password can be changed at any time later, see
       <xref linkend="sec-admsupport-sca-appliance-config-passwd"/>.
      </para>
<!--taroth 2014-05-02: additional info in bnc#876021#c3:
       setup-sca accepts a "-w <str> Web user password" to set the password without
       being prompted if they want.-->
     </step>
    </procedure>
    <para>
     After successful installation and setup, the SCA appliance is ready for
     use, see <xref linkend="sec-admsupport-sca-appliance-use"/>. 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 <xref linkend="sec-admsupport-sca-appliance-config"/>.
    </para>
    <warning>
     <title>Data protection</title>
     <para>
      As the reports on the SCA appliance server contain security-relevant
      information<!-- of the machines whose Supportconfig archives have been
      analyzed-->, make sure to protect the data on the SCA appliance server
      against unauthorized access.
     </para>
    </warning>
   </sect3>
   <sect3 xml:id="sec-admsupport-sca-appliance-use">
    <title>Using the SCA appliance</title>
    <para>
     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
     <xref linkend="pro-sca-appl-install"/>.
    </para>
    <sect4 xml:id="sec-admsupport-sca-appliance-use-upload">
     <title>Uploading supportconfig archives to the SCA appliance</title>
     <para/>
     <itemizedlist mark="bullet" spacing="normal">
      <listitem>
       <para>
        For creating a Supportconfig archive and uploading it via (anonymous)
        FTP:
       </para>
<screen>&prompt.sudo;supportconfig -U “ftp://<replaceable>SCA-APPLIANCE.COMPANY.COM</replaceable>/upload”</screen>
      </listitem>
      <listitem>
       <para>
        For creating a Supportconfig archive and uploading it via SCP:
       </para>
<screen>&prompt.sudo;supportconfig -U “scp://<replaceable>SCA-APPLIANCE.COMPANY.COM</replaceable>/tmp”</screen>
       <para>
        You will be prompted for the &rootuser; user password of the server
        running the SCA appliance.
       </para>
      </listitem>
      <listitem>
       <para>
        To manually upload one or multiple archives, copy the
        existing archive files (located
        at<filename>/var/log/scc_*.tbz</filename>) to the SCA appliance. As
        target, use either the appliance server's <filename>/tmp</filename>
        directory or the <filename>/srv/ftp/upload</filename> directory (if FTP
        is configured for the SCA appliance server).
       </para>
      </listitem>
     </itemizedlist>
    </sect4>
    <sect4 xml:id="sec-admsupport-sca-appliance-use-view">
     <title>Viewing SCA reports</title>
     <para>
      SCA reports can be viewed from any machine that has a browser installed
      and can access the report index page of the SCA appliance.
     </para>
     <procedure>
      <step>
       <para>
        Start a Web browser and make sure that JavaScript and cookies are
        enabled.
       </para>
      </step>
      <step>
       <para>
        As a URL, enter the report index page of the SCA appliance.
       </para>
<screen>https://sca-appliance.company.com/sca</screen>
       <para>
        If in doubt, ask your system administrator.
       </para>
      </step>
      <step>
       <para>
        You will be prompted for a user name and a password to log in.
       </para>
       <figure xml:id="fig-sca-appl-html">
        <title>HTML report generated by SCA appliance</title>
        <mediaobject>
         <imageobject role="fo">
          <imagedata fileref="sca_appl_report_html.png" width="100%"/>
         </imageobject>
         <imageobject role="html">
          <imagedata fileref="sca_appl_report_html.png" width="100%"/>
         </imageobject>
        </mediaobject>
       </figure>
      </step>
      <step>
       <para>
        After logging in, click the date of the report you want to read.
       </para>
      </step>
      <step>
       <para>
        Click the <guimenu>Basic Health</guimenu> category first to expand it.
       </para>
      </step>
      <step>
       <para>
        In the <guimenu>Message</guimenu> column, click an individual entry.
<!--pattern result title-->
        This opens the corresponding article in the &suse; Knowledge base. Read
        the proposed solution and follow the instructions.
       </para>
      </step>
      <step>
       <para>
        If the <guimenu>Solutions</guimenu> column of the
        <guimenu>Supportconfig Analysis Report</guimenu> shows any additional
        entries, click them. Read the proposed solution and follow the
        instructions.
       </para>
      </step>
      <step>
       <para>
        Check the &suse; Knowledge base
        (<link xlink:href="https://www.suse.com/support/kb/"/>) for results that
        directly relate to the problem identified by SCA. Work at resolving
        them.
       </para>
      </step>
      <step>
       <para>
        Check for results that can be addressed proactively to avoid future
        problems.
       </para>
      </step>
     </procedure>
    </sect4>
   </sect3>
   <sect3 xml:id="sec-admsupport-sca-appliance-config">
    <title>Customizing the SCA appliance</title>
    <para>
     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.
    </para>
    <sect4 xml:id="sec-admsupport-sca-appliance-config-passwd">
     <title>Password for the Web interface</title>
     <para>
      The SCA Appliance Web interface requires a user name and password for
      logging in. The default user name is <literal>scdiag</literal> and the
      default password is <literal>linux</literal> (if not specified otherwise,
      see <xref linkend="pro-sca-appl-install"/>). Change the default password
      to a secure password at the earliest possibility. You can also modify the
      user name.
     </para>
     <procedure xml:id="pro-sca-passwd-change">
      <title>Changing user name or password for the Web interface</title>
      <step>
       <para>
        Log in as &rootuser; user at the system console of the SCA appliance
        server.
       </para>
      </step>
      <step>
       <para>
        Open <filename>/srv/www/htdocs/sca/web-config.php</filename> in an
        editor.
       </para>
      </step>
      <step>
       <para>
        Change the values of <literal>$username</literal> and
        <literal>$password</literal> as desired.
       </para>
      </step>
      <step>
       <para>
        Save the file and exit.
       </para>
      </step>
     </procedure>
    </sect4>
    <sect4 xml:id="sec-admsupport-sca-appliance-config-upd">
     <title>Updates of SCA patterns</title>
     <para>
      By default, all <systemitem class="resource">sca-patterns-*</systemitem>
      packages are updated regularly by a &rootuser; cron job that executes the
      <filename>sdagent-patterns</filename> script nightly, which in turn runs
      <command>zypper update sca-patterns-*</command>. A regular system update
      will update all SCA appliance and pattern packages. To update the SCA
      appliance and patterns manually, run:
     </para>
<screen>&prompt.sudo;zypper update sca-*</screen>
     <para>
      The updates are installed from the &sle; &productnumber; update
      repository by default. You can change the source for the updates to an
      &rmt; server, if desired. When <filename>sdagent-patterns</filename> runs
      <command>zypper update sca-patterns-*</command>, 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.
     </para>
     <procedure>
      <title>Disabling automatic updates of SCA patterns</title>
      <step>
       <para>
        Log in as &rootuser; user at the system console of the SCA appliance
        server.
       </para>
      </step>
      <step>
       <para>
<!--taroth 2014-04-09: this file does not exist on my test
         VM (which still runs a beta3) - is that a packaging error or perhaps a
         typo in your document? - bnc#876030: This file is new and will be included in Beta6. -->
        Open <filename>/etc/sca/sdagent-patterns.conf</filename> in an editor.
       </para>
      </step>
      <step>
       <para>
        Change the entry
       </para>
<screen>UPDATE_FROM_PATTERN_REPO=1</screen>
       <para>
        to
       </para>
<screen>UPDATE_FROM_PATTERN_REPO=0</screen>
      </step>
      <step>
       <para>
        Save the file and exit. The machine does not require any restart to
        apply the change.
       </para>
      </step>
     </procedure>
    </sect4>
    <sect4 xml:id="sec-admsupport-sca-appliance-config-archive">
     <title>Archiving mode</title>
     <para>
      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.
     </para>
     <procedure>
      <title>Enabling archiving mode in the SCA appliance</title>
      <step>
       <para>
        Log in as &rootuser; user at the system console of the SCA appliance
        server.
       </para>
      </step>
      <step>
       <para>
        Open <filename>/etc/sca/sdagent.conf</filename> in an editor.
       </para>
      </step>
      <step>
       <para>
        Change the entry
       </para>
<screen>ARCHIVE_MODE=0</screen>
       <para>
        to
       </para>
<screen>ARCHIVE_MODE=1</screen>
      </step>
      <step>
       <para>
        Save the file and exit. The machine does not require any restart to
        apply the change.
       </para>
      </step>
     </procedure>
     <para>
      After having enabled archive mode, the SCA appliance will save the
      Supportconfig files to the <filename>/var/log/archives/saved</filename>
      directory, instead of deleting them.
     </para>
    </sect4>
    <sect4 xml:id="sec-admsupport-sca-appliance-config-mail">
     <title>Sending SCA reports via e-mail</title>
     <para>
      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
      (<literal>STATUS_NOTIFY_LEVEL</literal>).
     </para>
     <variablelist xml:id="vl-sca-mails-notify-level">
      <title>Possible values for <literal>STATUS_NOTIFY_LEVEL</literal></title>
      <varlistentry>
       <term>$STATUS_OFF</term>
       <listitem>
        <para>
         Deactivate sending of HTML reports.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term>$STATUS_CRITICAL</term>
       <listitem>
        <para>
         Send only SCA reports that include a CRITICAL.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term>$STATUS_WARNING </term>
       <listitem>
        <para>
         Send only SCA reports that include a WARNING or CRITICAL.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term>$STATUS_RECOMMEND</term>
       <listitem>
        <para>
         Send only SCA reports that include a RECOMMEND, WARNING or CRITICAL.
        </para>
       </listitem>
      </varlistentry>
      <varlistentry>
       <term>$STATUS_SUCCESS</term>
       <listitem>
        <para>
         Send SCA reports that include a SUCCESS, RECOMMEND, WARNING or
         CRITICAL.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>
     <procedure>
      <title>Configuring e-mail notifications for SCA reports</title>
      <step>
       <para>
        Log in as &rootuser; user at the system console of the SCA appliance
        server.
       </para>
      </step>
      <step>
       <para>
        Open <filename>/etc/sca/sdagent.conf</filename> in an editor.
       </para>
      </step>
      <step>
       <para>
        Search for the entry <systemitem>STATUS_NOTIFY_LEVEL</systemitem>. By
        default, it is set to <literal>$STATUS_OFF</literal> (e-mail
        notifications are disabled).
       </para>
      </step>
      <step>
       <para>
        To enable e-mail notifications, change <literal>$STATUS_OFF</literal>
        to the level of status messages that you want to have e-mail reports
        for, for example:
       </para>
<screen>STATUS_NOTIFY_LEVEL=$STATUS_SUCCESS</screen>
       <para>
        For details, see <xref linkend="vl-sca-mails-notify-level"/>.
       </para>
      </step>
      <step>
       <para>
        To define the list of recipients to which the reports should be sent:
       </para>
       <substeps performance="required">
        <step>
         <para>
          Search for the entry <literal>EMAIL_REPORT='root'</literal>.
         </para>
        </step>
        <step>
         <para>
          Replace <literal>root</literal> 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:
         </para>
<screen>EMAIL_REPORT='&exampleuser_plain;@my.company.com&nbsp;&exampleuserII_plain;@your.company.com'</screen>
        </step>
       </substeps>
      </step>
      <step>
       <para>
        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.
       </para>
      </step>
     </procedure>
    </sect4>
   </sect3>
   <sect3 xml:id="sec-admsupport-sca-appliance-backup">
    <title>Backing up and restoring the database</title>
    <para>
     To back up and restore the MariaDB database that stores the SCA reports,
     use the <command>scadb</command> command as described
     below. <command>scadb</command> is provided by the package
     <package>sca-appliance-broker</package>.
    </para>
    <procedure>
     <title>Backing up the database</title>
     <step>
      <para>
       Log in as &rootuser; user at the system console of the server running
       the SCA appliance.
      </para>
     </step>
     <step>
      <para>
       Put the appliance into maintenance mode by executing:
      </para>
<screen>&prompt.root;scadb maint</screen>
     </step>
     <step>
      <para>
       Start the backup with:
      </para>
<screen>&prompt.root;scadb backup</screen>
      <para>
       The data is saved to a TAR archive:
       <filename>sca-backup-*sql.gz</filename>.
      </para>
     </step>
     <step>
      <para>
       If you are using the pattern creation database to develop your own
       patterns (see <xref linkend="sec-admsupport-sca-patterns"/>), back up
       this data, too:
      </para>
<screen>&prompt.root;sdpdb backup</screen>
      <para>
       The data is saved to a TAR archive:
       <filename>sdp-backup-*sql.gz</filename>.
      </para>
     </step>
     <step>
      <para>
       Copy the following data to another machine or an external storage
       medium:
      </para>
      <itemizedlist mark="bullet" spacing="normal">
       <listitem>
        <para>
         <filename>sca-backup-*sql.gz</filename>
        </para>
       </listitem>
       <listitem>
        <para>
         <filename>sdp-backup-*sql.gz</filename>
        </para>
       </listitem>
       <listitem>
        <para>
         <filename>/usr/lib/sca/patterns/local</filename> (only needed if you
         have created custom patterns)
        </para>
       </listitem>
      </itemizedlist>
     </step>
     <step>
      <para>
       Reactivate the SCA appliance with:
      </para>
<screen>&prompt.root;scadb reset agents</screen>
     </step>
    </procedure>
    <procedure>
     <title>Restoring the database</title>
     <para>
      To restore the database from your backup, proceed as follows:
     </para>
     <step>
      <para>
       Log in as &rootuser; user at the system console of the server running
       the SCA appliance.
      </para>
     </step>
     <step>
      <para>
       Copy the newest <filename>sca-backup-*sql.gz</filename> and
       <filename>sdp-backup-*sql.gz</filename> TAR archives to the SCA
       appliance server.
      </para>
     </step>
     <step>
      <para>
       To decompress the files, run:
      </para>
<screen>&prompt.root;gzip -d *-backup-*sql.gz</screen>
     </step>
     <step>
      <para>
       To import the data into the database, execute:
      </para>
<screen>&prompt.root;scadb import sca-backup-*sql</screen>
     </step>
     <step>
      <para>
       If you are using the pattern creation database to create your own
       patterns, also import the following data with:
      </para>
<screen>&prompt.root;sdpdb import sdp-backup-*sql</screen>
     </step>
     <step>
      <para>
       If you are using custom patterns, also restore
       <filename>/usr/lib/sca/patterns/local</filename> from your backup data.
      </para>
     </step>
     <step>
      <para>
       Reactivate the SCA appliance with:
      </para>
<screen>&prompt.root;scadb reset agents</screen>
     </step>
     <step>
      <para>
       Update the pattern modules in the database with:
      </para>
<screen>&prompt.root;sdagent-patterns -u</screen>
     </step>
    </procedure>
   </sect3>
  </sect2>

  <sect2 xml:id="sec-admsupport-sca-patterns">
   <title>Developing custom analysis patterns</title>
   <para>
    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
    <filename>/usr/lib/sca/patterns/local</filename> 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
    <link xlink:href="https://www.suse.com/c/blog/sca-pattern-development/"/>.
   </para>
  </sect2>
 </sect1>

 <sect1 xml:id="sec-admsupport-install">
  <title>Gathering information during the installation</title>
  <para>
   During the installation, <command>supportconfig</command> is not available.
   However, you can collect log files from &yast; by using
   <command>save_y2logs</command>. This command will create a
   <filename>.tar.xz</filename> archive in the directory
   <filename>/tmp</filename>.
  </para>
  <!-- It seems that we do not have linuxrc documentation, so
  there is not much I can link to. - sknorr, 2016-07-20 -->
  <para>
   If issues appear early during installation, you may be able to gather
   information from the log file created by
   <command>linuxrc</command>. <command>linuxrc</command> is a small command
   that runs before &yast; starts. This log file is available at
   <filename>/var/log/linuxrc.log</filename>.
  </para>
  <important>
   <title>Installation log files not available in the installed system</title>
   <para>
    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.
   </para>
  </important>
 </sect1>

 <sect1 xml:id="sec-admsupport-kernel">
  <title>Support of kernel modules</title>

  <para>
   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 (<quote>controllers</quote>) and the
   operating system. Every kernel module in &sle; has a
   <literal>supported</literal> flag that can take three possible values:
  </para>

  <itemizedlist mark="bullet" spacing="normal">
<!-- bnc#892346: be more explicit -->
   <listitem>
    <para>
     <quote>yes</quote>, thus <literal>supported</literal>
    </para>
   </listitem>
   <listitem>
    <para>
     <quote>external</quote>, thus <literal>supported</literal>
    </para>
   </listitem>
   <listitem>
    <para>
     (empty, not set), thus <literal>unsupported</literal>
    </para>
   </listitem>
  </itemizedlist>

  <para>
   The following rules apply:
  </para>

  <itemizedlist mark="bullet" spacing="normal">
   <listitem>
    <para>
     All modules of a self-recompiled kernel are by default marked as
     unsupported.
    </para>
   </listitem>
   <listitem>
    <para>
     Kernel modules supported by &suse; partners and delivered using
     <literal>&suse; SolidDriver Program</literal> are marked
     <quote>external</quote>.
    </para>
   </listitem>
   <listitem>
    <para>
     If the <literal>supported</literal> 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
     (<systemitem>kernel-<replaceable>FLAVOR</replaceable>-extra</systemitem>).
     That package is only available for &sled; and the &slewe;.
     Those kernels will not be loaded by default
     (<replaceable>FLAVOR</replaceable>=<literal>default</literal>|<literal>xen</literal>|...).
     In addition, these unsupported modules are not available in the installer,
     and the
     <systemitem class="resource">kernel-<replaceable>FLAVOR</replaceable>-extra</systemitem>
     package is not part of the &sle; media.
    </para>
   </listitem>
   <listitem>
    <para>
     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
     <filename>/proc/sys/kernel/tainted</filename>.
    </para>
   </listitem>
  </itemizedlist>

  <sect2 xml:id="sec-admsupport-kernel-background">
   <title>Technical background</title>
   <para/>
   <itemizedlist mark="bullet" spacing="normal">
    <listitem>
     <para>
      Linux kernel: The value of
      <filename>/proc/sys/kernel/unsupported</filename> defaults to
      <literal>2</literal> on &sle; &productnumber; (<literal>do not warn in
      syslog when loading unsupported modules</literal>). This default is used
      in the installer and in the installed system.
     </para>
    </listitem>
    <listitem>
     <para>
      <command>modprobe</command>: The <command>modprobe</command> utility for
      checking module dependencies and loading modules appropriately checks for
      the value of the <literal>supported</literal> flag. If the value is
      <quote>yes</quote> or <quote>external</quote> the module will be loaded,
      otherwise it will not. For information on how to override this behavior,
      see <xref linkend="sec-admsupport-kernel-unsupported"/>.
     </para>
     <note>
      <title>Support</title>
      <para>
       &suse; does not generally support the removal of storage modules via
       <command>modprobe -r</command>.
      </para>
     </note>
    </listitem>
   </itemizedlist>
  </sect2>

  <sect2 xml:id="sec-admsupport-kernel-unsupported">
   <title>Working with unsupported modules</title>
   <para>
    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.
   </para>
   <itemizedlist mark="bullet" spacing="normal">
    <listitem>
     <para>
      To override the default, copy
      <filename>/lib/modprobe.d/10-unsupported-modules.conf</filename> to
      <filename>/etc/modprobe.d/10-unsupported-modules.conf</filename> and
      change the value of the variable
      <varname>allow_unsupported_modules</varname> from <literal>0</literal> to
      <literal>1</literal>. Do not edit
      <filename>/lib/modprobe.d/10-unsupported-modules.conf</filename> directly;
      any changes will be overwritten whenever the
      <package>suse-module-tools</package> package is updated.
     </para>
     <para>
      If an unsupported module is needed in the initrd, do not forget to run
      <command>dracut</command> <option>-f</option> to update the initrd.
     </para>
     <para>
      If you only want to try loading a module once, you can use the
      <option>--allow-unsupported-modules</option> option with
      <command>modprobe</command>. For more information, see the comments in
      <filename>/lib/modprobe.d/10-unsupported-modules.conf</filename> and the
      <command>modprobe</command> man page.
     </para>
    </listitem>
    <listitem>
     <para>
      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
      <option>oem-modules</option>. While installing and initializing the
      <systemitem class="resource">suse-module-tools</systemitem> package, the
      kernel flag <literal>TAINT_NO_SUPPORT</literal>
      (<filename>/proc/sys/kernel/tainted</filename>) will be evaluated. If the
      kernel is already tainted, <literal>allow_unsupported_modules</literal>
      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
      (<option>oem-modules=1</option>) is not used, the default still is to
      disallow unsupported modules.
     </para>
    </listitem>
   </itemizedlist>
   <para>
    Remember that loading and running unsupported modules will make the kernel
    and the whole system unsupported by &suse;.
   </para>
  </sect2>
 </sect1>
 <sect1 xml:id="sec-admsupport-moreinfo">
  <title>More information</title>

  <para/>

  <itemizedlist mark="bullet" spacing="normal">
   <listitem>
    <para>
     <command>man supportconfig</command>&mdash;The
     <command>supportconfig</command> man page.
    </para>
   </listitem>
   <listitem>
    <para>
     <command>man supportconfig.conf</command>&mdash;The man page of the
     Supportconfig configuration file.
    </para>
   </listitem>
   <listitem>
    <para>
     <command>man scatool</command>&mdash;The <command>scatool</command> man
     page.
    </para>
   </listitem>
   <listitem>
    <para>
     <command>man scadb</command>&mdash;The <command>scadb</command> man page.
    </para>
   </listitem>
   <listitem>
    <para>
     <command>man setup-sca</command>&mdash;The <command>setup-sca</command>
     man page.
    </para>
   </listitem>
   <listitem>
    <para>
     <link xlink:href="https://mariadb.com/kb/en/"/>&mdash;The MariaDB
     documentation.
    </para>
   </listitem>
   <listitem os="sles">
    <para>
     <link xlink:href="https://httpd.apache.org/docs/"/> and
     <xref linkend="cha-apache2"/>&mdash;Documentation about the Apache Web
     server.
    </para>
   </listitem>
   <listitem os="sles">
    <para>
     <xref linkend="cha-ftp"/>&mdash;Documentation of how to set up an FTP
     server.
    </para>
   </listitem>
   <listitem>
    <para>
     <link xlink:href="https://www.suse.com/c/blog/sca-pattern-development/"/>&mdash;Instructions
     on how to create (and test) your own SCA patterns.
    </para>
   </listitem>
   <listitem>
    <para>
     <link xlink:href="https://www.suse.com/c/blog/basic-server-health-check-supportconfig/"/>&mdash;A
     Basic Server Health Check with Supportconfig.
    </para>
   </listitem>
   <listitem>
    <para>
     <link xlink:href="https://community.microfocus.com/img/gw/groupwise/w/groupwise/34308/create-your-own-supportconfig-plugin"/>&mdash;Create
     Your Own Supportconfig Plugin.
    </para>
   </listitem>
   <listitem>
    <para>
     <link xlink:href="https://www.suse.com/c/blog/creating-a-central-supportconfig-repository/"/>&mdash;Creating
     a Central Supportconfig Repository.
    </para>
    <para>
     <remark>taroth 2014-04-25: jrecord, should we still refer to the three articles above? </remark>
    </para>
   </listitem>
  </itemizedlist>
 </sect1>
</chapter>