- openldap-bugs - openldap.org

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? > > I haven't had access to Solaris in years... p. Me neither. Too bad, a Niagara might actually show more than a 1% gain from the multi-listener patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? I haven't had access to Solaris in years... p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

masarati(a)aero.polimi.it wrote: > Blind-fixed in HEAD. Thanks, p. By the way Ando, any more ideas about the devpoll implementation? Have you tested it against select on Solaris recently? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

Blind-fixed in HEAD. Thanks, p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 12 Aug '10

12 Aug '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Doug Leavitt > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.18.43.225) > > > Two syntax errors were introduced into daemon.c as a result of: > the commits to change daemon.c 1.444 -> 1.445 -> 1.446 > > > Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. > > > --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 > +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 > @@ -521,7 +521,7 @@ > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > int i; \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > for ( i=0; i<readfds.fd_count; i++) { \ > int fd = slapd_sock2fd(readfds.fd_array[i]); \ > @@ -666,7 +666,7 @@ > # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd),&writefds) > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > } while (0) > # endif /* !HAVE_WINSOCK */ > > Nice catch, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1000000000 with a parent of > 9999999999 (and > a row 9999999999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1410065407 = 32-bit rollover of 9999999999). A (blind) fix is in HEAD; you need to pull modifications related to this ITS and to ITS#6622. Please test and report. p.

1 0

