Hi Graham, Sorry I didn't respond earlier - for some reason your last reply with the questions didn't show up until late today. Very odd -- didn't mean to ignore your question or give the impression that I was ignoring it. I most certainly am interested in potential solutions.
> I don't know how lighttpd works, but if one does a graceful restart > (or even a restart) with Apache, in the main it isn't noticeable to > the user as the listener socket is never released and so new > connections just queue up and aren't outright refused, ie., server > isn't actually completely stopped. The issue is more the startup time > of Django instances and whether a restart will cause active login > sessions to be terminated based on how application is written. This is > because on a restart, active instances which are still required are > restarted regardless. I know little about webservers, but I'm relieved to hear that the restarts are graceful. I believe this gracefulness was a recent addition to Lighttpd, also. Incidentally, I simply chose Lighttpd because I've never used it before, and I figure it'd be fun to learn how to set it up. I would think the Django processes ought to be persistent in the background (unless the webserver is starting/stopping them). > The actual Django application is something the users themselves are > just a user of? There is no requirement for them to be able to make > changes to a segment of code base and force their own restarts of > their instance to pick up changes. Yes, they're just Users, and will never restart the instance. > For each account, through what do they login initially? Are you > expecting to use Django based login mechanisms for that, or do you > front it all with HTTP Basic Authentication. If you are going to > somehow switch based on their identity it presumably needs to be done > outside of the context of the target Django instance else you will not > know which to go to. This is a good question, and I haven't come to a conclusion. Probably it'll be the Django built-in application-based authentication, particular to each Django instance. There will be a master map of all users to their respective Django instance. > Does the account have a distinct UNIX account associated with it, or > would all Django instances run as same user and you are then just > mapping a logical account name to a specific instance attached to a > specific database. I'm thinking they'll all run as the same Unix user, and it's just a logical mapping from an account to a database. This could change. > Would there be a calculable cap on the number of accounts you would > have active at any one time. Or would it at least be acceptable that > if there is a preconfigured number of instances you can switch between > and that limit is reached, that restarting web server would then be > seen as okay? Yes, a cap on the number of accounts is definitely possible in the short term. > Sorry, if I seem to be asking a lot of questions, but believe might > have a manageable solution for you, but want to be clear on these > things so know if will be or not and what configuration would need to > be. That's quite exciting. :o) Thank you, in advance for any solution you may be able to suggest. Brian > > On Nov 26, 11:31 pm, Graham Dumpleton <[EMAIL PROTECTED]> > > wrote: > > > > On Nov 27, 3:17 pm, Brian <[EMAIL PROTECTED]> wrote: > > > > > Hi Graham, > > > > > Thanks for the reply. No, I'm not stuck using Lighttpd at all - I just > > > > like it because it's simple and fast. :) > > > > > Here's a link to a description of what I'd like to > > > > see:http://stackoverflow.com/questions/314515 > > > > > The situation is this: I'm creating a web-site with a bunch of > > > > accounts - each account having its own database. I want people to go > > > > to the site (i.e.www.example.com/) and when they log in the > > > > application gets all its requests/responses from their account's > > > > database. For the moment, all accounts will be using the same Django > > > > applications, though that is subject to change so I'd prefer not to > > > > rely on a solution that precludes that possibility. > > > > > I suspect (but am happy to be corrected...) that the easiest and > > > > safest way to do this is to have a Django instance running in FastCGI > > > > mode with a socket for each account. When a user is logged in, their > > > > requests/responses are mapped to/from the proper Django socket via the > > > > multiplexing solution I've suggested in my original post. > > > > > As mentioned, accounts may crop up and disappear, and shouldn't > > > > require restarting the web-server. There could be dozens of accounts > > > > (which means lots of Django instances). > > > > How often would accounts be changed and if not that often, why would > > > restarting the web server be a problem? > > > > Graham > > > > > Is there any more information that would be helpful? > > > > > Cheers & thank you, > > > > Brian > > > > > On Nov 26, 10:32 pm, Graham Dumpleton <[EMAIL PROTECTED]> > > > > wrote: > > > > > > On Nov 27, 2:06 pm, Brian <[EMAIL PROTECTED]> wrote: > > > > > > > Hi everyone, > > > > > > > Here's a questions I just posted on stackoverflow.com (because I > > > > > > like > > > > > > that forum's layout) - but I thought posting it here might lead to > > > > > > more / better coverage. > > > > > > See:http://stackoverflow.com/questions/322694/ > > > > > > > Multiple installs of Django - How to configure transparent multiplex > > > > > > through the webserver (Lighttpd)? > > > > > > Are you stuck with using Lighttpd? > > > > > > Can you explain the background of the situation you have that requires > > > > > such a setup? May help in working out what to suggest. > > > > > > Graham > > > > > > > Hi Everyone, > > > > > > > This question flows from the answer to: How does one set up multiple > > > > > > accounts with separate databases for Django on one server? (http:// > > > > > > stackoverflow.com/questions/314515) > > > > > > > I haven't seen anything like this on Google or elsewhere (perhaps I > > > > > > have the wrong vocabulary), so I think input could be a valuable > > > > > > addition to the internet discourse. > > > > > > > How could one configure a server likeso: > > > > > > > * One installation of Lighttpd > > > > > > * Multiple Django projects running as FastCGI > > > > > > * The Django projects may be added/removed at will, and ought not to > > > > > > require restarting the webserver > > > > > > * Transparent redirection of all requests/responses to a particular > > > > > > Django installation depending on the current user > > > > > > > I.e. Given Django projects (with corresponding FastCGI socket): > > > > > > > * Bob (/tmp/bob.fcgi) > > > > > > * Sue (/tmp/sue.fcgi) > > > > > > * Joe (/tmp/joe.fcgi) > > > > > > > The Django projects being started with a (oversimplified) script > > > > > > likeso: > > > > > > > #!/bin/sh > > > > > > NAME=bob > > > > > > > SOCKET=/tmp/$NAME.fcgi > > > > > > > PROTO=fcgi > > > > > > DAEMON=true > > > > > > > /django_projects/$NAME/manage.py runfcgi protocol=$PROTO socket= > > > > > > $SOCKET > > > > > > daemonize=$DAEMON > > > > > > # ---- end > > > > > > > I want traffic tohttp://www.example.com/todirecttherequesttothe > > > > > > correct Django application depending on the user that is logged in. > > > > > > > In other words,http://www.example.comshouldcome"be"; /tmp/bob.fcgi > > > > > > if bob is logged in, /tmp/joe.fcgi if joe is logged in, > > > > > > /tmp/sue.fcgi > > > > > > if sue is logged in. If no-one is logged in, it should redirect to a > > > > > > login page. > > > > > > > I've contemplated a demultiplexing "plexer" FastCGI script with the > > > > > > following algorithm: > > > > > > > 1. If the cookie $PLEX is set, pipe request to /tmp/$PLEX.fcgi > > > > > > > 2. Otherwise redirect to login page (which sets the cookie PLEX > > > > > > based > > > > > > on a many-to-one mapping of Username => PLEX) > > > > > > > Of course as a matter of security $PLEX should be taint checked, and > > > > > > $PLEX shouldn't give rise to any presumption of trust. > > > > > > > A Lighttpd configuration would be likeso (though Apache, Nginx, etc. > > > > > > could be used just as easily): > > > > > > > fastcgi.server = ( "plexer.fcgi" => > > > > > > ( "localhost" => > > > > > > ( > > > > > > "socket" => "/tmp/plexer.fcgi", > > > > > > "check-local" => "disable" > > > > > > ) > > > > > > ) > > > > > > ) > > > > > > # ---- end > > > > > > > Input and thoughts, helpful links, and to know how to properly > > > > > > implement the FastCGI plexer would all be appreciated. > > > > > > > Thank you. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
