- openldap-bugs - openldap.org

(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 21 Apr '07

21 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

Re: (ITS#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by hyc＠symas.com 16 Apr '07

16 Apr '07

imtiazpk82(a)gmail.com wrote: > Full_Name: Imtiaz Khadim > Version: 3 > OS: Window server 2000 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.38.48.230) > > > Hi, > > I am using Sun Iplanet Directory Server 5.2 That's your first problem. Nothing in this report has anything to do with OpenLDAP Software. I suggest you contact Sun for assistance, or upgrade from the Sun server to a current OpenLDAP release. This ITS will be closed. > and LDAP Version 3.0 to fetch > records. The Problem currently i am facing is as follow > > I have made three conection to Iplanet Directory with same authentication level. > Each connection apply diferent filter and fetch records. > First rule fetch 15000 records. > and 2nd and third fetch 700 record each and this schedule is to be run on every > day. > First time it fetch records correctly but when on next day it ran again 2nd and > third filter run correctly but when first filter is applied the API > ldap_search_s() return error code 0x34. Why this happen? the other two are > working fine and these three connections are part of one application. Can any > one help me out please. > > reagrds > Imtiaz Khadim > > > . > -- -- 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#4928) LDAP Error 0x34=LDAP_UNAVAILABLE
by imtiazpk82＠gmail.com 16 Apr '07

16 Apr '07

Full_Name: Imtiaz Khadim Version: 3 OS: Window server 2000 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.38.48.230) Hi, I am using Sun Iplanet Directory Server 5.2 and LDAP Version 3.0 to fetch records. The Problem currently i am facing is as follow I have made three conection to Iplanet Directory with same authentication level. Each connection apply diferent filter and fetch records. First rule fetch 15000 records. and 2nd and third fetch 700 record each and this schedule is to be run on every day. First time it fetch records correctly but when on next day it ran again 2nd and third filter run correctly but when first filter is applied the API ldap_search_s() return error code 0x34. Why this happen? the other two are working fine and these three connections are part of one application. Can any one help me out please. reagrds Imtiaz Khadim

1 0

