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
