SUSE Manager 2.1

Installation & Troubleshooting Guide

Publication date: September 09, 2015
About This Guide
Available Documentation
Documentation Conventions
1 Conceptual Overview
1.1 Main Components
1.2 Process Flow
1.3 Setup Scenarios and Security
1.4 Benefits
2 Example Topologies
2.1 Single SUSE Manager Topology
2.2 Multiple SUSE Manager Servers—Horizontally Tiered
2.3 SUSE Manager with SUSE Manager Proxies—Vertically Tiered
3 Requirements
3.1 System Requirements
3.2 External Database Requirements
3.3 Additional Requirements
3.4 Prerequisites
4 Installation
4.1 Summary of Steps
4.2 Installation
4.3 Setup
4.4 Setup Without Internet Connection
4.5 Basic Configuration
4.6 Server Migration
5 SUSE Manager on IBM System z
5.1 Introduction
5.2 Base System Requirements
5.3 Additional Requirements
5.4 Storage Preparation
5.5 SUSE Linux Enterprise 12 Required Functionality
5.6 SUSE Manager Installation
6 Importing and Synchronizing with Inter-Server Sync
6.1 Exporting with mgr-exporter
6.2 Importing with SUSE Manager Synchronization Tool mgr-inter-sync
6.3 Synchronizing
6.4 Inter-Server Synchronization
6.5 Organizational Synchronizing
6.6 Inter-Server Synchronization Use Cases
7 Troubleshooting
7.1 Installation and Configuration
7.2 General Problems
7.3 Configuring Reliable SUSE Manager Setup
7.4 Gathering Information with spacewalk-report
7.5 Changing the CSV Separator
7.6 Log Files
7.7 Naming Custom Channels
7.8 Accessing Local Channels without Proxy
7.9 Using a Proxy with Certificates to Access the Internet
7.10 Discovering Hosts and Subnets in the Network
7.11 Host Not Found/Could Not Determine FQDN
7.12 RPC Connection Timeout Settings
7.13 Connection Errors
7.14 SUSE Manager Debugging
7.15 Resetting the SUSE Manager Password
7.16 Registering a Client Manually with suse_register
7.17 Multiple Mirror Credentials
7.18 Invoking Spacecmd
8 Maintenance
8.1 Managing SUSE Manager with spacewalk-service
8.2 Updating SUSE Manager
8.3 Creating Up-to-date Bootstrap Repositories
8.4 Backing Up SUSE Manager
8.5 Migrating Patches from Old to New Naming
8.6 Configuring SUSE Manager's Database (smdba)
8.7 Cloning SUSE Manager with the Embedded Database
8.8 Establishing Redundant SUSE Manager Servers with Stand-Alone Database
8.9 Conducting SUSE Manager-Specific Tasks
8.10 Automating Synchronization
8.11 Implementing PAM Authentication
8.12 Enabling Push to Clients
8.13 SSH Server Push
8.14 Uploading and Maintaining Custom Packages
8.15 Configuring Audit Log Keeper
8.16 Generating Spacewalk Reports
8.17 Online Migration with YaST Wagon
8.18 Performing an Offline Migration
9 For More Information
A Documentation Updates
A.1 xxx, 2015
A.2 July 31, 2015
A.3 February 12, 2015
A.4 February 6, 2015
A.5 December 5, 2014
A.6 April 30, 2014
A.7 April 29, 2014
A.8 November 22, 2013
A.9 September 9, 2013
A.10 August 23, 2013
A.11 January 25, 2013
A.12 November 28, 2012

Copyright © 2015 SUSE LLC

Copyright © 2011-2014 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution-Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

This document is an adaption of original works found at and and

Red Hat, as a licensor of these documents, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners.

For Novell trademarks, see the Novell Trademark and Service Mark list Linux* is a registered trademark of Linus Torvalds. All other third party trademarks are the property of their respective owners. A trademark symbol (®, ™ etc.) denotes a Novell trademark; an asterisk (*) denotes a third party trademark.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither Novell, Inc., SUSE LINUX Products GmbH, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.

About This Guide

SUSE® Manager lets you efficiently manage a set of Linux systems and keep them up to date. It provides automated and cost-effective software management, asset management, system provisioning, and monitoring capabilities. SUSE Manager is compatible with Red Hat Satellite Server and offers seamless management of both SUSE® Linux Enterprise and Red Hat Enterprise Linux client systems.

This guide is intended for system administrators.

Many chapters in this manual contain links to additional documentation resources available on the installed system and on the Internet.

For an overview of the documentation available for your product and the latest documentation updates, refer to or to the following sections.

HTML versions of the manuals are also available from the Help tab of the SUSE Manager Web interface.

Note: Obtaining the Release Notes

Although this manual reflects the most current information possible, read the SUSE Manager Release Notes for information that may not have been available prior to the finalization of the documentation. These notes can be found at

1 Available Documentation

The following manuals are available on this product:

Installation & Troubleshooting Guide

Lists installation scenarios and example topologies for different SUSE Manager setups. Guides you step by step through the installation, setup and basic configuration of SUSE Manager. Also contains detailed information about SUSE Manager maintenance and troubleshooting.

Proxy Quick Start

Gives an overview of the installation and setup of SUSE Manager Proxy.

User Guide

Guides through common use cases and explains the Web interface.

Client Configuration Guide

Describes best practices for setting up clients to connect to a SUSE Manager server or SUSE Manager Proxy.

Reference Guide

Reference documentation that covers administration topics like registering and updating client systems, configuring the SUSE Manager daemon, monitoring client systems, and more. Also contains a glossary with key terms used in the SUSE Manager context.

HTML versions of the product manuals can be found in the installed system under /usr/share/doc/manual. Find the latest documentation updates at where you can download PDF or HTML versions of the manuals for your product.

2 Feedback

Several feedback channels are available:

Bugs and Enhancement Requests

For services and support options available for your product, refer to

To report bugs for a product component, go to, log in, and click Create New.

User Comments

We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to and enter your comments there.


For feedback on the documentation of this product, you can also send a mail to Make sure to include the document title, the product version and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).

3 Documentation Conventions

The following typographical conventions are used in this manual:

  • /etc/passwd: directory names and filenames.

  • placeholder: replace placeholder with the actual value.

  • PATH: the environment variable PATH.

  • ls, --help: commands, options, and parameters.

  • user: users or groups.

  • Alt, AltF1: a key to press or a key combination; keys are displayed with uppercase letters as on a keyboard.

  • File, File › Save As: menu items, buttons.

  • amd64, em64t This paragraph is only relevant for the specified architectures. The arrows mark the beginning and the end of the text block.

  • Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.

1 Conceptual Overview

SUSE Manager provides a solution to organizations requiring absolute control over and privacy of the maintenance and package deployment of their servers. It allows customers the greatest flexibility and power in keeping servers secure and updated.

1.1 Main Components

SUSE Manager consists of the following components:


SUSE Manager can be used in conjunction with a stand-alone database (for example, the organizations' existing database) or with an embedded database. The embedded database comes bundled with SUSE Manager and is installed on the same machine as the SUSE Manager server.

Some differences exist when using SUSE Manager with an external database as opposed to the embedded database. These affect mainly hardware requirements, but also some installation steps, maintenance or troubleshooting activities. Differing instructions are either marked with embedded database or stand-alone database throughout this guide.

SUSE Manager

Core business logic and entry point for the update tool running on client systems. The SUSE Manager server also includes an Apache HTTP Server that serves XML-RPC requests.

SUSE Manager Web Interface

For advanced management of systems, system groups, users, and channels.

RPM Repository

Repository for default packages (and custom RPM packages identified by the organization).

Management Tools

The following tools are available:

  • Database and file system synchronization tools.

  • RPM importing tools.

  • Channel maintenance tools (Web-based).

  • Patch management tools (Web-based).

  • User management tools (Web-based).

  • Client system and system grouping tools (Web-based).

  • An update tool on the client systems.

    If you have Red Hat Enterprise Linux clients that use the Red Hat Update Agent (up2date or yum) or RHN Registration Client (rhn_register), these applications must be reconfigured or replaced with spacewalk-client-tools to retrieve updates from the organization's internal SUSE Manager server or SUSE Manager Proxy. After this one-time reconfiguration, these client systems can retrieve updates locally using the Red Hat Update Agent, or system administrators can schedule actions through the SUSE Manager Web interface.

The SUSE Manager management tools are used to synchronize the SUSE Manager database and package repository with the Novell Customer Center (NCC). The SUSE Manager import tool allows the system administrator to include custom RPM packages in the package repository.

For an explanation of key terms in the SUSE Manager context, refer to the Glossary, Reference Guide.

1.2 Process Flow

When receiving an update request from a client, the organization's internal SUSE Manager server queries its database, authenticates the client system, identifies the updated packages available for the client system, and sends the requested RPMs to the client system. Depending on the client's preferences, the package may also be installed. If the packages are installed, the client system sends an updated package profile to the SUSE Manager database. Those packages are removed from the list of outdated packages for the client.

1.3 Setup Scenarios and Security

The organization can configure the Web site for SUSE Manager server to be accessible from the local area network only or from both the local area network and the Internet. Both setups allow full control over client systems, system groups, and users. System profiles containing hardware and software information of the client systems are stored locally on the customer's SUSE Manager server. When a client system requests package updates, only the applicable packages for the client are returned. All package management tasks, including patch updates, are performed through the local area network.

SUSE Manager can be used in combination with a SUSE Manager Proxy server to deliver a distributed, self-contained deployment for the organization. For example, an organization can maintain one SUSE Manager server in a secure location. Any client systems with local network access to SUSE Manager can connect to it. Other remote offices can maintain SUSE Manager Proxy server installations that connect to the SUSE Manager server. The different locations inside the organization must be networked. This can be a private network—an Internet connection is not required for any of the systems.

Using SUSE Manager and SUSE Manager Proxy Server Together
Figure 1.1: Using SUSE Manager and SUSE Manager Proxy Server Together

1.4 Benefits

Advantages of using SUSE Manager include:

  • Scalability — a single system administrator can set up and maintain hundreds or thousands of SUSE Linux Enterprise or Red Hat Enterprise Linux client systems more easily, accurately, and quickly than they could maintain a single system without SUSE Manager.

    SUSE Manager may oversee an entire organization's servers in combination with a SUSE Manager Proxy server.

  • Security — all communication between registered systems and SUSE Manager takes place over secure Internet connections.

  • Control — clients' system profiles are stored on the local SUSE Manager server.

  • Access control — system administrators can be restricted to access only those systems within their maintenance responsibilities.

  • Efficiency and bandwidth — packages are delivered significantly faster over a local area network. The bandwidth used for transactions between the clients and the SUSE Manager server is controlled by the organization on the local area network.

  • Overview about patches — easily view patch alerts for all your client systems through one Web site.

  • Customized updates — custom channels allow fine-grained control of the delivery of custom software packages. SUSE Manager allows you to create a truly automated delivery system for custom packages as well as any SUSE Linux Enterprise or Red Hat Enterprise Linux packages required by client systems.

  • Scheduled actions — use the SUSE Manager Web interface to schedule actions, including patch updates, package installations, and software profile updates.

  • Standard protocols — used to maintain security and increase capability. For example, XML-RPC enables SUSE Manager to do much more than merely download files.

  • Simplification — maintaining SUSE Linux Enterprise and Red Hat Enterprise Linux systems becomes a simple, automated process.

2 Example Topologies

SUSE Manager can be set up in multiple ways, depending on a number of factors like the following:

  • the total number of client systems to be served by SUSE Manager,

  • the maximum number of clients expected to connect concurrently to SUSE Manager,

  • the number of custom packages and channels to be served by SUSE Manager,

  • the number of SUSE Manager servers used in the customer environment,

In the following, find a simple setup example and two examples demonstrating how to effectively balance loads for larger environments.

2.1 Single SUSE Manager Topology

Using a single SUSE Manager to serve your entire network is adequate to service a medium-sized group of clients. However, performance will be compromised if the number of clients requesting packages grows.

Single SUSE Manager Topology
Figure 2.1: Single SUSE Manager Topology

2.2 Multiple SUSE Manager Servers—Horizontally Tiered

For larger networks, distributing the load of client requests becomes important. For this purpose, you can use several SUSE Manager servers in parallel as illustrated in Figure 2.2, “SUSE Manager Servers—Horizontally Tiered” or a combination of a SUSE Manager server with several SUSE Manager Proxy servers to which clients connect directly as shown in Figure 2.3, “SUSE Manager with SUSE Manager Proxies—Vertically Tiered”.

It is possible to synchronize content between SUSE Manager instances using the mgr-exporter and mgr-nnc-sync -m commands. This feature is discussed in detail in Section 6.1, “Exporting with mgr-exporter.

SUSE Manager Servers—Horizontally Tiered
Figure 2.2: SUSE Manager Servers—Horizontally Tiered

However, using a horizontal structure causes additional maintenance.

2.3 SUSE Manager with SUSE Manager Proxies—Vertically Tiered

An alternative method to balance load is to install SUSE Manager Proxy servers below a SUSE Manager. These proxies connect to the SUSE Manager server for packages from NCC and custom packages created locally. In essence, the proxies act as clients of the SUSE Manager server.

This vertically tiered setup requires that channels and RPMs be created only on the SUSE Manager server. In this manner, the proxies inherit and then serve packages from a central location.

The Proxy Servers' SSL certificates should also be set up so that the SUSE Manager Proxy servers become clients of the SUSE Manager. These Proxy servers should also be set up to serve content to client systems simultaneously. This process is described in the Section “Configuring Client Systems to Use Certificates”, Chapter 3, SSL Infrastructure, Client Configuration Guide.

SUSE Manager with SUSE Manager Proxies—Vertically Tiered
Figure 2.3: SUSE Manager with SUSE Manager Proxies—Vertically Tiered

3 Requirements

For requirements and prerequisites to be met before installation, refer to Section 3.1, “System Requirements” and Section 3.4, “Prerequisites”. If you want to use SUSE Manager with an external database, refer to Section 3.2, “External Database Requirements”.

3.1 System Requirements

The following sections inform about the system requirements and some prerequisites for SUSE Manager, including hardware, database, supported clients, and other requirements. The base system for SUSE Manager 2.1 is SLES 11 SP 3.

3.1.1 Server Requirements




Required: a multi-core 64bit CPU (x86_64).


Required: 4 GB when only managing a few client systems.

Recommended for production use: 16 GB.

Free Disk Space

Required: 20 GB for base installation.

Additionally at least 25 GB for caching per distribution or channel; resizable partition strongly recommended.

For examples of sizing requirements for SUSE Manager, see


We strongly recommend to use disk space monitoring probes to avoid file system and database corruption due to a lack of disk space. Set a lower threshold than you would use for a regular system so as to notify the admin in advance of upcoming low disk space conditions. For more information on monitoring see Chapter 11, Monitoring — [Mon], User Guide and Appendix B, Probes, Reference Guide.

3.1.2 Supported Client Systems

Clients with the following operating systems and architectures are supported for registration at SUSE Manager:


Supported Architectures

SUSE Linux Enterprise 10 SP3 and SP4

x86, x86_64, Itanium, IBM POWER, IBM System z

SUSE Linux Enterprise 11 SP1, SP2, and SP3

x86, x86_64, Itanium, IBM POWER, IBM System z

SUSE Linux Enterprise 12

x86_64, IBM POWER (ppc64le), IBM System z

Red Hat Enterprise Linux 5

x86, x86_64

Red Hat Enterprise Linux 6

x86, x86_64

Red Hat Enterprise Linux 7

x86, x86_64

Novell Open Enterprise Server 11, 11 SP1, and 11 SP2

x86, x86_64

Warning: Do Not Register SUSE Manager Against Itself

You must not register a SUSE Manager instance against itself!

The reason is that if patching goes wrong, you would not be able to apply a patch to patch the SUSE Manager instance back into a working condition.

3.2 External Database Requirements

This section applies only to SUSE Manager if used with a stand-alone database. The requirements for the embedded database are included in Section 3.1, “System Requirements”. SUSE Manager supports Oracle Database 10g and 11g. The stand-alone database must not run on the same server as the SUSE Manager.

A single 6 GB tablespace is recommended for most installations. It possibly works for many customers with a smaller tablespace. An experienced Oracle database administrator (DBA) will be necessary to assess sizing issues. However, keep in mind that the exact size of the database depends on many factors, such as number of systems managed, number of packages installed on the client systems, and number of packages imported. For example, 1000 packages need approximately 100 MB in the database. Due to these factors, database storage may grow rapidly.

Although you should be generous in your database sizing estimates, you must consider that size affects the time to conduct backups and adds load to other system resources. If the database is shared, selecting the right hardware and spacing entirely depend on what else is using it.

Additionally, block sizes must be a minimum of 8 KB for SUSE Manager to install properly.

The Oracle database should have a user assigned to SUSE Manager with full DDL and DML access to that user's default tablespace. The user needs standard connection information for the database at the time of installation.

Before installing SUSE Manager some system-level ALTER statements must be executed:

alter system set job_queue_processes=1000;
alter system set processes = 400 scope=spfile;
alter system set deferred_segment_creation=FALSE;

Also, the charset must be set to UTF-8. The following example script switches the character set and executes the ALTER statements:

# Run this as user oracle:
cat - << EOF | sqlplus /nolog
connect / as sysdba;
select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
shutdown immediate;
startup mount;
alter system enable restricted session;
alter system set job_queue_processes=0;
alter database open;
alter database character set UTF8;
alter database character set internal_use utf8;
shutdown immediate;
alter system set job_queue_processes=1000;
alter system set processes = 400 scope=spfile;
alter system set deferred_segment_creation=FALSE;

The precise access levels required by the Oracle user (susemanager) are as follows:

















Here's an example script to grant these permissions in one go:

cat - << EOF | sqlplus /nolog
connect / as sysdba;
create user susemanager identified by password default tablespace tablespace;
grant ALTER SESSION to susemanager;
grant CREATE SEQUENCE to susemanager;
grant CREATE SYNONYM to susemanager;
grant CREATE TABLE to susemanager;
grant CREATE VIEW to susemanager;
grant CREATE PROCEDURE to susemanager;
grant CREATE TRIGGER to susemanager;
grant CREATE TYPE to susemanager;
grant CREATE SESSION  to susemanager;
grant CREATE CLUSTER to susemanager;
grant CREATE INDEXTYPE to susemanager;
grant CREATE OPERATOR to susemanager;
grant UNLIMITED TABLESPACE to susemanager;
grant EXECUTE on DBMS_LOB to susemanager;

Additional database requirements include:

  • Security Identifier (SID),

  • Listener Port,

  • Username,

  • UTF-8 character set.

Two additional suggested recommendations for the user's default tablespace include:

  • Uniform Extent Size,

  • Auto Segment Space Management.

Important: "UTF8" Charset Mandatory

Ensure that the NLS/charset is set to "UTF8" when using an external database, not "AL32UTF8" or other charsets. Using other charsets may lead to problems later.

The disk layout on the database machine is independent of SUSE Manager and entirely up to the customer.

Note: For More Information

For more information, see

3.3 Additional Requirements

Important: Network Setup

For correct installation and setup of SUSE Manager, make sure the following requirements are met.

Fully Qualified Domain Name (FQDN):

The SUSE Manager server must resolve its own FQDN correctly, otherwise cookies will not work properly on the Web interface.

Hostname and IP Address:

To guarantee that SUSE Manager's domain name can be resolved by its clients, the server and the client machines must be linked to a working Domain Name System (DNS) server in the customer environment.

The hostname of the SUSE Manager server must not contain uppercase letters as this might cause jabberd to fail.

Important: Renaming SUSE Manager Server Not Supported

Choose the hostname of the SUSE Manager server carefully. Once installed renaming is not supported.

For more information, see

Full Access:

Client systems need full network access to the SUSE Manager's services and ports.

Firewall Rules:

Protect your SUSE Manager with a firewall against the Internet by blocking all unnecessary and unused ports.

Client systems connect to SUSE Manager via ports 80, 443, and 4545 (if monitoring is enabled). In addition, enabling push actions from SUSE Manager to client systems, as described in Section 8.12, “Enabling Push to Clients”, requires inbound connections on port 5222. If SUSE Manager will also push to a SUSE Manager proxy, you must allow inbound connections on port 5269.

Table 3.1: Ports to Open on SUSE Manager






Open this port to configure the SUSE Manager system as a DHCP server for systems requesting IP addresses.



Open this port to configure SUSE Manager as a PXE server and allow installation and reinstallation of PXE-boot enabled systems.



SUSE Manager server uses this port to reach Novell Customer Center



WebUI, client, and proxy server requests come in via either http or https.



WebUI, client, and proxy server requests come in via either http or https.



SUSE Manager uses this port to reach Novell Customer Center (unless running in a disconnected mode with SMT—as described in Section 4.4, “Setup Without Internet Connection”).



SUSE Manager Monitoring makes connections to rhnmd running on client systems if Monitoring is enabled and probes are configured for registered systems.



Required by osad running on the client systems if you plan to push actions to client systems.



Needed if you push actions to or via a SUSE Manager Proxy.

For reference, here are also listings of ports to open on the client systems and the SUSE Manager Proxy server.

Table 3.2: Ports to Open on the Client Systems




80 and 443


To reach the SUSE Manager server or SUSE Manager Proxy server.



Required when using ssh-push or ssh-push-tunnel contact methods.



For connections from the server or proxy server for monitoring.



For push actions with the server or proxy server.

Table 3.3: Ports to Open on the Proxy Servers






Required when using ssh-push or ssh-push-tunnel contact methods. Check-in on clients connected to a SUSE Manager Proxy will be initiated on the SUSE Manager Server and hop through through to clients.

80 and 443


To reach the SUSE Manager server.



For monitoring and probes connecting rhnmd running on the client systems.



For push actions and connections issued by osad running on the client systems.



For push actions with the server.

Synchronized System Times:

The connection to the Web server via Secure Sockets Layer (SSL) requires correct system time on server and clients. For this reason, SUSE Manager server and all client systems must use NTP. If SUSE Manager is used with a stand-alone database, the machine running the database must be set to the same time zone as SUSE Manager.

Novell Customer Center account:

For using SUSE Manager, you need an account at the Novell Customer Center (NCC), where your purchased products and product subscriptions are defined. Make sure to have the following subscriptions:

  • one or more subscriptions for SUSE Manager,

  • subscriptions for the products on the client systems you want to register with SUSE Manager,

  • subscriptions to client entitlements for the client system you want to register with SUSE Manager.

Keep backups of login information in multiple secure places:

Record all relevant usernames, passwords and other login information. For SUSE Manager, this includes usernames and passwords for the Organization Administrator account, the primary administrator account on SUSE Manager itself, SSL certificate generation, and database connection (which also requires a SID, or net service name). We strongly recommend this information be copied onto two separate electronic media, printed out on paper, and stored in a fireproof safe.

Supported Browsers

SUSE Manager supports the latest versions of IE, Firefox, Chrome and the version of Firefox shipped with our latest SUSE Linux Enterprise version. Other browsers may work, but are not tested and supported.

Virtual Environments

For running SUSE Manager server in virtual environments, use the following settings for the virtual machine (VM):

  • At least 4 GB of RAM

  • Bridged network

The following virtual environments are supported:

  • KVM

  • VMware

  • Hyper-V

For running SUSE Manager in KVM, VMware, or Hyper-V, use the SUSE Manager ISO image.

In addition to these requirements, we recommend to configure SUSE Manager in the following way:

  • The entire SUSE Manager solution should be protected by a firewall if the SUSE Manager server accesses or is accessed via the Internet. An Internet connection is not required for SUSE Manager servers running in completely disconnected environments. Instead they can use channel content downloaded to Subscription Management Tool (SMT) for synchronizing SUSE Manager with Novell channels. For more information, see Section 4.4, “Setup Without Internet Connection”.

  • No system components should be directly publicly available. No users other than the system administrators should have command line access to these machines.

  • All unnecessary services should be disabled using chkconfig.

  • The httpd service should be enabled.

  • If SUSE Manager serves monitoring-entitled systems and you want to acknowledge incoming alert notifications via email, you must have installed and configured a mail transfer agent such as postfix to properly handle email. This can be done with YaST.

  • Check the log files, if further tuning is needed—such as increasing OutOfMemoryError. For more information, see Section 7.6, “Log Files”.

3.4 Prerequisites

For the basic SUSE Manager setup, you need to have your mirror credentials from the NCC at hand. To look up your credentials and the email address with which you are registered in NCC, proceed as follows.

Procedure 3.1: Looking Up Mirror Credentials in NCC
  1. Start a Web browser and go to

  2. Log in to the NCC.

  3. Select Software › Mirror Credentials. A Web page opens showing your credentials (username and password).

  4. Memorize the username and the password listed there.

  5. Select your user name, then View Profile and memorize the email address with which you are registered.

  6. Log out from the NCC.

4 Installation

SUSE Manager is an appliance: a management server application combined with an operating system. It can be deployed on industry hardware or in a virtual environment and used with an embedded or a stand-alone database.

If your future SUSE Manager server is connected to the Internet, it will receive any updates directly from the Novell Customer Center. For a disconnected setup scenario, configure SUSE Manager to receive updates from an internal update server (like SMT) instead.

The YaST graphical user interface will guide you through the installation and the setup process. It is started in text mode. Use the →| key to navigate among individual elements. To select a value from a list, use the and arrow keys and press Enter. To activate an option, press the Space key.

For new features and changes, see Appendix F, Changes, Reference Guide.

To migrate an existing SUSE Manager server 1.7 to version 2.1, refer to Section 8.17, “Online Migration with YaST Wagon.

4.1 Summary of Steps

The following installation and setup scenarios, including all required steps for basic configuration of SUSE Manager are covered in this guide:

Setup From Scratch—With Internet Connection

For installation and initial setup, you need to execute the following basic steps:

  1. If using a stand-alone database: Preparing your database instance according to the formula provided in Chapter 3, Requirements.

  2. Installing the Appliance

  3. Setting Up SUSE Manager

Setup From Scratch—Without Internet Connection

For installation and initial setup, execute the same basic steps as listed above, but skip the registration of the product at NCC. For details, refer to Section 4.4, “Setup Without Internet Connection”.

Migration from a Satellite Server

Instead of setting up a SUSE Manager server from scratch, you can also migrate from an existing Satellite server. For details, refer to Section 4.6, “Server Migration”.

Important: Renaming SUSE Manager Server Not Supported

Choose the hostname of the SUSE Manager server carefully. Once installed renaming is not supported.

For more information, see

4.2 Installation

The following procedure describes the installation on a physical machine. Make sure the machine you intend to use fulfills the “Server Requirements”. If you want to install the appliance in a virtual machine, additionally check the settings listed in Virtual Environments.

Procedure 4.1: Installing the Appliance
Warning: Loss of Data

Installing SUSE Manager on a physical machine will completely erase any data on the hard disk that will be used for installation. Before you start the installation process, create a backup of your hard disks.

  1. Boot your future SUSE Manager server from the installation medium. Select Install/Restore SUSE Manager.

  2. If your machine contains more than one hard disk, you are asked which one to use for the installation of SUSE Manager. Navigate with the arrow keys, and use the space key to mark the desired hard disk. You are asked if you want to continue and you are warned that the installation will destroy all data on the disk.

  3. To proceed, answer with Yes. The deployment process takes over. This step may take some time as large amounts of data need to be unpacked and verified. After the verification, YaST firstboot is started.

  4. In the first screen, set the system Language and Keyboard Layout for your future SUSE Manager server. Proceed with Next.

  5. In the next screen, read the licenses and agree to them. Proceed with Next. The installation routine checks some basic system requirements and depending on the results, lets you decide whether to proceed with the installation or cancel.

  6. In the next screen, set the root password for your SUSE Manager server and confirm it.

    YaST Firstboot—Password for the System Administrator
    Figure 4.1: YaST Firstboot—Password for the System Administrator

    Proceed with Next.

  7. In the next screen, configure the network settings. Note the network requirements listed in Section 3.3, “Additional Requirements”. Either choose to Use Following Configuration or Change the network setup according to your wishes.

    YaST Firstboot— Network Configuration
    Figure 4.2: YaST Firstboot— Network Configuration

    Proceed with Next.

  8. In the next screen, configure the Clock and Time Zone to use for your SUSE Manager server. Proceed with Next.

  9. In the next screen, configure the NTP settings according to your wishes. For more information about the options, refer to Help. Note the NTP requirements listed in Section 3.3, “Additional Requirements”. Proceed with Next.

  10. In the next screen, your are asked to register and activate your product at NCC. During registration, the respective online update repositories are automatically configured.

    Important: NCC Registration and Updates

    Proper registration is mandatory for the system to receive updates and to ensure that any known installation problems are fixed. In case of a disconnected SUSE Manager setup, skip this step by selecting Configure Later.

    YaST Firstboot—NCC Configuration
    Figure 4.3: YaST Firstboot—NCC Configuration

    If you decide to Configure Later, you can call the respective YaST module on the SUSE Manager server with the yast inst_suse_register command any time.

    If you need to check the registration status of your SUSE Manager, use the isRegistered command on the server. If the system is registered, more detailed information is available in the /var/lib/suseRegister/registration-status.xml file.

    To register directly:

    1. Select Configure Now (Recommended).

    2. Confirm that you want to continue. A text-based browser (w3m) appears. Use the →| key or the arrow keys to navigate among individual elements. To enter data into an input field, activate text input mode by pressing the Enter key once, then enter the value and press Enter again to confirm.

    3. After all values are entered according to your wishes, Submit your input and press ShiftQ to close the text-based browser.

  11. On the Installation Completed screen, select Finish to close YaST firstboot. The boot process continues.

  12. Wait for the boot process to finish.

    Important: SUSE Manager Update Required

    After installation, update your SUSE Manager server to apply the latest patches before starting the setup process. To receive updates, registration at NCC (or a connection to an internal update server like SMT) is required. For details on how to execute the update, refer to Section “Updating Packages on SLE”, Chapter 2, Package Update Tools (SLE and RHEL), Reference Guide.

4.3 Setup

In the previous step you ran YaST firstboot and updated SUSE Manager server. Now use a setup script to configure the basic data for setup and the database connection on several consecutive screens. You run this via YaST. Enter a value in each input field, otherwise the setup may fail.

In the setup screens, you will also be prompted for two passwords.

Note: Password Criteria

Both passwords must match the following criteria (otherwise the connection to the database or the creation of the certificate might fail):

  • Length: At least 7 characters.

  • Special characters: Must not contain any of the following characters:

    • Spaces

    • Quotation marks (neither " nor ')

    • Exclamation marks (!)

    • Dollar symbols ($)

Procedure 4.2: Setting Up SUSE Manager
  1. Log in to the machine as root with the password you set during the installation in Step 6.

  2. Execute yast2 susemanager_setup to start the setup process.

  3. The first setup screen lets you choose between setting up SUSE Manager from scratch and migrating to SUSE Manager from a Satellite/Spacewalk compatible server. Choose Set up SUSE Manager from scratch. Proceed with Next.

    Figure 4.4: Setup—Type
  4. In the next setup screen, enter an email address for the SUSE Manager administrator. It is used for notifications by SUSE Manager and is associated with the SSL certificate to be created in the next step. In the same dialogue, decide whether SUSE Manager should advertise its services via SLP under the name susemanager. Clients can then find the closest SUSE Manager server to connect to. Proceed with Next.

  5. In the next setup screen, enter the details needed for the creation of an SSL certificate. The certificate is used for a number of purposes like connections to a proxy, HTTPS protocol in browsers, and more.

    1. Enter the name of your organization, the organization unit, and the city, state and country that your SUSE Manager server is located in. The Organization name defines the name of the default administrative organization that is automatically created during setup.

    2. Set an SSL (Secure Sockets Layer) password and repeat it in the next field.

      Figure 4.5: Setup—Certificate

      Proceed with Next.

  6. In the next setup screen, set the details for the setup of the server and the database:

    1. Decide whether to use the embedded (local) or a remote database for SUSE Manager.

      If you select Local Database, YaST automatically sets the Port and Protocol.

      To use an existing, remote database instead, select Remote Database and enter the following details for the connection to the database: the database system (SID) used to identify a particular database instance, the FQDN of the remote database, the external Port to use (usually 1521), and the Protocol to use (usually TCP).

    2. If you use the embedded database, set a user name and a password for the SUSE Manager database user (that is used to connect to the database).

      For a remote database, enter a user name that already exists in the database configuration, and enter the correct password for this user. Otherwise the connection to the database will fail.

    3. Repeat the password in the next field.

      Setup—Local Database
      Figure 4.6: Setup—Local Database

      Proceed with Next.

  7. The last setup screen asks for your SUSE Customer Center (SCC) credentials. Select Connect to SCC and enter your SCC Organization Credentials Username and SCC Organization Credentials Password.

    Setup—SCC Settings
    Figure 4.7: Setup—SCC Settings
    Note: NCC Settings

    In case you did not deploy all the offered packages, you might be asked to Connect to NCC and enter your NCC Mirror Credentials Username, the NCC Mirror Credentials Password, and your NCC Email Address.

    Because registering new installations at NCC is now discouraged, it is strongly recommended to install the missing packages and restart the setup procedure.

  8. Proceed with Next and confirm with Yes to start the setup.

    Note: Long Operation

    This step may take some time. Wait until the Setup is completed message appears in the upper part of the YaST screen.

  9. Click Next and read the instructions about the next steps. Close YaST by pressing Finish.

The basic SUSE Manager settings are written to /etc/rhn/rhn.conf. If you have chosen to use a local database, the initial database is created and populated. If you have chosen to use a remote database, the setup script connects to the database.

The setup script also runs the /usr/sbin/mgr-sync command which downloads the subscriptions listed in your Organization Credentials. The respective Software Channel Entitlements will be listed in the SUSE Manager Web interface (select Admin › Subscriptions).

To switch from a trial license to a full license, repeat server registration with the new registration key (or keys, in case more than one applies). Replace EMAIL_ADDRESS and REGISTRATION_CODE with appropriate values in this command:

suse_register -a email=EMAIL_ADDRESS -a regcode-sms=REGISTRATION_CODE

Then refresh SUSE Manager channels to reflect the new entitlements with the mgr-sync refresh command.

Tip: Running SUSE Manager Behind an HTTP Proxy

If mgr-sync fails because you are running the SUSE Manager server behind an HTTP proxy configured with YaST, check in the Web interface whether the proxy is actually known to SUSE Manager. For more information, see Section “Admin > SUSE Manager Configuration > General”, Chapter 12, Admin, User Guide.

Note: Accessing SCC uses proxy technologies to provide a fast download service world-wide. Depending on the location, the real hostname and the IP address is different.

To correctly setup company firewalls, to allow access to the repositories, check which proxy you are using with the following command:


4.4 Setup Without Internet Connection

If it is not possible to connect SUSE Manager directly or via a proxy to the Internet, a disconnected setup in combination with Subscription Management Tool (SMT) is the recommended solution. In this scenario, SMT stays in an external network with a connection to Novell Customer Center and synchronizes the software channels and repositories on a removable storage medium. Then you separate the storage medium from SMT, and let the SUSE Manager server mount it locally to read the data.

4.4.1 Basic Configuration and Usage

Procedure 4.3: SMT: Fetching Data from the Internet
  1. Install SMT in the external network with SUSE Customer Center (SCC) or Novell Customer Center (NCC) connection. For details about installing SMT, see

  2. In SMT, mirror all wanted repositories.

  3. Create a database replacement file (e.g., /tmp/dbrepl.xml):

    smt-sync --createdbreplacementfile /tmp/dbrepl.xml
  4. Mount a removable storage medium such as an external hard disk or USB flash drive.

  5. Export the data to the mounted medium:

    smt-sync --todir /media/disk/
    smt-mirror --dbreplfile /tmp/dbrepl.xml --directory /media/disk \
               --fromlocalsmt -L /var/log/smt/smt-mirror-export.log
    Note: Synchronizing Meta Data

    smt-sync also exports the subscription and entitlement data. To keep SUSE Manager up-to-date with the amount of subscriptions and entitlements, you must export and import these data frequently.

  6. Unmount the storage medium to carry it to your SUSE Manager server.

Continue with the configuration on your SUSE Manager server.

Procedure 4.4: SUSE Manager Server: Updating Data from the Storage Medium
  1. Mount the storage medium on your SUSE Manager server (e.g., at /media/disk).

  2. Specify the local path on the SUSE Manager server in /etc/rhn/rhn.conf:

    server.susemanager.fromdir = /media/disk

    This setting is optional if you are still using NCC with mgr-ncc-sync, while it is mandatory for SCC using mgr-sync.

  3. Restart Tomcat:

    rctomcat6 restart
  4. Do a full sync before anything else:

    mgr-sync refresh                       # SCC (fromdir in rhn.conf required!)
    mgr-ncc-sync --from-dir /media/disk    # NCC
  5. mgr-ncc or mgr-ncc-sync can now be used as usual. SCC, for example:

    mgr-sync list channels
        mgr-sync add channel channel-label

    With mgr-ncc-sync using NCC specify --from-dir parameter to point the sync to the mounted disk, if not set in rhn.conf:

    mgr-ncc-sync --from-dir /media/disk -l
    mgr-ncc-sync --from-dir /media/disk -c channel-name
    Warning: Data Corruption

    The disk must always be available at the same mount point. To avoid data corruption, do not trigger a sync, if the storage medium is not mounted. If you have already added a channel from a local repository path, you will not be able to change its URL to point to a different path afterwards (this includes NCC).

Now the up-to-date data are available on your SUSE Manager and ready for updating the client systems. According to your needs, refresh the data on the storage medium:

Procedure 4.5: Refreshing Data on the Storage Medium
  1. On the SUSE Manager server, unmount the storage medium to carry it to your SMT.

  2. On your SMT, continue with Step 4.

Warning: Data Corruption

The storage medium must always be available at the same mount point. To avoid data corruption, do not trigger a sync if the storage medium is not mounted.

4.4.2 Additional Settings

To disable the forwarding of registrations to Novell Customer Center via mgr-register, set the following value in /etc/rhn/rhn.conf:

server.susemanager.forward_registration = 0

Without this setting, the log file will be populated with many error messages.

4.5 Basic Configuration

To complete the basic SUSE Manager configuration, you need to execute the following steps:

4.5.1 Login to the Web Interface

After installation of the appliance, you need to log in and create the first administrator account for SUSE Manager. This administrator has access to all resources on SUSE Manager and has the right to create and manage user accounts. Additionally, he is given the role of an organization administrator for the default organization created during SUSE Manager installation and setup.

To access the SUSE Manager Web interface, ask your system administrator for the URL of your SUSE Manager server. It is shown on the console after completion of the installation— see Step 8 from Procedure 4.1, “Installing the Appliance”.

Procedure 4.6: Creating the SUSE Manager Administrator Account
  1. Start a Web browser. Enter the URL of your SUSE Manager server, using the Fully Qualified Domain name as in the following example: The SUSE Manager Web interface appears. On first login, you are prompted to create the SUSE Manager administrator account.

  2. Enter the data for the administrator account and click Create Login.

    You will be logged in as administrator.

  3. On the Overview tab, a message notifies you to finalize your basic system configuration. In the message, there's a link to the Setup Wizard, where you can add and manage products without having to pick individual channels. For more information on the setup wizard, see Section “Admin > Setup Wizard”, Chapter 12, Admin, User Guide.

4.5.2 Setup of SUSE Channels and Products

Channels are collections of repositories which are assigned to client systems. Without a channel, clients cannot be grouped nor can they receive updates.

Note: SUSE Manager Server Without Internet Connection

This procedure only applies to scenarios where your SUSE Manager server is connected to the Internet. For a disconnected scenario using Subscription Management Tool, refer to Section 4.4, “Setup Without Internet Connection”.

During installation, a first synchronization between Novell Customer Center and SUSE Manager is automatically done by mgr-ncc-sync. At this point, it only downloads the subscriptions to the products you have registered for. When you first log in to the SUSE Manager Web interface, there's a link to the Setup Wizard, where you can add and manage products without having to pick individual channels. For more information on the setup wizard, see Section “Admin > Setup Wizard”, Chapter 12, Admin, User Guide.

Note: Expanded Support

After adding Expanded Support channels to SUSE Manager, the parent channel (rhel-x86_64-server-6) needs to be filled with the RHEL DVD contents using the following command:

spacewalk-repo-sync -c rhel-x86_64-server-6 -u file:///path/to/mounted/dvd/

Without that, RHEL servers cannot be managed.

To manually import and synchronize specific channel data after installation, perform to the following procedure:

Procedure 4.7: Importing SUSE Channels from NCC
  1. On a shell, log in to the SUSE Manager server as root.

  2. Execute mgr-ncc-sync -l to view all channels that you are allowed to synchronize with SUSE Manager. The output lists both parent and child channels. The following notation is used to mark each channel:

    • [.]: A channel not imported or synchronized yet.

    • [p]: A previously imported or synchronized channel.

  3. Select the channels you want to import. You can only import child channels if their respective parent channel is already imported.

    Note: Deleting SUSE Channels

    By now, it is possible to delete SUSE channels with spacewalk-remove-channel.

  4. For each channel that you want to import, run mgr-ncc-sync with the -c option and add the respective channel label. For example:

    mgr-ncc-sync -c suse_sles_11.i586-base

    The respective channel data is imported into the SUSE Manager database and a full synchronization is triggered for that channel.

Note: Client Tools Channel

Make sure to also import the client tools channel. It provides the packages that need to be installed on a system to make it a SUSE Manager client system.

Any channel that has been imported is also displayed in the SUSE Manager Web interface. To see a list of all channels, go to the Channels tab and select SUSE Channels from the left navigation bar.

For setting up automatic channel synchronization, see Section 8.10, “Automating Synchronization”.

4.5.3 Client Setup

For a list of client systems supported by SUSE Manager, refer to Section 3.1.2, “Supported Client Systems”. Registering clients to SUSE Manager is done with a bootstrap script that deploys all necessary information to the clients. The bootstrap script refers some parameters like activation keys or GNU Privacy Guard (GPG) keys that depend on your particular setup.

Procedure 4.8: Creating Activation Keys

Activation keys define entitlements and which channels and groups the client system is allowed to subscribe to. This information is passed on to all systems registered with a key. Each activation key is bound to the organization for which it has been created.

Note: Activation Keys for New Organizations

If you need to create activation keys for a new organization, assign system entitlements first. For details, refer to Procedure “Assigning Entitlements to an Organization”, Reference Guide and Section 4.5.4, “Organization Management”. The default organization has all necessary prerequisites by default.

  1. Log in to the SUSE Manager Web interface as administrator.

  2. Switch to the Systems tab and select Activation Keys.

  3. Click the Create New Key link at the upper right corner.

  4. Enter a Description to identify the generated activation key.

  5. If you want the key to be generated automatically, leave the Key input field empty. If you want to use a certain string for the key, define the desired string in the Key input field.

    Warning: Allowed Characters

    Do not use commas within the key string. All other characters are allowed. Commas are used as separators when registering client systems with multiple activation keys with rhnreg_ks.

  6. To restrict the number of client systems that can be registered with the activation key, set a Usage Limit by entering a maximum number of systems.

    For unlimited use, leave this field empty.

  7. With Base Channels, set the primary channel for the key. This can be either the SUSE Manager Default channel or a custom base channel.

    Choosing SUSE Manager Default allows client systems to register with the default SUSE-provided channel that corresponds to their installed version of SUSE Linux Enterprise.

  8. Activate the Add-On Entitlements that you want to give to the client systems that are registered with that key.

  9. If all newly registered client systems of your organization should inherit the properties of this key, activate the Universal Default check box. Only one universal default activation key can be defined per organization.

    Warning: Changing the Default Activation Key

    Only one universal default activation key can be defined per organization. If some other key is already the default activation key for your organization, this check box will automatically unset the check box for that other key.

  10. Generate the key by clicking Create Activation Key. The prefix of the activation key indicates which organization (by ID number) owns the activation.

  11. To create more activation keys, repeat the steps above.

Example Activation Key
Figure 4.8: Example Activation Key
Note: Activation Key Update

After modifying or adding any components that are bound to an existing activation key (for example adding channels), make sure to update the key under Systems › Activation Keys › KEY_TO_MODIFY › Update Activation Key.

The next steps are to generate the script on the SUSE Manager server, then edit a copy of the script and run the modified script on each client machine that you want to register with SUSE Manager.

Procedure 4.9: Generating the Bootstrap Script

Several options in the bootstrap script can be set via the SUSE Manager Web interface, for example, if remote command execution or remote configuration of clients should be allowed.

  1. On the SUSE Manager Web interface, switch to the Admin tab and select SUSE Manager Configuration › Bootstrap Script.

  2. Check the options listed on the page and activate or deactivate them according to your needs.

    Note: Remote Command Execution and Configuration

    If you choose to Enable Remote Configuration or Enable Remote Commands, make sure that the rhncfg-actions package is installed on the client systems:

    1. Switch to the Systems tab and select Activation Keys.

    2. From the list of activation keys, click the one you want to modify.

    3. Click the Packages subtab, enter rhncfg-actions into the input field and click Update Key.

    The required package for remote command execution and configuration will automatically be installed on all client systems registered with the respective activation key.

  3. Click the Update button. The necessary bootstrap script is generated and stored on the server's file system in the /srv/www/htdocs/pub/bootstrap directory. It is also available from

  4. Proceed with the following procedure,Procedure 4.10, “Editing the Bootstrap Script and Registering Clients”.

Procedure 4.10: Editing the Bootstrap Script and Registering Clients

Adjust the generated bootstrap script according to your needs. The minimal requirement is to include the activation key. We strongly recommend to also include one or more GPG keys (for example, your organization key, and package signing keys). Then execute the resulting script on each client machine that you want to register with SUSE Manager (either centrally, from the SUSE Manager server, or decentralized, on each client.)

Note: Access to Installation Media During Registration

The bootstrap process triggers installation of packages on the client machines. Before executing the bootstrap script on a client, make sure the client can access its default installation medium: network access (in case of network repositories) or inserted DVD (in case of physical media).

  1. Log in as root to the SUSE Manager server.

  2. Create a copy of the automatically generated script:

    cd /srv/www/htdocs/pub/bootstrap
  3. Edit the copy as follows:

    1. Search for the ACTIVATION_KEYS entry and enter the activation key from Procedure 4.8, “Creating Activation Keys”. Make sure to also include the organization prefix in the key, for example:

    2. Search for the ORG_GPG_KEY entry and enter one or more filenames, separated by commas. The GPG key is located under the /srv/www/htdocs/pub/ directory and must be entered without any path name, for example:


      If you do not need or have a GPG key, search for the variable USING_GPG and set it to 0.

      Note: Package Signing Key for Red Hat Support

      If you receive maintenance and support for your Red Hat client systems through SUSE, make sure to include the package signing key you received from SUSE. Otherwise RPM packages cannot be installed on the Red Hat client systems. On the client system, run:

      rpm --import http://sumaserver/pub/res.key
      rpm --import http://sumaserver/pub/suse-307E3D54.key
    3. Adjust further parameters, if needed. For details, refer to the comments in

    4. To enable the script for execution, remove the exit 1 entry from the message block. The last lines of the message block should now read:

      echo "the exit below)"
  4. Save the edited version of the script.

  5. Use one of the following possibilities to execute the edited script on all client machines that you want to register with SUSE Manager:

    • Log in as root on the SUSE Manager server and execute the following commands:

      cd /srv/www/htdocs/pub/bootstrap/
      cat | ssh root@client_hostname /bin/bash
    • Log in to each client and execute the following command (all on one line):

      curl -Sks https://server_hostname/pub
      /bootstrap/ | /bin/bash

    The clients are registered with the SUSE Manager server as specified in the bootstrap script. The SUSE Manager Web interface shows the registered client systems on the Systems tab.

For more information about bootstrapping, refer to Chapter 5, Using Bootstrap, Client Configuration Guide.

Note: Client-side PackageKit Conflicting with Remote SUSE Manager package management

If client-side PackageKit conflicts with remote SUSE Manager package management, consider to uninstall PackageKit.

4.5.4 Organization Management

During installation and setup, SUSE Manager automatically creates a default administrative organization. It gets the organization ID 1 and the organization name that you entered in Step 5.a in Procedure 4.2, “Setting Up SUSE Manager”. For management of larger environments, create multiple organizations: for example, for different departments within your company—or for administering several distinct third-party companies.

For more information and details about creating organizations, refer to Section “Managing Organizations”, Chapter 5, Managing Multiple Organizations, Reference Guide.

4.5.5 Management of System and Software Entitlements

One important task after creating a new organization is to assign entitlements to the new organization. There are two types of entitlements that are important:

System Entitlements

Various categories of system entitlements are available: management, provisioning, monitoring, and virtualization entitlements. Having management entitlements is a base requirement for an organization to function in SUSE Manager.

Software Channel Entitlements

Apart from system entitlements, software channel entitlements are needed for each organization. For example, you must grant client tools channel entitlements to each organization (as this channels contains client software required for extended SUSE Manager functionality, such as AutoYaST or Kickstart or virtualization support).

For more details and instructions on how to transfer the respective entitlements from the default organization to any newly created organization, refer to Section “Managing Organization Entitlements”, Chapter 5, Managing Multiple Organizations, Reference Guide.

4.5.6 User Management

When first logging in to the SUSE Manager Web interface, the account for the first SUSE Manager administrator needs to be created as described in Procedure 4.6, “Creating the SUSE Manager Administrator Account”. The SUSE Manager administrator can then add more SUSE Manager users and grant and edit permissions for each user.

Note: Users and Organizations

Each user belongs to the organization within which the user account has been created. A user cannot belong to more than one organization. For creating or editing a user account, log in with an organization administrator account for the organization to which the user belongs or should belong.

Procedure 4.11: Creating User Accounts

Only organization administrators or SUSE Manager administrators can create and edit user accounts.

  1. Log in to the SUSE Manager Web interface as administrator. The top level row of the Web interface shows the organization you are currently logged in to.

  2. Switch to the Users tab and click the create new user link at the upper right corner.

  3. Enter the Desired Login and the Desired Password for the new user and confirm the password. Both login and password must consist of at least 5 characters.

  4. Enter the first and last name and the email address of the new user and click Create Login. The Web interface switches to the User List, showing either Active, Deactivated, or All users.

With the creation of a new user account, the user can log in to the SUSE Manager Web interface, but he does not have any administrative permissions yet. Administrative permissions are granted via roles. Each user can have multiple roles. To assign roles to a user and to set other permissions and options proceed as described in Procedure 4.12, “Editing User Accounts”:

Procedure 4.12: Editing User Accounts
  1. Log in to the SUSE Manager Web interface as administrator. The top level row of the Web interface shows the organization you are currently logged in to.

  2. Switch to the Users tab.

  3. From the left navigation bar, select if you want to see Active, Deactivated, or All users.

  4. From the list of users, click the user entry you want to modify. The Web interface shows the User Details for the selected entry. Apart from the user's name and password, the Details subtab also lets you assign roles to the user.

  5. Select the roles that you want to assign to the user. For detailed information about the roles, refer to Section “User List > Active > User Details > Details — [Mgmt]”, Chapter 10, Users — [Mgmt], User Guide. If you activate the Organization Administrator check box, the user will automatically inherit the roles listed below. To assign or remove individual roles, activate or deactivate the respective check boxes.

  6. Click Submit to confirm your changes on the Details subtab.

  7. To set or modify the user's permissions for system groups, systems or channels that exist within the current organization, switch to the respective subtabs and follow the instructions on the Web interface.

  8. To modify preferences, addresses or notification methods for the currently selected user, switch to the respective subtabs and confirm your changes.

Procedure 4.13: Adding or Removing the SUSE Manager Administrator Role

As SUSE Manager administrator, you can assign the permission to become SUSE Manager administrator to other users.

  1. Log in to the Web interface as SUSE Manager administrator.

  2. For an overview of all users that exist within SUSE Manager (across all organizations), switch to the Admin tab and select Users from the left navigation bar.

    A green check mark in the SUSE Manager Administrator column marks users that have the respective permission.

  3. To assign or remove the SUSE Manager administrator role, activate or deactivate the SUSE Manager Administrator check box for the respective user.

For more details about user management, refer to Chapter 10, Users — [Mgmt], User Guide.

4.5.7 Management of SUSE Manager with Database

For maintenance and administration purposes, SUSE Manager with Database is bundled with tools to administer your SUSE Manager database. Refer to the Reference Guide for more information.

4.6 Server Migration

If you have a SUSE Manager server installed in parallel to an existing Satellite server, you can migrate the Satellite server to SUSE Manager. The YaST SUSE Manager setup module first collects the necessary information. Then you execute the migration in several steps with the script as described in Procedure 4.14, “Migrating a Red Hat Satellite to SUSE Manager”. Use -h to see the available options:

/usr/lib/susemanager/bin/ -h
Note: Supported Migration

SUSE Manager supports migration from Satellite 5.3, 5.4, 5.5, and 5.6 servers. We recommend you get assistance from SUSE consulting, sales or partners.

Procedure 4.14: Migrating a Red Hat Satellite to SUSE Manager
  1. Log in to your existing SUSE Manager server as root.

  2. Execute yast2 susemanager_setup to start the YaST module.

  3. Select Migrate a Satellite/Spacewalk compatible server. Proceed with Next.

  4. In the next screen, enter the Hostname of the Satellite Server, its Domain Name, the Satellite Database Username, the Satellite Database Password, and the Satellite Database SID.

    Migration—Satellite Information
    Figure 4.9: Migration—Satellite Information

    Proceed with Next.

  5. In the next screen, enter the IP Address of the SUSE Manager Server, the Database Administrator Password (belonging to the database's root), and the email address of the SUSE Manager administrator.

    Migration—SUSE Manager Information
    Figure 4.10: Migration—SUSE Manager Information

    Proceed with Next.

  6. The next screen asks for details about the database to be migrated.

    1. If you want to migrate data from an embedded database, select Local Database. YaST automatically sets the Port and Protocol.

      To migrate data from an existing remote database instead, select Remote Database and enter the following details for the connection to the database: the database system (SID) used to identify a particular database instance, the FQDN of the remote database, the external Port to use (usually 1521), and the Protocol to use (usually TCP).

    2. Enter or set the name and password of the SUSE Manager database user (that is used to connect to the local or remote database).

    3. Repeat the password in the next field.

      Migration—Local Database
      Figure 4.11: Migration—Local Database

      Proceed with Next.

  7. The next screen asks for your organization credentials from the SCC. Enter your SCC Organization Credentials Username and the SCC Organization Credentials Password).

    Migration—SCC Information
    Figure 4.12: Migration—SCC Information

    Proceed with Next.

  8. Click Next to close YaST and to write the collected information to a file that will be parsed by the script during the next steps.

  9. Using the -r option, first copy the RPM packages and configuration files from the Satellite server:

    /usr/lib/susemanager/bin/ -r
    Important: Long Operation

    This step may take hours to finish.

  10. Before you start the final migration process, make sure that nothing is changed on your Satellite server from this point on. Log in to your Satellite server and shut down the Web interface:

    rcapache2 stop
  11. On the SUSE Manager server, start the final migration process:

    /usr/lib/susemanager/bin/ -m

    It synchronizes any remaining changes (that may have occurred during the first run with the -r option) and migrates the database.

  12. After the process has been finished successfully, shut down the Satellite server.

  13. In the DNS server, change the name of the Satellite server to the SUSE Manager server's IP address, so that the new SUSE Manager server gets the hostname of the former Satellite server.

From now on, use your SUSE Manager as a replacement for your Satellite server. Since the hostname is the same, all certificates will still work. Any registered clients are automatically directed to the SUSE Manager server.

5 SUSE Manager on IBM System z

5.1 Introduction

This best practice guide is intended for z/VM administrators responsible for operating the IBM System z Mainframe. The goal of this guide is to lead an z/VM administrator trained on normal System z operating protocols through the installation of SUSE Manager 2.1 onto an existing mainframe system. The intent of this article is not to cover the variety of hardware configuration profiles available on System z but instead to provide a foundational overview of the procedure and requirements necessary for a successful SUSE Manager server deployment.

5.2 Base System Requirements

The z/VM administrator should acquire and prepare the following resources for a successful SUSE Manager installation. SUSE Manager 2.1 for IBM z Systems is delivered as an appliance image. During setup it will be required to dump this SUSE Manager image onto a disk assigned to your designated z/VM guest. The following sections describe this procedure using the tools located on the SLES 12 installation media. These sections will provide you with the minimum recommended system requirements for SUSE Manager to include: hardware, database, and disk space. The base system for SUSE Manager 2.1 is SLES 11 SP3.

Hardware Requirements
Media Requirements

The following tables contain the network and device information used for this guide. Your configuration data including network and device numbers will be different.

Network Type

IP Addresses





FTP Server

Device Type

Device ID Number

EDEV Device


5.3 Additional Requirements

There are a few additional resource requirements you will need to prepare before installing the SUSE Manager appliance on your system. This section overviews these requirements.

Guest z/VM Network Information. The guest z/VM should be provided with a static IP address and hostname as these cannot be easily changed after initial setup. The hostname should contain less than 8 characters. For example: SUMA21

FTP Server Accessible from Guest. An ftp server must be reachable from the z/VM guest. This must contain the SUSE Manager installation media and a directory containing the contents of the SUSE Linux Enterprise 12 installation image. The extracted SLES12 directory is necessary for additional tools and will not be installed. For more information on loop mounting See also:

FTP Server Contents
  • Directory containing the extracted SLES12 installation image.
  • SUSE Manager image

parmfile for Network Configuration. A parmfile is required during the initial installation of SUSE Manager for network configuration. See also: (The parmfile-Automating the System Configuration)

Pre-Installation Storage Requirements. There are several storage devices that must be configured and added before installation of SUSE Manager. You are required to calculate sufficient disk storage for SUSE Manager before runningyast2susemanager_setup. The following information will help fulfill these requirements.

Warning: SUSE Manager Default Volume Groups and Disk Space

The SUSE Manager installation defaults to creating one volume group and a single volume for the root filesystem. The file system of SUSE Manager including the embedded database and patch directories will reside within this root volume. While adjustments are possible once installation has completed it becomes the administrators responsibility to specify and monitor these adjustments.

If your SUSE Manager runs out of disk space, this can have a severe impact on its database and file structure. Preparing storage requirements in accordance with this section will aid in preventing these harmful effects.

SUSE technical services will be unable to provide support for systems suffering from low disk space conditions as this can have an effect on an entire system and therefore becomes unresolvable. A full recovery is only possible with a previous backup or a new SUSE Manager installation.

Required Storage Devices
  • A read/writeable 191 minidisk with at least 100MB of available storage.

  • A 512-byte block EDEV emulated DASD device with at least 10GB of allocated space for SUSE Manager system files.

  • An additional disk is required for database storage. This should be an zFCP or DASD device as these are preferred for use with HYPERPAV. This disk should fulfill the following requirements

    At least 30GB for


    At least 100GB for

  • For more information regarding storage requirements see also:

5.4 Storage Preparation

This procedure covers the preparation of the required storage devices in the Additional Requirements section. It is assumed that the SLES 12 installation image contents have been extracted to a directory on your ftp server. For more information on loop mounting See also: >

  1. Logon to z/VM guest.

  2. Give access to the ftp command with:

    ==> vmlink tcpmaint 592
  3. Continue via ftp to your server:

    ==> ftp 
  4. Log on to your ftp server.

  5. On the ftp server change to the extracted SLES 12 installation media directory and execute the following commands:

    ==> get boot/s390x/sles12.exec sles12.exec.a
    ==> get boot/s390x/parmfile sles12.parmfile.a
    ==> bin 
    ==> locsite fix 80  
    ==> get boot/s390x/linux sles12.linux.a
    ==> get boot/s390x/initrd sles12.initrd.a
    ==> quit  
  6. Next prepare Initial Program Loader (IPL) with:

    ==> PIPE < SLES12 LINUX A | fblock 80 00 | > SLES12 LINUX A
    ==> PIPE < SLES12 INITRD A | fblock 80 00 | > SLES12 INITRD A
  7. Advance to the next section.

5.5 SUSE Linux Enterprise 12 Required Functionality

This procedure walks through the necessary steps of installing the SLES 12 tools to memory which are required for dumping the SUSE Manager image.

  1. Start the Installation of SLES12.

    ==> SLES12
    1. After initial boot select 1 to start installation.

      Main Menu
      0)<-- Back <--
      1) Start Installation
      2) Settings
      3) Expert
      4) Exit or Reboot
      ==> 1
    2. Select 1 to continue with the installation.

      Start Installation
      0)<-- Back <--
      1) Installation
      2) Upgrade
      3) Rescue System
      4) Boot Installed System
      5) Network Setup
      ==> 1
    3. Select 2 as the source medium.

      Choose the source medium
      0) <-- Back <--
      1) DVD / CD-ROM
      2) Network
      3) Hard Disk
      ==> 2
  2. You will now configure your network. Select 1 as the network protocol.

    Choose the network protocol
    0) <-- Back <--
    1) FTP
    2) HTTP
    3) HTTPS
    4) NFS
    5) SMB / CIFS (Windows Share)
    6) TFTP
    ==> 1
    1. Choose the network device appropriate for your configuration.

    2. Enter the port number if necessary.

    3. Enable OSI Layer 2 support (yes or no).

    4. Enter a mac address if necessary.

    5. Select automatic network configuration via DHCP only if your environment supports it.

  3. Next input your ftp information. Enter your ftp server address.

    Enter the name of the FTP server. (Enter '+++' to abort).
    1. Enter the directory which contains the SLES12 installation disk contents.

      Enter the directory on the server. (Enter '+++' to abort).
    2. Select user and password requirements, (yes or no) for your FTP server.

    3. Select proxy information (yes or no). The installation system will load.

  4. Select SSH as the desired display type. This will allow you to login via SSH.

    Select the display type.
    0) <-- Back <--
    1) X11
    2) VNC
    3) SSH
    4) ASCII Console
    ==> 3
    1. Enter a temporary SSH password

