View a markdown version of this page

Problèmes connus - Studio de recherche et d'ingénierie

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Problèmes connus

Problèmes connus 2024.x

........................

(2024.12 et 2024.12.01) Échec de Regex lors de l'enregistrement d'un nouvel utilisateur de Cognito

Description du bogue

Si vous tentez d'enregistrer des utilisateurs de AWS Cognito via le portail Web dont le préfixe d'e-mail contient » . «, par exemple<firstname>.<lastname>@<company>.com, cela provoquera une erreur indiquant que le nom d'utilisateur de Cognito ne correspond pas au modèle d'expression régulière défini.

Erreur de paramètres non valides

Cette erreur est due au fait que RES génère automatiquement des noms d'utilisateur à partir du préfixe de courrier électronique de l'utilisateur. Cependant, les noms d'utilisateur marqués de «. » ne sont pas des utilisateurs valides pour les VDI dans certaines distributions Linux prises en charge par RES. Ce correctif supprime tout «. » dans le préfixe d'e-mail lors de la génération d'un nom d'utilisateur afin que le nom d'utilisateur soit valide sur les VDI RES Linux.

Versions concernées

Versions RES 2024.12 et 2024.12.01

Mitigation

  1. Exécutez les commandes suivantes pour télécharger patch.py et cognito_sign_up_email_fix.patch pour la version 2024.12 ou cognito_sign_up_email_fix.patch pour la version 2024.12.01, en les <output-directory> remplaçant par le répertoire dans lequel vous souhaitez télécharger le script de correctif et le fichier de correctif, et par le nom de votre <environment-name> environnement RES :

    1. Le correctif s'applique aux normes RES 2024.12 et 2024.12.01.

    2. Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.

    3. Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> RES_VERSION=<res-version> # either 2024.12 or 2024.12.01 mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patches/cognito_sign_up_email_fix.patch --output ${OUTPUT_DIRECTORY}/cognito_sign_up_email_fix.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif ont été téléchargés. Exécutez la commande de correctif suivante :

    python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version ${RES_VERSION} --module cluster-manager --patch ${OUTPUT_DIRECTORY}/cognito_sign_up_email_fix.patch
  3. Redémarrez l'instance de Cluster Manager pour votre environnement. Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.

    INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
  4. Vérifiez l'état de l'instance de Cluster Manager en vérifiant l'activité du groupe de dimensionnement automatique en commençant par son nom<RES-EnvironmentName>-cluster-manager-asg. Attendez que la nouvelle instance soit lancée avec succès.

........................

(2024.12.01 et versions antérieures) Erreur de mauvais certificat non valide lors de la connexion au VDI à l'aide d'un domaine personnalisé

Description du bogue

Lorsque vous déployez la recette External Resources et RES avec un nom de domaine de portail personnalisé, vous CertificateRenewalNode ne parvenez pas à actualiser le certificat TLS pour la connexion VDI avec l'erreur suivante dans : /var/log/user-data.log

{ "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Error finalizing order :: OCSP must-staple extension is no longer available: see https://letsencrypt.org/2024/12/05/ending-ocsp", "status": 403 }

Par conséquent, vous rencontrerez une erreur indiquant net::ERR_CERT_DATE_INVALID (Chrome) ou Error code: SSL_ERROR_BAD_CERT_DOMAIN (FireFox) lorsque vous vous connectez à vos VDI sur le portail Web RES.

Versions concernées

2024.12.01 et versions antérieures

Mitigation

  1. Accédez à la console EC2. Si une instance est nomméeCertificateRenewalNode-, mettez-la hors service.

  2. Accédez à la console Lambda. Ouvrez le code source de la fonction Lambda nommée. -CertificateRenewalLambda- Identifiez la ligne commençant par ./acme.sh --issue --dns dns_aws --ocsp-must-staple --keylength 4096 et supprimez l'--ocsp-must-stapleargument.

  3. Sélectionnez Déployer et attendez que le changement de code prenne effet.

  4. Pour déclencher manuellement la fonction Lambda : allez dans l'onglet Test, puis sélectionnez Test. Aucune saisie supplémentaire n'est requise. Cela devrait créer une instance de certificat EC2 qui met à jour le certificat et PrivateKey les secrets dans Secret Manager. L'instance sera automatiquement résiliée une fois les secrets mis à jour.

  5. Mettez fin à l'instance dcv-gateway existante : <env-name>-vdc-gateway et attendez que le groupe auto scaling en déploie automatiquement une nouvelle.

