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 Shaw enough for mongrel and Bradley Taylor
enough for mongrel_cluster :-)
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 (c) where do I file said bug report?
Thanks,
Jason
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Young -- Systems Engineer, eXtension
http://about.extension.org/wiki/Jason_Young
______________________________________
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 Mornini On Jun 20, 2006, at 8:11 AM, Jason Young wrote:> 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 Shaw enough for mongrel and Bradley > Taylor enough for mongrel_cluster :-) > > 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 (c) where do I file said bug report? > > Thanks, > Jason > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jason Young -- Systems Engineer, eXtension > http://about.extension.org/wiki/Jason_Young > ______________________________________ > > > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
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 Young wrote:> 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 Shaw enough for mongrel and Bradley > Taylor enough for mongrel_cluster :-) > > 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 (c) where do I file said bug report? > > Thanks, > Jason > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jason Young -- Systems Engineer, eXtension > http://about.extension.org/wiki/Jason_Young > ______________________________________ > > > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jason Young -- Systems Engineer, eXtension http://about.extension.org/wiki/Jason_Young ______________________________________