Product Documentation

Installer Virtual Delivery Agent Linux pour RHEL/CentOS

Feb 26, 2018

Vous pouvez choisir de suivre les étapes ci-dessous pour l’installation manuelle ou utiliser Easy Install pour l’installation et la configuration automatique. Easy Install permet des gains de temps et de main d'œuvre et il est plus fiable que l’installation manuelle. 

Remarque : utilisez uniquement Easy Install pour des nouvelles installations. N’utilisez pas Easy Install pour mettre à jour une installation existante.

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

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

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

Étape 1b : définir le nom de l'hôte

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

HOSTNAME=nom d'hôte

Étape 1c : attribuer une adresse de bouclage au nom de l'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 pour qu'elle 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 VDA Linux 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 de l'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 de l'hôte

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

commande Copier

hostname

Renvoie uniquement le nom d'hôte de la machine et non pas son nom de domaine complet (FQDN).

Vérifiez que le nom de domaine complet est correctement configuré :

commande Copier

hostname -f

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

commande Copier

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn

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 VDA Linux 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 que root, modifiez /etc/ntp.conf et ajoutez une entrée de serveur pour chaque serveur de temps distant :

config Copier

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst

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

commande Copier

sudo /sbin/service ntpd restart

Configurer le service NTP (RHEL 7/CentOS uniquement)

Sous 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

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

commande Copier

sudo /sbin/service chronyd restart

Étape 1g : installer OpenJDK

Le VDA Linux 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 avec :

  • RHEL 7/CentOS 7 :
commande Copier

sudo yum info java-1.8.0-openjdk

  • RHEL 6/CentOS 6 :
commande Copier

sudo yum info java-1.7.0-openjdk

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

  • RHEL 7/CentOS 7 :
commande Copier

sudo yum -y update java-1.8.0-openjdk

  • RHEL 6/CentOS 6 :
commande Copier

sudo yum -y update java-1.7.0-openjdk

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 :

commande Copier

java –version

Conseil

Pour éviter les problèmes, assurez-vous que vous avez installé uniquement OpenJDK version 1.7.0 ou 1.8.0 pour RHEL 6/CentOS 6 ou uniquement OpenJDK version 1.8.0 pour RHEL 7/CentOS 7. Supprimez toutes les autres versions de Java de votre système.

Étape 1h : installer PostgreSQL

Le VDA Linux 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 :

commande Copier

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc

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. 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
commande Copier

sudo postgresql-setup initdb

  • RHEL 6 uniquement : PostgreSQL 8
commande Copier

sudo /sbin/service postgresql initdb

Étape 1i : démarrer PostgreSQL

Configurez le service pour qu'il soit lancé au démarrage et pour qu'il soit lancé maintenant :

  • RHEL 7 uniquement : PostgreSQL 9
commande Copier

sudo systemctl start postgresql

sudo systemctl enable postgresql

  • RHEL 6 uniquement : PostgreSQL 8
commande Copier

sudo /sbin/chkconfig postgresql on

sudo /sbin/service postgresql start

Vérifiez la version de PostgreSQL avec :

commande Copier

psql --version

Vérifiez que le répertoire de données est défini à l'aide de l'utilitaire de ligne de commande psql :

commande Copier

sudo -u postgres psql -c 'show data_directory'

Important

Dans cette version, nous avons ajouté une nouvelle dépendance pour gperftools-libs, mais elle n’existe pas dans le référentiel d’origine. Vous devez ajouter un nouveau référentiel avec la commande suivante :

sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

Ceci affecte uniquement RHEL 6 / CentOS 6 et vous devez exécuter la commande avant d’installer le package VDA Linux.

Étape 2 : préparer l'hyperviseur

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

Corriger la synchronisation de l'heure sur Citrix XenServer

Si la fonctionnalité de synchronisation de l'heure de XenServer est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car XenServer et NTP 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 XenServer Tools installé, vous pouvez vérifier si la fonctionnalité de synchronisation de l'heure de XenServer est présente et activée à partir de la VM Linux :

commande Copier

su -

cat /proc/sys/xen/independent_wallclock

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/indepent_wallclock n'est pas présent, les étapes suivantes ne sont pas requises.

Si cette option est activée, désactivez la fonctionnalité de synchronisation de l'heure en indiquant 1 dans le fichier :

commande Copier

