[turba] Ldap maintanance suggestion.

Adam Tauno Williams adam at morrison-ind.com
Sun Mar 30 21:19:29 PST 2003


>Thought I'd post this before hacking.
>I'm running horde 2.2.1-1 and turba 1.2-2. and using ldap address books.
>They are working fine, but I it seems to me that the ldap schema that is
>recommended has a shortcoming.
>The pilotperson object class produces address book entries in the form:
>dn: cn=budy,ou=xxx,ou=personalAddressBook,dc=example,dc=com
>objectClass: person
>objectClass: pilotPerson
>cn: budy
>mail: budy at somewher.org
>sn: xxx
>homePostalAddress: xxx 
>... etc
>but does no require (allow) an attribute org unit - only as part of the dn.
>This leads to a maintenance problem as one may, for example, need to identify
>all address book entries that belong to a user for wholesale modification,
>transferring/copying  of entries etc.  One can do this by collecting all the
>DNs and parsing for the desired user, but that isn't the ideal.

Why not just search for objectclass=* with a base of
ou=xxx,ou=personalAddressBook,dc=example,dc=com,  that will return all the
objects in the given ou.

A search result is a search result.  I don't see how this would be any different
than searching by an ou attribute embedded in the object.

>The problem here, and the suggestion, is that the ldap driver should be
>modified to allow explicit saving of any attribute that may exist in 
>the ldap schema.

Any attribute you have defined in attributes.php can be applied to an LDAP data
source.  The Turba LDAP driver does not perform subschema queries (which can be
tough to do in a cross-DSA compatible manner) so it has no mechanism to know
what is permited/allowed by the schema of a given DSA.  

If you want a general purpose LDAP browser there are alternatives to Turba.

>As is, it seem only to provide for the "objectclass" array and the "cn".
>I've created a new schema entry  'personalContact' which requires an

As an object class name that is probably too generic,  tiy should name it after
something more specific to your organization.

>ou.  This, of course, being the ou of the owner of that entry and the
>ou of 'personalAddressBook".
>It seems to me that the ldap driver should be able to accept a line like
>'ou' => array( 'xxx' , 'personalContact' ]" ),

Would be a nice feature; to always set some attribute to given values.

>and create the attributes accordingly.  I can' see why this couldn't
>be done for any attribute.
>Any comments?  Suggestions.


More information about the turba mailing list