DISQUS

simeon · 2 months ago

local_settings.py doesn't have to be harmful. I usually have one directory up from my project in version control and use fabric for deployment. My directory structure looks like:
- virtualenv
- proj_dir
-- django_site
---- settings.py
-- host1.local_settings.py
-- host2.local_settings.py
-- fabfile.py

My fabfile deployment rules transfer the appropriate local_settings.py file for the host I'm deploying to - and everything is under version control...

kteague · 2 months ago

You'll also need to take care that no other users can read your passwords.py file. One option is a simple 'chmod 600 passwords.py' to remove group and world read-only privies. However, using the recently released 'keyring' project, you can take advantage of your operating system's keyring encryption facilities.

You can either set this password using your OS tools (e.g. Keychain on Mac OS X lets you add new keychain entries from a GUI), or set the password programmatically from an interactive session:

>>> import keyring
>>> keyring.set_password('django-app-name','fred','abc123')

Then, in your settings.py, read the password from the keychain with:

>>> import keyring
>>> password = keyring.get_password('django-app-name','fred')

I've been using this to secure my password for development environments on Mac OS X, and production environments on Linux (RHEL 4 and CentOS 5). Works great!

Benjamin · 2 months ago

Am I understanding correctly that this allows the use of the Keyring on OS X, and the secure password store on GNOME, using the same API? If so, could you provide a link to the project? I'd love to give it a shot.

kteague · 2 months ago

Yes, this project was written this summer as a Google Summer of Code project and released not too long ago:

http://pypi.python.org/pypi/keyring

johnpaulett · 2 months ago

I see the benefit of the socket-based approach, but if breaks (or at least requires jumping thru additional hoops) when you have anything other than a one machine to one environment ratio.

For instance, if I have host my staging environment and demo environment on the same EC2 host to save money, they will both have the same hostname.

Additionally, what happens when I have to scale up my production environment to multiple machines, each which will have a different hostname. One simple workaround in this case is to simply copy my production settings to prodserver1.py, prodserver2.py, etc.--but this approach would violate DRY.

Benjamin · 2 months ago

In the case of the first—multiple environments on a single machine—you couldn't use this solution, I agree.

In the case of the second, though, you don't actually need to violate DRY. If your VCS supports symlinks, you just make a single deploy.py and then symlink it to the machine names. Alternatively, since you probably have a fabfile.py already to manage deployment, and that has a list of servers, you could just modify your __init__.py script to check the same list to determine whether to use the server deployment settings or not.