Comment résoudre un problème d’installation de l’AWS Replication Agent sur mon serveur Linux ?

Solution

Identification de la cause des problèmes d’installation

Utilisez le dossier d’exploitation AWSSupport-TroubleshootLinuxMGNDRSAgentLogs

Prérequis : vérifiez que votre utilisateur ou rôle Gestion des identités et des accès AWS (AWS IAM) dispose des autorisations nécessaires. Pour plus d’informations, consultez la section Required IAM permissions dans AWSSupport-TroubleshootLinuxMGNDRSAgentLogs. Vous devez également charger le fichier journal de l’agent de réplication installer-path/aws_replication_agent_installer.log dans un compartiment Amazon Simple Storage Service (Amazon S3).

Pour identifier automatiquement les problèmes d’installation de l’agent de réplication d’Application Migration Service ou d’Elastic Disaster Recovery sur les serveurs sources Linux, utilisez le dossier d’exploitation d’automatisation AWSSupport-TroubleshootLinuxMGNDRSAgentLogs. Ce dossier d’exploitation analyse les fichiers journaux d’installation de l’AWS Replication Agent afin de fournir une liste des erreurs détectées et des solutions permettant de les résoudre.

Pour exécuter AWSSupport-TroubleshootLinuxMGNDRSAgentLogs, consultez la section Instructions dans AWSSupport-TroubleshootLinuxMGNDRSAgentLogs. Pour ServiceName (obligatoire), sélectionnez AWS MGN pour Application Migration Service ou AWS DRS pour Elastic Disaster Recovery.

Identifiez les erreurs manuellement

Exécutez la commande suivante pour identifier manuellement les erreurs survenues lors de l’installation de l’AWS Replication Agent :

less +G installer-path/aws_replication_agent_installer.log

Remarque : remplacez installer-path par le chemin d’installation que vous avez utilisé pour l’agent de réplication.

Une fois l’erreur identifiée, suivez les étapes de dépannage correspondantes pour résoudre le problème.

Résoudre l’erreur « failed to map segment from shared object: Operation not permitted »

Le script d’installation utilise le répertoire /tmp. Si vous définissez noexec sur /tmp, libz.so ne peut pas mapper les segments, ce qui génère le message d’erreur suivant :

« error while loading shared libraries: libz.so.1: failed to map segment from shared object: Operation not permitted »

Pour résoudre ce problème, exécutez la commande suivante afin de monter le volume avec les autorisations exec :

sudo mount /tmp -o remount,exec

Ensuite, réinstallez l’AWS Replication Agent pour Application Migration Service ou Elastic Disaster Recovery.

Une fois l’installation terminée, exécutez la commande suivante pour réactiver noexec sur le serveur :

sudo mount /tmp -o remount,noexec

Si vous ne souhaitez pas supprimer noexec du répertoire /tmp, ajoutez la variable d’environnement suivante à la commande :

TMPDIR='my_temp_dir' AGENT INSTALLATION COMMAND

Remarque : remplacez my_temp_dir par un répertoire sur lequel l’option noexec n’est pas activée, et AGENT INSTALLATION COMMAND par la commande que vous utilisez pour installer l’agent.

Exemple de commande :

TMPDIR='temp1' sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init

Résoudre l’erreur « security token included in the request is expired »

Si votre rôle IAM arrive à expiration, les appels d’API vers le point de terminaison d’Application Migration Service ou d’Elastic Disaster Recovery échouent. Par conséquent, vous recevez le message d’erreur suivant :

« botocore.exceptions.ClientError: An error occurred (ExpiredTokenException) when calling the GetAgentInstallationAssetsForDrs operation: The security token included in the request is expired [installation_id: 1a9af9d3-9485-4e02-965e-611929428c61, agent_version: 3.7.0, mac_addresses: 206915885515739,206915885515740, _origin_client_type: installer] »

