SUSE Manager 1.7

Installation & Troubleshooting Guide

Publication Date 21 Nov 2013

Copyright © 2013 Novell, Inc.

Copyright © 2011 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

Red Hat, as a licensor of this document, 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
1. Available Documentation
2. Feedback
3. 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. External Database Requirements
3.2. Additional Requirements
3.3. Additional Documentation
4. Installation
4.1. Summary of Steps
4.2. Setup Without Internet Connection
5. Importing and Synchronizing with Inter-Server Sync
5.1. Exporting with mgr-exporter
5.2. Importing with SUSE Manager Synchronization Tool mgr-inter-sync
5.3. Synchronizing
5.4. Inter-Server Sync
5.5. Using Inter-Server Sync
5.6. Synchronizing by Organization
6. Troubleshooting
6.1. General Problems
6.2. Gathering Information with spacewalk-report
6.3. Changing the CSV Separator
6.4. Log Files
6.5. Naming Custom Channels
6.6. Accessing Local Channels without Proxy
6.7. Discovering Hosts and Subnets in the Network
6.8. Host Not Found/Could Not Determine FQDN
6.9. RPC Connection Timeout Settings
6.10. Connection Errors
6.11. SUSE Manager Debugging
6.12. Resetting the SUSE Manager Password
6.13. Registering a Client Manually with suse_register
6.14. Multiple Mirror Credentials
6.15. Invoking Spacecmd
7. Maintenance
7.1. Managing SUSE Manager with spacewalk-service
7.2. Updating SUSE Manager
7.3. Backing Up SUSE Manager
7.4. Migrating Patches from Old to New Naming
7.5. Configuring SUSE Manager's Database (smdba)
7.6. Cloning SUSE Manager with the Embedded Database
7.7. Establishing Redundant SUSE Manager Servers with Stand-Alone Database
7.8. Conducting SUSE Manager-Specific Tasks
7.9. Automating Synchronization
7.10. Implementing PAM Authentication
7.11. Enabling Push to Clients
7.12. SSH Server Push
7.13. Uploading and Maintaining Custom Packages
7.14. Configuring Audit Log Keeper
7.15. Generating Spacewalk Reports
7.16. Performing an Offline Migration
A. Documentation Updates
A.1. November 22, 2013
A.2. September 9, 2013
A.3. August 23, 2013
A.4. January 25, 2013
A.5. November 28, 2012

List of Figures

1.1. Using SUSE Manager and SUSE Manager Proxy Server Together
2.1. Single SUSE Manager Topology
2.2. SUSE Manager Servers—Horizontally Tiered
2.3. SUSE Manager with SUSE Manager Proxies—Vertically Tiered
5.1. Staging SUSE Manager Server
5.2. Master Server and Slave Peers that include their own custom content
5.3. SUSE Manager Slaves are Maintained Exactly as the SUSE Manager Master
5.4. Syncing from NCC and a SUSE Manager Staging Server
7.1. User Deletion
7.2. User Delete Confirmation

List of Tables

3.1. Ports to Open on SUSE Manager
3.2. Ports to Open on the Client Systems
3.3. Ports to Open on the Proxy Servers
6.1. spacewalk-report Reports
6.2. Log Files
7.1. Available Optional Log Keeper Plug-ins
7.2. Options for spacewalk-report

List of Examples

7.1. Available Options on a Machine with a Oracle Database
7.2. Available Options on a Machine with a PostgreSQL Database

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 Network 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 section.

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:

Quick Start (↑Quick Start)

Guides you step by step through the installation, setup and basic configuration of SUSE Manager.

Proxy Quick Start (↑Proxy Quick Start)

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

Installation & Troubleshooting Guide

Lists installation scenarios and example topologies for different SUSE Manager setups. Also contains detailed information about SUSE Manager maintenance and troubleshooting.

Client Configuration Guide (↑Client Configuration Guide)

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

Reference Guide (↑Reference Guide)

Reference documentation that covers administration topics like registering and updating client systems, configuring the SUSE Manager daemon, using the Web interface, 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, log into the Novell Customer Center from and select My Support+Service Request.

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, Alt+F1: 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.

