Supervision des mises à jour de l'infrastructure AJLSM

Supervision des mises à jour de l'infrastructure AJLSM

Dernière mise à jour : 14 octobre 2026

Présentation générale

Élément	Information
Serveur de supervision	Saturne3
Systèmes surveillés	Saturne3, Beotos3, Eole3, PBS100, AD64, APBP2
Mise en service initiale	13 octobre 2026
Extension à six serveurs	14 octobre 2026
Contrôle quotidien	Tous les jours à 6 h
Rapport hebdomadaire	Lundi à 7 h
Installation automatique	Aucune
Redémarrage automatique	Aucun
Notifications	Courriel hebdomadaire à ajlsm@ajlsm.com
Configuration des serveurs	/etc/ajlsm/supervision-serveurs.conf

Objectif

La supervision des mises à jour AJLSM permet de surveiller quotidiennement les mises à jour disponibles sur les principaux serveurs de l'infrastructure.

Le dispositif est centralisé sur Saturne3.

Il permet :

• D'actualiser les index APT des serveurs.
• D'identifier les mises à jour disponibles.
• De distinguer les mises à jour de sécurité Debian/Ubuntu des autres mises à jour, lorsque cette distinction est possible.
• De détecter les erreurs d'accès SSH et les échecs des commandes APT.
• De conserver les incidents rencontrés entre deux rapports.
• De vérifier que chaque serveur configuré figure exactement une fois dans le rapport.
• D'envoyer un rapport hebdomadaire récapitulatif.

Aucun paquet n'est installé automatiquement par ces scripts.

Les mises à jour et les éventuels redémarrages restent des opérations de maintenance manuelles.

Le suivi opérationnel, les versions des systèmes et les historiques d'intervention sont documentés dans :

Maintenance et mises à jour de l'infrastructure AJLSM

Architecture

Serveurs surveillés

Serveur	Fonction	Cible de supervision	Mode
Saturne3	Hyperviseur principal et serveur de supervision	local	Exécution locale
Beotos3	Hyperviseur et serveur de sauvegarde	root@192.168.123.104	SSH
Eole3	Serveur de données et d'images	root@192.168.123.202	SSH
PBS100	Serveur Proxmox Backup Server	root@51.178.245.43	SSH
AD64	Serveur applicatif AD64	root@192.168.123.41	SSH
APBP2	Serveur applicatif APBP2	root@192.168.123.42	SSH

Attention : Beotos3 et PBS100 sont deux systèmes distincts.

Beotos3 est le serveur physique Proxmox. PBS100 est la machine virtuelle hébergeant Proxmox Backup Server.

Ils sont supervisés séparément.

Principe de fonctionnement

Le mécanisme comporte deux opérations distinctes :

1. Une collecte quotidienne des informations APT.
2. Un rapport hebdomadaire envoyé par courriel.

Les opérations sont ordonnancées par systemd.

Les contrôles quotidiens sont silencieux : ils n'envoient pas directement de courriel.

Les anomalies sont enregistrées dans un journal d'incidents et reprises dans le rapport hebdomadaire.

Schéma de fonctionnement

                      SATURNE3
                 Serveur de supervision
                           |
                           |
              Configuration centralisée
         /etc/ajlsm/supervision-serveurs.conf
                           |
                           |
                 Tous les jours à 6 h
                           |
                           v
              supervision_updates.sh
                           |
             +-------------+-------------+
             |                           |
        Exécution locale             Connexions SSH
             |                           |
         Saturne3          +-------------+-------------+
                           |             |             |
                        Beotos3        Eole3         PBS100
                           |             |             |
                           +-------------+-------------+
                                         |
                                      AD64
                                      APBP2
                           |
                           v
               supervision_updates_collect.py
                           |
                           v
                  Résultat quotidien
                           |
                +----------+----------+
                |                     |
        dernier-rapport.txt       incidents.log
                |                     |
                +----------+----------+
                           |
                    Lundi à 7 h
                           |
                           v
                supervision_rapport.sh
                           |
                           v
                         Postfix
                           |
                           v
                    ajlsm@ajlsm.com

Configuration centralisée des serveurs

Emplacement

La liste des serveurs supervisés est définie dans :

/etc/ajlsm/supervision-serveurs.conf

Cette configuration est utilisée par les deux scripts :

• supervision_updates.sh
• supervision_rapport.sh

Elle évite de maintenir deux listes de serveurs indépendantes.

Contenu actuel

