Re: Re: master server and other ideas

On Thursday, July 24, 2003, at 01:52 AM, Steve Arnold wrote:
> Last night on #gentoo-server, spoob brought up this link:

Hi. :)

> So I think if we develop our requirements a little, we can build a 
> usable concept for large-scale deployments/maintenance of both gentoo 
> and other distros...

This is what I would like to do with Gentoo, for my job. This means I'm 
getting paid to work on this kind of stuff so I should have the time to 
devote to this. :)

> Zope aside, I think the infrastructures concept is exactly what we 
> need; looking forward to lots of feedback :)

I did something very similar in my last job (as systems/network manager 
for JORN), and it does work. It would be good to see the concept 
developed into an easy-to-deploy tool, which should do a lot for 
promoting Gentoo as a solution in search of a problem. :)

Setting up CVS is the first step, and the first items checked into the 
repository are the Gentoo ebuilds that created the system from the 
ground up, and preferably the source code as well. This functionality 
is needed so that machines built at different times don't just check 
out the latest files, but groups of machines all use the same versions 
of files.

When this is complete (which hopefully isn't much more than checking 
out CVS from Gentoo at strategic times), then extra areas are created 
to hold configuration information for ebuilds. Then the last bit is to 
create ebuilds that have dependencies on the right packages (eg, 
server-ldap depends on openldap) and connect to CVS to overlay 
configuration files.

This brings up one of the engineering tradeoffs: script configuration 
or file configuration? In my experience, scripted changes are harder to 
write, but clearer and handles system upgrades better. Overlaying 
configuration files is easier to set up and handles a wider range of 
changes, but is more brittle over time.

If the infrastructures.org paper has wetted your appetite, there is 
another paper on the same site that goes into detail about order of 
changes being important. The quick summary is that if you make changes 
to the system in X Y Z order, then you may not end up with the same 
system if you make those changes in Y X Z order. This, in a nutshell, 
is what's wrong with cfengine.

The solution I used was to split the configuration scripts into half - 
one group of scripts handled building the machine, including 
partitioning, formatting and other things that can't be changed while 
the machine is operational. Any changes to the configuration in this 
area would require a complete machine rebuild.

The other group of scripts could be run on an operational machine and 
would handle making already running daemons reload configuration files. 
It is possible to handle reconfiguring entire groups of machines on the 
fly, using the same code path as rebuilding them from scratch. This was 
one of the core capabilities that ensured that running machines that 
had been updated a few times wouldn't fail when rebooted or rebuilt.

I can go into a lot more detail about how the files are arranged in CVS 
and the balance between scripting and file storage is handled, but I 
would like to read the reactions to the above first. There isn't a lot 
involved in getting this off the ground, especially with Gentoo 
adopting generally the same approach everywhere else, so this should be 
a good project with quick results.

--
   [email protected]

CRICOS Provider Number 00123M
------------------------------------------------
This email message is intended only for the addressee(s)
and contains information that may be confidential and/or
copyright.  If you are not the intended recipient please
notify the sender by reply email and immediately delete
this email. Use, disclosure or reproduction of this email
by anyone other than the intended recipient(s) is strictly
prohibited. No representation is made that this email or
any attachments are free of viruses. Virus scanning is
recommended and is the responsibility of the recipient.


--
[email protected] mailing list