[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Just organizationalUnits objects copied doing sync replication
Solved:
There was an schema file in the provider that I hadn't included in the
consumer. That was the reason of the "value #0 invalid per syntax"
error.
Sorry for my newbie question. At least I hope that this could be
useful for anybody else.
Howerver I still don't know how to delete those wrong objects.
2009/8/13 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
>>
>