# Supervision APT AJLSM
# Format : Nom|Cible SSH
# Utiliser "local" pour Saturne3.

Saturne3|local
Beotos3|root@192.168.123.104
Eole3|root@192.168.123.202
PBS100|root@51.178.245.43
AD64|root@192.168.123.41
APBP2|root@192.168.123.42

Format

Chaque ligne contient :

Nom|Cible

Exemples :

Saturne3|local
Beotos3|root@192.168.123.104

Les lignes vides et les commentaires commençant par # sont ignorés.

Les scripts vérifient :

• La présence du fichier de configuration.
• La présence d'au moins un serveur.
• Le format des entrées.
• L'absence de noms de serveurs en double.

Une configuration invalide provoque l'arrêt du script concerné.

Ajouter un serveur

Pour ajouter un serveur :

1. Vérifier que le serveur dispose d'APT et de Python 3 avec la bibliothèque python-apt.
2. Configurer l'authentification SSH depuis Saturne3.
3. Vérifier la clé d'identité SSH du serveur distant.
4. Tester la connexion SSH sans agent interactif.
5. Ajouter une ligne dans supervision-serveurs.conf.
6. Vérifier la syntaxe des scripts.
7. Lancer une collecte de supervision.
8. Vérifier que le serveur apparaît dans le rapport.
9. Mettre à jour la documentation MediaWiki.
10. Enregistrer la modification dans SVN.

Exemple :

NOUVEAU|root@192.168.123.50

Important : l'ajout d'un serveur ne nécessite pas de modifier les listes internes des scripts.

Authentification SSH

Principe

Saturne3 interroge les serveurs distants en SSH avec le compte root.

L'authentification repose sur une clé publique autorisée sur les serveurs distants.

Le script utilise notamment :

-o BatchMode=yes
-o ConnectTimeout=10
-o StrictHostKeyChecking=yes

• BatchMode=yes empêche les demandes interactives de mot de passe.
• ConnectTimeout=10 limite le délai d'établissement de la connexion.
• StrictHostKeyChecking=yes impose la vérification de la clé d'identité du serveur distant.

Les clés d'identité SSH des serveurs doivent donc être connues et vérifiées avant leur utilisation automatisée.

Clé SSH de Saturne3

La clé publique ED25519 du compte root de Saturne3 possède l'empreinte :

SHA256:fTlK1a2y6at6ZPpDWVy1of+Q210IxxaU1NkmqMgDkyw

Elle est autorisée dans le fichier suivant sur les serveurs supervisés :

/root/.ssh/authorized_keys

Le fichier authorized_keys contient les clés publiques des clients autorisés à se connecter.

Il ne doit pas être confondu avec les clés d'identité SSH propres au serveur.

Incident du 14 octobre 2026

Lors du contrôle automatique de 6 h, trois connexions SSH ont échoué :

• Beotos3 ;
• Eole3 ;
• PBS100.

Les erreurs étaient enregistrées avec le code 255.

Les connexions fonctionnaient pourtant depuis une session interactive root sur Saturne3.

Cause identifiée :

La session interactive disposait d'un agent SSH, accessible par la variable :

SSH_AUTH_SOCK

Cet agent permettait l'utilisation de clés qui n'étaient pas directement disponibles pour le service systemd.

Le service systemd ne disposait pas de cet agent.

Les connexions échouaient donc lors de l'exécution automatique.

Correction appliquée :

La clé publique ED25519 du compte root de Saturne3 a été ajoutée aux fichiers authorized_keys de Beotos3, Eole3 et PBS100.

Les clés déjà autorisées ont été conservées.

Les connexions ont ensuite été vérifiées sans agent SSH.

Le contrôle quotidien a été relancé via systemd et s'est terminé sans erreur sur les six serveurs.

Tester une connexion sans agent SSH

Depuis Saturne3 :

env -u SSH_AUTH_SOCK ssh \
    -o IdentityAgent=none \
    -o BatchMode=yes \
    -o IdentitiesOnly=yes \
    -i /root/.ssh/id_ed25519 \
    root@192.168.123.104 \
    'hostname'

Adapter l'adresse au serveur concerné.

Ce test vérifie que l'authentification fonctionne sans dépendre de l'agent SSH de la session interactive.

Pour vérifier tous les serveurs, utiliser les cibles indiquées dans le fichier de configuration.

Particularité de template3

Le modèle de VM Ubuntu template3 contient désormais la clé publique ED25519 de Saturne3 dans :

