Re: updates regarding hosting/easy deployment
Hi David just a quick reply, because I've been off the Camping case for various reasons (work, health), but still following... this is great news! An 'alternative to Heroku' is pretty ambitious, but since many (most?) people don't need anything like the full array of Heroku features (or news updates!) it's a viable 'lite' alternative. Yes, I'd be interested in testing. Dave Hello Everyone, sorry for the longish silence but as you know sometimes it can be busy at work! I just wanted to let you know about a complete update on the free hosting system I did prepare from camping. The github idea was not that bad but it didn't work in many cases (too many!) and did not give enough control to the users. So I am testing a completely rebuild system with these currently working features: - SFTP access to users: no more github madeness and total control over your files. It is as drop and run as it can get; - MySQL available to all users - it is popular so regardless of other cutting edge possibilities I think it is an important add-on - Fairly secure environment: users can't read other users files (which seems like a no brainer but it is not possible to do or at least not easily with nginx so we are using apache with a worker that runs everything as the owner of the file) - Ruby and PHP side by side? yes! see http://testme.2.ai camping app http://testme.2.ai/i.php This is a quick test regarding permissions e.g. this user cannot open via PHP or Ruby another user file http://testme.2.ai/testperms.php It also works with other rack frameworks like Sinatra http://dotgeek.2.ai So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) What do you think ? Would you be interested in testing the system ? Do you think it could be interesting to users as an alternative to heroku etc ?I will soon move the domain 1.ai to the new system so that you can test. Initially I plan to add a key of some sort to make it by invitation only or sort of for the alpha stage. Thanks in advance for your feedback! 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: updates regarding hosting/easy deployment
Hi Isak, sure - if there is anything I need to install I will be happy to do so. :) On Sun, Aug 12, 2012 at 5:18 PM, Isak Andersson icepa...@lavabit.comwrote: ** Very exciting :) And nice! Would also be sweet if you added early support for what Magnus has been working on when that's ready to ship! On Sun, 12 Aug 2012 17:09:17 +0200, gurugeek gurugeek...@gmail.com wrote: Hello Everyone, sorry for the longish silence but as you know sometimes it can be busy at work! I just wanted to let you know about a complete update on the free hosting system I did prepare from camping. The github idea was not that bad but it didn't work in many cases (too many!) and did not give enough control to the users. So I am testing a completely rebuild system with these currently working features: - SFTP access to users: no more github madeness and total control over your files. It is as drop and run as it can get; - MySQL available to all users - it is popular so regardless of other cutting edge possibilities I think it is an important add-on - Fairly secure environment: users can't read other users files (which seems like a no brainer but it is not possible to do or at least not easily with nginx so we are using apache with a worker that runs everything as the owner of the file) - Ruby and PHP side by side? yes! see http://testme.2.ai camping app http://testme.2.ai/i.php This is a quick test regarding permissions e.g. this user cannot open via PHP or Ruby another user file http://testme.2.ai/testperms.php It also works with other rack frameworks like Sinatra http://dotgeek.2.ai So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) What do you think ? Would you be interested in testing the system ? Do you think it could be interesting to users as an alternative to heroku etc ?I will soon move the domain 1.ai to the new system so that you can test. Initially I plan to add a key of some sort to make it by invitation only or sort of for the alpha stage. Thanks in advance for your feedback! David Free Scan Can Radically Speed Up Your PC. Make It Run Like New http://click.lavabit.com/f1igcwdkj34nx4hjiyz9bbgzdt3rtdms1mm3skx6yc9zexte9fay/ -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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
updates regarding hosting/easy deployment
Hello Everyone, sorry for the longish silence but as you know sometimes it can be busy at work! I just wanted to let you know about a complete update on the free hosting system I did prepare from camping. The github idea was not that bad but it didn't work in many cases (too many!) and did not give enough control to the users. So I am testing a completely rebuild system with these currently working features: - SFTP access to users: no more github madeness and total control over your files. It is as drop and run as it can get; - MySQL available to all users - it is popular so regardless of other cutting edge possibilities I think it is an important add-on - Fairly secure environment: users can't read other users files (which seems like a no brainer but it is not possible to do or at least not easily with nginx so we are using apache with a worker that runs everything as the owner of the file) - Ruby and PHP side by side? yes! see http://testme.2.ai camping app http://testme.2.ai/i.php This is a quick test regarding permissions e.g. this user cannot open via PHP or Ruby another user file http://testme.2.ai/testperms.php It also works with other rack frameworks like Sinatra http://dotgeek.2.ai So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) What do you think ? Would you be interested in testing the system ? Do you think it could be interesting to users as an alternative to heroku etc ?I will soon move the domain 1.ai to the new system so that you can test. Initially I plan to add a key of some sort to make it by invitation only or sort of for the alpha stage. Thanks in advance for your feedback! David ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: updates regarding hosting/easy deployment
Very exciting :) And nice!Would also be sweet if you added early support for what Magnus has been working on when that's ready to ship!On Sun, 12 Aug 2012 17:09:17 +0200, gurugeek gurugeek...@gmail.com wrote:Hello Everyone,sorry for the longish silence but as you know sometimes it can be busy at work! I just wanted to let you know about a complete update on the free hosting system I did prepare from camping. The github idea was not that bad but it didn't work in many cases (too many!) and did not give enough control to the users. So I am testing a completely rebuild system with these currently working features: - SFTP access to users: no more github madeness and total control over your files. It is as drop and run as it can get; - MySQL available to all users - it is popular so regardless of other cutting edge possibilities I think it is an important add-on - Fairly secure environment: users can't read other users files (which seems like a no brainer but it is not possible to do or at least not easily with nginx so we are using apache with a worker that runs everything as the owner of the file) - Ruby and PHP side by side? yes! seehttp://testme.2.aicamping app http://testme.2.ai/i.php This is a quick test regarding permissions e.g. this user cannot open via PHP or Ruby another user file http://testme.2.ai/testperms.php It also works with other rack frameworks like Sinatrahttp://dotgeek.2.ai So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) What do you think ? Would you be interested in testing the system ? Do you think it could be interesting to users as an alternative to heroku etc ?I will soon move the domain 1.ai to the new system so that you can test. Initially I plan to add a key of some sort to make it by invitation only or sort of for the alpha stage. Thanks in advance for your feedback! David Free Scan Can Radically Speed Up Your PC. Make It Run Like New http://click.lavabit.com/f1igcwdkj34nx4hjiyz9bbgzdt3rtdms1mm3skx6yc9zexte9fay/ -- Using Opera's revolutionary email client: http://www.opera.com/mail/___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
updates regarding hosting/easy deployment
Hello Everyone, sorry for the longish silence but as you know sometimes it can be busy at work! I just wanted to let you know about a complete update on the free hosting system I did prepare from camping. The github idea was not that bad but it didn't work in many cases (too many!) and did not give enough control to the users. So I am testing a completely rebuild system with these currently working features: - SFTP access to users: no more github madeness and total control over your files. It is as drop and run as it can get; - MySQL available to all users - it is popular so regardless of other cutting edge possibilities I think it is an important add-on - Fairly secure environment: users can't read other users files (which seems like a no brainer but it is not possible to do or at least not easily with nginx so we are using apache with a worker that runs everything as the owner of the file) - Ruby and PHP side by side? yes! see http://testme.2.ai camping app http://testme.2.ai/i.php This is a quick test regarding permissions e.g. this user cannot open via PHP or Ruby another user file http://testme.2.ai/testperms.php It also works with other rack frameworks like Sinatra http://dotgeek.2.ai So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) What do you think ? Would you be interested in testing the system ? Do you think it could be interesting to users as an alternative to heroku etc ?I will soon move the domain 1.ai to the new system so that you can test. Initially I plan to add a key of some sort to make it by invitation only or sort of for the alpha stage. Thanks in advance for your feedback! David ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !
View Source link for open web apps and demos. I just added a link to the github repo on my links app, but if you have a snippet to display an app's code in formatted and syntax- coloured style... The idea is to get people to learn and use camping and deploy it / see their app live immediately. It should be a good learning tool... and you've done that job rather well :-) DaveE ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !
So if my SQLite db file is also in my repo and the path to it is in my app, sounds like the whole lot will transfer fine - DaveE It should :) If you want to test it I will be grateful. marking web design classes this week(!), so when I take a break I'll try it out with the blog app after using it locally then transferring to the server with the db file, and let you know... Fixing ATM some issues with installing extra gems so trying to find a clever solution to make most app run without intervention. be good to have a list of available gems (unless you already did that!) Dave ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !
Is this like Heroku or something? What are the use cases for this? It's an app server? What are the limitations? How much does it cost? If it is free, why is it free? On Sun, May 6, 2012 at 1:57 AM, gurugeek 1...@1.ai wrote: Hello Campers! I am happy to announce that the camping 1 click deployment is now available at http://1.ai The platform has been coded with camping (with some help from bash for the backend scripts) and it seems to work very well. We have spent some time to get sure that it would be secure and easy to use. After working on an easy and secure way to upload/manage files online etc. we have found an easier solution: fetch a github repository with a camping application and - with one click -deploy it online at yourname.1.ai So how does this works ? 1 - you signup 2 - after logging in you simply fetch your camping application from a github repository there is a sample hello world available at https://github.com/gurugeek/0ai and this is also explained in the app admin page 3 - after fetching (provided that this is a valid camping app and has a valid config.ru file) your application will be live. The admin panel has all these instructions and if you try to fetch a non-camping application from a github repository it will return the relevant error. The system supports private repositories too (this said I wouldn't run something very secret and private on it!) but you would need to authorise the github user 1ai to access your private repository. Github has a lot of wonderful features so I feel that this was the best solution without re-inventing the wheel. It is probably the fastest and easiest way to get your camping application up and running. Each application is securely isolated but all this is running in a traditional dedicated server (no virtual/cloud/droids) are employed. This should enhance the application performance. The server is also using only SSD (solid state drivers) that are not yet available in most of cloud providers (EC2, Rackspace cloud). I really appreciate your testing and comments so please go on and launch your shiny Camping app at http://1.ai ! A small caveat: The aim of this service is (hopefully) to promote camping (perhaps next with a programming contest with some cool prizes) but it is obviously not meant to replace a traditional hosting in the sense that there will be no tech support offered and the service is provided without any warranty. This doesn't mean that is not good enough to run any of your fancy Camping apps - just that you should not expect this to replace any professional hosting. Note on Databases: -If you have an sqlite database in your github repository it should work just fine. If it works for you locally it should work fine on http://1.ai after the github fetch -If you want to use CouchDB you can do it with the wonderful Chill ( https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is free for small apps/usage). Once you have your CouchDB on iriscouch you simply connect to it from your camping app, fetch the data etc. I do look forward to your comments and welcome any question you might have! 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: Camping 1 click deployment is live! 1.ai - alpha users welcome !
So if my SQLite db file is also in my repo and the path to it is in my app, sounds like the whole lot will transfer fine - DaveE -If you have an sqlite database in your github repository it should work just fine. If it works for you locally it should work fine on http://1.ai after the github fetch ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !
Heroku are the big tires, camping is the little wheels. They aren't a great fit. Heroku for example has a read-only file system and I believe no database in the free tier. This is a great little service we can build interesting things on. How about a remote server reloader? Streaming logs? Push notification stream server? View Source link for open web apps and demos. — Jenna Fox On Wednesday, 9 May 2012 at 1:30 PM, gurugeek wrote: On May 8, 2012, at 4:04 PM, Anthony Durity wrote: What are the limitations? I forgot to add these important limitations: - Presently No DB Support beside sqlite and couchdb if you use it via iriscouch or a similar service; - No professional support - so it is free but beside some help that I am willing to give to make sure that the service runs properly it cannot be compared with a professional service where you pay hence you can expect support In terms of benefits thou the app should run considerably faster than on the free tier of heroku because of the non-virtualization and the SSD hard drives - in my tests sqlite and all in general ix x 5 times than in a traditional HD or on EC2. The idea is to get people to learn and use camping and deploy it /see their app live immediately. It should be a good learning tool but not to run a professional application with clients etc. or where you expect a lot of support. ___ 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: Camping 1 click deployment is live! 1.ai - alpha users welcome !
On May 7, 2012, at 2:23 AM, Jenna Fox wrote: Things: 1) It'd be super cool if the user types in their email address as the username if it still works Yes this should be easy to do - could put both I think email or username 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com in the github repo name and it says my url contains invalid characters? I think the check in the script doesn't allow a repository to have a points inside it ..is it very common ? Can fix this but if you want to try in the interim just use any repo without a . on it :) Thanks again for testing this out David — Jenna On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote: Hello Campers! I am happy to announce that the camping 1 click deployment is now available at http://1.ai The platform has been coded with camping (with some help from bash for the backend scripts) and it seems to work very well. We have spent some time to get sure that it would be secure and easy to use. After working on an easy and secure way to upload/manage files online etc. we have found an easier solution: fetch a github repository with a camping application and - with one click -deploy it online at yourname.1.ai So how does this works ? 1 - you signup 2 - after logging in you simply fetch your camping application from a github repository there is a sample hello world available at https://github.com/gurugeek/0ai and this is also explained in the app admin page 3 - after fetching (provided that this is a valid camping app and has a valid config.ru file) your application will be live. The admin panel has all these instructions and if you try to fetch a non-camping application from a github repository it will return the relevant error. The system supports private repositories too (this said I wouldn't run something very secret and private on it!) but you would need to authorise the github user 1ai to access your private repository. Github has a lot of wonderful features so I feel that this was the best solution without re-inventing the wheel. It is probably the fastest and easiest way to get your camping application up and running. Each application is securely isolated but all this is running in a traditional dedicated server (no virtual/cloud/droids) are employed. This should enhance the application performance. The server is also using only SSD (solid state drivers) that are not yet available in most of cloud providers (EC2, Rackspace cloud). I really appreciate your testing and comments so please go on and launch your shiny Camping app at http://1.ai ! A small caveat: The aim of this service is (hopefully) to promote camping (perhaps next with a programming contest with some cool prizes) but it is obviously not meant to replace a traditional hosting in the sense that there will be no tech support offered and the service is provided without any warranty. This doesn't mean that is not good enough to run any of your fancy Camping apps - just that you should not expect this to replace any professional hosting. Note on Databases: -If you have an sqlite database in your github repository it should work just fine. If it works for you locally it should work fine on http://1.ai after the github fetch -If you want to use CouchDB you can do it with the wonderful Chill (https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is free for small apps/usage). Once you have your CouchDB on iriscouch you simply connect to it from your camping app, fetch the data etc. I do look forward to your comments and welcome any question you might have! 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !
A lot of repos for websites have dots in them, should fix it to support anything github can support. — Jenna On Monday, 7 May 2012 at 10:30 AM, gurugeek wrote: On May 7, 2012, at 2:23 AM, Jenna Fox wrote: Things: 1) It'd be super cool if the user types in their email address as the username if it still works Yes this should be easy to do - could put both I think email or username 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com (http://whywentcamping.com) in the github repo name and it says my url contains invalid characters? I think the check in the script doesn't allow a repository to have a points inside it ..is it very common ? Can fix this but if you want to try in the interim just use any repo without a . on it :) Thanks again for testing this out David — Jenna On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote: Hello Campers! I am happy to announce that the camping 1 click deployment is now available at http://1.ai (http://1.ai/) The platform has been coded with camping (with some help from bash for the backend scripts) and it seems to work very well. We have spent some time to get sure that it would be secure and easy to use. After working on an easy and secure way to upload/manage files online etc. we have found an easier solution: fetch a github repository with a camping application and - with one click -deploy it online at yourname.1.ai So how does this works ? 1 - you signup 2 - after logging in you simply fetch your camping application from a github repository there is a sample hello world available at https://github.com/gurugeek/0ai and this is also explained in the app admin page 3 - after fetching (provided that this is a valid camping app and has a valid config.ru (http://config.ru/) file) your application will be live. The admin panel has all these instructions and if you try to fetch a non-camping application from a github repository it will return the relevant error. The system supports private repositories too (this said I wouldn't run something very secret and private on it!) but you would need to authorise the github user 1ai to access your private repository. Github has a lot of wonderful features so I feel that this was the best solution without re-inventing the wheel. It is probably the fastest and easiest way to get your camping application up and running. Each application is securely isolated but all this is running in a traditional dedicated server (no virtual/cloud/droids) are employed. This should enhance the application performance. The server is also using only SSD (solid state drivers) that are not yet available in most of cloud providers (EC2, Rackspace cloud). I really appreciate your testing and comments so please go on and launch your shiny Camping app at http://1.ai (http://1.ai/) ! A small caveat: The aim of this service is (hopefully) to promote camping (perhaps next with a programming contest with some cool prizes) but it is obviously not meant to replace a traditional hosting in the sense that there will be no tech support offered and the service is provided without any warranty. This doesn't mean that is not good enough to run any of your fancy Camping apps - just that you should not expect this to replace any professional hosting. Note on Databases: -If you have an sqlite database in your github repository it should work just fine. If it works for you locally it should work fine on http://1.ai (http://1.ai/) after the github fetch -If you want to use CouchDB you can do it with the wonderful Chill (https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is free for small apps/usage). Once you have your CouchDB on iriscouch you simply connect to it from your camping app, fetch the data etc. I do look forward to your comments and welcome any question you might have! Best Regards David ___ 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 (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ 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
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 http
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
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 http://rubyforge.org/mailman/listinfo/camping
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 them
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
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
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
Re: dead easy deployment / Camping on the fly
. 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 (http://run.camping.io/) apparently db has some problems with fusion passenger (see http://run.camping.io (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
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
, 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 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 (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ 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 (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ 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 (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ 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 (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
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
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 = key.hash.to_s(36).scan
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
dead easy deployment / Camping on the fly
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
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
Re: Easy deployment on DreamHost with Phusion Passenger
Please add it to the Camping on Shared Hosting wiki page - on both the Camping Github wiki, and the Dreamhost wiki. I wrote the Dreamhost section of the former, and the entirety of the latter, after much agony making FastCGI work, and I'd love to see a simpler way documented. -- Eric On Mon, Jul 20, 2009 at 2:21 PM, Roland Crosbyrol...@rolandcrosby.com wrote: I don't know if this has been documented anywhere, but last night I had a surprisingly easy time deploying a Camping 2.0 app to my basic DreamHost shared hosting account. After fighting with FastCGI for a while, I noticed that there's an option to point the root of a domain or subdomain at a Rails app's public/ directory and use Phusion Passenger. Once I made such a directory, and a basic config.ru file to set the gem paths correctly and run the app, it seemed to work just fine. Granted, the app is dead simple (one file, no database), so I don't know if this configuration would break if I changed anything, but I thought it was worth mentioning. I can add this to the Camping on Shared Hosting wiki page, if nobody knows of any huge caveats to deploying this way. Roland ___ 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: deployment
Hi David, On Wed, Jun 03, 2009 at 10:24:01AM -0400, David Susco wrote: I have a few camping apps I'd like to start automatically if my server ever restarts. There's an init.d file that comes with mongrel_cluster that you can use for rails apps, is there anything out there for camping apps though? With the postamble containing all the configuration for the app, it seems that all the init.d file would have to do is execute the camping file. Has anyone done this/have any pointers? I know this is not exactly what you're asking since your question was mongrel based, but if you were to look at running camping 2.0 with passenger/rack you would get automatic restarts as well as working redirects. Plus you'd be able to also easily deploy rails apps (and even some python apps) with the same setup. Cheers, Jonathan ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: deployment
Maybe have a look at http://code.google.com/p/camping-picnic/ http://code.google.com/p/camping-picnic/Among other functionality, Picnic gives you a myapp-ctl wrapper script around your camping app that takes care of starting and stopping mongrel. Writing an init.d script around the myapp-ctl script is pretty trivial. Otherwise using mongrel_cluster to start up your app is probably your best choice. That's what we did before we switched to passenger. On Wed, Jun 3, 2009 at 10:24 AM, David Susco dsu...@gmail.com wrote: I have a few camping apps I'd like to start automatically if my server ever restarts. There's an init.d file that comes with mongrel_cluster that you can use for rails apps, is there anything out there for camping apps though? With the postamble containing all the configuration for the app, it seems that all the init.d file would have to do is execute the camping file. Has anyone done this/have any pointers? -- Dave ___ 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: no camping required deployment?
You can just include the camping library alongside the app. Put camping.rb (and maybe the folder 'camping' that has some helper scripts for sessions, webrick, etc.) in the same directory as your main .rb file. In your script, when you say require 'camping' it will load Camping from there, instead of looking for the gem. If you remove require 'rubygems' from your script, you can test it on your machine to make sure it's working, without uninstalling the gem. -- Eric On 2/11/07, Bil Kleb [EMAIL PROTECTED] wrote: Hi, So Lennon got me going with my database-less Camping app, but I've just realized that, I have no deployment strategy. This app is to provide a GUI front end to our FUN3D fluid flow simulation monster, which is used by ourselves, companies, universities, hobbyists, and the military. The end result of which, is a file of (key, value) pairs read by FUN3D. Requiring our users to have Camping installed is too much to ask. While we could host the Camping app, the hassle of getting it approved by our IT folks is daunting, and requiring an Internet connection is troublesome for our black-world users. So, I'm thinking either a stand-alone executable (via RubyScript2Exe?) or a set of static HTML pages they could load locally? Any other suggestions? Thanks, -- Bil Kleb http://fun3d.larc.nasa.gov ___ 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