Chapter 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 may retrieve updates locally using the Red Hat Update Agent, or system administrators may schedule actions through the SUSE Manager Web site.

The SUSE Manager management tools are used to synchronize the SUSE Manager database and package repository with Novell Customer Center. 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 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 back to the client system. Depending upon 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 conjunction 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.

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

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.

Chapter 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.

Figure 2.1. Single SUSE Manager Topology

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 and SUSE Manager Proxy servers installed behind as shown in Figure 2.3, “SUSE Manager with SUSE Manager Proxies—Vertically Tiered”.

Figure 2.2. SUSE Manager Servers—Horizontally Tiered

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.

Similarly, you should make the Proxies' SSL certificates clients of SUSE Manager while also setting them to serve the client systems. This process is described in Section “Configuring Client Systems” (Chapter 3, SSL Infrastructure, ↑Client Configuration Guide).

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

SUSE Manager with SUSE Manager Proxies—Vertically Tiered

Chapter 3. Requirements

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

3.1. External Database Requirements

This section applies only to SUSE Manager if used in conjunction with a stand-alone database as the requirements for the embedded database are included in Section “System Requirements” (↑Quick Start). 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.

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











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.2. Additional Requirements

The following additional requirements must be met before the SUSE Manager installation:

[Important]Network Setup

For correct installation and setup of SUSE Manager, make sure the following requirements are fulfilled:

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.

Full Access

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

Firewall Rules

We strongly recommend firewalling the SUSE Manager against the Internet. However, various TCP ports must be opened on SUSE Manager, depending on your implementation of SUSE Manager:

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 re-installation 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.2, “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.



If you plan to push actions to client systems, required by osad running on the client systems



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.



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




80 and 443


To reach to 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 server.

Synchronized System Times

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

A 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.

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.

In addition to these requirements, it is recommended to configure SUSE Manager in the following manner:

  • 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. This feature instead uses channel content that can be downloaded to Subscription Management Tool (SMT) to synchronize SUSE Manager with Novell channels. For more information, see Section 4.2, “Setup Without Internet Connection”.

  • All unused ports should be protected by a firewall. Client systems connect to SUSE Manager over ports 80, 443, and 4545 (if monitoring is enabled). In addition, if you plan to enable the pushing of actions from SUSE Manager to client systems, as described in Section 7.11, “Enabling Push to Clients”, you must allow inbound connections on port 5222. If SUSE Manager will also push to a SUSE Manager proxy, you must allow inbound connections on port 5269.

  • No system components should be directly publicly available. No user other than the system administrators should have shell 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 wish to acknowledge via e-mail the alert notifications you receive, you must have installed and configured a mail transfer agent such as postfix to properly handle incoming mail. This can be done with YaST.

3.3. Additional Documentation

In addition to this Installation & Troubleshooting Guide, more documentation is available, as a reference or tailored to specific administration tasks. For an overview, refer to About This Guide.

Chapter 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 in conjunction 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 any updates from an internal update server (like SMT) instead.

Installation and basic configuration of SUSE Manager is covered in Quick Start (↑Quick Start). It is task-based and guides you through all required steps, from basic installation and setup through basic configuration.

For new features and changes, see Appendix E, Changes (↑Reference Guide).

4.1. Summary of Steps

The following overview lists the installation and setup scenarios covered in the Quick Start. The overview includes all required steps for basic installation, setup and configuration of SUSE Manager. Additionally, it covers a list of common administration tasks that you might need afterwards.

[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.1.1. Installation and Setup

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. Procedure “Installing the Appliance” (↑Quick Start)

  3. Procedure “Setting Up SUSE Manager” (↑Quick Start)

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.2, “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 “Server Migration” (↑Quick Start).

4.1.2. Basic Configuration

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

  1. Procedure “Creating the SUSE Manager Administrator Account” (↑Quick Start)

  2. Procedure “Importing SUSE Channels from NCC” (↑Quick Start)

  3. Procedure “Creating Activation Keys” (↑Quick Start)

  4. Procedure “Generating the Bootstrap Script” (↑Quick Start)

  5. Procedure “Editing the Bootstrap Script and Registering Clients” (↑Quick Start)

The following tasks are not part of the initial installation, setup, and configuration but they represent common tasks for basic administration and further configuration:

  • Section “Organization Management” (↑Quick Start)

  • Section “Management of System and Software Entitlements” (↑Quick Start)

  • Section “User Management” (↑Quick Start)

After SUSE Manager is populated with standard channels and packages and all clients are connected to it, you may begin creating and serving custom channels and packages. Once the custom RPMs are developed, you can import them into SUSE Manager using mgrpush. In the SUSE Manager Web interface, add custom channels in which to store them.

As can be seen from the overview above, implementing a fully functional SUSE Manager requires more than installing software and a database. Many tasks extending beyond the basic installation and setup are covered in detail in other guides. For a full list of available documentation for this product, refer to About This Guide.

4.2. 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 Novell Customer Center connection, 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 from it.

4.2.1. Basic Configuration and Usage

Procedure 4.1. SMT: Fetching Data from the Internet

  1. Install SMT in the external network with Novell Customer Center 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-ncc-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-ncc-sync --todir /media/disk/
    smt-mirror --dbreplfile /tmp/dbrepl.xml --directory /media/disk \
               --fromlocalsmt -L /var/log/smt/smt-mirror-export.log
  6. Unmount the storage medium to carry it to your SUSE Manager server.

Continue with the configuration on your SUSE Manager server.

Procedure 4.2. 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. mgr-ncc-sync can now be used as usual. Use the --from-dir parameter to point the sync to the mounted disk. First import the data about products, subscriptions, channels, and more without additional options or with the --refresh option. Then use -l to list the base channels and the child channels of the already synced base channels, and together with --all-childs to list all child channels, even if the parent channel is not synced yet. Use -c to add a new channel and trigger a repository sync:

    mgr-ncc-sync --from-dir /media/disk --refresh
    mgr-ncc-sync --from-dir /media/disk -l
    mgr-ncc-sync --from-dir /media/disk -c channel-name

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.3. 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.2.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 logfile will be populated with many a lot error messages.

Chapter 5. 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, for exporting mgr-exporter and for synchronization mgr-inter-sync and mgr-ncc-sync, come installed as part of the spacewalk-backend-tools package.

5.1. Exporting with mgr-exporter

The SUSE Manager exporter (mgr-exporter) exports SUSE Manager content in an XML format that can then be imported into another identical SUSE Manager. The content is exported into a directory specified by the user with the -d option. Once that directory has been transported to another SUSE Manager, the mgr-inter-sync tool may be used to import the contents, synchronizing two SUSE Managers.

5.1.1. mgr-exporter

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

The amount of time it takes mgr-exporter to export data depends on the number and size of the channels being exported. Using the --no-packages, --no-kickstarts, --no-errata, and --no-rpms options reduces the amount of time required for mgr-exporter to run, but also prevents potentially useful information from being exported. For that reason, these options should only be used when you are certain that you will not need the content that they exclude. 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 in order to autoinstall machines to the distribution in the base channel. 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. This is because the tools channels contain the tools that install packages for autoinstalling a machine through SUSE Manager.

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:

-d, --dir=

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.

5.1.2. Exporting

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

  • The SUSE Manager installation must have been performed successfully.

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

Although it is not a requirement for the export to succeed, the export will be most useful when performed on a SUSE Manager that has populated channels. Running the Export

First, be sure to configure SUSE Manager in the manner that you would either like to duplicate in another SUSE Manager or back up to a storage solution. Second, select the contents you would like to export. You can choose not to export RPMs, patches (errata), or Kickstarts by using the options mentioned in Section 5.1.1, “mgr-exporter”. Finally, execute the command as root. The following is an example command:

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

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

5.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.

5.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. For it to obtain patch (errata) information, it must first know the packages contained. For the packages to be updated, the tool must first identify the associated channels. For this reason, the SUSE Manager synchronization tool performs its actions in the following 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.

Each of these steps can be initiated individually for testing purposes with the effect of forcing the tool to stop when that step is complete. All steps that precede it, however, will have taken place. Therefore, calling the rpms step will automatically ensure the channels and channel-families steps take place first. To initiate an individual step, use the --step option, like so (for example, replace STEP with rpms):

mgr-inter-sync --step=STEP

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 this list of options and exit.

-d=, --db=DB

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

-m=, --mount-point=MOUNT_POINT

Import or sync from local media mounted to the SUSE Manager. To be used 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. If no channels are specified, all channels on the SUSE Manager server will be freshened.

-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 sync process only to the step specified. Typically used in testing.


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 conducting a diff.


Forcibly process all package metadata without conducting 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 sync 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.

If no options are included, mgr-ncc-sync synchronizes all channels that already exist in the SUSE Manager database. By default, the --step (all steps) option is enabled.

Keep in mind that the --channel option requires the channel label, not its name. For instance, use sles11-sp1-pool-x86_64 not SLES11-SP1-Pool for x86_64. Use the --list-channels option to obtain a list of all channels by label. All displayed channels are available for importing and synchronizing.

5.2.2. Preparing for Import from Local Media

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 must be available, or access to the master SUSE Manager must be available. Preparing SUSE Manager Exporter Data

In order to perform the import from data previously exported using SUSE Manager exporter, you must first copy that data onto the local system. Steps such as the following will enable you to procede to running the import as described in Section 5.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. It is perhaps easiest to copy the data into the new directory with a command such as the following:

    scp -r* /var/sw-import

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

5.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 in the previous step 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 may 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.

You may 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, like so:

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

5.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 an 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 pachtes (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.

5.4. Inter-Server Sync

SUSE Manager supports synchronization between two SUSE Managers. This synchronization, also called Inter-Server Sync, allows administrators to simplify the process of coordinating content from one SUSE Manager source to another or several others.

The following are the basic requirements for Inter-Server Sync.

  • At least two fully patched SUSE Manager 1.7 or greater servers from August 2013 or later (at least, spacewalk-backend package version is required)

  • At least one SUSE Manager populated with at least one channel

  • Master SUSE Manager SSL certificate available on each of the slave SUSE Manager servers for secure connection

5.4.1. Recommended Models for Inter-Server Sync

The Inter-Server Sync feature for SUSE Manager provides facilities for synchronizing content between two or more SUSE Managers. The following are some of the more typical uses that show the possibilities of Inter-Server Sync and help guide you in determining how to make the most of this feature in your environment.


If you are not sure if the Inter-Server Sync feature is right for your organization, you can continue to use SUSE Manager in the typical manner. Installing or upgrading to SUSE Manager 1.7 (August 2013) or greater does not require that you make use of this feature.

Figure 5.1. Staging SUSE Manager Server

Staging SUSE Manager Server

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

Figure 5.2. Master Server and Slave Peers that include their own custom content

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.

Figure 5.3. SUSE Manager Slaves are Maintained Exactly as the SUSE Manager Master

SUSE Manager Slaves are Maintained Exactly as the SUSE Manager Master

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

5.4.2. Configuring the SUSE Manager Master Server

To use the Inter-Server Sync feature, you must first ensure that you have it enabled. Make sure that the /etc/rhn/rhn.conf contains the following line:


In the same file is the variable:


By default, no SUSE Manager slave servers are specified to sync from the master server, so you must list the hostname of each SUSE Manager slave server, separated by commas. For example:,

Once you finished editing the rhn.conf file, restart the SUSE Manager server by issuing the following command:

spacewalk-service restart

Now refresh the NCC data with:

mgr-ncc-sync --refresh

5.4.3. Configuring the SUSE Manager Slave Servers

A SUSE Manager slave server connects to its master server only. A connection to NCC is not needed. Either install the slave server during the initial setup with YaST (where you can select Connect to SUSE Manager for inter-server sync) or reconfigure an existing SUSE Manager server. Installing with YaST During the Initial Setup

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 there.

The NCC Mirror Credential Username and Password must be the same as the first credential on the SUSE Manager master server. Use the Test button to test if the credentials are working. Reconfiguring a SUSE Manager server as a Slave Server

  1. Update already installed packages.

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

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

    mv /etc/ssl/certs/RHN-ORG-TRUSTED-SSL-CERT.pem \
    c_rehash /etc/ssl/certs/
  4. Download the SSL CA Certificate (replace FQDN.ISS.PARENT with the FQDN of your master server):

    curl -o /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT \
  5. Trust this certificate:

    ln -s /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT \
    c_rehash /etc/ssl/certs/

    For information about SSL configuration for use with SUSE Manager, see Chapter 3, SSL Infrastructure (↑Client Configuration Guide).

  6. Restart the SUSE Manager server with spacewalk-service restart.

  7. Initialize the SUSE Manager server with mgr-ncc-sync --refresh.

Once the SSL certificate is placed on the slave server, you can see the list of channels available to sync from the master SUSE Manager server by running the following command (replacing the with the hostname of the master SUSE Manager server):

mgr-inter-sync \
  --ca-cert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels

This command lists both NCC channels as well as any custom channels available on the master SUSE Manager server.

5.5. Using Inter-Server Sync

Now that Inter-Server Sync is configured, you can now use it to synchronize channels from the master SUSE Manager to the slave servers. On a SUSE Manager slave the functions of mgr-ncc-sync are limited; instead the tool to use to sync channels on a slave is mgr-inter-sync, which is a symlink to satellite-sync.

Then run the mgr-inter-sync command. List available channels:

mgr-inter-sync --list-channels

Sync a channel:

mgr-inter-sync -c YOUR-CHANNEL

Refresh all channels that are available on this server:


Any command line options to the mgr-inter-sync command will override any default or customized settings in the /etc/rhn/rhn.conf file.

5.5.1. Forward Registrations to NCC

The slave servers forward registrations to NCC 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 first SUSE Manager Server will send these requests to NCC and return the answer back the chain to the originally requesting 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 mirror credential.

5.5.2. Syncing between a Development Staging Server and a Production SUSE Manager Server

There may be instances where an administrator wants to sync data from a staging server that has custom channels that are ready for production use to a production SUSE Manager server.

For example, a production SUSE Manager server normally syncs directly from NCC for content updates, but will occasionally sync production-ready information from a SUSE Manager development server.

Figure 5.4. Syncing from NCC and a SUSE Manager Staging Server

Syncing from NCC and a SUSE Manager Staging Server

Normally, the administrator runs:

mgr-ncc-sync -c your-channel

This command downloads directly from data from NCC Then, to sync from the staging SUSE Manager server address, the administrator runs:

mgr-inter-sync \
  -c custom-channel

5.6. Synchronizing by Organization

mgr-inter-sync has an inter-server sync feature where a user can import content to any specific organization. This can be done locally or by a remote syncing from hosted or another SUSE Manager.

The aim is for mgr-inter-sync to be able to import content with respect to org_id. This targets two sets of users. One is the disconnected Multi-Org case, where the main source of content for the user is either to get content from channel dumps or to export them from connected SUSE Managers and import it to a SUSE Manager. The user mainly hosts custom channels from disconnected SUSE Managers. If they wish to export custom channels from connected SUSE Managers, they can do so by organizational sync.

The other case is a connected Multi-Org SUSE Manager customer. These new flags could work as a means of moving content between multiple orgs.

Synchronizing by organization has a few rules that it follows to maintain the integrity of the source org.

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

  • If an org is specified at the command line, it will import content from that org.

  • If no org is specified, it will default to org 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 \
  2. Import content from an exported dump of a specific org:

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

    mgr-inter-sync -c channel-name

Chapter 6. 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 6.11, “SUSE Manager Debugging” for instructions.

6.1. General Problems

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

A common issue is full disk space. For example, if you observe the appearance of halted writing in the log files, or logging suddenly stopped during writing, you likely have filled disks. Run the following command and 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 6.8, “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 the administrator is not receiving e-mails from SUSE Manager, confirm that the correct e-mail addresses have been set for traceback_mail in /etc/rhn/rhn.conf.

If the traceback e-mail is marked from and you would like the address to be valid for your organization, set the web.default_mail_from variable in /etc/rhn/rhn.conf to the desired e-mail address.

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 5.2.2, “Preparing for Import from Local Media” 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

6.2. 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 lists 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 6.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 newest package versions only 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 --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.

6.3. 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.

6.4. 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 6.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 6.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


6.5. Naming Custom Channels

To avoid conflicts, do not use names for custom channels that a vendor such as SUSE or Red Hat use or may use officially.

6.6. 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.

6.7. 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.

6.7.1. Installation and Configuartion

Procedure 6.1. Installation and Configuartion 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. It must just 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.

6.7.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 switch to display an online help.

[Note]Scanning the Network

Scanning your network may take some time. So after starting the daemon, wait some minutes until 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

6.8. 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.

To resolve this problem, check the /etc/hosts file. It looks like this: this_machine localhost.localdomain \

In a text editor, remove the offending machine information so that the line in /etc/hosts looks like this: localhost

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

Replace the value with the actual IP address of the SUSE Manager server. Keep in mind, if the specific IP address is stipulated, the file will need to be updated when the machine obtains a new address.

6.9. 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.

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

Server — /etc/rhn/rhn.conf:
server.timeout = number
Proxy Server — /etc/rhn/rhn.conf:
server.proxy = 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. Limiting operations to less than a few minutes risk aborting perfectly normal operations.

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

6.10. 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. During the installation process SSL certificates are created with inaccurate times. 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.

6.11. SUSE Manager Debugging

If you have followed the steps above but still need more help, contact the SUSE support providing 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

6.12. 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 Ctrl+C.

6.13. 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 by our support.

Find other options and their explanations with --help.

6.14. Multiple Mirror Credentials

The Spacewalk backend (spacewalk-backend) and the SUSE Manager Tools (susemanager-tools) can handle multiple mirror credentials.

Procedure 6.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 ones 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

6.15. Invoking Spacecmd

Spacecmd does not seem to accept commands or options, but just 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

Chapter 7. 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.

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

7.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 7.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 “Installation and Setup” (↑Quick Start). SUSE Manager systems not connected to the Internet (disconnected setup) will receive updates from an internal update server instead.

Procedure 7.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


      /etc/init.d/oracle-xe 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.

7.3. 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 7.5, “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 “Installation and Setup” (↑Quick Start)). 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 re-installing 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

7.4. 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 more simpler notation:


After the migration has been successfully performed, the patches are listed twice after the first channel syncronization. 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

7.5. 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 and Oracle 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 your the database, it can happen that the Spacewalk services lost their connections. In such a case, run the following command:

spacewalk-service restart

7.5.1. Control Options

Depending on the database installed, smdba provides several subcommands:

Example 7.1. Available Options on a Machine with a Oracle Database

backup-list       List of available backups
backup-restore    Restore the SUSE Manager Database from backup
db-start          Start SUSE Manager database
db-status         Get SUSE Database running status
db-stop           Stop SUSE Manager database
listener-restart  Restart SUSE Database Listener
listener-start    Start the SUSE Manager Database listener
listener-status   Show database status
listener-stop     Stop the SUSE Manager Database listener
space-overview    Show database space report
space-reclaim     Free disk space from unused object in tables
                  and indexes
space-tables      Show space report for each table
stats-overview    Show tables with stale or empty statistics
stats-refresh     Gather statistics on SUSE Manager Database
                  database objects
system-check      Common backend healthcheck

Example 7.2. Available Options on a Machine with a PostgreSQL Database

backup-hot      Enable continuous archiving backup
backup-restore  Restore the SUSE Manager Database from backup.
backup-status   Show backup status.
db-start        Start the SUSE Manager Database.
db-status       Show database status.
db-stop         Stop the SUSE Manager Database.
space-overview  Show database space report.
space-reclaim   Free disk space from unused object in tables and indexes.
space-tables    Show space report for each table.
system-check    Common backend healthcheck.

[Note]smdba help Output Depends on the Database Used

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

7.5.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

7.5.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.

7.5.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.

7.5.5. Archive Log Settings

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

With archive log enabled, a lot more of 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/log/pgsql/data/pg_xlog/ (PostgreSQL)

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

7.5.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

7.6. 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 7.5, “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 appropriately.


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!

7.7. 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 the Sharing Certificates section of the Client Configuration Guide for precise instructions. 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.

7.8. Conducting SUSE Manager-Specific Tasks

7.8.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, select the name of the user to be removed and click the delete user link at the top-right corner of the User Details page.

Figure 7.1. User Deletion

User Deletion

Click Delete User at the bottom-right corner of the page to permanently remove the user.


The organization administrator role must be removed from the user's profile before deleting the user from SUSE Manager or the delete operation fails.

The organization administrator role can be removed by any organization administrator (provided they are not the sole organization administrator for the organization) by clicking on the Users tab and then visiting the Details subtab.

Figure 7.2. User Delete Confirmation

User Delete Confirmation

7.8.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.

  • search.index_work_dir : specifies where Lucene indexes are kept (/usr/share/rhn/search/indexes).

  • search.rpc_handlers : semi-colon separated list of classes to act as handlers for XMLRPC calls.

  • search.max_hits_returned : maximum number of results returned for the query (500).

  • search.connection.driver_class : JDBC driver class to conduct database searches (oracle.jdbc.driver.OracleDriver).

  • search.score_threshold : minimum score a result needs to be returned as query result (.10).

  • search.system_score_threshold : minimum score a system search result needs to be returned as a query result (.01).

  • search.errata_score_threshold : minimum score a patch search result needs to be returned as a query result (.20).

  • search.errata.advisory_score_threshold : minimum score a patch advisory result needs to be returned as a query result (.30).

  • search.min_ngram : 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)

  • search.max_ngram : 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.

  • search.doc.limit_results : 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).

  • search.schedule.interval : input the time in milliseconds to control the interval with which the SearchServer polls the database for changes; the default is 5 minutes (300000).

  • search.log.explain.results : used during development and debugging. If set to true, this will log additional information showing what influences the score of each result. (false)

