Documentation produit
Linux Virtual Delivery Agent
Current Release 2402 LTSR 2311 2308 2305 2303 2301 2212 2210 2209 2207 2206 2204 2203 LTSR 1912 LTSR 7.15 LTSR
Voir PDF

Installer le VDA Linux sur Amazon Linux 2, CentOS, RHEL et Rocky Linux manuellement

May 5, 2026
Contributeur: 
C C

Important :

Pour les nouvelles installations, nous vous recommandons d’utiliser l’installation facile pour une installation rapide. L’installation facile permet d’économiser du temps et du travail, et est moins sujette aux erreurs que l’installation manuelle détaillée dans cet article.

Étape 1 : Préparer les informations de configuration et la machine Linux

Étape 1a : Vérifier la configuration réseau

Assurez-vous que le réseau est connecté et configuré correctement. Par exemple, vous devez configurer le serveur DNS sur le VDA Linux.

Étape 1b : Définir le nom d’hôte

Pour vous assurer que le nom d’hôte de la machine est correctement signalé, modifiez le fichier /etc/hostname pour qu’il ne contienne que le nom d’hôte de la machine.

hostname

Étape 1c : Attribuer une adresse de bouclage au nom d’hôte

Pour vous assurer que le nom de domaine DNS et le nom de domaine complet (FQDN) de la machine sont correctement signalés, modifiez la ligne suivante du fichier /etc/hosts pour inclure le FQDN et le nom d’hôte comme les deux premières entrées :

127.0.0.1 hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4

Par exemple :

127.0.0.1 vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4

Supprimez toute autre référence à hostname-fqdn ou hostname des autres entrées du fichier.

Remarque :

Le VDA Linux ne prend actuellement pas en charge la troncation des noms NetBIOS. Le nom d’hôte ne doit pas dépasser 15 caractères.

Conseil :

Utilisez uniquement les caractères a–z, A–Z, 0–9 et le trait d’union (-). Évitez les traits de soulignement (_), les espaces et les autres symboles. Ne commencez pas un nom d’hôte par un chiffre et ne le terminez pas par un trait d’union. Cette règle s’applique également aux noms d’hôte du Delivery Controller.

Étape 1d : Vérifier le nom d’hôte

Vérifiez que le nom d’hôte est correctement défini :

hostname
<!--NeedCopy-->

Cette commande renvoie uniquement le nom d’hôte de la machine et non son nom de domaine complet (FQDN).

Vérifiez que le FQDN est correctement défini :

hostname -f
<!--NeedCopy-->

Cette commande renvoie le FQDN de la machine.

Étape 1e : Vérifier la résolution de noms et l’accessibilité du service

Vérifiez que vous pouvez résoudre le FQDN et effectuer un ping sur le contrôleur de domaine et le Delivery Controller™ :

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn
<!--NeedCopy-->

Si vous ne parvenez pas à résoudre le FQDN ou à effectuer un ping sur l’une de ces machines, examinez les étapes avant de continuer.

Étape 1f : Configurer la synchronisation de l’horloge

Il est crucial de maintenir une synchronisation précise de l’horloge entre les VDA, les Delivery Controller et les contrôleurs de domaine. L’hébergement du VDA Linux en tant que machine virtuelle (VM) peut entraîner des problèmes de décalage d’horloge. Pour cette raison, la synchronisation de l’heure avec un service de temps distant est préférable.

Un environnement RHEL par défaut utilise le démon Chrony (chronyd) pour la synchronisation de l’horloge.

  • Configurer le service Chrony

  • En tant qu’utilisateur root, modifiez /etc/chrony.conf et ajoutez une entrée de serveur pour chaque serveur de temps distant :
server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst
<!--NeedCopy-->

Dans un déploiement typique, synchronisez l’heure à partir des contrôleurs de domaine locaux et non directement à partir des serveurs de pool NTP publics. Ajoutez une entrée de serveur pour chaque contrôleur de domaine Active Directory dans le domaine.

Supprimez toutes les autres entrées de serveur répertoriées, y compris l’adresse IP de bouclage, localhost et les entrées de serveur public *.pool.ntp.org.

Enregistrez les modifications et redémarrez le démon Chrony :

sudo systemctl restart chronyd
<!--NeedCopy-->

Étape 1g : Installer PulseAudio (pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0 uniquement)

Exécutez la commande suivante pour installer pulseaudio :

sudo yum -y install pulseaudio --allowerasing
<!--NeedCopy-->

Ouvrez /etc/pulse/client.conf et ajoutez l’entrée suivante :

autospawn = yes
<!--NeedCopy-->

Étape 1h : Installer et spécifier une base de données à utiliser

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 l’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 VDA Linux utilise PostgreSQL par défaut.

  • Pour les installations manuelles, vous devez installer SQLite, PostgreSQL ou les deux manuellement. Si vous installez à la fois SQLite et PostgreSQL, vous pouvez spécifier l’un d’eux à utiliser en modifiant /etc/xdl/db.conf après l’installation du package VDA Linux.

Cette section décrit comment installer PostgreSQL et SQLite et comment spécifier l’un d’eux à utiliser.

Installer PostgreSQL

Le VDA Linux nécessite PostgreSQL :

  • PostgreSQL 9 pour Amazon Linux 2, RHEL 7 et CentOS 7
  • PostgreSQL 10 pour RHEL 8.x et Rocky Linux 8.x
  • PostgreSQL 13 pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0

Exécutez les commandes suivantes pour installer PostgreSQL :

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc
<!--NeedCopy-->

Pour RHEL 8.x et RHEL 9.6/9.4/9.3/9.2/9.0, exécutez la commande suivante pour installer libpq pour PostgreSQL :

sudo yum -y install libpq
<!--NeedCopy-->

Exécutez la commande suivante pour initialiser la base de données. Cette action crée des fichiers de base de données sous /var/lib/pgsql/data.

sudo postgresql-setup initdb
<!--NeedCopy-->

Exécutez les commandes suivantes pour démarrer PostgreSQL au démarrage de la machine ou immédiatement, respectivement :

sudo systemctl enable postgresql

sudo systemctl start postgresql
<!--NeedCopy-->
  • Vérifiez la version de PostgreSQL à l’aide de la commande suivante :
psql --version
<!--NeedCopy-->

(Pour RHEL 7 et Amazon Linux 2 uniquement) Vérifiez que le répertoire de données est défini à l’aide de l’utilitaire de ligne de commande psql :

sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->

Installer SQLite

Exécutez la commande suivante pour installer SQLite :

sudo yum -y install sqlite
<!--NeedCopy-->

Spécifier une base de données à utiliser

Si vous installez à la fois SQLite et PostgreSQL, vous pouvez spécifier l’une d’elles à utiliser en modifiant /etc/xdl/db.conf après l’installation du package Linux VDA.

  1. Exécutez /opt/Citrix/VDA/sbin/ctxcleanup.sh. Omettez cette étape s’il s’agit d’une nouvelle installation.

  2. Modifiez /etc/xdl/db.conf pour spécifier une base de données à utiliser. 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.

  3. Exécutez ctxsetup.sh.

Remarque :

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

Étape 2 : Préparer l’hyperviseur

Certaines modifications sont nécessaires lors de l’exécution du Linux VDA en tant que machine virtuelle sur un hyperviseur pris en charge. Apportez les modifications suivantes en fonction de la plateforme d’hyperviseur utilisée. Aucune modification n’est requise si vous exécutez la machine Linux sur du matériel physique.

