Il giorno 30/giu/2010, alle ore 05.31, Rocky Borg ha scritto: > I've been trying out Cherokee and I must say I really like it. I have it > up and running with a single test site with uwsgi and django. This is my > first time using both cherokee and uwsgi so I'm trying to get my head > around it. Here is my problem. > > I'm working on deploying a server that will have many sites that are > django apps. I have a backend which is automated. So files, permissions, > all that stuff are setup when needed. But I'm wondering what would be > the best way to go about this with cherokee. The "Advanced Virtual > Hosting" doesn't seem to support handlers for each virtual host at least > with the default setup. All the sites would have the same file structure > i.e. > > /home/site1.com > /home/site2.com > > What would the easiest way for multiple sites to use the same uwsgi > handler in cherokee. Is there a way to do this with advanced virtual > hosting? It just doesn't seem like a separate virtual host with a > separate process of uwsgi would be the best way to go about this. > Especially since this server could eventually have 20-30+ sites of > varying sizes that need to be deployed immediately when needed (can't be > setup by hand). For example is it possible to use dynamic apps in uwsgi > to add each site with advanced virtual hosting? Any help would be > appreciated as I haven't found any documentation that offers a clear > explanation of this. > _______________________________________________ > Cherokee mailing list > [email protected] > http://lists.octality.com/listinfo/cherokee
That is an interesting (and hard) topic. In the current mercurial repository you will find the virtual hosting mode: http://projects.unbit.it/uwsgi/wiki/VirtualHosting pratically it allows yout to configure dynamic apps by domain name and not by script_name. It works without particular problems with cherokee advanced virtual hosting but as you suggest, it would be better to have apps running on different processes and uids (and with different options). I have started analyzing some time ago the possibility of a "super-uWSGI-process-manager" that will seat in the middle of your uWSGI apps and the webserver. The webserver connect (via the uwsgi protocol) to the super uWSGI that parse the request (containing uWSGI configuration options and not only the HTTP request) and eventually spawns a new instance to pass request to (with its uid and configuration flags). The only things that scare me, is that you need to run super-uWSGI as root to allow setuid() (or chroot()) Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
