> Okay, I'll bite and give my $0.02.
>
> Method #1 Pros and Cons:
>
> Con: I don't like the application code to be responsible for log rotations.
> It "feels" like this should be a system administrative task.
> Pro: Easy to set up and no need to drop a logrotate config in /etc on
> deployment
Agreed...
> Method #2
>
> Con: Deployment requires another "external" step (configuration external to
> the application code itself)
> Pro: From a sysadmin point of view, I keep all my "log rotation"
> configuration in one place (as it ought to be).
>
> My Preference
>
> Method #2: use capistrano or other scripted/automated deployment tool to drop
> (or update) a logrotate config in your /etc/logrotate.d/ directory to
> overcome the downside of this method and you're golden.
One drawback to this is /etc/logrotate.d is usually owned by root... do you
want capistrano to be able to write to root protected directories? That opens
a door for someone to put in a postrotate script that does all kind of nasty
things as root :(
If it was me, I'd install a rails logrotate file *once* that covered all your
deployed applications... something like the below. This way it's installed
once, and never needs to be installed again for any new applications. As long
as you make sure the regex's match all your apps anyway :)
/home/philip/apps/*/shared/log/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 640 philip philip
sharedscripts
postrotate
if [ -f "`. /etc/apache2/envvars ; echo
${APACHE_PID_FILE:-/var/run/apache2.pid}`" ]; then
/etc/init.d/apache2 reload > /dev/null
fi
endscript
}
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
