RE: rhn_register / up2date hacking

On Wed, 2002-05-29 at 17:16, Anthony Mendoza wrote:
> Instead of modifying the clients, I made a script that I run on a new client that drops 
in my key, and updates /etc/sysconfig/rhn/up2date & rhn_register with the info for my current 
server.  I end up still doing the manual registration process though...  I then run my 
config script whenever the up2date / rhn_register rpms get updated and my script is 
independant of those RPMs..

Having to rerun a config script is exactly why most of us rebuild the
rpms. Current (and gromit) are largely exercises in wanting to never log
in to remote computers to admin them.

> 	
> 	you could use lvs for multiple servers, or if you had the money and 
resources use an alteon load balancer, with lvs you could just have one of the current
 servers be the load balancer to 1 other or a few other current servers, and load 
balance by wieght or round robin.....just an idea
> 

Uh, thats not quite what I meant.

apt-get can have a list of multiple servers _on_the_client_, so that if
someone says 

apt-get install foo

it'll look at each server in turn until it finds one with foo available.
(I think it even queries them all to find the newest foo)

What that means is that a client can look at multiple redundant servers
AND can hit different servers for different kinds of packages.

up2date can't do that right now - its kinda hardwired for one server and
one server only. However, reading through the rpmsources.py file, it
looks like it might not be too horrible to add that. 

You'd have one source per server. The only tricky bit would be teaching
it how to do proper dependancy resolution. I think the best idea there
is to figure out which server you want to get the package from, and then
do all your dep resolution against that one server.

rpmsources.py might not get you completely out of the woods either - I
think you'd have to invent some mechanism to get a concatenated
packagelist from EACH server to know where to begin.

For extra added bonus pain, you could figure out how non-anonymous
clients could use one non-anonymous server and multiple anonymous
servers.


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