ZENworks Linux Management 7.2 IR1 Lab Setup Guide for Patching SLES

Prepared By:
Cameron Seader – cseader@novell.com – NTS PSE
Nathan Conger – nconger@novell.com – TSS OPS
Bob Reynolds – rjreynolds@novell.com – TSS SRM

Updated on 22 April 08. Requested by popularity I have finally gotten around to updating this document here to add steps for the md5sum’s of the RPM’s and the gpg signing of the YaST repository in Appendix A.

Please have a look at this document if you are running SUSE Linux Enterprise 10 and are using ZLM as your patch management solution. This document can help you greatly diminish the time it takes to setting up this environment and be well on your way to patching your SUSE Linux Enterprise 10 environment.

Executive Summary

ZENworks Linux Management (ZLM) is a powerful systems management tool designed to ease the management of a mixed enterprise linux environment. Focused on supporting today’s management needs for linux, ZLM offers the industry’s best software delivery and patching tools. In addition to software delivery and patching, ZLM offers policy driven automation that ensures a well managed linux environment.

This guide is a supplement to the official ZENworks Linux Management (ZLM) documentation. It is intended to quickly walk through the common setup steps associated with managing a SUSE Linux Enterprise (SLE) environment mixed with SLES version 9 and SLES version 10. Although there are many features available in version ZLM 7.2 defined here, this guide will focus on setting up a lab managed environment for software delivery and patching.

Preparations – Start Here

Before starting, it is important to have an understanding of what needs to be accomplished to have a successful installation of ZLM. Please review these links prior to starting the installation steps below.

• Read the What’s New section
• Build and prepare a designated primary server and at least one additional device for testing by meeting System Requirements
  Suggestions: Primary server should be SLES10 SP1 with /var an LVM partition
• Obtain the ZENworks Linux Management 7.2 IR 1 ISOs
• Get access to latest Hot Patches – send an email to zen.feedback@novell.com with the subject of “ZLM7.2 Hot Patch”. An email will be returned with the steps to use.

Click to view.

Installation Steps

This guide will now walk through the basic installation steps necessary to building a primary ZLM server as well as updating and storing SLES patches on the server that are available from Novell. This installation uses a local PostgreSQL database that is installed during installation. The steps to build the first linux management server for patching and software deliver are:

1. Install ZLM Primary Server
2. Apply latest patches to ZLM Primary Server
3. Distro load and Mirror load from Novell
4. ZLM Agent installation to a SLES device
5. Deploy patches and software
6. Appendix A: Creating a YaST Repository
7. Appendix B: Troubleshooting
8. Appendix C: Additional Resources

Install ZLM Primary Server

Assuming hardware requirements for CPU, Memory, and Disk space have been met, installation of the Primary ZLM server is very straightforward. Below are the summarized installation steps. For detailed installation steps please refer to this section of the documentation.

1. Mount ZLM iso or insert ZLM CD into drive and type ./zlm-install
2. Enter “y” to install ZENworks
3. Review Software License Agreement and at end, enter “y” to accept agreement
4. If asked to update packages, enter “y”
5. When installation is complete, enter “y” to run configuration script zlm-config.
6. Answer the following questions –
   1. Is this the first server in your system? – enter “y”
   2. Enter a unique management zone name – for testing, suggest “zone1”
   3. Enter an Administrator password
   4. Retype Administrator password
   5. Do you want ZENworks to install and setup a local PostgreSQL database? – enter “y”
7. Verify installation has completed
   1. Confirm ZENworks services have started – /opt/novell/ZENworks/bin/zlm-config –status
   2. Access the ZENworks Control Center – https://ZENworks_Primary_Server_IPAddress

Apply latest patches to ZLM Primary Server

Please follow the steps in the email that is returned from zen.feedback@novell.com. Currently, Hot Patch 1 requires the installation of a new RPM called novell-ZENworks-zlm-release. It is suggested to use this command in a terminal after getting connected to the Hot Patch channel – rug in novell-ZENworks-zlm-release

Distro load and Mirror load from Novell

Once the Primary server has been built, the next step is loading the base distribution ISOs into ZLM for dependency resolution as well as mirror updates and patches from Novell Update Server. The update sources will vary depending on distributions that are being managed. Because of the diverse platform support offered by ZLM, each distribution requires a mirroring config file that can be used to get patches and updates from Novell Update Server. Follow the steps below to load base distributions and mirror updates from Novell Update Servers for SLES9, SLE10, and SLE10 SP1. It is important there is an estimated 3-5 GB of disk space per distribution and patches available for /var/opt/novell/ZENworks. Best practice is make this directory a LVM partition allowing for this partition to grow in size when needed.

Distro Load

1. To make loading base distributions easier, download the “zlmload” package found at http://www.novell.com/communities/node/2612/zlmload and install using the command:

   rpm -ihv zlmload*.rpm
   

2. Once the package is installed, there are two ways to run the command. You can run the command to load the RPM’s from a directory or from ISO images.
   1. Command to load RPM’s from a directory:

      		zlmload -P  -d 
      

      admin_pass	ZLM Administrator Password
      directory	Path to directory that contains the media media

      Administrators will need to mount the installation media or a remote installation source (HTTP/NFS/FTP) to a local directory to mirror the packages.

   2. Command to load RPM’s from ISO images.

      zlmload -P  -I  -d  -a  -b 
      
      

      admin_pass	ZLM Administrator Password
      ISO_image_location	Location where you have saved your ISO images for the Base distribution.
      ISO_mount_point	Location where you would like the ISO images mounted. (i.e. /mnt)
      target	The Target Platform (i.e. sles-10-i586)
      bundle_name	The name of the bundle it will put all of the RPM’s in (i.e. SLES-10-Distro)

      When running the command to load from ISO images you need to make sure all of your ISO’s are in the same folder for the distribution you are loading at the time.

SLES9 Mirroring

1. Use the template below to create a mirroring config file specific to your environment. Copy the xml contents and paste them to a file named “sles9_mirror.xml”. Save the file in “/etc/opt/novell/ZENworks”.
2. Validate the syntax of the mirror config file by running:

   zlmmirror cv /etc/opt/novell/ZENworks/sles9_mirror.xml
   
   

3. To run the first mirroring manually run the command below. The first mirroring of SLES 9 updates will likely take 2-3 days (based on line speed and the number of architectures downloaded). Subsequent mirroring (usually performed weekly or monthly) is incremental and should only take a matter minutes.

   zlmmirror m –c /etc/opt/novell/ZENworks/sles9_mirror.xml
   
   

