A bit late in the day, but (quick and probably uninformed thought,
given the volume of messages I just skimmed) might rvm help manage
Ruby installs/updates/gems safely? - DaveE
Hello again ! :)
well in theory we can chrot jail users but the best way is to
install the gems that people need perhaps the most used ones. It
will then work system wide !
The big question is who will be your typical user. If is someone you
trust then you can give them even limited ssh + sftp :)
Back to my ignorance: how do you folks run camping in a server ? do
you use fcgi ? At work we used to run a fairly big production
environment made of rails running with lighthtp and fcgi. If we
were to run this as a dead simple fcgi setup did anyone set this up?
I have tried all the instructions github on how to set this up with
dispatcher.fcgi but failed miserably.
I would can get the server installed + fcgi but how to run camping
apps from there is a bit of a mystery.
I am slightly frustrated because of passenger not making a simple
create page/test page http://camping.sh/ working. I know is not the
app as it works at http://camping.sh:3301/
Unicorn: I think you would be back to have nginx as a reverse proxy
for that which can present some problems for example, default port
is 3301 for camping. So you would need a script to check which port
is free and run then camping --port so seems a bit complicated.
Thanks
David
On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson
<icepa...@lavabit.com> wrote:
Okay then. But then we'd make sure that the applications don't have
privilege to install gems then.
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min
fåordighet.
Jenna Fox <a...@creativepony.com> skrev:
@Isak Anything run with the `backticks operator` runs with the same
privileges as the process which launched them, if using system level
sandboxing, or if using some crazy sandbox built in to ruby (which
probably wouldn't be very good, but maybe good enough) it'd probably
just disable backticks feature.
On 01/04/2012, at 9:31 PM, Isak Andersson wrote:
Well. Isn't it kind of possible to just hack the gem installation
in using the ruby quotes that execute code on the system. I can't
type them on the phone but I think you know what I mean. Kind of a
security issue isn't it?
Anyways. Perhaps we could offer some Gems to pick from that we
think are quality! (rack_csrf, scrypt).
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min
fåordighet.
Jenna Fox <a...@creativepony.com> skrev:
I don't think we need to go as far as automatically installing gems
- securing ruby is a pretty big challenge, but securing gcc? no way.
—
Jenna
On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote:
Remember that we should pretty much make a Gemfile mandatory if
the user makes use of gems other than Camping. For example,
rack_csrf. And we should make sure that dependencies get
installed. :)
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min
fåordighet.
Jenna Fox <a...@creativepony.com> skrev:
Hm. I know the main guy responsible for App Engine, and, well, I
certainly wouldn't build a platform atop it - even aside from the
huge glaring issue that to have an app which can store data
persistently, you need to use google's proprietary database
software.
Heroku doesn't screen against abuse at all. Heroku is not a
'shared hosting' provider. Their systems use the very finest
jailing techniques to lock the ruby process in to it's own little
world. It has no writable filesystem and it can only read what it
absolutely needs to be able to read to function. All data storage
happens over the network on separated database servers. The only
type of abuse they need to be weary of is people using their
servers to do illegal things - bullying, sharing illegal content,
that sort of thing. They deal with that the same way any provider
does - wait till someone makes a complaint. Matz, inventor of
ruby, works for heroku making exactly this sort of stuff work
extremely well.
Still, it's not as friendly as it could be, and I personally
think the trade offs on heroku are not very good for beginners
(you have to use a complex database system, and cannot use the
filesystem to store anything but static assets).
Good work getting this server up David! I'm pretty excited. It
sounds like you're having some pretty annoying deployment issues.
As it's being quite a hassle, perhaps we should be thinking more
deeply about creating our own special server for this task -
something like the modified unicorn I mentioned earlier somewhere.
—
Jenna
On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
Wonder if Google might help getting camping to run on app engine?
On 1 April 2012 10:03, david costa <gurugeek...@gmail.com> wrote:
Ah I forgot
you can compare camping running on thin here
http://run.camping.io:3301/
vs passenger at http://run.camping.io
apparently db has some problems with fusion passenger (see http://run.camping.io
create HTML page and test HTML page. The same code on thin
works just fine... umhh oh no don't feel like more debugging ):
On Sun, Apr 1, 2012 at 9:51 AM, david costa <gurugeek...@gmail.com
> wrote:
Okay :D after many many hours of testing I am settled for
nginx and passenger.
live at http://run.camping.io/
I did try every apache combination (with passenger, with cgi,
etc. etc.) as is simply not really working fine.
I tried some other obscure web servers too but apparently this
seems to work fine for now :) other servers would run the app
as CGI or FastCGI. I am not worried about speed just ease of
deployment and nginx with passenger seems to do the job for
now. The alternative is nginx as reverse proxy but as Jenna
rightly pointed out it would spawn a lot of thin instances
that might or might not be used.
I did throw the sponge at Webdav on apache. It doesn't work as
expected and not with all clients. It seems more suitable to
store quick files than something else.
Can try tomorrow with nginx but perhaps it would be nicer to
have a quick camping hack to upload a file etc. but you can't
just automate it entirely else you can have people running
malicious code automatically...
I can do the shell scripts to create virtual users for nginx
and dns. Another option is to give a normal hosting for
camping users. It wouldn't be an issue to have 100-200 trusted
users to have access to this e.g. we can build a camping
fronted for users to apply with a selection e.g. their github
account, why they want the deployment hosting etc. and then
once approved we would give them a normal account that would
allow them to upload files on SFTP and may be even shell
(which BTW is something you don't have on heroku and other
services. Of course this could be protected for security or
given only to active people.
How does heroku screens against abuses?
Anyway if some of you would like to be alpha users in this
system let me know, I will be glad to set you up as soon as I
am done testing subdomains etc. ;)
And of course if you have a better idea for a setup let me know.
Regards
David
On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox <a...@creativepony.com>
wrote:
WebDav for nginx: http://wiki.nginx.org/HttpDavModule
Or you could implement webdav as an application nginx proxies
to, just as it proxies to ruby instances.
—
Jenna
On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <icepa...@lavabit.com
> wrote:
Actually setting up a reverse proxy gives better
performance for the end user As you can have some sort of
buffer between them. The Unicorn server takes care of
whatever nginx asks for, and while it waits it can server
whatever unicorn outputs. It doesn't have to wait for what
it outputs itself to get done because you have a queue. Or
something like that.
Mh I am not really sure it would be a better performance as
it would be anyway more than one process. I think that
phusion passenger is pretty much the most robust solution
for this.
Some people actually out Apache to do PHP stuff while nginx
acts as a reverse proxy and actually shows things to the
user in the same way you'd do with Unicorn/Thin
Well this would be even more load as two web servers will
run at the same time. Apache + Phusion passenger already
lets you run .php or anything you want.
But this is not the issue really. I think this is all fine
in term of mono user. Question: if you have 100 users how do
you configure it ?
How can you add webdav support on the top of the Nginx +
unicorn setup ?
But perhaps That's too much for a server ment to serve
other peoples applications! Then you have to scale down the
resources used.
I am open to anything but if I can't do something I might
ask for some brave volunteers to set it up as I really never
tried anything else beside for local/quick test deployment.
_______________________________________________
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
