- openldap-bugs - openldap.org

Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com 26 Apr '07

26 Apr '07

----- richton(a)nbcs.rutgers.edu wrote: > I don't have #5 (sleepycat#14657) nor the unofficial > http://www.stanford.edu/services/directory/openldap/configuration/patches/d… > > patch. As for the official one, I'm not sure about its relevance to > the > actual SEGV due to the "recovery...fail" comment. In other words, > though > it may be impacting the ability of alock/db_recover to do its thing, > that's just a side effect of the unclean shutdown which is the real > bug > here to my view. Patch #5 specifically deals with a race condition where a checkpoint is occuring while a cache buffer retrieval is also occuring causing a database corruption that will later not be recoverable from. At least, that's how I read sleepcat's description: 5. Fix a bug where cache buffer retrieval could race with a checkpoint call, potentially causing database environment recovery to fail. [#14657] Given that OpenLDAP checkpoints on shutdown, shutting down the server could be what is triggering the issue for you. I'd suggest applying the patch and seeing if this resolves your problem. > The region size patch is interesting, but I will tell you that the > database in question has > > set_cachesize 0 200000000 0 > > and it (to a glance) looks like that only impacts the gig column, > which I > have as zero anyway. Yeah, the patch may not apply for you (I have a 3.5GB cache, so it does for me). Wouldn't harm anything, of course, if you decided later you needed a larger BDB cache. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4938) hdb_db_close SEGVs
by richton＠nbcs.rutgers.edu 26 Apr '07

26 Apr '07

I don't have #5 (sleepycat#14657) nor the unofficial http://www.stanford.edu/services/directory/openldap/configuration/patches/d… patch. As for the official one, I'm not sure about its relevance to the actual SEGV due to the "recovery...fail" comment. In other words, though it may be impacting the ability of alock/db_recover to do its thing, that's just a side effect of the unclean shutdown which is the real bug here to my view. The region size patch is interesting, but I will tell you that the database in question has set_cachesize 0 200000000 0 and it (to a glance) looks like that only impacts the gig column, which I have as zero anyway. I can tell you that stop/starts weren't an issue with 2.3.32 and the same Sleepycat binaries...not that I stop/start often as a rule of thumb. (I am lately; we're implementing ando's {RADIUS} module.) But two identical traces on two different boxes caught my eye. On Thu, 26 Apr 2007, Quanah Gibson-Mount wrote: > > ----- richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron RIchton >> Version: 2.3.35 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.30.206) >> >> >> BDB 4.2.52. I've had a couple (different) machines SEGV on slapd >> shutdown. Both >> had identical stack traces: > > Wierd, I've been running hdb on my servers for nearly a year without such an issue. Did this just start with 2.3.35? > > Also, what patches do you have applied to BDB 4.2.52. I'm up to 6 now. > > <http://www.stanford.edu/services/directory/openldap/configuration/bdb-build…> > > 5 are direct from sleepycat: > > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.2.52/patc…> > > with the last one there possibly impacting you if you don't have it? > > --Quanah > > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com 26 Apr '07

26 Apr '07

----- richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron RIchton > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.30.206) > > > BDB 4.2.52. I've had a couple (different) machines SEGV on slapd > shutdown. Both > had identical stack traces: Wierd, I've been running hdb on my servers for nearly a year without such an issue. Did this just start with 2.3.35? Also, what patches do you have applied to BDB 4.2.52. I'm up to 6 now. <http://www.stanford.edu/services/directory/openldap/configuration/bdb-build…> 5 are direct from sleepycat: <http://www.oracle.com/technology/products/berkeley-db/db/update/4.2.52/patc…> with the last one there possibly impacting you if you don't have it? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4938) hdb_db_close SEGVs
by richton＠nbcs.rutgers.edu 26 Apr '07

26 Apr '07

Full_Name: Aaron RIchton Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.30.206) BDB 4.2.52. I've had a couple (different) machines SEGV on slapd shutdown. Both had identical stack traces: current thread: t@1 =>[1] __dbreg_revoke_id(dbp = 0xa498818, have_lock = 0, force_id = -1), line 427 in "dbreg.c" [2] __dbreg_close_files(dbenv = 0x405320), line 206 in "dbreg_util.c" [3] __log_dbenv_refresh(dbenv = 0x405320), line 744 in "log.c" [4] __dbenv_refresh(dbenv = 0x405320, orig_flags = 0, rep_check = 0), line 648 in "env_open.c" [5] __dbenv_close(dbenv = 0x405320, rep_check = 0), line 579 in "env_open.c" [6] __dbenv_close_pp(dbenv = 0x405320, flags = 0), line 534 in "env_open.c" [7] hdb_db_close(be = 0x367340), line 517 in "init.c" [8] backend_shutdown(be = 0x367340), line 351 in "backend.c" [9] slap_shutdown(be = (nil)), line 279 in "init.c" [10] main(argc = 4, argv = 0xffbffd6c), line 870 in "main.c" No idea if this is Sleepycat or slapd, but it dirties the database in a way that automatic nor command-line db_recover appreciate: Ignoring log file: log.0000000007: magic number 0, not 40988 Invalid log file: log.0000000007: Invalid argument PANIC: Invalid argument PANIC: DB_RUNRECOVERY: Fatal error, run database recovery hdb_db_open: Database cannot be recovered, err -30978. Restore from backup! DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: txn_checkpoint failed: Invalid argument (22) backend_startup_one: bi_db_open failed! (-30978)

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by hyc＠symas.com 25 Apr '07

25 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > overlay chain breaks with databases ldbm and ldif: > > ./run -b {ldbm or ldif} test032-chain outputs: > ... > Starting second slapd on TCP/IP port 9012... > ... > Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com" > on port 9012... > ldapcompare failed (10)! > > ldapcompare output in testrun/test.out: > Compare Result: Referral (10) > Matched DN: ou=People,dc=example,dc=com > Referral: ldap://localhost:9011/ou=People,dc=example,dc=com > UNDEFINED > > testrun/slapd.1.log says the Compare was sent to the chained server, but > with baseDN=<Matched DN above>: > ... > do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot) > conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn" > ... > conn=5 op=2 RESULT tag=111 err=16 text= > ... > > Slapcat says the Matched DN entry is correct (same as in a BDB run): > dn: ou=People,dc=example,dc=com > objectClass: referral > objectClass: extensibleObject > ou: People > ref: ldap://localhost:9011/ou=People,dc=example,dc=com > structuralObjectClass: referral > > > Also the Statslog output is wrong for all three databases: > > With LDBM and LDIF, the CMP operation is not logged, only its result: > grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above > conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012) > conn=4 op=0 BIND dn="" method=128 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 RESULT tag=111 err=10 text= > conn=4 op=2 UNBIND > conn=4 fd=14 closed > > With BDB, the CMP operation is not logged, but both the returned > result and the suppressed referral result is logged: > conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012) > conn=4 op=0 BIND dn="" method=128 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 RESULT tag=111 err=6 text= > conn=4 op=1 RESULT tag=111 err=10 text= > conn=4 op=2 UNBIND > conn=4 fd=12 closed > > > I haven't tried other databases, but since two different databases > had the same bug and same wrong Statlog, I'm guessing others do too. This seems to be a known limitation, see the FIXME in slapd/compare.c, near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem for back-ldif, which does not provide its own compare entry point. As for back-ldbm, there is a missing referral_rewrite call in back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm, but you're welcome to fix it if you wish. Just have a look at back-bdb/referral.c for the correct code. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no 25 Apr '07

