--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
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
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.
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".
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
-----------------------------------
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
-----------------------------------
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/
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
-----------------------------------
Gavin Henry wrote:
> Thanks, I'll review and let you know.
>
> Gavin.
>
And while you're at it, please move the slapd config examples back to the end
of the slapd config chapters where they originally came from. You can insert
references like "for more detailed discussion of access controls go -there-"
but the examples need to be in the config chapters.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/