LDAP integration

David Nugent davidn at datalinktech.com.au
Thu Jan 11 17:08:26 UTC 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.
>   
This is a UI issue. I personally prefer one file, I don't have to wade 
though directories searching for any specific knob. :)

> 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.
>   
.. and can be scripted in a variety of languages.

> I fail to see how LDAP is not a standard tool. It is a tool that is
> really under utilized.
>   
Because it is a tool that incurs a cost to learn, configure and deploy. 
I'm not denying the benefits at all. But I think it must be an option, 
at least until the advantages gain momentum.

> 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.
>   
Again, there is a cost. You would be adding a third security framework 
to an ldap enabled system (we already have unix credentials overlaid by 
the MAC framework to which we add ldap directory rights), and they need 
to relate in some way since they are dependent when supporting a 
consistent security profile.

LDAP ACLs and understanding issues such as DIT structure, schemas, 
properties and attributes and how and why of ldap searches doesn't come 
naturally either, so you're dealing with a non-trivial learning curve.  
The benefits are plain to the 'already enlightened' but difficult to 
convince those who are not unless there is a very real problem to solve, 
not just a desire to deploy the technology for whatever reason. Maybe 
the technology will eventually become completely robust, easily 
installed and managed and offer some very significant benefits. I may be 
wrong, but I don't think we are at that point quite yet, but  I'd 
certainly like to see it happen and probably will at some point in the 
future.

Regards,
-d



More information about the freebsd-hackers mailing list