Harry Putnam wrote:
> One final question: I decided to rename the /etc/cron.daily/logrotate
> script to /etc/cron.daily/00logrotate, so that it runs first. Just in
> case what ever caused my problem ... comes up again. At least
> 00logrotate will have the best chance of getting run.
I just find it hard to believe that something being run before it was
causing the problem with something running after it. I really think
the root cause of the problem was something else. Therefore trying to
do this to fix it seems to be doing something that doesn't need to be
doing.
> Can anyone think of any problems that renaming step might cause? I
> mean other than it might get overwritten, sometime in the future, back
> to the default setup and so would possibly need maintenance.
Since there isn't any file /etc/cron.daily/00logrotate in any package
this file appears to the system as a new file. It is a local admin
change. It is your file. Nothing will touch it. Ever. It is your
file from here on moving forward. I usually name local files with
"local" in the name to make that very clear. It avoids confusion later.
The logrotate package owns the /etc/cron.daily/logrotate file. It is
a conffile.
$ dpkg-query -W -f='${Conffiles}\n' logrotate
/etc/logrotate.conf 176edd439a499501372cf3d04e795810
/etc/cron.daily/logrotate d2281ecb6f898b446ac8a5984ab5a243
Therefore one of a few things will happen the next time the logrotate
package is upgraded. This could be an upgrade for a security issue.
Or this could be a Debian release to the next stable release. When
cron upgrades the conffile handling will do one of two things. One
possibility is that it will either replace the file with a pristine
copy of the crontab. That would cause logrotation to run twice. Once
for your local 00logrotate and once for the regular logrotate crontab.
Or dpkg will refuse to install a new copy of the logrotate file
because being a conffile you have removed it and the local admin
wishes must be respected. Therefore dpkg might not ever update that
file again. There are explicit options to control this. Those are
the confnew, confold, confdef, confmiss and so forth.
I personally think that a missing conffile should be replaced
(confmiss) because this is such an unusual case that almost always a
mistake. Only very rarely is a missing conffile intentional. Usually
the best answer is a zero length file or a file with a comment that
documents why the admin wanted the file to be empty. The comment is
invaluable later when wondering why something is the way that it is.
I can't say enough about the usefulness of putting a comment in the
file. But I know that others feel strongly that if the file was
removed, even if by accident, that dpkg should respect that due to it
being a conffile and a local change regardless of intent and that the
package should not replace it. Bugs have been filed both ways on this
topic. It is contentious. I would need to try it and test to see
what is the current behavior today so I don't know which will happen.
Another possibility is that cron will update and want to make a change
to the crontab file. Normally that file is not modified locally and
therefore the cron update would update the file to the new contents.
If the file is modified then dpkg will present you with questions
asking if you want to select one or the other or handle it in some
way. Usually the admin needs to merge local changes in with the new
file. With the file having been removed it means that you will never
see any new contents to that file. I don't think that crontab changes
very often but it could. By using your own copy of that file it means
you won't see the update and if, say, a new something were added that
you would not see it unless you added it to your copy manually. I am
not saying that this will happen. But you were asking what were the
possible ramifications of your modification.
You could use dpkg-divert to divert the location from the old to the
new name. I think that would actually be quite safe. Then dpkg knows
that the old name is diverted to the new name. Basically it is a true
rename of the packaged file location. So updates should flow to the
new diverted location correctly and everything. I haven't ever needed
to do this myself so I won't propose an example. The man page
documents it and provides examples. I don't think you need to rename
that file but if you really do then I think using dpkg-divert is
probably the best way to do it. Assuming that its use isn't forgotten
about later causing confusion about why and what happened. :-)
> Of course there are other ways, like removing the
> /etc/cron.daily/logrotate script altogether and running logrotate
> from roots' crontab.
Under the principle of "where do you stop" I think that is worse.
Because following that to the logical conclusion it means that you
should run everything from your own cubbyhole. "Standard is better
than better." But as we know if things are very much too customized
then they become fragile. Upgrades become a mental memory challenge.
You have to remember too much about how everything is configured. I
wouldn't do it. But then I wouldn't do the rename either. :-)
Good luck!
Bob
Attachment:
signature.asc
Description: Digital signature