Description of problem: when attempting to integrate selenium into a jenkins build, firefox fails to run due to what seems to be SELinux errors Version-Release number of selected component (if applicable): OpenShift Enterprise 2.1 How reproducible: always Steps to Reproduce: 1. set up Selenium according to https://blog.openshift.com/selenium-ruby-jenkins/ 2. start a build Actual results: errors reported mkdir: cannot create directory `/var/lib/openshift/321fedcba0987654321fedcba//.mozilla process 8685: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id" Expected results: tests run fine Additional info: when SELinux is disabled, the setup starts to work
I agree that this is a really nice use case to enable. Just to set expectations, that article is three years old, OpenShift has changed massively since, and this isn't likely to be a high priority for OpenShift engineering to work on. In fact I would say it's unlikely to be addressed under OpenShift v2 unless you or someone else looking at this troubleshoots and contributes some code (or finds the right SELinux policy changes - setenforce 0 and run audit2allow to determine what policy is needed). Does this work on OpenShift Online (rhcloud.com)?
@Luke I believe this requires firefox installation on hosts. I don't know the software configuration of the hosts used but presume it's the bare minimum required. So I don't expect it to work there.
It would have helped had I done more than skim the article. It's about running this setup in general, not on an OpenShift Jenkins gear (which I think would be an awesome use of OpenShift if it worked). Of course Online isn't going to supply the dependencies to run this. I strongly suspect that there's just no good way to get this to work with OpenShift v2 containers. For a start, containers don't have access to edit their own home dir to create e.g. /var/lib/openshift/321fedcba0987654321fedcba//.mozilla (though you could with a custom cartridge), but beyond that, I don't think interactions with dbus and probably console/X11 are going to work from the confines of a gear (*maybe* with selinux permissive). It's not a use case we've ever targeted, but there's a much better chance it will work under Docker containers in v3. For now, I don't think we can address it.