Re: (ITS#4922) test_filter problem on uid filter
by ando＠sys-net.it 16 Apr '07

16 Apr '07

Please post replies to the ITS system. Juri Tanganelli wrote: > The entry e497004 is a candidate for sure My point is: it's clear that if you filter for (uid=e497004) the corresponding entry must be selected as candidate. But does it actually get selected, and does test_filter() get applied to it? I understand it's obvious, but the typical bug with things that have always worked is that one believes they don't work while the point is that they don't get used as one expects. You should check this. > : a filter on a different > attribute > of the same entry returns the correct result. I can provide you with any > information you need for an analysis of the problem (stack trace, variable > dumps, etc...). > What kind of information do you want me to produce? Well, you should check that when searching for (uid=e497004) test_filter() gets invoked and the entry passed to it contains the attribute "uid" with the value "e497004". To do this, you should run slapd within a debugger, set a breakpoint at test_filter() and, as soon as the function is entered, check the contents of e->e_attrs down the list until you find the "uid" attribute. If the attribute is there with the requested value, and it is searchable (ACL), test_filter() must succeed (return LDAP_COMPARE_TRUE). So you need to check: - the presence of "uid" - the presence of the desired value - the access privileges of the identity that runs the request It might be that test_filter() returns LDAP_COMPARE_TRUE but the result is handled incorrectly by your custom backend, or by the frontend based on the way the result is passed back to it. By stepping through the whole operation you should be able to detect what goes wrong. If you find out that the error is in test_filter(), we'll be happy of fixing it, of course. p. 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#4927) pam_authenticate through ldap causes cups to crash
by hyc＠symas.com 13 Apr '07

13 Apr '07

h.b.furuseth(a)usit.uio.no 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 ... > No need to rerun configure. Just "make install STRIP=" -- -- 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

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by h.b.furuseth＠usit.uio.no 13 Apr '07

13 Apr '07

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 ... -- Regards, Hallvard

1 0

Re: (ITS#4927) pam_authenticate through ldap causes cups to crash
by hyc＠symas.com 13 Apr '07

13 Apr '07

ryan(a)stat.berkeley.edu wrote: > Full_Name: Ryan Lovett > Version: 2.3.32 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.32.135.6) > > > 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. -- -- 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#4927) pam_authenticate through ldap causes cups to crash
by ryan＠stat.berkeley.edu 13 Apr '07

13 Apr '07

Full_Name: Ryan Lovett Version: 2.3.32 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.32.135.6) 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. #0 0xfe50ddf0 in ldap_abandoned () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 (gdb) bt #0 0xfe50ddf0 in ldap_abandoned () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #1 0xfe50b354 in chkResponseList () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #2 0xfe50b230 in ldap_result () from /usr/local/openldap-2.3.32/lib/libldap-2.3.so.0 #3 0xfe5d40f0 in do_bind (ld=0x1272d8, timelimit=30, dn=0xfe5f4a65 "uid=ldapadmin,cn=users,dc=our,dc=ldap,dc=domain", pw=0xfe5f4b7c "PaSsWoRD", with_sasl=1) at ldap-nss.c:1792 #4 0xfe5d49b8 in do_with_reconnect ( base=0xfe5f4acc "cn=users,dc=our,dc=ldap,dc=domain", scope=1, filter=0xffbefa60 "(&(objectClass=shadowAccount)(uid=op))", attrs=0xfe5f57dc, sizelimit=1, private=0xffbf02e0, search_func=0xfe5d4ef0 <do_search_s>) at ldap-nss.c:1620 #5 0xfe5d7a00 in _nss_ldap_search_s (args=0xffbf0368, filterprot=0xfe5fa2a0 "(&(objectClass=shadowAccount)(uid=%s))", sel=LM_SHADOW, user_attrs=0x0, sizelimit=1, res=0xffbf02e0) at ldap-nss.c:3047 #6 0xfe5d7b84 in _nss_ldap_getbyname (args=0xffbf0368, result=0x128430, buffer=0x12c0e0 "nobody4", buflen=1024, errnop=0xffbf0484, filterprot=0xfe5fa2a0 "(&(objectClass=shadowAccount)(uid=%s))", sel=LM_SHADOW, parser=0xfe5db86c <_nss_ldap_parse_sp>) at ldap-nss.c:3394 #7 0xfe5dbb88 in _nss_ldap_getspnam_r (be=0x3, args=0xffbf0460) at ldap-spwd.c:136 #8 0xfeddbbfc in nss_search () from /lib/libc.so.1 #9 0xfedcad80 in getspnam_r () from /lib/libc.so.1 #10 0xfeba9630 in nss_getpwnam () from /usr/lib/passwdutil.so.1 #11 0xfeba9778 in nss_getattr () from /usr/lib/passwdutil.so.1 #12 0xfeba2e90 in __get_authtoken_attr () from /usr/lib/passwdutil.so.1 #13 0xfebd0cf0 in pam_sm_authenticate () from /usr/lib/security/pam_authtok_get.so.1 #14 0xff2d2c88 in run_stack () from /lib/libpam.so.1 #15 0xff2d2f2c in pam_authenticate () from /lib/libpam.so.1 #16 0x00018b70 in cupsdAuthorize (con=0x140fe8) at auth.c:513 #17 0x0001eb98 in cupsdReadClient (con=0x140fe8) at client.c:1033 #18 0x0002dd04 in main (argc=476808, argv=0x461fc665) at main.c:934

1 0

