Hi everybody,
we want to activate the remote execution plugin, but it’s not working correctly at the moment .
Since we’ve build foreman + foreman smart proxy from source, we can neither use the installer nor the puppet modules.
At the moment we’re not really sure whether the way we have set up the environment is correct.
The documentation is unfortunately too imprecise for us.
What we got so far: Foreman
Foreman, build from source + bundler.d/remote_execution.rb with the content: gem 'foreman_remote_execution'
so all necessary gems are installed
Starting Foreman with Puma
Starting redis for dynflow-sidekiq
Starting dynflow-sidekiq@orchestrator.service and dynflow-sidekiq@worker.service with default configuration and the systemd unit file from /path/to/foreman/extras/systemd
=> Foreman and all services are running without any obvious error. But how do the setup look like, if we run forman on N diffent nodes? Do we need a seperate/central redis or dynflow-sidekiq cluster?
Foreman Smart Proxy
Foreman smart proxy build from source. Here it is not 100% clear for us, which extra gem we need. Only the *_core or all (smart_proxy_remote_execution_ssh, smart_proxy_dynflow, smart_proxy_dynflow_core, foreman_remote_execution_core, foreman-tasks-core)
Staring Foreman smart proxy with all gems with puma works fine and Foreman showing the Features “Dynflow” and “SSH”. But do we need to start a seperate dynflow process on the Foreman Smart Proxy? How is it done? Where can we find the dynflow binary?
If you need further data/configurations, please let me know.
This actually depends on you and your needs, you can do both. Someone else was in a similar situation before and I posted more elaborate answer there Foreman Tasks with new Redis support , the same will apply here.
Again, it depends. There are two options. Either you run dynflow inside the smart proxy or you run it as a standalone process.
Either way, you need to load all the relevant non*_core gems into the smart proxy. Those are the ones which define the APIs, settings and features.
The easiest way is to run dynflow inside the smart proxy. For that, you just need to require all the relevant *_core gems and it should be good to go. This is actually the way how things get set up by the installer on deb based platforms.
Alternatively, you could set up smart_proxy_dynflow_core from source (https://github.com/theforeman/smart_proxy_dynflow), require all the *_core gems into it and configure the smart proxy to use this external process (in config/settings.d/dynflow.yml). This is what the installer does on EL* based platforms.
Both ways have its pros and cons, the internal dynflow is easier to deploy, but if under heavy load it could have negative impact on other smart proxy functionality.
So we tried the “All-in-one solution”, but yet it doesnt work :/.
Currently we get the following error:
2020-08-07T10:24:27 24c52b5f [I] Started GET /dynflow/tasks/count state=running
E, [2020-08-07T10:24:27.577101 #19095] ERROR – : SSL certificate with unexpected serial supplied
2020-08-07T10:24:27 24c52b5f [I] Finished GET /dynflow/tasks/count with 403 (4.36 ms)
about this error we found the following: Remote Proxy - SSL Certificate Unexpected Serial, but if we have understood the instructions correctly, there is no need to configure dynflow_core for the “All-in-one solution”?!
There is too many moving parts in play for me to able to reliably tell you what is wrong based on three lines from logs. If your certificates are configured properly, it should just work.
On a more general note, there are two sets of certs in use by the proxy configured as ssl_ca_file, ssl_certificate, ssl_private_key and foreman_ssl_ca, foreman_ssl_cert, foreman_ssl_key. Most likely you don’t have those configured as they should be.
The rule of the thumb is the ones prefixed with foreman_ should match the ssl certs configured for foreman (ssl_certificate, ssl_ca_file, ssl_priv_key in foreman’s settings.yml)
.