Re: setting up the SQLite database
Hi, Just a comment: I don't think it's a good practice to set the database details (establish_connection() call) in the application itself. It's an environmental issue, and this way you lose the possibility to move your app between dev, ((devtest)), (test) and production environments without modifications. On Tue, May 15, 2012 at 7:39 PM, Dave Everitt dever...@innotts.co.ukwrote: I know this isn't Python, but I'd like to get a view on the 'one obvious' way to set up an SQLite (or other) database and its location per-app. I've got a bit lost with the Camping 2 changes and various code snippets I have kicking around. 1. is it best to set up the DB creation/connection: 1.1 at the end of the app AppName::Models::Base.**establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/myApp.db' ) run AppName #from an old snippet 1.2 OR like this (postgres) example [Magnus]: def List.create List::Models::Base.establish_**connection( :adapter = postgresql, :username = root, :password = toor, :database = list ) List::Models.create_schema end 1.3 in a config/database.yml file [Magnus] (probably not worth it for SQLite): --- adapter: postgresql username: root password: toor database: mycampingdb And then do: require 'yaml' def AppName.create AppName::Models::Base.**establish_connection(YAML.** load(File.read(database.yml)**)) AppName::Models.create_schema end 2. since sqlite is the default, is it necessary to set :adapter explicitly if that's what I'm using? def AppName.create AppName::Models::Base.**establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/.camping.db' ) end 3. Since .create is *only needed once* to set up the database (Magnus: if you connect to a database which already has the tables, DON'T run `AppName::Models.create_**schema` as this will probably delete the whole database.) what do we do with this after the first run: def AppName.create AppName::Models.create_schema end 3.1 delete it after the db is created on the first run? 3.2 check if the db already exists (best way, please)? 3.3 check like this (never understood ':assume'?): AppName::Models.create_schema :assume = (AppName::Models:: table_name.table_exists? ? 1.0 : 0.0) or could we do something simpler like (?): AppName::Models.create_schema unless table_exists?(table_name) ? 4. There's also this from a previous post (opinions please?): On the part of migrations ... def self.up and def self.down ... gave me errors for some reason. But ... it should be updated to def self.change ... that's the modern way of doing it. DaveE __**_ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/**listinfo/camping-listhttp://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping + Couch DB
Hi, In a previous thread I was declared as a newbie end user, now I'll behave like that :) If I'll use the hosting service, I'll want to be able to use mysql and not sqlite, and other experimental solutions. You can say that this is silly of me, but, as an end user, I have the right to be silly. BTW I have bad experience with sqlite. It can happen that the database becomes corrupted somehow, maybe because of not properly handled concurrent accesses, or a ctrl-c in a bad moment, I don't know. And mysql is faster too. As a silly end user I would prefer a separately existing permanency layer. This is not a problem for active record, so I really don't get it why not to use it. (It would be enough to have one database for all the users and let the databasename_tablename structured tablenames solve the rest. Actually the users don't need to know where is the data stored and how, just use the ActiceRecord API, but they need to know that it's fast enough and the data is securely stored.) I'm sorry, I know I was not really constructive... ...end users are always silly... ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: framework size, forking etc.
On Mon, Apr 16, 2012 at 5:40 PM, Dave Everitt dever...@innotts.co.ukwrote: I'm not too bothered about 3k. But I think what Nokan's saying is that he'd like Camping to remain functioning as it is so he can continue to run his apps as they're set up now, but that extra features could be added with an optional `require 'camping/new_extra_stuff`... - Nokan, is this correct? Although I've no practical idea about how this might best be achieved - DaveE Exactly. That's what I wanted to say. I don't really care about the 3k, however it is charming for me. What I like in Camping is the simplicity. I don't need to be up-to-date in new inventions like in Rails. What I've learnt about Camping N years ago that's still true and works. It's enough if I have a massive Ruby knowledge and I'll be able to solve anything that comes up. Sometimes it is a bit too simple, sometimes it's not logical, and I can understand that people want it to be more supportive while working with it. If you could somehow make the shiny new version an extension of the existing one, then you could keep the 3k (or 4k) limit, and serve the needs of the extra features at the same time. Of course I don't know how to do it, or if it is possible at all. The source of Camping is something that I don't want to see again. :) u. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: framework size, forking etc.
I would leave the name camping for the original gem, and would choose another one for the fork. But exactly what are those features that you (all) would like to add to camping? - before/after methods of controllers, - something around serving static files and R(), - ??? Actually I think it's not logical that you can build HTML by default using Markaby, but you can't build CSS in the same way. And I hate the trick with __END__ and appended CSS code. It's not good if you require your app into a production environment, for example. u. 2012/4/16 Isak Andersson icepa...@lavabit.com ** Like I've kind of said. I don't want the history of camping to disappear. But I do want to move forward. I'd say create a classic branch and put it in a camping-classic gem. And then move on with New extra bossy beef Camping for real enterprise jungle guns! (?) Cheers! Isak Andersson Jenna Fox a...@creativepony.com skrev: So the 3kb thing is pretty important to you? Anyone else feel the same way? :) — Jenna On Monday, 16 April 2012 at 10:17 PM, Nokan Emiro wrote: Hi, As a simple user of Camping I would prefer to have a classic and a modern one. in one gem or in separate ones, that's not an issue. I would like to use the old one without modifications in my apps, and if I need extra features, I can uncomment/inser a line like this: require 'camping' require 'camping/session' # require 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc' Camping.goes :MyApp module MyApp ... But it's just a feature request... u. 2012/4/15 Isak Andersson icepa...@lavabit.com ** Ah, no I didn't mean maintaining two versions. Just making sure that everything in current Camping works as it should (not sure it does, my migrations aren't happening) and then freeze it. Call it Camping classic and then re-write it to be well designed for extensibility. With readable code and all. The names for things in our methods should be more then one character lång when we aren't worrying about size anymore. Cheers! Isak Andersson david costa gurugeek...@gmail.com skrev: Hi all :) I have been playing with Sinatra a lot lately and perhaps *some* things are done easily there (URL mapping, static files) but being a DSL and not a framework it is a bit different. For many things camping does the job very well and overall I find it a more comprehensive solution than Sinatra. For the classic/new versions I think the issue would be if the main code maintainer (Magnus) should decide if he is willing to do that. Of course other people could do that too but it would still be two versions to maintain or, if you are freezing camping-classic as it is it should at least have a light maintenance that ensures that it would still works fine. Everyone can fork (e.g. camping-couch is a gem with couch db and no active record) the only issue is maintenance and build momentum about it ! Regards David On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson icepa...@lavabit.comwrote: Right. We could just have a branch called classic on github. Leaving everything untouched. And then change the gem name to camping-classic or something. Maybe we should rewrite it afterwards (kind of). And make it backwards compatible with Camping applications. Just make the infrastructure simple and minimalistic. And make it easy to extend and configure. I think this would be the best thing ever for Camping more or less. Cheers! Isak Andersson Philippe Monnet r...@monnet-usa.com skrev: On one hand everyone is free to fork anything to change radical direction. This would allow for the size and some design constraints to be eliminated. But on the other hand, at this point in time (since we are the new community) shouldn't we free ourselves from the original constraints and just ignore the size aspect? I personally think so. It does not mean we have to go crazy and make it large and complicated (like Rails). With the source being on Github, we can just designate the current version as the classic (super micro version) and document very explicitly that from now on we will be free of these constraints and explain how people can still get the classic version. Since the framework has proven extremely stable and resilient, this would not prevent any tinkerer who needs the classic version to just do so. Although it has been fun to reference the size when talking about Camping, keeping it reasonably simple and small is good enough for me. ... free free set them free ... On 4/13/2012 9:55 AM, Isak Andersson wrote: I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should
Re: http_referrer
I'm totally convinced... so I'm going to download the whole source before the guys start to rewrite it as a modern framework... :) But to be frank, this, for instance, is not so great to read: https://github.com/camping/camping/blob/master/lib/camping.rb I mean I'm big http://catseye.tc/ fan, but when I'm working on a site, it's not a big flash to try to find out something from that ~ camping.min.rb u. On Mon, Apr 16, 2012 at 10:23 PM, Philippe Monnet r...@monnet-usa.comwrote: Everything I actually learned about Camping was by reading the source code as it is quite a feat of engineering. And I learned a ton about metaprogramming too. So it can be quite interesting. :-) On 4/16/2012 12:41 PM, Nokan Emiro wrote: Actually env[] works with mongrel also, not just fcgi or passenger. (No, it's not a typo: env, and not ENV. But I'm sure ENV works too.) Yes, env inside Camping is the same @env (it's just an attr_accessor). Same for @body, @request, @method, @status etc: https://github.com/camping/camping/blob/75f1144b7c9f53948d887d331a4f583a3b86a74f/lib/camping-unabridged.rb#L257 Hmmm, maybe I should read through this commented version of source code. ___ Camping-list mailing listCamping-list@rubyforge.orghttp://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: framework size, forking etc.
Shit! If you told me about it a few hours ago, I wouldn't bother myself
writing a RobotsTxt Controller...
__END__
@@ /style.css
* { margin: 0; padding: 0 }
And Camping will serve it for you. See also:
https://github.com/camping/camping/blob/master/test/app_file.rb
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: sites powered by Camping
Hi, I have been working on this in the last ~2.5 weeks: http://rapiddatingmalta.com (Yes, I know I'm slow... :- ) On Thu, Apr 12, 2012 at 12:14 AM, Dave Everitt dever...@innotts.co.ukwrote: I know. That's why it says Look. I haven't done this yet, okay? Give me a break. :-) I spent most of the afternoon checking and tidying up the other links and the app. But they will come! I have quite a few links I haven't put up yet. Meanwhile, if you know of any, please reply to this and send them... DaveE The tab Sites using Camping is empty :) ___ 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
sites powered by Camping
Hi List, What about creating a section on the Camping site, where you list and link sites that were built using Camping? Of course just those ones that are good enough. It would show the public that it's a working framework, so it's good for the community. On the other hand it's good for the linked page too, it gets visitors and a bit boost of page rank. u. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: sites powered by Camping
Hi, The tab Sites using Camping is empty :) I mean no more than 0 links are there. On Wed, Apr 11, 2012 at 2:13 PM, Dave Everitt dever...@innotts.co.ukwrote: I've been collecting Camping links for some years, including 'sites built with', and started sorting them here (the site's not permanent, and will win precisely zero design awards - I'm also using it to test the 'Camping server' service): http://dave.camping.sh/ If anyone wants to: * send new links, * correct outdated ones with updated code (pastebin?) Please reply to this topic on the mailing list and I'll collect them temporarily on the above site. Jenna, if you point me to a file on the Camping site I'll maintain these links on it, and add the ones already on the Camping wiki. DaveE I don't think we should ever consider pagerank in decision making. Sounds like a nice idea otherwise tho. Does anyone want to maintain a page like that? — Jenna Fox ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: http_referrer
Starship Enterprise, Stardate #{Time.now.to_f}. Captain's Log.
network.http.sendrefererheader was set to 0 in my Firefox for unknown
reasons.
Probably Mr Spock, the Chief of security did this.
I make this log entry for those who don't want to spend hours in a
spacedock repairing a working application.
Signing out...
On Sat, Apr 7, 2012 at 6:06 PM, Nokan Emiro uzleep...@gmail.com wrote:
Why does it work without the @ for me?
On Fri, Apr 6, 2012 at 4:26 PM, Magnus Holm judo...@gmail.com wrote:
It should be in @env:
@env['HTTP_REFERER']
(Note that it's misspelled in the spec)
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: http_referrer
Why does it work without the @ for me? On Fri, Apr 6, 2012 at 4:26 PM, Magnus Holm judo...@gmail.com wrote: It should be in @env: @env['HTTP_REFERER'] (Note that it's misspelled in the spec) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
~ AppController
Hi, What's the nice and preferred way to run a snippet of controller code before all other normal controllers can do something? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
http_referrer
Hi, How can I access the Rack request object in a controller? I need to know the HTTP_REFERRER, but I can't find it in env. (I'm sure I need glasses, or have to sleep more...) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: http_referrer
I'm sorry bothering you, it was there in env, env['HTTP_REFERER']. (But it still would be useful sometimes to access the Rack's Request object...) On Fri, Apr 6, 2012 at 3:01 PM, Nokan Emiro uzleep...@gmail.com wrote: Hi, How can I access the Rack request object in a controller? I need to know the HTTP_REFERRER, but I can't find it in env. (I'm sure I need glasses, or have to sleep more...) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
Hi, As I already mentioned I use Camping with fcgi in production. If It is your choice (and not passenger), I will help you set it up. On Sun, Apr 1, 2012 at 5:49 PM, david costa gurugeek...@gmail.com wrote: Hello again ! :) well in theory we can chrot jail users but the best way is to install the gems that people need perhaps the most used ones. It will then work system wide ! The big question is who will be your typical user. If is someone you trust then you can give them even limited ssh + sftp :) Back to my ignorance: how do you folks run camping in a server ? do you use fcgi ? At work we used to run a fairly big production environment made of rails running with lighthtp and fcgi. If we were to run this as a dead simple fcgi setup did anyone set this up? I have tried all the instructions github on how to set this up with dispatcher.fcgi but failed miserably. I would can get the server installed + fcgi but how to run camping apps from there is a bit of a mystery. I am slightly frustrated because of passenger not making a simple create page/test page http://camping.sh/ working. I know is not the app as it works at http://camping.sh:3301/ Unicorn: I think you would be back to have nginx as a reverse proxy for that which can present some problems for example, default port is 3301 for camping. So you would need a script to check which port is free and run then camping --port so seems a bit complicated. Thanks David On Sun, Apr 1, 2012 at 2:38 PM, Isak Andersson icepa...@lavabit.comwrote: Okay then. But then we'd make sure that the applications don't have privilege to install gems then. -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: @Isak Anything run with the `backticks operator` runs with the same privileges as the process which launched them, if using system level sandboxing, or if using some crazy sandbox built in to ruby (which probably wouldn't be very good, but maybe good enough) it'd probably just disable backticks feature. On 01/04/2012, at 9:31 PM, Isak Andersson wrote: Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. — Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. — Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa gurugeek...@gmail.com wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at
Re: dead easy deployment / Camping on the fly
I really want to know what gems do you (all out there) think quality... Maybe there's a statistics from a big gem server which ones are the most wanted. What about the versions? Applications can work differently (or not work :- ) with different versions of gems (and ruby). Will the hosting server allow to open connections to other hosts for the uploaded apps? It is also dangerous like backtick/system calls. But if it's banned, lots of gems are excluded. 2012/4/1 Isak Andersson icepa...@lavabit.com ** Well. Isn't it kind of possible to just hack the gem installation in using the ruby quotes that execute code on the system. I can't type them on the phone but I think you know what I mean. Kind of a security issue isn't it? Anyways. Perhaps we could offer some Gems to pick from that we think are quality! (rack_csrf, scrypt). -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: I don't think we need to go as far as automatically installing gems - securing ruby is a pretty big challenge, but securing gcc? no way. — Jenna On Sunday, 1 April 2012 at 8:25 PM, Isak Andersson wrote: Remember that we should pretty much make a Gemfile mandatory if the user makes use of gems other than Camping. For example, rack_csrf. And we should make sure that dependencies get installed. :) -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. Jenna Fox a...@creativepony.com skrev: Hm. I know the main guy responsible for App Engine, and, well, I certainly wouldn't build a platform atop it - even aside from the huge glaring issue that to have an app which can store data persistently, you need to use google's proprietary database software. Heroku doesn't screen against abuse at all. Heroku is not a 'shared hosting' provider. Their systems use the very finest jailing techniques to lock the ruby process in to it's own little world. It has no writable filesystem and it can only read what it absolutely needs to be able to read to function. All data storage happens over the network on separated database servers. The only type of abuse they need to be weary of is people using their servers to do illegal things - bullying, sharing illegal content, that sort of thing. They deal with that the same way any provider does - wait till someone makes a complaint. Matz, inventor of ruby, works for heroku making exactly this sort of stuff work extremely well. Still, it's not as friendly as it could be, and I personally think the trade offs on heroku are not very good for beginners (you have to use a complex database system, and cannot use the filesystem to store anything but static assets). Good work getting this server up David! I'm pretty excited. It sounds like you're having some pretty annoying deployment issues. As it's being quite a hassle, perhaps we should be thinking more deeply about creating our own special server for this task - something like the modified unicorn I mentioned earlier somewhere. — Jenna On Sunday, 1 April 2012 at 6:23 PM, Peter Retief wrote: Wonder if Google might help getting camping to run on app engine? On 1 April 2012 10:03, david costa gurugeek...@gmail.com wrote: Ah I forgot you can compare camping running on thin here http://run.camping.io:3301/ vs passenger at http://run.camping.io apparently db has some problems with fusion passenger (see http://run.camping.io create HTML page and test HTML page. The same code on thin works just fine... umhh oh no don't feel like more debugging ): On Sun, Apr 1, 2012 at 9:51 AM, david costa gurugeek...@gmail.comwrote: 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
Re: dead easy deployment / Camping on the fly
On fastcgi - fastcgi is not a server in itself - you cannot connect to it with a web browser. Like Passenger, it's a way for a server like nginx or apache to launch and talk to processes which return webpages directly. FastCGI IS a server in itself - you can connect to it, but not with a web browser. It's because it uses a protocol called fastcgi, not http. (The easiest way to interact with it is to use the cgi-fcgi command from command line...) It is not necessary to use the webserver to launch the fcgi processes, they can be configured just to connect to these servers, and you can run them whatever way you want. (I use simple init scripts for this purpose, but in a specialized hosting environment you must build a launcher for them, that handles new uploads, handles broken scripts (those that die after starting), and this system has to manage with ports associated with users, like in the case of using thin and reverse proxies.) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: dead easy deployment / Camping on the fly
Hi,
I run a few Camping apps in production with Rack's FastCGI handler.
This way it is completely separable from the webserver, which can be
nginx, apache, lighttpd, or anything else that implements the FastCGI
protocol. On top of that it's more scalable, because you can run these
processes on different machines -- if you feel so.
...just an idea to think about, but better than using reverse proxies.
On Sat, Mar 31, 2012 at 4:29 PM, david costa gurugeek...@gmail.com wrote:
Hello Jenna !
I think that run rack applications the most efficient way seems to be
phusion passenger that works with apache and nginx. It might work with
other setups but it is not documented.
The other alternative to serve a camping application is to use a standard
ruby webserver (thin, unicorn, etc.) and use either apache or nginx as
reverse proxy. This should be more resource consuming as you would have
both a thin/unicorn instance running and nginx. The setup of passenger +
apache seems to be very easy as you just drop the file with the camping app
and it works. It can't really get more easier than this.
The camping file has to be called config.ru
http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand
this is the only way it works on my tests but I am sure that there is
an easy way to work with several files or in a different way.
Now if we want to use webdav apache has the module and with a digest
authentication over ssl should be fairly secure. It also allows to limit
the upload file size which could be useful (e.g. if someone is obviously
trying to upload not a camping file !).
This is what I found so far as a possible solution but I am open to
anything. I did try also an image that was using git/capistrano for remote
deployment but somehow seemed an overkill to me and it didn't really work.
All I am doing is highly experimental so I am more than happy to see other
idea/possibilities and see how far I can go with it.
I did think about webdav based on your idea which I think would make this
different than heroku etc. like some beginners would not know git and might
just like a little tent for their shiny camping app !
David
On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox a...@creativepony.com wrote:
Apache? What are your thoughts on that choice I am curious? :)
—
Jenna
On Sunday, 1 April 2012 at 12:27 AM, david costa wrote:
Thank you :D as soon as the DNS will propagate it should be live.
Some updates: now added the design from camping.io (working on the
fonts) and I have narrowed down the probably easiest/best way to do it:
using Webdav module on apache. So there will be no issue with creating
real server users and it should really be easily accessible by anyone,
anywhere. Working on some securities configurations to be sure that it
works fine!
On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com wrote:
@David - sorted, both those subdomains now point to your machine. :)
—
Jenna
On Saturday, 31 March 2012 at 4:10 PM, david costa wrote:
BTW if you want to point a run.camping.io or host.camping.io or
anything you like to 66.116.108.12 will then be able to show an
(hopefully) working demo using the official domain ;)
On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.comwrote:
oh sure ! for me is not a problem - love camping.io as a domain !
first worry is to have a working system that is fairly stable and usable
albeit it might be launched as alpha/beta anyway :)
On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote:
We can just use a *.camping.io catchall entry
On 31/03/2012, at 3:30 PM, david costa wrote:
Hello Jenna,
we could use host.camping.io or anything.camping.io for the frontend but
if the server has to allow users to create myfancyapp.camping.io it
would be complicated as I would need to run the camping.io DNS on the
hosting server to create the sub domains on the fly. I started working on
it more details on a separate email.
I love your idea about the key-value database how can we implement this ?
Thanks
David
On Sat, Mar 31, 2012 at 12:21 AM, Jenna Fox a...@creativepony.com wrote:
Those both sound like brilliant servers! I'm not laughing at all. If my
mac mini is good enough for sky rim, it's good enough for web hosting for
sure!
Can we just use camping.io?
I think starting simple is a good idea. Databases are pretty cool among
web developers for various reasons, but I think are totally unnecessary for
most smaller experimental applications. For a beginner, I'm inclined to
have key-value databases. A really simple key-value database would work
like this:
sections = key.hash.to_s(36).scan(/.{0,3}/)
sections.delete
Dir.mkdir sections[0…-1].join('/')
File.open(sections.join('/') + '-value', 'w') do |file|
file.write JSON.generate(value)
end
add in some file locking, and everything is pretty cool. It splits up the
kevin to a series
Re: dead easy deployment / Camping on the fly
This solution is almost the same as using reverse proxies, but between the nginx and the Rack/Camping app you don't need HTTP traffic, just FastCGI. That means you can save one layer in the application, you don't need a http server (thin, mongrel, etc.) that point. Rack is a native FastCGI speaker. However this is the only difference, in other ways it's the same as using reverse proxy. The webserver (nging) knows about the virtual hosts, and maps them into host:port pairs, where the appropriate FastCGI server (the Rack itself) listens for connections. You can call this reverse proxying too if you want, but in this case there are different protocols on the client side (http) and the server side (fcgi). On Sat, Mar 31, 2012 at 4:51 PM, david costa gurugeek...@gmail.com wrote: Thanks for this but how would it run for multiple users on the same port (80) like yourname.camping.io yourname2.camping.io without having nginx or apache as a reverse proxy ? On Sat, Mar 31, 2012 at 4:44 PM, Nokan Emiro uzleep...@gmail.com wrote: Hi, I run a few Camping apps in production with Rack's FastCGI handler. This way it is completely separable from the webserver, which can be nginx, apache, lighttpd, or anything else that implements the FastCGI protocol. On top of that it's more scalable, because you can run these processes on different machines -- if you feel so. ...just an idea to think about, but better than using reverse proxies. On Sat, Mar 31, 2012 at 4:29 PM, david costa gurugeek...@gmail.comwrote: Hello Jenna ! I think that run rack applications the most efficient way seems to be phusion passenger that works with apache and nginx. It might work with other setups but it is not documented. The other alternative to serve a camping application is to use a standard ruby webserver (thin, unicorn, etc.) and use either apache or nginx as reverse proxy. This should be more resource consuming as you would have both a thin/unicorn instance running and nginx. The setup of passenger + apache seems to be very easy as you just drop the file with the camping app and it works. It can't really get more easier than this. The camping file has to be called config.ru http://www.modrails.com/documentation/Users%20guide%20Apache.html#_campingand this is the only way it works on my tests but I am sure that there is an easy way to work with several files or in a different way. Now if we want to use webdav apache has the module and with a digest authentication over ssl should be fairly secure. It also allows to limit the upload file size which could be useful (e.g. if someone is obviously trying to upload not a camping file !). This is what I found so far as a possible solution but I am open to anything. I did try also an image that was using git/capistrano for remote deployment but somehow seemed an overkill to me and it didn't really work. All I am doing is highly experimental so I am more than happy to see other idea/possibilities and see how far I can go with it. I did think about webdav based on your idea which I think would make this different than heroku etc. like some beginners would not know git and might just like a little tent for their shiny camping app ! David On Sat, Mar 31, 2012 at 3:43 PM, Jenna Fox a...@creativepony.com wrote: Apache? What are your thoughts on that choice I am curious? :) — Jenna On Sunday, 1 April 2012 at 12:27 AM, david costa wrote: Thank you :D as soon as the DNS will propagate it should be live. Some updates: now added the design from camping.io (working on the fonts) and I have narrowed down the probably easiest/best way to do it: using Webdav module on apache. So there will be no issue with creating real server users and it should really be easily accessible by anyone, anywhere. Working on some securities configurations to be sure that it works fine! On Sat, Mar 31, 2012 at 2:52 PM, Jenna Fox a...@creativepony.com wrote: @David - sorted, both those subdomains now point to your machine. :) — Jenna On Saturday, 31 March 2012 at 4:10 PM, david costa wrote: BTW if you want to point a run.camping.io or host.camping.io or anything you like to 66.116.108.12 will then be able to show an (hopefully) working demo using the official domain ;) On Sat, Mar 31, 2012 at 7:08 AM, david costa gurugeek...@gmail.comwrote: oh sure ! for me is not a problem - love camping.io as a domain ! first worry is to have a working system that is fairly stable and usable albeit it might be launched as alpha/beta anyway :) On Sat, Mar 31, 2012 at 6:33 AM, Jenna Fox a...@creativepony.com wrote: We can just use a *.camping.io catchall entry On 31/03/2012, at 3:30 PM, david costa wrote: Hello Jenna, we could use host.camping.io or anything.camping.io for the frontend but if the server has to allow users to create myfancyapp.camping.ioit would be complicated as I would need to run the camping.io DNS on the hosting
Re: Camping into production
SCRIPT_NAME is the mount-path. PATH_INFO is the internal app-path. So if you want your application available at xxx.com/my_app/, then the request xxx.com/my_app/add will look like this: SCRIPT_NAME=/my_app PATH_INFO=/add If it's available at xxx.com/, then xxx.com/add will look like this: SCRIPT_NAME= PATH_INFO=/add Camping uses PATH_INFO for route dispatching and SCRIPT_NAME for route generating. In this case you probably want to explicitly set SCRIPT_NAME to . Thanks for these infos, it made everything clear. Actually Camping is not working in this way. My app has a whole domain, so it is the second case, where xxx.com/add is my Add controller's path. But I have to force / into SCRIPT_NAME to work. If SCRIPT_NAME is empty, Camping generates strange values on R(Add). Maybe this is a bug, I don't know, but this is what I discovered. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
how to catch 404s?
How can I hide/catch the Camping problem! /xxx not found pages? It would be great to define my own handler instead, or simply redirect to the root of my app. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping into production
It seems to me that PATH_INFO is still not properly handled, but that it's always empty. You are right, PATH_INFO is always empty. If I fill it with the $SCRIPT_NAME value, controllers can be accessed again. But links generated by R() are still wrong: a 'Add', :href = R(Add) on a page xxx.com/list goes to xxx.com/list/add, not to xxx.com/add . ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping into production
Hi, As you already know I'm working on turning my Camping app into production. Unfortunatelly I find lots of problems on my way. The next one is here: My Camping app does something dirty on the 'redirect CtrllerName' lines. The webserver serves https requests, and before I placed fastcgi_param HTTPS on; which passes these two params to the fastcgi application: HTTPS=on, rack.url_scheme=https, But my app fails on the first redirect line in my controllers: (eval):10:in `URL': undefined method `+' for nil:NilClass (NoMethodError) from (eval):15:in `redirect' from /home/bsanyi/MyApp.rb:53:in `post' from (eval):24:in `send' from (eval):24:in `service' from (eval):24:in `catch' from (eval):24:in `service' from (eval):34:in `call' from /usr/lib/ruby/1.8/rack/session/cookie.rb:37:in `call' from (eval):38:in `call' from /usr/lib/ruby/1.8/rack/content_length.rb:13:in `call' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:57:in `serve' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:25:in `run' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:24:in `each' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:24:in `run' MyApp.rb:53 is a `redirect ControllerName` line. What do I wrong? Redirects are working with different Rack handlers than FascCGI. And I'm sure it is related to the https, because before I switched HTTPS on in my webserver, redirect worked, but to http (not https) and port 443 - which was of course a wrong combination. Now Rack know about https, and my app seems to work until the first redirect. The same happens in ruby1.8 + ubuntu packages of rack and camping (and other necessary libs), and with ruby1.9.2 and the latest gems. The above error message is from 1.8. uzlee ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: run my Camping app as a Rack app
Thanks for the explanation. I have had the create method in my application, it calls Models::create_scheme, because I have migrations too. (Everything encapsulated, that's what I like about Camping.) Actually the problem with X.create was that my fastcgi-camping-server did not initialize any ActiveRecord connections, while the standard camping server did. After I placed this ActiveRecord::Base.establish_connection( :adapter = mysql, :host = localhost, :user = *, :password = **, :database = databasename ) before the X.create line, it worked fine. Anyway that generated a question. As you can see I replaced sqlite to mysql, and now I can see in the mysql database, that table names are in form of databasename_tablename, and I have an extra databasename_schema_infos table too. How can I turn this behavior off? It's not critical, but a bit ugly. uzlee On Tue, Oct 11, 2011 at 9:50 AM, Magnus Holm judo...@gmail.com wrote: Now that you have solved your real problem, let me explain this one too: X.create is purely a convention so you can write code that will run on startup inside your application. So you can write this in your application: def X.create # run migrations etc. end Then a proper Camping server (like your FastCGI-wrapper) will make sure to invoke X.create. Of course, a proper Camping server must also take care to handle applications that *don't* define X.create, so that line should actually look like this: # inside the server: X.create if X.respond_to? :create ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping into production
It has still the same 4 problematic lines:
s.date = %q{2011-10-11 00:00:00.0Z}
...
s.add_development_dependency(%qrake,
[#YAML::Syck::DefaultKey:0xb67fdb98 0.8.7])
...
s.add_dependency(%qrake, [#YAML::Syck::DefaultKey:0xb67fdb98
0.8.7])
...
s.add_dependency(%qrake, [#YAML::Syck::DefaultKey:0xb67fdb98
0.8.7])
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: run my Camping app as a Rack app
Yes, You are right, that works in this way. But this is a bit different what I want to do. rackup runs my Rack application in a webserver (webrick or mongrel), and I can't use orher handlers than these. I prefer to use Rack in a bit lower level. Suppose that in a standard Ruby script the object `obj` implements tha Rack interface. In this case I can simply run it in this way: require 'rack' Rack::Handler::WEBrick.run obj or require 'rack' Rack::Handler::Mongrel.run obj without all the magic of rackup. This has the advantage to use other handlers, not only WEBrick and Mongrel. I can user Rack::Handler::Thin, ...::CGI, and even ...::FastCGI. What I really want to do is to run my Camping app using the Rack::Handler::FastCGI. I would like to know how can I convert my Camping app into an object (module, class, lambda or anything else) in Ruby that implements the Rack interface, and I can push it to Rack::Handler::FastCGI.run(). If there is any other way to run a Camping app as a fastcgi, that can be also a good solution. -- uzlee 2011/10/9 Bartosz Dziewoński matma@gmail.com I'm not sure what are you trying to accomplish. Can't you just create a config.ru file like this: require './yourapp.rb' run YourApp And then use `rackup` to start the app? config.ru files are widely understood, the same thing works for example with mod_passenger or Heroku. -- Matma Rex ___ 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: run my Camping app as a Rack app
The app itself implements Rack protocol. Yes, that's what I've already tried. It is the case when my app stops whenever the first fastcgi request arrives: /usr/lib/ruby/1.8/rack/utils.rb:23:in `unescape': undefined method `tr' for nil:NilClass (NoMethodError) from (eval):33:in `call' from /usr/lib/ruby/1.8/rack/session/cookie.rb:37:in `call' from (eval):38:in `call' from /usr/lib/ruby/1.8/rack/content_length.rb:13:in `call' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:57:in `serve' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:25:in `run' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:24:in `each' from /usr/lib/ruby/1.8/rack/handler/fastcgi.rb:24:in `run' ... What I do here is: require 'camping' require 'camping/session' Camping.goes :App module App # . here is my Camping App end Rack::Handler::FastCGI.run App, :Port = 9000 ...and configure webserver to send fcgi queries to 9000. Is this a Rack problem? (In this case I'm sorry bothering you!) uzlee ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: run my Camping app as a Rack app
Are you running Apache? No, the webserver is nginx, and I use fastcgi to attach my apps into it. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: run my Camping app as a Rack app
Does it work the regular way? (via rackup) Yes, rackup makes my app run. In this case an other probleme occures, that is more Camping specific. The ActiveRecord cannot connect to any database. I think Camping makes some initialization before starting up my app, that is missing in this case. (I've tried to call App.create before the Rack handler, but it's not the right way.) Does it work your way, but with a different handler? Yes, with (for example) Rack::Handler::WEBrick works the same way as with rackup. I can connect to the app with my browser, but ActiveRecord fails to work. But I use Rack::Handler::FastCGI with other Rack apps, and it works. Which version of rack you're using? I tried it with ruby1.9.2 with the latest rack gem a few days ago, that was 1.3.4. It did not work, so I downgraded. Now I'm using ruby 1.8 and the standard librack-ruby1.8 package in Ubuntu. It's version is 1.1.0-4ubuntu1. -- uzlee ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