5.6 SUSE Manager Installation

This section covers the installation of SUSE Manager on the required EDEV device.

Procedure 5.1: Preparing EDEV Disk Device

The following procedure prepares the EDEV device for dumping the SUSE Manager image to and sets it as the default boot disk. Log into your SUSE Linux Enterprise System z guest as root and issue the following commands.

  1. Log into the SUSE Manager server guest via SSH.

    tux > ssh root@SUMA21
  2. Bring the disk online with:

    root# > chccwdev -e <EDEV_DEVICE_ID> 
  3. Use the lsdasd command to list devices available on your system and their assigned id's:

    root# > lsdasd
    Bus-ID     Status      Name      Device  Type  BlkSz  Size      Blocks
     0.0.0240   active      dasda     94:0    FBA   512    10240MB   20971520
  4. Continue by writing the SUSE Manager image to the EDEV disk device:

    root# > wget -O - ftp://your_ftpserver/susemanager21.raw.xz | xzcat > /dev/dasda

    Run sync to ensure the buffer is empty.

    root# > sync
  5. Wait for the image to finish dumping to disk.

  6. After the image has finished dumping to your EDEV disk, you must execute the following command. This command takes the device offline and sets it as the default boot disk.

    root# > chccwdev -d <EDEV_DEVICE_ID>
  7. On the 3270 console run the following command:

    ==> #cp ipl cms
  8. Create the SUMA21 PARM-S11 A file and add the required kernel parameters for your setup. See also

    Warning: Parameter Contents

    Configuration parameters in the parmfile are case sensitive. Note the following example.

    InstNetDev=osa Layer2=1
    OSAInterface=qdio OSAMedium=eth portno=0 portname=whatever
    ReadChannel=0.0.0800 WriteChannel=0.0.0801 DataChannel=0.0.0802
  9. Initial program load the edev device.

    ==> ipl <EDEV_DEVICE_ID>
  10. Log into the SUSE Manager server guest via SSH as root. The default password is linux.

  11. YaST firstboot will auto start. Accept the license agreement and Follow the steps to complete YaST firstboot procedures

  12. After firstboot procedures have completed continue by updating SUSE Manager using online update and reboot the system.