Corriger la synchronisation de l’heure sur XenServer (anciennement Citrix Hypervisor™)

Lorsque la fonctionnalité de synchronisation de l’heure de XenServer® est activée, vous rencontrez des problèmes avec NTP et XenServer au sein de chaque machine virtuelle Linux paravirtualisée. Les deux tentent de gérer l’horloge système. Pour éviter que l’horloge ne se désynchronise avec d’autres serveurs, assurez-vous que l’horloge système de chaque invité Linux est synchronisée avec le NTP. Ce cas nécessite la désactivation de la synchronisation de l’heure de l’hôte. Aucune modification n’est requise en mode HVM.

Si vous exécutez un noyau Linux paravirtualisé avec les outils XenServer VM Tools installés, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure de XenServer est présente et activée depuis la machine virtuelle Linux :

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Cette commande renvoie 0 ou 1 :

  • 0 - La fonctionnalité de synchronisation de l’heure est activée et doit être désactivée.
    • 1 - La fonctionnalité de synchronisation de l’heure est désactivée et aucune autre action n’est requise.

Si le fichier /proc/sys/xen/independent_wallclock n’est pas présent, les étapes suivantes ne sont pas nécessaires.

Si elle est activée, désactivez la fonctionnalité de synchronisation de l’heure en écrivant 1 dans le fichier :

sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Pour rendre cette modification permanente et persistante après le redémarrage, modifiez le fichier /etc/sysctl.conf et ajoutez la ligne :

xen.independent_wallclock = 1

Pour vérifier ces modifications, redémarrez le système :

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Cette commande renvoie la valeur 1.

Corriger la synchronisation de l’heure sur Microsoft Hyper-V

Les machines virtuelles Linux avec les services d’intégration Hyper-V Linux installés peuvent appliquer la fonctionnalité de synchronisation de l’heure Hyper-V pour utiliser l’heure du système d’exploitation hôte. Pour garantir que l’horloge système reste précise, vous devez activer cette fonctionnalité en même temps que les services NTP.

Depuis le système d’exploitation de gestion :

  1. Ouvrez la console du Gestionnaire Hyper-V.
  2. Pour les paramètres d’une machine virtuelle Linux, sélectionnez Services d’intégration.
  3. Assurez-vous que Synchronisation de l’heure est sélectionné.

Remarque :

Cette approche est différente de VMware et XenServer (anciennement Citrix Hypervisor), où la synchronisation de l’heure de l’hôte est désactivée pour éviter les conflits avec NTP. La synchronisation de l’heure Hyper-V peut coexister et compléter la synchronisation de l’heure NTP.

Corriger la synchronisation de l’heure sur ESX et ESXi

Lorsque la fonctionnalité de synchronisation de l’heure VMware est activée, vous rencontrez des problèmes avec le NTP et l’hyperviseur au sein de chaque machine virtuelle Linux paravirtualisée. Les deux tentent de synchroniser l’horloge système. Pour éviter que l’horloge ne se désynchronise avec d’autres serveurs, assurez-vous que l’horloge système de chaque invité Linux est synchronisée avec le NTP. Ce cas nécessite la désactivation de la synchronisation de l’heure de l’hôte.

Si vous exécutez un noyau Linux paravirtualisé avec les outils VMware Tools installés :

  1. Ouvrez le client vSphere.
  2. Modifiez les paramètres de la machine virtuelle Linux.
  3. Dans la boîte de dialogue Propriétés de la machine virtuelle, ouvrez l’onglet Options.
  4. Sélectionnez VMware Tools.
  5. Dans la zone Avancé, désélectionnez Synchroniser l’heure de l’invité avec l’hôte.

Étape 3 : Ajouter la machine virtuelle Linux au domaine Windows

Les méthodes suivantes sont disponibles pour ajouter des machines Linux au domaine Active Directory (AD) :

