openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable
by Kurt＠OpenLDAP.org 23 Oct '10

23 Oct '10

On Oct 23, 2010, at 3:14 AM, hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Str=F6der >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.41.128) >>=20 >>=20 >> After a cvs up the file tests/scripts/test060-mt-hot is not = executable. >>=20 >> michael@local:/usr/src/michael/openldap/HEAD/openldap/tests> ./run = test060 >> run: test060 not found (or not executable) >>=20 >>=20 > Sorry, looks like I should've checked this on initial commit. Will = have to let=20 > Kurt fix it. >=20 Fixed. -- Kurt > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20

1 0

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable
by hyc＠symas.com 23 Oct '10

23 Oct '10

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.41.128) > > > After a cvs up the file tests/scripts/test060-mt-hot is not executable. > > michael@local:/usr/src/michael/openldap/HEAD/openldap/tests> ./run test060 > run: test060 not found (or not executable) > > Sorry, looks like I should've checked this on initial commit. Will have to let Kurt fix it. -- -- 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#6682) tests/scripts/test060-mt-hot not executable
by michael＠stroeder.com 23 Oct '10

23 Oct '10

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.41.128) After a cvs up the file tests/scripts/test060-mt-hot is not executable. michael@local:/usr/src/michael/openldap/HEAD/openldap/tests> ./run test060 run: test060 not found (or not executable)

1 0

(ITS#6681) Incorrect fix documented for file permissions error
by todd_taft＠unc.edu 23 Oct '10

23 Oct '10

Full_Name: Todd Taft Version: 2.4.21 OS: Ubuntu 10.04 URL: Submission from: (NULL) (152.2.132.25) The fix in section C.2.8 in the admin guide ( http://www.openldap.org/doc/admin24/appendix-common-errors.html ) is incorrect. It should say chown instead of chmod.

1 0

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

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