After rebooting you will need to setup the additional storage required for /var/spacewalk and /var/lib/pgSQL and swap space using the yast partitioner tool. This step is required before running yast2 susemanager_setup

After having configured the storage requirements, executed a yast update and completed a system reboot, run SUSE Manager setup to finalize the SUSE Manager installation on your System z mainframe:

root# > yast2 susemanager_setup

Proceed through the SUSE Manager setup until complete. For more information on a typical SUSE Manager setup, see also:

6 Importing and Synchronizing with Inter-Server Sync

After installing SUSE Manager, you must provide it with the packages and channels to be served to client systems. This chapter explains how to import that data and keep it up to date.

Two tool chains come installed as part of the spacewalk-backend-tools package: mgr-exporter for exporting and mgr-inter-sync for synchronization, as well as mgr-ncc-sync.

6.1 Exporting with mgr-exporter

The SUSE Manager exporter (mgr-exporter) exports a SUSE Manager content listing in an XML format that the user then can import into another SUSE Manager. Export the content into a directory specified with the -d option, transport the directory to another SUSE Manager, then use the mgr-inter-sync to import the contents. These three steps synchronize two SUSE Managers so they serve identical content.

The mgr-exporter tool can export the following content:

  • Channel Families

  • Architectures

  • Channel metadata

  • Blacklists

  • RPMs

  • RPM metadata

  • Patches

  • Kickstarts

  • Support Information

  • SUSE Product Data

  • SUSE Subscriptions

To perform a SUSE Manager export (mgr-exporter), the following prerequisites must be met:

  • A successful SUSE Manager installation.

  • There must be sufficient disk space in the directory specified with the --dir option. This directory will contain the exported contents.

6.1.1 Performing an Export

Export the current SUSE Manager configuration into a backup or storage solution by executing the following command as root:

mgr-exporter --dir=/var/sw-export --no-errata --channel channel_name

When finished, the export directory may be moved to another SUSE Manager or a storage solution using rsync or scp -r.

The mgr-exporter tool offers several command line options. To use them, insert the option and appropriate value after the mgr-exporter command.

mgr-exporter Options:

Place the exported information into this directory.


Process data for this specific channel (specified by label) only. NOTE: the channel's label is not the same as the channel's name.


List all available channels and exit.


List all of the steps that mgr-exporter takes while exporting data. These can be used as values for --step.

-p --print-configuration

Print the configuration and exit.


Print a report to the terminal when the export is complete.


Do not retrieve actual RPMs.


Do not export RPM metadata.


Do not process patch (errata) information.


Do not process kickstart data (provisioning only).


Override the amount of messaging sent to log files and generated on the screen set in /etc/rhn/rhn.conf, 0-6 (2 is default).


The start date limit that the last modified dates are compared against. Must be in the format YYYYMMDDHH24MISS (for example, 20071225123000).


The end date limit that the last modified dates are compared against. Must be typed in the format YYYYMMDDHH24MISS (for example, 20071231235900).


Create a channel dump ISO directory called ISOS (for example, --make-isos=cd or dvd).


Email a report of what was exported and what errors may have occurred.


Alternative email address for --email.


Include alternate database connect string: username/password@SID.


Export the RPM and kickstart files with hard links to the original files.

You can deselect some contents, such as RPMs, errata, or Kickstarts, which you do not want to export, by using the --no-* command line options. The default is to export everything.

The amount of time it takes mgr-exporter to export data depends on the number and size of the exported channels. The --no-packages, --no-kickstarts, --no-errata, and --no-rpms options reduce the amount of time required for mgr-exporter to run, but also prevents export of potentially useful information. For that reason, only use these options when certain the content is not required and can be excluded. Additionally, you must use the matching options for mgr-inter-sync when importing the data. For example, if you use --no-kickstarts with mgr-exporter you must specify the --no-kickstarts option when importing the data.

When exporting a base channel, you must also export the client tools channel associated with that base channel. This is because the tools channels contain the tools that install packages for autoinstalling a machine through SUSE Manager. For instance, if you export sles11-sp1-pool-x86_64 you must also export the sles11-sp1-suse-manager-tools-x86_64 channel in order to autoinstall machines to SUSE Linux Enterprise Server 11 SP1 x86_64.

6.2 Importing with SUSE Manager Synchronization Tool mgr-inter-sync

Before distributing packages via SUSE Manager, the packages must first be uploaded to the SUSE Manager server. This section describes the process for importing packages and other channel data.

6.2.1 mgr-inter-sync

The mgr-inter-sync tool enables a SUSE Manager server to update its database metadata and RPM packages from a SUSE Manager master server.

The SUSE Manager synchronization tool mgr-inter-sync can be used in a closed environment, such as the one created with a disconnected install, or it may obtain data directly from another SUSE Manager. Closed environment imports can get their data from the XML data generated by mgr-exporter.

mgr-inter-sync works incrementally, or in steps. To obtain patch (errata) information, it first requires information about the packages contained. For the packages to be updated, the tool first identifies the associated channels. For this reason, the SUSE Manager synchronization tool performs the following actions in order:

  1. channel-families — Import/synchronize channel family (architecture) data.

  2. channels — Import/synchronize channel data.

  3. rpms — Import/synchronize RPMs.

  4. packages — Import/synchronize full package data for those RPMs retrieved successfully.

  5. errata — Import/synchronize patch (errata) information.

Users can perform each of these steps individually for testing purposes with the effect of forcing the tool to stop when a step completes. All preceding steps, however, will execute. For example, calling the rpms step automatically ensures the channels and channel-families steps execute first. To initiate an individual step, use the --step option:

mgr-inter-sync --step=rpms

In addition to --step, the SUSE Manager synchronization tool offers many other command line options. To use them, insert the option and the appropriate value after the mgr-inter-sync command when launching import or synchronization.

SUSE Manager Import and Synchronization Options:
-h, --help

Display the list of options and exit.

-d=, --db=DB

Include alternate database connect string: username/password@SID.

-m=, --mount-point=MOUNT_POINT

Import or synchronization from local media mounted to the SUSE Manager. Use in closed environments (such as those created during disconnected installs).


List all available channels and exit.


Process data for this channel only. Multiple channels can be included by repeating the option. By default all channels on the SUSE Manager server will be refreshed. Use --list-channels to see the available channel labels.

-p, --print-configuration

Print the current configuration and exit.


Not Advisable - Turn off SSL.


Organization to which the sync imports data (default: the admin account).


Perform the synchronization process only to the step specified. Typically used in testing. By default, all steps are executed.


Do not retrieve actual RPMs.


Do not process full package data.


Do not process patch (errata) information.


Do not process Kickstart data (provisioning only).


Forcibly process all patch metadata without performing a diff.


Forcibly process all package metadata without performing a diff.


Override the amount of messaging sent to log files and generated on the screen set in /etc/rhn/rhn.conf, 0-6 (2 is default).


Email a report of what was imported/synchronized to the designated recipient of traceback email.


Direct synchronization output (from --email) to this mail address.

-s=, --server=SERVER

Include the hostname of an alternative server to connect to for synchronization.


Add an alternative HTTP proxy server in the form hostname:port.


Include the username for the alternative HTTP proxy server.


Include the password for the alternative HTTP proxy server.


Use an alternative SSL CA certificate by including the full path and filename.


For debugging only - Include path to alternative digital system ID.


For debugging only - Set maximum batch size in percent for XML/database-import processing.

6.2.2 Preparing for Import

To perform the SUSE Manager import, the following prerequisites must be met:

  • The SUSE Manager installation must have been performed successfully.

  • The SUSE Manager exporter (mgr-exporter) data or access to the master SUSE Manager must be available.

Procedure 6.1: Preparing SUSE Manager Exporter Data

To import data previously exported using SUSE Manager exporter, you must first copy that data onto the local system. The following steps prepare the import as described in Section 6.2.3, “Running the Import”.

  1. Log into the machine as root.

  2. Create a target directory for the files, such as:

    mkdir /var/sw-import/
  3. Make the export data available on the local machine in the directory created in the previous step. This can be done by copying the data directly or by mounting the data from another machine using NFS. The following is an example scp command copying the data into the new directory:

    scp -r* /var/sw-import

Now that the data is available, you can proceed to performing the import.

6.2.3 Running the Import

The susemanager-backend-tools package provides the mgr-inter-sync program for managing all package, channel, and patch (errata) imports and inter-server synchronizations. mgr-inter-sync is a symlink to satellite-sync.

The following process assumes the user has copied all data to /var/sw-import.

The first step in importing channels into the database is listing the channels available for import. This is accomplished with the command:

mgr-inter-sync --list-channels --mount-point /var/sw-import

The next step is to initiate the import of a specific channel. Do this using a channel label presented in the previous list. The command will look like:

mgr-inter-sync -c rhel-i386-6 --mount-point /var/sw-import

Importing package data can take up to two hours per channel. You can begin registering systems to channels as soon as they appear in the SUSE Manager Web interface. No packages are necessary for registration, although updates cannot be retrieved from SUSE Manager until the channel is completely populated.

Repeat this step for each channel or include them all within a single command by passing each channel label preceded by an additional -c flag:

mgr-inter-sync -c channel-label-1 -c channel-label-2 --mount-point /var/sw-import

This conducts the following tasks in this order:

  1. Populating the tables describing common features for channels (channel families). This can also be accomplished individually by passing the --step=channel-families option to mgr-inter-sync.

  2. Creating a particular channel in the database and importing the metadata describing the channel. Individually, use the --step=channels option.

  3. Moving the RPM packages from the temporary repository into their final location. Individually, use the --step=rpms option.

  4. Parsing the header metadata for each package in the channel, uploading the package data, and associating it with the channel. Individually, use the --step=packages option.

  5. Identifying patches (errata) associated with the packages and including them in the repository. Individually, use the --step=errata option.

  6. Syncing kickstart data. Individually, use the --step=kickstarts option.

After running the preceding sample command, the population of the channel should be complete. All of the packages should have been moved out of the repository; this can be verified with the following command sequence:

cd /var/sw-import/
ls -alR | grep rpm

If all RPMs have been installed and moved to their permanent locations, then this count will be zero, and the administrator may safely remove the temporary repository (in this case, /var/sw-import/).

6.3 Synchronizing

An update channel is only as useful as the freshness of the information in that channel. Since SUSE Manager is designed to be a standalone environment, any update advisories published by SUSE must be manually imported and synchronized by the administrator of the SUSE Manager.

During synchronization over the network, the SUSE Manager synchronization tool performs the following steps:

  1. Connects over SSL to the SUSE Manager master, authenticates itself as a SUSE Manager, and triggers an export of the channel data.

  2. Examines the export and identifies differences between the SUSE Manager data set and the exported SUSE data set. For a particular channel, the following information is analyzed:

    • Channel metadata

    • Metadata of all packages in that channel

    • Metadata for all patches (errata) that affect that channel


    All analysis is performed on the SUSE Manager slave; the master delivers only an export of its channel information and remains ignorant of any details regarding the SUSE Manager slave.

  3. After the analysis of the export data, any differences are imported into the SUSE Manager database. Note that importing new packages may take variable lengths of time. For a large update, an import can take several hours.

6.4 Inter-Server Synchronization

Inter-Server Synchronization (ISS) allows a SUSE Manager to synchronize content and permissions from another SUSE Manager instance in a peer-to-peer relationship. However, in the following section, a SUSE Manager which receives content will be referred to as a "Slave Server" and a SUSE Manager which acts as the source, where the content is pulled from, is called a "Master Server". When using ISS to synchronize content, the slave instance may have a different setup from that of the Master for non-content entities such as users and organizations. The administrator on the slave instance is free to add, remove, and change entities independently from what occurs on the master instance.


Master and slave are legacy terms that carry connotations that are not enforced by the ISS protocol. Keep their restricted meanings, as described above, in mind while reading this section.

With SUSE Manager 2.1, ISS allows the slave SUSE Manager to duplicate the organizational trust hierarchy and the custom channel permissions from the settings configured on the master. This is accomplished by exporting information about specific organizations from the master SUSE Manager to the receiving slave server. The administrator on the slave can then choose to map the master organizations to specific slave organizations. Future synchronization operations use this information to assign custom channel ownership to the slave organization, which is mapped to a specific master organization. It can also map the trust relationships between the exposed master organization to matching slave organizations, creating the equivalent relationships on the slave.


An inter-server sync between a SUSE Manager 1.7 server as master and a SUSE Manager 2.1 server as client will succeed but generate an error email to the admin. The error email is harmless and can be deleted.

6.4.1 Configuring the Master SUSE Manager Server

Log in to the Web interface as SUSE Manager administrator. Click on Admin › ISS Configuration › Master Setup. In the top right-hand corner of this page, click Add New Slave and fill in the following information:

  • Slave Fully Qualified Domain Name (FQDN)

  • Allow Slave to Sync? - Choosing this field will allow the slave SUSE Manager to access this master SUSE Manager. Otherwise, contact with this slave will be denied.

  • Sync all orgs to Slave? - Checking this field will synchronize all organizations to the slave SUSE Manager.


Choosing the Sync All Orgs to Slave? option on the Master Setup page will override any specifically selected organizations in the local organization table.

Click Create. Optionally, click on any local organization to be exported to the slave SUSE Manager then click Allow Orgs.


In SUSE Manager 1.7 the master server used the iss_slaves parameter in the /etc/rhn/rhn.conf file to identify which slaves were allowed to contact the master. SUSE Manager 2.1 uses the information in the Master Setup page to determine this information.

To enable the inter-server synchronization (ISS) feature, edit the /etc/rhn/rhn.conf file and set: disable_iss=0. Save the file and restart the httpd service with service httpd restart.

6.4.2 Configuring Slave Servers

Slave SUSE Managers can be configured during installation with YaST or later via the Web interface. During Installation with YaST

The SUSE Manager YaST module is able to setup a slave server.

In the dialog with the NCC credentials you can select between Connect to NCC and 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 name (FQDN) of the master server.

Note: Inter-server Sync and SUSE Customer Center (SCC)

Organization credentials are only needed for SCC connections, for slave server organization credentials are no longer needed.

The slave server forwards registrations to SUSE Customer Center by using the parent server as a proxy. A SUSE Manager server acting as a parent accepts register and de-register operations and forwards them directly to its parent. The top SUSE Manager server will send these requests to SCC and return the answers back the chain to the originally requesting slave server.

There are checks implemented that need to be passed before a SUSE Manager server forwards such a request. It checks, if the requesting slave is in the allowed list and it verifies the user and password. These must match the first configured credential. Web Interface

Slave servers are the machines that will receive content synchronized from the master server. To securely transfer content to the slave servers, the ORG-SSL certificate from the master server is needed. The certificate can be downloaded over HTTP from the /pub/ directory of any SUSE Manager. The file is called RHN-ORG-TRUSTED-SSL-CERT , but can be renamed and placed anywhere in the local file system of the slave, such as the /usr/share/rhn/ directory.

Log in to the slave SUSE Manager as administrator and click on Admin › ISS Configuration › Slave Setup. In the top right-hand corner, click Add New Master and fill in the following information:

  • Master Fully Qualified Domain Name (FQDN)

  • Default Master?

  • Filename of this Master's CA Certificate: use the full path to the CA Certificate.

Click Add New Master.

6.4.3 Performing Inter-Server Synchronization

Once the master and slave servers are configured, a synchronization can be performed by running the mgr-inter-sync command:

mgr-inter-sync -c YOUR-CHANNEL

6.4.4 Mapping SUSE Manager Master Server Organizations to Slave Organizations

The master SUSE Manager should now show up in the slave's setup page under Admin › ISS Configuration › Slave Setup. If it does not, check the steps above.

A mapping between organizational names on the master SUSE Manager allows for channel access permissions to be set on the master server and propagated when content is synced to a slave SUSE Manager. Not all organization and channel details need to be mapped for all slaves. SUSE Manager administrators can select which permissions and organizations can be synchronized by allowing or omitting mappings.

To complete the mapping, log in to the Slave SUSE Manager as administrator. Click Admin › ISS Configuration › Slave Setup and select a Master SUSE Manager by clicking its name. Use the drop-down box to map the exported master organization name to a matching local organization in the slave SUSE Manager, then click Update Mapping.

On the command line, issue the sync command on each of the custom channels to obtain the correct trust structure and channel permissions:

mgr-inter-sync -c YOUR-CHANNEL

6.4.5 Automated Configuration

The spacewalk-sync-setup tool allows users to specify a Master and Slave SUSE Manager instance and uses configuration files to set up the information described in both the master and slave setup. It can create a set of default configuration files if requested. Essentially, it automates the previous setup and mapped configuration for master-slave relationships.

For automated configuration to succeed, the following prerequisites must be met:

  • The spacewalk-util package needs to be installed on the system that will issue the spacewalk-sync-setup command.

  • Organizations with custom permissions must exist on the master SUSE Manager.

  • Existing organizations within the Slave SUSE Manager must be present. Configuring the Master SUSE Manager Server

Enable the inter-server synchronization (ISS) feature in the /etc/rhn/rhn.conf file:


