Description of problem: Using the F19 image on KVM, when the broker needs to re-create Gemfile.lock it is blocked: Exception PhusionPassenger::UnknownError in PhusionPassenger::Rack::ApplicationSpawner (There was an error while trying to write to Gemfile.lock. It is likely that you need to allow write permissions for the file at path: /var/www/openshift/broker/Gemfile.lock (Bundler::InstallError) The actual problem seems to be that httpd_unified is set to off. Version-Release number of selected component (if applicable): F19 Origin VM image release 2 running on KVM, out of the box Steps to Reproduce: 1. rm /var/www/openshift/broker/Gemfile.lock 2. service openshift-broker restart 3. check /var/log/openshift/broker/httpd/error_log for errors, run rhc commands 4. getsebool httpd_unified Actual results: 3. Errors mentioned in description 4. httpd_unified --> off Expected results: httpd_unified --> on Broker restart should be able to create Gemfile.lock Additional info: Easy to fix - # setsebool httpd_unified on
The Gemfile.lock should be generated by puppet or manual installation. Currently, it is not meant to be regenerated at runtime. When changing broker plugin, the Gemfile.lock needs to be generated manually after configuring the new plugin. Do you see a case where it makes sense to generate the lock file during runtime?
(In reply to Krishna Raman from comment #1) > When changing broker plugin, the Gemfile.lock needs to be generated manually > after configuring the new plugin. It wouldn't need to be if it happened automatically, which is the mechanism we have been relying on in Enterprise installs to fix up install issues. Administrators do not and should not need to understand how rubygems and bundler work. > Do you see a case where it makes sense to generate the lock file during > runtime? When yum update brings a new version of a gem. When the administrator adds the admin console or changes any other broker plugin.
BTW, the init.d openshift-broker service does automatically regenerate the Gemfile.lock: https://github.com/openshift/origin-server/blob/master/broker/init.d/openshift-broker#L43-L52 For whatever reason, this didn't get transferred over to the systemd invocation. I'm not sure whether the httpd_unified boolean is consistently applied across the Origin deploy processes.
Just tested this on a fully patched f19 system with the changes in this PR: https://github.com/openshift/origin-server/pull/4049 and generating the Gemfile.lock is working as it should. getsebool httpd_unified returns the following: httpd_unified --> on
According to Comment 5 and I also check this issue on f19 system by oo-install, this issue has been fixed. steps 1. rm -f Gemfile.lock 2. systemctl restart openshift-broker.service 3. Gemfile.lock will be regenerated 4. [root@dhcp-13-103 broker]# getsebool httpd_unified httpd_unified --> on