[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
====================================================================