This one time, at band camp, O Plameras wrote: >1. Given a specific server in the network, can remember exactly previous >configurations >for 3 generations (parent, grand parent, and great grand parent) along >with each file in >each of those generations. >2. Given a specific server in the network, SysAdmin must be able to >revert back to that >generation along with each file in that generation through an operation >or a set of >operations availble in the systems.
those last three are tough problems, but should be theoretically possible with either full dumps of the system before and after changes, or using some sort of delta algorithm. I think isconf does somethign close to this though -- at least in the forward direction. I don't have that requirement for rollbacks though, I test on a small set of machines before rolling out new changes, changes are always small and manageable. It's not a perfect method but it works. >3. Must be able to effect change of Operating Systems from older version >to a newer one. >Because of item 2. above the reverse will be possible. cfengine and isconf are two tools that spring to mind for this task. I'm using cfengine on a production network of 30ish machines with good results. Actually, I think I misread this one. You mean operating system versions and not configuration versions; in that case I'm not sure I trust any software to do this automatically for me, yet. That said, I've had cfengine work smoothly on machiens that have been live upgraded from RH 7.3 to RHEL AS 2.1, RH 8.0 through 9.0 through RHEL ES 3, and Debian woody to sarge. >4. Must be able to effect change of Operating Systems of one type (say >MS XP to Linux). youch. What you want is something like cfengine for NT, class-based rules for configuring services, and somethign thats going to be able to copy user data between the two. the first part might be easy, the last might be hideous depending on the level of migration you want. >5. Must be able to effect change of Applications (delete, add, or a >combination) for a given >server in the network. cfengine again; servers on our network that are part of the, say, ftp server class, have their installed packages list checked, and packages installed. I don't do the reverse, because whilst I can guarantee that I need to install and configure a service on a machine, I can't guarantee that a machine that isn't part of a class isn't supposed to have that service configured. At least, not yet (lots of auditing involved) >6. Etc. that is to do with any management of changes in the server of >the network. Um. >7. Source Codes must be GPLed. www.cfengine.org :-) -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