sudo echo 1 > /proc/sys/xen/independent_wallclock

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

config Copier

xen.independent_wallclock = 1

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

commande Copier

su -

cat /proc/sys/xen/independent_wallclock

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 VM Linux, sélectionnez Integration Services
  3. Assurez-vous que Time synchronization est sélectionné. 

Remarque

Cette approche diffère de XenServer et VMware, 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, 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
  • Service d'authentification Quest
  • Centrify DirectControl
  • SSSD

Suivez les instructions ci-dessous pour 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 :

commande Copier

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir

Activer le lancement du démon Winbind au démarrage

Le démon Winbind doit être configuré pour être lancé au démarrage :

commande Copier

sudo /sbin/chkconfig winbind on

Configurer l'authentification Winbind

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

commande Copier

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

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 ci-dessus :

commande Copier

--enablekrb5kdcdns --enablekrb5realmdns

Ignorez les erreurs renvoyées par la commande authconfig sur l'échec du démarrage du service winbind. C'est parce que 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 :

config Copier

kerberos method = secrets and keytab

winbind refresh tickets = true

Le fichier keytab système /etc/krb5.keytab est requis par le VDA Linux pour s'authentifier et s'enregistrer auprès du Delivery Controller. Le paramètre kerberos method ci-dessus 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 :

commande Copier

sudo net ads join REALM -U user

Où 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] :

config Copier

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 :

commande Copier

sudo /sbin/service winbind restart

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 :

config Copier

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

Vérifier l'appartenance au domaine

Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory.

Exécutez la commandenet ads de Samba pour vérifier que la machine est associée à un domaine :

commande Copier

sudo net ads testjoin

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

commande Copier

sudo net ads info

Vérifier la configuration de Kerberos

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

commande Copier

sudo klist -ke

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 :

commande Copier

sudo kinit -k MACHINE\$@REALM

Les noms de machine et de domaine doivent être spécifiés en majuscules, et le signe dollar ($) doit être placé dans une séquence d'échappement avec une barre oblique inverse (\) 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 :

Code Copier

sudo klist

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

commande Copier

sudo net ads status

Vérifier l'authentification utilisateur

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

commande Copier

wbinfo --krb5auth=domain\\username%password

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 localement à l'aide d'un compte d'utilisateur de domaine qui ne s'est pas connecté à la machine précédemment :

commande Copier

ssh localhost -l domain\\username

id -u

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

commande Copier

klist

Quittez la session :

commande Copier

exit

Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome.

Service d'authentification Quest

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

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

  1. Dans la console de gestion Utilisateurs et ordinateurs Active Directory, ouvrez les propriétés de l'utilisateur Active Directory pour ce compte d'utilisateur.
  2. Sélectionnez l'onglet Unix Account.
  3. Sélectionnez la case 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 VDA Linux

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

L'environnement RHEL par défaut applique entièrement SELinux, ce qui 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.

Conseil

Il existe plusieurs façons de contourner ce problème, comme indiqué ici.

La plus facile consiste à désactiver SELinux. En tant que root, modifiez le paramètre SELinux dans /etc/selinux/config :

config Copier

SELINUX=permissive

Cette modification nécessite un redémarrage :

commande Copier

reboot

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

commande Copier

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

Ces commandes définissent l'intervalle de renouvellement sur 9 heures (32 400 secondes), ce qui est 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

Quest requiert la configuration manuelle de PAM et NSS pour permettre la connexion d'utilisateur de domaine via HDX et d'autres services tels que su, ssh et RDP. Pour configurer PAM et NSS :

commande Copier

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss

Rejoindre un domaine Windows

Associez la machine Linux au domaine Active Directory à l'aide de la commande vastool de Quest :

commande Copier

sudo /opt/quest/bin/vastool -u user join domain-name

L'utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le nom de domaine est le nom DNS du domaine ; par exemple, exemple.com.

Vérifier l'appartenance au domaine

Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory. Pour vérifier qu'une machine Linux associée à Quest se trouve sur le domaine :

commande Copier

sudo /opt/quest/bin/vastool info domain

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 :

Erreur Copier

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 à l'aide de PAM, ouvrez une session à l'aide d'un compte d'utilisateur de domaine qui ne s'est pas connecté à la machine précédemment :

commande Copier

ssh localhost -l domain\\username

id -u

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

commande Copier

ls /tmp/krb5cc_uid

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

