Date: Thu, 11 Jan 2007 12:00:03 -0800 (PST) From: Lamont Granquist <lamont@scriptkiddie.org> To: Vulpes Velox <v.velox@vvelox.net> Cc: hackers@freebsd.org, David Nugent <davidn@datalinktech.com.au> Subject: Re: LDAP integration Message-ID: <Pine.GSO.4.60.0701111136440.2433@sploit.scriptkiddie.org> In-Reply-To: <20070111035549.7c11a450@vixen42> References: <60737.24.71.119.183.1168496463.squirrel@webmail.sd73.bc.ca> <45A5EA3B.9020000@datalinktech.com.au> <20070111035549.7c11a450@vixen42>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.60.0701111136440.2433>