What are the common steps taken to secure a django app instance in production.
I am using sqlite so encrypting the database would be nice too.
And since the database is encrypted the app code should also be either encrypted or compiled only. Is it safe to simply delete all the *py files and leave the *pyc files?
Also, is it possible to disable the django shell (./manage.py shell) in the production server? Once the shell is accessible so is all the data.
The stack that I am using is: Nginx + Gunicorn + Django + SQLite all hosted on a rackspace dedicated server with a dedicated firewall.
Basically, the objective is, that anyone with root access may not access the database contents.
Securing django is an important question, but I think you are confused.
First of all even if you could make your code less easy to examine, it would not make it more secure. Secondly, it is possible to recover all but comments from pyc files.
Lastly, the django shell is a convenience for interacting with your application at the commandline. If anyone unauthorised were in a position to run it, it would not matter if you had disabled it - your security would already be completely compromised.
I strongly recommend that you do not administer your own production server with your current state of knowledge. Use a shared host, and follow your hosting service's security guidelines. Concentrate on the actual web security aspects of your application.
One more thing: you're not using the built-in server in production are you?
Update: You can't protect yourself from root, and even if you could, they could, say, just put the hard disk in another computer.
Related
I'm a newbie in django and have a project that involves distributed remote storage and I'm suggested to use mod x-sendfile as part of the project procedure.
In have a django app that receives a file and transforms it into N segments each to be stored on a distinct server. Those servers having a django app receiving and storing the segments.
But since mod x-sendfile works need apache and I am just in developing and trying stage this question occurred to me.
I googled a lot but found nothing in that regard.
So my question being: Is it possible to use apache as django web server during the development of django apps? Does it make sense in development mode to replace apache with django built-in web server?
There should be nothing stopping you from installing a copy of Apache on your workstation and using it for developing, and since you're working on something that depends on some of that functionality it makes perfect sense for you to use that for your development server instead of ./manage.py runserver.
Most people use Djangos built-in server because they don't need more than that for what they're trying to do - it sounds like your solution does.
Heck, since you're testing distributed you may even want to consider grabbing a virtualization tool (qemu, virtualbox, et al) so you can have a faux-distributed setup to work with (I'd suggest doing a bit of scripting to make it easy to deploy / restart them all at once though - it'll save you from having to track down issues where the code that's running is older than you thought it was).
Your development environment can be what you need it to be for what you're doing.
I need to write a very light database (sqlite is fine) app that will initially be run locally on a clients windows PC but could, should it ever be necessary, be upgraded to work over the public interwebs without a complete rewrite.
My end user is not very technically inclined and I'd like to keep things as simple as posible. To that end I really want to avoid having to install a local webserver, however "easy" that may seem to you or I. Django specifically warns not to use it's inbuilt webserver in production so my two options seem to be...
a) Use django's built in server anyway while the app is running locally on windows and, if it ever needs to be upgraded to work over the net just stick it behind apache on a linux box somewhere in the cloud.
b) Use a framework that has a more robust built in web server from the start.
My understanding is that the only two disadvantages of django's built in server are a lack of security testing (moot if running only locally) and it's single threaded nature (not likely to be a big deal either for a low/zero concurrency single user app running locally). Am I way off base?
If so, then can I get some other "full stack" framework recommendations please - I strongly prefer python but I'm open to PHP and ruby based solutions too if there's no clear python winner. I'm probably going to have to support this app for a decade or more so I'd rather not use anything too new or esoteric unless it's from developers with some serious pedigree.
Thanks for your advice :)
Roger
I find Django's admin very easy to use for non-technical clients. In fact, that is the major consideration for my using Django as of late. Once set up properly, non-technical people can very easily update information, which can reflected on the front end immediately.
The client feels empowered.
Use Django. It's very simple for you to get started. Also, they have the best documentation. Follow the step by step app creating tutorial. Django supports all the databases that exist. Also, the built in server is very simple to use for the development and production server. I would highly recommend Django.
I have picked up python/django just barely a year. Deployment of django site is still a subject that I have many questions about, though I have successfully manual deployed my site. One of my biggest questions around deployment is what measures can I take to safeguard the source code of my apps, including passwords in django's setting.py, from others, especially when my site runs on a virtual hosting provided by some 3rd party. Call me paranoid but the fact that my source code is running on a third-party server, which someone has the privileges to access anything/anywhere on the server, makes me feel uneasy.
There is almost no scenario where your hosting provider would be interested in your source code. The source code of most websites just isn't worth very much.
If you really feel it is necessary to protect your source code, the best thing to do is serve it from a system that you own and control physically and have exclusive access to.
Failing that, there are a few techniques for obfuscating python, the most straightforward of which is to only push .pyc files and not .py files to your production server. However, this is not standard practice with Django because theft of web site source code by hosting providers is not really an extant problem. I do not know whether or not this technique would work with Django specifically.
If someone has the privileges to access anything/anywhere on the server you can't do much, because what you can do others can do too, you can try some way of obfuscation but that will not work. Only solution is NOT to use such shared repository.
Edit: options
Keep working with shared repository if your data is not very sensitive
Use dedicated hosting from companies like rack-space etc
Use AWS to run your own instance
Use google-app-engine server but that may require a DB change
Run your own server (most secure)
While your source code's probably fine where it is, I'd recommend not storing your configuration passwords in plaintext, whether the code file is compiled or not. Rather, have a hash of the appropriate password on the server, have the server generate a hash of the password submitted during login and compare those instead. Standard security practice.
Then again I could just be talking out my rear end since I haven't fussed about with Django yet.
Protecting source code is not that important IMHO. I would just deploy compiled files and not worry too much about it.
Protecting your config (specially passwords) is indeed important. Temia's point is good.
I am developping a django app on Windows, SQLite and the django dev server . I have deployed it to my host server which is running Linux, Apache, FastCgi, MySQL.
Unfortunately, I have an error returned by the server on the prod while everything ok on the dev machine. I've asked my provider for a pre-production solution in order to be able to debug and understand the problem.
Anyway, what are according to you the most likely errors that can happen when moving a django app from dev to prod?
Best
Update: I think that a pre-prod is the best way to address this kind of problem. But I would like to build a check list of what must be done before to put in production.
Thanks for the very valuable answers that I received until now :)
Update: FYI, I 've implemented the preprod server and the email notification as suggested by shanyu and I can see that the error comes from the smart_if templatetag that I am using on this new version. Any trick with template tags?
Update: I think I've fixed the pb which was caused I think by the Filezilla FTP sending. I was using the "replace if newer" option which I guess is causing some unexpected results. Using the "replace all" option fix the issue. However, it was an opportunity for me to learn more about deployment. Thansk for your answers.
Problems I typically have include:
Misconfigured productions settings, whether in my production localsettings.py, wsgi/cgi, or apache site files in /etc/sites-available
Database differences. I use South for migrations and have run into some subtle issues when performing my migration on PostgreSQL when it worked smoothly in sqlite.
Static file hosting since I cheat and use the Django server in development
Permissions, both on the file system and within the database
Rare, but possible, network issues preventing me from getting my dependencies, whether on PyPi or some 3rd party site
Ways that I have mitigated these issues:
Use the same database in production and development (in your case, MySQL everywhere)
I've found it is useful to have a "test" environment which mimics production in every way possible (it can be on lower end hardware, or even the same machine). This way, if there are any issues in this "production-like" enivornment, I can solve them without taking my production server offline.
Script everything for repeatable deployments. I use fabric, but zc.buildout or Paver would also work. These tools help reduce typos while deploying and reduce the time to deploy my app.
Use version control (mercurial, git, subversion) and a schema migration tool (like South), so if something does go wrong when you deploy to production, you have the possibility of backing out the changes and allowing production to run on the old code with the old database schema.
I haven't set up an "egg proxy" yet, but I am considering it, to avoid issues when downloading dependencies.
I've found pip's freezing dependencies to be useful, in case a new, incompatible change to a library occurred since I downloaded it initially
Use a web testing framework like Windmill or Selenium to test my application in my "test" environment, so that I can get a lot of test coverage of my system very quickly.
Regarding your case, I can think of 2 simple things that may help you:
You can enable Django to send messages when exceptions occur giving details about them. Look at here for details.
You'll be better off if you set up a test environment on the prod server (say, test.example.com) so that you can check if things will go smoothly or not before you deploy the app.
I believe these were the podcasts I listened to recently (from Pycon 2009):
Locate Django in the Real World (PyCon 2009):
http://advocacy.python.org/podcasts/pycon.rss
Parts 1 to 3
Very good introduction to designing your apps for deployment, in particular for reuse and redeployment.
Regs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm about to deploy a mediumsized site powered by Django. I have a dedicated Ubuntu Server.
I'm really confused over which serversoftware to use. So i thought to myself: why not ask stackoverflow.
What i'm looking for is:
Easy to set up
Fast and easy on resources
Can serve mediafiles
Able to serve multiple djangosites on same server
I would rather not install PHP or anything else that sucks resources, and for which I have no use for.
I have heard of mod_wsgi and mod_python on Apache, nginx and lighty. Which are the pros and cons of these and have i missed someone?
#Barry: Somehow i feel like Apache is to bloated for me. What about the alternatives?
#BrianLy: Ok I'll check out mod_wsgi some more. But why do i need Apache if i serve static files with lighty? I have also managed to serve the django app itself with lighty. Is that bad in anyway? Sorry for beeing so stupid :-)
UPDATE: What about lighty and nginx - which are the uses-cases when these are the perfect choice?
Since I was looking for some more in-depth answers, I decided to research the issue myself in depth. Please let me know if I've misunderstood anything.
Some general recommendation are to use a separate webserver for handling media. By separate, I mean a webserver which is not running Django. This server can be for instance:
Lighttpd (Lighty)
Nginx (EngineX)
Or some other light-weight server
Then, for Django, you can go down different paths. You can either:
Serve Django via Apache and:
mod_python
This is the stable and recommended/well documented way. Cons: uses a lot of memory.
mod_wsgi
From what I understand, mod_wsgi is a newer alternative. It appears to be faster and easier on resources.
mod_fastcgi
When using FastCGI you are delegating the serving of Django to another process. Since mod_python includes a python interpreter in every request it uses a lot of memory. This is a way to bypass that problem. Also there is some security concerns.
What you do is that you start your Django FastCGI server in a separate process and then configures apache via rewrites to call this process when needed.
Or you can:
Serve Django without using Apache but with another server that supports FastCGI natively:
(The documentation mentions that you can do this if you don't have any Apache specific needs. I guess the reason must be to save memory.)
Lighttpd
This is the server that runs Youtube. It seems fast and easy to use, however i've seen reports on memoryleaks.
nginx
I've seen benchmarks claiming that this server is even faster than lighttpd. It's mostly documented in Russian though.
Another thing, due to limitations in Python your server should be running in forked mode, not threaded.
So this is my current research, but I want more opinions and experiences.
I'm using Cherokee.
According to their benchmarks (grain of salt with them), it handles load better than both Lighttpd and nginx... But that's not why I use it.
I use it because if you type cherokee-admin, it starts a new server that you can log into (with a one-time password) and configure the whole server through a beautifully-done webmin. That's a killer feature. It has already saved me a lot of time. And it's saving my server a lot of resources!
As for django, I'm running it as a threaded SCGI process. Works well. Cherokee can keep it running too. Again, very nice feature.
The current Ubuntu repo version is very old so I'd advise you use their PPA. Good luck.
As #Barry said, the documentation uses mod_python. I haven't used Ubuntu as a server, but had a good experience with mod_wsgi on Solaris. You can find documentation for mod_wsgi and Django on the mod_wsgi site.
A quick review of your requirements:
Easy to setup I've found apache 2.2 fairly easy to build and install.
Fast and easy on resources I would say that this depends on your usage and traffic. * You may not want to server all files using Apache and use LightTPD (lighty) to server static files.
Can serve media files I assume you mean images, flash files? Apache can do this.
Multiple sites on same server Virtual server hosting on Apache.
Rather not install other extensions Comment out anything you don't want in the Apache config.
The officially recommended way to deploy a django project is to use mod_python with apache. This is described in the documentation. The main pro with this is that it is the best documented, most supported, and most common way to deploy. The con is that it probably isn't the fastest.
The best configuration is not so known I think. But here is:
Use nginx for serving requests (dynamic to app, static content directly).
Use python web server for serving dynamic content.
Two most speedy solutions for python-based web server is:
cogen
fapws2
You need to look into google to find current best configuration for django (still in development).
I’m using nginx (0.6.32 taken from Sid) with mod_wsgi. It works very well, though I can’t say whether it’s better than the alternatives because I never tried any. Nginx has memcached support built in, which can perhaps interoperate with the Django caching middleware (I don’t actually use it, instead I fill the cache manually using python-memcache and invalidate it when changes are made), so cache hits completely bypass Django (my development machine can serve about 3000 requests per second).
A caveat: nginx’ mod_wsgi highly dislikes named locations (it tries to pass them in SCRIPT_NAME), so the obvious ‘error_page 404 = #django’ will cause numerous obscure errors. I had to patch mod_wsgi source to fix that.
I'm struggling to understand all the options as well. In this blog post I found some benefits of mod_wsgi compared to mod_python explained.
Multiple low-traffic sites on a small VPS make RAM consumption the primary concern, and mod_python seems like a bad option there. Using lighttpd and FastCGI, I've managed to get the minimum memory usage of a simple Django site down to 58MiB virtual and 6.5MiB resident (after restarting and serving a single non-RAM-heavy request).
I've noticed that upgrading from Python 2.4 to 2.5 on Debian Etch increased the minimum memory footprint of the Python processes by a few percent. On the other hand, 2.5's better memory management might have a bigger opposite effect on long-running processes.
Keep it simple: Django recommends Apache and mod_wsgi (or mod_python). If serving media files is a very big part of your service, consider Amazon S3 or Rackspace CloudFiles.
There are many ways, approach to do this.For that reason, I recommend to read carefully the article related to the deployment process on DjangoAdvent.com:
Eric Florenzano - Deploying Django with FastCGI: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/
Read too:
Mike Malone - Scaling Django
Stochastictechnologies Blog: The perfect Django Setup
Mikkel Hoegh Blog: 35 % Response-time-improvement-switching-uwsgi-nginx
Regards
In my opinion best/fastest stack is varnish-nginx-uwsgi-django.
And I'm successfully using it.
If you're using lighthttpd, you can also use FastCGI for serving Django. I'm not sure how the speed compares to mod_wsgi, but if memory serves correctly, you get a couple of the benefits that you would get with mod_wsgi that you wouldn't get with mod_python. The main one being that you can give each application its own process (which is really helpful for keeping memory of different apps separated as well as for taking advantage of multi-core computers.
Edit: Just to add in regards to your update about nginix, if memory serves correctly again, nginix uses "greenlets" to handle concurrency. This means that you may need to be a little bit more careful to make sure that one app doesn't eat up all the server's time.
We use nginx and FastCGI for all of our Django deployments. This is mostly because we usually deploy over at Slicehost, and don't want to donate all of our memory to Apache. I guess this would be our "use case".
As for the remarks about the documentation being mostly in Russian -- I've found most of the information on the English wiki to be very useful and accurate. This site has sample configurations for Django too, from which you can tweak your own nginx configuration.
I have a warning for using Cherokee. When you make changes to Django Cherokee maintains the OLD process, instead of killing it and starting a new one.
On Apache i strongly recommend this article.
http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl
Its easy to setup, easy to kill or reset after making changes.
Just type in terminal
sudo /etc/init.d/apache2 restart
and changes are seen instantly.