Split installation into three distinct phases #119
Conversation
Signed-off-by: Eric D. Helms <[email protected]>
| package: | ||
| name: foreman-proxy | ||
|
|
||
| - name: Deploy default certificates |
There was a problem hiding this comment.
Assuming this is temporarily, given the current installer can't deal well with "proxy only certs for the internal proxy" scenario, what would be the most elegant way for us to pass those certs on?
Part of me wants to say "the tarball we have for external proxies is nice", but given that we don't need to transfer it across systems, it's not strictly required to be a single file (which adds complexity).
We could set the API to be "a folder with a specified structure" (think like the one in ssl-build), but put it soemwhere like /var/lib/foreman-certs and it either gets fed by foreman-certs cli or the certificates role, and then everyone can just pick up things from there.
For the external proxy we'd then tar things up that resemble the same structure and off we go.
There was a problem hiding this comment.
This is tricky because there is this unfun orchestration that has to happen as shown here. The certificates need to be deployed to a location with the correct ownership (user/group/mode) access by foreman-proxy. Which means the foreman-proxy RPM needs to be installed or something needs to ensure creation of them.
For foreman-installer based certificates, I proposed fixing that with this class https://github.com/theforeman/puppet-certs/pull/449/files#diff-e6327449f108163297d1ce69ca08f3a4d8013b01d772a4be3aba628b223bd8c5 and adding it to the answers file. This wouldn't solve it for the new certificate generation though.
I was also thinking of adding certificate "management" to puppet-foreman_proxy based on a parameter so that the module could ensure the right user/group and permissions are ensured on the certificates. I tried this idea out like 4 years ago -- theforeman/puppet-foreman_proxy#599
There was a problem hiding this comment.
I updated theforeman/puppet-foreman_proxy#599 idea to our current certificates approach.
2 participants
Another look at splitting the installation process into three distinct phases. This does use Ansible, but that's just to help orchestrate and automate for testing purposes. The playbook is split into three sections:
The foreman-proxy is not optional at this point. That would require #81I rebased this on #105 to have the Pulp smart-proxy and thus make the stand-alone smart-proxy optional.