Here’s how to troubleshoot the issue:

Si le problème n'est pas résolu, veuillez contacter le service d'assistance de Netskope.

Vous devez vérifier l'état du conteneur Cloud Exchange. Vérifiez l'état à l'aide des commandes suivantes :

For Ubuntu/CentOS:
sudo Docker ps

Pour RHEL :
sudo podman-compose ps

Si les conteneurs ne sont pas en cours d'exécution, utilisez cette commande pour les démarrer :
./start

Si vous utilisez RHEL, assurez-vous que SELinux est désactivé, car Cloud Exchange n'est pas officiellement testé sur SELinux. Nous vous recommandons de désactiver SELinux.

Vérifiez également l'état de l'ipv4 forwarder status à l'aide de cette commande :
systemctl net.ipv4.ip_forward

Si la valeur de cette commande est 1, cela signifie qu'elle est activée. Mais si la valeur est 0, vous devez l'activer en exécutant cette commande :
systemctl net.ipv4.ip_forward=1

In order to check the container status, you need to go to the folder ta_cloud_exhange.

Si vos conteneurs fonctionnent, vous devez vérifier la connectivité réseau de la machine hôte. Vous pouvez utiliser ces commandes pour vérifier la connectivité :
curl -v <IP of Local Host>:443 [i.e curl -v 127.0.0.1:443]
curl -v www.github.com:443

Si la connectivité fonctionne, vérifiez en redémarrant le CE. Utilisez ces commandes pour redémarrer le CE :
./stop
./start

Il est également possible que votre certificat SSL ait expiré. Si vous utilisez des certificats SSL d'entreprise, validez le certificat. Si vous utilisez le certificat SSL Cloud Exchange par défaut, le certificat est valable un an. Vérifiez-le également.

Si le certificat a expiré, suivez les instructions de ce document.

Essayez maintenant de redémarrer la VM.

Scénario : Dans les anciennes versions de CE, l'utilisateur peut commencer à voir des erreurs liées à l'importation de plugins en continu.

Impact : L'EC fonctionne correctement mais des erreurs d'importation sont continuellement enregistrées dans les journaux d'audit de l'EC.

Résolution : Cette erreur n'a pas d'impact fonctionnel, vous pouvez donc l'ignorer.

Issue Description

Lorsque vous tentez d'enregistrer le plugin, vous rencontrez l'erreur suivante :

Error: Value error, Validation error occurred. No AWS Credentials were found in the environment. Deploy the
plugin into AWS environment or use AWS IAM Roles Anywhere authentication method.

Lorsque vous rencontrez cette erreur, la raison principale est probablement liée à la "limite d'espérance de réponse HTTP PUT" configurée dans les métadonnées de votre instance AWS EC2. Il détermine la distance que les requêtes HTTP adressées au service de métadonnées d'instance peuvent parcourir sur le réseau avant d'être rejetées.

What to Do

Pour résoudre ce problème, vous devez augmenter la "limite de saut de réponse HTTP PUT" sur votre instance EC2. En fonction de vos préférences, procédez à l'une des options ci-dessous pour mettre à jour ce paramètre.

Option 1 : Mise à jour des paramètres de métadonnées via la console AWS

1. Naviguez vers l'instance EC2 dans la console AWS < Select l'instance EC2 < Actions < Modifier les options de métadonnées de l'instance.

2. Une fois que vous avez cliqué sur "Modifier les options de métadonnées de l'instance", vous verrez quelque chose comme ci-dessous.

3. Vous trouverez probablement la limite de saut par défaut fixée à 1. Cela signifie que la réponse aux métadonnées ne sera envoyée qu'à l'instance d'origine et ne sera pas acheminée au-delà. Mettez la valeur "HTTP PUT response hope limit" à 3 et enregistrez la configuration.

4. Une fois cela fait, naviguez vers Cloud Exchange et essayez de sauvegarder le plugin. La configuration du plugin devrait être réussie.

Option 2 : Utilisez AWS CloudShell (ligne de commande)

Si vous préférez utiliser l'interface de programmation ou si vous ne voyez pas l'option dans la console :

1. Ouvrez AWS CloudShell.

2. Vérifiez la limite de saut actuelle (remplacez i-xxxxxxxxxxxxxxxxx par votre ID d'instance EC2) :

aws ec2 describe-instances --instance-ids i-xxxxxxxxxxxxxxxxx --query
'Reservations[].Instances[].MetadataOptions'

3. Verify the current value of the http-put-response-hop-limit parameter.

4. Mettez à jour la limite de saut à 3 (remplacez i-xxxxxxxxxxxxxxxxx par votre ID d'instance EC2) :

aws ec2 modify-instance-metadata-options \
2 --instance-id i-xxxxxxxxxxxxxxxxx \
3 --http-put-response-hop-limit 3

5. Confirmez la modification à l'aide de la commande ci-dessous.

aws ec2 describe-instances --instance-ids i-xxxxxxxxxxxxxxxxx --query
'Reservations[].Instances[].MetadataOptions'

6. When done, go to Cloud Exchange and try to save the plugin. It should result in successful plugin configuration.

Le statut du conteneur RabbitMQ est en baisse. Pour résoudre le problème : Ouvrez l'interface utilisateur CE et vérifiez l'état du conteneur RabbitMQ dans chaque nœud. Si le conteneur RabbitMQ est hors service dans la majorité des nœuds, procédez comme suit : 

1. Ouvrez l'interface de gestion RabbitMQ à cette URL :

http://<CE_UI_IP>:15672/

Nom d’utilisateur : utilisateur Mot de passe : Mot de passe de maintenance de CE Si vous avez observéces erreurs : Partition réseau Detected.mnesia rapporte que ce cluster RabbitMQ a subi une partition réseau. Steps to Resolve Network partition issue 1. Arrêtez les conteneurs un par un en utilisant un script d’arrêt :

$ sudo ./stop

2. Redémarrez les nœuds CE un par un (exécutez d'abord le script de démarrage dans le nœud principal):-

$ sudo ./start

3. Surveillez également le tableau de bord CE Home et le tableau de bord RabbitMQ. Note : Les tâches d'ingestion/partage en file d'attente seront perdues si elles sont présentes dans l'EC et si elles ne sont pas encore exécutées par l'EC.

Scénario : si vous modifiez un cluster existant et que vous rencontrez des problèmes de clustering après l'arrêt avec le script d'arrêt puis le démarrage avec le script de démarrage, en particulier lors de l'ajout/du retrait de nœuds ou d'une migration, ce problème peut survenir.

Résolution : Si votre message est le suivant, cela signifie qu'il y a eu des problèmes lors de la suppression de l'instance2 du cluster. "Le nœud 'lapin@instance1' pense qu'il est regroupé avec le nœud 'lapin@instance2', mais 'lapin@instance2' n'est pas d'accord.

1. Exécutez le script d'arrêt dans instance2.
   $ sudo ./stop
2. Va au instance1 et exécute la commande en dessous. (assurez-vous de remplacer l’instance1 par l’IP ou le nom d’hôte réel). Si vous utilisez Docker, utilisez cette commande :
   $ docker-compose -f docker-compose-ha.yml exec -- rabbitmq-stats rabbitmqctl forget_cluster_node rabbit@instance2
   Dans le cas de podman, utilisez cette commande :
   $ podman-compose -f podman-compose-ha.yml exec -- rabbitmq-stats rabbitmqctl forget_cluster_node rabbit@instance2
3. Ensuite, exécutez le script de démarrage dans instance2.
   $ sudo ./start

Scénario : Lors de l'exécution du script d'installation, il se peut que l'erreur suivante s'affiche en raison d'une spécification du système qui n'est pas compatible avec CE : CE Sizing Profile Check : Failed for Large profile" ou "CE Sizing Profile Check : Échec pour le profil moyen".

Impact : Vous ne pourrez pas configurer l'EC tant que la configuration minimale requise n'aura pas été atteinte.

Résolution :

• Assurez-vous que votre machine compte exactement 8 ou 16 unités centrales pour déterminer le profil moyen ou grand respectivement.
  Notez que si la machine est déployée sur une infrastructure sur site, mettez à jour le nombre de CPU pour qu'il corresponde au profil en fonction de vos besoins. Si la machine est déployée sur une infrastructure en nuage (comme AWS, Azure), vous devrez créer une instance New.
• Pour le profil moyen, la RAM minimale et l'espace disque total sont respectivement de 16 Go et 80 Go.
• Pour les grands profils, la mémoire vive minimale et l'espace disque total sont respectivement de 32 Go et de 120 Go.
• Un minimum de 20 Go d'espace disque libre est nécessaire pour les deux profils.

Si vous rencontrez un gel ou une inaccessibilité de l’interface Cloud Exchange depuis votre navigateur, cela peut être lié à une configuration requise dans les environnements Docker/Podman. Docker nécessite spécifiquement le net.ipv4.ip_forward Réglage pour être activé pour la connectivité sortante (https://github.com/moby/moby/issues/490). Il est important de noter que, bien que Docker s’attende à ce que les utilisateurs activent ce paramètre manuellement, Podman gère cela différemment, voir https://github.com/containers/podman/issues/399.

Si vous rencontrez des erreurs lors de l'installation, de la migration ou de la mise à jour de Cloud Exchange, nous sommes là pour vous aider. Veuillez suivre les étapes ci-dessous pour obtenir de l'aide :

1. Ouvrez un ticket de support : Si vous rencontrez une erreur lors de l'installation, de la migration ou de la mise à jour de Cloud Exchange, veuillez ouvrir un ticket de support avec le support de Netskope. Notre équipe d'ingénieurs vous aidera rapidement à résoudre le problème.
2. Fournissez des détails pertinents : Lorsque vous ouvrez un ticket d'assistance, veillez à fournir les informations suivantes :
   • Journaux de plateforme : Vous pouvez exporter les journaux de plateforme en allant sur Cloud Exchange > Logging > Export Logs.
   • Journaux de diagnostic : Reportez-vous à la documentation ici pour collecter les journaux de diagnostic.

Ressources complémentaires :

Pour une documentation détaillée sur les différents aspects de Cloud Exchange, veuillez vous référer aux liens suivants :

• Pour l'installation : Documentation d'installation
• Pour la mise à jour et la migration : Mise à niveau vers la dernière version Documentation
• Pour le déploiement en haute disponibilité : Documentation sur le déploiement en haute disponibilité

Nous nous engageons à vous garantir une expérience fluide avec Cloud Exchange et nous sommes là pour vous aider à chaque étape.

Le message d'erreur est le suivant :

Network netskope-cloud-threat-exchange-docker-compose_default Error 0.0s failed to create network netskope-cloud-threat-exchange-docker-compose_default: Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network.

Le problème est spécifique au réseau de la machine. Le réseau docker entre en conflit avec le réseau hôte et, à cause de cela, le réseau docker n’est pas créé avec succès. Pour changer la configuration réseau du docker, vous pouvez vous référer à : https://docs.docker.com/compose/compose-file/06-networks/

Possible Root Cause

• Le conteneur principal a redémarré. Vérifiez l'état du conteneur principal à l'aide des commandes suivantes :.
  

  docker ps [Ubuntu]
  podman-compose ps [RHEL]

1. Passez d'abord en revue les registres des conteneurs dore.
   

   docker compose logs -f core [Ubuntu]
   podman-compose logs -f core [RHEL]

   Si vous observez l'erreur ci-dessous, cela indique que le conteneur Core n'est pas en mesure de se connecter au conteneur RabbitMQ.
   

   PLAIN login refused: user 'user'

   Vous pouvez d'abord supprimer les données RabbitMQ à l'aide de cette commande.
   Accédez au dossier Cloud Exchange.
   

   rm -rf data/rabbitmq/data/rabbit@rabbitmq-stats*

   Mais cela entraînera la perte des données des files d'attente actuelles. Une autre étape consiste à recréer l'utilisateur RabbitMQ.Connectez-vous au conteneur RabbitMQ.
   

   docker exec -ti <Container ID> sh
   podman exec -ti <Container ID> sh

• List Users
  

  rabbitmqctl list_users	

  Supprimer un utilisateur existant
  

  rabbitmqctl delete_user user

  Cela permet d'ajouter un utilisateur et un mot de passe à New.
  

  rabbitmqctl add_user user <MAINTENENCE_PASSWORD>

  Cela fait de l'utilisateur un administrateur.
  

  rabbitmqctl set_user_tags user administrator

  Cela permet de définir les autorisations pour l'utilisateur.
  

  rabbitmqctl set_permissions -p / user "." "." ".

Il y a trois causes possibles :

1. Problème de permission du répertoire de données Mongo.
2. Le conteneur Core/Mongo-DB est en panne.
3. Le mot de passe de maintenance CE est incorrect.

1. Pour le problème des autorisations du répertoire de données Mongo

Verify

Exécutez ls -lRn . dans le répertoire avec docker-compose.yml.

Le répertoire mongo-données doit être accessible en lecture/écriture à l'utilisateur ayant l'UID 1001.

./data/mongo-data:
total 0
drwxr-xr-x. 3 1001 0 16 Apr 14 18:16 data

Solution à un problème de permissions dans le répertoire de données de Mongo :

Exécutez à nouveau le script d'installation à l'aide de ./setup pour corriger les autorisations d'accès aux fichiers.

Redémarrez CE.

2. Pour le problème du conteneur core/mongo-db est en panne

Verify

Vérifiez l'état des conteneurs en utilisant sudo docker-compose ps, tous les conteneurs doivent être Up.

$ sudo docker-compose ps
Name Command
State Ports
---------------------------------------------------------------------------------------------------------------- 
ce_330_core_1 /bin/sh start.sh Up 80/tcp
ce_330_mongodb-primary_1 /opt/bitnami/scripts/mongo ... Up 0.0.0.0:27018->27017/tcp ce_330_rabbitmq-stats_1 /opt/bitnami/scripts/rabbi ... Up 15671/tcp, 0.0.0.0:15672->15672/tcp, 25672 /tcp, 4369/tcp, 5551/tcp, 5552/tcp, 5671/tcp, 0.0.0.0:5672->5672/tcp
ce_330_ui_1 /bin/sh start.sh Up 0.0.0.0:443->3000/tcp, 80/tcp ce_330_watchtower_1 /watchtower --http-api-update Up 0.0.0.0:8080->8080/tcp

Solution à core/mongo-db container est en panne :

Si des conteneurs sont hors service, suivez les étapes ci-dessous :

sudo docker-compose down
sudo ./start

3. Le mot de passe de maintenance est incorrect.

Verify

Vérifiez les logs du noyau en utilisant `sudo docker-compose logs core` pour toute "erreur d'authentification".

Vérifiez si le client utilise la version 3.2.0 de CE ou une version inférieure à 3.2.0 avec le même MongoDB.

Solution au mot de passe de maintenance est incorrect :

Procédez comme suit :

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password as "cteadmin"
sudo ./start

Un caractère spécial a potentiellement été utilisé pour le mot de passe de maintenance lors de la configuration, ce que RabbitMQ ne supporte pas et qui cause des problèmes avec d'autres services qui tentent de planifier des tâches car la communication entre les conteneurs ne parvient pas à engager RabbitMQ.

Exécutez les commandes suivantes à partir du répertoire où se trouve docker-compose.yml pour reconfigurer le mot de passe de maintenance :

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password.
sudo ./start

Ce problème est dû au fait que Podman ne permet pas de redémarrer automatiquement les conteneurs après un redémarrage. Ce comportement est particulièrement important pour les utilisateurs de serveurs RHEL (Red Hat Enterprise Linux) où Podman est couramment utilisé. Les utilisateurs devront démarrer manuellement les conteneurs après le redémarrage. Voici les étapes détaillées pour y parvenir :

1. Allez dans le répertoire Cloud Exchange :

$ cd <ce_directory>

Notez que pour CE en tant que VM, le répertoire Cloud Exchange est :

/opt/cloudexchange/cloudexchange

2. Vérifiez l'état des conteneurs :

$ podman-compose ps

3. Démarrez le Cloud Exchange :

$ ./start

Pour les utilisateurs qui utilisent Docker sur d'autres machines virtuelles comme Ubuntu ou CentOS, il n'est pas nécessaire de prendre des mesures manuelles pour le redémarrage des conteneurs. Docker comprend une fonction de redémarrage automatique qui garantit que les conteneurs redémarrent automatiquement après un redémarrage. Cette fonctionnalité de redémarrage automatique offre une expérience transparente sans intervention manuelle après le redémarrage.

Cloud Exchange (CE) peut devenir inaccessible après un redémarrage, une migration ou un changement d'infrastructure. Il peut s'agir d'une interface web qui ne se charge pas ou de services centraux qui ne démarrent pas.
La raison la plus fréquente est que le système ne prend pas en charge l'AVX (Advanced Vector Extensions), requis par MongoDB 5.0+ (utilisé dans CE).

Typical Symptoms

• CE web interface shows errors (e.g., 400 Bad Request).
• Les conteneurs mongodb-primary et core sont dans un état exited, alors que les autres conteneurs (UI, RabbitMQ) sont toujours en cours d'exécution.

CE fonctionnait bien auparavant mais est devenu inaccessible après un redémarrage, une migration ou une mise à niveau.

Root Cause

MongoDB 5.0+ nécessite des processeurs avec AVX instructions. Si la machine hôte (physique ou virtuelle) ne prend pas en charge AVX ou si AVX est désactivé, MongoDB ne peut pas démarrer, ce qui entraîne l'arrêt des principaux services CE.

Steps to Troubleshoot

• Check container status
  podman ps -a

• Regardez l'état des conteneurs mongodb-primary et core.

• Review MongoDB logs
  Dans le répertoire CE, exécutez :
  sudo docker-compose logs -f mongodb-primary | grep "AVX"

• Si le support AVX est manquant, vous verrez des avertissements comme :
  MongoDB 5.0+ nécessite un processeur avec support AVX, et votre système actuel ne semble pas en disposer !

• Check AVX availability
  lscpu | grep -i avx

Resolution

• Demandez à votre IT/VM team de confirmer et d'activer la prise en charge d'AVX sur l'hôte ou la VM.
• Pour les machines virtuelles, assurez-vous que AVX est exposed to the guest system.

Après avoir activé AVX, redémarrez les services CE :

• podman-compose down && podman-compose up -d

Confirmez que MongoDB et les conteneurs principaux démarrent correctement, et que l'interface utilisateur CE est accessible.

Next Step: Si AVX est activé mais que le problème persiste, veuillez partager les journaux/captures d'écran avec l'équipe d'assistance afin que nous puissions vous aider davantage.

Issue Overview

L'interface utilisateur de Cloud Exchange est inaccessible en raison d'une résolution DNS manquante. Vous obtenez l'erreur "Hostname does not resolve error when try to execute any command in Cloud Exchange Host Machine".

Typical Symptoms

• L'interface utilisateur de Cloud Exchange n'est pas accessible.
• When you try to restart the Cloud Exchange, getting Hostname does not resolve error.

Root Cause

Le fichier qui contient toute la configuration DNS a été supprimé. De ce fait, la machine n'est pas en mesure de résoudre le nom d'hôte.

Steps to Troubleshoot

1. Check the DNS resolution on the Cloud Exchange server by attempting to run basic Docker commands:

   sudo docker ps

2. If you receive Name does not resolve errors, proceed to next step.
3. Vérifiez l'existence du fichier resolv.conf :

   cat /etc/resolv.conf

4. Si le fichier resolv.conf est manquant, créez-le et ajoutez les détails de votre serveur DNS :

   vi /etc/resolv.conf

5. Ajoutez les entrées de votre serveur DNS dans le format suivant :

   nameserver [DNS_SERVER_IP_1] 
   nameserver [DNS_SERVER_IP_2]

6. Enregistrez ce fichier.
   • Press Esc
   • Type :wq!
   • Press Enter (key)
7. Redémarrez la machine pour appliquer les modifications de la configuration DNS.
8. Vérifiez que tous les conteneurs Docker fonctionnent correctement :

   sudo docker ps

9. Assurez-vous que les conteneurs suivants sont opérationnels :

   cloudexchange_ui_1
   
   cloudexchange_core_1
   
   cloudexchange_rabbitmq-stats_1
   
   Cloudexchange_mongodb-primary_1

10. If still facing the issue, please collect the diagnose logs and create a support case. For diagnostic log generation troubleshooting, refer to: Generate Diagnostic Logs.

Issue Summary:

• Lors de l'installation de Cloud Exchange sur votre serveur RHEL, vous observez l'erreur suivante : "Could not verify Podman/Podman-compose/Podman-plugins version of the machine" et vous avez confirmé que podman, podman-compose, et podman-plugins sont déjà installés sur le serveur selon la documentation suivante ici.

Common Symptoms:

Tout d'abord, veuillez vérifier la version de python3 sur votre serveur :

• Veuillez confirmer la version de python3 dans votre machine à l'aide de la commande : python3 --version

Si vous utilisez Python 3.6.8 ou une version plus ancienne sur votre serveur, c'est la raison de votre problème.

Root Cause:

• Avec python 3.6.8 et son pip3 associé, le podman-compose est installé et provoque des conflits.

Troubleshooting Steps/Resolution:

Veuillez noter que Cloud Exchange utilise Python 3.11 ou supérieur, comme nous l’avons souligné dans la documentation suivante : /en/Cloud Exchange-system-requirements#system-specifications

Hence, we recommend you to please remove podman-compose and then install python3.11 and then reinstall podman-compose. Please follow below steps:

• Remove podman-compose using command:
  sudo pip3 uninstall podman-compose
• Install python3.11 and setting alternative:
  yum install -y python311
yum module enable python311
alternatives --set python3 /usr/bin/python3.11
python3 --version (should point to Python 3.11.x)
• Podman-compose installation commands:
  sudo pip3 install podman-compose
sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose (lien logiciel pour podman-compose)

Une fois ces étapes terminées, vous pouvez confirmer la version de podman-compose à l'aide de la commande partagée précédemment et vous pouvez ensuite procéder à l'installation de Cloud Exchange avec l'exécution du script d'installation.

Reference:

• Pour votre référence, vous pouvez consulter ce guide dans lequel les spécifications du système CE sont mises en évidence : Spécifications du système CE

Résumé de la question : Le script d'installation échoue lors d'une nouvelle installation ou d'une mise à niveau/migration avec le message d'erreur suivant :

Des versions incompatibles ont été trouvées pour pyyaml. Veuillez vous assurer que les dépendances (pyyaml>=6.0.0 | python-dotenv>=0.20.0,<=1.0.0 | pymongo>=4.6.3，<=4.7.3) soient satisfaits avant d'exécuter le script -/setup.

Symptômes courants : Soit les dépendances python ne sont pas présentes, soit la version n'est pas compatible avec la version CE en cours d'installation.

Cause première :

Il est possible qu'à la suite d'une mise à niveau CE d'une version inférieure à une version supérieure, les versions minimales prises en charge aient été mises à niveau ou que, lors d'une nouvelle installation, toutes les dépendances n'aient pas été installées correctement.

Étapes de dépannage/résolution :

Tout d'abord, accédez au répertoire racine de cloudexchange où l'environnement est stocké.

Cloud Exchange as a VM Deployment

cd /opt/cloudexchange/cloudexchange

If using Containerized Deployment

cd  <ta_cloud_exchange_directory>

Recréer l'environnement virtuel

python3 -m venv --clear .cevenv

Activer l'environnement virtuel

source ./.cevenv/bin/activate

Installer les paquets requis

pip3 install "pyyaml>=6.0.0" 

pip3 install "python-dotenv>=0.20.0,<=1.0.0" 

pip3 install "pymongo>=4.6.3,<=4.7.3"

Désactiver l'environnement

deactivate

Résumé du problème : Le script de configuration échoue lors de la configuration HA à cause d’une erreur d’entrée/sortie.

Étapes de dépannage/résolution :

Tout d'abord, accédez au répertoire racine de cloudexchange où l'environnement est stocké pour ce nœud particulier.
Cloud Exchange as a VM Deployment

cd /opt/cloudexchange/cloudexchange

If using Containerized Deployment

cd  <ta_cloud_exchange_directory>

Exécutez la commande suivante (réplique 1 pour le premier nœud secondaire, réplique 2 pour le second nœud secondaire)

gluster volume remove-brick CloudExchange replica 1 <node_ip>:/opt/shared/gluster/bricks/1/brick force 

Exécutez cette opération sur le nœud principal

gluster peer detach <replica node_ip>

umount /opt/shared/data

rm -rf /opt/shared/*

Description de la question

During the execution of the setup script for containerized deployments of Cloud Exchange, users encounter a connection timeout error when attempting to connect to hub.docker.com. This occurs even when network settings appear to permit the connection.

Cause première

The issue is linked to recent changes on Docker Hub (Docker’s side) and is not related to Cloud Exchange itself.

These changes are causing the Cloud Exchange setup pre-requisite check for Docker Hub to fail specifically for containerized deployments.

Users deploying Cloud Exchange as VM) are not affected by this issue.

 Solution provisoire

Pendant que l'équipe produit travaille activement sur un correctif permanent, vous pouvez utiliser la solution de contournement suivante :

1. Standalone Deployments

For standalone deployments only, you can bypass the failing prerequisite check by using the –ignore-failures flag with the setup script.

• python3 ./setup --ignore-failures 

2. High Availability (HA) Deployments

For High Availability (HA) deployments, reach out to the support team for assistance with the setup.

Resolution

L'équipe travaille activement à la résolution de ce problème. Veuillez consulter les notes de mise à jour pour connaître les mises à jour qui corrigent cette limitation connue.

Issue Overview

When a secondary node is added to the Cloud Exchange HA cluster, sometimes because of the network throughput and latency the new docker image pull might take some elongated time. due to which the containers on the new node does not get started automatically.

Steps to start the services on new node

1. Go to the CE installation directory on the newly added secondary node
2. Execute the start script
   sudo ./start
3. Verify the status of the services of newly added node after completion of start script.

Scénario

This guide walks you through completely removing GlusterFS and clearing all leftover FUSE state to permanently resolve the error:

Transport endpoint is not connected

The fix requires three things: uninstalling packages, cleaning all leftover FUSE and mount cache, and rebooting the server. Skipping any step may leave the system in a broken state.

Conditions préalables

• Root or sudo access on the affected server
• GlusterFS service must be stopped before proceeding
• Schedule a maintenance window a reboot is required

Resolution

Step 1 — Stop GlusterFS Service:

• For RHEL Operation System

systemctl stop glusterd
systemctl disable glusterd

• For Ubuntu Operating System

Give sudo its own private PATH (secure_path)

Utilisez un python3 qui pointe vers la version 3.11, tout en laissant la /usr/bin/python3 système intacte.

# 1. install python3.11 
sudo dnf install -y python3.11

# 2. sudo-only bin dir with a python3 -> 3.11 symlink
sudo mkdir -p /usr/local/sudo-bin
sudo ln -sf /usr/bin/python3.11 /usr/local/sudo-bin/python3

# 3. Write the sudoers override LOCALLY first, then copy in
cat > /tmp/python311_secure_path << 'EOF'
Defaults secure_path="/usr/local/sudo-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
EOF

# 4. Validate BEFORE installing into /etc/sudoers.d
sudo visudo -cf /tmp/python311_secure_path

# 5. Install (only if step 4 said "parsed OK")
sudo install -m 0440 -o root -g root /tmp/python311_secure_path /etc/sudoers.d/python311_secure_path
rm -f /tmp/python311_secure_path

# 6. Re-validate the whole sudoers config
sudo visudo -cf /etc/sudoers

Add an alias Python3 -> 3.11 for Interactive Shells (normal user + root)

# normal user (~/.bashrc)
echo "alias python3=/usr/bin/python3.11" >> ~/.bashrc

# root (/root/.bashrc) — needed separately, root has its own rc file
sudo bash -c 'echo "alias python3=/usr/bin/python3.11" >> /root/.bashrc'

# apply to current shells
source ~/.bashrc
sudo -i bash -c 'source /root/.bashrc'

Configure a Systemd Drop-In Override 

# add a drop-in override (survives ./setup regenerating the base unit file)
sudo mkdir -p /etc/systemd/system/cloud-exchange.service.d
sudo tee /etc/systemd/system/cloud-exchange.service.d/override.conf << 'EOF'
[Service]
Environment="PATH=/usr/local/sudo-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
EOF

#If the Management Server is running, perform a restart.
sudo systemctl daemon-reload
sudo systemctl restart cloud-exchange

Validate Changes

sudo python3 --version   # -> Python 3.11.x   (via /usr/local/sudo-bin/python3)
python3 --version        # -> python3.11.x       (system default)

Scénario : Après avoir migré vers la version 5.1.0, le conteneur CE core est redémarré et les erreurs suivantes sont observées dans les journaux du conteneur core.

Impact : L'EC n'est pas accessible.

Résolution : Contactez l'équipe d'assistance de Netskope avec les journaux de diagnostic.

Vous obtenez des erreurs telles que InvalidReplicaSetConfig lors de l'exécution de ./start script lors du déploiement de Cloud Exchange avec High Availability

Lors de l'initialisation d'un ensemble de répliques MongoDB, un message d'erreur peut apparaître, indiquant : "Aucun hôte décrit dans la configuration New avec {version : 1, term : 0} pour l'ensemble de réplicas mongo_replic_set ne correspond à ce nœud." Ce problème survient généralement lorsque le conteneur MongoDB éprouve des difficultés à se connecter via l'adresse IP ou le nom d'hôte spécifié dans le script d'installation. Pour résoudre efficacement ce problème, il est essentiel de s'assurer que les ports nécessaires sont autorisés par le pare-feu. Pour faciliter l'initialisation transparente de MongoDB, il faut accorder l'accès à ces ports essentiels, ce qui permet une communication et un fonctionnement sans heurts au sein de l'ensemble de répliques. Ce sont les ports à autoriser.

• 4369 (Un service de découverte de pairs utilisé par les nœuds RabbitMQ et les outils CLI)
• 5672 (utilisé par les clients AMQP 0-9-1 et AMQP 1.0 sans et avec TLS)
• 15672 (clients API HTTP, interface de gestion et rabbitmqadmin, sans et avec TLS)
• 25672 (utilisé pour la communication entre les nœuds et les outils CLI)
• 35672 (utilisé pour la communication avec les outils CLI)
• 27017 (Le port par défaut pour les instances mongod et mongos.)
• Port de l'interface utilisateur sélectionné (par défaut 443 pour HTTPS et 80 pour HTTP) (pour accéder à l'interface utilisateur et au contrôle de santé de l'internode)

Procédez comme suit pour autoriser les numéros de port :

1. Vérifiez l'état des ports :

   Pour Ubuntu :

   $ sudo ufw status PORT_NUMBER

   Pour Redhat :

   $ sudo firewall-cmd --list-ports=PORT_NUMBER/tcp

2. Si le port n'est pas autorisé, procédez comme suit :

   Pour Ubuntu :

   $ sudo ufw allow PORT_NUMBER

   Pour Redhat :

   $ sudo firewall-cmd --zone=public --add-port=PORT_NUMBER/tcp --permanent

3. Rechargez le pare-feu :

   Pour Ubuntu :

   $ sudo ufw reload

   Pour Redhat :

   $ sudo firewall-cmd --reload

Cette erreur se produit lors de la mise à jour de Cloud Exchange à partir de 3.x/4.x à la dernière version :

ta_cloud_exchange_mongodb-primary_1 |

{"t":{"$date":"2025-01-15T10:17:50.744+00:00"},"s":"F", "c":"CONTROL",

"id":20573, "ctx":"initandlisten","msg":"Wrong mongod version","attr":{"error":"UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id:

"featureCompatibilityVersion", version: "4.4" }.

Primary Observed Issue: La migration/mise à niveau a échoué.

Follow these steps to analyze the issue you are facing

1. Vous devez d'abord vérifier la version de docker et de docker compose. Utilisez les commandes suivantes pour vérifier la version
   • version de docker
   • docker compose version/docker-compose version.
2. Si la version de Docker est inférieure à 25, vous devez la mettre à jour.
3. Suivez les instructions de ce document. https://docs.docker.com/engine/install/ubuntu/.
4. Pour docker-compose, utilisez ce document. https://docs.docker.com/compose/install/standalone/.

Le mot de passe de maintenance saisi n'est pas correct

L'utilisateur rencontre le message d'erreur mentionné ci-dessous lors de l'exécution du script d'installation pendant le processus de migration ou de mise à niveau. Une erreur s'est produite lors de l'exécution de cette commande. Erreur : La commande 'docker exec mongo-migration mongo -u root -password <pass> admin -eval 'db.adminCommand({setFeatureCompatibilityVersion : "5.0"})" a renvoyé un état de sortie non nul 1. Pour vérifier l'erreur résultant d'un mot de passe de maintenance incorrect, l'utilisateur doit exécuter la commande spécifiée à l'aide de podman ou de docker :

$ sudo docker ps

$ sudo podman ps

Si vous observez un conteneur en cours d'exécution nommé "mongo-migration", cela indique qu'un mot de passe de maintenance incorrect a été ajouté au cours du processus de migration. 

Dans ce cas, vous devez exécuter à nouveau le script de configuration en fonction du type de déploiement. En outre, vous devez saisir le même mot de passe de maintenance que celui utilisé lors de l'ancienne configuration de Cloud Exchange. Pour l'EC conteneurisé ou l'EC en tant que HA, la commande pour réexécuter le script d'installation est la suivante :

$ sudo python3 ./setup

Pour CE as VM Instance, la commande pour réexécuter le script d'installation est la suivante :

$ sudo ./setup.

Si l'utilisateur ne parvient pas à localiser le conteneur en cours d'exécution, il peut avoir besoin de se référer aux étapes de dépannage fournies ci-dessous.

Fonctionnalité incompatible Mongo Version de compatibilité

Vous rencontrez le message d'erreur mentionné ci-dessous lors de l'exécution du script d'installation pendant le processus de migration ou de mise à niveau. Réponse d'erreur du démon : Container <Container_ID> is not runningErroroccurred while executing command. Erreur : La commande 'docker/podman exec mongo-migration mongo -u root -password <pass> admin -eval 'db.adminCommand({setFeatureCompatibilityVersion : "5.0"})" a renvoyé un état de sortie non nul 1. Pour éviter que cette erreur ne se produise, veuillez suivre les instructions ci-dessous.
For those who are utilizing a Containerized CE, follow these steps:
1. Exécutez la commande suivante :

$ echo MONGO_COMPATIBILITY=True >> .env

2. Pour vérifier les modifications, utilisez cette commande pour l'instance CE conteneurisée :

$ cat .env

3. Exécutez à nouveau le script d'installation. Si vous utilisez la commande ci-dessous :

$ sudo ./setup

If you are using CE as HA (Containerized) based instance, follow these steps:
1. Exécutez la commande suivante :

$ echo MONGO_COMPATIBILITY=True >> <shared_drive>/config/.env

2. Pour vérifier les modifications, utilisez la commande suivante pour CE en tant qu'instance basée sur HA :

$ sudo cat <shared_drive>/config/.env

3. Exécutez à nouveau le script d'installation sur le nœud actuel. Cette fois, l'erreur ne devrait pas apparaître.

$ sudo ./setup

If you are using CE as OVA instance, follow these steps:
1. Exécutez la commande suivante :

$ sudo vi /opt/cloudexchange/cloudexchange/.env

Si vous avez opté pour l'AH en CE en tant qu'instances basées sur une VM, exécutez cette commande :

$ sudo vi <shared_drive>/config/.env

2. Insérez la ligne suivante dans le fichier .env et n'oubliez pas d'enregistrer les modifications.

MONGO_COMPATIBILITY=True

3. Exécutez à nouveau le script d'installation à l'aide de la commande ci-dessous :

$ sudo ./setup

 Scénario : Lorsqu'un client tente de migrer vers la version 5.1.1 HA à partir d'une ancienne version de HA, ils doivent exécuter le script restore_ha_backup. Cependant, dans certaines versions du shell, en particulier sur Ubuntu 22.04/ CE as a VM Images, ce script rencontre une erreur lors de l'exportation des variables d'environnement.

Résolution : Pour éviter que cette erreur ne se produise, veuillez suivre les instructions ci-dessous au lieu d'exécuter ./restore_ha_backup le scénario.

1. Exécutez la commande suivante pour exporter les variables d'environnement nécessaires :
   $ export MONGO_INITDB_ROOT_PASSWORD=<Enter_maintenance_password>
$ export HA_PRIMARY_NODE_IP=<Enter_current_node_ip>
   
2. Utilisez la commande suivante pour démarrer MongoDB Container :
   
   • Exécutez la commande ci-dessous pour un système basé sur Docker comme Ubuntu :
     $ sudo docker compose -f docker-compose-ha.yml up mongodb-primary -d
   • Exécutez la commande ci-dessous pour un système basé sur podman comme RHEL :
     $ sudo podman-compose -f podman-compose-ha.yml up mongodb-primary -d
3. Run this command to assign new primary IP to the cluster after migration using the below command:
   
   • Exécutez la commande ci-dessous pour un système basé sur Docker comme Ubuntu :
     $ sudo docker compose -f docker-compose-ha.yml exec mongodb-primary bash -c "mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD --eval 'cfg = rs.conf();cfg.members[0].host = "$HA_PRIMARY_NODE_IP:27017";rs.reconfig(cfg, { force: true })'"
   • Exécutez la commande ci-dessous pour un système basé sur podman comme RHEL :
     $ sudo podman-compose -f podman-compose-ha.yml exec mongodb-primary bash -c "mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD --eval 'cfg = rs.conf();cfg.members[0].host = "$HA_PRIMARY_NODE_IP:27017";rs.reconfig(cfg, { force: true })'"
4. Exécutez la commande suivante pour arrêter le conteneur MongoDB :
   
   • Exécutez la commande ci-dessous pour un système basé sur Docker comme Ubuntu :
     $ sudo docker compose -f docker-compose-ha.yml down -v
   • Exécutez la commande ci-dessous pour un système basé sur podman comme RHEL :
     $ sudo podman-compose -f podman-compose-ha.yml down -v

Issue Summary: Cloud Exchange ne démarre pas après la mise à jour du système d'exploitation RHEL sur votre serveur.

Common Symptoms: il se peut que vous receviez une erreur liée au fait que podman ou podman-compose n'est pas présent dans votre système lorsque vous essayez d'exécuter le script de démarrage pour lancer les conteneurs Cloud Exchange.

Cause première :

Il est possible qu'une mise à jour du système d'exploitation du serveur ait entraîné la suppression de ces fichiers et paquets de vos machines. Nous vous recommandons donc de vérifier auprès de votre équipe informatique ou VM la cause exacte de ce problème.

Étapes de dépannage/résolution :

Podman, Podman-compose et Podman-plugins sont des prérequis pour Cloud Exchange et vous devrez donc les réinstaller sur votre machine. 

Veuillez donc suivre les étapes ci-dessous :

• Commande d'installation de Podman :
  sudo yum install podman
• Commandes d'installation de Podman-compose :
  sudo pip3 install podman-compose
• Création d'un lien logiciel pour podman-compose :
  sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose 
• Podman-plugins Commande d'installation :
  sudo yum install podman-plugins

Une fois ces dépendances installées, veuillez exécuter la commande suivante pour recréer les détails du système podman : sudo podman system reset

Après avoir suivi ces étapes, veuillez redémarrer le Cloud Exchange en utilisant les commandes suivantes :

1. sudo ./stop
2. sudo ./start

 Maintenant, vous devriez être en mesure de démarrer votre Cloud Exchange dans votre machine sans perdre les configurations précédentes.

Lors de la configuration du plugin Netskope Log Shipper dans Cloud Exchange, les utilisateurs peuvent rencontrer une erreur de validation :

TENANT Netskope Tenant (Required) []: Validation error occurred, Received exit code 403, Forbidden, Verify the V1, V2 API Token provided in the configuration parameters.

Typical Symptoms

• Le problème se produit même si les autorisations semblent correctes.
• Bannière d'erreur lors de l'enregistrement de la configuration du plugin.
• Le message fait référence à un jeton d'API V1 ou V2 invalide/insuffisant.

Root Cause

• À partir de Cloud Exchange v5.1.1 avec CLS Plugin v2.2.0+, un type d'événement New Client Status a été introduit.
• Ce type d'événement utilise le point de terminaison :
  /api/v2/events/dataexport/iterator
/api/v2/events/datasearch/clientstatus  
• Ce Token API V2 doit avoir les permissions READ + WRITE pour ce point final.

Steps to Troubleshoot

1. Check plugin version; it must be CLS v2.2.0 or above.
2. Vérifiez les autorisations des jetons :
   • Assurez-vous que tous les points de terminaison /api/v2/events/dataexport/* et /api/v2/events/datasearch/clientstatus sont inclus.
   • Confirmez que /api/v2/events/dataexport/iterator a READ + WRITE.
3. Mettez à jour ou recréez le jeton API V2 avec les autorisations correctes.

Enregistrez le jeton mis à jour dans la configuration du plugin CLS.

Resolution

• Ajoutez les permissions requises pour l'exportation de données (READ + WRITE pour l'itérateur).
• Réessayez d'enregistrer la configuration CLS.
• Si le statut du client n'est pas nécessaire, désélectionnez temporairement ce type d'événement pour le contourner jusqu'à ce que le jeton soit mis à jour.
  

Vous voyez cette erreur :

- Error: Value error, please check the Tenant Name field has no special characters, ensure V1 and V2 tokens are valid.

Troubleshooting Steps

1. Tout d'abord, assurez-vous que l'état de l'API REST est activé pour l'API REST v2 dans le locataire Netskope.
   
2. Confirmez que vous avez créé le jeton REST API v2 avec les permissions/étendues nécessaires du point final Netskope, comme indiqué ici.
3. Vérifiez votre jeton REST API v2 existant et, si nécessaire, modifiez les autorisations/étendues du point de terminaison Netskope conformément à la documentation ci-dessus. Réessayez d'enregistrer le locataire Netskope dans l'interface utilisateur de Cloud Exchange.
4. Si le problème persiste, exécutez la requête curl suivante sur la machine hôte où Cloud Exchange est déployé :

   Note

   Avant d'exécuter la commande ci-dessus, assurez-vous de remplacer <tenant-name> le nom de locataire<> par le nom de locataire Netskope et <V2 token> le jeton par le jeton REST API v2 existant.

   curl --location https://<tenant-name>.goskope.com/api/v2/events/dataexport/events/page?index=tenant --header 'Netskope-Api-Token: <V2 token>'

Command Output
Si vous observez que la sortie de la commande est non autorisée pour l'adresse IP x.x.x.x, ajoutez l'adresse IP mise en évidence dans la section Adresses IP personnalisées (activez-la si elle est désactivée) dans la liste des adresses IP autorisées de votre locataire Netskope.

Path for IP Allowlist

Connectez-vous au locataire Netskope et accédez à Settings > Administration > IP Allowlist > Custom IP Addresses.

Si vous avez observé cette bannière dans l'interface utilisateur de Cloud Exchange, cela indique que le jeton V2 de l'API REST a expiré.

Follow these steps to resolve this error

1. Dans votre locataire Netskope, allez dans Settings > Tools > REST API V2 et sélectionnez un jeton API. Cliquez sur le menu déroulant des trois points et sélectionnez Change Expiration Date.
2. Maintenant, il faut réémettre le jeton. Pour votre jeton API, cliquez sur le menu déroulant des trois points et sélectionnez Reissue.
3. Copiez le jeton New et utilisez-le dans votre configuration de locataire Cloud Exchange Netskope .

Le SSO nécessite un domaine de premier niveau (TLD). Si vous n'ajoutez pas de TLD dans le nom d'hôte lors du mappage de l'URL et que vous activez le SSO dans CE, le client recevra l'erreur "Nom d'hôte invalide, domaine de premier niveau requis". Ce problème est résolu en ajoutant le TLD approprié (comme Netskope.com).

Si vous recevez ce type d'erreur, c'est parce que Netskope CE ne supporte par défaut que TLSv1.3. Pour résoudre cette erreur, vous devez permettre à Netskope CE de fonctionner avec TLSv1.2 et TLSv1.3. Pour cela, vous devez modifier la version de TLS dans le script d'installation. Exécutez à nouveau le script d'installation et répondez "Oui" à la question suivante.

Do you want to enable TLSv1.2 along with TLSv1.3 for CE UI.

Exécutez ensuite le script de démarrage.

Si vos certificats ont expiré, suivez les étapes ci-dessous pour régénérer les certificats.

1. Déposez tous les conteneurs.
2. Supprimez les fichiers de certificats (cte_cert.crt, cte_cert_key.key) du dossier données/ssl_certs.
3. Exécutez à nouveau le script d'installation pour régénérer les certificats. Répondez "https" à la question ci-dessous :

   Do you want to access CE over HTTP, or HTTPS (HTTPS is recommended)? https

4. Exécutez le script de démarrage.

Pour réinitialiser le mot de passe de l'administrateur, reportez-vous à la section Réinitialiser le mot de passe dans la section Paramètres du compte. Veillez à modifier le mot de passe à partir des paramètres du compte après que l'administrateur de l'EC a réinitialisé le mot de passe.

Pour réinitialiser le mot de passe d'un autre utilisateur, le super administrateur peut mettre à jour le mot de passe d'un utilisateur à partir de Settings > Users, puis cliquer sur l'icône Modifier à droite.

Pour modifier la configuration SSO, vous devez désactiver le SSO à l'aide de la bascule de l'onglet Configuration SSO dans l'interface utilisateur CE. Pour ce faire, suivez les étapes suivantes :

1. Tout d'abord, sauvegardez vos détails relatifs à la configuration SSO d'Okta dans un fichier (Identity Provider Issuer URL, Identity Provider SSO URL, Identity Provider SLO URL, et Public x509 Certificate).
2. Désactivez ensuite le SSO à l'aide de la bascule qui se trouve sur la page de configuration du SSO dans l'interface utilisateur du CE.
3. Après avoir désactivé le SSO, le changement de domaine doit se refléter dans l'ID d'entité du fournisseur de services, l'URL ACS du fournisseur de services et l'URL SLS du fournisseur de services, conformément à votre domaine modifié.
4. Lorsque vous voyez cela dans l'interface utilisateur du CE, réactivez le SSO à l'aide de la bascule.
5. Saisissez à nouveau les données enregistrées dans le fichier lors de la première étape.

Notez que vous devrez également mettre à jour les détails de votre IdP (comme Okta) concernant l'ID de l'entité du fournisseur de services, l'URL ACS du fournisseur de services et l'URL SLS du fournisseur de services afin qu'ils reflètent également le changement en ce qui concerne votre domaine modifié.

Issue Overview

La bannière d'expiration du certificat SSL a été visible sur l'interface Web de Cloud Exchange après avoir effectué une mise à jour.

Étapes de dépannage

1. Go to the CLI of the Cloud Exchange host machine.
2. Allez dans le répertoire Cloud Exchange.
3. Arrêtez les services Cloud Exchange :

   sudo ./stop

4. Now remove the existing SSL certificate:

   rm -rf data/ssl_certs/cte_cert.crt
   rm -rf data/ssl_certs/cte_cert_key.key

5. After finishing this, re-run the setup script:

   sudo python3 ./setup

6. Note, if you have deployed Cloud Exchange as a VM, run:

   sudo ./setup

7. Now run the start script:

   sudo ./start

These steps will have generated the latest SSL certificate.

Issue Overview

During HA configuration, all nodes must use the same JWT secret as the primary node. If the JWT secret generated or configured during the primary node setup is not available, generate a new JWT secret and configure it on all nodes in the cluster.

Steps to Regenerate JWT TOKEN

1. Navigate to the CE installation directory (primary node). Follow the appropriate steps based on your deployment type:
   • Containerized CE deployment
     cd <ta_cloud_exchange_directory_path>
   • CE deployed as a VM
     cd /opt/cloudexchange/cloudexchange
2. Arrêtez les conteneurs.
   sudo ./stop
3. To set a specific JWT secret, modify the cloudexchange.config file and provide the value for JWT_SECRET.
   sudo cp cloudexchange.config.example cloudexchange.config
sudo vi cloudexchange.config

4. Run the setup script.
   sudo ./setup
5. Restart the containers.
   sudo ./start

Scénario : L'EC détecte automatiquement le type de données (chaîne, nombre ou booléen) des champs entrants et ajuste les opérateurs en fonction du type de données New dans toutes les vues de filtre de l'EC lors de la récupération des données. Si le type de données d'un champ change, toutes les règles de gestion, de mise en sourdine ou de déduplication configurées utilisant ce champ afficheront une icône d'erreur rouge. Vous devez reconfigurer ces règles à l'aide de l'option d'édition.

Impact : Les tâches du cycle de vie spécifiques au module, telles que le filtrage, la transformation, la création de tickets, la déduplication et l'évaluation des règles de mise en sourdine seront arrêtées pour les alertes/événements/logs entrants, et les processus de données entrants vers des tiers seront ignorés. Les règles non valides empêcheront l'EC de traiter les lots d'alertes ou d'événements entrants et déclencheront un message d'erreur dans l'onglet Journalisation.

Résolution : Vous devez reconfigurer ces règles à l'aide de l'option d'édition.

1. Accédez à la page de la règle de gestion correspondante.
2. Cliquez sur Edit.
3. Modifiez le filtre si nécessaire pour résoudre le problème.
4. Cliquez sur Save pour appliquer les modifications.

Scénario : si vous configurez SIEM et que vous supprimez ce SIEM particulier, et que vous le reconfigurez alors que l'extraction de l'historique est en cours pour la plage initiale mentionnée dans la configuration du plugin, CE crée plusieurs tâches (l'une concerne la création de la durée du mappage SIEM, et l'autre la reconfiguration du mappage SIEM). 

To resolve this, restart CE using the stop and start scripts and perform a manual sync in Log shipper > SIEM Mappings manual sync with historical range.

Scénario : Lorsque vous partagez les IoC de menace avec Netskope, vous pouvez rencontrer l'erreur suivante.

Impact : Les IoC seront partagés avec Netskope, mais la fonctionnalité de marquage des indicateurs sera affectée. Cela pourrait également avoir un impact sur la fonctionnalité de rétractation de l'IoC.

Résolution :

1. Allez sur Settings > Repository et cliquez sur Check for Updates pour récupérer les mises à jour du référentiel par défaut.
2. Cliquez sur Update Plugins, sélectionnez le plugin Netskope Threat Exchange, puis cliquez sur Save et suivez les instructions.
3. Attendez la prochaine exécution pour le partage, puis vérifiez si l'erreur n'est plus visible dans les journaux d'audit.

Scénario : Lors de la récupération des mises à jour du Default plugin Repository après la migration de l'ancien CE, cette erreur se produit.

Impact : Il ne sera pas possible de récupérer les mises à jour de plugins depuis Github pour le dépôt par défaut.

Résolution :

1. SSH dans l'instance CE et allez dans le répertoire du package d'installation de Cloud Exchange.
2. Supprimez tous les fichiers non suivis à l'aide de cette commande : (Utilisez podman-compose au lieu de docker-compose dans les systèmes d'exploitation basés sur RHEL).

$ docker-compose exec -w /opt/netskope/repos/Default core git clean -df

Si vous recevez une erreur lors de l'exécution des commandes ci-dessus, essayez cette commande pour supprimer les fichiers non suivis.

$ cd data/repos/Default (cd <shared_drive>/repos/Default for HA deployment) 
$ sudo rm -rf crowdstrike_identity_protect_ztre/ crowdstrike_ztre/ microsoft_entra_id_ztre/ mimecast_ztre/ netskope_ztre/ okta_ztre/

Pour résoudre ce problème, il est essentiel de vérifier que les règles de gestion et le mappage SIEM utilisés sont corrects. En outre, veillez à ce que tous les paramètres soient correctement remplis lors de la configuration du plugin. Il est également important de vérifier la configuration du partage afin de confirmer qu'elle correspond aux IoC que vous souhaitez partager. Si le filtre de partage est incorrect, ajustez les critères de partage en conséquence.

Pour récupérer les données historiques qui auraient pu être manquées en raison d'une mauvaise configuration, envisagez de supprimer la configuration de partage, puis de la réintroduire. En prenant ces mesures, vous pouvez vous assurer que les IoC sont correctement partagés avec la source de menace prévue.

Netskope n'accepte que les URL comportant des caractères génériques devant le domaine. Les autres URL seront rejetées lorsque Threat Exchange essaiera de les envoyer. Ainsi, *.google.com sera accepté par le locataire de Netskope, mais pas google.com/*. Si votre base de données Threat Exchange contient des caractères génériques, vous devrez marquer manuellement les partages.

Par défaut, tous les plugins téléchargés sont stockés dans le répertoire ./data/custom_plugins. Cependant, ceci peut être modifié à partir de docker-compose en montant un répertoire différent ou l'administrateur peut ajouter un dépôt supplémentaire pour télécharger des plugins personnalisés. Cette fonction est configurée dans le menu Paramètres. C'est la meilleure méthode pour ajouter des plugins supplémentaires à votre instance CE, et la seule méthode pour ajouter des plugins CTO, CLS et CRE.

Scénario : Après avoir migré vers la version 5.1.0 L'utilisateur peut rencontrer l'erreur suivante lors de la mise à jour de la règle de gestion existante pour le module CTO.

Impact : Vous ne pourrez pas mettre à jour la règle existante tant que vous ne l'aurez pas redéfinie.

Résolution : Redéfinissez la règle de gestion à partir de l'interface utilisateur et mettez-la à jour.

Par défaut, la plateforme recherche les 7 derniers jours d'IoC. S'il y a trop d'IoC (plus d'un million) et qu'aucun filtre n'est sélectionné, la recherche sera lente.

Solution proposée : Envisagez d'appliquer les filtres et de restreindre les critères de recherche. Les performances sont optimales lorsque l'ensemble des données est inférieur ou égal à 100 000 enregistrements.

Vérifiez si les appels API sortants nécessitent un proxy. Si le déploiement de votre réseau prévoit un proxy pour les appels API HTTP et qu'un proxy est configuré, les opérations du plugin seront affectées.

Solution proposée :

1. Va sur Settings > General > Proxy.
2. Modifiez la configuration existante et activez Use System Proxy.

CE s'appuie sur un mécanisme de planification interne pour les tâches du plugin. Des travailleurs exécutent les tâches du plugin, en prenant une à une les tâches dans la file d'attente. Le nombre de travailleurs disponibles dans votre système dépend du nombre de cœurs. Si les travailleurs disponibles sont occupés à servir une tâche plugin, la tâche déjà en file d'attente doit attendre que le travailleur existant soit disponible. Cette situation peut généralement se produire lors de l'ingestion initiale des données, lorsqu'il y a plus de données à traiter.

Solution proposée : Envisagez d'augmenter le nombre de cœurs du système si vous avez un grand nombre de plugins configurés et que ces derniers sont constamment à la traîne. En ce qui concerne l'ingestion initiale, le système devrait prendre en charge les arriérés après l'ingestion initiale et se comporter normalement si les données incrémentielles ne sont pas volumineuses.

Si une icône d'alerte rouge apparaît sur l'une des configurations, cela signifie qu'un ou plusieurs problèmes se sont produits lors de l'interrogation du système branché pour les données de cette configuration. Cela peut être lié aux paramètres de l'API, du proxy ou de SSL.

Solution proposée :

• Assurez-vous que la configuration du plugin contient les paramètres corrects pour l'API, la clé secrète, l'URL, etc.
• Assurez-vous que l'option Activer le proxy est sélectionnée et que votre proxy est configuré si les appels réseau sortants nécessitent une connexion proxy.
• Vérifiez dans les journaux les erreurs survenues autour de la dernière heure d'exécution affichée dans la configuration à partir de la section Audit.

Lorsqu'un utilisateur tente de télécharger un plugin avec un paquet tar.gz en utilisant le bouton "browse", les fichiers tar.gz ne sont pas sélectionnables par défaut.

Solution proposée : Glissez-déposez les paquets de plugins dans la zone de dépôt de l'interface utilisateur.

Ouvrez la configuration du plugin et définissez la valeur Dernière exécution à une date antérieure, puis enregistrez la configuration. Assurez-vous que la configuration n'est pas en cours d'exécution lorsque vous mettez à jour la valeur Last Run.

• Pour un déploiement basé sur Docker :
  1. Récupérez les journaux du conteneur principal à l'aide de cette commande :
     $ docker-compose logs core | grep WorkerLost
     Si les journaux contenant WorkerLost apparaissent environ 5 à 6 fois, cela indique qu'il y a un problème. Redémarrez les conteneurs à l'aide des commandes suivantes :
     $ ./stop
$ ./start
• Pour un déploiement basé sur Podman :
  1. Pour accéder aux journaux du conteneur principal, utilisez cette commande :
     $ podman-compose logs core | grep WorkerLost. Si les journaux contenant WorkerLost apparaissent environ 5 à 6 fois, cela indique qu’il y a un problème. Redémarrez les conteneurs en utilisant ces commandes :
     $ ./stop
$ /start

Scénario : dans les journaux du noyau, vous pouvez observer "Process 'ForkPoolWorker-**' pid:552 exited with 'signal 9 (SIGKILL)'"

Impact : Il arrive souvent que le conteneur principal soit redémarré et que vous subissiez des retards dans les tâches effectuées par CE (par exemple, l'ingestion des journaux est retardée).

Résolution :

• Assurez-vous que l'EC est hébergé sur une machine ayant une fréquence de CPU d'au moins 2,2 GHz.
• Si vous ne répondez pas aux critères de fréquence du CPU, veuillez migrer vers la machine qui répond à ces critères.
• Si vous répondez déjà aux critères de fréquence du CPU, contactez l'équipe d'assistance.

Cloud Exchange (CE) génère des messages d'avertissement pour le champ "networksessionID" dans la section Logging lors de l'envoi des logs Network Events depuis le plugin CLS Syslog/Qradar.

Example Warning Log Message in Cloud Exchange UI (under Logging Section):

CLS QRadar [QRadar]([events][network]) : Une erreur s'est produite lors de la génération des données CEF pour le champ : "networkSessionId". Erreur : networkSessionId : Une erreur s'est produite lors de la conversion en entier. Le champ sera ignoré

Root Cause:

Dans les événements réseau, Cloud Exchange s'attend à ce que le champ networkSessionId soit l'un des suivants :

1. Absent
2. Présentez un nombre valide entre guillemets (c'est-à-dire une chaîne JSON).
3. Présentez un numéro valide (c'est-à-dire un numéro JSON)

Ce message d'avertissement indique que le champ "networkSessionId" n'est pas disponible/présent de manière inattendue dans les logs bruts de votre Netskope Tenant et parce que ce champ est ajouté dans le fichier de mapping par défaut du plugin respectif, Cloud Exchange ignore ce champ de l'ingestion avec l'avertissement mentionné ci-dessus.

Troubleshooting Steps/Resolution:

Dans ce cas, vous pouvez créer une correspondance personnalisée et supprimer ce champ du fichier de correspondance pour supprimer cet avertissement. Cela n'aura aucune incidence sur Cloud Exchange workflow.

Ce champ est disponible sous Network Events dans le fichier de correspondance par défaut. Vous pouvez donc suivre les étapes ci-dessous pour créer une correspondance personnalisée afin de supprimer le champ "networkSessionId" et l'utiliser dans le plugin correspondant :

• Connectez-vous à l'interface utilisateur de Cloud Exchange. Select Paramètres.
• Select Log Shipper dans le panneau latéral et passez à Mappings.
• Recherchez le fichier Default Mapping du plugin concerné (par exemple : Qradar Default Mapping).
• Cliquez sur l'action Cloner pour faire une copie du fichier de mappage par défaut.
• Donnez un nom à ce fichier de mappage personnalisé.
• Allez maintenant dans l'onglet Événements et développez la partie Extensions dans la section Événements de réseau.
• Recherchez le champ "networkSessionId" et supprimez-le du mappage.
• Enregistrez le fichier de mappage.
• Maintenant, à l'aide de la flèche arrière, revenez en arrière et entrez dans le module Log Shipper.
• Select Plugins et modifiez le plugin correspondant (Syslog/Qradar).
• Modifiez le mappage sélectionné dans la liste déroulante et sélectionnez le mappage personnalisé récemment créé.
• Cliquez ensuite sur Enregistrer pour le plugin.

Au bout d'un certain temps, vous devriez voir dans la section "Logging" que les messages d'avertissement relatifs au champ "networkSessionId" ne sont plus remplis.

Pour votre référence, vous pouvez suivre ce document pour créer une cartographie : Create a Mapping File in Log Shipper

Issue Overview :

Les utilisateurs qui configurent un site Netskope provider plugin dans Cloud Exchange peuvent rencontrer une erreur liée au site Client Status iterator. Cela se produit lorsque le locataire possède déjà un itérateur de statut de client créé par un autre module (par exemple, Netskope CLS ou Netskope CRE) via un utilisateur différent ou une autre instance CE.

Error:

TENANT Netskope Tenant (Required) [Support Tenant]: Error while creating iterator with name netskope_ce_cs_iterator. Cannot create Client Status Iterator. One iterator already exists for the Client Status event for your tenant. Delete the existing iterator to continue.

Root Cause:

• Chacun Netskope tenant supports only one Client Status iterator.
• Lorsqu'un plugin (Netskope CLS ou Netskope CRE) est configuré, Cloud Exchange vérifie la présence d'un itérateur existant :

1. If missing → crée un itérateur New.
   
2. If already present → la validation échoue si elle est déclenchée par un autre utilisateur ou une autre instance de l'EC, et renvoie l'erreur.

Ce comportement est by design: plusieurs modules doivent partager le même itérateur, et un second ne peut être créé.

Steps to Troubleshoot:

1. Confirm existing iterator

• L'erreur indique qu'il y en a déjà un dans le locataire.
• Cela se produit généralement si CLS (avec le statut du client activé) ou une autre intégration a été configurée précédemment.

Confirmez le nom de l'itérateur existant via l'erreur CE enregistrée lors de l'ajout du plugin.

API response: {"message":"Only one iterator is allowed per event type. Please use the existing iterator, netskope_ce_cs_iterator_70332c65-aad4xxxxxxxxxxxxxxxxxx, or delete the existing iterator."}

2. Delete the existing iterator

• Utilisez le script ci-dessous pour supprimer l'itérateur existant

curl –location –request DELETE '<Tenant_url>/api/v2/events/dataexport/iterator/<iterator_name>' –header 'Authorization: Bearer <token>' 

• Remplacez le texte suivant :
  ○ <Tenant_url>
  ○ <iterator_name>: Copiez le nom de l'itérateur mis en évidence dans le journal des erreurs de la section "Logging".
  ○ <token>

3. Reconfigure plugins in Cloud Exchange

• Configurez d'abord le site Provider plugin.
• Ajoutez ensuite CLS, CRE et d'autres modules.
• Tous les modules créés par le même plugin Provider dans la même instance CE partageront le même itérateur.

Resolution:

• La suppression et la reconfiguration de l'itérateur permettent au même utilisateur de configurer avec succès tous les plugins dans une seule instance de CE.

Issue Overview

When Diagnosis is triggered from the Cloud Exchange > Settings > General Tab, the status of the job stays in the “Running” state. Since Diagnosis collects exhaustive details about the Cloud exchange deployment it will take few minutes to execute, however if it stays in the “Running” state even after considerable about of time then follow below steps to stop existing diagnose job.

Steps to stop the existing diagnose job

1. Navigate to the CE installation directory (In case of HA, use the node from where diagnose is triggered)
2. Verify already running diagnose jobs
   sudo ps -A | grep diagnose
3. Run command to kill existing diagnose jobs
   sudo pkill diagnose
4. Remove stale diagnose metadata files.
   • For HA Deployments
     • sudo cd {HA_NFS_DATA_DIRECTORY}
     • sudo rm -f ./diagnose_output/.diagnose_job_*
   • For Standalone Deployments
     • sudo cd {CE installation directory}
     • sudo rm -f ./data/diagnose_output/.diagnose_job_*
5. Re-trigger the Diagnose job execution

Lors de la configuration de la file d’attente dans le module Ticket Orchestrator pour le plugin ServiceNow, vous remarquerez peut-être que tous les champs cibles attendus ne sont pas disponibles dans la section Champs de carte.

Cause

Les champs cibles affichés dans la section Map Fields sont récupérés dynamiquement depuis le Destination Table configuré dans le plugin ServiceNow en utilisant le point de terminaison /api/now/table/sys_dictionary .

Au cours de ce processus :

• Seuls les champs retournés par l’API sys_dictionary sont disponibles pour le mapping.
• Les champs définis par le système (champs dont les noms commencent par sys_) sont intentionnellement exclus car ServiceNow n’autorise pas la modification de ces champs via l’API.

En conséquence, si un champ n’est pas retourné par le point de terminaison sys_dictionary, il ne sera pas disponible pour la correspondance dans la configuration de la file d’attente.

Resolution

Pour vérifier quels champs sont disponibles pour le mapping, exécutez la commande cURL suivante sur votre instance ServiceNow.

Avant d’exécuter la commande :

• Remplacez <Instance URL> par votre URL d’instance ServiceNow.
• Remplacez <Username> par votre nom d’utilisateur ServiceNow.
• Vous serez invité à entrer votre mot de passe ServiceNow.

cURL Command:

curl --location '<Instance URL>/api/now/table/sys_dictionary?sysparm_query=name%3Dincident%5EORname%3Dtask%5Einternal_type!%3Dcollection&sysparm_fields=column_label%2Celement%2Cinternal_type&sysparm_offset=0&sysparm_limit=1000' -u '<Username>' -H 'Accept: application/json'

Expected Output

La commande renvoie une réponse JSON contenant les champs disponibles pour la table de destination sélectionnée.

Chaque entrée inclut des informations telles que :

• column_label – Afficher le nom du champ.
• element – Nom interne du champ.
• internal_type – Type de champ ServiceNow.

Examinez les champs retournés pour déterminer lesquels sont disponibles pour la correspondance dans la configuration de la file d’attente.

Validation

• Si le champ attendu is present dans la réponse de l’API, il devrait également être disponible pour la sélection dans la section Map Fields de la Configuration de la file d’attente.
• Si le champ attendu is not present dans la réponse de l’API, le champ n’est pas disponible pour le mappage car il n’est pas retourné par l’API ServiceNow sys_dictionary pour la table de destination configurée.
• Les champs précédés de sys_ sont censés être absents, car ils sont exclus par conception.