lamont at scriptkiddie.org
Thu Jan 11 20:21:47 UTC 2007
On Thu, 11 Jan 2007, Vulpes Velox wrote:
> I vote both are completely stupid. LDAP is nice organizing across
> many systems, but if you are just dealing with one computer it is
> complete over kill for any thing. Splitting rc.conf up into
> multiple files is just plain messy and stupid as well. I can see
> there being times when it is split into two, but I don't see any
> reason for more than that.
When was the last time you worked on a configuration management system
which maintained 30,000 servers and had ~50 people with commit access to
In such a situation you wind up with multiple people managing horizontal
slices out of all of the machines. You no longer have the model of a
single admin for a single server who knows everything about the config of
a given machine. In that situation it becomes very useful for admin #1
who is managing a particular aspect of the config to be able to drop a
file like /etc/rc.conf.d/foo and admin #2 who is managing a different
aspect of the config to be able to drop a file like /etc/rc.conf.d/bar.
Having both of them editing /etc/rc.conf opens up the very real possiblity
of having simple editing conflicts which corrupt the file.
What I'm talking about with splitting up /etc/rc.conf isn't really
orthogonal to anything that you've written about LDAP, however. You don't
have to attack this idea just to make LDAP sound good.
> There are plenty of nice ways to access and modify LDAP data. I would
> say it is easily as friendly as editing text files to be pulled
> I fail to see how LDAP is not a standard tool. It is a tool that is
> really under utilized.
In general database-driven configuration management is under utilized,
I'll agree with that. LDAP is the first tool that you're going to pick up
to do that, but I think its utility for the generalized problem is not as
large as you think it is.
> What this gains is being able to store a lot of configuration stuff
> in the same place. It makes permission handling a lot easier as well.
> If you store it in a file any one with write access can edit it, but
> with LDAP it can assign write access to specific attributes. With
> files you would have to split it up across multiple files.
I simply don't understand why you want to start picking up raw
configuration data on the end host and dumping it into LDAP. That doesn't
solve a problem. I don't need host-by-host rc.conf variables or systls
exposed through a database interface. I can use labels inside of cfengine
to define roles which cause all kinds of actions to be taken, including
setting /etc/rc.conf, setting sysctls, pushing scripts, managing daemons,
mounting filesystems, etc, etc. What becomes useful is having those
labels put into a database, not the results of the config itself.
You could try to generate a completely database-driven configuration
management language. So that in your schema for a given role you would
attatch not only /etc/rc.conf information, but all the sysctls, daemon
management, filesystem mounts, etc. But then the scope of what you're
doing can be looked at as taking a cfengine configuration file (defining
all the given config management steps taken for a given role) and putting
it into a database. Without going all the way what you're trying to build
isn't going to be very useful and I don't see the driver to do all that
work. What is the compelling use case for taking the existing cfengine
language (or any other CM language, e.g. puppet) and making it entirely
More information about the freebsd-hackers