Re: (ITS#5795) Modification of cn=config prevents to bind at next directory restart
by hyc＠symas.com
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)
>
>
> I have set a rootdn on cn=config which is a real entry
> (cn=admin,ou=somewhere,o=myorg,c=fr).
> I bind with this DN.
> I perform a change on cn=config (change the log level).
> At next slapd startup, I get:
> PROXIED attributeDescription "OU" inserted.
> PROXIED attributeDescription "O" inserted.
> PROXIED attributeDescription "C" inserted.
> and then when trying to bind, I get an invalid credentials error (49).
> The problem seems to come from modifiersname in cn=config entry, because if I
> delete this attribute and restarts slapd, all is fine.
Ah, thanks for this. You're seeing the same as #5783, but you've provided much
more useful information 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/
14 years, 10 months
(ITS#5795) Modification of cn=config prevents to bind at next directory restart
by emmanuel.duru＠atosorigin.com
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 set a rootdn on cn=config which is a real entry
(cn=admin,ou=somewhere,o=myorg,c=fr).
I bind with this DN.
I perform a change on cn=config (change the log level).
At next slapd startup, I get:
PROXIED attributeDescription "OU" inserted.
PROXIED attributeDescription "O" inserted.
PROXIED attributeDescription "C" inserted.
and then when trying to bind, I get an invalid credentials error (49).
The problem seems to come from modifiersname in cn=config entry, because if I
delete this attribute and restarts slapd, all is fine.
14 years, 10 months
(ITS#5794) Password exop unwilling to verify old password
by aja＠nlgroup.ca
Full_Name: Arthur Anhalt
Version: 2.4.12
OS: Ubuntu 8.04
URL:
Submission from: (NULL) (205.200.169.138)
When parsing password change extended operations,
servers/slapd/passwd.c:slap_passwd_parse() calls ber_get_stringbv() with
LBER_BV_NOTERM set. The resulting bv_val doesn't end with a \0.
In libraries/liblutil/passwd.c:chk_crypt will return an error is the old and
new
passwords do not end with a null terminator. I believe more of the chk_*
functions
return the same error.
This is the same bug as ITS#5575, but affects the core system, not contributed
code.
14 years, 10 months
(ITS#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
Current draft-zeilenga-ldap-relax requires the DSA to modify the
structuralObjectClass attribute of an entry based on modifications of the
structural objectClass of that entry. Slapd doesn't implement this; in order to
obtain the desired effect, one needs to explicitly modify the
structuralObjectClass attribute accordingly. This is explicitly forbidden by
draft-zeilenga-ldap-relax.
p.
14 years, 10 months
Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it
Maykel Moya wrote:
> El mar, 04-11-2008 a las 20:20 +0100, Pierangelo Masarati escribió:
>
>> This does not look like a db corruption. It looks like you restarted
>> slapd with back-config in a compromised state, since it is now missing
>> the definition of "dc", which is in core.schema. You don't specify how
>> you edited cn=config; did you manually edited the corresponding ldif
>> files? You're supposed to modify them only via operations using the
>> LDAP protocol while the server is running.
>
> Well, maybe a better title would be: possible cn=config backend
> corruption, to make a diference with classic DB usage to refer to
> HDB/BDB backends.
>
> I added olcTLS* fields via normal ldap operations, not by manually
> editing text files inside /etc/ldap/slapd.d. Specifically I used a
> frontend called luma, which is built around python-ldap.
OK. Is the issue reproducible? Can you provide a simple initial
slapd.conf and an LDIF containing the modifications that triggered the
issue, along with a clear sequence of steps required to reproduce it?
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, 10 months
Re: (ITS#5783) Possible DB corruption
by moya＠latertulia.org
El mar, 04-11-2008 a las 20:20 +0100, Pierangelo Masarati escribió:
> This does not look like a db corruption. It looks like you restarted
> slapd with back-config in a compromised state, since it is now missing
> the definition of "dc", which is in core.schema. You don't specify how
> you edited cn=config; did you manually edited the corresponding ldif
> files? You're supposed to modify them only via operations using the
> LDAP protocol while the server is running.
Well, maybe a better title would be: possible cn=config backend
corruption, to make a diference with classic DB usage to refer to
HDB/BDB backends.
I added olcTLS* fields via normal ldap operations, not by manually
editing text files inside /etc/ldap/slapd.d. Specifically I used a
frontend called luma, which is built around python-ldap.
Cheers,
maykel
14 years, 10 months
Re: (ITS#5764) addpartial patch
by dhawes＠vt.edu
dhawes(a)vt.edu wrote:
> Pierangelo Masarati wrote:
>> dhawes(a)vt.edu wrote:
>>> 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.
>> You should probably use overlay_entry_get_ov() rather than
>> be_entry_get_rw() from inside an overlay (AFAIR).
>
> Okay, I'll make that change, thanks.
>
> I notice that most overlays seem to use be_entry_get_rw(), and one
> (translucent) uses both. What is the reasoning to use one over the other?
New patch that uses overlay_entry_get_ov() available at:
ftp://ftp.openldap.org/incoming/david-hawes-081104.patch
The patch referenced previously can be discarded. This patch contains
all changes against 2.4.12.
14 years, 10 months
Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it
moya(a)latertulia.org wrote:
> Full_Name: Maykel Moya
> Version: 2.4.11
> OS: Debian Lenny
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (200.55.135.211)
>
>
> It's second time that I have bitten by this:
>
> Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted.
>
> After that I'm unable to bind against the DSA. The problem has arise in two
> independent systems.
>
> Steps to reproduce:
>
> 1. Create a minor db (like Debian does), a dc=foo,dc=org node and a
> cn=admin,rootdn node
> 2. Migrate to cn=config
> 3. Edit cn=config
> I've added olcTLSCACertificateFile / olcTLSCertificateFile /
> olcTLSCertificateKeyFiel attributes
> 4. Restart the server
>
> After restarting I see the PROXIED error. I'd wrote to the list before [1][2]
> but the same thing has come in another system.
This does not look like a db corruption. It looks like you restarted
slapd with back-config in a compromised state, since it is now missing
the definition of "dc", which is in core.schema. You don't specify how
you edited cn=config; did you manually edited the corresponding ldif
files? You're supposed to modify them only via operations using the
LDAP protocol while the server is running.
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, 10 months
