headers
Jenna Fox | 1 Apr 2012 01:24
Gravatar

Re: dead easy deployment / Camping on the fly

Oh whoops! I forgot to press the save button on the dns management page. Should go through now, certainly
within the next hour.

On fastcgi - fastcgi is not a server in itself - you cannot connect to it with a web browser. Like Passenger,
it's a way for a server like nginx or apache to launch and talk to processes which return webpages directly.

The easiest way to run camping apps for many different users would be regular CGI. You might think this as
being terribly slow - but I assure you, if ruby and it's libraries are stored on a fast SSD disk, ruby
launches incredibly quickly - further, the operating system's disk cache creates an in-ram copy of
popular applications and ruby libraries, allowing the more heavily used hosted camping apps to become
even more responsive. CGI certainly not worth ruling out. PHP works like this - loading and recompiling
each of it's source code files for each request, unless special optimisation is done - like facebook's php
to c compiler.

If CGI is too slow or consumes too many resources, there's also a middle ground worth exploring - Unicorn
uses a forking system, which is rather cool because it launches new ruby instances very very quickly -
practically instant. It wouldn't be all that difficult to make a forking server variant which forks on
each request and loads up a user's application, runs it, then closes (or maybe idles out after five
minutes). There are all sorts of interesting ways we could optimise existing server ideas to work very
well with small infrequently used applications on different domains for different fully isolated
users, rather like the ways PHP tends to be hosted which make it so practical for large numbers of users
running infrequently accessed applications.

Sandboxing is also something worth investigating.
Permalink | Reply | 2 comments |
headers
Jenna Fox | 1 Apr 2012 01:32
Gravatar

Re: dead easy deployment / Camping on the fly

The main downside to passenger, is that when things go wrong, it can be a bit 'thar be monsters in here!'

It's a bit of a mysterious technology which isn't very well documented when stuff doesn't work, or at least it wasn't when I was playing with it about 8 months ago. I ended up settling on thins to get away from passenger, though for a while I was using passenger on my local mac apache instance for testing.

—
Jenna

On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih <at> 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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 0 comments |
headers
Jenna Fox | 1 Apr 2012 01:30
Gravatar

Re: dead easy deployment / Camping on the fly

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 <IcePapih <at> 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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 23 comments |
headers
david costa | 1 Apr 2012 10:03
Picon

Re: dead easy deployment / Camping on the fly

Ah I forgot

you can compare camping running on thin here
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 <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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 <at> 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 <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 21 comments |
headers
david costa | 1 Apr 2012 09:51
Picon

Re: dead easy deployment / Camping on the fly

Okay :D after many many hours of testing I am settled for nginx and passenger.


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 <at> 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 <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 22 comments |
headers
Peter Retief | 1 Apr 2012 10:23
Picon

Re: dead easy deployment / Camping on the fly

Wonder if Google might help getting camping to run on app engine?

On 1 April 2012 10:03, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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 <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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 <at> 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 <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 20 comments |
headers
david costa | 1 Apr 2012 10:41
Picon

Re: dead easy deployment / Camping on the fly

Umh I doubt it was already here

but is far from an automated, one line /one upload system


On Sun, Apr 1, 2012 at 10:23 AM, Peter Retief <peterretief-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Wonder if Google might help getting camping to run on app engine?


On 1 April 2012 10:03, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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 <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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 <at> 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 <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 0 comments |
headers
Jenna Fox | 1 Apr 2012 11:13
Gravatar

Re: dead easy deployment / Camping on the fly

Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software.

Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well.

Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets).

Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere.

—
Jenna

On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:

Wonder if Google might help getting camping to run on app engine?

On 1 April 2012 10:03, david costa <gurugeekphp <at> gmail.com> wrote:
Ah I forgot
you can compare camping running on thin here
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 <gurugeekphp <at> gmail.com> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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 <at> 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 <IcePapih <at> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
 

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 18 comments |
headers
Isak Andersson | 1 Apr 2012 12:25

Re: dead easy deployment / Camping on the fly

Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :)
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Jenna Fox <a <at> creativepony.com> skrev:
Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software.

Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well.

Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets).

Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere.

—
Jenna

On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:

Wonder if Google might help getting camping to run on app engine?

On 1 April 2012 10:03, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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 <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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 <at> 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 <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ 
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 17 comments |
headers
Jenna Fox | 1 Apr 2012 12:28
Gravatar

Re: dead easy deployment / Camping on the fly

I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way.

—
Jenna

On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote:

Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :)
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Jenna Fox <a <at> creativepony.com> skrev:
Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software.

Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well.

Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets).

Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere.

—
Jenna

On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:

Wonder if Google might help getting camping to run on app engine?

On 1 April 2012 10:03, david costa <gurugeekphp <at> gmail.com> wrote:
Ah I forgot
you can compare camping running on thin here
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 <gurugeekphp <at> gmail.com> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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 <at> 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 <IcePapih <at> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list
 

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Permalink | Reply | 16 comments |

Gmane