david costa | 30 Mar 18:22 2012
Picon

dead easy deployment / Camping on the fly

Hello all,

I am opening a separate topic just to brainstorm the idea of a free, simple camping deployment/hosting option.
Now this is not about re-inventing the wheel as heroku already supports camping apps too. So this would be the ground idea:

a) This would be entirely free - no paid plans to upgrade etc.;
b) Eventually users should be able to deploy a camping application by launching something like camping-fly myapp in the command line and it would simply work (through a git push or similar) and make it available live in a custom domain like camping.sh or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am
c) Database fanciness should also be available or at least sqlite/mysql

Suggestion and ideas on how to achieve this are welcome (or professionals with the expertise willing to do a simple project based on this )
servers I can make available for this: 

Debian 6
Intel Core i7 3930K (6 x 3,20 GHz)
RAM 64 GB
3000 GB HD + 256 MB SSD drive (very useful for databases, much faster)

OR (don't laugh)

Mac mini 
2.0GHz quad-core Intel Core i7
8GB memory
2X256GB Solid State Drive

of course we would need to limit this to screened applicants to avoid any spammers/troublemakers

Best Regards
David
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Dave Everitt | 30 Mar 20:29 2012
Picon

Re: dead easy deployment / Camping on the fly

oops - should have put my last reply here... - DaveE

Hello all,
I am opening a separate topic just to brainstorm the idea of a free, simple camping deployment/hosting option.
Now this is not about re-inventing the wheel as heroku already supports camping apps too. So this would be the ground idea:

a) This would be entirely free - no paid plans to upgrade etc.;
b) Eventually users should be able to deploy a camping application by launching something like camping-fly myapp in the command line and it would simply work (through a git push or similar) and make it available live in a custom domain like camping.sh or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am
c) Database fanciness should also be available or at least sqlite/mysql

Suggestion and ideas on how to achieve this are welcome (or professionals with the expertise willing to do a simple project based on this )
servers I can make available for this: 

Debian 6
Intel Core i7 3930K (6 x 3,20 GHz)
RAM 64 GB
3000 GB HD + 256 MB SSD drive (very useful for databases, much faster)

OR (don't laugh)

Mac mini 
2.0GHz quad-core Intel Core i7
8GB memory
2X256GB Solid State Drive

of course we would need to limit this to screened applicants to avoid any spammers/troublemakers

Best Regards
David
_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Isak Andersson | 30 Mar 21:51 2012

Re: dead easy deployment / Camping on the fly

+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
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 31 Mar 00:21 2012

Re: dead easy deployment / Camping on the fly

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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 06:30 2012
Picon

Re: dead easy deployment / Camping on the fly

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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 31 Mar 06:33 2012

Re: dead easy deployment / Camping on the fly

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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 07:08 2012
Picon

Re: dead easy deployment / Camping on the fly

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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 07:10 2012
Picon

Re: dead easy deployment / Camping on the fly

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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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@...
http://rubyforge.org/mailman/listinfo/camping-list
Isak Andersson | 31 Mar 11:22 2012

Re: dead easy deployment / Camping on the fly

Perhaps if this is working in time of the deployment screencast we can showcase this kind of deployment AND unicorn/nginx!
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

david costa <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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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/
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 31 Mar 14:52 2012

Re: dead easy deployment / Camping on the fly

<at> 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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 15:27 2012
Picon

Re: dead easy deployment / Camping on the fly

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:
<at> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 31 Mar 15:43 2012

Re: dead easy deployment / Camping on the fly

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

Jenna

On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:

Thank you :D as soon as the DNS will propagate it should be live.
Some updates: now added the design from camping.io (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:
<at> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 16:29 2012
Picon

Re: dead easy deployment / Camping on the fly

Hello Jenna !

I think that run rack applications the most efficient way seems to be phusion passenger that works with apache and nginx. It might work with other setups but it is not documented.
The other alternative to serve a camping application is to use a standard ruby webserver (thin, unicorn, etc.) and use either apache or nginx as reverse proxy. This should be more resource consuming as you would have both a thin/unicorn instance running and nginx.  The setup of passenger + apache seems to be very easy as you just drop the file with the camping app and it works. It can't really get more easier than this.

The camping file has to be called config.ru http://www.modrails.com/documentation/Users%20guide%20Apache.html#_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:
<at> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Nokan Emiro | 31 Mar 16:44 2012
Picon

Re: dead easy deployment / Camping on the fly

Hi,


I run a few Camping apps in production with Rack's FastCGI handler.
This way it is completely separable from the webserver, which can be
nginx, apache, lighttpd, or anything else that implements the FastCGI
protocol.  On top of that it's more scalable, because you can run these
processes on different machines -- if you feel so.

...just an idea to think about, but better than using reverse proxies.



On Sat, Mar 31, 2012 at 4:29 PM, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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#_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:
<at> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list


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


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 16:51 2012
Picon

Re: dead easy deployment / Camping on the fly

Thanks for this but how would it run for multiple users on the same port (80) like  yourname.camping.io yourname2.camping.io without having nginx or apache as a reverse proxy ? 

On Sat, Mar 31, 2012 at 4:44 PM, Nokan Emiro <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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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#_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:
<at> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Nokan Emiro | 31 Mar 17:24 2012
Picon

Re: dead easy deployment / Camping on the fly

This solution is almost the same as using reverse proxies, but between

the nginx and the Rack/Camping app you don't need HTTP traffic, just
FastCGI.  That means you can save one layer in the application, you
don't need a http server (thin, mongrel, etc.) that point.  Rack is a native
FastCGI speaker.  However this is the only difference, in other ways
it's the same as using reverse proxy.  The webserver (nging) knows
about the virtual hosts, and maps them into host:port pairs, where the
appropriate FastCGI server (the Rack itself) listens for connections.
You can call this "reverse proxying" too if you want, but in this case
there are different protocols on the client side (http) and the server
side (fcgi).


On Sat, Mar 31, 2012 at 4:51 PM, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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#_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:
<at> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 1 Apr 01:24 2012

Re: dead easy deployment / Camping on the fly

Oh whoops! I forgot to press the save button on the dns management page. Should go through now, certainly
within the next hour.

On fastcgi - fastcgi is not a server in itself - you cannot connect to it with a web browser. Like Passenger,
it's a way for a server like nginx or apache to launch and talk to processes which return webpages directly.

The easiest way to run camping apps for many different users would be regular CGI. You might think this as
being terribly slow - but I assure you, if ruby and it's libraries are stored on a fast SSD disk, ruby
launches incredibly quickly - further, the operating system's disk cache creates an in-ram copy of
popular applications and ruby libraries, allowing the more heavily used hosted camping apps to become
even more responsive. CGI certainly not worth ruling out. PHP works like this - loading and recompiling
each of it's source code files for each request, unless special optimisation is done - like facebook's php
to c compiler.

If CGI is too slow or consumes too many resources, there's also a middle ground worth exploring - Unicorn
uses a forking system, which is rather cool because it launches new ruby instances very very quickly -
practically instant. It wouldn't be all that difficult to make a forking server variant which forks on
each request and loads up a user's application, runs it, then closes (or maybe idles out after five
minutes). There are all sorts of interesting ways we could optimise existing server ideas to work very
well with small infrequently used applications on different domains for different fully isolated
users, rather like the ways PHP tends to be hosted which make it so practical for large numbers of users
running infrequently accessed applications.

Sandboxing is also something worth investigating.
Nokan Emiro | 2 Apr 11:08 2012
Picon

Re: dead easy deployment / Camping on the fly

On fastcgi - fastcgi is not a server in itself - you cannot connect to it with a web browser. Like Passenger, it's a way for a server like nginx or apache to launch and talk to processes which return webpages directly.

FastCGI IS a server in itself - you can connect to it, but not with a web browser.  It's because it uses a protocol called fastcgi, not http.  (The easiest way to interact with it is to use the cgi-fcgi command from command line...)  It is not necessary to use the webserver to launch the fcgi processes, they can be configured just to connect to these servers, and you can run them whatever way you want.  (I use simple init scripts for this purpose, but in a specialized hosting environment you must build a launcher for them, that handles new uploads, handles broken scripts (those that die after starting), and this system has to manage with ports associated with users, like in the case of using thin and reverse proxies.)


_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 2 Apr 20:05 2012
Picon

Re: dead easy deployment / Camping on the fly

Yes thanks for this well I am pretty set with nginx + passenger. Once I spent the week end digging into it I am pretty happy and it is the recommended way to deploy by many so I will trust this setup for now. I like this more than moving parts with reverse proxies and since it will end up to me to manage this I want to keep it simple as time is scarce ;)



