[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4238) refreshAndPersist & filter
This has already been fixed in 2.3.12.
ak2@smr.ru wrote:
> 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
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/