- openldap-bugs - openldap.org

(ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by sebastien.bahloul＠gmail.com 27 Oct '10

27 Oct '10

Full_Name: Sebastien Bahloul Version: HEAD OS: Linux RHEL 5 URL: Submission from: (NULL) (109.197.176.10) Hi, I think there is a bug / limitation inside VLV implementation : it can not handle multiple search operation on a single connection. The first operation succeeds and next operations fail with the following message : LDAP: error code 51 - Other sort requests already in progress My first guess was to remove / comment the following condition in sssvlv.c:757 : vc->vc_context != so->so_vcontext But I think this issue is more global. This implementation seems to be able to only handle a single VLV context per connection. If I am right, this is related with the indexing method of sort_conns structure which seems to be based only on the connection id. I suggest to implement a double indexing array by connection id / VLV context id. Regards,

1 0

Re: (ITS#6619) CSN too old
by heinz.hoelzl＠gvcc.net 27 Oct '10

27 Oct '10

I testet it also whithout a back-ldap The problem exists also if the provider is a "normal" slapd with "database hdb"

1 0

(ITS#6685) VLV implementation and compatibility
by sebastien.bahloul＠gmail.com 25 Oct '10

25 Oct '10

Full_Name: Sebastien Bahloul Version: HEAD OS: Linux RHEL 5 URL: ftp://ftp.openldap.org/incoming/sbahloul-101026.patch Submission from: (NULL) (2a01:e35:2ebe:f470:222:fbff:fe34:f796) Hi, OpenLDAP VLV implementation seems not to be fully compliant with latest draft. Use case has been identify through JNDI - JDK 1.5, (whereas it seems to be functional in ldapsearch) : javax.naming.NamingException [Root exception is com.sun.jndi.ldap.Ber$DecodeException: Encountered ASN.1 tag 2 (expected tag 10)] After doing some network captures between different directories implementation, it seems that there is a BER encoding error on the VLV response error code : Global VLV control response ASN1 dump (through openssl asn1parse) : 0:d=0 hl=2 l= 50 cons: SEQUENCE 2:d=1 hl=2 l= 24 prim: OCTET STRING :2.16.840.1.113730.3.4.10 28:d=1 hl=2 l= 22 prim: OCTET STRING 0000 - 30 14 02 01 00 02 02 00-aa 02 01 00 04 08 10 0a 0............... 0010 - 82 15 .. 0016 - <SPACES/NULS> Included octet string VLV control response ASN1 dump : 0:d=0 hl=2 l= 20 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 2 prim: INTEGER :AA 9:d=1 hl=2 l= 1 prim: INTEGER :00 12:d=1 hl=2 l= 8 prim: OCTET STRING 0000 - 10 0a 82 15 .... 0008 - <SPACES/NULS> According to latest VLV draft (seems to be version 4) in section 5.2, return type for error code (last 00 in this dump) must be an enumerated type (tag type 10). In OpenLDAP response, error code is encoded as an integer (tag type 2). I suggest to fix this by changing ber_printf(..."{iii ... to ber_printf(..."{iie ... in sssvlv.c:198. Regards,

1 0

Re: (ITS#6684) Patch for autogroup overlay
by hyc＠symas.com 25 Oct '10

25 Oct '10

norbert(a)pueschel.net wrote: > Full_Name: Norbert Pueschel > Version: HEAD > OS: Solaris > URL: http://www.pueschel.net/openldap/norbert-pueschel-autogroup-25102010.tar > Submission from: (NULL) (80.152.154.98) > > > When starting to use the autogroup-overlay from the contrib directory, I > stumbled over some issues: > > 1) Using non-DN-valued URIs for autogroup does not work correctly, even > with the latest version from HEAD. Especially changing group member is > not tracked. > > 2) Using the memberOf-overlay for constructing autogroups does not work > > 3) autogroup crashes slaptools (e.g. slaptest) when used together with > the ppolicy-overlay. > > 4) The Makefile install the overlay into the wrong directory (lib, > should be libexec) > > I have invested some time and found fixes for all these problems; see > the URL for the patch I uploaded. > > Please read the contributing Guidelines http://www.openldap.org/devel/contributing.html and provide a suitable IPR notice. -- -- 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#6684) Patch for autogroup overlay
by norbert＠pueschel.net 25 Oct '10

25 Oct '10

Full_Name: Norbert Pueschel Version: HEAD OS: Solaris URL: http://www.pueschel.net/openldap/norbert-pueschel-autogroup-25102010.tar Submission from: (NULL) (80.152.154.98) When starting to use the autogroup-overlay from the contrib directory, I stumbled over some issues: 1) Using non-DN-valued URIs for autogroup does not work correctly, even with the latest version from HEAD. Especially changing group member is not tracked. 2) Using the memberOf-overlay for constructing autogroups does not work 3) autogroup crashes slaptools (e.g. slaptest) when used together with the ppolicy-overlay. 4) The Makefile install the overlay into the wrong directory (lib, should be libexec) I have invested some time and found fixes for all these problems; see the URL for the patch I uploaded.

1 0

(ITS#6683) DDS fails with expired branches
by petteri.stenius＠ubisecure.com 25 Oct '10

25 Oct '10

Full_Name: Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.197.205.34) Hello, I have a directory with branches of dynamicObject entries. It looks like if the entryExpireTimestamp value is the same on objects within a branch then DDS search for expired objects will only find the top-most object. This results in remove failing with message DDS dn="cn=top,cn=root,dc=test" is non-leaf; deferring. To reproduce OpenLDAP 2.4.23, Berkeley DB 4.6.21 Use slapadd to prepare directory with following dn: cn=Root,dc=test objectClass: top objectClass: applicationProcess cn: Root dn: cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: top dn: cn=leaf1,cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf1 dn: cn=leaf2,cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf2 dn: cn=leaf3,cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf3 Relevant slapd.conf entries database bdb suffix "cn=Root,dc=test" rootdn "cn=Root,dc=test" rootpw "password" overlay dds dds-default-ttl 3600 dds-min-ttl 60 dds-interval 60 dds-state true index entryExpireTimestamp eq,pres access to dn.subtree="cn=Root,dc=test" by users write by * read Running "slapd -d 1 -d 256" produces following put_filter: "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20101025082446Z))" put_filter: AND put_filter_list "(objectClass=dynamicObject)(entryExpireTimestamp<=20101025082446Z)" put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" put_filter: "(entryExpireTimestamp<=20101025082446Z)" put_filter: simple put_simple_filter: "entryExpireTimestamp<=20101025082446Z" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => bdb_search bdb_dn2entry("cn=root,dc=test") => bdb_dn2id("cn=root,dc=test") <= bdb_dn2id: got id=0x1 entry_decode: "cn=Root,dc=test" <= entry_decode(cn=Root,dc=test) search_candidates: base="cn=root,dc=test" (0x00000001) scope=2 => bdb_dn2idl("cn=root,dc=test") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 4 candidates <= bdb_equality_candidates: id=4, first=2, last=5 => bdb_inequality_candidates (entryExpireTimestamp) => key_read <= bdb_index_read 1 candidates => key_read <= bdb_index_read: failed (-30989) <= bdb_inequality_candidates: id=1, first=2, last=2 bdb_search_candidates: id=1 first=2 last=2 entry_decode: "cn=top,cn=Root,dc=test" <= entry_decode(cn=top,cn=Root,dc=test) => bdb_dn2id("cn=top,cn=root,dc=test") <= bdb_dn2id: got id=0x2 send_ldap_result: conn=-1 op=0 p=0 bdb_dn2entry("cn=top,cn=root,dc=test") => bdb_dn2id_children("cn=top,cn=root,dc=test") <= bdb_dn2id_children("cn=top,cn=root,dc=test"): (0) send_ldap_result: conn=-1 op=0 p=0 DDS dn="cn=top,cn=root,dc=test" is non-leaf; deferring. DDS expired=0 ldapsearch "(entryExpireTimestamp=*)" produces dn: cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z dn: cn=leaf1,cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z dn: cn=leaf2,cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z dn: cn=leaf3,cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z where ldapsearch "(entryExpireTimestamp<=20101024113626Z)" only finds dn: cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z If I change all timestamps to distinct values then expiration of complete branches works as expected. Thanks, Petteri

1 0

Re: (ITS#6682) tests/scripts/test060-mt-hot not executable
by michael＠stroeder.com 24 Oct '10

24 Oct '10

Works for me now. Ciao, Michael.

1 0

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

23 Oct '10

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

1 0

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 22 Oct '10

22 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

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs