Posted by Nick Sieger
Thu, 08 May 2008 17:31:00 GMT
Continuing in the spirit of Conference-Driven Development, I’m happy to announce the first public release of JRuby-Rack! You can use it to run Rails, Merb, or any Rack-compatible application inside a Java application server.
Also released today is Warbler 0.9.9, which has been updated to bundle JRuby-Rack.
In addition to providing as seamless a connection as possible between the servlet environment and Rack, JRuby-Rack (along with Warbler) is also bridging the gap between Ruby and Java web development. Some of the things it does are:
- Makes the Java servlet context and servlet request available to Ruby through special variables in the Rack environment
- Servlet request attributes from Java are passed through and available in the Rack environment. Request attributes can override Rack variables such as
PATH_INFO, QUERY_STRING etc.
- Configures Rails deployment options such as page caching directories and session handling automatically and optimally for the servlet environment.
I’ve also included the beginnings of some extensions that should help integrate Rails with existing Java web frameworks, servlets, JSPs, and other code. For example, you can invoke a Rails request from within a JSP with a tag:
<jruby-rack:rails path="/projects/activity" params="layout=none"/>
You can set servlet and session attributes and forward to other servlets and JSPs from your Rails controllers:
class DemoController < ApplicationController
def index
servlet_request["hello"] = "world!"
session["rails"] = "Visible to java!"
forward_to "/attributes.jsp"
end
end
and read them from within the servlet or JSP:
<dl>
<dt><tt>servlet_request["hello"] | request.getAttribute("hello")</tt></dt>
<dd><%= request.getAttribute("hello") %></dd>
<dt><tt>session["rails"] | session.getAttribute("rails")</tt></dt>
<dd><%= session.getAttribute("rails") %></dd>
</dl>
This is just the beginning of this kind of integration, and I’m interested where people take it. I think this provides a nifty way to start integrating Rails bits into existing applications or reuse existing Java web application code.
I’ve tagged the release with an 0.9 version number. I believe the bits are ready for serious use, but could use some help pounding out a few more bugs before calling it 1.0. So jruby -S gem install warbler today, try it out, and bring plenty of feedback to the JRuby user list!
Tags jruby, merb, rack, rails | 10 comments
Posted by Nick Sieger
Thu, 17 Jan 2008 23:48:00 GMT
Next up in our performance series: Builder::XChar. (Another fine Sam Ruby production!) While this piece of code in the Builder library strikes me as perfectly fine, it also tends to slow down quite a bit with larger documents or chunks of text.
Our path to the bottleneck is as follows: ActiveRecord::Base#to_xml => Builder::XMLMarkup#text! => String#to_xs => Fixnum#xchr. Consider:
require 'rubygems'
gem 'activesupport'
require 'active_support'
require 'benchmark'
module Benchmark
class << self
def report(&block)
n = 10
times = (1..10).map do
bm = measure(&block)
puts bm
bm
end
sum = times.inject(0) {|s,t| s + t.real}
mean = sum / n
sumsq = times.inject(0) {|s,t| s + t.real * t.real}
sd = Math.sqrt((sumsq - (sum * sum / n)) / (n - 1))
puts("Mean: %0.6f SDev: %0.6f" % [mean, sd])
end
end
end
page = File.open("page.xml") {|f| f.read }
Benchmark.report do
20.times { page.to_xs }
end
On Ruby and JRuby, this produces:
$ ruby to_xs.rb
21.430000 0.400000 21.830000 ( 22.022769)
21.530000 0.360000 21.890000 ( 22.005737)
21.540000 0.370000 21.910000 ( 22.065165)
21.530000 0.370000 21.900000 ( 22.028591)
21.500000 0.350000 21.850000 ( 21.990395)
21.550000 0.370000 21.920000 ( 22.033164)
21.520000 0.360000 21.880000 ( 21.984129)
21.550000 0.370000 21.920000 ( 22.116802)
21.550000 0.370000 21.920000 ( 22.051421)
21.520000 0.380000 21.900000 ( 22.084736)
Mean: 22.038291 SDev: 0.041985
$ jruby -J-server to_xs.rb
79.112000 0.000000 79.112000 ( 79.112000)
81.480000 0.000000 81.480000 ( 81.481000)
84.745000 0.000000 84.745000 ( 84.745000)
84.384000 0.000000 84.384000 ( 84.384000)
121.933000 0.000000 121.933000 (121.933000)
85.533000 0.000000 85.533000 ( 85.532000)
82.762000 0.000000 82.762000 ( 82.763000)
82.090000 0.000000 82.090000 ( 82.090000)
81.298000 0.000000 81.298000 ( 81.299000)
80.774000 0.000000 80.774000 ( 80.773000)
Mean: 86.411200 SDev: 12.635700
(Hmm, I must have accidentally swapped in some large program in the middle of that JRuby run. The perils of benchmarking on a desktop machine. I don’t claim that the numbers are scientific, just illustrative!)
Fortunately, the fix again is very simple, and has previously been acknowledged. The latest (unreleased?) Hpricot has a new native extension, fast_xs, which is an almost drop-in replacement for the pure-ruby String#to_xs. (Almost, because it creates the method String#fast_xs instead of String#to_xs. ActiveSupport 2.0.2 and later take care of aliasing it for you). Unbeknownst to me, I ported fast_xs recently as part of upgrading JRuby extensions that have Java code in them. And so it happens to come in handy at this time. The patch for that is here.
I have the latest Hpricot gems on my server, so you can install it yourself (for either Ruby or JRuby):
gem install hpricot --source http://caldersphere.net
or
jruby -S gem install hpricot --source http://caldersphere.net
With that installed, the script now produces these results:
$ ruby to_xs.rb
0.460000 0.080000 0.540000 ( 0.537793)
0.420000 0.070000 0.490000 ( 0.501965)
0.430000 0.070000 0.500000 ( 0.501359)
0.400000 0.070000 0.470000 ( 0.484495)
0.400000 0.070000 0.470000 ( 0.479995)
0.400000 0.070000 0.470000 ( 0.469118)
0.390000 0.070000 0.460000 ( 0.468864)
0.390000 0.070000 0.460000 ( 0.465009)
0.390000 0.060000 0.450000 ( 0.452902)
0.390000 0.070000 0.460000 ( 0.466881)
Mean: 0.482838 SDev: 0.024926
$ jruby -J-server to_xs.rb
0.882000 0.000000 0.882000 ( 0.883000)
0.832000 0.000000 0.832000 ( 0.832000)
0.851000 0.000000 0.851000 ( 0.850000)
0.837000 0.000000 0.837000 ( 0.837000)
0.846000 0.000000 0.846000 ( 0.846000)
0.843000 0.000000 0.843000 ( 0.843000)
0.835000 0.000000 0.835000 ( 0.835000)
0.825000 0.000000 0.825000 ( 0.826000)
0.830000 0.000000 0.830000 ( 0.830000)
0.834000 0.000000 0.834000 ( 0.833000)
Mean: 0.841500 SDev: 0.016379
Tags jruby, performance, rails, ruby | 3 comments
Posted by Nick Sieger
Tue, 06 Nov 2007 15:00:00 GMT
Just out is ActiveRecord-JDBC 0.6, the post-RubyConf release.
The sparkly new feature is Rails 2.0 support. In the soon-to-be-released Rails 2.0 (edge), Rails will automatically look for and load an adapter gem based on the name of the adapter you specify in database.yml. Example:
development:
adapter: funkdb
...
With this database configuration, Rails will attempt to load the activerecord-funkdb-adapter gem, require the active_record/connection_adapters/funkdb_adapter library, and call the method ActiveRecord::Base.funkdb_connection in order to obtain a connection to the database. (This is the mechanism used to off-load non-core adapters out of the Rails codebase.)
We can leverage this convention to make it easier than ever to get started using JRuby with your Rails application. So, the first thing new in the 0.6 release is the name. You now install activerecord-jdbc-adapter:
jruby -S gem install activerecord-jdbc-adapter
But wait, there’s more! We also have adapters for four open-source databases, including MySQL, PostgreSQL, and two embedded Java databases, Derby and HSQLDB. And, for your convenience, we’ve bundled the JDBC drivers in dependent gems, so you don’t have to go hunting them down if you don’t have them handy.
Check this out. Get a fresh copy of JRuby 1.0.2, unpack it, and add the bin directory to your path. Install the adapter:
$ jruby -S gem install activerecord-jdbcderby-adapter --include-dependencies
Successfully installed activerecord-jdbcderby-adapter-0.6
Successfully installed activerecord-jdbc-adapter-0.6
Successfully installed jdbc-derby-10.2.2.0
In your Rails application, freeze to edge Rails (soon to be Rails 2.0).
rake rails:freeze:edge
Re-run the Rails command, regenerating configuration files.
jruby ./vendor/rails/railties/bin/rails .
Currently, Rails 2.0 uses openssl for the HMAC digest used in the new cookie session store, so we have to install the jruby-openssl gem:
jruby -S gem install jruby-openssl
Now, update your config/database.yml as follows:
development:
adapter: jdbcderby
database: db/development
Re-run your migrations, and you should now see a Derby database footprint in the db/development directory.
$ ls -l db/development
total 24
-rw-r--r-- 1 nicksieg nicksieg 38 Nov 6 08:24 db.lck
-rw-r--r-- 1 nicksieg nicksieg 4 Nov 6 08:24 dbex.lck
drwxr-xr-x 5 nicksieg nicksieg 170 Nov 6 08:24 log/
drwxr-xr-x 65 nicksieg nicksieg 2210 Nov 6 08:24 seg0/
-rw-r--r-- 1 nicksieg nicksieg 882 Nov 6 08:24 service.properties
drwxr-xr-x 2 nicksieg nicksieg 68 Nov 6 08:24 tmp/
That’s it! To re-emphasize, to make your application run under JRuby, no longer will you need to a) find and download appropriate JDBC drivers, b) wonder where they should be placed so that JRuby will find them, or c) make custom changes to config/environment.rb. All that’s taken care of you if you use one of the following adapters:
activerecord-jdbcmysql-adapter (MySQL)activerecord-jdbcpostgresql-adapter (PostgreSQL)activerecord-jdbcderby-adapter (Derby)activerecord-jdbchsqldb-adapter (HSQLDB)
If you need to connect to a different database, you’ll still need to place your database’s JDBC driver jar file in the appropriate place and use the straight activerecord-jdbc-adapter. Also note that in this case, and for Rails 1.2.x in general, you’ll still need to add that pesky require statement to config/environment.rb.
As always, there are bug fixes too (though we haven’t been tracking exactly which ones are fixed). We’re starting to file ActiveRecord-JDBC bugs in the JRuby JIRA now, and will be putting in future AR-JDBC versions to target soon too. So, please file new bugs in JIRA (and select component “ActiveRecord-JDBC”) rather than in the antiquated Rubyforge tracker.
Tags activerecord, jruby, rails | 9 comments
Posted by Nick Sieger
Thu, 25 Oct 2007 03:36:00 GMT
People have been asking for a while how fast JRuby runs Rails. (Of course, “fast” has always been a relative term.) We haven’t been quick to answer the question, because frankly we didn’t know. We hadn’t been building real Rails applications on JRuby ourselves yet, and there was no definitive word from the crowd either.
Recently, several guys from ThoughtWorks have been working on a Rails petstore application and benchmark to get to the heart of the matter. Discussion has been heated on the JRuby mailing list, but results have not been conclusive yet.
In the project I’m working on, we’ve committed to using and deploying on JRuby. Eventually we were going to reach the point where we’d need to find out how well our application runs. So today I began running a simple single request benchmark on a relatively busy page. The numbers turned out to be rather surprising:
(The raw data is available here.)
Now, MRI (C Ruby) will always run about the same speed no matter how many runs you give it, but it’s well known that the JVM needs time to warm up. And indeed it does; after 250 iterations, Mongrel running on JRuby finally surpasses MRI. The JRuby/Goldspike/Glassfish combo comes close as well.
Some details about the setup:
- I ran the tests on my MacBook Pro Core 2 Duo 2.4 GHz. I didn’t disable one of the cores for the tests, which means that JRuby has an advantage over MRI because it can use both (native threads at work). However, the test script ran the requests serially, which means that the advantage was minimal.
- The application is indeed of the “hydra” variety; the setup is nearly identical to the second diagram on that page. So a single request is passing through not one, but two Rails applications in addition to touching the database. It rendered an HTML ERb view with data from an ActiveResource-accessed RESTful service. The applications are based on Rails 1.2.3.
- MRI version is using Ruby 1.8.6 and Mongrel 1.0.1.
- JRuby Mongrel is also version 1.0.1 (details on installing it here)
- JRuby on Glassfish used Glassfish 2 and Goldspike 1.4, deployed in war files via Warbler.
- The two JRuby setups used JDK 1.5 and were tweaked to disable ObjectSpace and use the “server” VM (-server argument to the JVM).
The main point I wish to make with these numbers is that JRuby performance is there today, and still has room to grow. There’s no longer any doubt in my mind. Yes, this is a simplistic application benchmark run on a developer’s machine, but it’s a real application. The test may not be exacting in precision, but I see enough in the numbers to believe that this will be replicable to production environments. The plot thickens!
Tags jruby, rails, ruby | 1 comment
Posted by Nick Sieger
Fri, 14 Sep 2007 05:33:00 GMT
Speaking of keeping busy, I’ll be speaking alongside my colleague Craig McClanahan at RailsConf Europe in Berlin next week.
Sun is a Diamond Sponsor at RailsConf again, just like in Portland last May. Part of that sponsorship money pays for a brief keynote spot (filled by Craig) as well as a session or two. So no, I didn’t get my spot through an accepted proposal submission, but that doesn’t mean that the session is going to be a big marketing shill.
No, actually Craig and I are part of a small group at Sun that’s embracing Rails in a big way, and we’re going to be launching a site built mostly on Rails later this fall. We’re taking what we think are some novel approaches to building a Rails-based application and we thought we’d share some of those thoughts with you rather than drone on for the session about how great Sun is and what snazzy tools we make. (Although expect to see a subtle plug or two for Sun hardware and tools. Call it product placement rather than overt selling.)
I titled the session “Rails Hydra” because the central idea of the structure of our application is not one Rails app, but many. The UI and views don’t even talk to a database; instead they make use of ActiveResource and RESTful web services, talking to the models living in other Rails applications in the backend. One key point is we’re deploying .war files to JRuby running on Glassfish, thus avoiding headaches of morbidly multiplying Mongrel math. We’ll elaborate on this arrangement and talk about some of the other tools and tricks we’re using.
Also, Charlie, Tom and Ola will be there, so we’ll certainly have a JRuby summit at some point. Stop by and say hello!
Posted in java | Tags gig, rails, railsconf | 1 comment
Posted by Nick Sieger
Tue, 04 Sep 2007 02:48:40 GMT
This week I was working on integrating the latest JRuby 1.0.1 and Goldspike 1.3 releases into our environment, when my frustration hit a fever pitch.
See, I had always thought that the .war packaging side of Goldspike was a little clunky and
un-ruby-like, but I didn’t see a clear path to fixing it. I had heard little complaints about it here
and there: the little configuration DSL didn’t give you enough control or wasn’t documented well
enough; the fact that it downloads libraries from the internet during assembly (convenient, but not
safe or reproducible for production deployments).
Also, in my own opinion it took the wrong approach to packaging Rails in a .war file. It puts the
Rails application directory structure into the root of the .war file where any web server or Java
application server might mistakenly serve up your code as static content. The Java .war file spec has
this special directory called WEB-INF expressly for the purpose of hiding that stuff away, so why
not use it?
And then, suddenly Goldspike was packaging up my entire Rails application directory, .svn directories
and everything. So I set out to fix this once and for all.
And so I present Warbler. A little bird who chirpily steps up to the task of assembling your
Rails application into a Java Web Archive (.war). Here, get it:
gem install warbler
And then, in the top directory of your Rails application,
warble
Those two steps are all it takes to make a .war file, including your application and recent versions
of JRuby and Goldspike, that’s deployable to your favorite Java application server.
There are a number of points about Warbler worth mentioning.
Does one thing, well
Warbler only packages, and doesn’t care about anything else, like how to dispatch servlet requests to
Rails. This will allow for more runtime servlet binding mechanisms to take advantage of Warbler in
the future.
Fast and lightweight
50% less code than the Goldspike packaging plugin, yet does the job quickly and efficiently.
Sane defaults
Warbler only packages code that you need to run the application, omitting database migrations and
tests. If your application is self-sufficient (no external dependencies), then the out-of-the-box
configuration will probably work for you. Public HTML/images/javascript/stylesheets go in the root of
the webapp, where Java webservers expect them to be.
Documented, flexible configuration
Need to customize your configuration? Run warble config and edit config/warble.rb. All the
options are there, commented and documented.
Need to change out the bundled JRuby/Goldspike versions? warble pluginize makes a copy of Warbler
in the vendor/plugins area of your application, allowing you to change the .jar files in the
vendor/plugins/warbler-0.9/lib directory. Warbler then makes his nest in your project’s list of
rake tasks (as rake -T | grep war shows)
rake war # Create trunk.war
rake war:app # Copy all application files into the .war
rake war:clean # Clean up the .war file and the staging area
rake war:gems # Unpack all gems into WEB-INF/gems
rake war:jar # Run the jar command to create the .war
rake war:java_libs # Copy all java libraries into the .war
rake war:public # Copy all public HTML files to the root of the .war
rake war:webxml # Generate a web.xml file for the webapp
Warbler even omits himself in the .war file produced when running in plugin mode, since you won’t
need him at runtime. It’s the little details that matter.
Give him a try and let me know if it makes your life deploying Rails applications to JRuby on Java appservers easier!
Tags jruby, rails, warbler | 13 comments
Posted by Nick Sieger
Wed, 23 May 2007 05:51:36 GMT
I was fortunate to be in town right after RailsConf and attended the inaugural geekSessions event on Rails scalibility. The event went off without a hitch: it was well attended, City Club is a classy place, and there was decent food and an open bar. I don’t know the SF geek/startup scene, but pretty much all of the few guys I know were there along with a ton of other folks. My only complaint would have been to let it run at least 30 minutes longer. Socializing was good too, but it seemed like the conversation was just getting started.
Here are some notes for you in my typical rapid-fire style – hope they’re useful to you.
Ian McFarland
Case study: divine caroline
Servers:
- Load balancer
- Apache + mongrel
- MySQL
- SOLR
Ruby is slow. Rails is slow. Unoptimized app was slow – 7 pages/sec with ab. So how can Rails possibly be? 150 pv/s with a simple text render. This formed a sort of upper-bound, that ruled out fragment/action/partial caching, etc. This brought the throughput to 3500 pv/s. Except for page caching limitations:
- Cache coherency
- Writes are more expensive
- Page caching is not applicable to as many pages as you think
But measure first. Pivotal built a drop-in page caching extension to deal with cache coherency issues (soon to be at http://rubyforge.org/projects/pivotalrb)
Jason Hoffman
Jason somehow has the distinction of the first four commits in the Rails repository. Joyent/TextDrive/Strongspace.
If your application is successful, you’re going to have a lot of machines. What happens when you have 1000s of machines, 100s of TB, 4 locations, etc. Is this really a Rails issue? In a typical Joyent setup, Rails is only one of 26+ processes on the server stack. So scaling it really doesn’t mean much more than scaling any application. Object creation in Ruby is fast, sockets and threads are slow. So forget sockets and threads.
Instead, use DNS, load balancers, evented mongrels, JRuby/Java, DBMSes (not just RDBMS; LDAP, filesystem, etc.), Rails process doing Rails only, static assets going through a static server, federate and separate as much as you can.
Jeremy LaTrasse
Jeremy’s job is about safety nets; about knowing the underlying infrastructure. Is the hardware/OS/stack important? Can you build safety nets around those so that you can spare cycles when you need to intrude into the system to troubleshoot?
Twitter is in a unique position with the volume of traffic to be able to find some pretty tough bugs, like the recent backtrace issue.
Bryan Cantrill
Measure first! Like Ian said. Is software information? Or a machine? It’s both. Nothing else in human existence can claim this. 3 weeks after Bryan joined Sun, he was working with Jeff (ZFS architect) debugging an issue when Jeff retorted, “Does it bother you that none of this exists? It’s just a representation of some plastic and metal morass in a backroom” (slightly paraphrased).
We’ve been living with bifurcated code – “if DEBUG; print something” ad nauseum. But this has a cost. So dev code deviates from production code. But we can’t get the data we want, where it matters, in production. Bryan goes on to describe the aforementioned backtrace issue and how it saved Twitter 33% CPU. So don’t pre-optimize, but you’ve got to be prepared to go get the data. In production.
Q & A
What’s the best way to move from one database to two databases (MySQL), when you scale past the volume of reads that overwhelms one?
Jason doesn’t like the replication approach, it’s not fault tolerant. Reference to Dr Nic’s magic multi-connections gem. Reference to acts_as_readonly. Don’t rely on things that are out of your control, start reading/writing to multiple locations, at the application level. Jeremy: So do you want to be in the business of writing SQL or C extensions to Rails? What about MySQL proxy? Seems ok, but I might not trust it in production. MyTop/InnoTop will tell you about your query volume.
Virtualization: 4 virtual servers w/ web servers on top of a single physical server? Why?
Jason: Free BSD 4.9 on early pentium was the perfect balance of utilization. 18 CPUs by 64G RAM with virtual servers gets us back to that level of utilization. Bryan: Not all virtualization solutions are equivalent! (Solaris containers/zones plug.)
RDBMSes are not good for web applications? Why? Can you give some examples?
Jason: It depends on when you want to join. When people are clicking, or pre-assembled. Look at your application and put the data together before people request it. Why does YouTube need an RDBMS? It serves a file that people can comment on.
Mention of Dabble DB, ZFS, Jabber, Atom, Atom over Jabber, etc. as ways of innovative ways of storing objects, data, etc. GData/GCal most certainly does not store its Atom files in an RDBMS.
Sell Rails apps and have the customer deploy it? What options are available?
Ian: JRuby on Rails with a .war file is an interesting approach. What operational issues/ways to help with scaling remote deployments? Jeremy: Log files are the first line of defense. Jason: Corporate IT are comfortable with Java.
The pessimist in me says that my servers are going to fall over after 5 users. How can I be prepared/not be optimistic about a traffic spike?
Ian: Load test the crap out of the app. Find out the horizontal scaling point. Use solutions like S3 for images. Make sure you can scale by throwing hardware at it. Eventually single points of failure will overcome you (such as a single database), but you can wait until you get to that point before doing something about it.
Jason: You can benchmark your processes, and get an idea of what they can do. Most people that want to do something will be look at your stuff, and maybe signup. So front-load and optimize your signup process, possibly by taking it out of Rails.
Jeremy: Conversations with Zed, DHH, etc. have pointed out that sometimes “Rails isn’t good at that, take it out of Rails.” Same thing for the database. Split those things out into a different application.
Bryan: Do your dry land work, know your toolchain, so that when the moment comes, you can dive in and find the problem.
We have a migration that takes a week to run because of text processing. GC was running after every 10th DB statement. Used Rails bench GC patch to overcome the issue with the migration. Any issue running these?
Jason: We run those GC modifications and a few more in production, and they’re fine.
Most comversations revolve around items like database is slow, or Ruby is slow. How can we use DTrace to streamline the process?
Jeremy: We spent 20 minutes over lunch (plus some preparation) to find a Memcache issue. It’s worth it to spend a little time to learn the tool.
Bryan: “Awk is God’s gift to all of us.” When DTrace was being reviewed inside of Sun, folks commented “This reminds us of awk.” “Thanks!”
Jason: We’re putting a tracing plugin in Rails as a remote process to collect data from a running app. Apple has shown a commitment to get this in Leopard. Textual and graphical output are possible. I believe in DTrace a lot, and the tooling and documentation will go beyond its current state of an experts tool.
Lastly, what one closing thing would you like to say about Rails scalability?
Ian: Measure.
Jason: Don’t use relational databases.
Jeremy: I thought it was a Joyent sales pitch.
Bryan: Use DTrace (with Joyent accelerators of course).
Tags rails, ruby | 2 comments | no trackbacks
Posted by Nick Sieger
Fri, 16 Mar 2007 16:55:00 GMT
On the heels of my last post, Robert announced the 1.0 release of Rails Integration, the bits that allow JRuby on Rails to be run out of a Java web archive (war). If you have any interest at all in trying out JRuby on Rails, do yourself a favor and try out the integration bits. Even though this is 1.0, we’re still moving rapidly and would appreciate any and all feedback. (And Robert is doing his best to keep up with changes in core.)
Related to this, Stuart Halloway recently announced his J plugin which is a drop-in collection of Rake tasks that bridge the inherent differences between Rails running on C Ruby vs. JRuby. We still have some work to do in some areas, such as database driver configuration, test database bootstrapping and launching unit tests. For example, instead of the big, ugly, database-specific case statement that’s in Rails’ databases.rake today:
desc "Recreate the test databases from the development structure"
task :clone_structure => [ "db:structure:dump", "db:test:purge" ] do
abcs = ActiveRecord::Base.configurations
case abcs["test"]["adapter"]
when "mysql"
ActiveRecord::Base.establish_connection(:test)
ActiveRecord::Base.connection.execute('SET foreign_key_checks = 0')
IO.readlines("db/#{RAILS_ENV}_structure.sql").join.split("
").each do |table|
ActiveRecord::Base.connection.execute(table)
end
when "postgresql"
ENV['PGHOST'] = abcs["test"]["host"] if abcs["test"]["host"]
ENV['PGPORT'] = abcs["test"]["port"].to_s if abcs["test"]["port"]
ENV['PGPASSWORD'] = abcs["test"]["password"].to_s if abcs["test"]["password"]
`psql -U "#{abcs["test"]["username"]}" -f db/
when "sqlite", "sqlite3"
dbfile = abcs["test"]["database"] || abcs["test"]["dbfile"]
`
when "sqlserver"
`osql -E -S
when "oci", "oracle"
ActiveRecord::Base.establish_connection(:test)
IO.readlines("db/#{RAILS_ENV}_structure.sql").join.split(";
").each do |ddl|
ActiveRecord::Base.connection.execute(ddl)
end
when "firebird"
set_firebird_env(abcs["test"])
db_string = firebird_db_string(abcs["test"])
sh "isql -i db/#{RAILS_ENV}_structure.sql #{db_string}"
else
raise "Task not supported by '#{abcs["test"]["adapter"]}'"
end
end
we can use migrations to create the test database:
desc "Recreate the test databases from migrations"
task :migrate_test_db do
ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations['test'])
ActiveRecord::Schema.verbose = t.application.options.trace
ActiveRecord::Migrator.migrate("db/migrate/")
end
Over time, I hope to see all these efforts coalesce and make the Rails developer experience virtually identical on either interpreter. What would be most excellent is to eventually push some of these improvements back to the Rails core.
Tags jruby, rails | 2 comments | no trackbacks
Posted by Nick Sieger
Wed, 15 Nov 2006 15:46:00 GMT
Inspired by a posting on the RSpec list and recent comments stating that my Auto RSpec hack wasn’t working, I’ve bitten the bullet and upgraded to RSpec 0.7.2, and made rspec_autotest a plugin in the process. So, herewith are the necessary incantations to auto-rspec your project. If you’ve tried my hack already, please remove any bits you previously had installed.
- Install RSpec on Rails, following the original instructions. As of RSpec 0.7.3, the specific version of ZenTest is no longer required. Also, diff-lcs is required to show unified diff output on
should == failures.
gem install zentest -v 3.4.1
gem install diff-lcs
gem install rspec
script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec
script/plugin install http://svn.caldersphere.net/svn/main/plugins/rspec_autotest
Please let me know if you experience any problems!
Tags plugin, rails, rspec | 15 comments | no trackbacks
Posted by Nick Sieger
Tue, 15 Aug 2006 04:12:00 GMT
What was the biggest security threat story for me last week? No, it
was not the disrupted liquid bomb plot, it was the Rails
security hole that caused quite a brouhaha among the Ruby
community. (Guess that shows my increasing tendency to lose touch
with reality. Maybe a sign of the miserable state of unrest in the
world and how living in the land of the world’s only super-power makes
it easy to turn the other cheek? Or…ok, ok…it’s just me.)
From my view of the Rails security issue, there are actually quite a
few interesting angles that came out of this story.
Rails is Growing Up
This is the obvious one. The first major fault to be discovered in
Rails shows that Rails the codebase, Rails the core team, Rails the
technology stack, and Rails the community is going through growing
pains. David was both praised and criticized widely for his handling
of the disclosure. Many rightly complained that the initial
announcement didn’t give system maintainers enough information to
decide whether the risk warranted disrupting normal operations to
spend time to test and roll out the patch. This was compounded by the
fact that the initial announcement did not identify versions affected
and instead assumed all past versions, which turned out not to be the
case.
Others thanked the Rails team for their discretion and trusted the
recommendation despite the fuzziness and lack of details. These folks
either were able to perform the upgrade much more easily or had some
inkling of just how serious the issue was.
The aftermath showed that the Rails core quickly learned from the
experience. A security mailing list and google group were
set up for future incidents and David promised to apply more rigor
and policy to future announcements.
It seems pretty obvious that the size of the gaffe was such that to
expose the details immediately would have had way too much potential
to cause widespread data loss and denial of service. In fact, the
nature of the bug strikes me as one of those embarrassing bugs that
every software developer commits at one point in their coding life
where you amaze yourself at the short-sightedness of your
implementation. I think the initial message could have been
dispatched with information on the severity of the threat without
necessarily disclosing the exact exploit. So, essentially I agree
with the approach that was taken, but the message left out details
required to evaluate the threat.
Threat Analysis
Two early blog posts came out the day after
claiming to know the details of the exploit. It turned out that they
didn’t quite understand what was afoot. (Although Evan Weaver has
since updated his post to clarify his original analysis.)
The threat turned out to be a simple remote code execution issue. The
:controller dynamic expansion aspect of routing contained a bug that
allowed arbitrary .rb files in a Rails application to be executed
undesirably. By far the most dramatic consequence would be
experienced if one’s db/schema.rb file were to be executed with a
request for /db/schema, causing your entire database contents to be
dropped and reloaded.
By examining the safe_load_paths method defined in affected
versions, it appears that the implementation tried to limit elements
of the load path that matched the expanded RAILS_ROOT of the
application. Combine this with the fact that other elements of the
routing system eagerly require‘d files with inadequate
bounds-checking spells your recipe for disaster.
Many posters and commenters quipped that a simple svn diff was
enough to give script kiddies or other black hats the information
needed to exploit the issue. Or was it? Given that the two early
analyses turned out to be off the mark, were people in the know
exercising more discretion by not disclosing more details?
Personally, I spent more than an hour staring at the affected routing
code trying to untangle the various metaprogramming tricks and regular
expressions that make up the Rails routing system. And I consider
myself fairly adept at reading and understanding code!
The truth of the matter is that, unless you’re a member of core or
have a high level of familiarity and involvement with the Rails
codebase, the svn diffs provide far too little context to decode the
actual problem.
Does this speak to the obfuscated nature of the Rails codebase or to
the relatively advanced nature of web programming in Ruby? If I had
to pick one, it would be the latter, but I’m leaning towards neither.
The Rails codebase is not the most readable, comprehensible piece of
code I’ve ever seen, but it does its job remarkably well. Perhaps if
the routing code in question was a bit more understandable by the
masses, this rather obvious security issue wouldn’t have gone
undetected for so long.
Post-1.1.6 Release Triage
A group of enthusiastic Railsers jumped onto #rails-security on
freenode shortly after the 1.1.6 release, where an effort had been
organized to verify all the patches across various combinations of
web servers and Rails versions. An IRC channel, a wiki,
Ruby, Zed’s RFuzz, and a piece of code were all the
tools required to get a distributed test verification process up and
running. This sort of thing happens all the time in the open source
world, with programmers around the globe pitching in to raise the
triage tent of the MASH unit. Still, it was exciting to see and be a
part of the action and to be reminded of the power of the collective
whole working for a common cause.
Dynamic Routing Harmful?
Rails’s dynamic routing code came under fire too, understandably so.
Maybe this is one case where the developer-friendly approach of
magically recognizing URLs goes a little too far? Production-only
routes that do away with the expandable path elements could easily be
generated by visiting all the controllers in the codebase and
generating a more static route for each – sounds like a good idea for
a plugin. Perhaps the controller is the better place to store routing
metadata anyway?
class UsersController < ActionController::Base
map_default_route
end
class PostsController < ActionController::Base
map_route_as_resource
end
Sounds like good fodder for future investigation!
Posted in ruby, rails | Tags rails, security | no comments | no trackbacks
