openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5173) Cannot add pcache to config
by hyc＠symas.com 08 Oct '07

08 Oct '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE23/RE24/HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > As reported by Ralf here > http://www.openldap.org/lists/openldap-devel/200709/msg00036.html > > Fixed in HEAD But the same problem also occurs with the translucent overlay... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5173) Cannot add pcache to config
by hyc＠OpenLDAP.org 08 Oct '07

08 Oct '07

Full_Name: Howard Chu Version: RE23/RE24/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc As reported by Ralf here http://www.openldap.org/lists/openldap-devel/200709/msg00036.html Fixed in HEAD

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> (Of course, if you only appended to /etc/hosts then the old address is still > in there and getting used first..) "files dns" in nsswitch.conf, and no prior /etc/hosts entry. i.e., this overrode DNS to the 192.168.* interface. netstat shows that (by now, at least) this has completely taken. > If this is happening even with slapd cleanly shut down then it should also > prevent slapd from restarting, since slapd first attempts to join an existing > environment before trying to create a new one. And that really implies that > the rest of the environment is shot. Agreed, but that's a pretty awful condition to have in a long-running slapd process. Without db_stat (easily) working, is there any hope at finding clues as to how this might have happened, or is it just time to rm/slapadd and hope it doesn't happen again?

1 0

Re: (ITS#4884) Back-config inheritance issue
by hyc＠symas.com 08 Oct '07

08 Oct '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD (re23,...) > OS: irrelevant > URL: > Submission from: (NULL) (87.28.220.33) > Submitted by: ando > > > I think I've spotted a potential issue in back-config. When creating a custom > object, say an overlay, the configuration objectClass should inherit from > olcOverlayConfig. While adding the object via LDAP, however, if the ancestor > class is not explicitly listed, the derived object must provide a co_ldadd() > hook, otherwise addition fails. > Currently, the code uses all defined objectClasses and stops the first time a > hook is available and it does not fail. That was of course the designed and desired behavior... > It would be more sound, IMHO, to have something like: > > - if the structural objectClass provides a co_ldadd() hook, use it; it is that > hook's responsibility to call the superior's one if required; > > - if it doesn't, then climb the inheritance tree and call co_ldadd() for the > first occurrence of a valid one. The point is that structural classes are not the only ones that matter here, and if you're creating an entry that has a special class, you must provide the necessary handlers for that class. Climbing the inheritance tree seems an ok convenience for entries that don't explicitly list all their superior classes, but that should not have precluded the existing behavior (checking all of the explicitly listed classes, whether they are structural or auxiliary). -- -- Howard Chu Chief Architect, 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#4884) Back-config inheritance issue
by hyc＠symas.com 08 Oct '07

08 Oct '07

ando(a)sys-net.it wrote: > I've committed to HEAD a fix that exploits inheritance. The rationale is: > > - lookup the structural objectClass; starting from it, check it and > subordinates for a function that successfully adds the entry > > - using all objectClass values, collect all, including ancestors, that > may be of use in checking configuration. > > Passes all tests (049->051), and allows to add an overlay using only the > overlay's objectClass, provided it's derived from olcOverlayConfig. > > Please test. p. Something's wrong here, it's only checking structural classes but not auxiliary classes. This breaks proxycache now, which uses an auxiliary class for the ldadd hook when adding its private DB. -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

Aaron Richton wrote: >> No. The BDB transaction log files don't know (or care) anything about IP >> addresses. Nothing at the slapd layer could have any direct effect on the BDB >> transaction logs. How exactly did you reconfigure the servers, did you stop >> them and restart them or did you use cn=config? > > echo 192.blahblah master.r.e >> /etc/hosts > > The master changed from 128.blahblah to 192.blahblah. Same physical > machine, just different interface. On slave4 and 6, I didn't touch slapd. (Of course, if you only appended to /etc/hosts then the old address is still in there and getting used first..) >> Might as well get the db_stat -l output for a few of them to compare. > > This isn't going well at all; they just can't join the environment. I > tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're > talking >30 minutes here.) Although I swear I've run db_stat hot, I killed > db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, > ran db_stat again, and it hung there...and corrupted the environment to > the point where I couldn't get db_recover/slapd to run. (I ended up > blowing the slave1 database away; it's refreshing from syncrepl now.) > I've got a few more slaves that I haven't shot in the foot yet, and I only > tried this on one of the suffixes on slave{1,4}. Plenty of more > opportunities to screw this up yet if there's anything to try...I suppose > I could go for -N, or if the command line is going to be a pain, I could > join the slapd process with dbx and print ->log_stat myself (although I > might need a bit of hand holding on that)... > > [the hang on slave4] > db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) > lwp_mutex_lock(0xFF0D0000) (sleeping...) > mutex type: USYNC_PROCESS > > ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 > ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 > ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 > 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 > 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 > 00011470 _start (0, 0, 0, 0, 0, 0) + 108 If this is happening even with slapd cleanly shut down then it should also prevent slapd from restarting, since slapd first attempts to join an existing environment before trying to create a new one. And that really implies that the rest of the environment is shot. -- -- Howard Chu Chief Architect, 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#5164) slapi plugins prevent slapd starting.
by hyc＠symas.com 08 Oct '07

