Nommez la machine
Précisez le VPS ou le service concerné avant de demander une inspection.
Précisez la machine, les actions autorisées et ce qui doit rester inchangé. Ces exemples vous aident à préparer une conversation ; ils ne déclenchent aucune opération.
Lance un diagnostic en lecture seule de cette machine. Résume son état système et les points à examiner, sans rien modifier.
Examine l’état et les journaux récents de nginx sur cette machine. Résume les faits sans redémarrer le service.
Examine le conteneur web-prod et ses journaux récents. Résume ce que tu observes sans modifier ni redémarrer le conteneur.
Diagnostique le service nginx. Si les observations justifient un redémarrage du service, présente la demande et attends mon approbation humaine avant toute modification.
Précisez le VPS ou le service concerné avant de demander une inspection.
Demandez un diagnostic en lecture seule pour comprendre la situation.
Demandez un plan, relisez l’action proposée et approuvez uniquement celle que vous souhaitez.
Ces parcours sont des exemples à adapter, pas des comptes rendus d’opérations réalisées. Ils n’exécutent rien ; demandez uniquement les actions disponibles pour votre machine.
Sur mon VPS, examine l’état de nginx et ses journaux récents en lecture seule. Repère les erreurs liées au service en amont, sans redémarrer ni modifier la configuration.
L’heure des erreurs, le service ou conteneur en amont et les messages de connexion. Distinguer les faits observés des causes encore à vérifier.
Avant d’agir : Une erreur 502 ne suffit pas à justifier un redémarrage. Préparer une demande ciblée seulement après le diagnostic.
Consulte l’état système de mon VPS et prépare un plan de nettoyage avec les actions disponibles. Présente ce qui serait supprimé et les limites du diagnostic, sans appliquer le nettoyage.
L’espace disponible signalé par la machine et les éléments retenus par le plan de nettoyage. Ne pas présenter un plan comme une suppression déjà réalisée.
Avant d’agir : Le nettoyage effectif nécessite les permissions prévues et une approbation humaine. Vérifier les données à conserver.
Pour le service concerné sur mon VPS, examine les journaux et les fichiers de certificat autorisés en lecture seule. Indique si les données accessibles permettent de confirmer l’échéance ; sinon, précise ce qui manque.
Les avertissements du service et l’échéance seulement si elle peut être établie à partir des données accessibles. Ne jamais demander le contenu d’une clé privée.
Avant d’agir : Aucun contrôle universel de certificat ni renouvellement automatique n’est promis. Vérifier séparément le certificat public si les actions disponibles ne suffisent pas.
Examine l’état et les journaux du service ou du conteneur concerné après le déploiement. Résume l’erreur et les vérifications nécessaires avant d’envisager un retour arrière. Ne relance ni ne restaure rien.
L’état actuel, les messages d’échec et la version concernée lorsqu’elle est identifiable. Une cause supposée doit rester présentée comme une hypothèse.
Avant d’agir : Les actions de déploiement et de restauration prises en charge nécessitent un administrateur et une approbation. Vérifier la cible et la version avant validation.
Connectez votre serveur, adaptez un exemple et commencez par observer avant de préparer une intervention.