Installer manuellement Linux Virtual Delivery Agent pour RHEL/CentOS

Important :

Pour les nouvelles installations, nous vous recommandons d’utiliser Easy Install pour effectuer une installation rapide. Easy Install permet de gagner du temps et d’économiser de la main d’œuvre. Cette installation est également plus fiable que l’installation manuelle décrite dans cet article.

Étape 1 : préparer RHEL 7/CentOS 7, RHEL 6/CentOS 6 pour l’installation sur un VDA

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

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

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

Pour vous assurer que le nom d’hôte de la machine est indiqué correctement, modifiez le fichier /etc/hostname (pour RHEL 7 et CentOS 7) ou le fichier /etc/sysconfig/network (pour RHEL 6 et CentOS 6) pour qu’il contienne uniquement 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 indiqués correctement, modifiez la ligne suivante du fichier /etc/hosts afin que celle-ci inclue le nom de domaine complet et le nom d’hôte dans 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 Linux VDA ne prend actuellement pas en charge la troncation de noms NetBIOS. Par conséquent, le nom d’hôte ne doit pas comporter plus de 15 caractères.

Conseil :

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

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

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

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 nom de domaine complet est correctement configuré :

hostname -f
<!--NeedCopy-->

Cette commande renvoie le nom de domaine complet de la machine.

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

Vérifiez que vous pouvez résoudre le nom de domaine complet et effectuer un sondage 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 pouvez pas résoudre le nom de domaine complet ou effectuer un sondage ping sur l’une de ces machines, reprenez les étapes avant de continuer.

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

Il est très important de maintenir la synchronisation de l’horloge entre les VDA, les Delivery Controller et les contrôleurs de domaine. L’hébergement du Linux VDA en tant que machine virtuelle peut entraîner des problèmes de décalage d’horloge. Pour cette raison, il est recommandé de synchroniser l’heure avec un service de temps à distance.

RHEL 6.x et versions antérieures utilisent le démon NTP (ntpd) pour la synchronisation d’horloge, tandis qu’un environnement RHEL 7.x par défaut utilise le démon Chrony le plus récent (chronyd). Le processus de configuration et de fonctionnement entre les deux services est similaire.

Configurer le service NTP (RHEL 6/CentOS 6 uniquement)

En tant qu’utilisateur racine, modifiez /etc/ntp.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 type, synchronisez l’heure depuis les contrôleurs de domaine locaux et non pas directement depuis des serveurs de pool NTP publics. Ajoutez une entrée de serveur pour chaque contrôleur de domaine Active Directory du domaine.

Supprimez toute autre entrée de serveur répertoriée, y compris les entrées d’adresse IP de bouclage, localhost et *.pool.ntp.org de serveur public.

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

sudo /sbin/service ntpd restart
<!--NeedCopy-->

Configurer le service NTP (RHEL 7/CentOS 7 uniquement)

En tant qu’utilisateur racine, 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 type, synchronisez l’heure depuis les contrôleurs de domaine locaux et non pas directement depuis des serveurs de pool NTP publics. Ajoutez une entrée de serveur pour chaque contrôleur de domaine Active Directory du domaine.

Supprimez toute autre entrée de serveur répertoriée, y compris les entrées d’adresse IP de bouclage, localhost et *.pool.ntp.org de serveur public.

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

sudo /sbin/service chronyd restart
<!--NeedCopy-->

Étape 1g : installer OpenJDK

Le Linux VDA dépend de OpenJDK. L’environnement d’exécution est généralement installé dans le cadre de l’installation du système d’exploitation.

Vérifiez que la version est correcte :

sudo yum info java-1.8.0-openjdk
<!--NeedCopy-->

Le OpenJDK préconditionné peut être une version antérieure. Mettez à jour vers la dernière version :

sudo yum -y update java-1.8.0-openjdk
<!--NeedCopy-->

Ouvrez un nouveau shell et vérifiez la version de Java :

java -version
<!--NeedCopy-->

Conseil :

Pour éviter les échecs d’enregistrement auprès du Delivery Controller, assurez-vous d’avoir installé uniquement OpenJDK 1.8.0. Supprimez toutes les autres versions de Java de votre système.

Étape 1h : installer PostgreSQL

Linux VDA requiert PostgreSQL 8.4 ou version ultérieure sur RHEL 6 ou PostgreSQL 9.2 ou version ultérieure sur RHEL 7.

