Bug 1567348 - New 6.3 capsule install breaks pulp with Puppet 4
Summary: New 6.3 capsule install breaks pulp with Puppet 4
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Installer
Version: 6.3.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Devendra Singh
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-13 20:33 UTC by Neal Kim
Modified: 2021-06-10 15:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-03 12:54:10 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Neal Kim 2018-04-13 20:33:55 UTC
Description of problem:

Installing a brand new 6.3 capsule with Puppet 4 enabled breaks pulp upon completion.

The installation itself will not report any errors but '/var/log/messages' shows the following error(s):

pulp: celery.worker.consumer:ERROR: (16071-98304) consumer: Cannot connect to qpid://localhost:5671//: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579).

Notice that '/etc/pki/katello/certs/katello-default-ca.crt' ends up being an odd size and group ownership (apache)

-rw-r--r--. 1 root apache 1757 Apr 13 18:46 katello-default-ca.crt

Observe that certificate issuer and subject is from PULP:

$ openssl x509 -in katello-default-ca.crt -issuer -subject
issuer= /CN=rhel75-capsule.example.com/O=PULP
subject= /CN=rhel75-capsule.example.com/O=PULP

Appears to coincide with pulp installation steps (pulp-gen-ca-certificate):

[ INFO 2018-04-13 18:46:14 main]  /Stage[main]/Pulp::Config/Exec[run pulp-gen-ca]: Starting to evaluate the resource
[DEBUG 2018-04-13 18:46:14 main]  Exec[run pulp-gen-ca](provider=posix): Executing '/usr/bin/pulp-gen-ca-certificate'
[DEBUG 2018-04-13 18:46:14 main]  Executing: '/usr/bin/pulp-gen-ca-certificate'
[ WARN 2018-04-13 18:46:15 main]  /Stage[main]/Pulp::Config/Exec[run pulp-gen-ca]/returns: executed successfully
[DEBUG 2018-04-13 18:46:15 main]  /Stage[main]/Pulp::Config/Exec[run pulp-gen-ca]: The container Class[Pulp::Config] will propagate my refresh event
[DEBUG 2018-04-13 18:46:15 main]  Exec[run pulp-gen-ca](provider=posix): Executing '/usr/bin/pulp-gen-ca-certificate'
[DEBUG 2018-04-13 18:46:15 main]  Executing: '/usr/bin/pulp-gen-ca-certificate'
[ WARN 2018-04-13 18:46:15 main]  /Stage[main]/Pulp::Config/Exec[run pulp-gen-ca]: Triggered 'refresh' from 1 events
[DEBUG 2018-04-13 18:46:15 main]  /Stage[main]/Pulp::Config/Exec[run pulp-gen-ca]: The container Class[Pulp::Config] will propagate my refresh event
[ INFO 2018-04-13 18:46:15 main]  /Stage[main]/Pulp::Config/Exec[run pulp-gen-ca]: Evaluated in 0.35 seconds

Depending on the order of operations it is possible that `pulp-gen-ca-certificate` will clobber '/etc/pki/katello/certs/katello-default-ca.crt':

$ /usr/bin/pulp-gen-ca-certificate
+ set -e
++ cat
+ READ_PULP_CONF='from pulp.server.config import config as pulp_conf
print pulp_conf.get('\''security'\'', '\''cakey'\'')
print pulp_conf.get('\''security'\'', '\''cacert'\'')'
+ PULP_CONF=(`python -c "$READ_PULP_CONF"`)
++ python -c 'from pulp.server.config import config as pulp_conf
print pulp_conf.get('\''security'\'', '\''cakey'\'')
print pulp_conf.get('\''security'\'', '\''cacert'\'')'
++ mktemp -d
+ TMP=/tmp/tmp.eaCQiLPSsZ
+ CA_KEY=/etc/pki/pulp/ca.key
+ CA_CRT=/etc/pki/katello/certs/katello-default-ca.crt
++ hostname --fqdn
+ CN=rhel75-capsule.example.com
+ ORG=PULP
+ '[' -f /etc/pki/pulp/ca.key ']'
+ umask 027
+ openssl genrsa -out /etc/pki/pulp/ca.key 4096
+ chgrp apache /etc/pki/pulp/ca.key
+ openssl req -new -key /etc/pki/pulp/ca.key -out /tmp/tmp.eaCQiLPSsZ/ca.req -subj /CN=rhel75-capsule.example.com/O=PULP
+ openssl x509 -req -days 7035 -sha1 -extensions ca -signkey /etc/pki/pulp/ca.key -in /tmp/tmp.eaCQiLPSsZ/ca.req -out /etc/pki/katello/certs/katello-default-ca.crt
+ chgrp apache /etc/pki/katello/certs/katello-default-ca.crt
+ rm /tmp/tmp.eaCQiLPSsZ/ca.req
+ rmdir /tmp/tmp.eaCQiLPSsZ
+ echo 'Created: /etc/pki/pulp/ca.key and /etc/pki/katello/certs/katello-default-ca.crt'
Created: /etc/pki/pulp/ca.key and /etc/pki/katello/certs/katello-default-ca.crt

The question is why does this happen with Puppet 4 and not Puppet 3?

Fortunately, the workaround is to simply run the installer again and it will restore the correct katello-default-ca.crt


Version-Release number of selected component (if applicable):

satellite-installer-6.3.0.12-1.el7sat.noarch
puppetserver-2.8.0-1.el7sat.noarch


How reproducible:

Easily, with a brand new 6.3 capsule installation.


Steps to Reproduce:

1. Follow the normal Capsule install procedures outlined in the documentation (https://access.redhat.com/documentation/en-us/red_hat_satellite/6.3/html/installation_guide/installing_capsule_server)

2. Make sure that the Puppet 4 repo is enabled for the Capsule:

# subscription-manager repos \
--enable=rhel-7-server-satellite-capsule-6.3-puppet4-rpms

3. Observe celery.worker.consumer complains about CERTIFICATE_VERIFY_FAILED


Actual results:

Pulp is broken.


Expected results:

Pulp is not broken.


Additional info:

As mentioned before, simply running the installer again will restore the correct '/etc/pki/katello/certs/katello-default-ca.crt'.

Comment 3 Neal Kim 2018-06-21 19:41:22 UTC
I think the case could be made that pulp-gen-ca-certificate could handle this scenario a bit better...

From /usr/bin/pulp-gen-ca-certificate:

# Generate the Pulp CA private key and certificate.
# They are generated only when both do not already exist.

25 if [ -f ${CA_KEY} ] && [ -f ${CA_CRT} ]
26 then
27   echo "Both ${CA_KEY} and ${CA_CRT} already exist."
28   echo "Nothing generated."
29   exit 0
30 fi

Do OpenSSL stuff...

But what if we have just the CA_KEY or CA_CRT?

Comment 5 Bryan Kearney 2019-11-04 14:34:24 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 6 Bryan Kearney 2019-12-03 12:54:10 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.


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