openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs