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, 11 months
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, 11 months
(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, 11 months
(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, 11 months
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, 11 months
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, 11 months