[dev] preferences naming is not ldap compliant.
Kaalh!
kaalh@smol.org
Tue, 18 Dec 2001 17:07:54 +0100
Another update
Changes :
- remove attribute from ldap when preference deleted.
--
Kaalh!
Surlignage KaalH! <kaalh@smol.org>:
> 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.
> > ------------------------------------------------------------------------
> >
>
> --
> Horde Developers mailing list: http://horde.org/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe@lists.horde.org
>
>