On Nov 27, 3:45 pm, Brian <[EMAIL PROTECTED]> wrote:
> Accounts could be created as often as hourly. I'd be very bad to have
> the webserver go down while people use the system (unless it was for
> less than a second or two... but even then, it's still be very
> bad :) ).
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.
A few more questions.
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.
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.
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.
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?
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.
Graham
> 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/todirecttherequestto the
> > > > > 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
-~----------~----~----~----~------~----~------~--~---
