Orion Poplawski wrote:
On 01/17/2013 09:27 AM, Rob Crittenden wrote:
Orion Poplawski wrote:
But then on ipa-replica-install, problems as predicted:

ipa-replica-install --setup-ca
   [16/30]: configuring ssl for ds instance
creation of replica failed: Could not find a CA cert in

Ok, I think what I would recommend is preparing a replica w/o
replacing the
certs (e.g. let the CA issue certs for all the services).

Install the replica.

Then replace with the wildcard certs once the install is up and


That gets to:

   [21/30]: setting up initial replication
Starting replication, please wait until this has completed.
[ipa.cora.nwra.com] reports: Update failed! Status: [-11  - System error]
creation of replica failed: Failed to start replication

Because on ipa.cora :
[17/Jan/2013:09:31:42 -0700] NSMMReplicationPlugin -
agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Replication bind with
SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error
-8172:Peer's certificate issuer has been marked as not trusted by the

because the new cert install wiped out the old slapd-NWRA-COM certs.
Installed the NWRA.COM IPA CA there.

It seems like a most of the problems would be alleviated if instead of
wiping out the old NSS dbs, it simply added the new certs.  I don't know
if there are any other security implications of this or not.

Yes, that is probably true. I think the reasoning was we didn't know what was in the database already so starting over seemed safer.

I'm also tempted to start over and do the --dirsrv-cert options on the
initial ipa-server-install to see if that helps.

Anyway, tried again and now:

Configuring Kerberos KDC: Estimated time 30 seconds
   [1/9]: adding sasl mappings to the directory
   [2/9]: writing stash file from DS
   [3/9]: configuring KDC
   [4/9]: creating a keytab for the directory
   [5/9]: creating a keytab for the machine
   [6/9]: adding the password extension to the directory
   [7/9]: enable GSSAPI for replication
creation of replica failed: list index out of range

2013-01-17T16:41:33Z DEBUG   [7/9]: enable GSSAPI for replication
2013-01-17T16:41:33Z INFO Setting agreement
tree,cn=config schedule to 2358-2359 0 to force synch
2013-01-17T16:41:34Z INFO Deleting schedule 2358-2359 0 from agreement
2013-01-17T16:41:35Z INFO Replication Update in progress: FALSE: status:
-11 - System error: start: 0: end: 0
2013-01-17T16:41:35Z INFO Setting agreement
schedule to 2358-2359 0 to force synch
2013-01-17T16:41:36Z INFO Deleting schedule 2358-2359 0 from agreement

2013-01-17T16:41:37Z INFO Replication Update in progress: FALSE: status:
0 Replica acquired successfully: Incremental update succeeded: start:
20130117164126Z: end: 20130117164127Z
2013-01-17T16:41:37Z DEBUG list index out of range
   File "/usr/sbin/ipa-replica-install", line 496, in <module>

   File "/usr/sbin/ipa-replica-install", line 441, in main
     krb = install_krb(config, setup_pkinit=options.setup_pkinit)

   File "/usr/sbin/ipa-replica-install", line 163, in install_krb
     setup_pkinit, pkcs12_info)

line 207, in create_replica
     self.start_creation("Configuring Kerberos KDC", 30)

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

line 442, in __convert_to_gssapi_replication

line 833, in convert_to_gssapi_replication
     self.gssapi_update_agreements(self.conn, r_conn)

line 557, in gssapi_update_agreements
     self.setup_krb_princs_as_replica_binddns(a, b)

line 550, in setup_krb_princs_as_replica_binddns
     mod = [(ldap.MOD_ADD, "nsds5replicabinddn", a_pn[0].dn)]

This error means that we lack one of the ldap principals on one of the replicas. We've improved the reporting about this error in newer versions and we try a bit harder to make sure things are ok before trying the conversion. It may be because of the replication trust issues, or it could just be bad timing.

I also see this in /var/log/dirsrv/slapd-NWRA-COM/errors on the master:

[17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin -
agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Schema replication
update failed: Type or value exists
[17/Jan/2013:09:41:26 -0700] NSMMReplicationPlugin -
agmt="cn=meToipapub.cora.nwra.com" (ipapub:389): Warning: unable to
replicate schema: rc=1

Which is probably due to some schema modifications I've made, but these
don't really seem related to the error above.

We try to do all schema modifications online so they end up in 99user.ldif. This ensures that things replicate smoothly.


Freeipa-users mailing list

Reply via email to