There are two types of sections in the yum.conf file: main and server. Main defines all the global configuration options. The Server section(s) define the entries for each server.
The Main section must exist for yum to do anything. Here is a fairly typical Main:
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
Here is the meaning of the various options (straight from "man yum.conf", in case you haven't read this yet). All options are of the form:
option=value
Note that most of the options can be left at the default and yum will function just fine.
In addition, there must be at least one [server] section. Note well that "server" here does not refer to a single physical machine, nor does it necessarily refer to a single repository, a server id (this is made clear in the man page for yum.conf). As such it is an arbitrary but unique label attached to a set of (usually identical/mirrored) repositories that will in general be on different physical machines to provide a measure of fallback robustness in operation.
Note well that yum creates cache directories according to the label in the [server] tag. If the fallback repositories are not in fact mirrors and consistent with the primary repository, odd things can be expected to occur that are very likely not going to be what you intended to happen.
Server sections inherit global options from [main], but also have options of their own. Consider the following example:
[duke-base]
name=Linux@Home $releasever - $basearch - Base
baseurl=http://192.168.1.2/dulug/$releasever/$basearch/
http://install.dulug.duke.edu/pub/dulug/base/$releasever/$basearch
gpgcheck=0
[duke-distrib]
name=Linux@Home Distributable add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-distrib/
http://install.dulug.duke.edu/pub/dulug/add-on/distrib/$releasever/$basearch
gpgcheck=0
[duke-nondistrib]
name=Linux@Home Nondistributable add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-duke/
install.dulug.duke.edu/pub/dulug/add-on/duke/$releasever/$basearch
http://localhost:33333/pub/dulug/add-on/duke/$releasever/$basearchgpgcheck=0
gpgcheck=0
[home]
name=Linux@Home personal add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-local/
gpgcheck=0
[ayo]
name=freshrpms
baseurl=http://ayo.freshrpms.net/redhat/9/i386/freshrpms/
gpgcheck=0
This example illustrates much of the power of yum. There are five distinct repositories indicated. The first, duke-base, is linux@duke's Red Hat 9 public repository. However, I use yum at home to keep my LAN up to date through a low-bandwidth DSL link. I have some ten computers that update nightly and don't want to have to move headers and rpm's through the link for each one. So I maintain a full mirror via rsync of this repository, and use it by preference rather than the repository at Duke.
Duke has two more collections of packages it provides in different repositories. One is open source/free add-ons to the base Red Hat distribution. This repository is open to the public, but less likely to be of use to people who aren't associated with Duke. I use some packages from this repository and so include in yum.conf, again first from a local mirror in my home LAN and from Duke through the DSL link only as a fallback.
The second repository contains packages that for one reason or another cannot be openly distributed. There are proprietary, site-licensed packages there, or packages with private data, for example. Although as a Duke faculty person I'm entitled to use these packages at home, only duke.edu addresses can access the repository. However, I connect via an ISP.
The [duke-nondistrib] entry thus tries to update from the home mirror (which I have to rsync via an ssh forwarded port). If this doesn't work it tries to access it directly (which might succeed on e.g. my laptop, if I've brought it into Duke). Finally, if neither of these work it tries localhost:33333, hoping that I've hotwired an ssh port forward at that address in case my laptop is not at home or at Duke, but I suddenly need access while I'm on the road.
The [home] entry is where I put those rpm's I build at home strictly for local/home distribution. This is surprisingly useful -- a good way to move around certain configuration files, for example, and there are a few packages I find to install that aren't maintained at Duke at all.
The [ayo] entry is a public rpm repository that contains one or two libraries that I need that aren't at Duke and that I don't want to build locally.
As one can see, yum can be amazingly powerful and flexible in the way that it is configured to use repositories (and their fallback mirros) in layers, each layer providing a different set of packages. Most yum clients will need a much simpler yum.conf than this -- in many cases one with a single server entry. However, systems managers who wish to install packages in layers from a common public repository and one or more private repositories will find that yum is designed to accomplish this in the most natural manner possible.