Foreman-installer on Centos 7 crash dues improper folder permission

Support
1

Problem:
foreman-installer on Centos 7 crash dues to wrong permission

Expected outcome:
foreman-installer complete successfully

Foreman and Proxy versions:
foreman: 1.22.0

Other relevant data:

During the first installation, foreman-installer crash during the database initialization.
Running the command manually display a access denied error.

During the installation, the folder /usr/share/foreman ownership is set to root:root instead of foreman.
Setting the proper ownership (ex foreman:root) on that folder and rerunning foreman-install solve the issue

 INFO 2019-08-23T11:45:30 main] All hooks in group post finished
[DEBUG 2019-08-23T11:45:30 main] Exit with status code: 6 (signal was 6)
[ERROR 2019-08-23T11:45:30 main] Errors encountered during run:
[ERROR 2019-08-23T11:45:30 main]  /Stage[main]/Foreman::Database/Foreman::Rake[db:migrate]/Exec[foreman-rake-db:migrate]: Failed to call refresh: '/usr/sbin/foreman-rake db:migrate' returned 1 inst
ead of one of [0]
[ERROR 2019-08-23T11:45:30 main]  /Stage[main]/Foreman::Database/Foreman::Rake[db:migrate]/Exec[foreman-rake-db:migrate]: '/usr/sbin/foreman-rake db:migrate' returned 1 instead of one of [0]
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/errors.rb:157:in `fail'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:168:in `sync'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:626:in `refresh'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:149:in `process_callback'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:34:in `block in process_events'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:121:in `block in queued_events'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:120:in `each'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:120:in `queued_events'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/event_manager.rb:33:in `process_events'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:284:in `eval_resource'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `call'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `block (2 levels) in evaluate'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:521:in `block in thinmark'
[ERROR 2019-08-23T11:45:30 main] /opt/puppetlabs/puppet/lib/ruby/2.5.0/benchmark.rb:308:in `realtime'
2

That doesn’t sound right. Do you have any logs to show what exactly failed during the migration?

3

shell.txt.gz (1.6 KB)
I have attached the Shell output. I also have the foreman.log if that is not enough, but I’ll have to clean up the sensitive information first if the file is required.

But the key point on that log.

    • The installer run
    • It crash during /usr/sbin/foreman-rake db:migrate
    • Running foreman-rake manually crash with “ArgumentError: /usr/share/foreman is not writable.”
    • Checking the /usr/share/foreman permission point to be root only:
      drwxr-xr-x 14 root root 297 Aug 29 18:58 /usr/share/foreman
    • Manually changing the ownership then rerunning the command progress further
4

I’ve upgrade to 1.23 today and again it crashed.
The problem is in the RPM itself.

rpm -qp --dump foreman-1.23.0-1.el7.noarch.rpm | grep "/usr/share/foreman "
/usr/share/foreman 4096 1568132349 0000000000000000000000000000000000000000000000000000000000000000 040755 root root 0 0 0 X

The folder in the RPM is set as root:root

5

We had the same issue, the problem was that /tmp/bundler did already exist, but with bad SELinux context:

unconfined_u:object_r:user_tmp_t:s0

Deleting /tmp/bundler fixed that, we now have:

system_u:object_r:tmp_t:s0

and it works. /usr/share/foreman is still owned by root, but thats probably for the better to protect the config files.

6

IIRC Passenger creates this temporary directory. With Puma, you should not see this problem anymore.

7

Thanks!
We ran into this issue when upgrading from 2.0 to 2.1, and dynflow-sidekiq@orchestrator logged:

dynflow-sidekiq@orchestrator[13741]: `/usr/share/foreman` is not writable.
dynflow-sidekiq@orchestrator[13741]: Bundler also failed to create a temporary home directory at `/tmp/bundler/home':
dynflow-sidekiq@orchestrator[13741]: File exists @ dir_s_mkdir - /tmp/bundler
dynflow-sidekiq@orchestrator[13741]: /opt/rh/rh-ruby25/root/usr/share/gems/gems/bundler-1.16.1/lib/bundler.rb:193:in `rescue in tmp_home_path'
...

This is already with puma.
Of course, the temporary directory with bad SELinux context may have been created by 2.0. However, it seems also 2.1 wants to use it.

8

Hmmm I thougth this was just a Passenger problem. Clearly it’s bundler code. Now I remember, there was also a security issue I emailed them about years ago, they wouldn’t care until someone from Debian filed a CVE and only after then they fixed it:

This should have be fixed in 2.1 and older, bundler now creates /tmp/random-name so the context should always have been correct.

Strange, we don’t use bundler on EL installs, at least we override it with our bundler_ext which essentially turns it off. At least that’s what I thought.

9

This is not how I understand it. It turns of exact version number checking. Also disables a lock file which Bundler normally likes. We do that because then you can yum update rubygem-mygem without having to build a new lock file. bundler_ext still has a a dependency and loads a Gemfile.