Package management has always been a sore point for Linux, and particularly for RPM-based distros. "Dependency hell" is the term commonly used for the pain involved in installing a piece of software with a package management utility. Debian made things easier with its Advanced Packaging Tool (APT), but that's no comfort to Red Hat and Fedora users. Connectiva Linux created APT-RPM, which brings most of the benefits of APT to RPM-based distros, but early versions bent some rules to get results.
Yum (Yellow Dog Updater, Modified) was created to address both the perceived deficiences in APT-RPM at the time, and restrictions of the Red Hat up2date package management tool. Yum handles dependencies gracefully and supports multiple repositories, as does APT-RPM. It also supports groups -- tell a machine to process an application group and it will install all of those applications. This greatly simplifies managing multiple machines.
Why use yum instead of APT-RPM? Well, apart from the groups support, yum is distributed with Fedora Core, and APT-RPM is an add-on.
Creating thebase repository
To create local yum repository, you need a Web server. I'll be using the default Apache configuration you get with Fedora Core 2.
The DocumentRoot for Apache on Fedora Core is set to /var/www/html. Create a yum folder below this:
$ mkdir /var/www/html/yum
The base install RPMs for FC2 come to approximately 1.9GB in total, so ensure you have enough room. If you don't, create the yum folder somewhere else, and create a softlink:
$ mkdir /home/yum
$ ln -s /home/yum /var/www/html/yum
You need to ensure that Apache is configured to follow links.
Now you can create a structure to store the files in. Yum supports multiple repositories, so you can serve files for both Fedora Core 1 and 2 from the same server. We're going to store our files in the following structure:
yum
|-Fedora
|-Core
|-2
|-base
Creating this is simple:
$ mkdir -p /var/www/html/yum/Fedora/Core/2/base
To get the source files for the repository, run the following commands for each of the FC2 binary CDs:
$ mount /mnt/cdrom
$ cp /mnt/cdrom/Fedora/RPMS/*.rpm /var/www/html/yum/Fedora/Core/2/base/
$ umount /mnt/cdrom
Yum works by parsing the RPM headers. To save us from downloading each RPM to read its header, yum's developers provide a tool called yum-arch to extract the headers into their own (much smaller) files. To create your headers, run the commands:
$ cd /var/www/html/yum/Fedora/Core/2/base/
$ yum-arch .
This creates a headers folder, and turns your collection of files into a repository.
Creating theupdates repository
Having your own base repository is all well and good for installing software, but you can derive far more benefit from having your own Updates repository. Creating one is as straightforward as creating the base was. Conceptually, the Updates repository fits into our structure thusly:
yum
|-Fedora
|-Core
|-2
|-base
| |-headers
|-updates
Creating it is simple:
$ mkdir -p /var/www/html/yum/Fedora/Core/2/updates
Next, get a copy of the updates, which can be found on the Fedora Download Server or your friendly neighbourhood mirror. Simply grab them with your favourite download tool and place them in the updates folder, then run yum-arch again.
Make sure you keep this repository up-to-date, or you'll lose the benefit of having it!
Configuring your machineNow that you've got your repositories, you need to set your machine up to talk to them. This is controlled by the file /etc/yum.conf.
Here's the default contents of the file:
[main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 retries=20 [base] name=Fedora Core $releasever - $basearch - Base baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/> [updates-released] name=Fedora Core $releasever - $basearch - Released Updates baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/ #[updates-testing] #name=Fedora Core $releasever - $basearch - Unreleased Updates #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/$releasever/$basearch/ #[development] #name=Fedora Core $releasever - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/
...and here are the changes we'll make:
[base] name=Fedora Core $releasever - $basearch - Base baseurl=http://servername/Fedora/Core/$releasever/$basearch/base/ [updates-released] name=Fedora Core $releasever - $basearch - Released Updates baseurl=http://servername/Fedora/Core/$releasever/$basearch/updates/
$releasever and $basearch will get expanded by yum to point to the current folder structure.
Now it's a simple matter of running yum update to see what needs updating.
Suppose you have 100 machines you want to keep updated. Editing the yum.conf file for each machine is possible, but I'm sure you've got better things to do. There's got to be a better way, right?
There is. You can alter the stock Fedora yum RPM to automatically point your machines at the repository.
Get the source RPM (SRPM) from either your CD or the Fedora Download Server (or your friendly neighbourhood mirror, of course). The package you want is yum-2.0.7-1.1.src.rpm. As root, install this package with the command rpm -i yum-2.0.7-1.1.src.rpm.
RPM sources are kept in the /usr/src/redhat folder, with the source files in SOURCES and the spec files in SPECS. You need to edit both the default yum.conf file and the yum.spec file.
First, edit /usr/src/redhat/SOURCES/yum.conf.fedora as in the "Configuring your machine" section above. Next, edit /usr/src/redhat/SPECS/yum.spec, changing the line:
Release: 1.1
to:
Release: 1.2
This change gives our customised RPM precedence over the stock one. Now you can build the RPM with the command rpmbuild -ba /usr/src/redhat/SPECS/yum.spec.
The resultant RPM is stored in /usr/src/redhat/RPMS/noarch, and can be installed with the command rpm -U /usr/src/redhat/RPMS/noarch/yum-2.0.7-1.2.noarch.rpm.
Note: if you've already edited your /etc/yum.conf file, you can create the customised one as /etc/yum.conf.rpmnew.
There you have it -- a local yum repository complete with a customised yum package to take the strain out of maintaining your machines.
Note: Comments are owned by the poster. We are not responsible for their content.
<TT>[base]I've found the file protocol to be much faster than the http.
name=Fedora Core $releasever - $basearch - Base
baseurl=file:///nfsshare/Fedora/Core/$relea<nobr>s<wbr></nobr> ever/$basearch/base/
[updates-released]
name=F edora Core $releasever - $basearch - Released Updates
baseurl=file:///nfsshare/Fedora/Core/$re<nobr>l<wbr></nobr> easever/$basearch/updates/</TT>
1. Using up2date with your repository
Although everyone seems to have forgotten this, the Fedora Core up2date now has backend support for yum repositories. What I find really useful about making my own repositories is to not only have a mirror of the distribution, but to mirror an update server as well. I use a nightly cron job to pull released updates from a mirror after they've performed their mirror routines. I also mirror FreshRPMS and other useful repositories (such as Fedora Legacy for my Red Hat Linux 9 systems).
By setting up my<nobr> <wbr></nobr><tt>/etc/sysconfig/rhn/sources</tt> file, my desktop RHN applet tells me when there are updates available in any of my local repos by flashing its red exclamation mark. Then either my wife or I can have them installed using the simple GUI interface (or I ssh from work and do them via terminal for more speed). I don't even have to use<nobr> <wbr></nobr><tt>/etc/yum.conf</tt> since the yum support in up2date is built-in.
up2date seems to have been criminally ignored by many intermediate Linux users because they don't realize that it is no longer inextricably linked with Red Hat Network. Red Hat went to some trouble to build in yum and apt support so that Fedora Core would be more useful to the community. Don't be afraid to use it!
2. RPM release tag
Rather than setting the release tag from 1.1 to 1.2, a better idea would be to use 1.1.0.xxx, where xxx are your initials. That way, if an official release is tagged 1.2, it will override your custom 1.1.0.xxx RPM. If the officially released 1.2 has been changed to eliminate a bug or contains a security fix, you would want to rebuild the new RPM (which you would then tag 1.2.0.xxx).
Can I take their repository of RPMs, and make a yum repository of them, and then use yum update to only get the RPMs I really should have?
-Ben
Re:alternative health complementary medicine Londo
Posted by: Anonymous Coward on May 29, 2005 11:54 PM#