Pour résoudre ce problème, demandez des informations d’identification de sécurité temporaires pour générer un nouveau jeton. Vous pouvez également installer le rôle à l’aide d’une clé d’accès ou d’une clé d’accès secrète pour Application Migration Service ou Elastic Disaster Recovery.

Résoudre l’erreur « ssl.SSLCertVerificationError »

Si vous utilisez une version antérieure d’un système d’exploitation (OS) avec Python 3.10 ou version ultérieure, le message d’erreur suivant peut s’afficher :

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997) - urllib.error.URLError: urlopen error unknown url type: https

Ce problème est dû au fait que Python 3.10 et les versions ultérieures nécessitent OpenSSL 1.1.1 ou version ultérieure. Les versions antérieures des systèmes d’exploitation utilisent une version obsolète d’OpenSSL. Python ne peut donc pas créer un module SSL fonctionnel. L’AWS Replication Agent ne peut alors pas valider le certificat SSL du point de terminaison d’Application Migration Service ou d’Elastic Disaster Recovery. Pour plus d’informations, consultez la section PEP 644 -- Require OpenSSL 1.1.1 or newer sur le site web Python Enhancement Proposals.

Pour résoudre ce problème, procédez comme suit pour mettre à jour le système d’exploitation :

1. Pour actualiser l’ensemble de certificats de l’autorité de certification (CA), exécutez la commande correspondant à votre distribution Linux.
   Amazon Linux, Red Hat Enterprise Linux (RHEL), CentOS, Oracle, Rocky et AlmaLinux :

   sudo yum install -y ca-certificates && sudo update-ca-trust

   SUSE et SUSE Linux Enterprise Server (SLES) :

   sudo zypper install -y ca-certificates && sudo update-ca-certificates

   Debian et Ubuntu :

   sudo apt-get update && sudo apt-get install -y ca-certificates && sudo update-ca-certificates

2. Exécutez la commande suivante pour vérifier la version d’OpenSSL utilisée par Python :

    python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"

   Remarque : sur SLES, la version d’OpenSSL indiquée peut être plus récente que celle réellement utilisée par Python. Pour déterminer la version correcte, vérifiez celle indiquée par Python.

3. Si le référentiel de votre distribution ne propose pas OpenSSL 1.1.1 ou une version ultérieure, passez à l’étape 4.
   Remarque : pour les instances Amazon Linux 2 (AL2), passez à l’étape 4. La dernière version d’OpenSSL disponible pour AL2 est la version 1.0.2. AL2 est arrivé en fin de vie le 30 juin 2026. Il est recommandé de migrer les instances AL2 vers Amazon Linux 2023 (AL2023).
   Si les référentiels de votre distribution proposent OpenSSL 1.1.1 ou une version ultérieure, mettez OpenSSL à jour à l’aide du gestionnaire de packages. Exécutez la commande correspondant à votre distribution.
   RHEL, CentOS, Oracle, Rocky et AlmaLinux :

   sudo yum update -y openssl openssl-libs

   Remarque : pour AL2023 et les autres distributions Linux utilisant dnf, remplacez yum par dnf.
   SUSE et SLES :

   sudo zypper --non-interactive update openssl libopenssl1_1 libopenssl3

   Debian et Ubuntu :

   sudo apt-get update && sudo apt-get install --only-upgrade -y openssl libssl3

   Remarque : pour les versions de Debian et Ubuntu qui utilisent OpenSSL 1.1.1, remplacez libssl3 par libssl1.1.

4. Mettez à niveau votre système d’exploitation vers une version plus récente prenant en charge OpenSSL 1.1.1 ou une version ultérieure.

5. Réinstallez l’AWS Replication Agent pour Application Migration Service ou Elastic Disaster Recovery.

Important : n’installez pas une version antérieure de Python, telle que Python 2.7 ou 3.8, pour contourner l’exigence liée à la version d’OpenSSL. Ces versions de Python sont arrivées en fin de vie et ne sont plus disponibles dans les référentiels des distributions.

Résoudre l’erreur « botocore.exceptions.CredentialRetrievalError »

