Please include /var/log/ipaserver-install.log so that we can see what's wrong.

By the way, if you hit an issue with CA not installed, install 'java-atk-wrapper' and remove broken PKI install before re-installing

To remove broken PKI install, do following:
rm -rf /var/log/pki/pki-tomcat
rm -rf /etc/sysconfig/pki-tomcat
rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
rm -rf /var/lib/pki/pki-tomcat
rm -rf /etc/pki/pki-tomcat

I encountered the same issue. Relevant part of the log:

2013-04-18T12:11:05Z DEBUG Starting external process
2013-04-18T12:11:05Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp_RHd8e
2013-04-18T12:11:07Z DEBUG Process finished, return code=1
2013-04-18T12:11:07Z DEBUG stdout=
2013-04-18T12:11:07Z DEBUG stderr=pkispawn    : ERROR    ....... PKI subsystem 'CA' for instance 'pki-tomcat' already exists!

2013-04-18T12:11:07Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp_RHd8e' returned non-zero exit status 1
2013-04-18T12:11:07Z INFO   File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 613, in run_script
    return_value = main_function()

  File "/sbin/ipa-server-install", line 1022, in main
    dm_password, subject_base=options.subject)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 617, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 362, in start_creation
    method()

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 735, in __spawn_instance
    raise RuntimeError('Configuration of CA failed')

2013-04-18T12:11:07Z INFO The ipa-server-install command failed, exception: RuntimeError: Configuration of CA failed

Looks like CA instance has not been properly cleaned up.

Removing CA manually solved the issue for me: 

pkidestroy -s CA -i pki-tomcat
rm -rf /var/log/pki/pki-tomcat
rm -rf /etc/sysconfig/pki-tomcat
rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
rm -rf /var/lib/pki/pki-tomcat
rm -rf /etc/pki/pki-tomcat

You are right, I will link this bug with upstream ticket 2796 that was already opened for this issue, we should handle it there.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2796

I encountered the same problem
attaching /var/log/ipaserver-install.log

Created attachment 737307 [details]
installation log with traceback

I tink this bug is fixed in F20 with pki-ca-10.1.0-0.10.fc20.noarch . I don't  know if there is another bug report for f20 (this one is for f19) but it might be closed as resolved.

I've spent many long hours struggling with freeipa especially the server install.  I've seen this problem and one very similar too it and I think my experiences my help here.  

As Jan suggest if the installer has run previously or for some other reason pki-tomcat exists the install fails with 

 CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpjsLgeh' returned non-zero exit status 1

The install log in which case shows 

2013-04-18T12:11:07Z DEBUG stderr=pkispawn    : ERROR    ....... PKI subsystem 'CA' for instance 'pki-tomcat' already exists!

I have seen a very similar initial error message "CRITICAL failed" etc. with a different message in the install log, suggesting that the ca server (dogtag or whatever) has not been restarted.  I tried to verify this and found it was restarted (systemctl status pki-tomcatd)  after many hours I the issue turned out to be simple.  

I work at a university and my lab is behind a firewall, I use HTTP_PROXY, HTTPS_PROXY etc. to point yum at the proxy servers to get out of the network.  It seems when the IPA installer looks for the ca server it goes out on the proxy. The proxy does not respect the internal DNS for my lab so can't resolve the address for my IPA server.  Taking out the HTTP and HTTPS_PROXY variables (setting to blank) solves the problem and the install proceeds with out issue.  

I didn't keep the error logs for this, but the bug should be easy to reproduce. 

I hope this helps others, I've actually run into this bug two years running and failed to document the solution!

Problem still exist in Fedora-20 (freeipa-server-3.3.1-1.fc20.i686).

I used this command line to install IPA (just removed my e-mail):
# ipa-server-install -r AJS7 -n ajs7 --hostname=serwer.ajs7 --idstart=7000000 --no_hbac_allow --ssh-trust-dns --setup-dns --forwarder=62.179.1.62 --forwarder=62.179.1.63 --zonemgr=artur@.....

