Linux and other Unices prevent ordinary users from being able to install, remove, or modify software, libraries, or important configurational information. On a networked, professionally run installation of workstations the need for this sort of control to ensure security and functionality is obvious. On a privately owned and controlled workstation, the need is less obvious but just as profound. Even there the owner of the workstation needs to take extreme care whenever working with the fundamental system configuration and package installation or they will likely break the system or leave it vulnerable to crackers.
To ensure that an adequate degree of care is exercised when doing things that could render a system unusable or vulnerable, linux and Unices require the owner of such a workstation to assume root privileges, usually by means of the su command. In order to execute the privileged commands to add or remove software from your system, you must therefore become root. To do this, enter (in a tty window such as an xterm):
$ su
and enter the root password when prompted to do so. The prompt should become the sharp sign `#'
# yum list
to remind you to be sharp as root.
Warning! It is essential that you heed this advice to "be sharp" as you can destroy your system's installation with a careless keystroke, especially one involving wildcards such as '*' or '?'. Certain yum commands (notably upgrade and remove) can have unexpected side effects depending on the whims of the maintainers of RPMs in the repository, so caution and testing are advised. Be certain that you understand what a command will do, including side effects, before invoking it, especially with commands that delete files.
Some yum commands will actually work fine for ordinary, unprivileged users. In general these are the informational yum commands, discussed next. Note that the unprivileged commands do require that the yum header cache exist, so they will not work at all correctly if run before root has run a yum command to create current images of the header files.
There are several ways of "getting yum":
Each of these possibilities is detailed in the subsections below.
If your goal is just to get yum and install it on a client, you will likely just want to get yum in a ready-to-install-and-run rpm from from the main yum website. One can select and download the appropriate rpm for your architecture (which matters) from the yum website http://www.linux.duke.edu/projects/yum.
To explain the importance of matching architecture for a tool written in a presumably agnostic and slowly varying scripting language, note that yum is written in python (the agnostic and slowly varying language:-) and uses the python rpm bindings, the same as Red Hat's anaconda and up2date. Ahh, good news and bad news, same as always.
The good news is that the basic python code is indeed quite stable, and using the python-rpm bindings makes yum relatively unlikely to break, at least for long, as Red Hat has a vested interest in making these binding work for their own products.
The bad news is that as rpm changes (fairly rapidly in recent releases) the bindings change and yum needs revision. Hence there are thus several versions of yum available for download at this time, each matching a quite recent revision of rpm and (not coincidentally) a release number of Red Hat Linux.
Fortunately, there is a short table of download links on the server above where you can find ready to install rpm's for yum built for each of the recent major linux releases. If you have difficulty picking, ask on the yum list for help or try using the tarball of yum sources to build the right version automagically. Or both!
Note Well: The yum rpm's you will download from this site have an /etc/yum.conf that is preconfigured to point to a public repository that supports yum, probably http://mirror.dulug.duke.edu. Naturally, if the entire Internet got yum and started updating clients from this site, at some point it would pretty much get hammered to where it no longer worked. DULUG is not google, and this is a single not-particularly powerful server, not a web farm. You may well want to look over the list of public yum repositories and edit /etc/yum.conf to use one of the alternatives, or (if you are a LAN manager with a publically accessible webserver) set up a repository of your own and add it to the list, following the instructions in this HOWTO!
To set up a repository of your own to serve a private LAN or public WAN or both, you will need the yum tarball so that you can build your own yum rpm with its configuration files and %post installation instructions customized for your site (following the instructions given in the next couple of sections). If you are new to yum, you should likely start with the stable tarball, not the development tree, and join the yum list. You'll know when it is time to move up and start using the public CVS repository to get the latest tarball snapshot instead of using the stable tarball.
To get the stable tarball is simple. Just visit the yum website, http://www.linux.duke.edu/projects/yum, and download it. Then skip ahead to the sections on planning a repository and building a custom yum rpm.
As noted above, it is also possible to get yum directly from the CVS tree on the linux@duke repository. Most "normal humans" won't need or want to do this -- you are accessing the raw development tree, which might have cool new features or support a broader range of cutting edge distributions and releases, but which also might have bugs. Even immediately fatal bugs -- some snapshots you might grab will simply be pre-broken and need immediate replacement.
To use the CVS repository you don't quite need mad skills, but you do need to be familiar with and comfortable with the open source development process. Joining the yum mailing list is essential for example, and in fact if you are reading this in preparation for doing a CVS download I'm going to hope that you've been on the list already for a while, and are grabbing the CVS-based snapshot fully understanding that if it doesn't work you'll submit an immediate bug report and wait for (or help find) a solution, not scream because it "breaks" your production network.
It should almost never break your production network because anybody who participates in this sort of development cycle knows better than to immediately deploy such a snapshot without a fair bit of testing on clients and servers where if it turns out to be broken "it doesn't matter".
Don't let these dire-sounding warnings deter you, though. The entire operating system you are using (presuming that you are using Linux) was built by precisely this process, and many hands contributing a small bit of work, intelligently directed, can create incredibly powerful tools. Come on in, the water's fine! Especially if you have mad python skills and some clever ideas...;-)
To pull yum from cvs do the following:
cd ~
mkdir cvsroot
cd cvsroot
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
login
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
get yum
To update it once you've gotten it:
cd ~
cd cvsroot
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
upd yum
[*Thanks to Russ Herrold for providing the above instructions*]
As noted above, it is strongly recommended that one become pretty thoroughly familiar with yum from using a stable release version and at least listening in on the yum list (which is mailman-managed and hence can easily be digested or throttled altogether) before tackling a CVS tree build. Knowing python is probably a good idea as well.
Once you have yum sources from either the stable tarball or the CVS tree, it is time to plan out your repository. This is detailed in the next section