Recently we migrated from certbot-auto to use snapd on our CentOS7 servers. But we can't find a way to disable debug log entries to go to the /var/log/letsencrypt/letsencrypt.log file. In our old implementation we deployed a crontab and added a quiet argument. We now created a /etc/letsencrypt/cli.ini file with that argument inside but that does not seem to work.
My domain is: jcid.nl
The operating system my web server runs on is (include version): CentOS 7
--quiet suppresses terminal output, except for errors. It doesn't affect file logging.
--max-log-backups 0 disables log rotation, for cases such as when the operating system already has logrotate set up to perform that task. Again, it doesn't disable logging entirely.
I am not actually sure whether it's possible to disable file logging in Certbot. Certainly, by the way the code is written, it doesn't seem to be possible.
There is this comment which suggests combining --max-log-backups 0 with a clever symlink to /dev/null in order to prevent anything being written to disk. Works for me when I try it.
It is impossible to disable file logging or change log levels in Certbot. that is by design; IIRC the maintainers wanted to ensure there is a full trail that users can not accidentally lose. The big complaint on this policy has been from people using Docker/etc and/or CI systems and wanted the file logging to hit the screen.
I don't know what @cliffodijk's former setup was, or did, but it should not have been able to affect file logging.
Hi @jvanasco tnx for the response. In the past we logged the stdout of the renewal cronjob with certbot reneal quite > /var/log/renew.log. But with snapd the renew command is run using the systemd listeners so i'm not sure how to change the output of that.
Just to make sure you understand this point: --quiet only affects what gets sent to STDOUT, and limits it to errors and above -- but does not affect the logging of anything to /var/log/letsencrypt.
What we did in the past was using eleastic filebeat ship the .log file to our kibana stack and have a trigger / monitoring task validate that nothing went wrong while renewing. I think we could solve this using the journalctl -u snap.certbot.renew command i will look into that.