- openldap-bugs - openldap.org

ITS 5709
by Burton, Kris - Acision 11 Nov '08

11 Nov '08

All, I apologize if this is sent twice, I noticed I copied the wrong address in the first email sent by accident to openldap-its(a)openldap.org<mailto:openldap-its@openldap.org>. I am currently experiencing the problem that is detailed in ITS 5709. I am running OpenLDAP 2.4.11, from the information in ITS5709 it appears that this problem is resolved in HEAD. What I would like to do is to isolate the code that resolves this problem and put them in the 2.4.11 version of OpenLDAP that I am running. I have been trying to determine exactly what changes were added to resolve the issue. I also wanted to ask if doing this would be a viable solution until the time that another OpenLDAP version is released that resolves this issue. I am not familiar with the code base and would not want to introduce one change to try to resolve this issue and open up several new issues. Can someone familiar with the fix point me in the right direction as to whether the fix that resolves this is isolated and would be safe to back port to an older release (2.4.11), and if so how would I identify exactly what needs to be changed? Also if someone could inform me if the above ITS would be included in part of 2.4.13 and is there any projected date for when 2.4.13 would be released. Kris Burton Software Engineer ________________________________________ Acision. Innovation. Assured. www.acision.com 4870 Sadler Road Suite 200 Glen Allen, VA 23060 USA This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 11 Nov '08

11 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. ok, this looks like it... Nov 11 17:01:38 nops slapd[24733]: backsql_dn2id("dc=sql,dc=example,dc=com") : error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?", "dc=sql,dc=example,dc=com"): Nov 11 17:01:38 nops slapd[24733]: Return code: -1 Nov 11 17:01:38 nops slapd[24733]: nativeErrCode=2006 SQLengineState=08S01 msg="[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.67-log]MySQL server has gone away" Nov 11 17:01:38 nops slapd[24733]: <==backsql_dn2id("dc=sql,dc=example,dc=com") : err=80 if you'd like a tarball of full logs + config just say. Regards, Rob

1 0

(ITS#5803) Incorrect filters (e.g. substrings) may trigger "disconnect"
by ando＠sys-net.it 11 Nov '08

11 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 When a malformed filter is encountered, ber decoding may stop before the specific element has been parsed. This results in a decoding error later, that triggers a "disconnect" response. To reproduce: search with "(objectClass=foo*bar)". The correct behavior would consist in parsing the whole filter anyway and identify it as COMPUTED UNDEFINED. p.

1 0

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 11 Nov '08

11 Nov '08

Robert Brooks wrote: > Pierangelo Masarati wrote: >> I have no possibility to setup a back-sql with mysql right now. Can >> you post your configuration? Can you post some (verbose) logs of >> operations affecting back-sql (e.g. with BACKSQL_TRACE manually >> #defined in back-sql/back-sql.h)? Can you step thru a search into >> backsql_search() and see if it gets called and why it doesn't get to >> contacting the rdbms? > > I'm compiling with BACKSQL_TRACE defined right now. > > After further prodding I have discovered... > > ejabberd (a jabber daemon) makes connections to ldap, which it keeps > open indefinitely. It appears mysql's odbc connector will time out an > idle mysql connection after 8 hours. Since this is the slave system it's > entirely possible for it not touch mysql connections for at least 8 hours. > > If we restart mysql some ldap queries fail on back-sql portion until we > kill ejabberd (to close it's ldap connections). > > I'll give you logs with tracing enabled asap, but this looks like a big > clue as to what is happening. OK, this makes sense. In fact, back-sql does not seem to specifically handle broken connections to the odbc. It appears it would need something similar to idle-timeout as in back-ldap and back-meta. 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#5796) back-sql intermittently failing
by robb＠wtg.cw.com 11 Nov '08

11 Nov '08

Pierangelo Masarati wrote: > I have no possibility to setup a back-sql with mysql right now. Can you > post your configuration? Can you post some (verbose) logs of operations > affecting back-sql (e.g. with BACKSQL_TRACE manually #defined in > back-sql/back-sql.h)? Can you step thru a search into backsql_search() > and see if it gets called and why it doesn't get to contacting the rdbms? I'm compiling with BACKSQL_TRACE defined right now. After further prodding I have discovered... ejabberd (a jabber daemon) makes connections to ldap, which it keeps open indefinitely. It appears mysql's odbc connector will time out an idle mysql connection after 8 hours. Since this is the slave system it's entirely possible for it not touch mysql connections for at least 8 hours. If we restart mysql some ldap queries fail on back-sql portion until we kill ejabberd (to close it's ldap connections). I'll give you logs with tracing enabled asap, but this looks like a big clue as to what is happening.

1 0

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 11 Nov '08

11 Nov '08

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2 > OS: 2.4.12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.49.19.14) > > > Set up is a pair of centos 4 hosts, one acts as primary, the other is a syncrepl > consumer and mysql slave. Apart from syncrepl config/myqsl slave all config and > software versions are the same. Mysql queries on both hosts are to localhost via > socket. > > After a period of operation (24-48 hours) the slave host drops the back-sql part > of directory for some queries (same query will suceed some times). Using strace > it can been seen that the ldap searches are not resulting in queries to mysql. > Back-sql is a subordinate db and results from hdb backed part of directory are > returned. > > Restarting slapd fixes the problem, but start-up reports the shutdown was > unclean on hdb db. Operation of primary is reliable. I have no possibility to setup a back-sql with mysql right now. Can you post your configuration? Can you post some (verbose) logs of operations affecting back-sql (e.g. with BACKSQL_TRACE manually #defined in back-sql/back-sql.h)? Can you step thru a search into backsql_search() and see if it gets called and why it doesn't get to contacting the rdbms? 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

[Fwd: ITS#4556 ACLs for new entries]
by hyc＠symas.com 11 Nov '08

11 Nov '08

For completeness' sake... ACL checking for Added entries is available in RE24/HEAD. See the add_content_acl / olcAddContentAcl setting in slapd.conf/slapd.d. The default for most DBs is off, for backward compatibility. It is ON by default for cn=config. -------- Original Message -------- Subject: ITS#4556 ACLs for new entries Date: Fri, 21 Sep 2007 09:00:37 -0700 From: Howard Chu <hyc(a)symas.com> To: OpenLDAP Devel <openldap-devel(a)openldap.org> Revisiting this topic - DITStructureRules are not a solution to this problem. E.g. in cn=config, now that you can grant write access to arbitrary users, it becomes pretty critical to be able to prevent certain users from creating certain types of objects. E.g., I may want to allow someone to be able to create one type of child object under cn=config (e.g., databases) but not some other type (e.g., modules). So at the very least we need to be able to use ACL filters on new entries. -- -- 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#5796)
by robb＠webtechnologygroup.co.uk 11 Nov '08

11 Nov '08

can re-create this problem by restarting mysql. Following a restart about one in five queries fails on back-sql portion of directory.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by quanah＠zimbra.com 11 Nov '08

11 Nov '08

--On Tuesday, November 11, 2008 3:52 AM +0000 abartlet(a)samba.org wrote: > > --=-nSmbtQnR20QHrM5OsFp5 > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > I just wanted to say thankyou very much for doing this. The Samba side > of things has taken far longer than I ever imagined, but I hope to look > at the OpenLDAP integration this or next week. It was added to RE24 today, for inclusion in 2.4.13, so getting feedback would be great. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Nov '08

11 Nov '08

--=-nSmbtQnR20QHrM5OsFp5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > A tentative implementation is in HEAD, please test. You need to: I just wanted to say thankyou very much for doing this. The Samba side of things has taken far longer than I ever imagined, but I hope to look at the OpenLDAP integration this or next week. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-nSmbtQnR20QHrM5OsFp5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJGQF+z4A8Wyi0NrsRAnpXAJ9c4Lx4uVyadLTvaTaAm7rvTWKC+QCgrK9p Vhadna7DXcJs0h11JPmkg8c= =HgJ+ -----END PGP SIGNATURE----- --=-nSmbtQnR20QHrM5OsFp5--

1 0

Re: (ITS#5797) build failed
by hyc＠symas.com 10 Nov '08

10 Nov '08

cycwj(a)163.com wrote: > Full_Name: bluewind > Version: 2.4.12 > OS: ubunt server 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (219.133.134.8) > > > try to build on ubutnu server 8, use install manaul from www.openldap.org > > #./configure (ok) > #make depen (ok) > #make (ok) > > but,when execution > > #make test > > the system stop on "Running slapadd to build slapd database...", no any > response > > after about 1 hour I think what Ando was trying to say very subtly is that your bug report does not contain much useful information, and you should have searched the ITS for similar issues before posting. This is a known bug in BerkeleyDB 4.7.25. We have to guess that this is the version of BDB that you're using because you didn't provide this info in your report. ITS#5707 already contains the details of this bug and the official patch from Oracle. The patch is also present in the OpenLDAP CVS. This ITS will be closed. -- -- 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#5799) smbk5pwd update to work with heimdal 1.2 API
by hyc＠symas.com 10 Nov '08

10 Nov '08

admin(a)dmarkey.com wrote: > Full_Name: David Markey > Version: 2.4 > OS: Solaris/AIX/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.97.241.103) > > > Update smbk5pwd to work with the heimdal 1.2 API. Work has been done on the > mailing list but the patches have not been applied to the release. I don't see any patches in your report. Patches that are to be considered for inclusion into the codebase must be submitted to the ITS by their authors, with any Rights statement as needed. -- -- 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#5796)
by robb＠webtechnologygroup.co.uk 10 Nov '08

10 Nov '08

strace from failing slapd process 13637 send(3, "<167>Nov 5 10:34:39 slapd[13628"..., 117, MSG_NOSIGNAL) = 117 13637 semop(22052874, 0xb53ad7d0, 2) = 0 13637 semop(22052874, 0xb53ad7e0, 1) = 0 13637 time(NULL) = 1225881279 13637 semop(22052874, 0xb53ad750, 2) = 0 13637 semop(22052874, 0xb53ad760, 1) = 0 13637 write(57, "\27\3\1\0 \334@\'\353]R\251-Q\251Dd>0\376&\227\326\4\222dU\t\266/\356\177"..., 90) = 90 13637 time(NULL) = 1225881279 13637 stat64("/etc/localtime", {st_dev=makedev(3, 3), st_ino=1032239, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size= 1323, st_atime=2008/11/05-10:31:17, st_mtime=2007/08/09-19:54:26, st_ctime=2007/08/09-19:54:26}) = 0 13637 stat64("/etc/localtime", {st_dev=makedev(3, 3), st_ino=1032239, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size= 1323, st_atime=2008/11/05-10:31:17, st_mtime=2007/08/09-19:54:26, st_ctime=2007/08/09-19:54:26}) = 0 13637 stat64("/etc/localtime", {st_dev=makedev(3, 3), st_ino=1032239, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size= 1323, st_atime=2008/11/05-10:31:17, st_mtime=2007/08/09-19:54:26, st_ctime=2007/08/09-19:54:26}) = 0 13637 send(3, "<167>Nov 5 10:34:39 slapd[13628"..., 76, MSG_NOSIGNAL) = 76 looks like it connect to mysql but never queries it. any way I can capture something useful with gdb?

1 0

(ITS#5802) nssov_uid2dn using wrong LDAP filter
by ralf＠OpenLDAP.org 10 Nov '08

10 Nov '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.136.132) Submitted by: ralf The uid2dn function to resolve a username into a DN uses filters of the form "(&(objectclass=posixAccount)(uidNumber=<username>))" in it's query. The correct filter would be: "(&(objectclass=posixAccount)(uid=<username>))" Fix will appear in CVS soon.

1 0

(ITS#5801) "nssov-map" directive cause slapd to crash on startup
by ralf＠OpenLDAP.org 10 Nov '08

10 Nov '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.136.132) Submitted by: ralf Adding the line: nssov-map group uniquemember member To the nssov configuration in /etc/openldap/slapd.conf cause slapd to crash on startup. I'll commit a fix to HEAD shortly.

1 0

(ITS#5800) nssov overlay crashing on empty groups
by ralf＠OpenLDAP.org 10 Nov '08

10 Nov '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.136.132) Submitted by: ralf Calling "getent group" causes the nssov-overlay to crash, when there are "posixGroups" without members. A fix is coming.

1 0

(ITS#5799) smbk5pwd update to work with heimdal 1.2 API
by admin＠dmarkey.com 10 Nov '08

10 Nov '08

Full_Name: David Markey Version: 2.4 OS: Solaris/AIX/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.97.241.103) Update smbk5pwd to work with the heimdal 1.2 API. Work has been done on the mailing list but the patches have not been applied to the release.

1 0

Missing module PPolicy with openldap on CentOS5.0!
by Nguyen Quang Huy 10 Nov '08

10 Nov '08

Dear all! I'm setup openldap + CentOS 5.0 (I'm setup by YUM). I'm setup and configure test LDAP --> Ok, but I can't configure password policies for Openldap beacause openldap missing ppolicy module. I'm searching with google this error, but I can't append module ppolicy. Please help me!! Thanks.

3 2

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> IMO defaulting schemacheck off for replication is fine because >> replicated entries will have been checked on the master. > > What if two simulaneous, valid changes to the same entry on two masters > produce a schema error when combined? I haven't been tracking MMR - > does the entry end up with a schema error, or does MMR consider two > changes to the same entry a conflict and fail to replicate, or...? AFAIK, the last entryCSN should win. Something like: MM1 MM2 time 0 csn0 csn0 (same) time 1 csn0+1 -> - time 2 - <- csn0+2 time 3 csn0+1,csn0+2 csn0+2,csn0+1 (one wins, I assume the latest) At all times, each entry is sane. The one that wins is sane, the one that loses will be replaced by the one that wins. The reason for this ITS and other stuff that will come shortly is that I've been asked to audit MMR, by designing a suite of tests that check functionality and reliability of MMR under possibly reproducible conflict, concurrency and other critical conditions. I'm highlighting a series of issues. I won't post ITSes or other notices until I find out whether it's slapd's or my tests' fault. 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#5798) MMR/mirror mode circumvents schema check
by h.b.furuseth＠usit.uio.no 08 Nov '08

08 Nov '08

hyc(a)symas.com writes: > IMO defaulting schemacheck off for replication is fine because > replicated entries will have been checked on the master. What if two simulaneous, valid changes to the same entry on two masters produce a schema error when combined? I haven't been tracking MMR - does the entry end up with a schema error, or does MMR consider two changes to the same entry a conflict and fail to replicate, or...? -- Hallvard

1 0

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by hyc＠symas.com 08 Nov '08

08 Nov '08

Howard Chu wrote: > All we have to do is change the code from setting the DB flag to using the > per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication > is fine because replicated entries will have been checked on the master. Of course, it was already using the per-op flag too. Probably meant to remove the per-DB flag and forgot to some time ago. Fixed now 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/

1 0

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by hyc＠symas.com 08 Nov '08

08 Nov '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> When syncrepl is configured, schema checking is switched off. As a consequence, >> schema checking does not occur for all writes, including direct writes from >> clients when MMR/MM is in use. >> >> Internal writes performed by syncrepl should be marked as such, in order to >> disable schema checking only when appropriate. > > It all seems to boil down to the fact that syncrepl schemachecking is > off by default. So, not specifying any results in having multimasters > with schemachecking disabled, which is not desirable. I recommend > schema checking be on by default. All we have to do is change the code from setting the DB flag to using the per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication is fine because replicated entries will have been checked on the master. -- -- 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#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (82.63.140.131) >>> Submitted by: ando >>> >>> >>> When syncrepl is configured, schema checking is switched off. As a >>> consequence, >>> schema checking does not occur for all writes, including direct >>> writes from >>> clients when MMR/MM is in use. >>> >>> Internal writes performed by syncrepl should be marked as such, in >>> order to >>> disable schema checking only when appropriate. >> >> It all seems to boil down to the fact that syncrepl schemachecking is >> off by default. So, not specifying any results in having multimasters >> with schemachecking disabled, which is not desirable. I recommend >> schema checking be on by default. > > All we have to do is change the code from setting the DB flag to using > the per-op o_no_schema_check flag. IMO defaulting schemacheck off for > replication is fine because replicated entries will have been checked on > the master. Well, it used to be so, but now with MMR (and mirror mode) it's no longer so. Using the per-op is fine, as long as the caller consistently sets 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#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > When syncrepl is configured, schema checking is switched off. As a consequence, > schema checking does not occur for all writes, including direct writes from > clients when MMR/MM is in use. > > Internal writes performed by syncrepl should be marked as such, in order to > disable schema checking only when appropriate. It all seems to boil down to the fact that syncrepl schemachecking is off by default. So, not specifying any results in having multimasters with schemachecking disabled, which is not desirable. I recommend schema checking be on by default. 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

(ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When syncrepl is configured, schema checking is switched off. As a consequence, schema checking does not occur for all writes, including direct writes from clients when MMR/MM is in use. Internal writes performed by syncrepl should be marked as such, in order to disable schema checking only when appropriate. p.

1 0

Re: (ITS#5797) build failed
by ando＠sys-net.it 08 Nov '08

08 Nov '08

cycwj(a)163.com wrote: > Full_Name: bluewind > Version: 2.4.12 > OS: ubunt server 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (219.133.134.8) > > > try to build on ubutnu server 8, use install manaul from www.openldap.org > > #./configure (ok) > #make depen (ok) > #make (ok) > > but,when execution > > #make test > > the system stop on "Running slapadd to build slapd database...", no any > response > > after about 1 hour Thanks for the detailed report. Did you read <http://www.openldap.org/faq/data/cache/56.html>, significantly <http://www.openldap.org/faq/data/cache/58.html>, <http://www.openldap.org/faq/data/cache/59.html> and <http://www.openldap.org/faq/data/cache/1122.html>? 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

(ITS#5797) build failed
by cycwj＠163.com 07 Nov '08

07 Nov '08

Full_Name: bluewind Version: 2.4.12 OS: ubunt server 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.133.134.8) try to build on ubutnu server 8, use install manaul from www.openldap.org #./configure (ok) #make depen (ok) #make (ok) but,when execution #make test the system stop on "Running slapadd to build slapd database...", no any response after about 1 hour

1 0

Re: (ITS#5773) bi_entry_get_rw() and overlays issue
by hyc＠symas.com 07 Nov '08

07 Nov '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> I think bi_entry_get_rw() needs work. >> Or maybe phase it out in favor of some other call? >> >>> In fact, as also discussed in ITS#5628, callers either return the >>> entry or have no means to modify the arguments of the request. >> It has more troubles than that. See e.g. the notes about passing rw=1 >> (write) to it here: >> http://www.openldap.org/lists/openldap-devel/200803/msg00055.html >> And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which >> says to pass an rw=1 argument to bi_entry_release_rw(). > > Well, I see many places where an entry needs to be fetched. Typically, > it needs to be done read-only. In fact, the rw flag makes no sense. You can only fetch an entry ro; if you actually fetched it for write access and modified the entry, there's no API to commit the changed entry to stable storage. You would only be making a transient change to a cached copy (which could disappear as soon as you release the entry). So if we're going to change this API, the first thing to do is get rid of the rw flag. You must use be_modify if you want to change anything about an entry... > So the difference between > bi_entry_get_ro() and an internal search is that if we are fine with the > entry in-cache, we save lots of manipulation. However this might no > longer suffice when overlays muck with the entry (like slapo-rwm). > Moreover, when overlays are present, I see the need to: > 1) run it like it came from outside, going thru all the overlays That's what overlays currently do when they do the bd_info swap and then call be_entry_get_rw(). > 2) go straight to the underlying database That's done by calling bd_info->bi_entry_get_rw()... > 3) go thru overlays starting at some point (e.g. when called from inside > an overlay under the assumption the entry is fetched as that overlay > would see it, so with only any possible mucking from overlays layered > deeper than the caller). That's what overlay_entry_get_ov() does. Also note that passing a NULL overinst here accomplishes (2). > This probably needs to modify the way > callbacks are actually called, allowing some "after self" feature in > playing not just the overlay list, but also the response (and the cleanup). Then we need an "opcode" for this, so that response / cleanup handlers know why they're being invoked. -- -- 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#5796) back-sql intermittently failing
by robb＠wtg.cw.com 06 Nov '08

06 Nov '08

Full_Name: Robert Brooks Version: 2 OS: 2.4.12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) Set up is a pair of centos 4 hosts, one acts as primary, the other is a syncrepl consumer and mysql slave. Apart from syncrepl config/myqsl slave all config and software versions are the same. Mysql queries on both hosts are to localhost via socket. After a period of operation (24-48 hours) the slave host drops the back-sql part of directory for some queries (same query will suceed some times). Using strace it can been seen that the ldap searches are not resulting in queries to mysql. Back-sql is a subordinate db and results from hdb backed part of directory are returned. Restarting slapd fixes the problem, but start-up reports the shutdown was unclean on hdb db. Operation of primary is reliable.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 06 Nov '08

06 Nov '08

ali.pouya(a)free.fr wrote: > Howard Chu wrote : > >> I see. >> >> This has been fixed for back-bdb/hdb in HEAD. If the database was shut down >> cleanly before, there will be no scan on the next startup. > > Hi Howard, > Thanks for the corrections. > We tested the HEAD extracted on monday november 3. Unfortunately the problem > explained in point 2 persists (even after a clean shutdown). > Our directory contains 10 million entries. It can evolve to 40 million entries > next year. > The local sacanning speed is around 250 000 entries per minute. > So the scan of the recent objects on the standby mirror after startup can take > several minutes (unless if we distribute the write operations on both mirrors). I don't see this happening on my builds. Maybe you should post your configs and a sample of the data and modifications used to illustrate the problem. -- -- 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#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 Nov '08

Maykel Moya wrote: > El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > >> 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. >> This is now fixed in HEAD. > > Oh, thanks. Is there a way I can get the patch for applying it to my > system? See the diff here http://www.openldap.org/lists/openldap-commit/200811/msg00034.html -- -- 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#5794) Password exop unwilling to verify old password
by hyc＠symas.com 06 Nov '08

06 Nov '08

aja(a)nlgroup.ca wrote: > 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. Fixed in HEAD, thanks. -- -- 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#5783) Possible DB corruption
by moya＠latertulia.org 06 Nov '08

06 Nov '08

El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > 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. > > This is now fixed in HEAD. Oh, thanks. Is there a way I can get the patch for applying it to my system? Regards, maykel

1 0

Re: (ITS#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 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. This is now fixed 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/

1 0

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

06 Nov '08

hyc(a)symas.com wrote: > 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. > Now fixed 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/

1 0

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 05 Nov '08

05 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

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 04 Nov '08

04 Nov '08

Howard Chu wrote : >I see. > >This has been fixed for back-bdb/hdb in HEAD. If the database was shut down >cleanly before, there will be no scan on the next startup. Hi Howard, Thanks for the corrections. We tested the HEAD extracted on monday november 3. Unfortunately the problem explained in point 2 persists (even after a clean shutdown). Our directory contains 10 million entries. It can evolve to 40 million entries next year. The local sacanning speed is around 250 000 entries per minute. So the scan of the recent objects on the standby mirror after startup can take several minutes (unless if we distribute the write operations on both mirrors). Best Regards Ali

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 04 Nov '08

04 Nov '08

We tested the HEAD version extracted november 4th : the problem is fixed. The ITS can be closed. thank you for your help ! Best regards Sylvain Thomas

1 0

Re: (ITS#5789) using IP address in CN with GnuTLS
by hyc＠symas.com 04 Nov '08

04 Nov '08

leva(a)ecentrum.hu wrote: > Full_Name: LÉVAI Dániel > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.131.56.68) > > > I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. > The GnuTLS version is 2.4.2. > > So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? > > And please allow me include some additional information, which was told me by > Philip Guenther on openldap-software@: > "It appears the routine used with GNUtls > refuses to match IP addresses against a CN subjects component, thus > explaining that weird message. > > (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname > doesn't look like an IPv6 or IPv4 address, while the subject CN test needs > 'len1' to be the same as the length of the CN value.)" Thanks for the report, now fixed in HEAD. Note that using an IP address in the CN is not the way you're supposed to generate certs; IP addresses belong in the subjectAltName extension. The CN is only supposed to contain a fully qualified domain name. -- -- 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#5791) searches with entryDN in the filter scan the whole db
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) (131.175.154.146) Submitted by: ando Filtering for entryDN equality requires scanning the whole DB, although dn's are indexed in dn2id. See also ITS#5790

1 0

(ITS#5790) Indexing for entryDN results in no entry found
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) (131.175.154.146) Submitted by: ando If an explicit equality index is set for entryDN, searches with entryDN in the filter find no entries.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs