On Wed, Sep 15, 2010 at 11:55 PM, Graham Dumpleton < [email protected]> wrote:
> On 16 September 2010 16:50, Sameer Sundresh <[email protected]> wrote: > > On Wed, Sep 15, 2010 at 11:23 PM, Graham Dumpleton > > <[email protected]> wrote: > >> > >> BTW, how paranoid are you wanting to be? There are some options to > >> WSGIDaemonProcess which I seem to have never documented, even in > >> changes file. Nor do I have appeared to mention them on mailing list. > >> > >> These are 'script-user' and 'script-group'. They can be used to > >> enforce, in similar way to suexec, things about the ownership of the > >> WSGI script file, the file owner/group permissions and directory > >> owner/group permissions. > >> > >> I'll have to actually go and refresh myself what they do? > >> > >> If you are being especially paranoid, they may be of interest. > > > > The more paranoid the better ;) > > But realistically, accidentally running a WSGI script that's owned by the > > wrong user isn't something I anticipate running into. The Python code is > > all stored read-only, I just want to minimize how different applications > may > > be able to interfere with each other. > > Also, some results with mod_wsgi 3.3: > > Good news: Other applications' error.log files are no longer open in a > WSGI > > process (they were with mod_wsg 2.6). > > Bad news: However, all other applications' access.log files are still > open > > in all the WSGI processes. > > Sorry, should have said that access logs for all hosts still open, not > just main log. Forgot about that. > > This comes down to being a limitation in Apache in being able to get a > handle for the access log file. > > The only way I know of getting around this is to not use CustomLog at > all. Instead, put a nginx front end in place and have it do access > logging for hosts. > > This has other benefits anyway. These including: > > 1. Saves Apache doing access logging, with Apache likely being slower > at doing it than nginx anyway. > > 2. You get benefits of nginx isolating Apache from slow clients, > allowing Apache to perform better with less resources. > > 3. You can use nginx to serve static files, which it does better than > Apache. > Thanks, that now answers my questions about mod_wsgi. I had a suspicion that we'd have to switch over to something like nginx, but I wanted to get as much mileage as I could out of the current setup. I hadn't specifically considered keeping apache as the layer behind nginx. I'll look into that and perhaps separate apache instances. I appreciate the advice! -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