7.9. 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 occur 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 easily read message from mgr-ncc-sync. Options other than --email can also be included. Once you exit the editor, the modified crontab is installed immediately.

7.10. 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 SP1 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     include        common-auth
    account  include        common-account
    password include        common-password
    session  include        common-session
  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 Website 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 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

7.11. Enabling Push to Clients

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

OSA dispatcher is a service that periodically queries SUSE Manager server for commands to be executed on the client. If there are commands, it sends a message via jabberd to the osad instances running on the clients.


SSL must be employed 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 take advantage of this feature, configure your firewall rules to allow connections on the required ports, as described in Section 3.2, “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, as it will conflict with the osa-dispatcher 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 system recognizing the fully qualified domain name (FQDN) of SUSE Manager. This name and not the IP address of the server must be used 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.

7.12. 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 itself will contact the clients in regular intervals (using SSH) to perform all actions via an encrypted channel.

This feature enables SUSE Manager from within the internal network to manage clients in the DMZ. In such a scenario, for security reasons no systems 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, and then all connections the SUSE Manager server will be routed through the tunnel. Once all actions are performed, the tunnel will be closed again.

7.12.1. Configuring SUSE Manager Server

For tunneling connections via ssh, two available high port numbers (> 1024) are needed, one is for tunneling HTTP and one for HTTPS (while HTTP is only needed during the registration process). Port numbers used by default are 1232 and 1233. In order 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 registered before changing the port numbers, must be registered again, otherwise the server will not be able to contact them anymore.

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

