Download Report

Linux Deployment Guide
How to Use the Subscription
Management Tool for
SUSE Linux Enterprise 11
®
Manage Updates and Compliance
www.novell.com
Contents
Contents...........................................................................................................................................................................2
Overview of the Subscription Management Tool for SUSE Linux Enterprise 11 .............................................................4
Installation and Basic Configuration.................................................................................................................................6
Managing the Subscription Management Tool...............................................................................................................10
Configuring Clients to Use the Subscription Management Tool.....................................................................................13
Jobs and Client Status Monitoring..................................................................................................................................15
Staging............................................................................................................................................................................19
Compliance Monitoring with Subscription Management Tool Reports...........................................................................21
Supportconfig Proxy.......................................................................................................................................................22
Mirroring Updates for Red Hat Enterprise Linux.............................................................................................................23
Mirroring SUSE Linux Enterprise 9 Updates..................................................................................................................23
Custom Repositories......................................................................................................................................................24
Disconnected Subscription Management Tool Servers..................................................................................................27
Registration Data Synchronization with Novell Customer Center...................................................................................29
Publish Update Repositories on the Internet for Mobile Workstations...........................................................................30
Preloading Repositories..................................................................................................................................................31
Server Tuning.................................................................................................................................................................32
Backup of Subscription Management Tool Servers........................................................................................................32
Conclusion......................................................................................................................................................................32
References.....................................................................................................................................................................33
2
What Can the Subscription Management Tool for
SUSE Linux Enterprise Do For You?
The Subscription Management Tool for SUSE® Linux Enterprise allows enterprise customers to optimize the
management of SUSE Linux Enterprise software updates and subscription entitlements. It establishes a proxy system
for Novell Customer Center with repository and registration targets. This helps you centrally manage software
®
updates within the firewall on a per-system basis, while maintaining your corporate security policies and regulatory
compliance
The tool allows you to provision updates for all of your devices running a product based on SUSE Linux Enterprise. By
downloading these updates only once and distributing them throughout the enterprise, you can set more restrictive
firewall policies and, where applicable, avoid significant network usage stemming from repeated downloads of the
same updates by each device. The tool is fully supported and available as a download to customers with an active
SUSE Linux Enterprise product subscription.
The Subscription Management Tool for SUSE Linux Enterprise 11 is a good choice for you if you:
•
would like to have one tool that updates both SUSE Linux Enterprise and Novell Open Enterprise Server, as
well as your Red Hat Enterprise Linux servers
•
want to be on top of your company's license compliance
•
don't want to connect all your machines to Novell Customer Center to register and retrieve updates for
bandwidth and/or security reasons
•
have SUSE Linux Enterprise hosts that are restricted and difficult to update without having to invent your own
update management solutions
•
want to integrate additional software update repositories (either external or internal) into your update solution
•
would like an out-of-the box staging solution for testing updates before releasing them to the masses
•
want to be able to get a quick overview of the patch status of your SUSE Linux Enterprise 11 servers and
desktops
This document targets medium experienced SUSE Linux Enterprise administrators and describes how to use the
Subscription Management Tool for SUSE Linux Enterprise 11 from Novell. We strongly advise reading each chapter
at least once before performing the actions described within. The author will not accept any responsibility for any
incorrect information within this document, nor for any damage that information might cause when applied. Do not
forget, most how-to documents are the result of volunteers who devote time and resources to their creation.
3
Overview of the Subscription Management Tool for SUSE Linux Enterprise
11
With the release of the SUSE Linux Enterprise 10 platform back in 2006, Novell introduced a new mechanism for
keeping systems up to date. By registering each individual host with Novell Customer Center during or after
installation, the machines regularly query the nu.novell.com update services and catalogs to see if new updates have
been released.
Not only does this process potentially consume considerable Internet bandwidth, it can also make it difficult to enforce
security policies at the firewall level. Another challenge is that in an increasing number of customer installations, there
are SUSE Linux Enterprise hosts, which are restricted from Internet access.
In addition, new patches are often required to undergo testing within a limited group of machines before they are
made available to the general public.
The Subscription Management Tool addresses all of the above issues. Furthermore, the reporting feature provides
means for license tracking across large deployments as well as effective measurement of subscription utilization. This
makes it easier to determine how many entitlements need to be renewed at the end of a billing cycle.
Figure 1: Subscription Management Tool Overview
The Subscription Management Tool supports products based on SUSE Linux Enterprise 10 SP2 (and later). For a sixmonth period after these products are released, the tool also supports their previous support pack version. In addition
to this, the Subscription Management Tool supports products based on SUSE Linux Enterprise 9.
At the time of writing, the Subscription Management Tool is able to mirror updates for the following products:
SUSE Linux Enterprise 11:
•
SUSE Linux Enterprise Server 11
•
SUSE Linux Enterprise Desktop 11
•
SUSE Linux Enterprise 11 Software Development Kit
4
SUSE Linux Enterprise 10:
•
SUSE Linux Enterprise Server 10 SP2 and SP3
•
SUSE Linux Enterprise Desktop 10 SP2 and SP3
•
SUSE Linux Enterprise 10 SP2 Software Development Kit
•
Novell Open Enterprise Server 2 Support Pack 1
SUSE Linux Enterprise 9:
•
SUSE Linux Enterprise Server 9
•
Novell Linux Desktop 9
•
SUSE Linux Enterprise 9 Software Development Kit
•
Novell Linux Point of Service
Furthermore, you can configure mirroring of:
•
Installation sources for SUSE Linux Enterprise 10 and 11 products
•
Custom external repositories like third-party hardware driver updates
•
Self-created update repositories
Depending on the workload, a single server scales up to handling 1,000+ clients, although it may require some minor
tuning efforts (discussed in a later section).
The product is mostly written in Perl and plain shell scripts, creates a MySQL database and publishes its repositories
via Apache. It communicates with Novell Customer Center in https, while the clients are served via https (registration
process) and http (update retrieval).
Figure 2: Components of the Subscription Management Tool for SUSE Linux Enterprise 11
5
Installation and Basic Configuration
The Subscription Management Tool must be installed on SUSE Linux Enterprise Server 11 (an active SUSE Linux
Enterprise maintenance subscription is required). It is available for the i586, x86_64 and s390x architectures. In
addition to the normal system requirements for SUSE Linux Enterprise Server 11, the server must have a valid DNS
host name, such as smt.mycompany.com. This name must be resolvable to the clients for the certificates involved to
work. Finally, as a rough estimate, it is recommended that you have 10 GB of available storage space per product to
be mirrored (more if the sources are also to be mirrored).
The Subscription Management Tool is provided as an add-on product to SUSE Linux Enterprise Server 11. While it
can also be installed during the initial SUSE Linux Enterprise Server installation phase (see section 1.1 in the
Subscription Management Tool guide) this article discusses installing it on top of an already installed system. The
installation ISO image can be downloaded from http://download.novell.com/
Before starting the installation, you should have the mirroring credentials available. How to find them is described in
section 3.1 of the Subscription Management Tool guide, available at http://www.novell.com/documentation/smt11/.
The installation is described in section 1.2 and 1.3 of the Subscription Management Tool guide and flows as follows:
•
Start it by invoking the Add-on module in the Software group in the YaST Control Center (yast2 add-on).
•
Select the Subscription Management Tool medium you have downloaded as the installation source and start
the installation.
•
Accept the license agreement in the dialog and click Next.
•
The software management dialog appears. At first glance it looks like nothing is being installed. But if you
scroll down in the Patterns window, the Subscription Management Tool and the five packages that constitute
the Subscription Management Tool will be marked for installation.
Figure 3: YaST Software Management Dialog
•
When you select Accept, YaST may install additional required packages to meet the prerequisites of the
Subscription Management Tool.
•
When the package installation is completed, the Subscription Management Tool configuration wizard (section
1.3 of the Subscription Management Tool guide) is launched.
6
Figure 4: Subscription Management Tool Configuration Wizard-1/2
•
In the first step, fill in the NU user and NU password with your mirror credentials.
•
Click the Test button to verify that the credentials entered are valid. It should result in a success message.
•
Enter the e-mail address that is registered in the Novell Customer Center and linked to the mirror credentials.
•
Verify that your SMT server URL points to the server (http://server-fq-dns-name)
•
Click Next.
Figure 5: Subscription Management Tool Configuration Wizard-2/2
7
•
The second step of the wizard prompts you to enter the desired password of the smt user that gets created in
the MySQL database configuration
•
Here you can also add e-mail addresses that the Subscription Management Tool reports should be sent to.
•
Select Next.
•
If the system has not yet been registered in Novell Customer Center, the following dialog appears.
Figure 6: Novell Customer Center Credentials Dialog
•
The reason for this new dialog is that the installation of SUSE Linux Enterprise 11 does not automatically
generate the machine-specific GUID and password that the previous versions did. This information is now
stored in /etc/zypp/credentials.d/NCCcredentials, which corresponds to /etc/zmd/deviceid and
/etc/zmd/secret on SUSE Linux Enterprise 10, created by the ZENworks® Management Daemon. In SUSE
Linux Enterprise 11 the ZENworks Management Daemon has been replaced by zypper, which has no need
for these credentials.
•
For normal Subscription Management Tool servers with access to the Internet, select the default option to
register in Novell Customer Center.
•
The option to generate Novell Customer Center credentials is useful when configuring isolated Subscription
Management Tool servers that are not able to contact Novell Customer Center.
•
The use case for the option to skip registration is currently unknown to the author.
•
Click Next.
8
Figure 7: Writing Subscription Management Tool Configuration
After the Novell Customer Center registration (if applicable) the initial configuration reaches its final stage.
•
You will be prompted to enter the MySQL root user password to set up the Subscription Management Tool
database.
•
If the file /srv/www/htdocs/robots.txt is detected a warning appears. This file (usually installed with apache2example-pages) prevents the clients from accessing the repository key files of the Subscription Management
Tool. Handling this is described in section 8.3.1 of the Subscription Management Tool guide.
•
Now the configuration is written and an initial synchronization of products and entitlements from Novell
Customer Center is performed in the background.
This may take a few minutes.
The last step is to perform an update of the Subscription Management Tool packages. A few of the features described
in this document require these versions (or newer) to work correctly:
•
yast2-smt-2.17.22
•
smt-client-0.0.13
To install the updates follow these steps:
1.
Open a terminal window.
2.
As the root user, verify that you have an enabled Subscription Management Tool repository:
# zypper lr
A line like this should appear in the output (the initial repository number varies):
7 | nu_novell_com:SLE11-SMT-Updates /--/ | SLE11-SMT-Updates | Yes | Yes
3.
It is recommended to install all available updates with the command:
# zypper up -y
If you only want to install the updates from the SLE11-SMT-Updates repository, use this command instead:
# zypper up -y -r nu_novell_com:SLE11-SMT-Updates
9
4.
Reload the Subscription Management Tool service with the command:
# rcsmt restart
Now your Subscription Management Tool server is configured and ready to use.
Managing the Subscription Management Tool
A new benefit of the Subscription Management Tool for SUSE Linux Enterprise 11 is that a lot of the day-to-day
management can be done via the Subscription Management Tool Server Management YaST module (yast2 smt). The
Subscription Management Tool Server Configuration module (yast2 smt-server) is used for global configuration of
things like Subscription Management Tool report recipients and cron job scheduling.
The Subscription Management Tool Server Management module contains three tabs —Repositories, Staging and
Client Status—as shown below:
Figure 8: Subscription Management Tool Server Management, Repositories Tab
On the Repositories tab you can toggle the mirroring and staging status of the individual repositories, which are
available for mirroring to the server. It is also possible to mirror just one selected repository by clicking Mirror Now.
This new feature is particularly useful if many repositories are already enabled for mirroring and you have just enabled
a new one and only want to mirror that one. The remaining two tabs will be discussed in later sections.
In addition to the YaST modules, the main command line interface is /usr/sbin/smt, which takes subcommands and
parameters for these. /usr/sbin/smt calls smt-subcommand executables in /usr/sbin/ which in turn then call tools in
/usr/lib/perl5/vendor_perl/5.10.0/SMT/.
If the smt command is used alone, it prints out a list of all available subcommands. There are man pages for all smt-*
commands and invoking
•
# smt help subcommand
or
10
•
# smt -h subcommand
•
# smt-subcommand -h
or
also shows the syntax and options for the specific command.
For daily work, one may find it handy to use smt-subcommand instead of smt subcommand since it enables tab
completion. The smt subcommands are:
repos
List available repositories, enable/disable them for mirroring and staging
client
Shows information about registered clients
delete-registrations
Delete one or more registrations
job
Manage client jobs
list-products
List all products in Subscription Management Tool database
list-registrations
List all hosts registered with this Subscription Management Tool server
mirror
Perform the actual mirroring of products based on SUSE Linux Enterprise 10 and
11
mirror-sle9
Mirroring of products based on SUSE Linux Enterprise 9
ncc-sync
Download products, targets, repositories, subscriptions and registration
information from Novell Customer Center to the Subscription Management Tool
database
register
Register all currently unregistered and updated clients with Novell Customer
Center
report
Generate extensive reports of the smt data
setup-custom-repos
Enable and disable non-NU catalogs to be mirrored
staging
Manage patch filters and testing/production repositories
support
Support config archive management
In addition to these "catalogs", a symlink to "repos" and "setup-custom-catalogs" is linked to "setup-custom-repos" as
a convenience for administrators, who are used to the Subscription Management Tool for SUSE Linux Enterprise 10
commands.
Examples:
•
List all repos for the sles-10-x86_64 target that you are entitled to mirror
# smt-repos -m '' sles-10-x86_64 (single quotes)
•
Enable mirroring of a repository
# smt-repos -e SLES10-SP2-Updates sles-10-x86_64
•
Show the repos that are marked for mirroring
# smt-repos -o
11
•
Perform a mirror of the enabled SUSE Linux Enterprise 10 repos with verbose output and logging
# smt-mirror -d -L /var/log/smt/smt-mirror.log
•
Perform mirroring of the SUSE Linux Enterprise 9 products with verbose output and logging
# smt-mirror-sle9 -d -L /var/log/smt/smt-mirror-sle9.log
•
Create a report of the Subscription Management Tool and Novell Customer Center data based on
information in the local database.
# smt-report --local
•
List the products in the database and their IDs
# smt-list-products
•
Configure a non-Novell Update repository for mirroring
# smt-setup-custom-repos --productid 824 --name 'corp_updates' \
--exturl 'http://apps.mycompany.com/corp_updates/' \
--description 'Updates for my applications'
For information on which repositories to enable for mirroring see TID 7001199 - Which software catalogs to mirror with
Subscription Management Tool
Important Files and Directories
The main configuration file is /etc/smt.conf. Since it is well documented in section 7.2.1 of the Subscription
Management Tool guide we will not discuss it here except for a few parameters.
If source RPM packages are not relevant to your organization, then considerable time and disk space can be saved
by disabling mirroring of these. This is done by changing the parameter MirrorSRC = true to MirrorSRC = false in the
[LOCAL] section of /etc/smt.conf.
(# sed -i 's/MirrorSRC \= true/MirrorSRC \= false/g' /etc/smt.conf)
In case the Subscription Management Tool should use different HTTP and HTTPS proxy servers than the global
settings propose, this can also be configured with parameters in the [LOCAL] section.
Besides /etc/smt.conf, other files and directories worth knowing about are:
File/Directory
Description
/etc/smt.d/novell.com-smt
Cron file - symlinked into /etc/cron.d/
/etc/smt.d/smt-cron.conf
Parameters for cron jobs (7.2.2 in manual)
/srv/www/htdocs/smt.crt
Server certificate copied from
/etc/ssl/certs/YaST-CA.pem
/srv/www/htdocs/repo/$RCE/
Production (Novell) repositories
/srv/www/htdocs/repo/full/
Download directory for staged repositories
/srv/www/htdocs/repo/keys/
Directory for repo signing keys
/srv/www/htdocs/repo/RPMMD/
Custom repositories
/srv/www/htdocs/repo/testing/
Testing repositories
/srv/www/htdocs/repo/tools/clientSetup4SMT.sh
Script to import SMT server certificate and adapt
12
/etc/suseRegister.conf
/usr/sbin/smt*
Command line utilities to manage SMT
/usr/share/doc/manual/sle-smt_en/
Online documentation
/usr/share/doc/packages/smt/
Very useful other documentation
/var/spool/smt-support/
Incoming supportconfig archives
/var/log/smt/
Log files from the scheduled smt commands
The /var/log/smt/smt-* files get logrotated
In some scenarios it is not feasible to place the Subscription Management Tool certificate and repository directories
inside the Apache 2 DocumentRoot structure. It can for instance be security policies that prohibit even creating
symbolic links to the Subscription Management Tool data within the DocumentRoot. Check out the article How to
clean SMT completely out of apache DocumentRoot for instructions on how to configure that.
Configuring Clients to Use the Subscription Management Tool
The Subscription Management Tool is primarily designed for products based on SUSE Linux Enterprise 10 Service
Pack 2 and later versions. All machines running SUSE Linux Enterprise10 SP2 or later can be configured to register
with and download updates from the Subscription Management Tool instead of having to communicate with the
external Novell Customer Center and nu.novell.com servers.
Since the registration process against the Subscription Management Tool server uses https, the certificate of the
server needs to be installed in the client certificate store as part of the configuration.
There are four different ways to configure these clients to use the Subscription Management Tool, all described in
section 7 of the Subscription Management Tool guide.
1.
Novell Customer Center wizard (yast inst_suse_register) (SUSE Linux Enterprise 11 and later versions).
Can be done during normal installation (interactive) or at any time later.
Select the Advanced option in the Customer Center dialog to get the Local registration server dialog:
Figure 8a: Local Registration Server Dialog in Novell Customer Center Wizard
Here you can enter the full URL of the Subscription Management Tool server (e.g.
https://mysmt.blip.com/center/regsvc) and if the server certificate is in a non-default location, it can also be
13
specified. After this, you will be prompted to trust the certificate of the Subscription Management Tool server
and additional keys stored on it (if any).
2.
Kernel parameters (SUSE Linux Enterprise10 SP2 and newer)
Provide the regurl and optionally regcert kernel parameters during machine boot at installation time.
regurl is the URL of the Subscription Management Tool server and must be specified in the following format:
https://FQDN/center/regsvc/ with FQDN being the fully qualified hostname of the Subscription Management
Tool server which again must match the FQDN of the Subscription Management Tool server certificate.
Example: regurl=https://smt2.nts.com/center/regsvc/
regcert can be used to specify the location of the Subscription Management Tool server's CA certificate in
case you are not using the default location of http://smt-server-FQDN/smt.crt.
If clients are installed from DVDs, they could be remastered to include these parameters. Add these
parameters to the existing list in the "append" line for the install section in /boot/<arch>/loader/isolinux.cfg.
For inspiration look at TID 7001823 - Creating an auto-installing SLE 10 DVD.
3.
AutoYaST profile (SUSE Linux Enterprise10 SP2 and newer)
This method is much less error-prone and the preferred way for new clients to be installed.
It is possible to use the Autoinstallation GUI front end in YaST to create a section in an AutoYaST profile to
handle this. In SUSE Linux Enterprise 10 it is called "customer_center", but has been renamed to
"suse_register" in SUSE Linux Enterprise 11.
Create an xml block like the following to include in the profiles used to install SP2 based clients:



<$section-name>
<do_registration config:type="boolean">true</do_registration>
<reg_server>https://smt2.nts.com/center/regsvc</reg_server>
<reg_server_cert></reg_server_cert>
<register_regularly config:type="boolean">false</register_regularly>
<registration_data/>
<submit_hwdata config:type="boolean">false</submit_hwdata>
<submit_optional config:type="boolean">false</submit_optional>
</$section-name>
Adapt the reg_server and reg_server_cert as the corresponding kernel parameters described above.
4.
The clientSetup4SMT.sh script (SUSE Linux Enterprise 10 SP1 and newer)
The /srv/www/htdocs/repo/tools/clientSetup4SMT.sh script can be used to configure a client machine to use
a Subscription Management Tool server instead of Novell Customer Center or to reconfigure it to use a
different Subscription Management Tool server.
clientSetup4SMT.sh should be executed as root and takes the Subscription Management Tool server host
name or the full registration URL as parameter like this:
# ./clientSetup4SMT.sh --host smt_server_FQDN
or
# ./clientSetup4SMT.sh https://smt_server_FQDN/center/regsvc
The script first downloads the Subscription Management Tool server's CA certificate and prompts for
acceptance of it before installing it in the certificate store.
If it finds key files in /srv/www/htdocs/repo/keys/, the user is then prompted to accept them. Then it modifies
the url parameter in /etc/suseRegister.conf to point to the specified Subscription Management Tool server.
Now the client is ready to register against the Subscription Management Tool server. The script prompts the
user to run the suse_register command to register it.
Depending on the existence of key files in repo/keys/ a script like the following can be used to download and
execute the clientSetup4SMT.sh script without user intervention:
#!/bin/bash
# Add a Y below for each key file in /repo/keys/
14
wget -O /tmp/clientSetup4SMT.sh smt2.nts.com/repo/tools/clientSetup4SMT.sh
bash /tmp/clientSetup4SMT.sh --host smt2.nts.com<<EOF
Y
Y
EOF
rm /tmp/clientSetup4SMT.sh
# Work around service refreshing issue on SLE 11 (TID 7003779)
if [[ `grep -i version /etc/SuSE-release | grep 11` ]] ;then zypper ref -s
fi
The only way to configure products based on SUSE Linux Enterprise 10 SP1 (and earlier versions) to use
Subscription Management Tool is using the clientSetup4SMT.sh script. The parameters for the kernel and AutoYaST
profiles are only implemented from SUSE Linux Enterprise10 SP2 and later versions.
Jobs and Client Status Monitoring
For each client that is registered against the Subscription Management Tool server, Subscription Management Tool
creates a job queue. In order for this to be of any use to the clients, the smt-client package (only available for SUSE
Linux Enterprise11) needs to be installed on them. It could be installed during client installation time with an AutoYaST
script.
Installing the Client During System Installation
Although the original packages for the different architectures are shipping on the Subscription Management Tool for
SUSE Linux Enterprise 11 installation medium in CD1/clients/SLE11/, updated versions have been published in the
regular SLE?11-Updates repositories for SUSE Linux Enterprise Desktop /SUSE Linux Enterprise Server 11. Please
take the newest ones.
To avoid having to update the AutoYaST scripts that are used to install the clients, you can simply create a copy of the
packages without the version information in /repo/tools/ and name them smt-client.x86_64.rpm, smt-client.i586.rpm
etc. so that they can be retrieved with http.
Then add this tiny init-script to the <scripts> section of the AutoYaST profile while replacing the obvious:
<init-scripts config:type="list">
<script>
<filename>install-smt-client.sh</filename>
<interpreter>shell</interpreter>
<source><![CDATA[
zypper in -y http://my-smt-server/repo/tools/smt-client.x86_64rpm
]]>
</source>
</script>
</init-scripts>
During installation of smt-client package, a cron job gets created. This job by default kicks off the client executable
(/usr/sbin/smt-agent) every three hours. The agent then asks the server if it has any jobs in the queue belonging to
this client, and executes these jobs. When there are no more jobs in the queue, the agent terminates completely. It is
important to understand that jobs are not pushed directly to the clients when they get created, but are not executed
until the client asks for them in the preconfigured intervals of the cron job. Therefore, a delay of several hours may
occur from the creation time of a job on the server until the job gets executed on the client.
Every job can have its parent job, which means that the (child) job only runs after the parent job successfully finished.
It is also possible to configure advanced timing and recurrence/persistence of jobs, but this and many other details are
15
explained in the section about the smt-job command (7.1.2) of the Subscription Management Tool guide, on the man
page of smt-job and by executing smt-job -h.
When creating jobs, the GUID of the target clients must be specified using the -g <GUID>parameter. Although the -g
parameter can be specified multiple times on a single command, there is no "wild card" functionality to assign a job to
all clients.
Currently the following types of jobs are relevant:
Execute
Run commands on the client
Eject
Open, close or toggle the CD tray of the client
Patchstatus
Report the status of installed patches
Reboot
Reboot the client (requires smt-client-0.0.13-0.1)
Softwarepush
Install packages
Update
Install available updates (requires smt-client-0.0.13-0.1)
By default only softwarepush, patchstatus and update jobs are allowed. To allow more types of jobs, append the job
type to the ALLOWED_AGENTS list in /etc/sysconfig/smt-client.
All clients that register against a Subscription Management Tool server automatically get a persistent patchstatus job
added to their job queue. This unfortunately also counts for clients that are not SUSE Linux Enterprise 11 clients,
although there are no smt-clients for them. These clients will forever appear with a patchstatus of "Unknown" in the
client lists. The patchstatus jobs for clients that are not SUSE Linux Enterprise 11 are not required and clients can
safely be deleted (if you want to clean up the output of smt-job). Just remember that if you update a machine to SUSE
Linux Enterprise 11 later, you will have to create the patchstatus job manually if it is used on that client.
The most obvious use for this is to monitor the patch status of clients. Whenever the client runs a patchstatus job, it
compares the currently installed updates with what is available in the repositories on the Subscription Management
Tool server. The job then reports back the number of missing patches that need to be installed in each of the four
categories:
•
•
•
•
Security
Package Manager
Recommended
Optional
A summary of the status of all registered clients is available on the clients tab of the Subscription Management Tool
Server Management YaST module (see screenshot figure 9 below):
16
Figure 9: Subscription Management Tool Server Management, Clients Tab
For the host xsles11a there are two package manager patches and two optional patches available. Security and
package manager updates are considered critical, and recommended and optional updates will be flagged with
"Updates available.”
The status of the hosts xres47a and xres52a is unknown, because these are Red Hat servers for which there is no
smt-client package available. The same applies to SUSE Linux Enterprise 10 clients.
NOTE: Package manager patches can "hide" other patches, since they might be a prerequisite to other patches in
such a way that these do not show up as available until the package manager patch(es) have been installed.
In the example above, there are many security and recommended patches available for the xsles11a host, but they do
not show up until the package manager patches have been installed.
The date and time in the “Last Contact” column is the real last time contact of the server, even if it only ran the regular
registration update script (see the "register regularly" switches during registration and in AutoYaST). This date is not
the date of the last patchstatus report. The command line tool smt-client prints the correct date and calls it “Patch
Status Date” (smt-client -v will print both dates, the patchstatus date and the last contact of the client system).
TIP: To install a package (and its dependencies), the job type softwarepush is used. When creating this type of job, it
is a good habit to always add the --agreelicense option. The reason for this is that if a package displays a license
agreement and expects it to be accepted, the job will just skip the package unless --agreelicense has been specified.
The smt-client hands off the installation process to zypper, which does not consider a failed acceptance of a license
agreement to be an error. This results in the job being completed successfully, even though the package might not
have been installed due to this, which is a bit misleading.
Another practical example of using jobs would be using a combination of execute and update jobs.
NOTE: Execute jobs are not enabled by default, since they allow commands to be executed on the host. Extreme
caution should be used before deploying this in production. The same applies to reboot jobs. While they might be
17
handy, rebooting can have serious implications if you submit a job that reboots your CEO's machine in the middle of a
board meeting.
This idea is to configure selected clients to subscribe to the update repositories in the testing environment and then
perform an update. In the scenario below, the client to update is named host1, which has the GUID
fc9a5b43ead542fba9cedb7b00d20647. On the SMT server we have created the script
/srv/www/htdocs/repo/tools/switch-to-testing-repos.
It reconfigures /etc/suseRegister.conf, performs a suse_register and launches an update like this:
#!/bin/bash
/usr/bin/sed -i '/^register/ c\register = command=register\&namespace=testing'
/etc/suseRegister.conf
/usr/bin/suse_register
/usr/bin/zypper ref -s
/bin/logger SMT : Now switched to testing repositories
/bin/logger SMT : Installing available updates
/usr/bin/zypper up -y –l
First, ensure that the job type "execute" is listed in ALLOWED_AGENTS in /etc/sysconfig/smt-client on the client.
Second, create a job that downloads the script to the client and executes it:
# smt-job --create -t execute --verbosejob -g fc9a5b43ead542fba9cedb7b00d20647 \
-X "wget smt11a/repo/tools/switch-to-testing-repos -O /tmp/switch-to-testing-repos ; \
bash /tmp/switch-to-testing"
Successfully created new job. The job id is: 14
Then create an update child job that runs when the above job has successfully completed.
# smt-job --create -t update --verbosejob -g fc9a5b43ead542fba9cedb7b00d20647 \
--parent 14
To avoid waiting for the next cron-initiated launch of the client agent and to monitor its log file, simply issue the
command:
# smt-agent & tail -f /var/log/smtclient.log
Since --verbosejob was specified when creating the jobs, stderr and stdout will be shown in the log file (once the
commands have finished).
If you want to monitor the zypper update process itself, run tail -f /var/log/zypper.log.
This is just the beginning; with some creativity, many tasks can be completed with Subscription Management Tool
jobs.
One thing to keep in mind is that Subscription Management Tool abstracts tasks by letting you run high-level
commands like "update" or "install-software". It does not know how they are updated on the target client; only the
agents in the smt-client package know that. So although you can tunnel shell scripts through the smt-jobs layer, it may
break the target system independency.
18
Staging
When a repository has been mirrored, it can be used for staging. That means that testing and production repositories
can be created based on the "full" mirrored repository. This way it is possible to test new patches from Novell on a
limited number of clients before releasing them to the public. It is also possible to simply prevent individual patches
from ever being "released" internally. Although this is all manageable with smt commands, the easiest way is to use
the staging tab in the Subscription Management Tool server management module:
Figure 10: Subscription Management Tool Server Management, Staging Tab
The flow in using staging goes as follows:
•
Mirror a repository
•
Enable the repository for staging
•
Mirror it again to create the staging structure
•
Select the patches to be included in a testing snapshot by clicking "Change Status" and selecting "All
listed..." and "Enable." Individual patches can then be disabled by selecting them and clicking "Toggle Patch
Status."
•
When the filtering is completed, a testing snapshot is created by clicking "Create Snapshot" and selecting
"From full mirror to testing"
•
Redirect selected clients towards the testing environment. This is done by changing the register command
in /etc/suseRegister.conf to:
register = command=register&namespace=testing
and executing the suse_register command.
The Namespace column in the output of the smt-list-registrations provides an overview of which staging
environment the clients are registered against.
•
Now install the available updates on the clients and test, test, test
19
•
Once the patches in the testing environment have been tested and approved, a production snapshot can be
created. This is done by clicking "Create Snapshot" and selecting "From Testing to Production."
A visual representation of the flow might help:
Figure 11: Staging Illustrated
In the figure above, there is a dotted line between the clients and the full repository. That is because in some
situations it might be feasible for a client to have access to all updates from Novell as soon as they occur (for instance
if using the IS&T department as alpha testers). This is possible by appending "&namespace=full" to the register
command in /etc/suseRegister.conf.
The full-blown staging feature is only supported for SUSE Linux Enterprise 11 repositories. Since not all of the SUSE
Linux Enterprise 10 repositories support selective staging (patch filtering), the testing environment must be managed
manually. This is described briefly in section 3.4 of the Subscription Management Tool guide and the concept is the
same as for the SUSE Linux Enterprise 11 repositories. However, there is no filtering of patches available and the
snapshots must be created manually.
The scenario to use the testing environment looks like the following:
•
Perform an smt-mirror to the $MirrorTo/repo/testing/ structure:
# smt-mirror --directory /srv/www/htdocs/repo/testing ...
•
Now reconfigure the test clients to use the test environment:
•
Change the register command in /etc/suseRegister.conf to:
register = command=register&namespace=testing
•
Register the client against the testing service/repos and verify that the testing service has been added and
that the corresponding repos have been subscribed. For SUSE Linux Enterprise 10 clients, use the
following commands:
20
# yast2 inst_suse_register (or suse_register)
# rug service-list
# rug catalogs
The service name should have "/testing/" appended to the Subscription Management Tool server URL. For
SUSE Linux Enterprise 11 clients, use the following commands:
#
#
#
#
yast2 inst_suse_register (or suse_register)
zypper ref -s
zypper ls -u
zypper lr -u
On SUSE Linux Enterprise11 it is not possible to verify that the client is in testing namespace from the
client side. This has to be verified with the smt-list-registrations command on the Subscription
Management Tool server, which shows the namespace information.
Now testing can begin. Perform the desired level of testing and once you are done testing, deploy the contents of the
testing environment. This could effectively be done with an rsync command like:
# rsync -av /srv/www/htdocs/repo/testing/<repository>/ \
/srv/www/htdocs/repo/<repository>/
•
If desired, then reconfigure the test clients to use the production environment by setting the register command
back to default in /etc/suseRegister.conf:
register = command=register
•
Run suse_register / yast inst_suse_register to register back against the production service/repositories and
verify that the service has changed back to normal with the same rug or zypper commands as above
depending on the client platform.
Compliance Monitoring with Subscription Management Tool Reports
To assist customers in monitoring their license compliance, Subscription Management Tool generates a weekly report
based on Subscription Management Tool and Novell Customer Center data. This report contains information about
statistics of the registered machines, products used, and of the active, expiring or missing license subscriptions. In
case subscriptions are about to expire and/or a lack of licenses is observed (e.g., more SUSE Linux Enterprise Server
10 machines are registered than you have purchased licenses for) the report contains warnings about this.
In order to be able to calculate the compliance, the smt-report tool by default downloads information about the
subscriptions and registrations (this can be disabled).
The addresses to send the reports to can be configured on the Database and Reporting tab of the YaST Subscription
Management Tool configuration module. All of the e-mail configuration options are located in the [REPORT] part of
/etc/smt.conf and explained in section 6.2.1 of the Subscription Management Tool guide.
The scheduling of the reports is configured in /etc/smt.d/novell.com-smt and the parameters to use with the cron jobs
are set in REPORT_PARAMS in /etc/smt.d/smt-cron.conf file.
The content of the reports is too comprehensive to cover in this article, but a set of reports can be broken down into
five individual parts. By default, these reports are attached as individual files to the mail on the weekly report run. The
alerts report is a normal text file while the others are in CSV format. The reports can also be created in PDF or XML
by specifying --pdf or --xml as output format.
To generate a set of reports in CSV files based on local data and to display them on stdout, a command like the
following would work:
21
# smt-report --local --csv --file /tmp/smt-local-rep
Generates:
/tmp/smt-local-rep-product_subscription_active.csv
/tmp/smt-local-rep-product_subscription_alerts.txt
/tmp/smt-local-rep-product_subscription_expired.csv
/tmp/smt-local-rep-product_subscription_expiresoon.csv
/tmp/smt-local-rep-product_subscription_summary.csv
NOTE: If you have multiple Subscription Management Tool servers deployed in your environment, the reports may
not represent all of the Subscription Management Tool servers or machines in your environment. For the complete
statistics of all your registered machines, refer to the information in the Novell Customer Center.
The smt-report tool takes into consideration if forwarding of registration data to Novell Customer Center has been
disabled (forwardRegistration = false in /etc/smt.conf) and then sets the type of report to --local.
For more information about types of reports, output formats and targets refer to section 6 of the Subscription
Management Tool guide.
Supportconfig Proxy
The supportconfig utility from the supportutils package (available here) is used to create archive files containing
system configuration information. These archive files are used by Novell engineers working on service requests to
troubleshoot customer issues. The supportconfig utility is capable of uploading these files directly to the novell.com
servers, so that they get attached to the ongoing service requests records in the Novell call tracking system.
The Subscription Management Tool for SUSE Linux Enterprise 11 is able to act as a proxy for clients (SUSE Linux
Enterprise and Novell Open Enterprise Server), by acting as store-and-forward agent for the archive files. Before
submitting the archives to Novell, they could be analyzed for known issues by the Novell Support Advisor utility.
Issues, which get identified by the Novell Support Advisor, could then be resolved without further involvement by
Novell.
The flow would be as follows:
•
supportconfig creates an archive on the host being investigated and uploads it to the Subscription Management
Tool server
•
An administrator runs Novell Support Advisor against the archive directory on the Subscription Management
Tool server to identify known issues
•
Individual archive files can be repacked with new or updated metadata as they are uploaded
On the "Scheduled SMT jobs" tab of the Subscription Management Tool server configuration module, it is also
possible to add a predefined job to simply upload supportconfig archives to novell.com. Click the Add button and
select "Uploading Support Configs" and set a schedule. The Subscription Management Tool will then upload all the
archives from /var/spool/smt-support/ to novell.com without any modifications when the job runs.
22
Mirroring Updates for Red Hat Enterprise Linux
Customers who have purchased SUSE Linux Enterprise Server Subscription with Expanded Support (see
http://www.novell.com/products/server/expandedsupport/offering_summary.html for details) are entitled to mirror
updates for Red Hat 3.9, 4.7 and 5.2 as described in the terms above.
How to configure the Subscription Management Tool server and the Red Hat clients to use Subscription Management
Tool as their update source is described in TID 7004324 - How to update Red Hat Enterprise Linux with SMT 11.
Mirroring SUSE Linux Enterprise 9 Updates
Although the Subscription Management Tool is primarily designed to manage products based on SUSE Linux
Enterprise 10 (and later) update repositories, Novell has added basic functionality to enable mirroring of products
based on SUSE Linux Enterprise 9 as well. By using this functionality, the Subscription Management Tool server can
act as a SUSE Linux Enterprise Server 9 YaST Online Update (YOU) server, which your SUSE Linux Enterprise
Server 9 servers can be pointed against. This way the need for having a dedicated SUSE Linux Enterprise Server 9
server running the YOU service is eliminated.
The smt-mirror-sle9 tool creates a structure in $MirrorTo/repo/YOU9 that is similar to /var/lib/YaST2/you/mnt on a
SUSE Linux Enterprise Server 9 YOU server and stores the updates there.
The repositories to mirror are configured in /etc/smt.conf and by default it mirrors everything accessible on
https://you.novell.com/update/ for each product.
It is important to note that all updates and sources for a product since it was released will be mirrored. This means
that the repositories may consume up to 10 times more than what is needed by a freshly configured YOU server (e.g.
27 G for SUSE-CORE 9 versus 2 G respectively).
For SUSE-CORE 9 this includes:
/x86_64/update/SUSE-CORE/9/
/x86_64/update/SUSE-CORE/9/images (irrelevant)
/x86_64/update/SUSE-CORE/9/patches
/x86_64/update/SUSE-CORE/9/patches.obsolete (irrelevant)
/x86_64/update/SUSE-CORE/9/rpm
/x86_64/update/SUSE-CORE/9/scripts
/x86_64/update/SUSE-CORE/9/sources (relevant for some)
And inconsistent index.html* files in all directories
The irrelevant directories above can be excluded from download by creating the file /var/lib/smt/.wgetrc containing one
line with comma-separated directories to omit, e.g.,
exclude_directories = /update/x86_64/update/SUSE-CORE/9/images,
/update/x86_64/update/SUSE-CORE/9/patches.obsolete,
/update/x86_64/update/SUSE-SLES/9/sources
(All on one line)
Another difference between the mirroring of SUSE Linux Enterprise 10 and SUSE Linux Enterprise 9 updates is that
while the SUSE Linux Enterprise 10 updates reside on the nu.novell.com servers, which are globally mirrored by an
external IP application accelerator, the SUSE Linux Enterprise 9 servers get downloaded from you.novell.com.
23
This leads to considerably slower download rates (especially during the initial download of the repositories). But for
the users of smt-mirror-sle9 this small hitch may be counteracted by the fact that it is possible to mirror SUSE Linux
Enterprise 9 updates with the Subscription Management Tool.
So how do we get it to work?
1.
Enable mirroring of the products and architectures desired to mirror in /etc/smt.conf. As an example, if you want to
mirror the updates for SUSE Linux Enterprise Server 9 i386 and x86-64 architectures, the following changes should
be applied to both the [YOU9-SUSE-CORE] and [YOU9-SUSE-SLES] sections:
Change mirror = false to mirror = true
Change mirror_archs to only reflect those you need - e.g. :
mirror_archs = i386,x86_64
Set credentials to those in /var/lib/YaST2/you/password on your YOU server - e.g. :
credentials = my-ncc-account-name:password
2.
(Optional) Create the file /var/lib/smt/.wgetrc to exclude undesired directories as described above.
3.
Perform the actual mirror. To run it with verbose output and logging to a file that gets logrotated, use a command
like:
smt-mirror-sle9 -d -L /var/log/smt/smt-mirror-sle9.log
4.
Schedule regular execution of smt-mirror-sle9 by e.g. adding a line like this to /etc/smt.d/novell.com-smt:
33 3 * * 1 root /usr/sbin/smt-mirror-sle9 -L /var/log/smt/smt-mirror-sle9.log
This executes it at 3:33 a.m. every day.
5.
Configure the client SUSE Linux Enterprise Server 9 servers to retrieve updates from your Subscription
Management Tool server. This is done in the online update module in YaST, where the URL should point to the
repository on the Subscription Management Tool server, e.g., http://smtsrv.your.domain/repo/YOU9
NOTE : An update for the smt package is also needed for proper mirroring of SLES 9 updates, but the version and
release date is not set at the time of writing this document.
Custom Repositories
The Subscription Management Tool also includes functionality to mirror custom repositories that are not available at
Novell Customer Center. These might be your own in-house developed applications or third-party driver/software
repositories like close source hardware drivers that Novell for is not shipping with the products (for legal reasons).
When configuring custom repositories to be mirrored with smt-mirror, all repositories must be associated with one or
more Novell product IDs. This ID can be determined using the smt-list-products command:
#
|
|
|
|
|
smt-list-products | grep SLED
1223 | SUSE_SLED
1222 | SUSE_SLED
1221 | SUSE_SLED
1220 | SUSE_SLED
1224 | SUSE_SLED
/-/
/-/
/-/
/-/
/-/
|
|
|
|
|
11
11
11
11
11
|
|
|
|
|
i386
i486
i586
i686
x86_64
|
|
|
|
|
-
|
|
|
|
|
0
0
0
0
0
|
|
|
|
|
This shows that the product ID for i686 based SUSE Linux Enterprise Desktop 11 is 1220 and for the x86_64
architecture it is 1224.
To verify the installed product on a SUSE Linux Enterprise 11 system, use zypper to dump the product data in xml
format. This can be difficult to understand, but if we grep and awk it a little it becomes more user-friendly:
# zypper --xml products -i |grep SUSE_ | awk '{print $2" "$3}'
name="SUSE_SLED" version="11"
24
On SUSE Linux Enterprise 10 the product IDs can be a bit confusing:
#
|
|
|
smt-list-products | grep SUSE-Linux-Enterprise-Server-SP2 | grep x86
824 | SUSE-Linux-Enterprise-Server-SP2
| 10 | x86_64 | 839 | SUSE-Linux-Enterprise-Server-SP2
| 10 | x86_64 | online
809 | SUSE-Linux-Enterprise-Server-SP2-migration
| 10 | x86_64 | -
|
|
|
5 |
0 |
1 |
As the output above shows, multiple IDs can exist for the same product, depending on the release, which basically
represents the way that the SUSE Linux Enterprise product has been installed. “Online” is an upgraded product, e.g.,
a machine originally installed from SUSE Linux Enterprise Server 10 SP1 and then updated online to SP2.
To determine the release of a SUSE Linux Enterprise 10 SP2 product installed on a system, execute the following
command on it:
# /usr/lib/zypp/zypp-query-pool products @system
i|product|SUSE_SLES_SP2|10.2-0|x86_64|SUSE-Linux-Enterprise-Server-SP2|10-SP2|base|
SLES 10 SP2|SUSE Linux Enterprise Server 10 SP2
The 8th field is the release
base = "-" in smt-list-products
online = online in smt-list-products
So for the machine above, the product ID would be 824.
To associate a catalog with multiple product IDs, just add more --productid ID# parameters. As an example :
# smt-setup-custom-repos --productid 824 --productid 839 \
--name "My_own_SLES10_SP2_APP_UPDATES" \
--exturl "http://download.my.company/SLES10-SP2" \
--description "Private SLES updates"
When deleting a custom catalog, the ID to provide for this step is the GUID. Find it with the smt-repositories command
in verbose mode:
# smt-repos -v VLC_SLED10_SP2 |grep ID
CatalogID: 657e1ad399d8cf69a8f7202baeb05db8c8835c93
and then delete the catalog from the local Subscription Management Tool database with:
# smt-setup-custom-repos –delete \ 657e1ad399d8cf69a8f7202baeb05db8c8835c93
If the custom catalog/repository is unsigned, the clients will fail to subscribe to them for security reasons.
On SUSE Linux Enterprise 11 clients you will be presented with a prompt like the following when trying to register an
unsigned repository:
File 'repomd.xml' from repository 'Corp-Updates' is unsigned, continue? [yes/NO]:
After accepting this, the repository will be added.
SUSE Linux Enterprise 10 clients do not allow the use of unsigned repositories at all unless their configuration gets
changed to allow this explicitly. This is done by executing the following command:
#rug set security-level checksum
This may be a security concern to your company, but custom repositories are beyond the control of Novell. How to
deal with this issue is something you need to work out on your own.
25
Repository Signing
Although it is possible to accept unsigned repositories, they should be avoided because they make the systems
vulnerable to security threats.
When refreshing the repositories, the zypper package manager in SUSE Linux Enterprise 11 handles repository
signing differently than the ZENworks Management Daemon (rug) does on SUSE Linux Enterprise 10. The goal is to
enable silent addition of custom repositories that are signed with unknown keys. These are keys that are not provided
by Novell.
In SUSE Linux Enterprise 10, the options to handle repositories that are signed with unknown keys are:
1.
Import the key with
# rpm --import <keyfile>
This can be done during the installation with a post-script in AutoYaST (or later).
2.
Lower the security level check from signature to checksum in ZMD with:
# rug set security-level checksum
This is also possible through AutoYaST.
In SUSE Linux Enterprise 11 the options are:
1.
Import the key with
# rpm --import <keyfile>
This can be done during the installation with a post-script in AutoYaST (or later).
2.
Download the key during registration with the Subscription Management Tool server.
Place a copy of the key used in /repo/keys/ on the Subscription Management Tool server. The registration
process with the Subscription Management Tool server will then pick up the key and display a dialog similar to
this:
/tmp/smtsetup-lxl52yc6/.gnupg/pubring.gpg
----------------------------------------pub 1024D/C8A57A4A 2008-10-14 [expires: 2010-10-14]
Key fingerprint = 3730 C2A0 E2A5 2778 A22C BEA4 B19C 56D8 C8A5 7A4A
uid Update Administration (Repository key1) <updates@mycompany.com>
sub 2048g/CCB57776 2008-10-14 [expires: 2010-10-14]
Trust and import this key? [y/n]
For security reasons every key does require user acceptance and this dialog cannot be avoided.
3.
If the key is not imported, then the user will be prompted to accept the key the first time the repository is
queried.
For more information about mirroring custom repositories with the Subscription Management Tool for SUSE Linux
Enterprise 11, refer to smt-setup-custom-repos -h or section 3.2.5 in the Subscription Management Tool guide.
If you would like to create your own repository with updates and publish it with the Subscription Management Tool, the
article Creating a YUM repository and publishing it with SMT explains all the steps (currently only based on SUSE
Linux Enterprise 10).
26
Disconnected Subscription Management Tool Servers
In some restricted environments it is not possible for the Subscription Management Tool servers to access the Internet
because they are located in disconnected or isolated networks. By using some special parameters on the Subscription
Management Tool commands and a mobile disk, it is possible to accommodate for this.
This option works by having one Subscription Management Tool server that mirrors the repositories, which are
needed on the isolated servers. Then these internal servers can "mirror" from the external servers (through the mobile
storage medium) a concept which is also sometimes referred to as "sneaker-netting."
The scenario can be illustrated like this:
Figure 12: Isolated Subscription Management Tool Setup
The initial setup of this special solution requires some extra configuration, but the regular update synchronization with
nu.novell.com and distribution to isolated servers is relatively simple. While the details in the configuration are covered
later, a quick overview might be useful first.
The steps required during the initial setup consist of:
•
Installation and configuration of the external Subscription Management Tool server "by the book"
•
Installation of the internal server
•
Modification of smt.conf and cron setup on the internal server
•
Creation of a copy of the Novell Customer Center data on the external Subscription Management Tool server
and importing it to the internal Subscription Management Tool server
•
Enabling and disabling of catalogs on the internal server
•
Creation of a Subscription Management Tool database replacement file (which can be used instead of the
normal MySQL Subscription Management Tool database when performing the mirror jobs) on the internal
server
The day-to-day operation includes:
27
•
On the external server run an smt-mirror job based on the database replacement file that writes to the mobile
disk.
•
Synchronization of the mirrored repositories from the mobile disk to the internal Subscription Management Tool
server.
We will now describe the individual steps in detail, considering the information about installation and configuration of
the Subscription Management Tool discussed earlier in this document.
•
On the external server
•
Install and configure the Subscription Management Tool "by the book"
•
Enable the repositories to be consumed by the internal Subscription Management Tool servers
•
Perform a normal mirror (smt-mirror) from Novell Customer Center
•
Attach a removable disk to the server and mount it
•
Export the required Novell Customer Center data to a directory on that disk:
•
Create the directory to hold the data
•
Grant permissions to that directory. Since the smt commands execute as the smt user (of which the
numeric uid can differ between the servers), we need to ease up the permissions for the directories on
the mobile disk.
# chmod o+w </path-to-ncc-dir-on-mobile-disk>
•
Export the Novell Customer Center data:
# smt-ncc-sync --export </path-to-ncc-dir-on-mobile-disk>
•
Set up a directory for repositories:
•
Create the directory
# mkdir </path-to-repository-on-mobile-disk>
•
Grant permissions as above
# chmod o+w </path-to-repository-on-mobile-disk>
•
•
Unmount and detach the removable disk
Install and configure the internal server:
•
Ensure you have a working SUSE Linux Enterprise Server 11 installation source
•
Install the Subscription Management Tool as on the external server with the following exceptions:
•
•
Select "Generate new NCC credentials" in the "NCC Credentials" dialog
•
Ignore the error about running the synchronization script in the "Writing SMT Configuration" phase of
the wizard
•
Abort the Novell Customer Center Configuration wizard and then click OK in the list of installed add-on
products
Re-launch the YaST Subscription Management Tool Server Configuration module (yast2 smt-server) and
go to the "Scheduled SMT Jobs" tab
•
Delete "NCC Registration" and "Synchronization of Updates" jobs
•
Hit OK to finish the wizard, provide the Subscription Management Tool user password and acknowledge
the sync error again.
•
Prevent registration data upstream sync to Novell Customer Center
set forwardRegistration = false in /etc/smt.conf
•
Prevent sync with Novell Customer Center before creating reports
•
Insert "--nonccsync" at the beginning of the REPORT_PARAMS list in /etc/smt.d/smt-cron.conf
# sed -i 's/REPORT_PARAMS=\"/REPORT_PARAMS=\"--nonccsync /g' \
/etc/smt.d/smt-cron.conf
•
Connect the mobile disk and mount it
28
•
Populate the Subscription Management Tool database with the Novell Customer Center data just created
•
Enable mirroring of the desired repositories
# smt-ncc-sync --fromdir </path-to-ncc-dir-on-mobile-disk>
smt-repos -e ...
•
Create a database replacement file on the mobile hard disk
# smt-ncc-sync --createdbreplacementfile \
</path-to-dbrepl-file-on-mobile-disk>
•
Unmount and detach the removable disk
•
Now the configuration is complete, but the update repository is empty
•
After one iteration of the day-to-day operation, the update repositories are synchronized and the internal
server is ready to serve clients
Day-to-day operation:
•
On the external server:
•
Connect the mobile disk and mount it
•
Perform a mirror based on the file on the mobile disk and to a directory on the mobile disk:
# smt-mirror --dbreplfile </path-to-dbrepl-file-on-mobile-disk> \
--fromlocalsmt --directory </path-to-repository-on-mobile-disk> \
-L /var/log/smt/smt-mirror-<you-name-it>.log
•
Update the database on the mobile disk with product and subscription info from Novell Customer Center:
# smt-ncc-sync --export </path-to-ncc-dir-on-mobile-disk>
•
•
Scan the mobile disk for virus and/or other unwanted content if desired
•
Unmount and disconnect the mobile disk
On the internal server:
•
Connect the mobile disk and mount it
•
Update the Novell Customer Center data on the server
# smt-ncc-sync --export </path-to-ncc-dir-on-mobile-disk>
•
Mirror from the mobile disk to the server
# smt-mirror --fromdir </path-to-repository-on-mobile-disk>
•
Update the Novell Customer Center data on the mobile disk with local changes in the mirror status since
the last synchronization
# smt-ncc-sync --createdbreplacementfile \
</path-to-dbrepl-file-on-mobile-disk>
•
Unmount and disconnect the mobile disk
If the isolated Subscription Management Tool server has mirrored the SUSE Linux Enterprise Server 11-Updates and
SUSE Linux Enterprise 11-SMT-Updates for its own target/architecture, it can be registered to consume locally
available updates as described in TID 7004388 - Configuring SMT11 servers to use self-hosted repositories.
Registration Data Synchronization with Novell Customer Center
By default, information about registered clients is sent from the Subscription Management Tool to Novell Customer
Center every 15 minutes. Some customers have concerns about disclosing information about internal resources to
Novell. They can set the parameter
29
forwardRegistration = false
in /etc/smt.conf to effectively disable this. The Subscription Management Tool tools take the setting of this parameter
into account when communicating with Novell Customer Center.
If you are really concerned, disable the "NCC registration" cron job in the YaST Subscription Management Tool
configuration module. This deletes the smt-repeated-register job from /etc/smt.d/novell.com-smt and since this file is
marked as a configuration file, updates to the Subscription Management Tool should not overwrite it. (Checking after
applying updates to the Subscription Management Tool never hurts.)
Publish Update Repositories on the Internet for Mobile Workstations
Some enterprises have many clients (workstations) that only occasionally are connected to the internal network. The
obvious way to make the update repositories accessible to these machines would be to expose the Subscription
Management Tool server to the public. However publishing the restricted files from the update repositories on the
internet would violate the copyright/licensing agreement with Novell and is liable for legal prosecution.
The Subscription Management Tool offers a way to legally meet this business need by using the authentication
feature available and adding a tweak to the registration handler configuration.
Before implementing this solution it is crucial that the fully qualified domain name of the Subscription Management
Tool server is be the same internally as externally. Otherwise the SSL communication between the server and the
clients will fail.
Start the configuration by adding the following three lines in the
<Location /center/regsvc> section of the /etc/smt.d/smt_mod_perl.conf file:
Order Deny,Allow
Deny from all
Allow from <network-address/subnet-mask>
This is normal apache2 configuration and the address can also be specified using CIDR notation.
The section could for example look like this:
<Location /center/regsvc>
# perl cgi mode
# Limit access to registration service
Order Deny,Allow
Deny from all
Allow from 192.168.0.0/24
SetHandler perl-script
HostnameLookups On
PerlResponseHandler SMT::Registration
</Location>
Please be aware that although /etc/smt.d/smt_mod_perl.conf is marked as a configuration file, it may get
changed when applying updates to SMT. So keep in mind to verify that your changes are still in the file after an
update.
Then configure /etc/smt.conf to require authentication by changing the default
requiredAuthType = none
to
requiredAuthType = lazy
30
or
requiredAuthType = strict
Depending on how strict policies are desired. See section “7.2.1 /etc/smt.conf” of the Subscription Management Tool
guide for details.
Finally restart the Subscription Management Tool service with the command :
# rcsmt restart
This changes the behavior, so that the clients must authenticate with the Subscription Management Tool server when
accessing the updates. The userid and password being used for this are what is stored in
/etc/zypp/credentials.d/NCCcredentials.
The 32-digit hexidecimal username is the “Unique ID” that the client is registered with in the Subscription Management
Tool database.
Now the configuration is completed. Test it by trying to register against the Subscription Management Tool server from
a client on an unauthorized network.
If clients from unauthorized networks try to register against the restricted Subscription Management Tool server,
errors like this will appear:
sles11pv:~ # suse_register
ERROR: 403: Access forbidden!
You don't have permission to access the requested object. It is either
read-protected or not readable by the server.
If you think this is a server error, please contact the webmaster.
Error 403
smt11a.nts.com
Mon Nov 16 13:32:47 2009
Apache/2.2.10 (Linux/SUSE)
Forbidden
(2)
At the same time a message like this will be logged in /var/log/apache2/access.log of the Subscription
Management Tool server:
[Mon Nov 16 13:32:47 2009] [error] [client 192.168.1.25] client denied by server
configuration: /srv/www/htdocs/center
Preloading Repositories
Although the nu.novell.com servers are accelerated as mentioned previously and you may have lots of Internet
bandwidth, deploying multiple Subscription Management Tool servers may become time consuming if each new
Subscription Management Tool server must mirror the same repositories.
To save time when deploying new Subscription Management Tool servers, the catalogs can be preloaded from
another server/disk instead.
The steps to do that are:
•
Enable the catalogs to be mirrored with the Subscription Management Tool - example:
# smt-repos -e SLES1-Updates sle-11_x86_64
31
•
Perform a dry run of smt-mirror to get the repository directories created
# smt-mirror -d --dryrun -L /var/log/smt/smt-mirror.log
•
Using the repository above and the default MirrorTo, this will create:
/srv/www/htdocs/repo/repoindex.xml
/srv/www/htdocs/repo/$RCE/SLES11-Updates/sle-11-x86_64/*
•
Now you can copy over the repositories for instance from another Subscription Management Tool server example:
# rsync -av 'smt10:/srv/www/htdocs/repo/\$RCE/SLES11-Updates/sle-11-x86_64/' \
'/srv/www/htdocs/repo/$RCE/SLES11-Updates/sle-11-x86_64/'
•
To get the repodata fixed up perform a normal smt-mirror like:
# smt-mirror -d -L /var/log/smt/smt-mirror.log
Be prepared for errors like “repomd.xml is the same, but repo is not valid. Start mirroring.” These errors occur,
since the metadata about the preloaded repositories in the server's database is incorrect until this initial mirror
of the repositories has completed.
Server Tuning
The /usr/share/doc/packages/smt/Server-Tuning.txt contains very useful tips about different ways of tuning
Subscription Management Tool server performance.
Here you will find tips on increasing number of clients for Apache 2, increasing mysqld connections and also how to
speed up the database connection by installing the perl-Apache-DBI module from the SUSE Linux Enterprise 11
Software Development Kit.
Backup of Subscription Management Tool Servers
For many of us, the last thing we think of is creating a backup. In case of loss of a Subscription Management Tool
server, the update repositories can be re-mirrored, but the Subscription Management Tool MySQL database will be
gone and it is not possible to recover or synchronize it back from Novell Customer Center.
This database contains important information about clients, registrations, machine data, which catalogs that are
enabled for mirroring, custom catalogs, etc.
Thus it is highly recommended to include a backup of at least your Subscription Management Tool database and
possibly also the update repositories into your normal backup solution. Since the database is MySQL based, the
easiest way to produce a restorable backup is to create a cron job that performs a simple mysqldump of it with a
command like:
# mysqldump -uroot -p<smt-db-pwd> smt > /some-directory/smt-db-backup.sql
and include the file in your normal backup jobs.
Conclusion
The Subscription Management Tool for SUSE Linux Enterprise Server 11 comes with several exciting and innovative
capabilities in systems management. These capabilities include the:
•
Possibility of staging patches to internal managed areas under full control of the site administrator. This gives
the administrator the option to carry out integration testing before they fully enable the new patches onsite.
•
Ability to centrally push packages to managed devices
32
•
Improved setup and the facilitated operation for fully disconnected ("sneakernet") configurations
•
New support for System z as server hosting architecture (in addition to x86 and x86-64)
•
Full integration with the new supportability infrastructure delivered with SUSE Linux Enterprise (Novell Support
Link integrated in SUSE Linux Enterprise 11 and Novell Support Advisor from Novell Technical Services). This
helps facilitate problem reporting and troubleshooting.
Support for the Subscription Management Tool for SUSE Linux Enterprise 11 is included with any SUSE Linux
Enterprise subscription at no additional cost. The support level available is applicable to your active SUSE Linux
Enterprise subscription.
We hope that this deployment guide has helped demonstrate how easy it is to use the Subscription Management
Tool, and has also provided you with some tips that can be useful when deploying the Subscription Management Tool
in your specific environment.
References
•
Subscription Management Tool for SUSE Linux Enterprise 11 guide available online and in
/usr/share/doc/manual/sle-smt_en/.
•
Documents in /usr/share/doc/packages/smt/
•
Subscription Management Tool for SUSE Linux Enterprise Web page
•
Frequently Asked Questions for Subscription Management Tool for SUSE Linux Enterprise
© 2009 Novell, Inc. All Rights Reserved. Novell, the Novell logo, the N logo, SUSE and ZENworks are registered trademarks of
Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.
33