#643960 Broken log rotation

Package:
inn2
Source:
inn2
Description:
'InterNetNews' news server
Submitter:
Richard Kettlewell
Date:
2011-12-22 10:09:08 UTC
Severity:
normal
#643960#5
Date:
2011-10-01 08:24:32 UTC
From:
To:
I have the following in my news.daily report:

/usr/lib/news/bin/scanlogs: line 135: /var/log/news/news.crit:
Permission denied
/usr/lib/news/bin/scanlogs: line 135: /var/log/news/news.err: Permission
denied
/usr/lib/news/bin/scanlogs: line 135: /var/log/news/news.notice:
Permission denied

The reason is that these files are owned by syslog.adm:
#643960#10
Date:
2011-10-01 08:30:40 UTC
From:
To:
Since when?
inn has always cooperated with the standard syslogd.
Yes, everybody knows this. So it is not going to change soon...
#643960#15
Date:
2011-10-01 09:25:01 UTC
From:
To:
Hi Marco and Richard,
argument for news.daily (in sample inn2 crontab) and provide a logrotate
entry for standard Debian logrotate program?

It would do the trick, wouldn't it?  or am I missing something?


Basically, scanlogs performs two kinds of actions:  a few files are
copied for backup purpose (like the active file) and a few files are
rotated.


P.-S.:  If something needs being changed in scanlogs (reorganization of
code or new arguments to use) so that using logrotate in Debian is
eased, do not hesitate to tell.  INN 2.5.3 will be released this month.
#643960#20
Date:
2011-10-01 14:27:00 UTC
From:
To:
It's the behavior of the sysklogd package in sid.  I assume it was
introduced in 1.5-6.1 but I don't know for sure.

ttfn/rjk
#643960#25
Date:
2011-10-01 15:52:34 UTC
From:
To:
I do not think so, since the two actions need to be coordinated.
I see a suid wrapper as a more plausible solution (and it is not much of
one...).
#643960#30
Date:
2011-10-01 20:06:31 UTC
From:
To:
md@Linux.IT (Marco d'Itri) writes:

Could news.daily do its analysis on the .0 version of the logs after being
rotated by logrotate?  Some coordination is still needed, but not a lot.
#643960#35
Date:
2011-10-02 13:18:35 UTC
From:
To:
Hi Russ,

I have not thoroughly looked at the code but I do not see why
news.daily/scanlogs could not use .0 versions.
Yet, are we sure that logrotate will always generate these files?  (If a
user changes the configuration of logrotate, it could break log analysis.)

Would a new "rotate=<program>" option to news.daily be usable for
Debian?  We could then skip the rotation part of news.daily/scanlogs and
run instead <program>.

rotate="logrotate inn2" may be used for Debian, with a proper
/etc/logrotate.d/inn2 configuration file.

Does it sound good?
I can have a look at it, if it is usable by Debian (and probably other
distributions, that have a similar logrotate program).
#643960#40
Date:
2011-10-02 17:51:25 UTC
From:
To:
Julien ÉLIE <julien@trigofacile.com> writes:

Yeah, but... I think at some level we have to make some documented
assumptions about log rotation and go with that.  As long as there's a
comment somewhere in the inn2 configuration file telling people what to do
if they want to change it, I think this is okay.

But we'd need to convince logrotate to not also run the inn2 configuration
when it runs normally from cron.daily.
#643960#45
Date:
2011-10-02 18:06:59 UTC
From:
To:
The problem is that somebody may change the logrotate configuration
(e.g. moving it after news.daily is run) without knowing about INN.
It already ignores the news.* files.
#643960#50
Date:
2011-10-02 18:33:44 UTC
From:
To:
Hi Marco,

Could news.daily be run by a "postrotate" section in logrotate?
We could imagine to run news.daily with the "norotate" keyword in this case.

If I run "man logrotate" on Lenny (I have not checked on Squeeze), I read:

/var/log/news/news.crit {
   monthly
   rotate 2
   olddir /var/log/news/old
   missingok
   postrotate
     kill -HUP ‘cat /var/run/inn.pid‘
   endscript
   nocompress
}

I wonder why this example is given in the documentation.  It will give
unwise ideas for dealing with inn2 log files at the moment.
Hopefully no default inn2 configuration is shipped by default.
#643960#55
Date:
2011-12-22 10:04:38 UTC
From:
To:
rsyslog does not do this (yet).  So for people who can accept changing
to a different syslogd, a workaround is to use that instead of sysklogd.

This part of the bug remains even with rsyslog.

One possible option would be a userv service to allow the news user to
send a SIGHUP to [r]syslogd.

ttfn/rjk