[Yum] some specific questions regarding yum.conf

[Robert G. Brown]

On Mon, 22 Sep 2003, Robert P. J. Day wrote:

> 
>   since this is a critical part of getting basic yum to work
> properly, there's a few things i'd like to clarify.  (and
> i won't quibble over terminology for now.)
> 
>   first, what's the rationale for multiple [server] entries
> in /etc/yum.conf?  just for redundancy?  or, from what i can see,
> different [server]s can have different groupings of RPMs.  as in
> base, updates and so on.  so this would represent a mutually
> exclusive set of [server]s, or maybe not?

This really should be read as multiple [serverid] entries, or if you
prefer multiple repositories.  Each repository requires a unique
identifier, used to create /var/cache/yum/serverid (the location for
yum's caches of headers and rpm's for this repository).

There are some really good reasons for permitting multiple repositories.
I discuss some of them in great detail in the HOWTO, which is now about
2/3 purged of backwards references to server/repository (so from now on
server is a physical box, repository is a tree containing rpm's, and
[serverid] is retained as the LABEL of a repository, at least
unless/until Seth changes primary yum.conf documentation to refer to
repository sections and calls it e.g. [repositoryid] to label each one.

I expect to reinstall the online request-for-comments HOWTO in a few
hours.  I'm resisting reinstalling incremental changes as I work since
then it will be inconsistent AND broken instead of just broken.

>   and related to the above, what about multiple baseurl's?
> again, just for redundancy, which is what it appears.

Yes, each repository can then have multiple baseurl's for fallback
redundancy.  These "should" be de facto functional mirrors if the
primary repository/baseurl, although I've discovered the hard way that
if they're not, yum won't fail but "interesting" things will happen.
Probably not what you meant to happen, but interesting...:-)

>   next, should all [server] entries in a single yum.conf
> be appropriate for that linux box?  as in, if i'm on a RH 9
> system, should *every* single [server] entry in my yum.conf
> file refer to a RH 9 repository?  what if it doesn't?  is yum
> smart enough to realize something is amiss?  or is this just
> undefined and probably really boneheaded behaviour?

Here I will defer to higher powers who can likely answer in detail.  I
>>think<< that it is caveat user -- if you put a mish-mosh of rpm's
built for various architectures into a yum repository, yum will do its
darnedest to install them and update them consistently, but that
ultimately it relies on rpm itself and the builders of the rpm's and the
maintainer of the repository to have proceeded in a sane and deliberate
manner.  Some rpm's will install across distribution versions, some
won't.  In general it is probably better not to, but don't see why yum
wouldn't do it.  Yum will, I'm pretty sure, help keep you from replacing
a newer rpm with an older one, however.  If it can tell (see part about
sanity on the part of the rpm builder).

>   (as an analogy, most folks know they can have a single,
> global /etc/sudoers file that's appropriate for all hosts in
> an organization.  can the same be done for a single, global
> /etc/yum.conf file?  i'm guesssing not.)

Sure, why not?  You still have to get the file onto all clients, but
that's just a matter of putting it into the yum rpm you distribute to
those clients.

I'd say most users of yum do precisely this.

A very few might use this as a base and add a public repository
"elsewhere" where one or two favorite rpm's are maintained, if they have
privileges to do so.

Note that regardless, yum pretty much requires root privileges to
operate.  It has to write in /var/cache/yum even in its informational
modes.  So most users have no choice -- they use the yum.conf their
sysadmin installed for them.  It is also obviously unsafe to make this
sort of thing an sudo enabled privilege to users who aren't fully
trusted.  Let me install an arbitrary package onto any system and I will
become root as fast as you can say "suid root script rpm" in sanskrit
backwards three times.  yum is deep juju and hence a bit dangerous.

>   third, what if a baseurl doesn't represent an actual URL?
> as in, when i tried playing with yum earlier, from my severn
> box, the $releasever variable seemed to be "9.0.93", while the
> corresponding repository at dulug was, instead, "severn".
> this caused a simple "yum list" to fail, even after i added
> a valid (download.fedora.us) 9.0.93 yum repository at the
> end of that file.
> 
>   should i have expected this behaviour?  why wouldn't yum not
> just give up on the bad baseurl and keep on going?

An excellent question.  I have encountered the same problem.  I'd even
call it a bug -- yum should not crash if a URL fails to resolve or a
repository "suddenly" is restricted.

>   finally, i'm guessing that one can incorporate the [server]
> value in subsequent commands, yes?  rather than let yum just 
> start at the top, i recall someone earlier mentioning "grouping",
> but i have no idea what that is, so i might be way off base.
> 
>   (that is, i skimmed the options and arguments to the "yum"
> command, and i didn't immediately see any invocations that
> involved actually specifying an individual [server] name.)

Can't help you here.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu