On Wed, 10 Jan 2007, Vulpes Velox wrote:
And if you're looking specifically at the /etc/rc.conf config file,
what would be more useful would be an /etc/rc.conf.d/ directory.
That gets away from the need to tweak and edit the /etc/rc.conf
config file with multiple inputs tweaking a single file. Instead
you can drop whole orthogonal fragments into /etc/rc.conf.d/inetd
to manage the inetd config which would make it more friendly to
radmind-like approaches. It also makes it easier to use with
cfengine since orthogonal cfengine modules aren't doing editfiles
touches to the same files. The /etc/cron.d directory that (most?)
linux distros have is similarly very useful to drop in files that
contain completely orthogonal config (and may be written by
entirely different config management tools -- e.g. system config
management vs. application deployment/management), and
the /etc/periodic functionality is not flexible enough to cover all
cases.
This honestly sounds like a massive and complete pain in the ass. I
don't even see how this is remote admin friendly. It just means way
more to muck around with.
If cfengine can not generate rc.conf in a nice manner, it seems more
like a problem with cfengine.
Actually, cfengine is perfectly capable of doing that, it has an obscenely
flexible ability to edit files 'in place' to do this kind of tweaking and
tuning to manage monolithic config files like rc.conf or inetd.conf which
may have orthogonal configuration inputs from different apps running on
the machine. The problem is that with orthogonal inputs to the same
config file it becomes more likely that entirely seperate pieces of config
will be twiddling the same file, and those pieces of code will be built
and maintained by entirely different people and that increases the chances
of simple file editing errors. Once you start hitting the problem of
dozens of system admins trying to collaboratively manage 1000s of systems
these kinds of issues come up. They're not apparent when you've got
single administrative owners for all the machines.
The radmind model of system configuration alone, however, doesn't let you
do this since it is built around pushing only whole files. You can
construct all the different flavors of the monolithic files that you're
managing and try to make sure that the correct image gets on the correct
system but that requires higher-level wrapping -- or you can just have
radmind call out to cfengine to construct files like this. Still,
avoiding monolithic files makes system configuration friendlier to those
who use the radmind-approach.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
