I compiled new rpms and upgraded to 2.4.17 on both the provider and consumer. The problem persists.
New entries like: dn:cn=test2,dc=srg,dc=com objectclass: top objectclass: person userpassword:blah sn:test2
don't replicate. But other entries do, like: dn: uid=user1,ou=People,dc=srg,dc=com uid: user1 cn: Advanced Open Systems objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: shadowLastChange: 14441 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 5000 gidNumber: 5000 homeDirectory: /home/user1 gecos: Advanced Open Systems
I've attached the slapd.conf for the master/provider.
Thank you in advance for any assistance.
--- On Thu, 8/20/09, Brian Neu proclivity76@yahoo.com wrote:
From: Brian Neu proclivity76@yahoo.com Subject: Re: top-level data entries not replicating, 2.4.15 To: "Jonathan Clarke" jonathan@phillipoux.net Cc: openldap-technical@openldap.org Date: Thursday, August 20, 2009, 8:39 AM Forgive me if pasting here is bad etiquette.
<consumer slapd.conf>
include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/samba.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt TLSCertificateFile /etc/openldap/keys/victory3cert.pem TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
database hdb suffix "dc=srg,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=srg,dc=com"
rootpw {MD5}blah
directory /var/lib/ldap
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=0 provider=ldap://victory2.srg.com:389 bindmethod=simple starttls=critical binddn="cn=replicator,dc=srg,dc=com" credentials=blah searchbase="dc=srg,dc=com" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog
updateref ldaps://victory2.srg.com
database monitor
access to * by dn.exact="cn=Manager,dc=srg,dc=com" write by * none
</consumer slapd.conf>
--- On Thu, 8/20/09, Jonathan Clarke jonathan@phillipoux.net wrote:
From: Jonathan Clarke jonathan@phillipoux.net Subject: Re: top-level data entries not replicating,
2.4.15
To: "Brian Neu" proclivity76@yahoo.com Cc: openldap-technical@openldap.org Date: Thursday, August 20, 2009, 8:02 AM On 19/08/2009 19:29, Brian Neu wrote:
Even with no logfilter on the consumer,
cn=replicator,dc=domain,dc=com&
sambaDomainName=SRG,dc=domain,dc=com
don't replicate, even after wiping the database
and
restarting. Everything else seems to replicate
fine.
How do I get top-level data entries to
replicate?
This really depends on your syncrepl configuration on
the
consumer. If you provide it here, maybe we can take a look.
Aside from that, the latest version, 2.4.17, contains
a few
fixes that might help with this problem.
Jonathan
On Sat, Aug 22, 2009 at 12:18 AM, Brian Neu proclivity76@yahoo.com wrote:
I compiled new rpms and upgraded to 2.4.17 on both the provider and consumer. The problem persists.
New entries like: dn:cn=test2,dc=srg,dc=com objectclass: top objectclass: person userpassword:blah sn:test2
If this is literally correct, there is no cn attribute (although it is referred to in the dn) ?
This would not b considered valid with respect to the schema, and as such ignored during replication. I would think to get it to slapadd in the first place, schema validation would need to have been turned off.
The other entry you quoted, has a cn value.
Cheers Brett
I really only created the test2 record to find out why the
sambaDomainName=SRG,dc=srg,dc=com
record wasn't replicating.
This entry won't replicate either, even with a cn attribute . . . dn:cn=test3,dc=srg,dc=com objectclass: top objectclass: person userpassword:blah sn:test3 cn:test3
--- On Fri, 8/21/09, Brett @Google brett.maxfield@gmail.com wrote:
From: Brett @Google brett.maxfield@gmail.com Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: openldap-technical@openldap.org Date: Friday, August 21, 2009, 10:28 AM On Sat, Aug 22, 2009 at 12:18 AM, Brian Neu proclivity76@yahoo.com wrote:
I compiled new rpms and upgraded to 2.4.17 on both the provider and consumer. The problem persists.
New entries like:
dn:cn=test2,dc=srg,dc=com
objectclass: top
objectclass: person
userpassword:blah
sn:test2
If this is literally correct, there is no cn attribute (although it is referred to in the dn) ? This would not b considered valid with respect to the schema, and as such ignored during replication. I would think to get it to slapadd in the first place, schema validation would need to have been turned off.
The other entry you quoted, has a cn value.
Cheers Brett
--On Friday, August 21, 2009 8:52 AM -0700 Brian Neu proclivity76@yahoo.com wrote:
I really only created the test2 record to find out why the
sambaDomainName=SRG,dc=srg,dc=com
record wasn't replicating.
This entry won't replicate either, even with a cn attribute . . . dn:cn=test3,dc=srg,dc=com objectclass: top objectclass: person userpassword:blah sn:test3 cn:test3
Please don't top post.
Your config is a little... odd. You have per-db access rules, and yet you break them like you expect more:
database hdb suffix "cn=accesslog" ... access to * by dn.base="cn=replicator,dc=srg,dc=com" read by * break
Not that this hurts anything, but it is a weird read.
Also, I don't see *any* access rules on the main DB. You have:
database hdb suffix "dc=srg,dc=com" .... database monitor access to * by dn.exact="cn=Manager,dc=srg,dc=com" write by dn.exact="uid=root,ou=People,dc=srg,dc=com" write by dn.base="cn=replicator,dc=srg,dc=com" read by * break
Which means you just gave a lot of access to the *monitor* database but not your *primary* database. I suggest go re-read the slapd.access(5) man page. If you want global ACLs, they need to come before any "database xyz" line. If you want per-db ACLs, which I think is what you're trying to do, then you need to do them *per-db*. Not the odd acl in accesslog, none in your main db, and some for your monitor database.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Brett ＠Google -
Brian Neu -
Quanah Gibson-Mount