Re: up2date trick

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

Right

> 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.
>

Yeah, this is something to work on. I might be able to fake it by going
through multiple passes and changing the rpmdb or configuration options.
 
> 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.
> 

That is a matter of opinion. By only letting a human add updates to the
Current server you expose yourself to errata longer unless you live just
to update it. Also totally automating it with a script was just an idea.
I think using this idea to just get all the rpms manually is also a good
idea for the same reasons I mentioned in the first place, not wanting to
hunt for a mirror.

> > > 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 delete them because I thought they weren't needed and they clutter the
directory. Current seems to be perfectly happy to accept just the rpms
off the CD, so why have the headers? It may affect how up2date acts, but
I haven't tested that. 
 
> > > 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)
> 

Again, why do I need the headers for Current when just raw rpms work?


> 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.
>

How would this break RHN? How would local patches affect this? I always
use the rpmdb, not the system rpm database.
 
> > 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.
> 

You obviously didn't read this very closely, or I must have been really
tired when I wrote it. I meant to describe what was possible and then
show the problems with doing it that way. In the end I was trying to
show why it could be in anyone's best interest to buy a $60 entitlement
and to use Current.

> 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.
>

Ok
 
> -- 
> 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.
> 
> _______________________________________________
> Current-server mailing list
> [email protected]
> http://lists.dulug.duke.edu/mailman/listinfo/current-server