[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#4238) refreshAndPersist & filter
Full_Name: Alexey Kravchuk
Version: 2.3.11
OS: Linux kernel 2.6.9-22.0.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (62.76.46.53)
syncrepl of slapd 2.3.11 with type = refreshAndPersist works
only when the syncrepl filter allows to fetch all parent entries up to the
base.
Yet it worked fine in 2.2.13.
That is if we specify searchbase="dc=example,dc=com",
filter="(objectClass=organizationalPerson)"
for syncrepl as in the LDAP Sync Replication config example from the Doc,
but set type = refreshAndPersist instead of type=refreshOnly
then syncing does not work.
How to reproduce:
Started master slapd on port 9011 with config:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
allow bind_v2
pidfile /var/run/slapd_new_master.pid
argsfile /var/run/slapd.args
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap6
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
database monitor
loglevel 55
Populated it with test entries:
dn: dc=example,dc=com
dc: example
objectClass: organization
objectClass: domainRelatedObject
objectClass: dcObject
o: Example, Inc.
description: location 1
associatedDomain: example.com
dn: cn=Manager,dc=example,dc=com
cn: Manager
objectClass: organizationalRole
dn: ou=user,dc=example,dc=com
ou: user
description: location 1
objectClass: organizationalUnit
dn: cn=u1,ou=user,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: organizationalPerson
objectClass: top
givenName: u1@example.com
uid: u1@example.com
mail: u1@example.com
sn: SURNAMEu1
cn: u1
dn: cn=u2,ou=user,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: organizationalPerson
objectClass: top
givenName: u2@example.com
uid: u2@example.com
mail: u2@example.com
sn: SURNAMEu2
cn: u2
Then started a slave slapd with config on port 9012:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
allow bind_v2
pidfile /var/run/slapd__new_slave.pid
argsfile /var/run/slapd.args
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap7
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
syncrepl rid=125
provider=ldap://localhost:9011
type=refreshAndPersist
interval=00:00:00:10
searchbase="dc=example,dc=com"
filter="(objectClass=organizationalPerson)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=example,dc=com"
credentials=secret
No entries on the slave:
ldapsearch -h localhost:9012 -b "dc=example,dc=com" -x -LLL
No such object (32)
Here is a log excerpt for the master:
Nov 30 18:31:28 slave slapd[22130]: do_search
Nov 30 18:31:28 slave slapd[22130]: >>> dnPrettyNormal: <dc=example,dc=com>
Nov 30 18:31:28 slave slapd[22130]: <<< dnPrettyNormal: <dc=example,dc=com>,
<dc=example,dc=com>
Nov 30 18:31:28 slave slapd[22130]: SRCH "dc=example,dc=com" 2 0
Nov 30 18:31:28 slave slapd[22130]: 0 0 0
Nov 30 18:31:28 slave slapd[22130]: begin get_filter
Nov 30 18:31:28 slave slapd[22130]: EQUALITY
Nov 30 18:31:28 slave slapd[22130]: end get_filter 0
Nov 30 18:31:28 slave slapd[22130]: filter:
(objectClass=organizationalPerson)
Nov 30 18:31:28 slave slapd[22130]: => get_ctrls
Nov 30 18:31:28 slave slapd[22130]: => get_ctrls:
oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical)
Nov 30 18:31:28 slave slapd[22130]: <= get_ctrls: n=1 rc=0 err=""
Nov 30 18:31:28 slave slapd[22130]: attrs:
Nov 30 18:31:28 slave slapd[22130]: *
Nov 30 18:31:28 slave slapd[22130]: structuralObjectClass
Nov 30 18:31:28 slave slapd[22130]: entryCSN
Nov 30 18:31:28 slave slapd[22130]:
Nov 30 18:31:28 slave slapd[22130]: slap_global_control: unavailable
control: 1.3.6.1.4.1.4203.1.9.1.1
Nov 30 18:31:28 slave slapd[22130]: => bdb_search
Nov 30 18:31:28 slave slapd[22130]: bdb_dn2entry("dc=example,dc=com")
Nov 30 18:31:28 slave slapd[22130]: base_candidates: base:
"dc=example,dc=com" (0x00000001)
Nov 30 18:31:28 slave slapd[22130]: => test_filter
Nov 30 18:31:28 slave slapd[22130]: EQUALITY
Nov 30 18:31:28 slave slapd[22130]: <= test_filter 5
Nov 30 18:31:28 slave slapd[22130]: bdb_search: 1 does not match filter
Nov 30 18:31:28 slave slapd[22130]: send_ldap_result: conn=4 op=1 p=3
Nov 30 18:31:28 slave slapd[22130]: send_ldap_result: err=0 matched=""
text=""
Nov 30 18:31:28 slave slapd[22130]: send_ldap_result: conn=4 op=1 p=3
Nov 30 18:31:28 slave slapd[22130]: send_ldap_result: err=32 matched=""
text=""
Nov 30 18:31:28 slave slapd[22130]: send_ldap_response: msgid=2 tag=101
err=32
With 2.2.13. this scenario worked fine.
I guess the changed behaviour is not an intended feature, because the Doc
mentions this specific situation:
"Because a general search filter can be used in the syncrepl specification,
some entries in the context may be omitted from the synchronization content.
The syncrepl engine creates a glue entry to fill in the holes in the replica
context if any part of the replica content is subordinate to the holes. The
glue entries will not be returned in the search result unless ManageDsaIT
control is provided."
If the syncrepl filter is changed so that it returns all parent entries
("(objectClass=*)" for example), sync works fine.
refreshOnle type works fine with any filter.
Another strange issue is that error message "slap_global_control:
unavailable control: 1.3.6.1.4.1.4203.1.9.1.1" still occurs in log even when
everything seems to work fine (with refreshOnle type or "(objectClass=*)"
filter)
And slapd does not mention '1.3.6.1.4.1.4203.1.9.1.1' as a supported
control:
# ldapsearch -h localhost:9011 -b "" -x -s base +
-D"cn=Manager,dc=example,dc=com" -w secret | grep -F '1.3.6.1.4.1.4203.1.9.1.1'
#
Yet it is stated in the draft-zeilenga-ldup-sync-06.txt :
To allow clients to discover support for this operation, servers
implementing this operation SHOULD publish the
1.3.6.1.4.1.4203.1.9.1.1 as a value of 'supportedControl' attribute
[RFC2252] of the root DSA-specific entry (DSE). A server MAY choose
to advertise this extension only when the client is authorized to use
it.
Please let me know if any more delailed info is needed.
Best regards
Alexey Kravchuk