Capistrano, chmod, and revisions.log

Rails
1

background:

One of our developers is just getting started with Capistrano, just
getting together a rudimentary deploy.rb, copied from one of our
contract developers who is just getting started a bit too. I’m the
systems manager and a complete Rails and Ruby newbie (who, by the
way, cannot thank Zed S. enough for mongrel and Bradley Taylor
enough for mongrel_cluster :slight_smile:

I’m using POSIX ACLs on ext3 to let the devs do their thing and make
sure that apache and mongrel have r, rx, and rwx where they need to
for their applications without playing a bunch of owner/group games
for the files. This is working out well, and I can happily tell the
devs to ignore any and all chmod recommendations littered throughout
the web references to capistrano, because they are completely
unnecessary

well, until capistrano itself does a chmod.

Buried in …/gems/capistrano-1.1.0/lib/capistrano/scm/base.rb is this:

     def logging_commands(directory = nil)
       log = "#{configuration.deploy_to}/revisions.log"

       "(test -e #{log} || touch #{log} && chmod 666 #{log}) && " +
       "echo `date +\"%Y-%m-%d %H:%M:%S\"` $USER #

{configuration.revision} #{directory} >> #{log};"
end

Well, this apparently caused a deployment to fail for my dev (maybe,
the dev and I were debugging this over IM and there were multiple
issues, one of which was a mongrel_rails cluster::restart which
doesn’t start a stopped mongrel_rails process). For reasons that I’m
still not sure about (see debugging comment above), the test -e
failed on the revisions.log (even though it existed) and because the
dev wasn’t the owner (but has read/write from the ACL on the file) -
the chmod failed, failing the logging - and affecting who knows what
else.

This chmod assumption annoys the heck out of my system admin
sensibilities. I don’t want/need scripts trying to fix their own
permissions. Either try the write and fail or succeed. (okay, so
my dev sensibilities appreciate the attempt, at least until its
assumption fails).

so…

a) is this the right forum to comment on this?
b) in the collective opinion, what’s the feeling on this? (if the
consensus thinks the chmod is great, I’ll get over it)
c) if (b) == get rid of the chmod, is this worthy for a bug report?
d) if © where do I file said bug report?

Thanks,
Jason

–

Jason Y. --  Systems Engineer, eXtension
  http://about.extension.org/wiki/Jason_Young
______________________________________
2

I’ve not worked with ACLs, but I’ve found that
Capistrano works great if you create a user
that:

  1. Owns the files, and
  2. Starts Mongrel

This user needs almost no privileges at all.

–
– Tom M.

3

Well,

part of the whole problem here is that this is supposedly a fixed bug:

http://dev.rubyonrails.org/ticket/3223

but it’s not in capistrano 1.1.0

when do capistrano fixes make it into the gems?

thanks!
Jason

On Jun 20, 2006, at 11:11 AM, Jason Y. wrote:

make sure that apache and mongrel have r, rx, and rwx where they

multiple issues, one of which was a mongrel_rails cluster::restart
my dev sensibilities appreciate the attempt, at least until its
Thanks,

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

–

Jason Y. --  Systems Engineer, eXtension
  http://about.extension.org/wiki/Jason_Young
______________________________________