coreos-overlay: drop logrotate

[git-bruh]

Drop logrotate

This drops the app-admin/logrotate package as requested in flatcar/Flatcar#556

The aforementioned issue mentions the caveat of /var/log/{btmp,wtmp} growing indefinitely due to the absence of logrotate. In addition to that, a brief glance (aka grep -r) at the overlay reveals packages that log to paths other than these. For instance, sssd seems to log to various files in /var/log/sssd/*.log. There may be many such packages logging to such directories, which can be pinpointed by looking for logrotate config files in the installed manifest of each package.

Any hints for solving this issue sanely? Taking the sssd example, it would require patching upstream code, not to mention it would break references to such files in the documentation. But this is unsustainable as patching N packages entails much more overhead than just maintaining logrotate, unless I am missing something.

TODO

• Drop logrotate

• Add a systemd timer for truncation of now unmanaged files (blocked on requested feedback)

How to use

TODO

Testing done

TODO, Will be performed after pending feedback is received

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[pothos]

I think a possible solution could be a tmpfile rule for cleaning up based on age:
https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#Age
Our tmpfile files live here: https://github.com/flatcar/baselayout/tree/flatcar-master/tmpfiles.d

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/6601932050

[git-bruh]

Hm, interesting. So would we have a tmpfiles rule that can automatically (& recursively) clean up all log files in /var/log after a specified interval?

[pothos]

Yes, maybe not all folder content but certain files we know about

[git-bruh]

Hmm actually I think it's better to just have a systemd timer that truncates files rather than using tmpfiles that deletes them

We won't be having any logic that would say, send a signal to a process, telling it to open() a new log file (as the old fd would become stale), so all logs would be lost after the file is deleted. But if we just truncate via a timer, all new log lines after that point would be appended to the respective file.

What do you think?

[pothos]

I think it's ok to create a new timer and service unit that truncates known files, which could include the sssd log file. The appending should be tested to work as expected, and maybe the truncating can keep the last X bytes?
Otherwise, we can also keep logrotate but move the customization into another ebuild package so that we can update logrotate without downstream patches.

[git-bruh]

@pothos Could you elaborate a bit on the latter approach? What exactly do you mean by "move the customization into another package"? Since the package currently contains both patches and config files