- openldap-bugs - openldap.org

(ITS#5778) slapd crashes while adding multipe attributes
by yoreck＠rambler.ru 29 Oct '08

29 Oct '08

Full_Name: Yuriy V. Ohonin Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) OS: FreeBSD 6.2-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.16.93) slapd daemon crashes complitely in such a situation: I create my own class in shema objectclass ( Tasks:Chain:Element NAME ('x-tch-e' 'x-Task-Chain-Element') MUST ( cn ) MAY ( x-tch-nxt $ x-tch-sp $ x-tch-ep ) DESC 'Container of pointers, next and previos' ) and an attribute wich should have multiple values attributetype ( Tasks:Attr:3 NAME ('x-tch-nxt' 'x-Task-Chain-Next') EQUALITY distinguishedNameMatch DESC 'Point to next chain element' SYNTAX distinguishedName ) Slapd starts sussesfully. It is possible add first x-tch-nxt attribute to an entry, but if i try to add next one (usind ldapbrowser, or ldap_mod_add php function) slapd stops (i have no such process any more) this is what syslog say: Oct 30 12:11:45 yurik kernel: pid 13227 (slapd), uid 389: exited on signal 6

1 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by michael＠stroeder.com 29 Oct '08

29 Oct '08

Kurt Zeilenga wrote: > > On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote: > >> I wonder whether it would be worth that slapd rejects a SASL bind >> request with >> BindRequest.name set (normally used for simple bind) returning a >> protocolError >> error code. > > RFC 4513: > Clients sending a BindRequest message with the sasl choice selected > SHOULD send a zero-length value in the name field. Servers receiving > a BindRequest message with the sasl choice selected SHALL ignore any > value in the name field. > > So, no. Ok. My intention was that if 'name' field and SASL authc-ID leads to different identity mapping it could confuse admins seeing 'name' in the BindRequest but a different authz-ID being in effect. Anyway no strong need, just an idea. Ciao, Michael.

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc＠symas.com 29 Oct '08

29 Oct '08

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: > URL: > Submission from: (NULL) (193.55.250.67) > > > [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr > ... > bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run > database recovery > bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run > recovery > bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: > DB_RUNRECOVERY: Fatal error, run database recovery (-30975) > [root@etoile ~]# echo $? > 0 > > It makes a bit difficult to know if slapcat-based backup were successful. How did you create this situation? I can't test a fix without some way to break the DB in the first place, and generally the DB doesn't fail... -- -- 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#5763) libRSAglue bug in OpenLDAP configure script
by hyc＠symas.com 29 Oct '08

29 Oct '08

epj(a)newpointtech.com wrote: > 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. The configure script only checks for -lRSAglue after it has already failed to link without it. As such, there's something wrong on your machine for it to even be reaching that test. There is no OpenLDAP bug 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

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by Kurt＠OpenLDAP.org 29 Oct '08

29 Oct '08

On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote: > I wonder whether it would be worth that slapd rejects a SASL bind > request with > BindRequest.name set (normally used for simple bind) returning a > protocolError > error code. RFC 4513: Clients sending a BindRequest message with the sasl choice selected SHOULD send a zero-length value in the name field. Servers receiving a BindRequest message with the sasl choice selected SHALL ignore any value in the name field. So, no. -- Kurt

1 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by hyc＠symas.com 29 Oct '08

29 Oct '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (84.163.120.227) > > > This is somewhat related to the client tool modification in ITS#5753. > > I wonder whether it would be worth that slapd rejects a SASL bind request with > BindRequest.name set (normally used for simple bind) returning a protocolError > error code. > > Example for an inconsistent use of -D and -U with SASL/DIGEST-MD5 at the > command-line: > > $ ldapwhoami -D "cn=root,dc=stroeder,dc=de" -W -U michael -Y DIGEST-MD5 > Enter LDAP Password: > SASL/DIGEST-MD5 authentication started > SASL username: michael > SASL SSF: 128 > SASL data security layer installed. > dn:cn=michael ströder,ou=private,dc=stroeder,dc=de Changing this behavior seems like a bad idea to me. Currently the RFC doesn't require servers to behave one way or the other, so there's no argument that this change would improve interoperability. If there are no clients out there depending on the behavior, then this change is meaningless. If there *are* clients out there depending on the behavior, then they will break for no apparent reason. -- -- 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#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by michael＠stroeder.com 29 Oct '08

29 Oct '08

Full_Name: Michael Ströder Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.120.227) This is somewhat related to the client tool modification in ITS#5753. I wonder whether it would be worth that slapd rejects a SASL bind request with BindRequest.name set (normally used for simple bind) returning a protocolError error code. Example for an inconsistent use of -D and -U with SASL/DIGEST-MD5 at the command-line: $ ldapwhoami -D "cn=root,dc=stroeder,dc=de" -W -U michael -Y DIGEST-MD5 Enter LDAP Password: SASL/DIGEST-MD5 authentication started SASL username: michael SASL SSF: 128 SASL data security layer installed. dn:cn=michael ströder,ou=private,dc=stroeder,dc=de