/root/.ssh/authorized_keys

Les nouvelles VM clonées à partir de template3 héritent de cette autorisation.

En parallèle, template3 possède un mécanisme de régénération automatique des clés SSH d'identité du serveur après clonage.

Il faut distinguer :

Élément	Fonction	Comportement après clonage
/root/.ssh/authorized_keys	Autorise Saturne3 à se connecter	Conservé
/etc/ssh/ssh_host_*	Identifie le serveur SSH	Régénéré automatiquement

Le README de template3 documente ce fonctionnement.

Attention : une VM clonée doit recevoir sa propre configuration réseau avant d'être démarrée simultanément avec une autre VM utilisant les mêmes adresses.

Scripts

Emplacement

Les scripts sont installés sur Saturne3 dans :

/usr/local/sbin/

Fichier	Fonction
supervision_updates.sh	Orchestration des contrôles quotidiens
supervision_updates_collect.py	Analyse et classification des mises à jour APT
supervision_rapport.sh	Production et envoi du rapport hebdomadaire

supervision_updates.sh

Ce script assure la supervision quotidienne des six serveurs.

Il lit la liste des serveurs dans :

/etc/ajlsm/supervision-serveurs.conf

Pour chaque serveur :

1. Actualisation des index APT avec apt-get update.
2. Vérification du résultat de l'actualisation.
3. Exécution du collecteur Python.
4. Enregistrement des mises à jour disponibles.
5. Enregistrement des incidents éventuels.
6. Ajout d'un marqueur de fin de contrôle lorsque la vérification est réussie.

La commande d'actualisation utilise notamment :

apt-get update -qq -o APT::Update::Error-Mode=any

L'option Error-Mode=any permet de considérer comme une erreur un échec d'actualisation d'un dépôt APT.

Le script utilise des délais maximaux d'exécution pour éviter qu'un serveur indisponible bloque indéfiniment la supervision.

Les erreurs d'accès SSH et les erreurs APT sont enregistrées.

Marqueurs de contrôle

Lorsqu'un serveur a été vérifié avec succès, le script ajoute une ligne :

CONTROLE TERMINE : Saturne3

Chaque serveur possède son propre marqueur.

Le rapport hebdomadaire vérifie la présence d'un en-tête et d'un marqueur pour chaque serveur configuré.

Il exige que chacun apparaisse exactement une fois.

Cela permet notamment de détecter :

• Un serveur absent du rapport.
• Un contrôle interrompu.
• Un contrôle incomplet.
• Un serveur présent plusieurs fois.

supervision_updates_collect.py

Le collecteur Python utilise la bibliothèque python-apt.

Il examine les paquets installés et leurs versions candidates.

Pour chaque mise à jour disponible, il indique :

• Le nom du paquet.
• La version installée.
• La version candidate.

Les mises à jour sont réparties en deux catégories.

Sécurité Debian/Ubuntu

Versions candidates provenant des dépôts de sécurité Debian ou Ubuntu.

Autres mises à jour

Versions candidates provenant des autres dépôts, notamment Proxmox.

Exemple :

ATTENTION : 3 mise(s) a jour APT disponible(s)
Securite Debian/Ubuntu : 1
  exemple-paquet : 1.0 -> 1.1

Autres mises a jour (dont Proxmox) : 2
  exemple-proxmox : 2.0 -> 2.1
  exemple-debian : 3.0 -> 3.1

Limite importante :

Une mise à jour classée parmi les autres mises à jour peut également contenir un correctif de sécurité.

La classification repose sur la provenance APT de la version candidate.

Elle ne constitue pas une analyse exhaustive des vulnérabilités.

Le dispositif ne réalise pas de classification automatique des CVE selon leur gravité.

Les correctifs Ubuntu Pro ESM ne font pas l'objet d'un suivi spécifique.

supervision_rapport.sh

Le script produit le rapport hebdomadaire.

Il lit également :

/etc/ajlsm/supervision-serveurs.conf

Il vérifie notamment :

• La présence du rapport quotidien.
• Son ancienneté, limitée à 25 heures.
• La présence de tous les serveurs configurés.
• La présence d'un en-tête et d'un marqueur de contrôle exactement une fois par serveur.
• L'absence d'erreurs dans la dernière collecte.
• L'existence de mises à jour disponibles.
• Les incidents enregistrés depuis le précédent rapport.

Le rapport est transmis à Postfix avec :

