Installation de l’agent de livraison virtuel Linux pour Ubuntu

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 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 Ubuntu pour l’installation du VDA

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

Nous vous recommandons de vérifier que le réseau est connecté et configuré correctement avant de continuer.

Si vous utilisez un serveur Ubuntu 18.04 Live, apportez la modification suivante au fichier de configuration /etc/cloud/cloud.cfg avant de définir le nom d’hôte :

preserve_hostname: true

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

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

hostname

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

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

127.0.0.1 hostname-fqdn hostname localhost

Par exemple :

127.0.0.1 vda01.example.com vda01 localhost

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

Remarque :

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

Conseil :

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

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

hostname -f
<!--NeedCopy-->

Cette commande renvoie le FQDN de la machine.

Étape 1e : Désactiver le DNS multidiffusion

Les paramètres par défaut ont le DNS multidiffusion (mDNS) activé, ce qui peut entraîner des résultats de résolution de noms incohérents.

Pour désactiver mDNS, modifiez /etc/nsswitch.conf et changez la ligne contenant :

hosts: files mdns_minimal [NOTFOUND=return] dns

En :

hosts: files dns

Étape 1f : 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 continuer.

Étape 1g : Configurer la synchronisation de l’horloge (chrony)

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.

Installer chrony :

apt-get install chrony
<!--NeedCopy-->

En tant qu’utilisateur root, modifiez /etc/chrony/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 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 server ou pool répertoriées, y compris l’adresse IP de bouclage, localhost et les entrées de serveur public *.pool.ntp.org.

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

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

Étape 1h : 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.

Sur Ubuntu 16.04, installez OpenJDK en utilisant :

sudo apt-get install -y default-jdk
<!--NeedCopy-->

Sur Ubuntu 18.04, installez OpenJDK en utilisant :

sudo apt-get install -y openjdk-8-jdk
<!--NeedCopy-->

Étape 1i : Installer PostgreSQL

Le VDA Linux nécessite PostgreSQL version 9.x sur Ubuntu :

sudo apt-get install -y postgresql

sudo apt-get install -y libpostgresql-jdbc-java
<!--NeedCopy-->

• Étape 1j : Installer Motif

sudo apt-get install -y libxm4
<!--NeedCopy-->

Étape 1k : Installer d’autres packages

sudo apt-get install -y libsasl2-2

sudo apt-get install -y libsasl2-modules-gssapi-mit

sudo apt-get install -y libldap-2.4-2

sudo apt-get install -y krb5-user

sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->

Étape 2 : Préparer l’hyperviseur

Certaines modifications sont nécessaires 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 Hypervisor™

Lorsque la fonctionnalité de synchronisation de l’heure de Citrix Hypervisor est activée, des problèmes peuvent survenir au sein de chaque machine virtuelle Linux paravirtualisée avec NTP et Citrix Hypervisor, 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 Citrix VM Tools installés, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure de Citrix Hypervisor est présente et activée depuis la machine virtuelle Linux :

su -

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

Cette commande renvoie 0 ou 1 :

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

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

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

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

Pour rendre cette modification permanente et persistante après 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.

Résoudre les problèmes de synchronisation de l’heure sur Microsoft Hyper-V

Les machines virtuelles Linux avec les services d’intégration Linux Hyper-V installés peuvent utiliser 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, activez cette fonctionnalité en même temps que les services NTP.

À partir du système d’exploitation de gestion :

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

Remarque :

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

Résoudre les problèmes de 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 VMware Tools installé :

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ésactivez Synchroniser l’heure de l’invité avec l’hôte.

Étape 3 : Ajouter la machine virtuelle Linux (VM) 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
• PBIS

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

sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user
<!--NeedCopy-->

Activer le démarrage du 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 systemctl enable winbind
<!--NeedCopy-->

Remarque :

Assurez-vous que le script winbind se trouve sous /etc/init.d.

Configurer Kerberos

Ouvrez /etc/krb5.conf en tant qu’utilisateur root et effectuez les réglages suivants :

Remarque :

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