1 0

Re: (ITS#5753) Command-line tools: Handling of -x and -D vs. -Y and -U
by michael＠stroeder.com 29 Oct '08

29 Oct '08

Seems to work as expected.

1 0

Re: (ITS#5771) autogroup overlay prevent slapd to works correctly
by ando＠sys-net.it 28 Oct '08

28 Oct '08

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.224.237.5) > > > Enabling the autogroup overlay make slapd unwilling to work: > > [guillaume@oberkampf ~]$ ldapsearch -LLL -x > Server is unwilling to perform (53) > Additional information: operation not supported within namingContext I think this is a duplicate of ITS#5724; in fact, it seems to be already fixed in HEAD code. 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#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()
by dhawes＠vt.edu 28 Oct '08

28 Oct '08

Pierangelo Masarati wrote: > Fixed in HEAD; please test. Thanks, p. Fix works, thanks.

1 0

Re: (ITS#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()
by ando＠sys-net.it 28 Oct '08

28 Oct '08

Fixed in HEAD; please test. Thanks, 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: ACLs related to the content of *new* entries (ITS#4556)
by manu＠netbsd.org 28 Oct '08

28 Oct '08

Howard Chu <hyc(a)symas.com> wrote: > Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file. ITS's > that involve code changes generally don't get closed until the change gets > released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g. > patches to something that only existed in HEAD...) Given that rule, then it should remain open. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#5776) syncprov removes qtask from runqueue twice
by rein＠OpenLDAP.org 28 Oct '08

28 Oct '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncprov could attempt to remove its qtask from the runqueue twice if syncprov_qlay() detects an error. First in that function, later in syncprov_free_syncop(). A fix is coming. -- Rein Tollevik Basefarm AS

1 0

(ITS#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()
by dhawes＠vt.edu 28 Oct '08

28 Oct '08

Full_Name: David Hawes Version: 2.4.12 OS: Debian GNU/Linux 4.0 URL: Submission from: (NULL) (96.253.80.116) slap_send_search_entry() prints out some logging messages at result.c:1228 which includes the DN of the entry being sent. The entry is previously released on line 1202. If no overlays are configured, the DN in the log message is printed correctly. If, however, an overlay makes a copy (with entry_dup()) of the entry that is being sent, the DN printed out will be garbled or empty. Moving the block of code at line 1201 below the Statslog line will cause the DN to be printed correctly. I initially noticed this with some custom overlays, but it is easy to reproduce with the valsort overlay. Simple enable the overlay and search for an entry that will cause valsort to call entry_dup(), and look for the log message.

1 0

Re: ACLs related to the content of *new* entries (ITS#4556)
by ando＠sys-net.it 28 Oct '08

28 Oct '08

hyc(a)symas.com wrote: > manu(a)netbsd.org wrote: >> Hello >> >> I believe this has been fixed. This ITS should be closed, IMO. >> > Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file. ITS's > that involve code changes generally don't get closed until the change gets > released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g. > patches to something that only existed in HEAD...) Right. I thought it was released, though. It was committed well before 2.4.12 was released. Moved to "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

Re: ACLs related to the content of *new* entries (ITS#4556)
by hyc＠symas.com 28 Oct '08

28 Oct '08

manu(a)netbsd.org wrote: > Hello > > I believe this has been fixed. This ITS should be closed, IMO. > Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file. ITS's that involve code changes generally don't get closed until the change gets released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g. patches to something that only existed in HEAD...) -- -- 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

ACLs related to the content of *new* entries (ITS#4556)
by manu＠netbsd.org 28 Oct '08

28 Oct '08

Hello I believe this has been fixed. This ITS should be closed, IMO. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5767) ppolicy doesn't recognize the smbkrb5-specific {K5KEY} storage scheme
by hyc＠symas.com 28 Oct '08

28 Oct '08

Guillaume.Rousse(a)inria.fr wrote: > 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 This is not a bug; ppolicy quality checking only works when a plaintext password is provided. The fact that you saw "{SASL}" work is probably just a coincidence, i.e., --enable-spasswd is not set by default in configure, so "{SASL}" is just treated as a plaintext string, not a password scheme. -- -- 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#5774) Modifications not saved on file by back-ldif (on Windows)
by hyc＠symas.com 27 Oct '08

27 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> I guess we should be using #ifdef _WIN32 / ReplaceFile instead of >> rename() in this case. > > Argh, why didn't that arrive before I wrote my reply? I don't know > Windows... > I don't think it's worth the effort to learn, really. But all of the Windows API documentation is on msdn.microsoft.com if you're inclined to read it. MoveFileEx(old,new,MOVEFILE_REPLACE_EXISTING) would also be fine. http://msdn.microsoft.com/en-us/library/aa365240(VS.85).aspx -- -- 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#5774) Modifications not saved on file by back-ldif (on Windows)
by h.b.furuseth＠usit.uio.no 27 Oct '08

27 Oct '08

hyc(a)symas.com writes: > I guess we should be using #ifdef _WIN32 / ReplaceFile instead of > rename() in this case. Argh, why didn't that arrive before I wrote my reply? I don't know Windows... -- Hallvard

1 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by h.b.furuseth＠usit.uio.no 27 Oct '08

27 Oct '08

emmanuel.duru(a)atosorigin.com writes: > Reading back-ldif code I see that when modifying an entry, back-ldif > creates a temporary file containing the modified entry, and then > renames the temporary file to the entry file. > > On Windows, renaming a file to an already existing file does not work, > it gets an ERROR_ALREADY_EXISTS error (183), error code which is > ignored by back-ldif. If so we should rename cn=foo.ldif to cn=foo.save before moving the new file in place and delete the .save afterwards, so the old file won't be lost if slapd or the machine dies as just the wrong time. Might try the same as a fallback on Mac/Unix if rename(tmpfile, ldiffile) fails there. There are lots of strange OSes out there, or for that matter an OS might mount a filesystem from another OS. It still needs manual cleanup though. But we could maintain a "state" file in the database directory which says which entry was last written, and on startup in write mode rename that file back. Read mode slapcat could read any .save files as well as .ldif files. Or all acceses to .ldif files could, though that doubles the number of failed open/stat() calls. -- Hallvard

1 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by hyc＠symas.com 27 Oct '08

27 Oct '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > On Windows, modifications are not saved on file by back-ldif. > This is the case for example with cn=config. > > Reading back-ldif code I see that when modifying an entry, back-ldif creates a > temporary file containing the modified entry, and then renames the temporary > file to the entry file. > On Windows, renaming a file to an already existing file does not work, it gets > an ERROR_ALREADY_EXISTS error (183), error code which is ignored by back-ldif. > > > I guess we should be using #ifdef _WIN32 / ReplaceFile instead of rename() in this case. -- -- 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#5774) Modifications not saved on file by back-ldif (on Windows)
by emmanuel.duru＠atosorigin.com 27 Oct '08

27 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) On Windows, modifications are not saved on file by back-ldif. This is the case for example with cn=config. Reading back-ldif code I see that when modifying an entry, back-ldif creates a temporary file containing the modified entry, and then renames the temporary file to the entry file. On Windows, renaming a file to an already existing file does not work, it gets an ERROR_ALREADY_EXISTS error (183), error code which is ignored by back-ldif.

1 0

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

27 Oct '08

OK, forget it. > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : jeudi 23 octobre 2008 16:13 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5769) Behaviour of ldap_sort_entries on a multivalued > attribute > > 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

Re: (ITS#5773) bi_entry_get_rw() and overlays issue
by ando＠sys-net.it 26 Oct '08

26 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I think bi_entry_get_rw() needs work. > > Or maybe phase it out in favor of some other call? > >> In fact, as also discussed in ITS#5628, callers either return the >> entry or have no means to modify the arguments of the request. > > It has more troubles than that. See e.g. the notes about passing rw=1 > (write) to it here: > http://www.openldap.org/lists/openldap-devel/200803/msg00055.html > And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which > says to pass an rw=1 argument to bi_entry_release_rw(). Well, I see many places where an entry needs to be fetched. Typically, it needs to be done read-only. So the difference between bi_entry_get_ro() and an internal search is that if we are fine with the entry in-cache, we save lots of manipulation. However this might no longer suffice when overlays muck with the entry (like slapo-rwm). Moreover, when overlays are present, I see the need to: 1) run it like it came from outside, going thru all the overlays 2) go straight to the underlying database 3) go thru overlays starting at some point (e.g. when called from inside an overlay under the assumption the entry is fetched as that overlay would see it, so with only any possible mucking from overlays layered deeper than the caller). This probably needs to modify the way callbacks are actually called, allowing some "after self" feature in playing not just the overlay list, but also the response (and the cleanup). 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#5773) bi_entry_get_rw() and overlays issue
by h.b.furuseth＠usit.uio.no 26 Oct '08

26 Oct '08

ando(a)sys-net.it writes: > I think bi_entry_get_rw() needs work. Or maybe phase it out in favor of some other call? > In fact, as also discussed in ITS#5628, callers either return the > entry or have no means to modify the arguments of the request. It has more troubles than that. See e.g. the notes about passing rw=1 (write) to it here: http://www.openldap.org/lists/openldap-devel/200803/msg00055.html And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which says to pass an rw=1 argument to bi_entry_release_rw(). -- Hallvard

1 0

(ITS#5773) bi_entry_get_rw() and overlays issue
by ando＠sys-net.it 26 Oct '08

26 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I think bi_entry_get_rw() needs work. In fact, as also discussed in ITS#5628, callers either return the entry or have no means to modify the arguments of the request. This can be critical, for example, when slapo-rwm(5) is involved. In many cases, it might need to rewrite the ndn, or to map the attribute and the objectClass. However, this cannot be done without returning the entry, and thus directly performing a bi_entry_get_rw() to the original database, bypassing any further stacked overlay. Probably, the API of this call, and that of bi_entry_release_rw() should be modified in conformity to that of BI_op_func, possibly adding further structs to the main union. I'm not going to implement this right now, as I fear I might have overlooked something. Moreover, this change would have significant impact on existing code, since these calls are widely used. In the meanwhile I'm adding support for these two calls to slapo-rwm(5) along the above lines. p.

1 0

(ITS#5772) slapo-rwm does not normalize rewritten DN-valued attributes
by ando＠sys-net.it 26 Oct '08

26 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Only a_vals are rewritten; this is not an issue when used with back-ldap, but can be an issue when used with back-relay and in all cases overlays are expected to interact. A fix is coming. p.

1 0

(ITS#5771) autogroup overlay prevent slapd to works correctly
by Guillaume.Rousse＠inria.fr 25 Oct '08

25 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.224.237.5) Enabling the autogroup overlay make slapd unwilling to work: [guillaume@oberkampf ~]$ ldapsearch -LLL -x Server is unwilling to perform (53) Additional information: operation not supported within namingContext No need for dynamic entry in the DIT to trigger the error, just configuring the overlay as documented in its README file is enough: overlay autogroup autogroup-attrset groupOfURLs memberURL member

1 0

(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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs