Deploying only what you need with Capistrano?

Rails
1

The recent Rails security issue highlighted a concern I’ve had about
Rails
deploys; namely, you shouldn’t deploy anything to production that you
don’t
need there. Rails apps have a number of scripts–potential security
holes or
DOS targets in this case–along with all the other application code you
need. There’s no reason you should have script/server, console, plugin,
generate, or any of the others on a production machine, as far as I can
tell. I’m sure there’s other items that could be cleared out as well,
and/or
Ruby and Rails features explicitly turned off.

Is this contrary to the Rails way? It’s always been considered a best
practice on my projects, but do folks in the Rails world share my
concerns?
Is there a way to make Capistrano only deploy what you need?

2

Since capistrano’s deployment tasks really only automate the
performing of “checkout” from a repository (and usually through
subversion), it is really the developers job to “ignore” files that
shouldn’t be checked in. There are good reasons, I agree, to not
include developer tools like breakpointer and such.

And, on the other hand, if you need to setup another developer, they
could always check out the production limited code-base and run “rails
.” on the current dir to get the latest dev tools like script/server
that have been removed anyways.

In the case of schema.rb (highglighted by attacks), this file is
generated when you run rake migrate, thus it would be worthy to have
a:

desc “After deploy_with_migrations callback”
task :after_deploy_with_migrations, :roles => [:app, :db] do
run “rm db/schema.rb”
end

Continuing along that path, it would perhaps be feasible to alter
Capistrano to remove files that developers have checked in and will
continue to get checked out or generated.

The after_ callbacks are a good place to do this.

My recommendations:

  • alter anywhere you see svn practices (like the subversion setup
    rails wiki page) to not include script/* and to ignore dispatch.rb,
    etc.

  • we could beef up capistrano and have default affer_deploy tasks, or
    even alter to have a mode of deployment, so the deploy to staging or
    deploy to dev box task keeps files, but the deploy to production just
    exports code.

I’m with you, and I agree.

Charles Brian Q.
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com

On 8/16/06, Charles O Nutter [email protected] wrote:

practice on my projects, but do folks in the Rails world share my concerns?
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

3

On 8/16/06, Charles Brian Q. [email protected] wrote:

Since capistrano’s deployment tasks really only automate the
performing of “checkout” from a repository (and usually through
subversion), it is really the developers job to “ignore” files that
shouldn’t be checked in. There are good reasons, I agree, to not
include developer tools like breakpointer and such.

I agree with keeping Cap simple in principal; my concern is to try to
avoid
having to hand-roll a less-than-perfect production scrubber, as well as
trying to keep up with new “fluff” in future Rails releases that I don’t
want to deliver with applications. There ought to be some reasonable
conventions for removing community-accepted fluff before a production
release.

And, on the other hand, if you need to setup another developer, they

could always check out the production limited code-base and run “rails
.” on the current dir to get the latest dev tools like script/server
that have been removed anyways.

Not a bad thought, but it pushes the onus on the Rails end-user to know
which files shouldn’t go to production, rather than having a “safe by
default” scrubber already available. It also eliminates some of the
agility
of Rails development if I’m always forced to prime a newly-checked-out
application before getting back to work. Still, it’s not bad.

In the case of schema.rb (highglighted by attacks), this file is

continue to get checked out or generated.
deploy to dev box task keeps files, but the deploy to production just
exports code.

This is exactly in line with what I’m thinking. At a minimum, there
should
be a number of files you’d never want delivered to production, and a
reasonable set of defaults “after” tasks to prevent that from happening
without explicit permission. I’m not sure I’m the right person to say
what
files those are, however, nor to make appropriate changes to HOWTOs or
code…

4

Weeeelll,

We actually do like having testing on prod that so that we know
everything is working. A quick full test of your app on a production
server will sure let you know quick if you’re missing a gem,
dependency, or expect certain file paths/system conventions to work.

To be completely honest: I’m currently working on a new tool for
deployment that utilizes Capistrano – and has some really slick stuff
for automating its usage.

It’s based off our RailsDay2006 entry:

http://heartbeat.highgroove.com/

In the mean time, I’d love to share some best practices for capistrano
recipes – let’s get this thread together, and I’ll patch up the
default capistrano recipes with an option to turn on in your deploy.rb
file – this would enable after_ callback tasks to clean up everything
for a real prod deploy.

The maintainers are rails core (Jamis B. and DHH), so when we’re
done I’ll submit on the rails trac – I also have some changes to our
capistrano setup for our new tool, but these changes don’t necessarily
need to be pushed upstream.

cheers,

Charles Brian Q.
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com

5

On 8/16/06, Charles O Nutter [email protected] wrote:

This is exactly in line with what I’m thinking. At a minimum, there should
be a number of files you’d never want delivered to production, and a
reasonable set of defaults “after” tasks to prevent that from happening
without explicit permission. I’m not sure I’m the right person to say what
files those are, however, nor to make appropriate changes to HOWTOs or
code…

Another thought: test cases. It’s generally a serious no-no to deliver
test
code to a production server, but current Cap will do it happily, yes?