[dev] preferences naming is not ldap compliant.

Dominic Ijichi dom@ijichi.org
Mon, 17 Dec 2001 18:40:18 +0000
Previous message: [dev] preferences naming is not ldap compliant.
Next message: [dev] preferences naming is not ldap compliant.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
------------------------------------------------------------------------
Previous message: [dev] preferences naming is not ldap compliant.
Next message: [dev] preferences naming is not ldap compliant.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]