For the benefit, or added confusion, of future generations, some
ipa-ca-install, run successful replica instantiation w/o --setup-ca
fails consistently with the errors in my orig post. Never figured out
what the script was finding that needed purging. After a multitude of
attempts (thank you, ESXi snapshots) with multiple ipa-server-install
--uninstall's , i gave up and rebuilt from the gound up withlatest
packages and --setup-ca which works great
I found that installing a replica with firewalld enabled would
consistently fail during initial replication. Disabling firewalld
always allowed replication and later stages to complete
[24/38]: setting up initial replication
Starting replication, please wait until this has completed.
[ipa.localdomain.local] reports: Update failed! Status: [-1 - LDAP
error: Can't contact LDAP server]
The first master and all replicas are all CentOS Linux release 7.2.1511
(Core) with ipa-server-4.2.0-15.0.1.el7
One other thing. if, during ipa-replica-install,+ you choose the
default answer to the following:
Existing BIND configuration detected, overwrite? [no]:
ipa.ipapython.install.cli.install_tool(Replica): ERROR Aborting
Not sure if that is intended? Which BIND configuration is being detected?
Anyhow, up and running with 4 replicas, 2 of which will be split off to
a failover instance of ESXi in the future. When it works, it's a joy
Now back to getting these Mac clients to play nicely with IPA ...
thanks for the help and advice
On 02/06/16 22:27, Rob Crittenden wrote:
Cal Sawyer wrote:
Apologies for the lengthy pause in getting back onto this. I ended up
destroying the replica and reprovisioning frmm scratch, but the replica
still lists as being CA-less.
Is what i'm seeing normal? Would this 2-node setup in this state
survive failure of the master?
It will until the certificates start expiring. You want at least 2
CA's to avoid a single point of failure situation.
ON MASTER ipa.localdomain.local
# ipa-replica-manage list
# ipa-csreplica-manage list
>> ipa2.localdomain.local: CA not configured
ON REPLICA ipa2.localdomain.local
Directory Manager (existing master) password:
>> CA is already installed.
# ipa-ca-install -d
ipa.ipaserver.plugins.ldap2.ldap2: DEBUG Created connection
ipa.ipalib.plugins.config.config_show: DEBUG raw:
ipa.ipalib.plugins.config.config_show: DEBUG config_show(rights=False,
all=False, raw=False, version=u'2.156')
ipa.ipapython.ipaldap.SchemaCache: DEBUG retrieving schema for
conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x4516ea8>
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUG raw:
ipa : DEBUG File
line 732, in run_script
return_value = main_function()
File "/usr/sbin/ipa-ca-install", line 204, in main
File "/usr/sbin/ipa-ca-install", line 191, in install_master
ca.install_check(True, None, options)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
49, in install_check
sys.exit("CA is already installed.\n")
ipa : DEBUG The ipa-ca-install command failed, exception:
SystemExit: CA is already installed.
>> CA is already installed.
It detects whether a CA is installed by the existence of something
like /var/lib/pki-tomcat/ca. You can use pkidestroy to remove any
remnants that might be left over from some previous failed install.
Or it could be that something wasn't updated properly in LDAP and
there actually is a working CA. You might try manually starting the CA
to see if it comes up, and/or run ipa-csreplica-manage to see if there
are any working agreements.
- cal sawyer
On 09/03/16 16:13, Simo Sorce wrote:
On Wed, 2016-03-09 at 15:59 +0000, Cal Sawyer wrote:
Somehow i picked the wrong cookbook when i provisioned my first (and
only) replica and it lacks CA aso, as pointed out in a recent thread,
creates a single point of failure. Not ready to set up more 2
yet and am still in testing. Is it possible to replicate the master's
CA to the replica without destroying and reprovisioning with
Use ipa-ca-install on the replica.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project