Linux Virtual Delivery Agent

Créer des VDA Linux à l’aide de Machine Creation Services (MCS)

August 21, 2024

Contributeur:

C C

Vous pouvez créer des VDA joints à un domaine et non joints à un domaine à l’aide de MCS. Si vous souhaitez créer des VDA Linux non joints à un domaine dans Citrix DaaS, vous pouvez également consulter l’article dédié Créer des VDA Linux non joints à un domaine à l’aide de MCS.

Important :

À compter de la version 2212, les modifications importantes suivantes sont apportées :

La variable AD_INTEGRATION du fichier /etc/xdl/mcs/mcs.conf ou de l’interface graphique Easy Install n’a plus de valeur par défaut. Vous devez définir une valeur selon vos besoins. Pour plus d’informations, consultez la section Étape 3h : configurer les variables MCS dans cet article.

La valeur valide de l’entrée UPDATE_MACHINE_PW dans /etc/xdl/mcs/mcs.conf n’est plus définie sur on ou off, mais sur Y ou N. Pour plus d’informations, consultez Automatiser les mises à jour du mot de passe du compte de machine dans cet article.

Distributions prises en charge

	Winbind	SSSD	Centrify	PBIS
Debian 12.5/11.9	Oui	Oui	Non	Oui
RHEL 9.4/9.3/9.2	Oui	Oui	Non	Non
RHEL 8.10/8.9/8.8	Oui	Oui	Oui	Oui
Rocky Linux 9.4/9.3/9.2	Oui	Oui	Non	Non
Rocky Linux 8.10/8.9/8.8	Oui	Oui	Non	Non
SUSE 15.5	Oui	Oui	Non	Oui
Ubuntu 22.04, Ubuntu 20.04	Oui	Oui	Non	Oui

Citrix utilise les versions de Centrify suivantes pour la validation initiale des fonctionnalités sur les distributions Linux concernées :

Distribution Linux	Version de Centrify
RHEL 7/8	5.8.0
SUSE	5.7.1
Debian, Ubuntu	5.6.1

L’utilisation d’autres versions de Centrify peut provoquer des erreurs. N’utilisez pas Centrify pour joindre un modèle de machine à un domaine.

Si vous utilisez PBIS ou Centrify pour joindre des machines créées avec MCS à des domaines Windows, effectuez les tâches suivantes :
- Sur la machine modèle, configurez le chemin de téléchargement du package PBIS ou Centrify dans le fichier /etc/xdl/mcs/mcs.conf ou installez directement le package PBIS ou Centrify.
- Avant d’exécuter /opt/Citrix/VDA/sbin/deploymcs.sh, créez une unité d’organisation dotée d’autorisations d’écriture et de réinitialisation de mot de passe sur toutes ses machines subordonnées créées avec MCS.
- Avant de redémarrer les machines créées avec MCS une fois l’exécution de /opt/Citrix/VDA/sbin/deploymcs.sh terminée, exécutez klist -li 0x3e4 purge sur votre Delivery Controller ou sur votre Citrix Cloud Connector en fonction de votre déploiement.
Pour utiliser un VDA RHEL 8.x/9.x ou Rocky Linux 8.x/9.x en cours d’exécution connecté au domaine à l’aide de SSSD comme machine virtuelle modèle pour MCS, assurez-vous que les exigences suivantes sont remplies :
- Le VDA est installé manuellement, et non via Easy Install. Easy Install utilise Adcli pour RHEL 8.x/9.x et Rocky Linux 8.x/9.x ; la combinaison de SSSD et Adcli n’est pas prise en charge par MCS.
- Un serveur Samba est configuré pour utiliser SSSD pour l’authentification AD. Pour plus d’informations, consultez l’article de Red Hat en accédant à https://access.redhat.com/solutions/3802321.

Hyperviseurs pris en charge

AWS
XenServer (anciennement Citrix Hypervisor)
GCP
Microsoft Azure
Nutanix AHV
VMware vSphere

Des résultats inattendus peuvent se produire si vous essayez de préparer une image principale sur des hyperviseurs autres que ceux qui sont compatibles.

Utiliser MCS pour créer des machines virtuelles Linux

Considérations

À partir de la version 2203, vous pouvez héberger le Linux VDA sur Microsoft Azure, AWS et GCP pour Citrix Virtual Apps and Desktops ainsi que Citrix DaaS (anciennement Citrix Virtual Apps and Desktops Service). Pour ajouter ces connexions hôtes au cloud public à votre déploiement Citrix Virtual Apps and Desktops, vous avez besoin de la licence Citrix Universal Hybrid Multi-Cloud (HMC).
Les serveurs bare metal ne sont pas pris en charge lorsqu’ils sont utilisés avec MCS pour créer des machines virtuelles.

(Pour Nutanix uniquement) Étape 1 : installer et enregistrer le plug-in Nutanix AHV

Procurez-vous le package de plug-in Nutanix AHV auprès de Nutanix. Installez et enregistrez le plug-in dans votre environnement Citrix Virtual Apps and Desktops. Pour de plus amples informations, consultez le Guide d’installation du plugin Nutanix Acropolis MCS, disponible sur le portail d’assistance Nutanix.

Étape 1a : installer et enregistrer le plug-in Nutanix AHV pour les Delivery Controller locaux

