Installation de l’agent de livraison virtuel Linux pour RHEL/CentOS

Vous pouvez choisir de suivre les étapes de cet article pour une installation manuelle ou d’utiliser l’installation facile pour une installation et une configuration automatiques. L’installation facile permet de gagner du temps et de réduire les efforts, et elle est moins sujette aux erreurs que l’installation manuelle.

Remarque :

Utilisez l’installation facile uniquement pour les nouvelles installations. N’utilisez pas l’installation facile pour mettre à jour une installation existante.

Étape 1 : Préparer RHEL 7/CentOS 7, RHEL 6/CentOS 6 pour l’installation du VDA

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

Citrix® recommande que le réseau soit connecté et configuré correctement avant de poursuivre.

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

Remarque :

L’agent de livraison virtuel Linux ne prend pas actuellement en charge la troncation des noms NetBIOS. Par conséquent, le nom d’hôte ne doit pas dépasser 15 caractères.

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=nom_hôte

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

Remarque :

L’agent de livraison virtuel Linux ne prend pas actuellement en charge la troncation des noms NetBIOS. Par conséquent, le nom d’hôte ne doit pas dépasser 15 caractères.

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 nom_hôte-fqdn nom_hôte 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 à nom_hôte-fqdn ou nom_hôte des autres entrées du fichier.

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 des 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 envoyer un ping au contrôleur de domaine et au 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 FQDN ou envoyer un ping à l’une de ces machines, examinez les étapes avant de poursuivre.

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

• Le maintien d’une synchronisation précise de l’horloge entre les VDA, les Delivery Controller et les contrôleurs de domaine est crucial. L’hébergement du VDA Linux en tant que machine virtuelle 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.

RHEL 6.x et les versions antérieures utilisent le démon NTP (ntpd) pour la synchronisation de l’horloge, tandis qu’un environnement RHEL 7.x par défaut utilise le nouveau démon Chrony (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 root, 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 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 NTP :

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

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

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 /sbin/service chronyd restart
<!--NeedCopy-->

Étape 1g : Installer OpenJDK

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

Confirmez la version correcte :

• RHEL 7/CentOS 7 :

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

• RHEL 6/CentOS 6 :

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

L’OpenJDK pré-packagé peut être une version antérieure. Mettez à jour vers la dernière version si nécessaire :

• RHEL 7/CentOS 7 :

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

• RHEL 6/CentOS 6 :

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

Définissez la variable d’environnement JAVA_HOME en ajoutant la ligne suivante au fichier ~/.bashrc :

export JAVA\_HOME=/usr/lib/jvm/java

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

java -version
<!--NeedCopy-->

Conseil :

Pour éviter les problèmes, assurez-vous d’avoir installé uniquement OpenJDK version 1.7.0 ou 1.8.0 dans le cas de RHEL 6/CentOS 6, ou uniquement OpenJDK version 1.8.0 dans le cas de RHEL 7/CentOS 7. Supprimez toutes les autres versions de Java de votre système.

Étape 1h : Installer PostgreSQL

Le VDA Linux nécessite 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 démarre au démarrage de la machine. Cette action crée des fichiers de base de données sous /var/lib/pgsql/data. La commande diffère entre PostgreSQL 8 et PostgreSQL 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

Démarrez le service au démarrage de la machine et 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 en utilisant :

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 est ajoutée pour gperftools-libs, mais elle n’existe pas dans le référentiel d’origine. Ajoutez un nouveau référentiel à l’aide de la commande sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm. Seuls RHEL 6/CentOS 6 sont concernés. Exécutez la commande avant d’installer le package VDA Linux.

Étape 2 : Préparer l’hyperviseur

Certaines modifications sont requises lors de l’exécution du VDA Linux 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 Citrix XenServer®

Lorsque la fonctionnalité de synchronisation de l’heure XenServer est activée, au sein de chaque machine virtuelle Linux paravirtualisée, vous rencontrez des problèmes avec le NTP et le XenServer, qui tentent tous deux 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.

Sur certaines distributions Linux, si vous exécutez un noyau Linux paravirtualisé avec les outils XenServer installés, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure 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/indepent_wallclock n’est pas présent, les étapes suivantes ne sont pas requises.

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 un 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 Linux Hyper-V 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 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, où la synchronisation de l’heure de l’hôte est désactivée pour éviter les conflits avec le 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, au sein de chaque machine virtuelle Linux paravirtualisée, vous rencontrez des problèmes avec le NTP et l’hyperviseur, qui tentent tous deux 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 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 (VM) Linux au domaine Windows

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

• Samba Winbind
• Quest Authentication Service
• Centrify DirectControl
• SSSD

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 VDA Linux et le compte dans AD.

Samba Winbind

Installer ou mettre à jour les paquets requis :

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir
<!--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 :

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

Ignorez toute erreur renvoyée par la commande authconfig concernant l’échec du démarrage du service winbind. Ces erreurs peuvent survenir lorsque authconfig tente de démarrer le service winbind sans que la machine ne soit encore jointe au domaine.

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

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 le 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 du royaume Kerberos en majuscules, et user est un utilisateur de domaine qui a les autorisations d’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 /sbin/service winbind restart
<!--NeedCopy-->

Conseil :

Le démon Winbind ne reste actif que 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}

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 configuré correctement 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 principaux 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, pas le nom de royaume 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 le succès ou l’échec.

Pour vérifier que le module PAM Winbind est configuré correctement, utilisez un compte utilisateur de domaine pour vous connecter au VDA Linux. Le compte utilisateur de domaine n’a pas é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 non expirés :

klist
<!--NeedCopy-->

Quitter la session :

exit
<!--NeedCopy-->

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

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

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

Permettre aux utilisateurs de domaine de se connecter aux machines Linux VDA

Pour permettre aux utilisateurs de domaine d’é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 Compte Unix.
3. Cochez la case 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, RDP, SSH ou tout autre protocole d’accès à distance.

Configurer Quest sur Linux VDA

Contourner l’application de la politique SELinux

L’environnement RHEL par défaut a SELinux entièrement appliqué. 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 changez 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 du ticket 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 manuellement PAM et NSS :

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 un utilisateur de domaine qui dispose des autorisations pour joindre des ordinateurs au domaine Active Directory. Le nom-de-domaine est le nom DNS du domaine, par exemple, example.com.

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 du 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, utilisez un compte d’utilisateur de domaine pour vous connecter au Linux VDA. Le compte d’utilisateur de domaine n’a pas é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 se connectant directement à la console Gnome ou KDE. Passez à l’Étape 4 : Installer le Linux VDA après la vérification de la jonction au domaine.

Centrify DirectControl

Joindre le 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 qui dispose des autorisations 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) aient 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 « 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 système et de diagnostic plus complètes sont disponibles en utilisant :

adinfo --sysinfo all

adinfo –diag
<!--NeedCopy-->

Testez la connectivité aux différents services Active Directory et Kerberos. Passez à l’Étape 4 : Installer le Linux VDA après la vérification de la jonction au domaine.

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

SSSD

Si vous utilisez SSSD, suivez les instructions de cette section. Cette section comprend des instructions pour joindre une machine Linux VDA à 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. Joignez le domaine et créez un keytab d’hôte avec Samba
2. Configurez SSSD
3. Configurez NSS/PAM
4. Vérifiez la configuration Kerberos
5. Vérifiez l’authentification de l’utilisateur

Logiciels requis

Le fournisseur Active Directory a été introduit pour la première fois avec SSSD version 1.9.0. Si vous utilisez une version antérieure, suivez les instructions fournies dans configuration du fournisseur LDAP avec Active Directory.

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

• RHEL 7.3 ou version ultérieure/CentOS 7.3 ou version ultérieure
• Linux VDA version 1.3 ou version ultérieure

Joindre le domaine et créer un keytab hôte avec Samba

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

Les informations de cette section décrivent uniquement l’approche Samba. Pour realmd, consultez la documentation RHEL ou CentOS. Ces étapes doivent être suivies avant de configurer SSSD.

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 domain est le nom NetBIOS court du domaine Active Directory.

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

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 user est un utilisateur de domaine qui dispose des autorisations 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.
  • Apportez des modifications de configuration à divers 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, consultez la page de manuel Linux sssd-ad(5).

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

Configurer NSS/PAM

RHEL/CentOS :

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 service sssd start

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 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 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 de connexion est pris en charge et que NSS fonctionne :

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

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

Les formats de connexion pris en charge sont :

• Nom de connexion 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é, utilisez un compte utilisateur de domaine pour vous connecter au VDA Linux. Le compte utilisateur de domaine n’a pas é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é. Passez à l’Étape 4 : Installer le VDA Linux après la vérification de la jonction au domaine.

klist
<!--NeedCopy-->

Étape 4 : Installer le VDA Linux

Étape 4a : Désinstaller l’ancienne version

Si vous avez précédemment installé une version antérieure du VDA Linux, désinstallez-la avant d’installer la nouvelle version.

1. Arrêtez les services du VDA Linux :

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

2. Désinstallez le package :

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

Remarque :

La mise à niveau à partir des deux versions précédentes est prise en charge.

Remarque :

À partir de la version 1.3, le chemin d’installation a changé. Dans les versions précédentes, les composants d’installation se trouvaient dans /usr/local/. Le nouvel emplacement est /opt/Citrix/VDA/.

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

Étape 4b : Télécharger le package Linux VDA

Accédez au site web de Citrix et téléchargez le package Linux VDA approprié en fonction de votre distribution Linux.

Étape 4c : Installer le Linux VDA

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

-  **Pour RHEL 7/CentOS 7 :**

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.9 :

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.6/CentOS 6.6 :

    -  sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.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 RHEL 7/CentOS 7 :

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.9 :

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.6/CentOS 6.6 :

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Liste des dépendances RPM pour RHEL 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

xorg-x11-server-Xorg >= 1.17

xorg-x11-server-Xorg < 1.18

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->

Liste des dépendances RPM pour RHEL 6.9 :

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.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

xorg-x11-server-Xorg >= 1.17

xorg-x11-server-Xorg < 1.18

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->

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

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.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

xorg-x11-server-Xorg >= 1.15

xorg-x11-server-Xorg < 1.16

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->

Étape 4d : Mettre à niveau le Linux VDA (facultatif)

Vous pouvez mettre à niveau le logiciel Linux VDA à partir des versions 7.14 et 7.13 à l’aide de Yum :

Pour RHEL 7/CentOS 7 :

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.9 :

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.6/CentOS 6.6 :

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Mettez à niveau le logiciel Linux VDA à l’aide du gestionnaire de packages RPM :

Pour RHEL 7/CentOS 7 :

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.9 :

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Pour RHEL 6.6/CentOS 6.6 :

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Important :

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

Étape 5 : Installer les pilotes NVIDIA GRID

L’activation de HDX 3D Pro nécessite des étapes d’installation supplémentaires pour installer les pilotes graphiques requis sur l’hyperviseur et sur les machines VDA.

Configurez les éléments suivants :

1. Citrix XenServer
2. VMware ESX

Suivez les instructions de l’hyperviseur que vous avez choisi.

Citrix XenServer :

Cette section détaillée explique l’installation et la configuration des pilotes NVIDIA GRID sur Citrix XenServer.

VMware ESX :

Suivez les informations contenues dans ce guide pour installer et configurer les pilotes NVIDIA GRID pour VMware ESX.

Machines VDA :

Suivez ces étapes pour installer et configurer les pilotes pour chacun des invités de machine virtuelle Linux :

1. Avant de commencer, assurez-vous que la machine virtuelle Linux est arrêtée.
2. Dans XenCenter®, ajoutez un GPU en mode pass-through GPU à la machine virtuelle.
3. Démarrez la machine virtuelle RHEL.

Pour préparer la machine aux pilotes NVIDIA GRID, exécutez les commandes suivantes :

yum install gcc

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

systemctl set-default multi-user.target
<!--NeedCopy-->

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 pass-through GPU activé, la machine virtuelle 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 profiter des résolutions élevées et des capacités multi-écrans, vous avez besoin d’une licence NVIDIA valide. Pour demander la licence, suivez la documentation produit « GRID Licensing Guide.pdf - DU-07757-001 Septembre 2015 ».

Étape 6 : Configurer le VDA Linux

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 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 concernant 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 d’installation à l’aide de 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_SUPPORT_DDC_AS_CNAME = Y | N – Le VDA Linux prend en charge la spécification d’un nom de Delivery Controller à l’aide d’un enregistrement CNAME DNS. La valeur par défaut est N.
• CTX_XDL_DDC_LIST = list-ddc-fqdns – Le VDA Linux requiert 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 un alias CNAME doit être spécifié.
• CTX_XDL_VDA_PORT = port-number – Le VDA Linux communique avec les Delivery Controllers via un port TCP/IP, qui est le port 80 par défaut.
• CTX_XDL_REGISTER_SERVICE = Y | N - Les services Linux Virtual Desktop sont démarré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 nécessitent que les connexions réseau entrantes soient autorisées via le pare-feu système. Vous pouvez ouvrir automatiquement les ports requis (ports 80 et 1494 par défaut) dans le pare-feu système pour le Linux Virtual Desktop. La valeur par défaut est Y.
• CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 – Le VDA Linux requiert 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. Spécifiez la méthode d’intégration Active Directory prise en charge à utiliser :
  • 1 – Samba Winbind
  • 2 – Quest Authentication Service
  • 3 – Centrify DirectControl
  • 4 – SSSD
