Camping list - Mar 2012 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120330/32bd29a2/attachment.html>

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120330/e6fdd0cd/attachment.html>

+999999999 this :)
-- 
Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet.

david costa <gurugeekphp at 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/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120330/dd73ea08/attachment.html>

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/859aee78/attachment.html>

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 at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/4bb362c1/attachment.html>

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 at 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
> 
> 
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
> 
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/f12fa922/attachment-0001.html>

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 <gurugeekphp at 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 at 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/483a6738/attachment.html>

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 at 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 at 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/9678aa6d/attachment-0001.html>

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 <gurugeekphp at 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 at 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 at
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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/d42dc9eb/attachment.html>

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



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


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



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



	Get the best selection of web sites here. Click Here to check them out!
	http://click.lavabit.com/qszoentdu6cfiot97ef4mghqkwt1fg67m1hts7zqac5c8hghizob/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/af132d0a/attachment-0001.html>

@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 <gurugeekphp at gmail.com
(mailto:gurugeekphp at 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 at creativepony.com
(mailto:a at 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 at
creativepony.com (mailto:a at 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 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 at rubyforge.org (mailto:Camping-list
at rubyforge.org)
> > > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > > >  
> > > > > _______________________________________________
> > > > > Camping-list mailing list
> > > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > >  
> > > > _______________________________________________
> > > > Camping-list mailing list
> > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> > > _______________________________________________
> > > Camping-list mailing list
> > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> >  
>  
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/61ed966c/attachment.html>

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 at 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 <gurugeekphp at
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 at 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 at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/1ddd5ddd/attachment-0001.html>

Apache? What are your thoughts on that choice I am curious? :)  

?
Jenna


On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:
> Thank you :D as soon as the DNS will propagate it should be live.
> Some updates: now added the design from camping.io (http://camping.io)
(working on the fonts) and I have narrowed down the probably easiest/best way to
do it:
> using Webdav module on apache. So there will be no issue with creating real
server users and it should really be easily accessible  by anyone, anywhere.
Working on some securities configurations to be sure that it works fine!
>  
>  
> On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox <a at creativepony.com
(mailto:a at creativepony.com)> wrote:
> > @David - sorted, both those subdomains now point to your machine. :)
> >  
> > ?
> > Jenna
> >  
> >  
> > On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
> >  
> > > BTW if you want to point a  run.camping.io
(http://run.camping.io) or host.camping.io (http://host.camping.io) or anything
you like to  66.116.108.12 will then be able to show an (hopefully) working demo
using the official domain ;)
> > >  
> > > On Sat, Mar 31, 2012 at 7:08 AM, david costa <gurugeekphp at
gmail.com (mailto:gurugeekphp at 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 at
creativepony.com (mailto:a at 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
at creativepony.com (mailto:a at 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 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 at rubyforge.org
(mailto:Camping-list at rubyforge.org)
> > > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > > >  
> > > > > > >
_______________________________________________
> > > > > > > Camping-list mailing list
> > > > > > > Camping-list at rubyforge.org
(mailto:Camping-list at rubyforge.org)
> > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > >  
> > > > > > _______________________________________________
> > > > > > Camping-list mailing list
> > > > > > Camping-list at rubyforge.org (mailto:Camping-list
at rubyforge.org)
> > > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > > >  
> > > > > _______________________________________________
> > > > > Camping-list mailing list
> > > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > >  
> > >  
> > > _______________________________________________
> > > Camping-list mailing list
> > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> > >  
> > >  
> >  
> >  
> >  
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
>  
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/ac32caa3/attachment.html>

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 at 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 at 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 <gurugeekphp at
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 at 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 at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/2ccc15b6/attachment-0001.html>

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 <gurugeekphp at 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 at 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 at
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 <gurugeekphp at
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 at
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 at
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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/7a6d8633/attachment.html>

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 <uzleepito at 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 <gurugeekphp at
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 at
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 at
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 <gurugeekphp at
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 at
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 at
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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/21fbbe72/attachment-0001.html>

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 <gurugeekphp at 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 <uzleepito at 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 <gurugeekphp at
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 at
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 at
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 <gurugeekphp at
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 at
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 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 at
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 at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/730a17e4/attachment-0001.html>

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.

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

But perhaps That''s too much for a server ment to serve other peoples
applications! Then you have to scale down the resources used.
-- 
Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet.

david costa <gurugeekphp at gmail.com> skrev:

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#_camping and
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 at 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 at 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 <gurugeekphp at 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 at 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 at 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 at rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



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


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



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



_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list



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


_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list



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


	Get the best selection of employment in atlanta sites here. Click Here to check
	them out!
	http://click.lavabit.com/fgzdikinbozpgnswnc13tpywy481ijz1ugm1mqa7yo617kgub7wb/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/fb497b47/attachment.html>

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
> ** Actually setting up a reverse proxy gives better performance for the
> end user As you can have some sort of buffer between them. The Unicorn
> server takes care of whatever nginx asks for, and while it waits it can
> server whatever unicorn outputs. It doesn''t have to wait for what
it
> outputs itself to get done because you have a queue. Or something like
that.
>
Mh I am not really sure it would be a better performance as it would be
anyway more than one process. I think that phusion passenger is pretty much
the most robust solution for this.
>
> Some people actually out Apache to do PHP stuff while nginx acts as a
> reverse proxy and actually shows things to the user in the same way
you''d
> do with Unicorn/Thin
>
Well this would be even more load as two web servers will run at the same
time. Apache + Phusion passenger already lets you run .php or anything you
want.

But this is not the issue really. I think this is all fine in term of mono
user. Question: if you have 100 users how do you configure it ?
How can you add webdav support on the top of the Nginx + unicorn setup ?


But perhaps That''s too much for a server ment to serve other
peoples
> applications! Then you have to scale down the resources used.
>
>
I am open to anything but if I can''t do something I might ask for some
brave volunteers to set it up as I really never tried anything else beside
for local/quick test deployment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120331/106ad670/attachment-0001.html>

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.

WebDav for nginx: http://wiki.nginx.org/HttpDavModule

Or you could implement webdav as an application nginx proxies to, just as it
proxies to ruby instances.

?
Jenna


On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at lavabit.com
(mailto:IcePapih at lavabit.com)> wrote:
> > Actually setting up a reverse proxy gives better performance for the
end user As you can have some sort of buffer between them. The Unicorn server
takes care of whatever nginx asks for, and while it waits it can server whatever
unicorn outputs. It doesn''t have to wait for what it outputs itself to
get done because you have a queue. Or something like that.
>  
> Mh I am not really sure it would be a better performance as it would be
anyway more than one process. I think that phusion passenger is pretty much the
most robust solution for this.
> >  
> > Some people actually out Apache to do PHP stuff while nginx acts as a
reverse proxy and actually shows things to the user in the same way
you''d do with Unicorn/Thin
>  
> Well this would be even more load as two web servers will run at the same
time. Apache + Phusion passenger already lets you run .php or anything you want.
>  
> But this is not the issue really. I think this is all fine in term of mono
user. Question: if you have 100 users how do you configure it ?
> How can you add webdav support on the top of the Nginx + unicorn setup ?
>  
>  
> > But perhaps That''s too much for a server ment to serve other
peoples applications! Then you have to scale down the resources used.
> >  
>  
> I am open to anything but if I can''t do something I might ask for
some brave volunteers to set it up as I really never tried anything else beside
for local/quick test deployment.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/a8d5e6b0/attachment.html>

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

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

?
Jenna


On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at lavabit.com
(mailto:IcePapih at lavabit.com)> wrote:
> > Actually setting up a reverse proxy gives better performance for the
end user As you can have some sort of buffer between them. The Unicorn server
takes care of whatever nginx asks for, and while it waits it can server whatever
unicorn outputs. It doesn''t have to wait for what it outputs itself to
get done because you have a queue. Or something like that.
>  
> Mh I am not really sure it would be a better performance as it would be
anyway more than one process. I think that phusion passenger is pretty much the
most robust solution for this.
> >  
> > Some people actually out Apache to do PHP stuff while nginx acts as a
reverse proxy and actually shows things to the user in the same way
you''d do with Unicorn/Thin
>  
> Well this would be even more load as two web servers will run at the same
time. Apache + Phusion passenger already lets you run .php or anything you want.
>  
> But this is not the issue really. I think this is all fine in term of mono
user. Question: if you have 100 users how do you configure it ?
> How can you add webdav support on the top of the Nginx + unicorn setup ?
>  
>  
> > But perhaps That''s too much for a server ment to serve other
peoples applications! Then you have to scale down the resources used.
> >  
>  
> I am open to anything but if I can''t do something I might ask for
some brave volunteers to set it up as I really never tried anything else beside
for local/quick test deployment.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/52b14d4c/attachment.html>

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 at creativepony.com> wrote:
> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>
> Or you could implement webdav as an application nginx proxies to, just as
> it proxies to ruby instances.
>
> ?
> Jenna
>
> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>
> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>
> ** Actually setting up a reverse proxy gives better performance for the
> end user As you can have some sort of buffer between them. The Unicorn
> server takes care of whatever nginx asks for, and while it waits it can
> server whatever unicorn outputs. It doesn''t have to wait for what
it
> outputs itself to get done because you have a queue. Or something like
that.
>
>
> Mh I am not really sure it would be a better performance as it would be
> anyway more than one process. I think that phusion passenger is pretty much
> the most robust solution for this.
>
>
> Some people actually out Apache to do PHP stuff while nginx acts as a
> reverse proxy and actually shows things to the user in the same way
you''d
> do with Unicorn/Thin
>
>
> Well this would be even more load as two web servers will run at the same
> time. Apache + Phusion passenger already lets you run .php or anything you
> want.
>
> But this is not the issue really. I think this is all fine in term of mono
> user. Question: if you have 100 users how do you configure it ?
> How can you add webdav support on the top of the Nginx + unicorn setup ?
>
>
> But perhaps That''s too much for a server ment to serve other
peoples
> applications! Then you have to scale down the resources used.
>
>
> I am open to anything but if I can''t do something I might ask for
some
> brave volunteers to set it up as I really never tried anything else beside
> for local/quick test deployment.
>  _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/ee384d04/attachment-0001.html>

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 <gurugeekphp at 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 at creativepony.com>
wrote:
>
>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>
>> Or you could implement webdav as an application nginx proxies to, just
as
>> it proxies to ruby instances.
>>
>> ?
>> Jenna
>>
>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>
>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>>
>> ** Actually setting up a reverse proxy gives better performance for the
>> end user As you can have some sort of buffer between them. The Unicorn
>> server takes care of whatever nginx asks for, and while it waits it can
>> server whatever unicorn outputs. It doesn''t have to wait for
what it
>> outputs itself to get done because you have a queue. Or something like
that.
>>
>>
>> Mh I am not really sure it would be a better performance as it would be
>> anyway more than one process. I think that phusion passenger is pretty
much
>> the most robust solution for this.
>>
>>
>> Some people actually out Apache to do PHP stuff while nginx acts as a
>> reverse proxy and actually shows things to the user in the same way
you''d
>> do with Unicorn/Thin
>>
>>
>> Well this would be even more load as two web servers will run at the
same
>> time. Apache + Phusion passenger already lets you run .php or anything
you
>> want.
>>
>> But this is not the issue really. I think this is all fine in term of
>> mono user. Question: if you have 100 users how do you configure it ?
>> How can you add webdav support on the top of the Nginx + unicorn setup
?
>>
>>
>> But perhaps That''s too much for a server ment to serve other
peoples
>> applications! Then you have to scale down the resources used.
>>
>>
>> I am open to anything but if I can''t do something I might ask
for some
>> brave volunteers to set it up as I really never tried anything else
beside
>> for local/quick test deployment.
>>  _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/8ed12853/attachment.html>

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

On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com> wrote:
> Ah I forgot
> you can compare camping running on thin here
> 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 <gurugeekphp at
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 at creativepony.com>
wrote:
>>
>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>>
>>> Or you could implement webdav as an application nginx proxies to,
just
>>> as it proxies to ruby instances.
>>>
>>> ?
>>> Jenna
>>>
>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>>
>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>>>
>>> ** Actually setting up a reverse proxy gives better performance for
the
>>> end user As you can have some sort of buffer between them. The
Unicorn
>>> server takes care of whatever nginx asks for, and while it waits it
can
>>> server whatever unicorn outputs. It doesn''t have to wait
for what it
>>> outputs itself to get done because you have a queue. Or something
like that.
>>>
>>>
>>> Mh I am not really sure it would be a better performance as it
would be
>>> anyway more than one process. I think that phusion passenger is
pretty much
>>> the most robust solution for this.
>>>
>>>
>>> Some people actually out Apache to do PHP stuff while nginx acts as
a
>>> reverse proxy and actually shows things to the user in the same way
you''d
>>> do with Unicorn/Thin
>>>
>>>
>>> Well this would be even more load as two web servers will run at
the
>>> same time. Apache + Phusion passenger already lets you run .php or
anything
>>> you want.
>>>
>>> But this is not the issue really. I think this is all fine in term
of
>>> mono user. Question: if you have 100 users how do you configure it
?
>>> How can you add webdav support on the top of the Nginx + unicorn
setup ?
>>>
>>>
>>> But perhaps That''s too much for a server ment to serve
other peoples
>>> applications! Then you have to scale down the resources used.
>>>
>>>
>>> I am open to anything but if I can''t do something I might
ask for some
>>> brave volunteers to set it up as I really never tried anything else
beside
>>> for local/quick test deployment.
>>>  _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>
>>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/5ed3dcec/attachment-0001.html>

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 <peterretief at gmail.com>
wrote:
> Wonder if Google might help getting camping to run on app engine?
>
>
> On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com> wrote:
>
>> Ah I forgot
>> you can compare camping running on thin here
>> 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 <gurugeekphp at
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 at
creativepony.com> wrote:
>>>
>>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>>>
>>>> Or you could implement webdav as an application nginx proxies
to, just
>>>> as it proxies to ruby instances.
>>>>
>>>> ?
>>>> Jenna
>>>>
>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>>>
>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>>>>
>>>> ** Actually setting up a reverse proxy gives better performance
for
>>>> the end user As you can have some sort of buffer between them.
The Unicorn
>>>> server takes care of whatever nginx asks for, and while it
waits it can
>>>> server whatever unicorn outputs. It doesn''t have to
wait for what it
>>>> outputs itself to get done because you have a queue. Or
something like that.
>>>>
>>>>
>>>> Mh I am not really sure it would be a better performance as it
would be
>>>> anyway more than one process. I think that phusion passenger is
pretty much
>>>> the most robust solution for this.
>>>>
>>>>
>>>> Some people actually out Apache to do PHP stuff while nginx
acts as a
>>>> reverse proxy and actually shows things to the user in the same
way you''d
>>>> do with Unicorn/Thin
>>>>
>>>>
>>>> Well this would be even more load as two web servers will run
at the
>>>> same time. Apache + Phusion passenger already lets you run .php
or anything
>>>> you want.
>>>>
>>>> But this is not the issue really. I think this is all fine in
term of
>>>> mono user. Question: if you have 100 users how do you configure
it ?
>>>> How can you add webdav support on the top of the Nginx +
unicorn setup ?
>>>>
>>>>
>>>> But perhaps That''s too much for a server ment to serve
other peoples
>>>> applications! Then you have to scale down the resources used.
>>>>
>>>>
>>>> I am open to anything but if I can''t do something I
might ask for some
>>>> brave volunteers to set it up as I really never tried anything
else beside
>>>> for local/quick test deployment.
>>>>  _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/6345561c/attachment.html>

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

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

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

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

?
Jenna


On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
> Wonder if Google might help getting camping to run on app engine?
>  
> On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com
(mailto:gurugeekphp at 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 <gurugeekphp at
gmail.com (mailto:gurugeekphp at 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 at
creativepony.com (mailto:a at creativepony.com)> wrote:
> > > > WebDav for nginx: http://wiki.nginx.org/HttpDavModule
> > > >  
> > > > Or you could implement webdav as an application nginx
proxies to, just as it proxies to ruby instances.
> > > >  
> > > > ?
> > > > Jenna
> > > >  
> > > >  
> > > > On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
> > > >  
> > > >  
> > > > > On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson
<IcePapih at lavabit.com (mailto:IcePapih at lavabit.com)> wrote:
> > > > > > Actually setting up a reverse proxy gives better
performance for the end user As you can have some sort of buffer between them.
The Unicorn server takes care of whatever nginx asks for, and while it waits it
can server whatever unicorn outputs. It doesn''t have to wait for what
it outputs itself to get done because you have a queue. Or something like that.
> > > > >  
> > > > > Mh I am not really sure it would be a better
performance as it would be anyway more than one process. I think that phusion
passenger is pretty much the most robust solution for this.
> > > > > >  
> > > > > > Some people actually out Apache to do PHP stuff
while nginx acts as a reverse proxy and actually shows things to the user in the
same way you''d do with Unicorn/Thin
> > > > >  
> > > > > Well this would be even more load as two web servers
will run at the same time. Apache + Phusion passenger already lets you run .php
or anything you want.
> > > > >  
> > > > > But this is not the issue really. I think this is all
fine in term of mono user. Question: if you have 100 users how do you configure
it ?
> > > > > How can you add webdav support on the top of the Nginx
+ unicorn setup ?
> > > > >  
> > > > >  
> > > > > > But perhaps That''s too much for a server
ment to serve other peoples applications! Then you have to scale down the
resources used.
> > > > > >  
> > > > >  
> > > > > I am open to anything but if I can''t do
something I might ask for some brave volunteers to set it up as I really never
tried anything else beside for local/quick test deployment.
> > > > > _______________________________________________
> > > > > Camping-list mailing list
> > > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > >  
> > > >  
> > > >  
> > > > _______________________________________________
> > > > Camping-list mailing list
> > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> >  
> >  
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
>  
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/a5ebc36e/attachment-0001.html>

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

Jenna Fox <a at creativepony.com> skrev:

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


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


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


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


?

Jenna


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

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

On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com> wrote:

Ah I forgot

you can compare camping running on thin here

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 <gurugeekphp at 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 at creativepony.com> wrote:

WebDav for nginx: http://wiki.nginx.org/HttpDavModule


Or you could implement webdav as an application nginx proxies to, just as it
proxies to ruby instances.


?

Jenna


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

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at lavabit.com>
wrote:

Actually setting up a reverse proxy gives better performance for the end user As
you can have some sort of buffer between them. The Unicorn server takes care of
whatever nginx asks for, and while it waits it can server whatever unicorn
outputs. It doesn''t have to wait for what it outputs itself to get done
because you have a queue. Or something like that.


Mh I am not really sure it would be a better performance as it would be anyway
more than one process. I think that phusion passenger is pretty much the most
robust solution for this.


Some people actually out Apache to do PHP stuff while nginx acts as a reverse
proxy and actually shows things to the user in the same way you''d do
with Unicorn/Thin


Well this would be even more load as two web servers will run at the same time.
Apache + Phusion passenger already lets you run .php or anything you want.


But this is not the issue really. I think this is all fine in term of mono user.
Question: if you have 100 users how do you configure it ?

How can you add webdav support on the top of the Nginx + unicorn setup ?



But perhaps That''s too much for a server ment to serve other peoples
applications! Then you have to scale down the resources used.



I am open to anything but if I can''t do something I might ask for some
brave volunteers to set it up as I really never tried anything else beside for
local/quick test deployment.

_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list



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




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


_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list


	Scarica Subito la Musica pi Trendy sul Tuo Telefonino 
	http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/68f31a78/attachment.html>

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

?
Jenna


On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote:
> Remember that we should pretty much make a Gemfile mandatory if the user
makes use of gems other than Camping. For example, rack_csrf. And we should make
sure that dependencies get installed. :)
> --  
> Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet.
>  
> Jenna Fox <a at creativepony.com (mailto:a at creativepony.com)>
skrev:
> > Hm. I know the main guy responsible for App Engine, and, well, I
certainly wouldn''t build a platform atop it - even aside from the huge
glaring issue that to have an app which can store data persistently, you need to
use google''s proprietary database software.
> >  
> > Heroku doesn''t screen against abuse at all. Heroku is not a
''shared hosting'' provider. Their systems use the very finest
jailing techniques to lock the ruby process in to it''s own little
world. It has no writable filesystem and it can only read what it absolutely
needs to be able to read to function. All data storage happens over the network
on separated database servers. The only type of abuse they need to be weary of
is people using their servers to do illegal things - bullying, sharing illegal
content, that sort of thing. They deal with that the same way any provider does
- wait till someone makes a complaint. Matz, inventor of ruby, works for heroku
making exactly this sort of stuff work extremely well.
> >  
> > Still, it''s not as friendly as it could be, and I personally
think the trade offs on heroku are not very good for beginners (you have to use
a complex database system, and cannot use the filesystem to store anything but
static assets).
> >  
> > Good work getting this server up David! I''m pretty excited.
It sounds like you''re having some pretty annoying deployment issues. As
it''s being quite a hassle, perhaps we should be thinking more deeply
about creating our own special server for this task - something like the
modified unicorn I mentioned earlier somewhere.
> >  
> > ?
> > Jenna
> >  
> >  
> > On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
> >  
> > > Wonder if Google might help getting camping to run on app engine?
> > >  
> > > On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com
(mailto:gurugeekphp at 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 <gurugeekphp
at gmail.com (mailto:gurugeekphp at 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 at
creativepony.com (mailto:a at creativepony.com)> wrote:
> > > > > > WebDav for nginx:
http://wiki.nginx.org/HttpDavModule
> > > > > >  
> > > > > > Or you could implement webdav as an application
nginx proxies to, just as it proxies to ruby instances.
> > > > > >  
> > > > > > ?
> > > > > > Jenna
> > > > > >  
> > > > > >  
> > > > > > On Sunday, 1 April 2012 at 2:11 AM, david costa
wrote:
> > > > > >  
> > > > > >  
> > > > > > > On Sat, Mar 31, 2012 at 5:36 PM, Isak
Andersson <IcePapih at lavabit.com (mailto:IcePapih at lavabit.com)>
wrote:
> > > > > > > > Actually setting up a reverse proxy
gives better performance for the end user As you can have some sort of buffer
between them. The Unicorn server takes care of whatever nginx asks for, and
while it waits it can server whatever unicorn outputs. It doesn''t have
to wait for what it outputs itself to get done because you have a queue. Or
something like that.
> > > > > > >  
> > > > > > > Mh I am not really sure it would be a better
performance as it would be anyway more than one process. I think that phusion
passenger is pretty much the most robust solution for this.
> > > > > > > >  
> > > > > > > > Some people actually out Apache to do
PHP stuff while nginx acts as a reverse proxy and actually shows things to the
user in the same way you''d do with Unicorn/Thin
> > > > > > >  
> > > > > > > Well this would be even more load as two web
servers will run at the same time. Apache + Phusion passenger already lets you
run .php or anything you want.
> > > > > > >  
> > > > > > > But this is not the issue really. I think
this is all fine in term of mono user. Question: if you have 100 users how do
you configure it ?
> > > > > > > How can you add webdav support on the top of
the Nginx + unicorn setup ?
> > > > > > >  
> > > > > > >  
> > > > > > > > But perhaps That''s too much for
a server ment to serve other peoples applications! Then you have to scale down
the resources used.
> > > > > > > >  
> > > > > > >  
> > > > > > > I am open to anything but if I can''t
do something I might ask for some brave volunteers to set it up as I really
never tried anything else beside for local/quick test deployment.
> > > > > > >
_______________________________________________
> > > > > > > Camping-list mailing list
> > > > > > > Camping-list at rubyforge.org
(mailto:Camping-list at rubyforge.org)
> > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > _______________________________________________
> > > > > > Camping-list mailing list
> > > > > > Camping-list at rubyforge.org (mailto:Camping-list
at rubyforge.org)
> > > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > > >  
> > > >  
> > > >  
> > > > _______________________________________________
> > > > Camping-list mailing list
> > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> > > _______________________________________________
> > > Camping-list mailing list
> > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> > >  
> > >  
> >  
> >  
> > Scarica Subito la Musica pi Trendy sul Tuo Telefonino  
> >
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/b934999a/attachment-0001.html>

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 at 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 at creativepony.com> skrev:

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


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


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


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


?

Jenna


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

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

On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com> wrote:

Ah I forgot

you can compare camping running on thin here

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 <gurugeekphp at 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 at creativepony.com> wrote:

WebDav for nginx: http://wiki.nginx.org/HttpDavModule


Or you could implement webdav as an application nginx proxies to, just as it
proxies to ruby instances.


?

Jenna


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

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at lavabit.com>
wrote:

Actually setting up a reverse proxy gives better performance for the end user As
you can have some sort of buffer between them. The Unicorn server takes care of
whatever nginx asks for, and while it waits it can server whatever unicorn
outputs. It doesn''t have to wait for what it outputs itself to get done
because you have a queue. Or something like that.


Mh I am not really sure it would be a better performance as it would be anyway
more than one process. I think that phusion passenger is pretty much the most
robust solution for this.


Some people actually out Apache to do PHP stuff while nginx acts as a reverse
proxy and actually shows things to the user in the same way you''d do
with Unicorn/Thin


Well this would be even more load as two web servers will run at the same time.
Apache + Phusion passenger already lets you run .php or anything you want.


But this is not the issue really. I think this is all fine in term of mono user.
Question: if you have 100 users how do you configure it ?

How can you add webdav support on the top of the Nginx + unicorn setup ?



But perhaps That''s too much for a server ment to serve other peoples
applications! Then you have to scale down the resources used.



I am open to anything but if I can''t do something I might ask for some
brave volunteers to set it up as I really never tried anything else beside for
local/quick test deployment.

_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list



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




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


_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list


	Scarica Subito la Musica pi Trendy sul Tuo Telefonino 
	http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ 

_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list


	Download de gratis Registry Scan om het problem te vinden!
	http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/d23ba84c/attachment.html>

@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 at 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 at creativepony.com> skrev:
>>> 
>>> Hm. I know the main guy responsible for App Engine, and, well, I
certainly wouldn''t build a platform atop it - even aside from the huge
glaring issue that to have an app which can store data persistently, you need to
use google''s proprietary database software.
>>> 
>>> Heroku doesn''t screen against abuse at all. Heroku is not
a ''shared hosting'' provider. Their systems use the very finest
jailing techniques to lock the ruby process in to it''s own little
world. It has no writable filesystem and it can only read what it absolutely
needs to be able to read to function. All data storage happens over the network
on separated database servers. The only type of abuse they need to be weary of
is people using their servers to do illegal things - bullying, sharing illegal
content, that sort of thing. They deal with that the same way any provider does
- wait till someone makes a complaint. Matz, inventor of ruby, works for heroku
making exactly this sort of stuff work extremely well.
>>> 
>>> Still, it''s not as friendly as it could be, and I
personally think the trade offs on heroku are not very good for beginners (you
have to use a complex database system, and cannot use the filesystem to store
anything but static assets).
>>> 
>>> Good work getting this server up David! I''m pretty
excited. It sounds like you''re having some pretty annoying deployment
issues. As it''s being quite a hassle, perhaps we should be thinking
more deeply about creating our own special server for this task - something like
the modified unicorn I mentioned earlier somewhere.
>>> 
>>> ?
>>> Jenna
>>> 
>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
>>> 
>>>> Wonder if Google might help getting camping to run on app
engine?
>>>> 
>>>> On 1 April 2012 10:03, david costa <gurugeekphp at
gmail.com> wrote:
>>>>> Ah I forgot
>>>>> you can compare camping running on thin here
>>>>> 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 <gurugeekphp
at 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 at
creativepony.com> wrote:
>>>>>>> WebDav for nginx:
http://wiki.nginx.org/HttpDavModule
>>>>>>> 
>>>>>>> Or you could implement webdav as an application
nginx proxies to, just as it proxies to ruby instances.
>>>>>>> 
>>>>>>> ?
>>>>>>> Jenna
>>>>>>> 
>>>>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa
wrote:
>>>>>>> 
>>>>>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson
<IcePapih at lavabit.com> wrote:
>>>>>>>>> Actually setting up a reverse proxy gives
better performance for the end user As you can have some sort of buffer between
them. The Unicorn server takes care of whatever nginx asks for, and while it
waits it can server whatever unicorn outputs. It doesn''t have to wait
for what it outputs itself to get done because you have a queue. Or something
like that.
>>>>>>>> 
>>>>>>>> Mh I am not really sure it would be a better
performance as it would be anyway more than one process. I think that phusion
passenger is pretty much the most robust solution for this.
>>>>>>>>> 
>>>>>>>>> Some people actually out Apache to do PHP
stuff while nginx acts as a reverse proxy and actually shows things to the user
in the same way you''d do with Unicorn/Thin
>>>>>>>> 
>>>>>>>> Well this would be even more load as two web
servers will run at the same time. Apache + Phusion passenger already lets you
run .php or anything you want.
>>>>>>>> 
>>>>>>>> But this is not the issue really. I think this
is all fine in term of mono user. Question: if you have 100 users how do you
configure it ?
>>>>>>>> How can you add webdav support on the top of
the Nginx + unicorn setup ?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> But perhaps That''s too much for a
server ment to serve other peoples applications! Then you have to scale down the
resources used.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I am open to anything but if I can''t
do something I might ask for some brave volunteers to set it up as I really
never tried anything else beside for local/quick test deployment.
>>>>>>>> _______________________________________________
>>>>>>>> Camping-list mailing list
>>>>>>>> Camping-list at rubyforge.org
>>>>>>>>
http://rubyforge.org/mailman/listinfo/camping-list
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Camping-list mailing list
>>>>>>> Camping-list at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>> 
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>> 
>>> Scarica Subito la Musica pi Trendy sul Tuo Telefonino 
>>>
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
>> 
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
> 
> Download de gratis Registry Scan om het problem te vinden!
>
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/9088bfd1/attachment-0001.html>

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 at 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 at 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 at creativepony.com> skrev:

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


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


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


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


?

Jenna


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

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

On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com> wrote:

Ah I forgot

you can compare camping running on thin here

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 <gurugeekphp at 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 at creativepony.com> wrote:

WebDav for nginx: http://wiki.nginx.org/HttpDavModule


Or you could implement webdav as an application nginx proxies to, just as it
proxies to ruby instances.


?

Jenna


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

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at lavabit.com>
wrote:

Actually setting up a reverse proxy gives better performance for the end user As
you can have some sort of buffer between them. The Unicorn server takes care of
whatever nginx asks for, and while it waits it can server whatever unicorn
outputs. It doesn''t have to wait for what it outputs itself to get done
because you have a queue. Or something like that.


Mh I am not really sure it would be a better performance as it would be anyway
more than one process. I think that phusion passenger is pretty much the most
robust solution for this.


Some people actually out Apache to do PHP stuff while nginx acts as a reverse
proxy and actually shows things to the user in the same way you''d do
with Unicorn/Thin


Well this would be even more load as two web servers will run at the same time.
Apache + Phusion passenger already lets you run .php or anything you want.


But this is not the issue really. I think this is all fine in term of mono user.
Question: if you have 100 users how do you configure it ?

How can you add webdav support on the top of the Nginx + unicorn setup ?



But perhaps That''s too much for a server ment to serve other peoples
applications! Then you have to scale down the resources used.



I am open to anything but if I can''t do something I might ask for some
brave volunteers to set it up as I really never tried anything else beside for
local/quick test deployment.

_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list



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




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


_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list


	Scarica Subito la Musica pi Trendy sul Tuo Telefonino 
	http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/ 

_______________________________________________

Camping-list mailing list

Camping-list at rubyforge.org

http://rubyforge.org/mailman/listinfo/camping-list


	Download de gratis Registry Scan om het problem te vinden!
	http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/ 

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

	Get the best selection of names sites here. Click Here to check them out!
	http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/dbddb5a4/attachment.html>

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 <IcePapih at 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 at 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 at 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 at creativepony.com> skrev:
>>>
>>> Hm. I know the main guy responsible for App Engine, and, well, I
>>> certainly wouldn''t build a platform atop it - even aside
from the huge
>>> glaring issue that to have an app which can store data
persistently, you
>>> need to use google''s proprietary database software.
>>>
>>> Heroku doesn''t screen against abuse at all. Heroku is not
a ''shared
>>> hosting'' provider. Their systems use the very finest
jailing techniques to
>>> lock the ruby process in to it''s own little world. It has
no writable
>>> filesystem and it can only read what it absolutely needs to be able
to read
>>> to function. All data storage happens over the network on separated
>>> database servers. The only type of abuse they need to be weary of
is people
>>> using their servers to do illegal things - bullying, sharing
illegal
>>> content, that sort of thing. They deal with that the same way any
provider
>>> does - wait till someone makes a complaint. Matz, inventor of ruby,
works
>>> for heroku making exactly this sort of stuff work extremely well.
>>>
>>> Still, it''s not as friendly as it could be, and I
personally think the
>>> trade offs on heroku are not very good for beginners (you have to
use a
>>> complex database system, and cannot use the filesystem to store
anything
>>> but static assets).
>>>
>>> Good work getting this server up David! I''m pretty
excited. It sounds
>>> like you''re having some pretty annoying deployment issues.
As it''s being
>>> quite a hassle, perhaps we should be thinking more deeply about
creating
>>> our own special server for this task - something like the modified
unicorn
>>> I mentioned earlier somewhere.
>>>
>>> ?
>>> Jenna
>>>
>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
>>>
>>> Wonder if Google might help getting camping to run on app engine?
>>>
>>> On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com>
wrote:
>>>
>>> Ah I forgot
>>> you can compare camping running on thin here
>>> 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 <gurugeekphp at
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 at
creativepony.com> wrote:
>>>
>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>>
>>> Or you could implement webdav as an application nginx proxies to,
just
>>> as it proxies to ruby instances.
>>>
>>> ?
>>> Jenna
>>>
>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>>
>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>>>
>>> ** Actually setting up a reverse proxy gives better performance for
the
>>> end user As you can have some sort of buffer between them. The
Unicorn
>>> server takes care of whatever nginx asks for, and while it waits it
can
>>> server whatever unicorn outputs. It doesn''t have to wait
for what it
>>> outputs itself to get done because you have a queue. Or something
like that.
>>>
>>>
>>> Mh I am not really sure it would be a better performance as it
would be
>>> anyway more than one process. I think that phusion passenger is
pretty much
>>> the most robust solution for this.
>>>
>>>
>>> Some people actually out Apache to do PHP stuff while nginx acts as
a
>>> reverse proxy and actually shows things to the user in the same way
you''d
>>> do with Unicorn/Thin
>>>
>>>
>>> Well this would be even more load as two web servers will run at
the
>>> same time. Apache + Phusion passenger already lets you run .php or
anything
>>> you want.
>>>
>>> But this is not the issue really. I think this is all fine in term
of
>>> mono user. Question: if you have 100 users how do you configure it
?
>>> How can you add webdav support on the top of the Nginx + unicorn
setup ?
>>>
>>>
>>> But perhaps That''s too much for a server ment to serve
other peoples
>>> applications! Then you have to scale down the resources used.
>>>
>>>
>>> I am open to anything but if I can''t do something I might
ask for some
>>> brave volunteers to set it up as I really never tried anything else
beside
>>> for local/quick test deployment.
>>>  _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>  Scarica Subito la Musica pi Trendy sul Tuo Telefonino
>>>
>>>
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>>  Download de gratis Registry Scan om het problem te vinden!
>>>
>>>
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>> Get the best selection of names sites here. Click Here to check them
out!
>
>
http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/c4fc3405/attachment-0001.html>

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  
> <IcePapih at 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 at 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 at 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 at creativepony.com> skrev:
>>>>
>>>> Hm. I know the main guy responsible for App Engine, and, well,
I
>>>> certainly wouldn''t build a platform atop it - even
aside from the
>>>> huge glaring issue that to have an app which can store data  
>>>> persistently, you need to use google''s proprietary
database
>>>> software.
>>>>
>>>> Heroku doesn''t screen against abuse at all. Heroku is
not a
>>>> ''shared hosting'' provider. Their systems use
the very finest
>>>> jailing techniques to lock the ruby process in to it''s
own little
>>>> world. It has no writable filesystem and it can only read what
it
>>>> absolutely needs to be able to read to function. All data
storage
>>>> happens over the network on separated database servers. The
only
>>>> type of abuse they need to be weary of is people using their  
>>>> servers to do illegal things - bullying, sharing illegal
content,
>>>> that sort of thing. They deal with that the same way any
provider
>>>> does - wait till someone makes a complaint. Matz, inventor of  
>>>> ruby, works for heroku making exactly this sort of stuff work  
>>>> extremely well.
>>>>
>>>> Still, it''s not as friendly as it could be, and I
personally
>>>> think the trade offs on heroku are not very good for beginners
>>>> (you have to use a complex database system, and cannot use the
>>>> filesystem to store anything but static assets).
>>>>
>>>> Good work getting this server up David! I''m pretty
excited. It
>>>> sounds like you''re having some pretty annoying
deployment issues.
>>>> As it''s being quite a hassle, perhaps we should be
thinking more
>>>> deeply about creating our own special server for this task -  
>>>> something like the modified unicorn I mentioned earlier
somewhere.
>>>>
>>>> ?
>>>> Jenna
>>>>
>>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
>>>>
>>>>> Wonder if Google might help getting camping to run on app
engine?
>>>>>
>>>>> On 1 April 2012 10:03, david costa <gurugeekphp at
gmail.com> wrote:
>>>>>> Ah I forgot
>>>>>> you can compare camping running on thin here
>>>>>> 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
<gurugeekphp at 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 at
creativepony.com>
>>>>>>> wrote:
>>>>>>>> WebDav for nginx:
http://wiki.nginx.org/HttpDavModule
>>>>>>>>
>>>>>>>> Or you could implement webdav as an application
nginx proxies
>>>>>>>> to, just as it proxies to ruby instances.
>>>>>>>>
>>>>>>>> ?
>>>>>>>> Jenna
>>>>>>>>
>>>>>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa
wrote:
>>>>>>>>
>>>>>>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak
Andersson <IcePapih at lavabit.com
>>>>>>>>> > wrote:
>>>>>>>>>> Actually setting up a reverse proxy
gives better
>>>>>>>>>> performance for the end user As you can
have some sort of
>>>>>>>>>> buffer between them. The Unicorn server
takes care of
>>>>>>>>>> whatever nginx asks for, and while it
waits it can server
>>>>>>>>>> whatever unicorn outputs. It
doesn''t have to wait for what
>>>>>>>>>> it outputs itself to get done because
you have a queue. Or
>>>>>>>>>> something like that.
>>>>>>>>>
>>>>>>>>> Mh I am not really sure it would be a
better performance as
>>>>>>>>> it would be anyway more than one process. I
think that
>>>>>>>>> phusion passenger is pretty much the most
robust solution
>>>>>>>>> for this.
>>>>>>>>>>
>>>>>>>>>> Some people actually out Apache to do
PHP stuff while nginx
>>>>>>>>>> acts as a reverse proxy and actually
shows things to the
>>>>>>>>>> user in the same way you''d do
with Unicorn/Thin
>>>>>>>>>
>>>>>>>>> Well this would be even more load as two
web servers will
>>>>>>>>> run at the same time. Apache + Phusion
passenger already
>>>>>>>>> lets you run .php or anything you want.
>>>>>>>>>
>>>>>>>>> But this is not the issue really. I think
this is all fine
>>>>>>>>> in term of mono user. Question: if you have
100 users how do
>>>>>>>>> you configure it ?
>>>>>>>>> How can you add webdav support on the top
of the Nginx +
>>>>>>>>> unicorn setup ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> But perhaps That''s too much
for a server ment to serve
>>>>>>>>>> other peoples applications! Then you
have to scale down the
>>>>>>>>>> resources used.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am open to anything but if I
can''t do something I might
>>>>>>>>> ask for some brave volunteers to set it up
as I really never
>>>>>>>>> tried anything else beside for local/quick
test deployment.
>>>>>>>>>
_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120401/251bd504/attachment.html>

Oh gods not RVM. This setup does not need another layer of complexity.  

On my own server, I use five thins, which run all the time, on a set of five
ports which nginx proxy to. To run hundreds of camping apps, this sort of
persistent setup isn''t viable. CGI would work, but could be a little
slow for some more complex applications. A better solution is, in my opinion, to
fork. thins or unicorns could be connected with a simple camping app which forks
on each request, loads a users app in to that instance, runs it once, then
closes. It would be faster than CGI, not too hard to implement, and
wouldn''t take more resources to install more apps on the server. It
also makes for a convenient place to run code before the user''s
application runs, which maybe useful for sandboxing or setting up web accessible
logging.

From what I''ve heard chroot isn''t a good way to jail processes
- it doesn''t restrict network access, and it''s often possible
to escape the jail. Consider this: A script loads the socket library and opens
port after port until computer fails. Disable the socket library? have the ruby
process store a binary inside it, which it saves to a file, sets execute
permission, then runs - it does the same thing. Another attack would be a fork
bomb.

Security is really complex. How did dot geek deal with it? did you ever have
trouble with malicious users?

?
Jenna


On Monday, 2 April 2012 at 1:49 AM, david costa wrote:
> Hello again ! :)
> well in theory we can chrot jail users but the best way is to install the
gems that people need perhaps the most used ones. It will then work system wide
!
> The big question is who will be your typical user. If is someone you trust
then you can give them even limited ssh + sftp :)
>  
> Back to my ignorance: how do you folks run camping in a server ? do you use
fcgi ? At work we used to run a fairly big production environment made of rails 
running with lighthtp  and fcgi. If we were to run this as a dead simple fcgi
setup did anyone set this up? I have tried all the instructions github on how to
set this up with dispatcher.fcgi but failed miserably.
>  
> I would can get the server installed + fcgi but how to run camping apps
from there is a bit of a mystery.
>  
> I am slightly frustrated because of passenger not making a simple create
page/test page http://camping.sh/ working. I know is not the app as it works at
http://camping.sh:3301/
> Unicorn: I think you would be back to have nginx as a reverse proxy for
that which can present some problems for example, default port is 3301 for
camping. So you would need a script to check which port is free and run then
camping --port so seems a bit complicated.
>  
> Thanks
> David
>  
>  
> On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson <IcePapih at lavabit.com
(mailto:IcePapih at 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 at creativepony.com (mailto:a at 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 at creativepony.com (mailto:a at
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 at creativepony.com (mailto:a at
creativepony.com)> skrev:
> > > > > > > Hm. I know the main guy responsible for App
Engine, and, well, I certainly wouldn''t build a platform atop it - even
aside from the huge glaring issue that to have an app which can store data
persistently, you need to use google''s proprietary database software.
> > > > > > >  
> > > > > > > Heroku doesn''t screen against abuse
at all. Heroku is not a ''shared hosting'' provider. Their
systems use the very finest jailing techniques to lock the ruby process in to
it''s own little world. It has no writable filesystem and it can only
read what it absolutely needs to be able to read to function. All data storage
happens over the network on separated database servers. The only type of abuse
they need to be weary of is people using their servers to do illegal things -
bullying, sharing illegal content, that sort of thing. They deal with that the
same way any provider does - wait till someone makes a complaint. Matz, inventor
of ruby, works for heroku making exactly this sort of stuff work extremely well.
> > > > > > >  
> > > > > > > Still, it''s not as friendly as it
could be, and I personally think the trade offs on heroku are not very good for
beginners (you have to use a complex database system, and cannot use the
filesystem to store anything but static assets).
> > > > > > >  
> > > > > > > Good work getting this server up David!
I''m pretty excited. It sounds like you''re having some pretty
annoying deployment issues. As it''s being quite a hassle, perhaps we
should be thinking more deeply about creating our own special server for this
task - something like the modified unicorn I mentioned earlier somewhere.
> > > > > > >  
> > > > > > > ?
> > > > > > > Jenna
> > > > > > >  
> > > > > > >  
> > > > > > > On Sunday, 1 April 2012 at 6:23 PM, Peter
Retief wrote:
> > > > > > >  
> > > > > > > > Wonder if Google might help getting
camping to run on app engine?
> > > > > > > >  
> > > > > > > > On 1 April 2012 10:03, david costa
<gurugeekphp at gmail.com (mailto:gurugeekphp at 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 <gurugeekphp at gmail.com (mailto:gurugeekphp at 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 at creativepony.com (mailto:a at creativepony.com)>
wrote:
> > > > > > > > > > > WebDav for nginx:
http://wiki.nginx.org/HttpDavModule
> > > > > > > > > > >  
> > > > > > > > > > > Or you could implement
webdav as an application nginx proxies to, just as it proxies to ruby instances.
> > > > > > > > > > >  
> > > > > > > > > > > ?
> > > > > > > > > > > Jenna
> > > > > > > > > > >  
> > > > > > > > > > >  
> > > > > > > > > > > On Sunday, 1 April 2012
at 2:11 AM, david costa wrote:
> > > > > > > > > > >  
> > > > > > > > > > >  
> > > > > > > > > > > > On Sat, Mar 31, 2012
at 5:36 PM, Isak Andersson <IcePapih at lavabit.com (mailto:IcePapih at
lavabit.com)> wrote:
> > > > > > > > > > > > > Actually
setting up a reverse proxy gives better performance for the end user As you can
have some sort of buffer between them. The Unicorn server takes care of whatever
nginx asks for, and while it waits it can server whatever unicorn outputs. It
doesn''t have to wait for what it outputs itself to get done because you
have a queue. Or something like that.
> > > > > > > > > > > >  
> > > > > > > > > > > > Mh I am not really
sure it would be a better performance as it would be anyway more than one
process. I think that phusion passenger is pretty much the most robust solution
for this.
> > > > > > > > > > > > >  
> > > > > > > > > > > > > Some people
actually out Apache to do PHP stuff while nginx acts as a reverse proxy and
actually shows things to the user in the same way you''d do with
Unicorn/Thin
> > > > > > > > > > > >  
> > > > > > > > > > > > Well this would be
even more load as two web servers will run at the same time. Apache + Phusion
passenger already lets you run .php or anything you want.
> > > > > > > > > > > >  
> > > > > > > > > > > > But this is not the
issue really. I think this is all fine in term of mono user. Question: if you
have 100 users how do you configure it ?
> > > > > > > > > > > > How can you add
webdav support on the top of the Nginx + unicorn setup ?
> > > > > > > > > > > >  
> > > > > > > > > > > >  
> > > > > > > > > > > > > But perhaps
That''s too much for a server ment to serve other peoples applications!
Then you have to scale down the resources used.
> > > > > > > > > > > > >  
> > > > > > > > > > > >  
> > > > > > > > > > > > I am open to
anything but if I can''t do something I might ask for some brave
volunteers to set it up as I really never tried anything else beside for
local/quick test deployment.
> > > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > > Camping-list mailing
list
> > > > > > > > > > > > Camping-list at
rubyforge.org (mailto:Camping-list at rubyforge.org)
> > > > > > > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > > > > > > > >  
> > > > > > > > > > > >  
> > > > > > > > > > > >  
> > > > > > > > > > > >  
> > > > > > > > > > >  
> > > > > > > > > > >  
> > > > > > > > > > >  
> > > > > > > > > > >
_______________________________________________
> > > > > > > > > > > Camping-list mailing list
> > > > > > > > > > > Camping-list at
rubyforge.org (mailto:Camping-list at rubyforge.org)
> > > > > > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >
_______________________________________________
> > > > > > > > > Camping-list mailing list
> > > > > > > > > Camping-list at rubyforge.org
(mailto:Camping-list at rubyforge.org)
> > > > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > > > >  
> > > > > > > >
_______________________________________________
> > > > > > > > Camping-list mailing list
> > > > > > > > Camping-list at rubyforge.org
(mailto:Camping-list at rubyforge.org)
> > > > > > > >
http://rubyforge.org/mailman/listinfo/camping-list
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > > Scarica Subito la Musica pi Trendy sul Tuo
Telefonino
> > > > > > >
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
> > > > > > _______________________________________________
> > > > > > Camping-list mailing list
> > > > > > Camping-list at rubyforge.org (mailto:Camping-list
at rubyforge.org)
> > > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > > > >  
> > > > > >  
> > > > > >  
> > > > >  
> > > > >  
> > > > > Download de gratis Registry Scan om het problem te
vinden!
> > > > >
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
_______________________________________________
> > > > Camping-list mailing list
> > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/camping-list
> > Get the best selection of names sites here. Click Here to check them
out!
> >
http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
>  
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/6c8b4914/attachment-0001.html>

I have no idea but could something like ZeroVM be useful?

http://zerovm.org/

On Monday, April 2, 2012, Jenna Fox 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.
>
> From what I''ve heard chroot isn''t a good way to jail
processes - it
> doesn''t restrict network access, and it''s often possible
to escape the
> jail. Consider this: A script loads the socket library and opens port after
> port until computer fails. Disable the socket library? have the ruby
> process store a binary inside it, which it saves to a file, sets execute
> permission, then runs - it does the same thing. Another attack would be a
> fork bomb.
>
> Security is really complex. How did dot geek deal with it? did you ever
> have trouble with malicious users?
>
> ?
> Jenna
>
> On Monday, 2 April 2012 at 1:49 AM, david costa wrote:
>
> Hello again ! :)
> well in theory we can chrot jail users but the best way is to install the
> gems that people need perhaps the most used ones. It will then work system
> wide !
> The big question is who will be your typical user. If is someone you trust
> then you can give them even limited ssh + sftp :)
>
> Back to my ignorance: how do you folks run camping in a server ? do you
> use fcgi ? At work we used to run a fairly big production environment made
> of rails  running with lighthtp  and fcgi. If we were to run this as a dead
> simple fcgi setup did anyone set this up? I have tried all the instructions
> github on how to set this up with dispatcher.fcgi but failed miserably.
>
> I would can get the server installed + fcgi but how to run camping apps
> from there is a bit of a mystery.
>
> I am slightly frustrated because of passenger not making a simple create
> page/test page http://camping.sh/ working. I know is not the app as it
> works at http://camping.sh:3301/
> Unicorn: I think you would be back to have nginx as a reverse proxy for
> that which can present some problems for example, default port is 3301 for
> camping. So you would need a script to check which port is free and run
> then camping --port so seems a bit complicated.
>
> Thanks
> David
>
>
> On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson <IcePapih at
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 at 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 at 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 at creativepony.com> skrev:
>
> Hm. I know the main guy responsible for App Engine, and, well, I certainly
> wouldn''t build a platform atop it - even aside from the huge
glaring issue
> that to have an app which can store data persistently, you need to use
> google''s proprietary database software.
>
> Heroku doesn''t screen against abuse at all. Heroku is not a
''shared
> hosting'' provider. Their systems use the very finest jailing
techniques to
> lock the ruby process in to it''s own little world. It has no
writable
> filesystem and it can only read what it absolutely needs to be able to read
> to function. All data storage happens over the network on separated datab
>
>
-- 
----=^.^=---
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/0323162f/attachment.html>

On Mon, Apr 2, 2012 at 1:02 AM, Jenna Fox <a at 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

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/85ba4f6f/attachment-0001.html>

Hi Adam :)

On Mon, Apr 2, 2012 at 2:46 AM, adam moore <nerdfunk at gmail.com> wrote:
> I have no idea but could something like ZeroVM be useful?
>
> http://zerovm.org/
>
> Well this is entirely different :) If you give a virtualized environment
the user is pretty much on his own and can do/install anything as in a
separate server. Per see is a good idea but the question is how camping as
a community would gain out of it. Another issue is you do have already free
competition
http://aws.amazon.com/free/
with a pretty decent offer if you ask me (which I am sure many are using).
My idea was just to make easier for learners to run and deploy a camping
app e.g. from command line
camping-fly BestApp  and then you would see it live at
bestapp.camping.iosimple yet effective as I don''t think any other
framework, micro or not,
offers this out of the box.
As camping is a micro framework that might be used for smallish projects
this would work fine e.g. you are working on a quick idea and you want to
show it to some friends, colleagues or need to use it for a class project
and there you go. Low learning curve !
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/3fbf5f4c/attachment.html>

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 <gurugeekphp at 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 <IcePapih at
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 at 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 at 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 at creativepony.com> skrev:
>>>>
>>>> Hm. I know the main guy responsible for App Engine, and, well,
I
>>>> certainly wouldn''t build a platform atop it - even
aside from the huge
>>>> glaring issue that to have an app which can store data
persistently, you
>>>> need to use google''s proprietary database software.
>>>>
>>>> Heroku doesn''t screen against abuse at all. Heroku is
not a ''shared
>>>> hosting'' provider. Their systems use the very finest
jailing techniques to
>>>> lock the ruby process in to it''s own little world. It
has no writable
>>>> filesystem and it can only read what it absolutely needs to be
able to read
>>>> to function. All data storage happens over the network on
separated
>>>> database servers. The only type of abuse they need to be weary
of is people
>>>> using their servers to do illegal things - bullying, sharing
illegal
>>>> content, that sort of thing. They deal with that the same way
any provider
>>>> does - wait till someone makes a complaint. Matz, inventor of
ruby, works
>>>> for heroku making exactly this sort of stuff work extremely
well.
>>>>
>>>> Still, it''s not as friendly as it could be, and I
personally think the
>>>> trade offs on heroku are not very good for beginners (you have
to use a
>>>> complex database system, and cannot use the filesystem to store
anything
>>>> but static assets).
>>>>
>>>> Good work getting this server up David! I''m pretty
excited. It sounds
>>>> like you''re having some pretty annoying deployment
issues. As it''s being
>>>> quite a hassle, perhaps we should be thinking more deeply about
creating
>>>> our own special server for this task - something like the
modified unicorn
>>>> I mentioned earlier somewhere.
>>>>
>>>> ?
>>>> Jenna
>>>>
>>>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
>>>>
>>>> Wonder if Google might help getting camping to run on app
engine?
>>>>
>>>> On 1 April 2012 10:03, david costa <gurugeekphp at
gmail.com> wrote:
>>>>
>>>> Ah I forgot
>>>> you can compare camping running on thin here
>>>> 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 <gurugeekphp at
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 at
creativepony.com> wrote:
>>>>
>>>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>>>
>>>> Or you could implement webdav as an application nginx proxies
to, just
>>>> as it proxies to ruby instances.
>>>>
>>>> ?
>>>> Jenna
>>>>
>>>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>>>
>>>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>>>>
>>>> ** Actually setting up a reverse proxy gives better performance
for
>>>> the end user As you can have some sort of buffer between them.
The Unicorn
>>>> server takes care of whatever nginx asks for, and while it
waits it can
>>>> server whatever unicorn outputs. It doesn''t have to
wait for what it
>>>> outputs itself to get done because you have a queue. Or
something like that.
>>>>
>>>>
>>>> Mh I am not really sure it would be a better performance as it
would be
>>>> anyway more than one process. I think that phusion passenger is
pretty much
>>>> the most robust solution for this.
>>>>
>>>>
>>>> Some people actually out Apache to do PHP stuff while nginx
acts as a
>>>> reverse proxy and actually shows things to the user in the same
way you''d
>>>> do with Unicorn/Thin
>>>>
>>>>
>>>> Well this would be even more load as two web servers will run
at the
>>>> same time. Apache + Phusion passenger already lets you run .php
or anything
>>>> you want.
>>>>
>>>> But this is not the issue really. I think this is all fine in
term of
>>>> mono user. Question: if you have 100 users how do you configure
it ?
>>>> How can you add webdav support on the top of the Nginx +
unicorn setup ?
>>>>
>>>>
>>>> But perhaps That''s too much for a server ment to serve
other peoples
>>>> applications! Then you have to scale down the resources used.
>>>>
>>>>
>>>> I am open to anything but if I can''t do something I
might ask for some
>>>> brave volunteers to set it up as I really never tried anything
else beside
>>>> for local/quick test deployment.
>>>>  _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>  Scarica Subito la Musica pi Trendy sul Tuo Telefonino
>>>>
>>>>
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>>
>>>>  Download de gratis Registry Scan om het problem te vinden!
>>>>
>>>>
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
>>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>>
>>> Get the best selection of names sites here. Click Here to check
them out!
>>
>>
http://click.lavabit.com/kjnnwpwx7rfhs87amq3msu4unurqou7r41y6imtiaksp48anaaky/
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/0b09cfe8/attachment-0001.html>

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 <IcePapih at 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 at 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 at creativepony.com> skrev:
>>
>> Hm. I know the main guy responsible for App Engine, and, well, I
>> certainly wouldn''t build a platform atop it - even aside from
the huge
>> glaring issue that to have an app which can store data persistently,
you
>> need to use google''s proprietary database software.
>>
>> Heroku doesn''t screen against abuse at all. Heroku is not a
''shared
>> hosting'' provider. Their systems use the very finest jailing
techniques to
>> lock the ruby process in to it''s own little world. It has no
writable
>> filesystem and it can only read what it absolutely needs to be able to
read
>> to function. All data storage happens over the network on separated
>> database servers. The only type of abuse they need to be weary of is
people
>> using their servers to do illegal things - bullying, sharing illegal
>> content, that sort of thing. They deal with that the same way any
provider
>> does - wait till someone makes a complaint. Matz, inventor of ruby,
works
>> for heroku making exactly this sort of stuff work extremely well.
>>
>> Still, it''s not as friendly as it could be, and I personally
think the
>> trade offs on heroku are not very good for beginners (you have to use a
>> complex database system, and cannot use the filesystem to store
anything
>> but static assets).
>>
>> Good work getting this server up David! I''m pretty excited. It
sounds
>> like you''re having some pretty annoying deployment issues. As
it''s being
>> quite a hassle, perhaps we should be thinking more deeply about
creating
>> our own special server for this task - something like the modified
unicorn
>> I mentioned earlier somewhere.
>>
>> ?
>> Jenna
>>
>> On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
>>
>> Wonder if Google might help getting camping to run on app engine?
>>
>> On 1 April 2012 10:03, david costa <gurugeekphp at gmail.com>
wrote:
>>
>> Ah I forgot
>> you can compare camping running on thin here
>> 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 <gurugeekphp at
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 at creativepony.com>
wrote:
>>
>> WebDav for nginx: http://wiki.nginx.org/HttpDavModule
>>
>> Or you could implement webdav as an application nginx proxies to, just
as
>> it proxies to ruby instances.
>>
>> ?
>> Jenna
>>
>> On Sunday, 1 April 2012 at 2:11 AM, david costa wrote:
>>
>> On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih at
lavabit.com>wrote:
>>
>> ** Actually setting up a reverse proxy gives better performance for the
>> end user As you can have some sort of buffer between them. The Unicorn
>> server takes care of whatever nginx asks for, and while it waits it can
>> server whatever unicorn outputs. It doesn''t have to wait for
what it
>> outputs itself to get done because you have a queue. Or something like
that.
>>
>>
>> Mh I am not really sure it would be a better performance as it would be
>> anyway more than one process. I think that phusion passenger is pretty
much
>> the most robust solution for this.
>>
>>
>> Some people actually out Apache to do PHP stuff while nginx acts as a
>> reverse proxy and actually shows things to the user in the same way
you''d
>> do with Unicorn/Thin
>>
>>
>> Well this would be even more load as two web servers will run at the
same
>> time. Apache + Phusion passenger already lets you run .php or anything
you
>> want.
>>
>> But this is not the issue really. I think this is all fine in term of
>> mono user. Question: if you have 100 users how do you configure it ?
>> How can you add webdav support on the top of the Nginx + unicorn setup
?
>>
>>
>> But perhaps That''s too much for a server ment to serve other
peoples
>> applications! Then you have to scale down the resources used.
>>
>>
>> I am open to anything but if I can''t do something I might ask
for some
>> brave volunteers to set it up as I really never tried anything else
beside
>> for local/quick test deployment.
>>  _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>  Scarica Subito la Musica pi Trendy sul Tuo Telefonino
>>
>>
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>  Download de gratis Registry Scan om het problem te vinden!
>>
>>
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
>>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/c8b301d0/attachment.html>

>
> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/02d2bec2/attachment-0001.html>

Apart from the obvious (rack, markaby, etc...), possibly trivial  
relevant gems I''ve used/tried (and am happy with): data_mapper,  
kramdown, RedCloth

Agreed: `camping-fly MyLovelyApp` is the baseline aim - this  
functionality would be a deployment holy grail :-)

- DaveE
> I really want to know what gems do you (all out there) think  
> quality...
>
>> My idea was just to make easier for learners to run and deploy a  
>> camping app e.g. from command line camping-fly BestApp
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/f47e97dc/attachment.html>

A way to check for this kind of abuse would be to only allow static  
files referred to in the Camping app itself - DaveE
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/4796b005/attachment.html>

haha! Oh well... you''re right :-)

Just emailed David to test all this with one of my totally boring  
little local apps.

  - DaveE
> Oh gods not RVM. This setup does not need another layer of complexity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/33f91d9c/attachment.html>

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 <uzleepito at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/7e90f6b5/attachment.html>

>
>
> Just emailed David to test all this with one of my totally boring little
> local apps.
>
> your account has been setup and details sent directly :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120402/19c00c25/attachment.html>

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