LDAP integration

[Lamont Granquist]

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 
it?

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
> across.
>
> 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 
database driven?