search cancel

Patch Management for Linux var directory and Yum Cache disk usage.

book

Article ID: 175837

calendar_today

Updated On:

Products

Patch Management Solution for Linux

Issue/Introduction

Patch Management for Linux /var directory and Yum Cache disk usage.
This article contains observations, test results and recommendations on the Yum Cache and /var sizing for Patch Management.

Environment

Patch Management for Linux 8.1 and 8.5

Resolution

System owners must make sure that the /var directory on Linux systems has sufficient storage space for the operation of OS utilities (yum, syslog, etc) and installed applications (Symantec Management Agent, Plugins, etc).

1) Based on RHN KB article(https://access.redhat.com/solutions/974373) we are expecting that size of yum cache should be at least 5GB.

Following samples were collected during testing:
 - size of yum cache is ~1.5 GB ( for 6.X systems) and ~2.5 ( for 7.X systems) if we imported all available channels for current subscription.
 -Each main channel for 6.x Linux takes up to ~ 400 MB, for 7.x  - up to ~700 MB ( potentially 1000). Of course, all depends from count of packages in the channel.
 -No packages are created in the Yum Cache during a Symantec Patch Management policy installation. Yum cache stores only metadata information for channels.

2) Customers can use official yum commands to clean the cache, and should specify the custom Patch Management repository smf-yum-repository.conf

For example:
sudo yum -c /opt/altiris/notification/swuagent/var/repo/smf-yum-repository.conf clean all

Note that the above command will not remove everything always. This is per designed behavior of yum utility.
In some cases, customers can apply a more drastic mitigation and remove the cache directory directly:

rm -rf /var/cache/yum

Also, when users accidentally run Yum via regular user (forgot sudo), yum will create a user-cache. Following command will delete that too:

rm -rf /var/tmp/yum-*

Note: If customers cleanup data from the yum cache (or delete the cache folder), most of the files will be restored during next policy installation again.
So huge size directories in yum cache don't mean that something is broken. Caches are not broken. They're just large, this is internal implementation of the yum utility.

General advice to customers:

a. Make sure sufficient space is allocated to the /var directory.
b. Remove or clean up the yum cache directory periodically.
c. Address known issues from Red Hat:

We have observed customers reporting this behavior to Red Hat, that yum cleanup does not work correctly in some cases. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1357083
Note: In some environments we have observed when deleted metadata files were still present in yum cache.
Note: Red Hat metadata files contains checksum in the name, So name of metadata file will be changed after modify list of packages in the channel.

3) Size of Patch Management metadata is comparable with native channels from Red Hat subscription.
Difference is not greater than 10%.
Note: yum stores primary metadata file additionally(gzipped) from Patch management repository.

Size of channels in yum repository for example:
- 'rhel-6-server-rpms' from subscription - 318MB
- Patch channel 'Red Hat Enterprise Linux 6 Server (RPMs)' - 376 MB