Aside from not deploying a Django project to the web site root directory, is there any specific benefit to running Django projects from one location, e.g. /var/django-projects/**xxxxx-project/ vs. (in a shared hosting environment) running each Django project in a domain folder, e.g. **/vhost/mydomain.com/xxxxx-project?
Doesn't matter -- choose an organization that fits your needs.
I roughly followed this guide when creating a server to handle several Django sites, and I like the folder organization it uses. A couple of benefits:
All Django sites are in a special django user's home directory
There is a domains folder, then a folder for every site that contains the django projects, logs, wsgi files, and other files
VirtualHost containers are each in the own file, keeing httpd.conf manageable.
Realistically it shouldn't matter where you put them so long as you're consistent.
I think the biggest argument one way or another would boil down to file system permissions and where related files will be. If you are allowing development from different users on the projects but want to limit their scope, this is where the split will make more sense.
No except to extent that you mention, ie., that it shouldn't be under DocumentRoot for any site.
You should also ensure that the WSGI script file is not in the same directory as the Django settings file as doing so would generally see you saying to Apache that that directory can be served up by Apache. This may not happen as there will be no Alias directive mapping a URL to that directory, but you have still removed one layer of protection from Apache security.
So, follow the guidelines in:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
and have the WSGI script file in a directory of its own which has no source code at all under it, or have the WSGI script file in a completely different directory outside of Django project, which again contains only script files of other files that Apache would technically be allowed to serve up.
Basic rule is don't stick source code (except for WSGI script file) in any directory for which:
Allow from all
has been defined by way of Apache configuration.
Of course, above partly assumes you are using mod_wsgi. :-)
Related
I started app development with drop-wizard recently and a bit confusing how the whole thing works.
Where is the web app directory?
Is it possible to edit static files (JS, CSS) without needing to have a redeployment?
Thanks.
I have looked into this a bit more and will attempt to answer your questions:
Where is the web app directory
DW applications are not (meant as) web applications. They are deployed as an embedded system running a jetty embedded server and listening on some port(s). Having said that, there are certainly ways of packaging the application as a web application. (see link in comment)
Is it possible to edit static files (JS, CSS) without needing to have a redeployment? - Yes(ish)
This depends on you, really. There is a thing called an AssetBundle. These can be used to server static resources (from the classpath usually). This however is a mechanism you could use to implement your own AssetBundle that instead of serving files off the classpath, will serve files off the regular path.
Or, you could add your regular path to the classpath on startup so that the AssetBundle works.
Or, you could implement a ServletFilter for the AssetBundle (assets are not part of the jersey ecosystem) and implement your dynamic changes in the Filter.
Most of these will require restart for a reason or another. E.g.a custom implementation of a Filter obviously requires a redeploy. The Servlet returning assets also (I believe) employs a caching strategy that might require a restart (subject to your implementation).
For your UI: There is also a DW-views project that adds the ability to create views (with by default mustache templates) that can be powered from your application and served by the same REST endpoints.
Hope that helps,
After some more checking:
You can serve static resources from the file system and modify them as you go. They will be served correctly. How to do this:
Add an asset bundle with the resource path:
bootstrap.addBundle(new AssetsBundle("/assets2/", "/assets"));
This adds the root classpath resource assets2 and has it served statically from the endpoint assets.
The trick is that you have to add your file system location as a classpath resource. This can be done via arguments (or the classpath tab in the eclipse run configuration). You can google that relatively easy. However, you will have to remember that classpath resources behave differently from file system resources:
In my case I added to the classpath:
/home/artur/tmp/assets/
However, my Asset bundle serves from "assets2". Let's have a look at the file system:
artur#pandaadb:~/tmp/assets$ pwd
/home/artur/tmp/assets
artur#pandaadb:~/tmp/assets$ find .
.
./assets2
./assets2/test.txt
artur#pandaadb:~/tmp/assets$
So, in my file system location has been added as root, but assets are only served from the subfolder assets2
Now, all the resources that are located in assets2 can be modified at runtime and will be served by DW as a static resource.
Have fun playing around,
Artur
Background
I'm learning to deploy Django application with Nginx on top of Ubuntu. As far as I know /var/www/<project_root> is one common place to place the Django project.
Problem
I'm not sure if /var/www is considered to be the good and safe practice for the project or is there some other options that are considered more appropriate. Also I'm not totally sure who should be the owner of the project dir and which permissions should it have.
Guestions
Where should I place the Django project in Ubuntu filesystem?
Which user should own the project directory?
What permissions should the project directory and files
I know there is no definitive answer for these guestions, but I'm pretty sure there are some common good practices that are widely considered to be safe.
Actually, /var/www is a bad place for your Django code. It's the default DocumentRoot for Apache, so is the place were it looks to serve files to users; but Django code is not files that should be served, it's code that should be run. Putting the code there allows the possibility that a misconfiguration permits your code to be served directly to users, which is a big security risk.
Apart from that, it doesn't really matter where the code goes. Personally I like /srv.
I have a /static/ subdirectory in my django application (hosted on appengine) which is used to serve images, .js and .css files (with django.views.static.serve).
I would like to prevent directory listing on that subdirectory, but the .htaccess doesn't seem to work. How can i do that ?
There is a lot of confusion in this question.
.htaccess is a feature of the Apache web server, so naturally it won't work on a site that is not being served by Apache.
django.views.static.serve is a method of serving files that is only for development. It must not be used in a production site - in fact, as the documentation states, it does not even work if DEBUG is False.
App Engine has its own method of serving static assets, via handler paths configured in app.yaml, and this is what you should be using for an App Engine app. This method does not support directory listing anyway.
I'm a django newbie. I've read that all django projects, deployed in production environment, should serve media files (uploads) through web server such as apache. My question is - why is that?
There are lots of PHP frameworks - eg. symfony 1 and 2 - which don't follow the rule. Once you've made your app accessible through a web server, you don't have to change anything depending on the env you deploy. There is just the DOCUMENT_ROOT configured on the web server and somewhere inside this directory lies the upload directory - that's all. You can be sure that no one will access PHP, sql files and so on - thanks to the proper framework architecture and the document root. Why is it different in django?
edit: besides, preparing different code for different environments (e.g. this) is quite a bad approach, since you can't use exactly the same code to deploy a project in different envs (and the code from the link makes sense only for debug env.
Because with PHP your code is served from web server's public directories together with static and media files. So when you request any of these static files web server serves them directly without executing any PHP code along the way.
In Django your code is running separately and all requests are processed by python code in Django. This is inefficient to serve static files, it's more efficient to serve allow a web server like Apache or Nginx to serve them directly without going through any python code.
I notice that the official recommended book "The Definitive Guide to Django" was written based on mod_python, for both editions.
However, I think most beginners would follow what most people use: mod_wsgi.
I followed their first tutorials, that is, display current time
I have the mod_wsgi and everything setup correctly. But I am still getting the default page regardless how I access to http://domain/time/
Is there any book that is written for mod_wsgi, or did t setup the environment incorrectly?
I know I can begin without using apache, but it would be a headache in the future to deploy apache again...
EDIT
I added the wsgi script and inclued that in the views.py. It seems to work. Is it the right way???
So what is the purpose of having a separate wsgi script anyway?
I know the official guide said that create a folder name such as /apache/ and create django.wsgi...
You don't need a full rewrite of the Django book for mod_wsgi. The ony thing that is different is the apache.conf and the script inside your cgi-bin directory (both aren't directly related to Django, so all the Django parts will apply for both).
But you might probably find it useful to read the general usage/configuration instructions for mod_wsgi, and probably the special notes about django too. If you have some troubles (e.g. some kind of error message in your apache.log) then you might look at the ConfigurationIssues page too.
So what is the purpose of having a separate wsgi script anyway?
Nearly all Python web applications are based on the WSGI specification, which allows your application to be used with CGI, FastCGI, mod_python, mod_wsgi, etc. So, you might have more than one of those scripts - one for each technology for example.
Another thing is, that you can also control a lot of configuration settings inside this script (e.g. forking of additional python processes for increased performance, path to additional python modules or different versions of existing modules) which are normally set by the server administrator (and not the application developer). Thats probably also the main reason why such scripts aren't included directly in the applications.
And the third thing is, that you might have several such wsgi scripts which are deploying the same application with different settings. For example, you might have your application deployed several times for different users, or with different database settings (e.g. production and testing).