Difference between revisions of "SUSE Manager/InterServerSync"

From MicroFocusInternationalWiki
Jump to: navigation, search
(Post-installation: refreshing channel data)
(Replaced content with "Please see the [https://www.suse.com/documentation/suse-manager-3/singlehtml/suse_manager21/book_susemanager_install/book_susemanager_install.html#s1-sync-iss SUSE Manager...")
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= New Features in SUSE Manager 1.7 =
+
Please see the [https://www.suse.com/documentation/suse-manager-3/singlehtml/suse_manager21/book_susemanager_install/book_susemanager_install.html#s1-sync-iss SUSE Manager 2.1 official manual, Installation & Troubleshooting Guide, Inter Server Synchronization].
 
+
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.
+
 
+
= Common installation instructions (Server) =
+
 
+
Stop spacewalk services
+
  $> spacewalk-service stop
+
 
+
Update already installed packages
+
  $> zypper ar -f http://beta.suse.com/private/SUSE-Manager-beta/<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-specific instructions =
+
 
+
== 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:
+
  allowed_iss_slaves=slave1.example.com,slave2.example.com
+
 
+
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 http://beta.suse.com/private/SUSE-Manager-beta/features/inter-server-sync 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.
+
 
+
=== Manually 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:
+
  $> curl -o /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT "http://FQDN.ISS.PARENT/pub/RHN-ORG-TRUSTED-SSL-CERT"
+
 
+
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.
+
 
+
== Open questions ==
+
 
+
Register a SUSE Manager Slave to its parent and get updates from the parent is currently not
+
supported. To every beta tester the question, if this is needed and wanted.
+
 
+
= CVE audit-specific instructions =
+
 
+
== Post-installation: refreshing channel data ==
+
 
+
CVE Audit needs to refresh channel data periodically in the background in order to produce correct results. This is scheduled, by default, at 23:00 every night. You can also schedule a run manually, right after installation, in order to have 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;
+
* Patch status unknown: SUSE Manager does not know the CVE identifier, thus it cannot determine if the system is affected or not;
+
* 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.
+
 
+
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.
+
 
+
== API Usage ==
+
 
+
An API method is available to run CVE audits from custom scripts, <code>audit.listSystemsByPatchStatus</code>. Details on how to use it are available in the API guide.
+
 
+
== Notes ==
+
 
+
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.
+

Latest revision as of 13:29, 25 July 2016

Please see the SUSE Manager 2.1 official manual, Installation & Troubleshooting Guide, Inter Server Synchronization.