Article

Contents:

• Introduction
• Problem
• System Environment
• Solution
  

  Cleaning the ZENworks Package Repository

  Configuring a non EXT3 File System as a Package Repository

  Promoting a Secondary Server to a Primary Server

Introduction

A ZENworks Linux Management server can be installed on the supported Server platform with EXT3 file system. The package repositories for the ZENworks Linux Management server can be hosted either on a local device or a remote device that has the EXT3 file system.

In ZENworks Linux Management, the path to the package repository on the Primary Server and the Secondary Servers is /var/opt/novell/zenworks/pkg-repo/ . The rpm packages imported as content of any package bundle are stored in the packages directory under the package-repository path on the ZENworks Server. The package directory organizes the packages based on the hexadecimal 4 char directory names such as '30d1'. These directories contain zero or more rpm packages which are imported from any package bundle. This package repository on the ZENworks Primary Server is also replicated to all the ZENworks Secondary Servers during the content replication action.

Problem

The EXT3 file system can have only 32000 subdirectories under a given directory. Therefore, on a ZENworks Linux Management server installed on an EXT3 file system, the package management backend cannot create more than 32000 subdirectories under the /var/opt/novell/zenworks/pkg-repo/packages directory, for storing the packages that are imported through the package bundles.

System Environment

The solution explained in this document is applicable for the ZENworks 7.2 Linux Management and the ZENworks 7.3 Linux Management servers.

Note: This solution might not be required for package repositories on other file systems such as Reiserfs and XFS. This is because these file systems do not have a limitation of 32000 subdirectories. However, you can still perform the package repository cleaning process to free the disk space on ZENworks Server.

Solution

You can overcome the limitation of the EXT3 file system by doing any of the following:

• Cleaning the ZENworks Package Repository
• Configuring a non-EXT3 file system as Package Repository
• Promoting a Secondary Server to a Primary Server

Cleaning the ZENworks Package Repository

Cleaning the package repository is only a temporary solution to overcome the directories limitation of the EXT3 file system. This depends on the number of bundle versions and packages that are associated to bundles or are dangling in the repository.

By cleaning the Package Repository, you can reduce the risk of reaching the 32000 limitation for package directories on the ZENworks Server. The directories that are created within the /var/opt/novell/zenworks/pkg-repo/packages directory on the ZLM Server are also reduced. You can, therefore, import more packages into the package repository through bundles.

To clean the local package repository, it is recommended to do the following:

• Delete the obsolete package bundles that are already deployed and installed on the managed devices and might not be needed for future deployments.
• Delete the unused package bundles that are not assigned to any devices, or are used only as part of outdated catalogs . For example, you can delete the bundles that are related to some old updates, patches, applications etc, assuming that these bundles will no longer be used for future deployments .
• Delete those bundle versions from ZCC that might not be deployable any more.

On deleting the package bundles, the packages are orphaned in the package repository if they are not associated with any other bundles. After removing the bundles or bundle versions, you can clean up the Orphan RPM packages from the ZLM Server's package repository by using either the ZCC or zlman commands.

To clean up the orphan RPM packages by using ZENworks Control Center:

• In ZENworks Control Center, click Tools.
• In the Management Zone Settings panel, click the Package List category to list all the imported packages in the repository.
• Search and delete all the Orphaned RPM Packages from the package repository.

By using the zlman commands, you can automate the task of removing the orphan RPM packages in batches by running the following shell script on the ZLM Server. The script purges many package files from the package repository thus freeing the disk space and creating empty directories.

>>>>>>>>>>>>Orphan-Packages-Deletion-Script>>>>>>>>>>>>