Après avoir installé Citrix Virtual Apps and Desktops, sélectionnez et installez XD MCS AHV Plugin sur vos Delivery Controller.

Plug-in Nutanix AHV pour les Delivery Controller locaux

Étape 1b : installer et enregistrer le plug-in Nutanix AHV pour les Delivery Controller cloud

Sélectionnez et installez CWA MCS AHV Plugin sur les Citrix Cloud Connector. Installez le plug-in sur tous les Citrix Cloud Connector enregistrés auprès du client Citrix Cloud. Vous devez enregistrer les Citrix Cloud Connector même lorsqu’ils desservent un emplacement de ressources sans AHV.

Étape 1c : effectuer les étapes suivantes après l’installation du plug-in

Vérifiez qu’un dossier Nutanix Acropolis a été créé dans C:\Program Files\Common Files\Citrix\HCLPlugins\CitrixMachineCreation\v1.0.0.0.
Exécutez la commande "C:\Program Files\Common Files\Citrix\HCLPlugins\RegisterPlugins.exe" -PluginsRoot "C:\Program Files\Common Files\Citrix\HCLPlugins\CitrixMachineCreation\v1.0.0.0".
Redémarrez Citrix Host, Citrix Broker et Citrix Machine Creation Services sur vos Delivery Controller locaux ou redémarrez Citrix RemoteHCLServer Service sur les Citrix Cloud Connector.

Conseil :

Nous vous recommandons d’arrêter, puis de redémarrer Citrix Host, Citrix Broker et Machine Creation Services lorsque vous installez ou mettez à jour le plug-in Nutanix AHV.

Étape 2 : créer une connexion hôte

Cette section fournit des exemples sur la création d’une connexion hôte à Azure, AWS, XenServer (anciennement Citrix Hypervisor), GCP, Nutanix AHV et VMware vSphere.

Remarque :

Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.

Pour plus d’informations, consultez Créer et gérer des connexions et des ressources dans la documentation Citrix Virtual Apps and Desktops et Créer et gérer des connexions dans la documentation Citrix DaaS.

Créer une connexion hôte à Azure dans Citrix Studio

Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez Microsoft Azure comme type de connexion.
Sélectionnez le type de connexion Microsoft Azure.
L’assistant vous guide à travers les pages. Le contenu de la page dépend du type de connexion sélectionné. Après avoir complété chaque page, sélectionnez Suivant jusqu’à la page Résumé. Pour plus d’informations, consultez Étape 2 : créer une connexion hôte dans l’article Créer des VDA Linux non joints à un domaine à l’aide de MCS.

Créer une connexion hôte à AWS dans Citrix Studio

Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez Amazon EC2comme type de connexion.

Par exemple, dans la configuration locale Citrix Studio :
Entrez la clé API et la clé secrète de votre compte AWS, puis entrez le nom de votre connexion.

La clé API correspond à l’ID de votre clé d’accès et la clé secrète à votre clé d’accès secrète. Elles sont considérées comme une paire de clés d’accès. Si vous perdez votre clé d’accès secrète, vous pouvez la supprimer et en créer une autre. Pour créer une clé d’accès, procédez comme suit :
1. Connectez-vous aux services AWS.
2. Accédez à la console Identity and Access Management (IAM). 1 Dans le panneau de navigation de gauche, choisissez Users.
3. Sélectionnez l’utilisateur cible et faites défiler vers le bas pour sélectionner l’onglet Security credentials.
4. Faites défiler vers le bas et cliquez sur Create access key. Une nouvelle fenêtre apparaît.
5. Cliquez sur Download .csv file et enregistrez la clé d’accès dans un emplacement sécurisé.
L’assistant vous guide à travers les pages. Le contenu de la page dépend du type de connexion sélectionné. Après avoir complété chaque page, sélectionnez Suivant jusqu’à la page Résumé.

Créer une connexion hôte à XenServer dans Citrix Studio

Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez XenServer (anciennement Citrix Hypervisor) dans le champ Type de connexion.
Tapez l’adresse de connexion (l’URL XenServer) et les informations d’identification.
Entrez un nom pour la connexion.

Créer une connexion hôte à GCP dans Citrix Studio

Configurez votre environnement GCP en fonction des environnements de virtualisation Google Cloud Platform, puis suivez les étapes ci-dessous pour créer une connexion hôte à GCP.

Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez Google Cloud Platform comme type de connexion.

Par exemple, dans la console Studio Web sur Citrix Cloud :
Importez la clé de compte de service de votre compte GCP et saisissez votre nom de connexion.
L’assistant vous guide à travers les pages. Le contenu de la page dépend du type de connexion sélectionné. Après avoir complété chaque page, sélectionnez Suivant jusqu’à la page Résumé. Pour plus d’informations, consultez Étape 2 : créer une connexion hôte dans l’article Créer des VDA Linux non joints à un domaine à l’aide de MCS.

Créer une connexion hôte à Nutanix dans Citrix Studio

Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez le type de connexion Nutanix AHV sur la page Connexion, puis spécifiez l’adresse et les informations d’identification de l’hyperviseur, ainsi qu’un nom pour la connexion. Sur la page Réseau, sélectionnez un réseau pour l’unité.

Par exemple, dans la configuration locale Citrix Studio :

Créer une connexion hôte vers VMware dans Citrix Studio

