Re: updates regarding hosting/easy deployment

[gurugeek]

Hi Isak,
sure - if there is anything I need to install I will be happy to do so. :)

On Sun, Aug 12, 2012 at 5:18 PM, Isak Andersson wrote:

> **
> Very exciting :) And nice!
>
> Would also be sweet if you added early support for what Magnus has been
> working on when that's ready to ship!
>
> On Sun, 12 Aug 2012 17:09:17 +0200, gurugeek 
> wrote:
>
> Hello Everyone,
> sorry for the longish silence but as you know sometimes it can be busy at
> work!
> I just wanted to let you know about a complete update on the free hosting
> system I did prepare from camping. The github idea was not that bad but it
> didn't work in many cases (too many!) and did not give enough control to
> the users.
>
> So I am testing a completely rebuild system with these currently working
> features:
>
> - SFTP access to users: no more github madeness and total control over
> your files. It is as drop and run as it can get;
> - MySQL available to all users - it is popular so regardless of other
> cutting edge possibilities I think it is an important add-on
> - Fairly secure environment: users can't read other users files (which
> seems like a no brainer but it is not possible to do or at least not easily
> with nginx so we are using apache with a worker that runs everything as the
> owner of the file)
> - Ruby and PHP side by side? yes! see
> http://testme.2.ai  camping app
> http://testme.2.ai/i.php
> This is a quick test regarding permissions e.g. this user cannot open via
> PHP or Ruby another user file
> http://testme.2.ai/testperms.php
>
> It also works with other rack frameworks like Sinatra http://dotgeek.2.ai
>
> So in short it supports secure Ruby (Camping, Sinatra, even ROR but not
> fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;)
>
> What do you think ? Would you be interested in testing the system ?  Do
> you think it could be interesting to users as an alternative to heroku etc
> ?I will soon move the domain 1.ai to the new system so that you can test.
> Initially I plan to add a key of some sort to make it by invitation only or
> sort of for the alpha stage.
>
> Thanks in advance for your feedback!
> David
>  Free Scan Can Radically Speed Up Your PC. Make It Run Like New
>
> http://click.lavabit.com/f1igcwdkj34nx4hjiyz9bbgzdt3rtdms1mm3skx6yc9zexte9fay/
>
>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: updates regarding hosting/easy deployment

[gurugeek]

Thanks a lot for the availability. Well obviously it would be no
competition to Heroku :) but it would be a simple SFTP hosting working with
both Ruby and PHP side by side (if one wishes to do so!)  and MySQL
support. It will also be entirely free with very flexible quotes so a
completely different thing than a commercial services.

I will email you privately in a few days once all is up and ready :)

On Mon, Aug 13, 2012 at 3:29 PM, Dave Everitt wrote:

> Hi David
>
> just a quick reply, because I've been off the Camping case for various
> reasons (work, health), but still following... this is great news!
>
> An 'alternative to Heroku' is pretty ambitious, but since many (most?)
> people don't need anything like the full array of Heroku features (or news
> updates!) it's a viable 'lite' alternative. Yes, I'd be interested in
> testing.
>
> Dave
>
>
>  Hello Everyone,
>> sorry for the longish silence but as you know sometimes it can be busy at
>> work!
>> I just wanted to let you know about a complete update on the free hosting
>> system I did prepare from camping. The github idea was not that bad but it
>> didn't work in many cases (too many!) and did not give enough control to
>> the users.
>>
>> So I am testing a completely rebuild system with these currently working
>> features:
>>
>> - SFTP access to users: no more github madeness and total control over
>> your files. It is as drop and run as it can get;
>> - MySQL available to all users - it is popular so regardless of other
>> cutting edge possibilities I think it is an important add-on
>> - Fairly secure environment: users can't read other users files (which
>> seems like a no brainer but it is not possible to do or at least not easily
>> with nginx so we are using apache with a worker that runs everything as the
>> owner of the file)
>> - Ruby and PHP side by side? yes! see
>> http://testme.2.ai  camping app
>> http://testme.2.ai/i.php
>> This is a quick test regarding permissions e.g. this user cannot open via
>> PHP or Ruby another user file
>> http://testme.2.ai/testperms.**php 
>>
>> It also works with other rack frameworks like Sinatra http://dotgeek.2.ai
>>
>> So in short it supports secure Ruby (Camping, Sinatra, even ROR but not
>> fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;)
>>
>> What do you think ? Would you be interested in testing the system ?  Do
>> you think it could be interesting to users as an alternative to heroku etc
>> ?I will soon move the domain 1.ai to the new system so that you can
>> test. Initially I plan to add a key of some sort to make it by invitation
>> only or sort of for the alpha stage.
>>
>> Thanks in advance for your feedback!
>> David
>>
>>
>>
>>
>> __**_
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/**listinfo/camping-list
>>
>
> __**_
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/**listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: updates regarding hosting/easy deployment

[Dave Everitt]

Hi David

just a quick reply, because I've been off the Camping case for various  
reasons (work, health), but still following... this is great news!


An 'alternative to Heroku' is pretty ambitious, but since many (most?)  
people don't need anything like the full array of Heroku features (or  
news updates!) it's a viable 'lite' alternative. Yes, I'd be  
interested in testing.


Dave


Hello Everyone,
sorry for the longish silence but as you know sometimes it can be  
busy at work!
I just wanted to let you know about a complete update on the free  
hosting system I did prepare from camping. The github idea was not  
that bad but it didn't work in many cases (too many!) and did not  
give enough control to the users.


So I am testing a completely rebuild system with these currently  
working features:


- SFTP access to users: no more github madeness and total control  
over your files. It is as drop and run as it can get;
- MySQL available to all users - it is popular so regardless of  
other cutting edge possibilities I think it is an important add-on
- Fairly secure environment: users can't read other users files  
(which seems like a no brainer but it is not possible to do or at  
least not easily with nginx so we are using apache with a worker  
that runs everything as the owner of the file)

- Ruby and PHP side by side? yes! see
http://testme.2.ai  camping app
http://testme.2.ai/i.php
This is a quick test regarding permissions e.g. this user cannot  
open via PHP or Ruby another user file

http://testme.2.ai/testperms.php

It also works with other rack frameworks like Sinatra http://dotgeek.2.ai

So in short it supports secure Ruby (Camping, Sinatra, even ROR but  
not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;)


What do you think ? Would you be interested in testing the system ?   
Do you think it could be interesting to users as an alternative to  
heroku etc ?I will soon move the domain 1.ai to the new system so  
that you can test. Initially I plan to add a key of some sort to  
make it by invitation only or sort of for the alpha stage.


Thanks in advance for your feedback!
David




___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

updates regarding hosting/easy deployment

[gurugeek]

Hello Everyone,
sorry for the longish silence but as you know sometimes it can be busy at work!
I just wanted to let you know about a complete update on the free hosting 
system I did prepare from camping. The github idea was not that bad but it 
didn't work in many cases (too many!) and did not give enough control to the 
users.

So I am testing a completely rebuild system with these currently working 
features:

- SFTP access to users: no more github madeness and total control over your 
files. It is as drop and run as it can get;
- MySQL available to all users - it is popular so regardless of other cutting 
edge possibilities I think it is an important add-on
- Fairly secure environment: users can't read other users files (which seems 
like a no brainer but it is not possible to do or at least not easily with 
nginx so we are using apache with a worker that runs everything as the owner of 
the file)
- Ruby and PHP side by side? yes! see 
http://testme.2.ai  camping app
http://testme.2.ai/i.php  
This is a quick test regarding permissions e.g. this user cannot open via PHP 
or Ruby another user file
http://testme.2.ai/testperms.php

It also works with other rack frameworks like Sinatra http://dotgeek.2.ai

So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully 
tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) 

What do you think ? Would you be interested in testing the system ?  Do you 
think it could be interesting to users as an alternative to heroku etc ?I will 
soon move the domain 1.ai to the new system so that you can test. Initially I 
plan to add a key of some sort to make it by invitation only or sort of for the 
alpha stage.

Thanks in advance for your feedback!
David




___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: updates regarding hosting/easy deployment

[Isak Andersson]

Very exciting :) And nice!Would also be sweet if you added early support for what Magnus has been working on when that's ready to ship!On Sun, 12 Aug 2012 17:09:17 +0200, gurugeek  wrote:Hello Everyone,sorry for the longish silence but as you know sometimes it can be busy at work!
I just wanted to let you know about a complete update on the free hosting system I did prepare from camping. The github idea was not that bad but it didn't work in many cases (too many!) and did not give enough control to the users.
So I am testing a completely rebuild system with these currently working features:
- SFTP access to users: no more github madeness and total control over your files. It is as drop and run as it can get;
- MySQL available to all users - it is popular so regardless of other cutting edge possibilities I think it is an important add-on
- Fairly secure environment: users can't read other users files (which seems like a no brainer but it is not possible to do or at least not easily with nginx so we are using apache with a worker that runs everything as the owner of the file)
- Ruby and PHP side by side? yes! see http://testme.2.ai  camping app
http://testme.2.ai/i.php  
This is a quick test regarding permissions e.g. this user cannot open via PHP or Ruby another user file
http://testme.2.ai/testperms.php
It also works with other rack frameworks like Sinatra http://dotgeek.2.ai
So in short it supports secure Ruby (Camping, Sinatra, even ROR but not fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;) 
What do you think ? Would you be interested in testing the system ?  Do you think it could be interesting to users as an alternative to heroku etc ?I will soon move the domain 1.ai to the new system so that you can test. Initially I plan to add a key of some sort to make it by invitation only or sort of for the alpha stage.
Thanks in advance for your feedback!
David

	Free Scan Can Radically Speed Up Your PC. Make It Run Like New 
	http://click.lavabit.com/f1igcwdkj34nx4hjiyz9bbgzdt3rtdms1mm3skx6yc9zexte9fay/


-- Using Opera's revolutionary email client: http://www.opera.com/mail/___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

updates regarding hosting/easy deployment

[gurugeek]

Hello Everyone,
sorry for the longish silence but as you know sometimes it can be busy at
work!
I just wanted to let you know about a complete update on the free hosting
system I did prepare from camping. The github idea was not that bad but it
didn't work in many cases (too many!) and did not give enough control to
the users.

So I am testing a completely rebuild system with these currently working
features:

- SFTP access to users: no more github madeness and total control over your
files. It is as drop and run as it can get;
- MySQL available to all users - it is popular so regardless of other
cutting edge possibilities I think it is an important add-on
- Fairly secure environment: users can't read other users files (which
seems like a no brainer but it is not possible to do or at least not easily
with nginx so we are using apache with a worker that runs everything as the
owner of the file)
- Ruby and PHP side by side? yes! see
http://testme.2.ai  camping app
http://testme.2.ai/i.php
This is a quick test regarding permissions e.g. this user cannot open via
PHP or Ruby another user file
http://testme.2.ai/testperms.php

It also works with other rack frameworks like Sinatra http://dotgeek.2.ai

So in short it supports secure Ruby (Camping, Sinatra, even ROR but not
fully tested) and PHP hosting with MySQL, Sqlite or Kirbybase ;)

What do you think ? Would you be interested in testing the system ?  Do you
think it could be interesting to users as an alternative to heroku etc ?I
will soon move the domain 1.ai to the new system so that you can test.
Initially I plan to add a key of some sort to make it by invitation only or
sort of for the alpha stage.

Thanks in advance for your feedback!
David
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Dave Everitt]

Just a note - to see changes to your app on reload you'll need a 'tmp'  
directory in the app's dir containing a blank text file  
'always_restart.txt':


www/tmp/always_restart.txt

DaveE



Hello Campers!
I am happy to announce that the camping 1 click deployment is now  
available at http://1.ai


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Jenna Fox]

We'd need a syntax highlighting gem on the server, but it should be easy enough 
to construct such a snippet otherwise  

—
Jenna


On Wednesday, 9 May 2012 at 8:14 PM, Dave Everitt wrote:

> > View Source link for open web apps and demos.
>  
>  
> I just added a link to the github repo on my links app, but if you  
> have a snippet to display an app's code in formatted and syntax-  
> coloured style...
>  
> > > The idea is to get people to learn and use camping and deploy it /  
> > > see their app live immediately. It should be a good learning tool...
> > >  
> >  
>  
>  
>  
> and you've done that job rather well :-)
>  
> DaveE
>  
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Dave Everitt]

So if my SQLite db file is also in my repo and the path to it is in  
my app, sounds like the whole lot will transfer fine - DaveE


It should :) If you want to test it I will be grateful.


marking web design classes this week(!), so when I take a break I'll  
try it out with the blog app after using it locally then transferring  
to the server with the db file, and let you know...


Fixing ATM some issues with installing extra gems so trying to find  
a clever solution to make most app run without intervention.



be good to have a list of available gems (unless you already did that!)

Dave

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Dave Everitt]

View Source link for open web apps and demos.


I just added a link to the github repo on my links app, but if you  
have a snippet to display an app's code in formatted and syntax- 
coloured style...


The idea is to get people to learn and use camping and deploy it / 
see their app live immediately. It should be a good learning tool...



and you've done that job rather well :-)

DaveE

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Jenna Fox]

Heroku are the big tires, camping is the little wheels. They aren't a great 
fit. Heroku for example has a read-only file system and I believe no database 
in the free tier.  

This is a great little service we can build interesting things on. How about a 
remote server reloader? Streaming logs? Push notification stream server? View 
Source link for open web apps and demos.   

—
Jenna Fox


On Wednesday, 9 May 2012 at 1:30 PM, gurugeek wrote:

>  
> On May 8, 2012, at 4:04 PM, Anthony Durity wrote:
> > What are the limitations?
>  
>  
> I forgot to add these important limitations:
> - Presently No DB Support beside sqlite and couchdb if you use it via 
> iriscouch or a similar service;
> - No professional support - so it is free but beside some help that I am 
> willing to give to make sure that the service runs properly it cannot be 
> compared with a professional service where you pay hence you can expect 
> support
>  
>  
> In terms of benefits thou the app should run considerably faster than on the 
> free tier of heroku because of the non-virtualization and the SSD hard drives 
> - in my tests sqlite and all in general ix x 5 times than in a traditional HD 
> or on EC2.
>  
> The idea is to get people to learn and use camping and deploy it /see their 
> app live immediately. It should be a good learning tool but not to run a 
> professional application with clients etc. or where you expect a lot of 
> support.
>  
>  
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[gurugeek]

On May 8, 2012, at 4:04 PM, Anthony Durity wrote:
> What are the limitations?

I forgot to add these important limitations:
- Presently No DB Support beside sqlite and couchdb if you use it via iriscouch 
or a similar service;
- No professional support - so it is free but beside some help that I am 
willing to give to make sure that the service runs properly it cannot be 
compared with a professional service where you pay hence you can expect support


In terms of benefits thou the app should run considerably faster than on the 
free tier of heroku because of the non-virtualization and the SSD hard drives - 
in my tests sqlite and all in general ix x 5 times than in a traditional HD or 
on EC2.

The idea is to get people to learn and use camping and deploy it /see their app 
live immediately. It should be a good learning tool but not to run a 
professional application with clients etc. or where you expect a lot of support.


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[gurugeek]

On May 8, 2012, at 4:04 PM, Anthony Durity wrote:

> Is this like Heroku or something?

My understanding is that Heroku uses a different system for what I gather 
mostly virtualized. This is a running on a traditional physical dedicated 
server. 

> What are the use cases for this?
> It's an app server?

My idea of the use was to be able to deploy a camping app directly from the 
code in github. So once you have it in github you don't need to push it to 
another git (as I think it is the case on heroku) but just fetch and run it 
from the admin. 

> What are the limitations?
> How much does it cost?
There are some soft limitations on memory usage - mostly to avoid abuse and not 
to slow down the app - it is entirely free. 

> If it is free, why is it free?

why not? :)

> 

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Dave Everitt]

So if my SQLite db file is also in my repo and the path to it is in my  
app, sounds like the whole lot will transfer fine - DaveE


-If you have an sqlite database in your github repository it should  
work just fine. If it works for you locally it should work fine on http://1.ai 
 after the github fetch


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Anthony Durity]

Is this like Heroku or something? What are the use cases for this? It's an
app server? What are the limitations? How much does it cost? If it is free,
why is it free?

On Sun, May 6, 2012 at 1:57 AM, gurugeek <1...@1.ai> wrote:

> Hello Campers!
> I am happy to announce that the camping 1 click deployment is now
> available at http://1.ai
> The platform has been coded with camping (with some help from bash for the
> backend scripts) and it seems to work very well.
>
> We have spent some time to get sure that it would be secure and easy to
> use. After working on an easy and secure way to upload/manage files online
> etc. we have found an easier solution: fetch a github repository with a
> camping application and - with one click -deploy it online at
> yourname.1.ai
>
> So how does this works ?
> 1 - you signup
> 2 - after logging in you simply fetch your camping application from a
> github repository there is a sample hello world available at
> https://github.com/gurugeek/0ai and this is also explained in the app
> admin page
> 3 - after fetching (provided that this is a valid camping app and has a
> valid config.ru file) your application will be live.
>
> The admin panel has all these instructions and if you try to fetch a
> non-camping application from a github repository it will return the
> relevant error.
>
> The system supports private repositories too (this said I wouldn't run
> something very secret and private on it!) but you would need to authorise
> the github user 1ai to access your private repository.
>
> Github has a lot of wonderful features so I feel that this was the best
> solution without re-inventing the wheel. It is probably the fastest and
> easiest way to get your camping application up and running.
>
> Each application is securely isolated but all this is running in a
> traditional dedicated server (no virtual/cloud/droids) are employed. This
> should enhance the application performance. The server is also using only
> SSD (solid state drivers) that are not yet available in most of cloud
> providers (EC2, Rackspace cloud).
>
> I really appreciate your testing and comments so please go on and launch
> your shiny Camping app at
> http://1.ai  !
>
> A small caveat: The aim of this service is (hopefully) to promote camping
> (perhaps next with a programming contest with some cool prizes) but it is
> obviously not meant to replace a traditional hosting in the sense that
> there will be no tech support offered and the service is provided without
> any warranty. This doesn't mean that is not good enough to run any of your
> fancy Camping apps - just that you should not expect this to replace any
> professional hosting.
>
> Note on Databases:
> -If you have an sqlite database in your github repository it should work
> just fine. If it works for you locally it should work fine on http://1.ai 
> after
> the github fetch
> -If you want to use CouchDB you can do it with the wonderful Chill (
> https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is
> free for small apps/usage). Once you have your CouchDB on iriscouch you
> simply connect to it from your camping app, fetch the data etc.
>
>
> I do look forward to your comments and welcome any question you might have!
> Best Regards
> David
>
>
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[gurugeek]

Actually I did miss the fact that you had a capital B on the repo so anyway it 
works now in the sense that it fetches the script and shows the ruby include 
errors on the screen... will install the gems tomorrow and see if all works 
fine !

On May 7, 2012, at 2:49 AM, Jenna Fox wrote:

> A lot of repos for websites have dots in them, should fix it to support 
> anything github can support.
> 
> —
> Jenna
> 
> On Monday, 7 May 2012 at 10:30 AM, gurugeek wrote:
> 
>> 
>> On May 7, 2012, at 2:23 AM, Jenna Fox wrote:
>> 
>>> Things:
>>> 1) It'd be super cool if the user types in their email address as the 
>>> username if it still works
>> 
>> Yes this should be easy to do  - could put both I think email or username
>> 
>>> 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com in 
>>> the github repo name and it says my url contains invalid characters?
>>> 
>> 
>> I think the check in the script doesn't allow a repository to have a points 
>> inside it ..is it very common ? Can fix this but if you want to try in the 
>> interim just use any repo without a . on it :)
>> Thanks again for testing this out
>> David
>> 
>> 
>>> —
>>> Jenna
>>> 
>>> On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote:
>>> 
>>>> Hello Campers!
>>>> I am happy to announce that the camping 1 click deployment is now 
>>>> available at http://1.ai
>>>> The platform has been coded with camping (with some help from bash for the 
>>>> backend scripts) and it seems to work very well. 
>>>> 
>>>> We have spent some time to get sure that it would be secure and easy to 
>>>> use. After working on an easy and secure way to upload/manage files online 
>>>> etc. we have found an easier solution: fetch a github repository with a 
>>>> camping application and - with one click -deploy it online at yourname.1.ai
>>>> 
>>>> So how does this works ?
>>>> 1 - you signup 
>>>> 2 - after logging in you simply fetch your camping application from a 
>>>> github repository there is a sample hello world available at 
>>>> https://github.com/gurugeek/0ai and this is also explained in the app 
>>>> admin page
>>>> 3 - after fetching (provided that this is a valid camping app and has a 
>>>> valid config.ru file) your application will be live.
>>>> 
>>>> The admin panel has all these instructions and if you try to fetch a 
>>>> non-camping application from a github repository it will return the 
>>>> relevant error. 
>>>> 
>>>> The system supports private repositories too (this said I wouldn't run 
>>>> something very secret and private on it!) but you would need to authorise 
>>>> the github user 1ai to access your private repository.
>>>> 
>>>> Github has a lot of wonderful features so I feel that this was the best 
>>>> solution without re-inventing the wheel. It is probably the fastest and 
>>>> easiest way to get your camping application up and running. 
>>>> 
>>>> Each application is securely isolated but all this is running in a 
>>>> traditional dedicated server (no virtual/cloud/droids) are employed. This 
>>>> should enhance the application performance. The server is also using only 
>>>> SSD (solid state drivers) that are not yet available in most of cloud 
>>>> providers (EC2, Rackspace cloud). 
>>>> 
>>>> I really appreciate your testing and comments so please go on and launch 
>>>> your shiny Camping app at
>>>> http://1.ai  !
>>>> 
>>>> A small caveat: The aim of this service is (hopefully) to promote camping 
>>>> (perhaps next with a programming contest with some cool prizes) but it is 
>>>> obviously not meant to replace a traditional hosting in the sense that 
>>>> there will be no tech support offered and the service is provided without 
>>>> any warranty. This doesn't mean that is not good enough to run any of your 
>>>> fancy Camping apps - just that you should not expect this to replace any 
>>>> professional hosting. 
>>>> 
>>>> Note on Databases:
>>>> -If you have an sqlite database in your github repository it should work 
>>>> just fine. If it works for you locally it should work fine on http://1.ai 
>>>> after the github fetch
>>>> -If y

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[gurugeek]

Fixed the validation but I am having a weird error in fetching from your repo:

odin install https://github.com/bluebie/whywentcamping.com.git
fatal: https://github.com/bluebie/whywentcamping.com.git/info/refs not found: 
did you run git update-server-info on the server?
Cloning of https://github.com/bluebie/whywentcamping.com.git failed

Now I forked your repo on a dummy github account (1ai) 
and it doesn't give me this error. 

Yet it won't run because the config.ru file is not as per example and has a 
number of non working requires

from /var/www/config.ru:5
from /opt/lib/ruby/gems/1.8/gems/rack-1.4.1/lib/rack/builder.rb:51:in 
`instance_eval'
from /opt/lib/ruby/gems/1.8/gems/rack-1.4.1/lib/rack/builder.rb:51:in 
`initialize'
from /var/www/config.ru:1:in `new'
from /var/www/config.ru:1

I have fixed that (with a new config file 
https://github.com/1ai/whywentcamping.com/blob/master/config.ru) but there are 
a lot of gems not installed for users by default:

require 'rubygems'
require 'camping'
require 'fileutils'
require 'open-uri'
require 'syntax/convertors/html'
require 'RedCloth'
require 'rdiscount'

which of course I can add but at the moment I have made it that each jail has 
the camping-omnibus and associated libs. Are these typically needed by all 
users? Will install these tomorrow and see if it runs fine.
Regards
David


On May 7, 2012, at 2:49 AM, Jenna Fox wrote:

> A lot of repos for websites have dots in them, should fix it to support 
> anything github can support.
> 
> —
> Jenna
> 
> On Monday, 7 May 2012 at 10:30 AM, gurugeek wrote:
> 
>> 
>> On May 7, 2012, at 2:23 AM, Jenna Fox wrote:
>> 
>>> Things:
>>> 1) It'd be super cool if the user types in their email address as the 
>>> username if it still works
>> 
>> Yes this should be easy to do  - could put both I think email or username
>> 
>>> 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com in 
>>> the github repo name and it says my url contains invalid characters?
>>> 
>> 
>> I think the check in the script doesn't allow a repository to have a points 
>> inside it ..is it very common ? Can fix this but if you want to try in the 
>> interim just use any repo without a . on it :)
>> Thanks again for testing this out
>> David
>> 
>> 
>>> —
>>> Jenna
>>> 
>>> On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote:
>>> 
>>>> Hello Campers!
>>>> I am happy to announce that the camping 1 click deployment is now 
>>>> available at http://1.ai
>>>> The platform has been coded with camping (with some help from bash for the 
>>>> backend scripts) and it seems to work very well. 
>>>> 
>>>> We have spent some time to get sure that it would be secure and easy to 
>>>> use. After working on an easy and secure way to upload/manage files online 
>>>> etc. we have found an easier solution: fetch a github repository with a 
>>>> camping application and - with one click -deploy it online at yourname.1.ai
>>>> 
>>>> So how does this works ?
>>>> 1 - you signup 
>>>> 2 - after logging in you simply fetch your camping application from a 
>>>> github repository there is a sample hello world available at 
>>>> https://github.com/gurugeek/0ai and this is also explained in the app 
>>>> admin page
>>>> 3 - after fetching (provided that this is a valid camping app and has a 
>>>> valid config.ru file) your application will be live.
>>>> 
>>>> The admin panel has all these instructions and if you try to fetch a 
>>>> non-camping application from a github repository it will return the 
>>>> relevant error. 
>>>> 
>>>> The system supports private repositories too (this said I wouldn't run 
>>>> something very secret and private on it!) but you would need to authorise 
>>>> the github user 1ai to access your private repository.
>>>> 
>>>> Github has a lot of wonderful features so I feel that this was the best 
>>>> solution without re-inventing the wheel. It is probably the fastest and 
>>>> easiest way to get your camping application up and running. 
>>>> 
>>>> Each application is securely isolated but all this is running in a 
>>>> traditional dedicated server (no virtual/cloud/droids) are employed. This 
>>>> should enhance the application performance. The server is also usi

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Jenna Fox]

A lot of repos for websites have dots in them, should fix it to support 
anything github can support.  

—
Jenna


On Monday, 7 May 2012 at 10:30 AM, gurugeek wrote:

>  
> On May 7, 2012, at 2:23 AM, Jenna Fox wrote:
> > Things:
> > 1) It'd be super cool if the user types in their email address as the 
> > username if it still works
> >  
> >  
>  
>  
> Yes this should be easy to do  - could put both I think email or username
> > 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com 
> > (http://whywentcamping.com) in the github repo name and it says my url 
> > contains invalid characters?  
> >  
>  
> I think the check in the script doesn't allow a repository to have a points 
> inside it ..is it very common ? Can fix this but if you want to try in the 
> interim just use any repo without a . on it :)
> Thanks again for testing this out
> David
>  
>  
> > —
> > Jenna
> >  
> >  
> > On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote:
> >  
> > > Hello Campers!
> > > I am happy to announce that the camping 1 click deployment is now 
> > > available at http://1.ai (http://1.ai/)
> > > The platform has been coded with camping (with some help from bash for 
> > > the backend scripts) and it seems to work very well.  
> > >  
> > > We have spent some time to get sure that it would be secure and easy to 
> > > use. After working on an easy and secure way to upload/manage files 
> > > online etc. we have found an easier solution: fetch a github repository 
> > > with a camping application and - with one click -deploy it online at 
> > > yourname.1.ai
> > >  
> > > So how does this works ?
> > > 1 - you signup  
> > > 2 - after logging in you simply fetch your camping application from a 
> > > github repository there is a sample hello world available at 
> > > https://github.com/gurugeek/0ai and this is also explained in the app 
> > > admin page
> > > 3 - after fetching (provided that this is a valid camping app and has a 
> > > valid config.ru (http://config.ru/) file) your application will be live.
> > >  
> > > The admin panel has all these instructions and if you try to fetch a 
> > > non-camping application from a github repository it will return the 
> > > relevant error.  
> > >  
> > > The system supports private repositories too (this said I wouldn't run 
> > > something very secret and private on it!) but you would need to authorise 
> > > the github user 1ai to access your private repository.
> > >  
> > > Github has a lot of wonderful features so I feel that this was the best 
> > > solution without re-inventing the wheel. It is probably the fastest and 
> > > easiest way to get your camping application up and running.  
> > >  
> > > Each application is securely isolated but all this is running in a 
> > > traditional dedicated server (no virtual/cloud/droids) are employed. This 
> > > should enhance the application performance. The server is also using only 
> > > SSD (solid state drivers) that are not yet available in most of cloud 
> > > providers (EC2, Rackspace cloud).  
> > >  
> > > I really appreciate your testing and comments so please go on and launch 
> > > your shiny Camping app at
> > > http://1.ai (http://1.ai/)  !
> > >  
> > > A small caveat: The aim of this service is (hopefully) to promote camping 
> > > (perhaps next with a programming contest with some cool prizes) but it is 
> > > obviously not meant to replace a traditional hosting in the sense that 
> > > there will be no tech support offered and the service is provided without 
> > > any warranty. This doesn't mean that is not good enough to run any of 
> > > your fancy Camping apps - just that you should not expect this to replace 
> > > any professional hosting.  
> > >  
> > > Note on Databases:
> > > -If you have an sqlite database in your github repository it should work 
> > > just fine. If it works for you locally it should work fine on http://1.ai 
> > > (http://1.ai/) after the github fetch
> > > -If you want to use CouchDB you can do it with the wonderful Chill 
> > > (https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which 
> > > is free for small apps/usage). Once you have your CouchDB on iriscouch 
> > > you simply connect to it from your camping app, fetch the data etc.  
> > >  
> >

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[gurugeek]

On May 7, 2012, at 2:23 AM, Jenna Fox wrote:

> Things:
> 1) It'd be super cool if the user types in their email address as the 
> username if it still works

Yes this should be easy to do  - could put both I think email or username

> 2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com in 
> the github repo name and it says my url contains invalid characters?
> 

I think the check in the script doesn't allow a repository to have a points 
inside it ..is it very common ? Can fix this but if you want to try in the 
interim just use any repo without a . on it :)
Thanks again for testing this out
David


> —
> Jenna
> 
> On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote:
> 
>> Hello Campers!
>> I am happy to announce that the camping 1 click deployment is now available 
>> at http://1.ai
>> The platform has been coded with camping (with some help from bash for the 
>> backend scripts) and it seems to work very well. 
>> 
>> We have spent some time to get sure that it would be secure and easy to use. 
>> After working on an easy and secure way to upload/manage files online etc. 
>> we have found an easier solution: fetch a github repository with a camping 
>> application and - with one click -deploy it online at yourname.1.ai
>> 
>> So how does this works ?
>> 1 - you signup 
>> 2 - after logging in you simply fetch your camping application from a github 
>> repository there is a sample hello world available at 
>> https://github.com/gurugeek/0ai and this is also explained in the app admin 
>> page
>> 3 - after fetching (provided that this is a valid camping app and has a 
>> valid config.ru file) your application will be live.
>> 
>> The admin panel has all these instructions and if you try to fetch a 
>> non-camping application from a github repository it will return the relevant 
>> error. 
>> 
>> The system supports private repositories too (this said I wouldn't run 
>> something very secret and private on it!) but you would need to authorise 
>> the github user 1ai to access your private repository.
>> 
>> Github has a lot of wonderful features so I feel that this was the best 
>> solution without re-inventing the wheel. It is probably the fastest and 
>> easiest way to get your camping application up and running. 
>> 
>> Each application is securely isolated but all this is running in a 
>> traditional dedicated server (no virtual/cloud/droids) are employed. This 
>> should enhance the application performance. The server is also using only 
>> SSD (solid state drivers) that are not yet available in most of cloud 
>> providers (EC2, Rackspace cloud). 
>> 
>> I really appreciate your testing and comments so please go on and launch 
>> your shiny Camping app at
>> http://1.ai  !
>> 
>> A small caveat: The aim of this service is (hopefully) to promote camping 
>> (perhaps next with a programming contest with some cool prizes) but it is 
>> obviously not meant to replace a traditional hosting in the sense that there 
>> will be no tech support offered and the service is provided without any 
>> warranty. This doesn't mean that is not good enough to run any of your fancy 
>> Camping apps - just that you should not expect this to replace any 
>> professional hosting. 
>> 
>> Note on Databases:
>> -If you have an sqlite database in your github repository it should work 
>> just fine. If it works for you locally it should work fine on http://1.ai 
>> after the github fetch
>> -If you want to use CouchDB you can do it with the wonderful Chill 
>> (https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is 
>> free for small apps/usage). Once you have your CouchDB on iriscouch you 
>> simply connect to it from your camping app, fetch the data etc. 
>> 
>> 
>> I do look forward to your comments and welcome any question you might have!
>> Best Regards
>> David
>> 
>> 
>> ___
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
> 
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Jenna Fox]

Things:
1) It'd be super cool if the user types in their email address as the username 
if it still works
2) I wonder what I'm doing wrong? I enter in bluebie/whywentcamping.com in the 
github repo name and it says my url contains invalid characters?


—
Jenna


On Sunday, 6 May 2012 at 10:41 AM, gurugeek wrote:

> Hello Campers!
> I am happy to announce that the camping 1 click deployment is now available 
> at http://1.ai (http://1.ai/)
> The platform has been coded with camping (with some help from bash for the 
> backend scripts) and it seems to work very well.  
>  
> We have spent some time to get sure that it would be secure and easy to use. 
> After working on an easy and secure way to upload/manage files online etc. we 
> have found an easier solution: fetch a github repository with a camping 
> application and - with one click -deploy it online at yourname.1.ai
>  
> So how does this works ?
> 1 - you signup  
> 2 - after logging in you simply fetch your camping application from a github 
> repository there is a sample hello world available at 
> https://github.com/gurugeek/0ai and this is also explained in the app admin 
> page
> 3 - after fetching (provided that this is a valid camping app and has a valid 
> config.ru (http://config.ru/) file) your application will be live.
>  
> The admin panel has all these instructions and if you try to fetch a 
> non-camping application from a github repository it will return the relevant 
> error.  
>  
> The system supports private repositories too (this said I wouldn't run 
> something very secret and private on it!) but you would need to authorise the 
> github user 1ai to access your private repository.
>  
> Github has a lot of wonderful features so I feel that this was the best 
> solution without re-inventing the wheel. It is probably the fastest and 
> easiest way to get your camping application up and running.  
>  
> Each application is securely isolated but all this is running in a 
> traditional dedicated server (no virtual/cloud/droids) are employed. This 
> should enhance the application performance. The server is also using only SSD 
> (solid state drivers) that are not yet available in most of cloud providers 
> (EC2, Rackspace cloud).  
>  
> I really appreciate your testing and comments so please go on and launch your 
> shiny Camping app at
> http://1.ai (http://1.ai/)  !
>  
> A small caveat: The aim of this service is (hopefully) to promote camping 
> (perhaps next with a programming contest with some cool prizes) but it is 
> obviously not meant to replace a traditional hosting in the sense that there 
> will be no tech support offered and the service is provided without any 
> warranty. This doesn't mean that is not good enough to run any of your fancy 
> Camping apps - just that you should not expect this to replace any 
> professional hosting.  
>  
> Note on Databases:
> -If you have an sqlite database in your github repository it should work just 
> fine. If it works for you locally it should work fine on http://1.ai 
> (http://1.ai/) after the github fetch
> -If you want to use CouchDB you can do it with the wonderful Chill 
> (https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is 
> free for small apps/usage). Once you have your CouchDB on iriscouch you 
> simply connect to it from your camping app, fetch the data etc.  
>  
>  
> I do look forward to your comments and welcome any question you might have!
> Best Regards
> David
>  
>  
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Isak Andersson]

I won't be able try it until next weekend as I'm going away for a week. But 
this is absolutely amazing, I am thankful and proud that we have this kind of 
service. Thank you David!

Cheers!

Isak Andersson

Dave Everitt  skrev:

no time to try this today, but - as an existing user :-) this is a brilliant 
service, nice work! - DaveE


Hello Campers!
I am happy to announce that the camping 1 click deployment is now available at 
http://1.ai
The platform has been coded with camping (with some help from bash for the 
backend scripts) and it seems to work very well. 

We have spent some time to get sure that it would be secure and easy to use. 
After working on an easy and secure way to upload/manage files online etc. we 
have found an easier solution: fetch a github repository with a camping 
application and - with one click -deploy it online at yourname.1.ai

So how does this works ?
1 - you signup 
2 - after logging in you simply fetch your camping application from a github 
repository there is a sample hello world available at 
https://github.com/gurugeek/0ai and this is also explained in the app admin page
3 - after fetching (provided that this is a valid camping app and has a valid 
config.ru file) your application will be live.

The admin panel has all these instructions and if you try to fetch a 
non-camping application from a github repository it will return the relevant 
error. 

The system supports private repositories too (this said I wouldn't run 
something very secret and private on it!) but you would need to authorise the 
github user 1ai to access your private repository.

Github has a lot of wonderful features so I feel that this was the best 
solution without re-inventing the wheel. It is probably the fastest and easiest 
way to get your camping application up and running. 

Each application is securely isolated but all this is running in a traditional 
dedicated server (no virtual/cloud/droids) are employed. This should enhance 
the application performance. The server is also using only SSD (solid state 
drivers) that are not yet available in most of cloud providers (EC2, Rackspace 
cloud). 

I really appreciate your testing and comments so please go on and launch your 
shiny Camping app at
http://1.ai  !

A small caveat: The aim of this service is (hopefully) to promote camping 
(perhaps next with a programming contest with some cool prizes) but it is 
obviously not meant to replace a traditional hosting in the sense that there 
will be no tech support offered and the service is provided without any 
warranty. This doesn't mean that is not good enough to run any of your fancy 
Camping apps - just that you should not expect this to replace any professional 
hosting. 

Note on Databases:
-If you have an sqlite database in your github repository it should work just 
fine. If it works for you locally it should work fine on http://1.ai after the 
github fetch
-If you want to use CouchDB you can do it with the wonderful Chill 
(https://github.com/Bluebie/chill) and http://www.iriscouch.com/ (which is free 
for small apps/usage). Once you have your CouchDB on iriscouch you simply 
connect to it from your camping app, fetch the data etc. 


I do look forward to your comments and welcome any question you might have!
Best Regards
David


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Get the best selection of safeway job application sites here. Click 
Here to 
check them out!

http://click.lavabit.com/uhoku5c17amadfhg9o4nw4fucgue4d4j5wn6q6uie66maeppqixy/ 

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Camping 1 click deployment is live! 1.ai - alpha users welcome !

[Dave Everitt]

no time to try this today, but - as an existing user :-) this is a  
brilliant service, nice work! - DaveE



Hello Campers!
I am happy to announce that the camping 1 click deployment is now  
available at http://1.ai
The platform has been coded with camping (with some help from bash  
for the backend scripts) and it seems to work very well.


We have spent some time to get sure that it would be secure and easy  
to use. After working on an easy and secure way to upload/manage  
files online etc. we have found an easier solution: fetch a github  
repository with a camping application and - with one click -deploy  
it online at yourname.1.ai


So how does this works ?
1 - you signup
2 - after logging in you simply fetch your camping application from  
a github repository there is a sample hello world available at https://github.com/gurugeek/0ai 
 and this is also explained in the app admin page
3 - after fetching (provided that this is a valid camping app and  
has a valid config.ru file) your application will be live.


The admin panel has all these instructions and if you try to fetch a  
non-camping application from a github repository it will return the  
relevant error.


The system supports private repositories too (this said I wouldn't  
run something very secret and private on it!) but you would need to  
authorise the github user 1ai to access your private repository.


Github has a lot of wonderful features so I feel that this was the  
best solution without re-inventing the wheel. It is probably the  
fastest and easiest way to get your camping application up and  
running.


Each application is securely isolated but all this is running in a  
traditional dedicated server (no virtual/cloud/droids) are employed.  
This should enhance the application performance. The server is also  
using only SSD (solid state drivers) that are not yet available in  
most of cloud providers (EC2, Rackspace cloud).


I really appreciate your testing and comments so please go on and  
launch your shiny Camping app at

http://1.ai  !

A small caveat: The aim of this service is (hopefully) to promote  
camping (perhaps next with a programming contest with some cool  
prizes) but it is obviously not meant to replace a traditional  
hosting in the sense that there will be no tech support offered and  
the service is provided without any warranty. This doesn't mean that  
is not good enough to run any of your fancy Camping apps - just that  
you should not expect this to replace any professional hosting.


Note on Databases:
-If you have an sqlite database in your github repository it should  
work just fine. If it works for you locally it should work fine on http://1.ai 
 after the github fetch
-If you want to use CouchDB you can do it with the wonderful Chill (https://github.com/Bluebie/chill 
) and http://www.iriscouch.com/ (which is free for small apps/ 
usage). Once you have your CouchDB on iriscouch you simply connect  
to it from your camping app, fetch the data etc.



I do look forward to your comments and welcome any question you  
might have!

Best Regards
David


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Dave Everitt]

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

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[Dave Everitt]

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

Re: dead easy deployment / Camping on the fly

[Dave Everitt]

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

Re: dead easy deployment / Camping on the fly

[Dave Everitt]

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

Re: dead easy deployment / Camping on the fly

[Nokan Emiro]

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

Re: dead easy deployment / Camping on the fly

[Nokan Emiro]

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 

> ** 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  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  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  wrote:
>>
>> Ah I forgot
>> you can compare camping running on thin here
>> http://run.camping.io:3301/
>> vs passenger at http://run.camping.io
>>
>> apparently db has some problems with fusion passenger  (see
>> http://run.camping.io create HTML page and test HTML page. The same code
>> on thin works just fine... umhh oh no don't feel like more debugging ):
>>
>>
>>
>> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote:
>>
>> Okay :D after many many hours of testing I am settled for nginx and
>> passenger.
>> live at http://run.camping.io/
>>
>> I did try every apache combination (with passenger, with cgi, etc. etc.)
>> as is simply not really working fine.
>> I tried some other obscure web servers too but apparently this seems to
>> work fine for now :) other servers would run the app as CGI or FastCGI. I
>> am not worried about speed just ease of deployment and nginx with passenger
>> seems to do the job for now. The alternative is nginx as reverse proxy but
>> as Jenna rightly pointed out it would spawn a lot of thin instances that
>> might or might not be used.
>>
>> I did throw the 

Re: dead easy deployment / Camping on the fly

[Nokan Emiro]

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  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 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  skrev:
>>>
>>> @Isak Anything run with the `backticks operator` runs with the same
>>> privileges as the process which launched them, if using system level
>>> sandboxing, or if using some crazy sandbox built in to ruby (which probably
>>> wouldn't be very good, but maybe good enough) it'd probably just disable
>>> backticks feature.
>>>
>>>
>>> On 01/04/2012, at 9:31 PM, Isak Andersson wrote:
>>>
>>> Well. Isn't it kind of possible to just hack the gem installation in
>>> using the ruby quotes that execute code on the system. I can't type them on
>>> the phone but I think you know what I mean. Kind of a security issue isn't
>>> it?
>>>
>>> Anyways. Perhaps we could offer some Gems to pick from that we think are
>>> quality! (rack_csrf, scrypt).
>>> --
>>> Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
>>>
>>> Jenna Fox  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  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

Re: dead easy deployment / Camping on the fly

[david costa]

Hi Adam :)

On Mon, Apr 2, 2012 at 2:46 AM, adam moore  wrote:

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

Re: dead easy deployment / Camping on the fly

[david costa]

On Mon, Apr 2, 2012 at 1:02 AM, 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.
>
> 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 se

Re: dead easy deployment / Camping on the fly

[adam moore]

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 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  skrev:
>
> @Isak Anything run with the `backticks operator` runs with the same
> privileges as the process which launched them, if using system level
> sandboxing, or if using some crazy sandbox built in to ruby (which probably
> wouldn't be very good, but maybe good enough) it'd probably just disable
> backticks feature.
>
>
> On 01/04/2012, at 9:31 PM, Isak Andersson wrote:
>
> Well. Isn't it kind of possible to just hack the gem installation in using
> the ruby quotes that execute code on the system. I can't type them on the
> phone but I think you know what I mean. Kind of a security issue isn't it?
>
> Anyways. Perhaps we could offer some Gems to pick from that we think are
> quality! (rack_csrf, scrypt).
> --
> Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
>
> Jenna Fox  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  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 writabl

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

uch 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 mailto:a...@creativepony.com)> 
> > > > > > skrev:
> > > > > > > Hm. I know the main guy responsible for App Engine, and, well, I 
> > > > > > > certainly wouldn't build a platform atop it - even aside from the 
> > > > > > > huge glaring issue that to have an app which can store data 
> > > > > > > persistently, you need to use google's proprietary database 
> > > > > > > software.
> > > > > > >  
> > > > > > > Heroku doesn't screen against abuse at all. Heroku is not a 
> > > > > > > 'shared hosting' provider. Their systems use the very finest 
> > > > > > > jailing techniques to lock the ruby process in to it's own little 
> > > > > > > world. It has no writable filesystem and it can only read what it 
> > > > > > > absolutely needs to be able to read to function. All data storage 
> > > > > > > happens over the network on separated database servers. The only 
> > > > > > > type of abuse they need to be weary of is people using their 
> > > > > > > servers to do illegal things - bullying, sharing illegal content, 
> > > > > > > that sort of thing. They deal with that the same way any provider 
> > > > > > > does - wait till someone makes a complaint. Matz, inventor of 
> > > > > > > ruby, works for heroku making exactly this sort of stuff work 
> > > > > > > extremely well.
> > > > > > >  
> > > > > > > Still, it's not as friendly as it could be, and I personally 
> > > > > > > think the trade offs on heroku are not very good for beginners 
> > > > > > > (you have to use a complex database system, and cannot use the 
> > > > > > > filesystem to store anything but static assets).  
> > > > > > >  
> > > > > > > Good work getting this server up David! I'm pretty excited. It 
> > > > > > > sounds like you're having some pretty annoying deployment issues. 
> > > > > > > As it's being quite a hassle, perhaps we should be thinking more 
> > > > > > > deeply about creating our own special server for this task - 
> > > > > > > something like the modified unicorn I mentioned earlier 
> > > > > > > somewhere.  
> > > > > > >  
> > > > > > > —
> > > > > > > Jenna
> > > > > > >  
> > > > > > >  
> > > > > > > On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
> > > > > > >  
> > > > > > > > Wonder if Google might help getting camping to run on app 
> > > > > > > > engine?
> > > > > > > >  
> > > > > > > > On 1 April 2012 10:03, david costa  > > > > > > > (mailto:gurugeek...@gmail.com)> wrote:
> > > > > > > > > Ah I forgot
> > > > > > > > > you can compare camping running on thin here
> > > > > > > > > http://run.camping.io:3301/
> > > > > > > > > vs passenger at http://run.camping.io (http://run.camping.io/)
> > > > > > > > >  
> > > > > > > > > apparently db has some problems with fusion passenger  (see 
> > > > > > > > > http://run.camping.io (http://run.camping.io/) create HTML 
> > > > > > > > > page and test HTML page. The same code on thin works just 
> > > > > > > > > fine... umhh oh no don't feel like more debugging ):  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > >  
> > > > > > > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa 
> > > > > > > > > mailto:gurugeek...@gmail.com)> wrote:
> > > >

Re: dead easy deployment / Camping on the fly

[Dave Everitt]

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  
 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  skrev:
@Isak Anything run with the `backticks operator` runs with the same  
privileges as the process which launched them, if using system level  
sandboxing, or if using some crazy sandbox built in to ruby (which  
probably wouldn't be very good, but maybe good enough) it'd probably  
just disable backticks feature.



On 01/04/2012, at 9:31 PM, Isak Andersson wrote:

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


Anyways. Perhaps we could offer some Gems to pick from that we  
think are quality! (rack_csrf, scrypt).

--
Skickat från min Android-telefon med K-9 E-post. Ursäkta min  
fåordighet.


Jenna Fox  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  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  wrote:

Ah I forgot
you can compare camping running on thin here
http://run.camping.io:3301/
vs passenger at http://run.cam

Re: dead easy deployment / Camping on the fly

[david costa]

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  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  skrev:
>>
>> @Isak Anything run with the `backticks operator` runs with the same
>> privileges as the process which launched them, if using system level
>> sandboxing, or if using some crazy sandbox built in to ruby (which probably
>> wouldn't be very good, but maybe good enough) it'd probably just disable
>> backticks feature.
>>
>>
>> On 01/04/2012, at 9:31 PM, Isak Andersson wrote:
>>
>> Well. Isn't it kind of possible to just hack the gem installation in
>> using the ruby quotes that execute code on the system. I can't type them on
>> the phone but I think you know what I mean. Kind of a security issue isn't
>> it?
>>
>> Anyways. Perhaps we could offer some Gems to pick from that we think are
>> quality! (rack_csrf, scrypt).
>> --
>> Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.
>>
>> Jenna Fox  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  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

Re: dead easy deployment / Camping on the fly

[Isak Andersson]

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

@Isak Anything run with the `backticks operator` runs with the same privileges 
as the process which launched them, if using system level sandboxing, or if 
using some crazy sandbox built in to ruby (which probably wouldn't be very 
good, but maybe good enough) it'd probably just disable backticks feature.



On 01/04/2012, at 9:31 PM, Isak Andersson wrote:


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

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

Jenna Fox  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  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  wrote:

Ah I forgot

you can compare camping running on thin here

http://run.camping.io:3301/

vs passenger at http://run.camping.io


apparently db has some problems with fusion passenger  (see 
http://run.camping.io create HTML page and test HTML page. The same code on 
thin works just fine... umhh oh no don't feel like more debugging ):




On Sun, Apr 1, 2012 at 9:51 AM, david costa  wrote:

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

live at http://run.camping.io/


I did try every apache combination (with passenger, with cgi, etc. etc.) as is 
simply not really working fine.

I tried some other obscure web servers too but apparently this seems to work 
fine for now :) other servers would run the app as CGI or FastCGI. I am not 
worried about speed just ease of deployment and nginx with passenger seems to 
do the job for now. The alternative is nginx as reverse proxy but as Jenna 
rightly pointed out it would spawn a lot of thin instances that might or might 
not be used.


I did throw the sponge at Webdav on apache. It doesn't work as expected and not 
with all clients. It seems more suitable to store quick files than something 
else.

Can try tomorrow with nginx but perhaps it would be nicer to have a quick 
camping hack to upload  a file etc. but you can't just automate it entirely 
else you can have people running malicious code automatically... 


I can do the shell scripts to create virtual users for nginx and dns. Another 
option is to give a normal hosting for camping users. It wouldn't be an issue 
to have 100-200 trusted users to have access to this e.g. we can build a 
camping fro

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

@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  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  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  wrote:
>>>>> Ah I forgot
>>>>> you can compare camping running on thin here
>>>>> http://run.camping.io:3301/
>>>>> vs passenger at http://run.camping.io
>>>>> 
>>>>> apparently db has some problems with fusion passenger  (see 
>>>>> http://run.camping.io create HTML page and test HTML page. The same code 
>>>>> on thin works just fine... umhh oh no don't feel like more debugging ):
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, Apr 1, 2012 at 9:51 AM, david costa  wrote:
>>>>>> Okay :D after many many hours of testing I am settled for nginx and 
>>>>>> passenger.
>>>>>> live at http://run.camping.io/
>>>>>> 
>>>>>> I did try every apache combination (with passenger, with cgi, etc. etc.) 
>>>>>> as is simply not really working fine.
>>>>>> I tried some other obscure web servers too but apparently this seems to 
>>>>>> work fine for now :) other servers would run the app as CGI or FastCGI. 
>>>>>> I am not worried abo

Re: dead easy deployment / Camping on the fly

[Isak Andersson]

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

Ah I forgot

you can compare camping running on thin here

http://run.camping.io:3301/

vs passenger at http://run.camping.io


apparently db has some problems with fusion passenger  (see 
http://run.camping.io create HTML page and test HTML page. The same code on 
thin works just fine... umhh oh no don't feel like more debugging ):




On Sun, Apr 1, 2012 at 9:51 AM, david costa  wrote:

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

live at http://run.camping.io/


I did try every apache combination (with passenger, with cgi, etc. etc.) as is 
simply not really working fine.

I tried some other obscure web servers too but apparently this seems to work 
fine for now :) other servers would run the app as CGI or FastCGI. I am not 
worried about speed just ease of deployment and nginx with passenger seems to 
do the job for now. The alternative is nginx as reverse proxy but as Jenna 
rightly pointed out it would spawn a lot of thin instances that might or might 
not be used.


I did throw the sponge at Webdav on apache. It doesn't work as expected and not 
with all clients. It seems more suitable to store quick files than something 
else.

Can try tomorrow with nginx but perhaps it would be nicer to have a quick 
camping hack to upload  a file etc. but you can't just automate it entirely 
else you can have people running malicious code automatically... 


I can do the shell scripts to create virtual users for nginx and dns. Another 
option is to give a normal hosting for camping users. It wouldn't be an issue 
to have 100-200 trusted users to have access to this e.g. we can build a 
camping fronted  for users to apply with a selection e.g. their github account, 
why they want the deployment hosting etc. and then once approved we would give 
them a normal account that would allow them to upload files on SFTP and may be 
even shell (which BTW is something you don't have on heroku and other services. 
Of course this could be protected for security or given only to active people. 


How does heroku screens against abuses?  

Anyway if some of you would like to be alpha users in this system let me know, 
I will be glad to set you up as soon as I am done testing

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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 mailto:a...@creativepony.com)> skrev:
> > Hm. I know the main guy responsible for App Engine, and, well, I certainly 
> > wouldn't build a platform atop it - even aside from the huge glaring issue 
> > that to have an app which can store data persistently, you need to use 
> > google's proprietary database software.
> >  
> > Heroku doesn't screen against abuse at all. Heroku is not a 'shared 
> > hosting' provider. Their systems use the very finest jailing techniques to 
> > lock the ruby process in to it's own little world. It has no writable 
> > filesystem and it can only read what it absolutely needs to be able to read 
> > to function. All data storage happens over the network on separated 
> > database servers. The only type of abuse they need to be weary of is people 
> > using their servers to do illegal things - bullying, sharing illegal 
> > content, that sort of thing. They deal with that the same way any provider 
> > does - wait till someone makes a complaint. Matz, inventor of ruby, works 
> > for heroku making exactly this sort of stuff work extremely well.
> >  
> > Still, it's not as friendly as it could be, and I personally think the 
> > trade offs on heroku are not very good for beginners (you have to use a 
> > complex database system, and cannot use the filesystem to store anything 
> > but static assets).
> >  
> > Good work getting this server up David! I'm pretty excited. It sounds like 
> > you're having some pretty annoying deployment issues. As it's being quite a 
> > hassle, perhaps we should be thinking more deeply about creating our own 
> > special server for this task - something like the modified unicorn I 
> > mentioned earlier somewhere.  
> >  
> > —
> > Jenna
> >  
> >  
> > On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote:
> >  
> > > Wonder if Google might help getting camping to run on app engine?
> > >  
> > > On 1 April 2012 10:03, david costa  > > (mailto:gurugeek...@gmail.com)> wrote:
> > > > Ah I forgot
> > > > you can compare camping running on thin here
> > > > http://run.camping.io:3301/
> > > > vs passenger at http://run.camping.io
> > > >  
> > > > apparently db has some problems with fusion passenger  (see 
> > > > http://run.camping.io create HTML page and test HTML page. The same 
> > > > code on thin works just fine... umhh oh no don't feel like more 
> > > > debugging ):  
> > > >  
> > > >  
> > > >  
> > > > On Sun, Apr 1, 2012 at 9:51 AM, david costa  > > > (mailto:gurugeek...@gmail.com)> wrote:
> > > > > Okay :D after many many hours of testing I am settled for nginx and 
> > > > > passenger.
> > > > > live at http://run.camping.io/
> > > > >  
> > > > >  
> > > > > I did try every apache combination (with passenger, with cgi, etc. 
> > > > > etc.) as is simply not really working fine.  
> > > > > I tried some other obscure web servers too but apparently this seems 
> > > > > to work fine for now :) other servers would run the app as CGI or 
> > > > > FastCGI. I am not worried about speed just ease of deployment and 
> > > > > nginx with passenger seems to do the job for now. The alternative is 
> > > > > nginx as reverse proxy but as Jenna rightly pointed out it would 
> > > > > spawn a lot of thin instances that might or might not be used.
> > > > >  
> > > > > I did throw the sponge at Webdav on apache. It doesn't work as 
> > > > > expected and not with all clients. It seems more suitable to store 
> > > > > quick files than something else.
> > > > > Can try tomorrow with nginx but perhaps it would be nicer to have a 
> > > > > quick camping hack to upload  a file etc. but you can't just automate 
> > > > > it entirely else you can have people ru

Re: dead easy deployment / Camping on the fly

[Isak Andersson]

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

Ah I forgot

you can compare camping running on thin here

http://run.camping.io:3301/

vs passenger at http://run.camping.io


apparently db has some problems with fusion passenger  (see 
http://run.camping.io create HTML page and test HTML page. The same code on 
thin works just fine... umhh oh no don't feel like more debugging ):




On Sun, Apr 1, 2012 at 9:51 AM, david costa  wrote:

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

live at http://run.camping.io/


I did try every apache combination (with passenger, with cgi, etc. etc.) as is 
simply not really working fine.

I tried some other obscure web servers too but apparently this seems to work 
fine for now :) other servers would run the app as CGI or FastCGI. I am not 
worried about speed just ease of deployment and nginx with passenger seems to 
do the job for now. The alternative is nginx as reverse proxy but as Jenna 
rightly pointed out it would spawn a lot of thin instances that might or might 
not be used.


I did throw the sponge at Webdav on apache. It doesn't work as expected and not 
with all clients. It seems more suitable to store quick files than something 
else.

Can try tomorrow with nginx but perhaps it would be nicer to have a quick 
camping hack to upload  a file etc. but you can't just automate it entirely 
else you can have people running malicious code automatically... 


I can do the shell scripts to create virtual users for nginx and dns. Another 
option is to give a normal hosting for camping users. It wouldn't be an issue 
to have 100-200 trusted users to have access to this e.g. we can build a 
camping fronted  for users to apply with a selection e.g. their github account, 
why they want the deployment hosting etc. and then once approved we would give 
them a normal account that would allow them to upload files on SFTP and may be 
even shell (which BTW is something you don't have on heroku and other services. 
Of course this could be protected for security or given only to active people. 


How does heroku screens against abuses?  

Anyway if some of you would like to be alpha users in this system let me know, 
I will be glad to set you up as soon as I am done testing subdomains etc. ;)

And of course if you have a better idea for a setup let me know.


Regards

David





On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox  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  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 se

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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  (mailto:gurugeek...@gmail.com)> wrote:
> > Ah I forgot
> > you can compare camping running on thin here
> > http://run.camping.io:3301/
> > vs passenger at http://run.camping.io
> >  
> > apparently db has some problems with fusion passenger  (see 
> > http://run.camping.io create HTML page and test HTML page. The same code on 
> > thin works just fine... umhh oh no don't feel like more debugging ):  
> >  
> >  
> >  
> > On Sun, Apr 1, 2012 at 9:51 AM, david costa  > (mailto:gurugeek...@gmail.com)> wrote:
> > > Okay :D after many many hours of testing I am settled for nginx and 
> > > passenger.
> > > live at http://run.camping.io/
> > >  
> > >  
> > > I did try every apache combination (with passenger, with cgi, etc. etc.) 
> > > as is simply not really working fine.  
> > > I tried some other obscure web servers too but apparently this seems to 
> > > work fine for now :) other servers would run the app as CGI or FastCGI. I 
> > > am not worried about speed just ease of deployment and nginx with 
> > > passenger seems to do the job for now. The alternative is nginx as 
> > > reverse proxy but as Jenna rightly pointed out it would spawn a lot of 
> > > thin instances that might or might not be used.
> > >  
> > > I did throw the sponge at Webdav on apache. It doesn't work as expected 
> > > and not with all clients. It seems more suitable to store quick files 
> > > than something else.
> > > Can try tomorrow with nginx but perhaps it would be nicer to have a quick 
> > > camping hack to upload  a file etc. but you can't just automate it 
> > > entirely else you can have people running malicious code automatically... 
> > >  
> > >  
> > > I can do the shell scripts to create virtual users for nginx and dns. 
> > > Another option is to give a normal hosting for camping users. It wouldn't 
> > > be an issue to have 100-200 trusted users to have access to this e.g. we 
> > > can build a camping fronted  for users to apply with a selection e.g. 
> > > their github account, why they want the deployment hosting etc. and then 
> > > once approved we would give them a normal account that would allow them 
> > > to upload files on SFTP and may be even shell (which BTW is something you 
> > > don't have on heroku and other services. Of course this could be 
> > > protected for security or given only to active people.   
> > >  
> > > How does heroku screens against abuses?   
> > > Anyway if some of you would like to be alpha users in this system let me 
> > > know, I will be glad to set you up as soon as I am done testing 
> > > subdomains etc. ;)
> > > And of course if you have a better idea for a setup let me know.
> > >  
> > > Regards
> > > David
> > >  
> > >  

Re: dead easy deployment / Camping on the fly

[david costa]

Umh I doubt it was already here
http://camping.io/Book/-Publishing-an-App#Using-Google-App-Engine
but is far from an automated, one line /one upload system


On Sun, Apr 1, 2012 at 10:23 AM, Peter Retief  wrote:

> Wonder if Google might help getting camping to run on app engine?
>
>
> On 1 April 2012 10:03, david costa  wrote:
>
>> Ah I forgot
>> you can compare camping running on thin here
>> http://run.camping.io:3301/
>> vs passenger at http://run.camping.io
>>
>> apparently db has some problems with fusion passenger  (see
>> http://run.camping.io create HTML page and test HTML page. The same code
>> on thin works just fine... umhh oh no don't feel like more debugging ):
>>
>>
>>
>> On Sun, Apr 1, 2012 at 9:51 AM, david costa wrote:
>>
>>> Okay :D after many many hours of testing I am settled for nginx and
>>> passenger.
>>> live at http://run.camping.io/
>>>
>>> I did try every apache combination (with passenger, with cgi, etc. etc.)
>>> as is simply not really working fine.
>>> I tried some other obscure web servers too but apparently this seems to
>>> work fine for now :) other servers would run the app as CGI or FastCGI. I
>>> am not worried about speed just ease of deployment and nginx with passenger
>>> seems to do the job for now. The alternative is nginx as reverse proxy but
>>> as Jenna rightly pointed out it would spawn a lot of thin instances that
>>> might or might not be used.
>>>
>>> I did throw the sponge at Webdav on apache. It doesn't work as expected
>>> and not with all clients. It seems more suitable to store quick files than
>>> something else.
>>> Can try tomorrow with nginx but perhaps it would be nicer to have a
>>> quick camping hack to upload  a file etc. but you can't just automate it
>>> entirely else you can have people running malicious code automatically...
>>>
>>> I can do the shell scripts to create virtual users for nginx and dns.
>>> Another option is to give a normal hosting for camping users. It wouldn't
>>> be an issue to have 100-200 trusted users to have access to this e.g. we
>>> can build a camping fronted  for users to apply with a selection e.g. their
>>> github account, why they want the deployment hosting etc. and then once
>>> approved we would give them a normal account that would allow them to
>>> upload files on SFTP and may be even shell (which BTW is something you
>>> don't have on heroku and other services. Of course this could be protected
>>> for security or given only to active people.
>>>
>>> How does heroku screens against abuses?
>>> Anyway if some of you would like to be alpha users in this system let me
>>> know, I will be glad to set you up as soon as I am done testing subdomains
>>> etc. ;)
>>> And of course if you have a better idea for a setup let me know.
>>>
>>> Regards
>>> David
>>>
>>>
>>>
>>>
>>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox  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 
>>>> 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 

Re: dead easy deployment / Camping on the fly

[Peter Retief]

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

On 1 April 2012 10:03, david costa  wrote:

> Ah I forgot
> you can compare camping running on thin here
> http://run.camping.io:3301/
> vs passenger at http://run.camping.io
>
> apparently db has some problems with fusion passenger  (see
> http://run.camping.io create HTML page and test HTML page. The same code
> on thin works just fine... umhh oh no don't feel like more debugging ):
>
>
>
> On Sun, Apr 1, 2012 at 9:51 AM, david costa  wrote:
>
>> Okay :D after many many hours of testing I am settled for nginx and
>> passenger.
>> live at http://run.camping.io/
>>
>> I did try every apache combination (with passenger, with cgi, etc. etc.)
>> as is simply not really working fine.
>> I tried some other obscure web servers too but apparently this seems to
>> work fine for now :) other servers would run the app as CGI or FastCGI. I
>> am not worried about speed just ease of deployment and nginx with passenger
>> seems to do the job for now. The alternative is nginx as reverse proxy but
>> as Jenna rightly pointed out it would spawn a lot of thin instances that
>> might or might not be used.
>>
>> I did throw the sponge at Webdav on apache. It doesn't work as expected
>> and not with all clients. It seems more suitable to store quick files than
>> something else.
>> Can try tomorrow with nginx but perhaps it would be nicer to have a quick
>> camping hack to upload  a file etc. but you can't just automate it entirely
>> else you can have people running malicious code automatically...
>>
>> I can do the shell scripts to create virtual users for nginx and dns.
>> Another option is to give a normal hosting for camping users. It wouldn't
>> be an issue to have 100-200 trusted users to have access to this e.g. we
>> can build a camping fronted  for users to apply with a selection e.g. their
>> github account, why they want the deployment hosting etc. and then once
>> approved we would give them a normal account that would allow them to
>> upload files on SFTP and may be even shell (which BTW is something you
>> don't have on heroku and other services. Of course this could be protected
>> for security or given only to active people.
>>
>> How does heroku screens against abuses?
>> Anyway if some of you would like to be alpha users in this system let me
>> know, I will be glad to set you up as soon as I am done testing subdomains
>> etc. ;)
>> And of course if you have a better idea for a setup let me know.
>>
>> Regards
>> David
>>
>>
>>
>>
>> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox  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 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.
>>>
>

Re: dead easy deployment / Camping on the fly

[david costa]

Okay :D after many many hours of testing I am settled for nginx and
passenger.
live at http://run.camping.io/

I did try every apache combination (with passenger, with cgi, etc. etc.) as
is simply not really working fine.
I tried some other obscure web servers too but apparently this seems to
work fine for now :) other servers would run the app as CGI or FastCGI. I
am not worried about speed just ease of deployment and nginx with passenger
seems to do the job for now. The alternative is nginx as reverse proxy but
as Jenna rightly pointed out it would spawn a lot of thin instances that
might or might not be used.

I did throw the sponge at Webdav on apache. It doesn't work as expected and
not with all clients. It seems more suitable to store quick files than
something else.
Can try tomorrow with nginx but perhaps it would be nicer to have a quick
camping hack to upload  a file etc. but you can't just automate it entirely
else you can have people running malicious code automatically...

I can do the shell scripts to create virtual users for nginx and dns.
Another option is to give a normal hosting for camping users. It wouldn't
be an issue to have 100-200 trusted users to have access to this e.g. we
can build a camping fronted  for users to apply with a selection e.g. their
github account, why they want the deployment hosting etc. and then once
approved we would give them a normal account that would allow them to
upload files on SFTP and may be even shell (which BTW is something you
don't have on heroku and other services. Of course this could be protected
for security or given only to active people.

How does heroku screens against abuses?
Anyway if some of you would like to be alpha users in this system let me
know, I will be glad to set you up as soon as I am done testing subdomains
etc. ;)
And of course if you have a better idea for a setup let me know.

Regards
David




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

Re: dead easy deployment / Camping on the fly

[david costa]

Ah I forgot
you can compare camping running on thin here
http://run.camping.io:3301/
vs passenger at http://run.camping.io

apparently db has some problems with fusion passenger  (see
http://run.camping.io create HTML page and test HTML page. The same code on
thin works just fine... umhh oh no don't feel like more debugging ):



On Sun, Apr 1, 2012 at 9:51 AM, david costa  wrote:

> Okay :D after many many hours of testing I am settled for nginx and
> passenger.
> live at http://run.camping.io/
>
> I did try every apache combination (with passenger, with cgi, etc. etc.)
> as is simply not really working fine.
> I tried some other obscure web servers too but apparently this seems to
> work fine for now :) other servers would run the app as CGI or FastCGI. I
> am not worried about speed just ease of deployment and nginx with passenger
> seems to do the job for now. The alternative is nginx as reverse proxy but
> as Jenna rightly pointed out it would spawn a lot of thin instances that
> might or might not be used.
>
> I did throw the sponge at Webdav on apache. It doesn't work as expected
> and not with all clients. It seems more suitable to store quick files than
> something else.
> Can try tomorrow with nginx but perhaps it would be nicer to have a quick
> camping hack to upload  a file etc. but you can't just automate it entirely
> else you can have people running malicious code automatically...
>
> I can do the shell scripts to create virtual users for nginx and dns.
> Another option is to give a normal hosting for camping users. It wouldn't
> be an issue to have 100-200 trusted users to have access to this e.g. we
> can build a camping fronted  for users to apply with a selection e.g. their
> github account, why they want the deployment hosting etc. and then once
> approved we would give them a normal account that would allow them to
> upload files on SFTP and may be even shell (which BTW is something you
> don't have on heroku and other services. Of course this could be protected
> for security or given only to active people.
>
> How does heroku screens against abuses?
> Anyway if some of you would like to be alpha users in this system let me
> know, I will be glad to set you up as soon as I am done testing subdomains
> etc. ;)
> And of course if you have a better idea for a setup let me know.
>
> Regards
> David
>
>
>
>
> On Sun, Apr 1, 2012 at 1:30 AM, Jenna Fox  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 wrote:
>>
>> ** Actually setting up a reverse proxy gives better performance for the
>> end user As you can have some sort of buffer between them. The Unicorn
>> server takes care of whatever nginx asks for, and while it waits it can
>> server whatever unicorn outputs. It doesn't have to wait for what it
>> outputs itself to get done because you have a queue. Or something like that.
>>
>>
>> Mh I am not really sure it would be a better performance as it would be
>> anyway more than one process. I think that phusion passenger is pretty much
>> the most robust solution for this.
>>
>>
>> Some people actually out Apache to do PHP stuff while nginx acts as a
>> reverse proxy and actually shows things to the user in the same way you'd
>> do with Unicorn/Thin
>>
>>
>> Well this would be even more load as two web servers will run at the same
>> time. Apache + Phusion passenger already lets you run .php or anything you
>> want.
>>
>> But this is not the issue really. I think this is all fine in term of
>> mono user. Question: if you have 100 users how do you configure it ?
>> How can you add webdav support on the top of the Nginx + unicorn setup ?
>>
>>
>> But perhaps That's too much for a server ment to serve other peoples
>> applications! Then you have to scale down the resources used.
>>
>>
>> I am open to anything but if I can't do something I might ask for some
>> brave volunteers to set it up as I really never tried anything else beside
>> for local/quick test deployment.
>>  ___
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>>
>>
>> ___
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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

Re: dead easy deployment / Camping on the fly

[david costa]

On Sat, Mar 31, 2012 at 5:36 PM, Isak Andersson wrote:

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

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

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

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

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


But perhaps That's too much for a server ment to serve other peoples
> applications! Then you have to scale down the resources used.
>
>
I am open to anything but if I can't do something I might ask for some
brave volunteers to set it up as I really never tried anything else beside
for local/quick test deployment.
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Isak Andersson]

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

Re: dead easy deployment / Camping on the fly

[Nokan Emiro]

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  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  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 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  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  wrote:
>>>>
>>>> @David - sorted, both those subdomains now point to your machine. :)
>>>>
>>>> —
>>>> Jenna
>>>>
>>>> On

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[Nokan Emiro]

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

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

gt; > > > > > > a very nice maximum number of things you'd ever want to put in a 
> > > > > > > single directory if using something like EXT4 or HFS+. Of course, 
> > > > > > > if using a B-Tree filesystem like reiser, btrfs, zfs there is no 
> > > > > > > such limitation so you can skip the scanning joining thing and 
> > > > > > > just open "database/#{key.hash}" and put a value in that.  
> > > > > > >  
> > > > > > > Pretty cool, no? It's really easy to turn something like that in 
> > > > > > > to what seems from the outside to be a persistent hash.
> > > > > > >  
> > > > > > > I was working on another thing called ForeverHash, which was the 
> > > > > > > same sort of idea, but used flat files. If people are interested 
> > > > > > > I'd be curious enough to revive that project with more of a 
> > > > > > > CouchDB inspired design.  
> > > > > > >  
> > > > > > > I like all these filesystem based solutions (sqlite, crazy hash 
> > > > > > > in folders, flat file key-value db's) because they can be backed 
> > > > > > > up and restored via webdav or sftp or whatever, and you don't 
> > > > > > > need to do any weird stuff of configuring which ports and 
> > > > > > > usernames and passwords in your database abstraction. I prefer 
> > > > > > > the idea of having a little key-value filesystem db written in 
> > > > > > > clear straight forward ruby code, because it means kids learning 
> > > > > > > can see how it works and hack at it - as nice as sqlite is, it is 
> > > > > > > in no way transparent. You at least have to learn SQL if you want 
> > > > > > > to play with it's innards, and possibly C.   
> > > > > > > On 31/03/2012, at 3:22 AM, david costa wrote:
> > > > > > > > Hello all,
> > > > > > > > I am opening a separate topic just to brainstorm the idea of a 
> > > > > > > > free, simple camping deployment/hosting option.
> > > > > > > > Now this is not about re-inventing the wheel as heroku already 
> > > > > > > > supports camping apps too. So this would be the ground idea:
> > > > > > > >  
> > > > > > > > a) This would be entirely free - no paid plans to upgrade etc.;
> > > > > > > > b) Eventually users should be able to deploy a camping 
> > > > > > > > application by launching something like camping-fly myapp in 
> > > > > > > > the command line and it would simply work (through a git push 
> > > > > > > > or similar) and make it available live in a custom domain like 
> > > > > > > > camping.sh (http://camping.sh) or ruby.am (http://ruby.am/) 
> > > > > > > > e.g. myfancyapp.camping.sh (http://myfancyapp.camping.sh/) or 
> > > > > > > > myfancyapp.ruby.am (http://myfancyapp.ruby.am/)
> > > > > > > > c) Database fanciness should also be available or at least 
> > > > > > > > sqlite/mysql
> > > > > > > >  
> > > > > > > > Suggestion and ideas on how to achieve this are welcome (or 
> > > > > > > > professionals with the expertise willing to do a simple project 
> > > > > > > > based on this )  
> > > > > > > > servers I can make available for this:  
> > > > > > > >  
> > > > > > > > Debian 6
> > > > > > > > Intel Core i7 3930K (6 x 3,20 GHz)
> > > > > > > > RAM 64 GB
> > > > > > > > 3000 GB HD + 256 MB SSD drive (very useful for databases, much 
> > > > > > > > faster)
> > > > > > > >  
> > > > > > > > OR (don't laugh)
> > > > > > > >  
> > > > > > > > Mac mini  
> > > > > > > > 2.0GHz quad-core Intel Core i7
> > > > > > > > 8GB memory
> > > > > > > > 2X256GB Solid State Drive
> > > > > > > >  
> > > > > > > >  
> > > > > > > > of course we would need to limit this to screened applicants to 
> > > > > > > > avoid any spammers/troublemakers  
> > > > > > > >  
> > > > > > > > Best Regards
> > > > > > > > David
> > > > > > > >  
> > > > > > > >  
> > > > > > > > ___
> > > > > > > > Camping-list mailing list
> > > > > > > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > > > > > > http://rubyforge.org/mailman/listinfo/camping-list  
> > > > > > >  
> > > > > > > ___
> > > > > > > Camping-list mailing list
> > > > > > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > > > >  
> > > > > > ___
> > > > > > Camping-list mailing list
> > > > > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > > > > http://rubyforge.org/mailman/listinfo/camping-list  
> > > > >  
> > > > > ___
> > > > > Camping-list mailing list
> > > > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > >  
> > >  
> > > ___
> > > Camping-list mailing list
> > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> > >  
> > >  
> > >  
> >  
> >  
> >  
> > ___
> > Camping-list mailing list
> > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
>  
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>  
>  


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

@David - sorted, both those subdomains now point to your machine. :)

—
Jenna


On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:

> BTW if you want to point a  run.camping.io (http://run.camping.io) or 
> host.camping.io (http://host.camping.io) or anything you like to  
> 66.116.108.12 will then be able to show an (hopefully) working demo using the 
> official domain ;)
>  
> On Sat, Mar 31, 2012 at 7:08 AM, david costa  (mailto:gurugeek...@gmail.com)> wrote:
> > oh sure ! for me is not a problem - love camping.io (http://camping.io) as 
> > a domain !
> >  
> > first worry is to have a working system that is fairly stable and usable 
> > albeit it might be launched as alpha/beta anyway :)  
> >  
> >  
> > On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox  > (mailto:a...@creativepony.com)> wrote:
> > > We can just use a *.camping.io (http://camping.io) catchall entry
> > >  
> > >  
> > > On 31/03/2012, at 3:30 PM, david costa wrote:  
> > > > Hello Jenna,
> > > > we could use host.camping.io (http://host.camping.io/) or 
> > > > anything.camping.io (http://anything.camping.io/) for the frontend but 
> > > > if the server has to allow users to create myfancyapp.camping.io 
> > > > (http://myfancyapp.camping.io/) it would be complicated as I would need 
> > > > to run the camping.io (http://camping.io/) DNS on the hosting server to 
> > > > create the sub domains on the fly. I started working on it more details 
> > > > on a separate email.  
> > > >  
> > > > I love your idea about the key-value database how can we implement this 
> > > > ?
> > > > Thanks
> > > > David
> > > >  
> > > >  
> > > > On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox  > > > (mailto:a...@creativepony.com)> wrote:
> > > > > Those both sound like brilliant servers! I'm not laughing at all. If 
> > > > > my mac mini is good enough for sky rim, it's good enough for web 
> > > > > hosting for sure!  
> > > > >  
> > > > > Can we just use camping.io (http://camping.io/)?
> > > > >  
> > > > > I think starting simple is a good idea. Databases are pretty cool 
> > > > > among web developers for various reasons, but I think are totally 
> > > > > unnecessary for most smaller experimental applications. For a 
> > > > > beginner, I'm inclined to have key-value databases. A really simple 
> > > > > key-value database would work like this:  
> > > > >  
> > > > > sections = key.hash.to_s(36).scan(/.{0,3}/)
> > > > > sections.delete ""
> > > > > Dir.mkdir sections[0…-1].join('/')
> > > > > File.open(sections.join('/') + '-value', 'w') do |file|
> > > > >   file.write JSON.generate(value)
> > > > > end
> > > > >  
> > > > > add in some file locking, and everything is pretty cool. It splits up 
> > > > > the kevin to a series of about four directories and then a file, and 
> > > > > conveniently "fff" in base36 is 19995, which is a very nice maximum 
> > > > > number of things you'd ever want to put in a single directory if 
> > > > > using something like EXT4 or HFS+. Of course, if using a B-Tree 
> > > > > filesystem like reiser, btrfs, zfs there is no such limitation so you 
> > > > > can skip the scanning joining thing and just open 
> > > > > "database/#{key.hash}" and put a value in that.  
> > > > >  
> > > > > Pretty cool, no? It's really easy to turn something like that in to 
> > > > > what seems from the outside to be a persistent hash.
> > > > >  
> > > > > I was working on another thing called ForeverHash, which was the same 
> > > > > sort of idea, but used flat files. If people are interested I'd be 
> > > > > curious enough to revive that project with more of a CouchDB inspired 
> > > > > design.  
> > > > >  
> > > > > I like all these filesystem based solutions (sqlite, crazy hash in 
> > > > > folders, flat file key-value db's) because they can be backed up and 
> > > > > restored via webdav or sftp or whatever, and you don't need to do any 
> > > > > weird stuff of configuring which ports and usernames and passwords in 

Re: dead easy deployment / Camping on the fly

[Isak Andersson]

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  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  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  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  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@rubyforge.org
http://

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[david costa]

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

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

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

Some small things you might have some ideas for:
-On Passenger apparently camping runs without issues as config.ru (camping
code on the config.ru file directly)
see
http://www.modrails.com/documentation/Users%20guide%20Apache.html#_camping
I did try to use the camping book instructions (dreamhost) but for a reason
or another it doesn't work. This is not a main issue thou as, if we allow
to test 1 file apps automagically it can be renamed to config.ru as
passenger wants but I am sure there is another way to do it perhaps;
- I am getting the nasty internal error if I call a page like
http://bash.is/lsdlksd but I do get a nice camping error for something like
http://bash.is/blahh.html I am sure I can fix this small cosmetic thing
easily thou need to dig a bit more on apache config

TODO from my side:
- If this testing would not include mysql or a db beside sqlite or flat
would be probably easier as I won't need to make a script to set a db user
etc.
- A simple ruby or shell script to test quick upload and deployment of
camping apps (this should required the creation of a new user + allow the
user to connect and upload the files I guess).  An alternative would be to
have no new user created but, via a unique key, allow the user to see his
app/change it etc. in his/her app sub-domain (myappl.domain.something)
- Testing, Testing, Testing :)

It looks exciting and I am sure it can come up as a pretty good solution.
Webdav shouldn't be difficult at all and perhaps is the best way to do it
so it would be way less geeky than heroku  and well on one or more mac
minis is fairly hedgy !

Cheers
David




On Sat, Mar 31, 2012 at 6:30 AM, david costa  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  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&#

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[david costa]

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

Re: dead easy deployment / Camping on the fly

[Jenna Fox]

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

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Isak Andersson]

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

david costa  skrev:

Hello all,

I am opening a separate topic just to brainstorm the idea of a free, simple 
camping deployment/hosting option.

Now this is not about re-inventing the wheel as heroku already supports camping 
apps too. So this would be the ground idea:


a) This would be entirely free - no paid plans to upgrade etc.;

b) Eventually users should be able to deploy a camping application by launching 
something like camping-fly myapp in the command line and it would simply work 
(through a git push or similar) and make it available live in a custom domain 
like camping.sh or ruby.am e.g. myfancyapp.camping.sh or myfancyapp.ruby.am

c) Database fanciness should also be available or at least sqlite/mysql


Suggestion and ideas on how to achieve this are welcome (or professionals with 
the expertise willing to do a simple project based on this )

servers I can make available for this: 


Debian 6

Intel Core i7 3930K (6 x 3,20 GHz)

RAM 64 GB

3000 GB HD + 256 MB SSD drive (very useful for databases, much faster)


OR (don't laugh)


Mac mini 

2.0GHz quad-core Intel Core i7

8GB memory

2X256GB Solid State Drive


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


Best Regards

David

Dcouvre tous les secrets de la Magie. Clique Ici!

http://click.lavabit.com/hmfehg75rumtxy6e9birp9px66eqeqn1cjxgcxtdp648siroyzcb/ 

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: dead easy deployment / Camping on the fly

[Dave Everitt]

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


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

dead easy deployment / Camping on the fly

[david costa]

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

Re: Easy deployment on DreamHost with Phusion Passenger

[Eric Mill]

Nope, I didn't have to change anything.  And for getting it working in
development, it was made easier by me copying the preamble that you
had helped me concoct so long ago for another app that I did in
Camping 2.0 from the get go, so that helped.

For reference, the site I'm talking about is ohnomymoney.com, and the
code for it that I'm talking about is here:
http://github.com/klondike/money/blob/b0d7c8c9bcaae9ccd6aa90a2a819168f8b5c28a9/money.rb

-- Eric

On Fri, Aug 7, 2009 at 4:12 PM, Magnus Holm wrote:
> Did you have any problems upgrading from 1.5? We'll have to write down
> a little guide :-)
>
> //Magnus Holm
>
>
>
> On Fri, Aug 7, 2009 at 21:56, Eric Mill wrote:
>> So, I switched my Camping app from Camping 1.5 to Camping 2.0 and
>> deployed it using these Passenger instructions...
>>
>> ...worked the first time! Amazing!  I spent several hours figuring out
>> the FastCGI shared hosting instructions for Dreamhost for Camping 1.5,
>> and for Camping 2.0.  This is hideously easier and faster.
>>
>> Thanks again, sir!
>>
>> -- Eric
>>
>> On Mon, Jul 20, 2009 at 10:56 PM, Eric Mill wrote:
>>> You are awesome! I'm gonna switch my Camping app to passenger and test it
>>> out at the next opportunity.
>>>
>>> -- Eric
>>>
>>> On Jul 20, 2009 8:12 PM, "Roland Crosby"  wrote:
>>>
>>> OK, I updated the Dreamhost wiki
>>> and http://wiki.github.com/why/camping/camping-on-shared-hosting with a
>>> configuration that worked for me - other people using Dreamhost and/or
>>> Passenger, let me know if
>>> this works for you, or if there are other tips and tricks that you suggest.
>>> Roland
>>>
>>> On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill  wrote: >
 Here's the link to t...
>>>
>>> ___
>>> Camping-list mailing list
>>> Camping-list@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> ___
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Magnus Holm]

Did you have any problems upgrading from 1.5? We'll have to write down
a little guide :-)

//Magnus Holm



On Fri, Aug 7, 2009 at 21:56, Eric Mill wrote:
> So, I switched my Camping app from Camping 1.5 to Camping 2.0 and
> deployed it using these Passenger instructions...
>
> ...worked the first time! Amazing!  I spent several hours figuring out
> the FastCGI shared hosting instructions for Dreamhost for Camping 1.5,
> and for Camping 2.0.  This is hideously easier and faster.
>
> Thanks again, sir!
>
> -- Eric
>
> On Mon, Jul 20, 2009 at 10:56 PM, Eric Mill wrote:
>> You are awesome! I'm gonna switch my Camping app to passenger and test it
>> out at the next opportunity.
>>
>> -- Eric
>>
>> On Jul 20, 2009 8:12 PM, "Roland Crosby"  wrote:
>>
>> OK, I updated the Dreamhost wiki
>> and http://wiki.github.com/why/camping/camping-on-shared-hosting with a
>> configuration that worked for me - other people using Dreamhost and/or
>> Passenger, let me know if
>> this works for you, or if there are other tips and tricks that you suggest.
>> Roland
>>
>> On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill  wrote: >
>>> Here's the link to t...
>>
>> ___
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Eric Mill]

So, I switched my Camping app from Camping 1.5 to Camping 2.0 and
deployed it using these Passenger instructions...

...worked the first time! Amazing!  I spent several hours figuring out
the FastCGI shared hosting instructions for Dreamhost for Camping 1.5,
and for Camping 2.0.  This is hideously easier and faster.

Thanks again, sir!

-- Eric

On Mon, Jul 20, 2009 at 10:56 PM, Eric Mill wrote:
> You are awesome! I'm gonna switch my Camping app to passenger and test it
> out at the next opportunity.
>
> -- Eric
>
> On Jul 20, 2009 8:12 PM, "Roland Crosby"  wrote:
>
> OK, I updated the Dreamhost wiki
> and http://wiki.github.com/why/camping/camping-on-shared-hosting with a
> configuration that worked for me - other people using Dreamhost and/or
> Passenger, let me know if
> this works for you, or if there are other tips and tricks that you suggest.
> Roland
>
> On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill  wrote: >
>> Here's the link to t...
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Mathieu Jobin]

the problem with dreamhost is when your app becomes popular.
not enough to afford a VPS but too popular to fit in dreamhost shared
hosting allowed RAM.

your process will get killed and your users will see error 500.

thanks for the howto anyway.

On Tue, Jul 21, 2009 at 3:38 AM, Jenna Fox wrote:
> MMm yeah I've been using passenger to run talkie.me on DreamHost for a while
> now without issue. I found that without those lines setting the gem paths
> the app would work intermittently, rather frustratingly. So don't forget
> those! :)
> —
> Jenna
>
> On 21/07/2009, at 12:56 PM, Eric Mill wrote:
>
> You are awesome! I'm gonna switch my Camping app to passenger and test it
> out at the next opportunity.
>
> -- Eric
>
> On Jul 20, 2009 8:12 PM, "Roland Crosby"  wrote:
>
> OK, I updated the Dreamhost wiki
> and http://wiki.github.com/why/camping/camping-on-shared-hosting with a
> configuration that worked for me - other people using Dreamhost and/or
> Passenger, let me know if
> this works for you, or if there are other tips and tricks that you suggest.
> Roland
>
> On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill  wrote: >
>> Here's the link to t...
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
"While the Baroque rules of chess could only have been created by
humans, the rules of go are so elegant, organic, and rigorously
logical that if intelligent life forms exist elsewhere in the
universe, they almost certainly play go."

-- Edward Lasker
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Jenna Fox]

MMm yeah I've been using passenger to run talkie.me on DreamHost for a  
while now without issue. I found that without those lines setting the  
gem paths the app would work intermittently, rather frustratingly. So  
don't forget those! :)


—
Jenna


On 21/07/2009, at 12:56 PM, Eric Mill wrote:

You are awesome! I'm gonna switch my Camping app to passenger and  
test it out at the next opportunity.


-- Eric


On Jul 20, 2009 8:12 PM, "Roland Crosby"   
wrote:


OK, I updated the Dreamhost wiki and http://wiki.github.com/why/camping/camping-on-shared-hosting 
 with a configuration that worked for me - other people using  
Dreamhost and/or Passenger, let me know if this works for you, or  
if there are other tips and tricks that you suggest.


Roland
On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill   
wrote: > > Here's the link to t...



___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Eric Mill]

You are awesome! I'm gonna switch my Camping app to passenger and test it
out at the next opportunity.

-- Eric

On Jul 20, 2009 8:12 PM, "Roland Crosby"  wrote:

OK, I updated the Dreamhost wiki and
http://wiki.github.com/why/camping/camping-on-shared-hosting with a
configuration that worked for me - other people using Dreamhost and/or
Passenger, let me know if
this works for you, or if there are other tips and tricks that you suggest.
Roland

On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill  wrote: >
> Here's the link to t...

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Roland Crosby]

OK, I updated the Dreamhost wiki and
http://wiki.github.com/why/camping/camping-on-shared-hosting with a
configuration that worked for me - other people using Dreamhost and/or
Passenger, let me know if
this works for you, or if there are other tips and tricks that you suggest.
Roland

On Mon, Jul 20, 2009 at 2:57 PM, Eric Mill  wrote:

> Here's the link to the page on the Dreamhost wiki:
>
> http://wiki.dreamhost.com/Camping
>
> -- Eric
>
> On Mon, Jul 20, 2009 at 2:55 PM, Eric Mill wrote:
> > Please add it to the Camping on Shared Hosting wiki page - on both the
> > Camping Github wiki, and the Dreamhost wiki.  I wrote the Dreamhost
> > section of the former, and the entirety of the latter, after much
> > agony making FastCGI work, and I'd love to see a simpler way
> > documented.
> >
> > -- Eric
> >
> > On Mon, Jul 20, 2009 at 2:21 PM, Roland Crosby
> wrote:
> >> I don't know if this has been documented anywhere, but last night I had
> a
> >> surprisingly easy time deploying a Camping 2.0 app to my basic DreamHost
> >> shared hosting account. After fighting with FastCGI for a while, I
> noticed
> >> that there's an option to point the root of a domain or subdomain at a
> >> "Rails" app's public/ directory and use Phusion Passenger. Once I made
> such
> >> a directory, and a basic config.ru file to set the gem paths correctly
> and
> >> run the app, it seemed to work just fine. Granted, the app is dead
> simple
> >> (one file, no database), so I don't know if this configuration would
> break
> >> if I changed anything, but I thought it was worth mentioning.
> >>
> >> I can add this to the Camping on Shared Hosting wiki page, if nobody
> knows
> >> of any huge caveats to deploying this way.
> >>
> >> Roland
> >>
> >> ___
> >> Camping-list mailing list
> >> Camping-list@rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/camping-list
> >>
> >
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Eric Mill]

Here's the link to the page on the Dreamhost wiki:

http://wiki.dreamhost.com/Camping

-- Eric

On Mon, Jul 20, 2009 at 2:55 PM, Eric Mill wrote:
> Please add it to the Camping on Shared Hosting wiki page - on both the
> Camping Github wiki, and the Dreamhost wiki.  I wrote the Dreamhost
> section of the former, and the entirety of the latter, after much
> agony making FastCGI work, and I'd love to see a simpler way
> documented.
>
> -- Eric
>
> On Mon, Jul 20, 2009 at 2:21 PM, Roland Crosby wrote:
>> I don't know if this has been documented anywhere, but last night I had a
>> surprisingly easy time deploying a Camping 2.0 app to my basic DreamHost
>> shared hosting account. After fighting with FastCGI for a while, I noticed
>> that there's an option to point the root of a domain or subdomain at a
>> "Rails" app's public/ directory and use Phusion Passenger. Once I made such
>> a directory, and a basic config.ru file to set the gem paths correctly and
>> run the app, it seemed to work just fine. Granted, the app is dead simple
>> (one file, no database), so I don't know if this configuration would break
>> if I changed anything, but I thought it was worth mentioning.
>>
>> I can add this to the Camping on Shared Hosting wiki page, if nobody knows
>> of any huge caveats to deploying this way.
>>
>> Roland
>>
>> ___
>> Camping-list mailing list
>> Camping-list@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: Easy deployment on DreamHost with Phusion Passenger

[Eric Mill]

Please add it to the Camping on Shared Hosting wiki page - on both the
Camping Github wiki, and the Dreamhost wiki.  I wrote the Dreamhost
section of the former, and the entirety of the latter, after much
agony making FastCGI work, and I'd love to see a simpler way
documented.

-- Eric

On Mon, Jul 20, 2009 at 2:21 PM, Roland Crosby wrote:
> I don't know if this has been documented anywhere, but last night I had a
> surprisingly easy time deploying a Camping 2.0 app to my basic DreamHost
> shared hosting account. After fighting with FastCGI for a while, I noticed
> that there's an option to point the root of a domain or subdomain at a
> "Rails" app's public/ directory and use Phusion Passenger. Once I made such
> a directory, and a basic config.ru file to set the gem paths correctly and
> run the app, it seemed to work just fine. Granted, the app is dead simple
> (one file, no database), so I don't know if this configuration would break
> if I changed anything, but I thought it was worth mentioning.
>
> I can add this to the Camping on Shared Hosting wiki page, if nobody knows
> of any huge caveats to deploying this way.
>
> Roland
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Easy deployment on DreamHost with Phusion Passenger

[Roland Crosby]

I don't know if this has been documented anywhere, but last night I had a
surprisingly easy time deploying a Camping 2.0 app to my basic DreamHost
shared hosting account. After fighting with FastCGI for a while, I noticed
that there's an option to point the root of a domain or subdomain at a
"Rails" app's public/ directory and use Phusion Passenger. Once I made such
a directory, and a basic config.ru file to set the gem paths correctly and
run the app, it seemed to work just fine. Granted, the app is dead simple
(one file, no database), so I don't know if this configuration would break
if I changed anything, but I thought it was worth mentioning.

I can add this to the Camping on Shared Hosting wiki page, if nobody knows
of any huge caveats to deploying this way.

Roland
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: deployment

[Matt Zukowski]

Maybe have a look at http://code.google.com/p/camping-picnic/
Among other functionality, Picnic
gives you a myapp-ctl wrapper script around your camping app that takes care
of starting and stopping mongrel. Writing an init.d script around the
myapp-ctl script is pretty trivial.

Otherwise using mongrel_cluster to start up your app is probably your best
choice. That's what we did before we switched to passenger.

On Wed, Jun 3, 2009 at 10:24 AM, David Susco  wrote:

> I have a few camping apps I'd like to start automatically if my server
> ever restarts. There's an init.d file that comes with mongrel_cluster
> that you can use for rails apps, is there anything out there for
> camping apps though?
>
> With the postamble containing all the configuration for the app, it
> seems that all the init.d file would have to do is execute the camping
> file. Has anyone done this/have any pointers?
>
> --
> Dave
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: deployment

[David Susco]

I haven't looked into Rack in depth, is there a camping/rack/mongrel
tutorial out there?

Dave

On Fri, Jun 5, 2009 at 1:54 AM, Jonathan Groll wrote:
> Hi David,
>
> On Wed, Jun 03, 2009 at 10:24:01AM -0400, David Susco wrote:
>>
>> I have a few camping apps I'd like to start automatically if my server
>> ever restarts. There's an init.d file that comes with mongrel_cluster
>> that you can use for rails apps, is there anything out there for
>> camping apps though?
>>
>> With the postamble containing all the configuration for the app, it
>> seems that all the init.d file would have to do is execute the camping
>> file. Has anyone done this/have any pointers?
>
> I know this is not exactly what you're asking since your question was
> mongrel based, but if you were to look at running camping 2.0 with
> passenger/rack you would get automatic restarts as well as working
> redirects. Plus you'd be able to also easily deploy rails apps (and
> even some python apps) with the same setup.
> Cheers,
> Jonathan
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Dave
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: deployment

[Jonathan Groll]

Hi David,

On Wed, Jun 03, 2009 at 10:24:01AM -0400, David Susco wrote:

I have a few camping apps I'd like to start automatically if my server
ever restarts. There's an init.d file that comes with mongrel_cluster
that you can use for rails apps, is there anything out there for
camping apps though?

With the postamble containing all the configuration for the app, it
seems that all the init.d file would have to do is execute the camping
file. Has anyone done this/have any pointers?


I know this is not exactly what you're asking since your question was
mongrel based, but if you were to look at running camping 2.0 with
passenger/rack you would get automatic restarts as well as working
redirects. Plus you'd be able to also easily deploy rails apps (and
even some python apps) with the same setup. 


Cheers,
Jonathan
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

deployment

[David Susco]

I have a few camping apps I'd like to start automatically if my server
ever restarts. There's an init.d file that comes with mongrel_cluster
that you can use for rails apps, is there anything out there for
camping apps though?

With the postamble containing all the configuration for the app, it
seems that all the init.d file would have to do is execute the camping
file. Has anyone done this/have any pointers?

-- 
Dave
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: "no camping required" deployment?

[Lennon Day-Reynolds]

On 2/11/07, Bil Kleb <[EMAIL PROTECTED]> wrote:
> So, I'm thinking either a stand-alone executable (via
> RubyScript2Exe?) or a set of static HTML pages they could
> load locally?

I've used both RubyScript2Exe and Exerb in the past, and actually had
quite-good results. It's been a while since I had to support Windows
deployment, but if I recall correctly, RubyScript2Exe offered somewhat
simpler packaging, while Exerb allowed for much smaller .exe files,
since you could use a compressor like UPX on the "core" image files it
used to shrink them considerably.

(Again, it's been at least two years since I really had to think about
any of this, though, so I'd check out both projects and see where
they've gone in the meantime.)

RS2E does have the additional advantage of being cross-platform, so if
you anticipate having any need to support Linux or Mac OS users, it
would be the obvious choice.

Good luck,

Lennon
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: "no camping required" deployment?

[Eric Mill]

You can just include the camping library alongside the app.  Put
camping.rb (and maybe the folder 'camping' that has some helper
scripts for sessions, webrick, etc.) in the same directory as your
main .rb file.  In your script, when you say "require 'camping'" it
will load Camping from there, instead of looking for the gem.  If you
remove "require 'rubygems'" from your script, you can test it on your
machine to make sure it's working, without uninstalling the gem.

-- Eric

On 2/11/07, Bil Kleb <[EMAIL PROTECTED]> wrote:
> Hi,
>
> So Lennon got me going with my database-less Camping app,
> but I've just realized that, I have no deployment strategy.
>
> This app is to provide a GUI front end to our FUN3D fluid
> flow simulation monster, which is used by ourselves, companies,
> universities, hobbyists, and the military.  The end result
> of which, is a file of (key, value) pairs read by FUN3D.
>
> Requiring our users to have Camping installed is too much
> to ask.  While we could host the Camping app, the hassle
> of getting it approved by our IT folks is daunting, and
> requiring an Internet connection is troublesome for our
> black-world users.
>
> So, I'm thinking either a stand-alone executable (via
> RubyScript2Exe?) or a set of static HTML pages they could
> load locally?
>
> Any other suggestions?
>
> Thanks,
> --
> Bil Kleb
> http://fun3d.larc.nasa.gov
>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

"no camping required" deployment?

[Bil Kleb]

Hi,

So Lennon got me going with my database-less Camping app,
but I've just realized that, I have no deployment strategy.

This app is to provide a GUI front end to our FUN3D fluid
flow simulation monster, which is used by ourselves, companies,
universities, hobbyists, and the military.  The end result
of which, is a file of (key, value) pairs read by FUN3D.

Requiring our users to have Camping installed is too much
to ask.  While we could host the Camping app, the hassle
of getting it approved by our IT folks is daunting, and
requiring an Internet connection is troublesome for our
black-world users.

So, I'm thinking either a stand-alone executable (via
RubyScript2Exe?) or a set of static HTML pages they could
load locally?

Any other suggestions?

Thanks,
--
Bil Kleb
http://fun3d.larc.nasa.gov

___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list