Installez les packages suivants :

sudo yum -y install postgresql-server

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

L’étape de post-installation suivante est requise pour initialiser la base de données et s’assurer que le service est lancé au démarrage de la machine. Cette opération crée les fichiers de base de données sous /var/lib/pgsql/data. Cette commande diffère entre PostgreSQL 8 et 9 :

• RHEL 7 uniquement : PostgreSQL 9

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

• RHEL 6 uniquement : PostgreSQL 8

sudo /sbin/service postgresql initdb
<!--NeedCopy-->

Étape 1i : démarrer PostgreSQL

Une fois la machine démarrée, démarrez le service immédiatement :

• RHEL 7 uniquement : PostgreSQL 9

sudo systemctl enable postgresql

sudo systemctl start postgresql
<!--NeedCopy-->

• RHEL 6 uniquement : PostgreSQL 8

sudo /sbin/chkconfig postgresql on

sudo /sbin/service postgresql start
<!--NeedCopy-->

Vérifiez la version de PostgreSQL avec :

psql --version
<!--NeedCopy-->

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-->

Important :

Dans cette version, une nouvelle dépendance pour gperftools-libs a été ajoutée, mais elle n’existe pas dans le référentiel d’origine. Ajoutez le référentiel à l’aide de la commande sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm.
Seul RHEL 6/CentOS 6 est affecté. Exécutez la commande suivante avant l’installation du package Linux VDA.

Étape 2 : préparer l’hyperviseur

Certaines modifications sont requises pour 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 utilisez la machine Linux sur un matériel bare metal.

Corriger la synchronisation de l’heure sur Citrix Hypervisor

Si la fonctionnalité de synchronisation de l’heure de Citrix Hypervisor est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car NTP et Citrix Hypervisor tenteront de gérer l’horloge du système. Pour éviter que l’horloge ne soit plus synchronisée avec d’autres serveurs, assurez-vous l’horloge du système de chaque invité Linux est synchronisée avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte. Aucune modification n’est requise en mode HVM.

Sur certaines distributions Linux, si vous utilisez un noyau Linux paravirtualisé avec le composant Citrix VM Tools installé, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure de Citrix Hypervisor est présente et activée à partir de la VM 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 action n’est requise.

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

Si la fonctionnalité de synchronisation est désactivée, désactivez-la en entrant 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 VM Linux sur lesquelles Hyper-V Integration Services est installé peuvent tirer parti de la fonctionnalité de synchronisation de l’heure Hyper-V pour utiliser l’heure du système d’exploitation hôte. Pour vous assurer que l’horloge du système est toujours précise, cette fonctionnalité doit être activée avec 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 Integration Services.
3. Assurez-vous que Time synchronization est sélectionné.

Remarque :

Cette approche diffère de VMware et Citrix Hypervisor, pour lesquels la synchronisation de l’heure est désactivée pour éviter tout conflit avec NTP. La synchronisation de l’heure Hyper-V peut co-exister avec la synchronisation de l’heure NTP.

Corriger la synchronisation de l’heure sur ESX et ESXi

Si la fonctionnalité de synchronisation de l’heure de VMware est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car l’hyperviseur et NTP tenteront de synchroniser l’horloge du système. Pour éviter que l’horloge ne soit plus synchronisée avec d’autres serveurs, assurez-vous l’horloge du système de chaque invité Linux est synchronisée avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte.

Si vous exécutez un noyau Linux paravirtualisé sur lequel VMware Tools est installé :

1. Ouvrez vSphere Client.
2. Modifiez les paramètres pour la VM Linux.
3. Dans la boîte de dialogue Virtual Machine Properties (Propriétés de la machine virtuelle), ouvrez l’onglet Options.
4. Sélectionnez VMware Tools.
5. Dans la zone Advanced (Avancé), désélectionnez Synchronize guest time with host (Synchroniser l’heure de l’invité avec l’hôte).

Étape 3 : ajouter la machine virtuelle (VM) Linux au domaine Windows

Le Linux VDA prend en charge plusieurs méthodes pour ajouter des machines Linux au domaine Active Directory (AD) :

• Samba Winbind
• Quest Authentication Services
• Centrify DirectControl
• SSSD
• PBIS (compatible avec RHEL 7 uniquement)

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

Installez ou mettez à jour les packages requis :

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

Activer le démon Winbind pour qu’il soit lancé au démarrage de la machine

Le démon Winbind doit être configuré pour être lancé 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 :

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 domaine Kerberos en majuscules et domain est le nom NetBIOS du domaine.

Si des recherches DNS sur le nom de domaine et de serveur KDC sont requises, ajoutez les options suivantes à la commande précédente :

--enablekrb5kdcdns --enablekrb5realmdns

Ignorez les erreurs renvoyées par la commande authconfig sur l’échec du démarrage du service winbind. Ces erreurs se produisent lorsque authconfig essaie de démarrer le service winbind sans que la machine ait rejoint le domaine.

Ouvrez /etc/samba/smb.conf et ajoutez les entrées suivantes dans 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

Linux VDA exige l’authentification et l’enregistrement du fichier keytab système /etc/krb5.keytab auprès du Delivery Controller. Le paramètre kerberos method précédent force Winbind à créer le fichier keytab système lorsque la machine rejoint le domaine.

Rejoindre 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 :

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

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

Configurer PAM pour Winbind

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

krb5_auth = yes
krb5_ccache_type = FILE
mkhomedir = yes

Assurez-vous que les points-virgules de début de chaque paramètre sont supprimés. Ces modifications requièrent un redémarrage du démon Winbind :

sudo /sbin/service winbind restart
<!--NeedCopy-->

Conseil :

Le démon winbind ne reste en cours d’exécution que si la machine est associée à un domaine.

Ouvrez /etc/krb5.conf et modifiez le paramètre suivant dans la section [libdefaults], remplacez le type KEYRING par le type FILE :

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

Vérifier l’appartenance à un domaine

Le composant 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 si la machine est associée à un domaine :

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

Exécutez la commande suivante pour vérifier les informations d’objet de domaine et d’ordinateur supplémentaires :

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

Vérifier la configuration de Kerberos

Pour vous assurer que Kerberos est correctement configuré pour être utilisé avec le Linux VDA, 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 principaux et de suites de chiffrement. Exécutez la commande kinit Kerberos 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 placé dans une séquence d’échappement avec une barre oblique inversée (\) pour empêcher le remplacement 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, aucun résultat n’est affiché.

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

sudo klist
<!--NeedCopy-->

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

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

Vérifier l’authentification utilisateur

Utilisez l’outil wbinfo pour vérifier que les utilisateurs de domaine peuvent s’authentifier auprès du domaine :

wbinfo --krb5auth=domain\username%password
<!--NeedCopy-->

Le domaine spécifié ici est le nom de domaine Active Directory, et non le nom de domaine Kerberos. Pour le shell bash, la barre oblique inverse (\) doit être placée dans une séquence d’échappement 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é, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.

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

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

klist
<!--NeedCopy-->

Quittez la session.

exit
<!--NeedCopy-->

Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome. Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.

Quest Authentication Services

Configurer Quest sur le contrôleur de domaine

Cette procédure suppose que vous avez installé et configuré le logiciel Quest sur les contrôleurs de domaine Active Directory et disposez des droits Administrateur pour créer des objets ordinateur dans Active Directory.

Autoriser les utilisateurs de domaine à ouvrir une session sur des machines Linux VDA

Pour autoriser les utilisateurs de domaine à établir des sessions HDX sur une machine Linux VDA :

1. Dans la console de gestion Utilisateurs et ordinateurs Active Directory, ouvrez les propriétés de l’utilisateur Active Directory pour ce compte d’utilisateur.
2. Sélectionnez l’onglet Unix Account.
3. Sélectionnez Unix-enabled.
4. Définissez Primary GID Number sur l’ID d’un groupe d’utilisateurs de domaine.

Remarque :

Ces instructions sont les mêmes que pour la configuration d’utilisateurs de domaine pour l’ouverture de session à l’aide de la console, RDP, SSH ou tout autre protocole de communication à distance.

Configurer Quest sur un Linux VDA

Solution à l’application forcée de la stratégie SELinux

L’environnement RHEL par défaut applique entièrement SELinux. Cette mise en œuvre interfère avec les mécanismes IPC de socket de domaine Unix utilisés par Quest et empêche les utilisateurs de domaine d’ouvrir une session.

Le moyen pratique de remédier à ce problème consiste à désactiver SELinux. En tant qu’utilisateur racine, modifiez /etc/selinux/config en modifiant le paramètre SELinux :

SELINUX=permissive

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

reboot
<!--NeedCopy-->

