RE: rhn_register / up2date hacking

ahhhh, i understand what you mean now, and i cannot help with that. i dont know where to start 

	-----Original Message----- 
	From: Hunter Matthews [mailto:[email protected]] 
	Sent: Wed 5/29/2002 2:29 PM 
	To: Current Server Mailing List 
	Cc: 
	Subject: RE: [Current-server] 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.
	
	_______________________________________________
	Current-server mailing list
	[email protected]
	http://lists.dulug.duke.edu/mailman/listinfo/current-server