SUSE Manager/InterServerSync

From MicroFocusInternationalWiki
Revision as of 13:48, 22 July 2013 by J renner (Talk | contribs) (Open questions)

Jump to: navigation, search

New Features in SUSE Manager 1.7

This betatest comes with the latest upcoming features for SUSE Manager 1.7, which includes support for:

  • Inter Server Sync - connect a SUSE Manager Server to another SUSE Manager Server instead of NCC for content distribution;
  • CVE Audit - find out what systems need to be patched for a certain CVE identifier.

Installation Instructions

Stop spacewalk services

 $> spacewalk-service stop

Update already installed packages

 $> zypper ar -f<BETA_PATH> manager-<BETA_NAME>-beta
 $> zypper dup --from manager-<BETA_NAME>-beta

Schema upgrade

 $> spacewalk-schema-upgrade

Start spacewalk services

 $> spacewalk-service start

Inter Server Sync

Configure the Master Server to accept connections from a SUSE Manager Slave Server

A SUSE Manager Server does not allow any other SUSE Manager Server to connect. You need to allow it explicitly.

Modify /etc/rhn/rhn.conf and add the hostnames of the allowed slaves to allowed_iss_slaves options:

 # Use this option if this server is intended to be a master
 # Comma separated list of allowed iss slaves, like:,

Additionally take care, that the option disable_iss is set to '0'

After changing the config, please restart the SUSE Manager Server:

 $> spacewalk-service restart

Now you need to refresh the NCC Sync data with:

 $> mgr-ncc-sync --refresh

Configure the SUSE Manager Slave Server

A SUSE Manager Slave Server connect only to its master server. A Connection to NCC is not needed.

During initial setup

We have enhanced the yast module which setup a SUSE Manager Server to be able to setup a Slave server. To test this, please install a new SUSE Manager Server from the appliance ISO and update all the packages before you start the yast module:

Update already installed packages

 $> zypper ar -f manager-iss-beta
 $> zypper dup --from manager-iss-beta

Setup SUSE Manager Server

 $> yast2 susemanager_setup

You will see that the screen with the NCC credentials has changed. You can select between

  • Connect to NCC
  • Connect to SUSE Manager for inter-server sync

Choose Connect to SUSE Manager for inter-server sync. The additional field Parent Server Name will be enabled. Enter the FQDN of the master server there.

The NCC Mirror Credential Username and Password needs to be the same as the first credential on the master Server.

Use the Test button to test if the credentials are working.

Manual Setup

If you have an already setup SUSE Manager Server you want to connect as a slave, you need to configure it manually.

Update the Server using the same steps as described above in Installation Instruction (Server).

Modify /etc/rhn/rhn.conf and set iss_parent to the FQDN of the master server.

Check, if /etc/ssl/certs/RHN-ORG-TRUSTED-SSL-CERT.pem already exists. If yes, you need to rename it:

 $> mv /etc/ssl/certs/RHN-ORG-TRUSTED-SSL-CERT.pem /etc/ssl/certs/OWN-SUSE-MANAGER-TRUSTED-SSL-CERT.pem
 $> c_rehash /etc/ssl/certs/

Download the SSL CA Certificate:


Trust this certificate:

 $> ln -s /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT /etc/ssl/certs/RHN-ORG-TRUSTED-SSL-CERT.pem
 $> c_rehash /etc/ssl/certs/

Restart the SUSE Manager Server

 $> spacewalk-service restart

Initialize the SUSE Manager Server

 $> mgr-ncc-sync --refresh

Use Inter Server Sync

On a SUSE Manager Slave the functions of mgr-ncc-sync are limited. The tool you should use to sync channels is now mgr-inter-sync. (This is a symlink to satellite-sync)

List available channels:

 $> mgr-inter-sync --list-channels

Sync a channel:

 $> mgr-inter-sync --channel <channel label>

Refresh all channels which are available in this server:

 $> mgr-inter-sync

