Co-authored-by: Codex/gpt-5.6-terra <codex-gpt-5.6-terra@agents.invalid>
5.6 KiB
Exploitation de pronote-sync
Ce guide décrit l'installation et l'exploitation des artefacts de déploiement fournis par le projet. Les paramètres de l'unité systemd fournie sont des exemples d'installation : adaptez-les à l'hôte cible avant son installation. Ne placez jamais de secret dans une unité systemd, une commande shell, un journal ou ce document.
Préparer l'hôte
Installez le projet et ses dépendances dans le répertoire choisi, puis créez le
fichier d'environnement référencé par l'unité à partir de .env.example. Il
doit rester local et lisible uniquement par le compte de service :
sudo install -d -m 0700 -o <utilisateur-service> -g <groupe-service> <repertoire-configuration>
sudo install -m 0600 -o <utilisateur-service> -g <groupe-service> .env <fichier-environnement>
Les unités fournies nécessitent l'interface CLI livrée au jalon M12. Avant de les installer, vérifiez que la version installée contient bien ce point d'entrée :
.venv/bin/pronote-sync --help
Avant toute activation ou mise à jour, exécutez les contrôles depuis la racine du projet :
.venv/bin/python scripts/check_secrets.py
.venv/bin/python -m pip check
.venv/bin/pronote-sync --dry-run
Le contrôle des secrets doit réussir avant le déploiement. Il inspecte les
fichiers textuels de l'artefact, en excluant volontairement .env, les
environnements virtuels, les répertoires générés, tests/ et
GUIDE_DEV_PYTHON.md ; les sentinelles et exemples de ces deux derniers ne
bloquent donc pas le déploiement. Il ne valide ni les valeurs ni les permissions
du fichier d'environnement. Pour analyser seulement le contenu indexé avant un
commit, utilisez scripts/check_secrets.py --staged.
Le dry-run vérifie le pipeline sans appliquer les écritures de synchronisation ; il ne remplace pas une vérification des paramètres réellement chargés.
Installation systemd
Les fichiers versionnés sont :
deploy/systemd/pronote-sync.service;deploy/systemd/pronote-sync.timer.
Copiez-les dans le répertoire d'unités systemd de l'hôte. Avant de les activer,
adaptez User, Group, WorkingDirectory, EnvironmentFile, les chemins des
exécutables dans ExecStartPre et ExecStart, ainsi que les chemins de
StateDirectory, LogsDirectory et ReadWritePaths. L'artefact fourni prend
pour exemple le compte pronote-sync, le code dans /opt/pronote-sync, l'état
dans /var/lib/pronote-sync, les logs dans /var/log/pronote-sync et le fichier
d'environnement /etc/pronote-sync/pronote-sync.env. Ne copiez pas de valeur
secrète dans l'unité.
sudo install -m 0644 deploy/systemd/pronote-sync.service /etc/systemd/system/
sudo install -m 0644 deploy/systemd/pronote-sync.timer /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now pronote-sync.timer
systemctl list-timers pronote-sync.timer
Pour tester une exécution sans attendre la prochaine échéance :
sudo systemctl start pronote-sync.service
sudo systemctl status pronote-sync.service
Une exécution en échec laisse l'unité pronote-sync.service en état failed.
La supervision de l'hôte doit donc déclencher une alerte sur cet état ou sur un
échec du timer/service ; le transport de cette alerte (courriel, XMPP ou système
de supervision) relève de l'exploitation locale.
Journaux et alertes
La configuration systemd redirige la sortie standard et la sortie d'erreur vers
/var/log/pronote-sync/pronote-sync.log. Consultez ce fichier ou, selon la
configuration de l'hôte, le journal de l'unité :
sudo tail -f /var/log/pronote-sync/pronote-sync.log
sudo journalctl -u pronote-sync.service --since today
sudo journalctl -u pronote-sync.service -f
systemctl status pronote-sync.timer
Traitez un statut non nul ou une unité failed comme un échec à investiguer.
Les logs applicatifs masquent les secrets configurés, mais évitez tout de même
de partager sans relecture un export de journal : une donnée sensible issue de
l'environnement ou d'un outil tiers ne doit pas être supposée sûre par défaut.
Rotation des journaux
L'artefact deploy/logrotate/pronote_sync cible le fichier
/var/log/pronote-sync/pronote-sync.log utilisé par l'unité fournie. Installez-
le puis validez sa syntaxe avant activation :
sudo install -m 0644 deploy/logrotate/pronote_sync /etc/logrotate.d/pronote_sync
sudo logrotate --debug /etc/logrotate.d/pronote_sync
La rotation configurée est quotidienne, conserve sept archives et utilise
compress avec delaycompress. Elle recrée le fichier avec les droits 0640
pour le compte de service. Si vous modifiez le chemin de journal dans l'unité,
mettez aussi à jour la règle logrotate correspondante.
Mise à jour et retour au service
Avant de remplacer les dépendances ou le code, conservez une copie protégée du fichier d'environnement local, sans l'ajouter au dépôt. Après la mise à jour, réexécutez, dans cet ordre, les contrôles de secrets, de cohérence des paquets et le dry-run :
.venv/bin/python scripts/check_secrets.py
.venv/bin/python -m pip check
.venv/bin/pronote-sync --dry-run
Rechargez ensuite les unités si leurs fichiers ont changé, puis vérifiez une exécution et son journal :
sudo systemctl daemon-reload
sudo systemctl restart pronote-sync.timer
sudo systemctl start pronote-sync.service
journalctl -u pronote-sync.service -n 100 --no-pager
En cas d'échec, ne relancez pas automatiquement après avoir modifié des identifiants : corrigez la configuration locale, repassez le contrôle des secrets et le dry-run, puis consultez le journal expurgé.