Go figure. I rebuilt it (again) cleanly, and after starting replication again, while I was madly trying to change the debug level on the new replica...it completed replication this time.

Heisenbugs. Gotta love them. (I think this one was in my network somewhere, not your code -- I just couldn't observe it enough and someone must've changed something while I wasn't looking).


On 05/21/2014 10:19 PM, Rob Crittenden wrote:
Bret Wortman wrote:
It takes about 2 minutes. How would you like me to turn debugging on?

I'm not sure if you should enable this on both sides of the agreement or
not. If you have the ability and don't mind potentially slowing down the
working master it might be useful to the 389-ds guys.


Bret Wortman

On May 21, 2014, at 4:26 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

Bret Wortman wrote:
On the new replica (asipa) I see in the access log almost 5000 entries
like this:

[21/May/2014:10:30:58 -0400] conn=4 op=4923 EXT
oid="2.16.840.113730.3.5.6" name="Netscape Replication Total update Entry"
[21/May/2014:10:30:58 -0400] conn=4 op=4923 RESULT err=0 tag=120
nentries=0 etime=0

And these just repeat, increasing the "op" value until they terminate
with this one. The rest of it just looks like informational messages.
How long does this take? Is there time to enable replication debugging?
That may provide more output.

Over on zsipa (the CA master), errors contains:

[21/May/2014:14:31:06 +0000] NSMMReplciationPlugin - Schema
agmt="cn=meToasipa.foo.net" (asipa:389) must not be overwritten(set
replication log for additional info)
[21/May/2014:14:31:06 +0000] NSMMReplicationPlugin -
agmt="cn=meToasipa.foo.net" (asipa:389) Warning: unable to replicate
schema: rc=1
I don't think this is related.

I'd run ipa-replica-manage list -v `hostname` and ipa-csreplica-manage
list -v `hostname` on the master you generated the replica install file
on to see what agreements it has or thinks it has.


These two lines repeat at intervals for a while.

Nothing else leapt out at me.

On 05/21/2014 11:04 AM, Rob Crittenden wrote:
Bret Wortman wrote:
This occurs on our first attempt to join as a replica. I've erased this
box and rebaselined it but the same thing happens. No network ports
being blocked that we know of, and another replica I created at the same
time installed its replica file without issue.

asipa is the new replica, zsipa is the ca and original master on which
the replica file was created.

   [24/34]: setting up initial replication
Starting replication, please wait until this has completed
Update in progress, 130 seconds elapsed
Update in progress yet not in progress

[ipamaster.foo.net] reports: Update failed! Status: [10 Total update
abortedLDAP error: Referral]

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication

/var/log/ipareplica-install.log contains this:

2014-05-21T145:28:56Z DEBUG retrieving schema for SchemaCache
url=ldaps://asipa.fopo.net:636 conn=<ldap.ldapobject.SimpleLDAPObject
instance at 0x4faf170>
2014-05-21T14:31:08Z DEBUG   File
line 638, in run_script
     return_value = main_function()

   File "/usr/sbin/ipa-replica-install", line 663, in main
     ds = install_replica_ds(config)

   File "/usr/sbin/ipa-replica-install", line 188, in install_replica_ds
     ca_file=config.dir + "/ca.crt",

"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
360 in create_replica

   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 364, in start_creation

"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
373, in __setup_replica

line 961, in setup_replication
     raise RuntimeError("Failed to start replication")

2014-0521T14:31:08Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Failed to start replication

Any guidance on where to start looking?
Check the 389-ds access and error logs on both masters.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Freeipa-users mailing list

Reply via email to