[dev] preferences naming is not ldap compliant.

KaalH! kaalh@smol.org
Mon, 17 Dec 2001 13:46:07 +0100


Surlignage Dominic Ijichi <dom@ijichi.org>:

> Hi, I emailed these problems to imp@lists.horde.org, and got directed here.  
> 
> Thanks for sorting this, the patches works a treat! I ran into a few
> problems,
> though:
> 
> 1) The objectclasses are not added to the user record automatically, that has
> to
> be done manually otherwise you get schema violation.
> 

Hi,
patches updated (http://kaalh.smol.org/horde/)

changes :
- automatically add the hordePrefs objectClass attribute.
- use get_class to retrieve driver name
- store multi-apps map data in Prefs::mapdata
- prevent add of empty attributes in directory.

> 2) If you use IMP to authenticate (ie by uncommenting first to lines of
> registry.php), then the preferences are attempted as user@domain.com (the
> search
> for the user that is, which fails, and also bombs out with unfriendly error
> message).  If you login using Horde Auth, then login to IMP, it binds as
> just
> user (as opposed to user@domain.com) and everything works.  I noticed the
> same
> thing under sql - it makes sense under sql to avoid clashes, but breaks under
> LDAP.
> 
> 3) Who is responsible for getting an OID? It takes a couple of weeks to get
> one,
> can we ask someone to start the process?
> 
> 4) My Openldap (v2.0.18) on Solaris dumped core everytime I ran it up with
> your
> original schema.  After recapitalising attributetype, objectclass, changing
> oids
> etc, fiddling with attribute length constraints, I eventually found it was
> because the single objectClass was too long!  Did you have this trouble?  I
> had
> to split it into multiple objectClasses before slapd would run without
> dumping
> core..  I've attached the schema that works for me - maybe it's a good thing
> to
> split it up anyway?  I know this is off target, but my slapd fails with
> (truss
> output):
> 
>     Incurred fault #6, FLTBOUNDS  %pc = 0xFEF423FC
>       siginfo: SIGSEGV SEGV_MAPERR addr=0x00000308
>     Received signal #11, SIGSEGV [caught]
>       siginfo: SIGSEGV SEGV_MAPERR addr=0x00000308
> sigprocmask(SIG_SETMASK, 0xFEEAEFE8, 0x00000000) = 0
> sigaction(SIGSEGV, 0xFFBEE318, 0x00000000)      = 0
> sigprocmask(SIG_SETMASK, 0xFEEBADB8, 0x00000000) = 0
> setcontext(0xFFBEE4D0)
>     Incurred fault #6, FLTBOUNDS  %pc = 0xFEF423FC
>       siginfo: SIGSEGV SEGV_MAPERR addr=0x00000308
>     Received signal #11, SIGSEGV [default]
>       siginfo: SIGSEGV SEGV_MAPERR addr=0x00000308
>         *** process killed ***
> 
> Anyone got a clue??
> 


Seems to be an openldap bug.
openldap 2.0.14 on linux cause slurpd segfaults with long objectClasses 
definitions (its #1343)
May your issue smtgh like that.

--
Kaalh

> Cheers
> Dom
> 
> 
> You're right, but default identity params are stored in the main fullname, 
> signature, etc..
> I've update the patches and schema (empty pref value storage fix, impFullname
> 
> & impFromAddress attributes added)
> stuff still in http://kaalh.smol.org/horde/
> 
> -- 
> )../-{^_^}-\..(
>              --
> 
> 
> Surlignage Jan Schneider <jan@horde.org>:
> 
> > Zitat von kaalh@smol.org:
> > > > Surlignage Atif Ghaffar <aghaffar@developer.ch>:
> > > > > well .. I made it ;)
> > > > > I've put the map data in the /module/config/prefs.php.dist files ,
> seems
> > > to be 
> > > a better place than conf.php.
> > > > > let's see an example from imp/config/prefs.php.dist:
> > > > > // user signature
> > > $_prefs['signature'] = array(
> > > 'value' => '',
> > > 'locked' => false,
> > > 'shared' => true,
> > > 'type' => 'implicit',
> > > 'map' => array('ldap' => 'impSignature')
> > > );
> > > > > for sql backend, it's possible to do smtgh like :
> > > > > // user signature
> > > $_prefs['signature'] = array(
> > > 'value' => '',
> > > 'locked' => false,
> > > 'shared' => true,
> > > 'type' => 'implicit',
> > > 'map' => array('sql' => 'impSignature')
> > > );
> > > Just to make some things clear: Stuff like signature, full_name,
> from_addr 
> > are not really prefs anymore. They are altogether stored in identities as
> a
> > > serialized array. The entrie in prefs.php are just for setting which
> parts 
> > of the identity are locked and to provide default values.
> > > Jan.
> > > ::::::::::::::::::::::::::::::::::::::::
> > AMMMa AG - discover your knowledge
> > :::::::::::::::::::::::::::
> > Detmolder Str. 25-33 :: D-33604 Bielefeld
> > fon +49.521.96878-0 :: fax  +49.521.96878-20
> > http://www.ammma.de
> > ::::::::::::::::::::::::::::::::::::::::::::::
> > > -- 
> > Horde Developers mailing list: http://horde.org/
> > Frequently Asked Questions: http://horde.org/faq/
> > To unsubscribe, mail: dev-unsubscribe@lists.horde.org
> > > -- 
> Horde Developers mailing list: http://horde.org/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe@lists.horde.org
> 
> 
> 
> -- 
> This message was penned by the hand of DOM
> 
> ------------------------------------------------------------------------
> The information in this e-mail and any attachments is confidential and
> may be privileged or protected by other legal rules. It is intended
> solely for the addressee(s). Access to this e-mail by anyone other than
> the addressee(s) is unauthorised. If you are not the intended recipient
> or a person responsible for delivering it to the intended recipient, you
> are not authorised to, and therefore must not, disclose, copy,
> distribute or retain all or any part of this message.
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
> The information in this e-mail and any attachments is confidential and
> may be privileged or protected by other legal rules. It is intended
> solely for the addressee(s). Access to this e-mail by anyone other than
> the addressee(s) is unauthorised. If you are not the intended recipient
> or a person responsible for delivering it to the intended recipient, you
> are not authorised to, and therefore must not, disclose, copy,
> distribute or retain all or any part of this message.
> ------------------------------------------------------------------------
>