<!-- >>>>>>>>>>>>>>> Begin SLES 9 Mirror  Config Template <<<<<<<<<<<<<<<<< -->
<ZLMMirrorConf>
   <Session>
      <RemoteServer>
         <Base>https://you.novell.com/update</Base>
         <Type>YAST</Type>
         <User>NCC_User</User>
         <Password>NCC_Password</Password>
      </RemoteServer>
      <LocalServer>
         <Base></Base>
         <Type>zlm</Type>
         <User>administrator</User>
         <Password>password</Password>
      </LocalServer>
      <Catalog>
         <Name>sles-9-i586</Name>
         <LocalName>sles-9-i586-patches</LocalName>
         <Folder>sles-9-i586/patches</Folder>
         <Target>sles-9-i586</Target>
      </Catalog>
      <Catalog>
         <Name>sles-9-x86_64</Name>
         <LocalName>sles-9-x86_64-patches</LocalName>
         <Folder>sles-9-x86_64/patches</Folder>
         <Target>sles-9-x86_64</Target>
      </Catalog>
   </Session>
</ZLMMirrorConf>
-- >>>>>>>>>>>>>>> End SLES 9 Mirror Config Template <<<<<<<<<<<<<<<<< -->

The following table describes the mandatory and optional elements in each section of the template that is needed to customize the mirror config file to fit your environment:

zlmmirror slc -c /etc/opt/novell/ZENworks/sles9_mirror.xml

Note: There are a number of ways that a folder hierarchy can be be created to organize both patches and software. An example of the folder organization the SLES9 template uses once you click on Bundles in ZCC:
-sles-9-i586
   |— patches
   |— packages

-sles-9-x86_64
   |— patches
   |— packages
Note1: If you are executing the command remotely (ssh, etc.), consider using the nohup or screen command to allow the process to complete in the event of lost connectivity.

nohup zlmmirror m –c /etc/opt/novell/ZENworks/sles9_mirror.xml > /tmp/nohup.log &

Click to view.

Once it is executing you can tail the log with:

tail -f /tmp/nohup.log

Click to view.

SLES10 and SLES10 SP1 Mirroring

1. Use the template below to create a mirroring config file specific to your environment. Copy the xml contents and paste them to a file named “sles10_mirror.xml”. Save the file in “/etc/opt/novell/ZENworks”.
2. Validate the syntax of the mirror config file by running:

   zlmmirror cv /etc/opt/novell/ZENworks/sles10_mirror.xml
   
   

