Francois Visconte wrote:
Hello
To the OP, I would keep everything centralized and in a repository.
Then dedicate a test machine, or two, that you will use to deploy
your updates and test the integrity of your automation system. If all
goes well with the test, push the tested updates over to the
production repos. That particular production system should
automatically pull the updates on the next scheduled system update
via cron or some custom polling system. If the updates crap out the
production server, you can then revert your changes in the repos, the
server will pick up the revert, and everything will be back to the
original, hopefully. The only tricky part, for me to grasp, is how to
execute a set of actions before/after updating/adding/deleting a
system file if needed?
I am working on an automation system that will commence from OS
installation. For instance, all the questions asked during OS
installation can be placed in a config file on the central repos. To
initiate an installation, run bsd.rd via CD or PXEBOOT. When asked
whether to run install, upgrade or shell, run shell. Then ftp your
system build script to the bare system and run it. The script will
then run the installation for you and build you a base system,
filling in the blanks. It will then "customize" the system by pulling
individual updates meant only for that server. Command line interaction:
That's what cfengine do:
- a simple daemon on the client hosts,
- a set of spec file that contains, what to do, in which cases
(machine type, service provided, os type ....)
- a set off predifined actions desined to be portable (packages
install, file modes ...)
- a reference repository to store config files and other file
(under a source control repository)
an example of spec file :
control:
any::
inform = ( on )
domain = ( foo.org )
actionsequence = ( shellcommands )
shellcommands:
any::
"/bin/echo Hello World"
openbsd::
"/bin/echo Openbsd Host"
We use it for our servers and machines and it works great, (about 70
servers and 150 workstation ).
Setup for such and infrastructure is not trivial but far less
complicated than tons of scripts...
To feet your needs, you can create another install set conaining
cfengine and distribute is accross your managed machines
So cfengine would need to be included in an install set, such as
base40.tgz or some custom install set? If that's true, which it
obviously is, then I don't have much use for cfengine because I would
like to automate the install process as well as the upgrade process. If
cfengine can take me from a bare bones system to fully function server,
let me know.
I am currently working on the automated install script and it is fairly
simple. In fact, once it is setup and talking to a central repository
for install purposes, making it also perform updates will be a breeze.
I will look into cfengine. I always figured it was one of those bloated
apps that did about 90% of what you needed, dropping the ball on the
last and most complex 10% of the task. For that last 10% you usually end
up building a custom solution. Can others comment on cfengine? How many
managed boxen? What are its quirks, pros, cons?
-pachl
