Re: Just organizationalUnits objects copied doing sync replication

[Yeray Gutiérrez Cedrés <ycedres@gmail.com>]

On Wed, Aug 12, 2009 at 11:40 PM, Quanah Gibson-Mount<quanah@zimbra.com> wrote:
> --On Wednesday, August 12, 2009 11:17 PM +0100 Yeray Gutiérrez Cedrés
> <ycedres@gmail.com> wrote:
>
>> I'm trying to replicate an openldap database from a consumer like this:
>>
>> index           objectClass,entryCSN,entryUUID eq
>> overlay syncprov
>> syncprov-checkpoint 100 10
>> syncprov-sessionlog 100
>>
>>
>> To a provider like this:
>>
>>
>> index           objectClass,entryCSN,entryUUID eq
>>
>>        syncrepl rid=123
>>                provider=ldap://10.140.200.3:389
>>                type=refreshOnly
>>                interval=00:00:00:01
>>                searchbase="dc=example,dc=org"
>>                scope=sub
>>                attrs="*"
>>                schemachecking=off
>>                bindmethod=simple
>>                binddn="cn=admin,dc=example,dc=org"
>>                credentials="mypassword"
>>
>> The provider database is completely emtpy and I want the provider to
>> copy the whole database. The only objects that are copied are the
>> organizationalUnit class objects. The objects that are "under" the
>> organizationalUnits  (like for example a 'person' objetct)  are not
>> being copied. What could be the reason for that?
>
>
> I think you are confused about the differences between "provider" and
> "consumer".  The provider is what starts with the full database.  The
> consumer is what gets the database from the provider.  So the provider does
> *not* copy the database, the consumer does.
>

I'm sorry for mixing my e-mail up a little bit. I read it three times
before sending but at certain hours your brain doesn't work as you
expect :-).


> In any case, your "attrs" line is wrong.  You really shouldn't set it at all
> and just use the default unless you really know what you're doing.
>

Well I tried first leaving those lines at their default value.
According to the openldap documentation:

"The scope defaults to sub, the filter defaults to (objectclass=*),
attrs defaults to "*,+" to replicate all user and operational
attributes, and attrsonly is unset by default."

I try this in the consumer:

        syncrepl rid=123
                provider=ldap://10.140.209.254:389
                type=refreshOnly
                interval=00:00:00:01
                searchbase="dc=example,dc=org"
                schemachecking=off
                bindmethod=simple
                binddn="cn=admin,dc=example,dc=org"
                credentials="secret"


Then I check the slapd.con file:
# slaptest
/etc/ldap/slapd.conf: line 152: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 174: rootdn is always granted unlimited privileges.
config file testing succeeded

Then I restart:
# /etc/init.d/slapd restart

I see this in the logfile

slapd[22700]: slapd starting
slapd[22700]: syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
slapd[22700]: syncrepl_entry: rid=123 inserted UUID
ead90d7a-c02b-102c-8c00-cb58049f9ef6
slapd[22700]: syncrepl_entry: rid=123 be_search (32)
slapd[22700]: syncrepl_entry: rid=123 dc=example,dc=org
slapd[22700]: syncrepl_entry: rid=123 be_add (0)

If does the same for "cn=admin,dc=example,dc=org",
"ou=users,dc=example,dc=org",
"ou=groups,dc=groups,dc=org","ou=postfix,dc=example,dc=org",
"ou=alias,ou=postfix,dc=example,dc=org","cn=vmail,ou=groups,dc=example,dc=org"
and finally I get this message:

slapd[22700]: syncrepl_message_to_entry: rid=123 mods check
(objectClass: value #0 invalid per syntax)
slapd[22700]: do_syncrepl: rid=123 quitting

When I try with ldapsearch (from the consumer to the provider, the
provider IP is 10.140.200.3):

# ldapsearch -D "cn=admin,dc=example,dc=org" -W -x -h 10.140.200.3
objectClass=* attr=*,+

it does return all entries:
# numResponses: 705
# numEntries: 704


As additional information, when I do slapcat, I get this (apart from
the objects that were created before, as I said):

dn:
objectClass: top
objectClass: dcObject
objectClass: organization
o: corp.example.org

dn:
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin

I think this objects are there as a result of starting slapd in the
first moment with a wrong configuration file (for example, the suffix
line was incorrectly set to corp.example.com insted of example.com).
But I don't know how to delete those entries. And I also don't know if
this is affecting to the correct behaviour of the replication.

> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>