3. To run the first mirroring manually run the command below. The first mirroring of SLES 9 updates will likely take 2-3 days (based on line speed and the number of architectures downloaded). Subsequent mirroring (usually performed weekly or monthly) is incremental and should only take a matter minutes.

   zlmmirror m –c /etc/opt/novell/ZENworks/sles10_mirror.xml
   
   

   <!-- >>>>>>>>>>>>>>> Begin SLES 10 and SLES10 SP1 Mirror Config Template <<<<<<<<<<<<<<<<< -->
   <ZLMMirrorConf>
      <Session>
         <RemoteServer>
            <Base>https://nu.novell.com/repo</Base>
            <Type>nu</Type>
            <User>Mirroring_User</User>
            <Password>Mirroring_Password</Password>
         </RemoteServer>
         <LocalServer>
            <Type>zlm</Type>
            <User>administrator</User>
            <Password>password</Password>
         </LocalServer>
         <Catalog>
            <Name>SLES10-Updates</Name>
            <Folder>sles-10-i586/patches</Folder>
            <Target>sles-10-i586</Target>
         </Catalog>
    	<Catalog>
            <Name>SLES10-SP1-Updates</Name>
            <Folder>sles-10-i586/SP1/patches</Folder>
            <Target>sles-10-i586</Target>
         </Catalog>
         <Catalog>
            <Name>SLES10-Updates</Name>
            <Folder>sles-10-x86_64/patches</Folder>
            <Target>sles-10-x86_64</Target>
         </Catalog>
         <Catalog>
            <Name>SLES10-SP1-Updates</Name>
            <Folder>sles-10-x86_64/SP1/patches</Folder>
            <Target>sles-10-x86_64</Target>
         </Catalog>
      </Session>
   </ZLMMirrorConf>
   
   

   RemoteServer	Change the User and Password elements to match your login credentials at the Novell Customer Center (http://www.novell.com/center). Typically, the contents of /etc/zmd/deviceid and /etc/zmd/secret (from a machine that has been registered with the Novell Customer Center) are used as values for the User and Password elements respectively. Use the following TID to allow the use of your Novell Customer Center (NCC) credentials directly: http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3612166&sliceId=SAL_Public&dialogID=46095292&stateId=0%200%2046099851 You can also search for for TID#3612166 under knowledgebase at: http://www.novell.com/support
   LocalServer	Change the Password element to match your login credentials to the local ZLM system.
   Catalog	Include the number of catalog sections to match the architectures that you would like to mirror. In the example above, both i586 (x86) and x86_64 are included. Power (ppc) and Itanium (ia64) can also be mirrored by adding additional catalog sections. To see a listing of the available catalogs and target platforms (you have access to) on the remote server, run: zlmmirror slc -c /etc/opt/novell/ZENworks/sles10_mirror.xml Change the Name, LocalName, Folder and Target elements to match the architecture. Name: Name of the catalog on the remote server LocalName: Name of the to-be-created local catalog Target: Name of the target platform for which the catalog is intended Folder: Folder on the ZLM system where the updates will be placed; can be viewed under the Bundles tab in the ZLM web console

   Note: There are a number of ways that a folder hierarchy can be be created to organize both patches and software. An example of the folder organization the SLES10 template uses once you click on Bundles in ZCC:
   -sles-10-i586
      |— SP1
         |— packages
      |— patches
      |— packages

   -sles-10-x86_64
      |— SP1
         |— packages
      |— patches
      |— packages

   Note1: If you are executing the command remotely (ssh, etc.), consider using the nohup or screen command to allow the process to complete in the event of lost connectivity.

   nohup zlmmirror m –c /etc/opt/novell/ZENworks/sles10_mirror.xml > /tmp/nohup.log &
   
   

   

   Click to view.

   Once it is executing you can tail the log with:

   tail -f /tmp/nohup.log
   
   

   

   Click to view.

Automating the Mirror process

Once the initial mirroring has completed, leverage the cron subsystem to regulary execute the zlmmirror commands. A specific crontab file for mirroring is provided below. It’s recommended to mirror updates weekly, however the mirroring interval can be tailored to your organizational requirements.

Create a file called zlm-mirroring in /etc/cron.d. Edit the file and insert the following lines:

0 1 * * sun    root    /opt/novell/ZENworks/bin/zlmmirror m --force-nevra -c /etc/opt/novell/ZENworks/sles9_mirror.xml
0 2 * * sun    root    /opt/novell/ZENworks/bin/zlmmirror m --force-nevra -c /etc/opt/novell/ZENworks/sles10_mirror.xml

ZLM Agent installation to a SLES device

There are a few methods in which to deploy the ZLM Agent to make your linux devices managed. Some of the methods that are explained may not fit into your environment because of network/security limitations or the lack of an linux installation server. This guide recommends you to setup a SuSE Installation Server. Please refer to the documentation for SUSE Linux Enterprise Server at http://www.novell.com/documentation/sles10/sles_admin/data/sec_deployment_remoteinst_instserver.html .
Three methods for agent installation:

1. Manual installation
2. Using Autoyast for new machine builds *
3. Using Yast for existing machines *
   * Note – this option is based on the use of an Yast Repository. Please see “Appendix A – Creating a Yast Repository”

Manual installation

Manual installations are fairly easy; however, it does not scale when addressing many machines. To do a manual installation, please visit the online documentation at – http://www.novell.com/documentation/zlm72/lm7install/data/bx5ait1.html
Note: By creating custom scripts, using a manual install could be used to install agent to many existing machines.

Using AutoYaST for new machine builds

Using the installation scripting ability called AutoYaST found in SLES allows for complete control and customization when installing a new server. It is through this process that the ZENworks Linux Management agent can be scripted as part of the install. The process for auto installation requires the creation of a configuration file and varies between SLES9 and SLES10.

SLES9 AutoYaST – Creating autoinst.xml
General direction on how to create an auto installation control file for SLES 9 can be found at:
–   /usr/share/doc/packages/autoyast2/html/index.html
–   http://www.novell.com/documentation/sles9/pdfdoc/sles_9_admin_guide/sles_9_admin_guide.pdf
(this document is 69mb)

SLES9 AutoYaST– Adding ZLM Agent installation
Accomplishing this for SLES9 is much of a HACK job at best on the Installation Source and so I have left that part out in favor of a script I have written to save time and effort. All that is needed to incorporate the installation of the ZLM Agent during an AutoYaST install is to copy the xml below and insert it into your autoinst.xml file. I have created this script which is enclosed in the scripts tag of the xml. I explain the variables of the script in the table after. There are a few things in which you will need to modify as part of the variables in order for it to fit into your environment.

<scripts>
      <post-scripts config:type="list">
	<script>
          <filename>ZLM_Agent_Setup</filename>
          <network_needed config:type="boolean">true</network_needed>
          <interpreter>shell</interpreter>
          <source><![CDATA[#!/bin/bash
		## Install ZLM Agent ##

		## Variables ##
		#ZLM Agent RPM location, which can be HTTP or FTP protocols
	rpmloc="http://Install_Server/install/novell/ZLM721Agent/sles9/RPMS/i586/"
		#local download location
		downloc="/root/ZLM721Agent"
		#Registration Key
		regkey="regkey"
		#ZLM Server URI
		zlmuri="https://zlm_server_dnsname"
		#Install Minus X packages
		noX="true"
		Xfiles="*zmd-rmagent* *tightvnc* *x11vnc* *zmgweb* *zmd-gconfpolicyenforcers* *client-gui* *gtk-sharp*"
		#Install Minus Imaging packages
		noImg=”true”
		Imgfiles=”*zmd-imgagent* *zislnx* *zmgweb* *zmglibs*”
		#Install Minus OEM packages (For Dell PowerEdge Servers)
		noOEM="true"
		OEMfiles="*zmd-oem*"

		## Begin Script ##
		#make directory for download location
		mkdir $downloc
		#Get the RPM's from the ZLM Agent RPM location
		wget -r -l1 -nd -A "*.rpm" -e robots=off -P $downloc $rpmloc
		#Install the RPM's
		if [ $noOEM = true ]; then
		cd $downloc
		rm $OEMfiles
		fi

		if [ $noImg = true ]; then
		cd $downloc
		rm $Imgfiles
		fi

		if [ $noX = true ]; then
		cd $downloc
		rm $Xfiles
		rpm -i $downloc/*
		else
		rpm -i $downloc/*
		fi

		##Register with ZLM Server
		#Start zmd
		/etc/init.d/novell-zmd start
		#Register
		/opt/novell/ZENworks/bin/rug sa -k $regkey $zlmuri

		]]></source>
        	</script>
      </post-scripts>
</scripts>

Another thing that needs to be changed in the autoinst.xml file is the “software” tag. Your softare tag will change whether or not you have enabled X packages. The table below shows you which software tag to use depending on the option you select for “noX” variable.

<software>
      <addons config:type="list">
        <addon>Base-System</addon>
        <addon>YaST2</addon>
      </addons>
      <base>Minimal</base>
      <packages config:type="list">
        <package>wget</package>
        <package>xinetd</package>
        <package>python</package>
        <package>python-xml</package>
        <package>glib2</package>
      </packages>
</software>

<software>
	  <addons config:type="list">
		<addon>Base-System</addon>
		<addon>YaST2</addon>
	  </addons>
	  <base>Minimal</base>
	  <packages config:type="list">
		<package>wget</package>
		<package>xinetd</package>
		<package>python</package>
		<package>gconf2</package>
		<package>glib2</package>
		<package>orbit2</package>
		<package>python-xml</package>
	  </packages>
</software>

As you can see from the table there are a few more packages that you need to make sure are installed if your going to include the packages that depend on X being installed for the ZLM Agent.

If you plan on using noImg=”false” and noOEM=”false” then you will need to use the same Software Tag that is used for noX=”false” since these packages also require the extra X packages.

Now you are ready to install SLES9 with the ZLM Agent via AutoYaST.

SLES10 AutoYaST – Creating autoinst.xml
General direction on how to create an auto installation control file for SLES 10 can be found at:
–   http://www.novell.com/documentation/sles10/sles_admin/data/sec_deployment_autoinst_simple.html

SLES10 AutoYaST – Adding ZLM Agent installation
Accomplishing this in SLES10 is a bit easier since AutoYaST has been updated and includes new features such as the Software Add-on functionality. We will be taking advantage of this functionality in AutoYaST. All that we will need to do is edit the autoinst.xml file using the four steps below.

1. We will start with adding in the “signature handling” tag since we did not sign any of our ZLM Agent YaST repository. This is needed so that we can basically skip the checking for signature information, otherwise AutoYaST would fail and not continue since checking is automatically turned on. Below is the signature handling tag I used. You can copy this one and it will work fine in SLES10, just make sure its inside the “general” tag.

   <signature-handling>
   	<accept_unsigned_file         config:type="boolean">true</accept_unsigned_file>
   	<accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum>
   	<accept_verification_failed   config:type="boolean">true</accept_verification_failed>
   	<accept_unknown_gpg_key       config:type="boolean">true</accept_unknown_gpg_key>
   	<import_gpg_key config:type="boolean">true</import_gpg_key>
       	<accept_non_trusted_gpg_key config:type="boolean">true</accept_non_trusted_gpg_key>
   </signature-handling>
   
   

2. We will setup the “add on” tag which basically points to the installation source location of the ZLM Agent. Below is the “add on” tag I used. You can copy this one for your autoinst.xml file.

   <add-on>
    <add_on_products config:type="list">
      <listentry>
        <media_url>http://Inst_Server/install/novell/ZLM721Agent/sles10/</media_url>
        <product>ZLM Agent</product>
        <product_dir>/</product_dir>
      </listentry>
    </add_on_products>
   <add-on>
   
   

3. We will setup the “software” tag. You most likely have a “software” tag already defined. You need to pay particular attention to the “pattern” tag listed inside of it. You can copy this one for your autoinst.xml file.

   <software>
       <packages config:type="list">
       </packages>
       <patterns config:type="list">
         <pattern>base</pattern>
         <pattern>ZLM_Agent_noX</pattern>
       </patterns>
   </software>
   
   

   Notice the “pattern” tag. I have added in the pattern ZLM_Agent_noX, which corresponds to one of the pattern files copied into the AutoYast repository. There are 4 patterns to choose from and they are explained in the table below. Choose the pattern that fits your environment and drop that into your “pattern” tag.

   Pattern	Description
   ZLM_Agent_X	ZLM Agent including all of the X related packages.
   ZLM_Agent_noX	ZLM Agent excluding all of the X related packages. Great if your running from runlevel 3.
   ZLM_Agent_Img	Auto Selects ZLM_Agent_X pattern because of dependencies and also installs all Agent pieces for Imaging.
   ZLM_Agent_OEM	Auto Selects ZLM_Agent_noX pattern because of dependencies and also installs all Agent pieces for Dell PowerEdge Servers.

4. We will need to register the ZLM Agent with the ZLM Server. We can accomplish this with a small script in AutoYaST. You can copy this “script” tag into the autoinst.xml. The Variables are explained in the table following.

   <scripts>
         <post-scripts config:type="list">
   	<script>
             <filename>ZLM_Agent_Setup</filename>
             <network_needed config:type="boolean">true</network_needed>
             <interpreter>shell</interpreter>
             <source><![CDATA[#!/bin/bash
   		##Register with ZLM Server
   		##Variables
   		#ZLM Server URI
   		zlmuri="https://zlm_server_dnsname"
   		#Registration Key
   		regkey="regkey"
   
   		#Start zmd
   		/etc/init.d/novell-zmd start
   
   		#Register
   		/opt/novell/ZENworks/bin/rug sa -k $regkey $zlmuri
   	 ]]></source>
         </script>
         </post-scripts>
   </scripts>
   
   

   Variables Defined

   zlmuri	ZLM Server URI – i.e. https://ZLM_Server_dns_name
   regkey	Registration Key Created in the ZENworks Control Center

Now you are ready to install SLES10 with the ZLM Agent via AutoYaST

Using YaST for existing machines

There may be instances in your environment where the system is already installed and you would like to deploy the ZLM Agent to the platform. In this Section I will explain how to accomplish this using YaST.

SLES9 – Installing ZLM Agent using YaST
Accomplishing this in SLES9 is fairly easy, but since we didn’t create any package selections we will just have to select each package individually. The table below shows you which packages to select for each different selection. Some of the Imaging RPM’s require the X packages, so it will resolve those dependencies for you.

1. Setup the ZLM Agent YaST repository as an Installation Source. Open up YaST > Software > Change Source of Installation
   

   Click to view.

2. You will now see the Software Source Media you have defined currently. Click on the Add Button and select HTTP (or whatever protocol used to access installation server).
   

   Click to view.

   Fill in the dialog with the correct information for your environment. Once it is all filled in you can click OK and then FINISH.

   

   Click to view.

3. Now click on YaST > Software > Install and Remove Software
   

   Click to view.

4. Click on Filter and select Search. In the Search box type in novell-ZENworks. Notice in the box to the right you will see all of the ZLM Agent Packages. Use the table of packages from the beginning of this section to choose the packages for your setup and then click Accept
5. Close YaST and move onto the section “Register the Agent with the ZLM Server”.

SLES10 – Installing ZLM Agent using YaST

Accomplishing this in SLES10 is easy using the new Add On functionality.

1. First click on YaST > Software > Add On Product
   

   Click to view.

2. After clicking Add-On Product you will get the window below. Click on Specify URL and then Click Next.
   

   Click to view.

3. Fill in the URL of the ZLM Agent YaST repository for SLES10. Once complete click OK.
   

   Click to view.

   After you click OK then it will start adding the Add-On as an installation Source. You will get a few failures. These are normal since we did not sign or provide checksum information for our patterns. So click Yes to the messages like the ones below.

   

   Click to view.

   

   Click to view.

4. Once you get through clicking Yes about 12 times, you will then see the software management window open. Click on Filter and select Patterns. You can see at the bottom that you have some new patterns under the Add-on section. Click on the Pattern that you would like to use and then click Accept.
   

   Click to view.

5. Once the ZLM agent is installed you can close YaST and move onto the section “Register the Agent with the ZLM Server”.

Deploy patches and software

The first step to deploying patches or software to a managed device is to make sure the device is registered. Once the device is registered, patching and software delivery can be handled in a few different ways. This document will guide you through the 2 most common scenarios used:

• Scenario 1: You can deploy updates by assigning bundles to your devices or groups of devices.
• Scenario 2: You can deploy updates using a policy that gets executed remotely.

Both of these scenarios will be explained so that you can choose which is better for your environment.

Register the Agent with the ZLM Server

Registering the Agent is simple and is done the same way on both SLES9 and SLES10. The process that I will show here will be utilizing a registration key in order to register your device. This registration key can be created using the ZENworks Control Center. This process is explained in the Novell Documentation. Registration keys can be very helpful in Device registration since you can tell the device to get placed into a specific Server Group or Folder when it is registered. You can have multiple keys to register different devices for differing groups etc. I find it pretty common to have several different keys setup to accommodate various groups in an organization and also differing types of servers (i.e. web servers, database servers).
In order to manually register a device with the ZLM Server if it was not done automatically through AutoYaST or some other mass deployment method then you can issue the following command to do so.

rug sa -k registration_key https://ZLM_Server_address

NOTE: It is highly recommended to use DNS names

Deploy patch and software Scenario 1

Deploying updates by assigning bundles to your devices or groups of devices can be easy to accomplish.

1. Select device or group to test – Login to the ZCC (ZENworks Control Center). Once we are logged in we can click on the Devices Tab where we will have two folders. One is for Servers and the other is for Workstations. We will be dealing with Servers so click on the Servers Folder Link. You will now be able to see the ZENworks Server. For ease of management, let’s create a Server Group called test and add the ZENworks Server.
   1. When at Devices > Servers, click on New, Server Group
   2. Follow the wizard to name the server group test and add the ZENworks primary server
   3. Open the test server group
      

      Click to view.

2. Assign Bundles – Notice the Bundles section at the bottom. We can add Bundles to this group of servers from here. Click the Bundle’s Add link. After clicking Add you will use the Assign Bundle Wizard.
   

   Click to view.

   1. Click the Add Link to select the bundle you would like to add to the Server Group. You will now get a separate window like the screen shot below allowing you to navigate to the bundle you will use
   2. Navigate to the Bundle you want to add and click it to Select it, and then click OK. I will add the SLES10-Updates-bundle since I know that the server in this group is SLES10, and that it will need the updates. Once you click OK then you will be back to the wizard.
      

      Click to view.

      

      Click to view.

   3. After clicking Next, we can select the option to “Deploy and install immediately” which will attempt to refresh every device in the device group and Deploy the bundle. If you have a change request that occurs at some specific day or hour, then you can schedule it to be deployed at that time. Also, you can perform a test run to see if any problems may be identified. This will basically run through the motions but not install anything. So go ahead and click next after you have chosen your schedule. I am going to Deploy and Install Immediately.
      

      Click to view.

   4. After clicking Next, you will see the summary of your bundle assignment. Click Finish. You will now have a Bundle listed in the Bundles Section.
      The instant you clicked on Finish, the ZLM server started sending requests to each server in your server group to refresh and deploy the bundle that was just assigned. Be patient as it may take some time depending on how many servers you have in your Server Group. You can watch the event log of each server or the event log of the bundle you just deployed in the ZCC and you will start seeing messages saying that the bundle has been deployed successfully. It will most likely be easier to watch the event log of the bundle because it will show you messages for each device it tried to deploy.
      

      Click to view.

Deploy patch and software Scenario 2

Deploying updates through a policy can be accomplished; however, it is dependent upon your devices having catalogs created, assigned, and the devices are subscribed to those catalogs. Make sure that you have either an “updates” catalog or custom created catalog assigned to your device group or specific device. This should have been accomplished using the mirroring process defined earlier.

You can assign a catalog to your Device or Device Group through the Devices Tab in the ZCC. If you are just doing updates through a policy I would recommend assigning two catalogs to your Devices; The Base Packages Catalog and the Updates Catalog. Follow the next steps to help you assign the Catalogs to your device.

1. Select device or group to test – Login to the ZCC and click on the Devices Tab. If you don’t have a Server Group then you can assign the Catalogs to a single device. I would recommend creating a Server Group similar to that found in Scenario 1. I will refer to a Server Group called test that I will be using in this example. Click on your Server Group or Device in order to see its Summary page. You will see in the right column there is a section called Catalogs.
   

   Click to view.

2. Assign Catalogs – Click on the Add link to add a catalog to the server group or device. You will now see a wizard start up.
   

   Click to view.

   1. Click on Add link to browse and select the catalogs you would like to assign. Notice in the screen shot below I have selected one for SLES9 packages and SLES9 patches. Of course, if you are assigning to SLES10 Devices or a Group of SLES10 devices then you would add in the SLES10 packages and SLES10 patches Catalogs.
      

      Click to view.

   2. Click OK and then Next. This will bring you to the Bundle Options of Assigning Catalog. This screen is similar to the screen found in Scenario 1 Step 2c. The defaults here should be sufficient. If you would like to read more about these options, see this link from the online documentation http://www.novell.com/documentation/zlm72/lm7admin/data/bx4ss7s.html .
   3. Click Next when you are ready and you will see a summary page with all of the options you have selected. Click Finish and then OK to return to the Summary page of the device or device group in which you were assigning catalogs.
3. Subscribe devices to catalogs – You can either log into each device individually and issue the command in a terminal

   rug sub catalog_name
   
   

   OR, you can assign a Remote Execute Policy to your device group that will automatically subscribe you to the catalogs available. I find this option easier and saves lots of time. Follow these next steps to create a Remote Execute Policy that will subscribe you to all available catalogs.

   1. Click on the Policies Tab in ZCC and then click the New > Policy > Remote Execute Policy link to start the Create New Policy wizard. Click Next.
      

      Click to view.

   2. In Step 2: Policy Name of the wizard, give your Policy a name. I called mine Catalog-Subscription. Click Next when you’re ready.
      

      Click to view.

   3. In Step 3 : Remote Execute Policy in the wizard, select “Define your own script” for the “Script to run” field. Copy the script below into the “Script content” field.

      #!/bin/sh
      ## Variables ##
      CHANNELS=""
      CHECKSTAT=""
      ZMDSTART="/etc/init.d/zmd start"
      
      function rug_config ()
      {
      ## Pausing for 1 second ##
              echo "Sleeping for 1 Second"
              sleep 1
      
      ## Subscribing Client to available Channels ##
              echo "Subscribing Client to the available Channels."
              echo "Channels=$CHANNELS"
      
              for i in $CHANNELS; do
                  /usr/bin/rug sub $i
              done
      }
      
      CHANNELS=`/usr/bin/rug ca | cut -d"|" -f2`
      LENGTH=$(($(echo "$CHANNELS" | wc -l) - 3))
      CHANNELS=`echo "$CHANNELS" | tail -n $LENGTH`
      
      CHECKSTAT=`checkproc zmd && echo "ok" || echo "no_process"`
      
      ## Check status of zmd daemon and continue rug configuration ##
      case $CHECKSTAT in
        ( ok ) rug_config
              STATUS=0
          ;;
        ( no_process ) $ZMDSTART && rug_config
              STATUS=0
          ;;
        ( * )  STATUS=1
      esac
      echo -e "exit code $STATUS\n"
      exit $STATUS
      
      

      

      Click to view.

   4. Once you have copied the script into the “Script content” field then you can click Next. In Step 4: Summary of the wizard you will see a Summary page where you can either click Next to continue and assign the policy to a device or device group or click Finish to save and go back to the Policies Tab page. Click Next so that we can assign this policy to our device group called test.
   5. Step 5: Policy Assignments of the wizard allows us to add devices or device groups. Use the Add link to add our test server group and click OK, then click Next.
      

      Click to view.

   6. In Step 6: Policy Schedule of the wizard, keep the Policy Schedule set to “Relative to Refresh” so that when the devices refresh they will be subscribed to their catalogs. Click Next to continue to Step 7: Policy Groups. We are not assigning this policy to any Policy Groups. Click Next. For more information on policy groups, visit – http://www.novell.com/documentation/zlm72/lm7admin/data/bxd47tf.html
      

      Click to view.

   7. In Step 8: Finish of the wizard, you will see a summary page where you can click Finish and OK to be brought back to the Policies tab. The devices you assigned this policy to will now get subscribed to their catalogs when the device refreshes. Now that we have catalogs created, assigned, and devices are subscribed to catalogs, we can continue on creating a policy that will allow us to update our devices.
4. Create update policy – Create a new policy that will be enforced on each managed device at an appropriate schedule so that the device receives patches, updates, or additional packages.
   1. Click on the Policies Tab in ZCC and then click the New > Policy > Remote Execute Policy link to start the Create New Policy wizard. Click Next.
      

      Click to view.

   2. In Step 2: Policy Name of the wizard, give your Policy a name. I called mine Update-test. Click Next when you are ready.
      

      Click to view.

   3. In Step 3 : Remote Execute Policy in the wizard, select “Define your own script” for the “Script to run” field. Copy the script below into the “Script content” field.

      #!/bin/sh
      /usr/bin/rug up -y
      
      

      

      Click to view.

      NOTE: Here are some links to other scripts you may want to use in your environment that I have created in separate cool solutions documents.
      SLE10: Apply Updates Without New Kernel Updates Being Applied
      http://www.novell.com/coolsolutions/feature/18984.html

      OES: Apply Patches Without New Kernel Patches Being Applied
      http://www.novell.com/coolsolutions/feature/18985.html

      Using ZENworks Linux Management 7.2 to Change the Root Password on All Managed Systems

   4. Once you have copied the script into the “Script content” field then you can click Next. In Step 4: Summary of the wizard you will see a Summary page where you can either click Next to continue and assign the policy to a device or device group or click Finish to save and go back to the Policies Tab page. Click Next so that we can assign this policy to our device group called test.
   5. Step 5: Policy Assignments of the wizard allows us to add devices or device groups. Use the Add link to add our test server group and click OK, then click Next. (See Step 3e for graphic)
   6. In Step 6: Policy Schedule of the wizard, keep the default set to “Relative to Refresh” (see Step 3f for graphic). This is ok because it will only execute once on the first refresh and not on any of the subsequent refreshes. You can think of it as a one time execution. There will be; however, times you may want to schedule it in advance because of a change request or you may not be around to execute it. For this reason, you would set the schedule to be Date Specific so that you can execute on a date and time in the future. Click Next to continue to Step 7: Policy Groups. We are not assigning this policy to any Policy Groups. Click Next. For more information on policy groups, visit – http://www.novell.com/documentation/zlm72/lm7admin/data/bxd47tf.html
   7. In Step 8: Finish of the wizard, you will see a summary page where you can click Finish and OK to be brought back to the Policies tab. The devices you assigned this policy to will now get subscribed to their catalogs when the device refreshes. Now that we have catalogs created, assigned, and devices are subscribed to catalogs, we can continue on creating a policy that will allow us to update our devices.

Appendix A: Creating a YaST Repository

The creation of a YaST repository for the deployment of the ZLM Agent has a few advantages. It can be used as Add On software in AutoYaST for an automated deployment or as an Add On in YaST’s Software Management module.
Creating a YaST repository for the the ZLM Agent.

1. Create a directory within the Installation repository that will contain your new YaST repository. Replace Installation_Repo with the path to your Installation repository. You could name the directory what you want, but for the case of this document I have called it ZLM721Agent which refers best to the current release which is ZLM 7.2 IR1.

   mkdir /Installation_repo/ZLM721Agent
   
   

2. Change directory to the directory you just created

   cd /Installation_repo/ZLM721Agent
   
   

3. Create directories for each platform you plan to manage.

   mkdir sles10 sles9
   
   

4. Change directory to one of the platform directories just created ( The steps below this point will be the same for every platform directory, so don’t forget to duplicate the steps beyond this point for each platform directory.)

   cd /Installation_repo/ZLM721Agent/sles10
   
   

5. Create another directory called media.1

   mkdir media.1
   
   

6. Create another directory called RPMS with architecture subdirectories

   mkdir -p RPMS/i586 RPMS/x86_64 RPMS/noarch
   
   

7. Create a file called media under the directory media.1 The media file contains a medium description consisting of the following components:
   

   <Author> <Date of Creation (YYYYMMDDhhmmss)> <Number of media>

   The following is the media file I used:

   Novell 20070907104055 1

   Note: An easy way to generate the Date of Creation would be the command

   date +%Y%m%d%H%M%S
   
   

8. Make sure the ZLM Agent ISO is mounted.

   mount -o loop ZLM72_Agent_with_IR1.iso /mnt
   
   

9. Copy the RPM’s to the ZLM Agent YaST repository for SLES10 ( replace Installation_repo with the path to your installation repository. )

   cp /mnt/data/packages/client/sles-10-i586/*i586* /Installation_repo/ZLM721Agent/sles10/RPMS/i586
   cp /mnt/data/packages/client/sles-10-x86_64/*x86_64* /Installation_repo/ZLM721Agent/sles10/RPMS/x86_64
   cp /mnt/data/packages/client/sles-10-i586/*noarch* /Installation_repo/ZLM721Agent/sles10/RPMS/noarch
   cp /mnt/data/packages/imaging/sles-10-i586/* /Installation_repo/ZLM721Agent/sles10/RPMS/i586
   cp /mnt/data/packages/imaging/sles-10-x86_64/* /Installation_repo/ZLM721Agent/sles10/RPMS/x86_64
   cp /mnt/data/packages/runtime-deps/sles-10-i586/* /Installation_repo/ZLM721Agent/sles10/RPMS/i586
   cp /mnt/data/packages/runtime-deps/sles-10-x86_64/* /Installation_repo/ZLM721Agent/sles10/RPMS/x86_64
   
   

10. Copy the RPM’s to the ZLM Agent YaST repository for SLES9 (replace Installation_repo with the path to your installation repository. The SLES9 repository will need mono, so we will copy those as well. )

    cp /mnt/data/packages/client/sles-9-i586/* /Installation_repo/ZLM721Agent/sles9/RPMS/i586
    cp /mnt/data/packages/client/sles-9-x86_64/* /Installation_repo/ZLM721Agent/sles9/RPMS/x86_64
    cp /mnt/data/packages/runtime-deps/sles-9-i586/* /Installation_repo/ZLM721Agent/sles9/RPMS/i586
    cp /mnt/data/packages/runtime-deps/sles-9-x86_64/* /Installation_repo/ZLM721Agent/sles9/RPMS/x86_64
    cp /mnt/data/packages/imaging/sles-9-i586/* /Installation_repo/ZLM721Agent/sles9/RPMS/i586
    cp /mnt/data/packages/imaging/sles-9-x86_64/* /Installation_repo/ZLM721Agent/sles9/RPMS/x86_64
    cp /mnt/data/packages/mono/sles-9-i586/* /Installation_repo/ZLM721Agent/sles9/RPMS/i586
    cp /mnt/data/packages/mono/sles-9-x86_64/* /Installation_repo/ZLM721Agent/sles9/RPMS/x86_64
    
    

11. Create md5 checksum’s of all your rpm’s in each slesXX/RPMS/ directory.

    cd /Installation_repo/ZLM721Agent/sles9/RPMS/i586
    md5sum * >MD5SUMS
    cd /Installation_repo/ZLM721Agent/sles9/RPMS/x86_64
    md5sum * >MD5SUMS
    cd /Installation_repo/ZLM721Agent/sles10/RPMS/i586
    md5sum * >MD5SUMS
    cd /Installation_repo/ZLM721Agent/sles10/RPMS/x86_64
    md5sum * >MD5SUMS
    cd /Installation_repo/ZLM721Agent/sles10/RPMS/noarch
    md5sum * >MD5SUMS
    
    

    If you have installed the package Inst-source-utilsthe tool create_md5sums should be helpful as well.

12. Create a file called content. The content file contains a medium content description consisting of the following components:
    

    Key Product VERSION VENDOR LABEL ARCH. DEFAULTBASE DESCRDIR DATADIR

    Content Product Name Product Version Product Vendor Source destination to be used in YaST Supported architectures for the base architecture Default base architecture The directory containing the package descriptions The directory containing the packages

    The following is the content file I used:

    PRODUCT ZLM Agent VERSION 7.2.1 VENDOR Novell LABEL ZLM 7.2.1 Agent ARCH.x86_64 x86_64 i586 noarch ARCH.i586 i586 noarch DEFAULTBASE i586 DESCRDIR setup/descr DATADIR RPMS

13. Generate the setup/descr/* directory and meta data content with the command below. (When you run this command make sure your present working directory (pwd) states you are at the root of the source you created i.e. /Installation_repo/ZLM721Agent/sles9 . Note: each platform directory is a source root.)

    cd /Installation_repo/ZLM721Agent/sles9
    create_package_descr -d RPMS/
    cd /Installation_repo/ZLM721Agent/sles10
    create_package_descr -d RPMS/
    
    

    If you don’t have the command create_package_descr, you must install the rpm autoyast2-utils for SLES9 or inst-source-utils-2007 for SLES10. If you are running your Installation Server on SLES9 then I would suggest downloading a newer version of create_package_descr from the developers site – http://www.suse.de/~ug/ in the Tools Section.

14. Generate our Pattern files so that this ZLM Agent YaST repository can be used as an Add-on during an AutoYaST installation in SLES10. In the interest of time I have chosen to point you to a tarball that has the patterns you will need. After you download the tarball here you can then follow the commands below to extract in the right place. (If you will be setting this up for Architectures that are out of the scope of this document you can refer to the references at the end of this document on how to create your patterns.)

    mv /location_of_tarball/patterns.tgz /Installation_repo/ZLM721Agent/sles10/setup/descr
    cd /Installation_repo/ZLM721Agent/sles10/setup/descr
    tar -xzvf patterns.tgz
    
    

    You will now see several .pat files and also a patterns file.

15. Create the SHA1 META keys for all files in the DESCRDIR. To create the digest, use sha1sum. (DESCRDIR in this case is setup/descr) Once the SHA1 META keys are created then we can copy those into our content file we have created in step 12.

    cd /Installation_Repo/ZLM721Agent/sles9/DESCRDIR
    sha1sum * >>SHA1SUM
    cd /Installation_Repo/ZLM721Agent/sles10/DESCRDIR
    sha1sum * >>SHA1SUM
    
    

16. Copy the contents of each SHA1SUM in to its respective platform content file.
    The following is the content file I used which shows the SHA1 META keys added:

    PRODUCT ZLM Agent VERSION 7.2.1 VENDOR Novell LABEL ZLM 7.2.1 Agent ARCH.x86_64 x86_64 i586 noarch ARCH.i586 i586 noarch DEFAULTBASE i586 DESCRDIR setup/descr DATADIR RPMS META SHA1 5781c86958322b668c90b537de62e4e0d3fdabce packages META SHA1 376a710114c15adeb741d5657ced0fcca737d357 packages.DU META SHA1 2d43c34c806d846228a8f25e3ad10b99a8b53b12 packages.en META SHA1 9b45acfc090438d53a4dcd92e33c9e7ebd4e5775 patterns META SHA1 fb10332ad17a872dc227fb98a9f4402ee2332ff1 ZLM_Agent_Img-10-7.2.1.i586.pat META SHA1 ed6791d9aa963b1884b589420c760c60951e665b ZLM_Agent_Img-10-7.2.1.x86_64.pat META SHA1 e03c4f996a4efb6bd796c1cc194c9974eda88a68 ZLM_Agent_noX-10-7.2.1.i586.pat META SHA1 56b81f9e2c6193e8eae9d2aecedae5cd1756b14c ZLM_Agent_noX-10-7.2.1.x86_64.pat META SHA1 e2bb3358624d956558feef5b32f099b258d6279b ZLM_Agent_OEM-10-7.2.1.i586.pat META SHA1 b011ae49cf7194b894a9b47a73f8519656bf370b ZLM_Agent_OEM-10-7.2.1.x86_64.pat META SHA1 ff85dc0dae6fd06e3f2fc6a250d0a81ed744fe19 ZLM_Agent_X-10-7.2.1.i586.pat META SHA1 09d275eedc2f904196a42fdc6c8f8003a7f9dab3 ZLM_Agent_X-10-7.2.1.x86_64.pat

17. Generate your gpg key to sign the YaST repository with if you don’t already have one.

    gpg -q --gen-key
    
    

18. Get the value of your key and store it in a variable called MY_KEY.

    MY_KEY=$( gpg --list-secret-keys |grep "^sec"|sed -e 's/.*\///;s/ .*//g;' | tail -n 1 )
    
    

19. For each platform you will need to sign the content file and export the key.

    cd /Installation_Repo/ZLM721Agent/sles9
    gpg --detach-sign -u “$MY_KEY” -a content
    gpg --export -a -u “$MY_KEY” > content.key
    gpg --export -a -u “$MY_KEY” > gpg-pubkey-$MY_KEY.asc
    cd /Installation_Repo/ZLM721Agent/sles10
    gpg --detach-sign -u “$MY_KEY” -a content
    gpg --export -a -u “$MY_KEY” > content.key
    gpg --export -a -u “$MY_KEY” > gpg-pubkey-$MY_KEY.asc
    
    

20. Update your content file with the sha1sum of the gpg-pubkey-$MY_KEY.asc file.

    cd /Installation_Repo/ZLM721Agent/sles9
    sha1sum gpg-pubkey-$MY_KEY.asc (copy output and paste into content file with the KEY SHA1 prefix)
    cd /Installation_Repo/ZLM721Agent/sles10
    sha1sum gpg-pubkey-$MY_KEY.asc (copy output and paste into content file with the KEY SHA1 prefix)
    
    

    The following shows the content file with the included KEY line for the sha1 of the keys in the repository:

    PRODUCT ZLM Agent VERSION 7.2.1 VENDOR Novell LABEL ZLM 7.2.1 Agent ARCH.x86_64 x86_64 i586 noarch ARCH.i586 i586 noarch DEFAULTBASE i586 DESCRDIR setup/descr DATADIR RPMS META SHA1 5781c86958322b668c90b537de62e4e0d3fdabce packages META SHA1 376a710114c15adeb741d5657ced0fcca737d357 packages.DU META SHA1 2d43c34c806d846228a8f25e3ad10b99a8b53b12 packages.en META SHA1 9b45acfc090438d53a4dcd92e33c9e7ebd4e5775 patterns META SHA1 fb10332ad17a872dc227fb98a9f4402ee2332ff1 ZLM_Agent_Img-10-7.2.1.i586.pat META SHA1 ed6791d9aa963b1884b589420c760c60951e665b ZLM_Agent_Img-10-7.2.1.x86_64.pat META SHA1 e03c4f996a4efb6bd796c1cc194c9974eda88a68 ZLM_Agent_noX-10-7.2.1.i586.pat META SHA1 56b81f9e2c6193e8eae9d2aecedae5cd1756b14c ZLM_Agent_noX-10-7.2.1.x86_64.pat META SHA1 e2bb3358624d956558feef5b32f099b258d6279b ZLM_Agent_OEM-10-7.2.1.i586.pat META SHA1 b011ae49cf7194b894a9b47a73f8519656bf370b ZLM_Agent_OEM-10-7.2.1.x86_64.pat META SHA1 ff85dc0dae6fd06e3f2fc6a250d0a81ed744fe19 ZLM_Agent_X-10-7.2.1.i586.pat META SHA1 09d275eedc2f904196a42fdc6c8f8003a7f9dab3 ZLM_Agent_X-10-7.2.1.x86_64.pat KEY SHA1 fa2c602df4c96de65d5c7a1176f3daa50c6287fe gpg-pubkey-B504EC0F.asc

21. Generate directory.yast files which have the directory contents. We can easily create this from the following commands.

    cd /Installation_repo/ZLM721Agent/sles9
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles10
    ls -A1 > directory.yast
    
    

    For SLES9 you will also need to add in the following directory.yast files. Execute the following commands.

    cd /Installation_repo/ZLM721Agent/sles9/media.1
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles9/setup
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles9/setup/descr
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles9/RPMS
    ls -A1 > directory.yast
    
    

    For SLES10 you will also need to add in the following directory.yast files. Execute the following commands.

    cd /Installation_repo/ZLM721Agent/sles10/media.1
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles10/setup
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles10/setup/descr
    ls -A1 > directory.yast
    cd /Installation_repo/ZLM721Agent/sles10/RPMS
    ls -A1 > directory.yast
    
    

    That concludes the creation of the ZLM Agent YaST repository. Below is a Tree view of the ZLM Agent YaST repository we just created. (of course your RPMS directory will contain some RPM’s).

    SLES9 ZLM Agent YaST repository

    SLES10 ZLM Agent YaST repository

    |– content           |– directory.yast           |– media.1           |   |– directory.yast           |   |– media           |           |– setup           |   |– directory.yast           |   |– descr           |      |– directory.yast           |      |– packages           |      |– packages.DU           |      |– packages.en           |           |– RPMS              |– directory.yast              |– i586              |– x86_64

    |– content           |– directory.yast           |– media.1           |   |– directory.yast           |   |– media           |           |– setup           |   |–directory.yast           |   |– descr           |      |– directory.yast           |      |– packages           |      |– packages.DU           |      |– packages.en           |           |– RPMS              |– directory.yast              |– i586              |– x86_64              |– noarch

Appendix B: Troubleshooting

When your environment starts to grow there are some troubleshooting steps you can use to determine problems and help keep your system health good.

Viewing the new tasks in the Database Queue will ensure that your requests will go through the system smoothly and not get hung on a task that has been sitting there for quite awhile.

Issue the following command to view the tasks in the Queue:

zlman ql | grep -i new

If there are a lot then you might want to issue the command:

zlman ql | grep -i new | wc -l

Then watch it to make sure the number is decreasing. Also you can check the date of the task and if it is for sure old then we will need to flush it out of the Queue.

You can also view the tasks that are currently being processed, by issuing the command below.

zlman ql | grep -i prog

You might have some out in this Queue as well with old dates that may need to be flushed out as well.

Now to answer the question “How do I Flush the Queues?”. Issue the commands below in order to flush the Queues.

zlman qf S – Flush the queue of tasks that have Succeeded.
zlman qf F – Flush the queue of tasks that have Failed.
zlman qf I – Flush the queue of Tasks that are In-Progress. You would only issue this if you saw some tasks that were old and everything else has processes through this queue.
zlman qf without any switches will flush all queues.

It may be a good idea to setup the first two commands in a cron job and have it emailed to you so that you can see whats in the queue every day. This will help you keep the system healthy.

Appendix C: Additional Resources

• ZLM 7.2 Documentation Web Site
• Scenarios-1, great for seeing how other things are done.
• Scenarios-2, also great for seeing how things are done.
• Troubleshooting
• Please download the pdf version of this document here

Enjoy!