GNOME Bugzilla – Bug 628201
mod_wsgi support on window.gnome.org
Last modified: 2011-04-07 03:36:41 UTC
Copied verbatim from the request I filed in November 2007 in RT (#4116), that has now been closed due to "inactivity" (a bit bitter about this, tbh). > With regards to bug 500378, I implemented the feature but it requires SCGI support, there > are no official packages yet for Red Hat and cie, but I know some will be proposed soon for > CentOS Extras and Fedora Extras/EPEL, those are currently hosted at > http://redhat.sorbonne.fr/CentOS-5/siris/. (fwiw I don't know if they have finally been proposed, or accepted).
Frederic - We apologize for letting this request stall for so long. I am now assigning it to myself and will discuss a resolution with the team. Please feel free to contact me directly via email / IM to follow-up. Christer
Frederic, Would it be possible to implement this using mod_wsgi which has better uptake and distribution support?
It is certainly technically possible but the code is already written and I don't know "raw" WSGI; so I have very little motivation to change this and prefer to use my time on other things.
To give some motivation why mod_scgi is a bit of a problem - In general, web server load is probably the biggest runtime problem that sysadmins have to deal with on an emergency basis. If things are tuned wrong, or if some unexpected interaction comes up, you can pretty easily end up with 200 100meg apache processes. To deal with this sort of problem, you have to understand the pieces - how the web services are configured, etc. If every web service we run is doing it differently - mod_cgi, mod_python, mod_wsgi, mod_scgi, then that makes it much harder for whatever sysadmin that is around to at 2am on a Sunday morning to understand and fix the problem. Recently, we've been standardizing on mod_wsgi for Python web services - we have a couple done that way (at least live.gnome.org and shell-perf.gnome.org that I recall).
(In reply to comment #4) > Recently, we've been standardizing on mod_wsgi for Python web services - we > have a couple done that way (at least live.gnome.org and shell-perf.gnome.org > that I recall). Just for clarity: For live.gnome.org we want to migrate to mod_wsgi. This has not been done atm. Currently still uses mod_python.
(In reply to comment #5) > (In reply to comment #4) > > Recently, we've been standardizing on mod_wsgi for Python web services - we > > have a couple done that way (at least live.gnome.org and shell-perf.gnome.org > > that I recall). > > Just for clarity: For live.gnome.org we want to migrate to mod_wsgi. This has > not been done atm. Currently still uses mod_python. Ah, misremembered what had been done. I probably should say then that "we've made the decision to standardize on mod_wsgi", since running shell-perf.gnome.org on mod_wsgi doesn't quite count as an in-place gnome.org standard :-). But we did make that decision. (fredp: obviously you couldn't have been expected to know in 2007 that we were going to standardize on mod_wsgi in 2010. But the fact that the work was done in 2007 doesn't really change requirements keep a sane infrastructure now.)
The question arose when we deployed Damned Lies (#557359), finally which solution has been used? Do you have made other decisions on the deployment of Web apps (Python version, database, security, etc)?
Thinking about it, I went for minimalistic SCGI because it would be a very lightweight service, but I understand the need for standardisation, would it be ok to do it with a django application, instead of a straight (or not) port to raw wsgi? Using damned-lies, shell-perf, snowy as references.
AFAIK, Damned Lies is using FCGI on progress. I'm ready to provide a wsgi script if someone is willing to change the setup to use mod_wsgi (which is now Django's recommended deployment method).
@Fred: Yes django is preferable if you don't mind. @Claude: Let us know what you need and we can make it happen.
The server part of library-web is now a Django application (see bug 500378 comment 7), could it be installed and configured on window.gnome.org now? There is a short web/README with instructions.
Fredric, I've started working on this, but it isn't trivial. I copied defaults.lgorc to /etc/library-web, added the ftp root to be /cvs/gnome, and am running this to let the documentation pages build: python src/lgo.py -c /etc/library-web/defaults.lgorc -v -v -v Is this the right way to run things? Does this need an init script that runs a command similar to above and logs STD{OUT,ERR} somewhere? Do you have any special method you want to use for updating the site, or do you expect some sort of post commit hook? It has generated 831 documentation files thusfar so seems to be chugging along just fine. Would there be a good time we could both hop on IRC and chat about this?
Jeff, there is already library.gnome.org, generated, updated automatically, etc. that part is not needed. This bug is only about the "live search" part, described in library-web/web/README. Anyway I am in UTC+0100, and available most of the time on IRC.
Extracting useful lines from our IRC conversation... <SEJeff> fredp, ok well thats good to know. So, what do you want me to do :) <fredp> SEJeff: mod_wsgi, and a little snippet in the apache configuration, pointing to lgoweb.wsgi <SEJeff> But if you prefer ~gnomeweb thats fine as well. <fredp> well, the thing is already all installed in ~gnomeweb/, so I think it's easier to go with the existing installation <SEJeff> Sure <SEJeff> And I take it you want this to run as a wsgidaemonprocess or whatever? <SEJeff> where you can touch the wsgi file to trigger a code recompile / restart <SEJeff> fredp, Would you be ok with a setup like we worked out for snowy? <SEJeff> http://live.gnome.org/Snowy/Install/WSGI <SEJeff> using the gnomeweb user? <SEJeff> and the wsgi file you provided already <fredp> using gnomeweb is fine, if it's ok for you from a security pov. <SEJeff> Well unless you think it should be a separate user, it doesn't matter to me. <fredp> well, apache isn't running as gnomeweb, so a dedicated user for that wsgi may also be nice. <SEJeff> correct. Thats one of the benefits of the wsgi daemon model. The apache children running it run as a separate user
This has now been fixed.