Last time we visited Yellow Dog Updater Modified (YUM) in 2007 we created a repository and also configured access...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
to repositories in RHEL5. In this, our second look at YUM – we'll configure YUM by using its main configuration file, yum.conf, which resides in /etc. We'll also take you through some basic yum commands that should be a part of your repertoire.
For any yum newbie's, a quick definition and a look at history. YUM is a package manager (an installer and remover) for RPM systems. It is tailor made to update groups of machines without having to update each specific RPM. The software locates and obtains the correct RPM packages from repositories, freeing you from having to manually find and install new applications and/or updates. The beauty of YUM is in its simplicity. You can use a single command to update all system software. Way back when, RHEL4 used to use up2date as its package manager – RHEL5 uses YUM, based on version 3. Upd2date is actually used as a wrapper around YUM in RHEL5. The product was developed by Seth Vidal (who now works for Red Hat) and a group of volunteer programmers and coded in Python. It is now up to version 3.2.22.
The file itself is made up of two sections. The first is the main section and the second is the repository section. You have a choice to put your repositories in this file or in separate files named file.repo. You can have more than one repository in one configuration file but there can be only one main section. Here is an example of a yum config file.
main] cachedir=/var/cache/yum keepcache=0 debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800 timeout=10 [myexamplerepo] name=RHEL 5 $releasever - $basearch baseurl=http://local/path/to/myyum/repository/ enabled=1
Let's describe some important fields:
Cachedir: The directory where yum stores its cache and database files.
Keepcache: There are two choices here, 0 and 1. 1 informs yum to keep the cache of headers and packages after a successful install. The default is 1.
Tolerant: There are two choices here, 0 and 1. Setting this as 1 allows yum to be tolerant of errors on the command line. The default is 0.
Grpcheck: There are two choices here, 0 and 1. 1 enables GPG checking, which provides for GPG signature checking on packages on all repositories. This includes local package installation.
Metadata_expire: This is the time in seconds – after which the metadata will expire.
Timeout: This is the number of seconds that one would wait for a connection prior to timing out.
Exactarch: There are two choices here, 0 and 1. 1 tells YUM to update only the architectures of installed packages. For example, if you have this enabled you won't be able to install an i386 package to update an i686 package.
Obsoletes: This effects updates only and enables the processing logic of YUM. It's particularly useful when doing distribution level upgrades.
The repository section has the information required to find packages during package installation, updating and dependency installations. The mandatory field descriptions are as follows:
ID: a unique single word string which is the identifier of the repository.
Name: The string that describes the repository.
Baseurl: The url where the actual repository is housed.
Some optional fields include;
gpgcheck, gpgkey, exclude and
include. The exclude and include fields are similar to the ones used in the main section of the file, but apply only to a specific repository.
If you are shy about manually editing config files, than I would be extremely careful before doing so. Better to use some GUI software to help you configure YUM, than mess up a currently running YUM-based system. If you are going to edit these files manually, make sure you first play around with them in a test environment and/or have good backups. It just takes five seconds to issue the following command:
# cp /etc/yum.conf /etc/yum.conf.old
Please use this command prior to manually editing this file.
YUM has dozens of commands that are part of its system. Try to learn some of the key commands that you'll be using routinely. In this section we'll discuss some of these commands.
# yum list
This lists out all packages in all repositories which are installed on the system. There are a variety of options with this command. One option is:
# yum list installed
This is similar to running an
rpm –qa, which breaks down a list of all installed packages. By default
yum list without any options will list all packages in all the repositories, and all the packages installed on your system. (Note: "yum list all" and "yum list" give the same output.)
# yum info
Displays information about any package – either installed or available.
# yum search
Allows you to search for information from metadata available, about packages.
# yum clean
The yum clean command allows you to clean up the cached files of metadata and packages which YUM uses during its normal operations. This will clear up a lot of disk space.
# yum groupinfo groupname
This provides you with detailed information for each group including description, mandatory, default and optional packages.
We've focused on using YUM on RHEL, but it should also be noted that SLES10.1 has added support for YUM repositories in YaST. Many other distributions also provide YUM support – though some do not, so if YUM is really important to you, you should check your documentation carefully. Finally, as those of you who have already worked with YUM realize, it has a command line utility only. If you like GUI software there are also several GUI utilities which interface with YUM, including pup, pirut (the default Fedora GUI as of version 5), and Yum Extender. YUM may not be rocket science to use, but you will need to take some time to learn it properly. Like any other new software, the more time you spend learning it and playing with it in a sandbox the less time you will spend in having to fix it later.
ABOUT THE AUTHOR: Ken Milberg is a systems consultant with two decades of experience working with Unix and Linux systems. He is a SearchEnterpriseLinux.com Ask the Experts advisor and columnist.