- openldap-bugs - openldap.org

(ITS#5770) Unaligned BerElements
by h.b.furuseth＠usit.uio.no 24 Oct '08

24 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This code fails to align the BerElement: char berbuf[LBER_ELEMENT_SIZEOF]; BerElement *ber = (BerElement *)berbuf; in clients/tools/common.c, servers/slapd/overlays/ppolicy.c. Fixing.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by h.b.furuseth＠usit.uio.no 24 Oct '08

24 Oct '08

Howard Chu writes: >> BTW, possibly "deref(erence)" is a confusing name for the control, >> since it is apparently not related to aliases. > > Oh please. Nor is it related to referrals or search references, and yet > these are all references, and "dereference" applies to them equally. Actually the docs do use different names for that - "follow"/"chase" referrals, or "chain" on the server side, vs. "deref"erence aliases. So if this is a new operation, I figured it wouldn't hurt to look for another word for whatever it is doing. But sure, it's no big thing. And in that regard it can already be a bit confusing that it's aliases and not referrals & search references which are "deref"erenced. -- Hallvard

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 24 Oct '08

24 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The current specification is formalized in a comment in >> overlays/deref.c; I intend to improve it and post it at >> <http://www.openldap.org/faq/data/cache/1469.html>. > > You've specified the syntax, but not the semantics. I don't see > any mention there of what this control does, though I suppose the > examples help if one knows what a GUID and a SID are. I will, in a more detailed document. > BTW, possibly "deref(erence)" is a confusing name for the control, > since it is apparently not related to aliases. "Dereference" means take DN-valued attributes, lookup the requested attributes from their entry and present the whole thing (name + attrs) as the control value. So ldapsearch -E deref=member:cn,sn will return a control value consisting in sequences of member values contained in the search, plus the corresponding values of cn and sn. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by hyc＠symas.com 24 Oct '08

24 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The current specification is formalized in a comment in >> overlays/deref.c; I intend to improve it and post it at >> <http://www.openldap.org/faq/data/cache/1469.html>. > > You've specified the syntax, but not the semantics. I don't see > any mention there of what this control does, though I suppose the > examples help if one knows what a GUID and a SID are. It doesn't matter what a GUID or SID, aside from being attributes of an entry that was referenced by a search response entry. > BTW, possibly "deref(erence)" is a confusing name for the control, > since it is apparently not related to aliases. Oh please. Nor is it related to referrals or search references, and yet these are all references, and "dereference" applies to them equally. -- -- 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#5768) [enhancement] add support for Dereference Control
by h.b.furuseth＠usit.uio.no 24 Oct '08

24 Oct '08

ando(a)sys-net.it writes: > The current specification is formalized in a comment in > overlays/deref.c; I intend to improve it and post it at > <http://www.openldap.org/faq/data/cache/1469.html>. You've specified the syntax, but not the semantics. I don't see any mention there of what this control does, though I suppose the examples help if one knows what a GUID and a SID are. BTW, possibly "deref(erence)" is a confusing name for the control, since it is apparently not related to aliases. -- Hallvard

1 0

ITS#5768 - design considerations
by ando＠sys-net.it 24 Oct '08

24 Oct '08

ando(a)OpenLDAP.org wrote: > Log Message: > forgot access control... Probably the current implementation is far from optimal, since it makes use of over_entry_get_rw() and thus: - requires to apply ACLs within the overlay - prevents other overlays from interoperating - prevents the overlay from being instantiated as global Probably, an internal search with scope "base" would be better. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5769) Behaviour of ldap_sort_entries on a multivalued attribute
by ando＠sys-net.it 23 Oct '08

23 Oct '08

emmanuel.duru(a)atosorigin.com wrote: > Currently, ldap_sort_entries when used with a multivalued attribute assumes that > the attribute values are in the same order for all the entries. It would be > better if this was not the case. > For example, I would like to use ldap_sort_entries to sort entries according to > objectclass attribute, so as to group entries by kind of objects. > Let be 3 entries: > ==>cn=n1, objectclass: person, organizationalperson > ==>ou=ou1, objectclass: organizationalunit > ==>cn=n2, objectclass: organizationalperson, person > result of ldap_sort_entries on objectclass: n2, ou1, n1, whereas I expected n1, > n2, ou1. ldap_sort_entries() is deprecated. As a consequence, I would not expect any activity on it. It is the client's duty to sort the way it likes. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5769) Behaviour of ldap_sort_entries on a multivalued attribute
by emmanuel.duru＠atosorigin.com 23 Oct '08

23 Oct '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) Currently, ldap_sort_entries when used with a multivalued attribute assumes that the attribute values are in the same order for all the entries. It would be better if this was not the case. For example, I would like to use ldap_sort_entries to sort entries according to objectclass attribute, so as to group entries by kind of objects. Let be 3 entries: ==>cn=n1, objectclass: person, organizationalperson ==>ou=ou1, objectclass: organizationalunit ==>cn=n2, objectclass: organizationalperson, person result of ldap_sort_entries on objectclass: n2, ou1, n1, whereas I expected n1, n2, ou1.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 22 Oct '08

22 Oct '08

