Re: up2date trick

On Fri, 2002-03-22 at 22: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.
> > 
> > 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
> > 
> > 
> > There is currently a pitfall with this idea. As was mentioned on this
> > list a few days ago a new updates to the up2date and rhn_register
> > packages. The original version was up2date-2.7.2-7.x.6 for RedHat 7.2.
> > The first update was up2date-2.7.11-7.x.2. The second update from a few
> > days ago was update-2.7.46-7.x.2. But their was a glitch in the second
> > update which caused them to retract that version. So the RedHat up2date
> > database(Oracle) only knows about the first update. If you happen to
> > have updated to the second update through up2date before it was
> > retracted or manually by downloading it from a ftp site, then try to
> > install up2date-gnome using up2date it will have a version conflict. But
> > that is not the problem with this trick. Another side effect of this
> > retraction is that if you are still running the original version of
> > up2date and try to use up2date to update up2date or all your packages it
> > will currently get stuck trying to update up2date because of a missing
> > header file. 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:
> > 
> > rpm -U --justdb --dbpath /var/ftp/pub/RedHide/i386/.current/.redhat
> > up2date-2.7.11-7.x.2.i386.rpm up2date-gnome-2.7.11-7.x.2.i386.rpm
> > rhn_register-gnome-2.7.2-7.x.2.i386.rpm
> > rhn_register-2.7.2-7.x.8.i386.rpm
> > 
> > where
> > 
> > -U to upgrade
> > 
> > --justdb   to update the database but not install the files or run the
> > scripts, which would be a very bad thing
> > 
> > --dbpath   using the directory where you copied rpmdb-redhat to, also be
> > sure not to use a = like with up2date
> > 
> > 
> > You also may want to clean out your directory with something like:
> > 
> > rm /path/directory/*.hdr /path/directory/redhat-linux-*
> > 
> > 
> > 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.
> > 
> > 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.
> > 
> > 
> > 
> > Step by step for RedHat 7.2 i386:
> > 
> > rpm -i
> > ftp://fr.rpmfind.net/linux/redhat/7.2/en/os/i386/RedHat/RPMS/rpmdb-redhat-7.2-0.20010924.i386.rpm
> > 
> > cp -a /usr/lib/rpmdb/i386-redhat-linux/redhat /tmp
> > 
> > rpm -U --justdb --dbpath /tmp/redhat
> > ftp://fr.rpmfind.net/linux/redhat/updates/7.2/en/os/i386/up2date-2.7.11-7.x.2.i386.rpm ftp://fr.rpmfind.net/linux/redhat/updates/7.2/en/os/i386/up2date-gnome-2.7.11-7.x.2.i386.rpm
> > 
> > ftp://fr.rpmfind.net/linux/redhat/updates/7.2/en/os/i386/rhn_register-2.7.2-7.x.8.i386.rpm ftp://fr.rpmfind.net/linux/redhat/updates/7.2/en/os/i386/rhn_register-gnome-2.7.2-7.x.8.i386.rpm
> > 
> > 
> > mkdir /tmp/errata
> > 
> > up2date -uf -d --dbpath=/tmp/redhat --tmpdir=/tmp/errata
> > 
> > rm /tmp/errata/*.hdr /tmp/errata/redhat-linux-*
> > 
> 
> 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.
> This is somewhat dishonest, and also has the major drawback of now when
> a new errata gets released on RHN the free accounts get throttled off
> till the load goes down. This is pretty much guaranteed just after each
> announcement these days. You could pay $60 per server, but that quickly
> becomes expense, 60 * N = X = Ouch!  You pay $240 per server, 240 * N =
> Quad Ouch!, for their premium service, but that really just costs you
> 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
> Satellite which will be a personal offline clone of what RedHat has at
> their offices. From what they have said this will cost somewhere over
> $25,000 US to get. You provide the hardware, they set it up, and ship it
> back to you. They also plan to have RHN Proxy, which will basically
> download the rpms once, and feed them to the client as necessary, but
> still store profiles in the RHN database so that you can manage them
> through their website. They plan RHN Proxy for people with 50+ servers,
> and plan to charge $25,000 US, which is why I said RHN Satellite will be
> somewhere over $25,000. They have said they are planning a version of
> RHN Proxy for small organizations, but I haven't gotten any details
> about the smaller version. Which is why I think the most reasonable for
> me is $60 entitlement + scripts to implement the above trick + Current
> is definitely the way to go for me. You get the all the advantages of
> RHN Proxy, except for being able to manage servers through their
> website, for a Fraction of the price.
> 
> 
> It seems RedHat is being a little odd with the RHN. They yesterday
> admitted they won't be open sourcing the RHN server software. Which I
> took to mean the RHN Satellite software. It is still unclear if that
> includes RHN Proxy, but I think it will be closed source also. Their
> reason for this is because it is software used to provide a service. To
> me this means, they don't want to give out the software they wrote and
> have competition providing RHN like services. Which to me is a sad sad
> statement, since RedHat has always bragged about being completely Open
> Source. They did also mention their distribution build tools in the same
> breathe, another thing they haven't release source to. I also suspect
> that since they are using Oracle, and probably have had to tie into
> Oracle interface libraries, they might not have a choice in releasing it
> Open Source. They have talked about converting it to something like
> Postgres in the future, but currently Oracle is the only database that
> will handle the work load of providing RHN service to all their
> customers. Which may also mean they might convert RHN Satellite to
> Postgres in the future, since it won't need to work under such a huge
> workload, once they get around to it.
> 
> They seem to be basing most of the value/cost of RHN around it's
> manageability. Hence why you pay $60 each for fast and reliable
> downloads, yet pay $240 each for the ability to manage the servers in
> groups. I think they need to seriously reconsider this. I originally
> understand it that it was going to be $60 each and $240 for a
> group(either a set number of say 10, or near infinite). This seemed very
> practical to me. 4 or less, you pay $60 each, for more you get a
> discount for more, much like how corporations get site licenses from
> Microsoft at a big discount for what they would pay for each copy of
> Windows. I see RedHat's philosophy as gouge corporations on one side,
> and provide it pretty much free to the masses. My problems with this is
> just how much they seem to want to gouge corporations. In the process
> they hurting themselves when trying to compete with Microsoft in the
> server market and how their strategy has negative side effects on the
> masses.
> 

Update

They appear to have fixed the bug in the RHN database having to do with
the first update to up2date for RedHat 7.2. :) So updating the fake
database manually with the first update is now unnecessary.