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