commande Copier

/opt/quest/bin/vastool klist

Quittez la session :

commande Copier

exit

Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome.

Centrify DirectControl

Rejoindre un domaine Windows

Avec le Centrify DirectControl Agent installé, associez la machine Linux au domaine Active Directory à l'aide de la commande adjoin Centrify :

commande Copier

su – 

adjoin -w -V -u user domain-name

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

Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory. Pour vérifier qu'une machine Linux associée à Centrify se trouve sur le domaine :

commande Copier

su –

adinfo

Vérifiez que la valeur Joined to domain est valide et que CentrifyDC mode 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 :

commande Copier

adinfo --sysinfo all

adinfo –diag

Pour tester la connectivité avec les différents services Active Directory et Kerberos :

commande Copier

adinfo --test

SSSD

Utilisez les informations suivantes pour configurer SSSD ; elles comprennent des instructions permettant de connecter une machine VDA Linux à un domaine Windows et des indications sur la configuration de l'authentification Kerberos.

Remarque

Si vous utilisez SSSD, suivez les instructions contenues dans cet article, au lieu des informations fournies dans la section Ajouter une machine Linux au domaine Windows.

Qu’est-ce que SSSD ?

SSSD est un démon système. Sa fonction principale consiste à fournir un accès pour l'identification et l'authentification de ressources distantes par le biais d'une infrastructure commune qui peut fournir une mise en cache et un accès en mode déconnecté au système. Il propose des modules PAM et NSS et prendra en charge à l'avenir les interfaces D-BUS qui permettront d'obtenir davantage d'informations utilisateur. Il offre également une meilleure base de données pour stocker les utilisateurs locaux ainsi que les données utilisateur supplémentaires.

La configuration de SSSD sur RHEL et CentOS implique les étapes suivantes :

  1. Rejoindre le domaine et créer un fichier keytab hôte avec Samba
  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 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.3 ou version ultérieure/CentOS 7.3 ou version ultérieure
  • VDA Linux version 1.3 ou ultérieure

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

SSSD ne fournit pas de fonctions de client Active Directory pour rejoindre le domaine et gérer le fichier keytab système. Plusieurs méthodes sont disponibles, y compris :

  • adcli
  • realmd
  • winbind
  • samba

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

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 :

commande Copier

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

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 ci-dessus :

commande Copier

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

config Copier

kerberos method = secrets and  keytab

Pour rejoindre 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.

commande Copier

sudo net ads join REALM -U user

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 :

  • installer le package sssd-ad sur la machine cliente Linux
  • apporter des modifications de configuration à plusieurs fichiers (par exemple, sssd.conf)
  • démarrer le service sssd :

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

config Copier

