October 2008 - openldap-bugs

Re: (ITS#5771) autogroup overlay prevent slapd to works correctly

by ando＠sys-net.it

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

14 years, 4 months

1
0
0 / 0

Re: (ITS#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()

by dhawes＠vt.edu

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

14 years, 4 months

1
0
0 / 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

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

14 years, 4 months

1
0
0 / 0

Re: ACLs related to the content of *new* entries (ITS#4556)

by manu＠netbsd.org

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

14 years, 4 months

1
0
0 / 0

(ITS#5776) syncprov removes qtask from runqueue twice

by rein＠OpenLDAP.org

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

14 years, 4 months

1
0
0 / 0

(ITS#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()

by dhawes＠vt.edu

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.

14 years, 4 months

1
0
0 / 0

Re: ACLs related to the content of *new* entries (ITS#4556)

by ando＠sys-net.it

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

14 years, 4 months

1
0
0 / 0

Re: ACLs related to the content of *new* entries (ITS#4556)

by hyc＠symas.com

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/

14 years, 4 months

1
0
0 / 0

ACLs related to the content of *new* entries (ITS#4556)

by manu＠netbsd.org

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

14 years, 4 months

1
0
0 / 0

Re: (ITS#5767) ppolicy doesn't recognize the smbkrb5-specific {K5KEY} storage scheme

by hyc＠symas.com

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/

14 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2008