25 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard overlay chain breaks with databases ldbm and ldif: ./run -b {ldbm or ldif} test032-chain outputs: ... Starting second slapd on TCP/IP port 9012... ... Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com" on port 9012... ldapcompare failed (10)! ldapcompare output in testrun/test.out: Compare Result: Referral (10) Matched DN: ou=People,dc=example,dc=com Referral: ldap://localhost:9011/ou=People,dc=example,dc=com UNDEFINED testrun/slapd.1.log says the Compare was sent to the chained server, but with baseDN=<Matched DN above>: ... do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot) conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn" ... conn=5 op=2 RESULT tag=111 err=16 text= ... Slapcat says the Matched DN entry is correct (same as in a BDB run): dn: ou=People,dc=example,dc=com objectClass: referral objectClass: extensibleObject ou: People ref: ldap://localhost:9011/ou=People,dc=example,dc=com structuralObjectClass: referral Also the Statslog output is wrong for all three databases: With LDBM and LDIF, the CMP operation is not logged, only its result: grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012) conn=4 op=0 BIND dn="" method=128 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 RESULT tag=111 err=10 text= conn=4 op=2 UNBIND conn=4 fd=14 closed With BDB, the CMP operation is not logged, but both the returned result and the suppressed referral result is logged: conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012) conn=4 op=0 BIND dn="" method=128 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 RESULT tag=111 err=6 text= conn=4 op=1 RESULT tag=111 err=10 text= conn=4 op=2 UNBIND conn=4 fd=12 closed I haven't tried other databases, but since two different databases had the same bug and same wrong Statlog, I'm guessing others do too.

1 0

