Rails - Aug 2006 - Deploying only what you need with Capistrano?

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?

-- 
Contribute to RubySpec! @ www.headius.com/rubyspec
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060816/dda3e4be/attachment.html

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_<task> 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 Quinn
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com


On 8/16/06, Charles O Nutter <headius@headius.com>
wrote:
> 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?
>
> --
> Contribute to RubySpec! @ www.headius.com/rubyspec
> Charles Oliver Nutter @ headius.blogspot.com
> Ruby User @ ruby.mn
> JRuby Developer @ www.jruby.org
> Application Architect @ www.ventera.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

-

On 8/16/06, Charles Brian Quinn <me@seebq.com>
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
> 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_<task> 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.

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

-- 
Contribute to RubySpec! @ www.headius.com/rubyspec
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060816/a9b79abf/attachment.html

On 8/16/06, Charles O Nutter <headius@headius.com>
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?

-- 
Contribute to RubySpec! @ www.headius.com/rubyspec
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060816/16c10441/attachment.html

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 Buck 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 Quinn
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com


On 8/16/06, Charles O Nutter <headius@headius.com>
wrote:
>
> On 8/16/06, Charles O Nutter <headius@headius.com> 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?
>
>
> --
> Contribute to RubySpec! @ www.headius.com/rubyspec
> Charles Oliver Nutter @ headius.blogspot.com
> Ruby User @ ruby.mn
> JRuby Developer @ www.jruby.org
> Application Architect @ www.ventera.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>