Save the configuration file and restart the httpd service:

service httpd restart Configuring Slave Servers

Slave servers are the machines that will have their content synchronized by the master server. To securely transfer content to the slave servers, the ORG-SSL certificate from the master server is needed. The certificate can be downloaded over HTTP from the /pub/ directory of any SUSE Manager. The file is called RHN-ORG-TRUSTED-SSL-CERT, but can be renamed and placed anywhere in the local file system of the slave, such as the /usr/share/rhn/ directory.

Log in to the slave SUSE Manager as administrator and click Admin › ISS Configuration › Slave Setup. On the top right-hand corner, click Add New Master and fill in the following information:

  • Master Fully Qualified Domain Name (FQDN)

  • Default Master?

  • Filename of this Master's CA Certificate: use the full path to the CA Certificate.

Click Add New Master. Mapping Master Organizations to Slave Organizations

Log in to a system. It does not matter if it is a master or slave SUSE Manager, or a different system altogether as long as the system can access the public XMLRPC API of the master and slave SUSE Managers.

Run spacewalk-sync-setup on a command line interface:

spacewalk-sync-setup --ms=[Master_FQDN] \
  --ml=[Master_Sat_Admin_login] \
  --mp=[Master_Sat_Admin_password] \
  --ss=[Slave FQDN] --sl=[Slave_Sat_Admin_login]--sp=[Slave_Sat_Admin_password> \
  --create-templates --apply


  • --ms=MASTER, --master-server=MASTER is the FQDN of the Master to connect to,

  • --ml=MASTER_LOGIN, --master-login=MASTER_LOGIN is the administrator login for the master SUSE Manager,

  • --mp=MASTER_PASSWORD, --master-password=MASTER_PASSWORD is the password for the SUSE Manager administrator login on the master SUSE Manager,

  • --ss=SLAVE, --slave-server=SLAVE is the FQDN of the slave SUSE Manager to connect to,

  • --sl=SLAVE_LOGIN, --slave-login=SLAVE_LOGIN is the SUSE Manager administrator login for the slave server,

  • --sp=SLAVE_PASSWORD, --slave-password=SLAVE_PASSWORD is the password for the SUSE Manager administrator login on the slave server,

  • --ct, --create-templates is the option that creates both a master and a slave setup file for the master/slave pair,

  • --apply tells SUSE Manager to make the changes specified by the setup files to the specified SUSE Manager instances.


For more setup options, run spacewalk-sync-setup--help.

The output from this command will be as follows:

INFO: Connecting to [admin@master-fqdn]
INFO: Connecting to [admin@slave-fqdn]
INFO: Generating master-setup file $HOME/.spacewalk-sync-setup/master.txt
INFO: Generating slave-setup file $HOME/.spacewalk-sync-setup/slave.txt
INFO: Applying master-setup $HOME/.spacewalk-sync-setup/master.txt
INFO: Applying slave-setup $HOME/.spacewalk-sync-setup/slave.txt

On the command line, issue the mgr-inter-sync command on each of the custom channels to obtain the correct trust structure and channel permissions:

mgr-inter-sync -c channel-name

6.5 Organizational Synchronizing

Inter-Server Synchronization can also be used to import content to any specific organization. This can be done locally or by remote synchronization. This function is useful for a disconnected SUSE Manager with multiple organizations, where content is retrieved through channel dumps or by exporting from connected SUSE Managers and then importing into the disconnected SUSE Manager. Organizational synchronization can be used to export custom channels from connected SUSE Managers. It can also be used to effectively move content between multiple organizations.

Organizational synchronization follows a clear set of rules in order to maintain the integrity of the source organization:

  • If the source content belongs to a base organization, it will default to this base organization even if a destination organization is specified. This ensures that specified content is always in that privileged base organization.

  • If an organization is specified at the command line, content will be imported from that organization.

  • If no organization is specified, it will default to organization 1.

The following are three example scenarios where organizational IDs (orgid) are used to synchronize between SUSE Managers:

  1. Import content from a SUSE Manager master to a slave:

    mgr-inter-sync -c channel-name --orgid=2
  2. Import content from an exported dump of a specific organization:

    mgr-inter-sync -m /dump -c channel-name --orgid=2
  3. Import content from SUSE Manager Hosted (assuming the system is registered and activated). If the source organization is not specified, the base channel is chosen):

    mgr-inter-sync -c channel-name

6.6 Inter-Server Synchronization Use Cases

Inter-server synchronization (ISS) provides several different ways for synchronizing content, depending on the needs of the organization. The following are some of the more typical uses showcasing how to make the most of this feature depending on your environment.

Staging SUSE Manager Server
Figure 6.1: Staging SUSE Manager Server

In this example, the stage SUSE Manager is used to prepare the content and perform quality assurance (QA) to make sure that packages are fit for production use. After content is approved to go to production, the production SUSE Manager server can synchronize the content from the stage SUSE Manager.

Master Server and Slave Peers that include their own custom content
Figure 6.2: Master Server and Slave Peers that include their own custom content

In this example, the SUSE Manager master is the development channel, from which content is distributed to all SUSE Manager production slaves. Some SUSE Manager slaves have extra content not present in SUSE Manager master channels. These packages are preserved, but all changes from the SUSE Manager master are synchronized to SUSE Manager slaves.

SUSE Manager Slaves are Maintained Exactly as the SUSE Manager Master
Figure 6.3: SUSE Manager Slaves are Maintained Exactly as the SUSE Manager Master

In this example, the SUSE Manager master (e.g., a software or hardware vendor) provides data to its customer. These changes are regularly synchronized to the SUSE Manager slaves.

7 Troubleshooting

This chapter provides tips for determining the cause of and resolving the most common errors associated with SUSE Manager. For services and support options available for SUSE Manager, refer to

In addition, you may package configuration information and logs from SUSE Manager and send them to SUSE for further diagnosis. Refer to Section 7.14, “SUSE Manager Debugging” for instructions.

7.1 Installation and Configuration

If you have difficulties deploying the appliance, proceed according to the following list.

7.1.1 Installation and Basic Setup

CPU: 64-Bit and Virtualization Support

For running SUSE Manager in a virtual environment you need a machine with a recent Linux Kernel on either an Intel processor with VT (Virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V).

Test if your CPU supports hardware virtualization (and which set of extensions is used) by executing the following command:

egrep '(vmx|svm)' /proc/cpuinfo

If this command returns no output, your processor either does not support hardware virtualization, or this feature has been disabled in the BIOS. Enable virtualization support in the BIOS and try again. If in doubt, consult your mainboard manual.

If the output contains a svm string, your machine uses the AMD V extensions, if the output contains a vmx string, the Intel VT extensions are used.

Database Connection Error

If the setup script reports a database connection error, check if bridged networking is configured correctly on your virtual machine. As repairing the current installation will fail after a database connection error, fix the network settings in your virtual machine and start from scratch with a new SUSE Manager image.

Hostname and DNS

Make sure to fulfill the hostnames and DNS requirements listed in Section 3.3, “Additional Requirements”.

7.1.2 Basic Configuration

Client Is Not Registered

This is often caused by a missing channel assignment. For example, if you want to register a client running a 64-bit version of SUSE Linux Enterprise Server 11 SP1, you need to add one or more channels for that version of SUSE Linux Enterprise Server 11 SP1. Check if the required steps mentioned at the beginning of Section 4.5, “Basic Configuration” have been executed correctly.

Web Interface: Unavailable Functions

If any functions or entries in the Web interface are not available, check if you have the permission to access these functions. SUSE Manager uses a role-based model for granting permissions. For more information, refer to Section 4.5.6, “User Management” and Section 4.5.4, “Organization Management”.

Ports Required for Communication

The ports required for communication between SUSE Manager server, SUSE Manager Proxy server, client systems, and Novell Customer Center are listed in Section 3.3, “Additional Requirements”.

7.1.3 Mail and Notification Issues

If you as the administrator are not receiving mail notification from SUSE Manager, check and modify the following parameters in /etc/rhn/rhn.conf:


Defines the mail address of the system administrator of the SUSE Manager appliance. This mail address will only be used for error/warning/info messages from spacewalk services (java process, taskomatic tasks, etc.).


This is the mail address used by SUSE Manager to send notification mails about error messages and daily status reports. You can set this address that is valid for your organization.

7.2 General Problems

When having general problems, examine the log files related to the component exhibiting failures. For more information, see Section 7.6, “Log Files”.

A common issue is full disk space. For example, if you observe the halted writing in the log files, or logging suddenly stopped during writing, you likely have not enough disk space left. Run the following command to check the percentage in the Use% column:

df -h

In addition to log files, you can obtain valuable information by retrieving the status of your SUSE Manager and its various components. This can be done with the command:

/usr/sbin/spacewalk-service status

Furthermore, you can obtain the status of components such as the Apache Web server and the Task Engine individually. For example, to view the status of the Apache Web server, run the command:

rcapache2 status

If the Apache Web server is not running, entries in your /etc/hosts file may be incorrect. For more information, see Section 7.11, “Host Not Found/Could Not Determine FQDN”.

To obtain the status of the Task Engine, run the command:

rctaskomatic status

If a SUSE Manager's embedded database is in use, run one of the following commands to obtain its status:

service oracle status


service postgresql status

To determine the version of your database schema, run the command:


To list the character set types of your SUSE Manager's database, run the command:


If importing or synchronizing a channel fails and you cannot recover it in any other way, run this command to delete the cache:

rm -rf temporary-directory

Note that Section 6.2.2, “Preparing for Import” suggested that this temporary directory be /var/sw-import/.

Then restart the import or synchronization.

If zypper up or the push capability of SUSE Manager ceases to function, old log files might be the reason for this. Stop the jabberd daemon before removing these files. To do so, issue the following commands as root:

rcjabberd stop
cd /var/lib/jabberd
rm -f db*
rcjabberd start

7.3 Configuring Reliable SUSE Manager Setup

It is important to get the server/client SUSE Manager communication parameters right. For example, by default Apache is configured with 150 clients maximum (MaxClients). If you ping 1000 clients at the same time to perform a kernel update, this must fail. Even if you increase MaxClients to 1000, you will run out of database connections, which is configured to 400 by default.

osa-dispatcher is able to set a threshold on notifying clients to run rhn_check. In /etc/rhn/rhn.conf set

osa-dispatcher.notify_threshold = 80

to allow 80 clients in parallel to execute rhn_check. Note, clients doing "SSH PUSH" do not count. This is configured separately with the taskomatic.ssh_push_workers parameter.

Both settings together should not exceed Apache's MaxClients option. Better allow some unused connections for the webUI and internal communication. It is recommended to keep 20 or 30 free. As a rough calculation use:

notify_threshold + ssh_push_workers + 30 = Apache's MaxClients

7.4 Gathering Information with spacewalk-report

There are instances where administrators may need a concise, formatted summary of their SUSE Manager resources, whether it is to take inventory of their entitlements, subscribed systems, or users and organizations. Rather than gathering such information manually from the SUSE Manager Web interface, SUSE Manager includes the spacewalk-report command to fetch and display vital SUSE Manager information at once.


To use spacewalk-report, you must have the spacewalk-reports package installed.

spacewalk-report allows administrators to organize and display reports about content, systems, and user resources across SUSE Manager. Using spacewalk-report, you can receive reports on:

  • System Inventory: lists all of the systems registered to SUSE Manager.

  • Entitlements: lists all organizations on SUSE Manager, sorted by system or channel entitlements.

  • Patches: lists all the patches relevant to the registered systems and sorts patches by severity, as well as the systems that apply to a particular patch.

  • Users: lists all the users registered to SUSE Manager and any systems associated with a particular user.

spacewalk-report allows administrators to organize and display reports about content, systems, and user resources across SUSE Manager. To get the report in CSV format, run the following at the command line of your SUSE Manager server.

spacewalk-report report_name

The following reports are available:

Table 7.1: spacewalk-report Reports


Invoked as


Channel Packages


List of packages in a channel.

Channel Report


Detailed report of a given channel.

Cloned Channel Report


Detailed report of cloned channels.

Custom Info


System custom information.



Lists all organizations on SUSE Manager with their system or channel entitlements.

Patches in Channels


Lists of patches in channels.

Patches Details


Lists all patches that affect systems registered to SUSE Manager.

All patches


Complete list of all patches.

Patches for Systems


Lists applicable patches and any registered systems that are affected.

Host Guests


List of host-guests mapping.

Inactive Systems


List of inactive systems.

System Inventory


List of systems registered to the server, together with hardware and software information.

Kickstart Trees


List of kickstartable trees.

All Upgradable Versions


List of all newer package versions that can be upgraded.

Newest Upgradable Version


List of only newest package versions that can be upgraded.

Result of SCAP


Result of OpenSCAP sccdf eval.

Result of SCAP


Result of OpenSCAP sccdf eval, in a different format.

System Data


System data needed for splice integration.

System Groups


List of system groups.

Activation Keys for System Groups


List of activation keys for system groups.

Systems in System Groups


List of systems in system groups.

System Groups Users


Report of system groups users.

Installed Packages


List of packages installed on systems.

Users in the System


Lists all users registered to SUSE Manager.

Systems administered


List of systems that individual users can administer.

For more information about an individual report, run spacewalk-report with the option --info or --list-fields-info and the report name. The description and list of possible fields in the report will be shown.

For further information, the spacewalk-report(8) man page as well as the --help parameter of the spacewalk-report program can be used to get additional information about the program invocations and their options.

7.5 Changing the CSV Separator

The character used as the delimiter in downloadable CSV files throughout SUSE Manager can now be configured per user via the Web interface. When navigating to Your Preferences on the Overview page, the following options are available:

  • Comma (",", default)

  • Semicolon (";", compatible with Microsoft® Excel®)

Whenever downloading a CSV file from anywhere within SUSE Manager, the configured separator character will be used as the delimiter.

7.6 Log Files

If having trouble with SUSE Manager, examine the associated log files. Log files provide important information about the activity that has taken place on the device or within the application that can be used to monitor performance and ensure proper configuration. See Table 7.2, “Log Files” for the location of all the relevant log files.


There may be numbered log files (such as mgr-ncc-sync.log.1, mgr-ncc-sync.log.2, etc.) within the /var/log/rhn directory. When the current mgr-ncc-sync.log file fills up to a size as specified by the logrotate(8) daemon, rotated log files are created with a .NUMBER extension. The file with the highest number contains the oldest rotated logs.

Not all files are fully covered by the logrotate daemon. For example, with every run reposync log files get a new name containing date and time information—see its logrotate configuration in /etc/logrotate.d/spacewalk-backend-tools. If you want to keep only recent files in the /var/log/rhn/reposync directory and thus preventing the log process from filling up the storage space, specify after how many days untouched log files should be removed. Set the MAX_DAYS system configuration variable in /etc/sysconfig/rhn/reposync accordingly; then, the daily cron maintenance procedure removes outdated files.

Table 7.2: Log Files


Log File Location

Apache Web server


SUSE Manager


SUSE Manager Installation


Database installation (Embedded Database)


Database population


SUSE Manager Synchronization Tool


Monitoring infrastructure


Monitoring notifications


Task Engine (taskomatic)




XML-RPC transactions


If "OutOfMemoryError" strings appear in the rhn_taskomatic_daemon.log file, the parameter taskomatic.maxmemory in the /etc/rhn/rhn.conf file should be set to at least 4096 when dealing with a large number of packages and repositories. This parameter overrides the setting in /etc/rhn/default/rhn_taskomatic_daemon.conf.

7.7 Naming Custom Channels

To avoid conflicts, do not use names for custom channels that vendors such as SUSE or Red Hat use or might use.

7.8 Accessing Local Channels without Proxy

Even if a proxy is configured for accessing external Internet resources and a SUSE Manager Proxy for NCC connections and channel synchronization, it is possible to access local custom channels directly without a proxy.

To access local channels directly, set the server.satellite.no_proxy variable in /etc/rhn/rhn.conf accordingly.

server.satellite.no_proxy is a comma-separated list of hosts that do not use the proxy. Each name is matched as either a domain that contains the hostname or the hostname itself. For example, would match,, and, but not Additionally, it matches all subdomains; would also disable the proxy for This would be a valid setting:

server.satellite.no_proxy =,

The only allowed wildcard is a single * character, which matches all hosts, and thus effectively disables the proxy.

7.9 Using a Proxy with Certificates to Access the Internet

Some proxies need certificates to access the internet. Often these certificates are created on the own CA of the company. This will cause problems when SUSE Manager wants to access or servers. In these cases, you could see the following error messages:

In /var/log/tomcat6/catalina.out:
2015-04-28 09:31:00,886 [TP-Processor6] INFO  org.directwebremoting.log.accessLog - Method execution failed:
com.suse.scc.client.SCCClientException: peer not authenticated