/usr/sbin/sendmail

Expéditeur :

root@saturne3.ajlsm.com

Destinataire :

ajlsm@ajlsm.com

Cette adresse est une liste de diffusion.

Les destinataires peuvent être modifiés dans la gestion de la liste sans intervenir sur Saturne3.

Classification des rapports

Niveau	Critère	Objet du courriel
OK	Aucun paquet à mettre à jour et aucune anomalie	[AJLSM][OK] Maintenance hebdo
ACTION	Mises à jour disponibles sans anomalie	[AJLSM][ACTION] Maintenance hebdo
ERREUR	Rapport absent, incomplet, ancien ou incident enregistré	[AJLSM][ERREUR] Maintenance hebdo

L'objet réel du courriel contient également un résumé de la situation.

Exemple :

[AJLSM][ERREUR] Maintenance hebdo - Anomalie de supervision detectee

Le script ne produit pas d'alerte immédiate de type CRITIQUE.

Particularité des incidents historiques

Un rapport peut être classé ERREUR même si le dernier contrôle quotidien s'est terminé correctement.

C'est le cas lorsque des incidents ont été enregistrés depuis le précédent rapport.

Le premier rapport envoyé le 14 octobre 2026 illustre ce fonctionnement.

Les trois incidents SSH du matin étaient présents dans le rapport, alors que le contrôle quotidien suivant s'était terminé avec :

FIN DE VERIFICATION - Erreurs : 0

Ordonnancement systemd

Fichiers installés

/etc/systemd/system/supervision-updates.service
/etc/systemd/system/supervision-updates.timer

/etc/systemd/system/supervision-rapport.service
/etc/systemd/system/supervision-rapport.timer

Contrôle quotidien

Service :

[Unit]
Description=Supervision quotidienne des mises a jour AJLSM
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/sbin/supervision_updates.sh

Timer :

[Unit]
Description=Verification quotidienne des mises a jour AJLSM

[Timer]
OnCalendar=*-*-* 06:00:00
Persistent=true

[Install]
WantedBy=timers.target

Rapport hebdomadaire

Service :

[Unit]
Description=Rapport hebdomadaire des mises a jour AJLSM
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/sbin/supervision_rapport.sh

Timer :

[Unit]
Description=Envoi hebdomadaire du rapport de supervision AJLSM

[Timer]
OnCalendar=Mon *-*-* 07:00:00
Persistent=true

[Install]
WantedBy=timers.target

Remarque :

Ces configurations décrivent le fonctionnement du dispositif.

Les fichiers effectivement installés sur Saturne3 restent la référence pour leur contenu exact.

Activation des timers

Après installation ou modification des unités :

systemctl daemon-reload

systemctl enable --now supervision-updates.timer
systemctl enable --now supervision-rapport.timer

Vérification

Lister les timers :

systemctl list-timers --all | grep supervision

Vérifier leur activation :

systemctl is-enabled supervision-updates.timer
systemctl is-enabled supervision-rapport.timer

Vérifier leur état :

systemctl status supervision-updates.timer
systemctl status supervision-rapport.timer

Lancement manuel

Collecte quotidienne :

systemctl start supervision-updates.service

Cette commande actualise les index APT et collecte les informations.

Elle n'installe aucun paquet.

Rapport hebdomadaire :

systemctl start supervision-rapport.service

Attention : cette commande déclenche un véritable envoi de courriel.

Elle doit être utilisée uniquement lorsqu'un nouvel envoi est souhaité.

Journaux et fichiers d'état

Fichiers utilisés

Fichier	Fonction
/var/log/supervision-updates.log	Historique des contrôles quotidiens
/var/lib/supervision-updates/dernier-rapport.txt	Résultat de la dernière collecte
/var/lib/supervision-updates/incidents.log	Incidents non encore archivés
/var/lib/supervision-updates/incidents-archives.log	Historique des incidents transmis
/var/lib/supervision-updates/derniere-position	Position de lecture dans le journal d'incidents
/var/lib/supervision-updates/dernier-envoi	Fichier actuellement réservé, non exploité par le script hebdomadaire

Les fichiers d'état sont gérés par root.

Les journaux et fichiers d'état doivent conserver des permissions restrictives.

Gestion des incidents

Lorsqu'un contrôle échoue, le script quotidien ajoute une entrée dans incidents.log.

Chaque entrée contient :

• La date et l'heure.
• Le serveur concerné.
• La description de l'erreur.

