openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

(ITS#6064) syncrepl.c does not compile ("//" comment)
by h.b.furuseth＠usit.uio.no 16 Apr '09

16 Apr '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard C89 chokes on this comment from syncrepl.c 1.445: // add new syncrepl to end of list (same order as when deleting) Fixing.

1 0

Re: (ITS#6063) Syncrepl replication be_modify failed (18)
by michael＠stroeder.com 16 Apr '09

16 Apr '09

wan(a)ccs.neu.edu wrote: > I've been battling some issues with syncrepl for a while now, and I > can't quite figure out what has gone wrong. > [..] > and am still having issues (now at > 2.4.15) Could you please try 2.4.16 released a couple of days ago? There were four syncrepl-related fixes in this release. Not sure whether one of the fixes really solves your particular problem but please give it a try. Maybe it would also help if you try to get more detailed logs by starting slapd with -d on the console. (You might also need to use -u and/or -g option to use the demon user.) Ciao, Michael.

1 0

Re: (ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by quanah＠zimbra.com 15 Apr '09

15 Apr '09

--On Wednesday, April 15, 2009 5:52 PM +0000 rps2(a)socal.rr.com wrote: > Full_Name: Rick Stevens > Version: 2.4.16 > OS: Fedora 10, x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.200.106.34) > > > Compilation fails when compiling the libraries/liblutil/getpeereid.c > file. Under Fedora 10, one must include the line: > > #define _GNU_SOURCE > > somewhere near the top of the file to ensure the system can pick up the > size of the "ucred" structure. This is a duplicate of ITS#5464 and will be closed. The fix will be in the next release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6063) Syncrepl replication be_modify failed (18)
by wan＠ccs.neu.edu 15 Apr '09

15 Apr '09

Full_Name: Will Nowak Version: 2.4.15 OS: Ubuntu Hardy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.239.45.4) [Creating an ITS issue of the email thread with the same subject] I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong. I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listi… The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container: dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow) An incoming add for user james looks like dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow) Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves. Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed

1 0

(ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) Compilation fails when compiling the libraries/liblutil/getpeereid.c file. Under Fedora 10, one must include the line: #define _GNU_SOURCE somewhere near the top of the file to ensure the system can pick up the size of the "ucred" structure.

1 0

(ITS#6061) ./configure messups on NDB and Perl backends
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) The help text in the configure script for OpenLDAP 2.4.16 states: --enable-ndb enable MySQL NDB Cluster backend no|yes|mod [no] ... --enable-perl enable perl backend no|yes|mod [no] Which indicate that, by default, the MySQL Cluster NDB and Perl back-ends will not be built. This is not the case. The system tries to configure those back-ends. The "make depend" completes normally, but the "make" aborts when trying to compile those back-ends. In the case of the Perl back-end, configure does not find the necessary headers and reports that fact, however it does not set flags to block compilation of that module. On a separate identical machine, I did install the items necessary to build those back-ends. However, the system can't find the necessary headers even though they exist. For NDB, one must install the "mysql-devel" RPM. However, the path for finding the headers isn't correct. On Fedora 10, the include path must include "-I/usr/include/mysql/ndb/ndbapi". For Perl, one must install the "perl-devel" RPM, and the path for finding headers must include "-I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE".

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Yup this works, good work, thanks. > > Seems a tad slow though, do filters like these drastically slow down the > search? It applies some overhead: for each value of each attribute of each entry it needs to check whether the memberOf attr is present; if it is, a berval comparison is needed (compare the length first, and the value in case of match). As usual, it depends on the structure of your data. Also, but this is independent of ACL evaluation, slapo-rwm duplicates each entry as soon as it needs to do some manipulation on it (like massaging the DNs and so). If you notice any significant overhead, you might want to profile the execution of your slapd, to point out what's the actual bottleneck. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? Please test HEAD (or import the latest fixes to servers/slapd/overlays/rwm.[ch] into 2.4.16, if you prefer). You need to add rwm-drop-unrequested-attrs no to your slapo-rwm configuration. I haven't documented this flag yet; I'd wait until the fix is confirmed. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 15 Apr '09

15 Apr '09

ando(a)sys-net.it wrote: > David wrote: >> Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon >> it would be a difficult fix? > > On the contrary, it could be relatively simple. I need to further > investigate what's happening, but I could easily reproduce the issue. > I'll be back. Fixing it for back-bdb/hdb is easy enough. For other backends that don't always return whole entries (e.g. back-ldap) there would be more problems. It's an open question whether we care about those at the moment... -- -- 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? On the contrary, it could be relatively simple. I need to further investigate what's happening, but I could easily reproduce the issue. I'll be back. 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
...
5
6
7
8
9
10
11
...
15
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 April 2009