[libdefaults]

default_realm = REALM

dns_lookup_kdc = false

[realms]

REALM = {

admin_server = domain-controller-fqdn

kdc = domain-controller-fqdn

}

[domain_realm]

domain-dns-name = REALM

.domain-dns-name = REALM

Le paramètre domain-dns-name dans ce contexte est le nom de domaine DNS, tel que example.com. Le REALM est le nom du royaume Kerberos en majuscules, tel que EXAMPLE.COM.

Configurer l’authentification Winbind

Configurez Winbind manuellement car Ubuntu ne dispose pas d’un outil comme authconfig dans RHEL et yast2 dans SUSE.

Ouvrez /etc/samba/smb.conf et effectuez les réglages suivants :

[global]

workgroup = WORKGROUP

security = ADS

realm = REALM

encrypt passwords = yes

idmap config *:range = 16777216-33554431

winbind trusted domains only = no

kerberos method = secrets and keytab

winbind refresh tickets = yes

template shell = /bin/bash

WORKGROUP est le premier champ de REALM, et REALM est le nom du royaume Kerberos en majuscules.

Configurer nsswitch

Ouvrez /etc/nsswitch.conf et ajoutez winbind aux lignes suivantes :

passwd: compat winbind group: compat winbind

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

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

Redémarrer winbind

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

Configurer PAM pour Winbind

Exécutez la commande suivante et assurez-vous que les options Authentification Winbind NT/Active Directory et Créer un répertoire personnel lors de la connexion sont sélectionnées :

sudo pam-auth-update
<!--NeedCopy-->

Conseil :

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

Vérifier l’appartenance au domaine

Le Delivery Controller exige que toutes les machines VDA, qu’elles soient Windows ou 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 vérifier que Kerberos est configuré correctement pour être utilisé avec le VDA Linux, 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 par le shell. Dans certains environnements, le nom de domaine DNS est différent du nom du royaume Kerberos. Assurez-vous que le nom du 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-->

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

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

Vérifier l’authentification de l’utilisateur

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

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

Le domaine spécifié ici est le nom de domaine AD, et non le nom du 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 Winbind PAM est configuré correctement, connectez-vous au VDA Linux à l’aide d’un compte utilisateur de domaine qui n’a jamais été utilisé auparavant.

ssh localhost -l domain\\username

id -u
<!--NeedCopy-->

Remarque :

Pour exécuter une commande SSH avec succès, assurez-vous que SSH est activé et fonctionne correctement.

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 de l’utilisateur sont valides et n’ont pas expiré :

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 VDA Linux après la vérification de la jonction au domaine.

Conseil :

Si vous réussissez l’authentification de l’utilisateur mais ne pouvez pas afficher votre bureau lors de la connexion avec un compte de domaine, redémarrez la machine, puis réessayez.

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

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

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

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

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

Remarque :

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

Configurer Quest sur le VDA Linux

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.

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

SELINUX=disabled

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 tout utilisateur de domaine disposant des autorisations nécessaires pour joindre des ordinateurs au domaine Active Directory. Le nom de domaine est le nom DNS du domaine, par exemple, example.com.

Vérifier l’appartenance au domaine

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

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

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

ERROR: No domain could be found. ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm default_realm not configured in vas.conf. Computer may not be joined to domain

Vérifier l’authentification de l’utilisateur

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

ssh localhost -l domain\\username

id -u
<!--NeedCopy-->

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

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

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

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

Quittez la session.

exit
<!--NeedCopy-->

Passez à l’Étape 4 : Installer le VDA Linux 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 disposant des autorisations nécessaires pour joindre des ordinateurs au domaine Active Directory. Le paramètre 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, qu’elles soient Windows ou Linux, possèdent un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux jointe à Centrify est sur le domaine :

su –

adinfo
<!--NeedCopy-->

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

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

adinfo --sysinfo all

adinfo --diag
<!--NeedCopy-->

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

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

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

SSSD

Configurer Kerberos

Exécutez la commande suivante pour installer Kerberos :

sudo apt-get install krb5-user
<!--NeedCopy-->

Pour configurer Kerberos, ouvrez /etc/krb5.conf en tant que root et définissez les paramètres :

Remarque :

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

[libdefaults]

default_realm = REALM

dns_lookup_kdc = false

[realms]

REALM = {

admin_server = domain-controller-fqdn

kdc = domain-controller-fqdn

}

[domain_realm]

domain-dns-name = REALM

.domain-dns-name = REALM

Le paramètre domain-dns-name dans ce contexte est le nom de domaine DNS, tel que example.com. Le REALM est le nom du royaume Kerberos en majuscules, tel que EXAMPLE.COM.

Joindre le domaine

SSSD doit être configuré pour utiliser Active Directory comme fournisseur d’identité et Kerberos pour l’authentification. Cependant, SSSD ne fournit pas de fonctions client AD pour joindre le domaine et gérer le fichier keytab système. Vous pouvez utiliser adcli, realmd ou Samba à la place.

Remarque :

Cette section fournit uniquement des informations pour adcli et Samba.

Utiliser adcli pour joindre le domaine :

Installer adcli :

Installez le package requis :

sudo apt-get install adcli
<!--NeedCopy-->

Joindre le domaine avec adcli :

Supprimez l’ancien fichier keytab système et joignez le domaine à l’aide de :

su -

rm -rf /etc/krb5.keytab

adcli join domain-dns-name -U user -H hostname-fqdn
<!--NeedCopy-->

L’utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter des machines au domaine. Le nom-d’hôte-fqdn est le nom d’hôte au format FQDN pour la machine.

L’option -H est nécessaire pour qu’adcli génère un SPN au format host/hostname-fqdn@REALM, ce qui est requis par le VDA Linux.

Vérifier le keytab système :

Pour une machine Ubuntu 20.04, exécutez la commande adcli testjoin pour vérifier si elle est jointe au domaine.

Pour une machine Ubuntu 18.04 ou Ubuntu 16.04, exécutez la commande sudo klist -ket pour vous assurer que le fichier keytab système a été créé.

Vérifiez que l’horodatage de chaque clé correspond à l’heure à laquelle la machine a été jointe au domaine.

Utiliser Samba pour joindre le domaine :

Installer le paquet :

-  sudo apt-get install samba krb5-user
<!--NeedCopy-->

• Configurer Samba :

  • Ouvrez /etc/samba/smb.conf et appliquez les paramètres suivants :

  • [global]

  • workgroup = WORKGROUP

  • security = ADS

  • realm = REALM

  • client signing = yes

  • client use spnego = yes

kerberos method = secrets and keytab

WORKGROUP est le premier champ de REALM, et REALM est le nom du royaume Kerberos en majuscules.

Joindre le domaine avec Samba :

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

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

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

Configurer SSSD

Installer ou mettre à jour les paquets requis :

Installez les paquets SSSD et de configuration requis s’ils ne sont pas déjà installés :

sudo apt-get install sssd
<!--NeedCopy-->

Si les paquets sont déjà installés, une mise à jour est recommandée :

sudo apt-get install --only-upgrade sssd
<!--NeedCopy-->

Remarque :

Par défaut, le processus d’installation sous Ubuntu configure automatiquement nsswitch.conf et le module de connexion PAM.

Configurer SSSD

Des modifications de configuration SSSD sont requises avant de démarrer le démon SSSD. Pour certaines versions de SSSD, le fichier de configuration /etc/sssd/sssd.conf n’est pas installé par défaut et doit être créé manuellement. En tant que root, créez ou ouvrez /etc/sssd/sssd.conf et appliquez les paramètres suivants :

[sssd]

services = nss, pam

config_file_version = 2

domains = domain-dns-name

[domain/domain-dns-name]

id_provider = ad

access_provider = ad

auth_provider = krb5

krb5_realm = REALM

# Set krb5_renewable_lifetime higher if TGT renew lifetime is longer than 14 days

krb5_renewable_lifetime = 14d

# Set krb5_renew_interval to lower value if TGT ticket lifetime is shorter than 2 hours

krb5_renew_interval = 1h

krb5_ccachedir = /tmp

krb5_ccname_template = FILE:%d/krb5cc_%U

# This ldap_id_mapping setting is also the default value

ldap_id_mapping = true

override_homedir = /home/%d/%u

default_shell = /bin/bash

ad_gpo_map_remote_interactive = +ctxhdx

Remarque :

ldap_id_mapping est défini sur true afin que SSSD se charge lui-même du mappage des SID Windows aux UID Unix. Sinon, l’Active Directory doit être en mesure de fournir des extensions POSIX. Le service PAM ctxhdx est ajouté à ad_gpo_map_remote_interactive.

Le paramètre domain-dns-name dans ce contexte est le nom de domaine DNS, tel que example.com. Le REALM est le nom du royaume Kerberos en majuscules, tel que EXAMPLE.COM. Il n’est pas nécessaire de configurer le nom de domaine NetBIOS.

Pour plus d’informations sur les paramètres de configuration, consultez les pages de manuel de sssd.conf et sssd-ad.

Le démon SSSD exige que le fichier de configuration n’ait que la permission de lecture pour le propriétaire :

sudo chmod 0600 /etc/sssd/sssd.conf
<!--NeedCopy-->

Démarrer le démon SSSD

Exécutez les commandes suivantes pour démarrer le démon SSSD maintenant et pour l’activer au démarrage de la machine :

sudo systemctl start sssd

sudo systemctl enable sssd
<!--NeedCopy-->

Configuration PAM

Exécutez la commande suivante et assurez-vous que les options Authentification SSS et Créer le répertoire personnel lors de la connexion sont sélectionnées :

sudo pam-auth-update
<!--NeedCopy-->

• Vérifier l’appartenance au domaine

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

Utiliser adcli pour vérifier l’appartenance au domaine :

Affichez les informations de domaine en exécutant la commande suivante :

sudo adcli info domain-dns-name
<!--NeedCopy-->

Utiliser Samba pour vérifier l’appartenance au domaine :

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 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 qu’il contient des clés valides :

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

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms 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 empêcher 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 du royaume est utilisé. Si cette commande réussit, aucune sortie n’est affichée.

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

sudo klist
<!--NeedCopy-->

Vérifier l’authentification de l’utilisateur

SSSD ne fournit pas d’outil en ligne de commande pour tester l’authentification directement avec le démon, et cela ne peut être fait que via PAM.

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

ssh localhost -l domain\\username

id -u

klist

exit
<!--NeedCopy-->

Vérifiez que les tickets Kerberos renvoyés par la commande klist sont corrects pour cet utilisateur et n’ont pas expiré.

En tant qu’utilisateur root, vérifiez qu’un fichier de cache de tickets correspondant a été créé pour l’UID renvoyé par la commande id -u précédente :

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

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

PBIS

Télécharger le package PBIS requis

Par exemple :

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

Rendre le script d’installation PBIS exécutable

Par exemple :

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

Exécuter le script d’installation PBIS

Par exemple :

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

Joindre le domaine Windows

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

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

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

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

Vérifier l’appartenance au domaine

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

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

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

Vérifier l’authentification de l’utilisateur

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

sudo ssh localhost -l domain\\user

id -u
<!--NeedCopy-->

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

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

Quittez la session.

exit
<!--NeedCopy-->

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

Étape 4 : Installer le VDA Linux

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

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

Étape 4b : Installer le VDA Linux

Installez le logiciel VDA Linux à l’aide du gestionnaire de packages Debian :

Pour Ubuntu 20.04 :

sudo dpkg -i xendesktopvda_<version>.ubuntu20.04_amd64.deb
<!--NeedCopy-->

Pour Ubuntu 18.04 :

sudo dpkg -i xendesktopvda_<version>.ubuntu18.04_amd64.deb
<!--NeedCopy-->

Pour Ubuntu 16.04 :

sudo dpkg -i xendesktopvda_<version>.ubuntu16.04_amd64.deb
<!--NeedCopy-->

Liste des dépendances Debian pour Ubuntu 20.04 :

postgresql >= 12

libpostgresql-jdbc-java >= 42.2

openjdk-8-jdk >= 8u252

imagemagick >= 8:6.9.10

ufw >= 0.36

ubuntu-desktop >= 1.450

libxrandr2 >= 2:1.5.2

libxtst6 >= 2:1.2.3

libxm4 >= 2.3.8

util-linux >= 2.34

gtk3-nocsd >= 3

bash >= 5.0

findutils >= 4.7.0

sed >= 4.7

cups >= 2.3

libmspack0 >= 0.10

libgoogle-perftools4 >= 2.7~

libpython2.7 >= 2.7~
<!--NeedCopy-->

Liste des dépendances Debian pour Ubuntu 18.04 :

postgresql >= 9.5

libpostgresql-jdbc-java >= 9.2

openjdk-8-jdk >= 1.8.0

gtk3-nocsd >=3

imagemagick >= 8:6.8.9.9

ufw >= 0.35

ubuntu-desktop >= 1.361

libxrandr2 >= 2:1.5.0

libxtst6 >= 2:1.2.2

libxm4 >= 2.3.4

util-linux >= 2.27.1

bash >= 4.3

findutils >= 4.6.0

sed >= 4.2.2

cups >= 2.1

libldap-2.4-2 >= 2.4.42

libsasl2-modules-gssapi-mit >= 2.1.~

python-requests >= 2.9.1

libgoogle-perftools4 >= 2.4~

xserver-xorg-core >= 2:1.18

xserver-xorg-core << 2:1.19

x11vnc>=0.9.13

python-websockify >= 0.6.1
<!--NeedCopy-->

Liste des dépendances Debian pour Ubuntu 16.04 :

postgresql >= 9.5

libpostgresql-jdbc-java >= 9.2

default-jdk >= 2:1.8

imagemagick >= 8:6.8.9.9

ufw >= 0.35

ubuntu-desktop >= 1.361

libxrandr2 >= 2:1.5.0

libxtst6 >= 2:1.2.2

libxm4 >= 2.3.4

util-linux >= 2.27.1

bash >= 4.3

findutils >= 4.6.0

sed >= 4.2.2

cups >= 2.1

libldap-2.4-2 >= 2.4.42

libsasl2-modules-gssapi-mit >= 2.1.~

python-requests >= 2.9.1

libgoogle-perftools4 >= 2.4~

xserver-xorg-core >= 2:1.18

xserver-xorg-core << 2:1.19

x11vnc>=0.9.13

python-websockify >= 0.6.1
<!--NeedCopy-->

Remarque :

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

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

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

sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->

Étape 4d : 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, les options requises par le script d’installation peuvent être fournies à l’aide de variables d’environnement. Si toutes les variables requises sont présentes, le script ne demande aucune information à l’utilisateur, permettant un processus d’installation scripté.

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. Défini sur N par défaut.
• 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. Défini 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. Défini sur Y par défaut.
• CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 |5 – 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
  • 5 – PBIS