Installez vCenter Server dans l’environnement vSphere. Pour plus d’informations, consultez la section VMware vSphere.
Pour les Delivery Controller locaux, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans la configuration locale Citrix Studio pour créer une connexion hôte. Pour les Delivery Controller cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio Web sur Citrix Cloud pour créer une connexion hôte.
Sélectionnez le type de connexion VMware vSphere.

Par exemple, dans la configuration locale Citrix Studio :
Saisissez l’adresse de connexion (l’adresse URL du serveur vCenter) de votre compte VMware, vos informations d’identification et votre nom de connexion.

Étape 3 : préparer une image principale

(Pour XenServer uniquement) Étape 3a : Installer le composant XenServer VM Tools

Installez le composant XenServer VM Tools sur la VM modèle pour que chaque VM utilise l’interface de ligne de commande xe ou XenCenter. Les performances de la VM peuvent être lentes à moins que les outils ne soient installés. Sans les outils, vous ne pouvez pas effectuer les opérations suivantes :

Arrêter, redémarrer ou suspendre une VM correctement
Afficher les données de performances de la VM dans XenCenter
Migrer une VM en cours d’exécution (via XenMotion).
Créer des instantanés ou des instantanés avec de la mémoire (points de contrôle) et revenir aux instantanés
Régler le nombre de vCPU sur une VM Linux en cours d’exécution.

Téléchargez le fichier des outils de machine virtuelle XenServer pour Linux depuis la page de téléchargement de XenServer ou la page de téléchargement de Citrix Hypervisor en fonction de la version de l’hyperviseur utilisée.
Copiez le fichier LinuxGuestTools-xxx.tar.gz sur votre machine virtuelle Linux ou sur un lecteur partagé auquel la machine virtuelle Linux peut accéder.
Extrayez le contenu du fichier tar : tar -xzf LinuxGuestTools-xxx.tar.gz

Exécutez la commande suivante pour installer le package xe-guest-utilities en fonction de votre distribution Linux.

Pour RHEL/CentOS/Rocky Linux/SUSE :

sudo rpm -i <extract-directory>/xe-guest-utilities_{package-version}_x86.64.rpm
<!--NeedCopy-->

Pour Ubuntu/Debian :

sudo dpkg -i <extract-directory>/xe-guest-utilities_{package-version}_amd64.deb
<!--NeedCopy-->

Vérifiez l’état de la virtualisation de la VM modèle dans l’onglet General de XenCenter. Si le composant XenServer VM Tools est correctement installé, l’état de la virtualisation est défini sur Optimized.

Étape 3b : vérifier les configurations pour SUSE 15.5 sur AWS, Azure et GCP

Pour SUSE 15.5 sur AWS, Azure et GCP, assurez-vous que :

Vous utilisez libstdc++6 version 12 ou ultérieure.
Le paramètre Default_WM dans /etc/sysconfig/windowmanager est défini sur « gnome ».

Étape 3c : désactiver RDNS pour Ubuntu 20.04 sur GCP

Sur la VM modèle, ajoutez la ligne rdns = false sous [libdefaults] dans /etc/krb5.conf.

Étape 3d : installer .NET et le package Linux VDA sur la VM modèle

Remarque :

Pour utiliser un VDA en cours d’exécution comme VM modèle, ignorez cette étape. Pour utiliser un VDA RHEL 8.x/9.x ou Rocky Linux 8.x/9.x en cours d’exécution connecté au domaine à l’aide de SSSD comme machine virtuelle modèle, assurez-vous que les exigences suivantes sont remplies :

Le VDA est installé manuellement, et non via Easy Install. Easy Install utilise Adcli pour RHEL 8.x/9.x et Rocky Linux 8.x/9.x ; la combinaison de SSSD et Adcli n’est pas prise en charge par MCS.

Un serveur Samba est configuré pour utiliser SSSD pour l’authentification AD. Pour plus d’informations, consultez l’article de Red Hat en accédant à https://access.redhat.com/solutions/3802321.

Avant d’installer le package Linux VDA, installez .NET sur la machine virtuelle modèle et notez ce qui suit :

Outre le runtime .NET, vous devez installer le runtime .ASP.NET Core sur toutes les distributions Linux prises en charge avant d’installer ou de mettre à niveau le Linux VDA. La version 6 est requise pour Amazon Linux 2. La version 8 est requise pour les autres distributions.
Si votre distribution Linux contient la version .NET dont vous avez besoin, installez-la à partir du flux intégré. Sinon, installez .NET à partir du flux de packages Microsoft. Pour plus d’informations, consultez https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

Après avoir installé .NET, exécutez les commandes suivantes en fonction de votre distribution Linux pour installer le Linux VDA :

Pour RHEL/CentOS/Rocky Linux :

Remarque :

Avant d’installer Linux VDA sur RHEL 9.4/9.3/9.2 et Rocky Linux 9.4/9.3/9.2, mettez à jour le package libsepol vers la version 3.4 ou ultérieure.

sudo yum –y localinstall <PATH>/<Linux VDA RPM>
<!--NeedCopy-->

Pour Ubuntu/Debian :

sudo dpkg –i  <PATH>/<Linux VDA DEB>

apt-get install -f
<!--NeedCopy-->

Pour SUSE :

sudo zypper –i install <PATH>/<Linux VDA RPM>
<!--NeedCopy-->

Étape 3e (pour RHEL 7 uniquement) : activer les référentiels pour installer le package tdb-tools

Pour un serveur RHEL 7 :

subscription-manager repos --enable=rhel-7-server-optional-rpms
<!--NeedCopy-->

Pour un poste de travail RHEL 7 :

subscription-manager repos --enable=rhel-7-workstation-optional-rpms
<!--NeedCopy-->

Étape 3f (pour RHEL uniquement) : installer le référentiel EPEL qui peut prendre en charge ntfs-3g

Installez le référentiel EPEL sur RHEL 8. Pour plus d’informations sur l’installation d’EPEL, consultez les instructions de la page https://docs.fedoraproject.org/en-US/epel/.

Étape 3g (Pour SUSE uniquement) : installer manuellement ntfs-3g

Sur la plate-forme SUSE, aucun référentiel ne fournit ntfs-3g. Téléchargez le code source, compilez, puis installez ntfs-3g manuellement :

Installez le système de compilation GCC (GNU Compiler Collection) et le package de création :
```
sudo zypper install gcc
sudo zypper install make

```
Téléchargez le package ntfs-3g.

Décompressez le package ntfs-3g :

sudo tar -xvzf ntfs-3g_ntfsprogs-<package version>.tgz
<!--NeedCopy-->

Entrez le chemin d’accès au package ntfs-3g :

sudo cd ntfs-3g_ntfsprogs-<package version>
<!--NeedCopy-->

Installez ntfs-3g :

./configure
make
make install
<!--NeedCopy-->

Étape 3h : spécifier la base de données à utiliser

Vous pouvez également basculer entre SQLite et PostgreSQL après avoir installé le package Linux VDA. Pour ce faire, procédez comme suit :

Remarque :

Nous vous recommandons d’utiliser SQLite pour le mode VDI uniquement et d’utiliser PostgreSQL pour un modèle de mise à disposition de bureaux partagés hébergés.

Pour Easy Install et MCS, vous pouvez spécifier SQLite ou PostgreSQL sans avoir à les installer manuellement. Sauf indication contraire dans /etc/xdl/db.conf, le Linux VDA utilise PostgreSQL par défaut.

Vous pouvez également utiliser /etc/xdl/db.conf pour configurer le numéro de port de PostgreSQL.

Exécutez /opt/Citrix/VDA/sbin/ctxcleanup.sh. Omettez cette étape s’il s’agit d’une nouvelle installation.
Modifiez /etc/xdl/db.conf avant de lancer deploymcs.sh.

Étape 3i : configurer les variables MCS

Il existe deux manières de configurer les variables MCS :

Modifiez le fichier /etc/xdl/mcs/mcs.conf.
Utilisez l’interface graphique Easy Install. Pour ouvrir l’interface utilisateur graphique Easy Install, exécutez la commande /opt/Citrix/VDA/bin/easyinstall dans l’environnement de bureau de votre Linux VDA.

Conseil :

Cliquez sur Enregistrer pour enregistrer les paramètres des variables dans un fichier local sous le chemin que vous spécifiez. Cliquez sur Charger pour charger les paramètres des variables à partir d’un fichier que vous spécifiez.

Les variables MCS suivantes peuvent être configurées pour des scénarios de non-appartenance à un domaine et d’appartenance à un domaine :

Pour les scénarios de non-appartenance à un domaine

Vous pouvez utiliser les valeurs des variables par défaut ou personnaliser les variables selon vos besoins (facultatif) :

DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime
DESKTOP_ENVIRONMENT=gnome | mate
REGISTER_SERVICE=Y | N
ADD_FIREWALL_RULES=Y | N
VDI_MODE=Y | N
START_SERVICE=Y | N
Pour les scénarios avec appartenance à un domaine
- Use_AD_Configuration_Files_Of_Current_VDA : détermine s’il faut utiliser les fichiers de configuration liés à AD existants (/etc/krb5.conf, /etc/sssd.conf et /etc/samba/smb.conf) du VDA en cours d’exécution. Si la valeur Y est définie, les fichiers de configuration sur les machines créées avec MCS sont les mêmes que ceux sur le VDA en cours d’exécution. Cependant, vous devez toujours configurer les variables dns et AD_INTEGRATION. La valeur par défaut est N, ce qui signifie que les modèles de configuration sur l’image principale déterminent les fichiers de configuration sur les machines créées avec MCS. Pour utiliser un VDA en cours d’exécution comme machine virtuelle modèle, définissez la valeur sur Y. Sinon, définissez-la sur N.
- dns : définit l’adresse IP de chaque serveur DNS. Vous pouvez configurer jusqu’à quatre serveurs DNS.
- NTP_SERVER : définit l’adresse IP de votre serveur NTP. Sauf indication contraire, il s’agit de l’adresse IP de votre contrôleur de domaine.
- WORKGROUP : définit le nom du groupe de travail sur le nom NetBIOS (sensible à la casse) que vous avez configuré dans AD. Sinon, MCS utilise la partie du nom de domaine qui suit immédiatement le nom d’hôte de la machine comme nom de groupe de travail. Par exemple, si le compte de la machine est user1.lvda.citrix.com , MCS utilise lvda comme nom de groupe de travail alors que Citrix est le bon choix. Assurez-vous de définir correctement le nom du groupe de travail.
- AD_INTEGRATION : définit SSSD, Winbind, PBIS ou Centrify. Pour une matrice des distributions Linux et des méthodes de jonction de domaine prises en charge par MSC, consultez la section Distributions prises en charge dans cet article.
- CENTRIFY_DOWNLOAD_PATH : définit le chemin de téléchargement du package Server Suite Free (anciennement Centrify Express). La valeur prend effet uniquement lorsque vous définissez la variable AD_INTEGRATION sur Centrify.
- CENTRIFY_SAMBA_DOWNLOAD_PATH : définit le chemin d’accès au téléchargement du package Centrify Samba. La valeur prend effet uniquement lorsque vous définissez la variable AD_INTEGRATION sur Centrify.
- PBIS_DOWNLOAD_PATH : définit le chemin d’accès au téléchargement du package PBIS. La valeur prend effet uniquement lorsque vous définissez la variable AD_INTEGRATION sur PBIS.
- UPDATE_MACHINE_PW : active ou désactive l’automatisation des mises à jour des mots de passe des comptes de machines. Pour plus d’informations, consultez Automatiser les mises à jour du mot de passe du compte de machine
- Variables de configuration de Linux VDA :
  
  DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime
  DESKTOP_ENVIRONMENT=gnome | mate
  SUPPORT_DDC_AS_CNAME=Y | N
  VDA_PORT=port-number
  REGISTER_SERVICE=Y | N
  ADD_FIREWALL_RULES=Y | N
  HDX_3D_PRO=Y | N
  VDI_MODE=Y | N
  SITE_NAME=dns-site-name | ‘<none>’
  LDAP_LIST=’list-ldap-servers’ | ‘<none>’
  SEARCH_BASE=search-base-set | ‘<none>’
  FAS_LIST=’list-fas-servers’ | ‘<none>’
  START_SERVICE=Y | N
  TELEMETRY_SOCKET_PORT=port-number
  TELEMETRY_PORT=port-number

Étape 3j (facultatif) : écrire ou mettre à jour les valeurs de registre pour MCS

Sur la machine modèle, ajoutez des lignes de commande au fichier /etc/xdl/mcs/mcs_local_setting.reg pour écrire ou mettre à jour les valeurs de registre selon les besoins. Cette action empêche la perte de données et de paramètres chaque fois qu’une machine provisionnée par MCS redémarre.

Chaque ligne du fichier /etc/xdl/mcs/mcs_local_setting.reg est une commande permettant de définir ou de modifier une valeur de registre.

Par exemple, vous pouvez ajouter les lignes de commande suivantes au fichier /etc/xdl/mcs/mcs_local_setting.reg pour écrire ou modifier une valeur de registre respectivement :

create -k "HKLM\System\CurrentControlSet\Control\Citrix\VirtualChannels\Clipboard\ClipboardSelection" -t "REG_DWORD" -v "Flags" -d "0x00000003" --force
<!--NeedCopy-->

update -k "HKLM\System\CurrentControlSet\Control\Citrix\VirtualChannels\Clipboard\ClipboardSelection" -v "Flags" -d "0x00000003"
<!--NeedCopy-->

Remarque

Pour modifier les paramètres MCS, vous êtes autorisé à modifier des fichiers sous /etc/xdl/ad_join et /etc/xdl/mcs/, mais il est interdit de modifier des fichiers sous /var/xdl/mcs.

Étape 3j : créer une image principale

(Pour SSSD + RHEL 8.x/9.x ou Rocky Linux 8.x/9.x uniquement) Exécutez la commande update-crypto-policies --set DEFAULT:AD-SUPPORT, puis redémarrez la machine virtuelle modèle.
Si vous configurez des variables MCS en modifiant /etc/xdl/mcs/mcs.conf, exécutez /opt/Citrix/VDA/sbin/deploymcs.sh. Si vous configurez des variables MCS à l’aide de l’interface graphique, cliquez sur Déployer. Une fois que vous avez cliqué sur Déployer dans l’interface graphique, les variables que vous définissez dans l’interface utilisateur remplacent les variables que vous avez définies dans le fichier /etc/xdl/mcs/mcs.conf.
(Si vous utilisez un VDA en cours d’exécution en tant que VM modèle ou dans les scénarios dans lesquels le domaine n’est pas joint, ignorez cette étape.) Sur la VM modèle, mettez à jour les modèles de configuration pour personnaliser les fichiers /etc/krb5.conf, /etc/samba/smb.conf et /etc/sssd/sssd.conf sur toutes les VM créées.

Pour les utilisateurs Winbind, mettez à jour les modèles /etc/xdl/ad_join/winbind_krb5.conf.tmpl et /etc/xdl/ad_join/winbind_smb.conf.tmpl.

Pour les utilisateurs SSSD, mettez à jour les modèles /etc/xdl/ad_join/sssd.conf.tmpl, /etc/xdl/ad_join/sssd_krb5.conf.tmpl et /etc/xdl/ad_join/sssd_smb.conf.tmpl.

Pour les utilisateurs Centrify, mettez à jour les modèles /etc/xdl/ad_join/centrify_krb5.conf.tmpl et /etc/xdl/ad_join/centrify_smb.conf.tmpl.

Remarque :

Conservez le format existant utilisé dans les fichiers de modèle et utilisez des variables telles que $WORKGROUP, $REALM, $realm, ${new_hostname} et $AD_FQDN.
Créez et nommez un instantané de votre image principale en fonction du cloud public que vous utilisez.
- (Pour XenServer, GCP et VMware vSphere) Installez les applications sur la VM modèle et arrêtez-la. Créez et nommez un instantané de l’image principale.
- (Pour Azure) Installez les applications sur la VM modèle et fermez la VM modèle à partir du portail Azure. Assurez-vous que l’état de l’alimentation de la VM modèle est défini sur Arrêté (libéré). Mémorisez le nom du groupe de ressources. Vous avez besoin du nom pour localiser votre image principale sur Azure.
- (Pour AWS) Installez les applications sur la VM modèle et fermez la VM modèle à partir du portail AWS EC2. Assurez-vous que l’état de l’instance de la VM modèle est défini sur Arrêté. Cliquez avec le bouton droit de la souris sur la VM modèle et sélectionnez Image > Créer une image. Entrez les informations requises et définissez les paramètres nécessaires. Cliquez sur Créer une image.
- (Pour Nutanix) Sur Nutanix AHV, arrêtez la VM modèle. Créez et nommez un instantané de l’image principale.
  
  Remarque :
  
  Les noms des instantanés Acropolis doivent être précédés de XD_ pour pouvoir être utilisés dans Citrix Virtual Apps and Desktops. Utilisez la console Acropolis pour renommer vos instantanés, le cas échéant. Si vous renommez un instantané, redémarrez l’assistant Créer un catalogue pour afficher une liste actualisée.

(Pour GCP) Étape 3l : configurer la connexion Ethernet sur RHEL 8.x/9.x et Rocky Linux 8.x/9.x

Après avoir installé le Linux VDA sur RHEL 8.x/9.x et Rocky Linux 8.x/9.x hébergés sur GCP, la connexion Ethernet peut être perdue et le Linux VDA peut être inaccessible après le redémarrage d’une machine virtuelle. Pour contourner ce problème, définissez un mot de passe racine lorsque vous vous connectez à la VM pour la première fois et assurez-vous que vous pouvez vous connecter à la VM en tant qu’utilisateur racine. Exécutez ensuite les commandes suivantes dans la console après avoir redémarré la VM :

nmcli dev connect eth0
systemctl restart NetworkManager
<!--NeedCopy-->

Étape 4 : créer un catalogue de machines

Dans Citrix Studio où Web Studio, créez un catalogue de machines et spécifiez le nombre de VM à créer dans le catalogue. Lorsque vous créez le catalogue de machines, choisissez votre image principale et tenez compte des points suivants :

Sur la page Conteneur unique à Nutanix, sélectionnez le conteneur que vous avez spécifié précédemment pour la VM modèle.
Lorsque vous créez un catalogue contenant des machines avec OS mono-session, la page Expérience de bureau s’affiche et vous permet de déterminer ce qui se passe chaque fois qu’un utilisateur ouvre une session.

Sur la page Expérience de bureau, sélectionnez l’une des options suivantes :
- Les utilisateurs se connectent à un nouveau bureau (aléatoire) chaque fois qu’ils ouvrent une session
- Les utilisateurs se connectent au même bureau (statique) chaque fois qu’ils ouvrent une session.
Si vous choisissez la première option, les modifications apportées par les utilisateurs au bureau seront annulées (non persistantes).

Si vous choisissez la deuxième option et que vous utilisez MCS pour provisionner les machines, vous pouvez configurer la manière dont les modifications apportées par l’utilisateur au bureau doivent être gérées :
- Enregistrer les modifications apportées par l’utilisateur au bureau sur un disque local (persistantes).
- Supprimer toutes les modifications et effacer le bureau virtuel à la fermeture de session (non-persistantes). Sélectionnez cette option si vous utilisez la couche de personnalisation de l’utilisateur.
Lors de la mise à jour de l’image principale d’un catalogue MCS contenant des machines persistantes, toutes les nouvelles machines ajoutées au catalogue utilisent l’image mise à jour. Les machines préexistantes continuent d’utiliser l’image principale d’origine.

Pour plus d’informations, consultez la section Création d’un catalogue de machines dans la documentation de Citrix Virtual Apps and Desktops et la documentation de Citrix DaaS.

Remarque :

Dans les environnements Nutanix, si le processus de création de votre catalogue de machines sur le Delivery Controller prend beaucoup de temps, accédez à Nutanix Prism et mettez sous tension manuellement la machine dont le nom est précédé du préfixe Preparation. Cette approche permet de poursuivre le processus de création.

Étape 5 : créer un groupe de mise à disposition

Un groupe de mise à disposition est une collection de machines sélectionnées à partir d’un ou de plusieurs catalogues de machines. Il spécifie quels utilisateurs peuvent utiliser ces machines, ainsi que les applications et bureaux disponibles auprès de ces utilisateurs.

Pour plus d’informations, consultez la section Création de groupes de mise à disposition dans la documentation de Citrix Virtual Apps and Desktops et la documentation de Citrix DaaS.

Remarque :

Les machines virtuelles que vous créez à l’aide de MCS peuvent ne pas être enregistrées auprès de Citrix Cloud Connector et leur état peut apparaître comme Non enregistré. Le problème se produit lorsque vous hébergez les machines virtuelles sur Azure et que vous rejoignez le domaine AD avec Samba Winbind. Pour contourner le problème, procédez comme suit :
Accédez à la console ADSI Edit, sélectionnez une machine virtuelle non enregistrée et modifiez l’attribut msDS-SupportedEncryptionTypes de son compte de machine.

Redémarrez les services ctxjproxy et ctxvda sur la machine virtuelle. Si l’état de la machine virtuelle passe à Enregistré, passez aux étapes 3 à 5.

Ouvrez le fichier /var/xdl/mcs/ad_join.sh sur la machine virtuelle modèle.
Ajoutez la ligne net ads enctypes set $NEW_HOSTNAME$ <Decimal value of encryption type attribute, for example, 28> -U $NEW_HOSTNAME$ -P password après les lignes suivantes dans le fichier /var/xdl/mcs/ad_join.sh :
if [ "$AD_INTEGRATION" == "winbind" ]; then
                join_domain_samba
                restart_service winbind /usr/bin/systemctl

Prenez un nouvel instantané et créez des machines virtuelles à l’aide du nouveau modèle.

Utiliser MCS pour effectuer la mise à niveau de votre Linux VDA

Pour utiliser MCS pour la mise à niveau de votre Linux VDA, procédez comme suit :

Vérifiez que vous avez installé le runtime .NET avant de mettre à niveau votre Linux VDA avec la version actuelle.
- Installez le runtime .NET 8.0 sur toutes les distributions Linux prises en charge à l’exception d’Amazon Linux 2.
- Pour Amazon Linux 2, poursuivez l’installation du runtime .NET 6.0.
Si votre distribution Linux contient la version .NET dont vous avez besoin, installez-la à partir du flux intégré. Sinon, installez .NET à partir du flux de packages Microsoft. Pour plus d’informations, consultez https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.
Mettez à niveau votre Linux VDA sur la machine modèle :
Remarque :
- Vous pouvez également utiliser la fonctionnalité Mise à jour automatique de Linux VDA via Azure pour planifier des mises à jour logicielles automatiques. Pour ce faire, ajoutez des lignes de commande au fichier etc/xdl/mcs/mcs_local_setting.reg sur la machine modèle. Par exemple, vous pouvez ajouter les lignes de commande suivantes :
  create -k "HKLM\System\CurrentControlSet\Control\Citrix\SelfUpdate" -t "REG_DWORD" -v "fEnabled" -d "0x00000001" --force create -k "HKLM\System\CurrentControlSet\Control\Citrix\SelfUpdate" -t "REG_SZ" -v "ScheduledTime" -d "Immediately" --force create -k "HKLM\System\CurrentControlSet\Control\Citrix\SelfUpdate" -t "REG_SZ" -v "Url" -d "<Your-Azure-Container-Url>" –force create -k "HKLM\System\CurrentControlSet\Control\Citrix\SelfUpdate" -t "REG_SZ" -v "CaCertificate" -d "<Local-Certificate-Path-of-PortalAzureCom>" --force 
- À compter de la version 2407, le Linux VDA délègue les gestionnaires de packages rpm ou dpkg pour gérer les fichiers de configuration lors des mises à niveau. Voici comment rpm et dpkg interagissent avec les modifications apportées aux fichiers de configuration :
  - rpm : conserve par défaut la version locale et enregistre la nouvelle version depuis le package avec une extension .rpmnew.
  - dpkg : vous invite de manière interactive à choisir la marche à suivre. Pour mettre à niveau silencieusement le Linux VDA tout en conservant votre fichier de configuration local et en enregistrant la nouvelle version du package sous le nom .dpkg-new ou.dpkg-dist, utilisez la commande suivante :
    dpkg --force-confold -i package.deb # Always keep your version, then save new package's version as *.dpkg-new or *.dpkg-dist 
Pour les distributions RHEL et Rocky Linux :
```
sudo yum -y localinstall <PATH>/<Linux VDA RPM>

```
Remarque :

Avant de mettre à niveau Linux VDA sur RHEL 9.4/9.3/9.2 et Rocky Linux 9.4/9.3/9.2, mettez à jour le package libsepol vers la version 3.4 ou ultérieure.

Pour les distributions SUSE :
```
sudo zypper -i install <PATH>/<Linux VDA RPM>

```
Pour les distributions Ubuntu/Debian :
```
sudo dpkg -i <PATH>/<Linux VDA deb>

sudo apt-get install -f

```
Modifiez /etc/xdl/mcs/mcs.conf et /etc/xdl/mcs/mcs_local_setting.reg.
Prenez un nouvel instantané.
Dans Citrix Studio, sélectionnez le nouvel instantané pour la mise à jour de votre catalogue de machines. Attendez avant que chaque machine redémarre. Ne redémarrez pas une machine manuellement.

Automatiser les mises à jour du mot de passe du compte de machine

Par défaut, les mots de passe du compte de machine expirent 30 jours après la création du catalogue de machines. Pour empêcher l’expiration du mot de passe et automatiser les mises à jour du mot de passe du compte de machine, procédez comme suit :

Ajoutez l’entrée suivante dans /etc/xdl/mcs/mcs.conf avant d’exécuter /opt/Citrix/VDA/sbin/deployymcs.sh.

UPDATE_MACHINE_PW="Y"
Après avoir exécuté /opt/Citrix/VDA/sbin/deployymcs.sh, ouvrez /etc/cron.d/mcs_update_password_cronjob pour définir l’heure et la fréquence de mise à jour. Le paramètre par défaut met à jour les mots de passe du compte de machine chaque semaine à 2 h 30, le dimanche.

Après chaque mise à jour du mot de passe du compte de machine, le cache des tickets sur le Delivery Controller n’est plus valide et l’erreur suivante peut apparaître dans /var/log/xdl/jproxy.log :

[ERROR] - AgentKerberosServiceAction.Run: GSSException occurred. Error: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

Pour éliminer l’erreur, videz le cache des tickets régulièrement. Vous pouvez planifier une tâche de nettoyage du cache sur tous les Delivery Controller ou sur le contrôleur de domaine.

Activer FAS sur les VM créées par MCS

Vous pouvez activer FAS sur les VM créées par MCS qui s’exécutent sur les distributions suivantes :

	Winbind	SSSD	Centrify	PBIS
RHEL 9.4/9.3/9.2	Oui	Non	Non	Non
RHEL 8.x	Oui	Non	Non	Oui
Rocky Linux 9.4/9.3/9.2	Oui	Non	Non	Non
Rocky Linux 8.x	Oui	Non	Non	Non
Ubuntu 22.04, Ubuntu 20.04	Oui	Non	Non	Non
Debian 12.5/11.9	Oui	Oui	Non	Oui
SUSE 15.5	Oui	Non	Non	Non

Activer FAS lorsque vous préparez une image principale sur la VM modèle

Importez le certificat d’autorité de certification racine.
```
sudo cp root.pem /etc/pki/CA/certs/

```
Exécutez le script d’installation facile (ctxinstall.sh) et assurez-vous que la VM modèle est correctement associée à un domaine.
Exécutez ctxfascfg.sh.
Définissez les variables dans /etc/xdl/mcs/mcs.conf.

Remarque :

Définissez toutes les variables nécessaires dans /etc/xdl/mcs/mcs.conf, car elles sont appelées au démarrage de la VM.
1. Définissez la valeur de Use_AD_Configuration_Files_Of_Current_VDA sur Y.
2. Définissez les autres variables selon vos besoins, par exemple VDI_MODE.

Ajoutez la ligne de commande suivante au fichier /etc/xdl/mcs/mcs_local_setting.reg pour définir les adresses de vos serveurs FAS :

sudo /opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent\Authentication\UserCredentialService" -t "REG_SZ" -v "Addresses" -d "<Your-FAS-Server-List>" --force
<!--NeedCopy-->

Exécutez le script /opt/Citrix/VDA/sbin/deploymcs.sh.

Activer FAS sur une VM créée par MCS

Si FAS n’est pas activé sur la machine modèle comme décrit précédemment, vous pouvez activer FAS sur chaque machine virtuelle créée par MCS.

Pour activer FAS sur une machine virtuelle créée par MCS, procédez comme suit :

Définissez les variables dans /etc/xdl/mcs/mcs.conf.

Remarque :

Définissez toutes les variables nécessaires dans /etc/xdl/mcs/mcs.conf, car elles sont appelées au démarrage de la VM.
1. Définissez la valeur de Use_AD_Configuration_Files_Of_Current_VDA sur Y.
2. Définissez les autres variables selon vos besoins, par exemple VDI_MODE.

Ajoutez la ligne de commande suivante au fichier /etc/xdl/mcs/mcs_local_setting.reg pour définir les adresses de vos serveurs FAS :

sudo /opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent\Authentication\UserCredentialService" -t "REG_SZ" -v "Addresses" -d "<Your-FAS-Server-List>" --force
<!--NeedCopy-->

Importez le certificat d’autorité de certification racine.
```
sudo cp root.pem /etc/pki/CA/certs/

```
Exécutez le script /opt/Citrix/VDA/sbin/ctxfascfg.sh.

La version officielle de ce document est en anglais. Certains contenus de la documentation Cloud Software Group ont été traduits de façon automatique à des fins pratiques uniquement. Cloud Software Group n'exerce aucun contrôle sur le contenu traduit de façon automatique, qui peut contenir des erreurs, des imprécisions ou un langage inapproprié. Aucune garantie, explicite ou implicite, n'est fournie quant à l'exactitude, la fiabilité, la pertinence ou la justesse de toute traduction effectuée depuis l'anglais d'origine vers une autre langue, ou quant à la conformité de votre produit ou service Cloud Software Group à tout contenu traduit de façon automatique, et toute garantie fournie en vertu du contrat de licence de l'utilisateur final ou des conditions d'utilisation des services applicables, ou de tout autre accord avec Cloud Software Group, quant à la conformité du produit ou service à toute documentation ne s'applique pas dans la mesure où cette documentation a été traduite de façon automatique. Cloud Software Group ne pourra être tenu responsable de tout dommage ou problème dû à l'utilisation de contenu traduit de façon automatique.

Cela vous a-t-il été utile ?

Créer des VDA Linux à l’aide de Machine Creation Services (MCS)

August 21, 2024

Contributeur:

C C

August 21, 2024

Contributeur:

C C

Dans cet article

Distributions prises en charge
Hyperviseurs pris en charge
Utiliser MCS pour créer des machines virtuelles Linux
Utiliser MCS pour effectuer la mise à niveau de votre Linux VDA
Automatiser les mises à jour du mot de passe du compte de machine
Activer FAS sur les VM créées par MCS
- Activer FAS lorsque vous préparez une image principale sur la VM modèle
- Activer FAS sur une VM créée par MCS

Cela vous a-t-il été utile ?