openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 05 Sep '10

05 Sep '10

> Hello, > >> Hi. I don't have time to work at this right now, but I think the >> solution >> would be to modify slapo-chain(5) so that when a referral's DN is "" and >> the DN in the original request is not "", to use that DN instead. The >> original request DN can be found in op->o_req_dn. > > we tested the following - with success: > > Just replace in servers/slapd/back-ldap/chain.c, function > ldap_chain_op(), line 485-486: > > op->o_req_dn = pdn; > op->o_req_ndn = ndn; > > With: > > if (pdn.bv_len > 0) { > op->o_req_dn = pdn; > } > if (ndn.bv_len > 0) { > op->o_req_ndn = ndn; > } > > It would be great if this came into the official code. This issue was fixed consistently in HEAD code more than a month ago, please test it and report, so in case it works the ITS can be closed and the fix released. Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by jochen＠keutel.de 05 Sep '10

05 Sep '10

Hello, > Hi. I don't have time to work at this right now, but I think the solution > would be to modify slapo-chain(5) so that when a referral's DN is "" and > the DN in the original request is not "", to use that DN instead. The > original request DN can be found in op->o_req_dn. we tested the following - with success: Just replace in servers/slapd/back-ldap/chain.c, function ldap_chain_op(), line 485-486: op->o_req_dn = pdn; op->o_req_ndn = ndn; With: if (pdn.bv_len > 0) { op->o_req_dn = pdn; } if (ndn.bv_len > 0) { op->o_req_ndn = ndn; } It would be great if this came into the official code. Regards, Jochen.

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 04 Sep '10

04 Sep '10

--On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister <whm(a)stanford.edu> wrote: The problem with the database was only coincidental. Restoring the database got the failing replica past the problem replication event. In the replica pool of 6 servers we have seen the problem on there of the servers. In thinking about this more it is unlikely that it is a slave problem since the slaves have been in use for about 6 weeks and we did not see the problem. Only when we changed the master to 2.4.23 did we see the problem. I have captured a master debug log of the problem event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 03 Sep '10

03 Sep '10

Worked on this a bit more and in the end rebooted the server just to be sure I had a clean environment. When the system came back up slapd refused to start, the bdb database was corrupt. I reloaded from the master and replication is again working. Not sure why a reboot was required to uncover the error. I had stopped and started slapd multiple times without an errors being reported. Sorry for the inbox pollution. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 03 Sep '10

03 Sep '10

Full_Name: Bill MacAllister Version: 2.4.23-1 OS: Debian Lenny URL: http://www.stanford.edu/~whm/files/ldap-replication-error.txt Submission from: (NULL) (99.55.172.208) I just replaced a 2.3.43 OpenLDAP master with a 2.4.23-1 master. There are 6 slaves all running 2.4.23-1. After reloading the master database, I confirmed that replication was working my making some changes and then examining contextCSNs. Sometime later replication stopped on one of the servers. Looking at the log on the failing slave I saw: Sep 2 22:12:53 directory3 slapd[7005]: do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Sep 2 22:12:53 directory3 slapd[7005]: do_syncrep2: rid=000 (-1) Can't contact LDAP server Sep 2 22:12:53 directory3 slapd[7005]: do_syncrepl: rid=000 rc -1 retrying On the master I saw: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 fd=38 ACCEPT from IP=171.67.218.156:44519 (IP=0.0.0.0:389) Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=0 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=1 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND dn="" method=163 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND authcid="ldap/directory3.stanford.edu(a)stanford.edu" authzid="ldap/directory3.stanford.edu(a)stanford.edu" Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 BIND dn="cn=directory3,cn=ldap,cn=operational,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=2 RESULT tag=97 err=0 text= Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 op=3 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 2 22:12:53 directory-master0 slapd[15145]: conn=3764 fd=38 closed (connection lost on write) Running slapd on the failing slave with -d -1 I saw: =>do_syncrep2 rid=000 ldap_result ld 0x1c07000 msgid 4 wait4msg ld 0x1c07000 msgid 4 (timeout 0 usec) wait4msg continue ld 0x1c07000 msgid 4 all 0 ** ld 0x1c07000 Connections: * host: directory-master.stanford.edu port: 389 (default) refcnt: 2 status: Connected last used: Thu Sep 2 22:12:53 2010 ** ld 0x1c07000 Outstanding Requests: * msgid 4, origid 4, status InProgress outstanding referrals 0, parent count 0 ld 0x1c07000 request count 1 (abandoned 0) ** ld 0x1c07000 Response Queue: Empty ld 0x1c07000 response count 0 ldap_chkResponseList ld 0x1c07000 msgid 4 all 0 ldap_chkResponseList returns ld 0x1c07000 NULL ldap_int_select read1msg: ld 0x1c07000 msgid 4 all 0 ber_get_next sasl_generic_read: want=4, got=4 0000: 00 00 00 78 ...x sasl_generic_read: want=120, got=120 ... lots of output ... sasl_generic_read: want=45833, got=0 ldap_read: want=8, got=0 ber_get_next failed. ldap_err2string do_syncrep2: rid=000 (-1) Can't contact LDAP server I am including a pointer to the complete debug log. Looks like something in the sasl support is unhappy. We are using libsasl2-modules-gssapi-heimdal 2.1.23.dfsg1-5~sbp50+2. Strange to me that this one server is having a problem. There are actually 5 slaves that are working just fine. Here are current contextCSNs for the systems. directory-master contextCSN: 20100903060040.713677Z#000000#000#000000 directory1 contextCSN: 20100903060040.713677Z#000000#000#000000 directory2 contextCSN: 20100903060040.713677Z#000000#000#000000 directory3 contextCSN: 20100903015531.064407Z#000000#000#000000 directory4 contextCSN: 20100903060040.713677Z#000000#000#000000 directory11 contextCSN: 20100903060040.713677Z#000000#000#000000 directory12 contextCSN: 20100903060040.713677Z#000000#000#000000 What else should I look at? Bill

