epitech-tracker — Diagnostics¶
Ces commandes s'exécutent sur le laptop étudiant (le tracker n'a pas de composant serveur dans ce dépôt — voir overview.md).
État du service¶
Résultat attendu :
● epitech-tracker.service - EPITECH CI — Agent de suivi d'activité étudiant
Loaded: loaded (/lib/systemd/system/epitech-tracker.service; enabled)
Active: active (running) since ...
# Le service a-t-il redémarré en boucle récemment ? (StartLimitBurst=5 en 60s)
systemctl show epitech-tracker -p NRestarts
# Activé au boot ?
systemctl is-enabled epitech-tracker
Logs¶
# Temps réel
journalctl -u epitech-tracker -f
# Dernière heure
journalctl -u epitech-tracker --since "1 hour ago"
# Fichier de log applicatif (miroir du StandardOutput du service)
sudo tail -f /var/log/epitech-tracker.log
# Chercher un cycle de collecte
journalctl -u epitech-tracker | grep -i "snapshot envoyé\|snapshot mis en queue"
# Chercher des erreurs
journalctl -u epitech-tracker --since "1 day ago" | grep -iE "erreur|error|exception|rejeté|non enrôlée"
Identité et enrôlement¶
# Le poste est-il enrôlé ? (root uniquement — contient la clé HMAC)
sudo cat /etc/epitech-tracker/identity.json
sudo stat -c "%a %U" /etc/epitech-tracker/identity.json # attendu : 600 root
# URL API effective pour ce poste
sudo cat /etc/epitech-tracker/tracker.env
Ne jamais faire transiter le contenu de identity.json en dehors du poste
Il contient key, la clé HMAC qui signe les snapshots de CE poste. La transférer (capture d'écran, copier-coller dans un ticket, export) permet de forger des relevés au nom de l'étudiant. Se limiter à vérifier sa présence et sa structure (deviceId/key non vides), jamais sa valeur, en dehors d'un contexte de débogage strictement nécessaire.
Queue hors-ligne¶
# Nombre de snapshots en attente et taille occupée
ls -lh /var/lib/epitech-tracker/queue/ | tail -n +2 | wc -l
du -sh /var/lib/epitech-tracker/queue/
# Le plus ancien et le plus récent en attente (tri chronologique par nom de fichier)
ls /var/lib/epitech-tracker/queue/ | sort | head -1
ls /var/lib/epitech-tracker/queue/ | sort | tail -1
# Inspecter un snapshot en attente (contenu, pas de secret dedans — la clé n'y est jamais écrite)
cat /var/lib/epitech-tracker/queue/<fichier>.json | python3 -m json.tool
Une queue qui grossit sans jamais se vider indique soit une panne réseau/Zeno prolongée, soit des rejets 401/403/429/5xx répétés (voir troubleshooting.md) — dans les deux cas, sender.py conserve les données, rien n'est perdu tant que la limite de 7 jours / 50 Mo n'est pas atteinte.
Vérifier que le service reporte correctement¶
# 1. Le process tourne
pgrep -af "main.py" | grep epitech-tracker
# 2. Un cycle de collecte a bien eu lieu récemment (toutes les 5 min normalement)
journalctl -u epitech-tracker --since "10 minutes ago" | grep -i "snapshot"
# 3. La queue ne grossit pas de façon anormale
ls /var/lib/epitech-tracker/queue/ | wc -l
# 4. Tester la collecte d'un snapshot manuellement, sans l'envoyer
cd /opt/epitech-tracker
python3 -c "
from observer import collect_snapshot
from detector import detect_active_project
import json
p = detect_active_project()
s = collect_snapshot(active_project=p)
print(json.dumps(s, indent=2, ensure_ascii=False))
"
Mise à jour automatique¶
# Version actuelle installée
grep '^Version:' /var/lib/dpkg/info/epitech-tracker.control 2>/dev/null || dpkg -s epitech-tracker | grep Version
# Dernier check de version effectué (loggué chaque heure)
journalctl -u epitech-tracker | grep -i "vérification mise à jour" | tail -5
# Vérifier manuellement ce que Zeno publie comme dernière version
curl -s https://zeno.epitech.africa/sonde/version
Réseau¶
# Ce que voit le tracker pour la connectivité/réseau EPITECH (mêmes commandes qu'observer.py)
nmcli -t -f STATE general
nmcli -t -f active,ssid dev wifi
hostname -I
Immuabilité (anti-tamper)¶
# Vérifier l'attribut immuable posé par postinst
lsattr /usr/lib/systemd/system/epitech-tracker.service
lsattr -d /opt/epitech-tracker/
# Le lever avant toute intervention manuelle (dpkg le fait lui-même via prerm)
sudo chattr -i /usr/lib/systemd/system/epitech-tracker.service
sudo chattr -R -i /opt/epitech-tracker/
Construire et inspecter le paquet .deb¶
cd tracker/ # racine du dépôt cloné
# Build (Linux, nécessite dpkg-dev)
./build.sh
# Build depuis macOS (Docker/Colima, sans machine Linux)
docker run --rm -v "$PWD":/work -w /work debian:stable-slim \
bash -c "apt-get update -qq && apt-get install -y -qq dpkg-dev >/dev/null && ./build.sh"
# Inspecter le paquet généré
dpkg-deb --info epitech-tracker_<version>_all.deb
dpkg-deb --contents epitech-tracker_<version>_all.deb
# Vérifier que les trois artefacts de publication sont cohérents
cat tools.deb.version
sha256sum tools.deb # doit correspondre à tools.deb.sha256
cat tools.deb.sha256
# Nettoyer les artefacts de build
./build.sh --clean
build.sh échoue explicitement (avant même de builder) si package/DEBIAN/control et src/config.py::TRACKER_VERSION ne portent pas la même version — un message d'erreur explicite indique lequel des deux corriger.
Tests¶
Aucune dépendance (stdlib unittest uniquement) — tourne aussi sur macOS. Le CI (.github/workflows/release.yml) exécute ces tests avant le build : un paquet ne se publie pas si les tests échouent. Couverture par module : queue_manager (rotation/purge/ordre), observer (parsing /proc), detector (regex des dépôts EPITECH), identity (forme de la signature HMAC), updater (rejet sha256 invalide, comparaison de versions).
python3 -m unittest, pas python manage.py test
Ce n'est pas un projet Django — il n'y a pas de manage.py. La commande de test est celle de la stdlib unittest, avec discover.