On Mon, Apr 2, 2012 at 11:08 AM, Nokan Emiro <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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Isak Andersson | 31 Mar 17:36 2012

Re: dead easy deployment / Camping on the fly

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:
<at> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list


_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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/
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 18:11 2012
Picon

Re: dead easy deployment / Camping on the fly

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 1 Apr 01:32 2012

Re: dead easy deployment / Camping on the fly

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

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

Jenna

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

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 1 Apr 01:30 2012

Re: dead easy deployment / Camping on the fly

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

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

Jenna

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

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson <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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 1 Apr 09:51 2012
Picon

Re: dead easy deployment / Camping on the fly

Okay :D after many many hours of testing I am settled for nginx and passenger.


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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 1 Apr 10:03 2012
Picon

Re: dead easy deployment / Camping on the fly

Ah I forgot

you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Peter Retief | 1 Apr 10:23 2012
Picon

Re: dead easy deployment / Camping on the fly

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

On 1 April 2012 10:03, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list <at> rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 1 Apr 10:41 2012
Picon

Re: dead easy deployment / Camping on the fly

Umh I doubt it was already here

but is far from an automated, one line /one upload system


On Sun, Apr 1, 2012 at 10:23 AM, Peter Retief <peterretief-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Wonder if Google might help getting camping to run on app engine?


On 1 April 2012 10:03, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 1 Apr 11:13 2012

Re: dead easy deployment / Camping on the fly

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

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

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

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

Jenna

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

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

On 1 April 2012 10:03, david costa <gurugeekphp <at> gmail.com> wrote:
Ah I forgot
you can compare camping running on thin here
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.

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 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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Isak Andersson | 1 Apr 12:25 2012

Re: dead easy deployment / Camping on the fly

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

Jenna Fox <a <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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 1 Apr 12:28 2012

Re: dead easy deployment / Camping on the fly

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

Jenna

On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote:

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

Jenna Fox <a <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
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.

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 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

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Isak Andersson | 1 Apr 13:31 2012

Re: dead easy deployment / Camping on the fly

Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it?

Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt).
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Jenna Fox <a <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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

Download de gratis Registry Scan om het problem te vinden!
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 1 Apr 13:49 2012

Re: dead easy deployment / Camping on the fly

<at> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

Download de gratis Registry Scan om het problem te vinden!
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Isak Andersson | 1 Apr 14:38 2012

Re: dead easy deployment / Camping on the fly

Okay then. But then we'd make sure that the applications don't have privilege to install gems then.
--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Jenna Fox <a <at> creativepony.com> skrev:
<at> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list



_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

Download de gratis Registry Scan om het problem te vinden!
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 1 Apr 17:49 2012
Picon

Re: dead easy deployment / Camping on the fly

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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:
<at> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 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

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

Download de gratis Registry Scan om het problem te vinden!
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Dave Everitt | 1 Apr 19:38 2012
Picon

Re: dead easy deployment / Camping on the fly

A bit late in the day, but (quick and probably uninformed thought, given the volume of messages I just skimmed) might rvm help manage Ruby installs/updates/gems safely? - DaveE

Hello again ! :)
well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide !
The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :)

Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails  running with lighthtp  and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably.

I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery.

I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/
Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated.

Thanks
David


On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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:
<at> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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@...
http://rubyforge.org/mailman/listinfo/camping-list
Jenna Fox | 2 Apr 01:02 2012

Re: dead easy deployment / Camping on the fly

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

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

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

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

Jenna

On Monday, 2 April 2012 at 1:49 AM, david costa wrote:

Hello again ! :)
well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide !
The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :)

Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails  running with lighthtp  and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably.

