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 users being then able to run anything on their space by uploading on sftp. It could be even used to store unwanted files etc. This option could be also used in conjunction with option a) but only after a user has proven that is not ill intended. Another important point on dotgeek was the "php marathon" because that was one of the rules that the participating app should run on PHP 5 and back in the days there was no hosting providing that. So perhaps, once we get this running, we can do a small contest with prizes and see if people are interested in showing off their ideas with camping. I am saying this just to go to the next stage (after screencasts and on the fly app working) to then launch it and drive some more visitors. Else it would be pointless as with heroku and so many good services this might sound a bit bare bones to some ! David > >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