Détails de l'erreur

Let's Encrypt mettra fin au support OCSP en 2025. À compter du 30 janvier 2025, les Must-Staple demandes OCSP échoueront sauf si le compte demandeur a préalablement émis un certificat contenant l'extension OCSP Must Staple. Vérifiez https://letsencrypt.org/2024/12/05/ending-ocsp/pour plus de détails.

........................

(2024.12 et 2024.12.01) Les utilisateurs d'Active Directory ne peuvent pas se connecter par SSH à Bastion Host

Description du bogue

Les utilisateurs d'Active Directory reçoivent un message d'erreur de refus d'autorisation lorsqu'ils se connectent à l'hôte Bastion en suivant les instructions du portail Web RES.

L'application Python qui s'exécute sur l'hôte Bastion ne parvient pas à lancer le service SSSD en raison d'une variable d'environnement manquante. Par conséquent, les utilisateurs d'AD sont inconnus du système d'exploitation et ne peuvent pas se connecter.

Versions concernées

2024.12 et 2024.12.01

Mitigation

  1. Connectez-vous à l'instance Bastion Host depuis la console EC2.

  2. Modifiez /etc/environment et ajoutez environment_name=<res-environment-name> une nouvelle ligne sous IDEA_CLUSTER_NAME.

  3. Exécutez les commandes suivantes sur l'instance :

    source /etc/environment sudo service supervisord restart sudo systemctl restart supervisord
  4. Réessayez de vous connecter à l'hôte Bastion en suivant les instructions du portail Web RES.

........................

(2024.10) L'arrêt automatique du VDI est interrompu pour les environnements RES déployés dans des VPC isolés

Description du bogue

Avec la version 2024.10 RES, l'arrêt automatique des VDI a été ajouté pour les VDI inactifs pendant un certain temps. Ce paramètre peut être configuré dans Paramètres du bureau → Serveur → Session.

L'arrêt automatique VDI n'est actuellement pas pris en charge pour les environnements RES déployés dans des VPC isolés.

Versions concernées

2024,10

Mitigation

Nous travaillons actuellement sur un correctif qui sera inclus dans une future version. Cependant, il est toujours possible d'arrêter manuellement les VDI dans les environnements RES déployés dans des VPC isolés.

........................

(2024.10 et versions antérieures) Impossible de lancer VDI pour les types d'instances Graphic Enhanced

Description du bogue

Lorsqu'un VDI Amazon Linux 2 - x86_64, RHEL 8 - x86_64 ou RHEL 9 x86_64 est lancé sur un type d'instance graphique amélioré (g4, g5), l'instance reste bloquée dans l'état de provisionnement. Cela signifie que l'instance n'atteindra jamais l'état « Prêt » et ne sera jamais disponible pour la connexion.

Cela se produit parce que le serveur X n'instancie pas correctement sur les instances. Après avoir appliqué ce correctif, nous vous suggérons également d'augmenter la taille du volume racine de vos piles logicielles pour les instances graphiques à 50 Go afin de garantir un espace suffisant pour installer toutes les dépendances.

Versions concernées

Toutes les versions RES 2024.10 ou antérieures.

Mitigation

  1. Téléchargez les fichiers patch.py et graphic_enhanced_instance_types_fix.patch en les remplaçant <output-directory> par le répertoire dans lequel vous souhaitez télécharger le script et le fichier de correctif et par le nom de votre environnement RES dans la commande ci-dessous : <environment-name>

    1. Le correctif ne s'applique qu'à RES 2024.10.

    2. Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.

    3. Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.10/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.10/patch_scripts/patches/graphic_enhanced_instance_types_fix.patch --output ${OUTPUT_DIRECTORY}/graphic_enhanced_instance_types_fix.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif ont été téléchargés. Exécutez la commande de correctif suivante :

    python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.10 --module virtual-desktop-controller --patch ${OUTPUT_DIRECTORY}/graphic_enhanced_instance_types_fix.patch
  3. Pour mettre fin à l'instance Virtual Desktop Controller (vdc-controller) de votre environnement, exécutez les commandes suivantes en remplaçant le nom de votre environnement RES comme indiqué.

    INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
  4. Lancez une nouvelle instance une fois que le groupe cible commençant par le nom <RES-EnvironmentName>-vdc-ext est devenu sain. Nous recommandons que toutes les nouvelles piles logicielles que vous enregistrez pour les instances graphiques disposent d'au moins 50 Go de stockage.

........................

(2024.08) Préparation à une défaillance de l'AMI d'infrastructure

Description du bogue

Lorsque vous préparez des AMI à l'aide d'EC2 Image Builder conformément aux instructions répertoriées dans la documentation des prérequis, le processus de création échoue avec le message d'erreur suivant :

CmdExecution: [ERROR] Command execution has resulted in an error

Cela est dû à des erreurs dans le fichier de dépendances fourni dans la documentation.

Versions concernées

2024,08

Mitigation

Créez de nouvelles ressources EC2 Image Builder :

(Suivez ces étapes si vous n'avez jamais préparé d'AMI pour les instances RES)

  1. Téléchargez le fichier res-installation-scripts.tar.gz mis à jour.

  2. Suivez les étapes répertoriées sous Préparer les images Amazon Machine (AMI) sur la page des conditions préalables.

Réutilisation des ressources précédentes d'EC2 Image Builder :

(Suivez ces étapes si vous avez préparé des AMI pour les instances RES)

  1. Téléchargez le fichier res-installation-scripts.tar.gz mis à jour.

  2. Accédez à EC2 Image Builder → Composants → Cliquez sur le composant créé pour préparer les AMI RES.

  3. Notez l'emplacement S3 indiqué sous Contenu → DownloadRESInstallScripts étape → entrées → source.

  4. L'emplacement S3 ci-dessus contient le fichier de dépendances précédemment utilisé. Remplacez ce fichier par le fichier téléchargé lors de la première étape.

........................

(2024.08) Les bureaux virtuels ne parviennent pas à monter le compartiment read/write Amazon S3 avec l'ARN du compartiment racine et un préfixe personnalisé

Description du bogue

Research and Engineering Studio 2024.08 ne parvient pas à monter des compartiments read/write S3 sur une instance d'infrastructure de bureau virtuel (VDI) lorsqu'il utilise un ARN de bucket racine (c'est-à-direarn:aws:s3:::example-bucket) et un préfixe personnalisé (nom du projet ou nom du projet et nom d'utilisateur).

