Break · Linux Troubleshooting Lab

Réduire l’occupation de `/var/log` en supprimant les logs volumineux non essentiels.

Donner la permission d’exécution au script `/opt/app/deploy.sh`.

Éliminer le processus zombie en tuant son parent.

Rendre le script de sauvegarde exécutable pour que la tâche cron fonctionne à nouveau.

Démarrer la dépendance `db` puis stabiliser `web` (les deux doivent tourner).

Arrêter `legacy` (pour libérer 8080) puis démarrer `app`.

Créer le répertoire hôte `/data/postgres` et obtenir `db` en état `running`.

Connecter le conteneur `api` au réseau `backend`.

Redémarrer le conteneur backend pour que nginx serve à nouveau l’application.

Remplacer le certificat expiré par le renouvelé, puis recharger nginx.

Corriger la syntaxe de `/etc/nginx/sites-enabled/app.conf` jusqu’à ce que `nginx -t` passe.

Rendre le service `webapp` actif (`active (running)`).

Obtenir `database` puis `app` tous deux `active`.

Recharger la configuration systemd puis démarrer `metrics` (`active`).

Identifier l’intrusion et supprimer le cron malveillant `/etc/cron.d/backdoor`.

Tuer le processus qui fuit la mémoire (aucun process ne doit dépasser ~50% de RAM).

Lire le log compressé, comprendre l’échec silencieux et créer le répertoire manquant `/opt/app/data`.