> On 29 Sep 2016, at 1:47 PM, Jalapene Burro <[email protected]> wrote:
>
> Its set up for multiple vhosts, and I noticed I either have to explicity
> alias each folder I need served or i could use the project folder to allow
> the whole app but wouldnt that create security holes?
It isn’t that simple to use the project folder anyway, as using
‘WSGIScriptAlias ‘/ means it hides any directory you set up with DocumentRoot
anyway. Thus why you need alias in the first place.
Even so, there is a way to do it with DocumentRoot, but your directory
structure isn’t right for that, you would need to have a ‘htdocs’ directory in
your project and ‘static’ and ‘media’ would need to be under it, so that when
point DocumentRoot at ‘htdocs’ you aren’t exposing any source code.
This isn’t all you have to do though as ‘WSGIScriptAlias /‘ still overrides
DocumentRoot. The solution involves adding a ’site.wsgi’ into ‘htdocs’ which
imports the actual Django WSGI application and wraps it with some code which
does some fixups. The ‘WSGIScriptAlias /‘ is then removed and replace with a
special set of rewrite rules:
AddHandler wsgi-script .wsgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L]
What will happen now is that if Apache finds an actual file under ‘htdocs’
which matches it returns it, else it passes request to the WSGI application as
a fallback.
This way you just have one document root directory and any physical files just
get thrown in there and will be handled, Anything else goes to Django.
This technique is talked about in:
http://modwsgi.readthedocs.io/en/develop/user-guides/configuration-guidelines.html#the-apache-alias-directive
<http://modwsgi.readthedocs.io/en/develop/user-guides/configuration-guidelines.html#the-apache-alias-directive>
Overall I don’t understand why you are concerned about having to enumerate the
Alias directives in the configuration. What is wrong with doing that? You only
need to set it up once.
If the issue is that you are doing this for many sites and always follows the
same pattern, then you should consider looking at mod_macro and define a macro
for the whole VirtualHost so can be easily duplicated.
FWIW, this fallback mechanism is what is used in mod_wsgi-express so that all
someone needs to do if they want to is specify a —document-root option to a
directory containing all physical files.
> Actually I think I tried alias static with the project folder and it didnt
> work. And for production apache prob isnt the best for serving static files
> as well as being the server, so Ill look into nginx but for now will use
> apache for local dev.
There is nothing wrong with using Apache to host static files for your typical
site. If your site is at a size where it matters you probably want to use a CDN
anyway. Setting up nginx to handle a couple of directories of static files for
a site is going to be a lot more work than adding Alias directives.
If you can’t get the Alias directives working as is, you need to explain how it
isn’t working. Have to set up STATIC_ROOT in Django settings? Are you running
collectstatic each time you deploy?
Graham
>
> <VirtualHost *:80>
> ServerName dsite1.me <http://dsite1.me/>
> WSGIDaemonProcess dsite1 python-home=/var/www/dtuts/venv
> python-path=/var/www/dtuts/dsite1
> WSGIProcessGroup dsite1
> WSGIApplicationGroup %{GLOBAL}
> WSGIScriptAlias / /var/www/dtuts/dsite1/dsite1/wsgi.py
> <Directory /var/www/dtuts/dsite1/dsite1/>
> <Files wsgi.py>
> Order allow,deny
> Allow from all
> </Files>
> </Directory>
>
> Alias /static /var/www/dtuts/dsite1/bloghome/static
> <Directory /var/www/dtuts/dsite1/bloghome/static>
> Order allow,deny
> Allow from all
> </Directory>
>
> #Alias /robots.txt /var/www/dtuts/dsite1/static/robots.txt
> #Alias /favicon.ico /var/www/dtuts/dsite1/static/favicon.ico
>
> #Alias /media /var/www/dtuts/dsite1/media
> #<Directory /var/www/dtuts/dsite1/media>
> # Order allow,deny
> # Allow from all
> #</Directory>
>
> ErrorLog /var/www/dtuts/logs/error.log
> LogLevel warn
> CustomLog /var/www/dtuts/logs/access.log combined
> </VirtualHost>
>
>
>
> On Wednesday, September 28, 2016 at 5:48:46 PM UTC-7, Graham Dumpleton wrote:
>
>> On 28 Sep 2016, at 7:31 PM, Jalapene Burro <[email protected] <>> wrote:
>>
>> hey, using django,
>>
>> wondering, since its uses subapps, using apache for serving static files for
>> local development, jsut curious how can i allow all apps to serve without
>> having to add an extra entry for each one like so.
>>
>> Alias /static /var/www/dtuts/dsite1/bloghome/static
>> <Directory /var/www/dtuts/dsite1/bloghome/static>
>> Order allow,deny
>> Allow from all
>> </Directory>
>
> Bit confused by your question. What is the rest of the mod_wsgi
> configuration? Are you saying you only have one Django site configured in
> mod_wsgi, or do you have more than one? If more than one, is each in its own
> VirtualHost?
>
> BTW, for local development, you may be better off using mod_wsgi-express.
>
> https://pypi.python.org/pypi/mod_wsgi
> <https://pypi.python.org/pypi/mod_wsgi>
>
> You can run it from the command line when you need it just like with Django
> development server, but means using real web server. You can still enable
> things like source code reloading if need be.
>
> Graham
>
> --
> 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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <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 https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
