How to Use the Subscription Management Tool for SUSE Linux Enterprise 11

Transcription

1 Linux Deployment Guide How to Use the Subscription Management Tool for SUSE Linux Enterprise 11 Manage Updates and Compliance

2 C o n t e n t s Contents...2 Overview of the Subscription Management Tool for SUSE Linux Enterprise 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

3 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

4 O v e r v i e w o f t h e S u b s c r i p t i o n M a n a g e m e n t T o o l f o r S U S E L i n u x E n t e r p r i s e 1 1 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

5 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

6 I n s t a l l a t i o n a n d B a s i c C o n f i g u r a t i o n 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 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 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

7 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 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 ( Click Next. Figure 5: Subscription Management Tool Configuration Wizard-2/2 7

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

9 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 apache2- example-pages) prevents the clients from accessing the repository key files of the Subscription Management Tool. Handling this is described in section 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 smt-client 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

10 4. Reload the Subscription Management Tool service with the command: # rcsmt restart Now your Subscription Management Tool server is configured and ready to use. M a n a g i n g t h e S u b s c r i p t i o n M a n a g e m e n t T o o l 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 or # smt help subcommand 10

11 or # smt -h subcommand # smt-subcommand -h 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 client delete-registrations job list-products list-registrations mirror List available repositories, enable/disable them for mirroring and staging Shows information about registered clients Delete one or more registrations Manage client jobs List all products in Subscription Management Tool database List all hosts registered with this Subscription Management Tool server 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 register Download products, targets, repositories, subscriptions and registration information from Novell Customer Center to the Subscription Management Tool database Register all currently unregistered and updated clients with Novell Customer Center report setup-custom-repos staging support Generate extensive reports of the smt data Enable and disable non-nu catalogs to be mirrored Manage patch filters and testing/production repositories 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

12 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 name 'corp_updates' \ --exturl ' \ --description 'Updates for my applications' For information on which repositories to enable for mirroring see TID 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 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 /etc/smt.d/novell.com-smt /etc/smt.d/smt-cron.conf /srv/www/htdocs/smt.crt Description Cron file - symlinked into /etc/cron.d/ Parameters for cron jobs (7.2.2 in manual) Server certificate copied from /etc/ssl/certs/yast-ca.pem /srv/www/htdocs/repo/$rce/ /srv/www/htdocs/repo/full/ /srv/www/htdocs/repo/keys/ /srv/www/htdocs/repo/rpmmd/ /srv/www/htdocs/repo/testing/ /srv/www/htdocs/repo/tools/clientsetup4smt.sh Production (Novell) repositories Download directory for staged repositories Directory for repo signing keys Custom repositories Testing repositories Script to import SMT server certificate and adapt 12

13 /etc/suseregister.conf /usr/sbin/smt* /usr/share/doc/manual/sle-smt_en/ /usr/share/doc/packages/smt/ /var/spool/smt-support/ /var/log/smt/ Command line utilities to manage SMT Online documentation Very useful other documentation Incoming supportconfig archives 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. C o n f i g u r i n g C l i e n t s t o U s e t h e S u b s c r i p t i o n M a n a g e m e n t T o o l 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. and if the server certificate is in a non-default location, it can also be 13

14 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: 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= 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 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 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: <!-- replace $section-name depending on SLE version --> <!-- SLE 10 : customer_center --> <!-- SLE 11 : suse_register --> <$section-name> <do_registration config:type="boolean">true</do_registration> <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 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

15 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 ) 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. J o b s a n d C l i e n t S t a t u s M o n i t o r i n g 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 ]]> </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

16 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 Eject Patchstatus Reboot Softwarepush Update Run commands on the client Open, close or toggle the CD tray of the client Report the status of installed patches Reboot the client (requires smt-client ) Install packages Install available updates (requires smt-client ) 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

17 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

18 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 fc9a5b43ead542fba9cedb7b00d 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

19 S t a g i n g 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

20 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

21 # 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. C o m p l i a n c e M o n i t o r i n g w i t h S u b s c r i p t i o n M a n a g e m e n t T o o l R e p o r t s 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 configuration options are located in the [REPORT] part of /etc/smt.conf and explained in section 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

22 # 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. S u p p o r t c o n f i g P r o x y 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

23 M i r r o r i n g U p d a t e s f o r R e d H a t E n t e r p r i s e L i n u x Customers who have purchased SUSE Linux Enterprise Server Subscription with Expanded Support (see 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 How to update Red Hat Enterprise Linux with SMT 11. M i r r o r i n g S U S E L i n u x E n t e r p r i s e 9 U p d a t e s 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 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

24 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., 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. C u s t o m R e p o s i t o r i e s 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 /-/ 11 i SUSE_SLED /-/ 11 i SUSE_SLED /-/ 11 i SUSE_SLED /-/ 11 i SUSE_SLED /-/ 11 x86_64-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 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

25 On SUSE Linux Enterprise 10 the product IDs can be a bit confusing: # smt-list-products grep SUSE-Linux-Enterprise-Server-SP2 grep x SUSE-Linux-Enterprise-Server-SP2 10 x86_ SUSE-Linux-Enterprise-Server-SP2 10 x86_64 online SUSE-Linux-Enterprise-Server-SP2-migration 10 x86_64-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 i product SUSE_SLES_SP 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 productid 839 \ --name "My_own_SLES10_SP2_APP_UPDATES" \ --exturl " \ --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