openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by hyc＠symas.com 22 Oct '10

22 Oct '10

Howard Chu wrote: > doug.leavitt(a)oracle.com wrote: >> 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 > > Looking at the patch to abandon.c, first chunk > > http://cr.opensolaris.org/~djl/openldap-patch3/webrev/libraries/libldap/aba… > > it looks like you'll deadlock on the ld_req_mutex, based on the preceding > comment. I.e., you should not be using LDAP_NEXT_MSGID() here. Never mind, I forgot that LDAP_NEXT_MSGID uses its own msgid mutex now. -- -- 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 hyc＠symas.com 22 Oct '10

22 Oct '10

doug.leavitt(a)oracle.com wrote: > 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 Looking at the patch to abandon.c, first chunk http://cr.opensolaris.org/~djl/openldap-patch3/webrev/libraries/libldap/aba… it looks like you'll deadlock on the ld_req_mutex, based on the preceding comment. I.e., you should not be using LDAP_NEXT_MSGID() here. -- -- 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#6680) slapd why sasl error message?
by pablo.web＠tiscali.it 20 Oct '10

20 Oct '10

Full_Name: Paolo Version: 2.4.17 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.40.191.183) I installed ldap (slapd 2.4.17) on a debian machine (ARM processor). The LDAP server allows you to centralize authentication of users and unix samba (samba is set with the PDC for windows machines, all with windows 7 OS). The communication is protected by TLS / SSL. Dont use SALS mechanism and, at the moment, I dont want to use it. Everything works perfectly but I dont understand why in the log file (syslog) I find the following error message: Oct 18 14:52:10 qnapserver slapd[11916]: daemon: read active on 26 Oct 18 14:52:10 qnapserver slapd[11916]: connection_get(26) Oct 18 14:52:10 qnapserver slapd[11916]: ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=12 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: activity on 1 descriptor Oct 18 14:52:10 qnapserver slapd[11916]: daemon: activity on: Oct 18 14:52:10 qnapserver slapd[11916]: Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=12 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: activity on 1 descriptor Oct 18 14:52:10 qnapserver slapd[11916]: daemon: activity on: Oct 18 14:52:10 qnapserver slapd[11916]: 26r Oct 18 14:52:10 qnapserver slapd[11916]: Oct 18 14:52:10 qnapserver slapd[11916]: daemon: read active on 26 Oct 18 14:52:10 qnapserver slapd[11916]: connection_get(26) Oct 18 14:52:10 qnapserver slapd[11916]: ==> sasl_bind: dn="" mech=<continuing> datalen=265 Oct 18 14:52:10 qnapserver slapd[11916]: SASL [conn=542] Failure: realm changed: authentication aborted Oct 18 14:52:10 qnapserver slapd[11916]: send_ldap_result: err=49 matched="" text="SASL(-13): authentication failure: realm changed: authentication aborted" Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: epoll: listen=12 active_threads=0 tvp=zero Oct 18 14:52:10 qnapserver slapd[11916]: daemon: activity on 2 descriptors Oct 18 14:52:10 qnapserver slapd[11916]: daemon: activity on: Oct 18 14:52:10 qnapserver slapd[11916]: 26r This massage is displayed only after logged in from a Windows 7 client machine and is repeated approximately every 15 minutes. Please Help me, how can I fix this? Thanks Paolo

1 0

Re: (ITS#6679) syncrepl does not handle modifyTimestamp
by jonathan＠phillipoux.net 20 Oct '10

20 Oct '10

Le 20/10/2010 14:43, pcernko+openldap(a)mpi-sws.org a écrit : > 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. The syncrepl configuration in your slave.conf file contains "attrs=*". This configuration explicitly requests synchronizing user attributes only. creatorsName, createTimestamp, modifiersName, modifyTimestamp are operational attributes and would be synchronized with "attrs=+". To synchronize all attributes, you should set "attrs=*,+". This is the default value, as indicated in the man page slapd.conf(5). > 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. The expected result is that operational attributes are not replicated to the slave's database. It is however surprising that this behaviour varies between replicating an ADD operation and a MODIFY operation... > 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. -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

(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

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