J'avais un petit container podman que je lançais à la main quand j'en avais besoin, mais je me suis rendue compte que j'en avais souvent besoin quand j'étais sur mon PC.
Maintenant j'ai un quadlet (un fichier "unit" de systemd dédié aux containers) qui lance ce qu'il faut au démarrage de ma session.
La technique que j'ai indiqué dans une précédente note[0] ne fonctionne pas d'emblée pour moi.
Pour que cela fonctionne, et comme indiqué dans cette page[1], j'ai du rajouter NoNewPrivileges=false dans la section [Service] du service à partir duquel je souhaite envoyer un mail en cas d'erreur.
Entre temps, j'ai trouvé une meilleure solution plus facile à administrer : https://wiki.archlinux.org/title/Systemd#Notifying_with_e-mail
Une fois mise en place, il suffit de rajouter OnFailure=status_email_user@%n.service dans la section [Unit] du service à partir duquel on souhaite envoyer un mail en cas d'erreur.
D'autres ressources :
[0] : Renouvellement automatisé de certificats Letsencrypt avec certbot sur Debian
[1] : snapwebsites postfix/postdrop[18189]: warning: mail_queue_enter: create file maildrop/259373.18189: Permission denied https://linux.m2osw.com/snapwebsites-postfixpostdrop18189-warning-mailqueueenter-create-file-maildrop25937318189-permission
Je découvre que le cron /etc/cron.d/certbot n'est en fait pas utilisé sur mon serveur Debian.
Dans ce fichier, il est précisé que c'est le timer certbot.timer de systemd qui est utilisé (si on utilise systemd comme init, comme c'est le cas par défaut).
C'est donc pour cela que je ne recevais jamais de mail pour les renouvellements foirés de certificats Letsencrypt.
Oui, car par défaut, et contrairement au fonctionnement par défaut de cron, aucun mail n'est envoyé en cas d'erreur à l'exécution de la tâche planifiée. ¯_(ツ)_/¯
Voici une solution pour changer cela.
Connexion