Installer le Linux VDA manuellement sur Debian
Important :
Pour les nouvelles installations, nous vous recommandons d’utiliser Easy Install pour effectuer une installation rapide. Easy Install permet de gagner du temps et d’économiser de la main d’œuvre. Cette installation est également plus fiable que l’installation manuelle décrite dans cet article.
Étape 1 : préparer les informations de configuration et la machine Linux
Étape 1a : définir le nom d’hôte
Pour vous assurer que le nom d’hôte de la machine est indiqué correctement, modifiez le fichier /etc/hostname afin que celui-ci contienne uniquement le nom d’hôte de la machine.
hostname
Étape 1b : 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 signalés correctement. Pour ce faire, modifiez la ligne suivante du fichier /etc/hosts pour inclure le nom de domaine complet et le nom d’hôte en tant que 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 Linux VDA ne prend actuellement pas en charge la troncation de noms NetBIOS. Le nom d’hôte ne doit pas comporter plus de 15 caractères.
Conseil :
Utilisez uniquement les caractères a–z, A–Z, 0–9 et tiret (-). Évitez les caractères de soulignement (_), les espaces et autres symboles. Ne démarrez pas un nom d’hôte par un chiffre et ne le terminez pas par un tiret. Cette règle s’applique également aux noms d’hôte Delivery Controller.
Étape 1c : vérifier le nom d’hôte
Redémarrez l’ordinateur et vérifiez que le nom d’hôte est correctement configuré :
hostname
<!--NeedCopy-->
Cette commande renvoie uniquement le nom d’hôte de la machine et non son nom de domaine complet.
Vérifiez que le nom de domaine complet est correctement configuré :
hostname -f
<!--NeedCopy-->
Cette commande renvoie le nom de domaine complet de la machine.
Étape 1d : désactiver DNS multidiffusion
Les paramètres par défaut activent DNS multidiffusion (mDNS), ce qui peut entraîner des résultats incohérents de résolution de nom.
Pour désactiver mDNS, modifiez /etc/nsswitch.conf et dans la ligne suivante remplacez :
hosts: files mdns_minimal [NOTFOUND=return] dns
par :
hosts: files dns
Étape 1e : vérifier la résolution de nom et l’accessibilité du service
Vérifiez que vous pouvez résoudre le nom de domaine complet et effectuer un sondage ping sur le contrôleur de domaine et le Delivery Controller :
nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
Si vous ne pouvez pas résoudre le nom de domaine complet ou effectuer un sondage ping sur l’une de ces machines, reprenez les étapes avant de continuer.
Étape 1f : configurer la synchronisation de l’horloge (chrony)
Il est très important de maintenir la synchronisation de l’horloge entre les VDA, les Delivery Controller et les contrôleurs de domaine. L’hébergement du Linux VDA en tant que machine virtuelle (VM) 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.
Installez chrony :
apt-get install chrony
<!--NeedCopy-->
En tant qu’utilisateur racine, 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 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 ou pool répertoriée, y compris les entrées d’adresse IP de bouclage, localhost et *.pool.ntp.org de serveur public.
Enregistrez les modifications et redémarrez le démon Chrony :
sudo systemctl restart chrony
<!--NeedCopy-->
Étape 1g : installer les packages
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
Étape 1h : ajouter des référentiels pour installer les dépendances nécessaires
Pour Debian 11, ajoutez la ligne deb http://deb.debian.org/debian/ bullseye main
au fichier /etc/apt/sources.list.
Étape 1i : installer et spécifier la base de données à utiliser
Remarque :
Nous vous recommandons d’utiliser SQLite pour le mode VDI uniquement et d’utiliser PostgreSQL pour un modèle de mise à disposition de bureaux partagés hébergés.
Pour Easy Install et MCS, vous pouvez spécifier SQLite ou PostgreSQL sans avoir à les installer manuellement. Sauf indication contraire dans /etc/xdl/db.conf, le Linux VDA utilise PostgreSQL par défaut.
Pour les installations manuelles, vous devez installer SQLite, PostgreSQL ou les deux manuellement. Si vous installez SQLite et PostgreSQL, vous pouvez spécifier l’un d’entre eux à utiliser en modifiant /etc/xdl/db.conf après avoir installé le package Linux VDA.
Cette section explique la procédure d’installation de PostgreSQL et SQLite, et comment spécifier l’utilisation de l’un ou l’autre.
Installer PostgreSQL
Exécutez les commandes suivantes pour installer PostgreSQL :
sudo apt-get update
sudo apt-get install -y postgresql
sudo apt-get install -y libpostgresql-jdbc-java
<!--NeedCopy-->
Exécutez les commandes suivantes pour démarrer PostgreSQL au démarrage de la machine ou immédiatement, respectivement :
sudo systemctl enable postgresql
sudo systemctl start postgresql
<!--NeedCopy-->
Installer SQLite
Pour Debian, exécutez la commande suivante pour installer SQLite :
sudo apt-get install -y sqlite3
<!--NeedCopy-->
Spécifier la base de données à utiliser
Si vous installez SQLite et PostgreSQL, vous pouvez spécifier l’un d’entre eux à utiliser en modifiant /etc/xdl/db.conf après avoir installé le package Linux VDA.
- Exécutez /opt/Citrix/VDA/sbin/ctxcleanup.sh. Omettez cette étape s’il s’agit d’une nouvelle installation.
- Modifiez /etc/xdl/db.conf pour spécifier la base de données à utiliser.
- Exécutez le fichier ctxsetup.sh.
Remarque :
Vous pouvez également utiliser /etc/xdl/db.conf pour configurer le numéro de port de PostgreSQL.
Étape 2 : préparer l’hyperviseur
Certaines modifications sont requises pour l’exécution du Linux VDA en tant que VM 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 XenServer (anciennement Citrix Hypervisor)
Lorsque la fonctionnalité de synchronisation de l’heure de XenServer est activée, vous rencontrez des problèmes avec NTP et XenServer au sein de chaque machine virtuelle Linux paravirtualisée. En effet, les deux systèmes essaient de gérer l’horloge 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.
Si vous utilisez un noyau Linux paravirtualisé avec le composant XenServer VM 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 :
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
Cette commande renvoie 0 ou 1 :
- 0 - La fonctionnalité de synchronisation de l’heure est activée, et doit être désactivée.
- 1 - La fonctionnalité de synchronisation de l’heure est désactivée, et aucune action n’est requise.
Si le fichier /proc/sys/xen/independent_wallclock n’existe pas, les étapes suivantes ne sont pas nécessaires.
Si la fonctionnalité de synchronisation est activée, désactivez-la en entrant 1 dans le fichier :
sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
Pour rendre cette modification permanente et persistante après le redémarrage, modifiez le fichier /etc/sysctl.conf et ajoutez la ligne :
xen.independent_wallclock = 1
Pour vérifier ces modifications, redémarrez le système :
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
Cette commande renvoie la valeur 1.
Corriger la synchronisation de l’heure sur Microsoft Hyper-V
Les VM Linux sur lesquelles Hyper-V Integration Services est installé peuvent utiliser 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, activez cette fonctionnalité avec les services NTP.
Depuis le système d’exploitation de gestion :
- Ouvrez la console du gestionnaire Hyper-V.
- Pour les paramètres d’une machine virtuelle Linux, sélectionnez Integration Services.
- Assurez-vous que Time synchronization est sélectionné.
Remarque :
Cette approche diffère de VMware et XenServer (anciennement Citrix Hypervisor), pour lesquels la synchronisation de l’heure est désactivée pour éviter tout conflit avec NTP. La synchronisation de l’heure Hyper-V peut co-exister avec la synchronisation de l’heure NTP.
Corriger la synchronisation de l’heure sur ESX et ESXi
Si la fonctionnalité de synchronisation de l’heure de VMware est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée avec l’hyperviseur et NTP. En effet, les deux systèmes essaient de synchroniser l’horloge 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é :
- Ouvrez vSphere Client.
- Modifiez les paramètres pour la VM Linux.
- Dans la boîte de dialogue Virtual Machine Properties (Propriétés de la machine virtuelle), ouvrez l’onglet Options.
- Sélectionnez VMware Tools.
- Dans la zone Advanced (Avancé), désélectionnez Synchronize guest time with host (Synchroniser l’heure de l’invité avec l’hôte).
Étape 3 : ajouter la VM Linux au domaine Windows
Les méthodes suivantes sont disponibles pour ajouter des machines Linux au domaine Active Directory (AD) :
Suivez les instructions en fonction de la méthode choisie.
Remarque :
Les lancements de session peuvent échouer lorsque le même nom d’utilisateur est utilisé pour le compte local dans le Linux VDA et le compte dans AD.
Samba Winbind
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émon Winbind pour qu’il soit lancé au démarrage de la machine
Le démon Winbind doit être configuré pour être lancé au démarrage de la machine :
sudo 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 racine et configurez les paramètres suivants :
Remarque :
Configurez Kerberos en fonction de votre infrastructure AD. Les paramètres suivants sont destinés au modèle à domaine et à forêt uniques.
[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
Dans ce contexte, le paramètre domain-dns-name est le nom de domaine DNS, tel que exemple.com. L’élément REALM est le nom du domaine Kerberos en majuscules, tel que EXEMPLE.COM.
Configurer l’authentification Winbind
Ouvrez /etc/samba/smb.conf en exécutant la commande vim /etc/samba/smb.conf, puis définissez les paramètres suivants :
[global]
workgroup =
WORKGROUP
security = ADS
realm =
REALM
encrypt passwords = yes
idmap config *:range = 16777216-33554431
kerberos method = secrets and keytab
winbind refresh tickets = yes
template shell = /bin/bash
WORKGROUP est le premier champ dans REALM, et REALM est le nom de domaine Kerberos en majuscules.
Configurer nsswitch
Ouvrez /etc/nsswitch.conf et ajoutez winbind
aux lignes suivantes :
passwd: files systemd winbind
group: files systemd winbind
Rejoindre un domaine Windows
Votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :
sudo net ads join <Kerberos realm name in uppercase> -U <domain user with permission to add computers to the domain>
<!--NeedCopy-->
Redémarrer Winbind
sudo systemctl restart winbind
<!--NeedCopy-->
Configurer PAM pour Winbind
Exécutez la commande suivante et assurez-vous que les options Winbind NT/Active Directory authentication et Create home directory on login sont sélectionnées :
sudo pam-auth-update
<!--NeedCopy-->
Conseil :
Le démon winbind ne reste en cours d’exécution que si la machine est associée à un domaine.
Vérifier l’appartenance à un domaine
Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory
.
Exécutez la commande net ads de Samba pour vérifier si la machine est associée à un domaine :
sudo net ads testjoin
<!--NeedCopy-->
Exécutez la commande suivante pour vérifier les informations d’objet de domaine et d’ordinateur supplémentaires :
sudo net ads info
<!--NeedCopy-->
Vérifier la configuration de Kerberos
Pour 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 :
sudo klist -ke
<!--NeedCopy-->
Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms principaux et de suites de chiffrement. Exécutez la commande kinit Kerberos pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :
sudo kinit -k MACHINE$@REALM
<!--NeedCopy-->
Les noms de machine et de domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être placé dans une séquence d’échappement avec une barre oblique 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 :
sudo klist
<!--NeedCopy-->
Examinez les détails du compte de machine à l’aide de :
sudo net ads status
<!--NeedCopy-->
Vérifier l’authentification utilisateur
Utilisez l’outil wbinfo pour vérifier que les utilisateurs de domaine peuvent s’authentifier auprès du domaine :
wbinfo --krb5auth=domain\username%password
<!--NeedCopy-->
Le domaine spécifié ici est le nom de domaine Active Directory, et non le nom de domaine Kerberos. Pour le shell bash, la barre oblique inverse (\) doit être placée dans une séquence d’échappement avec une autre barre oblique inverse. Cette commande renvoie un message indiquant la réussite ou l’échec.
Pour vérifier que le module PAM Winbind est correctement configuré, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.
ssh localhost -l domain\username
id -u
<!--NeedCopy-->
Remarque :
Pour exécuter une commande SSH avec succès, assurez-vous que SSH est activé et fonctionne correctement.
Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le UID renvoyé par la commande id -u :
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Vérifiez que les tickets dans le cache d’identification Kerberos de l’utilisateur sont valides et n’ont pas expiré :
klist
<!--NeedCopy-->
Quittez la session.
exit
<!--NeedCopy-->
Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome. Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.
Conseil :
Si l’authentification utilisateur réussit mais que vous ne pouvez pas afficher votre bureau lors de la connexion avec un compte de domaine, redémarrez la machine et réessayez.
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 Linux VDA
Pour autoriser les utilisateurs de domaine à établir des sessions HDX sur une machine Linux VDA :
- 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.
- Sélectionnez l’onglet Unix Account.
- Sélectionnez Unix-enabled.
- Définissez Primary GID Number sur l’ID d’un groupe d’utilisateurs de domaine.
Remarque :
Ces instructions sont les mêmes que pour la configuration d’utilisateurs de domaine pour l’ouverture de session à l’aide de la console, RDP, SSH ou tout autre protocole de communication à distance.
Configurer Quest sur un Linux VDA
Solution à l’application forcée de la stratégie SELinux
L’environnement RHEL par défaut applique entièrement SELinux. Cette mise en œuvre interfère avec les mécanismes IPC de socket de domaine Unix utilisés par Quest et empêche les utilisateurs de domaine d’ouvrir une session.
Le moyen pratique de remédier à ce problème consiste à désactiver SELinux. En tant qu’utilisateur racine, modifiez /etc/selinux/config en modifiant le paramètre SELinux :
SELINUX=disabled
Cette modification nécessite le redémarrage de la machine :
reboot
<!--NeedCopy-->
Important :
Utilisez ce paramètre avec précaution. La réactivation de l’application forcée de la stratégie SELinux après sa désactivation peut entraîner un verrouillage complet, même pour l’utilisateur racine et d’autres utilisateurs locaux.
Configurer le démon VAS
Le renouvellement automatique des tickets Kerberos doit être activé et déconnecté. L’authentification (ouverture de session en mode déconnecté) doit être désactivée :
sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400
sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->
Cette commande définit l’intervalle de renouvellement sur 9 heures (32 400 secondes), ce qui représente une heure de moins que la valeur par défaut de 10 heures pour la durée de vie d’un ticket. Définissez ce paramètre sur une valeur inférieure sur les systèmes avec une durée de vie de ticket plus courte.
Configuration de PAM et de NSS
Pour permettre l’ouverture de session d’utilisateur de domaine via HDX et d’autres services tels que su, ssh et RDP, exécutez les commandes suivantes pour configurer manuellement PAM et NSS :
sudo /opt/quest/bin/vastool configure pam
sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->
Rejoindre un domaine Windows
Associez la machine Linux au domaine Active Directory à l’aide de la commande Quest vastool :
sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->
L’utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom DNS du domaine, par exemple, exemple.com.
Redémarrez la machine Linux une fois le domaine rejoint.
Vérifier l’appartenance à un 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 :
sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->
Si la machine est associée à un domaine, cette commande renvoie le nom de domaine. Si la machine n’est pas associée à un domaine, l’erreur suivante apparaît :
ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain
Vérifier l’authentification utilisateur
Pour vérifier que Quest peut authentifier les utilisateurs de domaine via PAM, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.
ssh localhost -l domain\username
id -u
<!--NeedCopy-->
Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le UID renvoyé par la commande id -u :
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Vérifiez que les tickets dans le cache d’identification de Kerberos sont valides et n’ont pas expiré :
/opt/quest/bin/vastool klist
<!--NeedCopy-->
Quittez la session.
exit
<!--NeedCopy-->
Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.
Centrify DirectControl
Rejoindre un domaine Windows
Une fois Centrify DirectControl Agent installé, associez la machine Linux au domaine Active Directory à l’aide de la commande Centrify adjoin
:
su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->
Le paramètre user est un utilisateur de domaine Active Directory disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom du domaine auquel associer la machine Linux.
Vérifier l’appartenance à un domaine
Le 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 :
su –
adinfo
<!--NeedCopy-->
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 :
adinfo --sysinfo all
adinfo --diag
<!--NeedCopy-->
Testez la connectivité avec les différents services Active Directory et Kerberos.
adinfo --test
<!--NeedCopy-->
Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.
SSSD
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 qu’utilisateur racine 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 à domaine et à forêt uniques.
[libdefaults]
default_realm =
REALM
dns_lookup_kdc = false
rdns = false
[realms]
REALM
= {
admin_server =
domain-controller-fqdn
kdc =
domain-controller-fqdn
}
[domain_realm]
domain-dns-name
=
REALM
.domain-dns-name
=
REALM
La propriété domain-dns-name
dans ce contexte est le nom de domaine DNS, tel que example.com. L’élément REALM est le nom du royaume Kerberos en majuscules, tel que EXEMPLE.COM.
Joindre le domaine
SSSD doit être configuré pour pouvoir utiliser Active Directory en tant que fournisseur d’identité et Kerberos pour l’authentification. Toutefois, SSSD ne fournit pas de fonctions de client Active Directory pour rejoindre le domaine et gérer le fichier keytab du système. Vous pouvez utiliser adcli, realmdou Samba à la place.
Remarque :
Cette section fournit des informations uniquement pour adcli et Samba.
- Si vous utilisez adcli pour rejoindre le domaine, procédez comme suit :
-
Installez adcli.
sudo apt-get install adcli <!--NeedCopy-->
-
Rejoignez le domaine avec adcli.
Supprimez l’ancien fichier keytab du système et rejoignez le domaine à l’aide de :
su - rm -rf /etc/krb5.keytab adcli join domain-dns-name -U user -H hostname-fqdn <!--NeedCopy-->
user est un utilisateur du domaine autorisé à ajouter des machines au domaine. hostname-fqdn est le nom d’hôte au format FQDN de la machine.
L’option -H est requise pour permettre à adcli de générer SPN au format host/hostname-fqdn@REALM, ce qui est requis par Linux VDA.
-
Vérifiez le fichier keytab système.
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.
- Si vous utilisez Samba pour rejoindre le domaine, procédez comme suit :
-
Installez le pack.
sudo apt-get install samba krb5-user <!--NeedCopy-->
-
Configurer Samba.
Ouvrez /etc/samba/smb.conf et configurez 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 dans REALM, et REALM est le nom de domaine Kerberos en majuscules.
-
Rejoignez 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 <the Kerberos realm name in uppercase> -U <domain user with permission to add computers to the domain> <!--NeedCopy-->
Configurer SSSD
Installer ou mettre à jour les packages requis :
Installez les packages de configuration et SSSD requis s’ils ne sont pas déjà installés :
sudo apt-get install sssd
<!--NeedCopy-->
Si les packages sont déjà installés, une mise à jour est recommandée :
sudo apt-get install --only-upgrade sssd
<!--NeedCopy-->
Configurer SSSD
Des modifications doivent être apportées à la configuration SSSD 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 qu’utilisateur racine, créez ou ouvrez /etc/sssd/sssd.conf et configurez 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 de façon à ce que SSSD se charge de mapper les SID Windows avec les UID Unix. Sinon,
Active Directory
doit être en mesure de fournir des extensions POSIX. Le service PAMctxhdx
est ajouté au paramètre ad_gpo_map_remote_interactive.Dans ce contexte, le paramètre domain-dns-name est le nom de domaine DNS, tel que exemple.com. L’élément REALM est le nom du royaume Kerberos en majuscules, tel que EXEMPLE.COM. Il n’est pas nécessaire de configurer le nom de domaine NetBIOS.
Pour de plus amples informations sur les paramètres de configuration, consultez les pages man pour sssd.conf et
sssd-ad
.
Le démon SSSD nécessite que le fichier de configuration dispose uniquement de l’autorisation d’accès en lecture de 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 permettre le lancement du démon au démarrage de la machine :
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
Configuration de PAM
Exécutez la commande suivante et assurez-vous que les options SSS authentication et Create home directory on login sont sélectionnées :
sudo pam-auth-update
<!--NeedCopy-->
Vérifier l’appartenance à un domaine
Le Delivery Controller requiert que toutes les machines VDA (VDA Windows et Linux) aient un objet ordinateur dans Active Directory
.
-
Si vous utilisez adcli pour vérifier l’appartenance à un domaine, exécutez la commande
sudo adcli info domain-dns-name
pour afficher les informations sur le domaine. -
Si vous utilisez Samba pour vérifier l’appartenance à un domaine, exécutez la commande
sudo net ads testjoin
pour vérifier que la machine est jointe à un domaine et la commandesudo net ads info
pour vérifier des informations supplémentaires sur le domaine et l’objet Ordinateur.
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 :
sudo klist -ke
<!--NeedCopy-->
Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms principaux et de suites de chiffrement. Exécutez la commande kinit
Kerberos pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :
sudo kinit -k MACHINE$@REALM
<!--NeedCopy-->
Les noms de machine et de domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être placé dans une séquence d’échappement avec une barre oblique 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 TGT pour le compte de machine a été mis en cache à l’aide de :
sudo klist
<!--NeedCopy-->
Vérifier l’authentification utilisateur
SSSD ne fournit pas d’outil de ligne de commande pour tester l’authentification directement avec le démon. Cela peut uniquement être effectué via PAM.
Pour vérifier que le module PAM SSSD est correctement configuré, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.
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 qu’ils n’ont pas expiré.
En tant qu’utilisateur racine, vérifiez qu’un fichier cache de ticket correspondant a été créé pour l’UID renvoyé par la commande id -u précédente :
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Le même test peut être réalisé en ouvrant une session directement sur KDE ou Gnome Display Manager. Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.
PBIS
Télécharger le package PBIS requis
sudo wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
Rendre le script d’installation PBIS exécutable
sudo chmod +x pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
Exécuter le script d’installation PBIS
sudo sh pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
Rejoindre un domaine Windows
Votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :
sudo /opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
L’utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom DNS du domaine, par exemple, exemple.com.
Remarque : pour définir Bash en tant que shell par défaut, exécutez la commande sudo /opt/pbis/bin/config LoginShellTemplate/bin/bash.
Vérifier l’appartenance à un domaine
Le Delivery Controller requiert que toutes les machines VDA (VDA Windows et Linux) aient un objet ordinateur dans Active Directory
. Pour vérifier qu’une machine Linux associée à PBIS se trouve sur le domaine :
/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->
Si la machine est associée à un domaine, cette commande renvoie les informations sur le domaine AD et l’unité d’organisation auxquels la machine est actuellement associée. Sinon, seul le nom d’hôte apparaît.
Vérifier l’authentification utilisateur
Pour vérifier que PBIS peut authentifier les utilisateurs de domaine via PAM, ouvrez une session sur le Linux VDA à l’aide d’un compte d’utilisateur de domaine qui n’a jamais été utilisé.
sudo ssh localhost -l domain\user
id -u
<!--NeedCopy-->
Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le UID renvoyé par la commande id -u :
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Quittez la session.
exit
<!--NeedCopy-->
Passez à l’étape 6 : installer le Linux VDA après vérification de la jonction du domaine.
Étape 4 : installer .NET
Avant d’installer Linux VDA, installez .NET en fonction de votre distribution Linux :
- Installez le runtime .NET 8.0 sur toutes les distributions Linux prises en charge à l’exception de RHEL 7.9 et d’Amazon Linux 2.
- Pour RHEL 7.9 et Amazon Linux 2, poursuivez l’installation du runtime .NET 6.0.
Si votre distribution Linux contient la version .NET dont vous avez besoin, installez-la à partir du flux intégré. Sinon, installez .NET à partir du flux de packages Microsoft. Pour plus d’informations, consultez https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.
Après avoir installé le runtime .NET, exécutez la commande which dotnet pour trouver le chemin d’exécution.
En fonction de la sortie de la commande, définissez le chemin binaire de .NET Runtime. Par exemple, si la sortie de la commande est /aa/bb/dotnet, utilisez /aa/bb comme chemin binaire .NET.
Étape 5 : télécharger le package Linux VDA
- Accédez à la page de téléchargement de Citrix Virtual Apps and Desktops.
- Développez la version appropriée de Citrix Virtual Apps and Desktops.
-
Développez Components pour trouver le Linux VDA. Par exemple :
-
Cliquez sur le lien Linux VDA pour accéder aux téléchargements de Linux VDA.
-
Téléchargez le package Linux VDA correspondant à votre distribution Linux.
-
Téléchargez la clé publique GPG que vous pouvez utiliser pour vérifier l’intégrité du package Linux VDA. Par exemple :
Pour vérifier l’intégrité du package Linux VDA, exécutez les commandes suivantes pour importer la clé publique dans la base de données DEB et vérifier l’intégrité du package :
sudo apt-get install dpkg-sig gpg --import <path to the public key> dpkg-sig --verify <path to the Linux VDA package> <!--NeedCopy-->
Étape 6 : installer le Linux VDA
Étape 6a : installer le Linux VDA
Installez le logiciel Linux VDA à l’aide du gestionnaire de package Debian :
sudo dpkg -i xendesktopvda_<version>.debian11_amd64.deb
<!--NeedCopy-->
Liste des dépendances pour Debian 11 :
libnss3-tools >= 2:3.61
libfuse2 >= 2.9
openjdk-11-jdk >= 11
imagemagick >= 8:6.9.10
ufw >= 0.36
desktop-base >= 10.0.2
libxrandr2 >= 2:1.5.1
libxtst6 >= 2:1.2.3
libxm4 >= 2.3.8
util-linux >= 2.33
gtk3-nocsd >= 3
bash >= 5.0
findutils >= 4.6.0
sed >= 4.7
cups >= 2.2
ghostscript >= 9.53~
libmspack0 >= 0.10
ibus >= 1.5
libgoogle-perftools4 >= 2.7~
libpython3.9 >= 3.9~
libsasl2-modules-gssapi-mit >= 2.1.~
libqt5widgets5 >= 5.5~
mutter >= 3.38.6~
libqrencode4 >= 4.0.0
libimlib2 >= 1.5.1
<!--NeedCopy-->
Remarque :
pour une matrice des distributions Linux et des versions Xorg que cette version du VDA Linux prend en charge, consultez la section Configuration système requise.
Étape 6b : mettre à niveau le Linux VDA (facultatif)
Le Linux VDA prend en charge les mises à niveau depuis la version la plus récente. Par exemple, vous pouvez mettre à niveau le Linux VDA de 2308 à 2311 et de 1912 LTSR à 2203 LTSR.
sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->
Remarque :
La mise à niveau d’une installation existante remplace les fichiers de configuration sous /etc/xdl. Avant de procéder à une mise à niveau, assurez-vous de sauvegarder les fichiers.
Étape 7 : installer les pilotes NVIDIA GRID
Pour activer HDX 3D Pro, vous devez installer les pilotes NVIDIA GRID sur votre hyperviseur et sur les machines VDA.
Pour installer et configurer le gestionnaire de GPU virtuel NVIDIA GRID (pilote hôte) sur les hyperviseurs spécifiques, consultez les guides suivants :
Pour installer et configurer les pilotes de VM invitée NVIDIA GRID, effectuez les opérations générales suivantes :
- Assurez-vous que la VM invitée est arrêtée.
- Dans le panneau de configuration de l’hyperviseur, attribuez un GPU à la VM.
- Démarrez la VM.
- Installez le pilote de VM invitée sur la VM.
Étape 8 : configurer le Linux VDA
Remarque :
Avant de configurer l’environnement d’exécution, assurez-vous que les paramètres régionaux en_US.UTF-8 sont installés dans votre système d’exploitation. Si les paramètres régionaux ne sont pas disponibles sur votre système d’exploitation, exécutez la commande sudo locale-gen en_US.UTF-8. Pour Debian, modifiez le fichier /etc/locale.gen en supprimant les marques de commentaire de la ligne # en_US.UTF-8 UTF-8, puis exécutez la commande sudo locale-gen.
Après l’installation du package, vous devez configurer le VDA Linux en exécutant le script ctxsetup.sh. Avant d’apporter des modifications, le script vérifie l’environnement et s’assure que toutes les dépendances sont installées. Si nécessaire, vous pouvez exécuter le script à tout moment pour modifier les paramètres.
Vous pouvez exécuter le script manuellement avec invite, ou automatiquement avec réponses pré-configurées. Consultez l’aide sur le script avant de continuer :
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help
<!--NeedCopy-->
Configuration avec invites
Exécutez une configuration manuelle avec questions :
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
Configuration automatique
Pour une installation automatique, les options requises par le script d’installation peuvent être fournies avec des variables d’environnement. Si toutes les variables requises sont présentes, le script ne demande aucune information à l’utilisateur, ce qui permet de procéder à l’installation à l’aide d’un script.
Les variables d’environnement prises en charge sont les suivantes :
-
CTX_XDL_NON_DOMAIN_JOINED=’Y|N’ : indique s’il faut associer la machine à un domaine . La valeur par défaut est “n”. Pour les scénarios liés à un domaine, définissez la valeur sur “n”.
-
CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’ : le Linux VDA requiert que les paramètres de configuration Kerberos s’authentifient auprès des Delivery Controller. La configuration de Kerberos est déterminée depuis l’outil d’intégration d’Active Directory installé et configuré sur le système.
-
CTX_XDL_DDC_LIST=’<list-ddc-fqdns>’ : Linux VDA requiert une liste séparée par des espaces de noms de domaines complets de Delivery Controller. Cette dernière sera utilisée pour l’enregistrement auprès d’un Delivery Controller. Au moins un nom de domaine complet (FQDN) ou CNAME doit être spécifié.
-
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 valeur sur ‘y’.
-
CTX_XDL_HDX_3D_PRO=’y|n’ : Linux VDA prend en charge HDX 3D Pro, un ensemble de technologies d’accélération GPU conçues pour optimiser la virtualisation des applications riches en graphiques. Si HDX 3D Pro est sélectionné, le VDA doit être configuré pour le mode Bureaux VDI (session unique), c’est-à-dire, CTX_XDL_VDI_MODE=‘y’.
-
CTX_XDL_START_SERVICE=’y|n’ : indique si les services Linux VDA sont lancés une fois la configuration de Linux VDA terminée.
-
CTX_XDL_REGISTER_SERVICE=’y|n’ : les services Linux Virtual Desktop sont lancés après le démarrage de la machine.
-
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 (par défaut, les ports 80 et 1494) dans le pare-feu du système pour Linux Virtual Desktop.
-
CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/kde/mate/’<none>‘ : spécifie l’environnement de bureau GNOME, GNOME Classic ou MATE à utiliser dans les sessions. Si vous le définissez sur <none>, le bureau configuré par défaut sur le VDA est utilisé.
Vous pouvez également passer d’un environnement de bureau à l’autre en exécutant des commandes ou en utilisant la barre d’état système. Pour plus d’informations, consultez Commandes de commutation de bureau et barre d’état système.
-
CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime : chemin d’installation du runtime .NET pour la prise en charge du nouveau service Broker Agent (ctxvda). Le chemin d’accès par défaut est ‘/usr/bin’.
-
CTX_XDL_VDA_PORT=port-number : le Linux VDA communique avec les composants Delivery Controller via un port TCP/IP.
-
CTX_XDL_SITE_NAME=<dns-name> : le Linux VDA découvre les serveurs LDAP à l’aide de DNS. Pour limiter les résultats de recherche DNS à un site local, spécifiez un nom de site DNS. Si cela n’est pas nécessaire, définissez la valeur sur ‘<none>‘.
-
CTX_XDL_LDAP_LIST=’<list-ldap-servers>’ : le Linux VDA envoie une requête vers le DNS pour découvrir les serveurs LDAP. Si DNS ne peut pas fournir d’enregistrements de service LDAP, vous pouvez entrer une liste séparée par des espaces de noms de domaines complets LDAP avec ports LDAP. Par exemple, ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268. Pour accélérer les requêtes LDAP dans une forêt Active directory, activez le catalogue global sur un contrôleur de domaine et définissez le numéro de port LDAP correspondant sur 3268. Cette variable est définie sur ‘<none>‘ par défaut.
-
CTX_XDL_SEARCH_BASE=search-base-set : le Linux VDA envoie une requête à LDAP via une base de recherche définie sur la racine du domaine Active Directory (par exemple, D, DC=mycompany,DC=com). Pour améliorer les performances de recherche, vous pouvez spécifier une base de recherche (par exemple, OU=VDI,DC=mycompany,DC=com). Si cela n’est pas nécessaire, définissez la valeur sur ‘<none>‘.
-
CTX_XDL_SUPPORT_DDC_AS_CNAME=’y|n’ : le Linux VDA prend en charge la spécification d’un nom de composant Delivery Controller à l’aide d’un enregistrement DNS CNAME.
Définissez la variable d’environnement et exécutez le script de configuration :
export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest
export CTX_XDL_DDC_LIST='<list-ddc-fqdns>'
export CTX_XDL_VDI_MODE='y|n'
export CTX_XDL_HDX_3D_PRO='y|n'
export CTX_XDL_START_SERVICE='y|n'
export CTX_XDL_REGISTER_SERVICE='y|n'
export CTX_XDL_ADD_FIREWALL_RULES='y|n'
export CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|'<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>'
export CTX_XDL_VDA_PORT='<port-number>'
export CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>'
export CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>'
export CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>'
export CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n'
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->
Lors de l’exécution de la commande sudo, entrez l’option -E pour transmettre les variables d’environnement au nouveau shell créé. Nous vous recommandons de créer un fichier de script shell à partir des commandes précédentes avec #!/bin/bash en tant que première ligne.
Vous pouvez également spécifier tous les paramètres avec une seule commande :
sudo CTX_XDL_NON_DOMAIN_JOINED='n' \
CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest \
CTX_XDL_DDC_LIST='<list-ddc-fqdns>' \
CTX_XDL_VDI_MODE='y|n' \
CTX_XDL_HDX_3D_PRO='y|n' \
CTX_XDL_START_SERVICE='y|n' \
CTX_XDL_REGISTER_SERVICE='y|n' \
CTX_XDL_ADD_FIREWALL_RULES='y|n' \
CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|kde|mate|'<none>' \
CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>' \
CTX_XDL_VDA_PORT='<port-number>' \
CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>' \
CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>' \
CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>' \
CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n' \
/opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->
Supprimer les modifications de configuration
Dans certains scénarios, il peut être nécessaire de supprimer les modifications de configuration effectuées par le script ctxsetup.sh sans désinstaller le package Linux VDA.
Consultez l’aide sur ce script avant de continuer :
sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->
Pour supprimer les modifications de configuration :
sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->
Important :
Ce script supprime toutes les données de configuration de la base de données et empêche Linux VDA de fonctionner.
Journaux de configuration
Les scripts ctxsetup.sh et ctxcleanup.sh affichent les erreurs dans la console, avec des informations supplémentaires consignées dans le fichier journal de configuration /tmp/xdl.configure.log.
Redémarrez les services de Linux VDA pour que les modifications prennent effet.
Désinstaller le logiciel Linux VDA
Pour vérifier que le Linux VDA 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 Linux VDA :
dpkg -r xendesktopvda
<!--NeedCopy-->
Remarque :
La désinstallation du logiciel Linux VDA supprime le PostgreSQL associé et d’autres données de configuration. Toutefois, le package PostgreSQL et les autres packages dépendants qui ont été installés avant l’installation du Linux VDA ne sont pas supprimés.
Conseil :
Les informations figurant dans cette section ne couvrent pas la suppression de packages dépendants, y compris PostgreSQL.
Étape 9 : exécuter XDPing
Exécutez sudo /opt/Citrix/VDA/bin/xdping
pour vérifier les problèmes de configuration courants avec un environnement VDA Linux. Pour de plus amples informations, consultez la section XDPing.
Étape 10 : exécuter le Linux VDA
Une fois que vous avez configuré le Linux VDA à l’aide du script ctxsetup.sh, utilisez les commandes suivantes pour contrôler le Linux VDA.
Démarrer Linux VDA :
Pour démarrer les services Linux VDA :
sudo systemctl start ctxhdx
sudo systemctl start ctxvda
<!--NeedCopy-->
Arrêter Linux VDA :
Pour arrêter les services Linux VDA :
sudo systemctl stop ctxvda
sudo systemctl stop ctxhdx
<!--NeedCopy-->
Remarque :
Avant d’arrêter les services ctxvda et ctxhdx, exécutez la commande systemctl stop ctxmonitord pour arrêter le démon du service de surveillance. Sinon, le démon du service de surveillance redémarre les services que vous avez arrêtés.
Redémarrer Linux VDA :
Pour redémarrer les services Linux VDA :
sudo systemctl stop ctxvda
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda
<!--NeedCopy-->
Vérifier l’état de Linux VDA :
Pour vérifier l’état de fonctionnement des services de Linux VDA :
sudo systemctl status ctxvda
sudo systemctl status ctxhdx
<!--NeedCopy-->
Étape 11 : créer des catalogues de machines
Le processus de création de catalogues de machines et d’ajout de machines Linux VDA est similaire à l’approche traditionnelle avec les VDA Windows. Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, consultez les sections Créer des catalogues de machines et Gérer des catalogues de machines.
Pour la création de catalogues de machines contenant des machines Linux VDA, il existe quelques restrictions qui différencient ce processus de la création de catalogues de machines pour VDA Windows :
- Pour le système d’exploitation, sélectionnez :
- l’option OS à sessions multiples pour un modèle de mise à disposition de bureaux partagés hébergés ;
- l’option OS mono-session pour un modèle de mise à disposition de bureaux dédiés VDI.
- Ne combinez pas de machines Linux VDA et Windows dans le même catalogue de machines.
Remarque :
Les versions antérieures de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux. » Toutefois, la sélection de l’option OS de serveur Windows ou OS de serveur implique un modèle de mise à disposition équivalent de bureaux partagés hébergés. La sélection de l’option OS de bureau Windows ou OS de bureau implique un modèle de mise à disposition d’un utilisateur unique par machine.
Conseil :
Si une supprimez une machine puis que vous la rejoignez au domaine Active Directory, vous devez supprimer et rajouter la machine au catalogue de machines.
Étape 12 : créer des groupes de mise à disposition
Le processus de création d’un groupe de mise à disposition et d’ajout de catalogues de machines contenant des machines Linux VDA est presque identique aux machines VDA Windows. Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, consultez la section Créer des groupes de mise à disposition.
Lors de la création de groupes de mise à disposition qui contiennent des catalogues de machines Linux VDA, les restrictions suivantes s’appliquent :
- Assurez-vous que les utilisateurs et les groupes AD que vous sélectionnez ont été correctement configurés pour l’ouverture de session sur les machines Linux VDA.
- N’autorisez pas l’ouverture de session d’utilisateurs non authentifiés (anonymes).
- Ne combinez pas le groupe de mise à disposition avec des catalogues de machines contenant des machines Windows.
Pour plus d’informations sur la création de catalogues de machines et de groupes de mise à disposition, consultez Citrix Virtual Apps and Desktops 7 2402 LTSR.
Dans cet article
-
Étape 1 : préparer les informations de configuration et la machine Linux
- Étape 1a : définir le nom d’hôte
- Étape 1b : attribuer une adresse de bouclage au nom d’hôte
- Étape 1c : vérifier le nom d’hôte
- Étape 1d : désactiver DNS multidiffusion
- Étape 1e : vérifier la résolution de nom et l’accessibilité du service
- Étape 1f : configurer la synchronisation de l’horloge (chrony)
- Étape 1g : installer les packages
- Étape 1h : ajouter des référentiels pour installer les dépendances nécessaires
- Étape 1i : installer et spécifier la base de données à utiliser
- Étape 2 : préparer l’hyperviseur
- Étape 3 : ajouter la VM Linux au domaine Windows
- Étape 4 : installer .NET
- Étape 5 : télécharger le package Linux VDA
- Étape 6 : installer le Linux VDA
- Étape 7 : installer les pilotes NVIDIA GRID
- Étape 8 : configurer le Linux VDA
- Étape 9 : exécuter XDPing
- Étape 10 : exécuter le Linux VDA
- Étape 11 : créer des catalogues de machines
- Étape 12 : créer des groupes de mise à disposition