Created attachment 773875 [details]
SCL spec file for mod_wsgi 3.4
OpenShift on RHEL 6 is trying to deploy the Python 2.7 SCL environment instead of the hand maintained community cartridge.
We would like mod_wsgi for this environment. I've created a package, built and tested it but need it to be built by Brew in the SCL environment and managed properly for inclusion into OpenShift.
The package I wrote creates mod_wsgi as "python27-mod_wsgi" in the regular Apache modules directory and does not load it into Apache by default. That can certainly change as necessary but its what we'd prefer for OpenShift.
So, after playing around with mod_wsgi + SCLs, here's a little analysis:
- Usable for both python27 and python33 (some minor patching for Python 3).
- Needs to be build separately for each Python runtime.
- If multiple mod_wsgi are installed (that includes two SCL mod_wsgi or system+SCL mod_wsgi), each one _must_ have it's own Apache instance with own httpd.conf (if we don't want to modify the current one, which we don't).
- Seems pretty ok from packaging/maintenance POV (no additional deps, little to no bugs).
Would you mind attaching any modifications to the spec file and patches. We're going ahead with our own build for testing and would like to make sure there are no surprises. Thanks!
An ETA for this package would be really helpful for our planning. Thanks!
For ETA, I think you'll need to talk to Brian Gollager (requesting needinfo from him so that he knows about this bug).
For the technical part: my specfile is a not working ATM, I built the package pretty much the same way you did and then I moved the files around by hand to make things work. Basically, what you need to do is:
1) Build mod_wsgi against scl python (correct in your specfile).
2) Place built mod_wsgi in correct location (I'd say using /opt/... is better than using the system dir).
3) Create a new httpd.conf (preferably in /opt/.../etc/httpd/conf) file that you will use to run the new apache instance.
4) Create wsgi.conf (in /opt/.../etc/httpd/conf.d) that will load the mod_wsgi built in step 2) (note that this will require using full path to mod_wsgi.so).
5) Run a new apache instance with the new httpd.conf.
This is what you need to do to not break system mod_wsgi (and _probably_ what we will do in RHSCL if adding mod_wsgi). If you are sure that you will only use the collection mod_wsgi, you can probably skip moving the files around, creating new httpd.conf etc - pretty much what you do in your specfile.
We're rolling our own version to continue testing and will switch to the official SCL version when its ready.
We're sticking with module installation as:
Files in /usr/lib64/httpd/modules/* get a specific SELinux tag as Apache modules. If the official SCL package places the module in the SCL build root instead, please ensure that it works with SELinux in enforcing mode. Thanks!
Why not use passenger to serve WSGI ? If I am not mistaken, OpenShift already supports passenger ... just saying
We have use cases where Apache mod_wsgi is preferred; though the latest version of our cartridge also allows the end-user to stand up their own framework and stand-alone Passenger would be an option.
I've seen there is a new Python 2.7 SCL version available (using the Repo:
but the mod WSGI package python27-mod_wsgi is not there.
That package was however available in the "candidate" Repo
Is there any problem with that package, or what is the current status?
Thanks a lot for your answer and your work! :)
Thank you for your interest in SCL. We don't plan to maintain packages on our private pages anymore. You can:
1/ buy a subscription
2/ wait for official start of our upstream pages http://softwarecollections.org/ (now Beta). We will be posting our upstream SCL there in few weeks.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.