openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

Re: (ITS#5795) Modification of cn=config prevents to bind at next directory restart
by hyc＠symas.com 06 Nov '08

06 Nov '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) > > > 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/

1 0

(ITS#5795) Modification of cn=config prevents to bind at next directory restart
by emmanuel.duru＠atosorigin.com 06 Nov '08

06 Nov '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 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.

1 0

(ITS#5794) Password exop unwilling to verify old password
by aja＠nlgroup.ca 05 Nov '08

05 Nov '08

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.

1 0

(ITS#5793) RFE for flexible logging at 256/stats level
by ghenry＠OpenLDAP.org 05 Nov '08

05 Nov '08

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry Hi all, Just a quick note to say it would be nice to be able to break out loglevel 256 i.e. Log just writes. The same as accesslog config. Thanks, Gavin.

1 0

(ITS#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 04 Nov '08

04 Nov '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 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.

1 0

Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it 04 Nov '08

04 Nov '08

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

1 0

Re: (ITS#5783) Possible DB corruption
by moya＠latertulia.org 04 Nov '08

04 Nov '08

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

1 0

Re: (ITS#5764) addpartial patch
by hyc＠symas.com 04 Nov '08

04 Nov '08

dhawes(a)vt.edu wrote: > The patch referenced previously can be discarded. This patch contains > all changes against 2.4.12. I suspect HEAD and 2.4.12 are identical here so it's no big deal this time, but remember for future reference, http://www.openldap.org/devel/contributing.html all contributions must be relative to 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

Re: (ITS#5764) addpartial patch
by dhawes＠vt.edu 04 Nov '08

04 Nov '08

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.

1 0

Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it 04 Nov '08

04 Nov '08

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

1 0

← Newer
1
...
18
19
20
21
22
23
24
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008