|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
YUM
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:
- 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).
- It can also 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.
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:
- Installing the package breaks none of the already installed packages
(recursively, as they may need packages of their own to be installed).
- All the packages that the package requires for correct operation are
also (or already) installed along with the selected package, recursively.
- A later version of the package does not (accidentally) replace an
earlier version of the package.
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:
- yum install foo - install package foo
- yum remove foo - remove package foo with dependencies
- yum search whatever - search for this string
- yum update foo - update only package foo
- yum update - update the whole system
- yum info foo - give the infos about this pacakge
- yum provides foolibrary - which pacakge has this library?
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).
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 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 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.
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]
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.
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.
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