Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

YUM via Proxy

The Yellow dog Updater, Modified (YUM) was written at the Duke University department of Physics and is currently being maintained by Seth Vidal now works for Red Hat) and Michael Stenner, both of Duke University, as part of Duke University's Linux@DUKE project. Yum is a rewrite in Python of its predecessor tool, Yellowdog Updater (YUP). The latter was originally written and maintained by Dan Burcaw, Bryan Stillwell, Stephen Edie, and Troy Bengegerdes of Yellowdog Linux (an RPM-based Linux distribution that runs on Macintoshes ).  YUM is a command line utility. There are several graphical frontends to yum. Among them pup, pirut, and yumex.

RHEL5 uses YUM as the default method for updating and installing RPM packages. It replaced older up2date. Automatic software update can be done with either the yum-updatesd or the yum-updateonboot packages. Yum's "intelligence" in performing updates is superior to most competitors (only smart comes close).

Yum's repository system is becoming the standard for RPM-based Linux distroibutions. Besides Red Hat 5.1, and SUSE Linux 10.1 adds support for Yum repositories in YaST. openSUSE Build Repository is  Yum-based.  Yum can do several things that yast cannot:

• install packages with the same name but for different architectures (which could be important for x86_64 users who sometimes can only install x86_32 packages).
• can check for the gpg keys.
• yum can handle mirror lists.

Yum (currently) consists of two tools; yum-arch, which is used to construct an (ftp or http) repository on a suitable server, and yum, the general-purpose client. Once a yum repository is prepared (a simple process detailed below) any client permitted to access the repository can install, update, or remove one or more rpm-based packages from the repository. If there is a proxy between client and server you need to configure client configuration file so that it knows about the proxy, The keyword is "proxy". You do not need quotes around the URL.

proxy=http://192.168.3.1:8080/

In case proxy requires authentication you need to provide those details too:

# The account details for yum connections
proxy_username=yum-user
proxy_password=qwerty

YUM also understands standard environment variable HTTP_PROXY. In this case you need to provide those variable either in /etc/profile or in particular user .bash_profile. The settings below enable yum to use the proxy server mycache.mydomain.com, connecting to port 8081.

# The Web proxy server used by this account
http_proxy="http://mycache.mydomain.com:8081"
export http_proxy

http_proxy="http://yum-user:yum_user_password@mycache.mydomain.com:3128"

The alternative way to provide access to YUM repositories on a local network is to use NFS.  You can  export  (rw,no_root_squash) /var/cache/yum to all the LAN clients. This will speed up operations with the remote repositories as NFS is faster then HTTP protocol.  Best of all, there is no setup.

Yum Repositories

Yum client encapsulates several tools that can display the list of installed and available for installation rpms, extract and publish information from the rpm headers based on keywords or globs, find packages that provide particular files. Yum is therefore of a higher level. more convenient tool  them rpm.

yum can be used to synchronize already tested updates for multipole Linux servers or desktops. It this case it can  be run from a night cron script