Important :

Utilisez ce paramètre avec précaution. La réactivation de l’application forcée de la stratégie SELinux après sa désactivation peut entraîner un verrouillage complet, même pour l’utilisateur racine et d’autres utilisateurs locaux.

Configurer le démon VAS

Le renouvellement automatique des tickets Kerberos doit être activé et déconnecté. L’authentification (ouverture de session en mode déconnecté) 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 sur 9 heures (32 400 secondes), ce qui représente une heure de moins que la valeur par défaut de 10 heures pour la durée de vie d’un ticket. Définissez ce paramètre sur une valeur inférieure sur les systèmes avec une durée de vie de ticket plus courte.

Configuration de PAM et de NSS

Pour permettre l’ouverture de session d’utilisateur de domaine via HDX et d’autres services tels que su, ssh et RDP, exécutez les commandes suivantes pour configurer manuellement PAM et NSS :

sudo /opt/quest/bin/vastool configure pam

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

Rejoindre un 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 un utilisateur de domaine disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom DNS du domaine, par exemple, exemple.com.

Vérifier l’appartenance à un domaine

Le composant 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 associée à Quest se trouve sur le domaine :

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

Si la machine est associée à un domaine, cette commande renvoie le nom de domaine. Si la machine n’est pas associée à un 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 utilisateur

Pour vérifier que Quest peut authentifier les utilisateurs de domaine via PAM, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.

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

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

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

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

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

Quittez la session.

exit
<!--NeedCopy-->

Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome. Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.

Centrify DirectControl

Rejoindre un domaine Windows

Une fois Centrify DirectControl Agent installé, associez 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 user est un utilisateur de domaine Active Directory disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom du domaine auquel associer la machine Linux.

Vérifier l’appartenance à un domaine

Le composant 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 associée à Centrify se trouve sur le domaine :

su –
adinfo
<!--NeedCopy-->

Vérifiez que la valeur Joined to domain est valide et que le mode CentrifyDC renvoie connected. 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 plus complètes sur le système et les diagnostics sont disponibles à l’aide de :

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

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

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

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

SSSD

Si vous utilisez SSSD, suivez les instructions de cette section. Cette section comprend des instructions permettant de connecter une machine Linux VDA à un domaine Windows et des indications sur la configuration de l’authentification Kerberos.

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

1. Rejoindre le domaine et créer un fichier keytab hôte
2. Configurer SSSD
3. Configurer NSS/PAM
4. Vérifier la configuration de Kerberos
5. Vérifier l’authentification utilisateur

Logiciel requis

Le fournisseur Active Directory a été introduit avec SSSD version 1.9.0. Si vous utilisez une version antérieure, suivez les instructions fournies dans la section Configuration du fournisseur LDAP avec Active Directory.

Les environnements suivants ont été testés et vérifiés lors de l’utilisation des instructions figurant dans cet article :

• RHEL 7.7 et versions ultérieures
• CentOS 7.7 et versions ultérieures

Rejoindre le domaine et créer un fichier keytab hôte

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

Les informations contenues dans cette section décrivent l’approche Samba uniquement. Pour adcli et realmd, reportez-vous à la documentation de RHEL ou CentOS. Ces étapes doivent être suivies avant la configuration de SSSD.

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 Kerberos et Samba :

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

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

Si des recherches DNS sur le nom de domaine et de serveur KDC sont requises, ajoutez les options suivantes à la commande précédente :

--enablekrb5kdcdns --enablekrb5realmdns

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

kerberos method = secrets and keytab

Rejoignez 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 de domaine Kerberos en majuscules, et user est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter les ordinateurs au domaine.

Configurer SSSD

La configuration de SSSD comprend les étapes suivantes :

• Installez le package sssd-ad sur Linux VDA.
• Apportez des modifications de configuration à plusieurs fichiers (par exemple, sssd.conf).
• Démarrez le service sssd.

Exemple de configuration sssd.conf (des options supplémentaires peuvent être ajoutées si nécessaire) :

[sssd]
config_file_version = 2
domains = ad.example.com
services = nss, pam

[domain/ad.example.com]
# Uncomment if you need offline logins
# cache_credentials = true

id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = ad

# Should be specified as the lower-case version of the long version of the Active Directory domain.
ad_domain = ad.example.com

# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U

# Uncomment if service discovery is not working
# ad_server = server.ad.example.com

# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
<!--NeedCopy-->

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

Définissez les autorisations et les propriétaires du fichier sssd.conf :

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

Configurer NSS/PAM

RHEL/CentOS :

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

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

sudo service sssd start

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

Vérifier la configuration de Kerberos

Vérifiez que le fichier keytab système a été créé et qu’il 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 principaux et de suites de chiffrement. Exécutez la commande kinit Kerberos 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 placé dans une séquence d’échappement avec une barre oblique inversée (**\**) pour empêcher le remplacement 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, aucun résultat n’est affiché.

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 utilisateur

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

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

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

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

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

Pour vérifier que le module PAM SSSD est correctement configuré, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.

sudo ssh localhost –l DOMAIN\username

id -u
<!--NeedCopy-->

Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le UID renvoyé par la commande :

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

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

klist
<!--NeedCopy-->

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

PBIS

Télécharger le package PBIS requis

Par exemple :

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

Rendre le script d’installation PBIS exécutable

Par exemple :

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

Exécuter le script d’installation PBIS

Par exemple :

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

Rejoindre 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 :

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

L’utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom DNS du domaine, par exemple, exemple.com.

Remarque : pour définir Bash en tant que shell par défaut, exécutez la commande /opt/pbis/bin/config LoginShellTemplate/bin/bash.

Vérifier l’appartenance à un domaine

Le composant 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 associée à PBIS se trouve sur le domaine :

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

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

Vérifier l’authentification utilisateur

Pour vérifier que PBIS peut authentifier les utilisateurs de domaine via PAM, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.

ssh localhost -l domain\user

id -u
<!--NeedCopy-->

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

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

Quittez la session.

exit
<!--NeedCopy-->

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

Étape 4 : installer .NET Core Runtime en tant que condition préalable

Avant d’installer Linux VDA, installez .NET Core Runtime conformément aux instructions de l’article https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

• Pour la version initiale 1912 LTSR, CU1 et CU2, installez .NET Core Runtime 2.1.
• Pour les versions CU3 et ultérieures, installez .NET Core Runtime 3.1.

Après avoir installé .NET Core Runtime, 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 Core. 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

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 correspondant à votre distribution Linux.

Étape 6 : installer le Linux VDA

Vous pouvez effectuer une nouvelle installation ou effectuer une mise à niveau d’une installation existante à partir des deux versions précédentes et d’une version LTSR.

Pour effectuer une nouvelle installation

1. (Facultatif) Désinstaller 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 /sbin/service ctxvda stop  
      
      sudo /sbin/service ctxhdx stop
      <!--NeedCopy-->
      

      Remarque :

      Avant d’arrêter les services ctxvda et ctxhdx, exécutez la commande service ctxmonitorservice stop 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 d’accès complet est nécessaire ; vous pouvez ajouter /opt/Citrix/VDA/sbin et /opt/Citrix/VDA/bin au chemin du système.

2. Installer le Linux VDA

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

     Pour RHEL 7/CentOS 7 :

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

     Pour RHEL 6/CentOS 6 :

      sudo yum install -y XenDesktopVDA-19.12.0.50-1.el6_x.x86_64.rpm
      <!--NeedCopy-->
     

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

     Pour RHEL 7/CentOS 7 :

      sudo rpm -i XenDesktopVDA-19.12.0.50-1.el7_x.x86_64.rpm
      <!--NeedCopy-->
     

     Pour RHEL 6/CentOS 6 :

      sudo rpm -i XenDesktopVDA-19.12.0.50-1.el6_x.x86_64.rpm
      <!--NeedCopy-->
     

     Liste des dépendances RPM pour RHEL 7/CentOS 7 :

      postgresql-server >= 9.2
     
      postgresql-jdbc >= 9.2
     
      java-1.8.0-openjdk >= 1.8.0
     
      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
     
      libXpm >= 3.5.10
     
      libXrandr >= 1.4.1
     
      libXtst >= 1.2.2
     
      motif >= 2.3.4
     
      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
     
      openldap >= 2.4
     
      cyrus-sasl >= 2.1
     
      cyrus-sasl-gssapi >= 2.1
     
      libxml2 >= 2.9
     
      python-requests >= 2.6.0
     
      gperftools-libs >= 2.4
     
      rpmlib(FileDigests) <= 4.6.0-1
     
      rpmlib(PayloadFilesHavePrefix) <= 4.0-1
     
      pmlib(CompressedFileNames) <= 3.0.4-1
     
      rpmlib(PayloadIsXz) <= 5.2-1
      <!--NeedCopy-->
     

     Remarque :

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

     Liste des dépendances RPM pour RHEL 6/CentOS 6 :

      postgresql-jdbc >= 8.4
     
      postgresql-server >= 8.4
     
      java-1.8.0-openjdk >= 1.8.0
     
      ImageMagick >= 6.5.4.7
     
      GConf2 >= 2.28.0
     
      system-config-firewall-base >= 1.2.27
     
      policycoreutils-python >= 2.0.83
     
      xorg-x11-server-utils >= 7.7
     
      xorg-x11-xinit >= 1.0.9
     
      ConsoleKit >= 0.4.1
     
      dbus >= 1.2.24
     
      dbus-x11 >= 1.2.24
     
      libXpm >= 3.5.10
     
      libXrandr >= 1.4.1
     
      libXtst >= 1.2.2
     
      openmotif >= 2.3.3
     
      pam >= 1.1.1
     
      util-linux-ng >= 2.17.2
     
      bash >= 4.1
     
      findutils >= 4.4
     
      gawk >= 3.1
     
      sed >= 4.2
     
      cups >= 1.4.0
     
      foomatic >= 4.0.0
     
      openldap >= 2.4
     
      cyrus-sasl >= 2.1
     
      cyrus-sasl-gssapi >= 2.1
     
      libxml2 >= 2.7
     
      python-requests >= 2.6.0
     
      gperftools-libs >= 2.0
     
      rpmlib(FileDigests) <= 4.6.0-1
     
      rpmlib(PayloadFilesHavePrefix) <= 4.0-1
     
      rpmlib(CompressedFileNames) <= 3.0.4-1
     
      rpmlib(PayloadIsXz) <= 5.2-1
      <!--NeedCopy-->
     

Remarque :

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

Pour effectuer une mise à niveau d’une installation existante

Vous pouvez effectuer une mise à niveau d’une installation existante à partir des deux versions précédentes et d’une version LTSR.

• Pour effectuer une mise à niveau de votre logiciel à l’aide de Yum :

  Pour RHEL 7/CentOS 7 :

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

  Pour RHEL 6/CentOS 6 :

   sudo yum  install -y XenDesktopVDA-19.12.0.50-1.el6_x.x86_64.rpm
   <!--NeedCopy-->
  

• Pour effectuer une mise à niveau de votre logiciel à l’aide du gestionnaire de package RPM :

  Pour RHEL 7/CentOS 7 :

   sudo rpm -U XenDesktopVDA-19.12.0.50-1.el7_x.x86_64.rpm
   <!--NeedCopy-->
  

  Pour RHEL 6/CentOS 6 :

   sudo rpm -U XenDesktopVDA-19.12.0.50-1.el6_x.x86_64.rpm
   <!--NeedCopy-->
  

Important :

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

Étape 7 : installer les pilotes NVIDIA GRID

Pour activer HDX 3D Pro, vous devez installer les pilotes NVIDIA GRID sur votre hyperviseur et sur les machines VDA.

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

• Citrix Hypervisor
• VMware ESX

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

1. Assurez-vous que la VM invitée est arrêtée.
2. Dans XenCenter, attribuez 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 décrites dans le document Red Hat Enterprise Linux pour installer les pilotes NVIDIA GRID.

Remarque :

Pendant l’installation du pilote GPU, sélectionnez la valeur par défaut (no) pour chaque question.

Important :

Une fois la fonctionnalité GPU pass-through activée, la VM Linux n’est plus accessible via XenCenter. Utilisez SSH pour vous connecter.

Définissez la configuration correcte pour la carte :

etc/X11/ctx-nvidia.sh

Pour bénéficier des résolutions élevées et des capacités multi-écrans, vous avez besoin d’une licence NVIDIA valide. Pour appliquer la licence, suivez les instructions de la documentation du produit, « GRID Licensing Guide.pdf - DU-07757-001 Septembre 2015 ».

Étape 8 : configurer le Linux VDA

Après l’installation du 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 exécuter le script à tout moment pour modifier les paramètres.

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

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

Configuration avec invites

Exécutez une configuration manuelle avec questions :

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

Configuration automatique

Pour une installation automatique, fournissez les options requises par le script d’installation avec des variables d’environnement. Si toutes les variables requises sont présentes, le script n’invite pas à entrer des informations.