08 Oct '07

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: 2.4.5beta > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.8.140) > > > This is mentioned in #4611 but marked as fixed there. Now fixed in HEAD. -- -- Howard Chu Chief Architect, 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#5172) slash in dn
by ando＠sys-net.it 07 Oct '07

07 Oct '07

reinhold.may(a)gmx.de wrote: > I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that > case: sorry. > > I've been trying to import the following .ldif: > > dn: dc=somedomain,dc=org > objectclass: top > objectclass: dcObject > objectclass: organization > o: somedomain LDAP > dc: somedomain > > dn: ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: My address book > > dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Medical > > dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: With/Slash > sn: With/Slash The above LDIF is inconsistent: the "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" entry is repeated, and in the first occurrence it is inconsistent: the distinguished value "With/Slash" is not present in the entry, there's a "Medical" instead. I suspect you messed things up when sanitizing your data. > > The "/" results into the following error message: > > ldap_add: No such object (32) > additional info: Parent does not exist This error means that the parent of the entry you're trying to add does not exist. Here "parent" means the entry immediately below the one you're trying to add, so assuming you're trying to add "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", what appears to be missing is "ou=My address book,dc=somedomain,dc=org". Are you sure it exists? By looking at the server's logs at "stats,trace" level, can you tell what DN is being looked up for the parent? > If my last entry reads: > > dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: WithoutSlash > sn: WithoutSlash > > slapd accepts the entry and adds it to its directory. > > I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to > be a special character. But just in case it was forgotten, I tried to represent > it as "\/" and "\2f" but neither solution helped. Yes, it's not. Using OpenLDAP 2.3 code, I can correctly parse the DN you suspect to trigger the unexpected behavior you reported: $ slapdn 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> $ ./libraries/libldap/dntest 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' ldap_rdn2str() = "cn=With/Slash" ldap_rdn2str() = "ou=My address book" ldap_rdn2str() = "dc=somedomain" ldap_rdn2str() = "dc=org" ldap_dn2str(ldap_str2dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org")) = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2domain("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org" ldap_dn2ufn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "With/Slash, My address book, somedomain.org" ldap_dn2dcedn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash" ldap_dcedn2dn("/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash") = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2ad_canonical("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org/My address book/With\/Slash" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org"): "cn=With/Slash" ldap_explode_rdn("cn=With/Slash") 'cn=With/Slash' ldap_explode_rdn("cn=With/Slash") (no types) "With/Slash" "ou=My address book" ldap_explode_rdn("ou=My address book") 'ou=My address book' ldap_explode_rdn("ou=My address book") (no types) "My address book" "dc=somedomain" ldap_explode_rdn("dc=somedomain") 'dc=somedomain' ldap_explode_rdn("dc=somedomain") (no types) "somedomain" "dc=org" ldap_explode_rdn("dc=org") 'dc=org' ldap_explode_rdn("dc=org") (no types) "org" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") (no types): "With/Slash" "My address book" "somedomain" "org" "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" == "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ? yes 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5172) slash in dn
by reinhold.may＠gmx.de 07 Oct '07

07 Oct '07

Full_Name: Reinhold May Version: 2.3.35 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.216.115.71) I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that case: sorry. I've been trying to import the following .ldif: dn: dc=somedomain,dc=org objectclass: top objectclass: dcObject objectclass: organization o: somedomain LDAP dc: somedomain dn: ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: My address book dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: organizationalUnit ou: Medical dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: With/Slash sn: With/Slash The "/" results into the following error message: ldap_add: No such object (32) additional info: Parent does not exist If my last entry reads: dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha cn: WithoutSlash sn: WithoutSlash slapd accepts the entry and adds it to its directory. I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to be a special character. But just in case it was forgotten, I tried to represent it as "\/" and "\2f" but neither solution helped.

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 07 Oct '07

07 Oct '07

> No. The BDB transaction log files don't know (or care) anything about IP > addresses. Nothing at the slapd layer could have any direct effect on the BDB > transaction logs. How exactly did you reconfigure the servers, did you stop > them and restart them or did you use cn=config? echo 192.blahblah master.r.e >> /etc/hosts The master changed from 128.blahblah to 192.blahblah. Same physical machine, just different interface. On slave4 and 6, I didn't touch slapd. > Might as well get the db_stat -l output for a few of them to compare. This isn't going well at all; they just can't join the environment. I tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're talking >30 minutes here.) Although I swear I've run db_stat hot, I killed db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, ran db_stat again, and it hung there...and corrupted the environment to the point where I couldn't get db_recover/slapd to run. (I ended up blowing the slave1 database away; it's refreshing from syncrepl now.) I've got a few more slaves that I haven't shot in the foot yet, and I only tried this on one of the suffixes on slave{1,4}. Plenty of more opportunities to screw this up yet if there's anything to try...I suppose I could go for -N, or if the command line is going to be a pain, I could join the slapd process with dbx and print ->log_stat myself (although I might need a bit of hand holding on that)... [the hang on slave4] db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) lwp_mutex_lock(0xFF0D0000) (sleeping...) mutex type: USYNC_PROCESS ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 00011470 _start (0, 0, 0, 0, 0, 0) + 108

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