A tentative implementation is in HEAD, please test. You need to: - configure as --enable-deref - enable the "deref" overlay in slapd, with "overlay deref" (doesn't work as global overlay yet, sorry). - run searches like $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID' you'll see results like # Alumni Assoc Staff, Groups, example.com dn: cn=Alumni Assoc Staff,ou=Groups,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIIDgjBdBAZtZW1iZXIEHGNuPU1hbmFnZXIsZ GM9ZXhhbXBsZSxkYz1jb22gNTAzBAllbnRyeVVVSUQxJgQkMjlkNTNiZjQtMzRhYi0xMDJkLThhNz MtYWI0MTM2OTEyOTExMIGFBAZtZW1iZXIERGNuPURvcm90aHkgU3RldmVucyxvdT1BbHVtbmkgQXN zb2NpYXRpb24sb3U9UGVvcGxlLGRjPWV4YW1wbGUsZGM9Y29toDUwMwQJZW50cnlVVUlEMSYEJDI5 ZDNhNzQ0LTM0YWItMTAyZC04YTZjLWFiNDEzNjkxMjkxMTCBhQQGbWVtYmVyBERjbj1KYW1lcyBBI EpvbmVzIDEsb3U9QWx1bW5pIEFzc29jaWF0aW9uLG91PVBlb3BsZSxkYz1leGFtcGxlLGRjPWNvba A1MDMECWVudHJ5VVVJRDEmBCQyOWQ0MTM5Ni0zNGFiLTEwMmQtOGE2ZS1hYjQxMzY5MTI5MTEwfgQ GbWVtYmVyBD1jbj1KYW5lIERvZSxvdT1BbHVtbmkgQXNzb2NpYXRpb24sb3U9UGVvcGxlLGRjPWV4 YW1wbGUsZGM9Y29toDUwMwQJZW50cnlVVUlEMSYEJDI5ZDQ4ZTQ4LTM0YWItMTAyZC04YTcwLWFiN DEzNjkxMjkxMTCBhAQGbWVtYmVyBENjbj1KZW5uaWZlciBTbWl0aCxvdT1BbHVtbmkgQXNzb2NpYX Rpb24sb3U9UGVvcGxlLGRjPWV4YW1wbGUsZGM9Y29toDUwMwQJZW50cnlVVUlEMSYEJDI5ZDRhNjR lLTM0YWItMTAyZC04YTcxLWFiNDEzNjkxMjkxMTCBgQQGbWVtYmVyBEBjbj1NYXJrIEVsbGlvdCxv dT1BbHVtbmkgQXNzb2NpYXRpb24sb3U9UGVvcGxlLGRjPWV4YW1wbGUsZGM9Y29toDUwMwQJZW50c nlVVUlEMSYEJDI5ZDU1NGY0LTM0YWItMTAyZC04YTc0LWFiNDEzNjkxMjkxMTCBhQQGbWVtYmVyBE Rjbj1VcnN1bGEgSGFtcHN0ZXIsb3U9QWx1bW5pIEFzc29jaWF0aW9uLG91PVBlb3BsZSxkYz1leGF tcGxlLGRjPWNvbaA1MDMECWVudHJ5VVVJRDEmBCQyOWQ1OGVkOC0zNGFiLTEwMmQtOGE3NS1hYjQx MzY5MTI5MTE= # member: <entryUUID=29d53bf4-34ab-102d-8a73-ab4136912911>;cn=Manager,dc=exam ple,dc=com # member: <entryUUID=29d3a744-34ab-102d-8a6c-ab4136912911>;cn=Dorothy Stevens ,ou=Alumni Association,ou=People,dc=example,dc=com # member: <entryUUID=29d41396-34ab-102d-8a6e-ab4136912911>;cn=James A Jones 1 ,ou=Alumni Association,ou=People,dc=example,dc=com # member: <entryUUID=29d48e48-34ab-102d-8a70-ab4136912911>;cn=Jane Doe,ou=Alu mni Association,ou=People,dc=example,dc=com # member: <entryUUID=29d4a64e-34ab-102d-8a71-ab4136912911>;cn=Jennifer Smith, ou=Alumni Association,ou=People,dc=example,dc=com # member: <entryUUID=29d554f4-34ab-102d-8a74-ab4136912911>;cn=Mark Elliot,ou= Alumni Association,ou=People,dc=example,dc=com # member: <entryUUID=29d58ed8-34ab-102d-8a75-ab4136912911>;cn=Ursula Hampster ,ou=Alumni Association,ou=People,dc=example,dc=com member: cn=Manager,dc=example,dc=com member: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com member: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com member: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com member: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com member: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com member: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com owner: cn=Manager,dc=example,dc=com description: All Alumni Assoc Staff cn: Alumni Assoc Staff objectClass: groupOfNames The related C API is in libraries/libldap/deref.c; as a guideline, you can look at clients/ttols/ldapsearch.c, which creates the control and parses the response in order to print it in extended DN style. The current specification is formalized in a comment in overlays/deref.c; I intend to improve it and post it at <http://www.openldap.org/faq/data/cache/1469.html>. Please report through the ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 22 Oct '08

22 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200810/msg00105.html> and <https://www.redhat.com/archives/fedora-directory-devel/2008-October/msg0000…> for discussion. p.

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 22 Oct '08

22 Oct '08

------=_Part_18730_5320025.1224681987183 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Unfortunately the release 2.4.12 does not fix the replication problem exposed in this ITS. I send you two test files to reproduce the problem easily : Copy the file test018-parallel-import in the directory tests/scripts/ of the release 2.4.12. This file is a modified version of the script test018-syncreplication-persist importing two LDIF files in parallel. It shows that, in the case of simultaneous writes, the sync provider skips some events. Copy the file test-parallel.ldif joined here in the directory tests/data/. Change directory to tests/, then try the following : ./run test018-parallel-import You will see that the test fails very often (it fails more often on a rapid server !) This is a real issue and is worth to be studied seriously. Best Regards Sylvain Thomas ------=_Part_18730_5320025.1224681987183 Content-Type: application/zip; name=test018-parallel-import.zip Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Content-Disposition: attachment; filename=test018-parallel-import.zip UEsDBBQAAgAIAPRiVjmc9uFlHwoAALYmAAAXAAAAdGVzdDAxOC1wYXJhbGxlbC1pbXBvcnTtWtl3 2kYXf0Z/xQ3mxElrNhtah8TuJwNOSLHhAE5Oz+mLkAaYWGj0zUjG9K/vvaMFgbHjtc1D/WC0zNy5 y+9uM9p5BeUx98pqZuxAoeczr9sy+w3wL6dl17H8csBUoMrKltzHX7qrVA+LaunZkvkut62AC6/o M6m4CvauoFo6OCztlw5gv1I5LFf2y9Uq7B809n9p1KtwGcoA2tc+FIydHRjNuIKFkJeAv76Fr8QE EhZgKCbBwpIMPsyCwG+Uy4vFoiTwLbFVEnJaPi4hFSLUFP5S8uksgOq7d4dFWhmJsxWtUxF6juaU poDpuqDHK5BMMXnFnITUgDkoh+TjkEaD5TkQKgbcAyVCaTP9BBVmySVMhJyrPVjwYAZC6l8RBkRl Lhw+iXWzByQEKmjOg4A5IDx3CZYCK8Thkv+Fj8ZLCDLsEoV+OEblQpfbzFMs4c4EG0UlNQWkOzd6 S+qzrizuWmNXs0rEJhyvu51m+3zYjp8RhUD4RZddMRccLpkdCBmTY7AmuJDItxsw6aEQOHyJt1q0 rDUShrU1YmZKs2DuomUMjlQRLZAvnJjN39vnrTy8OoL82Bnn4fXrre9m9O49MeMZOWbPBORHNMwR TIEnAlCh7wvESToNh13zACrGhBtGNEOGnse9KThswj2mSmqWN0pQGA6arc4gBfLq7YrTwvCP82Z/ 0PsCR0AA96W48kTEDyQMDWPkA73lDpMgrph0raVmMDXDXkRSXXLfZ06WTzCM+SUqH4roBqP2cIRs QaF1gj/V+LdmGGhu0LJnvKyBz4qgAvIUXN0JbSYzj2zhqXAeP/KFH7pWwDR3QC4TPWaSUItgnrMY pahawrTDXIbw1KMsBOrcDxAs0ZgIngl9eCPZhElpuYR6e2Zx762eJhniB7EF6GrW2FKZxfUStpj7 5AvWFKegaOzaRwQi/tEJQzdQKHRswyEJREZMxATlWj75Doya/XKnDxEM+r3BqFoqlbSFm73z09NO d9QepPiAwlnvvDPqDVon8IEwcGYO8T2NhONoRtUoDLtmvwXFSfwAijMoXAw6eOFAofuli2bqnHXO P9KUbu8jxrPj11V4bfQ7raPCqxV8vpqdEeG4kmAY8E8LhCOR2U5LP5HMcjB2CMLs751uF58Pj/L0 Om8YymXMh2qiiAtFWiANKmZJe0YmsWfMvsQFrGBTPRgHYvRrnaClgZPvVwB5hgOoQf09OpORK5DX DtvmoPkJigq0rYpjdMdYXXmtg26vaXY/9YYjDVWta/jTyOV2xfgbGs52LaWOftpFtaA7XZW9EMMq qcbIDZpHhd+MXKqZQRMyasnlxqiDSyOHCoi96qvFtb3roBjizFEUXGOpUGQNcC1TLlJQ3XCExzKu iytkNR+TzShugo6JUHuDI9++QjrRNNL/sD340h4Mab4nKDRdchSk+OmiH70n+8T+i5MzkWZlHMvR bGJgIJeLnSVg12QhDDTXwLwAA20cmhOraYG0KcwW4q9F+jfPzY/tQev8dgsUF3hlDodfWwjpP7Ut O6eI8Pag3Wr2bxojssU9FEVCvICWUl9O48ftvly7vy/3q8MBOu6XdtaZa5vOXEucuXaLM9cSZ9a0 7u/RyXAoJFd3+XZyuRr9YFff0N6Lu3rtP1e/y9XT/Jp16FVN9fyufd7b4tyAwH3aKiVd0lPC1hdF TNCW6zK35GLe37Je7C0xdiv/enRJ0FTdgFNSpaGp0CQMS1iqVLwplnxkmpj/+ipICd8nOrE5dWW3 B3qYJl9JyVMlgwVLEtV4BNYVv3EmX1jEK8WFVFfRUgMs+czBKA/HcTnxkALkpSuQJwSo/2qRHyNA JRV7WrvfEp10i9ES2VYgajN0Ha6tctbD+PMHFK8eE1uOdQSjBqd3MYoA++EDtHtIdGg4XgNs7+iz Ncf2w4TPqEAF1T0Q4ZHphnOPg6mUsHncQePjPhM+tVWOfcSurTld4yW2FEbk18HSZ41YZAODTQMc yb1LQ/9vQE/SIPgcYpdqFI2o22mA8gyFrOj18bGet/Ys4fTkm5AefKYON+Kn41EjpfnDRs2eecIV 0yW0+BVXj+KZwpVlsw2+OzYCZcSslJHOqAVYUk0me7jARylCX+3di34icujx/4dszuZjbBWzN1ss sv8Mot5Y4plVGVvtbrFaQopgtkTNYX/qqccB7TvKeiR8E8PSptSTDOuwaHMDl0yJfmQvhVpUupGJ vY1094q2ApEDGxnIrB65VHQZcrTX9Ft0E/DARXLNGWcT6HhXGAr51Apo/wmhbvgC462Li2HKxUUI /QWoH9Thawm+Ymzk1hy1hs9MzwNTjmneWQdqh9XKgaEYs1wlNtQLK/1ukTH2u6aYTBgzZhgcN1g4 rNXgRIqFh+RKYPr4r7Z1/ZqRsUgDvjDaakOtTSxb8Tkno7nMnyF2vDCC1M9VOKgeQL1eh1/r9V+N uwYcHtQOjDkmklSV/6O76aIUC1QiaTT/RGF9LsoQQQRVMWAB5gXnKaYXcmp5/C8NK8u98HhgiLAB MeUUjAOhbKxESqhcN8B4zP4FSN7gQQMzvdHQlDRm3XinWOAES1tkXOulpUHvlo5neGwhb1sxdn3h OnpIlQarEKXlQj7Attuz8f4zyxPxahhxBXD/ziEuY160aPIRL4toD0ezHFVF+qmQjlq1c3Fx84h6 CKuh3c3sdw8Fr/R7Q727RPMY1mqsH0Gtz92TpVsfODGI9sRt2llebnReq62YqPlKb2OCZ1piojgX kuk9Odr9Frftyj2t/L1P/bs9hjw8Iie+9Y8VqzcL7DNsKVtiCvuV8n7FeG4Bvxfabwvi20N+GoPi jnzVzSdQ0yDY3q8/aI/xn9xk3Gzf151x/zHOuF9ftbWvop1YfZ56FIUQT9w4rsMaJ/TpqDXeS1nf toza5kc5V+1Gb/myzSV8D/yZanutVIhOtSUPsKsOUW8UYGHMbIvOkaMWnOlMY4GaWY5YJGcFe+t0 Qs/FejNSIp2xpeeMSB5nTPg0RB8CzF1S+BKFYe4S3r9dgXvbzsdaLvh+MnhwNlilA9pQMXI7WLEP d2rvfqllEKKxcUumTaLxmiPmHp56axupN8q9lhxb0nrG7Hsj/f4ISn9SFs6laZho9frmaDTA6KIP sC4uMMToQy4h1Tm6V3ziNeJzCqFzPzlSjt9GAqZv83ftJOqgZqF0ZP0kNU+kmN+SnJMdwyHk89F+ 4Yk5bN+VnKkAe7O2Xfh2F3Z/2oVCLCUdCUUHxBvV1MO39rL7oS9Tsd5Xc2uO9CjN1e6nOZ15nkNx q+8MnkVxD5wcK/qU08cva58gxF8pJEeUdDYTH1F+yOImBdFpd3SDWCrbncRSVSZqJVIxrab+iIJo JZ9bOOtGT/mNPrnIWr951s8wt6Ktj0/P+rhixmK/bTOYfhWbqrh9qfTrD4XZbjJhMvn4pZrB8TH9 RR+4qNC2GXPoI5m7bEUlPc6OvqL5G1BLAQIUABQAAgAIAPRiVjmc9uFlHwoAALYmAAAXAAAAAAAA AAEAIAAAAAAAAAB0ZXN0MDE4LXBhcmFsbGVsLWltcG9ydFBLBQYAAAAAAQABAEUAAABUCgAAAAA= ------=_Part_18730_5320025.1224681987183 Content-Type: application/zip; name=test-parallel.ldif.zip Content-Transfer-Encoding: base64 X-Attachment-Id: file2 Content-Disposition: attachment; filename=test-parallel.ldif.zip UEsDBBQAAgAIAO9iVjnzI9kQrw0AADZMAAASAAAAdGVzdC1wYXJhbGxlbC5sZGlmzVtbc+I6En73 r9DW2dqXnZ3B2AScqlQtYEjgQC5cksy8ObbABtsC28Akv37lG8jQxnLC1jlTlYmvrXbr6+6vW8of g05TRe2H4bBzPxEM9xqRzc0jJisbi98M/Qb/1hx6HB7qxBH+6AxbHVXtHF4hbwusB7qt+T5915tr rvWhBRZxNXvqWoFANtcokSek8m89sln5kHweacnbe2lNe+O4Fmr6PtGt6OFvZ7+BZ4xTmfvheu6M eE50DU2wbrrEJvN3pFpby7/I2AUDCAb2dc9ahfevr5E2fFB35FGd+3+2d/Jje+4/tHck6D7bv56i 80Z4Tu83wvuD9rbyER6r4TF9VhXQjgzCt/+cNPaS1L2ktX91kDLYS1lMn5bQdUtAFfFpqgOSvB+H caORolGHoJRl+qyAYi2Tpwej9hP5ZQWdPvTV3gwaocdYQUD7MeaQjuu7jG2YUZfQqAI6My5ofcuH Z2v6/Gs9FdCQ225N2G6NmtGewLbrPjW4pf8AdBdQe/thV0DLk1deKe1tokVouxw9MpafQNfVk68X EH1iA9mPjCrMlzM6DxVIPzOSIaBjKd0HY+JBX3mXL2Uvg9oulQI9vQbnPbiD5tjUY5891k+F7CQb kOT1IvsdAoqfDkagnbbgzIDohm3nKePZrQdKebqd/4YkkRcz9R9qOwg/HF/PRrT994S2o56sgm90 IV3md2cwKKCjpzd3rzlIHq1Bn818D7Vd8kULbqtvoVlbRfdpvDuOSq/PCn4B5/kRQneHHZH6bGoT H5qFj4IIf9B5MYxx90UJmfcFFD7x++W5CMUHyb/BGZF2y8Rnj7OeDkkGoz+ZHeE0zRVF8fYw2hyM 12aNxR0TFz6ePkCfBHU+9kaaK45y5UHyRu22QNy9g35xb6hdAbVASV0Fgx4GZUXPnL36YK6IJZ7E ulexDtm2DecKC4wjdUhy67zXCYi1LGiTpgGyDTMArERxZ+rcMa4D6eYzOZrGO8CiufZkEAzNYCAg SMK6Xjr/xzNziHdg9CG/fO5IJcM+a0LzvJpy+UriswTMXb2x2i/lF/c0GvdbBTmgKGIx/CHKs2dz gFrAhzMahLniBBmLAmQcNHA7OXXFYNxpOWB8k+ydMZ7weVzks+BXkjfQ40DuNAR9dvXjE17ParCI 64qSOpxk61PbwTqIXrnR0jzLaGys+XHYWmdrzL3PrlpPBTZSe2C1sHpkRmdqshJx70HT4ZwhoMIY VyZnxNz4XM0IVy63IOKHlKMA9hj1waeLR4t8Nt+r56D1n5S80YC6wlO0EpKzfIpylE/k/Zy6zKkI qF6QAUsxjbCuKJMZC1ATcZT2xVgPwI0HBRVBXk1x4MZ1bu65BCvpfTaI61mOWrCg8ozf/7eAxvwZ cFcUc8JccZaN/TkRwcxIRiAeBbTN4xtgdX7qQ78qPxsg7nL6JkYXjCmmcZeJnNGoIb/LY7M1MD6v 22I/V3cAdy1xBHn7urvDyx8FmGQ5yiLH6mOdu6MkoKYxeQRt8wbYpsgyYT17ZJuOW6IvcFTpp30U UyuliwLPEpsrGCytety4ozM3ZHHH3vkr4t0C5O3NSHqYK4orN566rcHUs6QP9rSlstVKyFE4KhDt blrj4VVpXVHE8Dn5fcSNORg+Z4Sl3LjHr8OgoGtUzO9alZ7O3XdsJvXskW4Bf1e6adwyFUNSz6bd yJ+KEf5MziD1LE4j3H2x28FYJ+p99sBadV6KU8W2jHMFi/mRpbSmbaUV/n6hP7/o8ctHK/r9a5L8 pj9vyTVMr+VwY/rEcNo16Y83nHZujpappt0i051r7cVt2680B4+ai2H77KyEdRdMVqsRGDYFdEHd GgytL5LALiJ1+m2wVFJhl/FgKdN+ezQBA4i4W/a7b2yoPozRn7RHr8/PrfG0wU37jEmDWS5gdLhv 9NWWCC6rFDX/Wdu1JmCrahnAzYjdcgg0+uPW46z9tAPTLhwoqg8TOPQk1PTYZadwYdODaVcPplcm LKV/rxfa7ECvWJsVEfGiNKOyrUdl8grize70VVD6Ldy2hdsn4LLtfc7i4aDXCfFI09zxmN2JrfIv u4j3czjNgRRlteAmlo40+s36LGPdjxKLcXBJ5CmvWsmZMG4H8HLBYFb9KGV5UE9RZdtnBYTM5qAx +/YZ4abKa7EyduZkUpFO9aYUAdZ8AUqazydnyUi0LM/SEdUrZcPJuMVusGBp/ae2WGSlC2i/xQLO JhJ3sU/uYFpvgvpUnpb9259ezlcno8ZtjMeCNgW81Dwat0bPzuoJ3g5Salk53AYBLPNGucJ8eIW3 xpgvP8qVHaelONxqNEegFZ4fslrELe+8AmpRJu7p8FKLlbMpiKetu/dZcEErgEvHau7WJCbPMvq9 t0Dp5pRtlEC5LM4Vh1z2c8idJeUSS3zw/II6L+ElvhKbNRbg8rIy0dhtSJ/L1PlLLZ701XxBbZfT SPoxhbPR4NyWG6aNkV8yBtwLOQJaKWQI+qM95G9nSHCuABfe1pUtL7MIfRac2wl/a5nG6QcdtJ0H zkrH6MBNkWAyqjyyhT/TtgVxds+9dYrUBsky1Yn2zfl0yO15fg6/g3NnTpNwCrIQAZ2f+SyHh+03 getZUsCb2C1mLzAmwdYjkbi3Cbi7m5t4w6zu3jRtG40DbTb7dnbrr4OdN+xFbww1V5tjr+Cplua9 aZ6G+tj1cbTvtvzWXOqvoOy+5mKkEvztE/uLWTHEdFMxn903LKBT83hL1LFtiwRf1U9zsI+aqE9c +lu8qLTqpz5aQHnCsetaM+yhsWMF5hc1VYlHAvOdwhJvKXq+KG3q+RtbQ3f0vh9g74vSWgviuV8C 9coW0GHH+c4t9irdDbe8J26a6dyhzhZ773RCkeWiwMTIj15EhhZo2d3s89CzycwNQcD4/sEO/5cg cNmZvLQ/XCaIXBL5l4sdF0A9FzYzaAxBeoqpBL8nl4vxeYkcEuoqIOgPPB5W2B2ozccV9nziRlpm B0wuvfnpuR/2ynudlf3m3ttvVvNG2FjGNaJCo9uBFdj4Gg3fA9PSNRvtzYZG2Meap5to/E5nw/GF FfEDzdYMw8OhKr2Jih49YiAVb9G/6P8rm7w72A3QP1FNqqGX7+jForDQHGq772hEiIPkqlilt5vu e0Br0Z37DQ17SG6IFek/siJLgo+xZvukTJLf+NhbUdvQIt2gX/rTSb50TvmCo1n2/lP/G57Nd9+T 97+HL5vEwUefJVYl9IJ9G78nimbUzGJnbzUnthoisyiieb5hoI1r/UYrj4SzJxie5S6v0U6juI5H NWlAuEb/FpEkSqhWq6GqJEnCKhSTuSzR68JM033LsWwcYDt+1d3EbsMKqNZl4dwDSqVaPeD0AkmB IROFKGWGiy9Y1mzGgDQ9TNBJn74MGra6I9+AE60odKrHYZBHQ2paNDK+0ykfk01gogFNUPGsK/Rf On09HRvUOFoWBXfWkgYr9Bb+Sv1JtTxqDkIvd+g0GAZ9L8+NqN0jg+9NDfsPBMYU39RYueg+wVlN lmUAZ7JM0cOHM7FeP4uzilSr7XF2gXRahK2jIZJrwf48RFd6HMHLIIGfztQY6x4ONO/9G5oOob/S O5qv0yfo1IiiSCNnyGLGATBTymegnGBugB3iagaGICzV6+jFtAIcIaS5ov9JwPByFq/PlH4hKsbm m26pWpXOTrd0dSUnUAwNGyHxuxaZiQOOFbkm78ES5hQO03wuy++FRwA5nEE5nQbv9QbHmT0+5uOR J89mwuzDtGSYpaw7Ix+dDvC1EiliGcVjfKnozFTE6UxfgBcXhYWjIZhr0ZX43HKSsygFRUdRiFho i7/M84+SmOZ016D3NxpV1KJhzbPfk+R1PHwtx+nker2adZCHTUCFu4blzvecUDNQm+z2RDBMcjkh 8pS10NyaxARqydyQwBWAZEmqns83DaWWA6zqp6mNgD6HsyoHzqgrJShbxNfKYwTAgyJJqOURsvTB HAAjodGQGodU6FrEY0qAMn83ju5pxtWovq6BwgIfORvdTCEQfSZEUbjJ0J4LQTzoFH/VBi9rblw1 GmfRVZckmUHX5wvwYhzFsg8nTXsb386CxqBHyZTRAmzuaY5Da4+mq9mUYv7daExOiUVl+4GHcQDz lZj7GBa9r5MlPmoguYG58S3NDyw9RRi1yX93hMy+uzjIJ741ACpitVrhJL6SKJ6FCg2rDFS+3GQp BExmhPRSchaR3ugoBg3+y5nsmHpv09BoCQRholKpJAP/IcuglyeQn9AJcDRviYP8hJSAIin6+clo Tg1+JctVTojUa1dnIdKoSoca/BLNfD6kJAMlJ64WUPWiC9nIQh8zoD7PSUX6/wsOilhFHeraqGXb WwOMDmm6igpqCinHci0aTLSo3i6VswiNr5RlLbHxjxQzoQn4i2kp9HgAMLU6Z/qh1U9B00ZSDjHl TOWRgQAz9ekrcVWctCXeTy6HFyIw7G9kO13J1bTDZaSCjsmqXn1e6M5zhVH5S+3hImQz4g/nzfRK +EHJYQRwB8cnf6dkqCgh+aZRXPWsLaYj/Vz5lq25gZWOpTTyamdaAqTR9VbziW25+LQDdS5EJgbJ DZOn0K5f1UU+aNfrV+d5uxw2klKcXKL5X4CVoyEidOxPInxsTFqu/t0bQ59iVPF0h99XMiU25KoI EmyZs12o1CuVszCoSZIo/A9QSwECFAAUAAIACADvYlY58yPZEK8NAAA2TAAAEgAAAAAAAAABACAA AAAAAAAAdGVzdC1wYXJhbGxlbC5sZGlmUEsFBgAAAAABAAEAQAAAAN8NAAAAAA== ------=_Part_18730_5320025.1224681987183--

1 0

(ITS#5767) ppolicy doesn't recognize the smbkrb5-specific {K5KEY} storage scheme
by Guillaume.Rousse＠inria.fr 22 Oct '08

22 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.11 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) When using password policy, with pwdCheckQuality set to 1, ppolicy accept to change the password of a user to special values such as {SASL} without complaining. However, trying to use {K5KEY} instead doesn't work, as it doesn't satisfy quality checking: ldap_modify: Constraint violation (19) additional info: Password fails quality checking policy

1 0

(ITS#5766) smbkrb5 overlay doesn't honour kerberos principal expiration
by Guillaume.Rousse＠inria.fr 22 Oct '08

22 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) When using the smbkrb5 overlay, the {K5KEY} password can be used to make autentication use kerberos credentials. However, this redirection doesn't honour krb5ValidEnd or sambaKickoffTime attribute, positionned by either heimdal or smbkrb5 overlay when setting an expiration date to the kerberos principal. Whereas kdc refuses to provides a ticket for the user, openldap still allows the user to authenticate.

1 0

RE: (ITS#5765) Can not set log file with configdb
by emmanuel.duru＠atosorigin.com 22 Oct '08

22 Oct '08

OK it works, thank you.

1 0

Re: (ITS#5765) Can not set log file with configdb
by ando＠sys-net.it 22 Oct '08

22 Oct '08

emmanuel.duru(a)atosorigin.com wrote: Should be fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5765) Can not set log file with configdb
by emmanuel.duru＠atosorigin.com 22 Oct '08

22 Oct '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) I have a slapd.conf with a logfile directive. When converting the conf to LDIF (slapd -f slapd.conf -F /path/configdb), this directive is lost. When I try to add an olcLogFile attribute to cn=config, I get an "object class violation" error. I suppose the olcLogFile attribute is missing in the hard-coded schema for olcGlobal object class.

1 0

(ITS#5764) addpartial patch
by dhawes＠vt.edu 21 Oct '08

21 Oct '08

Full_Name: David Hawes Version: 2.4.12 OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch Submission from: (NULL) (128.173.38.164) This patch includes the following changes: - -fPIC added to the Makefile for compilation on x86_64 systems. - No longer use be_search() to retrieve the entry that is to be compared. Use be_entry_get_rw() instead. - No need to use strlen.

1 0

Re: (ITS#5757) back-null returns an error when any critical extension is specified
by jclarke＠linagora.com 21 Oct '08

21 Oct '08

ando(a)sys-net.it a écrit : > ando(a)sys-net.it wrote: >> A different fix is in HEAD. Please test. p. > > A more thorough fix is now in HEAD. Please re-test. Just tested, it works as expected: - searches with a non-critical control propagate the control to "glued-sub-backends" which use it if possible. - searches with a critical control propagate the control to "glued-sub-backends" and return error 12 if it is not supported. This is indeed a much better approach that I originally proposed - respecting control criticality as required, and reminded by Kurt. Thanks ando! Regards, Jonathan -- Jonathan Clarke Open Source Identity Management --------------------------------------------------------------- Linagora 27 rue de Berri, 75008 Paris Tel: 01 58 18 68 28 / 06 99 60 03 10 --------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org/ ---------------------------------------------------------------

1 0

(ITS#5763) libRSAglue bug in OpenLDAP configure script
by epj＠newpointtech.com 21 Oct '08

21 Oct '08

Full_Name: Eric Johanson Version: 2.4.12 OS: Debian Linux 4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.80.228.78) The "configure" script has a bug when TLS is enabled, which causes it to fail when using recent versions of OpenSSL. The bug is found on line 18759 of the "configure" script in OpenLDAP 2.4.12. The line currently reads: LIBS="-lssl -lcrypto -lRSAglue -lrsaref $LIBS" But the -lRSAglue and -lrsaref are old OpenSSL libraries that are not in use any more. I modified the above line to read: LIBS="-lssl -lcrypto $LIBS" This solves the problem. However, perhaps someone wants to add logic to detect which version of OpenSSL is being used and then vary the LIBS variable accordingly when the configure script tests for the linkability of the ssl3_accept() function. Note that many Linux systems, even those that have a recent OpenSSL, may still have the -lRSAglue and -lrsaref libraries (just for compatibility reasons). To reproduce this bug, you will have to search your system and remove all files with the names libRSAglue.a and librsaref.a.

1 0

(ITS#5762) ldap_create_page_control might return wrong error code
by ralf＠OpenLDAP.org 21 Oct '08

21 Oct '08

Full_Name: Ralf Haferkamp Version: RE24, Head OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.241.0) Submitted by: ralf ldap_create_page_control_value doesn't reset ld_errno to LDAP_SUCCESS therefor it will return the result code of the previous LDAP API call instead of LDAP_SUCCESS. (If the previous LDAP API call set ld_errno do something different than LDAP_SUCCESS). The same seems to be true for the corresponding function in at least: sortctrl.c, vlvctrl.c and stctrl.c Fix will follow.

1 0

Re: (ITS#5755) Schema file not always converted to LDIF and slapdwon't restart
by hyc＠symas.com 21 Oct '08

21 Oct '08

emmanuel.duru(a)atosorigin.com wrote: > OK this works. > My mistake, the concerned character is in fact a Windows character (CP1252) > I hadn't noticed when I converted my schema to a text file. With the patch in HEAD your schema file now yields: config_build_attrs: error 21 on olcAttributeTypes value #3 config_build_entry: build "cn={0}test" failed: "" backend_startup_one: bi_db_open failed! (-1) slapd stopped. Probably we should be detecting this problem earlier, when parsing slapd.conf, instead of when generating the cn=config entries. >> -----Message d'origine----- >> De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] >> Envoyé : lundi 20 octobre 2008 19:39 >> À : Emmanuel Duru >> Cc : openldap-its(a)OpenLDAP.org >> Objet : RE: (ITS#5755) Schema file not always converted to LDIF and >> slapdwon't restart >> >> The problem is the 8-bit Latin-1 character in the certificate's DESC. >> It works if you convert the schema file to UTF-8. >> >> Slapd should have refused to start with a non-UTF-8 attribute DESC. >> Possibly that should wait for OpenLDAP 2.5 though, and just log a >> warning for now. >> >> -- >> Hallvard > > > > -- -- 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#5755) Schema file not always converted to LDIF and slapdwon't restart
by emmanuel.duru＠atosorigin.com 21 Oct '08

21 Oct '08

OK this works. My mistake, the concerned character is in fact a Windows character (CP1252) I hadn't noticed when I converted my schema to a text file. > -----Message d'origine----- > De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] > Envoyé : lundi 20 octobre 2008 19:39 > À : Emmanuel Duru > Cc : openldap-its(a)OpenLDAP.org > Objet : RE: (ITS#5755) Schema file not always converted to LDIF and > slapdwon't restart > > The problem is the 8-bit Latin-1 character in the certificate's DESC. > It works if you convert the schema file to UTF-8. > > Slapd should have refused to start with a non-UTF-8 attribute DESC. > Possibly that should wait for OpenLDAP 2.5 though, and just log a > warning for now. > > -- > Hallvard

1 0

Re: (ITS#5761) More flexible dynlist configuration desirable
by ando＠sys-net.it 21 Oct '08

21 Oct '08

Applied to HEAD; please test. Instructions are (should be) in slapo-dynlist(5). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5761) More flexible dynlist configuration desirable
by Guillaume.Rousse＠inria.fr 21 Oct '08

21 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) Dynlist overlay only accept a single configuration directive for the whole base, preventing to map differently the request URL depending on the context. For including users into groups with such URL as ldap:///ou=users,dc=domain,dc=tld??sub?(gidNumber=X), you need dynlist-attrset groupOfURLs memberURL member For including groups into other groups, with such URL as ldap:///ou=group,dc=domain,dc=tld?member?sub?(cn=Y), you need dynlist-attrset groupOfURLs memberURL It would be practical to add a switch for this directive, allowing to restrict its application to a specific context. Pierangelo suggested something as: dynlist-attrset <group-oc> <URL-ad> [ ldap:///base??scope?filter ] [[<mapped-ad>:]<member-ad> ...] Which would turn previous examples into: dynlist-attrset groupOfURLs memberURL ldap:///ou=users,dc=domain,dc=tld??sub?(gidNumber=X) member dynlist-attrset groupOfURLs memberURL ldap:///ou=group,dc=domain,dc=tld??sub?(cn=Y)

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 20 Oct '08

20 Oct '08

brett.maxfield(a)gmail.com wrote: > Full_Name: Brett Maxfield > Version: 2.4.12 release > OS: Solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.18.108.167) > > > There is a bug that stops rwm-map being used to hide attributes, eg : > > database ldap > suffix "c=AU" > uri "ldap://<parent ip>:<parent port>/c=AU" > overlay rwm > lastmod off > > # attribute maps (ok except for final "rwm-map attribute *" map) > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute mail * > rwm-map attribute c * > rwm-map attribute o * > rwm-map attribute ou * > > # does not like this, it stops any entries being returned > #rwm-map attribute * > > # objectclass maps (ok) > rwm-map objectclass top * > rwm-map objectclass country * > rwm-map objectclass organization * > rwm-map objectclass organizationalRole * > rwm-map objectclass organizationalPerson * > rwm-map objectclass organizationalUnit * > rwm-map objectclass * Not clear what the problem is, now. The above configuration seems to work as intended as far as attribute mapping is concerned. The fact that "rwm-map objectclass *" no longer kills the objectClass attribuet was fixed some time ago (the fix is in 2.4.12). What kills the allowed objectClass values is a bug in evaluating what values are preserved. If you don't put any "rwm-map objectclass" rule, it works as expected. I'm fixing this other bug. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs