Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa <gurugeek...@gmail.com> wrote:
> Ah I forgot > you can compare camping running on thin here > http://run.camping.io:3301/ > vs passenger at http://run.camping.io > > apparently db has some problems with fusion passenger (see > http://run.camping.io create HTML page and test HTML page. The same code > on thin works just fine... umhh oh no don't feel like more debugging ): > > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa <gurugeek...@gmail.com> wrote: > >> Okay :D after many many hours of testing I am settled for nginx and >> passenger. >> live at http://run.camping.io/ >> >> I did try every apache combination (with passenger, with cgi, etc. etc.) >> as is simply not really working fine. >> I tried some other obscure web servers too but apparently this seems to >> work fine for now :) other servers would run the app as CGI or FastCGI. I >> am not worried about speed just ease of deployment and nginx with passenger >> seems to do the job for now. The alternative is nginx as reverse proxy but >> as Jenna rightly pointed out it would spawn a lot of thin instances that >> might or might not be used. >> >> I did throw the sponge at Webdav on apache. It doesn't work as expected >> and not with all clients. It seems more suitable to store quick files than >> something else. >> Can try tomorrow with nginx but perhaps it would be nicer to have a quick >> camping hack to upload a file etc. but you can't just automate it entirely >> else you can have people running malicious code automatically... >> >> I can do the shell scripts to create virtual users for nginx and dns. >> Another option is to give a normal hosting for camping users. It wouldn't >> be an issue to have 100-200 trusted users to have access to this e.g. we >> can build a camping fronted for users to apply with a selection e.g. their >> github account, why they want the deployment hosting etc. and then once >> approved we would give them a normal account that would allow them to >> upload files on SFTP and may be even shell (which BTW is something you >> don't have on heroku and other services. Of course this could be protected >> for security or given only to active people. >> >> How does heroku screens against abuses? >> Anyway if some of you would like to be alpha users in this system let me >> know, I will be glad to set you up as soon as I am done testing subdomains >> etc. ;) >> And of course if you have a better idea for a setup let me know. >> >> Regards >> David >> >> >> >> >> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox <a...@creativepony.com> wrote: >> >>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule >>> >>> Or you could implement webdav as an application nginx proxies to, just >>> as it proxies to ruby instances. >>> >>> — >>> Jenna >>> >>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote: >>> >>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <icepa...@lavabit.com>wrote: >>> >>> ** Actually setting up a reverse proxy gives better performance for the >>> end user As you can have some sort of buffer between them. The Unicorn >>> server takes care of whatever nginx asks for, and while it waits it can >>> server whatever unicorn outputs. It doesn't have to wait for what it >>> outputs itself to get done because you have a queue. Or something like that. >>> >>> >>> Mh I am not really sure it would be a better performance as it would be >>> anyway more than one process. I think that phusion passenger is pretty much >>> the most robust solution for this. >>> >>> >>> Some people actually out Apache to do PHP stuff while nginx acts as a >>> reverse proxy and actually shows things to the user in the same way you'd >>> do with Unicorn/Thin >>> >>> >>> Well this would be even more load as two web servers will run at the >>> same time. Apache + Phusion passenger already lets you run .php or anything >>> you want. >>> >>> But this is not the issue really. I think this is all fine in term of >>> mono user. Question: if you have 100 users how do you configure it ? >>> How can you add webdav support on the top of the Nginx + unicorn setup ? >>> >>> >>> But perhaps That's too much for a server ment to serve other peoples >>> applications! Then you have to scale down the resources used. >>> >>> >>> I am open to anything but if I can't do something I might ask for some >>> brave volunteers to set it up as I really never tried anything else beside >>> for local/quick test deployment. >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> > > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list