Re: (ITS#4926) german special characters ( Umlaute ) in Password
by h.b.furuseth＠usit.uio.no 13 Apr '07

13 Apr '07

2.1.22 is very old. See if it helps to upgrade. OpenLDAP has had bugs with 8-bit characters, though admittedly I don't see how those would affect passwords. Have you checked that the bug is not in your C program's input routine? Print out the password before passing it to OpenLDAP. -- Regards, Hallvard

1 0

(ITS#4926) german special characters ( Umlaute ) in Password
by m.birkenkamp＠e-fact-gmbh.de 13 Apr '07

13 Apr '07

Full_Name: Marcel Birkenkamp Version: 2.1.22 OS: HP-UX 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.63.14.237) hi, i have a problem submitting passwords containing german special characters (Umlaute ä,ü,ö & ß) by using the OpenLDAP Function ldap_simple_bind_s to our Active Directory Server. After investigating the issue it seems as if the password is cut off at the position of the special char, since it is possible to log in a user with his password (without special characters) if i use the correct password and add one of these characters to the end. Example: password for user: test submitted: testö this would succeed the problem is if a user i.e. enters the password: bäume the submitted password is: b Is there a fix/workaround for this? btw: i'm using this in a c program. Thanks in advance.

1 0

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

13 Apr '07

On Friday 13 April 2007 01:11, Pierangelo Masarati wrote: > You should print the contents of "res", which contains the offending > response message type. (gdb) frame 3 #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 465 assert( 0 ); (gdb) print *res $5 = {lm_msgid = 530, lm_msgtype = 96, lm_ber = 0x10020238, lm_chain = 0x0, lm_chain_tail = 0x10021458, lm_next = 0x0, lm_time = 0} (gdb) print *res->lm_ber $6 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 96, ber_len = 13, ber_usertag = 0, ber_buf = 0x10021368 "\002\002\002\022`\a\002\001\003\004", ber_ptr = 0x1002136c "`\a\002\001\003\004", ber_end = 0x10021375 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 13 Apr '07

13 Apr '07

rhafer(a)suse.de wrote: > #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 > tv = {tv_sec = 0, tv_usec = 100000} > res = (LDAPMessage *) 0x10021458 > msgid = 530 > rc = 0 > passwd = {bv_len = 0, bv_val = 0x0} > err = 1 > savedefconn = (LDAPConn *) 0x10016098 > lc = (LDAPConn *) 0x10016310 > srv = (LDAPURLDesc *) 0x10020278 > __PRETTY_FUNCTION__ = "ldap_new_connection" You should print the contents of "res", which contains the offending response message type. p. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

Hallvard suggested that a backtrace might help. This is what I was able to get: (gdb) bt full #0 0x0fb4fce0 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x0fb51620 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x0fb478dc in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x0ffb459c in ldap_new_connection (ld=0x10016128, srvlist=0x10020278, use_ldsb=0, connect=1, bind=0xff9b4624) at request.c:465 tv = {tv_sec = 0, tv_usec = 100000} res = (LDAPMessage *) 0x10021458 msgid = 530 rc = 0 passwd = {bv_len = 0, bv_val = 0x0} err = 1 savedefconn = (LDAPConn *) 0x10016098 lc = (LDAPConn *) 0x10016310 srv = (LDAPURLDesc *) 0x10020278 __PRETTY_FUNCTION__ = "ldap_new_connection" #4 0x0ffb3c44 in ldap_send_server_request (ld=0x10016128, ber=0x10020338, msgid=529, parentreq=0x100163e0, srvlist=0x10020278, lc=0x0, bind=0xff9b4624) at request.c:206 lr = (LDAPRequest *) 0xffb6cb8 incparent = 1 rc = -6601376 #5 0x0ffb5d34 in ldap_chase_v3referrals (ld=0x10016128, lr=0x100163e0, refs=0x0, sref=1, errstrp=0x100163fc, hadrefp=0xff9b46f4) at request.c:1013 unfollowed = 0x0 unfollowedcnt = 0 origreq = (LDAPRequest *) 0x100163e0 srv = (LDAPURLDesc *) 0x10020278 ber = (BerElement *) 0x10020338 refarray = (char **) 0x10016218 lc = (LDAPConn *) 0x0 rc = 0 count = 0 i = 0 j = 267910176 id = 529 rinfo = {ri_msgid = 528, ri_request = 99, ri_url = 0x100201f0 "ldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub"} #6 0x0ff970e0 in try_read1msg (ld=0x10016128, msgid=528, all=1, lcp=0xff9b47e0, result=0xff9b48bc) at result.c:560 tmpber = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 0, ber_len = 73, ber_usertag = 0, ber_buf = 0x100201a0 "\002\002\002\020sC\004Aldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub", ber_ptr = 0x100201e9 "", ber_end = 0x100201e9 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} refs = (char **) 0x10016218 ber = (BerElement *) 0x10020170 newmsg = (LDAPMessage *) 0x100162f0 l = (LDAPMessage *) 0x0 prev = (LDAPMessage *) 0x0 id = 528 tag = 115 len = 67 foundit = 0 lr = (LDAPRequest *) 0x100163e0 tmplr = (LDAPRequest *) 0x0 lc = (LDAPConn *) 0x10016098 tmpber = {ber_opts = {lbo_valid = 4095, lbo_options = 26992, lbo_debug = -6601008}, ber_tag = 4288366336, ber_len = 268140648, ber_usertag = 0, ber_buf = 0xffffffff <Address 0xffffffff out of bounds>, ber_ptr = 0x100170b8 "", ber_end = 0x3 <Address 0x3 out of bounds>, ber_sos = 0x10016128, ber_rwptr = 0x10016238 "", ber_memctx = 0xff9b4730} rc = -2 refer_cnt = 0 hadref = 0 simple_request = 0 lderr = 268396596 tmp = (LDAPMessage *) 0x0 chain_head = (LDAPMessage *) 0x0 moremsgs = 0 isv2 = 0 v3ref = V3REF_TOAPP __PRETTY_FUNCTION__ = "try_read1msg" #7 0x0ff96994 in wait4msg (ld=0x10016128, msgid=528, all=1, timeout=0x0, result=0xff9b48bc) at result.c:344 lc_ready = 0 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} tvp = (struct timeval *) 0x0 start_time = 0 tmp_time = -6600704 lc = (LDAPConn *) 0x10016098 __PRETTY_FUNCTION__ = "wait4msg" #8 0x0ff9612c in ldap_result (ld=0x10016128, msgid=528, all=1, timeout=0x0, result=0xff9b48bc) at result.c:124 lm = (LDAPMessage *) 0x0 rc = 268567256 __PRETTY_FUNCTION__ = "ldap_result" #9 0x0ff9a860 in ldap_search_s (ld=0x10016128, base=0x10016048 "o=Example,c=US", scope=2, filter=0x10016060 "cn=Barbara Jensen", attrs=0xff9b48ac, attrsonly=0, res=0xff9b48bc) at search.c:379 msgid = 528 #10 0x100020a0 in do_search (uri=0x0, host=0x10016008 "localhost", port=9013, manager=0x10016018 "cn=Manager,o=Example,c=US", passwd=0x10016038 "secret", sbase=0x10016048 "o=Example,c=US", filter=0x10016060 "cn=Barbara Jensen", maxloop=500, maxretries=20, delay=0) at slapd-search.c:201 ld = (LDAP *) 0x10016128 i = 263 do_retry = 20 attrs = {0x10003dfc "%d).\n", 0x10003e00 "\n", 0x0} pid = 13557 rc = 0 #11 0x10001eac in do_search (uri=0x0, host=0x0, port=19, manager=0xff9b4bd4 "�\233N��\233O\b�\233O\v�\233O\025�\233O\030�\233O\035�\233O �\233O:�\233O=�\233OD�\233OG�\233OJ�\233OM�\233OP�\233OS�\233OU�\233OX�\233Og�\233Oj", passwd=0x22 <Address 0x22 out of bounds>, sbase=0xff9b4bd4 "�\233N��\233O\b�\233O\v�\233O\025�\233O\030�\233O\035�\233O �\233O:�\233O=�\233OD�\233OG�\233OJ�\233OM�\233OP�\233OS�\233OU�\233OX�\233Og�\233Oj", filter=0xff9b4950 "�\233K\200\017�\217`�", maxloop=-134155200, maxretries=-134154560, delay=-134154568) at slapd-search.c:156 ld = (LDAP *) 0x10016038 i = 268525640 do_retry = 268525664 attrs = {0x10016018 "cn=Manager,o=Example,c=US", 0x10016008 "localhost", 0x0} pid = 0 rc = 20 #12 0x0fb38f60 in generic_start_main () from /lib/libc.so.6 No symbol table info available. #13 0x0fb3918c in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #14 0x00000000 in ?? () No symbol table info available. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

Ralf Haferkamp wrote: > It's not back-ldap that's trying to chase referrals here. It's slapd-search > (from the tester binaries), but if I see it corretcly that has referral > chasing turned of as well. At least it is not started with the -C option, > which should enable referral chasing. That's indeed puzzling. OK, I completely screwed the thing. slapd-search doesn't do anything about referrals, so it sticks with the default of libldap (on); also, it seems to have no -C flag. I'll fix this in a moment. This leaves the open point of ldap_result() returning what appears to be LDAP_REQ_BIND instead of a LDAP_RES_* in response to ... LDAP_REQ_BIND itself. Still digging... p. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 17:39, Pierangelo Masarati wrote: > Ralf Haferkamp wrote: > > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was > >> already present in earlier versions? > > > > I checked back to 2.3.27 and the problem as present there as well. I was > > however not yet able to reproduce the issue on another architecture, I've > > been running test039 for a few hours on an Intel x86_64 box without any > > problem. > > So this problem might as well be locate in some other part of the system > > (kernel, glibc, ...). What do you think? > > What puzzles me is that referral chasing should be disabled in that > test. In fact, slapd.3.conf contains "chase-referrals no" for both > instances of back-ldap. It's not back-ldap that's trying to chase referrals here. It's slapd-search (from the tester binaries), but if I see it corretcly that has referral chasing turned of as well. At least it is not started with the -C option, which should enable referral chasing. That's indeed puzzling. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

Ralf Haferkamp wrote: > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was >> already present in earlier versions? > I checked back to 2.3.27 and the problem as present there as well. I was > however not yet able to reproduce the issue on another architecture, I've > been running test039 for a few hours on an Intel x86_64 box without any > problem. > So this problem might as well be locate in some other part of the system > (kernel, glibc, ...). What do you think? > What puzzles me is that referral chasing should be disabled in that test. In fact, slapd.3.conf contains "chase-referrals no" for both instances of back-ldap. p. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > Another comment: would it be possible to check if the problem was > already present in earlier versions? I checked back to 2.3.27 and the problem as present there as well. I was however not yet able to reproduce the issue on another architecture, I've been running test039 for a few hours on an Intel x86_64 box without any problem. So this problem might as well be locate in some other part of the system (kernel, glibc, ...). What do you think? -- Ralf

1 0

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

12 Apr '07

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > ando(a)sys-net.it wrote: > > rhafer(a)suse.de wrote: > >> I was able to reproduce this problem again. It does not happen during > >> every run of test039-glue-ldap-concurrency (probably during 1 out of > >> 10). This time I had enabled debug logging in the slapd-search tester. > >> Find the log of it below. What's really strange that it fails when > >> chasing a referral to ldap://localhost:9016 (there is nothing listening > >> on port 9016 during test039) > >> > >> ldap_new_connection 0x100141e0: unexpected response 96 from BIND request > >> id=376 lt-slapd-search: request.c:470: ldap_new_connection: Assertion > >> `0' failed. > > > > 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() > > in any case. The bug is buried deeper in libldap, so the assert(0) was > > apparently worth :) > > Another comment: would it be possible to check if the problem was > already present in earlier versions? Yes, I had that on my list already. I am also trying to reproduce it on a different architecture, currently I only used different PowerPC machines. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: >> I was able to reproduce this problem again. It does not happen during every >> run of test039-glue-ldap-concurrency (probably during 1 out of 10). This >> time I had enabled debug logging in the slapd-search tester. Find the log >> of it below. What's really strange that it fails when chasing a referral to >> ldap://localhost:9016 (there is nothing listening on port 9016 during >> test039) > >> ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 >> lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. > > 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() > in any case. The bug is buried deeper in libldap, so the assert(0) was > apparently worth :) Another comment: would it be possible to check if the problem was already present in earlier versions? p. 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#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

