It is on a long TODO list to generate Apache configuration file snippets for most basic of things where people don't want to use mod_wsgi-express from init scripts and instead want to integrate into the existing Apache configuration, even though they then loose out on the benefits of mod_wsgi-express.
Right now all that is available is once you do a pip install mod_wsgi, you can run: $ mod_wsgi-express module-location /Users/graham/Projects/mod_wsgi/venv/lib/python2.7/site-packages/mod_wsgi-4.4.1-py2.7-macosx-10.8-intel.egg/mod_wsgi/server/mod_wsgi-py27.so so you can find out where pip installed the .so file in case you want to refer to it out of the Python installation when loading it into Apache. You might be able to use that at least to know from where to copy the .so file. Alternatively, you can run: $ sudo mod_wsgi-express install-module LoadModule wsgi_module /usr/libexec/apache2/mod_wsgi-py27.so WSGIPythonHome /Users/graham/Projects/mod_wsgi/venv This will install the .so file into your Apache modules directory for you. It will also give you the two key lines to stick in the Apache configuration, with the latter being what Python installation the module was compiled against. Down the track, for Django at least, I have been contemplating a 'httpdconf' Django management command. When this is run it would create and populate an 'apache' directory in your Django project with a WSGI script file and Apache configuration files snippets for loading and setting up the module, plus the specific snippets to mount your Django application and any static file assets. These snippets could be Include'd direct into the Apache configuration, copy pasted manually. The reason for doing this as that so many people seem to still screw up the configuration even when following the Django documentation about mod_wsgi. The other thing on the TODO list is have mod_wsgi-express generate init.d scripts for various Linux variants so that you can ignore the existing Apache and just start mod_wsgi-express on OS startup. If you are not using Apache for anything else this would be better than relying on default Apache configuration which generally sucks for Python web applications. Better to use my curated mod_wsgi-express configuration. Graham On 17/12/2014, at 11:44 AM, Charles Yeomans <[email protected]> wrote: > I've used mod_wsgi for several years and had to install via a bash script (so > that puppet could do it) to get current versions, but now one can install > using pip. The only issue I found was that the pip install does not create > mod_wsgi.load or mod_wsgi_conf, but those were simple enough to supply myself. > > > Charles Yeomans > > >> On Dec 16, 2014, at 6:59 PM, Graham Dumpleton <[email protected]> >> wrote: >> >> You will unfortunately not find a binary OS supplied Ubuntu 10.4 package for >> mod_wsgi which is newer. >> >> Your only choice would be to compile from source code. >> >> Graham >> >> On 17/12/2014, at 10:54 AM, Jennifer Mehl <[email protected]> wrote: >> >>> Thanks for this info. I’ll try a newer mod_wsgi. >>> >>> It’s very odd to me that the app works fine in mod_wsgi/Apache with no SSL >>> but parts become broken in certain browsers once SSL is enabled. >>> >>> At any rate, thanks for the guidance and I’ll report back if I find a fix! >>> >>> —Jennifer >>> >>>> On Dec 16, 2014, at 3:46 PM, Graham Dumpleton <[email protected]> >>>> wrote: >>>> >>>> If you are using mod_wsgi 3.4 that could be a problem in itself. >>>> >>>> Recent versions of Ubuntu as I understand it use Apache 2.4, but such an >>>> old version of mod_wsgi may have issues on Apache 2.4. At the minimum >>>> would need to have mod_wsgi 3.5 from memory as some Apache 2.4 fixes were >>>> back ported to 3.5. It is unlikely they back ported those themselves to >>>> 3.4 for 14.04. >>>> >>>> Either way, mod_wsgi itself shouldn't be causing any problems with HTTPS >>>> as it is Apache that deals with all that and mod_wsgi has nothing to do >>>> with the handling of secure connections. When mod_wsgi sees a request that >>>> came via HTTPS it sees it as being no different to a HTTP request with the >>>> exception of what the wsgi.url_scheme attribute is set to. It is therefore >>>> more likely to be an Apache configuration issue or issue with the code of >>>> Apache itself. >>>> >>>> FWIW, mod_wsgi 3.4 means that Ubuntu version is almost 20 versions behind. >>>> Even Ubuntu 14.10 has only mod_wsgi 3.5. It is quite frustrating that they >>>> haven't been bothered to update their packages to more recent versions >>>> even if only for the most recent 14.10. >>>> >>>> About the only thing I can suggest if it is readily reproducible, is to >>>> use request logging such as described in: >>>> >>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response >>>> >>>> to see if when a request has issues, that the WSGI application actually >>>> returned the requests properly. >>>> >>>> If it isn't, then use something like: >>>> >>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Extracting_Python_Stack_Traces >>>> >>>> to get out Python stack traces for where a request handler may be stuck. >>>> >>>> Both can be fiddly so sounds like you aren't going to have time to do that. >>>> >>>> Graham >>>> >>>> On 17/12/2014, at 10:04 AM, Jennifer Mehl <[email protected]> wrote: >>>> >>>>> I’m on the latest for Ubuntu 14.04LTS - 2.4.7-1ubuntu4.1. I have been >>>>> using the updated mod_wsgi3.4 from Ubuntu. >>>>> >>>>> At this point I was thinking about trying my Django application in a >>>>> different WSGI server to see if I can narrow down if the problem is with >>>>> the Django code or something with mod_wsgi. I was thinking about uwsgi >>>>> (trying to find something quick and easy to test) or nginx. >>>>> >>>>> Again, the weird browser behavior I describe below only happens when >>>>> using Apache/HTTPS, port 443, in mod_wsgi (not Apache/HTTP in mod_wsgi or >>>>> the Django development server in port 80). >>>>> >>>>> I’m kind of at my wit’s end trying to narrow down *where* the problem is >>>>> (if it’s something in the Django code, I only have one more day until my >>>>> developer leaves for a few weeks for winter break…) Do you think there >>>>> any debugging I can do by looking at the developer console in the >>>>> affected browsers - for instance comparing the affected pages on a >>>>> working port 80 vs the same pages on the non-working SSL/port 443 >>>>> connection? >>>>> >>>>> thank you, >>>>> Jennifer >>>>> >>>>> >>>>> >>>>>> On Dec 16, 2014, at 2:55 PM, Graham Dumpleton >>>>>> <[email protected]> wrote: >>>>>> >>>>>> One more question. What version of Apache are you using? >>>>>> >>>>>> If you are stuck on a quite old Apache 2.2.X version that would be a >>>>>> concern as there were various SSL related issues patched during the life >>>>>> of Apache 2.2.X. >>>>>> >>>>>> Graham >>>>>> >>>>>> On 16/12/2014, at 11:40 AM, Graham Dumpleton >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> I'll go through the description you gave me and see if can suggest >>>>>>> anything, but first up, what version of mod_wsgi are you using? >>>>>>> >>>>>>> If you are using mod_wsgi 4.4.0 make sure you update to 4.4.1. The >>>>>>> newer version resolves a potential for process crashing introduced in >>>>>>> 4.4.0. >>>>>>> >>>>>>> Graham >>>>>>> >>>>>>> On 16/12/2014, at 11:33 AM, Jennifer Mehl <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> I am backpedalling a bit from my previous attempt to chroot mod_wsgi - >>>>>>>> instead, for now, just to get this Django application running, for >>>>>>>> simplicity, I am going to start out with just running it as a daemon >>>>>>>> as a restricted user. >>>>>>>> >>>>>>>> In doing the final testing of my application on various browsers, I >>>>>>>> have noticed some strange problems. >>>>>>>> >>>>>>>> When I run Django/mod_wsgi/Apache on port 80 (same config as below, >>>>>>>> minus the mod_ssl stuff) or use the django development runserver >>>>>>>> 0.0.0.0:80, and disable the following settings in settings.py >>>>>>>> (#SESSION_COOKIE_SECURE = True #CSRF_COOKIE_SECURE = True) these >>>>>>>> browsers work correctly in the app. >>>>>>>> >>>>>>>> However, when running Django application running through mod_wsgi and >>>>>>>> HTTPS/port 443 in Apache, I see problems with both IE and Safari >>>>>>>> browsers. After login on Internet Explorer, page timeouts occur in >>>>>>>> various locations, reporting "This page can't be displayed". On >>>>>>>> Safari, the app won't get past the secondary Duo MFA authentication >>>>>>>> step, saying "Server unexpectedly dropped the connection." It is not a >>>>>>>> consistent behavior - seems to happen more frequently if I click >>>>>>>> quickly through links. Sometimes if I wait long enough to click, it >>>>>>>> might work momentarily, but then not again a moment later. This >>>>>>>> behavior does NOT happen using Chrome or Firefox browsers on any OS. >>>>>>>> >>>>>>>> Apache config: >>>>>>>> >>>>>>>> >>>>>>>> <IfModule mod_ssl.c> >>>>>>>> >>>>>>>> <VirtualHost *:443> >>>>>>>> >>>>>>>> ServerName **redacted** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> #Django WSGI - Daemon >>>>>>>> >>>>>>>> WSGIScriptAlias / /var/www/transfergateway/myproject/apache/wsgi.py >>>>>>>> >>>>>>>> WSGIProcessGroup file-xfer >>>>>>>> >>>>>>>> WSGIDaemonProcess file-xfer user=mod_wsgi group=mod_wsgi >>>>>>>> processes=2 threads=25 python-path=/var/www/transfergateway >>>>>>>> >>>>>>>> >>>>>>>> <Directory /var/www/transfergateway/myproject/apache> >>>>>>>> >>>>>>>> <Files wsgi.py> >>>>>>>> >>>>>>>> Order deny,allow >>>>>>>> >>>>>>>> Allow from all >>>>>>>> >>>>>>>> </Files> >>>>>>>> >>>>>>>> </Directory> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Alias /robots.txt >>>>>>>> /var/www/transfergateway/myproject/myapp/static/robots.txt >>>>>>>> >>>>>>>> Alias /favicon.ico >>>>>>>> /var/www/transfergateway/myproject/myapp/static/favicon.ico >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> AliasMatch ^/([^/]*\.css) >>>>>>>> /var/www/transfergateway/myproject/myapp/static/styles/$1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Alias /media/ /var/www/transfergateway/myproject/myapp/media/ >>>>>>>> >>>>>>>> Alias /static/ /var/www/transfergateway/myproject/myapp/static/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <Directory /var/www/transfergateway/myproject/myapp/static> >>>>>>>> >>>>>>>> Order deny,allow >>>>>>>> >>>>>>>> Allow from all >>>>>>>> >>>>>>>> </Directory> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <Directory /var/www/transfergateway/myproject/myapp/media> >>>>>>>> >>>>>>>> Order deny,allow >>>>>>>> >>>>>>>> Allow from all >>>>>>>> >>>>>>>> </Directory> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ErrorLog ${APACHE_LOG_DIR}/error.log >>>>>>>> >>>>>>>> CustomLog ${APACHE_LOG_DIR}/access.log combined >>>>>>>> >>>>>>>> SSLEngine on >>>>>>>> >>>>>>>> SSLCertificateFile /etc/ssl/certs/*** >>>>>>>> >>>>>>>> SSLCertificateKeyFile /etc/ssl/private/** >>>>>>>> >>>>>>>> SSLCertificateChainFile /etc/ssl/certs/** >>>>>>>> >>>>>>>> SSLCipherSuite HIGH:!aNULL:!MD5 >>>>>>>> >>>>>>>> </VirtualHost> >>>>>>>> >>>>>>>> >>>>>>>> </IfModule> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So, I'm concluding that the HTTPS problem is one of two things: how I >>>>>>>> am configuring mod_wsgi with HTTPS, or some issue inside the Django >>>>>>>> code (but HTTPS works on some browsers with no issues, so I'm >>>>>>>> stumped...) >>>>>>>> >>>>>>>> Is there anything special that I need to do in mod_wsgi or the Django >>>>>>>> application itself, in order to make the application HTTPS only? (I >>>>>>>> am not a Python or Django developer, so I would be passing info on to >>>>>>>> the actual application developer for resolution.) Any ideas? >>>>>>>> >>>>>>>> thank you, >>>>>>>> Jennifer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "modwsgi" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>>>> an email to [email protected]. >>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to a topic in the >>>>>> Google Groups "modwsgi" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe. >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "modwsgi" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "modwsgi" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/modwsgi. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