In a typical repository, there are several thousand packages, with a lot of headers. About 700 packages are actually installed on a typical linux system. However, the archive component of each package, which contains the actual binaries and libraries and documentation installed, is much larger -- the complete rpm is thus generally two to four orders of magnitude larger than the header. For example, the header for Open Office (a fairly large package) total about 100 kilobytes in size. The rpm itself, on the other hand, is about 30 megabytes in size. The header can be reliably delivered in a tiny fraction of a second over most networks; the rpm itself requires seconds to be delivered over 100Mbit/sec LAN.  Early automated update tools either required a locally mounted repository directory in order to be able to access all of the headers quickly (local disk access even from a relatively slow CD-ROM drive, being fast enough to deliver the rpm's in a timely way so that their headers could be extracted and parsed) or required that each linked rpm be sent in its entirety over a network to an updating client from the repository just so it could read the header. One was locally fast but required a large commitment of local disk resources (in addition to creating a new problem, that of keeping all the local copies of a master repository synchronized). The other was very slow. Both were also network resource intensive.

This is the fundamental problem that yum solves for you. Yum splits off the headers on the repository side (which is the job of its only repository-side tool, yum-arch). The headers themselves are thus available to be downloaded separately, and quickly, to the yum client, where they are typically cached semi-permanently in a small footprint in /var/cache/yum/serverid (recall that serverid is a label for a single repository that might be mirrored on several servers and available on a fallback basis from several URL's). Yum clients also cache (space permitting or according to the requirements and invocation schema selected by the system's administrator) rpm's when they are downloaded for an actual install or update, giving a yum client the best of both the options above -- a local disk image of (just the relevant part of) the repository that is automatically and transparently managed and rapid access to just the headers.

An actual download of all the headers associated with packages found on your system occurs the first time a yum client is invoked and thereafter it adds to or updates the cached headers (and downloads and caches the required rpm's) only if the repository has more recent versions or if the user has deliberately invoke yum's "clean" command to empty all its caches. All of yum's dependency resolution then proceeds from these cached header files, and if for any reason the install or update requires an rpm already in the cache to be reinstalled, it is immediately available.

However, it is probably better in many cases to use rsync or other tools to provide a local mirror of the repository in question and use yum's fallback capability to accomplish the same thing. This gives one a much better capability of standing alone should update access go away on the "server" of the yum cache NFS exported across a LAN.

With the header information (only) handy on high-speed local media, the standard tools used to maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies, determine if it is safe to proceed, what additional packages need to be installed, and so forth. Note well that yum is designed (by a highly experienced systems administrator, Seth Vidal, with the help of all the other highly experienced systems administrators on the yum list) to be safe. It will generally not proceed if it encounters a dependency loop, a package conflict, or a revision number conflict.

If yum finds that everything is good and the package can be safely installed, removed, or updated, it can either be invoked in such a way that it does so automatically with no further prompts so it can run automagically from cron, or (the general default when invoked from a command line) it can issue a user a single prompt indicating what it is about to do and requesting permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as informative an error message as it can generate, permitting the system's administrator to attempt to resolve the situation by hand before proceeding (which may, for example, involve removing certain conflicting packages from the client system or fixing the repository itself).

From the overview given above, it should be apparent that yum is potentially a powerful tool indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular degree of efficiency. One can immediately imagine all sorts of ways to exploit the information now so readily available to a client and wrap them all up in a single interface to eliminate the incredibly arcane and complex commands otherwise required to learn anything about the installed package base on a system and what is still available. The yum developers have been doing just that on the yum list - dreaming up features and literally overnight implementing the most attractive ones in new code. At this point yum is very nearly the last thing you'll ever need to manage packages on any rpm based system once it has gotten past its original, distribution vendor based, install.

rpm doesn't permit one to tell it to "install package X and anything else that it needs, after YOU figure out what that might be". Yum, of course, does.

Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering schemes or dependency specifications that appear in all the rpm's one might find and rebuild or develop locally for inclusion in a central repository. When one is encountered, a Real Human has to apply a considerable amount of systems expertise to resolve the problem. This suggests that building rpm's from sources in such a way that they "play nice" in a distribution repository, while a critical component of said repository, is not a trivial process. So much so that many rpm developers simply do not succeed.

Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation is permitted on all the systems using yum to keep up to date.

Consequently, repository maintainers must willy-nilly become rpm builders to at least some extent. If SuSE releases a lovely new tool in source rpm form that isn't in your current Red Hat based repository, of course you would like to rebuild it and add it. If your University has a site license for e.g. Mathematica and you would like to install it via the (properly secured and license controlling) repository you will need to turn it into an rpm. If nothing else, you'll need to repackage yum itself for client installations so that its configuration files point to your repositories and not the default repositories provided in the installation rpm's /etc/yum.conf.

Creating private Yum repositories

There are three steps to creating a yum repository:

• copy RPMs to the selected directory
• index the RPMs.
• Create a repo file for the new yum repository in  /etc/yum.repos.d/

If you have a special repository which you really like, but which does not support yum, you can use a trick: make a local mirror of the files via rsync or similar utility and then create a local YUM repository. To convert directory with RPMs into YUM repository you need to run a special utility createrepo

yum install createrepo

To create a repository you need to run it with a single parameter, the root of  RPM directory tree (you can use subdirectories for various groups of RPMs):

createrepo /var/cache/myrepo

After running the utility you can notice that in the directory /var/cache/yum/myrepo there is a new directory called repodata with data describing RPMs in it. 

The last step is to create the file with extension repo, for example, my.repo  in /etc/yum.repos.d/:

[myrepo]
name=my cool repo
baseur=file:///var/cache/myrepo
enabled=1

At this point you should be able to install RPM from local repository using yum. You can  use wget and cron-jobs for synchronizing of the local repository.  After each synchronization you need to update the repodata directory using createrepo

Setting up a remote yum repository

Once the repository is constructed, it must be made available by http, ftp, or rsync. If the repository is made in the root document tree of your web server, e.g., /var/www/html/, the following entry should be added to /etc/httpd/conf/httpd.conf:

<Directory /var/www/>
Options +Indexes
</Directory>

in order to allow the directories to be listed. Reload the httpd configuration file with

# /sbin/service httpd reload

or

# /sbin/service apache2 reload

depending of the flavour of Linux you are using and the type of Web server you have.

Reference

Most options come in two flavors: a long option and a short option. The long option features two hyphens and the full option name, the short one hyphen and - in most cases - the first character of the full option. Of course you only have to provide one option form (i.e. either rpm --install [name] or rpm -i [name]).

Installation/Removal

• yum install foo - install package foo
• yum remove foo - remove package foo with dependencies
• yum update foo - update only package foo 
• yum update - update the whole system

Queries

• yum search whatever - search for this string
• yum info foo - give the infos about this package
• yum provides foo_library - which package has this library?

Repo files

On invocation yum first checks its configuration file /etc/yum.conf which store all information about the repositories in /etc/yum.repos.d/.

The files in this directory should have an extension repo and format like this:

[base]
name=SUSE LINUX 10.0 - Base
baseurl=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse
enabled=1
gpgcheck=1
gpgkey=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/pubring.gpg

The first option shows the name - this must be unique because yum uses it to identify the repository and the cached data about it.

The second option, the name field, is for the user to know what he has configured.

baseurl gives the server and the directory where yum can find the packages.

You can use mirrorlists instead.  The url to the mirrorlist is part of the field mirrorlist - due to the fact the no server provides them, we have to make our own. Some mirrorlists:

• the SUSE LINUX 10.0 base files
• some german mirrors for the base files
• the java files
• some german mirrors for the java files
• packman files
• packman mirrors, at this moment only the server in Bremen
• the GM files (proprietary stuff)
• some mirrors for this stuff
• the update files
• some mirrors for the update servers

References

Yum: Yellow dog Updater, Modified Homepage
Charles Curley's Yum Repository Notes
Yum (Yellow dog Updater, Modified) HOWTO
YUM: Yellowdog Updater, Modified

Old News ;-)

Using apt in an RPM world Field Commander Wieers

Okay. Now my issue against apt. When you look for an libraries which is needed in an package you can use in RHEL/CentOS environments

up2date --whatprovides=lib.so.5.2

or

yum provides lib.so.5.2

This shows which packages provides that specific file. apt does not have this feature as far as I know.

Yum & Repositories

I noticed this issue with both CentOS 4 and 5 - Yum will often choose bad mirrors from the mirrorlist file - for example, choosing overseas servers, when an official NZ server exists. And in some cases, the servers it has chosen are horribly slow.

You will probably find that you get better download speeds by editing /etc/yum.repos.d/CentOS-Base.repo and commenting out the mirrorlist lines and setting the baseurl line to point to your preferred local mirror.



Yum-updatesd
CentOS 5 has a new daemon called yum-updatesd, which replaces the old cron job yum update scripts. This script will check frequently for updates, and can be configured to download and/or install them.

However, this daemon is bad for a server, since it doesn't run at a fixed time - I really don't want my server downloading and updating software during the busiest time of day thank-you-very-much!

So, it's bad for a server. Let's disable it with:
 

service yum-updatesd stop
chkconfig --level 2345 yum-updatesd off

Plus I don't like the idea of having a full blown daemon where a simple cronjob will do the trick perfectly fine - seems like overkill. (although it appears yum-updatesd has some useful features like dbus integration for desktop users)

So, I replace it with my favorite cronjob script approach, by running the following (as root of course):
 

cat << "EOF" > /etc/cron.daily/yumupdate
 #!/bin/sh
 # install any yum updates
/usr/bin/yum -R 10 -e 0 -d 1 -y update yum > /var/log/yum.cron.log 2>&1
/usr/bin/yum -R 120 -e 0 -d 1 -y update  >> /var/log/yum.cron.log 2>&1
if [ -s /var/log/yum.cron.log ]; then
        /bin/cat /var/log/yum.cron.log | mail root -s "Yum update information" 2>&1
fi
EOF

and if you want to clear up the package cache every week:
 

cat << "EOF" > /etc/cron.weekly/yumclean
 #!/bin/sh
 # remove downloaded packages
/usr/bin/yum -e 0 -d 0 clean packages
EOF

(please excuse the leading space infront of the comments ( #) - it is to work around a limitation in my site, which I will fix shortly. Just copy the lines into a text editor and remove the space, before pasting into the terminal)

This will install 2 scripts that get run around 4:00am (as set in /etc/crontab) which will check for updates and download and install any automatically. If there were any updates, it will send out an email, if there were none, it doesn't send anything.

(of course, you need sendmail/whatever_fucking_email_server_you_like configured correctly to get the alerts!)

You can change yum to just download and not install the updates (just RTFM), but I've never had a update break anything - update compatibility and quality is always very high - so I use automatic updates.

CentOS 4 had something very similar to this, with the addition of a bootscript to turn the cronjobs on and off.

* Please check out the update at the bottom of this page for futher information on this. UPDATE - 1st May 2007

A reader has informed me that the old RHEL 4 style cronjobs can be found in a package called 'yum-cron'. Just like in RHEL 4, it installs a service called "yum" which you can enable with:
 

chkconfig --level 2345 yum on
service yum start

However, I will point out a small difference with the Redhat cron script vs. my cron script - the Redhat one will send the list of updates as an email from cron (as cron simply emails the output the script produces). My version allows you to change the subject, and the destination email address. This may/may not be useful to you.

The same reader also points out that there is another package in the CentOS extras repository called 'yum-updateonboot', which installs bootscripts which update your system when you boot it, and will then reboot if there are any kernel updates needed.

You should be able to (I haven't tried myself) enable it with:
 

chkconfig --level 2345 yum-updateonboot on

Upgrading Red Hat Linux/Fedora Core with yum

Before performing an upgrade with yum, please read the YumUpgradeFaq Wiki.

The basic steps for upgrading a system to the latest Fedora Core release using yum:

1. Install the fedora-release package from the new release
2. Run yum upgrade
3. Reboot

Upgrading to Fedora Core 4

The following steps were used to update a Fedora Core 3 system to Fedora Core 4 using yum.

1. Update yum to the latest Fedora Core 3 version.
# yum -y update yum

2. Download and install the Fedora Core 4 version of fedora-release from one of the Fedora Core mirrors.

Example:
# rpm -Uvh http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/Fedora/RPMS/fedora-release-4-2.noarch.rpm

3. Disable third-party yum repositories, if applicable.

In my configuration, I had the Dag, FreshRPMs, and Dries third-party yum repositories enabled. As of 2005/06/15, only the Dries repository caused an error message (i.e. it had not been updated with Fedora Core 4 packages or it did not have a Fedora Core 4 directory structure) so I will only disable that repository.

# echo "enabled=0" >> /etc/yum.repos.d/dries.repo

4. When upgrading to Fedora Core 4, the kernel must be upgraded before the rest of the packages.
# yum -y update kernel

Otherwise, you may receive the following error message:

--> Running transaction check
--> Processing Dependency: kernel-utils for package: kernel
--> Finished Dependency Resolution
Error: Missing Dependency: kernel-utils is needed by package kernel

5. Disable SELinux, if applicable, and reboot the system to begin using the Fedora Core 4 kernel. I ran into significant problems after this reboot when SELinux was enabled.

To disable SELinux:

# vi /etc/sysconfig/selinux

Change:
SELINUX=enforcing
-- or --
SELINUX=permissive

To:
SELINUX=disabled

# reboot

7. Remove the Fedora Core 3 kernel(s) to prevent the aforementioned kernel-utils package dependency error.
# yum remove kernel-2.6.\*FC3\*
# yum remove kernel-smp\*FC3\* (if you have one or more FC3 SMP kernels installed)

8. Continue the upgrade to Fedora Core 4.
# yum -y upgrade

Note: if you receive the following error, import the RPM-GPG-KEY.

warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID db42a60e
public key not available for caching-nameserver-7.3-3.noarch.rpm

# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY

9. Reboot the system to begin using Fedora Core 4.

10. If applicable, re-enable SELinux by undoing the changes above, and reboot the system to use SELinux.

User-contributed notes on Upgrading to Fedora Core 4

On 2005/07/16, Jay Thorne wrote:

Before you upgrade the kernel, you need to upgrade mkinitrd, otherwise
the initrd that the kernel install process makes is in the old format
and the new kernel will not boot; it dies with a oops.

# yum -y upgrade mkinitrd

Otherwise, this procedure works well. Good work.

Also, in the x86_64 case, you need to specifically upgrade
libselinux.i386 and libselinux.x86_64 before the kernel upgrade, or the
upgrade will fail with a conflict.

# yum -y upgrade libselinux.i386 libselinux.x86_64

Thanks for Wim Cos for writing on 2005/06/16 and providing the steps to update yum to the latest FC3 version and for the steps to remove FC3 SMP kernels, if applicable.

Build Service-User - openSUSE

For SUSE Linux 9.3, 10.0, 10.1 and Factory, you can also use smart', zypper, yum, or apt to install and update packages from the Build Service. The latest smart and yum packages can be found at http://download.opensuse.org/repositories/smart/

Zypper

With openSUSE 10.2, you can also use the command line tool named zypper to add repositories:

zypper sa -r <URL_to_your_repo_file>

For example:

zypper sa -r http://download.opensuse.org/repositories/openSUSE:/Tools/SUSE_Linux_Factory/openSUSE:Tools.repo

For more information, use

zypper help

 

Smart

smart channel --add http://download.opensuse.org/repositories/<projectname>/<directory>/<project>.repo

To install a package you need to call

 smart update
 smart install <package>
 smart upgrade    # Performs an upgrade of all installed packages using the new repositories.

yum

YUM can use the repositories after the generated .repo file got copied into the /etc/yum.repos.d/ directory. Afterwards you can use yum commandline tools or GUI tools like kyum.

APT

APT isn't very well supported on openSUSE, so we recommend that you use one of the other above methods instead. This paragraph is a translation of an updated article for SuSE Linux 10.1 Apt v SUSE LINUX 10.1 from the czech SuSE portal which deals with the installation and usage of APT (Advanced Package Tool) in SUSE.

First we need apt and apt-libs. Both packages can be found on the DVD. The graphical front-end for Apt - Synaptic - is missing for an unknown reason, so we must be content with the command line version.

To install the above mentioned packages successfully we need to download and install the package install-apt4suse.rpm. The easiest installation is to launch mc as root, find and open the downloaded package by Enter and start the script INSTALL.

In a further step we launch:

 install-apt4suse --update-srclist

which updates the current list of mirrors. The result can be checked in /etc/apt/sources.list. The following table shows the commands which can be used with APT:

apt-get update	Creates a list of available packets
apt-get upgrade	Updates pre-installed packets by newer versions
apt-get -s upgrade	Shows more details about what is to be updated
apt-get -s install "packet name"	Shows more details about what is to be installed
apt-get install "packet name"	Installs a packet
apt-get reinstall "packet name"	Re-installs a packet
apt-get remove "packet name"	Removes a packet
apt-get clean	Cleanup of the buffered setups

In case of errors with GPG during the installation process open the file /etc/apt/apt.conf.d/gpg-checker.conf and change the entry

 GPG::Check true;

to

 GPG::Check false;

The usage of APT is faster and more transparent to end users compared to YaST and the new ZEN installer.

See also The Advanced Package Tool for SUSE for more information.

HelpUpdate suse - SUSE Wiki

Some options associated with the yum command:

• yum - display brief help (is the package installed?)
• yum check-update - displays any updates the current system needs
• yum update - check for updates and apply them interactively
• yum update <package> - check for updates and upgrade a specified package
• yum info - similar output to a rpm -qai
• yum info <package> - information about a specific package
• yum list - lists all available packages
• yum list <package> - list individual package(s)
• yum list installed - list all installed packages
• yum list available - list all packages not installed
• yum list update - list all packages that need to be upgraded
• yum clean - delete any rpms in the yum cache and remove any unneeded headers
• yum install <package> - install the package (or yum –y install <package>)
• yum remove <package> - delete the package
• yum search <string> - searches for packages containing the string in their name or header info
• RUN this command at TERMINAL --> yum check-update [ENTER]

Index of -repo-hardware

yum repository for suse 10.1 - LinuxQuestions.org

Go here:
http://linux01.gwdg.de/~pbleser/rpm-...=/System/smart

Install smart. It is better then Yum and it can handle multiple repostory types. Yast, Yum, Apt-get, Red Carpet, CD/DVD, plain directory are all handled well by Smart.

[Mar 23, 2007] Using YUM in RHEL5 for RPM systems

There is more to Red Hat Enterprise Linux 5 (RHEL5) than Xen. I, for one, think people will develop a real taste for YUM (Yellow dog Updater Modified), an automatic update and package installer/remover for RPM systems.

YUM has already been used in the last few Fedora Core releases, but RHEL4 uses the up2date package manager. RHEL5 will use YUM 3.0. Up2date is used as a wrapper around YUM in RHEL5. Third-party code repositories, prepared directories or websites that contain software packages and index files, will also make use of the Anaconda-YUM combination.

... ... ...

Using YUM makes it much easier to maintain groups of machines without having to manually update each one using RPM. Some of its features include:

• Multiple repositories
• Simple config file
• Correct dependency calculation
• Fast operation
• RPM-consistent behavior
• comps.xml group support, including multiple repository groups
• Simple interface

RHEL5 moves the entire stack of tools which install and update software to YUM. This includes everything from the initial install (through Anaconda) to host-based software management tools, like system-config-packages, to even the updating of your system via Red Hat Network (RHN). New functionality will include the ability to use a YUM repository to supplement the packages provided with your in-house software, as well as plugins to provide additional behavior tweaks.

YUM automatically locates and obtains the correct RPM packages from repositories. It frees you from having to manually find and install new applications or updates. You can use one single command to update all system software, or search for new software by specifying criteria.