Bug 1873378

Description of problem:

rancid.logrotate is not suitable for deploying with Rancid because the logfiles are timestamped.

The EPEL7 sources haven't changed since I installed in 2015. When I installed locally I did notice some issues, and made some minor changes: 

$ cat /etc/logrotate.d/rancid
/var/log/rancid/* {
    weekly
    rotate 1
    #notifempty
    missingok
    compress
    olddir old

    ifempty
    nocreate
}

However using olddir is really not suitable here as the filenames contain a timestamp. Once they end up in /var/log/rancid/old they never get removed.

Naively I created a cron job, based on FAQ #10 (
https://github.com/haussli/rancid/blob/babfe8344de57f70f01d749ebfb4bcfcc492d4d4/README ) to remove the olddir files.

$ crontab -l  | grep -B1 find
# Clean out month-old config differ logs daily at 23:50
50 23 * * * nice /usr/bin/find /var/log/rancid/old -mtime +30 -exec /usr/bin/rm {} \;

However this does not prevent /var/lib/logrotate.status filling up.

$ cat /var/lib/logrotate.status | awk '{print $2}' | cut -d- -f1 | sort | uniq -c
      7 2015
  96403 2016
 308585 2017
 302782 2018
 292858 2019
 204930 2020
      1 state

I'd also like to point out that NONE of the modifications I made to the RPM install would have lead to /var/lib/logrotate.status



Version-Release number of selected component (if applicable):
All

How reproducible:
Easily

Steps to Reproduce:
1. Install Rancid
2. Collect Configs on a regular basis
3. Wait five years or so

Actual results:
/var/lib/logrotate.status grows into a snowball

Expected results:
/var/lib/logrotate.status does not grow. 

Additional info:
I would suggest removing rancid.logrotate and replacing it with rancid.cron
Perhaps adding a less clumsy version of this to rancid.cron:
# Clean out month-old config differ logs daily at 23:50
50 23 * * * rancid nice /usr/bin/find /var/log/rancid/old -mtime +30 -exec /usr/bin/rm {} \;