Les configurations de bucket qui ne sont pas concernées par ce problème sont les suivantes :

  • compartiments en lecture seule

  • read/write compartiments avec un préfixe intégré à l'ARN du bucket (c'est-à-direarn:aws:s3:::example-bucket/example-folder-prefix) et un préfixe personnalisé (nom du projet ou nom du projet et nom d'utilisateur)

  • read/write buckets avec un ARN de bucket racine, mais sans préfixe personnalisé

Une fois que vous avez provisionné une instance VDI, le répertoire de montage spécifié pour ce compartiment S3 ne comportera pas de compartiment monté. Bien que le répertoire de montage du VDI soit présent, il sera vide et ne contiendra pas le contenu actuel du bucket. Lorsque vous écrivez un fichier dans le répertoire à l'aide du terminal, l'erreur Permission denied, unable to write a file est générée et le contenu du fichier n'est pas transféré dans le compartiment S3 correspondant.

Versions concernées

2024,08

Mitigation

  1. Pour télécharger le script de correctif et le fichier de correctif (patch.pyets3_mount_custom_prefix_fix.patch), exécutez la commande suivante en les <output-directory> remplaçant par le répertoire dans lequel vous souhaitez télécharger le script de correctif et le fichier de correctif et <environment-name> par le nom de votre environnement RES :

    1. Le correctif ne s'applique qu'à RES 2024.08.

    2. Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.

    3. Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations Amazon S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.08/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.08/patch_scripts/patches/s3_mount_custom_prefix_fix.patch --output ${OUTPUT_DIRECTORY}/s3_mount_custom_prefix_fix.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante :

    python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.08 --module virtual-desktop-controller --patch ${OUTPUT_DIRECTORY}/s3_mount_custom_prefix_fix.patch
  3. Pour mettre fin à l'instance de Virtual Desktop Controller (vdc-controller) de votre environnement, exécutez les commandes suivantes. (Vous avez déjà défini le nom de votre environnement RES à la ENVIRONMENT_NAME variable lors de la première étape.)

    INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
    Note

    Pour les configurations VPC privées, si ce n'est pas déjà fait, pour la <RES-EnvironmentName>-vdc-custom-credential-broker-lambda fonction, assurez-vous d'ajouter le nom AWS_STS_REGIONAL_ENDPOINTS et la Environment variable valeur de. regional Pour plus d’informations, consultez Conditions requises pour les compartiments Amazon S3 pour les déploiements de VPC isolés.

  4. Une fois que le groupe cible commençant par le nom <RES-EnvironmentName>-vdc-ext sera rétabli, de nouveaux VDI devront être lancés. Les compartiments read/write S3 dotés de l'ARN du bucket racine et d'un préfixe personnalisé devront être correctement montés.

........................

(2024.06) L'application d'un instantané échoue lorsque le nom du groupe AD contient des espaces

Problème

RES 2024.06 ne parvient pas à appliquer les instantanés des versions précédentes si les noms des groupes AD contiennent des espaces.

Les journaux du gestionnaire de clusters (sous le /<environment-name>/cluster-manager groupe de CloudWatch journaux) incluront l'erreur suivante lors de la synchronisation AD :

[apply-snapshot] authz.role-assignments/<Group name with spaces>:group#<projectID>:project FAILED_APPLY because: [INVALID_PARAMS] Actor key doesn't match the regex pattern ^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{1,20}:(user|group)$

L'erreur est due au fait que RES n'accepte que les noms de groupes répondant aux exigences suivantes :

  • Il ne peut contenir que des lettres ASCII minuscules et majuscules, des chiffres, un tiret (-), un point (.) et un trait de soulignement (_)

  • Le tiret (-) n'est pas autorisé comme premier caractère

  • Il ne doit pas contenir d'espace.

Versions concernées

2024,06

Mitigation

  1. Pour télécharger le script de correctif et le fichier de correctif (patch.py et groupname_regex.patch), exécutez la commande suivante, en les <output-directory> remplaçant par le répertoire dans lequel vous souhaitez placer les fichiers et par le nom de votre environnement <environment-name> RES :

    1. Le correctif ne s'applique qu'à RES 2024.06

    2. Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.

    3. Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES :

      OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patches/groupname_regex.patch --output ${OUTPUT_DIRECTORY}/groupname_regex.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante :

    python3 patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.06 --module cluster-manager --patch ${OUTPUT_DIRECTORY}/groupname_regex.patch
  3. Pour redémarrer l'instance de Cluster Manager pour votre environnement, exécutez les commandes suivantes : Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.

    INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
Note

Le correctif permet aux noms de groupes AD de contenir des lettres ASCII minuscules et majuscules, des chiffres, des tirets (-), des points (.), des traits de soulignement (_) et des espaces d'une longueur totale comprise entre 1 et 30 inclus.

........................

(2024.06 et versions antérieures) Les membres du groupe ne sont pas synchronisés avec RES lors de la synchronisation AD

Description du bogue

Les membres du groupe ne se synchroniseront pas correctement avec RES si le GroupOU est différent de l'UserOU.

RES crée un filtre ldapsearch lorsqu'il tente de synchroniser les utilisateurs d'un groupe AD. Le filtre actuel utilise incorrectement le paramètre UserOu au lieu du paramètre GroupOu. Le résultat est que la recherche ne renvoie aucun utilisateur. Ce comportement ne se produit que dans les cas où UserSOU et GroupOu sont différents.

Versions concernées

Toutes les versions RES 2024.06 ou antérieures

Mitigation

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

  1. Pour télécharger le script patch.py et le fichier group_member_sync_bug_fix.patch, exécutez les commandes suivantes, en les remplaçant par <output-directory> le répertoire local dans lequel vous souhaitez télécharger les fichiers et par la version de RES que vous souhaitez patcher : <res_version>

    Note
    OUTPUT_DIRECTORY=<output-directory> RES_VERSION=<res_version> mkdir -p ${OUTPUT_DIRECTORY} curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patches/${RES_VERSION}_group_member_sync_bug_fix.patch --output ${OUTPUT_DIRECTORY}/${RES_VERSION}_group_member_sync_bug_fix.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la <environment-name> remplaçant par le nom de votre environnement RES :

    cd ${OUTPUT_DIRECTORY} ENVIRONMENT_NAME=<environment-name> python3 patch.py --environment-name ${ENVIRONMENT_NAME} --res-version ${RES_VERSION} --module cluster-manager --patch $PWD/${RES_VERSION}_group_member_sync_bug_fix.patch
  3. Pour redémarrer l'instance de cluster-manager de votre environnement, exécutez les commandes suivantes :

    INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}

........................

(2024.06 et versions antérieures) CVE-2024-6387, Regresshion, vulnérabilité de sécurité dans RHEL9 et Ubuntu VDI

Description du bogue

CVE-2024-6387, baptisé RegressHion, a été identifié sur le serveur OpenSSH. Cette vulnérabilité permet à des attaquants distants non authentifiés d'exécuter du code arbitraire sur le serveur cible, ce qui représente un risque sérieux pour les systèmes qui utilisent OpenSSH pour sécuriser les communications.

Pour RES, la configuration standard consiste à passer par l'hôte bastion pour accéder en SSH aux bureaux virtuels, et l'hôte bastion n'est pas affecté par cette vulnérabilité. Cependant, l'AMI (Amazon Machine Image) par défaut que nous fournissons pour RHEL9 et Ubuntu2024 VDI (infrastructure de bureau virtuel) dans TOUTES les versions RES utilise une version OpenSSH vulnérable aux menaces de sécurité.

Cela signifie que les VDI RHEL9 et Ubuntu2024 existants pourraient être exploitables, mais que l'attaquant aurait besoin d'accéder à l'hôte du bastion.

Vous trouverez plus de détails sur le problème ici.

Versions concernées

Toutes les versions RES 2024.06 ou antérieures.

Mitigation

RHEL9 et Ubuntu ont publié des correctifs pour OpenSSH qui corrigent la faille de sécurité. Ils peuvent être extraits à l'aide du gestionnaire de packages correspondant à la plateforme.

Si vous avez des VDI RHEL9 ou Ubuntu existants, nous vous recommandons de suivre les instructions PATCH EXISTING VDI ci-dessous. Pour appliquer des correctifs aux futurs VDI, nous vous recommandons de suivre les instructions de PATCH FUTURE VDI. Ces instructions décrivent comment exécuter un script pour appliquer la mise à jour de la plateforme à vos VDI.

APPLIQUER DES CORRECTIFS AUX VDI EXISTANTS
  1. Exécutez la commande suivante pour patcher tous les VDI Ubuntu et RHEL9 existants :

    1. Le script de correctif nécessite la AWS CLI v2.

    2. Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations de AWS Systems Manager pour envoyer une commande d'exécution de Systems Manager.

      aws ssm send-command \ --document-name "AWS-RunRemoteScript" \ --targets "Key=tag:res:NodeType,Values=virtual-desktop-dcv-host" \ --parameters '{"sourceType":["S3"],"sourceInfo":["{\"path\":\"https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/scripts/patch_openssh.sh\"}"],"commandLine":["bash patch_openssh.sh"]}'
  2. Vous pouvez vérifier que le script a bien été exécuté sur la page Exécuter la commande. Cliquez sur l'onglet Historique des commandes, sélectionnez l'ID de commande le plus récent et vérifiez que tous les ID d'instance comportent un message de réussite.

APPLIQUEZ DES CORRECTIFS AUX FUTURS VDI
  1. Pour télécharger le script de correctif et le fichier de correctif (patch.py et update_openssh.patch), exécutez les commandes suivantes, en les <output-directory> remplaçant par le répertoire dans lequel vous souhaitez télécharger les fichiers et <environment-name> par le nom de votre environnement RES :

    Note
    • Le correctif ne s'applique qu'à RES 2024.06.

    • Le script de correctif nécessite AWS CLI (v2), Python 3.9.16 ou supérieur et Boto3.

    • Configurez votre copie de la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> ENVIRONMENT_NAME=<environment-name> curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.06/patch_scripts/patches/update_openssh.patch --output ${OUTPUT_DIRECTORY}/update_openssh.patch
  2. Exécutez la commande de correctif suivante :

    python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version 2024.06 --module virtual-desktop-controller --patch ${OUTPUT_DIRECTORY}/update_openssh.patch
  3. Redémarrez l'instance du contrôleur VDC pour votre environnement à l'aide des commandes suivantes :

    INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}
Important

L'application de correctifs aux futurs VDI n'est prise en charge que sur les versions RES 2024.06 et ultérieures. Pour appliquer des correctifs aux futurs VDI dans des environnements RES dont les versions sont antérieures à 2024.06, commencez par mettre à niveau l'environnement RES vers 2024.06 en suivant les instructions fournies à l'adresse :. Mises à jour majeures des versions

........................

(2024.04-2024.04.02) La limite d'autorisation IAM fournie n'est pas attachée au rôle des instances VDI

Le problème

Les sessions de bureau virtuel n'héritent pas correctement de la configuration des limites d'autorisation de leur projet. Cela est dû au fait que la limite d'autorisation définie par le IAMPermissionBoundary paramètre n'a pas été correctement attribuée à un projet lors de sa création.

Versions concernées

2024,04 - 2024,04.02

Mitigation

Procédez comme suit pour permettre aux VDI d'hériter correctement de la limite d'autorisations attribuée à un projet :

  1. Pour télécharger le script de correctif et le fichier de correctif (patch.py et vdi_host_role_permission_boundary.patch), exécutez la commande suivante, en les remplaçant par le répertoire local dans lequel vous souhaitez placer les fichiers : <output-directory>

    1. Le correctif ne s'applique qu'à RES 2024.04.02. Si vous utilisez la version 2024.04 ou 2024.04.01, vous pouvez suivre les étapes répertoriées dans le document public pour les mises à jour de version mineures afin de mettre à jour votre environnement vers la version 2024.04.02.

    2. Le script de correctif nécessite AWS CLI (v2), Python 3.9.16 ou supérieur et Boto3.

    3. Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patches/vdi_host_role_permission_boundary.patch --output ${OUTPUT_DIRECTORY}/vdi_host_role_permission_boundary.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la <environment-name> remplaçant par le nom de votre environnement RES :

    python3 patch.py --environment-name <environment-name> --res-version 2024.04.02 --module cluster-manager --patch vdi_host_role_permission_boundary.patch
  3. Redémarrez l'instance de cluster-manager dans votre environnement en exécutant cette commande, en la <environment-name> remplaçant par le nom de votre environnement RES. Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.

    ENVIRONMENT_NAME=<environment-name> INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}

........................

(2024.04.02 et versions antérieures) Les instances Windows NVIDIA dans ap-southeast-2 (Sydney) ne démarrent pas

Le problème

Les Amazon Machine Images (AMI) sont utilisées pour créer des bureaux virtuels (VDI) dans RES avec des configurations spécifiques. Chaque AMI possède un identifiant associé qui diffère selon les régions. L'ID AMI configuré dans RES pour lancer des instances Windows Nvidia dans ap-southeast-2 (Sydney) est actuellement incorrect.

AMI-ID ami-0e190f8939a996cafpour ce type d'instance, la configuration est incorrectement répertoriée dans ap-southeast-2 (Sydney). L'ID AMI ami-027cf6e71e2e442f4 doit être utilisé à la place.

Les utilisateurs obtiendront le message d'erreur suivant lorsqu'ils essaieront de lancer une instance avec l'ami-0e190f8939a996cafAMI par défaut.

An error occured (InvalidAMIID.NotFound) when calling the RunInstances operation: The image id ‘[ami-0e190f8939a996caf]’ does not exist

Étapes pour reproduire le bogue, y compris un exemple de fichier de configuration :

  • Déployez RES dans la région ap-southeast-2.

  • Lancez une instance à l'aide de la pile logicielle Windows-NVIDIA par défaut (ID AMIami-0e190f8939a996caf).

Versions concernées

Toutes les versions de RES 2024.04.02 ou antérieures sont concernées

Mitigation

Les mesures d'atténuation suivantes ont été testées sur la version RES 2024.01.01 :

  • Enregistrez une nouvelle pile logicielle avec les paramètres suivants

    • ID D'AMI : ami-027cf6e71e2e442f4

    • Système d'exploitation : Windows

    • Fabricant du GPU : NVIDIA

    • Minimum. Taille de stockage (Go) : 30

    • Minimum. RAM (GO) : 4

  • Utilisez cette pile logicielle pour lancer Windows-NVIDIA des instances

........................

(2024.04 et 2024.04.01) Échec de la suppression RES dans GovCloud

Le problème

Pendant le processus de suppression RES, le UnprotectCognitoUserPool Lambda désactive la protection contre la suppression pour les groupes d'utilisateurs de Cognito qui seront supprimés ultérieurement. L'exécution Lambda est démarrée par le. InstallerStateMachine

En raison des différences de version de la AWS CLI par défaut entre la version commerciale et les GovCloud régions, l'update_user_poolappel dans le Lambda échouera dans les GovCloud régions.

Les clients recevront le message d'erreur suivant lorsqu'ils tenteront de supprimer RES dans une GovCloud région :

Parameter validation failed: Unknown parameter in input: \"DeletionProtection\", must be one of: UserPoolId, Policies, LambdaConfig, AutoVerifiedAttributes, SmsVerificationMessage, EmailVerificationMessage, EmailVerificationSubject, VerificationMessageTemplate, SmsAuthenticationMessage, MfaConfiguration, DeviceConfiguration, EmailConfiguration, SmsConfiguration, UserPoolTags, AdminCreateUserConfig, UserPoolAddOns, AccountRecoverySetting

Étapes pour reproduire le bogue :

  • Déployer RES dans une GovCloud région

  • Supprimer la pile RES

Versions concernées

Versions RES 2024.04 et 2024.04.01

Mitigation

Les mesures d'atténuation suivantes ont été testées sur la version 2024.04 de RES :

  • Ouvrez le UnprotectCognitoUserPool Lambda

    • Convention de dénomination : <env-name>-InstallerTasksUnprotectCognitoUserPool-...

  • Paramètres d'exécution -> Modifier -> Sélectionnez Runtime Python 3.11 -> Enregistrer.

  • Ouverte CloudFormation.

  • Supprimer la pile RES -> laisser Retain Installer Resource NON COCHÉE -> Supprimer.

........................

(2024.04 - 2024.04.02) Le bureau virtuel Linux peut être bloqué à l'état « REPRISE » au redémarrage

Le problème

Les bureaux virtuels Linux peuvent rester bloqués en état « REPRISE » lors du redémarrage après un arrêt manuel ou programmé.

Une fois l'instance redémarrée, le AWS Systems Manager n'exécute aucune commande à distance pour créer une nouvelle session DCV et le message de journal suivant est absent des journaux du contrôleur vdc (sous le groupe de CloudWatch journaux) : /<environment-name>/vdc/controller CloudWatch

Handling message of type DCV_HOST_REBOOT_COMPLETE_EVENT

Versions concernées

2024,04 - 2024,04.02

Mitigation

Pour récupérer les bureaux virtuels bloqués à l'état « REPRISE » :

  1. Connectez-vous en SSH à l'instance problématique depuis la console EC2.

  2. Exécutez les commandes suivantes sur l'instance :

    sudo su - /bin/bash /root/bootstrap/latest/virtual-desktop-host-linux/configure_post_reboot.sh sudo reboot
  3. Attendez que l'instance redémarre.

Pour éviter que les nouveaux bureaux virtuels ne rencontrent le même problème :

  1. Pour télécharger le script de correctif et le fichier de correctif (patch.py et vdi_stuck_in_resuming_status.patch), exécutez la commande suivante en les remplaçant par le répertoire dans lequel vous souhaitez placer les fichiers : <output-directory>

    Note
    • Le correctif ne s'applique qu'à RES 2024.04.02.

    • Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.

    • Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patches/vdi_stuck_in_resuming_status.patch --output ${OUTPUT_DIRECTORY}/vdi_stuck_in_resuming_status.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la <environment-name> remplaçant par le nom de votre environnement RES et <aws-region> par la région dans laquelle RES est déployé :

    python3 patch.py --environment-name <environment-name> --res-version 2024.04.02 --module virtual-desktop-controller --patch vdi_stuck_in_resuming_status.patch --region <aws-region>
  3. Pour redémarrer l'instance de contrôleur VDC pour votre environnement, exécutez les commandes suivantes, en <environment-name> remplaçant par le nom de votre environnement RES :

    ENVIRONMENT_NAME=<environment-name> INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-vdc-controller \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}

........................

(2024.04.02 et versions antérieures) Impossible de synchroniser les utilisateurs AD dont SAMAccountName l'attribut inclut des majuscules ou des caractères spéciaux

Le problème

RES ne parvient pas à synchroniser les utilisateurs AD après la configuration du SSO pendant au moins deux heures (deux cycles de synchronisation AD). Les journaux du gestionnaire de clusters (sous le /<environment-name>/cluster-manager groupe de CloudWatch journaux) incluent l'erreur suivante lors de la synchronisation AD :

Error: [INVALID_PARAMS] Invalid params: user.username must match regex: ^(?=.{3,20}$)(?![_.])(?!.*[_.]{2})[a-z0-9._]+(?<![_.])$

L'erreur est due au fait que RES n'accepte qu'un nom d'utilisateur SAMAccount répondant aux exigences suivantes :

  • Il ne peut contenir que des lettres ASCII minuscules, des chiffres, un point (.), un trait de soulignement (_).

  • Le point ou le trait de soulignement ne sont pas autorisés comme premier ou dernier caractère.

  • Il ne peut pas contenir deux points continus ou deux traits de soulignement (par exemple,.., __, ._, _.).

Versions concernées

2024.04.02 et versions antérieures

Mitigation

  1. Pour télécharger le script de correctif et le fichier de correctif (patch.py et samaccountname_regex.patch), exécutez la commande suivante, en les remplaçant par le répertoire dans lequel vous <output-directory> souhaitez placer les fichiers :

    Note
    • Le correctif ne s'applique qu'à RES 2024.04.02.

    • Le script de correctif nécessite la AWS CLI v2, Python 3.9.16 ou supérieur et Boto3.

    • Configurez la AWS CLI pour le compte et la région où RES est déployé, et assurez-vous que vous disposez des autorisations S3 pour écrire dans le compartiment créé par RES.

    OUTPUT_DIRECTORY=<output-directory> curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/2024.04.02/patch_scripts/patches/samaccountname_regex.patch --output ${OUTPUT_DIRECTORY}/samaccountname_regex.patch
  2. Accédez au répertoire dans lequel le script de correctif et le fichier de correctif sont téléchargés. Exécutez la commande de correctif suivante, en la <environment-name> remplaçant par le nom de votre environnement RES :

    python3 patch.py --environment-name <environment-name> --res-version 2024.04.02 --module cluster-manager --patch samaccountname_regex.patch
  3. Pour redémarrer l'instance de Cluster Manager pour votre environnement, exécutez les commandes suivantes en <environment-name> remplaçant par le nom de votre environnement RES. Vous pouvez également mettre fin à l'instance depuis la console de gestion Amazon EC2.

    ENVIRONMENT_NAME=<environment-name> INSTANCE_ID=$(aws ec2 describe-instances \ --filters \ Name=tag:Name,Values=${ENVIRONMENT_NAME}-cluster-manager \ Name=tag:res:EnvironmentName,Values=${ENVIRONMENT_NAME}\ --query "Reservations[0].Instances[0].InstanceId" \ --output text) aws ec2 terminate-instances --instance-ids ${INSTANCE_ID}

........................

(2024.04.02 et versions antérieures) La clé privée pour accéder à l'hôte Bastion n'est pas valide

Le problème

Lorsqu'un utilisateur télécharge la clé privée pour accéder à l'hôte Bastion depuis le portail Web RES, la clé n'est pas correctement formatée : plusieurs lignes sont téléchargées en une seule ligne, ce qui rend la clé non valide. L'utilisateur obtiendra le message d'erreur suivant lorsqu'il tentera d'accéder à l'hôte du bastion avec la clé téléchargée :

Load key "<downloaded-ssh-key-path>": error in libcrypto <user-name>@<bastion-host-public-ip>: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

Versions concernées

2024.04.02 et versions antérieures

Mitigation

Nous vous recommandons d'utiliser Chrome pour télécharger les clés, car ce navigateur n'est pas concerné.

Le fichier clé peut également être reformaté en créant une nouvelle ligne après -----BEGIN PRIVATE KEY----- et une autre ligne juste avant. -----END PRIVATE KEY-----

........................