[dev] preferences naming is not ldap compliant.

KaalH! kaalh@smol.org
Tue, 18 Dec 2001 15:51:46 +0100
Previous message: [dev] mcrypt, magic_quotes_runtime
Next message: [dev] preferences naming is not ldap compliant.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
You're right ... this is brutal.

So, I've _again_ updated the patches, making a ldap_read to get entry 
objectClasses, check if hordePrefs exists and add it if necessary.

Sometimes, be brutal increase performance ;)

--
Kaalh

Surlignage Dominic Ijichi <dom@ijichi.org>:

> OK, much better!  However, line 324-ish of Prefs/ldap.php does an
> unconditional
> mod to add objectClass and just ignores errors, which is a bit brutal!  It
> might
> be quieter to do something like (apologies in advance for my php, I'm not
> the
> worlds greatest coder!):
> 
> foreach($prefs as $pref) {
>         if ($pref == "objectClass = hordePrefs") {
>                 $objectclasshorde = 1;
>         }
> }
> if ($objectclasshorde != 1) {
>         @ldap_mod_add($this->connection, $this->dn, array('objectclass' =>
> 'hordePrefs'));
> }
> 
> which would avoid an unnecessary mod, but of course the objectclasses
> aren't
> held in $prefs..  Is there any way this sort of thing can be done without a
> mod
> and preferably without an extra search?  Perhaps when the record is first
> read
> in a global flag could be set if the objectclass is found?
> 
> Also, in the identities, is there any way of mapping a default identity to
> the
> existing ldap record?  Most records will already hold name, email etc in
> standard attribs, it would be nice to use them?
> 
> Thanks,
> Dom
> 
> > 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
> > 
> > 
> 
> 
> -- 
> 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.
> ------------------------------------------------------------------------
> 
> -- 
> Horde Developers mailing list: http://horde.org/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe@lists.horde.org
> 
>
Previous message: [dev] mcrypt, magic_quotes_runtime
Next message: [dev] preferences naming is not ldap compliant.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]