Les variables d’environnement prises en charge sont les suivantes :

• 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. La valeur est définie par défaut sur N.
• CTX_XDL_DDC_LIST=’list-ddc-fqdns’ : le Linux VDA requiert une liste séparée par des espaces de noms de domaines complets de Delivery Controller. Cette dernière sera utilisée pour l’enregistrement auprès d’un Delivery Controller. Au moins un alias de nom de domaine complet (FQDN) ou CNAME doit être spécifié.
• CTX_XDL_VDA_PORT = port-number : le Linux VDA communique avec les Delivery Controller à l’aide d’un port (80 par défaut) TCP/IP.
• CTX_XDL_REGISTER_SERVICE = Y | N : les services Linux Virtual Desktop sont lancés après le démarrage de la machine. La valeur est définie sur Y par défaut.
• CTX_XDL_ADD_FIREWALL_RULES=Y | N : les services Linux Virtual Desktop requièrent que les connexions réseau entrantes soient autorisées via le pare-feu du système. Vous pouvez ouvrir automatiquement les ports requis (ports 80 et 1494 par défaut) dans le pare-feu du système pour Linux Virtual Desktop. Valeur définie sur Y par défaut.
• CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 |5 : le Linux VDA requiert que les paramètres de configuration Kerberos s’authentifient auprès des Delivery Controller. La configuration de Kerberos est déterminée depuis l’outil d’intégration d’Active Directory installé et configuré sur le système. Spécifiez la méthode d’intégration d’Active Directory prise en charge à utiliser :
  • 1 – Samba Winbind
  • 2 – Quest Authentication Services
  • 3 – Centrify DirectControl
  • 4 – SSSD
  • 5 – PBIS
• CTX_XDL_HDX_3D_PRO=Y | N : Linux VDA prend en charge HDX 3D Pro, un ensemble de technologies d’accélération GPU conçues pour optimiser la virtualisation des applications riches en graphiques. Si HDX 3D Pro est sélectionné, le Virtual Delivery Agent doit être configuré pour le mode Bureaux VDI (session unique), c’est-à-dire, CTX_XDL_VDI_MODE=Y.
• CTX_XDL_VDI_MODE=Y | N : indique si la machine est configurée comme modèle de mise à disposition de bureaux dédiés (VDI) ou comme modèle de mise à disposition de bureaux partagés hébergés. Pour les environnements HDX 3D Pro, définissez cette variable sur Y. Elle est définie par défaut sur N.
• CTX_XDL_SITE_NAME=dns-name : le Linux VDA découvre les serveurs LDAP à l’aide de DNS. Pour limiter les résultats de recherche DNS à un site local, spécifiez un nom de site DNS. Cette variable est définie sur <none> par défaut.
• CTX_XDL_LDAP_LIST=’list-ldap-servers’ : le Linux VDA envoie une requête vers le DNS pour découvrir les serveurs LDAP. Si DNS ne peut pas fournir d’enregistrements de service LDAP, vous pouvez entrer une liste séparée par des espaces de noms de domaines complets LDAP avec port LDAP. Par exemple, ad1.mycompany.com:389. Cette variable est définie sur <none> par défaut.
• CTX_XDL_SEARCH_BASE=search-base-set : le Linux VDA envoie une requête à LDAP via une base de recherche définie sur la racine du domaine Active Directory (par exemple, D, 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). Cette variable est définie sur <none> par défaut.
• CTX_XDL_FAS_LIST=’list-fas-servers’ : les serveurs du service d’authentification fédérée (FAS) sont configurés via la stratégie de groupe AD. Comme le Linux VDA ne prend pas en charge la stratégie de groupe AD, vous pouvez fournir une liste de serveurs FAS séparés par des points-virgules. La séquence doit être la même que celle configurée dans la stratégie de groupe AD. Si une adresse de serveur est supprimée, remplissez son espace vide avec la chaîne de texte <none> et conservez la séquence d’adresses du serveur sans effectuer de modification.
• CTX_XDL_DOTNET_ runtime_path=Path-to-install-dotnet-runtime : chemin d’accès à l’installation de .NET Core Runtime pour la prise en charge du nouveau Broker Agent Service (ctxvda). Le chemin par défaut est /usr/bin.
• CTX_XDL_START_SERVICE = Y | N : indique si les services Linux VDA sont lancés lorsque la configuration de Linux VDA est terminée. Valeur définie sur Y par défaut.

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

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST='list-ddc-fqdns'

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4|5

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

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_FAS_LIST='list-fas-servers' | '<none>'

