[turba] Re: Turba 1.2.2 and ldap

[Craig White]

meant to send to list...

On Mon, 2005-03-21 at 23:24 +0200, Jānis wrote:
> Citēju Craig White <craigwhite at azapple.com>:
> 
> > >
> > > here is the citation of core.shema modified according to the
> > core.shema.patch
> > >
> > > objectclass ( 2.5.6.6 NAME 'person'
> > >         DESC 'RFC2256: a person'
> > >         SUP top STRUCTURAL
> > >         MUST cn
> > >         MAY ( sn $ userPassword $ telephoneNumber $ seeAlso $
description )
> > )
> > >
> > > from that i see, that sn is optional.
> > > Regarding modification - can I only change mappings or more?
> > ----
> > core.schema as supplied by openldap v 2.2.23
> >
> > objectclass ( 2.5.6.6 NAME 'person'
> >         DESC 'RFC2256: a person'
> >         SUP top STRUCTURAL
> >         MUST ( sn $ cn )
> >         MAY ( userPassword $ telephoneNumber $ seeAlso $
description ) )
> >
> > You wanna use a modified schema? You're on your own - I can't help
you here. Suggest that you go back to the person who is providing you
with this concept.
> 
> :))) it is taken from the turba distrib - under scripts/ldap
----
search of turba & horde lists for core.schema.patch turn up nothing
regarding reasons for including this patch or using it.

turba/docs/LDAP gives no reason for installing

I didn't install it - I can't see any justifiable reason to install it,
but I do agree of its presence in cvs at least.

Given that this goes back to mid 2002 and openldap has moved to
'structural objects' - I can't see the wisdom of changing things like
the 'sn' requirement of the person objectclass without wondering if
something else isn't going to break in the process. I do know that
entries that I made into LDAP without regard to future needs are
somewhat painful to adapt when I've failed to anticipate structural
object restrictions - to quote Highlander - "there can be only one."

In short - I doubt many people are using that patch and those that have
installed that patch probably don't need it nor anticipate the
ramifications.
----
> > ----
> > OK - just briefly glancing through it - he's suggesting a tree
called ou=Hosting,ou=Account,dc=redant,dc=ca as base for user
authentication. probably gonna have to work something like that through
in your setup to get authentication working so you don't have
authentication errors (err=49 - Invalid Credentials)
> 
> One Russian generel ~200 years ago said: :Repeating is the mother of
knowledge". Now the privat addr books are working - the mistake covered
under wrong type of user records - after close inspection of what i
have, i changed it to person /organizationalPerson as in example
mentioned by myself... and it's ok now.
> 
> Regarding UTF8 problem - changing in sources.php to iso8859-13 does
not help... I (we) will have burden to change everything to hated UTF8
to use the addr book with all it's beauty and getting incompatibile with
standards used in Latvian mailing community... if only to disable utf8
in ldap at all...
----
UTF-8 is the standard of openldap because it permits all of the various
languages to utilize it. I find it's harder to fight this type of
technology than absorb it into your structure as everything is clearly
migrating towards UTF-8 for universality.