I had only barely looked at the mod_wsgi-express stuff; I was in a bit of hurry when moving to mod_wsgi v4. But i looked at the source code last night, so I might have to give this a try.
Charles Yeomans > On Dec 16, 2014, at 8:33 PM, Graham Dumpleton <[email protected]> > wrote: > > 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.
