openldap-bugs July 2009

openldap-bugs@openldap.org

49 participants
166 discussions

(ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristojosec＠yahoo.es 29 Jul '09

29 Jul '09

Full_Name: Evaristo Camarero Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.20) Hi, Working with slapd under heavy load it could be interesting to have TCP buffers size configurable at slapd application level instead of getting default OS values. Some fast modifications in daemon.c file to achieve a hardcoded value for the sender buffer are: int buf_size = 1572864; /* 1.5 Mb */ rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, sizeof(buf_size)); if(rc==-1) { Debug( LDAP_DEBUG_ANY, "slapd(%ld): " "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", (long) l.sl_sd, err, sock_errstr(err) ); } else { Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", (long) l.sl_sd, buf_size, 0); } Regards, Evaristo

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 29 Jul '09

29 Jul '09

jclarke(a)linagora.com wrote: > On 14.02.2009 01:51, Howard Chu wrote: >> Jonathan Clarke wrote: >>> On 13.02.2009 01:23, Howard Chu wrote: >>>> There are valid reasons to point a syncrepl consumer at the same slapd >>>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>>> subtree of a main database, etc.). Using the exhaustive matching that >>>> serverID uses would preclude those cases from working. >>> I see. I understand you don't want to break existing functionality. >>> However, I still feel this is a bug, or at least that you need to "hack" >>> the setup to get things working as expected. >> >> The docs state that "syncrepl provider" is the LDAP URI of the master >> server. If you're not putting in the same URI as the master is using, >> that's a config error, not a bug. > > Understood. Nothing is broken, and we have worked around this issue > using explicit listeners to slapd -h. > > This behaviour did surprise me, considering the behaviour of serverID > matching. May I suggest that a note of warning is included in the admin > guide? For example: > http://milopita.phillipoux.net/jonathan-clarke-20090216.patch > >>> Would I be right in assuming that in all the "valid reasons to point a >>> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >>> uses a different base DN than the base DN of the database that the >>> syncrepl consumer is configured on? If so, maybe the exhaustive matching >>> that serverID uses could be used, if and only if those two base DNs are >>> different? Actually, the exhaustive matching is only needed if the two base DNs are the same. This is now patched in HEAD, please test. >> That sounds reasonable. Will think about it a bit more. Certainly if the >> two base DNs are the same, it will cause a loop... > > Indeed. For what it's worth, while testing on cn=config, I noticed this > having various consequences including: > 1) cn=config becoming read-only (shadow) and updates returning a referral. > 2) in a MMR setup, some updates not being replicated to all N servers. -- -- 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#6233) print_deref assertion if no deref attributes returned
by hyc＠symas.com 28 Jul '09

28 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.17+ (current HEAD) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.113.59.19) > > > I am testing the LDAP Dereference feature specified here - > http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masara… > > I am getting an assertion in common.c at line 2077: > 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); > 2075: *ptr++ = '\n'; > 2076: *ptr++ = '\0'; > 2077: assert( ptr<= buf + len ); > > tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf); > > In my test, ptr is one greater than buf + len. It appears that len does not > take into consideration the addition of the trailing \0 at line 2076. My test > is looking for a dereference attribute which does not have any values, so that > the attrVals in the control response is empty. If there are values to return in > attrVals, the assertion is not triggered. > Ah the ever-popular off-by-one. Should be OK now in HEAD, thanks for the report. -- -- 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#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by hyc＠symas.com 28 Jul '09

28 Jul '09

steffen.hau(a)rz.uni-mannheim.de wrote: > Full_Name: Steffen Hau > Version: 2.4.17 > OS: gentoo > URL: > Submission from: (NULL) (134.155.35.13) > > > Gentoo prefers gnutls usage over openssl when compiling openldap. But if > with-tls=gnutls and enable-lmpasswd set, neither HAVE_OPENSSL nor NAVE_MOZNSS is > defined and passwd.c failes to compile with: See ITS #4997. There is a patch for this in the debian bug tracker, but until someone with appropriate authorization (i.e., the patch author) contributes it to the ITS with the requisite Rights statements attached, we cannot incorporate it. > passwd.c:813: error: expected declaration specifiers or ... before des_key > passwd.c: In function lmPasswd_to_key: > passwd.c:828: error: key undeclared (first use in this function) > passwd.c:828: error: (Each undeclared identifier is reported only once > passwd.c:828: error: for each function it appears in.) > passwd.c: In function chk_lanman: > passwd.c:839: error: des_key undeclared (first use in this function) > passwd.c:839: error: expected ; before key > passwd.c:840: error: des_context undeclared (first use in this function) > passwd.c:840: error: expected ; before schedule > passwd.c:841: error: des_data_block undeclared (first use in this function) > passwd.c:841: error: expected ; before StdText > passwd.c:842: error: expected ; before PasswordHash1 > passwd.c:859: error: key undeclared (first use in this function) > passwd.c:859: error: too many arguments to function lmPasswd_to_key > passwd.c:860: error: schedule undeclared (first use in this function) > passwd.c:861: error: StdText undeclared (first use in this function) > passwd.c:861: error: PasswordHash1 undeclared (first use in this function) > passwd.c:861: error: DES_ENCRYPT undeclared (first use in this function) > passwd.c:867: error: too many arguments to function lmPasswd_to_key > passwd.c:869: error: PasswordHash2 undeclared (first use in this function) > passwd.c: In function hash_lanman: > passwd.c:1135: error: des_key undeclared (first use in this function) > passwd.c:1135: error: expected ; before key > passwd.c:1136: error: des_context undeclared (first use in this function) > passwd.c:1136: error: expected ; before schedule > passwd.c:1137: error: des_data_block undeclared (first use in this function) > passwd.c:1137: error: expected ; before StdText > passwd.c:1138: error: expected ; before PasswordHash1 > passwd.c:1155: error: key undeclared (first use in this function) > passwd.c:1155: error: too many arguments to function lmPasswd_to_key > passwd.c:1156: error: schedule undeclared (first use in this function) > passwd.c:1157: error: StdText undeclared (first use in this function) > passwd.c:1157: error: PasswordHash1 undeclared (first use in this function) > passwd.c:1157: error: DES_ENCRYPT undeclared (first use in this function) > passwd.c:1159: error: too many arguments to function lmPasswd_to_key > passwd.c:1161: error: PasswordHash2 undeclared (first use in this function) > make[2]: *** [passwd.o] Error 1 > > I took a look in the passwd.c file, and because of neither HAVE_OPENSSL nor > HAVE_MOZNSS is defined, des_key isn't defined also. There is already a check in > the configure script, if tls is set when lmpasswd is set. The failure message > for it explains, that there has to be openssl installed in order to use lm > passwords. Perhaps this test has to be changed in a manner that it's checked, > what implementation is used for tls, and only activates lm passwords only, if > tls is either openssl or moznss. > > Please let me know if you need further information. > > Best regards, > Steffen Hau > -- -- 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

(ITS#6233) print_deref assertion if no deref attributes returned
by rmeggins＠redhat.com 28 Jul '09

28 Jul '09

Full_Name: Rich Megginson Version: 2.4.17+ (current HEAD) OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.113.59.19) I am testing the LDAP Dereference feature specified here - http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masara… I am getting an assertion in common.c at line 2077: 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); 2075: *ptr++ = '\n'; 2076: *ptr++ = '\0'; 2077: assert( ptr <= buf + len ); tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf); In my test, ptr is one greater than buf + len. It appears that len does not take into consideration the addition of the trailing \0 at line 2076. My test is looking for a dereference attribute which does not have any values, so that the attrVals in the control response is empty. If there are values to return in attrVals, the assertion is not triggered.

1 0

(ITS#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by steffen.hau＠rz.uni-mannheim.de 28 Jul '09

28 Jul '09

Full_Name: Steffen Hau Version: 2.4.17 OS: gentoo URL: Submission from: (NULL) (134.155.35.13) Gentoo prefers gnutls usage over openssl when compiling openldap. But if with-tls=gnutls and enable-lmpasswd set, neither HAVE_OPENSSL nor NAVE_MOZNSS is defined and passwd.c failes to compile with: passwd.c:813: error: expected declaration specifiers or ... before des_key passwd.c: In function lmPasswd_to_key: passwd.c:828: error: key undeclared (first use in this function) passwd.c:828: error: (Each undeclared identifier is reported only once passwd.c:828: error: for each function it appears in.) passwd.c: In function chk_lanman: passwd.c:839: error: des_key undeclared (first use in this function) passwd.c:839: error: expected ; before key passwd.c:840: error: des_context undeclared (first use in this function) passwd.c:840: error: expected ; before schedule passwd.c:841: error: des_data_block undeclared (first use in this function) passwd.c:841: error: expected ; before StdText passwd.c:842: error: expected ; before PasswordHash1 passwd.c:859: error: key undeclared (first use in this function) passwd.c:859: error: too many arguments to function lmPasswd_to_key passwd.c:860: error: schedule undeclared (first use in this function) passwd.c:861: error: StdText undeclared (first use in this function) passwd.c:861: error: PasswordHash1 undeclared (first use in this function) passwd.c:861: error: DES_ENCRYPT undeclared (first use in this function) passwd.c:867: error: too many arguments to function lmPasswd_to_key passwd.c:869: error: PasswordHash2 undeclared (first use in this function) passwd.c: In function hash_lanman: passwd.c:1135: error: des_key undeclared (first use in this function) passwd.c:1135: error: expected ; before key passwd.c:1136: error: des_context undeclared (first use in this function) passwd.c:1136: error: expected ; before schedule passwd.c:1137: error: des_data_block undeclared (first use in this function) passwd.c:1137: error: expected ; before StdText passwd.c:1138: error: expected ; before PasswordHash1 passwd.c:1155: error: key undeclared (first use in this function) passwd.c:1155: error: too many arguments to function lmPasswd_to_key passwd.c:1156: error: schedule undeclared (first use in this function) passwd.c:1157: error: StdText undeclared (first use in this function) passwd.c:1157: error: PasswordHash1 undeclared (first use in this function) passwd.c:1157: error: DES_ENCRYPT undeclared (first use in this function) passwd.c:1159: error: too many arguments to function lmPasswd_to_key passwd.c:1161: error: PasswordHash2 undeclared (first use in this function) make[2]: *** [passwd.o] Error 1 I took a look in the passwd.c file, and because of neither HAVE_OPENSSL nor HAVE_MOZNSS is defined, des_key isn't defined also. There is already a check in the configure script, if tls is set when lmpasswd is set. The failure message for it explains, that there has to be openssl installed in order to use lm passwords. Perhaps this test has to be changed in a manner that it's checked, what implementation is used for tls, and only activates lm passwords only, if tls is either openssl or moznss. Please let me know if you need further information. Best regards, Steffen Hau

1 0

(ITS#6231) The same problem: sasl realms don't work with digest-md5
by jackli7312＠yahoo.com.cn 27 Jul '09

27 Jul '09

Full_Name: jackli Version: 2.4.16 OS: fedora9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.41.165.157) I searched this problem from mail list, and there is no response for it. I'm really suffering this for a week. Any help will be greatly appreciated! Please help. Jack hi all, i've got a problem with the sasl authentication using digest-md5 and multiple realms with my openldapServer 2.3.19 (fc5, yum). i want to be able to authenticate against different subtrees of the dit by using different realms and i was reading as many documentation, howtos and so on as i was able to find at the net for at least the last 7 days. i don't get it running...! currently, for testing, i use two different realms: mydomain.net (o=home,dc=mydit,dc=lan) test.mydomain.net (o=test,dc=mydit,dc=lan) in the slapd.conf i added: # sasl-realm mydomain.net authz-regexp uid=(.*),cn=test.mydomain.net,cn=digest-md5,cn=auth uid=$1,ou=users,o=test,dc=ditroot authz-regexp uid=(.*),cn=mydomain.net,cn=digest-md5,cn=auth uid=$1,ou=users,o=home,dc=ditroot authz-regexp uid=(.*),cn=digest-md5,cn=auth uid=$1,ou=users,o=home,dc=ditroot as you can see, the sasl-realm parameter is commented. whether or not i comment or uncomment it, it does not work. (actualy it works, but only either for the default realm or through the last sasl-regexp if i set it, all authentication attemps are of the format: uid=XY,cn=mydomain.net,cn=digest-md5,cn=auth if i do not set it, all authentication is done using: uid=XY,cn=digest-md5,cn=auth i realy tried a lot, e.g.: (things like -h, ... are covered by the ldap.conf) - ldapwhoami -U XY -R test.mydomain.net - ldapwhoami -U XY(a)test.mydomain.net - ldapsearch -U XY -R test.mydomain.net - ldap... of course all of those test where performed with different -R, ... values. i realy do not know what to do anymore, i've got no more ideas... also what i do not understand is whether or not this is a problem with my cyrus-sasl installation, but i cannot imagine that. i guess i'm missing something but i don't know what. can someone help me with this, please? have a nice day... d.a.s.

1 0

Re: (ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by hyc＠symas.com 27 Jul '09

27 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.81.222) > > > Please let me know whether testrun/ is needed for examining this issue: Never mind, fixed in HEAD. > >>>>>> Starting test056-monitor for bdb... > running defines.sh > Starting slapd on TCP/IP port ... > Using ldapsearch to check that slapd is running... > Using ldapsearch to read connection monitor entries... > Filtering ldapsearch results... > Filtering expected data... > Comparing filter output... > Using ldapsearch to read database monitor entries... > Filtering ldapsearch results... > Comparing filter output... > comparison failed - database monitor output is not correct >>>>>> ./scripts/test056-monitor failed for bdb (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > -- -- 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#6230) test056-monitor: comparison failed - database monitor output is not correct
by hyc＠symas.com 27 Jul '09

27 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.81.222) > > > Please let me know whether testrun/ is needed for examining this issue: You could simply post the diff of the two files it was comparing. > >>>>>> Starting test056-monitor for bdb... > running defines.sh > Starting slapd on TCP/IP port ... > Using ldapsearch to check that slapd is running... > Using ldapsearch to read connection monitor entries... > Filtering ldapsearch results... > Filtering expected data... > Comparing filter output... > Using ldapsearch to read database monitor entries... > Filtering ldapsearch results... > Comparing filter output... > comparison failed - database monitor output is not correct >>>>>> ./scripts/test056-monitor failed for bdb (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > -- -- 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

(ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by michael＠stroeder.com 27 Jul '09

27 Jul '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.81.222) Please let me know whether testrun/ is needed for examining this issue: >>>>> Starting test056-monitor for bdb... running defines.sh Starting slapd on TCP/IP port ... Using ldapsearch to check that slapd is running... Using ldapsearch to read connection monitor entries... Filtering ldapsearch results... Filtering expected data... Comparing filter output... Using ldapsearch to read database monitor entries... Filtering ldapsearch results... Comparing filter output... comparison failed - database monitor output is not correct >>>>> ./scripts/test056-monitor failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2009