• 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 Virtual Delivery Agent est configuré pour le mode de bureaux VDI (session unique) – (c’est-à-dire, CTX_XDL_VDI_MODE=Y).
• CTX_XDL_VDI_MODE = Y | N – Permet de 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 cette variable sur Y. Cette variable est définie sur N par défaut.
• CTX_XDL_SITE_NAME = dns-name – Le VDA Linux découvre les serveurs LDAP via 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 VDA Linux 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 le 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 VDA Linux interroge LDAP via une base de recherche définie à 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). Cette variable est définie sur <none> par défaut.
• CTX_XDL_START_SERVICE = Y | N – Indique si les services VDA Linux sont démarrés une fois la configuration du VDA Linux terminée. La valeur par défaut est Y.

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

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-name

export CTX_XDL_LDAP_LIST=list-ldap-servers

export CTX_XDL_SEARCH_BASE=search-base-set

export CTX_XDL_START_SERVICE=Y|N

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

Lorsque vous exécutez la commande sudo, tapez l’option -E pour transmettre les variables d’environnement existantes au nouveau shell qu’elle crée. Citrix vous recommande 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_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 \

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_START_SERVICE=Y|N \

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

Supprimer les modifications de configuration

Dans certains scénarios, vous pourriez avoir à supprimer les modifications de configuration apportées par le script ctxsetup.sh sans désinstaller le package VDA Linux.

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 VDA Linux 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 VDA Linux pour que les modifications prennent effet.

Étape 7 : Exécuter le VDA Linux

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

Démarrer le VDA Linux :

Pour démarrer les services VDA Linux :

sudo /sbin/service ctxhdx start

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

Arrêter le VDA Linux :

Pour arrêter les services VDA Linux :

sudo /sbin/service ctxvda stop

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

Redémarrer le VDA Linux :

Pour redémarrer les services VDA Linux :

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

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

Vérifier l’état du VDA Linux :

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

sudo /sbin/service ctxvda status

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

Étape 8 : Créer le catalogue de machines dans XenApp ou XenDesktop®

Le processus de création de catalogues de machines et d’ajout de machines VDA Linux est similaire à l’approche traditionnelle du 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 VDA Linux, il existe quelques restrictions qui différencient le processus de la création de catalogues de machines pour les machines VDA Windows :

• Pour le système d’exploitation, sélectionnez :
  • L’option Système d’exploitation serveur pour un modèle de livraison de bureaux partagés hébergés.
  • L’option Système d’exploitation de bureau pour un modèle de livraison de bureau dédié VDI.
• Assurez-vous que les machines ne sont pas gérées par l’alimentation.
• Étant donné que MCS n’est pas pris en charge pour les VDA Linux, choisissez PVS ou la méthode de déploiement Autre service ou technologie (images existantes).
• Ne mélangez pas les machines VDA Linux et Windows 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 Système d’exploitation Windows Server ou Système d’exploitation serveur implique un modèle de livraison de bureaux partagés hébergés équivalent. La sélection de l’option Système d’exploitation de bureau Windows ou Système d’exploitation de bureau implique un modèle de livraison d’un seul utilisateur par machine.

Conseil :

Si vous supprimez une machine du domaine Active Directory et la rejoignez, vous devez la supprimer du catalogue de machines et l’y ajouter à nouveau.

Étape 9 : Créer le groupe de mise à disposition dans XenApp® ou XenDesktop

Le processus de création d’un groupe de mise à disposition et d’ajout de catalogues de machines contenant des machines VDA Linux est presque identique à celui des machines VDA Windows. 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 VDA Linux, les restrictions suivantes s’appliquent :

• Pour le type de mise à disposition, sélectionnez Bureaux ou Applications.
• 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 des utilisateurs non authentifiés (anonymes).
• Ne mélangez pas le groupe de mise à disposition avec des catalogues de machines qui contiennent 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.