Softpanorama
(slightly skeptical) Open Source Software Educational Society

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

Google   


YUM

News See Also Recommended Links RPMs Red Hat Suse Etc
 

The Yellow dog Updater, Modified (YUM) was written and is currently being maintained by Seth Vidal and Michael Stenner, both of Duke University, as part of Duke University's Linux@DUKE project. Though yum is a command line utility, several other tools provide graphical user interfaces to yum, among them pup, pirut, and yumex. Seth Vidal now works for Red Hat.

Yum is a rewrite 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 Apple Macintoshes of various generation).  The yum link above acknowledges the (mostly) complete list of contributers, as does the AUTHORS file in distribution tarball.

Yum was developed primarily in order to update and manage Red Hat Linux systems used at the Duke University department of Physics. Now it became standard for RedHat and its derivatives.  Red Hat's own enterprise package manager, up2date, can also make use of yum repositories when performing software updates. Red Hat Enterprise 5 saw yum and pirut replace up2date in that distribution. Because yum invokes the same tools and python bindings used by e.g. Red Hat to actually resolve dependencies and perform installations (functioning as a  shell for rpm and anaconda that can run directly from the local header cache) it has proven remarkably resient to changes of the rpm toolset.

Automatic software update can be done with either the yum-updatesd or the yum-updateonboot packages.

Yum's repository system is quickly becoming the standard for RPM-based repositories. Besides the distributions that use Yum directly, SUSE Linux 10.1 adds support for Yum repositories in YaST, and the openSUSE Build Repository is exclusively Yum-based. SUSE LINUX 10.x also provides kyum as a kde based gui.

yum can do several things that yast cannot:

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.

Yum's "intelligence" in performing updates is superior to most competitiors other then smart; yum has been used successfully on numerous occasions to perform a "running upgrade" of e.g. a Red Hat 7.1 system directly to 7.3 (where the probability of success naturally depends on how "customized" the target system is and how much critical configuration file formats have "drifted" between the initial and final revisions - YMMV).

In addition, the yum client encapsulates various informational tools, and can list rpm's both installed and available for installation, extract and publish information from the rpm headers based on keywords or globs, find packages that provide particular files. Yum is therefore of great use to users of a workstation, either private or on a LAN; with yum they can look over the list of available packages to see if there is anything "interesting", search for packages that contain a particular tool or apply to a particular task, and more.

Yum is designed to be a client-pull tool, permitting package management to be "centralized" to the extent required to ensure security and interoperability even across a broad, decentralized administrative domain. No root privileges are required on yum clients -- yum requires at most anonymous access (restricted or unrestricted) from the clients to a repository server (often one that is maintained by a central -- and competent -- authority). This makes yum an especially attractive tool for providing "centralized" scalable administration of linux systems in a decentralized network management environment, where a mix of machines maintained by their owners and by a variety of network managers naturally occurs (such as a University).

One of yum's most common uses in any LAN environment is to be run from a nightly cron script on each yum-maintained system to update every rpm package on the system safely to the latest versions available on the repository, including all security or operationally patched updates. If yum is itself installed from a rpm custom-preconfigured to perform this nightly update, an entire campus that installs its systems from a common repository base can achieve near complete consistency with respect to distribution, revision, and security. Security and other updates will typically appear on all net-connected clients no more than 24 hours after the an updated rpm is placed on the repository by its (trusted) administrator who requires no root-level privileges on any of the clients.

Consequently with yum a single trusted administrator can maintain a trusted rpm repository (set) for an entire University campus, an entire corporation, an entire government laboratory or institution. Alternatively, responsibility for different parts of a distribution can be split up safely between several trusted administrators on distinct repositories, or a local administrator can add a local trusted repository to overlay or augment the offerings of the campus level repositories. All systems at a common revision level will be consistent and interoperable to the extent that their installed packages (plus any overlays by local administrators) allow. Yum is hence an amazingly powerful tool for creating a customized repository-based package delivery and maintenance system that can scale the work of a single individual to cover thousands of machines.

An rpm consists of basically three parts: a header, a signature, and the (generally compressed) archive itself. The header contains a complete file list, a description of the package, a list of the features and libraries it provides, a list of tools it requires (from other packages) in order to function, what (known) other packages it conflicts with, and more. The basic rpm tool needs information in the header to permit a package to be installed (or uninstalled!) in such a way that:

Note that a similar list applies to uninstallation; removing a package must not break any packages left behind, for example.

This process is generically known as "resolving package dependencies" and is one of the most difficult parts of package management. It is quite possible to want to install a packaged tool that requires two or three libraries and a tool. The libraries in turn may require other libraries, the tool other tools. By the time you're done, installing the package may require that you install six or eight other packages, none of which are permitted to conflict or break any of the packages that are already there or will remain behind.