export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime

export CTX_XDL_START_SERVICE=Y|N

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

Lors de l’exécution de la commande sudo, entrez l’option -E pour transmettre les variables d’environnement au nouveau shell créé. Citrix vous recommande de créer un fichier de script shell à partir des commandes précédentes avec #!/bin/bash en tant que première ligne.

Vous pouvez également spécifier tous les paramètres avec une seule commande :

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST='list-ddc-fqdns' \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4|5 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST='list-ldap-servers' \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST='list-fas-servers' \

CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \

CTX_XDL_START_SERVICE=Y|N \

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

Supprimer les modifications de configuration

Dans certains scénarios, il peut être nécessaire de supprimer les modifications de configuration effectuées par le script ctxsetup.sh sans désinstaller le package Linux VDA.

Consultez l’aide sur 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 empêche Linux VDA de fonctionner.

Journaux de configuration

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

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

Étape 9 : exécuter XDPing

Nous fournissons un utilitaire de ligne de commande, l’outil XDPing Linux, pour vérifier les problèmes de configuration courants avec un environnement VDA Linux. Vous pouvez installer le package XDPing sur n’importe quelle machine exécutant une distribution Linux prise en charge. XDPing ne nécessite pas l’installation du package Linux VDA sur la machine. Pour plus d’informations sur l’outil, consultez l’article CTX202015 du centre de connaissances.

Étape 10 : exécuter le Linux VDA

Une fois que vous avez configuré Linux VDA à l’aide du script ctxsetup.sh, utilisez les commandes suivantes pour contrôler Linux VDA.

Démarrer Linux VDA :

Pour démarrer les services Linux VDA :

sudo /sbin/service ctxhdx start

sudo /sbin/service ctxvda start
<!--NeedCopy-->

Arrêter Linux VDA :

Pour arrêter les services Linux VDA :

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop
<!--NeedCopy-->

Remarque :

Avant d’arrêter les services ctxvda et ctxhdx, exécutez la commande service ctxmonitorservice stop 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 Linux VDA :

Pour redémarrer les services Linux VDA :

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

sudo /sbin/service ctxvda start
<!--NeedCopy-->

Vérifier l’état de Linux VDA :

Pour vérifier l’état de fonctionnement des services de Linux VDA :

sudo /sbin/service ctxvda status

sudo /sbin/service ctxhdx status
<!--NeedCopy-->

Étape 11 : créer le catalogue de machines dans Citrix Virtual Apps ou Citrix Virtual Desktops

Le processus de création de catalogues de machines et d’ajout de machines Linux VDA est similaire à l’approche traditionnelle avec les VDA Windows. Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, consultez les sections Créer des catalogues de machines et Gérer des catalogues de machines.

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

• Pour le système d’exploitation, sélectionnez :
  • l’option OS à sessions multiples pour un modèle de mise à disposition de bureaux partagés hébergés ;
  • l’option OS mono-session pour un modèle de mise à disposition de bureaux dédiés VDI.
• Ne combinez pas de machines Linux VDA et Windows dans le même catalogue de machines.

Remarque :

Les versions antérieures de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux. » Toutefois, la sélection de l’option OS de serveur Windows ou OS de serveur implique un modèle de mise à disposition équivalent de bureaux partagés hébergés. La sélection de l’option OS de bureau Windows ou OS de bureau implique un modèle de mise à disposition d’un utilisateur unique par machine.

Conseil :

Si une supprimez une machine puis que vous la rejoignez au domaine Active Directory, vous devez supprimer et rajouter la machine au catalogue de machines.

Étape 12 : créer le groupe de mise à disposition dans Citrix Virtual Apps ou Citrix Virtual Desktops

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 aux machines VDA Windows. Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, consultez la section Créer des groupes de mise à disposition.

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

• Assurez-vous que les utilisateurs et les groupes AD que vous sélectionnez ont été correctement configurés pour l’ouverture de session sur les machines Linux VDA.
• N’autorisez pas l’ouverture de session d’utilisateurs non authentifiés (anonymes).
• Ne combinez 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 la version 1.4 de Linux VDA et les versions supérieures. Toutefois, 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 1912 LTSR.