Ce document explique comment résoudre les problèmes que vous pouvez rencontrer lorsque vous connectez des instances de machines virtuelles (VM) Compute Engine exécutant un paiement à l'usage (PAYG) SUSE Linux Enterprise Server (SLES) au dépôt de l'outil de gestion des souscriptions SUSE (SMT).
Avant de commencer
- Assurez-vous que la VM est associée à un compte de service.
- Assurez-vous que l'API Service Metadata est accessible à partir de la VM.
- Assurez-vous que la connectivité réseau entre la VM et les serveurs de région et les serveurs SMT est établie.
- Utilisez l'outil sc-repocheck pour résoudre automatiquement les problèmes.
- Suivez les étapes décrites dans le guide de dépannage de SUSE PAYG.
-
Si ce n'est pas déjà fait, configurez l'authentification.
L'authentification permet de valider votre identité pour accéder aux services et aux API Google Cloud . Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes :
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
-
Installez la Google Cloud CLI. Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante :
gcloud initSi vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
- Set a default region and zone.
Problèmes de réseau
Nom de domaine non résolu
Vous pouvez rencontrer les problèmes suivants si la VM ne peut pas se connecter au serveur SMT
smt-gce.susecloud.net:SUSEConnect error: SocketError: getaddrinfo: Name or service not knownping: unknown host smt-gce.susecloud.netCes problèmes sont généralement dus à une résolution incorrecte du nom de domaine du serveur SMT
smt-gce.susecloud.net. Ce domaine ne peut pas être résolu à l'échelle mondiale. Vous devez donc définir son adresse IP en fonction de la région de la VM en procédant comme suit :Vérifiez le fichier
/etc/hostspour vous assurer qu'il contient une entrée avec le domainesmt-gce.susecloud.net.cat /etc/hosts | grep -i smtLe résultat ressemble à ce qui suit, mais l'adresse IP peut être différente:
# Added by SMT registration do not remove, retain comment as well 108.59.80.221 smt-gce.susecloud.net smt-gceSi le fichier
/etc/hostsne contient pas les mêmes lignes que l'exemple précédent, procédez comme suit:Recherchez une adresse IP correspondant à la région de votre VM dans la liste des adresses IP SUSE SMT.
Modifiez le fichier pour ajouter l'adresse IP SUSE SMT et toutes les autres informations manquantes.
Indisponibilité du réseau
Vous pouvez rencontrer les erreurs suivantes en raison d'une indisponibilité du réseau, même si la VM est capable de résoudre le nom de domaine du serveur de mise à jour Compute Engine:
Unexpected exception. Not ready to read within timeout.Repository 'SLE-Module-Adv-Systems-Management12-Pool' is invalid. Repository 'SLE-Module-Adv-Systems-Management12-Updates' is invalid.Voici quelques exemples d'erreurs que vous pouvez trouver dans le fichier journal
/var/log/cloudregisterlors de l'enquête :WARNING:Unable to remove client registration from server WARNING:HTTPSConnectionPool(host='smt-gce.susecloud.net', port=443): Max retries exceeded with url: /connect/systems (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 110] Connection timed out',)) INFO:Region server arguments: ?regionHint=europe-central2 ERROR:No response from: [('34.118.112.80', None), ('34.116.251.218', None), ('34.116.224.144', None)]Pour en savoir plus sur la cause du problème, effectuez un test de connectivité réseau. L'exemple suivant montre comment tester une connexion HTTPS à l'aide de
cURL:curl -sSI -m 5 -o /dev/null \ -w 'Response code (>0 is OK): %{http_code}\n' \ 'https://smt-gce.susecloud.net'Le résultat de la commande contient un code de réponse HTTP ou un message d'erreur. Voici les réponses et les erreurs courantes:
Réponse réussie :
Response code (>0 is OK): 200Erreur d'expiration de requête:
Response code (>0 is OK): 000 curl: (28) Connection timed out after 5001 millisecondsErreur de domaine non résolu :
Response code (>0 is OK): 000 curl: (6) Could not resolve host: smt-gce.susecloud.net
Dans certains cas, par exemple dans le cas de règles de pare-feu d'hôte strictes, l'adresse IP par défaut associée au domaine
smt-gce.susecloud.netpeut ne pas être disponible. Pour vous assurer que le problème n'est pas uniquement lié à l'adresse IP actuelle, testez la connectivité réseau pour les autres serveurs régionaux. Pour récupérer la liste des serveurs régionaux :Accédez à SUSE WebUI pour obtenir la liste des serveurs de mise à jour régionaux.
Utilisez l'outil
pintpour obtenir la liste des serveurs de mise à jour régionaux via la CLI.Installer le package requis
sudo zypper install python3-susepubliccloudinfoUtiliser la commande suivante avec une région spécifique
pint google servers --region us-central1Un résultat positif contient une liste d'entrées au format XML.
<?xml version='1.0' encoding='UTF-8'?> <servers> <server ip="146.148.73.14" name="" region="us-central1" type="regionserver-sles"/> <server ip="162.222.182.90" name="" region="us-central1" type="regionserver-sap"/> <server ip="108.59.80.221" name="smt-gce.susecloud.net" region="us-central1" type="smt"/> <server ip="108.59.85.41" name="smt-gce.susecloud.net" region="us-central1" type="smt"/> <server ip="108.59.80.58" name="smt-gce.susecloud.net" region="us-central1" type="smt"/> </servers>
Pour trouver la liste complète des adresses IP de serveurs SUSE pour Google Cloud, consultez les documents suivants :
Une mauvaise configuration de la VM peut entraîner l'indisponibilité du réseau. En cas de problème, effectuez des diagnostics réseau pour identifier la cause première.
Échec de l'enregistrement
Vous pouvez rencontrer l'erreur suivante si vous avez des VM disposant d'une adresse IP privée dans Cloud NAT :
ERROR: Registration failed: Registering system to registration proxy https://smt-gce.susecloud.net command '/usr/bin/zypper --non-interactive refs Python_3_Module_x86_64' failed Error: zypper returned 4 with 'Problem retrieving the repository index file for service 'Python_3_Module_x86_64': Timeout exceeded when accessing 'https://smt-gce.susecloud.net/services/2045/repo/repoindex.xml?credentials=Python_3_Module_x86_64'.Pour résoudre ce problème, examinez votre configuration Cloud NAT et vérifiez que vous avez défini le paramètre nombre minimal de ports par instance de VM sur au moins 256.
Pour plus d'informations, consultez le bulletin d'assistance SUSE Échec de l'enregistrement et de zypper pour les instances Compute Engine derrière Cloud NAT.
Pas de réponse
Si votre VM rencontre des problèmes de communication avec les serveurs de mises à jour et de régions, vous pouvez rencontrer les erreurs suivantes :
Erreur
SUSEConnect:SUSEConnect error: Errno::ETIMEDOUT: Connection timed out - connect(2) for "smt-gce.susecloud.net" port 443Erreur
zypper:Error retrieving metadata for 'SLE-Module-Adv-Systems-Management12-Pool': Not ready to read within timeout. ...
Ces erreurs peuvent se produire lorsque les serveurs de mise à jour et de région ne répondent pas. Pour le vérifier, recherchez le contenu similaire dans les journaux
/var/log/cloudregister:INFO:Region server arguments: ?regionHint=europe-central2 INFO:Using API: regionInfo INFO:Region server arguments: ?regionHint=europe-central2 INFO:Getting update server information, attempt 1 INFO: Using region server: 130.211.242.136 ERROR: No response from: 130.211.242.136 INFO: Using region server: 35.187.193.56 ERROR: No response from: 35.187.193.56 INFO: Using region server: 162.222.182.90 ERROR: No response from: 162.222.182.90 INFO: Using region server: 130.211.88.88 ERROR: No response from: 130.211.88.88 ERROR: None of the servers responded ERROR: Attempted: [IPv4Address('130.211.242.136'), IPv4Address('35.187.193.56'), IPv4Address('162.222.182.90'), IPv4Address('130.211.88.88')] ... ... ... ERROR:Request not answered by any server after 3 attempts ERROR:Exiting without registrationPour résoudre ce problème, essayez une ou plusieurs des solutions suivantes :
Vérifiez que la VM dispose d'une adresse IP externe ou que le sous-réseau cloud privé virtuel utilise une NAT (Cloud NAT ou solution personnalisée).
Si vous avez modifié les règles de routage réseau par défaut, telles que la limitation de l'accès Internet public ou le routage du trafic via un réseau sur site, ajoutez des routes manuellement pour les adresses IP SMT via la passerelle Compute Engine par défaut, en procédant comme suit :
Accédez à la page Routes dans la console Google Cloud .
Sous l'onglet Gestion des routes, recherchez une route qui inclut les adresses IP SMT SUSE et vérifiez que la passerelle par défaut de Compute Engine est définie comme saut suivant.
Si la route est manquante, ajoutez-la en cliquant sur Créer une route et en saisissant les informations nécessaires.
Si vous utilisez un équilibreur de charge réseau interne passthrough, par exemple avec un logiciel réseau intermédiaire supplémentaire (pare-feu, NAT personnalisé, etc…), assurez-vous que l'équilibreur de charge est le saut suivant pour le trafic de VM, en procédant comme suit :
Accédez à la page Instances de VM de la console Google Cloud .
Cliquez sur le nom de la VM que vous souhaitez vérifier. La page des détails de la VM s'affiche.
Dans la section Interfaces réseau, cliquez sur Afficher les détails.
Dans la section Détails des pare-feu et des routes, recherchez la route qui définit le chemin d'accès à la plage d'adresses IP sélectionnée.
Cliquez sur le nom de la route et vérifiez que l'équilibreur de charge réseau passthrough interne ou son adresse IP est le saut suivant.
Si aucune route ne définit le chemin d'accès vers la plage d'adresses IP sélectionnée ou si le saut suivant de la route est différent de l'équilibreur de charge réseau passthrough interne, configurez l'équilibreur de charge réseau passthrough interne en tant que saut suivant.
Si vous utilisez un équilibreur de charge réseau passthrough interne, vérifiez qu'il se trouve dans la même région que la VM.
Accédez à la page Instances de VM de la console Google Cloud .
Recherchez la VM que vous souhaitez vérifier et notez sa région.
Accédez à la page Équilibrage de charge de la console Google Cloud .
Localisez l'équilibreur de charge réseau passthrough interne utilisé et vérifiez s'il se trouve dans la même région que la VM.
Si la VM et l'équilibreur de charge réseau passthrough interne ne se trouvent pas dans la même région, activez l'accès mondial.
Enregistrement derrière les proxys
Vous pouvez rencontrer un problème si vos VM utilisent des proxys non transparents ou d'autres logiciels qui effectuent une inspection de type "personne au milieu" (PITM, person-in-the-middle), par exemple Barracuda CloudGen Firewall ou Palo Alto. L'exemple suivant illustre une tentative d'enregistrement de SLES à l'aide d'un proxy HTTP.
ERROR: Baseproduct registration failed ERROR: Registering system to registration proxy https://smt-gce.susecloud.net Announcing system to https://smt-gce.susecloud.net ... SUSEConnect error: Net::HTTPFatalError: 503 "Service Unavailable"
SUSE n'accepte pas officiellement l'enregistrement SLES derrière les proxys PITM (person-in-the-middle) et non transparents sur Compute Engine. Les configurations de proxy PITM échouent lors de l'enregistrement en raison de l'épinglage de certificat.
Nous vous recommandons d'utiliser une configuration Cloud NAT ou de configurer un serveur SMTP personnalisé.
Non-respect de VPC Service Controls
Si votre organisation utilise VPC Service Controls (VPC-SC), l'enregistrement peut échouer et un message d'erreur
Request is prohibited by organization's policypeut s'afficher. Cet échec peut être dû à des cas de non-respect des règles d'entrée ou de sortie si vous n'avez pas configuré d'exceptions pour SUSE Update Infrastructure dans votre règle VPC-SC.Pour résoudre ce problème, ajoutez les composants suivants à une liste d'autorisation dans votre règle VPC-SC afin de permettre à la VM de communiquer avec l'infrastructure de mise à jour SUSE :
- Mise à jour du projet d'infrastructure :
Suse-gce-smt(numéro de projet : 778092048372) - Compte de service :
778092048372@project.gserviceaccount.com - Méthode requise :
compute.alpha.InstancesService.GetLicenses
Problèmes de configuration de l'OS
État d'enregistrement inconnu
Si vous ne savez pas si votre paiement à l'usage (PAYG) SUSE Linux Enterprise Server (SLES) est enregistré, exécutez la commande suivante :
sudo SUSEConnect --status-textLa sortie contient la version et l'état d'enregistrement des produits SUSE, y compris SUSE Linux Enterprise Server.
Installed Products: ------------------------------------------ SUSE Linux Enterprise Server 12 SP5 (SLES/12.5/x86_64) Registered ------------------------------------------ ...Si l'état est
Not Registered, réenregistrez la VM pour résoudre le problème :sudo registercloudguest --force-newLien symbolique du produit de base incorrect
Vous pouvez rencontrer les erreurs suivantes si le lien du produit de base pointe vers un fichier de produit incorrect :
2020-06-17 12:03:56,124 ERROR:Unable to obtain product information from server "108.59.85.41,None" Unprocessable Entity {"type":"error","error":"Unmet product dependencies, activate one of these products first: SUSE Linux Enterprise Server 12 x86_64, SUSE Linux Enterprise Server for SAP Applications 12 x86_64, SUSE Linux Enterprise Server 12 SP1 x86_64, ...","localized_error":"..."} Unable to register modules, exiting.Cette erreur se produit lorsque le lien symbolique
/etc/products.d/baseproductpointe vers un fichier produit incorrect (par exemple,sle-module-toolchain.prod).Pour résoudre ce problème, mettez à jour le lien symbolique dans
/etc/products.d/baseproductpour qu'il pointe vers le fichier de produit de base approprié :Accédez au répertoire
/etc/products.dcd /etc/products.dExécutez la commande suivante en remplaçant
SLES.prodparSLES_SAP.prodsi vous avez installé SLES pour SAP :sudo ln -sf SLES.prod baseproduct
Indisponibilité des informations sur l'identité de l'instance
Vous pouvez rencontrer les erreurs suivantes si les informations d'identité de l'instance ne sont pas disponibles pour la VM. Ce problème peut se produire si aucun compte de service n'est associé à l'instance ou si le compte de service associé a été désactivé.
ERROR:Data collected from stderr for instance data collection "b'Unable to access instance identity information\n'"
Pour accéder aux métadonnées d'instance des jetons d'identité, toutes les VM doivent être associées à un compte de service.
Pour en savoir plus, consultez la page Mise à jour de l'infrastructure du cloud public.
Pour vérifier l'état du compte de service de votre VM, exécutez la commande suivante sur la VM :
curl -s -H 'Metadata-Flavor: Google' \ 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=test'Exemple de réponse réussie avec un jeton d'identité:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjkzOTd0MDQxSHQ2NDNxNzkzUjY1MDIwNzEyMjZPNnppaTdqNTl3eTciLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJ0ZXN0IiwiYXpwIjoiMjY1MDIwMDUyMzgzMjYyNTk0ODU2IiwiZXhwIjoxNjgzNzEyNTQzLCJpYXQiOjE2ODM3MTI4NjQsImlzcyI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbSIsInN1YiI6IjQ1NjA2MzQ5MDg5Mzc0Njg3ODI5NyJ9.EpzQ3NZ8mKStdpH10fL34qsKG0rjQEflzvLJLm2tVNX4xBJAkMhi8lcs5InUEY-QMK3njgbzdzNtD1fXoIfKoeWsqkA8vG3NkBz5zqRrtaB2STcO14H5tjIdTBsrCtET447tRXlGG5cvgMcWnRDZG92-jUZEpWki_Ri4T69X5-bBWkfE2Thm3oSUW4fScdeVOEmOgWnzD2jeVqQ_2YniywvpkT-rLzKfN-5AgN66zgBfXqJVTC90KFMebfiaOoL7z6ZSM9AjZGf45QEMZjxjd-Xzyee6ZWK8s0RE3hJlytb3zYcLt3tJwQ1WhnrC2ToJ-ZmKxxK3xKDLCvCQ6Ny5to
Si la VM n'est pas affectée, vous recevez un jeton. Si la VM est affectée, les métadonnées renvoyées sont un message d'erreur semblable à celui-ci :
{ "error": "invalid_request", "error_description": "Service account not enabled on this instance" }Pour résoudre ce problème, procédez comme suit :
Arrêtez la VM :
gcloud compute instances stop VM_NAMEAjoutez un compte de service à la VM:
gcloud compute instances set-service-account VM_NAME \ --service account SERVICE_ACCOUNT \ --no-scopesDémarrez la VM :
gcloud compute instances start VM_NAMEAprès avoir ajouté le compte de service manquant, exécutez la commande suivante à partir de la VM pour réenregistrer SLES :
sudo registercloudguest --force-new
Packages obligatoires manquants
L'enregistrement peut échouer si votre VM ne dispose pas de packages essentiels tels que
cloud-regionsrv-client,regionServiceClientConfigGCE,cloud-netconfig-gceoususeconnect-ng.Pour résoudre ce problème, installez les packages requis, nettoyez les fichiers d'enregistrement et réenregistrez la VM.
Installez les packages manquants.
sudo zypper install PACKAGE_NAMERemplacez
PACKAGE_NAMEpar le nom du package manquant.Nettoyez les anciens fichiers d'enregistrement :
sudo registercloudguest --clean sudo SUSEConnect --cleanup sudo rm -f /etc/zypp/credentials.d/* sudo rm -f /etc/zypp/repos.d/* sudo rm -f /etc/zypp/services.d/*Réenregistrez la VM :
sudo registercloudguest --force-new
Lien symbolique python3 incorrect
Si vous exécutez
registercloudguestet que l'erreurModuleNotFoundError: No module named 'requests's'affiche, cela peut être dû à un lien symbolique/usr/bin/python3incorrect, par exemple si vous l'avez écrasé manuellement.Traceback (most recent call last): File "/usr/sbin/registercloudguest", line 34, in <module> import requests ModuleNotFoundError: No module named 'requests'
Pour résoudre ce problème, recréez le lien symbolique afin qu'il pointe vers la version Python correcte.
Vérifiez la version de Python installée sur l'instance :
sudo zypper info python3Vérifiez le lien symbolique
python3:ls -ll /usr/bin | grep -i python3Si le lien est incorrect, supprimez-le et créez-en un autre qui pointe vers la version Python appropriée (par exemple,
python3.6) :sudo rm /usr/bin/python3 sudo ln -sf /usr/bin/python3.6 /usr/bin/python3
Échec de la validation du certificat SSL
Si des fichiers de certificat sont manquants dans le répertoire
/etc/pki/trust/anchors, des erreurs telles queCurl error 60oussl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]peuvent s'afficher. Voici un exemple plus détaillé d'erreur que vous pouvez rencontrer dans/var/log/cloudregister:Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 677, in urlopen ... File "/usr/lib64/python3.6/ssl.py", line 689, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)
Pour vérifier que des fichiers de certificat sont manquants, exécutez la commande suivante et vérifiez que la sortie est vide :
ls -lart /etc/pki/trust/anchorsSi des certificats sont manquants, le résultat doit être vide :
total 0Pour résoudre ce problème, essayez l'une des options suivantes :
Option 1 : Nettoyer et réenregistrer
Supprimez tous les fichiers associés à l'enregistrement, puis forcez un nouvel enregistrement. Le processus d'enregistrement télécharge les certificats nécessaires à partir des serveurs régionaux.
sudo registercloudguest --clean && \ sudo SUSEConnect --cleanup && \ sudo rm -f /etc/zypp/credentials.d/* && \ sudo rm -f /etc/zypp/repos.d/* && \ sudo rm -f /etc/zypp/services.d/* && \ sudo rm -f /etc/pki/trust/anchors/* && \ sudo sed -i '/^# Added by SMT reg/,+1d' /etc/hosts && \ sudo registercloudguest --force-newOption 2 : Copier les certificats à partir d'une instance fonctionnelle
Si le nettoyage et le nouvel enregistrement ne résolvent pas le problème, vous pouvez copier les fichiers de certificat à partir d'une instance fonctionnelle à l'aide de
gcloud compute scpou en associant le disque de démarrage d'une instance fonctionnelle à l'instance défaillante.Si vous associez et installez le disque d'une instance fonctionnelle sur
MOUNT_PATH, exécutez les commandes suivantes :sudo cp MOUNT_PATH/etc/pki/trust/anchors/* /etc/pki/trust/anchors/ sudo update-ca-certificates sudo cp -pr MOUNT_PATH/usr/lib/regionService /usr/lib/regionService sudo registercloudguest --force-new
Incompatibilité du package libzypp
Il est possible qu'une VM SUSE au paiement à l'utilisation avec SLES pour SAP 15 ne puisse pas s'enregistrer et affiche une erreur semblable à celle-ci :
ERROR:Baseproduct registration failed Registering system to registration proxy https://smt-gce.susecloud.net ... command '/usr/bin/zypper --non-interactive refs SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64' failed Error: zypper returned 1 with 'Error occurred while setting download (curl) options for 'https://smt-gce.susecloud.net/services/2294?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64': Unexpected exception. Unknown error reading from 'plugin:/susecloud?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64&path=/services/2294' ... - Error occurred while setting download (curl) options for 'https://smt-gce.susecloud.net/services/2294?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64':
Ce problème peut se produire lorsqu'une mise à jour du package
libzypplaisse une version incompatible du packagelibcurl4. Lorsquelibzypptente de se mettre à jour automatiquement, il ne peut plus utiliserlibcurl4pour envoyer des requêtes aux emplacements des packages.Pour résoudre ce problème, mettez à jour manuellement le package
libzypp. La commande suivante est un exemple. Vous devrez peut-être ajuster le numéro de version :sudo rpm -i libzypp-17.31.31-150400.3.52.2.x86_64.rpmVersion d'OS non compatible ou packages obsolètes
Si vous exécutez une version d'OS qui n'est plus couverte par l'assistance générale (par exemple, SLES 12 SP4, pour laquelle l'assistance générale a pris fin le 30 juin 2020), l'enregistrement peut échouer. Cet échec peut se produire, car des packages obsolètes sur la VM ne peuvent pas communiquer avec l'infrastructure de mise à jour SUSE. Des erreurs concernant des adresses IP inaccessibles peuvent s'afficher dans le fichier journal
/var/log/cloudregister, même si la connectivité réseau semble partiellement réussie (par exemple, si l'utilisation detelnetpour les serveurs SMTP renvoie une erreur403 Forbidden).Pour vérifier si des packages sont obsolètes, vous pouvez consulter leurs dates d'installation. Les packages qui n'ont pas été mis à jour depuis plus d'un an peuvent être obsolètes. Pour vérifier la date de la dernière mise à jour d'un package, utilisez la commande suivante :
rpm -qa --qf '%{NAME}-%{VERSION} : %{INSTALLTIME:date}\n' | grep PACKAGE_NAMEPour résoudre ce problème, passez à une version SLES compatible. Vous devrez peut-être également mettre à jour des packages spécifiques, comme décrit dans les documents d'informations techniques (TID) de SUSE.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/12/04 (UTC).
-