openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(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

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