Re: up2date trick

On Fri, 2002-03-22 at 23:31, Nathan G. Grennan wrote:
> On Fri, 2002-03-22 at 20:05, Nathan G. Grennan wrote:
> > Hello,
> > 
> > 
> > I have found the solution to getting errata rpms almost as fast as they
> > are released to your Current server using up2date. Instead of waiting
> > for a mirror to mirror them, and hoping it does a good job and is fast
> > that day.

Based on your later email, I assume you mean pulling updates with
up2date/RHN, instead of up2date/Current.

> > 
> > up2date -uf -d --dbpath=/var/ftp/pub/RedHide/i386/.current/.redhat
> > --tmpdir=/var/ftp/pub/RedHide/i386/updates/7.2
> > 
> > -uf  to update and force downloading of all errata
> > 
> > -d   to download but not to install the rpms
> > 
> > --dbpath=/path/directory  where directory contains a the files from the
> > rpmdb-redhat package, which is a copy of a rpm database with ALL the
> > packages installed
> > 
> > --tmpdir=/path/directory  where directory is the directory you want to
> > store the rpms for Current

Only problem here is you're not going to end up with all the kernel,
gzip, and glibc updates in that copy of the rpmdb. RPM doesn't allow all
the different archs to be installed if the versions are the same (this
is the feature that made it impossible to base Current on rpmdb
directly), and I'm not sure how that is going to affect your method of
pulling down more recent packages. I think you'd only get the kernel
that matched whatever your server was, for instance, and then some of
your clients will go boom.


> > 
> > 
 To work around this you must manually download the second
> > update to up2date and install them manually. To do this with the fake
> > database use something like:

This is why there are no features in Current yet for "automatic" channel
updates. Its a tough problem and the more important it is for your
client machines to keep running, the more important it is for a human to
make those decisions, in my opinion.

> > You also may want to clean out your directory with something like:
> > 
> > rm /path/directory/*.hdr /path/directory/redhat-linux-*

Um, if you wipe out all the cached headers, when do you recreate them?
During the channel create?

> > I haven't fully tested it, but from what I know of up2date it should
> > cache the rpms in the download directory, so it shouldn't try download
> > all the rpms every time you use this trick. Though you will probably
> > need to clean the directory of the headers each time.

It would be better to not delete all the headers each time and to export
the package updating code in channel.py to cadmin. It _should_ be
possible to do what you want without doing crazy things like wiping out
all the cached headers. 

I'm not willing to do this code, but if you want to take a crack at it,
I'm certainly willing to answer questions and review ideas/patches.

(I'm trying to get the sql code checked into the next devel tree, and my
time is consumed completely by that)

> > By combining this with Current by using a script(which I have yet to
> > write) to run cadmin and the above commands every so often through cron
> > you should have a very up2date, efficient, and reliable Current server.

That would break every time RHN did. 
Or would break everytime you had local patches added which suddenly
conflicted with something new/different in RHN.

I'm not saying this is a terrible idea - I'd love for this to be
automatic as much as anyone. But I think everyone should know its not
going to be flawless.

> Addendum
> 
> I forgot to mention one very key point, getting the $60 RHN Entitlement.
> Which is a major part of my original reason for figuring this out. With
> many servers on the same network you could have them all connect to RHN
> using Free Entitlements by signing them all up under different accounts.

Thats wrong, and if RH caught you, I'd support them in dropping you like
a bad habit. See below for alternative.

> This is somewhat dishonest, and also has the major drawback of now when

Somewhat? No. Its fraud, pure and simple. Reread the RHN user policy.

Turn this around. If you're going to use up2date itself to update the
Current servers, why do each Current server have to pull from RHN?

Just have one, free, RHN account, as per the RHN policy. 

Have that account feed your main Current server. Fast updates there.

Have that main current server feed the others, on an hourly basis. You
would still be pulling Current updates using up2date. And now you're not
violating the policy. If an hour or two makes a difference on your
network:

a) you're doing something wrong
b) you shouldn't be using Current - your needs for immediate updates  
   preclude using a (new) system that is single threaded.


> more and currently doesn't have many real advantages unless you are
> managing Lots of servers. They do plan to have what they called RHN

I had a much longer, more detailed email, but I've decided (just now)
that I'm not going to comment on anything RedHat does with RHN. That is
their product, and what they do with it is their business. I'm in an odd
situation in that I've written an open source server, yet I very much
want RHN to be money making, because I'm a shareholder. So I'm just
going to be quiet.

-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.