[Date Prev][Date Next] [Chronological] [Thread] [Top]
refreshAndPersist & filter 2.3.11

To: <OpenLDAP-software@OpenLDAP.org>
Subject: refreshAndPersist & filter 2.3.11
From: "Alexey Kravchuk" <ak2@smr.ru>
Date: Wed, 30 Nov 2005 20:37:14 +0400
Hi,

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.

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
Follow-Ups:
- Re: refreshAndPersist & filter 2.3.11
  - From: Howard Chu <hyc@symas.com>
Prev by Date: Search on 'member' attribute in dynamic group
Next by Date: Re: gssapi service principal
Index(es):
- Chronological
- Thread