[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

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

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

commande Copier

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 que la création du répertoire de base fonctionne avec SELinux :

commande Copier

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

sudo service sssd start

sudo chkconfig sssd on

Vérifier la configuration de Kerberos

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

commande Copier

sudo klist -ke

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 :

commande Copier

sudo kinit –k MACHINE\$@REALM

Les noms de machine et de domaine doivent être spécifiés en majuscules, et le signe dollar ($) doit être placé dans une séquence d'échappement avec une barre oblique inverse (\) 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 :

commande Copier

sudo klist

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 :

commande Copier

sudo getent passwd DOMAIN\\username

Le paramètre DOMAIN indique la version courte du nom de domaine. Si un autre format d'ouverture de session depuis Citrix Receiver est nécessaire, veuillez vérifier 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 : DOMAINE\nomutilisateur
  • UPN : utilisateur@domaine.com
  • Format suffixe NetBIOS : nomutilisateur@DOMAINE

Pour vérifier que le module PAM SSSD est correctement configuré, ouvrez une session localement à l'aide d'un compte d'utilisateur de domaine qui ne s'est pas connecté à la machine précédemment.

commande Copier

sudo ssh localhost –l DOMAIN\\username

id -u

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

commande Copier

ls /tmp/krb5cc_{uid}

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

commande Copier

klist

Installer les pilotes NVIDIA GRID

Pour activer HDX 3D Pro, des étapes d'installation supplémentaires sont requises pour installer les pilotes graphiques nécessaires sur l'hyperviseur, ainsi que sur les machines VDA.

Configurez ce qui suit :

  1. Citrix XenServer 
  2. VMware ESX

Suivez les instructions pour l'hyperviseur choisi.

Citrix XenServer

Cette section détaillée décrit 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 de VMware ESX.

Machines VDA

Suivez ces étapes pour installer et configurer les pilotes pour chaque invité de VM Linux :

  1. Avant de commencer, assurez-vous que la VM Linux est arrêtée.
  2. Dans XenCenter, ajoutez un processeur graphique en mode GPU Passthrough à la VM.
  3. Démarrez la VM RHEL.

Pour préparer la machine pour les pilotes NVIDIA GRID, les étapes suivantes sont requises :

commande Copier

yum install gcc

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

systemctl set-default multi-user.target

Une fois terminé, 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 que la fonctionnalité GPU Passthrough a été activée, la VM Linux n'est plus accessible via XenCenter, vous devez donc utiliser SSH pour vous connecter.

localized image

Définissez la configuration correcte pour la carte :

commande Copier

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 4 : installer le VDA Linux

Étape 4a : désinstaller l'ancienne version

Si vous avez déjà installé une version de VDA Linux antérieure à la version 1.0, désinstallez-la avant d'installer la nouvelle version.

(a) Arrêtez les services VDA Linux :

commande Copier

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

(b) Désinstallez le package :

commande Copier

sudo rpm -e XenDesktopVDA

Remarque

La mise à niveau à partir des deux dernières versions est prise en charge.

Remarque

À compter de la version 1.3, le chemin d'installation est différent. 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 d'accès complet est nécessaire ; vous pouvez ajouter  /opt/Citrix/VDA/sbin et /opt/Citrix/VDA/bin  au chemin du système.

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

Accédez au site Web de Citrix et téléchargez le package VDA Linux approprié à votre distribution Linux.

Étape 4c : installer le VDA Linux

Installer le logiciel VDA Linux à l'aide de Yum :

Pour RHEL 7/CentOS 7 :

commande Copier

sudo yum install -y XenDesktopVDA-7.17.0.420-1.el7_x.x86_64.rpm

Pour RHEL 6/CentOS 6 :

commande Copier

sudo yum install -y XenDesktopVDA-7.17.0.420-1.el6_x.x86_64.rpm

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

Pour RHEL 7/CentOS 7 :

commande Copier

sudo rpm -i XenDesktopVDA-7.17.0.420-1.el7_x.x86_64.rpm

Pour RHEL 6/CentOS 6 :

commande Copier

sudo rpm -i XenDesktopVDA-7.17.0.420-1.el6_x.x86_64.rpm

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

DÉPENDANCES Copier

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

Remarque

Pour plus d'informations sur les versions Xorg et les distributions Linux prises en charge par le Linux VDA, consultez la matrice dans l'article Citrix CTX221802.

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

dépendances Copier

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

Remarque

Après avoir installé le VDA Linux sur RHEL 7.3, vous devez exécuter la commande sudo yum install -y python-websockify x11vnc pour installer manuellement python-websockify et x11vnc pour utiliser la fonctionnalité d’observation de session. Pour de plus amples informations, consultez la section Observer des sessions.

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

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

Pour RHEL 7/CentOS 7 :

commande Copier

sudo yum install -y XenDesktopVDA-7.17.0.420-1.el7_x.x86_64.rpm

Pour RHEL 6/CentOS 6 :

commande Copier

sudo yum  install -y XenDesktopVDA-7.17.0.420-1.el6_x.x86_64.rpm

Mettez à niveau le logiciel VDA Linux à l'aide du gestionnaire de package RPM :

Pour RHEL 7/CentOS 7 :

commande Copier

sudo rpm -U XenDesktopVDA-7.17.0.420-1.el7_x.x86_64.rpm

Pour RHEL 6/CentOS 6 :

commande Copier

sudo rpm -U XenDesktopVDA-7.17.0.420-1.el6_x.x86_64.rpm

Important

Vous devez redémarrer la machine Linux VDA après la mise à niveau.

Étape 5 : 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 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 :

commande Copier

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help

Configuration avec invites

Exécutez une configuration manuelle avec questions :

commande Copier

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh

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 VDA Linux 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 VDA Linux requiert une liste séparée par des espaces de noms de domaines complets. 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 VDA Linux 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 prennent en charge le lancement lors du démarrage. Valeur 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 : le VDA Linux 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 – Service d'authentification Quest
    • 3 - Centrify DirectControl
    • 4 – SSSD
  • CTX_XDL_HDX_3D_PRO = Y | N : Linux Virtual Desktop prend en charge HDX 3D Pro, un ensemble de technologies d'accélération des graphiques conçues pour optimiser la virtualisation des applications riches en graphiques. HDX 3D Pro nécessite l'installation d'une carte graphique NVIDIA GRID compatible. Si HDX 3D Pro est sélectionné, le Virtual Delivery Agent est configuré pour le mode Bureaux VDI (session unique) – (c'est-à-dire, CTX_XDL_VDI_MODE=Y). Ceci n'est pas pris en charge avec SUSE. Assurez-vous que cette variable est définie sur N.
  • 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 VDA Linux détecte les serveurs LDAP à l'aide de DNS en interrogeant les enregistrements du service LDAP. Pour limiter les résultats de recherche DNS à un site local, spécifiez un nom de site DNS. Cette variable est vide [none] par défaut.
  • CTX_XDL_LDAP_LIST = list-ldap-servers : par défaut, le VDA Linux envoie une requête à DNS pour détecter les serveurs LDAP. Cependant, 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 (FQDN) LDAP avec port LDAP (par ex. ad1.mycompany.com:389). Cette variable est vide [none] par défaut.
  • CTX_XDL_SEARCH_BASE = search-base : par défaut, le VDA Linux envoie une requête à LDAP à l'aide d'une base de recherche définie sur la racine du domaine Active Directory (par exemple, DC=masociété,DC=com). Toutefois, pour améliorer les performances de recherche, vous pouvez spécifier une base de recherche (par exemple, OU=VDI,DC=masociété,DC=com). Cette variable est vide [none] par défaut.
  • CTX_XDL_START_SERVICE = Y | N : indique si les services VDA Linux sont lancés lorsque la configuration du VDA Linux est terminée. Valeur définie sur Y par défaut.

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

commande Copier

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

export CTX_XDL_START_SERVICE=Y|N

sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh

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 ci-dessus avec #!/bin/bash en tant que première ligne.

Éventuellement, vous pouvez spécifier les paramètres avec une seule commande :

commande Copier

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 \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh

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 VDA Linux.

Consultez l'aide sur ce script avant de continuer :

commande Copier

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help

Pour supprimer les modifications de configuration :

commande Copier

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh

Important

Ce script supprime toutes les données de configuration de la base de données et empêche VDA Linux 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 VDA Linux pour que les modifications prennent effet.

Étape 6 : exécuter le VDA Linux

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

Démarrer le VDA Linux

Pour démarrer les services VDA Linux :

commande Copier

sudo /sbin/service ctxhdx start

sudo /sbin/service ctxvda start

Arrêter le VDA Linux

Pour arrêter les services VDA Linux :

commande Copier

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

Redémarrer le VDA Linux

Pour redémarrer les services VDA Linux :

commande Copier

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

sudo /sbin/service ctxvda start

Vérifier l’état du VDA Linux

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

commande Copier

sudo /sbin/service ctxvda status

sudo /sbin/service ctxhdx status

Étape 7 : 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 très 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, veuillez consulter 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 VDA Linux, 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'OS de serveur pour un modèle de mise à disposition de bureaux partagés hébergés. 
    • L'OS de bureau pour un modèle de mise à disposition de bureaux dédiés VDI.
  • Assurez-vous que les machines sont définies avec une alimentation non gérée.
  • MCS n'étant pas pris en charge pour les VDA Linux, choisissez la méthode de déploiement PVS ou Autre service ou technologie (images existantes).
  • Ne combinez pas de machines VDA Linux 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 d'OS de serveur Windows ou d'OS de serveur implique un modèle de mise à disposition équivalent de bureaux partagés hébergés. La sélection de l'option Système d'exploitation de bureau Windows ou OS de bureau implique un modèle de mise à disposition d'un utilisateur XenDesktop unique par machine.

Conseil

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

Étape 8 : 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 aux machines VDA Windows.Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, veuillez consulter 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 VDA Linux, les restrictions suivantes s'appliquent :

  • Pour le type de mise à disposition, sélectionnez Bureaux ou Applications.
  • 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 VDA Linux.
  • 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 du VDA Linux et les versions supérieures. Toutefois, le VDA Linux 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 XenApp et XenDesktop 7.17.