Re: (ITS#4936) default modulepath
by ahasenack＠terra.com.br 23 Apr '07

23 Apr '07

On Mon, Apr 23, 2007 at 09:17:26PM +0000, abartlet(a)samba.org wrote: > It would be very useful if OpenLDAP would provide a default value for > modulepath. > > This would ensure that on systems with multiple openldap installs (such as test > rigs) that we do not need to specify the *correct* modulepath, when starting the > config with different slapd binaries. > > Similarly, it would avoid the need to guess which modulepath is correct for a > given system, such as when we find slapd in the path (as Samba4's test mode > does), but needs to automatically enable modules. Another scenario is with some tool providing a config file for slapd. It wouldn't have to guess the host arch whether it's i386 or x86_64 and set the correct module_path (/usr/lib/openldap vs /usr/lib64/openldap).

1 0

(ITS#4936) default modulepath
by abartlet＠samba.org 23 Apr '07

23 Apr '07

Full_Name: Andrew Bartlett Version: devel OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.70.73.150) It would be very useful if OpenLDAP would provide a default value for modulepath. This would ensure that on systems with multiple openldap installs (such as test rigs) that we do not need to specify the *correct* modulepath, when starting the config with different slapd binaries. Similarly, it would avoid the need to guess which modulepath is correct for a given system, such as when we find slapd in the path (as Samba4's test mode does), but needs to automatically enable modules. (Discussed with Howard Chu)

1 0

Re: (ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com 23 Apr '07

23 Apr '07

--=__PartDCFBBB68.0__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Confirmed fix works. — Luke --=__PartDCFBBB68.0__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"> <META content=3D"MSHTML 6.00.5346.5" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>Confirmed fix works.</DIV> <DIV> </DIV> <DIV>=E2=80=94 Luke<BR></DIV></BODY></HTML> --=__PartDCFBBB68.0__=--

1 0

(ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com 23 Apr '07

23 Apr '07

Full_Name: Luke Howard Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.16.129.17) SASL_MAX_BUFF_SIZE is too small for SASL mechanisms, such as GSS-SPNEGO, that use a buffer size unconstrained by the 64K limit defined for some mechanisms in RFC 2222. A more reasonable default would 0xFFFFFF (2^24), used as the maximum buffer size by many of the mechanisms shipped with Cyrus itself.

1 0

(ITS#4934) Port change
by babu.suresh＠pacificlife.com 20 Apr '07

20 Apr '07

Full_Name: Babu Version: 2.3 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.8.254) My openldap was running on default port 389 and imported all schema & data. Now I would like to change the port to different..would be 4000/5000. OpenLDAP process started successfully with non default port but I am getting "error 32 no such object" when try to browse the data using soferra. is it possible to change the port anytime? thank you

1 0

(ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by donn＠u.washington.edu 20 Apr '07

20 Apr '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) Appears to me that unless timelimit value passed to ldap_search_ext() is positive, the ld_timelimit from .ldaprc overrides, so there's no way for syncrepl ldap_sync_search() to literally specify "unlimited". To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc -> "TIMELIMIT 23"; start replica slapd with a sufficiently large replication backlog; observe timeout at 23 seconds. To kludge: use extravagantly large value instead: if (si->si_tlimit > 0) timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000; and pass &timeout unconditionally.

1 0

Re: (ITS#4922)
by ando＠sys-net.it 19 Apr '07

19 Apr '07

Juri Tanganelli wrote: > After further debugging i found the following behaviour: > > The entry has the uid attribute correctly initialized: uid S287384. Then it should have a corresponding normalized value "s287384" (note the lowercase "s") in the a_nvals array of bervals of the Attribute strycture where it's stored. If it doesn't (e.g. because the attribute was created incorrectly by your custom backend) then the behavior you see makes perfectly sense, and is not indicative of a software bug in OpenLDAP software. p. > If the uid starts with a capital letter then using these two filters: > > (uid=S287384) or (uid=s287384) doesn't return any result. > > If the uid attribute starts with a lower case letter ( i.e. uid=s287384 > ) then both filters work and return the entry. > The definition of the uid attribute is embodied in openldap source code > and from what i have seen it should be treated as a case insensitive > attribute. How to explain this behaviour?? Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4932) Core dump caused in ldap_extended_operation()
by h.b.furuseth＠usit.uio.no 19 Apr '07

19 Apr '07

rguerrero(a)datamirror.com writes: > ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c" > ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c" > do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c" Looks like an ldap-nss.c problem to me, not an OpenLDAP problem. An uninitialized (or destroyed but not zeroed) LDAP*, perhaps? Look at the value of *session, in particular session->ls_conn, in the do_start_tls() frame. -- Regards, Hallvard

1 0

(ITS#4922)
by juritanganelli＠gmail.com 19 Apr '07

19 Apr '07

------=_Part_125517_21113365.1176969864256 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline After further debugging i found the following behaviour: The entry has the uid attribute correctly initialized: uid S287384. If the uid starts with a capital letter then using these two filters: (uid=S287384) or (uid=s287384) doesn't return any result. If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry. The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour?? Best Regards, Juri. ------=_Part_125517_21113365.1176969864256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div>After further debugging i found the following behaviour:</div> <div> </div> <div>The entry has the uid attribute correctly initialized: uid S287384.</div> <div> </div> <div>If the uid starts with a capital letter then using these two filters:</div> <div> </div> <div>(uid=S287384) or (uid=s287384) doesn't return any result.</div> <div> </div> <div>If the uid attribute starts with a lower case letter ( i.e. uid=s287384 ) then both filters work and return the entry.</div> <div>The definition of the uid attribute is embodied in openldap source code and from what i have seen it should be treated as a case insensitive attribute. How to explain this behaviour??</div> <div> </div> <div>Best Regards,</div> <div>Juri.</div> ------=_Part_125517_21113365.1176969864256--

1 0

(ITS#4932) Core dump caused in ldap_extended_operation()
by rguerrero＠datamirror.com 18 Apr '07

18 Apr '07

Full_Name: Ron Guerrero Version: 2.3.27 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.201.167.139) We've got an application that indirectly calls OpenLDAP APIs. One function in particular is causing our process to core dump. The stack trace generated by dbx is as follows: 0xd0128470 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1) pthread_kill(??, ??) at 0xd0128470 _p_raise(??) at 0xd0127f08 raise.raise(??) at 0xd0315740 abort.abort() at 0xd0344cb0 __assert_c99(??, ??, ??, ??) at 0xd03aede0 ldap_extended_operation(ld = (nil), reqoid = "1.3.6.1.4.1.1466.20037", reqdata = (nil), sctrls = (nil), cctrls = ??, msgidp = 0x2ff18cd4), line 62 in "extended.c" ldap_start_tls(ld = ??, serverctrls = ??, clientctrls = ??, msgidp = ??), line 1859 in "tls.c" do_start_tls(session = 0xf027b7f0), line 1343 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" unnamed block in do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" do_with_reconnect(base = "dc=gwl,dc=com", scope = 2, filter = "(&(objectClass=posixAccount)(uidNumber=138056))", attrs = 0xf027d5a8, sizelimit = 1, private = 0x2ff19658, search_func = 0xf027b9a0), line 1530 in "ldap-nss.c" _nss_ldap_search_s(args = 0x2ff196c8, filterprot = "(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, user_attrs = (nil), sizelimit = 1, res = 0x2ff19658), line 3047 in "ldap-nss.c" _nss_ldap_getbyname(args = 0x2ff196c8, result = 0x20131698, buffer = "", buflen = 1024, errnop = 0x2ff22ff8, filterprot = "(&(objectClass=posixAccount)(uidNumber=%d))", sel = LM_PASSWD, parser = 0xf027b97c), line 3394 in "ldap-nss.c" ldap-pwd.pw_byuid(this = ??, uid = ??), line 55 in "irs-pwd.c" _nss_ldap_getpwuid(uid = 138056), line 181 in "aix_authmeth.c" _getpwuid_shadow_r(??, ??, ??, ??, ??) at 0xd03d0900 _posix_getpwuid_shadow_r(??, ??, ??, ??, ??, ??) at 0xd03d02cc sniq.getpwuid_r(??, ??, ??, ??, ??) at 0xd249170c snigun(??, ??, ??) at 0xd2491648 nigconcbs(??, ??, ??) at 0xd28cc858 osncon(0x0, 0x0, 0x1803, 0x201090ec, 0x20105bec, 0x20105be4, 0x20105b70, 0x20105c20) at 0xd28cce6c kpuadef(??, ??, ??, ??, ??, ??, ??, ??) at 0xd1d0d1b4 upiini(0x0, 0x0, 0x0, 0x0, 0x200eda80, 0x200edca0, 0x200edef4, 0x2010fe40) at 0xd20f24d4 upiah0(??, ??, ??, ??, ??, ??, ??) at 0xd20efce4 kpuatch(??, ??, ??, ??, ??, ??, ??) at 0xd1d378fc OCIServerAttach(??, ??, ??, ??, ??) at 0xd20fbfb0 As you can see application makes a call to an Oracle API. Has anyone seen this issue before? Notice in ldap_start_tls() the first parameter, the ldap handle, is non-null. However, in ldap_extended_operation(), the ldap handle is null. Looking at the code, ldap_start_tls() is calling ldap_extended_operation() with the same ldap handle that was passed to it. The latest source files for extended.c and tls.c have not changed since the 2.3.27 release.

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 18 Apr '07

18 Apr '07

This seems really to be an PPC specific kernel (or glibc) issue. I think I was able to create an isolated testcase to reproduce that problem outside of the OpenLDAP libraries. I'll now bug our kernel guys with it. But removing the assert(0) from request.c was still the right thing as Hallvard already mentioned in his first reply. -- Ralf

1 0

Re: (ITS#4931) To integrate Open LDAP with Jetspeed2
by quanah＠stanford.edu 18 Apr '07

18 Apr '07

--On Wednesday, April 18, 2007 1:57 PM +0000 vaibhav(a)omnimessaging.com wrote: > Full_Name: > Version: openldap-2.2.13-2 > OS: redhat linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.211.142.177) > > > How to use OPENLDAP with jetspeed2 ? > > please guide me. > Also please let me know how to check if ldap is working with jetspeed. > > I installed LDAP with BDB also can see all entires in LDAP -Browser. > Bis issue is how to use LDAP with Jetspeed2 for auth. Hello, The OpenLDAP ITS system is for reporting bugs, not for asking usage questions. If you have questions specific to the OpenLDAP software, please use the "openldap-software(a)openldap.org" mailing list. On a side note, you may need to contact RedHat for support if you run into issues with the openldap release you are using, as it is significantly out of date. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4931) To integrate Open LDAP with Jetspeed2
by vaibhav＠omnimessaging.com 18 Apr '07

18 Apr '07

Full_Name: Version: openldap-2.2.13-2 OS: redhat linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.211.142.177) How to use OPENLDAP with jetspeed2 ? please guide me. Also please let me know how to check if ldap is working with jetspeed. I installed LDAP with BDB also can see all entires in LDAP -Browser. Bis issue is how to use LDAP with Jetspeed2 for auth. regards VAibhav KAle

1 0

(ITS#4930) slaptest should be quiet on success
by jsafranek＠redhat.com 18 Apr '07

18 Apr '07

Full_Name: Jan Safranek Version: 2.3.35 OS: Linux (Fedora 6) URL: Submission from: (NULL) (62.40.79.66) The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded' to stderr. IMHO it should do not output anything, especially to stderr, if everything is all right. Here is a small patch, causing the slaptest to display the aforementioned message only if -v switch is used: Index: servers/slapd/slaptest.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v retrieving revision 1.9 diff -r1.9 slaptest.c 107c107,108 < fprintf( stderr, "config file testing succeeded\n"); --- > if (verbose) > fprintf( stderr, "config file testing succeeded\n");

1 0

(ITS#4929) Contriware Tool to create backsql metadata and tables
by takyin＠hotmail.com 17 Apr '07

17 Apr '07

Full_Name: Paul Version: 2..3.34 OS: FC6 URL: ftp://ftp.openldap.org/incoming/paul-070417.tar.gz Submission from: (NULL) (219.79.33.240) Dear Sir/Madam, I am interested to contribute my work on a tool that help backsql to work with MYSQL 5.0. It will create all tables, functions and metadata in sql command that can fit into MYSQL ver 5.0 ============================================= Some brief information about the tool ============================================= It is a php program with web interface, user can select which schema they want and create the resultant sql command. It should work with openldap 2.3.34 . Yours Paul

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by quanah＠stanford.edu 16 Apr '07

16 Apr '07

--On Monday, April 16, 2007 6:31 PM +0000 ryan(a)stat.Berkeley.EDU wrote: > On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >> > 3) if you can reproduce this issue with an unstripped set of OpenLDAP >> > libraries that would make the backtrace more useful. >> >> ...which I think you build with >> env ac_cv_prog_STRIP=":" ./configure ... > > I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still > prepared with "STRIP = -s" which then leads to "install -s". I found this: > > http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html > > I edited build/top.mk and removed the '-s' from STRIP and the configure > stage prepared Makefiles with "STRIP = ". You can always just run: make install STRIP="" or rather than hacking the makefiles. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.Berkeley.EDU 16 Apr '07

16 Apr '07

On Fri, Apr 13, 2007 at 11:29:39PM +0200, Hallvard B Furuseth wrote: > hyc(a)symas.com writes: > > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > > libraries that would make the backtrace more useful. > > ...which I think you build with > env ac_cv_prog_STRIP=":" ./configure ... I tried ac_cv_proj_STRIP as well as STRIP, but the Makefiles were still prepared with "STRIP = -s" which then leads to "install -s". I found this: http://www.openldap.org/lists/openldap-bugs/200604/msg00123.html I edited build/top.mk and removed the '-s' from STRIP and the configure stage prepared Makefiles with "STRIP = ". But the original issue has been resolved due to a local build issue. Thanks! Ryan

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.Berkeley.EDU 16 Apr '07

16 Apr '07

On Fri, Apr 13, 2007 at 02:10:19PM -0700, Howard Chu wrote: > >cups 1.2.10 invokes pam_authenticate which on my system goes through ldap. > >When > >cups tries to authenticate it is dumping core. The backtrace seems to show > >that > >it is crashing within the OpenLDAP code. I'm using the PADL libraries, not > >the > >native Solaris libraries. > > A few things: > 1) This is most likely going to be an nss_ldap issue. > 2) please provide the output for "info shared" in gdb. > 3) if you can reproduce this issue with an unstripped set of OpenLDAP > libraries that would make the backtrace more useful. Thanks for your feedback. Your second tip, running "info shared", showed that cups was linking against 2 different LDAP libraries, the one I intended and the one in /opt/SFW/. Once I fixed the build everything worked just fine. This issue can be closed. Ryan

1 0

Problème with SASL/DIGEST-MD5 authentication
by Abdelmjid HALLOUM 16 Apr '07

16 Apr '07

hi, i am a beginer with OpenLDAP, i installed it in my mchine ubuntu 6 but when i the problem is : root # ldapadd ............................) SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database anyhelp?

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs