Re: dead easy deployment / Camping on the fly
Been trying the setup (okay, this is not going to win any awards, but...): http://dave.camping.sh/ It's an old app rewritten (except - as yet - for the content :-) DaveE ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
Hi, As I already mentioned I use Camping with fcgi in production. If It is your choice (and not passenger), I will help you set it up. On Sun, Apr 1, 2012 at 5:49 PM, david costa gurugeek...@gmail.com wrote: Hello again ! :) well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. Thanks David On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson icepa...@lavabit.comwrote: Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: 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...@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 gurugeek...@gmail.com wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at
Re: dead easy deployment / Camping on the fly
I really want to know what gems do you (all out there) think quality... Maybe there's a statistics from a big gem server which ones are the most wanted. What about the versions? Applications can work differently (or not work :- ) with different versions of gems (and ruby). Will the hosting server allow to open connections to other hosts for the uploaded apps? It is also dangerous like backtick/system calls. But if it's banned, lots of gems are excluded. 2012/4/1 Isak Andersson icepa...@lavabit.com ** Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: 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...@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 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.comwrote: 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
Re: dead easy deployment / Camping on the fly
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. FastCGI IS a server in itself - you can connect to it, but not with a web browser. It's because it uses a protocol called fastcgi, not http. (The easiest way to interact with it is to use the cgi-fcgi command from command line...) It is not necessary to use the webserver to launch the fcgi processes, they can be configured just to connect to these servers, and you can run them whatever way you want. (I use simple init scripts for this purpose, but in a specialized hosting environment you must build a launcher for them, that handles new uploads, handles broken scripts (those that die after starting), and this system has to manage with ports associated with users, like in the case of using thin and reverse proxies.) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
Yes thanks for this well I am pretty set with nginx + passenger. Once I spent the week end digging into it I am pretty happy and it is the recommended way to deploy by many so I will trust this setup for now. I like this more than moving parts with reverse proxies and since it will end up to me to manage this I want to keep it simple as time is scarce ;) On Mon, Apr 2, 2012 at 11:08 AM, Nokan Emiro uzleep...@gmail.com wrote: 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. FastCGI IS a server in itself - you can connect to it, but not with a web browser. It's because it uses a protocol called fastcgi, not http. (The easiest way to interact with it is to use the cgi-fcgi command from command line...) It is not necessary to use the webserver to launch the fcgi processes, they can be configured just to connect to these servers, and you can run them whatever way you want. (I use simple init scripts for this purpose, but in a specialized hosting environment you must build a launcher for them, that handles new uploads, handles broken scripts (those that die after starting), and this system has to manage with ports associated with users, like in the case of using thin and reverse proxies.) ___ 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
Re: dead easy deployment / Camping on the fly
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.comwrote: ** 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
Re: dead easy deployment / Camping on the fly
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.comwrote: ** 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
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 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.comwrote: ** 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
Re: dead easy deployment / Camping on the fly
Umh I doubt it was already here http://camping.io/Book/-Publishing-an-App#Using-Google-App-Engine but is far from an automated, one line /one upload system On Sun, Apr 1, 2012 at 10:23 AM, Peter Retief peterret...@gmail.com wrote: 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.comwrote: 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.comwrote: ** 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
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 gurugeek...@gmail.com (mailto: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 (mailto: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 (mailto: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 (mailto: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
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...@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 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,
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...@creativepony.com (mailto:a...@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 gurugeek...@gmail.com (mailto: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 (mailto: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
Re: dead easy deployment / Camping on the fly
Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: 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...@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 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
Re: dead easy deployment / Camping on the fly
@Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: 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...@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 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
Re: dead easy deployment / Camping on the fly
Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: 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...@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 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
Re: dead easy deployment / Camping on the fly
A bit late in the day, but (quick and probably uninformed thought, given the volume of messages I just skimmed) might rvm help manage Ruby installs/updates/gems safely? - DaveE Hello again ! :) well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. Thanks David On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson icepa...@lavabit.com wrote: Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: 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...@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 gurugeek...@gmail.com wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at
Re: dead easy deployment / Camping on the fly
Oh gods not RVM. This setup does not need another layer of complexity. On my own server, I use five thins, which run all the time, on a set of five ports which nginx proxy to. To run hundreds of camping apps, this sort of persistent setup isn't viable. CGI would work, but could be a little slow for some more complex applications. A better solution is, in my opinion, to fork. thins or unicorns could be connected with a simple camping app which forks on each request, loads a users app in to that instance, runs it once, then closes. It would be faster than CGI, not too hard to implement, and wouldn't take more resources to install more apps on the server. It also makes for a convenient place to run code before the user's application runs, which maybe useful for sandboxing or setting up web accessible logging. From what I've heard chroot isn't a good way to jail processes - it doesn't restrict network access, and it's often possible to escape the jail. Consider this: A script loads the socket library and opens port after port until computer fails. Disable the socket library? have the ruby process store a binary inside it, which it saves to a file, sets execute permission, then runs - it does the same thing. Another attack would be a fork bomb. Security is really complex. How did dot geek deal with it? did you ever have trouble with malicious users? — Jenna On Monday, 2 April 2012 at 1:49 AM, david costa wrote: Hello again ! :) well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. Thanks David On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson icepa...@lavabit.com (mailto:icepa...@lavabit.com) wrote: Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) skrev: 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...@creativepony.com (mailto:a...@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.
Re: dead easy deployment / Camping on the fly
On Mon, Apr 2, 2012 at 1:02 AM, Jenna Fox a...@creativepony.com wrote: Oh gods not RVM. This setup does not need another layer of complexity. On my own server, I use five thins, which run all the time, on a set of five ports which nginx proxy to. To run hundreds of camping apps, this sort of persistent setup isn't viable. CGI would work, but could be a little slow for some more complex applications. A better solution is, in my opinion, to fork. thins or unicorns could be connected with a simple camping app which forks on each request, loads a users app in to that instance, runs it once, then closes. It would be faster than CGI, not too hard to implement, and wouldn't take more resources to install more apps on the server. It also makes for a convenient place to run code before the user's application runs, which maybe useful for sandboxing or setting up web accessible logging. I am pretty ignorant on unicorn but I did fix the db error which was fixed by adding HomePage::Models::Base.establish_connection( :adapter = 'sqlite3', :database = '/home/gurugeek/.camping.db') to the end of the file so now it is working with sqlite support http://run.camping.io Ironically this goes back to the first question I wrote to Isak on where was the famous .camping.db that was mentioned in the blog example. For a beginner it takes some googling to find out but now I know so not a big deal ! So we have now a working system with nginx and passenger. This is extremely simple as a user will have to upload the files on this folder and is ready to go. I have already tested multiple host on nginx and it works fine and is much easier to setup than apache. I already coded a add_camping_user bash script to automate user creation + nginx configuration updating and restart. So I am open to any fork but we have a working system (currently on linux but working fine also on mac see it running at http://basic.sh/) that should work fine with any basic camping app + sqlite too. I actually think that the guys at phusion did a good job on passenger as it is well documented, easy to install (if you use nginx it would even install nginx for you if you want) and they even included a camping example on the site. Whomever wants to try the system can email me and I will be glad to open an account for testing purposes. From what I've heard chroot isn't a good way to jail processes - it doesn't restrict network access, and it's often possible to escape the jail. Consider this: A script loads the socket library and opens port after port until computer fails. Disable the socket library? have the ruby process store a binary inside it, which it saves to a file, sets execute permission, then runs - it does the same thing. Another attack would be a fork bomb. Security is really complex. How did dot geek deal with it? did you ever have trouble with malicious users? You are very right on security :'( The first idea is to create users without shell so they can use sftp but not ssh. Then ssh could be granted to admins or people helping in the project. Now this doesn't solve security entirely as you can still run malicious stuff via sftp. In dotgeek we had a two tier screening process: a) the online form asked for an authorization key. This was given out on IRC after people explained why they wanted the hosting etc to some admins; b) the online form asked some general information about the user and why he wanted the free hosting. Based on the reply we would activate the account or not. Now this was on the pre-github and Facebook era perhaps now it is a bit easier to find out if someone is genuine or not. Still we had many issues with dotgeek. We discovered some people running even paypal clones to grab details from users. Emails was another issues we had to deal with and many other small ones but in short the only way to keep it decent was to screen people. I am too new to ruby and camping to know what kind of hostile commands you can run from a script but I guess it is as dangerous as php (or perhaps not?). If we want to automate some stuff I can easily build a script to find out if an uploaded file is a camping script or not. At least from the appearance. You already told me how Heroku does it and seems pretty smart. Is engine yard doing something similar ? There are essentially two options: a) Allow users to upload an app and their files via camping backed online interface. This can be fairly easy and would have a zero knowledge required. It would be somehow the opposite of other services that require you to use git and similar. The issue is how to evaluate what is uploaded. If we have some details about the user we could run a manual check the first 1-3 times and then set him/her free. If there is another way to evaluate files securely (e.g. is a camping app and not something malicious) it would be even better ! b) Open standard unix users. This is not an issue in terms of capacity but more security in the sense of
Re: dead easy deployment / Camping on the fly
Perhaps if this is working in time of the deployment screencast we can showcase
this kind of deployment AND unicorn/nginx!
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
david costa gurugeek...@gmail.com skrev:
BTW if you want to point a run.camping.io or host.camping.io or anything you
like to 66.116.108.12 will then be able to show an (hopefully) working demo
using the official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.com wrote:
oh sure ! for me is not a problem - love camping.io as a domain !
first worry is to have a working system that is fairly stable and usable albeit
it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote:
We can just use a *.camping.io catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io or anything.camping.io for the frontend but if the
server has to allow users to create myfancyapp.camping.io it would be
complicated as I would need to run the camping.io DNS on the hosting server to
create the sub domains on the fly. I started working on it more details on a
separate email.
I love your idea about the key-value database how can we implement this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com wrote:
Those both sound like brilliant servers! I'm not laughing at all. If my mac
mini is good enough for sky rim, it's good enough for web hosting for sure!
Can we just use camping.io?
I think starting simple is a good idea. Databases are pretty cool among web
developers for various reasons, but I think are totally unnecessary for most
smaller experimental applications. For a beginner, I'm inclined to have
key-value databases. A really simple key-value database would work like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up the kevin
to a series of about four directories and then a file, and conveniently fff
in base36 is 19995, which is a very nice maximum number of things you'd ever
want to put in a single directory if using something like EXT4 or HFS+. Of
course, if using a B-Tree filesystem like reiser, btrfs, zfs there is no such
limitation so you can skip the scanning joining thing and just open
database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in to what seems
from the outside to be a persistent hash.
I was working on another thing called ForeverHash, which was the same sort of
idea, but used flat files. If people are interested I'd be curious enough to
revive that project with more of a CouchDB inspired design.
I like all these filesystem based solutions (sqlite, crazy hash in folders,
flat file key-value db's) because they can be backed up and restored via webdav
or sftp or whatever, and you don't need to do any weird stuff of configuring
which ports and usernames and passwords in your database abstraction. I prefer
the idea of having a little key-value filesystem db written in clear straight
forward ruby code, because it means kids learning can see how it works and hack
at it - as nice as sqlite is, it is in no way transparent. You at least have to
learn SQL if you want to play with it's innards, and possibly C.
On 31/03/2012, at 3:22 AM, david costa wrote:
Hello all,
I am opening a separate topic just to brainstorm the idea of a free, simple
camping deployment/hosting option.
Now this is not about re-inventing the wheel as heroku already supports camping
apps too. So this would be the ground idea:
a) This would be entirely free - no paid plans to upgrade etc.;
b) Eventually users should be able to deploy a camping application by launching
something like camping-fly myapp in the command line and it would simply work
(through a git push or similar) and make it available live in a custom domain
like camping.sh or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am
c) Database fanciness should also be available or at least sqlite/mysql
Suggestion and ideas on how to achieve this are welcome (or professionals with
the expertise willing to do a simple project based on this )
servers I can make available for this:
Debian 6
Intel Core i7 3930K (6 x 3,20 GHz)
RAM 64 GB
3000 GB HD + 256 MB SSD drive (very useful for databases, much faster)
OR (don't laugh)
Mac mini
2.0GHz quad-core Intel Core i7
8GB memory
2X256GB Solid State Drive
of course we would need to limit this to screened applicants to avoid any
spammers/troublemakers
Best Regards
David
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io (http://run.camping.io) or
host.camping.io (http://host.camping.io) or anything you like to
66.116.108.12 will then be able to show an (hopefully) working demo using the
official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.com
(mailto:gurugeek...@gmail.com) wrote:
oh sure ! for me is not a problem - love camping.io (http://camping.io) as
a domain !
first worry is to have a working system that is fairly stable and usable
albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
We can just use a *.camping.io (http://camping.io) catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io (http://host.camping.io/) or
anything.camping.io (http://anything.camping.io/) for the frontend but
if the server has to allow users to create myfancyapp.camping.io
(http://myfancyapp.camping.io/) it would be complicated as I would need
to run the camping.io (http://camping.io/) DNS on the hosting server to
create the sub domains on the fly. I started working on it more details
on a separate email.
I love your idea about the key-value database how can we implement this
?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
Those both sound like brilliant servers! I'm not laughing at all. If
my mac mini is good enough for sky rim, it's good enough for web
hosting for sure!
Can we just use camping.io (http://camping.io/)?
I think starting simple is a good idea. Databases are pretty cool
among web developers for various reasons, but I think are totally
unnecessary for most smaller experimental applications. For a
beginner, I'm inclined to have key-value databases. A really simple
key-value database would work like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up
the kevin to a series of about four directories and then a file, and
conveniently fff in base36 is 19995, which is a very nice maximum
number of things you'd ever want to put in a single directory if
using something like EXT4 or HFS+. Of course, if using a B-Tree
filesystem like reiser, btrfs, zfs there is no such limitation so you
can skip the scanning joining thing and just open
database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in to
what seems from the outside to be a persistent hash.
I was working on another thing called ForeverHash, which was the same
sort of idea, but used flat files. If people are interested I'd be
curious enough to revive that project with more of a CouchDB inspired
design.
I like all these filesystem based solutions (sqlite, crazy hash in
folders, flat file key-value db's) because they can be backed up and
restored via webdav or sftp or whatever, and you don't need to do any
weird stuff of configuring which ports and usernames and passwords in
your database abstraction. I prefer the idea of having a little
key-value filesystem db written in clear straight forward ruby code,
because it means kids learning can see how it works and hack at it -
as nice as sqlite is, it is in no way transparent. You at least have
to learn SQL if you want to play with it's innards, and possibly C.
On 31/03/2012, at 3:22 AM, david costa wrote:
Hello all,
I am opening a separate topic just to brainstorm the idea of a
free, simple camping deployment/hosting option.
Now this is not about re-inventing the wheel as heroku already
supports camping apps too. So this would be the ground idea:
a) This would be entirely free - no paid plans to upgrade etc.;
b) Eventually users should be able to deploy a camping application
by launching something like camping-fly myapp in the command line
and it would simply work (through a git push or similar) and make
it available live in a custom domain like camping.sh
(http://camping.sh) or ruby.am (http://ruby.am/) e.g.
myfancyapp.camping.sh (http://myfancyapp.camping.sh/) or
myfancyapp.ruby.am (http://myfancyapp.ruby.am/)
c) Database fanciness
Re: dead easy deployment / Camping on the fly
Apache? What are your thoughts on that choice I am curious? :)
—
Jenna
On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:
Thank you :D as soon as the DNS will propagate it should be live.
Some updates: now added the design from camping.io (http://camping.io)
(working on the fonts) and I have narrowed down the probably easiest/best way
to do it:
using Webdav module on apache. So there will be no issue with creating real
server users and it should really be easily accessible by anyone, anywhere.
Working on some securities configurations to be sure that it works fine!
On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io (http://run.camping.io) or
host.camping.io (http://host.camping.io) or anything you like to
66.116.108.12 will then be able to show an (hopefully) working demo using
the official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.com
(mailto:gurugeek...@gmail.com) wrote:
oh sure ! for me is not a problem - love camping.io (http://camping.io)
as a domain !
first worry is to have a working system that is fairly stable and
usable albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
We can just use a *.camping.io (http://camping.io) catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io (http://host.camping.io/) or
anything.camping.io (http://anything.camping.io/) for the frontend
but if the server has to allow users to create
myfancyapp.camping.io (http://myfancyapp.camping.io/) it would be
complicated as I would need to run the camping.io
(http://camping.io/) DNS on the hosting server to create the sub
domains on the fly. I started working on it more details on a
separate email.
I love your idea about the key-value database how can we implement
this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com
(mailto:a...@creativepony.com) wrote:
Those both sound like brilliant servers! I'm not laughing at all.
If my mac mini is good enough for sky rim, it's good enough for
web hosting for sure!
Can we just use camping.io (http://camping.io/)?
I think starting simple is a good idea. Databases are pretty cool
among web developers for various reasons, but I think are totally
unnecessary for most smaller experimental applications. For a
beginner, I'm inclined to have key-value databases. A really
simple key-value database would work like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It
splits up the kevin to a series of about four directories and
then a file, and conveniently fff in base36 is 19995, which is
a very nice maximum number of things you'd ever want to put in a
single directory if using something like EXT4 or HFS+. Of course,
if using a B-Tree filesystem like reiser, btrfs, zfs there is no
such limitation so you can skip the scanning joining thing and
just open database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in
to what seems from the outside to be a persistent hash.
I was working on another thing called ForeverHash, which was the
same sort of idea, but used flat files. If people are interested
I'd be curious enough to revive that project with more of a
CouchDB inspired design.
I like all these filesystem based solutions (sqlite, crazy hash
in folders, flat file key-value db's) because they can be backed
up and restored via webdav or sftp or whatever, and you don't
need to do any weird stuff of configuring which ports and
usernames and passwords in your database abstraction. I prefer
the idea of having a little key-value filesystem db written in
clear straight forward ruby code, because it means kids learning
can see how it works and hack at it - as nice as sqlite is, it is
in no way transparent. You at least have to learn SQL if you want
to play with it's innards, and
Re: dead easy deployment / Camping on the fly
Hello Jenna !
I think that run rack applications the most efficient way seems to be
phusion passenger that works with apache and nginx. It might work with
other setups but it is not documented.
The other alternative to serve a camping application is to use a standard
ruby webserver (thin, unicorn, etc.) and use either apache or nginx as
reverse proxy. This should be more resource consuming as you would have
both a thin/unicorn instance running and nginx. The setup of passenger +
apache seems to be very easy as you just drop the file with the camping app
and it works. It can't really get more easier than this.
The camping file has to be called config.ru
http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand
this is the only way it works on my tests but I am sure that there is
an easy way to work with several files or in a different way.
Now if we want to use webdav apache has the module and with a digest
authentication over ssl should be fairly secure. It also allows to limit
the upload file size which could be useful (e.g. if someone is obviously
trying to upload not a camping file !).
This is what I found so far as a possible solution but I am open to
anything. I did try also an image that was using git/capistrano for remote
deployment but somehow seemed an overkill to me and it didn't really work.
All I am doing is highly experimental so I am more than happy to see other
idea/possibilities and see how far I can go with it.
I did think about webdav based on your idea which I think would make this
different than heroku etc. like some beginners would not know git and might
just like a little tent for their shiny camping app !
David
On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox a...@creativepony.com wrote:
Apache? What are your thoughts on that choice I am curious? :)
—
Jenna
On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:
Thank you :D as soon as the DNS will propagate it should be live.
Some updates: now added the design from camping.io (working on the fonts)
and I have narrowed down the probably easiest/best way to do it:
using Webdav module on apache. So there will be no issue with creating
real server users and it should really be easily accessible by anyone,
anywhere. Working on some securities configurations to be sure that it
works fine!
On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com wrote:
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io or host.camping.io or anything
you like to 66.116.108.12 will then be able to show an (hopefully) working
demo using the official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.comwrote:
oh sure ! for me is not a problem - love camping.io as a domain !
first worry is to have a working system that is fairly stable and usable
albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote:
We can just use a *.camping.io catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io or anything.camping.io for the frontend but
if the server has to allow users to create myfancyapp.camping.io it would
be complicated as I would need to run the camping.io DNS on the hosting
server to create the sub domains on the fly. I started working on it more
details on a separate email.
I love your idea about the key-value database how can we implement this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com wrote:
Those both sound like brilliant servers! I'm not laughing at all. If my
mac mini is good enough for sky rim, it's good enough for web hosting for
sure!
Can we just use camping.io?
I think starting simple is a good idea. Databases are pretty cool among
web developers for various reasons, but I think are totally unnecessary for
most smaller experimental applications. For a beginner, I'm inclined to
have key-value databases. A really simple key-value database would work
like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up the
kevin to a series of about four directories and then a file, and
conveniently fff in base36 is 19995, which is a very nice maximum number
of things you'd ever want to put in a single directory if using something
like EXT4 or HFS+. Of course, if using a B-Tree filesystem like reiser,
btrfs, zfs there is no such limitation so you can skip the scanning joining
thing and just open database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in to what
seems from the outside to
Re: dead easy deployment / Camping on the fly
Hi,
I run a few Camping apps in production with Rack's FastCGI handler.
This way it is completely separable from the webserver, which can be
nginx, apache, lighttpd, or anything else that implements the FastCGI
protocol. On top of that it's more scalable, because you can run these
processes on different machines -- if you feel so.
...just an idea to think about, but better than using reverse proxies.
On Sat, Mar 31, 2012 at 4:29 PM, david costa gurugeek...@gmail.com wrote:
Hello Jenna !
I think that run rack applications the most efficient way seems to be
phusion passenger that works with apache and nginx. It might work with
other setups but it is not documented.
The other alternative to serve a camping application is to use a standard
ruby webserver (thin, unicorn, etc.) and use either apache or nginx as
reverse proxy. This should be more resource consuming as you would have
both a thin/unicorn instance running and nginx. The setup of passenger +
apache seems to be very easy as you just drop the file with the camping app
and it works. It can't really get more easier than this.
The camping file has to be called config.ru
http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand
this is the only way it works on my tests but I am sure that there is
an easy way to work with several files or in a different way.
Now if we want to use webdav apache has the module and with a digest
authentication over ssl should be fairly secure. It also allows to limit
the upload file size which could be useful (e.g. if someone is obviously
trying to upload not a camping file !).
This is what I found so far as a possible solution but I am open to
anything. I did try also an image that was using git/capistrano for remote
deployment but somehow seemed an overkill to me and it didn't really work.
All I am doing is highly experimental so I am more than happy to see other
idea/possibilities and see how far I can go with it.
I did think about webdav based on your idea which I think would make this
different than heroku etc. like some beginners would not know git and might
just like a little tent for their shiny camping app !
David
On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox a...@creativepony.com wrote:
Apache? What are your thoughts on that choice I am curious? :)
—
Jenna
On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:
Thank you :D as soon as the DNS will propagate it should be live.
Some updates: now added the design from camping.io (working on the
fonts) and I have narrowed down the probably easiest/best way to do it:
using Webdav module on apache. So there will be no issue with creating
real server users and it should really be easily accessible by anyone,
anywhere. Working on some securities configurations to be sure that it
works fine!
On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com wrote:
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io or host.camping.io or
anything you like to 66.116.108.12 will then be able to show an
(hopefully) working demo using the official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.comwrote:
oh sure ! for me is not a problem - love camping.io as a domain !
first worry is to have a working system that is fairly stable and usable
albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote:
We can just use a *.camping.io catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io or anything.camping.io for the frontend but
if the server has to allow users to create myfancyapp.camping.io it
would be complicated as I would need to run the camping.io DNS on the
hosting server to create the sub domains on the fly. I started working on
it more details on a separate email.
I love your idea about the key-value database how can we implement this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com wrote:
Those both sound like brilliant servers! I'm not laughing at all. If my
mac mini is good enough for sky rim, it's good enough for web hosting for
sure!
Can we just use camping.io?
I think starting simple is a good idea. Databases are pretty cool among
web developers for various reasons, but I think are totally unnecessary for
most smaller experimental applications. For a beginner, I'm inclined to
have key-value databases. A really simple key-value database would work
like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up the
kevin to a series
Re: dead easy deployment / Camping on the fly
Thanks for this but how would it run for multiple users on the same port (80) like yourname.camping.io yourname2.camping.io without having nginx or apache as a reverse proxy ? On Sat, Mar 31, 2012 at 4:44 PM, Nokan Emiro uzleep...@gmail.com wrote: Hi, I run a few Camping apps in production with Rack's FastCGI handler. This way it is completely separable from the webserver, which can be nginx, apache, lighttpd, or anything else that implements the FastCGI protocol. On top of that it's more scalable, because you can run these processes on different machines -- if you feel so. ...just an idea to think about, but better than using reverse proxies. On Sat, Mar 31, 2012 at 4:29 PM, david costa gurugeek...@gmail.comwrote: Hello Jenna ! I think that run rack applications the most efficient way seems to be phusion passenger that works with apache and nginx. It might work with other setups but it is not documented. The other alternative to serve a camping application is to use a standard ruby webserver (thin, unicorn, etc.) and use either apache or nginx as reverse proxy. This should be more resource consuming as you would have both a thin/unicorn instance running and nginx. The setup of passenger + apache seems to be very easy as you just drop the file with the camping app and it works. It can't really get more easier than this. The camping file has to be called config.ru http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand this is the only way it works on my tests but I am sure that there is an easy way to work with several files or in a different way. Now if we want to use webdav apache has the module and with a digest authentication over ssl should be fairly secure. It also allows to limit the upload file size which could be useful (e.g. if someone is obviously trying to upload not a camping file !). This is what I found so far as a possible solution but I am open to anything. I did try also an image that was using git/capistrano for remote deployment but somehow seemed an overkill to me and it didn't really work. All I am doing is highly experimental so I am more than happy to see other idea/possibilities and see how far I can go with it. I did think about webdav based on your idea which I think would make this different than heroku etc. like some beginners would not know git and might just like a little tent for their shiny camping app ! David On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox a...@creativepony.com wrote: Apache? What are your thoughts on that choice I am curious? :) — Jenna On Sunday, 1 April 2012 at 12:27 AM, david costa wrote: Thank you :D as soon as the DNS will propagate it should be live. Some updates: now added the design from camping.io (working on the fonts) and I have narrowed down the probably easiest/best way to do it: using Webdav module on apache. So there will be no issue with creating real server users and it should really be easily accessible by anyone, anywhere. Working on some securities configurations to be sure that it works fine! On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com wrote: @David - sorted, both those subdomains now point to your machine. :) — Jenna On Saturday, 31 March 2012 at 4:10 PM, david costa wrote: BTW if you want to point a run.camping.io or host.camping.io or anything you like to 66.116.108.12 will then be able to show an (hopefully) working demo using the official domain ;) On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.comwrote: oh sure ! for me is not a problem - love camping.io as a domain ! first worry is to have a working system that is fairly stable and usable albeit it might be launched as alpha/beta anyway :) On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote: We can just use a *.camping.io catchall entry On 31/03/2012, at 3:30 PM, david costa wrote: Hello Jenna, we could use host.camping.io or anything.camping.io for the frontend but if the server has to allow users to create myfancyapp.camping.io it would be complicated as I would need to run the camping.io DNS on the hosting server to create the sub domains on the fly. I started working on it more details on a separate email. I love your idea about the key-value database how can we implement this ? Thanks David On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com wrote: Those both sound like brilliant servers! I'm not laughing at all. If my mac mini is good enough for sky rim, it's good enough for web hosting for sure! Can we just use camping.io? I think starting simple is a good idea. Databases are pretty cool among web developers for various reasons, but I think are totally unnecessary for most smaller experimental applications. For a beginner, I'm inclined to have key-value databases. A really simple key-value database would work like this: sections =
Re: dead easy deployment / Camping on the fly
This solution is almost the same as using reverse proxies, but between the nginx and the Rack/Camping app you don't need HTTP traffic, just FastCGI. That means you can save one layer in the application, you don't need a http server (thin, mongrel, etc.) that point. Rack is a native FastCGI speaker. However this is the only difference, in other ways it's the same as using reverse proxy. The webserver (nging) knows about the virtual hosts, and maps them into host:port pairs, where the appropriate FastCGI server (the Rack itself) listens for connections. You can call this reverse proxying too if you want, but in this case there are different protocols on the client side (http) and the server side (fcgi). On Sat, Mar 31, 2012 at 4:51 PM, david costa gurugeek...@gmail.com wrote: Thanks for this but how would it run for multiple users on the same port (80) like yourname.camping.io yourname2.camping.io without having nginx or apache as a reverse proxy ? On Sat, Mar 31, 2012 at 4:44 PM, Nokan Emiro uzleep...@gmail.com wrote: Hi, I run a few Camping apps in production with Rack's FastCGI handler. This way it is completely separable from the webserver, which can be nginx, apache, lighttpd, or anything else that implements the FastCGI protocol. On top of that it's more scalable, because you can run these processes on different machines -- if you feel so. ...just an idea to think about, but better than using reverse proxies. On Sat, Mar 31, 2012 at 4:29 PM, david costa gurugeek...@gmail.comwrote: Hello Jenna ! I think that run rack applications the most efficient way seems to be phusion passenger that works with apache and nginx. It might work with other setups but it is not documented. The other alternative to serve a camping application is to use a standard ruby webserver (thin, unicorn, etc.) and use either apache or nginx as reverse proxy. This should be more resource consuming as you would have both a thin/unicorn instance running and nginx. The setup of passenger + apache seems to be very easy as you just drop the file with the camping app and it works. It can't really get more easier than this. The camping file has to be called config.ru http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand this is the only way it works on my tests but I am sure that there is an easy way to work with several files or in a different way. Now if we want to use webdav apache has the module and with a digest authentication over ssl should be fairly secure. It also allows to limit the upload file size which could be useful (e.g. if someone is obviously trying to upload not a camping file !). This is what I found so far as a possible solution but I am open to anything. I did try also an image that was using git/capistrano for remote deployment but somehow seemed an overkill to me and it didn't really work. All I am doing is highly experimental so I am more than happy to see other idea/possibilities and see how far I can go with it. I did think about webdav based on your idea which I think would make this different than heroku etc. like some beginners would not know git and might just like a little tent for their shiny camping app ! David On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox a...@creativepony.com wrote: Apache? What are your thoughts on that choice I am curious? :) — Jenna On Sunday, 1 April 2012 at 12:27 AM, david costa wrote: Thank you :D as soon as the DNS will propagate it should be live. Some updates: now added the design from camping.io (working on the fonts) and I have narrowed down the probably easiest/best way to do it: using Webdav module on apache. So there will be no issue with creating real server users and it should really be easily accessible by anyone, anywhere. Working on some securities configurations to be sure that it works fine! On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com wrote: @David - sorted, both those subdomains now point to your machine. :) — Jenna On Saturday, 31 March 2012 at 4:10 PM, david costa wrote: BTW if you want to point a run.camping.io or host.camping.io or anything you like to 66.116.108.12 will then be able to show an (hopefully) working demo using the official domain ;) On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.comwrote: oh sure ! for me is not a problem - love camping.io as a domain ! first worry is to have a working system that is fairly stable and usable albeit it might be launched as alpha/beta anyway :) On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote: We can just use a *.camping.io catchall entry On 31/03/2012, at 3:30 PM, david costa wrote: Hello Jenna, we could use host.camping.io or anything.camping.io for the frontend but if the server has to allow users to create myfancyapp.camping.ioit would be complicated as I would need to run the camping.io DNS on the hosting
Re: dead easy deployment / Camping on the fly
On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson icepa...@lavabit.comwrote: ** 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
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. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
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 icepa...@lavabit.com (mailto: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 (mailto: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
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 icepa...@lavabit.com (mailto: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 (mailto: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
Re: dead easy deployment / Camping on the fly
oops - should have put my last reply here... - DaveE Hello all, I am opening a separate topic just to brainstorm the idea of a free, simple camping deployment/hosting option. Now this is not about re-inventing the wheel as heroku already supports camping apps too. So this would be the ground idea: a) This would be entirely free - no paid plans to upgrade etc.; b) Eventually users should be able to deploy a camping application by launching something like camping-fly myapp in the command line and it would simply work (through a git push or similar) and make it available live in a custom domain like camping.sh or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am c) Database fanciness should also be available or at least sqlite/ mysql Suggestion and ideas on how to achieve this are welcome (or professionals with the expertise willing to do a simple project based on this ) servers I can make available for this: Debian 6 Intel Core i7 3930K (6 x 3,20 GHz) RAM 64 GB 3000 GB HD + 256 MB SSD drive (very useful for databases, much faster) OR (don't laugh) Mac mini 2.0GHz quad-core Intel Core i7 8GB memory 2X256GB Solid State Drive of course we would need to limit this to screened applicants to avoid any spammers/troublemakers Best Regards David ___ 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
Re: dead easy deployment / Camping on the fly
+9 this :) -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. david costa gurugeek...@gmail.com skrev: Hello all, I am opening a separate topic just to brainstorm the idea of a free, simple camping deployment/hosting option. Now this is not about re-inventing the wheel as heroku already supports camping apps too. So this would be the ground idea: a) This would be entirely free - no paid plans to upgrade etc.; b) Eventually users should be able to deploy a camping application by launching something like camping-fly myapp in the command line and it would simply work (through a git push or similar) and make it available live in a custom domain like camping.sh or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am c) Database fanciness should also be available or at least sqlite/mysql Suggestion and ideas on how to achieve this are welcome (or professionals with the expertise willing to do a simple project based on this ) servers I can make available for this: Debian 6 Intel Core i7 3930K (6 x 3,20 GHz) RAM 64 GB 3000 GB HD + 256 MB SSD drive (very useful for databases, much faster) OR (don't laugh) Mac mini 2.0GHz quad-core Intel Core i7 8GB memory 2X256GB Solid State Drive of course we would need to limit this to screened applicants to avoid any spammers/troublemakers Best Regards David Dcouvre tous les secrets de la Magie. Clique Ici! http://click.lavabit.com/hmfehg75rumtxy6e9birp9px66eqeqn1cjxgcxtdp648siroyzcb/ ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
Here is my progress on the server :)
Spent several hours to try to work on a nginx + passenger setup on the
cloud even using some pre-made ami with no success. It was also fairly slow
vs. a real server (even on an XLarge instance).
So I went back to one spare brand new mac mini server quadcore i7 and I did
install passenger on apache 2 without any major problem. All is fine and
camping runs well pretty much on the fly by simply uploading your camping
file in the relevant directory (which is pretty much what I wanted to
achieve!)
the sample fine (very rough I know) runs fine on the preview at
http://bash.is/ :)
Some small things you might have some ideas for:
-On Passenger apparently camping runs without issues as config.ru (camping
code on the config.ru file directly)
see
http://www.modrails.com/documentation/Users%20guide%20Apache.html#_camping
I did try to use the camping book instructions (dreamhost) but for a reason
or another it doesn't work. This is not a main issue thou as, if we allow
to test 1 file apps automagically it can be renamed to config.ru as
passenger wants but I am sure there is another way to do it perhaps;
- I am getting the nasty internal error if I call a page like
http://bash.is/lsdlksd but I do get a nice camping error for something like
http://bash.is/blahh.html I am sure I can fix this small cosmetic thing
easily thou need to dig a bit more on apache config
TODO from my side:
- If this testing would not include mysql or a db beside sqlite or flat
would be probably easier as I won't need to make a script to set a db user
etc.
- A simple ruby or shell script to test quick upload and deployment of
camping apps (this should required the creation of a new user + allow the
user to connect and upload the files I guess). An alternative would be to
have no new user created but, via a unique key, allow the user to see his
app/change it etc. in his/her app sub-domain (myappl.domain.something)
- Testing, Testing, Testing :)
It looks exciting and I am sure it can come up as a pretty good solution.
Webdav shouldn't be difficult at all and perhaps is the best way to do it
so it would be way less geeky than heroku and well on one or more mac
minis is fairly hedgy !
Cheers
David
On Sat, Mar 31, 2012 at 6:30 AM, david costa gurugeek...@gmail.com wrote:
Hello Jenna,
we could use host.camping.io or anything.camping.io for the frontend but
if the server has to allow users to create myfancyapp.camping.io it would
be complicated as I would need to run the camping.io DNS on the hosting
server to create the sub domains on the fly. I started working on it more
details on a separate email.
I love your idea about the key-value database how can we implement this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com wrote:
Those both sound like brilliant servers! I'm not laughing at all. If my
mac mini is good enough for sky rim, it's good enough for web hosting for
sure!
Can we just use camping.io?
I think starting simple is a good idea. Databases are pretty cool among
web developers for various reasons, but I think are totally unnecessary for
most smaller experimental applications. For a beginner, I'm inclined to
have key-value databases. A really simple key-value database would work
like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up the
kevin to a series of about four directories and then a file, and
conveniently fff in base36 is 19995, which is a very nice maximum number
of things you'd ever want to put in a single directory if using something
like EXT4 or HFS+. Of course, if using a B-Tree filesystem like reiser,
btrfs, zfs there is no such limitation so you can skip the scanning joining
thing and just open database/#{key.hash} and put a value in that.
Pretty cool, no? It's really easy to turn something like that in to what
seems from the outside to be a persistent hash.
I was working on another thing called ForeverHash, which was the same
sort of idea, but used flat files. If people are interested I'd be curious
enough to revive that project with more of a CouchDB inspired design.
I like all these filesystem based solutions (sqlite, crazy hash in
folders, flat file key-value db's) because they can be backed up and
restored via webdav or sftp or whatever, and you don't need to do any weird
stuff of configuring which ports and usernames and passwords in your
database abstraction. I prefer the idea of having a little key-value
filesystem db written in clear straight forward ruby code, because it means
kids learning can see how it works and hack at it - as nice as sqlite is,
it is in no way transparent. You at least have to learn SQL if you want to
play with it's innards, and possibly C.
On
