Updates logrotate.conf for Debian

[abednarik]

This logrotate.conf in Ubuntu break logrotate. A few examples

rotating pattern: /var/log/wtmp  monthly (1 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/wtmp
error: skipping "/var/log/wtmp" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

rotating pattern: /var/log/btmp  monthly (1 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/btmp
error: skipping "/var/log/btmp" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

/var/log group in debian is syslog.

[wwentland]

Thank you. I had a short look and /var/log is owned by root:root on Debian and the default logrorate.conf on jessie looks like:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

# system-specific logs may be configured here

Is this maybe specific to Ubuntu? I wouldn't be happy with merging this PR.

[abednarik]

Thanks for that @babilen In that case, we need to add Ubuntu support right? Because I found many Ubuntu 14.04 broken because of this formula. I will find a way to fix this.

[abednarik]

Hi @babilen

How do you see this approach? Otherwise, let me know the correct path, so I can fix this formula. I use it everywhere, in many clients and is breaking logrotate in Ubuntu.

thanks.

[abednarik]

Hi @gravyboat

Sorry to bother, but this formula breaks logrotate in Ubuntu, we really need to fix this. Can I get some feedback if this is the way to go or I should approach this change in some other way?

Thanks.

[gravyboat]

Hey @abednarik no worries. I would prefer if we could somehow get this into a combo of the map.jinja and a separate ubuntu folder within the files directory, since obviously we need more support than what the debian file will provide. If you don't feel like doing that work let me know and I'll merge this so the formula is at least working properly on ubuntu.

[pcn]

@gravyboat, fixing this in the map.jinja would require breaking out every other OS as well (all readhat, all suse, etc.) which seems Un-necessary. Again since the map.jinja is filtering on the os_family grain I don't think there's going to be a solution to detecting ubuntu using the map.jinja.

I think this conditional in the template is the appropriate fix for the following reasons:

1. It is invisible to all other os families
2. It doesn't change the behavior on debian or other debian-derived disros
3. Currently this formula is filling up the /var/log disks for all of your ubuntu users.
4. Since this behavior is automatic, changing the mechanism it in a future update won't affect users

I'd like to stress that your preference for finding a fix in the map.jinja leaves ubuntu users of this formula in jeapordy. @abednarik seemed to be expressing this clearly. Since this fix doesn't preclude finding a more clever way to do this in the future, please consider making this work by default for now.

[gravyboat]

Yep I'm fine with it.

[abednarik]

Thanks

[gravyboat]

@abednarik For sure, in the future if you can respond back to let me know I can get this merged in faster. Managing the formulas is a hassle so I almost never open existing issues/PRs unless I get mentioned.