Re: up2date trick

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.