Foreman 1.24 and nighty with remote execution not working

Hello,

We all know that remote execution is not working properly in debian/ubuntu distro, but this problem is very irritating, as it has not worked properly for a long time. I also know that the problem has a dependence on third-party packages, but anyway, it is irritating to not be able to use the plugin satisfactorily.

This is more of an outburst than a criticism, as I know the foreman team does a great job !!

I would like to know if the foreman team has any expectations of full functioning?

Thanks!

1 Like

After some more work from the Debian Ruby team, I was able just today to have the rex proxy plugin apparently working again on my Ubuntu/bionic instance, so at this very moment I’m optimistic.

@mmoll
I install ruby-concurrent 1.1.6 from unstable (sid) source on debian 10, but it’s still not working. Maybe other packages besides ruby-concurrent are needed?

@mmoll

Today ruby-concurrent 1.1.6 was updated from http://deb.theforeman.org buster/nightly amd64 Packages, but anyway, don’t work.

Feb 28 09:33:22 puppet smart-proxy[10202]: /usr/lib/ruby/vendor_ruby/foreman_tasks_core/ticker.rb:2:in <module:ForemanTasksCore>': uninitialized constan Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/foreman_tasks_core/ticker.rb:1:in <top (required)>’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in require' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/foreman_tasks_core.rb:6:in <top (required)>’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in require' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/foreman_remote_execution_core.rb:1:in <top (required)>’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in require' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/bundler_ext/runtime.rb:41:in block in system_require’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/bundler_ext/runtime.rb:37:in each' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/bundler_ext/runtime.rb:37:in system_require’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/bundler_ext.rb:19:in block in system_require' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/bundler_ext.rb:14:in each’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/vendor_ruby/bundler_ext.rb:14:in system_require' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/share/foreman-proxy/lib/bundler_helper.rb:22:in require_groups’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/share/foreman-proxy/lib/smart_proxy_main.rb:31:in <top (required)>' Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in require’
Feb 28 09:33:22 puppet smart-proxy[10202]: from /usr/share/foreman-proxy/bin/smart-proxy:5:in `’
Feb 28 09:33:22 puppet systemd[1]: foreman-proxy.service: Main process exited, code=exited, status=1/FAILURE

@infomatico messaged me, so I started up my Buster Foreman instance to see if the update made progress. I still have ruby-concurrent held at 1.0.0-3 from Stretch. And am seeing the same behaviour after installation of ruby-smart-proxy-remote-execution-ssh 0.2.1-1.

The quoting in his block is a little messed up (seems like a recurring problem with quoting error messages in this forum), but the important bit that was missing is:

/usr/lib/ruby/vendor_ruby/foreman_tasks_core/ticker.rb:2:in `<module:ForemanTasksCore>’: uninitialized constant Dynflow (NameError)

1 Like

Thank you for the warning!! I hadn’t noticed that part was missing.

With current nightlies, the proxy is starting on Ubuntu/bionic but not on Debian/buster for reasons, yet unknown. On Ubuntu, there’s in turn a problem with dynflow-sidekiq that needs investigation.

We’ll continue to work on this, but I can’t give any guaranties or timelines on that.

Ok. Thanks for the feedback!

Debian/buster and Ubuntu/bionic should be OK with nightlies now.

For 2.0, 1.24 and 1.23 the foreman-proxy package will contain a fix going out with the next release. As a workaround, the foreman-proxy can get installed and before adding other packages or running the installer the directory /var/lib/foreman-proxy with ownership foreman-proxy:foreman-proxy must be created.

3 Likes

Wow!!! Thanks @mmoll!!!

root@puppet:~# /etc/init.d/foreman-proxy restart
[ ok ] Restarting foreman-proxy (via systemctl): foreman-proxy.service.

Thank you very much for the great work of the whole foreman team!!!

At least it won’t be a problem before, but this warning is occurring:

Mar 03 20:56:52 puppet systemd[1]: Starting Foreman Proxy…
Mar 03 20:56:52 puppet smart-proxy[20412]: /usr/share/foreman-proxy is not writable.
Mar 03 20:56:52 puppet smart-proxy[20412]: Bundler will use `/tmp/bundler20200303-20412-18jogkb20412’ as…rarily.

Would changing the foreman-proxy folder permissions solve? What would be the correct permissions?

This is perfectly fine (security reasons).

1 Like

Ok. Thanks again!!! :smiley: