[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[K12OSN] Re: up2date problem SOLVED

On Tuesday 13 January 2004 05:10, Randall Swift wrote:
> I have tried to update the server (k12ltsp 4) using up2date.
> The process works for a while and stops at the "Fetching rpm
> header: glibc-2.3.2-101.4". I have tried this nemerous times
> and the same thing always happens. Any thuoghts? Thanks

On Tuesday 13 January 2004 10:16, Ken Barber wrote:
> I've been having problems with up2date for about a week now. 
> It appears to me that this problem is being caused by servers
> at RedHat becoming overloaded with update requests.

On Tuesday 13 January 2004 11:09, Les Mikesell wrote:
> If you can find a less loaded mirror that is up to date
> wouldn't it be better to change your apt/yum configurations
> to use it?

But the problem with Les' answer (above), as I saw it, was that we 
need a *repository*, not just any old mirror.

Subsequent research led me to this nice article, apparently 
written by one of yum's maintainers:


... wherein I learned that anyone can become a repository by 
downloading the updates (presumably via rsync) and "yummifying" 
the directory that holds them.

There is a fedora mirror near me (VERY near -- my ISP has a direct 
connection into the OC-3 backbone of the Oregon University 
System, and UO is a fedora mirror!).  So of course my next 
question was, "how can I tell whether a particular fedora mirror 
has been yummified?"  Or maybe I should just ask, "How can I tell 
whether this is a yummy mirror without tasting it first?"

Well, I still don't have the definitive answer to that one, but it 
appears to be the presence of a directory called "headers" that 
makes the difference.  That directory is there on UO's mirror, so 
just for grins I modified the pertinent sections of my yum.conf 
file thus:

name=Fedora Core $releasever - $basearch - Base
name=Fedora Core $releasever - $basearch - Released Updates

... and tried "yum update" again.

SUCCESS!  Watching with netstat (as if the incredible boost in 
download speed wasn't enough evidence) confirmed that yum was now 
getting its updates from the University of Oregon (about 30 
blocks away from my house) instead of redhat's overloaded servers 
on the other side of the continent.

Note that yum works with ftp as well as http.  It also works with 
nfs or directly from a local filesystem, for those who wish to 
set up their own in-house repositories (good idea).

You know what?  If you set up your own repository, you can build 
your workstations with a yum.conf that points only to your 
in-house repository and then run yum in cron.daily.  VOILA!  All 
you have to do is add an update to your repository (and 
re-yummify it), and every workstation in your enterprise is 
automatically updated that night.

Contrast that with what it takes to keep Micro$oft workstations 
patched....  With yum, you can keep thousands of workstations 
patched simply by dropping a file into a directory on a server 
and running a command.  If you use kickstart, you can even add a 
yum update to the end of the install, and your workstations are 
already up to date before they reboot!

This is all very cool, and I am confident that everyone else's 
updating problems will go away if you'll try the same thing with 
a mirror near you.  Now all this talk of yummy stuff is making me 
hungry, so go ahead and try this while I go make a yummy peanut 
butter & jelly sandwich.

"If you think of yourselves as helpless and ineffectual, it is 
certain that you will create a despotic government to be your 
master. The wise despot, therefore, maintains among his subjects 
a popular sense that they are helpless and ineffectual."
	-- Frank Herbert, "The Dosadi Experiment"

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]