And informations from logfile:

--- START_LOG ---
2013-10-03T13:59:25Z DEBUG stderr=
2013-10-03T13:59:25Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2013-10-03T13:59:25Z DEBUG Starting external process
2013-10-03T13:59:25Z DEBUG args=/bin/systemctl disable dirsrv.target
2013-10-03T13:59:26Z DEBUG Process finished, return code=0
2013-10-03T13:59:26Z DEBUG stdout=
2013-10-03T13:59:26Z DEBUG stderr=
2013-10-03T13:59:26Z DEBUG   duration: 0 seconds
2013-10-03T13:59:26Z DEBUG Done configuring directory server (dirsrv).
2013-10-03T13:59:26Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2013-10-03T13:59:26Z DEBUG Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
2013-10-03T13:59:26Z DEBUG   [1/22]: creating certificate server user
2013-10-03T13:59:26Z DEBUG ca user pkiuser exists
2013-10-03T13:59:26Z DEBUG   duration: 0 seconds
2013-10-03T13:59:26Z DEBUG   [2/22]: configuring certificate server instance
2013-10-03T13:59:26Z DEBUG Contents of pkispawn configuration file (/tmp/tmpcsL_MS):
[CA]
pki_security_domain_name = IPA
pki_enable_proxy = True
pki_restart_configured_instance = False
pki_backup_keys = True
pki_backup_password = XXXXXXXX
pki_client_database_dir = /tmp/tmp-erRrnD
pki_client_database_password = XXXXXXXX
pki_client_database_purge = False
pki_client_pkcs12_password = XXXXXXXX
pki_admin_name = admin
pki_admin_uid = admin
pki_admin_email = root@localhost
pki_admin_password = XXXXXXXX
pki_admin_nickname = ipa-ca-agent
pki_admin_subject_dn = cn=ipa-ca-agent,O=AJS7
pki_client_admin_cert_p12 = /root/ca-agent.p12
pki_ds_ldap_port = 389
pki_ds_password = XXXXXXXX
pki_ds_base_dn = o=ipaca
pki_ds_database = ipaca
pki_subsystem_subject_dn = cn=CA Subsystem,O=AJS7
pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=AJS7
pki_ssl_server_subject_dn = cn=serwer.ajs7,O=AJS7
pki_audit_signing_subject_dn = cn=CA Audit,O=AJS7
pki_ca_signing_subject_dn = cn=Certificate Authority,O=AJS7
pki_subsystem_nickname = subsystemCert cert-pki-ca
pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca
pki_ssl_server_nickname = Server-Cert cert-pki-ca
pki_audit_signing_nickname = auditSigningCert cert-pki-ca
pki_ca_signing_nickname = caSigningCert cert-pki-ca


2013-10-03T13:59:26Z DEBUG Starting external process
2013-10-03T13:59:26Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpcsL_MS
2013-10-03T13:59:27Z DEBUG Process finished, return code=1
2013-10-03T13:59:27Z DEBUG stdout=Loading deployment configuration from /tmp/tmpcsL_MS.

2013-10-03T13:59:27Z DEBUG stderr=Traceback (most recent call last):
  File "/usr/sbin/pkispawn", line 452, in <module>
    main(sys.argv)
  File "/usr/sbin/pkispawn", line 318, in main
    parser.compose_pki_master_dictionary()
  File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 459, in compose_pki_master_dictionary
    self.flatten_master_dict()
  File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 355, in flatten_master_dict
    subsystem_dict = dict(self.pki_config.items(config.pki_subsystem))
  File "/usr/lib/python2.7/ConfigParser.py", line 655, in items
    for option in options]
  File "/usr/lib/python2.7/ConfigParser.py", line 691, in _interpolate
    self._interpolate_some(option, L, rawval, section, vars, 1)
  File "/usr/lib/python2.7/ConfigParser.py", line 732, in _interpolate_some
    "'%%' must be followed by '%%' or '(', found: %r" % (rest,))
ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%'