#Script to delete all orphaned packages in batch, by using zlman dp on ZLM 7.2 or ZLM7.3 
#Change the sleep interval(eg 15 sec) in this script based on the count of packages to be deleted at a time
# set the ~/.zlmanrc file to Username and Password for ZENworks Server Administrator
# Suggested to try with 100 or less as count for Orphan-packages-batch-delete-count option as Server handles 
# if the script cannot cleanup all the  packages in first run.
# If needed JVM heap memory settings can be increased for zlman script
# The orphan packages and deleted packages are logged  in  /tmp/orphan-pkgids.log and /tmp/orphan-deleted.log

 function usage()
 {
   echo  USAGE:
   echo  "$0  <Orphan-packages-batch-delete-count> "
   exit 1
 }

 if [ $#  -lt 1 ] || [ $# -gt 1 ]; then
  usage
 else  
 

 orphan_id_log="/tmp/orphan-pkgids.log"
 orphan_deleted_log="/tmp/orphan-deleted.log"
 packages_to_del=$1
 total_count=0
 while true ; 
 do
 count=0  
 zlman lp --orphan |  cut -d'|' -f1 -s | grep ^[0-9] > /tmp/orphaned.log
 cat /tmp/orphaned.log >> $orphan_id_log ; echo ""  
 total_count=`wc -l /tmp/orphaned.log | cut -f1 -d " "` 
 echo " zlman lp --orphan command completed. Total Orphan Packages found for deletion: $total_count . Log file /tmp/orphan-pkgids.log "  
 if [ $total_count -eq 0 ]; then 
 echo  " No more Orphan Packages present in package-repository for deletion "; echo "" ;
 rm -f /tmp/orphaned.log
 exit  1 
 fi
 while [ $total_count -gt $count ]  ;
  do 
    pkgid_list=""
    count=`expr $count + $packages_to_del`
    for i in `cat /tmp/orphaned.log | head -n $count | tail -n $packages_to_del`;
    do
      pkgid_list="$pkgid_list $i"
    done 
     zlman dp  $pkgid_list 
     if [ $? -ne 0 ] ; then 
       echo " zlman dp command failed to delete some orphaned packages. To delete them, you can run the script again with lesser package delete count " ;
       rm -f /tmp/orphaned.log
     exit 1
     fi
     echo " Orphan Packages  permanently deleted from package-repository  : $packages_to_del"
     echo " Packages successfully deleted:  $pkgid_list" >>  $orphan_deleted_log 
     echo " ------------------------ `date`-------------------------- " >> $orphan_deleted_log
   sleep 15;
  done
 done 
fi 

Empty directories are created within the /var/opt/novell/zenworks/pkg-repo/packages/ directory. To clean up these empty directories on the ZENworks Primary Server that has the local package repository, run the following shell script on the ZLM Server:

>>>>>>>>>>>>Package -Empty-Directories - Cleanup-Script>>>>>>>>>>>>

cd  /var/opt/novell/zenworks/pkg-repo/packages/
logfile="/var/opt/novell/log/zenworks/pkg-repo-cleanup.log"
echo "-----------------------------------------------"  > $logfile
echo -n "Total packages repository directories  count at `date` is :  "  >> $logfile
find -depth -type d  -exec  ls -ld  {} \;  | wc -l  >> $logfile
#list all empty  directories
echo "Logging the packages empty directories under the path : `pwd`"
echo -n "Total empty directories found under packages are : " >>  $logfile
find -depth -type d -empty -exec  ls -ld  {} \;  | wc -l  >> $logfile
find -depth -type d -empty -exec echo {} \;  >> $logfile
#delete empty directory under packages
echo "Deleting the packages empty directories under the path : `pwd` "
/usr/bin/perl -MFile::Find -e"finddepth(sub{rmdir},'.')"
#alternative way to delete empty directories
#find -depth -type d -empty -exec rmdir {} \
echo -n "Total packages directories count  after deleting  is :  "  >> $logfile
find -depth -type d  -exec  ls -ld  {} \;  | wc -l  >> $logfile

The /var/opt/novell/log/zenworks/pkg-repo-cleanup.log file that is created lists the package directories available before and after cleaning the package repository.

Configuring a non EXT3 File System as a Package Repository

You can configure a non EXT3 file system as a ZENworks Package Repository by adding an additional disk or a new volume, and then migrate the package repository data from the EXT3 file system to the new file system. The new file system can be a Reiserfs or XFS file system.

To configure and migrate the package repository data:

1. Stop the ZLM services on the ZENworks Primary Server or Secondary Servers, if any.
2. Add a new volume to the device that has the ZLM Server.
3. Create a device partition with the new file system.
4. Mount this file system to another directory located on the server and create packages directory under it.
   For example, mount the file system partition to the /data directory on the server and create /data/packages directory.
5. Copy the content under the /var/opt/novell/zenworks/pkg-repo/packages directory to the new /data/packages directory.
   For example, find /var/opt/novell/zenworks/pkg-repo/packages -depth -type d -exec cp -rp {} "/data/packages" \;
6. Copy the remaining directories under the path /var/opt/novell/zenworks/pkg-repo/ to /data directory on the new file system.
7. Backup or delete the /var/opt/novell/zenworks/pkg-repo/ directory and create a new /var/opt/novell/zenworks/pkg-repo/ directory, retaining the original attributes and ownership of this directory.
8. Unmount the /data directory that you created in Step 4.
9. Mount the new file system again to the /var/opt/novell/zenworks/pkg-repo/ directory.
   Note: You must see /var/opt/novell/zenworks/pkg-repo/packages directory with all its subdirectories as it existed in the old file system. Ensure that the permissions and ownership attributes for the /var/opt/novell/zenworks/pkg-repo/ directory and its subdirectories are preserved on the new file system.
10. Add the /var/opt/novell/zenworks/pkg-repo entry in the /etc/fstab file so that it is automatically mounted on device start.
11. Restart the ZLM services on the ZENworks Primary Server and Secondary Servers, if any.

Promoting a Secondary Server to a Primary Server

You can choose the disaster recovery process to promote a Secondary Server to a Primary Server only if no Secondary Servers with the EXT3 file system exist in the Management Zone.

Do the following:

1. Add a new Secondary Server with a non EXT3 file system to the existing Primary Server.
2. Perform the Content Replication of the ZENworks Package Repository to this new Secondary Server.
3. Follow the Disaster Recovery steps to promote the Secondary Server to the new Primary Server. For more information, see ZENworks 7.3 Linux Management Troubleshooting Guide (http://www.novell.com/documentation/zlm73/lm7trouble/data/bxxln70.html).
4. Detach the old Primary Server from the Management Zone and allow the new Primary Server to manage all the devices that are registered to it.

Acknowledgments

Reviewer: Shubhashree D - Technical writer, Novell, Inc.