7.12.2. Client Registration

Clients not able to reach the server need to be registered from within the server. mgr-push-register will accomplish this task. mgr-push-register expects the client's hostname (or IP address) as well as the path to a valid bootstrap script in the server's filesystem as parameters:

mgr-push-register client bootstrap-script

For registration of systems that should be managed via the SSH Server Push method, it is now possible to use an activation key that is configured with this contact method. In the SUSE Manager Web interface, find the dialog for creating and modifying activation keys this way: Systems+Activation Keys, then select a key or create new one, then modify the Contact Method combobox, and finally click 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.

The registraton tool will once ask for the client's root password, which is necessary for pushing the SSH public key to the client initially. Once the key is installed onto the client machine, the SUSE Manager server can log in to the client using key authentication for establishing the SSH tunnel needed for server-initiated communications. 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, and finally click Update Properties.

In order to enable a client to be managed using Push via SSH (without tunneling), it is currently required to manually install the SUSE Manager public key onto the system. This can be done by calling:

ssh-copy-id -i ~/.ssh/ root@client

In case the key pair does not yet exist on the SUSE Manager server, you can create it by either registering a system with mgr-push-register or manually like this (creating and pushing the key to clients only will be supported from within mgr-push-register in the future):

ssh-keygen -q -N '' -C 'susemanager' -f ~/.ssh/id_susemanager