rhafer(a)suse.de wrote: > I was able to reproduce this problem again. It does not happen during every > run of test039-glue-ldap-concurrency (probably during 1 out of 10). This > time I had enabled debug logging in the slapd-search tester. Find the log > of it below. What's really strange that it fails when chasing a referral to > ldap://localhost:9016 (there is nothing listening on port 9016 during > test039) > ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 > lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() in any case. The bug is buried deeper in libldap, so the assert(0) was apparently worth :) Thanks, p. 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#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

I was able to reproduce this problem again. It does not happen during every run of test039-glue-ldap-concurrency (probably during 1 out of 10). This time I had enabled debug logging in the slapd-search tester. Find the log of it below. What's really strange that it fails when chasing a referral to ldap://localhost:9016 (there is nothing listening on port 9016 during test039) [..] ldap_chase_v3referral: msgid 374, url "ldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9016 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 127.0.0.1:9016 ldap_connect_timeout: fd: 4 tm: -1 async: 0 anonymous rebind via ldap_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ldap_result ld 0x100141e0 msgid 376 ldap_chkResponseList ld 0x100141e0 msgid 376 all 1 ldap_chkResponseList returns ld 0x100141e0 NULL wait4msg ld 0x100141e0 msgid 376 (timeout 100000 usec) wait4msg continue ld 0x100141e0 msgid 376 all 1 ** ld 0x100141e0 Connections: * host: localhost port: 9016 refcnt: 2 status: Connected last used: Thu Apr 12 08:10:47 2007 rebind in progress queue is empty * host: localhost port: 9013 (default) refcnt: 2 status: Connected last used: Thu Apr 12 08:10:47 2007 ** ld 0x100141e0 Outstanding Requests: * msgid 376, origid 376, status InProgress outstanding referrals 0, parent count 0 * msgid 374, origid 374, status InProgress outstanding referrals 1, parent count 0 ** ld 0x100141e0 Response Queue: * msgid 374, type 100 ldap_chkResponseList ld 0x100141e0 msgid 376 all 1 ldap_chkResponseList returns ld 0x100141e0 NULL ldap_int_select read1msg: ld 0x100141e0 msgid 376 all 1 read1msg: ld 0x100141e0 msgid 376 message type unknown new result: res_errno: 3, res_error: <>, res_matched: <> read1msg: ld 0x100141e0 0 new referrals read1msg: mark request completed, ld 0x100141e0 msgid 376 request done: ld 0x100141e0 msgid 376 res_errno: 3, res_error: <>, res_matched: <> ldap_free_request (origid 376, msgid 376) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. [..] -- Ralf

1 0

Re: (ITS#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by jclarke＠linagora.com 12 Apr '07

12 Apr '07

Pierangelo Masarati wrote: > jclarke(a)linagora.com wrote: > >> When trying a modify operation (such as changing or adding a value of an >> attribute) with the NOOP control (set to critical) on an entry stored in a BDB >> backend, slapd crashes, with the following error: > > Thanks, applied to HEAD/re23. Please test and report. p. Just tested HEAD and RE23, NOOP works great on all operations. Thanks! -- Jonathan Clarke Linagora - OSSA 27, rue de Berri 75008 Paris Tél. 01 58 18 68 28 Fax. 01 58 18 68 29

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 12 Apr '07

12 Apr '07

ando(a)sys-net.it wrote: > Right. Time permitting, I'll check why back-sql behaves differently > and, in case, how to fix it. HEAD should be working as expected, now. I've also updated mysql and psql sql-test000 (the latter is untested, though). Please test and report. p. 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#4922) test_filter problem on uid filter
by ando＠sys-net.it 11 Apr '07

11 Apr '07

juritanganelli(a)gmail.com wrote: > I have developed a custom backend that uses the test_filter function to > determine > if an entry is matching a given input filter. Filter on any of the entry > attribute but Uid works fine. When i specify i filter on the uid attribute i get > very strange results for example: > > - when i use the complete value of the attribute such as uid=e497004 no result > is returned, but there is an entry with that value. > - when i use some regular expressions the result is correclty such as uid=e* the > corresponding entry is correctly returned. Unless you can show evidence that the problem is within test_filter(), which is known to work as expected, custom code issues cannot be considered OpenLDAP issues. You don't provide enough information to prove the above, so this ITS will be suspended waiting for further information. For example, did you check that the entry with uid=e497004 was actually candidate and thus subjected to test_filter()? p. 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#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by ando＠sys-net.it 11 Apr '07

11 Apr '07

jclarke(a)linagora.com wrote: > When trying a modify operation (such as changing or adding a value of an > attribute) with the NOOP control (set to critical) on an entry stored in a BDB > backend, slapd crashes, with the following error: Thanks, applied to HEAD/re23. Please test and report. p. 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

(ITS#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by jclarke＠linagora.com 11 Apr '07

11 Apr '07

Full_Name: Jonathan Clarke Version: 2.3.35 OS: Linux (ubuntu) URL: Submission from: (NULL) (213.41.243.192) When trying a modify operation (such as changing or adding a value of an attribute) with the NOOP control (set to critical) on an entry stored in a BDB backend, slapd crashes, with the following error: *** glibc detected *** ./servers/slapd/slapd: munmap_chunk(): invalid pointer: 0x0821e235 *** ======= Backtrace: ========= [...] ======= Memory map: ======== [...] Abandon (core dumped) This only happens for operations that should succeed (ie, should return the NOOP error code LDAP_X_NO_OPERATION). Operations which fail for other reasons (refused by ACLs, schema error, etc) do not make slapd crash. I have tested this on versions 2.3.32, 2.3.34, 2.3.35 and HEAD (as of today). The crash only happens with the BDB backend (I tested slapd with a ldap backend which only made the remote slapd with a BDB backend crash, not the one with the ldap backend). After some investigation, I found that this crash results from a call to attrs_free() in servers/slapd/back-bdb/modify.c, after the "return_results" label. This seems to be a double free() problem. The following patch solved the problem for me on versions 2.3.32, 2.3.34, 2.3.35 and HEAD (as of today). With this patch, NOOP behaves as expected. The patch simply adds 2 lines copied from the error handling "if" higher up in the same function (bdb_modify). ---------------------BEGIN PATCH--------------------- --- modify.c.~1.124.2.16.~ 2007-01-02 22:44:00.000000000 +0100 +++ modify.c 2007-04-11 14:44:56.000000000 +0200 @@ -538,6 +538,8 @@ } else { rs->sr_err = LDAP_X_NO_OPERATION; ltid = NULL; + /* Only free attrs if they were dup'd. */ + if ( dummy.e_attrs == e->e_attrs ) dummy.e_attrs = NULL; goto return_results; } } else { ----------------------END PATCH---------------------- (sorry not to put this patch on an FTP site, but ftp.openldap.org complains with 452 Error writing file: No space left on device.) I, Jonathan Clarke, hereby place the preceding modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#4910) mirrormode prevents syncrepl engine from working
by ali.pouya＠free.fr 11 Apr '07

11 Apr '07

Works fine. Thanks a lot. Issue to be closed. Best regards Ali Pouya

1 0

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 10 Apr '07

10 Apr '07

I have new tar.gz file ready, this time with unstripped binaries: http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz root@cemetery:~$ ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.3-releng.so.2 => /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000) liblber-2.3-releng.so.2 => /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000) libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000) libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000) libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000) libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000) libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000) libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000) libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000) libc.so.6 => /lib/libc.so.6 (0xa8319000) root@cemetery:~$ file /usr/local/libexec/slapd /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped Please let me know if there is anything else you need, --imriz > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Tuesday, April 03, 2007 12:42 AM > To: Imri Zvik ( Smile ) > Cc: openldap-its(a)openldap.org > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > imriz(a)co.zahav.net.il wrote: > > Sure. New core dumps and binary file is at > > http://mariska.inter.net.il/~imriz/slapd-core.tar.gz > > The slapd in this snapshot was stripped so no debug symbols are > present. > Please be sure to use an unstripped binary. > > Also, since you're also loading libldap_r, liblber, back-ldap, back- > bdb, > back-meta, and back-ldbm dynamically, you'll need to include those > modules in the tarball. (Also with debug and unstripped.) > > Although at this point I'm wondering why you're using back-ldbm, which > has been deprecated for quite a long time. > > > Please notice that the previous dump was from FreeBSD ports (OpenLDAP > > version 2.3.33). > > > > This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > > following configure options: > > > > ./configure --with-threads=posix --with-tls=openssl --enable-dynamic > > --without-cyrus-sasl --enable-modules --localstatedir=/var/ > > db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable- > ldap=mod > > --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > > e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod > > --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > > prefix=/usr/local --enable-debug > > > > > > -----Original Message----- > > From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > > Sent: Tuesday, February 13, 2007 1:14 AM > > To: Imri Zvik > > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > > > It looks like this core is from a binary without debug symbols > present, > > can you > > recompile with debugging enabled and get a new stack trace and core > > file? > > > > > > . > > > > > -- > -- 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

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

That assert() looks bad anyway. Looks like a server can crash the client by sending an incorrectly tagged result. -- Regards, Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs