The WSGIDaemonProcess directive, if using the mechanism to reach across to
other one in 80/443 pair, must be defined in the first of the two
VirtualHost entries that Apache reads. Even within the one VirtualHost, the
WSGIDaemonProcess directive should come before any WSGIScriptAlias
directive that referes to it if using the process-group option of
WSGIScriptAlias.

So ordering is important.

Besides that, would need to see how you set up the VirtualHost directives
and need to know the order.

Graham


On 5 April 2013 11:07, Garito <[email protected]> wrote:

> Hi, Graham!
> Thanks a lot for the help
>
> I have a not found error in my configuration
>
> I've tried to add the same root directory + same directory configuration
> but when I try to add the same WSGIScriptAlias it crashes with WSGI process
> group not accessible
>
> Any idea?
>
>
> On Thursday, April 4, 2013 4:44:15 AM UTC+2, Graham Dumpleton wrote:
>
>> One can use a nginx proxy as described, although that nginx configuration
>> is missing setting of special headers when proxying to indicate if request
>> was terminated at nginx as SSL, with Apache side then checking and setting
>> HTTPS using SetEnv to flag SSL, plus header/port information for front end.
>> Without that, URL reconstruction will not work properly and will not yield
>> the address of nginx front end.
>>
>> As to doing it in Apache, you cant avoid the duplicate configuration.
>> There is one important thing though. You do not want two separate daemon
>> process groups. So long as on ports 80/443, you should use:
>>
>> VirtualHost *:80>
>> ServerName example.com
>>
>> WSGIDaemonProcess mysite
>> WSGIProcessGroup mysite
>> </VirtualHost>
>>
>> VirtualHost *:443>
>> ServerName example.com
>>
>> WSGIProcessGroup mysite
>> </VirtualHost>
>>
>> In other words, don't have a WSGIDaemonProcess in second VirtualHost.
>> Instead, for WSGIProcessGroup, use the name of the WSGIDaemonProcess in the
>> matching VirtualHost for other port.
>>
>> There is a special thing in mod_wsgi which will allow you to reach across
>> to a daemon process group defined in another VirtualHost when ServerName is
>> the same.
>>
>> Do this and the HTTP and HTTPS requests will both be handled in the one
>> application instance and you do not double memory usage by having separate
>> ones for each port.
>>
>> Graham
>>
>>
>>
>> On 4 April 2013 07:20, Jason Garber <[email protected]> wrote:
>>
>>> We run nginx in front of apache and handle SSL termination there.  Then
>>> we `proxy_pass` to 127.0.0.1 on port (whatever), and let apache handle the
>>> app without caring if SSL was or was not used.
>>>
>>> From Apache's point of view, a virtual host that handles SSL and one
>>> that does not are separate, so you need to essentially duplicate all of the
>>> per-virtual-host settings if you do it in apache.
>>>
>>> FWIW, we use a different port for each app on apache, and do not even
>>> care what the ServerName is (because that is handled in nginx).
>>>
>>>
>>> *Nginx:*
>>>
>>>   5 server {
>>>   6     listen 192.168.1.164:80;
>>>   7     server_name drillapp.app-ssl.com;
>>>   8     rewrite ^/(.*)$ 
>>> https://drillapp.app-ssl.com/$**1<https://drillapp.app-ssl.com/$1>permanent;
>>>   9 }
>>>  10
>>>  11 server {
>>>  12     listen 192.168.1.164:443;
>>>  13     server_name drillapp.app-ssl.com;
>>>  14
>>>  15     ssl              on;
>>>  16     ssl_certificate  ssl/WILD.app-ssl.com-1213.**crt;
>>>  17     ssl_certificate_key ssl/WILD.app-ssl.com-1213.key;
>>>  18
>>>  19     location ^~ /FileStruct/
>>>  20     {
>>>  21         internal;
>>>  22         alias /var/lib/FileStruct/DrillApp_**0/;
>>>  23     }
>>>  24
>>>  25     location ~ \.(gif|jpg|png|ico|xml|html|**css|js|txt|pdf)$
>>>  26     {
>>>  27         root  /home/deploy/DevLevel.0/**DrillApp/Web/InternalSite;
>>>  28         expires max;
>>>  29     }
>>>  30
>>>  31     location /
>>>  32     {
>>>  33         add_header Cache-Control 'no-cache, no-store, max-age=0,
>>> must-revalidate';
>>>  34         add_header Expires 'Thu, 01 Jan 1970 00:00:01 GMT';
>>>  35         proxy_pass http://127.0.0.1:8130;
>>>  36     }
>>>  37
>>>  38 }
>>>  39
>>>
>>> *Apache:*
>>>
>>>   23 Listen 127.0.0.1:8130
>>>   24 NameVirtualHost 127.0.0.1:8130
>>>   25 WSGIDaemonProcess Port8130 processes=4 threads=10
>>> python-path=/home/deploy/**DevLevel.0/DrillApp/Python
>>>
>>> 1214 <VirtualHost 127.0.0.1:8130>
>>> 1215    ServerName drillapp.app-ssl.com
>>> 1216    DocumentRoot /home/deploy/DevLevel.0/**DrillApp/Web/InternalSite
>>> 1217    RewriteEngine on
>>> 1218    RewriteOptions inherit
>>> 1219    AddDefaultCharset UTF-8
>>> 1220    RewriteEngine on
>>> 1221    RewriteRule ^/m$  /mobile/  [R,L]
>>> 1222    RewriteRule \.(py|pyc|pyo|wsgi)$  -  [F]
>>> 1223    WSGIScriptAlias / /home/deploy/DevLevel.0/**
>>> DrillApp/Web/InternalSite/**index.wsgi
>>> 1224    WSGIProcessGroup Port8130
>>> 1225 </VirtualHost>
>>>
>>>
>>>
>>> On Wed, Apr 3, 2013 at 3:13 PM, Garito <[email protected]> wrote:
>>>
>>>>  Hi!
>>>> I have an application working correctly in my computer
>>>>
>>>> Now I wanna configure ssl to use this app so will be parts with http
>>>> and parts with https but the SAME app without any other differences
>>>>
>>>> I've seen I have to duplicate all the configuration for both servers
>>>> witch I think is, at least, not so convenient
>>>>
>>>> Could you confirm this situation?
>>>>
>>>> If so, could you please point me what else I have to change? (I know I
>>>> have to change WSGIDaemonProcess because if not apache raises an error:
>>>> Name duplicates previous WSGI daemon definition but I don't know how)
>>>>
>>>> Thanks a lot!!!
>>>>
>>>>  --
>>>> 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 modwsgi+u...@**googlegroups.com.
>>>> To post to this group, send email to [email protected].
>>>>
>>>> Visit this group at 
>>>> http://groups.google.com/**group/modwsgi?hl=en<http://groups.google.com/group/modwsgi?hl=en>
>>>> .
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>
>>>  --
>>> 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 modwsgi+u...@**googlegroups.com.
>>> To post to this group, send email to [email protected].
>>>
>>> Visit this group at 
>>> http://groups.google.com/**group/modwsgi?hl=en<http://groups.google.com/group/modwsgi?hl=en>
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
>>  --
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to