2013-10-03T13:59:27Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpcsL_MS' returned non-zero exit status 1
2013-10-03T13:59:27Z DEBUG   File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script
    return_value = main_function()

  File "/sbin/ipa-server-install", line 1022, in main
    dm_password, subject_base=options.subject)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance
    self.start_creation(runtime=210)

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

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance
    raise RuntimeError('Configuration of CA failed')

2013-10-03T13:59:27Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Configuration of CA failed
--- END_LOG ---

But, after steps provided by Tomas and Martin:
# pkidestroy -s CA -i pki-tomcat
ERROR:  PKI instance '/var/lib/pki/pki-tomcat' does NOT exist!
# rm -rf /var/log/pki/pki-tomcat
# rm -rf /etc/sysconfig/pki-tomcat
# rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
# rm -rf /var/lib/pki/pki-tomcat
# rm -rf /etc/pki/pki-tomcat
# ipa-server-install --uninstall

and reruning installation, all works fine. (I also disabled dns resolution for installation time).

Ok, my problem was related to ... password. If you use password (don't know yet if it is IPA admin or Directory Manager) containing % (percent) then PKI will fail.

Thanks for information, sorry for inconvenience. Nathan, I think this is something that should be fixed in pkispawn. There seems to be some flawed processing of the DM password value. I am not sure if PKI already has a ticket for this issue.

As for FreeIPA, I at least updated ipa-server-install to forbid '%' character in DM password until this is fixed:

master: https://fedorahosted.org/freeipa/changeset/1480cf1603a2292d2636562f06ad12cb8c86fe6d
ipa-3-3: https://fedorahosted.org/freeipa/changeset/cdae86ca461b1cf8895b33d9338d670610b30747

(In reply to Martin Kosek from comment #14)
> Thanks for information, sorry for inconvenience. Nathan, I think this is
> something that should be fixed in pkispawn. There seems to be some flawed
> processing of the DM password value. I am not sure if PKI already has a
> ticket for this issue.

I agree.  I'm working on reproducing this with standalone Dogtag as I type this.  I will file a ticket in Dogtag's trac for this.  The problem seems to be related to the parsing for interpolation of variables in pkispawn deployment files.

(In reply to Nathan Kinder from comment #15)
> I agree.  I'm working on reproducing this with standalone Dogtag as I type
> this.  I will file a ticket in Dogtag's trac for this.  The problem seems to
> be related to the parsing for interpolation of variables in pkispawn
> deployment files.

This is logged as an upstream Dogtag ticket:

  https://fedorahosted.org/pki/ticket/755

There is an easy solution to using '%' in values in the pkispawn deployment file that IPA would be able to handle.  The '%' character is used for interpolation in Python's ConfigParser class.  To use a '%' character in a config value where you are not trying to do interpolation, you simply need to escape the character with a second '%'.  For example, the following pkispawn deployment file works fine:

----------------------------------------
[DEFAULT]
pki_admin_password=Secret%%12
pki_client_pkcs12_password=Secret%%12
pki_ds_password=Secret%%12
----------------------------------------

Since IPA creates the deployment file used by pkispawn, it should be able to deal with this escaping.  I think this is a better solution than not allowing '%' characters to be used in passwords.

This needs to be discussed further on the Dogtag side, but the actual solution might just be to document that escaping is needed for '%' characters in pkispawn deployment files.

Thanks Nathan for investigation. I think there are more sensitive values than just '%' - we already have an active workaround in ipa-server-install not allowing ' ', '&', '\', '<' and '%' characters.

I think we need to do something about that. I am not convinced that IPA should do the escaping and special handling of the password values. What do you mean by 'interpolation'? Does it make sense to do it for password values? To me, these are just plain text values. Could IPA maybe wrap the password value in quotes? Would that help?

Martin, ConfigParser interpolation is described in http://docs.python.org/2/library/configparser.html - quoting won't help.

Perhaps for passwords Dogtag should use ConfigParser.get(..., raw=True).

I don't think we can change the code that fetches the passwords to get around this issue.

The exception occurs when we simply try to create a dict used for pkispawn from the contents of the deployment config file.  This '%' character causes a syntax error with ConfigParser, as it expects unscaped '%' characters to only be used for interpolation.  We are not even to the point where we are trying to access individual config settings.  We do leverage interpolation in a number of our config settings, so we need to support that functionality.  I don't think there is a way to have a special case around the password settings.

I did few tests with ConfigParser and the PKI code, could we do something like this?

$ cat /tmp/dogtag.conf
[DEFAULT]
password=mystrangedogtag%pwd
want_interpolation=%(foo)sbar

$ python
>>> import ConfigParser
>>> parser = ConfigParser.SafeConfigParser({'foo':'bar'})
>>> with open('/tmp/dogtag.conf') as f: parser.readfp(f)
... 
>>> results = {}
>>> no_interpolation = ('password',)
>>> for key,val in parser.items('DEFAULT', raw=True):
...     raw = key in no_interpolation
...     results[key] = parser.get('DEFAULT', key, raw)
... 
>>> results
{'want_interpolation': 'barbar', 'password': 'mystrangedogtag%pwd', 'foo': 'bar'}

I can make the approach work that is described in comment#21.  We just need to manually iterate through our settings and use ConfigParser.get() with the appropriate raw option instead of using ConfigParser.items() as we do now.

I still need to do a bit more testing to make sure that this doesn't cause problems for interactive pkispawn usage, but the initial tests are positive.

(In reply to Nathan Kinder from comment #22)
> I can make the approach work that is described in comment#21.  We just need
> to manually iterate through our settings and use ConfigParser.get() with the
> appropriate raw option instead of using ConfigParser.items() as we do now.
> 
> I still need to do a bit more testing to make sure that this doesn't cause
> problems for interactive pkispawn usage, but the initial tests are positive.

This approach breaks interactive pkispawn.  The code currently escapes the password values that are supplied interactively.  We must do this escaping, as ConfigParser.set() requires it, which is the method we use to add it to the dict.  There is no raw option for ConfigParser.set, and we can't use RawConfigParser since we require interpolation for other values.

The difficulty is that the code that flattens the installation dict can't tell which options were supplied interactively, and which were supplied from a deployment file.  This means that this code would need to see if a password value has unescaped "%" characters and deal with escaping them itself.  This works in the case of a deployment config file.  The problem is that we can't differentiate between a real password of "foo%%bar" and an escaped password of "foo%bar" (which is escaped as "foo%%bar").

This is a solvable problem, but it's going to require some surgery or a different approach.  Perhaps it would be easier to check if any of the password settings were supplied in a deployment file immediately after reading it, then replace the value in the dict with an escaped value.  Using this approach would allow the interactive code and the dict flattening code to remain how it is currently.

(In reply to Nathan Kinder from comment #23)
> Perhaps it would be easier to check if any of the
> password settings were supplied in a deployment file immediately after
> reading it, then replace the value in the dict with an escaped value.  Using
> this approach would allow the interactive code and the dict flattening code
> to remain how it is currently.

I have been able to get things working with this approach for both deployment file based installs as well as interactive installs.  This is being tracked upstream for Dogtag as this ticket:

    https://fedorahosted.org/pki/ticket/757

Thanks Nathan!

I checked the patch, I am just thinking this will fix only occurrence of '%' character. However, in ipa-server-install we have to also block ' ', '&', '\', '<' characters and I assume they will still keep failing, despite the proposed patch.

(In reply to Martin Kosek from comment #25)
> Thanks Nathan!
> 
> I checked the patch, I am just thinking this will fix only occurrence of '%'
> character. However, in ipa-server-install we have to also block ' ', '&',
> '\', '<' characters and I assume they will still keep failing, despite the
> proposed patch.

Do they fail because of the same cause?  We would need to see what the exact problem is with those characters and which component doesn't deal with them.  That should probably be dealt with in a separate bug, as I don't believe that it is a problem related to pkispawn.

I also did a quick test using the '&' character in the CA admin and Directory Manager password, and it worked just fine for a Dogtag install  (I didn't try it with FreeIPA though).  Perhaps there was some earlier problem with those characters in Dogtag 9 that work now with Dogtag 10.

That's possible. When a fixed Dogtag allowing '%' comes in, we should also test for other characters and remove then eventually from backlog.

(In reply to Martin Kosek from comment #28)
> That's possible. When a fixed Dogtag allowing '%' comes in, we should also
> test for other characters and remove then eventually from backlog.

s/backlog/blacklist in ipa-server-install/

*** Bug 962986 has been marked as a duplicate of this bug. ***

Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/41b057e38757c0acf1d600245269851f532df389
ipa-4-1:
https://fedorahosted.org/freeipa/changeset/41b057e38757c0acf1d600245269851f532df389
ipa-4-0:
https://fedorahosted.org/freeipa/changeset/41b057e38757c0acf1d600245269851f532df389

freeipa-4.0.2-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/freeipa-4.0.2-1.fc21

Package freeipa-4.0.2-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing freeipa-4.0.2-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10298/freeipa-4.0.2-1.fc21
then log in and leave karma (feedback).

freeipa-4.0.2-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Hello everyone.

I am quite new to this forum.

I have tried to run freeipa for the last two weeks... 
(in my organization doing it with redhat is impossible due to license restrictions, so I trie to create a pilot with fedora).

I have gone through fc18, fc19, fc20 and fc21.

Last freeipa package i tried to work with was: freeipa-4.0.3-1.fc21 and it causes to have the same problem you describe.

I do not use any % character for passwords.

Is there anything else I can do?

Regards.

Hi JJNR, 

if you check your HTTP_PROXY and HTTPS_PROXY and have them set for some reason, then unset them before running the ipa-server-install command. 

e.g. 

if 

echo $HTTP_PROXY
192.168.1.44:3128

try

HTTP_PROXY=

before calling ipa-server-install


Regards, 

Glenn

Thanks.

No way either.

I am running fc21 in virtual with vmware player.

I am testing in a system where without proxy there is host only network, the system will get to nowhere.

If i could make this work ( i have lost all hope) it will be running in virtual too, but in a differente physical device, so virtual is mandatory for me.

The errors in my /var/log are these:

 - I run ipa-server-install --no-ntp


ipaserver-install.log is like this:

[CA]
pki_security_domain_name = IPA
pki_enable_proxy = True
pki_restart_configured_instance = False
pki_backup_keys = True
pki_backup_password = XXXXXXXX
pki_client_database_dir = /tmp/tmp-AVW1Bf
pki_client_database_password = XXXXXXXX
pki_client_database_purge = False
pki_client_pkcs12_password = XXXXXXXX
pki_admin_name = admin
pki_admin_uid = admin
pki_admin_email = root@localhost
pki_admin_password = XXXXXXXX
pki_admin_nickname = ipa-ca-agent
pki_admin_subject_dn = cn=ipa-ca-agent,O=FAKEDOMAIN.COM
pki_client_admin_cert_p12 = /root/ca-agent.p12
pki_ds_ldap_port = 389
pki_ds_password = XXXXXXXX
pki_ds_base_dn = o=ipaca
pki_ds_database = ipaca
pki_subsystem_subject_dn = cn=CA Subsystem,O=FAKEDOMAIN.COM
pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=FAKEDOMAIN.COM
pki_ssl_server_subject_dn = cn=fipams.fakedomain.com,O=FAKEDOMAIN.COM
pki_audit_signing_subject_dn = cn=CA Audit,O=FAKEDOMAIN.COM
pki_ca_signing_subject_dn = cn=Certificate Authority,O=FAKEDOMAIN.COM
pki_subsystem_nickname = subsystemCert cert-pki-ca
pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca
pki_ssl_server_nickname = Server-Cert cert-pki-ca
pki_audit_signing_nickname = auditSigningCert cert-pki-ca
pki_ca_signing_nickname = caSigningCert cert-pki-ca
pki_ca_signing_key_algorithm = SHA256withRSA


2014-11-11T11:24:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2014-11-11T11:24:43Z DEBUG Starting external process
2014-11-11T11:24:43Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpbvAymO'
2014-11-11T11:24:46Z DEBUG Process finished, return code=1
2014-11-11T11:24:46Z DEBUG stdout=Loading deployment configuration from /tmp/tmpbvAymO.
Installing CA into /var/lib/pki/pki-tomcat.

Installation failed.


2014-11-11T11:24:46Z DEBUG stderr=pkispawn    : ERROR    ....... PKI instance 'pki-tomcat' would produce a namespace collision with '/etc/pki/pki-tomcat'!

2014-11-11T11:24:46Z CRITICAL failed to configure ca instance Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpbvAymO'' returned non-zero exit status 1
2014-11-11T11:24:46Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation
    run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step
    method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 671, in __spawn_instance
    raise RuntimeError('Configuration of CA failed')
RuntimeError: Configuration of CA failed

2014-11-11T11:24:46Z DEBUG   [error] RuntimeError: Configuration of CA failed
2014-11-11T11:24:46Z DEBUG   File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 642, in run_script
    return_value = main_function()

  File "/sbin/ipa-server-install", line 1181, in main
    ca_signing_algorithm=options.ca_signing_algorithm)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 518, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation
    run_step(full_msg, method)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step
    method()

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 671, in __spawn_instance
    raise RuntimeError('Configuration of CA failed')

2014-11-11T11:24:46Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Configuration of CA failed

According to


2014-11-11T11:24:46Z DEBUG stderr=pkispawn    : ERROR    ....... PKI instance 'pki-tomcat' would produce a namespace collision with '/etc/pki/pki-tomcat'!

you have already tried to install PKI (FreeIPA) on this host and it failed in the middle, leaving half-configured parts of PKI instance. These remnants are getting in the way.

You need to remove the instance leftover completely:

pkidestroy -s CA -i pki-tomcat
rm -rf /var/log/pki/pki-tomcat
rm -rf /etc/sysconfig/pki-tomcat
rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
rm -rf /var/lib/pki/pki-tomcat
rm -rf /etc/pki/pki-tomcat

then run 

ipa-server-install --uninstall

reboot the VM and start again.

Hi again.

That did not work.

I removed everything, and install a new machine.

I set the ip static.

I set the DNS properly, to use external DNS servers, which will be the real situation if i can make this work.

I checked open ports.

After setting these things (maybe everyone gave for granted that all previous requirements were met, even when i only wanted to test...), after checking everything, i installed freeipa-server.

Then use ipa-server-install --no-ntp on my virtual environment.

As far as I can know now, it has worked.

Now i will start the tests.

Thanks to everyone for your time.

Hi again.

That did not work.

I removed everything, and install a new machine.

I set the ip static.

I set the DNS properly, to use external DNS servers, which will be the real situation if i can make this work.

I checked open ports.

After setting these things (maybe everyone gave for granted that all previous requirements were met, even when i only wanted to test...), after checking everything, i installed freeipa-server.

Then use ipa-server-install --no-ntp on my virtual environment.

As far as I can know now, it has worked.

Now i will start the tests.

Thanks to everyone for your time.