(ITS#6622) Add support for [unsigned] long long parsing
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando A patch that adds support for parsing long long and unsigned long long is coming.

1 0

(ITS#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 12 Aug '10

12 Aug '10

Full_Name: Doug Leavitt Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) Two syntax errors were introduced into daemon.c as a result of: the commits to change daemon.c 1.444 -> 1.445 -> 1.446 Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 @@ -521,7 +521,7 @@ # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ int i; \ - *(nsp) = select( SLAP_EVENT_MAX, &readfds, \ + *(nsp) = select( SLAP_EVENT_MAX(t), &readfds, \ nwriters > 0 ? &writefds : NULL, NULL, (tvp) ); \ for ( i=0; i<readfds.fd_count; i++) { \ int fd = slapd_sock2fd(readfds.fd_array[i]); \ @@ -666,7 +666,7 @@ # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd), &writefds) # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ - *(nsp) = select( SLAP_EVENT_MAX, &readfds, \ + *(nsp) = select( SLAP_EVENT_MAX(t), &readfds, \ nwriters > 0 ? &writefds : NULL, NULL, (tvp) ); \ } while (0) # endif /* !HAVE_WINSOCK */

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

>> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >> >> >> Hello, >> >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. > > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", while it > is a request to shutdown a connection between client and server. As such, > it should be honored also when the connection is bound as the rootdn. Also, unbind operations are not supposed to return any response (see RFC4511 for details; note that no unbind response tag is defined). p.

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by Kurt＠OpenLDAP.org 11 Aug '10

11 Aug '10

On Aug 11, 2010, at 8:29 AM, masarati(a)aero.polimi.it wrote: >> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> = http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >>=20 >>=20 >> Hello, >>=20 >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. >=20 > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", = while it > is a request to shutdown a connection between client and server. As = such, > it should be honored also when the connection is bound as the rootdn. More to the point, backends should not be dependent on close (nor open) = connection events. Hence this patch ought to be rejected. -- Kurt=

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

> Full_Name: Gareth Palmer > Version: CVS HEAD > OS: Ubuntu 9.04 > URL: > http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch > Submission from: (NULL) (202.21.137.14) > > > Hello, > > This patch adds support for passing through unbind requests to the > underlying > module when using the perl backend. In this patch, the unbind operation is bypassed if requested by the rootdn. You seem to consider "unbind" as the opposite of "bind", while it is a request to shutdown a connection between client and server. As such, it should be honored also when the connection is bound as the rootdn. p.

1 0

(ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 11 Aug '10

11 Aug '10

Full_Name: Martin Evans Version: 2.4.20 OS: CentOS 5.X URL: Submission from: (NULL) (138.37.8.59) I've attached a proposed patch to fix an error that sometimes occurs when attempting to delete a userPassword attribute from an entry whilst the ppolicy overlay is active. The OL 2.4.20 code seems to assume that this operational attribute always exists (but it clearly cannot always exist otherwise the error would not occur). I think it can be reproduced by adding a fresh entry that contains a userPassword. Then simply deleting the userPassword fails resulting in: ldap_modify: No such attribute (16) additional info: modify/delete: pwdChangedTime: no such attribute Further experiments show that if the userPassword is modified before then deleted the error does not occur (presumably because something else sets pwdChangedTime on a mod operation but not when the attribute is added in an entire new entry). I've modified our OL 2.4.20 test systems with the patch below and the problem goes away: Cheerio! Martin. -bash-3.2# diff -u servers/slapd/overlays/ppolicy.c.0 servers/slapd/overlays/ppolicy.c --- servers/slapd/overlays/ppolicy.c.0 2009-08-26 00:07:41.000000000 +0100 +++ servers/slapd/overlays/ppolicy.c 2010-08-11 14:28:53.000000000 +0100 @@ -1880,22 +1880,31 @@ slap_timestamp( &now, &timestamp ); mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 ); - mods->sml_desc = ad_pwdChangedTime; + + /* MDTE PATCH 20100811: modify to not do delete non existing pwdChangedTime */ if (pwmop != LDAP_MOD_DELETE) { + mods->sml_desc = ad_pwdChangedTime; mods->sml_op = LDAP_MOD_REPLACE; mods->sml_numvals = 1; mods->sml_values = (BerVarray) ch_malloc( 2 * sizeof( struct berval ) ); ber_dupbv( &mods->sml_values[0], &timestamp ); BER_BVZERO( &mods->sml_values[1] ); assert( !BER_BVISNULL( &mods->sml_values[0] ) ); - + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; } else { - mods->sml_op = LDAP_MOD_DELETE; + if (attr_find(e->e_attrs, ad_pwdChangedTime )) { + mods->sml_desc = ad_pwdChangedTime; + mods->sml_op = LDAP_MOD_DELETE; + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; + } } - mods->sml_flags = SLAP_MOD_INTERNAL; - mods->sml_next = NULL; - modtail->sml_next = mods; - modtail = mods; + /* END OF MDTE PATCH */ if (attr_find(e->e_attrs, ad_pwdGraceUseTime )) { mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 );

1 0

(ITS#6619) CSN too old
by heinz.hoelzl＠gvcc.net 11 Aug '10

11 Aug '10

Full_Name: Heinz Hölzl Version: 2.4.23 OS: Linux Ubuntu Hardy LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.18.132.37) If i sync a part of my DIT with syncrepl, the first sync works fine. Then if i modify some objects on the provider, on the consumer appears: "do_syncrep2: rid=105 CSN too old, ignoring 20100811125159.871757Z#000000#001#000000" If i sync the hole DIT all works fine. If i use openldap 2.4.19 for syncing only a part of the DIT all works fine too. The version of the provider is 2.4.23 too. slapd.conf on the provider: ...snip.... database ldap lastmod on suffix "dc=krb" rootdn "cn=admin,dc=krb" uri "ldaps://lbackend.s2.dc.gvcc.net:10636" readonly on ...snip... slapd.conf on the consumer: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/sgv.schema include /etc/openldap/schema/mozillaOrgPerson.schema include /etc/openldap/schema/kerberos.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args allow bind_v2 # Schema check allows for forcing entries to # match schemas for their objectClasses's #schemacheck on loglevel none ####################################################################### # ldbm database definitions ####################################################################### modulepath /usr/lib/ldap moduleload back_hdb moduleload rwm sizelimit unlimited tool-threads 1 access to * by * write include /etc/openldap/tls.conf backend hdb # KERBEROS database hdb dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 lastmod on suffix "dc=krb" checkpoint 512 30 directory "/var/lib/ldap/krb" rootdn "cn=admin,dc=krb" rootpw blabla include /etc/openldap/slapd.replica.consumer-krb index objectClass eq index krbPrincipalName eq,pres,sub index krbPwdPolicyReference eq,pres index entryUUID,aliasedObjectName eq index default sub ############################################################################### /etc/openldap/slapd.replica.consumer-krb: # syncrepl syncrepl rid=101 searchbase="dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=102 searchbase="cn=princs,dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=103 searchbase="cn=krbcontainer,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=104 searchbase="o=zid,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=105 searchbase="o=klingons,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default ################################################################## buid-options for both versions (2.4.19 and 2.4.23) used on the consumer an on the provider: ./configure --prefix=${prefix} --bindir=${prefix}/bin --sbindir=${prefix}/sbin --libexecdir=${prefix}/lib --libdir=${prefix}/lib --sysconfdir=/etc --localstatedir=/var --mandir=${prefix}/share/man --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod --disable-ndb --enable-overlays=mod --with-subdir=ldap --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc --build x86_64-linux-gnu

1 0

(ITS#6618) Add support for unbind requests in perl backend
by gareth＠acsdata.co.nz 10 Aug '10

10 Aug '10

Full_Name: Gareth Palmer Version: CVS HEAD OS: Ubuntu 9.04 URL: http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch Submission from: (NULL) (202.21.137.14) Hello, This patch adds support for passing through unbind requests to the underlying module when using the perl backend. Regards Gareth

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 08 Aug '10

08 Aug '10

> masarati(a)aero.polimi.it wrote: >>> Attempting to create an inetOrgPerson interface to a proprietary >>> database >>> schema. >>> Obviously something wrong at this stage, causes slapd to SEGV. >>> >>> gdb tells me that in >>> servers/slapd/back-sql/entry-id.c:backsql_id2entry() >>> bsi->bsi_oc is null going into this call. >>> >>> rc = attr_merge_normalize_one( bsi->bsi_e, >>> slap_schema.si_ad_objectClass, >>> &bsi->bsi_oc->bom_oc->soc_cname, >>> bsi->bsi_op->o_tmpmemctx ); >>> >>> Without any time to absorb any implications, adding this just before >>> the >>> above >>> call >>> >>> // added without any clue... Rex >>> if ( eid->eid_oc == NULL ) >>> return LDAP_NO_SUCH_OBJECT; >>> >>> fixes the SEGV, but not my interface. >>> >> >> This should not happen, since that objectClass mapping is explicitly >> obtained few lines above if missing, and if the entry's OC was known by >> ID >> it must be available in the ID to OC mapping. I suspect something like >> ITS#6617, where the obejctClass' ID overflows the unsigned long. Can >> you >> investigate? >> >> A backtrace and a description of the expected and actual values would >> help >> (e.g. what ID has the "offending" objectClass, and what ID is >> backsql_id2entry() actually trying to fetch). >> >> It should be OK, at this point, to give up, but a clear indication that >> mapping did not succeed needs to be returned. >> >> p. >> >> > > I've finished my interface and i'm reluctant to share the mess it was in > when it caused the server to crash. > > What i found was that the call to avl_find() in backsql_id2oc() returned > NULL, which got passed back up the > stack, used as a pointer and boom. > > Without spending a long time trying to decipher the code, i could only > guess what any of this means, i'm not > an LDAP expert (or even really all that familiar with it). Please keep replies in CC to the ITS. In principle, avl_find() must return a valid objectClass; logically, we should assert() that a non-NULL pointer is returned. Determining why this occurs could help fixing the issue. Right now, you're just wiping it under the carpet, by returning a generic error instead of the expected data. p.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Tentatively, the "right" patch would be like this > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-its6600.1.patch> This patch, although apparently fixing this specific case, breaks test020; investigating... p.

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Attempting to create an inetOrgPerson interface to a proprietary database > schema. > Obviously something wrong at this stage, causes slapd to SEGV. > > gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() > bsi->bsi_oc is null going into this call. > > rc = attr_merge_normalize_one( bsi->bsi_e, > slap_schema.si_ad_objectClass, > &bsi->bsi_oc->bom_oc->soc_cname, > bsi->bsi_op->o_tmpmemctx ); > > Without any time to absorb any implications, adding this just before the > above > call > > // added without any clue... Rex > if ( eid->eid_oc == NULL ) > return LDAP_NO_SUCH_OBJECT; > > fixes the SEGV, but not my interface. This should not happen, since that objectClass mapping is explicitly obtained few lines above if missing, and if the entry's OC was known by ID it must be available in the ID to OC mapping. I suspect something like ITS#6617, where the obejctClass' ID overflows the unsigned long. Can you investigate? A backtrace and a description of the expected and actual values would help (e.g. what ID has the "offending" objectClass, and what ID is backsql_id2entry() actually trying to fetch). It should be OK, at this point, to give up, but a clear indication that mapping did not succeed needs to be returned. p.

1 0

Re: (ITS#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1,000,000,000 with a parent of > 9,999,999,999 (and > a row 9,999,999,999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1,410,065,407 = 32-bit rollover of 9,999,999,999). Currently, IDs are hardcoded as 32-bit unsigned (unsigned long) for internal use. In back-sql, we used the same type. I wonder whether it makes sense to allow to customize them (I think using 64-bit regardless of the arch is not a choice). p.

1 0

(ITS#6617) back-sql: 64-bit parent IDs get munged
by 7003＠blargh.com 06 Aug '10

06 Aug '10

Full_Name: Andrew Gray Version: 2.4.23 OS: Debian 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.216.14.1) 64-bit values for (at least) parent IDs do not get resolved correctly - only the lower 32 bits are preserved. This leads up to a crash as it tries to resolve a non-existant ID: To reproduce: ldap_entries has a row with an ID of 1000000000 with a parent of 9999999999 (and a row 9999999999 for the parent). When back-sql goes to resolve this, the following shows in the ODBC trace: SELECT COUNT(*) FROM ldap_entry_objclasses,ldap_entries,ldap_static_entries WHERE ldap_static_entries.id=1410065407 AND ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 (1410065407 = 32-bit rollover of 9999999999).

1 0

(ITS#6616) back-sql crashing
by rex.johnston＠gmail.com 06 Aug '10

06 Aug '10

Full_Name: Rex Johnston Version: cvs OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.255.40.107) Attempting to create an inetOrgPerson interface to a proprietary database schema. Obviously something wrong at this stage, causes slapd to SEGV. gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() bsi->bsi_oc is null going into this call. rc = attr_merge_normalize_one( bsi->bsi_e, slap_schema.si_ad_objectClass, &bsi->bsi_oc->bom_oc->soc_cname, bsi->bsi_op->o_tmpmemctx ); Without any time to absorb any implications, adding this just before the above call // added without any clue... Rex if ( eid->eid_oc == NULL ) return LDAP_NO_SUCH_OBJECT; fixes the SEGV, but not my interface.

1 0

Re: (ITS#6615) objectClass definition and error 65
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 10:43 PM +0000 philippe.eychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: 2.4.21 > OS: Ubuntu 9.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.86.106) This is a question better suited to openldap-technical(a)openldap.org, but inheritance works by having included the previous parent. I.e., person <- organizationalPerson <- inetOrgPerson, as in, inetOrgPerson inherits from organizationalPerson, which inherits from person. person <- organizationalPerson and person <- referencePerson are different inheritance trees. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6614) Checking Pre-Requisities
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 9:06 PM +0000 tcssuneelkumar(a)gmail.com wrote: > Full_Name: Suneel > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.95.226.224) The ITS system is for reporting bugs. For help with building the software, etc, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6615) objectClass definition and error 65
by philippe.eychart＠mail.pf 03 Aug '10

03 Aug '10

Full_Name: Philippe EYCHART Version: 2.4.21 OS: Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.86.106) Hi, Two structural (top) classes are not allowed in the same entry. (a person is not a posixGroup ...) Multiple inheritance is not allowed. (although "oc_sup_oids" is a "char **" in the structure "LDAPObjectClass" ... 8-| ) But, why "organisationalPerson" and "residentialPerson" are they not allowed (error returned: 65) in the same entry of type "person"? Yet, they both inherit from the same objectClass "person"?!... (And these two concepts are not incompatible...) Is this fact a misinterpretation of the "simple inheritance" or this return is correct?... (On the other hand, it's true that "person" and "posixGroup" inherit both from the same -abstract- objectClass : "top" ...) None of my research does the answer (Is this a bugg in the server or must I implement it like that?), so I turn to you ... Regards. PE <http://home.gna.org/ldapcppei/Frontends/Howto-7.fr.html#ss7.2>

1 0

(ITS#6614) Checking Pre-Requisities
by tcssuneelkumar＠gmail.com 03 Aug '10

03 Aug '10

Full_Name: Suneel Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.95.226.224) Hi, I am not a experienced unix admin, but i need to setup OpenLdap 2.4.23 on RedHat Linux environments. As per the Admin guide, There are pre-requisites before we install the openldap. Could you please help me to identify if i have the required pre-install libraries / packages. 1. 4.2.1. Transport Layer Security: [root@tmp]# rpm -q openssl openssl-0.9.8e-12.el5_4.6 2. 4.2.2. Simple Authentication and Security Layer [root@tmp]# rpm -qa | grep -i cyr xorg-x11-drv-cyrix-1.1.0-4 cyrus-sasl-devel-2.1.22-5.el5_4.3 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-plain-2.1.22-5.el5_4.3 cyrus-sasl-2.1.22-5.el5_4.3 3. Kerberos Authentication Service [root@astro tmp]# rpm -qa | grep krb krb5-devel-1.6.1-36.el5_4.1 krb5-auth-dialog-0.7-1 krb5-libs-1.6.1-36.el5_4.1 pam_krb5-2.2.14-15 krb5-workstation-1.6.1-36.el5_4.1 4. Database Software I have downloaded the latest Oracle Berkley DB (5.0.26) and set it up as per the Berkley install guide. IS this good enough to continue with OpenLdap installation ? Are the 2nd and 3rd pre-requisites are good enough to continue ? Could you also please let me know how to check if the specified pre-requisite is already existing in the server or not. Your help is much appreciated. Thanks

1 0

Re: (ITS#6586) PASSMOD operations are not getting chained correctly
by moenoel＠informatik.uni-bremen.de 31 Jul '10

31 Jul '10

Am 31.07.2010 04:46, schrieb masarati(a)aero.polimi.it: >> Every other write gets chained just fine when a slave is in this >> condition. It's only the PASSMOD operations that are stuck. > > One quick question: can you tell the parameters of the offending PASSMOD > operations? I mean: old/new password, password generated automatically or > provided, operation performed for self or by a privileged identity, and > so? > > Thanks, p. > > The PASSMODs are done by Linux 'passwd', using pam_ldap (mostly on Debian Lenny, if that matters). The new passwords are provided by the user and the operation is perfomed as "self". I don't know if pam_ldap provides the old password as a parameter to the PASSMOD operation. Binding is done with 'simple bind'. The whole SASL/Kerberos stuff is configured and working, but not yet deployed. I could add the client config (PAM, ldap.conf and so on) to the server related stuff in the linked directory, if you need it. Regards, Christian Manal

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs