Well, we'd need to see the config file for the replica as well.
--Quanah
Was in a previous post, but here you go.
--On Friday, August 21, 2009 5:03 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
Well, we'd need to see the config file for the replica as well.
--Quanah
Was in a previous post, but here you go.
Looks ok to me. Did you set your replica up to fully resynch after making the acl changes on the master and restarting slapd on it (the master)?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Looks ok to me. Did you set your replica up to fully resynch after making the acl changes on the master and restarting slapd on it (the master)?
--Quanah
I do this:
[root@victory3 ldap]# /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.* /var/lib/ldap/alock && /etc/init.d/ldap start
[root@victory3 ldap]# ldapsearch -x -Z -h victory2.srg.com -D "cn=Manager,dc=srg,dc=com" -w secret -b cn=test3,dc=srg,dc=com # extended LDIF # # LDAPv3 # base <cn=test3,dc=srg,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# test3, srg.com dn: cn=test3,dc=srg,dc=com objectClass: top objectClass: person userPassword:: e02A2X1IR3RTVEN2VDBoZitwakFKekw4ZU1nPT0= sn: test3 cn: test3
# search result search: 3 result: 0 Success
# numResponses: 2 # numEntries: 1 [root@victory3 ldap]# ldapsearch -x -D "cn=Manager,dc=srg,dc=com" -w secret -b cn=test3,dc=srg,dc=com # extended LDIF # # LDAPv3 # base <cn=test3,dc=srg,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object matchedDN: dc=srg,dc=com
# numResponses: 1
uid=user,ou=People entries replicate fine, as well as services and everything else that came from the migration tools. But those test entries and the SambaDomainName entry at the top level don't replicate.
Should I start the consumer with a certain debug level and look into an error?
I just started slapd with -s 205 -d 205 2>debug.txt after letting it run for a minute, there is no "test2" or "test3" in the resulting output, though every other entry is.
Should we be looking into the provider?
--On Friday, August 21, 2009 5:57 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
I do this:
[root@victory3 ldap]# /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.* /var/lib/ldap/alock && /etc/init.d/ldap start
Ok, that certainly looks like it is wiping out the database. ;)
[root@victory3 ldap]# ldapsearch -x -D "cn=Manager,dc=srg,dc=com" -w secret -b cn=test3,dc=srg,dc=com # extended LDIF # # LDAPv3 # base <cn=test3,dc=srg,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object matchedDN: dc=srg,dc=com
# numResponses: 1
Are you sure replication completed yet? I'm guessing yes, but ... ;)
uid=user,ou=People entries replicate fine, as well as services and everything else that came from the migration tools. But those test entries and the SambaDomainName entry at the top level don't replicate.
Should I start the consumer with a certain debug level and look into an error?
I just started slapd with -s 205 -d 205 2>debug.txt after letting it run for a minute, there is no "test2" or "test3" in the resulting output, though every other entry is.
Should we be looking into the provider?
I'm not sure why you are screwing with the syslog level. Usually the default level is fine. Have you completely verified that the replicator credentials can see those objects on the master?
If that works, then yes, using slapd -d -1 and capturing that to a file may indicate why they aren't replicating.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--- On Mon, 8/24/09, Quanah Gibson-Mount quanah@zimbra.com wrote:
From: Quanah Gibson-Mount quanah@zimbra.com Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" proclivity76@yahoo.com, openldap-technical@openldap.org Date: Monday, August 24, 2009, 12:26 PM --On Friday, August 21, 2009 5:57 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
I do this:
[root@victory3 ldap]# /etc/init.d/ldap stop &&
rm -fr /var/lib/ldap/*.*
/var/lib/ldap/alock && /etc/init.d/ldap start
Ok, that certainly looks like it is wiping out the database. ;)
[root@victory3 ldap]# ldapsearch -x -D
"cn=Manager,dc=srg,dc=com" -w
secret -b cn=test3,dc=srg,dc=com # extended LDIF # # LDAPv3 # base <cn=test3,dc=srg,dc=com> with scope
subtree
# filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object matchedDN: dc=srg,dc=com
# numResponses: 1
Are you sure replication completed yet? I'm guessing yes, but ... ;)
uid=user,ou=People entries replicate fine, as
well as services and
everything else that came from the migration
tools. But those test
entries and the SambaDomainName entry at the top level
don't replicate.
Should I start the consumer with a certain debug level
and look into an
error?
I just started slapd with -s 205 -d 205 2>debug.txt after letting it run for a minute, there is no "test2"
or "test3" in the
resulting output, though every other entry is.
Should we be looking into the provider?
I'm not sure why you are screwing with the syslog level. Usually the default level is fine. Have you completely verified that the replicator credentials can see those objects on the master?
If that works, then yes, using slapd -d -1 and capturing that to a file may indicate why they aren't replicating.
--Quanah
From what I can tell by looking at the provider log (-1), new top-level entries are added to the provider correctly, and to the accesslog on the provider, but I'm not familiar enough with the OpenLDAP code to be certain.
Can anyone test to see if they experience the same thing?
--On Monday, August 24, 2009 6:03 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
If that works, then yes, using slapd -d -1 and capturing that to a file may indicate why they aren't replicating.
--Quanah
From what I can tell by looking at the provider log (-1), new top-level entries are added to the provider correctly, and to the accesslog on the provider, but I'm not familiar enough with the OpenLDAP code to be certain.
Can anyone test to see if they experience the same thing?
Err, sorry. I meant run slapd -d -1 on the replica, to see why it isn't replicating those entries.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--- On Mon, 8/24/09, Quanah Gibson-Mount quanah@zimbra.com wrote:
From: Quanah Gibson-Mount quanah@zimbra.com Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" proclivity76@yahoo.com, openldap-technical@openldap.org Date: Monday, August 24, 2009, 9:11 PM --On Monday, August 24, 2009 6:03 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
If that works, then yes, using slapd -d -1 and
capturing
that to a file may indicate why they aren't replicating.
--Quanah
From what I can tell by looking at the provider log
(-1), new top-level
entries are added to the provider correctly, and to
the accesslog on the
provider, but I'm not familiar enough with the
OpenLDAP code to be
certain.
Can anyone test to see if they experience the same
thing?
Err, sorry. I meant run slapd -d -1 on the replica, to see why it isn't replicating those entries.
--Quanah
Unfortunately, not until tomorrow eve, EST. The consumer server (victory3) is temporarily in someone's office before it goes to a colo, and was turned off due to the fan noise for the biz day. It SHOULD have been powered back on, but someone forgot.
Aren't there a couple of virtual servers somewhere that serve as testing grounds for the project? That, or does someone have a provider->consumer set-up in production that can test a benign top-level data entry and see if it replicates?
Thanks!
--On Monday, August 24, 2009 6:28 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
Unfortunately, not until tomorrow eve, EST. The consumer server (victory3) is temporarily in someone's office before it goes to a colo, and was turned off due to the fan noise for the biz day. It SHOULD have been powered back on, but someone forgot.
Aren't there a couple of virtual servers somewhere that serve as testing grounds for the project? That, or does someone have a provider->consumer set-up in production that can test a benign top-level data entry and see if it replicates?
This sort of setup works for me, and hundreds of others, no problem. Which is why figuring out why it isn't working for you is non-trivial. I still suspect it is a configuration issue that is non-obvious.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--- On Mon, 8/24/09, Quanah Gibson-Mount quanah@zimbra.com wrote:
From: Quanah Gibson-Mount quanah@zimbra.com Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" proclivity76@yahoo.com, openldap-technical@openldap.org Date: Monday, August 24, 2009, 9:34 PM --On Monday, August 24, 2009 6:28 PM -0700 Brian Neu proclivity76@yahoo.com wrote:
Unfortunately, not until tomorrow eve, EST. The
consumer server
(victory3) is temporarily in someone's office before
it goes to a colo,
and was turned off due to the fan noise for the biz
day. It SHOULD have
been powered back on, but someone forgot.
Aren't there a couple of virtual servers somewhere
that serve as testing
grounds for the project? That, or does someone
have a provider->consumer
set-up in production that can test a benign top-level
data entry and see
if it replicates?
This sort of setup works for me, and hundreds of others, no problem. Which is why figuring out why it isn't working for you is non-trivial. I still suspect it is a configuration issue that is non-obvious.
--Quanah
On the consumer, victory3, I'm running this: /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.* /var/lib/ldap/alock && /etc/init.d/ldap start 2>/var/lib/ldap/debug-trace.txt
Then on the provider, I'm running an ldapadd on this file: <test9.ldif> dn:cn=test9,dc=srg,dc=com objectclass: top objectclass: person userpassword:{MD5}HaaaTaaaaaaaaaaaaaJzaaaaaMg== sn:test9 cn:test9
Then back to the consumer, I <CTRL+C> to stop slapd. I vim /var/lib/ldap/debug-trace.txt and /test9 . No instance of test9 in the file. No instance of any of the top-level data entries, though it's a 643MB file.
I'm at a loss.
--On Friday, August 28, 2009 8:58 AM -0700 Brian Neu proclivity76@yahoo.com wrote:
On the consumer, victory3, I'm running this: /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.* /var/lib/ldap/alock && /etc/init.d/ldap start 2>/var/lib/ldap/debug-trace.txt
Then on the provider, I'm running an ldapadd on this file: <test9.ldif> dn:cn=test9,dc=srg,dc=com objectclass: top objectclass: person userpassword:{MD5}HaaaTaaaaaaaaaaaaaJzaaaaaMg== sn:test9 cn:test9
Then back to the consumer, I <CTRL+C> to stop slapd. I vim /var/lib/ldap/debug-trace.txt and /test9 . No instance of test9 in the file. No instance of any of the top-level data entries, though it's a 643MB file.
I'm at a loss.
Can you please bind as the replicator credentials to the master, and verify it can see these entries?
I.e.,
ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "dc=srg,dc=com" cn=test9
Also, search the accesslog db:
ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "cn=accesslog"
And see if it can see the add operation for that entry in there too.
Also, make sure the add operation for that entry exists in the accesslog db either way (using the rootdn credentials if you can't see it with the replicator ones).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--- On Fri, 8/28/09, Quanah Gibson-Mount quanah@zimbra.com wrote:
From: Quanah Gibson-Mount quanah@zimbra.com Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" proclivity76@yahoo.com, openldap-technical@openldap.org Date: Friday, August 28, 2009, 12:18 PM --On Friday, August 28, 2009 8:58 AM -0700 Brian Neu proclivity76@yahoo.com wrote:
On the consumer, victory3, I'm running this: /etc/init.d/ldap stop && rm -fr
/var/lib/ldap/*.* /var/lib/ldap/alock &&
/etc/init.d/ldap start
2>/var/lib/ldap/debug-trace.txt
Then on the provider, I'm running an ldapadd on this
file:
<test9.ldif> dn:cn=test9,dc=srg,dc=com objectclass: top objectclass: person userpassword:{MD5}HaaaTaaaaaaaaaaaaaJzaaaaaMg== sn:test9 cn:test9
Then back to the consumer, I <CTRL+C> to stop
slapd. I vim
/var/lib/ldap/debug-trace.txt and /test9
. No instance of test9 in the
file. No instance of any of the top-level data
entries, though it's a
643MB file.
I'm at a loss.
Can you please bind as the replicator credentials to the master, and verify it can see these entries?
I.e.,
ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "dc=srg,dc=com" cn=test9
Worked fine.
Also, search the accesslog db:
ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "cn=accesslog"
Appears to also work fine, see below results.
And see if it can see the add operation for that entry in there too.
Also, make sure the add operation for that entry exists in the accesslog db either way (using the rootdn credentials if you can't see it with the replicator ones).
--Quanah
queried as replicator from the consumer . . . .
# extended LDIF # # LDAPv3 # base <cn=accesslog> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# accesslog dn: cn=accesslog objectClass: auditContainer cn: accesslog
# 20090828143237.000001Z, accesslog dn: reqStart=20090828143237.000001Z,cn=accesslog objectClass: auditAdd reqStart: 20090828143237.000001Z reqEnd: 20090828143237.000002Z reqType: add reqSession: 1417 reqAuthzID: cn=Manager,dc=srg,dc=com reqDN: cn=test9,dc=srg,dc=com reqResult: 0 reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: userPassword:+ {MD5}blah reqMod: sn:+ test9 reqMod: cn:+ test9 reqMod: structuralObjectClass:+ person reqMod: entryUUID:+ bce8a427-6d66-491d-b790-e80afc6f0112 reqMod: creatorsName:+ cn=Manager,dc=srg,dc=com reqMod: createTimestamp:+ 20090828143237Z reqMod: entryCSN:+ 20090828143237.174926Z#000000#000#000000 reqMod: modifiersName:+ cn=Manager,dc=srg,dc=com reqMod: modifyTimestamp:+ 20090828143237Z
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
--On Friday, August 28, 2009 10:21 AM -0700 Brian Neu proclivity76@yahoo.com wrote:
--- On Fri, 8/28/09, Quanah Gibson-Mount quanah@zimbra.com wrote:
ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "dc=srg,dc=com" cn=test9
Worked fine.
Also, search the accesslog db:
ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "cn=accesslog"
Appears to also work fine, see below results.
queried as replicator from the consumer . . . .
Ok.
Can you manually start slapd on the replica after wiping out its database, using -d -1 as one of the flags to slapd, and email me the logfile offline?
Thanks, Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Brian Neu -
Quanah Gibson-Mount