7.12.3. Proxy Support

Make sure that the latest beta packages 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-push-register from within the proxy system.

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.

7.13. 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.

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 values for all the options.

These distinct configuration files are useful in varying your settings depending on the directory from which the mgrpush command is issued. 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).

For instance, you can use the current directory configuration file to specify the software channel to be populated, the home directory configuration file to include the username to be invoked, and the central configuration file to identify the server to receive the packages.

The mgrpush command line options are also described in the mgrpush manual page (man mgrpush).

7.14. 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.

7.14.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 7.1, “Available Optional Log Keeper Plug-ins”.

Table 7.1. Available Optional Log Keeper Plug-ins




Store 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 a 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 rejects 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.

7.14.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 enable also 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 7.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 :+w+q 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

7.15. Generating Spacewalk Reports

The spacewalk-report tool creates a report from the SUSE Manager server in a comma separated value (CSV) format.

7.15.1. Options for spacewalk-report

The spacewalk-report offers some options which are briefly explained in Table 7.2, “Options for spacewalk-report.

Table 7.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

7.15.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

7.16. 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.

To perform an offline migration, do the following:

  1. Make sure your SUSE Manager and all the client you want to migrate has installed all available updates, including the SUSE Manager tools. This is absolutly 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 textfield.

    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 does the following:

  1. Fetches the Kernel and the initrd

  2. 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.

Appendix 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. November 22, 2013

Updates were made to the following sections. The changes are explained below.

A.1.1. Installation

Section 4.1, “Summary of Steps”

Add warning about SUSE Manager renaming.

A.1.2. Troubleshooting

Section 6.1, “General Problems”

Move this section to the beginning of the chapter.

Section 6.1, “General Problems”

Add PostgreSQL as an embedded database.

Section 6.5, “Naming Custom Channels”

New section.

Section 6.6, “Accessing Local Channels without Proxy”

Enhance server.satellite.no_proxy description.

Section 6.10, “Connection Errors”

Fix location of ssl.crt/server.crt.

Section 6.15, “Invoking Spacecmd”

New section.

A.1.3. Maintenance

Section 7.2, “Updating SUSE Manager”

Add PostgreSQL start command.

Section 7.5.3, “Backing up the Database”

Cleanup the PostgreSQL related procedure.

A.2. September 9, 2013

Updates were made to the following sections. The changes are explained below.

A.2.1. Importing and Synchronizing with Inter-Server Sync

A.3. August 23, 2013

Updates were made to the following sections. The changes are explained below.

A.3.1. Meta Information

A.3.2. Installation

Chapter 4, Installation

Move listing of new features and changes to Appendix E, Changes (↑Reference Guide).

A.3.3. Importing and Synchronizing

A.3.5. Maintenance

Section 7.5, “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 7.5.3, “Backing up the Database”

Better distinguish between creating backups for PostgreSQL or oracle.

Section 7.5.5, “Archive Log Settings”

New section.

Section 7.6, “Cloning SUSE Manager with the Embedded Database”

Replace DB control with smdba and change procedure for clarification.

Section 7.9, “Automating Synchronization”

Fix and improve crontab entry. Specify full path to the command.

Section 7.12, “SSH Server Push”

New section.

Section 7.16, “Performing an Offline Migration”

mgr-ncc-sync requires --all-childs to list all channels.

A.4. January 25, 2013

Updates were made to the following sections. The changes are explained below.

A.4.1. Installation

Section 4.2, “Setup Without Internet Connection”

Refresh the data in the database (mgr-ncc-sync) before triggering the sync.

A.4.2. Troubleshooting

Section 6.14, “Multiple Mirror Credentials”

Clarify warning about removing channels.

A.5. November 28, 2012

Updates were made to the following sections. The changes are explained below.

A.5.2. Maintenance

SUSE Manager Installation & Troubleshooting Guide 1.7