[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Why is LDAP so complex?



Tony,

There was a saying at a company I worked for a while back:
"He who proposes disposes."  Your ideas sound interesting.
Let me know when you get them implemented.  I think that
LDAP is overly complex, too.

Have a GREAT day!
Pete

Tony Bibbs wrote:
> 
> OK, I'm a bit frustrated with LDAP...partly because sometime I rush
> things and make stupid mistakes but also in part by LDAP being much more
> complicated than I think it should be.
> 
> Here's some thoughts from a newbie on how LDAP could be improved.  I'm
> guessing this may not be a totally original idea but I haven't heard
> anybody asking for this.
> 
> I think that LDAP is more complicated that it needs to be.  Particularly
> with the syntax of adding/searching/removing entries and in building
> your own object classes.
> 
> Has anyone thought to write a set of programs that turns the cryptic
> LDAP syntaxes into more of a usable system?
> 
> For example, LDIF files are a joke to me.  Maybe I should rest assured
> knowing that understanding them now affords me a degree of job security
> but why not simplify it.  Here's an example of what I'd like to see
> happen
> 
> Take this example (taken right from the openldap quick-start guide)
> 
> dn: dc=example,dc=com
> objectclass: dcObject
> objectclass: organization
> o: Example Company
> dc: example
> 
> dn: cn=Manager,dc=example,dc=com
> objectclass: organizationalRole
> cn: Manager
> 
> Why not create a simple object'ish language that allows all that to be
> defined as follows:
> 
> $myentry1 = New LDAP_ENTRY("example.com");
> $myentry1.InheritClass("dcObject");
> $myentry1.InheritClass("organization");
> $myentry1.o = "Example Company";
> $myentry1.dc ="example";
> $myentry1.add();
> 
> $myentry2 = New LDAP_ENTRY("manager.example.com");
> $myentry2.InheritClass("organizationalRole");
> $myentry2.cn = "Manager";
> $myentry2.add();
> 
> The idea here is that the above could be ran through some sort of LDAP
> interpreter that would then checks syntaxes and give more useful
> messages (errors or otherwise) that aid in deploying LDAP
> 
> When successfully intepreted these can then be used to build the LDIF
> files reliably and pumped through ldapadd or ldapsearch or ldapdelete.
> 
> Sure this may not seem to change anything for someone that has done LDAP
> for awhile but I think this would make LDAP easier to read and debug.
> 
> Similarly something needs to be done about object class definitions.
> 
> Specifically I shouldn't have to put 1.3.6.1.4.1.1466.115.121.1.27 for
> integer data types but, rather, LDAP_INT (they already did something
> like this for matching rules, why not for data types?).
> 
> Again, that would be 10 times more readable, easier to use and let's me
> worry about solving my problem with LDAP and not so much with LDAP
> itself.
> 
> Ok, I'm done ranting.
> 
> --Tony
> 
> On Thu, 2002-01-10 at 15:13, Stefan Alfredsson wrote:
> > On Thu, Jan 10, 2002 at 08:56:29AM +0100, Pierangelo Masarati wrote:
> > > Stefan Alfredsson wrote:
> > > > Is it possible to do a partial replication, i.e. only certain attributes
> > > > are taken into consideration?
> > >
> > > No. I'd say "not yet" because I was thinking about doing something like
> > > that some day.  A simple yet powerful solution would be to pass the data
> > > being sent to each replica thru ACLs.
> >
> > I came to think about this possiblity today myself; If the replica binddn
> > only has write access to certain attributes on the slave, would this
> > work as expected?
> >
> > Something like this springs to mind (slave config):
> >
> > access to attrs=maillocaladdress,rfc822mailmember,cn,uid
> >       by dn="cn=repl,dc=acme,dc=org" write
> >       by * read
> >
> > access to *
> >       by * read
> >
> > Or would slurpd fail when it has no access to modify other attributes
> > on the slave? I.e. if only maillocaladdress is changed, it is successful.
> > If maillocaladdress and loginShell were changed at the same time,
> > there would be a conflict and the "transaction" would fail?
> >
> > /Stefan

-- 
====================================================================
Peter E. Stoddard	
System Software Engineer	
Service Provider Solutions Engineering	Pete.Stoddard@compaq.com
Business Critical Solutions Division	Tel. (603) 884-5128
Compaq Computer Corporation		Fax. (603) 884-0627
110 Spit Brook Road, ZKO2-2/N87
Nashua, New Hampshire 03062-2698
USA
====================================================================