Bug 1122623 - Install fails if host puppet certs have already been generated
Summary: Install fails if host puppet certs have already been generated
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Installer
Version: 6.0.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Martin Bacovsky
QA Contact: Andrew Kofink
URL: http://projects.theforeman.org/issues...
Whiteboard:
: 1187264 (view as bug list)
Depends On:
Blocks: GSS_Sat6Beta_Tracker, GSS_Sat6_Tracker sat61-release-notes
TreeView+ depends on / blocked
 
Reported: 2014-07-23 16:13 UTC by Justin Sherrill
Modified: 2019-09-12 07:56 UTC (History)
16 users (show)

Fixed In Version: katello-installer-base-3.0.0.50-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-27 11:14:34 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 15241 None None None 2016-05-31 14:06:30 UTC
Red Hat Knowledge Base (Solution) 1276043 None None None Never
Red Hat Knowledge Base (Solution) 1336673 Troubleshoot None Satellite 6 Capsule installation fails when already registered to the puppet master with the error: "Failed to call refr... 2019-04-16 14:33:45 UTC

Description Justin Sherrill 2014-07-23 16:13:03 UTC
Description of problem:

When installing sat6, if puppet has been run at anytime on the host prior (such as in an environment where the normal bootstrap process involves running puppet), the host specific certs are generated:

/var/lib/puppet/ssl/private_keys/$HOSTNAME.pem 

but the ca cert is not generated:

 /var/lib/puppet/ssl/ca/ca_crt.pem

When the installer runs and attempts to generate the certs, puppet will not generate the ca cert since the host pem files already exist.  It also does not seem to error in anyway.  The result is that the install fails because httpd won't start:

 Could not start Service[httpd]: Execution of '/usr/share/katello-installer/modules/service_wait/bin/service-wait httpd start' returned 1: Starting httpd: [Tue Jul 22 12:49:31 2014] [warn] module passenger_module is already loaded, skipping
/Stage[main]/Foreman::Database/Foreman::Rake[db:seed]/Exec[foreman-rake-db:seed]: Failed to call refresh: /usr/sbin/foreman-rake db:seed returned 1 instead of one of [0]

Restarting httpd by hand reveals the error:

$ service httpd start

Starting httpd: [Tue Jul 22 18:06:27 2014] [warn] module passenger_module is already loaded, skipping

Syntax error on line 39 of /etc/httpd/conf.d/25-puppet.conf:

SSLCertificateChainFile: file '/var/lib/puppet/ssl/ca/ca_crt.pem' does not exist or is empty

                                                           [FAILED]



How reproducible:
Always

Steps to Reproduce:
1.  Install a new system
2.  run puppet on it
3.  verify that /var/lib/puppet/ssl/private_keys/$HOSTNAME.pem  was created
4.  Attempt to install satellite 6

Actual results:
Failure

Expected results:
Either the installer needs to error immediately with cleanup instructions, or it should handle this case and install fine

Comment 5 Martin Bacovsky 2015-06-09 20:34:45 UTC
Created redmine issue http://projects.theforeman.org/issues/10766 from this bug

Comment 6 Martin Bacovsky 2015-06-09 21:06:44 UTC
Puppet is not able to generate proper CA certificates when the client certificate was already generated. In practice it checks if the /var/lib/puppet/ssl exists and if so it skips the CA cert generation.

With the existing possibility of having custom ssl dir and existing puppet CA elsewhere it is difficult to detect the situation.
With the default installation the installer fails to start httpd on missing

- revocation list for foreman apache (/var/lib/puppet/ssl/ca/ca_crl.pem)
- ca cert when installed with passenger and puppet ran as master (/var/lib/puppet/ssl/ca/ca_crt.pem)

My proposal is to add hook guessing if these these two files will be missing and failing with suggestion of possible fixes.

The PR with the hook was pushed to foreman-installer for review and discussion and can be eventually used in katello installer and Satellite installer.

Comment 9 Olivier Contant 2015-09-15 22:04:53 UTC
I think it would be welcome to have an argument to cleanup the environment after a failed install attempt. 

I faced the issue described here and tried to reinstall 2-3 times before I find this post and the release note.  

Result, there is more to clean up on a multiple install attempt than the puppet ssl folder when thing didn't work from the first time and one tried to troubleshoot it. 

Would it be possible to create a cleanup flag that would reset the environment to as if the package just been installed and kastelo-installer never ran?

Comment 10 Pavel Moravec 2015-09-25 14:33:49 UTC
Just a note: same applies to capsule-installer so a fix needs to be applicable to Capsule installation as well.

Comment 11 David O'Brien 2016-04-18 00:48:49 UTC
Reset docs contact <> daobrien

Comment 14 Martin Bacovsky 2016-05-31 13:33:44 UTC
Created redmine issue http://projects.theforeman.org/issues/15241 from this bug

Comment 15 Martin Bacovsky 2016-05-31 14:00:59 UTC
As installer hooks are not shared among Foreman and Katello/Satellite scenarios I proposed the same patch also to Katello installer.

Comment 17 Bryan Kearney 2016-07-05 20:02:06 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/15241 has been closed

Comment 18 Andrew Kofink 2016-07-11 13:41:50 UTC
Verified.
Version tested: satellite-6.2.0-19.1.el7sat.noarch

After installing puppet and ensuring the ssl certificate was created, installing Satellite yields the following expected output:

The file /var/lib/puppet/ssl/certs/ca.pem does not exist.
 - is Puppet already installed without Puppet CA? You can remove the existing certificates with 'rm -rf /var/lib/puppet/ssl' to get Puppet CA properly configured.
 - if you use custom Puppet SSL directory (--foreman-proxy-ssldir) make sure the directory exists and contain the CA certificate.

Comment 19 Bryan Kearney 2016-07-27 11:14:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1501

Comment 20 Ivan Necas 2016-08-16 11:16:13 UTC
*** Bug 1187264 has been marked as a duplicate of this bug. ***


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