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 <[email protected]> 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 <[email protected]>wrote: > >> Hello Jenna ! >> I think that run rack applications the most efficient way seems to be >> phusion passenger that works with apache and nginx. It might work with >> other setups but it is not documented. >> The other alternative to serve a camping application is to use a standard >> ruby webserver (thin, unicorn, etc.) and use either apache or nginx as >> reverse proxy. This should be more resource consuming as you would have >> both a thin/unicorn instance running and nginx. The setup of passenger + >> apache seems to be very easy as you just drop the file with the camping app >> and it works. It can't really get more easier than this. >> >> The camping file has to be called config.ru >> http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand >> this is the only way it works on my tests but I am sure that there is >> an easy way to work with several files or in a different way. >> >> Now if we want to use webdav apache has the module and with a digest >> authentication over ssl should be fairly secure. It also allows to limit >> the upload file size which could be useful (e.g. if someone is obviously >> trying to upload not a camping file !). >> >> This is what I found so far as a possible solution but I am open to >> anything. I did try also an image that was using git/capistrano for remote >> deployment but somehow seemed an overkill to me and it didn't really work. >> All I am doing is highly experimental so I am more than happy to see other >> idea/possibilities and see how far I can go with it. >> >> I did think about webdav based on your idea which I think would make this >> different than heroku etc. like some beginners would not know git and might >> just like a little tent for their shiny camping app ! >> >> David >> >> >> >> >> On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox <[email protected]> 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 <[email protected]> wrote: >>> >>> @David - sorted, both those subdomains now point to your machine. :) >>> >>> — >>> Jenna >>> >>> On Saturday, 31 March 2012 at 4:10 PM, david costa wrote: >>> >>> BTW if you want to point a run.camping.io or host.camping.io or >>> anything you like to 66.116.108.12 will then be able to show an >>> (hopefully) working demo using the official domain ;) >>> >>> On Sat, Mar 31, 2012 at 7:08 AM, david costa <[email protected]>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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >>> >>> >>> _______________________________________________ >>> Camping-list mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/camping-list >>> >> >> >> _______________________________________________ >> Camping-list mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > _______________________________________________ > Camping-list mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/camping-list >
_______________________________________________ Camping-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/camping-list
