Résolution des incidents

Si vous rencontrez des problèmes, commencez par vérifier les points suivants :

• Assurez-vous que le chemin d'accès aux fichiers de propriétés est correct lors de l'installation.
• Consultez les fichiers journaux pour vérifier que la configuration système requise est correcte.

  Si l'installation échoue, le programme d'installation nettoie automatiquement les ressources extraites, laissant les fichiers .log intacts pour le débogage.

• Assurez-vous que le FQDN AppScan 360° est défini dans le serveur DNS.
• Vérifiez que tous les pods AppScan 360° fonctionnent.
• Entrez l'adresse URL AppScan 360° pour voir le service.

Si vous rencontrez des problèmes pour vous connecter à AppScan 360°, essayez les solutions suivantes :

• Vérifiez que le cluster AppScan 360° peut se connecter à la machine de la base de données.
• Vérifiez que la base de données AppScan 360° a bien été créée sur la machine de la base de données.
• Vérifiez que le serveur SQL est configuré pour autoriser les connexions à distance.
• Vérifiez que le cluster AppScan 360° peut se connecter au serveur LDAP.
• Vérifiez la configuration LDAP dans le fichier de configuration du kit AppScan 360°.

Les journaux suivants peuvent vous aider à résoudre les incidents AppScan 360° :

• Les journaux d'installation se trouvent dans AppScan 360°, dans le dossier contenant le kit extrait :

  <EXTRACTION_FOLDER>/logs/singular-setup[/teardown].log

• Les journaux d'application se trouvent dans un stockage partagé ASCP. Par exemple, si vous y accédez depuis le pod :

  /storagemount/logs

  Les journaux d'application sont limités à 2 Mo. Une fois cette limite atteinte, un autre journal est créé. Jusqu'à dix fichiers journaux peuvent être créés.

• Les journaux Microservice concernent les activités de la plateforme. Chaque microservice génère son propre fichier journal, le nom de fichier étant précédé du nom du microservice.

  <fileStorageRoot>/SaaSWorkingDirectory/SaaSStorage/Logs 

• Les journaux d'examen contiennent des informations détaillées sur les exécutions d'examen, y compris les mises à jour de progression, les mesures et les informations de débogage. Ils sont spécifiques à chaque exécution d'examen et peuvent également être téléchargés à partir de l'interface utilisateur AppScan 360°.

  <fileStorageRoot>/SaaSWorkingDirectory/SaaSStorage/Scans/<scanID>/<ExecutionID>/EngineLogs 

Occasionnellement, après la mise à niveau vers la version 2.0.0 dans un environnement de machine virtuelle unique, le pod Gestionnaire des tâches peut ne pas démarrer. Pour résoudre le problème, procédez comme suit :

• Si vous avez mis à niveau AppScan 360° avec le script en ligne, exécutez :

  ./AppScan360_SingleVMsetup_v2.0.0.run -- $PWD remediateStorageIssues

• Si vous avez mis à niveau AppScan 360° avec le script hors ligne, exécutez :

  ./AppScan360_SingleVMsetup_v2.0.0_Offline.run -- $PWD remediateStorageIssues

Une erreur type dans les événements de pod peut se présenter comme suit :

Normal   Pulling    60s (x4 over 4m1s)   kubelet            
Pulling image "<ip>:5443/as360-k8s-docker-images/reloader:v1.2.1"
Warning  Failed     30s (x4 over 3m31s)  kubelet            
Failed to pull image "<ip>:5443/as360-k8s-docker-images/reloader:v1.2.1": rpc error: code = DeadlineExceeded desc = failed to pull and unpack image "<ip>:5443/as360-k8s-docker-images/reloader:v1.2.1": failed to resolve reference "<ip>/as360-k8s-docker-images/reloader:v1.2.1": failed to do request: Head "https://<ip>/v2/as360-k8s-docker-images/reloader/manifests/v1.2.1": dial tcp <ip>:5443: i/o timeout

Pour résoudre le problème, procédez comme suit :

1. Connectez-vous au conteneur k0s et installez les outils de diagnostic :

   docker exec -it k0s sh
   # (Run once per container) Install basic network tools:
   apk add --no-cache curl busybox-extras bind-tools

2. Testez la connectivité réseau à partir du conteneur :
   1. Utilisez telnet pour vérifier la connectivité au registre :

      telnet <registry-ip> 5443

      Si vous ne voyez pas de message « Connecté », la connexion est bloquée.

   2. Essayez d'extraire l'image directement à l'aide de la commande ctr du conteneur.

      k0s ctr images pull --user <user>:<pass> <registry-ip>:5443/as360-k8s-docker-images/reloader:v1.2.1

      Si cela échoue, le problème est probablement lié aux règles de pare-feu.

3. Vérifiez le pare-feu (UFW) et les règles IPTables.
   1. Sur l'hôte, inspectez les règles de pare-feu :

      iptables -L -n -v

   2. Recherchez les chaînes liées à ufw (pare-feu simple) qui peuvent bloquer le trafic, comme dans le journal ci-dessous.

      Chain INPUT (policy DROP 39231 packets, 2148K bytes)
       pkts bytes target     prot opt in     out     source               destination         
      6603K 9311M ufw-before-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
      6603K 9311M ufw-before-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
       407K   50M ufw-after-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
      39311 2154K ufw-after-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
      39311 2154K ufw-reject-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
      39311 2154K ufw-track-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0    

4. Mettez à jour les règles UFW pour autoriser le trafic réseau Docker sur l'hôte :

   1. Autorisez le trafic sur l'interface réseau Docker :

      sudo ufw allow in on docker0
      sudo ufw allow out on docker0

   2. Autorisez le trafic vers les ports du registre.

      sudo ufw allow out from any to <registry-ip> port 5443 proto tcp
      sudo ufw allow out from any to <registry-ip> port 7443 proto tcp

5. Vérifiez la résolution.
   1. Exécutez à nouveau les tests de connectivité (telnet, ctr images pull) à partir du conteneur k0s.
   2. En cas de succès, les extractions d'image de pod devraient maintenant fonctionner comme prévu.

Pour faciliter une assistance efficace, incluez les éléments suivants :

• Pour les problèmes d'installation, incluez les journaux d'installation
• Pour les problèmes d'examen, incluez le contenu du répertoire d'examen (<fileStorageRoot>/SaaSWorkingDirectory/SaaSStorage/Scans/<scanID>/<ExecutionID>/), y compris l'application examinée (fichier .irx ou fichier source .war/.jar/.zip pour l'analyse statique) et tous les journaux d'examen. Pour plus d'informations sur la résolution d'incidents, consultez Dépannage des analyses statiques.