[Yum-devel] ready to help dev yum

[mark_yum at tcu-inc.com]

> > 2. Develop a webpage interface to a yum server for computers to use.
> >         I think everything should
> > 	be in the repository for the client side program (yum) to work with.

> Ah, but of course. :) About a year and a half ago we have all banded
> together (seth, mstenner, and me) and brainstormed about a way to make a
> fine replacement for all functionality of RHN without introducing the
> bad things that it carries with it. The end-result was the idea of a
> project called "Redux," which is a distributed network of machines,
> communicating over smpp (i.e. jabber), using a system of
> cryptographically signed action sets. I've even wrote some basic code
> for it, but then other tasks took priority, and I never managed to get a
> non-proof-of-concept stuff out.

I haven't looked at the code, but I looked at the description. 
It seems similar to something I did here at work. 
This is what I did, and I wrote it in Python:
1. Assume the computers have been kickstarted.
2. Each computers runs a script which connects to the main server asking what
	it should do next. If nothing, it sleeps for 5 minutes. 
	Here are the steps which is needs to do:
	a. Install database -- only db machines
	b. Setup hot standby database servre -- only primary and secondary db
	c. Install data and customer software -- all computers
	d. Start replication -- db machines
	e. Start software -- all computers

All I used was a webserver which had all the information of the computers. 
I also used Expect scripts to detect when steps were completed correctly. 

This sort of seems similar to what you have. 

The thing I want is:
a. kickstart computers.
b. After kickstart, computers routinely (doesn't have to be immediate) 
	1. execute arbitrary commands, or a predefined list of 
		commands (for security reasons) from the main server
	2. install rpms from the main server

Since installing arbitrary rpms is a security risk (rpms can execute 
any command), then executing arbitrary commands isn't more of a security
risk. If the server's rpm list gets compromised, then it is just as bad. 

Also, if they main server gets overloaded with pull requests, you just
make more servers or proxies. 

I like the idea of doing a push, but then it has to be done with preset list
of defined commands that can be executed (if you want any security). Or, put
it in a non-root account, but then you get locale exploit possibilities. 
The big problem is, if you install the preset list of commands with rpms and
your rpms get compromised (hence the preset list gets updated with bogus
commands), you are screwed. 

The only way I can think of to accomplish pushing commands is this:
	a. Setup yum to never update certain rpms. This can reduce but
		not eliminate security issues (just rename the compromised
		rpm). 
	b. Use a preset defined list of commands that can be pushed. The rpm
		that has this list can be restricted in terms of being
		updated (but this really doesn't do anything). 

I think I would like to take up something simialr to redux, but first to 
design it for pull technology (like I already have done), then to design
it with proxies (to offload the request load), and then to do the
push. I don't see push technology being the top priority since it would really
be just for executing arbitrary commands. In terms of monitoring systems
on a routine basis, just create plugins for ganglia and nagios. 

So, I probably wouldn't program "redux" the way you currently have it. 
monitor your systems. 

I think I would like to start out doing it in this fashion:
1. Setup a server to do kickstart and updates:
	a. using yum
	b. Keeps track of rpms for groups of computers
	c. Has accounts which can:
		1. give permission for which computers you can manage
		2. give permission to push an rpm along different channels
			a. Dev to QA to QA approval to Production to
				a channel for a group of computers
	d. Can issue commands before or after rpms are installed and get 	
		a response back. This will be tricky. This means 
		keeping track of individual computers. 
2. Besides dealing with rpms, issue arbitrary commands immediately. This
	can be tricky. Wrap the predefined list of commands into an rpm. 

Thank is what I am thinking of. 
I will look at the redux code, and I will probably start on this project
next week using yum as its core. I also don't mind to work on yum, since I
might need to add stuff to yum to get this to work. The stuff I would want
to add to yum have already been discussed in the mailing lists. 

Does this make sense? Doesn't it seem like a massive amount of people
could use something like this?

Mark