On 8 April 2013 12:13, Garito <[email protected]> wrote:
>
>
> On Saturday, April 6, 2013 6:28:50 AM UTC+2, Graham Dumpleton wrote:
>>
>>
>>
>>
>> On 5 April 2013 12:24, Garito <[email protected]> wrote:
>>
>>> I'm finishing the development phase of my first app with a programming
>>> language I've made with python so I'm not online
>>>
>>> So I'm very open to any suggestion/clue/idea about this configuration
>>>
>>> As you can see the WSGIDaemonProcess configuration is for prefork even
>>> when you don't recomend that but you could read also a spanish comment with
>>> a link to a blog post with the worker one. This is because I'm with a
>>> mountain lion apache and I've don't change the mode, sorry ;)
>>>
>>> # Reduce la cadena Server a Apache (Prod)
>>> ServerTokens Prod
>>> ServerSignature Off
>>>
>>> Listen 443
>>> NameVirtualHost *:443
>>>
>>> <VirtualHost *:80>
>>> ServerName example.net
>>> ServerAlias www.example.net
>>> ServerAdmin "[email protected]"
>>>
>>>
>>> WSGIDaemonProcess Yanged processes=8 threads=1 display-name=%{GROUP}
>>> user=garito group=staff
>>> WSGIProcessGroup Yanged
>>>
>>
>> The WSGIProcessGroup is not needed as you have process-group option on
>> WSGIScriptAlias.
>>
>
> Which one do you prefer? Or What are the differences?
>
Either can be used. WSGIProcessGroup will not override process-group option
on WSGIScriptAlias though.
Also, if you specify both process-group and application-group options to
WSGIScriptAlias, it will preload the WSGI script on process start as well.
Leave it out and let it default to server level default, or point it at an
>> empty directory.
>>
>>
>>> <Directory "/Users/garito/Yanged/Runner">
>>> Order deny,allow
>>> allow from all
>>> </Directory>
>>>
>>> ErrorLog "/Users/garito/Yanged/Logs/**ErroresLargo"
>>> #ErrorLog "|/usr/sbin/rotatelogs
>>> /Users/garito/Yanged/Logs/**errores.%Y%m%d-%H_%M_%S
>>> 5M"
>>>
>>
>> Missing error logging in HTTPS virtual host.
>>
>
> I've put the common parts in another file and include it from both
> virtualhosts. Is that make sense?
>
Yep, no problem doing that.
LogFormat "%h %{uuid1}C %{uuid2}C %t \"%r\" %>s %B \"%{Referer}i\"
>>> \"%{User-Agent}i\" \"%{Accept}i\" \"%{Accept-Language}i\"
>>> \"%{X-Requested-With}i\" \"%{Content-Type}o\" %I %O %D" yanged
>>> CustomLog "|/Users/garito/Yanged/**logAMongo/aMongo.py" yanged
>>> LogLevel debug
>>>
>>> # Gzip. No va mas rapido pero envia un tercio menos al navegador.
>>> Bueno para mobile
>>> <IfModule mod_deflate.c>
>>> # Force deflate for mangled headers
>>> developer.yahoo.com/blogs/ydn/**posts/2010/12/pushing-beyond-**gzipping/<http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/>
>>> <IfModule mod_setenvif.c>
>>> <IfModule mod_headers.c>
>>> SetEnvIfNoCase
>>> ^(Accept-EncodXng|X-cept-**Encoding|X{15}|~{15}|-{15})$
>>> ^((gzip|deflate)\s*,?\s*)+|[X~**-]{4,13}$ HAVE_Accept-Encoding
>>> RequestHeader append Accept-Encoding "gzip,deflate"
>>> env=HAVE_Accept-Encoding
>>> </IfModule>
>>> </IfModule>
>>>
>>> # Compress all output labeled with one of the following
>>> MIME-types
>>> # (for Apache versions below 2.3.7, you don't need to enable
>>> `mod_filter`
>>> # and can remove the `<IfModule mod_filter.c>` and
>>> `</IfModule>` lines as
>>> # `AddOutputFilterByType` is still in the core directives)
>>> <IfModule mod_filter.c>
>>> AddOutputFilterByType DEFLATE application/atom+xml \
>>> application/javascript \
>>> application/json \
>>> application/rss+xml \
>>> **
>>> application/vnd.ms-fontobject \
>>> application/x-font-ttf \
>>> application/xhtml+xml \
>>> application/xml \
>>> font/opentype \
>>> image/png \
>>> image/jpg \
>>> ** image/svg+xml \
>>> image/x-icon \
>>> text/css \
>>> text/html \
>>> text/plain \
>>> text/x-component \
>>> text/xml
>>> </IfModule>
>>> </IfModule>
>>>
>>> <IfModule mod_headers.c>
>>> Header set Connection Keep-Alive
>>> </IfModule>
>>>
>>
>> Not sure why you have all this here. Generally would be outside of the
>> VirtualHost so you don't have to duplicate it in every VirtualHost.
>>
>
> If my understaning is correct, I put them in both VS because is a rule
> that only applies in this context. It's not garantied that other VS have
> the same requirement. Am I right?
>
If they truly are specific to the VirtualHost then fine. They looked rather
generic to me.
> <IfModule mod_rewrite.c>
>>> RewriteEngine on
>>>
>>> # Reenvia favicon.ico a favicon.ico/
>>> RewriteCond %{REQUEST_URI} favicon.ico$
>>> RewriteRule .? %{REQUEST_URI}/ [NC,L,R=301]
>>>
>>> # Reenvia los ficheros *.less a *.less/
>>> RewriteCond %{REQUEST_URI} .less$
>>> RewriteRule .? %{REQUEST_URI}/ [NC,L,R=301]
>>> </IfModule>
>>>
>>
>> Not sure these will work as WSGIScriptAlias hijacks /.
>>
>> See Alias rules in:
>>
>> http://code.google.com/p/**modwsgi/wiki/**ConfigurationGuidelines#**
>> Hosting_Of_Static_Files<http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Hosting_Of_Static_Files>
>>
>>
>
> At this point perhaps you will not agree with me but I process most of the
> suposed static content for cache needs
>
I likely just don't understand what you are doing, but the WSGIScriptAlias
will hijack so unless you have Alias directives to override it, any
requests for stuff like this will still go through to the WSGI application.
> </VirtualHost>
>>>
>>>
>>> <VirtualHost *:443>
>>> ServerName example.net
>>> ServerAlias www.example.net
>>> ServerAdmin "[email protected]"
>>>
>>> WSGIProcessGroup Yanged
>>>
>>
>> Don't need WSGIProcessGroup here.
>>
>> You are also though missing:
>>
>> WSGIScriptAlias / /Users/garito/Yanged/Runner/yR**un.py
>> process-group=Yanged application-group=%{GLOBAL}
>>
>> <Directory "/Users/garito/Yanged/Runner">
>> Order deny,allow
>> allow from all
>> </Directory>
>>
>> In other words, the only bit for the mod_wsgi configuration not
>> duplicated is the WSGIDaemonProcess.
>>
>
> The only way I have to make it run is by putting the WSGIDaemonProcess
> outside the VS's definitions. Did I miss something or this is normal?
>
If the issue is still about not finding the daemon process group name, it
is going to be an ordering issue. The WSGIDaemonProcess directive when
reaching across VIrtualHost's must be in the first VirtualHost read by
Apache. So, if these are in separate files and included via a wildcard,
likely the WSGIDaemonProcess is in the wrong one. Is also important that
ServerName match for both. This all presumes you are using a recent
mod_wsgi, although if using process-group option to WSGIScriptAlias you
must be using mod_wsgi 3.0+, which should be okay.
Graham
> Thank you very much!!!
>
>
>
>>
>>>
>>> <IfModule ssl_module>
>>> SSLEngine on
>>> SSLProtocol all -SSLv2
>>> SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+**RSA:+HIGH:+MEDIUM
>>>
>>> SSLCertificateFile /Users/garito/Yanged/**Certificados/ssl.crt
>>> SSLCertificateKeyFile /Users/garito/Yanged/**
>>> Certificados/ssl.key
>>> SSLCertificateChainFile /Users/garito/Yanged/**
>>> Certificados/sub.class1.**server.ca.pem
>>> SSLCACertificateFile /Users/garito/Yanged/**Certificados/ca.pem
>>> </IfModule>
>>> </VirtualH
>>
>>
>
>> ost>
>>>
>>>
>>> On Friday, April 5, 2013 2:11:12 AM UTC+2, Graham Dumpleton wrote:
>>>
>>>> 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|**cs****
>>>>>>> s|js|txt|pdf)$
>>>>>>> 26 {
>>>>>>> 27 root /home/deploy/DevLevel.0/**Drill****
>>>>>>> App/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/**DevLe****vel.0/DrillApp/Python
>>>>>>>
>>>>>>> 1214 <VirtualHost 127.0.0.1:8130>
>>>>>>> 1215 ServerName drillapp.app-ssl.com
>>>>>>> 1216 DocumentRoot /home/deploy/DevLevel.0/**DrillA****
>>>>>>> pp/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/**DrillA****
>>>>>>> pp/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/**grou****
>>>>>>>> ps/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/**grou****
>>>>>>> ps/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/**grou**ps/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.