2015-01-08 17:07:20,240 [TP-Processor6] ERROR com.redhat.rhn.manager.setup.SCCMirrorCredentialsManager - Error getting subscriptions for 6419084, PKIX path building failed:
wget will show the following:
 --2015-04-28 11:12:23--
 Resolving xxxxxxxxxxxxxx... yyy.yyy.yyy.yyy
 Connecting to XXXXXXXXXXXXXX|yyy.yyy.yyy.yyy|:8080... connected.
 Proxy request sent, awaiting response... 301 Moved Permanently
 Location: [following]
 --2015-04-28 11:12:23--
 Connecting to XXXXXXXXXXXXXX|yyy.yyy.yyy.yyy|:8080... connected.
 ERROR: cannot verify's certificate, issued by `/C=XX/O=XXXXXX/CN=XXXXXXXXXXXXXXX':
 Unable to locally verify the issuer's authority.
 To connect to insecurely, use `--no-check-certificate'.
 Unable to establish SSL connection.

To solve this issue use the following procedure:

  1. Copy the root and—if needed—intermediate CA certificates to /tmp

  2. Copy the files to /etc/ssl/certs and change suffix to .pem:

    cp /tmp/filename_of_root_CA.cer /etc/ssl/certs/filename_of_root_CA.pem
    cp /tmp/filename_of_intermediate_CA.cer /etc/ssl/certs/filename_of_intermediate_CA.pem
  3. Update the information for the SSL certificates:

    c_rehash /etc/ssl/certs
  4. Import the certificates into the java keystore:

    keytool -import -alias root -file /tmp/filename_of_root_CA.cer \
      -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit
    keytool -import -alias intermediate \
      -file /var/tmp/filename_of_intermediate_CA.cer \
      -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit
  5. The last step is to restart spacewalk:

    spacewalk-service restart

To check whether everything works, run the following commands:

mgr-sync refresh

It works correctly, if the wget call will cause a 404 http error.

7.10 Discovering Hosts and Subnets in the Network

The SUSE Manager Network Scanner is a tool for scanning the network and finding hosts and subnets in it. It consists of the SUSE Manager Network Discovery daemon and its client. By default, the daemon runs on the network port 5000.

7.10.1 Installation and Configuration

Procedure 7.1: Installation and Configuration Instructions
  1. On the SUSE Manager server install the SUSE Manager Network Discovery daemon and its client with the following commands as root:

    zypper install sm-network-discovery
    zypper install sm-network-discovery-client
  2. For configuring the network device on which the daemon is listening, see the sm-netscan.conf manpage. Additionally you can change other defaults according to your needs.

    Background information: The Network Scanner does not need the SNMP protocol or any other special hints about the network that you want to scan. However, it must be allowed to send ICMP packets to ping its targets. Thus it can work on any network layout without a specific configuration or assumptions that some credentials need to be sent somewhere in order to get the needed starting info.

7.10.2 Usage

The Network Scanner consists of two pars: the daemon that discovers the network and the client that returns the already captured data.

To start the daemon:

rcsm-network-discovery start

To view the scanned network, use the SUSE Manager Network Discovery client sm-netscan that comes with the --help option to display an online help.

Note: Scanning the Network

Scanning your network may take some time. So after starting the daemon, wait some minutes before running the client tool.

To see the found subnets:

sm-netscan --subnets

To see the hosts in particular subnets:

sm-netscan --hosts=SUBNET_IP

To retrieve the data in XML, pass the format parameter to the client tool.

For more details, see the sm-netscan manpage and the online documentation at

7.11 Host Not Found/Could Not Determine FQDN

SUSE Manager configuration files rely exclusively on fully qualified domain names (FQDN). Therefore, it is imperative that key applications are able to resolve the name of the SUSE Manager server into an IP address. Red Hat Update Agent and the Apache Web server are particularly prone to this problem with the applications issuing errors of "Host not found" and the Web server stating "Could not determine the server's fully qualified domain name" upon failing to start.

This problem typically originates from the /etc/hosts file. The /etc/nsswitch.conf file defines the methods and the order by which domain names are resolved. Usually, the /etc/hosts file is checked first, followed by Network Information Service (NIS) if used, followed by DNS. One of the files has to succeed for the Apache Web server to start and the client applications to work.

  1. To resolve this problem, check the /etc/hosts file. It looks like this: this_machine localhost.localdomain \
  2. In a text editor, remove the offending machine information so that the line in /etc/hosts looks like this: localhost
  3. Save the file and try to run the client applications or the Apache Web server again. If they still fail, explicitly identify SUSE Manager server's IP address in the file, such as: localhost this_machine
  4. Replace the value with the actual IP address of the SUSE Manager server. Keep in mind, if the IP address is specified here, the file will need to be updated in case the machine receives a new address.

7.12 RPC Connection Timeout Settings

RPC connection timeouts are configurable on the SUSE Manager server, SUSE Manager Proxy server, and the clients. For example, if package downloads take longer then expected, you can increase timeout values. spacewalk-proxy restart should be run after the setting is added or modified.

Set the following variables to a value in seconds specifying how long an RPC connection may take at maximum:

Server — /etc/rhn/rhn.conf:
server.timeout = number
Proxy Server — /etc/rhn/rhn.conf:
proxy.timeout = number
SUSE Linux Enterprise Server Clients (using zypp-plugin-spacewalk) — /etc/zypp/zypp.conf:
## Valid values:  [0,3600]
## Default value: 180
download.transfer_timeout = 180

This is the maximum time in seconds that a transfer operation is allowed to take. This is useful for preventing batch jobs from hanging for hours due to slow networks or links going down. If limiting operations to less than a few minutes, you risk aborting perfectly normal operations.

Red Hat Enterprise Linux Clients (using yum-rhn-plugin) — /etc/yum.conf:
timeout = number

7.13 Connection Errors

A common connection problem, indicated by SSL_CONNECT errors, is the result of a SUSE Manager server being installed on a machine with an inaccurate time. In that case, SSL certificates are created with inaccurate times during the installation process. If the time on SUSE Manager is then corrected, the certificate start date and time may be set in the future, making it invalid.

To troubleshoot this, check the date and time on the clients and on SUSE Manager with date.

The results should be nearly identical for all machines and within the "notBefore" and "notAfter" validity windows of the certificates. Check the client certificate dates and times with the following command:

openssl x509 -dates -noout -in /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT

Check the SUSE Manager server certificate dates and times with the following command:

openssl x509 -dates -noout -in /etc/apache2/ssl.crt/server.crt

By default, the server certificate has a one-year life while client certificates are valid for 10 years. If the certificates are incorrect, you can either wait for the valid start time, or create new certificates, with an accurate time setting.

Do the following to troubleshoot general connection errors:

  • Attempt to connect to SUSE Manager's database in the command line using the correct connection string as found in /etc/rhn/rhn.conf:

    sqlplus username/password@sid
  • Ensure SUSE Manager is using Network Time Protocol (NTP) and is set to the appropriate time zone. This also applies to all client systems and the separate database machine in SUSE Manager (if used with a stand-alone database).

  • Confirm the correct package:


    is installed on SUSE Manager, and the corresponding rhn-org-trusted-ssl-cert-*.noarch.rpm or raw CA SSL public (client) certificate is installed on all client systems.

  • Verify the client systems are configured to use the appropriate certificate.

  • If also using one or more SUSE Manager Proxy Servers, ensure each Proxy's SSL certificates are prepared correctly. The Proxy should have both its own server SSL key-pair and CA SSL public (client) certificate installed, since it serves in both capacities. Refer to Chapter 3, SSL Infrastructure, Client Configuration Guide for specific instructions.

  • Make sure client systems are not using firewalls of their own, blocking required ports.

7.14 SUSE Manager Debugging

If you have followed the steps above but still need more help, contact the SUSE support and provide SUSE Manager's configuration parameters, log files, and database information.

SUSE Manager provides a command line tool explicitly for this purpose. Log in to your SUSE Manager server as root and execute the following command:


It collects several pieces of information and stores them in a tarball:

Collecting and packaging relevant diagnostic information.
Warning: this may take some time...
   * copying configuration information
   * copying logs
   * copying cobbler files
   * copying monitoring moc logs
   * copying monitoring scout logs
   * copying ssl-build
   * copying /etc/sudoers
   * copying apache, oracle, tomcat, nocpulse entries from /etc/passwd
   * copying apache, oracle, tomcat, nocpulse entries from /etc/group
   * querying RPM database (versioning of Spacewalk, etc.)
   * querying schema version, database charactersets and database
   * get diskspace available
   * get database statistics
   * get schema statistics
   * copying audit.log
   * timestamping
   * creating tarball (may take some time): /tmp/spacewalk-debug.tar.bz2
   * removing temporary debug tree
Debug dump created, stored in /tmp/spacewalk-debug.tar.bz2

7.15 Resetting the SUSE Manager Password

If you want to change the password for your Web instance of SUSE Manager or you have forgotten it, use the satpasswd command. Log in to your SUSE Manager with SSH and run it like this:

satpasswd admin

Type your password twice or cancel with CtrlC.

7.16 Registering a Client Manually with suse_register

If you have problems registering your clients or you want to do it manually, use suse_register. Before you register a client, collect the following information:

  • Your email address.

  • Your product key, starting with regcode-. In the case of SUSE Manager, it is regcode-sms.

  • Your registration key. Get it from your Novell Customer Center.

To register your client, run suse_register as follows:

suse_register -n \
  -L register.log \
  -a email=YOUR_EMAIL \
  -a regcode-sms=REG_KEY

The -n option (--no-optional) collects so called optional data which can be necessary for your registration. However, this depends on your contract.

The -L option tells suse_register to write a log message to register.log. You need this if you have to provide detailed information about the registration process to our support.

Find other options and their explanations with --help.

7.17 Multiple Mirror Credentials

The Spacewalk backend (spacewalk-backend) and the SUSE Manager Tools (susemanager-tools) can handle multiple mirror credentials. Either log in to the Web interface and go to Admin › Setup Wizard, where you can add credentials on the Mirror Credentials page, or add additional credentials in /etc/rhn/rhn.conf as described below. For more information on the setup wizard, refer to Section “Admin > Setup Wizard”, Chapter 12, Admin, User Guide.

Procedure 7.2: Configuring Multiple Mirror Credentials
  1. Add all your additional credentials to /etc/rhn/rhn.conf as follows:

    # This is already configured. Do not change it.
    server.susemanager.mirrcred_user = 111111
    server.susemanager.mirrcred_pass = secret
    # Add an additional set of credentials like this:
    server.susemanager.mirrcred_user_1 = 222222
    server.susemanager.mirrcred_pass_1 = secret
    # Add as many additional credentials as needed by incrementing
    # the suffix (mirrcred_user_#); e.g.:
    server.susemanager.mirrcred_user_2 = 333333
    server.susemanager.mirrcred_pass_2 = secret

    The numbers appended to the mirrcred_ keys must be numbered consecutively. If you skip one number, mgr-ncc-sync will stop looking for more credentials.

  2. After editing /etc/rhn/rhn.conf, run:

    mgr-ncc-sync --refresh

Now, if you type mgr-ncc-sync -l, you will see a channel listing with the combination of all mirror credentials.

If you have configured client registration forwarding, all clients are registered against the company identified by mirrcred_user.

Warning: Changing Credentials

To change credentials, edit /etc/rhn/rhn.conf as needed. If the previous credentials were used by one of your installed channels and the new credentials no longer provide access to that channel, connecting to NCC for that channel will no longer work.

If mgr-ncc-sync detects that a channel is not accessible anymore with the so far used credentials, it will test all credentials listed in rhn.conf and the first one that works will be stored in the database for further use.

Only remove a channel (with spacewalk-remove-channel) if you are sure that you do not need it anymore!

For more information, see

7.18 Invoking Spacecmd

Spacecmd does not seem to accept commands or options, instead only prints a usage message.

When running spacecmd non-interactively, take care to escape arguments passed to the spacecmd functions. This involves inserting -- before the function name to prevent the arguments to the function to be treated as global arguments to spacecmd. Also escape any quotes that are passed to the function so that the shell does not interpret them.


spacecmd -s server1 -- softwarechannel_create -n \'My Channel\' \
  -l channel1 -a x86_64

8 Maintenance

SUSE Manager provides a unique environment not available to any other Novell Customer Center customers. In return, SUSE Manager also requires maintenance. This chapter discusses the procedures that should be followed to carry out administrative functions outside of standard use and to apply patches to SUSE Manager.

8.1 Managing SUSE Manager with spacewalk-service

Since SUSE Manager consists of a multitude of individual components, SUSE provides the command-line tool spacewalk-service which allows you to stop, start, or retrieve status information from the various services in the appropriate order. This tool accepts all typical commands:

/usr/sbin/spacewalk-service start
/usr/sbin/spacewalk-service stop
/usr/sbin/spacewalk-service restart
/usr/sbin/spacewalk-service reload
/usr/sbin/spacewalk-service enable
/usr/sbin/spacewalk-service disable
/usr/sbin/spacewalk-service status

Use spacewalk-service to shut down and bring up the entire SUSE Manager and retrieve status messages from all of its services at once.

In case you need to do a database schema upgrade, do the following:

Procedure 8.1: Performing a Database Schema Upgrade
  1. Stop SUSE Manager with spacewalk-service stop.

  2. Run spacewalk-schema-upgrade.

  3. Restart SUSE Manager with spacewalk-service start.

8.2 Updating SUSE Manager

If any critical updates are provided for SUSE Manager, they will be released in the form of a patch for SUSE Manager. Find a generic description on how to apply patches in Procedure 8.2, “Updating a SUSE Manager Server”. Depending on the patch, specific instructions may apply.

For SUSE Manager systems connected to the Internet, the best method for applying these patches is using zypper or YaST Online Update. Proper registration at Novell Customer Center is mandatory for the system to receive updates. For details, refer to Section 4.2, “Installation”. SUSE Manager systems not connected to the Internet (disconnected setup) will receive updates from an internal update server instead.

Procedure 8.2: Updating a SUSE Manager Server

As soon as SUSE Manager is up and running and the database is configured, updating the server requires more than executing zypper patch (or running YaST Online Update alternatively).

The steps below describe the generic procedure, but depending on the patch, specific instructions may apply.

Warning: Read Patch Advisory

Before applying any updates, make sure to read the patch advisory. Additional configuration steps may be required to apply certain updates, especially if they involve the database. In such cases, the advisory will contain specific and detailed information about necessary steps.

  1. Log in as root user to the SUSE Manager server.

  2. Stop the Spacewalk service:

    spacewalk-service stop
  3. Apply the patch using either zypper patch or YaST Online Update. For more information about zypper or YaST Online Update, refer to Section “Updating Packages on SLE”, Chapter 2, Package Update Tools (SLE and RHEL), Reference Guide.

  4. If the patch includes an update of the database schema, proceed as follows (otherwise skip the substeps below):

    1. If the SUSE Manager database is running on the same machine as your SUSE Manager server, start the database instance with

      /etc/init.d/postgresql start
    2. Upgrade the database schema with

  5. Start the Spacewalk service:

    spacewalk-service start
Important: Restart of Services and Applications

Services affected by a package update are not automatically restarted after the update—you need to restart them manually to avoid failures.

Also execute zypper ps to check for any applications that still use old code. Restart those applications.

8.3 Creating Up-to-date Bootstrap Repositories

To get up-to-date packages for the bootstrap repositories, use the mgr-create-bootstrap-repo command, but first you need to uninstall all packages in the old bootstrap repositories:

# zypper remove spacewalk-client-repository spacewalk-client-repository-sle-10-4 
spacewalk-client-repository-sle-10-3 spacewalk-client-repository-sle-11-1
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following packages are going to be REMOVED:
  spacewalk-client-repository spacewalk-client-repository-sle-10-3 
  spacewalk-client-repository-sle-10-4 spacewalk-client-repository-sle-11-1 

4 packages to remove.
After the operation, 62.5 MiB will be freed.
Continue? [y/n/?] (y): y
Removing spacewalk-client-repository-0.1-0.7.1 [done]
Removing spacewalk-client-repository-sle-10-4-0.1-0.7.2 [done]
Removing spacewalk-client-repository-sle-11-1-0.1-0.7.1 [done]
Removing spacewalk-client-repository-sle-10-3-0.1-0.7.2 [done] 

Now call the mgr-create-bootstrap-repo command for SLE-11-SP3-x86_64:

# mgr-create-bootstrap-repo
Enter product label: SLE-11-SP3-x86_64
copy 'spacewalk-client-tools-'
copy 'zypper-1.6.308-0.9.16.x86_64'
copy 'libzypp-9.37.1-0.7.1.x86_64'
copy 'satsolver-tools-0.17.7-'
copy 'zypp-plugin-python-0.3-2.5.38.x86_64'
copy 'zypp-plugin-spacewalk-0.9.5-0.5.5.x86_64'
copy 'spacewalk-check-'
copy 'spacewalk-client-setup-'
copy 'newt-0.52.10-1.35.113.x86_64'
copy 'libnewt0_52-0.52.10-1.35.113.x86_64'
copy 'python-newt-0.52.10-1.35.113.x86_64'
copy 'python-dmidecode-3.10.11-0.10.1.x86_64'
copy 'python-ethtool-0.7-'
copy 'python-openssl-0.7.0-1.17.2.x86_64'
copy 'rhnlib-'
copy 'spacewalksd-'
copy 'suseRegisterInfo-1.7.4-0.5.1.x86_64'
copy 'libcurl4-7.19.7-1.28.1.x86_64'
copy 'slang-2.1.1-58.18.x86_64'
Spawning worker 0 with 26 pkgs
Workers Finished
Gathering worker results

Saving Primary metadata
Saving file lists metadata
Saving other metadata

Repeat the command for SLE-11-SP1-x86_64 and SLE-11-SP2-x86_64 if necessary. Now you have the latest package versions for your bootstrap repositories. For bootstrapping SUSE Linux Enterprise Server_11_SP_1 clients, you need to create a compatibility symlink:

cd /srv/www/htdocs/pub/repositories
ln -s sle/11/1/bootstrap susemanager-client-setup

For more information, refer to the mgr-create-bootstrap-repo manpage.

8.4 Backing Up SUSE Manager

Backing up SUSE Manager can be done in several ways. Regardless of the method chosen, the associated database also needs to be backed up. For the stand-alone database, consult your organization's database administrator. For the embedded database, refer to Section 8.6, “Configuring SUSE Manager's Database (smdba)” for a complete description of this process and the options available.

SUSE recommends backing up the following files and directories:

  • /rhnsat/ — embedded database only (never to be backed up while the database is running)

  • /etc/sysconfig/rhn/

  • /etc/rhn/

  • /etc/sudoers

  • /etc/tnsnames.ora

  • /srv/www/htdocs/pub/

  • /var/spacewalk/packages/1 — custom RPMs

  • /root/.gnupg/

  • /root/ssl-build/

  • /etc/dhcp.conf

  • /tftpboot/

  • /var/lib/cobbler/

  • /var/lib/rhn/kickstarts/

  • /srv/www/cobbler

  • /var/lib/nocpulse/

SUSE recommends to back up the entire /var/spacewalk/ tree. In case of failure, this will save lengthy download time. Since /var/spacewalk/ (specifically /var/spacewalk/packages/NULL/) is primarily a duplicate of the package repository, it can be regenerated with mgr-ncc-sync. In the case of disconnected SUSE Managers, /var/spacewalk/must be backed up.

Backing up only these files and directories requires reinstalling the SUSE Manager RPMs and re-registering SUSE Manager (see Section 4.2, “Installation”). In addition, packages need to be resynchronized using the mgr-ncc-sync tool. Finally, you have to reinstall the /root/ssl-build/rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm.

Another method is to back up all the files and directories mentioned above but reinstall the SUSE Manager without re-registering it. During the installation, cancel or skip the registration and SSL certificate generation sections.

The most comprehensive method is to back up the entire machine. This saves time in downloading and reinstalling but requires additional disk space and backup time.


Regardless of the backup method used, when restoring SUSE Manager from a backup, you must run the following command to schedule the recreation of search indexes the next time the rhn-search service is started:

rcrhn-search cleanindex

8.5 Migrating Patches from Old to New Naming

Version 1.2 of SUSE Manager had the following syntax of patch names:


This has been changed to a simpler notation:


After the migration has been successfully performed, the patches are listed twice after the first channel synchronization. The old names are still preserved and the new patch names are added. If you wish, the old names can be deleted (see below).

To migrate the old names to the new names, use the mgr-clean-old-patchnames command. It requires either a specific channel (using the -c option) or apply the conversation to all channels (using the -a option). However, the -a option removes all patches from cloned channels.

If a patch is not referenced from a channel, it will be deleted. In case you have a patch which is deleted from a specific channel, the patch will be preserved if it is also used in another channel.

For example, to execute the conversation process only for a SLES11 SP1 channel on a 64 bit architecture, use the following command:

mgr-clean-old-patchnames -c sles11-sp1-pool-x86_64

8.6 Configuring SUSE Manager's Database (smdba)

SUSE Manager provides the smdba command for managing the installed database. It is the successor of db-control, which is not supported anymore.

The smdba command works on local databases only, not remote. This utility allows you to do several administrative tasks like backing up and restoring the database, everything from creating, verifying, and restoring backups to obtain the database status and restart the database if necessary. The smdba command supports PostgreSQL 9.1 and Oracle 10g or 11g databases with different feature sets.

Important: Running smdba Relies on sudo Enablement

Running smdba relies on proper sudo configuration. sudo allows you to invoke smdba as a regular user and thus, you are save from executing unwanted system changes.

For example, to allow the user admin (the administrative UID) to execute smdba commands, and thus manipulating the underlying database with the operative UID, make sure something as follows is configured in /etc/sudoers:

admin   ALL = (oracle, postgres) /usr/bin/smdba

With this settings admin will be allowed to access the target database account (oracle or postgres).

For configuring sudo and its security implications, see the sudo and sudoers manpages and the extensive comments in the /etc/sudoers configuration file.

Find basic information about smdba in the smdba manpage.

Note: Restart Spacewalk Services When Connection is Lost

If you have stopped or restarted the database, it can happen that the Spacewalk services lost their connections. In such a case, run the following command:

spacewalk-service restart

8.6.1 Control Options

Depending on the database installed, smdba provides several subcommands; for the list of control options, see Section “Control Options”, Appendix A, Command Line Configuration Management Tools, Reference Guide.

Note: smdba help Output Depends on the Database Used

For a list of available commands on your particular appliance, call smdba help. Each subcommand can contain different options depending on the database used. To display the help message for a specific subcommand, call smdba COMMAND help.

8.6.2 Starting and Stopping the Database

There are three commands to start, stop, or get the status of the database. These commands work with both databases. Use the following commands:

smdba db-status
Checking database core...       online
smdba db-stop
Stopping the SUSE Manager database...
Stopping listener:     done
Stopping core:         done
smdba db-status
Checking database core...       offline
smdba db-start
Starting listener:     done
Starting core...       done

8.6.3 Backing up the Database

Backing up the database depends on the installed database:


The smdba command can be used to create a hot backup, which is a backup that is performed without shutting down the database.


The smdba command performs a continuous archiving backup.

To perform a hot backup for Oracle, do the following:

  1. For Oracle, there is no need to specify the space where to store the backups. By default, backups will be stored at /opt/apps/oracle/flash_recovery_area/uppercase SID/.

  2. Perform the hot backup:

    smdba backup-hot
    Backing up the database:       finished
    Data files archived:
    Archive logs:

    After the command returns without any errors, it contains some files in the flash_recovery_area directory.

  3. Get a list of available backups:

    smdba backup-list
    Getting available backups:    finished
    Backups available:
    Name:   /opt/apps/oracle/flash_recovery_area/SUSEMANAGER/backupset/2013_06_13/o1_mf_nnndf_TAG20130613T165358_8vmq8722_.bkp
            Type: Full      Date: 13-JUN-13         File:
            Type: Full      Date: 13-JUN-13         File:
            Type: Full      Date: 13-JUN-13         File:
            Type: Full      Date: 13-JUN-13         File:
            Type: Full      Date: 13-JUN-13         File:
    Name:   /opt/apps/oracle/flash_recovery_area/SUSEMANAGER/backupset/2013_06_14/o1_mf_nnndf_TAG20130614T040008_8vny9932_.bkp
            Type: Full      Date: 14-JUN-13         File:
            Type: Full      Date: 14-JUN-13         File:
            Type: Full      Date: 14-JUN-13         File:
            Type: Full      Date: 14-JUN-13         File:
            Type: Full      Date: 14-JUN-13         File:

To perform a hot backup for PostgreSQL, do the following:

  1. Allocate permanent space on your remote storage, which you use for general backups (NAS, iSCSI target, etc.). For example:


    This directory should always be the same and never change. It will be a permanent target to store new backups and restore from it during a disaster recovery.

  2. Create a directory with the correct permissions in your target directory, e.g., with using sudo:

    sudo -u postgres mkdir /mnt/backup/database

    Alternatively, as root:

    install -d -o postgres /mnt/backup/database


    mkdir /mnt/backup/database
    chown postgres:postgres /mnt/backup/database
  3. If you want to create a backup for the first time, run:

    smdba backup-hot --enable=on --backup-dir=/mnt/backup

    This command performs a restart of the PostgreSQL database. If you want to renew the basic backup, use the same command.

  4. Perform the hot backup:

    smdba backup-hot --backup-dir=/mnt/backup/database

    If the command exits without any errors, find the backup files in your /mnt/backup/database directory.

8.6.4 Restoring Backups

Use smdba backup-restore to restore to an earlier point in time. To restore the backup, proceed as follows:

  1. Shutdown the database:

    smbda db-stop
  2. Start the restore process:

    smdba backup-restore start
  3. Restart the database:

    smbda db-start

The above steps can be combined with:

smdba backup-restore force

In this case it will select the most recent backup and purge the rest. Every time you create a new backup, it also purges the previous backups.

Note: Restoring the Most Recent Backup Only

Because smdba makes automatic hot backups, it allows to restore only the most recent backup, and merging the current archive logs on top of it.

8.6.5 Archive Log Settings

In SUSE Manager with an embedded database, archive logging is enabled by default. This feature allows the database management tool smdba to perform hot backups.

With archive log enabled, far more data is stored on the hard disk:

  • Using an Oracle database, the archive log data will be removed as soon as you create a database backup with smdba.

  • With PostgreSQL only a limited number of archive logs is kept. With the default configuration, approx. 64 files with a size of 16 MiB are kept.

Creating a user and syncing the channels:

  • sles11-sp1-pool-x86_64

  • sles11-sp1-updates-x86_64

  • sles11-sp2-core-x86_64

  • sles11-sp2-updates-x86_64

will produce on PostgreSQL ~1 GB and on oracle ~7 GB additional data. So it is important to think about a backup strategy and create a backup in a regular way.

The archive logs are stored in:

  • /var/lib/pgsql/data/pg_xlog/ (PostgreSQL)

  • /opt/apps/oracle/oradata/sid/ (Oracle)

8.6.6 Getting Overview of Occupied Database Space

Database experts can use the subcommand space-overview to get a report about occupied table spaces, for example:

smdba space-overview

Tablespace | Size (Mb) | Used (Mb) | Avail (Mb) | Use %
DATA_TBS   | 193.5     | 306.5     | 500        | 61   
SYSAUX     | 38.75     | 631.25    | 670        | 94   
SYSTEM     | .75       | 719.25    | 720        | 99   
TEMP       | 76        | 0         | 76         | 0    
UNDOTBS1   | 161.625   | 13.375    | 175        | 7    
USERS      | 3.6875    | 1.3125    | 5          | 26

This command is available for both databases, Oracle and PostgreSQL. For a more detailed report, use the space-tables subcommand. It lists the table and its size, for example:

smdba space-tables

Table                          | Size     
PXTSESSIONS                    | 64.00K   
QRTZ_BLOB_TRIGGERS             | 64.00K   
QRTZ_CALENDARS                 | 64.00K   
QRTZ_CRON_TRIGGERS             | 64.00K   
QRTZ_FIRED_TRIGGERS            | 64.00K

8.6.7 Migrating Embedded Database from Oracle to PostgreSQL

SUSE Manager provides a tool for easy migration of an embedded Oracle database to PostgreSQL. Simply run: /usr/lib/susemanager/bin/

This script performs all necessary steps. For transparency reasons only, we line out what happens during the migration:

  1. install_latest spacewalk-utils: installs all tools necessary for migration.

  2. install_latest susemanager-schema: since schema versions must be identical, the new PostgreSQL database uses the existing schema.

  3. spacewalk-service stop: halts the spacewalk service while the database keeps running.

  4. upgrade_schema: upgrades to the new schema.

  5. dump_schema: writes all schema data to the hard disk as plain text, which should take a while.

  6. switch_oracle2postgres: stops the Oracle database, removes it from the boot process (insserv -r oracle), then deletes all spacewalk Oracle packages and installs the necessary PostgreSQL packages.

  7. setup_postgres: initializes and configures the database.

  8. configure_suma: loads the database with the schema and rewrites the configuration files for PostgreSQL.

  9. import_schema: loads all data into the database, which will take a while.

  10. spacewalk-service start: starts all services.

8.7 Cloning SUSE Manager with the Embedded Database

You may limit outages caused by hardware or other failures by entirely cloning the SUSE Manager server with its embedded database. The secondary server can take over if the primary one fails. To clone the SUSE Manager server, perform these tasks:

  1. Clone the SUSE Manager server at the operating system level (OS level) with your backup tools (e.g., rsync) to a separate machine. As needed, repeat this step daily.

  2. Back up the primary SUSE Manager database daily using the commands described in Section 8.6, “Configuring SUSE Manager's Database (smdba)”. If this is done, only changes made the day of the failure will be lost.

  3. Establish a mechanism to copy the backup to the secondary SUSE Manager and keep the repositories synchronized using a file transfer program such as rsync. If you are using a SAN, copying is not necessary.

  4. Use the smdba backup-restore subcommand to import the database backup data.

  5. If the primary SUSE Manager fails, change DNS to point to the new machine or configure your load-balancer accordingly.


The database backup is valid only on an identical system clone, which can be restored only from the backup as described above. The database backup will not work on a system that you reinstalled from NCC!

8.8 Establishing Redundant SUSE Manager Servers with Stand-Alone Database

If you are using a standalone database, you can limit outages on SUSE Manager servers by preparing redundant SUSE Manager servers. Unlike cloning a SUSE Manager with Database, redundant SUSE Manager servers with stand-alone database may be run as active, as well as standby. This is entirely up to your network topology and is independent of the steps listed here.

To establish this redundancy, first install the primary SUSE Manager server as usual, except that the value specified in the Common Name field for the SSL certificate must represent your high-availability configuration rather than the hostname of the individual server. Proceed with the following steps:

  1. Consult your database administrator on how to prepare the stand-alone database for failover, using Oracle's recommendations for building a fault-tolerant database.

  2. Install SUSE Manager with stand-alone database on a separate machine, skipping the database configuration, database schema, SSL certificate, and bootstrap script generation steps. Include the same Novell Customer Center account and database connection information provided during the initial SUSE Manager installation and register the new SUSE Manager server.

    If your original SSL certificate does not take your high-availability solution into account, create a new one with a more appropriate Common Name value now. In this case, also generate a new bootstrap script that captures this new value.

  3. After installation, copy the following files from the primary to the secondary SUSE Manager:

    • /etc/rhn/rhn.conf

    • /etc/tnsnames.ora

  4. Copy and install the server-side SSL certificate RPMs from the primary SUSE Manager to the secondary. Refer to Chapter 3, SSL Infrastructure, Client Configuration Guide in the Client Configuration Guide for information on SSL infrastructure. Remember, the Common Name value must represent the combined SUSE Manager solution, not a single machine's hostname.

    If you generated a new SSL certificate during the SUSE Manager installation that included a new Common Name value, copy the SSL certificate RPMs from the secondary to the primary server and redistribute the client-side certificate. If you also created another bootstrap script, you may use this to install the certificate on client systems.

  5. If you did not create a new bootstrap script, copy the contents of /srv/www/htdocs/pub/bootstrap/ from the primary server to the secondary. If you did generate a new one, copy that directory's contents to the primary SUSE Manager.

  6. Turn off the Task Engine on the secondary server with the following command:

    rctaskomatic stop

    You may use custom scripting or other means to establish automatic start-up or failover of the Task Engine on the secondary server. It will need to be started upon failover.

  7. Share channel package data (by default located in /var/spacewalk) between the SUSE Manager servers via a networked storage device. This eliminates data replication and ensures a consistent store of data for each SUSE Manager.

  8. Share cache data (by default located in /var/cache/rhn) between the SUSE Manager servers via a networked storage device. This eliminates data replication and ensures a consistent store of cached data for each server.

  9. Make the various SUSE Manager servers available on your network via Common Name and a method suiting your infrastructure. Options include round-robin DNS, a network load-balancer, and a reverse-proxy setup.

8.9 Conducting SUSE Manager-Specific Tasks

8.9.1 Deleting Users

If you need to delete users, click Users in the top navigation bar of the SUSE Manager Web site. In the resulting user list, click on the name of the user to be removed. On the user's Details page, click the delete user link at the top-right corner.

User Deletion
Figure 8.1: User Deletion

Confirm removal of this user by clicking the Delete User button.

User Delete Confirmation
Figure 8.2: User Delete Confirmation

The delete operation fails if the user has the organization administrator role. Remove the organization administrator role from the user's profile before deleting the user from SUSE Manager.

Any organization administrator can remove the organization administrator role, provided there is at least one other organization administrator for the organization. To do so, click on the Users tab and then click the Details subtab.

8.9.2 Configuring SUSE Manager Search

SUSE Manager search results can be customized via the /etc/rhn/search.rhn-search.conf file. The following list defines the search configuration and their default values in parentheses.


Semi-colon separated list of classes to act as handlers for XMLRPC calls.


Maximum number of results returned for the query (500).


JDBC driver class to conduct database searches (oracle.jdbc.driver.OracleDriver).


Minimum score a result needs to be returned as query result (.10).


Minimum score a system search result needs to be returned as a query result (.01).


Minimum score a patch search result needs to be returned as a query result (.20).


Minimum score a patch advisory result needs to be returned as a query result (.30).


Minimum length of n-gram characters. Note that any change to this value requires clean-index to be run, and doc-indexes need to be modified and rebuilt (1).


Maximum length of n-gram characters (5). Note that any change to this value requires clean-index to be run, and doc-indexes need to be modified and rebuilt.


Type true to limit the number of results both on search.score_threshold and restrict max hits to be below search.max_hits_returned; type false to return all documentation search matches (false).


Input the time in milliseconds to control the interval with which the SearchServer polls the database for changes; the default is 5 minutes (300000).


Used during development and debugging. If set to true, this will log additional information showing what influences the score of each result (false).

8.10 Automating Synchronization

Manually synchronizing the SUSE Manager repository with Novell Customer Center can be a time-consuming task. United States business hours tend to be the peak usage time for Novell Customer Center so synchronization at that time may be slow. Therefore, SUSE encourages you to automate synchronization at other times to better balance load and ensure fast synchronization. Continental United States business hours are roughly 8:00 AM to 9:00 PM EST (UTC -5), due to four time zones, Monday through Friday. These hours may vary seasonally by one hour. Further, SUSE strongly recommends that synchronization occurs randomly for best performance.

Use a cron job for automatic synchronization by editing the crontab as root:

crontab -e

This opens the crontab in a text editor.

Use the first five fields (minute, hour, day, month, and weekday) to schedule the synchronization. Remember, hours use the 24-hour format (military time). Edit the crontab to include random synchronization:

# connect to customer center every day at random time
# between 03:03 and 05:50
3 3 * * * sleep $[ $RANDOM / 5 ]; /usr/sbin/mgr-ncc-sync >/dev/null \

This particular job will run randomly between 3:03 a.m. and 5:50 a.m. system time each night and redirect stdout and stderr from cron to prevent duplicating the more readable message from mgr-ncc-sync. Options other than --email can also be included. Once you exit the editor, the modified crontab is installed immediately.

Note: SUSE Customer Center with mgr-sync

If you already switched to SUSE Customer Center, use the mgr-sync command.

8.11 Implementing PAM Authentication

As security measures become increasingly complex, SUSE Manager supports network-based authentication systems via Pluggable Authentication Modules (PAM). PAM is a suite of libraries that allows to integrate SUSE Manager with a centralized authentication mechanism, thus eliminating the need to remember multiple passwords.

SUSE Manager supports LDAP, Kerberos, and other network-based authentication systems via PAM. To enable SUSE Manager to use PAM in your organization's authentication infrastructure, set up a PAM service file and make SUSE Manager use it. Follow the steps below.

  1. On a SUSE Linux Enterprise Server 11 SP3 system, a typical generic PAM service file could look as follows (save it as /etc/pam.d/susemanager to make it work with the settings below):

    auth        required
    auth        sufficient no_user_check
    auth        required
    account     required no_user_check
  2. Make SUSE Manager use this service file (/etc/pam.d/susemanager) by adding the following line to /etc/rhn/rhn.conf:

    pam_auth_service = susemanager
  3. To enable a user to authenticate against PAM, on the SUSE Manager Web interface go to the Create User page and select the checkbox labeled Pluggable Authentication Modules (PAM) positioned below the password and password confirmation fields.

  4. Then finally YaST can be used to configure PAM when packages such as yast2-ldap-client and yast2-kerberos-client are installed; for detailed information on configuring PAM, see the SUSE Linux Enterprise Server Security Guide. This example is not limited to Kerberos; it is a generic example and uses the current server configuration. Note that only network-based authentication services are supported.

Note: Changing Passwords

Changing the password on the SUSE Manager Web interface changes only the local password on the SUSE Manager server. But this password may not be used at all if PAM is enabled for that user. In the above example, for instance, the Kerberos password will not be changed.

For more information, see

8.12 Enabling Push to Clients

In addition to allowing client systems to regularly poll SUSE Manager for scheduled actions, users can enable SUSE Manager to immediately initiate those actions on provisioning-entitled systems. Thus you avoid the typical delay between scheduling an action and the client system retrieving the action from SUSE Manager. This support is provided by the OSA dispatcher (osad).

OSA dispatcher is a service that periodically queries SUSE Manager server for commands to execute on the client. If any actions exist, it sends a message via jabberd to the osad instances running on the clients.


It is mandatory to use SSL between SUSE Manager and the client systems for this feature to work. If the SSL certificates are not available, the daemon on the client system will fail to connect.

To use this feature, first configure your firewall rules to allow connections on the required ports as described in Section 3.3, “Additional Requirements”.

Then install the osa-dispatcher package, which can be found in the SUSE Manager software channel. Once installed, start the service as root using the command:

rcosa-dispatcher start

Finally, install the osad package on all client systems to receive pushed actions. The package can be found in the Tools child channel.


Do not install the osad package on the SUSE Manager server. The osad client package conflicts with the osa-dispatcher server package.

Once installed, start the service on the client systems as root using the command:

rcosad start

Like other services, rcosa-dispatcher and rcosad accept stop, restart, and status commands as well.

This feature depends on the client systems recognizing the fully qualified domain name (FQDN) of SUSE Manager. The client systems use this name and not the IP address of the server when configuring the YaST Online Update.

Now when you schedule actions from SUSE Manager on any of the push-enabled systems, the task will be carried out immediately rather than after a client checks in.

8.13 SSH Server Push

SSH Server Push is intended to be used in environments where clients cannot reach the SUSE Manager server to regularly check in and, for example, fetch package updates. Therefore the server will contact the clients in regular intervals (using SSH) to perform all actions via an encrypted channel.

This feature enables SUSE Manager within the internal network to manage clients in the DMZ. In such a scenario, for security reasons no system in the DMZ is allowed to open a connection into the internal network. Instead SSH Server Push with tunnel initiates the tunnel from the internal network. Once all actions are performed, the tunnel will be closed again.

8.13.1 Configuring SUSE Manager Server

For tunneling connections via ssh, two available high port numbers (> 1024) are needed, one for tunneling HTTP and another for tunneling HTTPS (while HTTP is only needed during the registration process). The port numbers used by default are 1232 and 1233. To overwrite these, add your values in /etc/rhn/rhn.conf like this:

ssh_push_port_http = high port 1
ssh_push_port_https = high port 2
Note: Specifying Ports for Tunneling before Registering Clients

The ports for tunneling need to be specified before the first client is registered. Clients already registered before changing the port numbers, must be registered again, otherwise the server will not be able to contact them anymore.

In case the clients should be contacted via their hostnames instead of their IP addresses, set the following option:

ssh_push_use_hostname = true

It is also possible to adjust the number of threads to use for opening client connections in parallel. By default two parallel threads are used. Set taskomatic.ssh_push_workers in /etc/rhn/rhn.conf like this:

taskomatic.ssh_push_workers = number

8.13.2 Client Registration

Registration of a client that is unable to reach the server needs to be done on the server. Therefore we are shipping a tool called mgr-ssh-push-init, which obsoletes mgr-push-register. The latter could only set up clients to be managed via an SSH tunnel. The deprecated mgr-push-register script now simply calls the new one and will be removed with one of the next releases.

The new script provides the option to initialize and register a client to be managed via SSH push with or without tunneling. This command expects a client's hostname (or IP address) as well as the path to a valid bootstrap script in the server's file system as parameters for registration:

mgr-ssh-push-init --client client --register bootstrap_script --tunnel

For registration of systems that should be managed via SSH push, an activation key can be configured to enable this contact method. Go to Systems › Activation Keys and click on a key or create a new one. Select your preferred Push method from the dropdown menu and click on Update Activation Key.

All systems registered with an activation key will be pre-configured to be contacted by the server using the method specified in the key. Currently, the following server contact methods are available:

Pull via XMLRPC:

The longtime default: the clients contact the server.

Push via SSH:

The server will contact the clients using SSH and run rhn_check there.

Push via SSH tunnel:

The server will contact the clients and run rhn_check via an encrypted SSH tunnel.

For already registered clients it is still possible to change the contact method in the system details Web interface: On the Systems page select the system, click Edit These Properties and set the value in the Contact Method combobox, then click Update Properties.

To enable managing a client using Push via SSH (without tunneling), the same script can be used as with tunneling. Registration is optional since it can also be done from within the client in this case:

mgr-ssh-push-init --client client [--register bootstrap_script]

Note that mgr-ssh-push-init will automatically generate the necessary SSH key pair if it does not yet exist on the SUSE Manager server. The correct host keys of clients are being stored in the known_hosts file.


When using the Push via SSH tunnel contact method, the client is configured to connect to SUSE Manager via high port[1|2]. Tools like rhn_check and zypper will need an active SSH session with the proper port forwarding options to access the SUSE Manager API. To verify the Push via SSH tunnel connection manually, you can run the following command on the SUSE Manager server:

ssh -i /root/.ssh/id_susemanager -R high port2:susemanager:443 client zypper ref

8.13.3 Proxy Support

Make sure that the latest maintenance updates with the registration tool are installed on the SUSE Manager Proxy system.

It is possible to use the SSH push contact methods to manage systems that are connected to the SUSE Manager server via a proxy. To register such a system, run mgr-ssh-push-init on the proxy server that is next to the respective client.

This will even work with a chain of cascading SUSE Manager proxies. The only known limitation is that the server needs to be able to directly connect to the last proxy in the chain.

8.14 Uploading and Maintaining Custom Packages

The mgrpush application allows you to serve custom packages associated with a private SUSE Manager channel through the SUSE Manager server. If you want the SUSE Manager server to serve only official SUSE Linux Enterprise or Red Hat Enterprise Linux packages, you do not need to install mgrpush.

All packages distributed through SUSE Manager should have a digital signature. A digital signature is created with a unique private key and can be verified with the corresponding public key. After creating a package, the SRPM (Source RPM) and the RPM can be digitally signed with a GnuPG key. Before the package is installed, the public key is used to verify the package was signed by a trusted party and the package has not changed since it was signed.

8.14.1 Generating a GnuPG Keypair

A GnuPG keypair consists of the private and public keys. To generate a keypair, proceed as follows:

  1. Type the following command as root on the shell prompt:

         gpg --gen-key
  2. The command will prompt for key type. Choose option (2) DSA and ElGamal. This allows you to create a digital signature and encrypt/decrypt with two types of technologies.

  3. Choose the key size. The longer the key, the more resistant against attacks the messages are. Creating a key of at least 2048 bits in size is recommended.

  4. Next, specify how long the key needs to be valid. When choosing an expiration date, remember that anyone using the public key must also be informed of the expiration and supplied with a new public key. We recommended to not select an expiration date. If you do not specify an expiration date, you are asked to confirm that the key should not expire.

  5. In the next steps, provide a User-ID containing your name, your email address, and an optional comment. When finished, you are presented with a summary of the information you entered. Accept your choices and enter a passphrase.


    A good passphrase is essential for optimal security in GnuPG. Mix your passphrase with uppercase and lowercase letters, use numbers or punctuation marks.

  6. Once you enter and verify your passphrase, the keys are generated. A message will ask you to move the mouse or otherwise interact with the system to generate random data for the key. This part of the key generation process may take several minutes. When the activity on the screen ceases, your new keys are placed in the directory .gnupg in root's home directory. This is the default location for keys generated by the root user.

    To list the root keys, use the gpg --list-keys command.

  7. To retrieve the public key, use the command gpg --list-keys command. The public key is written to the file public_key.txt. This key must be deployed to all client systems that receive custom packages from SUSE Manager. Techniques for deploying this key across an organization are covered in Chapter 4, Importing Custom GPG Keys, Client Configuration Guide

8.14.2 Signing Custom Packages

Before the rpm command can be used to sign packages, it needs to know the key to use. View the uid of your secret key:

   gpg --list-secret-keys | grep uid

Add the following lines to the ~/.rpmmacros

    %_signature gpg 
    %_gpg_path /etc/rpm/.gpg 
    %_gpg_name secret_key_uid 
    %_gpgbin /usr/bin/gpg 

Replace secret_key_uid with exactly the output from the gpg --list-secret-keys | grep uid command.


RPMs can be signed during or after build. Determine if a package has already been signed with the command: rpm --qip filename.rpm.

If the RPM is already signed, check whether the signature is correct. If the existing signature is not correct, resign the package:

    rpm --resign filename.rpm 

If the RPM is not signed, sign it:

    rpm --addsign filename.rpm 

Check the value of the "Signature" tag to ensure that the RPM has been signed correctly:

    rpm -qip filename.rpm 

8.14.3 Uploading Custom Packages

To use mgrpush, install the rhnpush package and its dependencies. This package is available to registered SUSE Manager Server systems and is installed by running zypper in rhnpush.

mgrpush uploads RPM header information to the SUSE Manager server database and places the RPM in the SUSE Manager server package repository.

When mgrpush is installed, a central configuration file is installed in /etc/sysconfig/rhn/rhnpushrc. This file contains default values for all the options, which are described in the mgrpush manual page (man mgrpush).

Additionally, mgrpush looks for settings in the current directory (./.rhnpushrc) take precedent over those in the user's home directory (~/.rhnpushrc), which are used before those in the central configuration file (/etc/sysconfig/rhn/rhnpushrc). These distinct configuration files are useful in varying settings depending on the directory from which the mgrpush command is issued.

For instance the current directory configuration file can be used to specify:

  • the software channel to be populated,

  • the home directory configuration file to include the username to be invoked,

  • the central configuration file to identify the server to receive the packages.

8.15 Configuring Audit Log Keeper

Audit Log Keeper buffers incoming messages and delivers them to several destinations. A destination can be any type of storage, database, or search index as long as they are supported by Audit Log Keeper.

8.15.1 Installing Audit Log Keeper

Install the package auditlog-keeper to get its core functionality. Audit Log Keeper supports several output plugins, which can be installed if you need further logging capabilities. See Table 8.1, “Available Optional Log Keeper Plug-ins”.

Table 8.1: Available Optional Log Keeper Plug-ins




Stores log events into a relational database.


Stores log events on a remote syslog server; supports TCP, UDP, and local connections.


Writes its log events into an XML file.

Apart from the core package and optional plug-ins, you need to install at least one schema validator. Schema validators are sanitation filters that reject inaccurate data from the client components and assures that the logging events are described in a standardized format. For SUSE Manager install the package auditlog-keeper-spacewalk-validator.

8.15.2 Configuring Audit Log Keeper

Audit Log Keeper is a solution which is independent from SUSE Manager. As such, it first needs to be enabled before it can collect log events. To enable Audit Log Keeper to write its log events to /var/log/messages, add the following line anywhere in /etc/rhn/rhn.conf:


Restart the SUSE Manager server by running the following command:

spacewalk-service restart

After the command is successfully executed, Audit Log Keeper is correctly enabled and executed. To also enable Audit Log Keeper on system startup, use the following command as user root:

chkconfig auditlog-keeper on

Apart from the above first steps, it is a good idea to change the default credentials. Proceed as follows:

Procedure 8.3: Changing Default Credentials
  1. Log in as root. Stop the Audit Log Keeper and SUSE Manager server:

    rcauditlog-keeper stop
    spacewalk-service stop
  2. Remove table files manually:

    rm /var/opt/auditlog-keeper/auditlog*
  3. Change the password in the config file for the backend.db.auth.user and backend.db.auth.password fields:

    auditlog-keeper --configure

    Save the new configuration by pressing :wq and hit Enter.

  4. Start the Audit Log Keeper and SUSE Manager server again:

    rcauditlog-keeper start
    spacewalk-service start

Find further information about Audit Log Keeper plugins and how to configure at An FAQ can be found at

8.16 Generating Spacewalk Reports

The spacewalk-report tool creates a report from the SUSE Manager server in a comma separated value (CSV) format.

8.16.1 Options for spacewalk-report

The spacewalk-report offers some options, which are briefly explained in Table 8.2, “Options for spacewalk-report.

Table 8.2: Options for spacewalk-report


Passes alternative database string (username/password@sid); default is taken from /etc/rhn/rhn.conf (default_db keyword).


Prints available reports.


Lists fields of the report.


Same as --list-fields.

8.16.2 Using spacewalk-report

To get an overview of available reports, use the --info option:

spacewalk-report --info
channel-packages: Packages in channels
channels: Channel report
entitlements: Entitlement and channel list and usage
errata-list: Errata out of compliance information - errata details
errata-list-all: List of all erratas
errata-systems: Errata out of compliance information - erratas for systems
inventory: Inventory report
users: Users in the system
users-systems: Systems administered by individual users

This gives you a list of all available report generators and their description. For example, to list all the available channels, use this command:

spacewalk-report channels
sles11-sp1-pool-i586,SLES11-SP1-Pool for i586,0
sles11-sp1-pool-x86_64,SLES11-SP1-Pool for x86_64,0

If you need to get a list of all users, pass the users option to the command:

spacewalk-report users
1,Penguin Inc.,1,admin,Penguin,Tux,,,Organization Administrator;SUSE Manager Administrator,2012-03-19 15:59:40,2012-03-21 13:43:45,enabled

8.17 Online Migration with YaST Wagon

An online migration is conveniently performed with YaST Wagon.

  1. Run /usr/sbin/wagon as root from the command line.

  2. Confirm the Welcome dialog with Next.

  3. If Wagon finds that the requirements are not met (required maintenance updates are available but not yet installed), it will do an automatic self-update, which may require a reboot. Follow the on-screen instructions.

  4. Choose the update method in the following dialog. Select Customer Center to use the default setup (recommended).

    Click Custom URL to manually choose the software channels used for the online migration. A list of channels will be displayed, providing the opportunity to manually enable, disable, add, or delete channels. Add the SUSE Manager update source(s). This can either be the SUSE Manager installation media or the SUSE-Manager-Server-2.1-Pool and SUSE-Manager-Server-2.1-Updates channels. Click OK to return to the Update Method dialog.

    If you want to review changes to the channel setup caused by the update process, select Check Automatic Repository Changes.

    Proceed with Next.

  5. The system will be re-registered. During this process the Pool and Updates channels will be added to the system. Confirm the addition of the channels.

  6. If you have selected Check Automatic Repository Changes in the Update Method dialog, the list of repositories will be displayed, providing the opportunity to manually enable, disable, add, or delete channels. Proceed with OK when finished.

  7. The Distribution Upgrade Settings screen opens and presents a summary of the update configuration. The following sections are available:

    Add-On Products

    Do not select any add-on products during migration.

    Update Options

    Lists the actions that will be performed during the update. You can choose whether to download all packages before installing them (default, recommended), or whether to download and install packages one by one.


    Statistical overview of the update.


    Set backup options.

    Click Next and Start The Update to proceed.

    Important: Aborting the Online Migration

    It is safe to abort the online migration on this screen prior to clicking Start The Update and on all previous screens. Click Abort to leave the update procedure and restore the system to the state it was in prior to starting YaST Wagon. Follow the instructions on screen and perform a re-registration before leaving Wagon to remove obsolete channels from your system.

  8. During the update procedure the following steps are executed:

    1. Packages will be updated.

    2. The system will be rebooted (press OK).

    3. The newly updated system will be re-registered.

  9. After the service pack migration has finished successfully, reboot the server. Then, to complete the SUSE Manager server upgrade run:

  10. Your system has been successfully updated to SUSE Manager 2.1.

Important: Upgrading the Database Schema

During first startup several errors will occur because of an invalid database schema. Run the script susemanager-upgrade, which prepares the database for the schema upgrade, performs the upgrade, and converts configuration variables from rhn.conf to the database.

8.18 Performing an Offline Migration

This section deals with offline migration. In this case, the machine reboots and performs the upgrade. The process is controlled by YaST and AutoYaST and not by zypper.

Only perform offline migration on client systems managed by SUSE Manager servers, not for server migration. This is a viable method for major version upgrades like from SUSE Linux Enterprise 10 to 11. Perform the following steps:

  1. Make sure your SUSE Manager and all the clients you want to migrate have installed all available updates, including the SUSE Manager tools. This is absolutely necessary, otherwise the migration will fail.

  2. Update the SP2 channels.

    SP2 is not an extra base-channel, but the SLES11 SP1 base-channel will be enhanced by two new child channels SLES11 SP2 core and SLES11 SP2 updates. Use the following steps to integrate them:

    1. Open a shell and list your channels:

      mgr-ncc-sync -l --all-childs

      The result will look similar to this:

      [P] sles11-sp1-pool-i586
          [.] sle11-hae-sp1-pool-i586
          [.] sle11-hae-sp1-updates-i586
          [.] sle11-hae-sp2-pool-i586
          [.] sle11-hae-sp2-updates-i586
          [.] sle11-sdk-sp1-pool-i586
          [.] sle11-sdk-sp1-updates-i586
          [X] sle11-sdk-sp2-core-i586
          [.] sle11-sdk-sp2-updates-i586
          [.] sle11-smt-updates-i586
          [.] sle11-sp1-debuginfo-pool-i586
          [.] sle11-sp1-debuginfo-updates-i586
          [.] sle11-webyast-sp1-pool-i586
          [.] sle11-webyast-sp1-updates-i586
          [.] sles11-extras-i586
          [P] sles11-sp1-suse-manager-tools-i586
          [P] sles11-sp1-updates-i586
          [.] sles11-sp2-core-i586
          [.] sles11-sp2-updates-i586
    2. Subscribe to the core and update channels with mgr-ncc-sync:

      mgr-ncc-sync -c sles11-sp2-core-i586
      mgr-ncc-sync -c sles11-sp2-updates-i586
    3. Check the status again with mgr-ncc-sync -l --all-childs. You should see a P this time.

      In your SUSE Manager Web interface, go to Channels › All Channels and click Show All Child Channels to see the parent/child relationship of your channels.

  3. Create an autoinstall distribution.

    For all distributions we want to perform an autoinstallation, we need to create a SLES11 SP2 distribution in SUSE Manager. Use the following steps to create one:

    1. Mount the SLES11 SP2 DVD

    2. In the SUSE Manager Web interface go to Systems › Autoinstallation › Distributions and click create new distribution.

    3. Enter a label for your distribution and the mount point.

    4. Select the SP1 base channel.

  4. Create an activation key for your SP2 systems.

    In order to switch from the old SLES10 base channel to the new SP2 base channel, we need an activation key. Use the following steps to create one:

    1. Go to Systems › Activation Keys and click create new key.

    2. Enter a description for your key.

    3. Enter a key or leave it blank to generate an automatic key.

    4. If you limit the usage, enter your value in the Usage text field.

    5. Select the SLES11 SP1 base channel.

    6. Decide the entitlements.

    7. Click Create Activation Key.

    8. Click Child Channels and select the required channels. Finish with Update key.

  5. Upload an AutoYaST profile.

    1. Create an AutoYaST XML file.

    2. Go to System › Profiles and click upload new kickstart/autoyast file.

    3. Paste the XML content in the text area or select the file to upload. Click Create.

    4. Add autoupgrade=1 in the Kernel parameters of the Details tab and click Update.

    5. Switch to the Variable tab.

    6. Enter in the text field registration_key= and the key name from Step 4.b.

    7. Click Update Variables.

After you have successfully finished the previous procedure, everything is prepared for an upgrade. If you want to upgrade a system, do the following:

  1. Go to Provisioning › Autoinstallation › Schedule, and choose the AutoYaST XML profile you have uploaded in Step 5.

  2. Click Schedule Autoinstallation.

  3. Click Finish at the bottom of that page.

Next time the machine asks the SUSE Manager server for jobs, it will receive a reinstallation job which fetches Kernel and initrd and writes a new /boot/grub/menu.lst (contains pointers to the new Kernel and initrd).

When the machine boots, it will use the GRUB configuration and boots the new Kernel with its initrd. No PXE boot is required for this process. A shutdown of the machine is initiated as well, effectively 3 minutes after the job was fetched.

9 For More Information

SUSE Manager

This guide gave you a short introduction to SUSE Manager. To discover more, refer to the other manuals available for SUSE Manager. Find them at Alternatively, access them from the SUSE Manager Web interface by selecting Help from the top navigation bar.

Novell Wiki

On the Novell Wiki you can read articles about this product and add tips and tricks yourself. Find them at

SUSE Manager Twitter Account

Stay in contact with our Twitter account and get the latest news at

Novell Customer Center

For detailed information about the NCC, refer to the NCC guide available at


For detailed information about KVM refer to the guide Virtualization with KVM, available at

A Documentation Updates

This section contains information about documentation content changes made to the Installation & Troubleshooting Guide.

This document was updated on the following dates:

A.1 xxx, 2015

Updates were made to the following section. The changes are explained below.


Update feedback section.

Section 3.1.2, “Supported Client Systems”

As supported client systems also list Novell Open Enterprise Server 11 SP2.

Section 3.3, “Additional Requirements”

For debugging, link to Section 7.6, “Log Files” (

Section 4.2, “Installation”

Add information SUSE Customer Center registration instead of NCC at the end of the initial SUSE Manager setup (

Section 4.3, “Setup”

Now use mgr-sync and SCC (

Section 4.6, “Server Migration”

Now use SCC (

Section 4.4, “Setup Without Internet Connection”

Add information about using SUSE Customer Center (

Section 4.5.2, “Setup of SUSE Channels and Products”

Now use spacewalk-remove-channel to remove SUSE channels (

Section 7.3, “Configuring Reliable SUSE Manager Setup”

New section (

Section 7.1.3, “Mail and Notification Issues”

New section (

Section 7.6, “Log Files”

Recommend 4096 for taskomatic.maxmemory (

Section 7.9, “Using a Proxy with Certificates to Access the Internet”

New section (

Section 7.12, “RPC Connection Timeout Settings”

Fix variable name for proxy timeout setting (

Section 8.10, “Automating Synchronization”

Recommend using mgr-sync with SUSE Customer Center.

A.2 July 31, 2015

Updates were made to the following section. The changes are explained below.

Section 3.1.2, “Supported Client Systems” xrefstyle="SectTitleOnPage"/>

As supported client systems also list SUSE Linux Enterprise 12 and Red Hat Enterprise Linux 7.

Warn about registering a SUSE Manager instance against itself (

Chapter 5, SUSE Manager on IBM System z xrefstyle="SectTitleOnPage"/>

New chapter.

A.3 February 12, 2015

Updates were made to the following section. The changes are explained below.

Section 8.2, “Updating SUSE Manager” xrefstyle="SectTitleOnPage"/>

Remove misleading database start command.

Section “Autoinstallation > Distributions — [Prov]”, Chapter 3, Systems, User Guide xrefstyle="SectTitleOnPage"/>

More detailed description where you will find information about the installation data (source) to be provided.

Section 3.3, “Additional Requirements” xrefstyle="SectTitleOnPage"/>

Also Virtual Environments require now 4 GB of RAM or more.

Section 4.5.2, “Setup of SUSE Channels and Products”

Add note about Expanded Support setup.

Section “Activation Keys — [Mgmt]”, Chapter 3, Systems, User Guide

Explicitly list the activation key separator.

Section 8.6, “Configuring SUSE Manager's Database (smdba)”

Remove list of control options here; they are also listed in Section “Configuring SUSE Manager's Database (smdba)”, Appendix A, Command Line Configuration Management Tools, Reference Guide.

Section 8.6.5, “Archive Log Settings”

Fix link to archive logs.

Section 8.11, “Implementing PAM Authentication”

Update PAM settings.

A.4 February 6, 2015

Updates were made to the following section. The changes are explained below.

A.5 December 5, 2014

Updates were made to the following section. The changes are explained below.

Section 6.4.2, “Configuring Slave Servers”

Note on slave servers and SCC.

Section 8.17, “Online Migration with YaST Wagon

Online applet does not exist on a SUSE Manager standard installation.

Add step to call

A.6 April 30, 2014

Section 8.14, “Uploading and Maintaining Custom Packages”

New sections on generating GPG keys and signing custom packages.

A.7 April 29, 2014

Information on installation and initial setup has been consolidated.

Installation & Troubleshooting Guide

Quick Start and Installation & Troubleshooting Guide merged into one guide. Quick Start is now obsolete.

A.8 November 22, 2013

Updates were made to the following sections. The changes are explained below.

A.8.1 Installation

Section 4.1, “Summary of Steps”

Add warning about SUSE Manager renaming.

A.8.2 Troubleshooting

Section 7.2, “General Problems”

Move this section to the beginning of the chapter.

Section 7.2, “General Problems”

Add PostgreSQL as an embedded database.

Section 7.7, “Naming Custom Channels”

New section.

Section 7.8, “Accessing Local Channels without Proxy”

Enhance server.satellite.no_proxy description.

Section 7.13, “Connection Errors”

Fix location of ssl.crt/server.crt.

Section 7.18, “Invoking Spacecmd”

New section.

A.8.3 Maintenance

Section 8.2, “Updating SUSE Manager”

Add PostgreSQL start command.

Section 8.6.3, “Backing up the Database”

Cleanup the PostgreSQL related procedure.

A.9 September 9, 2013

Updates were made to the following sections. The changes are explained below.

A.9.1 Importing and Synchronizing with Inter-Server Sync

A.10 August 23, 2013

Updates were made to the following sections. The changes are explained below.

A.10.1 Meta Information

A.10.2 Installation

Chapter 4, Installation

Move listing of new features and changes to Appendix F, Changes, Reference Guide.

A.10.3 Importing and Synchronizing

A.10.5 Maintenance

Section 8.6, “Configuring SUSE Manager's Database (smdba)”

Add an explaining note: Running smdba requires proper sudo enablement. root no longer is allowed to run smdba.

Section 8.6.3, “Backing up the Database”

Better distinguish between creating backups for PostgreSQL or oracle.

Section 8.6.5, “Archive Log Settings”

New section.

Section 8.7, “Cloning SUSE Manager with the Embedded Database”

Replace DB control with smdba and change procedure for clarification.

Section 8.10, “Automating Synchronization”

Fix and improve crontab entry. Specify full path to the command.

Section 8.13, “SSH Server Push”

New section.

Section 8.18, “Performing an Offline Migration”

mgr-ncc-sync requires --all-childs to list all channels.

A.11 January 25, 2013

Updates were made to the following sections. The changes are explained below.

A.11.1 Installation

Section 4.4, “Setup Without Internet Connection”

Refresh the data in the database (mgr-ncc-sync) before triggering the sync.

A.11.2 Troubleshooting

Section 7.17, “Multiple Mirror Credentials”

Clarify warning about removing channels.

A.12 November 28, 2012

Updates were made to the following sections. The changes are explained below.

A.12.2 Maintenance

Print this page