Forward Registrations to NCC

Slave server forward the registrations to NCC by using the parent as a proxy. A SUSE Manager Server acting as a parent accept register and de-register operations and forward them directly to his parent. The first SUSE Manager Server will send these requests to NCC and return the answer back the chain to the original requesting server.

There are some checks implemented which needs to be passed before a SUSE Manager Server forward such a request. It checks, if the requesting slave is in the allowed list and it checks the user and password. These must match the first configured mirror credential.

Known Issues

  • Register a SUSE Manager Slave to its parent and get updates from the parent is currently not supported. Beta testers: please tell us if this is a valid scenario or use-case for you!

CVE Audit

Post Installation

CVE Audit needs to refresh data needed for the search periodically in the background in order to produce correct results. This is scheduled, by default, at 11:00 PM every night. You should manually schedule a run, right after installation, in order to get proper results without waiting until the next day:

  • Go to the "Admin" page
  • Click on "Task schedules" from the left menu
  • Click on the "cve-server-channels-default" schedule link
  • Click on the "cve-server-channels-bunch" bunch link
  • Click on the "Single Run Schedule" button
  • After some minutes, refresh the page and check that the scheduled run status is FINISHED.

A direct link is also available in the CVE Audit for your convenience.

Typical Usage

  • Go to the Audit page;
  • Input a 13-char CVE identifier;
  • Optionally, un-check patch statuses you are not interested in (see below);
  • Click on "Audit systems".

A list of systems is displayed, with usual pagination and navigation buttons. Each system has a "patch status" which describes its situation with respect to the CVE identifier. Possible statuses are:

  • Affected, patch available in a channel which is not assigned: system is affected by the vulnerability and SUSE Manager has a patch for it but, at the moment, that channel is not assigned to the system itself;
  • Affected, patch available in an assigned channel: system is affected by the vulnerability, SUSE Manager has a patch for it in a channel that is assigned to the system;
  • Not affected: the system does not have any installed packages that would be patchable;
  • Patched: a patch has already been installed.

For a more precise definition of these statuses, see Notes. If the CVE number is not known to SUSE Manager, an error notice is displayed, as Manager is not able to produce any audit data in that case.

For each system, the "Next Action" column contains suggestions on the steps to take in order to address vulnerabilities (installing a certain patch or assigning a new channel). When applicable, a list of "candidate" channels or patches is also displayed for your convenience.

You can also assign systems to a System Set for further batch work.

API Usage

An API method is available to run CVE audits from custom scripts, audit.listSystemsByPatchStatus. Details on how to use it are available in the API guide.


As stated above audit results are correct only if the assignment of channels to systems did not change since the last scheduled refresh (normally, at 23:00 every night). If a CVE audit is needed and channels were assigned or unassigned to any system during the day, a manual run is recommended.

Systems are said to be "affected", "not affected" or "patched" not in an absolute sense, but based on information that SUSE Manager knows about. This implies that concepts such as "affectedness to a vulnerability" have particular meanings in this context and more precisely, the following definitions apply:

  • system affected by a certain vulnerability: a system which has an installed package with version lower than the version of the same package in a relevant patch marked for the vulnerability;
  • system not affected by a certain vulnerability: a system which has no installed package that is also in a relevant patch marked for the vulnerability;
  • system patched for a certain vulnerability: a system which has an installed package with version equal to or greater than the version of the same package in a relevant patch marked for the vulnerability;
  • relevant patch: a patch known by SUSE Manager in a relevant channel;
  • relevant channel: a channel managed by SUSE Manager which is either assigned to the system, the original of a cloned channel which is assigned to the system, a channel linked to a product which is installed to the system or a past or future service pack channel for the system.

A notable consequence of the above definitions is that results can be inccorrect in cases of unmanaged channels, unmanaged packages and/or noncompliant systems.

Known Issues

  • Bug: The state of the page is lost (the page resets itself) when clearing the system set on top of the page using the "Clear" button.