Bug 953488 - CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn ...
Summary: CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 962986 (view as bug list)
Depends On:
Blocks: 1089987
TreeView+ depends on / blocked
 
Reported: 2013-04-18 09:54 UTC by Jan Ščotka
Modified: 2020-01-03 14:49 UTC (History)
14 users (show)

Fixed In Version: freeipa-4.0.2-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1089987 (view as bug list)
Environment:
Last Closed: 2014-09-11 02:43:53 UTC
Type: Bug


Attachments (Terms of Use)
installation log with traceback (185.79 KB, text/plain)
2013-04-18 13:32 UTC, Tomas Dolezal
no flags Details

Description Jan Ščotka 2013-04-18 09:54:42 UTC
Description of problem:
Hi,
I've participated fedora testday
https://fedoraproject.org/wiki/Test_Day:2013-04-18_FreeIPA
and tried command in first testcase:
# ipa-server-install --version
3.2.0.beta1

failed with bug
   Regards
   Honza

...
# ipa-server-install -a Secret123 -p Secret123 --domain=ipa.example.org --realm=IPA.EXAMPLE.ORG --hostname srv1.ipa.example.org --setup-dns --forwarder=10.38.5.26 -U

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the FreeIPA Server.

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)
  * Configure DNS (bind)

To accept the default shown in brackets, press the Enter key.

WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
in favor of ntpd

Warning: skipping DNS resolution of host srv1.ipa.example.org

Warning: hostname srv1.ipa.example.org does not match system hostname localhost.localdomain.
System hostname will be updated during the installation process
to prevent service failures.

Using reverse zone 122.168.192.in-addr.arpa.

The IPA Master Server will be configured with:
Hostname:      srv1.ipa.example.org
IP address:    192.168.122.178
Domain name:   ipa.example.org
Realm name:    IPA.EXAMPLE.ORG

BIND DNS server will be configured to serve IPA domain with:
Forwarders:    10.38.5.26
Reverse zone:  122.168.192.in-addr.arpa.

Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/36]: creating directory server user
  [2/36]: creating directory server instance
  [3/36]: adding default schema
  [4/36]: enabling memberof plugin
  [5/36]: enabling winsync plugin
  [6/36]: configuring replication version plugin
  [7/36]: enabling IPA enrollment plugin
  [8/36]: enabling ldapi
  [9/36]: configuring uniqueness plugin
  [10/36]: configuring uuid plugin
  [11/36]: configuring modrdn plugin
  [12/36]: configuring DNS plugin
  [13/36]: enabling entryUSN plugin
  [14/36]: configuring lockout plugin
  [15/36]: creating indices
  [16/36]: enabling referential integrity plugin
  [17/36]: configuring certmap.conf
  [18/36]: configure autobind for root
  [19/36]: configure new location for managed entries
  [20/36]: restarting directory server
  [21/36]: adding default layout
  [22/36]: adding delegation layout
  [23/36]: creating container for managed entries
  [24/36]: configuring user private groups
  [25/36]: configuring netgroups from hostgroups
  [26/36]: creating default Sudo bind user
  [27/36]: creating default Auto Member layout
  [28/36]: adding range check plugin
  [29/36]: creating default HBAC rule allow_all
  [30/36]: initializing group membership
  [31/36]: adding master entry
  [32/36]: configuring Posix uid/gid generation
  [33/36]: adding replication acis
  [34/36]: enabling compatibility plugin
  [35/36]: tuning directory server
  [36/36]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
  [1/20]: creating certificate server user
  [2/20]: configuring certificate server instance
ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpjsLgeh' returned non-zero exit status 1
Configuration of CA failed

Comment 1 Martin Kosek 2013-04-18 10:09:10 UTC
Please include /var/log/ipaserver-install.log so that we can see what's wrong.

Comment 2 Martin Kosek 2013-04-18 10:36:35 UTC
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

Comment 3 Tomas Babej 2013-04-18 12:17:28 UTC
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.

Comment 4 Tomas Babej 2013-04-18 12:22:34 UTC
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

Comment 5 Martin Kosek 2013-04-18 12:23:48 UTC
You are right, I will link this bug with upstream ticket 2796 that was already opened for this issue, we should handle it there.

Comment 6 Martin Kosek 2013-04-18 12:24:28 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2796

Comment 7 Tomas Dolezal 2013-04-18 13:31:12 UTC
I encountered the same problem
attaching /var/log/ipaserver-install.log

Comment 8 Tomas Dolezal 2013-04-18 13:32:21 UTC
Created attachment 737307 [details]
installation log with traceback

Comment 9 Mateusz Marzantowicz 2013-09-21 10:37:59 UTC
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.

Comment 10 Glenn L. Jenkins 2013-09-29 11:05:31 UTC
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!

Comment 11 Artur Szymczak 2013-10-03 14:18:48 UTC
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 ---

Comment 12 Artur Szymczak 2013-10-03 14:42:43 UTC
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).

Comment 13 Artur Szymczak 2013-10-03 15:51:39 UTC
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.

Comment 14 Martin Kosek 2013-10-04 15:44:08 UTC
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

Comment 15 Nathan Kinder 2013-10-04 15:51:30 UTC
(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.

Comment 16 Nathan Kinder 2013-10-04 18:13:51 UTC
(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

Comment 17 Nathan Kinder 2013-10-04 18:27:06 UTC
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.

Comment 18 Martin Kosek 2013-10-07 07:06:14 UTC
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?

Comment 19 Petr Viktorin 2013-10-07 08:01:45 UTC
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).

Comment 20 Nathan Kinder 2013-10-07 21:09:14 UTC
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.

Comment 21 Martin Kosek 2013-10-08 07:03:51 UTC
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'}

Comment 22 Nathan Kinder 2013-10-08 18:41:43 UTC
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.

Comment 23 Nathan Kinder 2013-10-08 20:44:19 UTC
(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.

Comment 24 Nathan Kinder 2013-10-08 22:29:58 UTC
(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

Comment 25 Martin Kosek 2013-10-09 07:49:31 UTC
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.

Comment 26 Nathan Kinder 2013-10-09 15:44:52 UTC
(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.

Comment 27 Nathan Kinder 2013-10-09 17:56:20 UTC
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.

Comment 28 Martin Kosek 2013-10-10 07:28:03 UTC
That's possible. When a fixed Dogtag allowing '%' comes in, we should also test for other characters and remove then eventually from backlog.

Comment 29 Martin Kosek 2013-10-10 07:28:48 UTC
(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/

Comment 30 Nathan Kinder 2013-10-10 18:52:01 UTC
*** Bug 962986 has been marked as a duplicate of this bug. ***

Comment 33 Fedora Update System 2014-09-08 08:14:40 UTC
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

Comment 34 Fedora Update System 2014-09-08 16:09:44 UTC
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).

Comment 35 Fedora Update System 2014-09-11 02:43:53 UTC
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.

Comment 36 JJNR 2014-11-10 12:20:45 UTC
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.

Comment 37 Glenn L. Jenkins 2014-11-10 15:32:27 UTC
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

Comment 38 JJNR 2014-11-12 11:43:36 UTC
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

Comment 39 Alexander Bokovoy 2014-11-12 11:56:36 UTC
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.

Comment 40 JJNR 2014-11-21 12:44:24 UTC
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.

Comment 41 JJNR 2014-11-21 12:44:55 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.