Installer Logwatch sur Ubuntu avec Plesk : le guide complet pour centraliser vos logs et recevoir des rapports quotidiens

📌	Définition : Logwatch lit les journaux système, les agrège et transforme le bruit des logs en rapport lisible envoyé par e-mail.
💡	Intérêt réel : sur un serveur Ubuntu avec Plesk, il aide à suivre SSH, mail, Apache, Nginx et les journaux Plesk sans ouvrir dix fichiers à la main.
⚙️	Pré-requis clé : un MTA local fonctionnel, souvent Postfix, sinon le rapport quotidien ne sortira tout simplement pas.
🧩	Point de configuration : les réglages utiles sont MailTo, Detail, Range, Output et les chemins de logs Plesk.
🕒	Exécution quotidienne : le paquet utilise généralement /etc/cron.daily/00logwatch pour générer le rapport automatiquement.
🔎	Validation : un test manuel doit confirmer la lecture des logs, l’envoi du mail et l’absence d’erreur de permission.

Logwatch est un analyseur de journaux simple sur le papier, mais très efficace quand il est bien branché. Il collecte les événements des fichiers de logs, les trie par service, puis envoie un résumé quotidien par e-mail. Sur Ubuntu avec Plesk, l’intérêt est net : moins de lecture manuelle, plus de signaux utiles, à condition de pointer les bons fichiers.

1. Installer le paquet Logwatch avec APT.
2. Vérifier que Postfix ou un autre MTA peut envoyer du courrier localement.
3. Définir le destinataire du rapport dans une configuration locale.
4. Ajouter les logs spécifiques à Plesk si besoin.
5. Lancer un test manuel, puis valider l’arrivée du rapport quotidien.

« Logwatch ne remplace pas une supervision temps réel. Il réduit le bruit pour faire remonter ce qui compte. »

Comment installer Logwatch sur Ubuntu avec Plesk sans casser la configuration existante ?

La bonne approche est franche : on installe le paquet, on garde les fichiers d’origine intacts et on ne modifie que la surcouche locale dans /etc/logwatch/conf/. Sur un serveur Plesk, le vrai verrou n’est presque jamais Logwatch lui-même, mais la messagerie locale et la liste des journaux réellement surveillés.

Installer le paquet proprement

Commencez par mettre le système à jour, puis installez Logwatch avec un MTA local si votre serveur n’en a pas déjà un. Dans un environnement Plesk, Postfix est souvent le choix le plus simple pour l’envoi local. Si le serveur sort déjà ses mails, ne rajoutez pas un second relais sans raison.

sudo apt update
sudo apt install logwatch postfix bsd-mailx

Si l’assistant de configuration de Postfix s’ouvre, un profil de type Local only convient dans beaucoup de cas pour un serveur qui doit surtout envoyer des rapports système. L’important n’est pas d’exposer un relais SMTP, mais de disposer d’une commande d’envoi fiable pour le mail Logwatch.

Vérifier que l’envoi de mail fonctionne

Le test le plus bête est souvent le meilleur : envoyez un message court depuis le serveur et regardez s’il arrive. Sans ce test, vous risquez de croire que Logwatch est cassé alors que le vrai problème se situe au niveau du transport mail, du relais ou du filtrage côté destinataire.

echo "Test de mail local" | mail -s "Test Logwatch" admin@example.com
systemctl status postfix
journalctl -u postfix -n 50

Si rien n’arrive, inspectez /var/log/mail.log ou le journal systemd selon votre version d’Ubuntu. Sur un serveur en production, c’est souvent là que la vérité sort du trou noir : adresse invalide, queue bloquée, alias root absent, ou résolution DNS mal fichue.

Quels fichiers modifier pour configurer Logwatch proprement ?

Logwatch fonctionne bien quand on ne touche pas aux defaults directement. On copie la configuration de base dans l’espace local, puis on définit le destinataire, le niveau de détail et la portée des rapports. C’est la méthode la plus propre sur Ubuntu, et elle évite de casser la config lors d’une mise à jour de paquet.

Les fichiers qui comptent vraiment

Fichier ou dossier	Rôle	Quand l’utiliser
/usr/share/logwatch/default.conf/logwatch.conf	Configuration par défaut fournie par le paquet	Comme référence, jamais comme fichier à éditer en premier
/etc/logwatch/conf/logwatch.conf	Surcouche locale prioritaire	Pour définir MailTo, Detail, Range et Output
/etc/logwatch/conf/logfiles/	Déclarations de journaux supplémentaires	Quand certains logs Plesk ne remontent pas dans le rapport
/etc/logwatch/conf/services/	Réglages par service	Pour affiner Apache, Nginx, SSH, mail ou exclure du bruit
/etc/cron.daily/00logwatch	Lancement quotidien automatique	Pour l’exécution standard sans tâche cron personnalisée

Exemple de configuration minimale utile

Voici une base saine pour configurer Logwatch sans surjouer. Le but est d’obtenir un rapport logs serveur lisible, pas un roman de 14 pages à 7 h du matin. Ajustez l’adresse e-mail, puis montez ou baissez le niveau de détail selon le bruit réel de votre machine.

sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf
sudo nano /etc/logwatch/conf/logwatch.conf

Output = mail
MailTo = admin@example.com
MailFrom = logwatch@serveur.example.com
Detail = Med
Range = yesterday
Service = All

Si vous voulez que le courrier destiné à root parte vers une boîte externe, ajoutez aussi un alias dans /etc/aliases puis régénérez la base. C’est une vieille habitude, mais elle évite de perdre des rapports quand le compte root n’est pas surveillé.

root: admin@example.com
sudo newaliases

« Le bon niveau de détail n’est pas celui qui parle de tout. C’est celui qui fait ressortir ce qui déraille. »

Comment adapter Logwatch aux logs Plesk sans noyer le rapport ?

Sur un serveur Plesk, les journaux utiles ne se limitent pas à /var/log/syslog et /var/log/auth.log. Il faut aussi prendre en compte les logs du panneau, du serveur web et parfois les logs propres à chaque abonnement. Sans ça, Logwatch surveille l’Ubuntu standard, mais oublie le cœur de votre stack d’hébergement.

Les emplacements à vérifier en priorité

• /var/log/plesk/panel.log pour les actions du panneau d’administration.
• /var/log/plesk/httpsd_error_log et /var/log/plesk/httpsd_access_log pour l’activité web liée à Plesk.
• /var/log/auth.log pour les authentifications SSH et les élévations de privilèges.
• /var/log/syslog pour les messages système généraux.
• /var/www/vhosts/system/<domaine>/logs/ pour les journaux par site quand vous avez besoin d’un suivi fin.

Ajouter un fichier de logs personnalisé si nécessaire

Lorsque Logwatch ne lit pas certains journaux Plesk, créez un fichier local dans /etc/logwatch/conf/logfiles/. L’idée n’est pas de tout surcharger, mais d’ajouter seulement les journaux qui apportent du signal. Si votre serveur héberge beaucoup de domaines, mieux vaut cibler les vhosts critiques que vouloir aspirer tous les logs d’un coup.

sudo nano /etc/logwatch/conf/logfiles/plesk.conf

LogFile = /var/log/plesk/panel.log
LogFile = /var/log/plesk/httpsd_error_log
LogFile = /var/log/auth.log
LogFile = /var/log/syslog

Selon la version de Plesk et votre mode d’hébergement, certains journaux sont déjà pris en compte par les services web existants. D’autres demandent un ajustement manuel. C’est normal : la dispersion des logs est précisément ce qui rend la centralisation utile.

« Sur Plesk, le piège n’est pas l’analyse. Le piège, c’est la dispersion des journaux. »

Réduire le bruit des services trop bavards

Si le rapport devient pénible, baissez le détail ou excluez les services qui polluent l’ensemble. Par exemple, un serveur très actif en web ou en mail peut générer beaucoup de lignes attendues. Le but n’est pas d’archiver du bruit, mais de faire ressortir les erreurs réelles, les anomalies de connexion et les échecs répétés.

• Réduisez Detail de High à Med si le rapport est trop bavard.
• Excluez un service précis avec une syntaxe du type Service = "-service" si nécessaire.
• Garde-fou utile : vérifiez d’abord sur un serveur de préproduction.

Comment tester le rapport quotidien et vérifier qu’il part vraiment ?

Le test manuel est indispensable. Il confirme que Logwatch lit bien les journaux, que le format de rapport vous convient, et que l’e-mail sort sans friction. Si vous sautez cette étape, vous découvrirez le problème au pire moment : quand vous attendez un rapport et qu’il n’arrive jamais.

Lancer un rapport à la main

Pour une vérification rapide, générez un rapport pour la journée courante et affichez-le à l’écran. C’est le moyen le plus simple d’inspecter le contenu avant de l’envoyer. Vous pouvez ensuite forcer un envoi e-mail pour valider toute la chaîne, du parsing au transport.

