On Wed, Aug 12, 2009 at 11:40 PM, Quanah Gibson-Mountquanah@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
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-Mountquanah@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
openldap-technical@openldap.org
-
Yeray Gutiérrez Cedrés