-  [Samba Winbind](/fr-fr/linux-virtual-delivery-agent/2402-ltsr/installation-overview/manual-installation-overview/redhat.html#samba-winbind)

Suivez les instructions en fonction de la méthode choisie.

Remarque :

Les lancements de session peuvent échouer lorsque le même nom d’utilisateur est utilisé pour le compte local dans le Linux VDA et le compte dans AD.

Samba Winbind

Pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0, exécutez la commande suivante pour empêcher pam_winbind de modifier la propriété du répertoire racine :

usermod -d /nonexistent nobody
<!--NeedCopy-->

Installez ou mettez à jour les packages requis :

Pour RHEL 9.6/9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.6/9.4/9.3/9.2/9.0/8.x :

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->

Pour Amazon Linux 2, CentOS 7 et RHEL 7 :

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authconfig
<!--NeedCopy-->

Activer le démon Winbind au démarrage de la machine

Le démon Winbind doit être configuré pour démarrer au démarrage de la machine :

sudo /sbin/chkconfig winbind on
<!--NeedCopy-->

Configurer l’authentification Winbind

Configurez la machine pour l’authentification Kerberos à l’aide de Winbind :

  1. Exécutez la commande suivante.

    Pour RHEL 9.6/9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.6/9.4/9.3/9.2/9.0/8.x :

    sudo authselect select winbind with-mkhomedir --force
<!--NeedCopy-->

    Pour Amazon Linux 2, CentOS 7 et RHEL 7 :

    sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall
<!--NeedCopy-->

    Où REALM est le nom du royaume Kerberos en majuscules et domain est le nom NetBIOS du domaine.

    Si une recherche DNS du serveur KDC et du nom de royaume est requise, ajoutez les deux options suivantes à la commande précédente :

    --enablekrb5kdcdns --enablekrb5realmdns

    Ignorez toutes les erreurs renvoyées par la commande authconfig concernant l’échec du démarrage du service winbind. Ces erreurs peuvent se produire lorsque authconfig tente de démarrer le service winbind alors que la machine n’est pas encore jointe au domaine.

  2. Ouvrez /etc/samba/smb.conf et ajoutez les entrées suivantes sous la section [Global], mais après la section générée par l’outil authconfig :

    kerberos method = secrets and keytab winbind refresh tickets = true winbind offline logon = no

  3. (Pour RHEL 9.6/9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.6/9.4/9.3/9.2/9.0/8.x uniquement) Ouvrez /etc/krb5.conf et ajoutez des entrées sous les sections [libdefaults], [realms] et [domain_realm] :

    Sous la section [libdefaults] :

    default_ccache_name = FILE:/tmp/krb5cc_%{uid} default_realm = REALM dns_lookup_kdc = true

    Sous la section [realms] :

    REALM = { kdc = fqdn-of-domain-controller }

    Sous la section [domain_realm] :

    realm = REALM .realm = REALM

Le VDA Linux nécessite le fichier keytab système /etc/krb5.keytab pour s’authentifier et s’enregistrer auprès du Delivery Controller. Le paramètre de méthode Kerberos précédent force Winbind à créer le fichier keytab système lorsque la machine est jointe pour la première fois au domaine.

Joindre un domaine Windows

Votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine.

Pour ajouter une machine virtuelle Linux au domaine Windows, exécutez la commande suivante :

sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->

Conseil :

Pour les machines virtuelles Linux exécutées sur Amazon Linux 2, RHEL 7.9 et CentOS 7.9, vous pouvez également utiliser la commande suivante pour les ajouter au domaine Windows :

sudo net ads join REALM -U user
<!--NeedCopy-->

REALM est le nom du royaume Kerberos en majuscules, et user est un utilisateur de domaine qui dispose des autorisations nécessaires pour ajouter des ordinateurs au domaine.

Configurer PAM pour Winbind

Par défaut, la configuration du module PAM Winbind (pam_winbind) n’active pas la mise en cache des tickets Kerberos ni la création de répertoires personnels. Ouvrez /etc/security/pam_winbind.conf et ajoutez ou modifiez les entrées suivantes sous la section [Global] :

krb5_auth = yes krb5_ccache_type = FILE mkhomedir = yes

Assurez-vous que tous les points-virgules de début de chaque paramètre sont supprimés. Ces modifications nécessitent le redémarrage du démon Winbind :

sudo systemctl restart winbind
<!--NeedCopy-->

Conseil :

Le démon winbind reste en cours d’exécution uniquement si la machine est jointe à un domaine.

Ouvrez /etc/krb5.conf et modifiez le paramètre suivant sous la section [libdefaults] de KEYRING à FILE :

default_ccache_name = FILE:/tmp/krb5cc_%{uid}

Pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0, exécutez les commandes suivantes pour résoudre le problème SELinux avec Winbind :

ausearch -c 'winbindd' --raw | audit2allow -M my-winbindd -p /etc/selinux/targeted/policy/policy.*

semodule -X 300 -i my-winbindd.pp
<!--NeedCopy-->

Vérifier l’appartenance au domaine 

-  Le Delivery Controller exige que toutes les machines VDA (VDA Windows et Linux) aient un objet ordinateur dans **Active Directory**.

Exécutez la commande net ads de Samba pour vérifier que la machine est jointe à un domaine :

sudo net ads testjoin
<!--NeedCopy-->

Exécutez la commande suivante pour vérifier les informations supplémentaires sur le domaine et l’objet ordinateur :

sudo net ads info
<!--NeedCopy-->

Vérifier la configuration Kerberos

Pour vous assurer que Kerberos est correctement configuré pour être utilisé avec le VDA Linux, vérifiez que le fichier keytab système a été créé et contient des clés valides :

sudo klist -ke
<!--NeedCopy-->

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms de principal et de suites de chiffrement. Exécutez la commande Kerberos kinit pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit -k MACHINE\$@REALM
<!--NeedCopy-->

Les noms de machine et de royaume doivent être spécifiés en majuscules. Le signe dollar ($) doit être échappé avec une barre oblique inverse (\) pour éviter la substitution de shell. Dans certains environnements, le nom de domaine DNS est différent du nom de royaume Kerberos. Assurez-vous que le nom de royaume est utilisé. Si cette commande réussit, aucune sortie n’est affichée.

Vérifiez que le ticket TGT pour le compte de la machine a été mis en cache à l’aide de :

sudo klist
<!--NeedCopy-->

Examinez les détails du compte de la machine à l’aide de :

sudo net ads status
<!--NeedCopy-->

Vérifier l’authentification de l’utilisateur

  • Utilisez l’outil wbinfo pour vérifier que les utilisateurs du domaine peuvent s’authentifier auprès du domaine :
wbinfo --krb5auth=domain\\username%password
<!--NeedCopy-->

Le domaine spécifié ici est le nom de domaine AD, et non le nom de domaine Kerberos. Pour le shell bash, le caractère barre oblique inverse (\) doit être échappé avec une autre barre oblique inverse. Cette commande renvoie un message indiquant la réussite ou l’échec.

Pour vérifier que le module PAM Winbind est correctement configuré, connectez-vous au VDA Linux à l’aide d’un compte utilisateur de domaine qui n’a jamais été utilisé auparavant.

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Vérifiez que les tickets dans le cache d’informations d’identification Kerberos sont valides et n’ont pas expiré :

klist
<!--NeedCopy-->

Quittez la session.

exit
<!--NeedCopy-->

Un test similaire peut être effectué en vous connectant directement à la console Gnome ou KDE. Passez à l’Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

Services d’authentification Quest

Configurer Quest sur le contrôleur de domaine

Supposons que vous ayez installé et configuré le logiciel Quest sur les contrôleurs de domaine Active Directory et que vous ayez obtenu les privilèges administratifs pour créer des objets ordinateur dans Active Directory.

Autoriser les utilisateurs de domaine à se connecter aux machines VDA Linux

Pour permettre aux utilisateurs de domaine d’établir des sessions HDX™ sur une machine VDA Linux :

  1. Dans la console de gestion Utilisateurs et ordinateurs Active Directory, ouvrez les propriétés de l’utilisateur Active Directory pour ce compte utilisateur.
  2. Sélectionnez l’onglet Compte Unix.
  3. Cochez Activé pour Unix.
  4. Définissez le numéro GID principal sur l’ID de groupe d’un groupe d’utilisateurs de domaine réel.

Remarque :

Ces instructions sont équivalentes pour la configuration des utilisateurs de domaine pour la connexion à l’aide de la console, de RDP, de SSH ou de tout autre protocole de connexion à distance.

Configurer Quest sur le VDA Linux

Contourner l’application de la politique SELinux

L’environnement RHEL par défaut applique entièrement SELinux. Cette application interfère avec les mécanismes IPC de socket de domaine Unix utilisés par Quest et empêche les utilisateurs de domaine de se connecter.

  • Le moyen pratique de contourner ce problème est de désactiver SELinux. En tant qu’utilisateur root, modifiez /etc/selinux/config et modifiez le paramètre SELinux :

  • SELINUX=permissive

Cette modification nécessite un redémarrage de la machine :

reboot
<!--NeedCopy-->

Important :

Utilisez ce paramètre avec prudence. La réactivation de l’application de la politique SELinux après sa désactivation peut entraîner un verrouillage complet, même pour l’utilisateur root et les autres utilisateurs locaux.

Configurer le démon VAS

Le renouvellement automatique des tickets Kerberos doit être activé et déconnecté. L’authentification (connexion hors ligne) doit être désactivée.

sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400

sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->

Cette commande définit l’intervalle de renouvellement à neuf heures (32 400 secondes), soit une heure de moins que la durée de vie par défaut des tickets de 10 heures. Définissez ce paramètre sur une valeur inférieure sur les systèmes avec une durée de vie de ticket plus courte.

Configurer PAM et NSS

Pour activer la connexion des utilisateurs de domaine via HDX et d’autres services tels que su, ssh et RDP, exécutez les commandes suivantes pour configurer PAM et NSS manuellement :

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->

Joindre le domaine Windows

Joignez la machine Linux au domaine Active Directory à l’aide de la commande Quest vastool :

sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->

L’utilisateur est tout utilisateur de domaine disposant des autorisations nécessaires pour joindre des ordinateurs au domaine Active Directory. Le nom de domaine est le nom DNS du domaine, par exemple, example.com.

Redémarrez la machine Linux après la jonction au domaine.

Vérifier l’appartenance au domaine

Le Delivery Controller exige que toutes les machines VDA (VDA Windows et Linux) aient un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux jointe à Quest est sur le domaine :

sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->

Si la machine est jointe à un domaine, cette commande renvoie le nom de domaine. Si la machine n’est jointe à aucun domaine, l’erreur suivante apparaît :

ERROR: No domain could be found. ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm

  • default_realm not configured in vas.conf. Computer may not be joined to domain

Vérifier l’authentification de l’utilisateur

Pour vérifier que Quest peut authentifier les utilisateurs de domaine via PAM, connectez-vous au VDA Linux à l’aide d’un compte utilisateur de domaine qui n’a jamais été utilisé auparavant.

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Vérifiez qu’un fichier de cache d’informations d’identification Kerberos correspondant a été créé pour l’UID renvoyé par la commande id -u :

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Vérifiez que les tickets dans le cache d’informations d’identification Kerberos sont valides et n’ont pas expiré :

/opt/quest/bin/vastool klist
<!--NeedCopy-->

Quittez la session.

exit
<!--NeedCopy-->

Un test similaire peut être effectué en vous connectant directement à la console Gnome ou KDE. Passez à l’Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

Centrify DirectControl

Joindre un domaine Windows

Une fois l’agent Centrify DirectControl installé, joignez la machine Linux au domaine Active Directory à l’aide de la commande Centrify adjoin :

su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->

Le paramètre utilisateur est tout utilisateur de domaine Active Directory disposant des autorisations nécessaires pour joindre des ordinateurs au domaine Active Directory. Le nom de domaine est le nom du domaine auquel joindre la machine Linux.

Vérifier l’appartenance au domaine

Le Delivery Controller exige que toutes les machines VDA (VDA Windows et Linux) possèdent un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux jointe à Centrify est sur le domaine :

su –
adinfo
<!--NeedCopy-->

Vérifiez que la valeur « Joint au domaine » est valide et que le mode CentrifyDC renvoie « connecté ». Si le mode reste bloqué à l’état de démarrage, le client Centrify rencontre des problèmes de connexion au serveur ou d’authentification.

Des informations système et de diagnostic plus complètes sont disponibles à l’aide de :

adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->

Testez la connectivité aux différents services Active Directory et Kerberos.

    -  adinfo --test
<!--NeedCopy-->

Passez à l’Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

SSSD

Si vous utilisez SSSD, suivez les instructions de cette section. Cette section inclut des instructions pour joindre une machine VDA Linux à un domaine Windows et fournit des conseils pour la configuration de l’authentification Kerberos.

Pour configurer SSSD sur RHEL et CentOS, procédez comme suit :

  1. Joindre le domaine et créer un keytab d’hôte
  2. Configurer SSSD
  3. Activer SSSD
  4. Vérifier la configuration Kerberos
  5. Vérifier l’authentification utilisateur

Joindre le domaine et créer un keytab d’hôte

SSSD ne fournit pas de fonctions client Active Directory pour joindre le domaine et gérer le fichier keytab système. Vous pouvez utiliser adcli, realmd ou Samba à la place.

Cette section décrit l’approche Samba pour Amazon Linux 2 et RHEL 7, et l’approche adcli pour RHEL 8.x/9.x et Rocky Linux 8.x/9.x. Pour realmd, consultez la documentation RHEL ou CentOS. Ces étapes doivent être suivies avant de configurer SSSD.

  • Samba (Amazon Linux 2 et RHEL 7) :

    Installez ou mettez à jour les packages requis :

     sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
 <!--NeedCopy-->

    Sur le client Linux avec des fichiers correctement configurés :

    • /etc/krb5.conf
    • /etc/samba/smb.conf :

    Configurez la machine pour l’authentification Samba et Kerberos :

     sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
 <!--NeedCopy-->

    Où REALM est le nom du royaume Kerberos en majuscules et domaine est le nom NetBIOS court du domaine Active Directory.

    Remarque :

    Les paramètres de cet article sont destinés au modèle de domaine unique, de forêt unique. Configurez Kerberos en fonction de votre infrastructure AD.

    Si la recherche basée sur DNS du serveur KDC et du nom de royaume est requise, ajoutez les deux options suivantes à la commande précédente :

    --enablekrb5kdcdns --enablekrb5realmdns

    Ouvrez /etc/samba/smb.conf et ajoutez les entrées suivantes sous la section [Global], mais après la section générée par l’outil authconfig :

    kerberos method = secrets and keytab winbind offline logon = no

    Joignez le domaine Windows. Assurez-vous que votre contrôleur de domaine est accessible et que vous disposez d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :

     sudo net ads join REALM -U user
 <!--NeedCopy-->

    REALM est le nom du royaume Kerberos en majuscules et utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter des ordinateurs au domaine.

  • Adcli (RHEL 9.6/9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.6/9.4/9.3/9.2/9.0/8.x) :

    Installez ou mettez à jour les packages requis :

     sudo yum -y install samba-common samba-common-tools krb5-workstation authconfig oddjob-mkhomedir realmd oddjob authselect
 <!--NeedCopy-->

    Configurez la machine pour l’authentification Samba et Kerberos :

     sudo authselect select sssd with-mkhomedir --force
 <!--NeedCopy-->

    Ouvrez /etc/krb5.conf et ajoutez les entrées sous les sections [realms] et [domain_realm].

    Sous la section [realms] :

    REALM = { kdc = fqdn-of-domain-controller }

    Sous la section [domain_realm] :

    realm = REALM .realm = REALM

    Joignez le domaine Windows. Assurez-vous que votre contrôleur de domaine est accessible et que vous disposez d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :

     sudo realm join REALM -U user
 <!--NeedCopy-->

    REALM est le nom du royaume Kerberos en majuscules et utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter des ordinateurs au domaine.

Configurer SSSD

La configuration de SSSD comprend les étapes suivantes :

  • Installez le package sssd-ad sur le VDA Linux en exécutant la commande sudo yum -y install sssd.
  • Apportez des modifications de configuration à divers fichiers (par exemple, sssd.conf).
  • Démarrez le service sssd.

Un exemple de configuration sssd.conf pour RHEL 7 (des options supplémentaires peuvent être ajoutées si nécessaire) :

Un exemple de configuration SSSD pour RHEL 7

Remplacez ad.example.com, server.ad.example.com par les valeurs correspondantes. Pour plus de détails, consultez la page de manuel Linux sssd-ad(5).

(RHEL 9.6/9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.6/9.4/9.3/9.2/9.0/8.x uniquement) Ouvrez /etc/sssd/sssd.conf et ajoutez les entrées suivantes sous la section [domain/ad.example.com] :

ad_gpo_access_control = permissive full_name_format = %2$s\%1$s fallback_homedir = /home/%d/%u # Kerberos settings krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U

Définissez la propriété et les autorisations du fichier sur sssd.conf :

chown root:root /etc/sssd/sssd.conf chmod 0600 /etc/sssd/sssd.conf restorecon /etc/sssd/sssd.conf

Activer SSSD

Pour RHEL 9.6/9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.6/9.4/9.3/9.2/9.0/8.x :

Exécutez les commandes suivantes pour activer SSSD :

sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->

Pour Amazon Linux 2, CentOS 7 et RHEL 7 :

Utilisez authconfig pour activer SSSD. Installez oddjob-mkhomedir pour vous assurer que la création du répertoire personnel est compatible avec SELinux :

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

sudo systemctl start sssd

sudo chkconfig sssd on
<!--NeedCopy-->

Vérifier la configuration Kerberos

Vérifiez que le fichier keytab du système a été créé et contient des clés valides :

sudo klist -ke
<!--NeedCopy-->

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms de principal et de suites de chiffrement. Exécutez la commande Kerberos kinit pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->

Les noms de machine et de domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être échappé avec une barre oblique inverse (\) pour éviter la substitution de shell. Dans certains environnements, le nom de domaine DNS est différent du nom de domaine Kerberos. Assurez-vous que le nom de domaine est utilisé. Si cette commande réussit, aucune sortie n’est affichée.

Vérifiez que le ticket TGT pour le compte de machine a été mis en cache à l’aide de :

sudo klist
<!--NeedCopy-->

Vérifier l’authentification de l’utilisateur

Utilisez la commande getent pour vérifier que le format d’ouverture de session est pris en charge et que le NSS fonctionne :

sudo getent passwd DOMAIN\\username
<!--NeedCopy-->

Le paramètre DOMAIN indique le nom de domaine en version courte. Si un autre format d’ouverture de session est nécessaire, vérifiez-le d’abord à l’aide de la commande getent.

Les formats d’ouverture de session pris en charge sont :

  • Nom d’ouverture de session de niveau inférieur : DOMAIN\username
  • UPN : username@domain.com
  • Format de suffixe NetBIOS : username@DOMAIN

Pour vérifier que le module PAM SSSD est correctement configuré, connectez-vous au VDA Linux à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé auparavant.

sudo ssh localhost –l DOMAIN\\username

id -u
<!--NeedCopy-->

Vérifiez qu’un fichier de cache d’informations d’identification Kerberos correspondant a été créé pour l’uid renvoyé par la commande :

ls /tmp/krb5cc_{uid}
<!--NeedCopy-->

Vérifiez que les tickets dans le cache d’informations d’identification Kerberos de l’utilisateur sont valides et n’ont pas expiré.

klist
<!--NeedCopy-->

Passez à Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

PBIS

Télécharger le package PBIS requis 

wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

Rendre le script d’installation PBIS exécutable 

chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

Exécuter le script d’installation PBIS 

sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

  • Joindre le domaine Windows

Votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte d’utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :

/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->

L’utilisateur est un utilisateur de domaine qui dispose des autorisations nécessaires pour ajouter des ordinateurs au domaine Active Directory. Le nom-de-domaine est le nom DNS du domaine, par exemple, example.com.

Remarque : Pour définir Bash comme shell par défaut, exécutez la commande /opt/pbis/bin/config LoginShellTemplate/bin/bash.

Vérifier l’appartenance au domaine

Le Delivery Controller exige que toutes les machines VDA (VDA Windows et Linux) aient un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux jointe à PBIS est sur le domaine :

/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->

Si la machine est jointe à un domaine, cette commande renvoie les informations sur le domaine AD et l’unité d’organisation (OU) actuellement joints. Sinon, seul le nom d’hôte apparaît.

Vérifier l’authentification de l’utilisateur

Pour vérifier que PBIS peut authentifier les utilisateurs de domaine via PAM, connectez-vous au VDA Linux à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé auparavant.

ssh localhost -l domain\\user

id -u
<!--NeedCopy-->

Vérifiez qu’un fichier de cache d’informations d’identification Kerberos correspondant a été créé pour l’UID renvoyé par la commande id -u :

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Quittez la session.

exit
<!--NeedCopy-->

  • Passez à Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

  • Étape 4 : Installer .NET

  • Avant d’installer le VDA Linux, installez .NET en fonction de votre distribution Linux :

  • Installez .NET Runtime 8.0 sur toutes les distributions Linux prises en charge, à l’exception de RHEL 7.9 et Amazon Linux 2.

  • Pour RHEL 7.9 et 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.

  • Après avoir installé .NET, exécutez la commande which dotnet pour trouver votre chemin d’exécution.

En fonction de la sortie de la commande, définissez le chemin binaire du runtime .NET. Par exemple, si la sortie de la commande est /aa/bb/dotnet, utilisez /aa/bb comme chemin binaire .NET.

Étape 5 : Télécharger le package Linux VDA

  1. Accédez à la page de téléchargement de Citrix Virtual Apps and Desktops.
  2. Développez la version appropriée de Citrix Virtual Apps and Desktops.

  3. Développez Composants pour trouver le Linux VDA. Par exemple :

    Composants pour Citrix Virtual Apps and Desktops

  4. Cliquez sur le lien Linux VDA pour accéder aux téléchargements du Linux VDA.

    Téléchargements du Linux VDA

  5. Téléchargez le package Linux VDA qui correspond à votre distribution Linux.

  6. Téléchargez la clé publique GPG que vous pouvez utiliser pour vérifier l’intégrité du package Linux VDA. Par exemple :

    Clé publique GPG

    Pour vérifier l’intégrité du package Linux VDA, exécutez les commandes suivantes pour importer la clé publique dans la base de données RPM et pour vérifier l’intégrité du package :

    rpmkeys --import <path to the public key>
rpm --checksig --verbose <path to the Linux VDA package>
<!--NeedCopy-->

Étape 6 : Installer le Linux VDA

Vous pouvez effectuer une nouvelle installation ou mettre à niveau une installation existante. Le Linux VDA prend en charge les mises à niveau à partir de la version la plus récente. Par exemple, vous pouvez mettre à niveau le Linux VDA de 2308 vers 2311 et de 1912 LTSR vers 2203 LTSR.

Étape 6a : Effectuer une nouvelle installation

  1. (Facultatif) Désinstallez l’ancienne version

    Si vous avez installé une version antérieure autre que les deux précédentes et une version LTSR, désinstallez-la avant d’installer la nouvelle version.

    1. Arrêtez les services Linux VDA :

      sudo systemctl stop ctxvda

sudo systemctl stop ctxhdx
<!--NeedCopy-->

      Remarque :

      Avant d’arrêter les services ctxvda et ctxhdx, exécutez la commande systemctl stop ctxmonitord pour arrêter le démon du service de surveillance. Sinon, le démon du service de surveillance redémarre les services que vous avez arrêtés.

    2. Désinstallez le package :

      sudo rpm -e XenDesktopVDA
<!--NeedCopy-->

    Remarque :

    Pour exécuter une commande, le chemin complet est nécessaire ; alternativement, vous pouvez ajouter /opt/Citrix/VDA/sbin et /opt/Citrix/VDA/bin au chemin système.

  2. Téléchargez le package Linux VDA

    Accédez à la page de téléchargement de Citrix Virtual Apps and Desktops. Développez la version appropriée de Citrix Virtual Apps and Desktops et cliquez sur Composants pour télécharger le package Linux VDA qui correspond à votre distribution Linux.

  3. Installez le Linux VDA

    Remarque :

    • Pour CentOS, RHEL et Rocky Linux, installez le référentiel EPEL avant de pouvoir installer le Linux VDA avec succès. Pour plus d’informations sur l’installation d’EPEL, consultez les instructions à l’adresse https://docs.fedoraproject.org/fr-FR/epel/.

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

    • Installez le logiciel Linux VDA à l’aide de Yum :

      Pour Amazon Linux 2 :

       sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
 <!--NeedCopy-->

      Pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0 :

       sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm
 <!--NeedCopy-->

      Pour RHEL 8.x et Rocky Linux 8.x :

       sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
 <!--NeedCopy-->

    • Pour CentOS 7 et RHEL 7 :

       sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
 <!--NeedCopy-->

    • Installez le logiciel Linux VDA à l’aide du gestionnaire de packages RPM. Avant de le faire, vous devez résoudre les dépendances suivantes :

      Pour Amazon Linux 2 :

       sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm
 <!--NeedCopy-->

  • RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0 :

     ```
 sudo rpm -i XenDesktopVDA-<version>.el9_x.x86_64.rpm
 <!--NeedCopy--> ```

 **Pour RHEL 8.x et Rocky Linux 8.x :**

 ```
 sudo rpm -i XenDesktopVDA-<version>.el8_x.x86_64.rpm
 <!--NeedCopy--> ```

 **Pour CentOS 7 et RHEL 7 :**

 ```
 sudo rpm -i XenDesktopVDA-<version>.el7_x.x86_64.rpm
 <!--NeedCopy--> ```

 **Liste des dépendances RPM pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0 :**

 ```
 tzdata-java >= 2022

 java-17-openjdk >= 17

  icoutils >= 0.32

  firewalld >= 0.6.3

  policycoreutils-python >= 2.8.9

  policycoreutils-python-utils >= 2.8

  python3-policycoreutils >= 2.8

  dbus >= 1.12.8

  dbus-common >= 1.12.8

  dbus-daemon >= 1.12.8

  dbus-tools >= 1.12.8

  dbus-x11 >= 1.12.8

  xorg-x11-server-utils >= 7.7

  xorg-x11-xinit >= 1.3.4

  libXpm >= 3.5.12

  libXrandr >= 1.5.1

  libXtst >= 1.2.3

  pam >= 1.3.1

  util-linux >= 2.32.1

  util-linux-user >= 2.32.1

  xorg-x11-utils >= 7.5

  bash >= 4.3

  findutils >= 4.6

  gawk >= 4.2

  sed >= 4.5

  cups >= 1.6.0

  foomatic-filters >= 4.0.9

  cups-filters >= 1.20.0

  ghostscript >= 9.25

  libxml2 >= 2.9

  libmspack >= 0.7

  krb5-workstation >= 1.13

  ibus >= 1.5

  nss-tools >= 3.44.0

  gperftools-libs >= 2.4

  cyrus-sasl-gssapi >= 2.1

  python3 >= 3.6~

  qt5-qtbase >= 5.5~

  qt5-qtbase-gui >= 5.5~

  qrencode-libs >= 3.4.4

  imlib2 >= 1.4.9

 <!--NeedCopy--> ```

 **Liste des dépendances RPM pour RHEL 8.x et Rocky Linux 8.x :**

 ```
 java-17-openjdk >= 17

 icoutils >= 0.32

 firewalld >= 0.6.3

 policycoreutils-python >= 2.8.9

 policycoreutils-python-utils >= 2.8

 python3-policycoreutils >= 2.8

 dbus >= 1.12.8

 dbus-common >= 1.12.8

 dbus-daemon >= 1.12.8

 dbus-tools >= 1.12.8

 dbus-x11 >= 1.12.8

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.4

 libXpm >= 3.5.12

 libXrandr >= 1.5.1

 libXtst >= 1.2.3

 pam >= 1.3.1

 util-linux >= 2.32.1

 util-linux-user >= 2.32.1

 xorg-x11-utils >= 7.5

 bash >= 4.3

 findutils >= 4.6

 gawk >= 4.2

 sed >= 4.5

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 cups-filters >= 1.20.0

 ghostscript >= 9.25

 libxml2 >= 2.9

 libmspack >= 0.7

 krb5-workstation >= 1.13

 ibus >= 1.5

 nss-tools >= 3.44.0

 gperftools-libs >= 2.4

 cyrus-sasl-gssapi >= 2.1

 python3 >= 3.6~

 qt5-qtbase >= 5.5~

 qt5-qtbase-gui >= 5.5~

 qrencode-libs >= 3.4.4

 imlib2 >= 1.4.9
 <!--NeedCopy--> ```

 **Liste des dépendances RPM pour CentOS 7 et RHEL 7 :**

 ```
 java-17-openjdk >= 17

 ImageMagick >= 6.7.8.9

 firewalld >= 0.3.9

 policycoreutils-python >= 2.0.83

 dbus >= 1.6.12

 dbus-x11 >= 1.6.12

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.2

 xorg-x11-server-Xorg >= 1.20.4

 libXpm >= 3.5.10

 libXrandr >= 1.4.1

 libXtst >= 1.2.2

 pam >= 1.1.8

 util-linux >= 2.23.2

 bash >= 4.2

 findutils >= 4.5

 gawk >= 4.0

 sed >= 4.2

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 libxml2 >= 2.9

 libmspack >= 0.5

 ibus >= 1.5

 cyrus-sasl-gssapi >= 2.1

 python3 >= 3.6~

 gperftools-libs >= 2.4

 nss-tools >= 3.44.0

 qt5-qtbase >= 5.5~

 qt5-qtbase >= 5.5~

 imlib2 >= 1.4.5
 <!--NeedCopy--> ```

 **Liste des dépendances RPM pour Amazon Linux 2 :**

 ```
 java-17-openjdk >= 17

 ImageMagick >= 6.7.8.9

 firewalld >= 0.3.9

 policycoreutils-python >= 2.0.83

 dbus >= 1.6.12

 dbus-x11 >= 1.6.12

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.2

 xorg-x11-server-Xorg >= 1.20.4

 libXpm >= 3.5.10

 libXrandr >= 1.4.1

 libXtst >= 1.2.2

 pam >= 1.1.8

 util-linux >= 2.23.2

 bash >= 4.2

 findutils >= 4.5

 gawk >= 4.0

 sed >= 4.2

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 libxml2 >= 2.9

 libmspack >= 0.5

 ibus >= 1.5

 cyrus-sasl-gssapi >= 2.1

 gperftools-libs >= 2.4

 nss-tools >= 3.44.0

 qt5-qtbase >= 5.5~

 qrencode-libs >= 3.4.1

 imlib2 >= 1.4.5
 <!--NeedCopy--> ```

    Remarque :

    Pour une matrice des distributions Linux et des versions Xorg prises en charge par cette version du VDA Linux, consultez la section Configuration système requise.

    Après avoir installé le VDA Linux sur RHEL 7.x, exécutez la commande sudo yum install -y python-websockify x11vnc. L’objectif est d’installer manuellement python-websockify et x11vnc pour utiliser la fonctionnalité d’observation de session. Pour plus d’informations, consultez la section Observation de sessions.

Étape 6b : Mettre à niveau une installation existante (facultatif)

Le VDA Linux prend en charge les mises à niveau à partir de la version la plus récente. Par exemple, vous pouvez mettre à niveau le VDA Linux de 2308 vers 2311 et de 1912 LTSR vers 2203 LTSR.

Remarque :

  • La mise à niveau d’une installation existante écrase les fichiers de configuration sous /etc/xdl. Avant d’effectuer une mise à niveau, assurez-vous de sauvegarder les fichiers.

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

-  Pour mettre à niveau votre logiciel à l’aide de `Yum` :

**Pour Amazon Linux 2 :**

```
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy--> ```

**Pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0 :**

```
sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm
<!--NeedCopy--> ```

**Pour RHEL 8.x et Rocky Linux 8.x :**

```
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy--> ```

**Pour CentOS 7 et RHEL 7 :**

```
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy--> ```

-  Pour mettre à niveau votre logiciel à l’aide du gestionnaire de packages RPM :

**Pour Amazon Linux 2 :**

```
sudo rpm -U XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy--> ```

**Pour RHEL 9.6/9.4/9.3/9.2/9.0 et Rocky Linux 9.6/9.4/9.3/9.2/9.0 :**

```
sudo rpm -U XenDesktopVDA-<version>.el9_x.x86_64.rpm
<!--NeedCopy--> ```

**Pour RHEL 8.x et Rocky Linux 8.x :**

```
sudo rpm -U XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy--> ```

**Pour CentOS 7 et RHEL 7 :**

```
sudo rpm -U XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy--> ```

Remarque :

Si vous utilisez RHEL 7, assurez-vous d’effectuer les étapes suivantes après avoir exécuté les commandes de mise à niveau précédentes :

  1. Exécutez /opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "DotNetRuntimePath" -d "/opt/rh/rh-dotnet6/root/usr/bin/" --force pour définir le chemin d’exécution .NET correct.
  2. Redémarrez le service ctxvda.

Important :

Redémarrez la machine VDA Linux après la mise à niveau du logiciel.

Étape 7 : Installer les pilotes NVIDIA GRID

L’activation de HDX 3D Pro nécessite l’installation des pilotes NVIDIA GRID sur votre hyperviseur et sur les machines VDA.

Remarque :

Pour utiliser HDX 3D Pro pour Amazon Linux 2, nous vous recommandons d’installer le pilote NVIDIA 470. Pour plus d’informations, consultez la section Configuration système requise.

Pour installer et configurer le gestionnaire de GPU virtuel NVIDIA GRID (le pilote hôte) sur les hyperviseurs spécifiques, consultez les guides suivants :

Pour installer et configurer les pilotes de VM invitée NVIDIA GRID, effectuez les étapes suivantes :

  1. Assurez-vous que la VM invitée est arrêtée.
  2. Dans XenCenter®, allouez un GPU à la VM.
  3. Démarrez la VM.

  4. Préparez la VM pour le pilote NVIDIA GRID :

    yum install gcc

yum install "kernel-devel-$(uname -r)"

systemctl set-default multi-user.target
<!--NeedCopy-->
  5. Suivez les étapes du document Red Hat Enterprise Linux pour installer le pilote NVIDIA GRID.

Remarque :

Lors de l’installation du pilote GPU, sélectionnez la valeur par défaut (« non ») pour chaque question.

Important :

Une fois le passthrough GPU activé, la VM Linux n’est plus accessible via XenCenter. Utilisez SSH pour vous connecter.

Extrait de code NVIDIA smi

Définissez la configuration correcte pour la carte :

etc/X11/ctx-nvidia.sh

Pour profiter des grandes résolutions et des capacités multi-écrans, vous avez besoin d’une licence NVIDIA valide. Pour demander la licence, suivez la documentation du produit « GRID Licensing Guide.pdf - DU-07757-001 September 2015 ».

Étape 8 : Configurer le VDA Linux

Remarque :

Avant de configurer l’environnement d’exécution, assurez-vous que la locale en_US.UTF-8 est installée sur votre système d’exploitation. Si la locale n’est pas disponible sur votre système d’exploitation, exécutez la commande sudo locale-gen en_US.UTF-8. Pour Debian, modifiez le fichier /etc/locale.gen en décommentant la ligne # en_US.UTF-8 UTF-8, puis exécutez la commande sudo locale-gen.

Après avoir installé le package, vous devez configurer le VDA Linux en exécutant le script ctxsetup.sh. Avant d’apporter des modifications, le script vérifie l’environnement et s’assure que toutes les dépendances sont installées. Si nécessaire, vous pouvez réexécuter le script à tout moment pour modifier les paramètres.

Vous pouvez exécuter le script manuellement avec des invites, ou automatiquement avec des réponses préconfigurées. Consultez l’aide sur le script avant de continuer :

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help
<!--NeedCopy-->

Configuration guidée

Exécutez une configuration manuelle avec des questions guidées :

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->

Configuration automatisée

Pour une installation automatisée, fournissez les options requises par le script de configuration avec des variables d’environnement. Si toutes les variables requises sont présentes, le script ne demande aucune information.

Les variables d’environnement prises en charge incluent :

  • CTX_XDL_NON_DOMAIN_JOINED=’y|n’ – Indique si la machine doit être jointe à un domaine. La valeur par défaut est « n ». Pour les scénarios joints à un domaine, définissez-la sur « n ».

  • CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’ – Le VDA Linux nécessite des paramètres de configuration Kerberos pour s’authentifier auprès des Delivery Controllers. La configuration Kerberos est déterminée à partir de l’outil d’intégration Active Directory installé et configuré sur le système.

  • CTX_XDL_DDC_LIST=’<list-ddc-fqdns>‘ – Le VDA Linux nécessite une liste de noms de domaine complets (FQDN) de Delivery Controller séparés par des espaces à utiliser pour l’enregistrement auprès d’un Delivery Controller. Au moins un FQDN ou CNAME doit être spécifié.

  • CTX_XDL_VDI_MODE=’y|n’ – Indique s’il faut configurer la machine comme un modèle de livraison de bureau dédié (VDI) ou un modèle de livraison de bureau partagé hébergé. Pour les environnements HDX 3D Pro, définissez la valeur sur ‘y’.

  • CTX_XDL_HDX_3D_PRO=’y|n’ – Le VDA Linux prend en charge HDX 3D Pro, un ensemble de technologies d’accélération GPU conçues pour optimiser la virtualisation des applications graphiques riches. Si HDX 3D Pro est sélectionné, le VDA est configuré pour le mode de bureaux VDI (session unique) - (c’est-à-dire, CTX_XDL_VDI_MODE=‘y’).

  • CTX_XDL_START_SERVICE=’y|n’ – Détermine si les services VDA Linux sont démarrés une fois la configuration terminée.

  • CTX_XDL_REGISTER_SERVICE=’y|n’ – Les services Linux Virtual Desktop sont démarrés après le démarrage de la machine.

  • CTX_XDL_ADD_FIREWALL_RULES=’y|n’ – Les services Linux VDA nécessitent que les connexions réseau entrantes soient autorisées via le pare-feu système. Vous pouvez ouvrir automatiquement les ports requis (par défaut les ports 80 et 1494) dans le pare-feu système pour le Bureau virtuel Linux.

  • CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/kde/mate/xfce/’<none>‘ – Spécifie l’environnement de bureau GNOME, GNOME Classic, KDE, MATE ou Xfce à utiliser dans les sessions. Si vous le définissez sur ‘<none>‘, le bureau par défaut configuré sur le VDA est utilisé.

    Vous pouvez également basculer entre les environnements de bureau en exécutant des commandes ou en utilisant la barre d’état système. Pour plus d’informations, consultez Commandes de basculement de bureau et Barre d’état système.

  • CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime – Le chemin d’installation de .NET pour prendre en charge le nouveau service d’agent de broker (ctxvda). Le chemin par défaut est ‘/usr/bin’.

  • CTX_XDL_VDA_PORT=port-number – Le Linux VDA communique avec les Delivery Controllers via un port TCP/IP.

  • CTX_XDL_SITE_NAME=<dns-name> – Le Linux VDA découvre les serveurs LDAP via DNS. Pour limiter les résultats de la recherche DNS à un site local, spécifiez un nom de site DNS. Si cela n’est pas nécessaire, définissez sur ‘<none>‘.

  • CTX_XDL_LDAP_LIST=’<list-ldap-servers>‘ – Le Linux VDA interroge DNS pour découvrir les serveurs LDAP. Si DNS ne peut pas fournir d’enregistrements de service LDAP, vous pouvez fournir une liste de FQDN LDAP séparés par des espaces avec les ports LDAP. Par exemple, ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268. Pour permettre des requêtes LDAP plus rapides au sein d’une forêt Active Directory, activez le catalogue global sur un contrôleur de domaine et spécifiez le numéro de port LDAP pertinent comme 3268. Cette variable est définie sur ‘<none>‘ par défaut.

  • CTX_XDL_SEARCH_BASE=search-base-set – Le Linux VDA interroge LDAP via une base de recherche définie sur la racine du domaine Active Directory (par exemple, DC=mycompany,DC=com). Pour améliorer les performances de recherche, vous pouvez spécifier une base de recherche (par exemple, OU=VDI,DC=mycompany,DC=com). Si cela n’est pas nécessaire, définissez sur ‘<none>‘.

  • CTX_XDL_SUPPORT_DDC_AS_CNAME=’y|n’ – Le Linux VDA prend en charge la spécification d’un nom de Delivery Controller à l’aide d’un enregistrement DNS CNAME.

Définissez la variable d’environnement et exécutez le script de configuration :

export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest
export CTX_XDL_DDC_LIST='<list-ddc-fqdns>'
export CTX_XDL_VDI_MODE='y|n'
export CTX_XDL_HDX_3D_PRO='y|n'
export CTX_XDL_START_SERVICE='y|n'
export CTX_XDL_REGISTER_SERVICE='y|n'
export CTX_XDL_ADD_FIREWALL_RULES='y|n'
export CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|xfce|'<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>'
export CTX_XDL_VDA_PORT='<port-number>'
export CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>'
export CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>'
export CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>'
export CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n'
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->

Lorsque vous exécutez la commande sudo, saisissez l’option -E pour transmettre les variables d’environnement existantes au nouveau shell qu’elle crée. Nous vous recommandons de créer un fichier de script shell à partir des commandes précédentes avec #!/bin/bash comme première ligne.

Vous pouvez également spécifier tous les paramètres à l’aide d’une seule commande :

sudo CTX_XDL_NON_DOMAIN_JOINED='n' \
CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest \
CTX_XDL_DDC_LIST='<list-ddc-fqdns>' \
CTX_XDL_VDI_MODE='y|n' \
CTX_XDL_HDX_3D_PRO='y|n' \
CTX_XDL_START_SERVICE='y|n' \
CTX_XDL_REGISTER_SERVICE='y|n' \
CTX_XDL_ADD_FIREWALL_RULES='y|n' \
CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|xfce|'<none>' \
CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>' \
CTX_XDL_VDA_PORT='<port-number>' \
CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>' \
CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>' \
CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>' \
CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n' \
/opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->

Supprimer les modifications de configuration

Dans certains scénarios, vous devrez peut-être supprimer les modifications de configuration apportées par le script ctxsetup.sh sans désinstaller le package Linux VDA.

Consultez l’aide concernant ce script avant de continuer :

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

Pour supprimer les modifications de configuration :

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->

Important :

Ce script supprime toutes les données de configuration de la base de données et rend le Linux VDA inopérant.

Journaux de configuration

Les scripts ctxsetup.sh et ctxcleanup.sh affichent les erreurs sur la console, avec des informations supplémentaires écrites dans le fichier journal de configuration /tmp/xdl.configure.log.

Redémarrez les services Linux VDA pour que les modifications prennent effet.

Étape 9 : Exécuter XDPing

Exécutez sudo /opt/Citrix/VDA/bin/xdping pour vérifier les problèmes de configuration courants dans un environnement Linux VDA. Pour plus d’informations, consultez XDPing.

Étape 10 : Exécuter le Linux VDA

Après avoir configuré le Linux VDA à l’aide du script ctxsetup.sh, vous pouvez exécuter les commandes suivantes pour contrôler le Linux VDA.

Démarrer le Linux VDA :

Pour démarrer les services Linux VDA :

sudo systemctl restart ctxhdx

sudo systemctl restart ctxvda
<!--NeedCopy-->

Arrêter le Linux VDA :

Pour arrêter les services Linux VDA :

sudo systemctl stop ctxvda

sudo systemctl stop ctxhdx
<!--NeedCopy-->

Remarque :

Avant d’arrêter les services ctxvda et ctxhdx, exécutez la commande systemctl stop ctxmonitord pour arrêter le démon du service de surveillance. Sinon, le démon du service de surveillance redémarre les services que vous avez arrêtés.

Redémarrer le Linux VDA :

Pour redémarrer les services Linux VDA :

sudo systemctl stop ctxvda

sudo systemctl restart ctxhdx

sudo systemctl restart ctxvda
<!--NeedCopy-->

Vérifier l’état du Linux VDA :

Pour vérifier l’état d’exécution des services Linux VDA :

sudo systemctl status ctxvda

sudo systemctl status ctxhdx
<!--NeedCopy-->

Étape 11 : Créer des catalogues de machines

Le processus de création de catalogues de machines et d’ajout de machines Linux VDA est similaire à l’approche traditionnelle des VDA Windows. Pour une description plus détaillée de la façon d’accomplir ces tâches, consultez Créer des catalogues de machines et Gérer les catalogues de machines.

Pour la création de catalogues de machines contenant des machines Linux VDA, il existe quelques restrictions qui différencient le processus de la création de catalogues de machines pour les machines Windows VDA :

  • Pour le système d’exploitation, sélectionnez :
    • L’option SE multi-session pour un modèle de livraison de bureaux partagés hébergés.
    • L’option SE mono-session pour un modèle de livraison de bureaux dédiés VDI.
  • Ne mélangez pas les machines Linux et Windows VDA dans le même catalogue de machines.

Remarque :

Les premières versions de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux ». Cependant, la sélection de l’option SE Windows Server ou SE Serveur implique un modèle de livraison de bureaux partagés hébergés équivalent. La sélection de l’option SE Windows Desktop ou SE Desktop implique un modèle de livraison d’un seul utilisateur par machine.

Conseil :

Lorsque vous rejoignez une machine supprimée au domaine Active Directory, supprimez la machine de son catalogue de machines et ajoutez-la à nouveau.

Étape 12 : Créer des groupes de mise à disposition

Le processus de création d’un groupe de mise à disposition et d’ajout de catalogues de machines contenant des machines Linux VDA est presque identique à celui des machines Windows VDA. Pour une description plus détaillée de la façon d’accomplir ces tâches, consultez Créer des groupes de mise à disposition.

Pour la création de groupes de mise à disposition contenant des catalogues de machines Linux VDA, les restrictions suivantes s’appliquent :

  • Assurez-vous que les utilisateurs et groupes AD que vous sélectionnez ont été correctement configurés pour se connecter aux machines Linux VDA.
  • N’autorisez pas la connexion d’utilisateurs non authentifiés (anonymes).
  • Ne mélangez pas le groupe de mise à disposition avec des catalogues de machines contenant des machines Windows.

Important :

La publication d’applications est prise en charge avec Linux VDA version 1.4 et ultérieure. Cependant, le Linux VDA ne prend pas en charge la mise à disposition de bureaux et d’applications sur la même machine.

Pour plus d’informations sur la création de catalogues de machines et de groupes de mise à disposition, consultez Citrix Virtual Apps and Desktops 7 2402 LTSR.

Installer le VDA Linux sur Amazon Linux 2, CentOS, RHEL et Rocky Linux manuellement
May 5, 2026
Contributeur: 
C C
May 5, 2026
Contributeur: 
C C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.