Steve Wray wrote: > I agree that once a set of hosts are under cfengine control and > converged the need is much reduced, but what a lot of people tend to > forget is that bringing hosts to convergence takes a lot of careful > examination of how each host is configured; finding the implicit classes > and making them explicit.
Yes in my experience with migrating to CFEngine its pretty useful to know the state of your system before you start enforcing rules on it here, there and everywhere. That can be especially true if you are trying to fight with boxes that have been set up over a long period by different people like I have to ;) Its pretty dangerous in CFEngine sometimes to say "oh it should be like this, make it so" without being sure what you are changing: and thats no surprise since it is also the case when you are changing a system manually! There is no direct way for the server to collect data I think but you could run a script locally via CFEngine to collect the data and either dump it on an remote NFS mount point on your central server or have it send the data to a mail address. At the mail address you can just put a .forward file that calls a shell script to handle the data. I use that for collecting a "snapshot" of the system state (configuration, packages installed, memory, cpu, etc) every day and it works fine - my script just sticks them on a web page for me automatically. Of course if you want to kick this off intraday why not use cfrun from the CFEngine server and restrict the actions of cfengine using a class on the command line. _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
