October 2010 - openldap-bugs

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable

by michael＠stroeder.com

Works for me now. Ciao, Michael.

12 years, 11 months

1
0
0 / 0

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable

by Kurt＠OpenLDAP.org

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

12 years, 11 months

1
0
0 / 0

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable

by Kurt＠OpenLDAP.org

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

12 years, 11 months

1
0
0 / 0

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable

by hyc＠symas.com

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/

12 years, 11 months

1
0
0 / 0

(ITS#6682) tests/scripts/test060-mt-hot not executable

by michael＠stroeder.com

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)

12 years, 11 months

1
0
0 / 0

(ITS#6681) Incorrect fix documented for file permissions error

by todd_taft＠unc.edu

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.

12 years, 11 months

1
0
0 / 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support

by hyc＠symas.com

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/a... > > 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/

12 years, 11 months

1
0
0 / 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support

by hyc＠symas.com

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/a... 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/

12 years, 11 months

1
0
0 / 0

(ITS#6680) slapd why sasl error message?

by pablo.web＠tiscali.it

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

12 years, 11 months

1
0
0 / 0

Re: (ITS#6679) syncrepl does not handle modifyTimestamp

by jonathan＠phillipoux.net

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_m... > 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 --------------------------------------------------------------

12 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2010