openldap-bugs October 2010

openldap-bugs@openldap.org

38 participants
86 discussions

(ITS#6679) syncrepl does not handle modifyTimestamp
by pcernko+openldap＠mpi-sws.org 20 Oct '10

20 Oct '10

Full_Name: Patrick Cernko Version: 2.4.23 OS: Debian Lenny URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_does_not_transfer_or_update_mod… Submission from: (NULL) (139.19.3.67) Hi OpenLDAP-Programmers, we discovered a possible bug in the syncrepl code. When objects get modified on the master server, all changed get propagated to the slaves. However, the for hidden attributes creatorsName, createTimestamp, modifiersName, modifyTimestamp seem to be not handled in a reasonable way: Obviously, the creat* attributes should only be written once (on creation). The modif* attributes are set to the same values as their creat* counterparts on creating. After replication, all these values can be found on the slave as well. When an object is modified now (for the first time!), the master correctly updated the modif* attributes. The slave replicates the modification correctly but neither does update the modif* attributes nor replicates their contents from the server. Especially the modifyTimestamp attribute does still contain the old value (equal to createTimestamp). This is wrong as the object WAS modified later. More interesting, if you do another modification, the master will handle it the same way as before, but now, the slave will completely REMOVE the four hidden attributes, as you can verify in the slapcat of the slave's database. To demonstrate and reproduce this behaviour, I have combined a set of files in the linked tarball: Extract to an empty folder, unpack openldap-2.4.23 into it and configure-make-make-install it (a suggested configuration can be found in the boundled configure.sh). The you can start the master and server with the corresponding sh-Scripts. You can use the following commands to search or slapcat the servers: install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL modifyTimestamp install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL modifyTimestamp install/sbin/slapcat -f master.conf install/sbin/slapcat -f slave.conf The mod.py script can be used to trigger a change: python mod.py mod-child Now check the modifyTimestamp on the slave, it is still the old one: install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL modifyTimestamp install/sbin/slapcat -f slave.conf After the second modification, the attributes are gone on the slave: python mod.py unmod-child install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL modifyTimestamp install/sbin/slapcat -f slave.conf I would really appreciate a reasonable behaviour for this in the next releases. If you have reasons not to REPLICATE but UPDATE the modif* attributes (with the replication timestamp instead of the master's one), that's ok, too. Thanks.

1 0

(ITS#6678) slapd.exe does not respond anymore
by Frank.Offermanns＠caseris.de 20 Oct '10

20 Oct '10

Full_Name: Frank Offermanns Version: 2.4.23 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.243) We are using OpenLDAP 2.4.23 on windows. We are doing a lot of LDAP work every morning at 5 AM. About every 3rd day the slapd.exe hang's up while doing this work. The LDAP client then also hangs. The search never comes back. It is no longer possible to bind to the server. Slapd.exe can't be stopped regulary (must be terminated). After restart of slapd.exe everything works fine. It does not matter if we specify a (search/open) timeout at client side - it always hangs. The log attached is without timeout. It also does not matter if replication is configured or not (currently replication is activated). I have uploaded a part of the slapd.log (with loglevel 264) and my configuration file as Frank-Offermanns-101020.log and Frank-Offermanns-101020.conf. To better analyse the log at 5 AM I added timestamps to the logging. At the attached log you can watch the way of "conn=3005" which results in a search, which never comes back. Would it make sense to adjust the loglevel. If so what loglevel would be helpfull?

1 0