Exemple :

2026-10-14 06:00:10 | Beotos3 | Echec actualisation APT (code 255)

Le rapport hebdomadaire reprend les incidents qui n'ont pas encore été transmis.

Un mécanisme de positionnement en octets permet de ne pas renvoyer les mêmes incidents lors des rapports suivants.

Seules les lignes complètes sont traitées.

Après acceptation du courriel par Postfix :

1. Les incidents transmis sont archivés.
2. La position de lecture est mise à jour.
3. Le journal actif est purgé lorsque toutes ses lignes ont été traitées.

Un verrou commun protège le journal contre les écritures simultanées pendant la préparation du rapport.

Verrous

/run/supervision-updates.lock
/run/supervision-rapport.lock
/run/supervision-incidents.lock

Les verrous sont gérés avec flock.

Ils empêchent les exécutions concurrentes susceptibles de provoquer des incohérences.

Rotation des journaux

Journal quotidien

Configuration :

/etc/logrotate.d/supervision-updates

Contenu :

/var/log/supervision-updates.log {
    weekly
    maxsize 10M
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0600 root root
}

Archives des incidents

Configuration :

/etc/logrotate.d/supervision-incidents

Contenu :

/var/lib/supervision-updates/incidents-archives.log {
    weekly
    rotate 12
    compress
    missingok
    notifempty
    create 0600 root root
}

Le journal actif incidents.log n'est pas soumis à logrotate.

Il est géré directement par le script hebdomadaire.

Vérification de logrotate

logrotate -d /etc/logrotate.d/supervision-updates
logrotate -d /etc/logrotate.d/supervision-incidents

L'option -d permet une simulation sans rotation effective.

Exploitation courante

Consulter le dernier rapport

cat /var/lib/supervision-updates/dernier-rapport.txt

Consulter les derniers contrôles

tail -100 /var/log/supervision-updates.log

Consulter les incidents

cat /var/lib/supervision-updates/incidents.log

Consulter les archives

cat /var/lib/supervision-updates/incidents-archives.log

Vérifier les exécutions systemd

journalctl -u supervision-updates.service --no-pager -n 100

journalctl -u supervision-rapport.service --no-pager -n 100

Vérifier les six contrôles

grep '^CONTROLE TERMINE :' \
    /var/lib/supervision-updates/dernier-rapport.txt

Résultat attendu :

CONTROLE TERMINE : Saturne3
CONTROLE TERMINE : Beotos3
CONTROLE TERMINE : Eole3
CONTROLE TERMINE : PBS100
CONTROLE TERMINE : AD64
CONTROLE TERMINE : APBP2

Le rapport doit également se terminer par :

FIN DE VERIFICATION - Erreurs : 0

Diagnostic

Absence de rapport quotidien

Vérifier :

systemctl status supervision-updates.timer
systemctl status supervision-updates.service

journalctl -u supervision-updates.service --no-pager -n 100

Erreur SSH

Tester depuis Saturne3, sans agent SSH :

env -u SSH_AUTH_SOCK ssh \
    -o IdentityAgent=none \
    -o BatchMode=yes \
    -o IdentitiesOnly=yes \
    -i /root/.ssh/id_ed25519 \
    root@192.168.123.104 true

Adapter l'adresse au serveur concerné.

Si le test échoue :

1. Vérifier la connectivité réseau.
2. Vérifier le service SSH du serveur distant.
3. Vérifier la présence de la clé publique de Saturne3 dans authorized_keys.
4. Vérifier les permissions du répertoire .ssh et du fichier authorized_keys.
5. Vérifier la clé d'identité SSH du serveur distant.
6. Examiner les journaux SSH du serveur concerné.

Ne pas désactiver StrictHostKeyChecking pour contourner une erreur de clé d'identité.

Erreur APT

Vérifier sur le serveur concerné :

apt-get update
apt list --upgradable

Ces commandes ne déclenchent aucune installation.

Vérification des scripts

bash -n /usr/local/sbin/supervision_updates.sh

bash -n /usr/local/sbin/supervision_rapport.sh

python3 -m py_compile \
    /usr/local/sbin/supervision_updates_collect.py

Sauvegarde et gestion des versions SVN

Objectif

Les scripts et fichiers de configuration doivent être conservés dans le dépôt SVN du projet AJLSM.

L'objectif est de pouvoir :

• Retrouver une version antérieure.
• Identifier les modifications apportées.
• Réinstaller le mécanisme sur un autre serveur.
• Reconstituer les unités systemd.
• Conserver une documentation cohérente avec les fichiers installés.

Principe :

Les fichiers à versionner doivent être récupérés directement sur Saturne3.

Les contenus présentés dans cette documentation sont explicatifs et ne remplacent pas les fichiers réellement installés.

Fichiers à versionner

Fichier source sur Saturne3	Fonction
/usr/local/sbin/supervision_updates.sh	Collecte quotidienne
/usr/local/sbin/supervision_updates_collect.py	Analyse APT
/usr/local/sbin/supervision_rapport.sh	Rapport hebdomadaire
/etc/ajlsm/supervision-serveurs.conf	Liste centralisée des serveurs
/etc/systemd/system/supervision-updates.service	Service quotidien
/etc/systemd/system/supervision-updates.timer	Timer quotidien
/etc/systemd/system/supervision-rapport.service	Service hebdomadaire
/etc/systemd/system/supervision-rapport.timer	Timer hebdomadaire
/etc/logrotate.d/supervision-updates	Rotation du journal quotidien
/etc/logrotate.d/supervision-incidents	Rotation des archives d'incidents

Soit 10 fichiers à versionner.

La documentation MediaWiki doit également être exportée et conservée dans SVN.

Organisation SVN proposée

ajlsm/
└── supervision/
    └── updates/
        ├── scripts/
        │   ├── supervision_updates.sh
        │   ├── supervision_updates_collect.py
        │   └── supervision_rapport.sh
        │
        ├── config/
        │   └── supervision-serveurs.conf
        │
        ├── systemd/
        │   ├── supervision-updates.service
        │   ├── supervision-updates.timer
        │   ├── supervision-rapport.service
        │   └── supervision-rapport.timer
        │
        ├── logrotate/
        │   ├── supervision-updates
        │   └── supervision-incidents
        │
        └── documentation/
            ├── maintenance.mediawiki
            └── supervision.mediawiki

Cette arborescence est une proposition.

Elle devra être adaptée à l'organisation réelle du dépôt SVN AJLSM.

Fichiers à exclure de SVN

Les fichiers suivants ne doivent pas être versionnés :

• Les journaux d'exécution.
• Les rapports quotidiens générés.
• Les incidents actifs.
• Les archives d'incidents.
• Les fichiers de position de lecture.
• Les fichiers de verrouillage.
• Les sauvegardes temporaires.
• Les fichiers Python compilés.
• Les clés SSH privées.

Exemples :

*.bak
*.bak-*
*.log
*.log.*
__pycache__/
*.pyc
dernier-rapport.txt
derniere-position
dernier-envoi
incidents.log
incidents-archives.log
*.key

Attention : la clé privée SSH de Saturne3 ne doit jamais être déposée dans SVN.

Récupération des fichiers

Les fichiers doivent être copiés depuis leurs emplacements réels sur Saturne3.

Leur récupération sera effectuée dans un répertoire de travail dédié avant leur ajout au dépôt SVN.

Les fichiers originaux doivent rester en place.

La récupération ne nécessite ni arrêt des services, ni désactivation des timers.

Maintenance du dispositif

En cas de modification des scripts :

1. Conserver une copie de la version précédente.
2. Modifier le script concerné.
3. Vérifier sa syntaxe.
4. Tester son fonctionnement.
5. Mettre à jour la documentation.
6. Enregistrer la nouvelle version dans SVN.

En cas de modification des unités systemd :

systemctl daemon-reload

Vérifier ensuite les timers.

Historique du dispositif

Date	Intervention	Résultat
13/10/2026	Mise en service initiale de la supervision centralisée sur Saturne3, Beotos3, Eole3 et PBS100.	OK
14/10/2026	Ajout d'AD64 et APBP2.	OK
14/10/2026	Centralisation de la liste des serveurs dans supervision-serveurs.conf.	OK
14/10/2026	Correction de l'authentification SSH pour les exécutions systemd sans agent interactif.	OK
14/10/2026	Validation du contrôle quotidien sur les six serveurs.	OK
14/10/2026	Modification du destinataire vers ajlsm@ajlsm.com.	OK
14/10/2026	Premier envoi réel du rapport hebdomadaire ; réception confirmée.	OK

Références

• Maintenance et mises à jour de l'infrastructure AJLSM
• Documentation Debian APT.
• Documentation systemd.
• Documentation Proxmox VE.
• Documentation Ubuntu.