Problem:
Completed a manual install of remote execution following guidance of the documentation for 1.3.
Remote execution appeared to fail, but after recourse to the logs, it transpired that it was the notification callback which was failing and the focus landed on the dynflow config (/etc/smart_proxy_dynflow_core/settings.yml
).
I guessed it was an issue relating to authenticating the https connection, but lacking details of the relevant paths, came to a dead end.
Solution:
In the end, I relented by backing up all my yaml configs, running the automated install, and then restoring them afterwards. Hey presto, everything suddenly worked!
I realised that my hunch was correct as I discovered the following lines inserted in the dynflow config file…
:ssl_ca_file: /etc/puppetlabs/puppet/ssl/certs/ca.pem
:ssl_certificate: /etc/puppetlabs/puppet/ssl/certs/mydomain.org.pem
:ssl_private_key: /etc/puppetlabs/puppet/ssl/private_keys/mydomain.org.pem
Is it worth noting this in a little more detail in the documentation where it mentions “This is done by properly configuring :core_url in /etc/foreman-proxy/settings.d/dynflow.yml and :foreman_url, :listen and :port keys in /etc/smart_proxy_dynflow_core/settings.yml.”
Might it also be worth highlighting the necessity to set the associated ssl parameters and what the potential values might be?
I actually did search for these under the foreman directories, but didn’t think to look under the puppet directories. Certainly a newbie mistake, but one pothole worth filling in for the newcomer?
Thanks again to everyone’s strong support of the Foreman - really excellent project!
Foreman and Proxy plugin versions:
Foreman 1.17
Remote Execution: 1.3