(ITS#6677) unregister_supported_control not under ifdef control
by doug.leavitt＠oracle.com 16 Oct '10

16 Oct '10

Full_Name: Douglas Leavitt Version: HEAD OS: OpenSolaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) The definition of unregister_supported_control is ifdef'd SLAP_CONFIG_DELETE but one reference in sssvlv.c is not. Compiling HEAD in a non Devel configuration will cause link failures. Suggested fix: --- openldap/servers/slapd/overlays/sssvlv.c.bad Wed Oct 13 12:08:18 2010 +++ openldap/servers/slapd/overlays/sssvlv.c Thu Oct 14 23:32:31 2010 @@ -1183,12 +1183,12 @@ if ( rc != LDAP_SUCCESS ) { Debug( LDAP_DEBUG_ANY, "Failed to register VLV Request control '%s' (%d)\n", LDAP_CONTROL_VLVREQUEST, rc, 0 ); #ifdef SLAP_CONFIG_DELETE overlay_unregister_control( be, LDAP_CONTROL_SORTREQUEST ); -#endif /* SLAP_CONFIG_DELETE */ unregister_supported_control( LDAP_CONTROL_SORTREQUEST ); +#endif /* SLAP_CONFIG_DELETE */ return rc; } } si = (sssvlv_info *)ch_malloc(sizeof(sssvlv_info));

1 0

Re: (ITS#6676) Some slap-commands remove nssov overlay socket
by hyc＠symas.com 16 Oct '10

16 Oct '10

sergei(a)bslos.com wrote: > Full_Name: Sergei Butakov > Version: 2.4.23 > OS: Linux > URL: > Submission from: (NULL) (94.190.117.137) > > > I'm using nssov overlay (and nss-pam-ldapd-0.7.10). > > > Some slap-commands remove nssov overlay socket "/var/run/nslcd/socket" (it shows > "strace slapcat"). > > For example, next commands remove socket: > slapcat -n 2, slapschema -n 2, slapacl<anything> > > But these ones do not remove: > slapcat -n 1, slapschema -n 1, slapdn<anything> Thanks for the report, fixed in CVS HEAD. > > > To avoid this, I commented out in contrib/slapd-modules/nssov/nssov.c file > from 890 to 894 lines (in nssov_db_close() function). Now the socket exists > even if slapd is stopped. But it seems that it does not interfere with > anything. > > > I have in slapd.conf two database: > ... > ... > database monitor > rootdn "cn=Manager" > ... > database hdb > suffix "" > rootdn "cn=Manager" > > overlay nssov > nssov-map aliases rfc822MailMember x-bsl-mailMember > nssov-map group uniqueMember member > nssov-ssd passwd > ldap:///??sub?(&(objectClass=posixAccount)(objectClass=sambaSamAccount)) > > overlay smbk5pwd > overlay memberof > ... > overlay refint > ... > ... > > > -- -- 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#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 16 Oct '10

16 Oct '10

Arthur de Jong wrote: > On Thu, 2010-10-14 at 14:42 -0700, Howard Chu wrote: >> What is the GnuTLS version number? Seems like you should be submitting >> this to their tracker anyway, as the original reporter. > > I'm using GnuTLS 2.8.6. I've just also tried with GnuTLS 2.10.2 which > shows the same behaviour. > > I've reported it to > https://savannah.gnu.org/support/index.php?107495 > feel free to add any more pointers that may be useful. > > Anyway, thanks for your help. > Based on the discussion there, I've committed the workaround I already mentioned in my previous reply. -- -- 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#6676) Some slap-commands remove nssov overlay socket
by sergei＠bslos.com 15 Oct '10

15 Oct '10

Full_Name: Sergei Butakov Version: 2.4.23 OS: Linux URL: Submission from: (NULL) (94.190.117.137) I'm using nssov overlay (and nss-pam-ldapd-0.7.10). Some slap-commands remove nssov overlay socket "/var/run/nslcd/socket" (it shows "strace slapcat"). For example, next commands remove socket: slapcat -n 2, slapschema -n 2, slapacl <anything> But these ones do not remove: slapcat -n 1, slapschema -n 1, slapdn <anything> To avoid this, I commented out in contrib/slapd-modules/nssov/nssov.c file from 890 to 894 lines (in nssov_db_close() function). Now the socket exists even if slapd is stopped. But it seems that it does not interfere with anything. I have in slapd.conf two database: ... ... database monitor rootdn "cn=Manager" ... database hdb suffix "" rootdn "cn=Manager" overlay nssov nssov-map aliases rfc822MailMember x-bsl-mailMember nssov-map group uniqueMember member nssov-ssd passwd ldap:///??sub?(&(objectClass=posixAccount)(objectClass=sambaSamAccount)) overlay smbk5pwd overlay memberof ... overlay refint ... ...

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 15 Oct '10

15 Oct '10

--=-ex4J6k12RcsGQxVIbjnQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2010-10-14 at 14:42 -0700, Howard Chu wrote: > What is the GnuTLS version number? Seems like you should be submitting > this to their tracker anyway, as the original reporter. I'm using GnuTLS 2.8.6. I've just also tried with GnuTLS 2.10.2 which shows the same behaviour. I've reported it to https://savannah.gnu.org/support/index.php?107495 feel free to add any more pointers that may be useful. Anyway, thanks for your help. --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-ex4J6k12RcsGQxVIbjnQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJMuAfmAAoJECqLdGgQ4K/Bws4P/3AP3NwmRZeO8feXY/F9wFwI NTr7zxjHjbdVOoOjS81YPIDGXrefDx5kV5ufpVhDI7ojZSyhJc7rKRu7mpEiWzZH pYIm9h+pFvRBSp4uGYGmlWQlkZHYNZFCYTNJo2+srl/evqyd4vKlvuMMn5QHlb8g DCJEf+3Zo2+kd42V0WdVcpOuTcTjvGzGEd5SLRHjHvcjSX/YTW4JijgiBILqN745 ei8jyE1qpm/N6W2Zevb+XRhnQ6g5X95UmFNeWie8PNWGgpMu0IhRh79cPX25wOIK 4fSVDTW6rNnKR4E9rtJkhl/VwYNSQgwd9g0kyhinCn3sswa1UGxs6abBcF8sILIe tEGiUJ7ZtJU4bA9uiILgGu94AV/zwkfqGC9y2q14jJ3N/28IcJIScWGqeYHaKZ1U uB+2Y33fmEbXaAUBjPng4dNmnmrtNU1/MAyf24SC+wx8HKrOliQl1Y9z5GeN/rgM bmSgFkdIJmHGvgmfW1+qUjynII67IIW5a42Amg/+o8LzKDJLZjs+WiJeZ7q7Pjd9 K6SgKiXTwu1mFgSt1kKz0rGUIYe4dZhkmmsKe8q7vCy8ME8MzibeQGwGK9cJLRqv GC1RIXKGVqBhjgwhJVwB+8EFZImWg/pfREofkyuphRwfT2i+omrYuHdpESoSJiCD i+QftiX5vMjKx+b965Jd =apB7 -----END PGP SIGNATURE----- --=-ex4J6k12RcsGQxVIbjnQ--

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 14 Oct '10

14 Oct '10

Arthur de Jong wrote: > On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote: >> It seems you can workaround this by changing tls_g.c's invocation of >> gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, that >> strikes me as fundamentally wrong, since libldap is clearly closing both >> directions when it gets here. I think the bug is in gnutls_bye(), it shouldn't >> be waiting indefinitely when it tries to read the peer's Close alert. I'm not >> sure it should even be trying to read that at all; some peers may never send it. > > I can't comment on the GnuTLS API because I haven't used it before. Can > you file a bugreport with GnuTLS? Do you need any more input from my > end? What is the GnuTLS version number? Seems like you should be submitting this to their tracker anyway, as the original reporter. https://savannah.gnu.org/support/?group=gnutls >> Note that because you're breaking the connection without warning, TCP doesn't >> know that the connection is gone, so there will be no error detected when >> gnutls attempts to send its own Close alert. In this case, it will probably >> block for 2*MSL before getting any further. > > In my tests I haven't waited that long (I think). Do you know if there > are any problems with using setsockopt(SO_RCVTIMEO) and > setsockopt(SO_SNDTIMEO) on the socket? > I have no idea whether GnuTLS handles asynch I/O properly or not. If you're only setting these options immediately before closing, I don't see why it should cause any problems. But GnuTLS has enough flaws in general that I wouldn't claim it ever does anything right or as expected. -- -- 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#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 14 Oct '10

14 Oct '10

Version 2... Part 3 of 3 of this patch with the request changes to options.c is now available for review. The full details are located here: http://cr.opensolaris.org/~djl/openldap-patch3/ The revised patch has been updated to include all changes as on 10-14-10AM including the commit of: Modified Files: cyrus.c 1.159 -> 1.160 The only file modified between the first and second version of this patch was options.c The web link above includes both the original patch (as version 1) and the revised patch (version 2) with full diff -Us, tarballs and such for both versions. Retesting has been completed on both Solaris x86 and Solaris SPARC. Both platforms have been re-tested under 32-bit and 64-bit compiles. All regression testing passed successfully. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms. Thank you for your consideration, Doug.

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 14 Oct '10

14 Oct '10

--=-6hDPPEPvd2QOD+/Er+Q8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote: > It seems you can workaround this by changing tls_g.c's invocation of=20 > gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, = that=20 > strikes me as fundamentally wrong, since libldap is clearly closing both= =20 > directions when it gets here. I think the bug is in gnutls_bye(), it shou= ldn't=20 > be waiting indefinitely when it tries to read the peer's Close alert. I'm= not=20 > sure it should even be trying to read that at all; some peers may never s= end it. I can't comment on the GnuTLS API because I haven't used it before. Can you file a bugreport with GnuTLS? Do you need any more input from my end? > Note that because you're breaking the connection without warning, TCP doe= sn't=20 > know that the connection is gone, so there will be no error detected when= =20 > gnutls attempts to send its own Close alert. In this case, it will probab= ly=20 > block for 2*MSL before getting any further. In my tests I haven't waited that long (I think). Do you know if there are any problems with using setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on the socket? --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-6hDPPEPvd2QOD+/Er+Q8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJMt01mAAoJECqLdGgQ4K/B5ogP/ihMljH3hvC7aKd6W4Mt526F J/W6Gpx8w7UUI2uymq23epRa1s/2aLWnPDpdP9uGbswrdBrOsRrUARWHPRy/I61L 8JhCiFcEXqyMJxrm7sW4uaVTHBS1AZPklCdfQ0+s4JdVKccLjOkUGJFh4sQL5TtA 3syopgjuQ2inqc9+wA3ZuGL3HgiOuLjXQauHQ0YbWdr+QYZjDZcero5RU6HU+jIv uh+SyQaTiTkzDc8MqGc/ImPZ5R55YORiKUF90Wr+3lGPGCloj8snqfUbMpjNTBkG jUPKBrl+bKgmKPtnpJzLzeCAZsH/rMdyhL0Apr1AZb5Ay8uHqxE3bHE/bTL7/mxA J/RvZlIR/BGed1dWWlQ+j2YE8zsCfvUNxH1GbbmWqk6pO+4BbZP/7XHs6rMW7XkL bT+LwW6J70ZrUFR7XEjkn/a++S7dm9zRoIVDvVgw7HduQSVU+nVQRIwh/CxyGhoG J8OefK5OEYuAqZjFJk8U1OpslstpGDvMjr7nbnY2TRkAg1QshydvhFaq+cp56Uey RT97jWFYTYuIUTrWh8SOog/NxE0WaBJuUqx/Lz/mBX7BkJj+zSDT9SD6IntV73eJ GBBr5wgyEzYyu7pg9uo3Ux16XFp+wwtjMHd8H9/EEEsBjOkuPyGVCz/9CynUgegr A/rMhnTnXTAt7zM/ydh2 =uUuU -----END PGP SIGNATURE----- --=-6hDPPEPvd2QOD+/Er+Q8--

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2010