1 0

(ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 02 Sep '10

02 Sep '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Mac OSX 10.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When querying AD from a mac, we found that we can segfault ldapsearch. This segfault does not happen when running the same query from linux. Here is the backtrace: (gdb) thr apply all bt full Thread 1 (core thread 0): #0 0x00007fff80697180 in strlen () No symbol table info available. #1 0x000000010008ae22 in ber_put_string (ber=0x100401480, str=0x686372616573 <Address 0x686372616573 out of bounds>, tag=18446744073709551615) at encode.c:273 No locals. #2 0x000000010008be20 in ber_printf (ber=0x100401480, fmt=0x10005f5e4 "s{") at encode.c:575 ap = {{ gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fff5fbfeb00, reg_save_area = 0x7fff5fbfea40 }} s = 0x686372616573 <Address 0x686372616573 out of bounds> ss = (char **) 0x0 bv = (struct berval *) 0x0 bvp = (struct berval **) 0x7fff8069dc3b rc = 0 i = 584234 len = 140734799800880 #3 0x00000001000586d8 in ldap_create_deref_control_value (ld=0x100401130, ds=0x100400130, value=0x100016a20) at deref.c:68 j = 1 ber = (BerElement *) 0x100401480 tag = 18 i = 1 __func__ = "\000\000\000\000\000\000\000Critical extension is una" #4 0x0000000100003a28 in main (argc=13, argv=0x7fff5fbff4f8) at ldapsearch.c:1090 i = 0 filtpattern = 0x7fff5fbff739 "(CN=SE-EMEA-OEM)" attrs = (char **) 0x7fff5fbff558 line = '\0' <repeats 504 times>, "ï¿œï¿œï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000\006\003ï¿œï¿œï¿œ\000\000\000ï¿œ_ï¿œ\000\000ï¿œ&ï¿œ_ï¿œ", '\0' <repeats 18 times>, "ï¿œï¿œï¿œ_ï¿œ\000\000\020ï¿œ_ï¿œ\000\000ï¿œï¿œ_ï¿œ\000\000ï¿œ\005ï¿œ_ï¿œ\000\000ï¿œï¿œ~L\000\000\000\000=ï¿œ\002\000ï¿œ\000\000ï¿œ\000\000\000Ì¹ï¿œT\035ï¿œ_ï¿œï¿œdYhMï¿œ6T{ï¿œbjï¿œ\033\020v:ï¿œ*ï¿œb7\003a/ï¿œMï¿œï¿œï¿œï¿œï¿œï¿œ8ï¿œLï¿œï¿œXï¿œ\025Cï¿œÔ¶&Úxï¿œ6cï¿œOï¿œï¿œDpb*\030\tdï¿œï¿œï¿œ^biï¿œ}ï¿œï¿œ&ï¿œyï¿œfï¿œq"... fp = (FILE *) 0x0 rc = 0 rc1 = 0 i = 0 first = 0 ld = (LDAP *) 0x100401130 seber = (BerElement *) 0x0 vrber = (BerElement *) 0x0 syncber = (BerElement *) 0x0 syncbvalp = (struct berval *) 0x0 err = 0 Search was: /opt/zimbra/openldap/bin/ldapsearch -LLL -D ... -w ... -H ldap://...:3268 -x -E deref=member:mail "(CN=test)" mail Segmentation fault (core dumped)

1 0

objectClass index from slapd.conf is not working
by tim stone 02 Sep '10

02 Sep '10

Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(objectclass=Guest)" I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. Afther this, I have rebuild the complete database via slapcat/slapadd, rebuild the index for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(Pk=1234-234)" Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (Pk) Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002 dn="cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on "normal" attributes. I don't know, if it is necessary, but for objectClass I can't find a attribute definition in the schema. In the core.schema is the attribute definition for objectClass deactivated (aka #)... Kindly regards Tim Stone

2 1

Re: (ITS#6637) valgrind issues in SSL code
by hyc＠symas.com 31 Aug '10

31 Aug '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: http://www.stanford.edu/~quanah/valgrind.txt > Submission from: (NULL) (75.111.45.108) > > > Numerous > ==30949== Conditional jump or move depends on uninitialised value(s) > and > Use of uninitialised value of size 8 > > errors. See: > http://www.stanford.edu/~quanah/valgrind.txt All irrelevant. OpenSSL is intentionally written to use uninit'd bytes in its random number generators etc., and none of this is an OpenLDAP issue anyway. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 31 Aug '10

31 Aug '10

--0016364ec88477ac37048f173de5 Content-Type: text/plain; charset=ISO-8859-1 Hi there, <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any other program comes immediately to mind. </quote> Even sounds like an strange behave, as Quanah said, this information should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 01:25:23.000000000 -0300 +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 -0300 @@ -7,6 +7,8 @@ .SH SYNOPSIS .B ldapsearch [\c +.BR \-V [ V ]] +[\c .BR \-n ] [\c .BR \-c ] @@ -107,6 +109,11 @@ Option \fI\-L\fP controls the format of the output. .SH OPTIONS .TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds with the search. +.B \-VV +Prints the ldapsearch version and quit. +.TP .B \-n Show what would be done, but don't actually perform the search. Useful for debugging in conjunction with \fB\-v\fP. Please review it. Thanks, Matheus Morais --0016364ec88477ac37048f173de5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi there, <quote> That's... bizarre. Even slapd doesn&#39= ;t behave that way. Nor any other program comes immediately to mind. </= quote> Even sounds like an strange behave, as Quanah said, this i= nformation should be included on ldapsearch man page IMHO. I believe that the following patch could close this BUG: --- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300 +++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300 @@ -7,6 +7,8 @@ =A0.SH SYNOPSIS =A0.B ldapsearch =A0[\c +.BR \-= V [ V ]] +[\c =A0.BR \-n ] =A0[\c =A0.BR \-c ] @@ -107,6 +10= 9,11 @@ =A0Option \fI\-L\fP controls the format of the output. =A0.SH= OPTIONS =A0.TP +.BR \-V [ V ] +Prints the ldapsearch version and proceeds wit= h the search. +.B \-VV +Prints the ldapsearch version and quit. +.= TP =A0.B \-n =A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for =A0debugging in conjunction with \fB\-v\fP. Please review it. <br= >Thanks, Matheus Morais --0016364ec88477ac37048f173de5--

1 0

(ITS#6637) valgrind issues in SSL code
by quanah＠OpenLDAP.org 31 Aug '10

31 Aug '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: http://www.stanford.edu/~quanah/valgrind.txt Submission from: (NULL) (75.111.45.108) Numerous ==30949== Conditional jump or move depends on uninitialised value(s) and Use of uninitialised value of size 8 errors. See: http://www.stanford.edu/~quanah/valgrind.txt --Quanah

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs