Créer des VDA Linux à l’aide de Machine Creation Services™ (MCS)
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 :
Voici les modifications importantes à partir de la version 2212 :
- La variable AD_INTEGRATION dans le fichier /etc/xdl/mcs/mcs.conf ou dans l’interface graphique d’installation facile 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 3i : Configurer les variables MCS de cet article.
- La valeur valide de l’entrée UPDATE_MACHINE_PW dans /etc/xdl/mcs/mcs.conf n’est plus enabled ou disabled, mais Y ou N. Pour plus d’informations, consultez la section Automatiser les mises à jour des mots de passe des comptes machine de cet article.
Distributions prises en charge
| Winbind | SSSD | Centrify | PBIS | |
|---|---|---|---|---|
| Debian 12.7/12.5/11.11 | Oui | Oui | Non | Oui |
| RHEL 9.4/9.2 | Oui | Oui | Oui | Non |
| RHEL 8.10/8.8 | Oui | Oui | Oui | Oui |
| Rocky Linux 9.4/9.2 | Oui | Oui | Oui | Non |
-
Rocky Linux 8.10/8.8 Oui Oui Oui Non SUSE 15.6 Oui Oui Non Oui Ubuntu 24.04 Oui Oui Non Oui Ubuntu 22.04/20.04 Oui Oui Non Oui -
Citrix® utilise les versions de Centrify suivantes pour la validation initiale des fonctionnalités sur les distributions Linux pertinentes :
-
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 entraîner des erreurs. N’utilisez pas Centrify pour joindre une machine modèle à un domaine.
-
Si vous utilisez PBIS ou Centrify pour joindre des machines créées par 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.confou installez le package PBIS ou Centrify directement. - Avant d’exécuter
/opt/Citrix/VDA/sbin/deploymcs.sh, créez une unité d’organisation (OU) qui dispose des autorisations d’écriture et de réinitialisation de mot de passe pour toutes ses machines subordonnées créées par MCS.
-
Avant de redémarrer les machines créées par MCS après l’exécution de
/opt/Citrix/VDA/sbin/deploymcs.sh, exécutezklist -li 0x3e4 purgesur 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 qui est connecté au domaine à l’aide de SSSD en tant que VM modèle pour MCS, assurez-vous que :
- Le VDA est installé manuellement et non à l’aide de l’installation facile. L’installation facile utilise Adcli pour RHEL 8.x/9.x et Rocky Linux 8.x/9.x, et MCS ne prend pas en charge la combinaison de SSSD et Adcli.
- Un serveur Samba est configuré pour utiliser SSSD pour l’authentification AD. Pour plus d’informations, consultez l’article de Red Hat à l’adresse 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 tentez de préparer une image principale sur des hyperviseurs autres que ceux pris en charge.
Utiliser MCS pour créer des VM Linux
Considérations
-
À partir de la version 2203, vous pouvez héberger le VDA Linux sur Microsoft Azure, AWS et GCP pour Citrix Virtual Apps and Desktops™ ainsi que Citrix DaaS (anciennement service Citrix Virtual Apps and Desktops). Pour ajouter ces connexions d’hôte de 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 pour une utilisation avec MCS afin de créer des machines virtuelles.
-
(Pour Nutanix uniquement) Étape 1 : Installer et enregistrer le plug-in Nutanix AHV
-
Obtenez le package du plug-in Nutanix AHV auprès de Nutanix. Installez et enregistrez le plug-in dans votre environnement Citrix Virtual Apps and Desktops. Pour plus d’informations, consultez le guide d’installation du plug-in Nutanix Acropolis MCS, disponible sur le portail de support Nutanix.
-
Étape 1a : Installer et enregistrer le plug-in Nutanix AHV pour les Delivery Controllers sur site
Après avoir installé Citrix Virtual Apps™ and Desktops, sélectionnez et installez le plug-in XD MCS AHV sur vos Delivery Controllers.
Étape 1b : Installer et enregistrer le plug-in Nutanix AHV pour les Delivery Controllers cloud
Sélectionnez et installez le plug-in CWA MCS AHV pour les Citrix Cloud™ Connectors. Installez le plug-in sur tous les Citrix Cloud Connectors enregistrés auprès du locataire Citrix Cloud. Vous devez enregistrer les Citrix Cloud Connectors même s’ils desservent un emplacement de ressources sans l’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 les services Citrix Host, Citrix Broker et Citrix Machine Creation Services sur vos Delivery Controllers sur site ou redémarrez le service Citrix RemoteHCLServer sur les Citrix Cloud Connectors.
Conseil :
Nous vous recommandons d’arrêter puis de redémarrer les services 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 d’hôte
Cette section fournit des exemples sur la façon de créer une connexion d’hôte à Azure, AWS, XenServer® (anciennement Citrix Hypervisor), GCP, Nutanix AHV et VMware vSphere.
Remarque :
Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’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 d’hôte à Azure dans Citrix Studio
-
Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’hôte.
-
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez Microsoft Azure comme type de connexion.
-
Sélectionnez Microsoft Azure comme type de connexion.
-
- L’assistant vous guide à travers les pages. Le contenu spécifique de la page dépend du type de connexion sélectionné. Après avoir terminé chaque page, sélectionnez Suivant jusqu’à ce que vous atteigniez la page Résumé. Pour plus d’informations, consultez l’Étape 2 : Créer une connexion d’hôte dans l’article Créer des VDA Linux non joints à un domaine à l’aide de MCS.
-
Créer une connexion d’hôte à AWS dans Citrix Studio
-
- Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’hôte.
-
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez Amazon EC2 comme type de connexion.
Par exemple, dans Citrix Studio sur site :
-
Saisissez la clé API et la clé secrète de votre compte AWS, puis saisissez le nom de votre connexion.
La clé API est votre ID de clé d’accès et la clé secrète est 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 supprimer la clé d’accès et en créer une autre. Pour créer une clé d’accès, procédez comme suit :
- Connectez-vous aux services AWS.
- Accédez à la console Identity and Access Management (IAM).
-
- Dans le volet de navigation de gauche, choisissez Utilisateurs.
-
- Sélectionnez l’utilisateur cible et faites défiler vers le bas pour sélectionner l’onglet Informations d’identification de sécurité.
- Faites défiler vers le bas et cliquez sur Créer une clé d’accès. Une nouvelle fenêtre apparaît.
- Cliquez sur Télécharger le fichier .csv et enregistrez la clé d’accès dans un emplacement sécurisé.
- L’assistant vous guide à travers les pages. Le contenu spécifique de la page dépend du type de connexion sélectionné. Après avoir terminé chaque page, sélectionnez Suivant jusqu’à ce que vous atteigniez la page Résumé.
Créer une connexion d’hôte à XenServer dans Citrix Studio
-
Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’hôte.
-
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez XenServer (anciennement Citrix Hypervisor) dans le champ Type de connexion.
-
- Saisissez l’adresse de connexion (l’URL XenServer) et les informations d’identification.
- Saisissez un nom de connexion.
Créer une connexion d’hôte à GCP dans Citrix Studio
Configurez votre environnement GCP conformément aux environnements de virtualisation Google Cloud Platform, puis suivez les étapes ci-dessous pour créer une connexion d’hôte à GCP.
-
Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’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 basée sur le Web sur Citrix Cloud :
-
Importez la clé de compte de service de votre compte GCP et saisissez le nom de votre connexion.
-
L’assistant vous guide à travers les pages. Le contenu spécifique de la page dépend du type de connexion sélectionné. Après avoir terminé chaque page, sélectionnez Suivant jusqu’à atteindre la page Résumé. Pour plus d’informations, consultez l’Étape 2 : Créer une connexion d’hôte dans l’article Créer des VDA Linux non joints à un domaine à l’aide de MCS.
Créer une connexion d’hôte à Nutanix dans Citrix Studio
-
Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’hôte.
-
Dans l’assistant Ajouter une connexion et des ressources, sélectionnez Nutanix AHV comme type de connexion sur la page Connexion, puis spécifiez l’adresse de l’hyperviseur, les informations d’identification et le nom de votre connexion. Sur la page Réseau, sélectionnez un réseau pour l’unité.
Par exemple, dans Citrix Studio sur site :
Créer une connexion d’hôte à VMware dans Citrix Studio
-
Installez vCenter Server dans l’environnement vSphere. Pour plus d’informations, consultez VMware vSphere.
-
Pour les Delivery Controllers sur site, choisissez Configuration > Hébergement > Ajouter une connexion et des ressources dans Citrix Studio sur site pour créer une connexion d’hôte. Pour les Delivery Controllers cloud, choisissez Gérer > Hébergement > Ajouter une connexion et des ressources dans la console Studio basée sur le Web sur Citrix Cloud pour créer une connexion d’hôte.
-
Choisissez VMware vSphere comme type de connexion.
Par exemple, dans Citrix Studio sur site :
-
Saisissez l’adresse de connexion (l’URL du serveur vCenter) de votre compte VMware, vos informations d’identification et le nom de votre connexion.
Étape 3 : Préparer une image principale
(Pour XenServer uniquement) Étape 3a : Installer les outils de machine virtuelle XenServer
Installez les outils de machine virtuelle XenServer sur la machine virtuelle de modèle pour que chaque machine virtuelle puisse utiliser l’interface de ligne de commande xe ou XenCenter. Les performances de la machine virtuelle peuvent être lentes si vous n’installez pas les outils. Sans les outils, vous ne pouvez effectuer aucune des opérations suivantes :
- Arrêter, redémarrer ou suspendre proprement une machine virtuelle.
- Afficher les données de performance de la machine virtuelle dans XenCenter.
- Migrer une machine virtuelle en cours d’exécution (via
XenMotion). - Créer des instantanés ou des instantanés avec mémoire (points de contrôle), et revenir à des instantanés.
- Ajuster le nombre de vCPU sur une machine virtuelle Linux en cours d’exécution.
-
Téléchargez le fichier XenServer VM Tools for Linux depuis la page de téléchargements XenServer ou la page de téléchargements Citrix Hypervisor en fonction de la version de l’hyperviseur utilisée.
-
Copiez le fichier
LinuxGuestTools-xxx.tar.gzsur 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-utilitiesen 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 virtualisation de la machine virtuelle de modèle sous l’onglet Général dans XenCenter. Si les outils de machine virtuelle XenServer sont installés correctement, l’état de virtualisation affiche Optimisé.
Étape 3b : Vérifier les configurations pour SUSE 15.6 sur AWS, Azure et GCP
Pour SUSE 15.6 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 machine virtuelle de modèle, ajoutez la ligne rdns = false sous [libdefaults] dans /etc/krb5.conf.
Remarque :
Pour utiliser un VDA en cours d’exécution comme machine virtuelle de 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 qui est connecté au domaine à l’aide de SSSD comme machine virtuelle de modèle, assurez-vous que :
Le VDA est installé manuellement et non à l’aide de l’installation facile. L’installation facile utilise Adcli pour RHEL 8.x/9.x et Rocky Linux 8.x/9.x, et 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 Red Hat à l’adresse https://access.redhat.com/solutions/3802321.
- Avant d’installer le package Linux VDA, installez .NET sur la machine virtuelle de modèle et notez les points suivants :
-
En plus du .NET Runtime, vous devez installer .ASP.NET Core Runtime 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 de .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/fr-fr/dotnet/core/install/linux-package-managers.
Étape 3e : Installer le package Linux VDA sur la machine virtuelle de modèle
- 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 le Linux VDA sur RHEL 9.4/9.2 et Rocky Linux 9.4/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 3f : (Pour RHEL uniquement) Installer le référentiel EPEL qui peut offrir ntfs-3g
Installez le référentiel EPEL sur RHEL 8. Pour plus d’informations sur l’installation d’EPEL, consultez les instructions à l’adresse https://docs.fedoraproject.org/fr-FR/epel/.
Étape 3g : (Pour SUSE uniquement) Installer manuellement ntfs-3g
Sur la plateforme SUSE, aucun référentiel ne fournit ntfs-3g. Téléchargez le code source, compilez et installez ntfs-3g manuellement :
-
Installez le système de compilation GNU Compiler Collection (GCC) et le package make :
sudo zypper install gcc sudo zypper install make <!--NeedCopy-->-
- 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 une base de données à utiliser
- Vous pouvez basculer entre SQLite et PostgreSQL après l'installation du package Linux VDA. Pour ce faire, suivez les étapes ci-dessous :
- > **Remarque :** > > - Nous vous recommandons d'utiliser SQLite uniquement pour le mode VDI et PostgreSQL pour un modèle de livraison de bureaux partagés hébergés. > - Pour une installation facile et MCS, vous pouvez spécifier SQLite ou PostgreSQL à utiliser sans avoir à les installer manuellement. Sauf indication contraire via **/etc/xdl/db.conf**, le Linux VDA utilise PostgreSQL par défaut. Si vous avez besoin d'une version personnalisée de PostgreSQL au lieu de la version fournie par votre distribution Linux, vous devez installer la version spécifiée manuellement, modifier `/etc/xdl/db.conf` pour refléter la nouvelle version et démarrer le service PostgreSQL avant d'exécuter le script d'installation facile (`ctxinstall.sh`) ou le script MCS (`deploymcs.sh`). > - 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.confavant d’exécuterdeploymcs.sh. Voici un exemple de fichier db.conf :# database configuration file for Linux VDA ## database choice # possible choices are: # SQLite # PostgreSQL # default choice is PostgreSQL DbType="PostgreSQL" ## database port # specify database port for the database. # if not specified, default port will be used: # SQLite: N/A # PostgreSQL: 5432 DbPort=5432 - ## PostgreSQL customized - # only the following value means true, otherwise false: # true # yes # y # YES # Y # default is false DbCustomizePostgreSQL=false ## PostgreSQL service name # specify the service name of PostgreSQL for Linux VDA # default is "postgresql" DbPostgreSQLServiceName="postgresql" <!--NeedCopy-->Pour utiliser une version personnalisée de PostgreSQL, définissez DbCustomizePostgreSQL sur true.
Étape 3i : Configurer les variables MCS
Il existe deux façons de configurer les variables MCS :
- Modifiez le fichier `/etc/xdl/mcs/mcs.conf`.
- Utilisez l'interface graphique d'installation facile. Pour ouvrir l'interface graphique d'installation facile, 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.
Voici les variables MCS que vous pouvez configurer pour les scénarios non joints à un domaine et joints à un domaine :
- **Pour les scénarios non joints à un domaine**
Vous pouvez utiliser les valeurs de variable par défaut ou personnaliser les variables selon vos besoins (facultatif) :
`DOTNET_RUNTIME_PATH`=chemin-vers-installation-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 joints à un domaine**
- `Use_AD_Configuration_Files_Of_Current_VDA` : Détermine s'il faut utiliser les fichiers de configuration existants liés à AD (/etc/krb5.conf, /etc/sssd.conf et /etc/samba/smb.conf) du VDA en cours d'exécution. Si la valeur est Y, les fichiers de configuration sur les machines créées par MCS sont identiques à ceux du 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 de l'image principale déterminent les fichiers de configuration sur les machines créées par MCS. Pour utiliser un VDA en cours d'exécution comme VM de 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 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 MCS, consultez [Distributions prises en charge](#supported-distributions) 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 de 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 de 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 du mot de passe du compte machine. Pour plus d'informations, consultez [Automatiser les mises à jour du mot de passe du compte machine](/en-us/linux-virtual-delivery-agent/2411/installation-overview/use-mcs-to-create-linux-vms.html#automate-machine-account-password-updates).
- Variables de configuration du Linux VDA :
`DOTNET_RUNTIME_PATH`=chemin-vers-installation-dotnet-runtime
`DESKTOP_ENVIRONMENT`=gnome | mate
`SUPPORT_DDC_AS_CNAME`=Y | N
`VDA_PORT`=numéro-de-port
`REGISTER_SERVICE`=Y | N
`ADD_FIREWALL_RULES`=Y | N
`HDX_3D_PRO`=Y | N
`VDI_MODE`=Y | N
`SITE_NAME`=nom-de-site-dns | '<none\>'
`LDAP_LIST`='liste-serveurs-ldap' | '<none\>'
`SEARCH_BASE`=ensemble-base-de-recherche | '<none\>'
`FAS_LIST`='liste-serveurs-fas' | '<none\>'
`START_SERVICE`=Y | N
`TELEMETRY_SOCKET_PORT`=numéro-de-port
`TELEMETRY_PORT`=numéro-de-port
(Facultatif) Étape 3j : É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 redémarrage d’une machine provisionnée par MCS.
Chaque ligne du fichier /etc/xdl/mcs/mcs_local_setting.reg est une commande pour définir ou mettre à jour 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 mettre à jour 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 de MCS, vous êtes autorisé à modifier les fichiers sous /etc/xdl/ad_join et /etc/xdl/mcs/, mais la modification de tout fichier sous /var/xdl/mcs est interdite.
Étape 3k : Créer une image maître
- (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 VM de modèle. -
Si vous configurez les variables MCS en modifiant
/etc/xdl/mcs/mcs.conf, exécutez/opt/Citrix/VDA/sbin/deploymcs.sh. Si vous configurez les variables MCS à l’aide de l’interface graphique, cliquez sur Déployer. Après avoir cliqué sur Déployer dans l’interface graphique, les variables que vous avez définies dans l’interface graphique remplacent les variables que vous avez définies dans le fichier/etc/xdl/mcs/mcs.conf. -
(Si vous utilisez une VM VDA en cours d’exécution comme VM de modèle ou s’il s’agit d’un scénario sans jonction de domaine, ignorez cette étape.) Sur la VM de modèle, mettez à jour les modèles de configuration pour personnaliser les fichiers
/etc/krb5.conf,/etc/samba/smb.confet/etc/sssd/sssd.confpertinents sur toutes les VM créées.Pour les utilisateurs de Winbind, mettez à jour les modèles
/etc/xdl/ad_join/winbind_krb5.conf.tmplet/etc/xdl/ad_join/winbind_smb.conf.tmpl.Pour les utilisateurs de SSSD, mettez à jour les modèles
/etc/xdl/ad_join/sssd.conf.tmpl,/etc/xdl/ad_join/sssd_krb5.conf.tmplet/etc/xdl/ad_join/sssd_smb.conf.tmpl.Pour les utilisateurs de Centrify, mettez à jour les modèles
/etc/xdl/ad_join/centrify_krb5.conf.tmplet/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 maître en fonction du cloud public que vous utilisez.
-
(Pour XenServer, GCP et VMware vSphere) Installez les applications sur la VM de modèle et arrêtez la VM de modèle. Créez et nommez un instantané de votre image maître.
-
(Pour Azure) Installez les applications sur la VM de modèle et arrêtez la VM de modèle depuis le portail Azure. Assurez-vous que l’état d’alimentation de la VM de modèle est Arrêté (désalloué). Retenez le nom du groupe de ressources ici. Vous avez besoin du nom pour localiser votre image maître sur Azure.
-
(Pour AWS) Installez les applications sur la VM de modèle et arrêtez la VM de modèle depuis le portail AWS EC2. Assurez-vous que l’état de l’instance de la VM de modèle est Arrêté. Cliquez avec le bouton droit sur la VM de modèle et sélectionnez Image > Créer une image. Saisissez les informations et effectuez les réglages nécessaires. Cliquez sur Créer une image.
-
(Pour Nutanix) Sur Nutanix AHV, arrêtez la VM de modèle. Créez et nommez un instantané de votre image maître.
Remarque :
Vous devez préfixer les noms d’instantanés Acropolis avec
XD_pour une utilisation dans Citrix Virtual Apps and Desktops. Utilisez la console Acropolis pour renommer vos instantanés si nécessaire. Après avoir renommé un instantané, redémarrez l’assistant Créer un catalogue pour obtenir 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 VDA Linux sur RHEL 8.x/9.x et Rocky Linux 8.x/9.x hébergé sur GCP, la connexion Ethernet peut être perdue et le VDA Linux peut être inaccessible après un redémarrage de la VM. Pour contourner le problème, définissez un mot de passe root lors de la première connexion à la VM et assurez-vous de pouvoir vous connecter à la VM en tant que root. Ensuite, exécutez les commandes suivantes dans la console après le redémarrage de la VM :
nmcli dev connect eth0
systemctl restart NetworkManager
<!--NeedCopy-->
Étape 4 : Créer un catalogue de machines
Dans Citrix Studio ou Web Studio, créez un catalogue de machines et spécifiez le nombre de VM à créer dans le catalogue. Lors de la création du catalogue de machines, choisissez votre image maître et prenez en compte les éléments suivants :
-
Sur la page Conteneur, qui est propre à Nutanix, sélectionnez le conteneur que vous avez spécifié précédemment pour la VM de modèle.
-
Lorsque vous créez un catalogue contenant des machines OS à session unique, la page Expérience de bureau apparaît et vous permet de déterminer ce qui se passe chaque fois qu’un utilisateur se connecte.
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 se connectent.
- Les utilisateurs se connectent au même bureau (statique) chaque fois qu’ils se connectent.
Si vous choisissez la première option, les modifications apportées par les utilisateurs au bureau seront ignoré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 de l’utilisateur apportées au bureau sont gérées :
- Enregistrer les modifications de l’utilisateur sur le disque local (persistant).
- Ignorer les modifications de l’utilisateur et effacer le bureau virtuel lorsque l’utilisateur se déconnecte (non persistant). Sélectionnez cette option si vous utilisez la couche de personnalisation de l’utilisateur.
-
Lors de la mise à jour de l’image maître pour 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 maître d’origine.
Pour plus d’informations, consultez la création de catalogues de machines dans la documentation Citrix Virtual Apps and Desktops et la documentation Citrix DaaS.
Remarque :
Pour les environnements Nutanix, si le processus de création de votre catalogue de machines sur le Delivery Controller™ prend un temps considérable, accédez à Nutanix Prism et mettez manuellement sous tension la machine préfixée par 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 plusieurs catalogues de machines. Il spécifie les utilisateurs qui peuvent utiliser ces machines, ainsi que les applications et les bureaux disponibles pour ces utilisateurs.
Pour plus d’informations, consultez la création de groupes de mise à disposition dans la documentation Citrix Virtual Apps and Desktops et la documentation Citrix DaaS.
Remarque :
Les machines virtuelles que vous créez à l’aide de MCS peuvent ne pas pouvoir s’enregistrer auprès des Citrix Cloud Connectors et s’afficher comme Non enregistrées. Le problème survient lorsque vous hébergez les machines virtuelles sur Azure et que vous les joignez au domaine AD avec Samba Winbind. Pour contourner le problème, suivez les étapes ci-dessous :
- Accédez à la console ADSI Edit, sélectionnez une machine virtuelle non enregistrée et modifiez l’attribut msDS-SupportedEncryptionTypes de son compte machine.
- Redémarrez les services ctxjproxy et ctxvda sur la machine virtuelle. Si l’état de la machine virtuelle passe à Enregistrée, passez aux étapes 3 à 5.
- Ouvrez le fichier /var/xdl/mcs/ad_join.sh sur la machine virtuelle de modèle.
Ajoutez une ligne de 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 <!--NeedCopy-->- Prenez un nouvel instantané et créez des machines virtuelles à l’aide du nouveau modèle.
Utiliser MCS pour mettre à niveau votre VDA Linux
Pour utiliser MCS afin de mettre à niveau votre VDA Linux, procédez comme suit :
-
Assurez-vous d’avoir installé .NET avant de mettre à niveau votre VDA Linux vers la version actuelle.
- Installez .NET Runtime 8.0 sur toutes les distributions Linux prises en charge, à l’exception d’Amazon Linux 2.
- Pour Amazon Linux 2, continuez à installer .NET Runtime 6.0.
Si votre distribution Linux contient la version de .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/fr-fr/dotnet/core/install/linux-package-managers.
-
Mettez à niveau votre VDA Linux sur la machine de modèle :
Remarque :
-
Vous pouvez également utiliser la fonctionnalité Mise à jour automatique du VDA Linux 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 de 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 <!--NeedCopy--> -
À partir de la version 2407, le VDA Linux délègue aux gestionnaires de packages rpm ou dpkg la gestion des 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 du package avec une extension .rpmnew.
-
dpkg : vous invite de manière interactive à choisir la marche à suivre. Pour mettre à niveau silencieusement le VDA Linux tout en conservant votre fichier de configuration local et en enregistrant la nouvelle version du package sous .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 <!--NeedCopy-->
-
Pour les distributions RHEL et Rocky Linux :
sudo yum -y localinstall <PATH>/<Linux VDA RPM> <!--NeedCopy-->Remarque :
Avant de mettre à niveau le VDA Linux sur RHEL 9.4/9.2 et Rocky Linux 9.4/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> <!--NeedCopy-->Pour les distributions Ubuntu/Debian :
sudo dpkg -i <PATH>/<Linux VDA deb> sudo apt-get install -f <!--NeedCopy--> -
-
Modifiez
/etc/xdl/mcs/mcs.confet/etc/xdl/mcs/mcs_local_setting.reg. -
Prenez un nouvel instantané.
-
Dans Citrix Studio, sélectionnez le nouvel instantané pour mettre à jour votre catalogue de machines. Attendez que chaque machine redémarre. Ne redémarrez pas une machine manuellement.
Automatiser les mises à jour des mots de passe des comptes machine
Les mots de passe des comptes machine expirent, par défaut, 30 jours après la création du catalogue de machines. Pour éviter l’expiration des mots de passe et automatiser les mises à jour des mots de passe des comptes machine, procédez comme suit :
-
Ajoutez l’entrée suivante à /etc/xdl/mcs/mcs.conf avant d’exécuter /opt/Citrix/VDA/sbin/deploymcs.sh.
UPDATE_MACHINE_PW="Y" -
Après avoir exécuté /opt/Citrix/VDA/sbin/deploymcs.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 des comptes machine chaque semaine le dimanche à 2h30 du matin.
Après chaque mise à jour du mot de passe du compte machine, le cache de tickets sur le Delivery Controller devient invalide 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 régulièrement le cache de tickets. Vous pouvez planifier une tâche de nettoyage du cache sur tous les Delivery Controllers ou sur le contrôleur de domaine.