Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am configuring a linux webserver to support several different websites, using Django and Apache2. I have Django code for each site, some libraries supporting each of those sites, and the Apache configuration files. Does this layout pose any problems?

home/
|--django_libraries
|  |--lib_one/
|  |--lib_two/
|--sites
|  |--site_one/
|  |--site_two/
|  |--site_three/
|--apache_conf/
|  |--apache2.conf, etc
|  |--sites-available/
|  |--sites-enabled/
|  |--et cetera
|  |--[mods-enabled and the like left under /etc]
|--apache-support/
   |--directories with certificates for ssl, authentication files, etc

My reasons:

  • This organizes the sites-specific files under one directory. I know where to find things and can back it up, or replicate it, with a single tar statement.
  • This seems to allow separate things enough to control access and security with user permissions.
  • I don't like to disturb the default Apache configurations under etc/ because I'm a newbie and often consult them. Also I find it less confusing to have the Apache configurations near the Django code.

Thoughts?

share|improve this question

5 Answers 5

Just a thought. If you are sharing libraries, problems might arise if you need to update one of these libraries.

We had this problem a while ago. We were using Zend Framework for a couple of projects with a single ZF instance. One of these projects needed to upgrade ZF, to a version with no backwards compatibility (like 1.7.8 -> 1.8). To not break the other projects, we ended up using a separate install of ZF for this project.

My recommendation is to use a versioning tool like Git or SVN to keep the libraries up-to-date on every project, and put these libraries in a library repository.

share|improve this answer
    
Well, I could put an incompatible update in a library subdirectory of its own, and link its dependents to that. –  chernevik Nov 19 '09 at 16:46
    
Re SVN -- I'm going to at least export the libraries from it. Probably make and check in any changes on a development box, and re-export to production from there. –  chernevik Nov 19 '09 at 16:47

It is similar to how I usually set up my own VPSes and servers if I am the only one doing something on them. I guess it would depend more on how this specific server is supposed to be used.

If you are just maintaining things yourself, then I think you would be fine. The shared dependencies were brought up above, so that is something to think about.

share|improve this answer

Do your applications (django apps that is) live in the site directories? If so which directories are the web roots for the sites?

Mine works like this:

var/
|--www/
|  |--website-root/
|  |  |--media-files/
|  |  |  |--css/
|  |  |  |--javascript/
|  |  |  |--images/
home/
|--djangisms
|  |--django-libraries/
|  |--my-django-website/

In the site config are instructions to django for where everything is.

share|improve this answer
    
Actually, right now I'm cogitating on how to split the django app. The view functions and templates, I think, go in the app -- but I don't know whether to put code for things like forms into the app, or put them in a "library", to be called from there by the app. –  chernevik Nov 19 '09 at 22:28
    
The book "The Definitive Guide to Django, Web Development Done Right" by Adrian Holovaty & Jacob Kaplan-Moss (Benevolent Dictators for Life, Django) has an online version maintained at djangobook.com/en/2.0 read that and the 4 part Tutorial which makes up part of the Django Documentation at docs.djangoproject.com/en/dev. That should give you enough insight to get going. If not post here, most of my django searches end up being answered here or on stackoverflow. Alternatively subscribe to the django group at google groups and ask some questions. –  Amos Nov 19 '09 at 22:54

I use "bin" for page handlers, "sbin" for system functions (System BIN), "lib" for different libraries/frameworks, "var" for system data (generated), "i" for images/css, "usr" for generated content (uploaded imgs, etc), "etc" for settings and "tmp" for temporary files.

share|improve this answer
    
This seems to spread the files out over the system, making them harder to find and backup, and I don't see what is gained by it. What am I missing? –  chernevik Nov 20 '09 at 21:44
    
Aah, I've misread the question. I use hardlinks into projects' 'lib', so nothing is copied, and the problem does not exist :) Everything edited is replicated to all instances of a single library/class in all projects' home paths. –  kolypto Nov 20 '09 at 23:36

I don't have enough reputation to add a comment .

@o_O Tync: Do you use this structure for Django based websites? chernevik's question is specific to how a number of different websites should coexist on one server, and whether they should share the Django libraries or use separately installed versions. Plus Django has specific places where it expects types of file to live (some of these can be changed if you know what you are doing). I'm assuming that your setup is not Django specific as you haven't specified where you keep your media files, admin media files, templates, where the apps live and where the site.urls is?

I would comment on chernevik's layout if I had more idea about multiple sites on one server but I don't.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.