SUSE Manager 1.7

Installation & Troubleshooting Guide

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
http://creativecommons.org/licenses/by-sa/3.0/. 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.

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
http://www.novell.com/company/legal/trademarks/tmlist.html.
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.

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

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
http://www.suse.com/documentation/suse_manager/.

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
http://www.novell.com/documentation where you can download
PDF or HTML versions of the manuals for your product.

To report bugs for a product component, log into the Novell Customer Center from
http://www.suse.com/support/ 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
http://www.suse.com/documentation/feedback.html and
enter your comments there.

Mail

For feedback on the documentation of this product, you can
also send a mail to doc-team@suse.de. 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).

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.

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.

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

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.

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.

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.

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.

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.

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

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

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:

ALTER SESSION

CREATE SEQUENCE

CREATE SYNONYM

CREATE TABLE

CREATE VIEW

CREATE PROCEDURE

CREATE TRIGGER

CREATE TYPE

CREATE SESSION

UNLIMITED TABLESPACE

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

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

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

5222

Inbound

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

5269

Inbound/Outbound

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.

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

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.

Renaming SUSE Manager Server Not Supported

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

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.

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.

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:

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.

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.

-cCHANNEL_LABEL,
--channel=CHANNEL_LABEL

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

List all available channels and exit.

--list-steps

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

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

--no-rpms

Do not retrieve actual RPMs.

--no-packages

Do not export RPM metadata.

--no-errata

Do not process patch (errata) information.

--no-kickstarts

Do not process kickstart
data (provisioning only).

--debug-level=LEVEL_NUMBER

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

--start-date=START_DATE

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

--end-date=END_DATE

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

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.

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:

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

List all available channels and exit.

-cCHANNEL_LABEL,
--channel=CHANNEL_LABEL

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.

--no-ssl

Not Advisable - Turn off SSL.

--orgid=ORGID

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

--step=STEP

Perform the sync process only to the step
specified. Typically used in testing.

--no-rpms

Do not retrieve actual RPMs.

--no-packages

Do not process full package data.

--no-errata

Do not process patch (errata) information.

--no-kickstarts

Do not process Kickstart
data (provisioning only).

--force-all-errata

Forcibly process all patch metadata without conducting a diff.

--force-all-packages

Forcibly process all package metadata without conducting a diff.

--debug-level=LEVEL_NUMBER

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

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

--traceback-mail=TRACEBACK_MAIL

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

-s=,
--server=SERVER

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

--http-proxy=HTTP_PROXY

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

--http-proxy-username=PROXY_USERNAME

Include the username for the alternative HTTP proxy server.

--http-proxy-password=PROXY_PASSWORD

Include the password for the alternative HTTP proxy server.

--ca-cert=CA_CERT

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

--systemid=SYSTEM_ID

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

--batch-size=BATCH_SIZE

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.

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

Log into the machine as root.

Create a target directory for the files, such as:

mkdir /var/sw-import/

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 root@master.suma.example.com:/var/sw-export/* /var/sw-import

Now that the data is available, you can procede to performing 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:

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

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:

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

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.

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.

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

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

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

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.

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.

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.

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

Restart the SUSE Manager server with spacewalk-service restart.

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
master.suma.example.com with the hostname of the
master SUSE Manager server):

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:

mgr-inter-sync

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

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

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

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
http://www.suse.com/products/suse-manager/.

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.

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:

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

service oracle status

Or:

service postgresql status

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

rhn-schema-version

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

rhn-charsets

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
susemanager@example.com 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:

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:

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

Report

Invoked as

Description

Channel Packages

channel-packages

List of packages in a channel.

Channel Report

channels

Detailed report of a given channel.

Cloned Channel Report

cloned-channels

Detailed report of cloned channels.

Custom Info

custom-info

System custom information.

Entitlements

entitlements

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

Patches in Channels

errata-channels

Lists of patches in channels.

Patches Details

errata-list

Lists all patches that affect systems registered to SUSE Manager.

All patches

errata-list-all

Complete list of all patches.

Patches for Systems

errata-systems

Lists applicable patches and any registered systems that are
affected.

Host Guests

host-guests

List of host-guests mapping.

Inactive Systems

inactive-systems

List of inactive systems.

System Inventory

inventory

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

Kickstart Trees

kickstartable-trees

List of kickstartable trees.

All Upgradable Versions

packages-updates-all

List of all newer package versions that can be upgraded.

Newest Upgradable Version

packages-updates-newest

List of newest package versions only that can be upgraded.

Result of SCAP

scap-scan

Result of OpenSCAP sccdf eval.

Result of SCAP

scap-scan-results

Result of OpenSCAP sccdf eval, in a different format.

System Data

splice-export

System data needed for splice integration.

System Groups

system-groups

List of system groups.

Activation Keys for System Groups

system-groups-keys

List of activation keys for system groups.

Systems in System Groups

system-groups-systems

List of systems in system groups.

System Groups Users

system-groups-users

Report of system groups users.

Installed Packages

system-packages-installed

List of packages installed on systems.

Users in the System

users

Lists all users registered to SUSE Manager.

Systems administered

users-systems

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.

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.

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.

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, example.com would match
example.com, example.com:80,
and www.example.com, but not
www.notexample.com.
Additionally, it matches all subdomains;
example.com would also disable the proxy for
my.sub.example.com. This would be a valid
setting:

server.satellite.no_proxy = example.com, host.example.org

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

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.

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.

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:

Replace the value 192.0.2.34 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.

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:

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.

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:

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:

rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm

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.

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.

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.

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!

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.

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.

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:

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.

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.

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.

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:

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:

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.

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.

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:

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.

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:

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.

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.

Use the smdbabackup-restore
subcommand to import the database backup data.

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!

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:

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

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.

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

/etc/rhn/rhn.conf

/etc/tnsnames.ora

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.

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.

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.

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.

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.

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.

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

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.

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)

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:

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.

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.

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):

#%PAM-1.0
auth include common-auth
account include common-account
password include common-password
session include common-session

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

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.

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.

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.

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.

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.

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.

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

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:

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 clientbootstrap-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/id_susemanager.pub 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):

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.

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.

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

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.

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.

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:

audit.enabled=1

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:

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:

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.

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:

Paste the XML content in the text area or
select the file to upload. Click
Create.

Add autoupgrade=1 in the
Kernel parameters of the
Details tab and click
Update.

Switch to the Variable tab.

Enter in the text field
registration_key= and the key
name from Step 4.b.

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:

Go to Provisioning+Autoinstallation+Schedule, and choose the AutoYaST XML profile you have uploaded
in Step 5.

Click Schedule Autoinstallation.

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:

Fetches the Kernel and the initrd

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.