I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery.

I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/
Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated.

Thanks
David


On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson <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:
<at> 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
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.

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 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

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing 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 mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
adam moore | 2 Apr 02:46 2012
Picon

Re: dead easy deployment / Camping on the fly

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:
<at> 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


--
----=^.^=---
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 2 Apr 03:47 2012
Picon

Re: dead easy deployment / Camping on the fly

Hi Adam :)

On Mon, Apr 2, 2012 at 2:46 AM, adam moore <nerdfunk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I have no idea but could something like ZeroVM be useful?

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 
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.io simple 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 !



 
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 2 Apr 03:40 2012
Picon

Re: dead easy deployment / Camping on the fly

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
 

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Dave Everitt | 2 Apr 11:50 2012
Picon

Re: dead easy deployment / Camping on the fly

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.

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Dave Everitt | 2 Apr 16:07 2012
Picon

Re: dead easy deployment / Camping on the fly

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.

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 2 Apr 20:06 2012
Picon

Re: dead easy deployment / Camping on the fly


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 :)

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Nokan Emiro | 2 Apr 10:45 2012
Picon

Re: dead easy deployment / Camping on the fly

Hi,


As I already mentioned I use Camping with fcgi in production.  If It is
your choice (and not passenger), I will help you set it up.



On Sun, Apr 1, 2012 at 5:49 PM, david costa <gurugeekphp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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:
<at> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 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

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

Download de gratis Registry Scan om het problem te vinden!
http://click.lavabit.com/rw5tyo3eorrquenu8grcd66hq8fc98mwz7k4ago4cu5mtkkiz5ry/
_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Dave Everitt | 4 Apr 01:00 2012
Picon

Re: dead easy deployment / Camping on the fly

Been trying the setup (okay, this is not going to win any awards,  
but...):

http://dave.camping.sh/

It's an old app rewritten (except - as yet - for the content :-)

DaveE
Nokan Emiro | 2 Apr 10:56 2012
Picon

Re: dead easy deployment / Camping on the fly

I really want to know what gems do you (all out there) think quality...

Maybe there's a statistics from a big gem server which ones are the most wanted.

What about the versions?  Applications can work differently (or not work :- ) with
different versions of gems (and ruby).

Will the hosting server allow to open connections to other hosts for the uploaded apps?
It is also dangerous like backtick/system calls.  But if it's banned, lots of gems are excluded.


2012/4/1 Isak Andersson <IcePapih-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org>
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Ah I forgot
you can compare camping running on thin here
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Okay :D after many many hours of testing I am settled for nginx and passenger.

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-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> 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 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

Scarica Subito la Musica pi Trendy sul Tuo Telefonino
http://click.lavabit.com/5rkybqcja4sfq3yz5tg58bmemuictja3cuf8pm4uuqumaedpg6my/
_______________________________________________
Camping-list mailing list

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

_______________________________________________
Camping-list mailing list
Camping-list-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/camping-list

_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
Dave Everitt | 2 Apr 11:42 2012
Picon

Re: dead easy deployment / Camping on the fly

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
_______________________________________________
Camping-list mailing list
Camping-list@...
http://rubyforge.org/mailman/listinfo/camping-list
david costa | 31 Mar 07:06 2012
Picon

Re: dead easy deployment / Camping on the fly

Here is my progress on the server :)

Spent several hours to try to work on a nginx + passenger setup on the cloud even using some pre-made ami with no success. It was also fairly slow vs. a real server (even on an XLarge instance).

So I went back to one spare brand new mac mini server quadcore i7 and I did install passenger on apache 2 without any major problem.  All is fine and camping runs well pretty much on the fly by simply uploading your camping file in the relevant directory (which is pretty much what I wanted to achieve!)

the sample fine (very rough I know) runs fine on the preview at http://bash.is/ :)

Some small things you might have some ideas for:
-On Passenger apparently camping runs without issues as config.ru (camping code on the config.ru file directly) 
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-GrnCvJ7WPxnNLxjTenLetw@public.gmane.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@...
http://rubyforge.org/mailman/listinfo/camping-list

Gmane