Smart_proxy_dynflow_core unable to start on Debian Buster

Problem: I have been having difficulties getting remote execution working, and I think am stepping through the issue, coming to my current one. Specifically, smart_proxy_dynflow will not start.
Expected outcome: On a similarly configured CentOS7 install of Foreman 1.24, smart_proxy_dynflow_core runs successfully.

Foreman and Proxy versions:
1.24

Foreman and Proxy plugin versions:
foreman-cli/buster,now 1.24.2-1 all [installed]
foreman-debug/buster,now 1.24.2-1 all [installed,automatic]
foreman-ec2/buster,now 1.24.2-1 all [installed]
foreman-installer/buster,now 1.24.2-1 all [installed]
foreman-postgresql/buster,now 1.24.2-1 all [installed]
foreman-proxy/buster,now 1.24.2-1 all [installed,automatic]
foreman/buster,now 1.24.2-1 amd64 [installed,automatic]
ruby-foreman-deface/plugins,now 1.5.3-1 all [installed]
ruby-foreman-remote-execution-core/buster,now 1.1.6-1 all [installed]
ruby-foreman-remote-execution/plugins,now 2.0.7-1 all [installed]
ruby-foreman-tasks-core/buster,now 0.2.5-1 all [installed]
ruby-foreman-tasks/plugins,now 0.17.5-2 all [installed]
ruby-hammer-cli-foreman/buster,now 0.19.7-1 all [installed,automatic]
ruby-smart-proxy-dynflow-core/plugins,now 0.2.2-1 all [installed]
ruby-smart-proxy-dynflow/plugins,now 0.2.3-1 all [installed]

Distribution and version:
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10.3
Codename: buster

Other relevant data:
ruby /usr/bin/smart_proxy_dynflow_core -d -p /var/run/foreman-proxy/smart_proxy_dynflow_core.pid
/usr/lib/ruby/vendor_ruby/concurrent/atomic/mutex_atomic_fixnum.rb:80: warning: constant ::Fixnum is deprecated
Traceback (most recent call last):
13: from /usr/bin/smart_proxy_dynflow_core:32:in <main>' 12: from /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/launcher.rb:8:in launch!’
11: from /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/launcher.rb:12:in start' 10: from /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/launcher.rb:28:in load_settings!’
9: from /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/bundler_helper.rb:26:in require_groups' 8: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:114:in require’
7: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:101:in setup' 6: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:134:in definition’
5: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:66:in configure' 4: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:532:in configure_gem_home_and_path’
3: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:551:in configure_gem_home' 2: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:80:in bundle_path’
1: from /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:230:in root' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:234:in rescue in root’: Could not locate Gemfile or .bundle/ directory (Bundler::GemfileNotFound)

You are not supposed to run a standalone smart_proxy_dynflow_core on debian. On EL* and derivatives it is a standalone service, on Debian-based systems it runs inside the smart proxy.

That explains that, now if I can just figure out my issues with ruby-smart-proxy-remote-execution-ssh, which is what lead me to look at this to begin with.

Remote execution through smart proxies running on debian is currently broken. Currently the most painless way is to have proxy on EL*-derivative distro

Is Debian sort of a dead end with Foreman, and if you want Foreman to operate to it’s full capabilities it should be running on EL based OSes for the foreseeable future? I.e. there seem to be a number of issues deploying on Debian, and if this is something that people are actively working on fixing, I will stick with it and try to be of what little assistance I can be buy hitting Foreman on Debian repeatedly with a hammer and seeing if it behaves. But if this is a longer timeframe, I should probably move on.

I wouldn’t necessarily say a dead end, but it is not 100%. The only issues I’m aware of are around remote execution and ansible, but only on the smart proxy’s side.

It really depends on what you need foreman to do, but in general you may get better experience on EL.