On Monday, April 8, 2013 8:21:59 AM UTC+2, Graham Dumpleton wrote:
>
>
>
>
> On 8 April 2013 12:13, Garito <[email protected] <javascript:>> 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.
>
You mean that?: process-group=Yanged application-group=%{GLOBAL}
I try to watch/read everything you post about mod_rewrite. I'm pretty sure
I've put that sometime ago because I read/watch your recommendation. Glad
to read that
>
> 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.
>
And they are. But it's a Yanged requierement that every request ends with /
Less.js doesn't work if they do. The same for the favicon.ico this is why I
put them inside the VHs, because it is a Yanged need
>
>
>> <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.
>
The point is that some static files like css or js will finish concatenated
and minified in the server side with cache management so I don't want to
serve them as static
>
>
>> </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.
>
The error is: WSGI process group not accessible.
>
> 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] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> 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.
