logrotate certbot logs: reduce retention

[juju4]

Describe the bug

Certbot/letsencrypt have by default a very high level of log retention which results in hundreds of logs file in /var/snap/nextcloud/current/certs/certbot/logs/.
Especially more for a snap, it is unlikely it is used.
A better default IMHO would be something like 30 days if rotating daily.

see also
https://community.letsencrypt.org/t/log-rotation-configuration/108596
certbot/certbot#4907

To Reproduce

Steps to reproduce the behavior:

1. Install nextcloud snap
2. Let it run for more than 30 days
3. See number of accumulated log files.

Expected behavior

A configurable option would be nice but at least a lesser number as I would expect most install don't need to keep a thousand log history

OS/snapd/snap version

# snap list nextcloud
Name       Version      Rev    Tracking       Publisher   Notes
nextcloud  22.2.0snap2  28586  latest/stable  nextcloud✓  -
# snap version
snap    2.52.1
snapd   2.52.1
series  16
ubuntu  18.04
kernel  4.15.0-161-generic

[kyrofa]

Thank you for this. We have a logrotate config in the snap that covers pretty much every log except certbot's! Shouldn't be hard to include it.

[r4co0n]

Please note that --max-log-backups as referred to in OPs' links seems to not work as expected: certbot/certbot#5575 . Also, GitHub refused to dig up any mention of this string when searching the certbot repo. So, as @kyrofa said, we should use logrotate to manage certbot logs, compressing and finally deleting the files.

What would be a good retention policy for certbot logs - When should they be compressed and when should they be discarded?

Answering this from my point of view: Let's-Encrypt-certificates live for 90 days and you might want to inspect the logs of the previous certificate, so 90*2+10=190 days would be a sane buffer, adding 10 days because 180 days and 6 months might be a different thing, and then add some extra days. (I reckon people will remember that their certificate is renewed every quarter of the year here,)

[kyrofa]

Yeah we just need to disable certbot's rotation. @r4co0n what do you think, is this worth doing if we're trying to replace certbot? Or is that a ways off, yet?

[r4co0n]

@kyrofa, the biggest concern with migration is keeping everything working for all the folks that currently use certbot, and for those that have provided their own certificates. As far as I could discern, we never log what people last chose when setting up encryption, or am I mistaken? It's prudent to know if the current certificate is self-signed (generated by us), provided by letsencrypt or provided by the admin.

--max-log-backups is still available, I was mistaken, Searching for max_log_backups instead of the apparently present string --max-log-backups helped, GitHub search decided to returning nothing, I found the flag here. This should be set to 0 before creating a logrotate config.

[kyrofa]

we never log what people last chose when setting up encryption, or am I mistaken? It's prudent to know if the current certificate is self-signed (generated by us), provided by letsencrypt or provided by the admin.

@r4co0n I have thoughts on that, but in the interest of not pulling this issue off-topic, do you mind making a comment on #1902 so we can discuss?

This should be set to 0 before creating a logrotate config.

Agreed.