sudo logwatch --range today --detail Med --output stdout | less
sudo logwatch --range today --detail Med --mailto admin@example.com --output mail

Vérifier la planification quotidienne

Le paquet installe généralement un script dans /etc/cron.daily/00logwatch. Si votre serveur exécute bien les tâches quotidiennes, le rapport doit partir tout seul. Sur les machines plus contrôlées, vous pouvez aussi créer votre propre entrée cron, mais ne le faites que si vous avez une vraie raison de changer l’horaire.

sudo ls -l /etc/cron.daily/00logwatch
sudo run-parts --test /etc/cron.daily

Pourquoi le rapport Logwatch reste vide ou n’arrive jamais ?

Dans 80 % des cas, Logwatch n’est pas en cause. Le problème vient du mail local, des permissions sur les journaux, d’un chemin Plesk mal déclaré ou d’un alias root oublié. La bonne méthode consiste à vérifier la chaîne complète, du fichier de log jusqu’à la boîte de réception, sans supposer que tout marche.

Les causes les plus fréquentes

• Aucun mail reçu : Postfix n’est pas opérationnel, ou le relais sortant est bloqué.
• Rapport vide : le bon service n’est pas lu, ou les logs ciblés ne contiennent rien sur la période choisie.
• Permission insuffisante : l’exécution manuelle ne voit pas les journaux que root lit sans problème via cron.daily.
• Logs Plesk absents : les chemins réels diffèrent de votre hypothèse, surtout pour les logs par domaine.
• Rapport trop gros : le niveau de détail est trop élevé et noie les incidents sous les lignes attendues.

La checklist de dépannage à garder sous la main

ls -l /var/log/plesk/
tail -n 50 /var/log/mail.log
journalctl -u postfix -n 50
sudo logwatch --range today --detail Low --output stdout

Si le test en sortie standard fonctionne mais pas l’e-mail, le coupable est ailleurs que dans Logwatch. Si le mail fonctionne mais que le rapport est vide, le problème est presque toujours la liste des logs ou la période analysée. Cette distinction évite de perdre du temps dans le mauvais compartiment.

« Si le mail sort mais que le rapport est vide, cherchez les chemins. Si le rapport est plein mais jamais reçu, cherchez le MTA. »

FAQ

Logwatch fonctionne-t-il sans Postfix ou autre MTA ?

Pas si vous voulez recevoir un mail. Logwatch peut produire un rapport à l’écran, mais pour l’envoi quotidien il lui faut une commande de livraison locale, généralement fournie par Postfix, Exim ou Sendmail. Sur Ubuntu avec Plesk, Postfix reste souvent l’option la plus simple et la plus prévisible.

Où sont les logs Plesk les plus utiles à surveiller ?

Les plus intéressants sont généralement /var/log/plesk/panel.log, les journaux web httpsd_error_log et httpsd_access_log, puis les journaux système classiques comme /var/log/auth.log et /var/log/syslog. Pour un hébergement multi-site, les logs par domaine sous /var/www/vhosts/system/ peuvent aussi être précieux.

Comment changer le destinataire du mail Logwatch ?

Le plus propre est d’éditer /etc/logwatch/conf/logwatch.conf et de définir MailTo. Si vous préférez centraliser les mails de root, ajoutez aussi un alias dans /etc/aliases puis exécutez newaliases. Les deux approches peuvent coexister sans se gêner.

Peut-on choisir un autre horaire que le cron quotidien ?

Oui. Le script standard passe par /etc/cron.daily/00logwatch, mais vous pouvez créer une tâche dédiée dans /etc/cron.d/ si vous voulez un envoi tôt le matin, après les rotations de logs, ou sur une fenêtre précise. Faites-le seulement si l’horaire standard ne convient pas.

Logwatch remplace-t-il Fail2ban ou une vraie supervision ?

Non. Logwatch sert à lire et synthétiser, pas à bloquer ni à alerter en temps réel. Fail2ban, une supervision métrique et des sauvegardes restent nécessaires. Logwatch complète l’ensemble en fournissant une vue quotidienne lisible, utile pour repérer les dérives qui passent sous le radar en temps réel.

Quand Logwatch est bien réglé, il devient un filtre simple et franchement rentable : il lit les bons journaux, trie le bruit, puis vous livre un résumé exploitable. Sur Ubuntu avec Plesk, l’équation est propre tant que la messagerie sortante fonctionne et que les chemins de logs ne sont pas laissés au hasard.