• CTX_XDL_HDX_3D_PRO=Y | N – Le VDA Linux prend en charge HDX 3D Pro, un ensemble de technologies d’accélération GPU conçues pour optimiser la virtualisation des applications graphiques riches. Si HDX 3D Pro est sélectionné, le VDA est configuré pour le mode postes de travail VDI (session unique) – (c’est-à-dire, CTX_XDL_VDI_MODE=Y).
• CTX_XDL_VDI_MODE=Y | N – Permet de configurer la machine en tant que modèle de livraison de postes de travail dédiés (VDI) ou modèle de livraison de postes de travail partagés hébergés. 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 les ports 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 sur la racine du domaine Active Directory (par exemple, DC=mycompany,DC=com). Cependant, pour améliorer les performances de recherche, vous pouvez spécifier une base de recherche (par exemple, OU=VDI,DC=mycompany,DC=com). Cette variable est définie sur <none> par défaut.
• CTX_XDL_FAS_LIST=‘list-fas-servers’ – Les serveurs Federated Authentication Service (FAS) sont configurés via la stratégie de groupe AD. Le VDA Linux ne prend pas en charge la stratégie de groupe AD, mais vous pouvez fournir une liste de serveurs FAS séparés par des points-virgules à la place. La séquence doit être la même que celle configurée dans la stratégie de groupe AD. Si une adresse de serveur est supprimée, remplissez son champ vide avec la chaîne de texte <none> et ne modifiez pas l’ordre des adresses de serveur.
• CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – Le chemin d’installation de .NET Core Runtime 3.1 pour prendre en charge le nouveau service d’agent de broker (ctxvda). Le chemin par défaut est /usr/bin.
• 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. Défini sur Y par défaut.
• CTX_XDL_TELEMETRY_SOCKET_PORT – Le port socket pour l’écoute de Citrix Scout. Le port par défaut est 7503.
• CTX_XDL_TELEMETRY_PORT – Le port pour la communication avec Citrix Scout. Le port par défaut est 7502.

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

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST=‘list-ddc-fqdns’

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

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

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-site-name | '<none>'

export CTX_XDL_LDAP_LIST=‘list-ldap-servers’ | '<none>'

export CTX_XDL_SEARCH_BASE=search-base-set | '<none>'

export CTX_XDL_FAS_LIST=‘list-fas-servers’ | '<none>'

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

export CTX_XDL_TELEMETRY_SOCKET_PORT=port-number

export CTX_XDL_TELEMETRY_PORT=port-number

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. Nous vous recommandons de créer un fichier de script shell à partir des commandes précédentes avec #!/bin/bash comme première ligne.

Alternativement, vous pouvez spécifier tous les paramètres en utilisant une seule commande :

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST=‘list-ddc-fqdns’ \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

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

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST=‘list-ldap-servers’ \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST=‘list-fas-servers’ \

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

CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \

CTX_XDL_TELEMETRY_PORT=port-number \

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.

Désinstaller le logiciel VDA Linux

Pour vérifier si le VDA Linux est installé et pour afficher la version du package installé :

dpkg -l xendesktopvda
<!--NeedCopy-->

Pour afficher des informations plus détaillées :

apt-cache show xendesktopvda
<!--NeedCopy-->

Pour désinstaller le logiciel VDA Linux :

dpkg -r xendesktopvda
<!--NeedCopy-->

Remarque :

La désinstallation du logiciel VDA Linux supprime les données de configuration associées à PostgreSQL et d’autres données de configuration. Cependant, le package PostgreSQL et les autres packages dépendants qui ont été configurés avant l’installation du VDA Linux ne sont pas supprimés.

Conseil :

Les informations de cette section ne couvrent pas la suppression des packages dépendants, y compris PostgreSQL.

Étape 5 : Exécuter le VDA Linux

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

Démarrer le VDA Linux :

Pour démarrer les services VDA Linux :

sudo systemctl start ctxhdx

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

Arrêter le VDA Linux :

Pour arrêter les services VDA Linux :

sudo systemctl stop ctxvda

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

Remarque :

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

Redémarrer le VDA Linux :

Pour redémarrer les services VDA Linux :

sudo systemctl stop ctxvda

sudo systemctl restart ctxhdx

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

Vérifier l’état du VDA Linux :

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

sudo systemctl status ctxvda

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

Étape 6 : Créer le catalogue de machines dans Citrix Virtual Apps ou Citrix Virtual Desktops™

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

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

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

Remarque :

Les premières versions de Citrix Studio ne prenaient pas en charge la notion de « SE Linux ». Cependant, la sélection de l’option SE Windows Server ou SE Serveur implique un modèle de déploiement de bureaux partagés hébergés équivalent. La sélection de l’option SE Windows Desktop ou SE Bureau implique un modèle de déploiement 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 7 : Créer le groupe de mise à disposition dans Citrix Virtual Apps™ ou Citrix Virtual Desktops

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

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

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

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