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.
