Although Quanah hasn't been able to trigger this yet, the regression
test in master he wrote has been consistently able to trigger for me on
my machine, so I've started to investigate.
For posterity and in case anyone is interested, I have uploaded the
testrun/ directory from a failing run (I suspect the fact of this laptop
having a slow 2-core CPU helps) with a slightly patched slapd that
records the thread ID as well since, in part, this seems like a race of
some sort.
The tgz is available at
ftp://ftp.openldap.org/incoming/its8444-regression-testrun-sync,stat.tgz
So far it looks like replica #3's threads 7f50fb7fe700 and 7f51017bb700
are both trying to apply the modification with CSN
20170605125334.856475Z#000000#001#000000 which sends it into a full
refresh.=20
--=20
Ond=C5=99ej Kuzn=C3=ADk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Full_Name: Gregory Noe
Version: 2.4.44
OS: Debian 8.7
URL: ftp://ftp.openldap.org/incoming/gregory-noe-170605.tar
Submission from: (NULL) (63.142.209.94)
Slapcat is not honoring the '-g' option. The output includes entries from glued
subordinates when it shouldn't. The attached test script
(gregory-noe-170605.tar) sets up the following DIT with inetOrgPerson entries in
each OU:
dn: dc=example,dc=com
|- ou=NonSub00,dc=example,dc=com
|- ou=NonSub01,dc=example,dc=com
|- ou=NonSub02,dc=example,dc=com
glued sub: ou=Accounting,dc=example,dc=com
glued sub: ou=Administrative,dc=example,dc=com
glued sub: ou=Janitorial,dc=example,dc=com
Then the script runs 'slapcat -g -b dc=example,dc=com | grep ^dn'. The result
contains entries from all three glued subordinates.
Tested using Symas OpenLDAP 2.4.44.5
Full_Name: Quanah Gibson-Mount
Version: 2.4.43
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
When using glued/subordinate databases, the "limits" directive needs to be set
on the parent as well as subordinate dbs to be applied if there are global
limits in place. This is currently not documented. Otherwise, the "limits"
directive settings on the subordinate databases is not honored.
Full_Name: Quanah Gibson-Mount
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
While you can set olcMemberOfRefInt during an add operation when instantiating
slapo-memberOf with cn=config, you cannot modify the value after that point.
Attempting to change the value results in:
Running ldapmodify to change olcMemberOfRefInt value
ldapmodify failed (80)!
slapd log shows:
592ef748 <<< dnPrettyNormal:
<olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config>,
<olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config>
592ef748 conn=1003 op=1 modifications:
592ef748 replace: olcMemberOfRefInt
592ef748 one value, length 5
592ef748 conn=1003 op=1 MOD
dn="olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config"
592ef748 conn=1003 op=1 MOD attr=olcMemberOfRefInt
592ef748 slap_queue_csn: queueing 0x7f326010add0
20170531170304.816445Z#000000#000#000000
592ef748 oc_check_required entry
(olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config), objectClass
"olcMemberOf"
592ef748 oc_check_allowed type "objectClass"
592ef748 oc_check_allowed type "olcOverlay"
592ef748 oc_check_allowed type "olcMemberOfGroupOC"
592ef748 oc_check_allowed type "olcMemberOfMemberAD"
592ef748 oc_check_allowed type "olcMemberOfMemberOfAD"
592ef748 oc_check_allowed type "structuralObjectClass"
592ef748 oc_check_allowed type "entryUUID"
592ef748 oc_check_allowed type "creatorsName"
592ef748 oc_check_allowed type "createTimestamp"
592ef748 oc_check_allowed type "olcMemberOfRefInt"
592ef748 oc_check_allowed type "entryCSN"
592ef748 oc_check_allowed type "modifiersName"
592ef748 oc_check_allowed type "modifyTimestamp"
592ef748 send_ldap_result: conn=1003 op=1 p=3
592ef748 send_ldap_result: err=80 matched="" text=""
592ef748 send_ldap_response: msgid=2 tag=103 err=80
ber_flush2: 14 bytes to sd 8
592ef748 conn=1003 op=1 RESULT tag=103 err=80 qtime=0.000020 etime=0.816572
text=
592ef748 slap_graduate_commit_csn: removing 0x7f326010add0
20170531170304.816445Z#000000#000#000000
592ef748 connection_get(8)
gnoe(a)symas.com wrote:
> Full_Name: Gregory Noe
> Version:
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (63.142.209.94)
>
>
> Update mdb_load to safely load back-mdb databases. Currently back-mdb's custom
> sort functions don't order database items in the correct order.
Actually no, this ITS is about tweaking back-mdb to give mdb_load a better
hint about what ordering to use. In particular, the id2v table in master/RE25
isn't being reloaded in proper order 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/