Si vous modifiez le rôle de service IAM AWSElasticDisasterRecoveryAgentRole ou AWSApplicationMigrationAgentRole, le message d’erreur suivant s’affiche :

« botocore.exceptions.CredentialRetrievalError: Error when retrieving credentials from cert: Oct 17, 2022 9:38:54 AM com.amazonaws.cloudendure.credentials_provider.SharedMain createAndSaveJks »

Pour résoudre ce problème, mettez à jour la politique d’autorisations pour le rôle de service IAM en fonction du service que vous utilisez.

Politique d’autorisations d’Application Migration Service :

{      "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Effect": "Allow",  
            "Principal": {  
                "Service": "mgn.amazonaws.com"  
            },  
            "Action": [  
                "sts:AssumeRole",  
                "sts:SetSourceIdentity"  
            ],  
            "Condition": {  
                "StringLike": {  
                    "sts:SourceIdentity": "s-*",  
                    "aws:SourceAccount": "123456789012"  
                }  
            }  
        }  
    ]
}

Remarque : remplacez 123456789012 par l’ID de votre compte AWS.

Politique d’autorisations d’Elastic Disaster Recovery :

{      "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Effect": "Allow",  
            "Principal": {  
                "Service": "drs.amazonaws.com"  
            },  
            "Action": [  
                "sts:AssumeRole",  
                "sts:SetSourceIdentity"  
            ],  
            "Condition": {  
                "StringLike": {  
                    "sts:SourceIdentity": "s-*",  
                    "aws:SourceAccount": "123456789012"  
                }  
            }  
        }  
    ]  
}

Remarque : remplacez 123456789012 par votre ID de compte.

Résoudre l’erreur « A dependency job for aws-replication.target failed »

Si les autorisations du répertoire /var sont définies sur 754 ou si vous rencontrez des problèmes lors de la création des groupes Linux pour l’utilisateur aws-replication, le message d’erreur suivant s’affiche :

« stderr: A dependency job for aws-replication.target failed. See 'journalctl -xe' for details »

Pour résoudre le problème lié aux autorisations de /var, exécutez la commande suivante :

sudo chmod 755 /var

Pour résoudre le problème lié au groupe Linux, procédez comme suit :

1. Désinstallez l’AWS Replication Agent pour Application Migration Service ou Elastic Disaster Recovery.

2. Exécutez les commandes suivantes pour supprimer l’utilisateur aws-replication et le groupe aws-replication :

   sudo userdel aws-replication
   sudo groupdel aws-replication

3. Réinstallez l’AWS Replication Agent pour Application Migration Service ou Elastic Disaster Recovery.

Pour connaître les prérequis d’installation pour Application Migration Service, consultez la section Installation requirements. Pour Elastic Disaster Recovery, consultez la section Installation requirements for AWS Replication Agent.

Résoudre l’erreur « Exception in thread "main" com.amazonaws.services.drs.model.InternalServerException »

Si vous désactivez le point de terminaison du Service de jetons de sécurité AWS (AWS STS), le message d’erreur suivant s’affiche :

« Exception in thread "main" com.amazonaws.services.drs.model.InternalServerException: An unexpected error has occurred (Service: Drs; Status Code: 500; Error Code: InternalServerException; Request ID: 4f4a76cb-aaec-44cc-a07a-c3579454ca55; Proxy: null »

Cette erreur se produit car Application Migration Service et Elastic Disaster Recovery appellent AWS STS afin qu’il assume le rôle dans le compte client. Pour résoudre ce problème, activez le point de terminaison STS dans le compte client.

Erreur « could not insert module ./aws-replication-driver.ko: »

Si vous avez activé SecureBoot sur le serveur source, l’un des messages d’erreur suivants s’affiche :

« insmod: ERROR: could not insert module ./aws-replication-driver.ko: Required key not available »

« insmod: ERROR: could not insert module ./aws-replication-driver.ko: Key was rejected by service »

Vous ne pouvez pas utiliser SecureBoot sur un système d’exploitation Linux avec Application Migration Service ou Elastic Disaster Recovery. Pour résoudre ce problème, désactivez SecureBoot pour le système d’exploitation Linux.

Remarque : en général, SecureBoot se désactive depuis l’hyperviseur.

Pour vérifier l’état de SecureBoot, exécutez la commande suivante :

sudo mokutil --sb-state

Résoudre l’erreur « could not insert module ./aws-replication-driver.ko: Cannot allocate memory »

Si votre système d’exploitation Linux ne dispose pas d’une quantité suffisante de mémoire pour installer l’agent, le message d’erreur suivant s’affiche :

« insmod: ERROR: could not insert module ./aws-replication-driver.ko: Cannot allocate memory »

Pour résoudre ce problème, assurez-vous que votre système d’exploitation dispose d’une mémoire disponible d’au moins 300 Mo lorsque vous exécutez l’installation. Ce problème peut se produire en raison de la fragmentation de la mémoire. Pour résoudre les problèmes de fragmentation de la mémoire, redémarrez le serveur source. Vérifiez également qu’aucun logiciel de sécurité ou antivirus ne bloque l’installation de l’agent en raison d’un mécanisme de protection de la mémoire ou du noyau.

Résoudre les erreurs « Unexpected error while making agent driver! », « Kernel development package ...missing from repositories » ou « Kernel development or header package...did not install »

Prérequis : vérifiez que vous respectez les prérequis d’installation Linux.

Les en-têtes ou la version de développement du noyau doit correspondre à celle du noyau actuellement en cours d’exécution pour permettre à AWS Replication Agent de compiler son pilote. Si l’agent ne parvient pas à trouver ou à installer les packages correspondant au noyau en cours d’exécution, l’un des messages d’erreur suivants s’affiche :

« Unexpected error while making agent driver! Are kernel linux headers installed correctly? »

« Kernel development package for '************' are missing from repositories »

« Kernel development or header package for ************ did not install »

Afin de résoudre ce problème, procédez comme suit :

1. Consultez le journal d’installation afin de détecter d’éventuels problèmes d’accès au référentiel, par exemple si le référentiel est désactivé ou si aucun chemin réseau ne permet d’y accéder.

2. Exécutez la commande suivante pour vérifier la version du noyau actuellement en cours d’exécution :

   uname -r

3. Si le dossier contenant les éléments kernel-devel ou linux-headers est un lien symbolique, supprimez le lien.

4. Pour installer la version du package correspondant à votre noyau, exécutez la commande appropriée selon votre distribution.
   AL2, RHEL, CentOS, Rocky, AlmaLinux et Oracle :

   sudo yum install -y kernel-devel-$(uname -r)

   Remarque : pour AL2023 et les autres distributions Linux utilisant dnf, remplacez yum par dnf.
   Oracle Linux avec le noyau Unbreakable Enterprise Kernel (UEK) :

   sudo yum install -y kernel-uek-devel-$(uname -r)

   SUSE et SLES :

   sudo zypper install -y kernel-default-devel-$(uname -r)

   Remarque : la commande ci-dessus utilise la variante de noyau par défaut. Si vous utilisez une autre variante, remplacez default par le nom de cette variante.
   Debian et Ubuntu :

   sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

5. Si aucun package ne correspond à la version de votre noyau en cours d’exécution, téléchargez le package manuellement. Vous pouvez également mettre à niveau le noyau vers une version compatible avec les packages disponibles dans votre distribution :
   Pour les répertoires de packages RHEL, CentOS, Oracle et SUSE, consultez la documentation de votre distribution relative aux packages.
   Pour Debian, consultez la section Paquets sur le site web Debian.
   Pour Ubuntu, consultez la section Recherche de paquets Ubuntu sur le site web des packages Ubuntu.

6. Réinstallez l’AWS Replication Agent pour Application Migration Service ou Elastic Disaster Recovery.

Informations connexes

Troubleshooting agent issues

Troubleshooting Elastic Disaster Recovery

Troubleshooting (Application Migration Service)