If you have ever attempted to manage rpm's by hand, you know that tracking down all of the headers and dependencies and resolving all conflicts is not easy and that it actually becomes more difficult in time as a system manager updates this on one system, that on another, rebuilds a package here, installs something locally into /usr/local there. Eventually (sometimes out of sheer frustration) an rpm is --force installed, and thereafter the rpm database itself on the system itself is basically inconsistent and any rpm install is likely to fail and require --force-ing in turn. Entropy creeps into the network, and with it security risks and dysfunction.

Yet not updating packages is also a losing situation. If you leave a distribution based install untouched it remains clean. However, parts of it were likely broken at the time of install -- there are always bugs even in the most careful of major distributions. Some of those bugs are security bugs, and as crackers discover them and exploits are developed it rapidly becomes a case of "patch your system or lay out the welcome mat for vermin". This is a global problem with all operating systems; even Windows-based systems (notorious for their vulnerability to viruses and crackers) can be made reasonably secure if they are rigorously kept up to date. Finally, users come along and demand THIS package or THAT package which are crucial to their work -- but not in the original, clean, consistent installation.

In balance, any professional LAN manager (or even humble standalone linux workstation owner) has little choice; they must have some sort of mechanism for updating the packages already installed on their system(s) to the latest, patched, secure, debugged versions and for adding more packages, including ones that may not have been in the distribution they relied upon for their original base install. The only questions are: what mechanism should they use and what will it cost them (in time, hassle, learning curve, and reliability as well as in money). Let us consider the problem:

In a typical repository, there are a lot of packages (order of 1000), with a lot of headers. About 700 packages are actually installed on the system I'm currently working on. 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 100BT, and minutes to be delivered over e.g. DSL, cable, or any relatively slow network. One occupies the physical server of a repository for a tiny interval; the other creates a meaningful, sustained load on the server. All of these are important considerations when designing or selecting an update mechanism intended to scale to perhaps thousands of clients and several distinct repositories per physical server.

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.

As a parenthetical note, the author has used yum's caches in a trick to create a "virtual" update repository on his homogeneous, DSL-connected home LAN. By NFS exporting and mounting (rw,no_root_squash) /var/cache/yum to all the LAN clients, once normal updates have caused a header or rpm to be retrieved for any local host, they are available to all the local hosts over a (much faster than DSL) 100BT NFS mount. This saves tremendously on bandwidth and (campus) server load, using instead the undersubscribed server capacity of a tiny but powerful LAN. Best of all, there "is no setup"; what I just described is the works. A single export and a mount on all the clients and yum itself transparently does all of the work.

However, it is probably better in many cases to use rsync or other tools to provide a faithful mirror of the repository in question and use yum's fallback capability to accomplish the same thing (single use of a limited DSL channel) by design. 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.

Indeed, it is now so powerful that it risks losing some of its appealing simplicity. This HOWTO is intended to document yum's capabilities so even a novice can learn to use it client-side effectively in a very short time, and so that LAN administrators can have guidance in the necessarily more complex tasks associated with building and maintaining the repositories from which the yum clients retrieve headers and rpm's.

Yum's development is far from over. Volunteers are working on a GUI (to encapsulate many of yum's features for tty-averse users). Some of yum's functionality may be split off so that instead of a single client command there are two, or perhaps three (each with a simpler set of subcommand options and a clear differentiation of functionality). The idea of making yum's configuration file XML (to facilitate GUI maintenance and extensibility) is being kicked around. And of course, new features are constantly being requested and discussed and implemented or rejected. Individuals with dreams of their own (and some mad python or other programming skills:-) are invited to join the yum list and participate in the grand process of open source development.

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.

Basic commands:

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

A file in this directory looks 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.  he 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:

If you have a special repository which you really like, but which does not support yum, you can use a trick: make a local copy of the files via rsync or whatever, and use the directory of the files as a local repository. You will need the small programm createrepo for this

yum install createrepo

After this, copy all the rpm-files you want to use to a special place:

mv *.rpm /var/cache/myrepo
createrepo /var/cache/myrepo

In /var/cache/yum/myrepo will appear a new directory called repodata. Now place the *.repo file in /etc/yum.repos.d/:

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

You can  use cron-jobs for synchronizing and the new creation of the repo-files

apt4rpm is very similar. apt isn't capable to handle mirror lists - yum and smart are! Smart, which is developed by a former apt4rpm developer, has a ongoing development (yum, too, btw).
It looks like that SUSE will drop apt4rpm as a tool, but will use the repository data for smart (smart can handle apt, yum, urpmi and other repositories).

Old News ;-)

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
[edit]

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.
[edit]

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.

[edit]

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:

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.



Copyright © 1996-2007 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: March 15, 2008