Installer manuellement le VDA Linux sur SUSE

Important :

Pour les nouvelles installations, nous vous recommandons d’utiliser l’installation facile pour une installation rapide. L’installation facile permet de gagner du temps et de réduire les efforts, et est moins sujette aux erreurs que l’installation manuelle détaillée dans cet article.

Étape 1 : Préparer les informations de configuration et la machine Linux

Étape 1a : Lancer l’outil YaST

L’outil YaST de SUSE Linux Enterprise est utilisé pour configurer tous les aspects du système d’exploitation.

Pour lancer l’outil YaST en mode texte :

su -

yast
<!--NeedCopy-->

Pour lancer l’outil YaST basé sur l’interface utilisateur :

su -

yast2 &
<!--NeedCopy-->

-  ### Étape 1b : Configurer la mise en réseau

Les sections suivantes fournissent des informations sur la configuration des différents paramètres et services réseau utilisés par le VDA Linux. La configuration du réseau est effectuée via l’outil YaST, et non via d’autres méthodes telles que Network Manager. Ces instructions sont basées sur l’utilisation de l’outil YaST basé sur l’interface utilisateur. L’outil YaST en mode texte peut être utilisé, mais sa méthode de navigation est différente et n’est pas documentée ici.

Configurer le nom d’hôte et le système de noms de domaine (DNS)

1. Lancez l’outil YaST basé sur l’interface utilisateur.
2. Sélectionnez Système, puis Paramètres réseau.
3. Ouvrez l’onglet Nom d’hôte/DNS.
4. Sélectionnez l’option non pour Définir le nom d’hôte via DHCP.
5. Sélectionnez l’option Utiliser une stratégie personnalisée pour Modifier la configuration DNS.

6. Modifiez les éléments suivants pour refléter votre configuration réseau :

   • Nom d’hôte statique – Ajoutez le nom d’hôte DNS de la machine.
   • Serveur de noms – Ajoutez l’adresse IP du serveur DNS. Il s’agit généralement de l’adresse IP du contrôleur de domaine AD.
   • Liste de recherche de domaine – Ajoutez le nom de domaine DNS.

7. 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 <FQDN du VDA> <nom d’hôte du VDA> localhost

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.

Vérifier le nom d’hôte

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

hostname
<!--NeedCopy-->

Cette commande renvoie uniquement le nom d’hôte de la machine et non son nom de domaine complet (FQDN).

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

hostname -f
<!--NeedCopy-->

Cette commande renvoie le FQDN de la machine.

• 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 parvenez pas à résoudre le FQDN ou à envoyer un ping à l’une de ces machines, examinez les étapes avant de continuer.

Étape 1c : Configurer le service NTP

Il est crucial de maintenir une synchronisation horaire précise entre les VDA, les Delivery Controller et les contrôleurs de domaine. L’hébergement du VDA Linux en tant que machine virtuelle (VM) peut entraîner des problèmes de décalage horaire. Pour cette raison, il est préférable de maintenir l’heure à l’aide d’un service NTP distant. Certaines modifications peuvent être nécessaires aux paramètres NTP par défaut.

Pour SUSE 15.5 :

1. Lancez l’outil YaST basé sur l’interface utilisateur.
2. Sélectionnez Services réseau, puis Configuration NTP.
3. Dans la section Démarrer le démon NTP, sélectionnez Maintenant et au démarrage.
4. Sélectionnez Dynamique pour Source de configuration.
5. Ajoutez les serveurs NTP si nécessaire. Le service NTP est normalement hébergé sur le contrôleur de domaine Active Directory.

6. Supprimez ou commentez la ligne suivante dans /etc/chrony.conf si elle existe.

   include /etc/chrony.d/*.conf

   Après avoir modifié chrony.conf, redémarrez le service chronyd.

   sudo systemctl restart chronyd.service
   <!--NeedCopy-->
   

Étape 1d : Installer les packages dépendants du VDA Linux

Le logiciel VDA Linux pour SUSE Linux Enterprise dépend des packages suivants :

• OpenJDK 11
• Open Motif Runtime Environment 2.3.1 ou version ultérieure
• Cups 1.6.0 ou version ultérieure
• ImageMagick 6.8 ou version ultérieure

Ajouter des dépôts

Vous pouvez obtenir la plupart des packages requis, à l’exception d’ImageMagick, à partir des dépôts officiels. Pour obtenir les packages ImageMagick, activez le dépôt sle-module-desktop-applications à l’aide de YaST ou de la commande suivante :

SUSEConnect -p sle-module-desktop-applications/<version number>/x86_64

Installer le client Kerberos

Installez le client Kerberos pour l’authentification mutuelle entre le VDA Linux et les Delivery Controller :

sudo zypper install krb5-client
<!--NeedCopy-->

La configuration du client Kerberos dépend de l’approche d’intégration d’Active Directory utilisée. Consultez la description suivante.

• Installer OpenJDK 11

Le VDA Linux nécessite la présence d’OpenJDK 11.

Pour installer OpenJDK 11, exécutez la commande suivante :

sudo zypper install java-11-openjdk
<!--NeedCopy-->

Installer et spécifier une base de données à utiliser

Remarque :

• Nous vous recommandons d’utiliser SQLite uniquement pour le mode VDI et PostgreSQL pour un modèle de livraison de bureaux partagés hébergés.

• Pour l’installation facile et MCS, vous pouvez spécifier SQLite ou PostgreSQL à utiliser sans avoir à les installer manuellement. Sauf indication contraire via /etc/xdl/db.conf, le VDA Linux utilise PostgreSQL par défaut.

• Pour les installations manuelles, vous devez installer SQLite, PostgreSQL ou les deux manuellement. Si vous installez à la fois SQLite et PostgreSQL, vous pouvez spécifier l’un d’eux à utiliser en modifiant /etc/xdl/db.conf après l’installation du package VDA Linux.

Cette section décrit comment installer PostgreSQL et SQLite et comment spécifier l’un d’eux à utiliser.

Installer PostgreSQL

Pour installer Postgresql, exécutez les commandes suivantes :

sudo zypper install postgresql-server

sudo zypper install postgresql-jdbc
<!--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 restart postgresql
<!--NeedCopy-->

• Installer SQLite

Pour SUSE, exécutez la commande suivante pour installer SQLite :

sudo zypper install sqlite3
<!--NeedCopy-->

Spécifier une base de données à utiliser

-  Si vous installez à la fois SQLite et PostgreSQL, vous pouvez spécifier l’une d’elles à utiliser en modifiant **/etc/xdl/db.conf** après l’installation du package Linux VDA.

    -  1.  Exécutez **/opt/Citrix/VDA/sbin/ctxcleanup.sh**. Omettez cette étape s’il s’agit d’une nouvelle installation.
    -  1.  Modifiez **/etc/xdl/db.conf** pour spécifier une base de données à utiliser.
    -  1.  Exécutez **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 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 XenServer (anciennement Citrix Hypervisor™)

Si la fonctionnalité de synchronisation de l’heure XenServer® est activée, vous rencontrez des problèmes avec NTP et XenServer au sein de chaque machine virtuelle Linux paravirtualisée. Les deux tentent de gérer l’horloge système. Pour éviter que l’horloge ne se désynchronise avec d’autres serveurs, synchronisez l’horloge système de chaque invité Linux avec 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.

Si vous exécutez un noyau Linux paravirtualisé avec les outils XenServer VM Tools installés, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure XenServer est présente et activée depuis la machine virtuelle Linux :

su -

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

Cette commande renvoie 0 ou 1 :

    -  0 - La fonctionnalité de synchronisation de l’heure est activée et doit être désactivée.

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

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

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

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

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

reboot
<!--NeedCopy-->

Après le redémarrage, vérifiez que le paramètre est correct :

su -

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

Cette commande renvoie la valeur 1.

Corriger la synchronisation de l’heure sur Microsoft Hyper-V

Les machines virtuelles Linux avec les services d’intégration Linux Hyper-V installés peuvent appliquer la fonctionnalité de synchronisation de l’heure Hyper-V pour utiliser l’heure du système d’exploitation hôte. Pour garantir que l’horloge système reste précise, activez cette fonctionnalité en même temps que les services NTP.

Depuis le système d’exploitation de gestion :

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

Remarque :

Cette approche est différente de VMware et XenServer (anciennement 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.

Corriger la synchronisation de l’heure sur ESX et ESXi

Si la fonctionnalité de synchronisation de l’heure VMware est activée, vous rencontrez des problèmes avec NTP et l’hyperviseur au sein de chaque machine virtuelle Linux paravirtualisée. Les deux tentent de synchroniser l’horloge système. Pour éviter que l’horloge ne se désynchronise avec d’autres serveurs, synchronisez l’horloge système de chaque invité Linux avec NTP. Ce cas nécessite la désactivation de la synchronisation de l’heure de l’hôte.

Si vous exécutez un noyau Linux paravirtualisé avec les outils VMware Tools installés :

1. Ouvrez le client vSphere.
2. Modifiez les paramètres de la machine virtuelle Linux.
3. Dans la boîte de dialogue Propriétés de la machine virtuelle, ouvrez l’onglet Options.
4. Sélectionnez VMware Tools.
5. Dans la zone Avancé, désélectionnez Synchroniser l’heure de l’invité avec l’hôte.

Étape 3 : Ajouter la machine virtuelle Linux au domaine Windows

Les méthodes suivantes sont disponibles pour ajouter des machines Linux au domaine Active Directory (AD) :

• Samba Winbind
• 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 pour le compte dans AD.

Samba Winbind

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

1. Lancez YaST, sélectionnez Services réseau, puis Adhésion au domaine Windows.

2. Apportez les modifications suivantes :

   • Définissez le Domaine ou groupe de travail sur le nom de votre domaine Active Directory ou l’adresse IP du contrôleur de domaine. Assurez-vous que le nom de domaine est en majuscules.
   • Cochez Utiliser les informations SMB pour l’authentification Linux.
   • Cochez Créer un répertoire personnel lors de la connexion.
   • Cochez Authentification unique pour SSH.
   • Assurez-vous que Authentification hors ligne n’est pas cochée. Cette option n’est pas compatible avec le VDA Linux.

3. Cliquez sur OK. Si vous êtes invité à installer des packages, cliquez sur Installer.

4. Si un contrôleur de domaine est trouvé, il vous demande si vous souhaitez joindre le domaine. Cliquez sur Oui.

5. Lorsque vous y êtes invité, saisissez les informations d’identification d’un utilisateur de domaine ayant l’autorisation d’ajouter des machines au domaine et cliquez sur OK.

6. Redémarrez vos services manuellement ou redémarrez la machine. Nous vous recommandons de redémarrer la machine :

   su -
   reboot
   <!--NeedCopy-->
   

Vérifier l’adhésion au domaine

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

Exécutez la commande net ads de Samba pour vérifier que la machine est jointe à un domaine :

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

Exécutez la commande suivante pour vérifier les informations supplémentaires sur le domaine et l’objet ordinateur :

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

Vérifier la configuration Kerberos

Assurez-vous que le fichier keytab système a été créé et contient des clés valides :

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

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms de principal et de suites de chiffrement. Exécutez la commande Kerberos kinit pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit -k MACHINE\$@REALM
<!--NeedCopy-->

Les noms de machine et de royaume doivent être spécifiés en majuscules. Le signe dollar ($) doit être échappé avec une barre oblique inverse (\) pour éviter la substitution de shell. Dans certains environnements, le nom de domaine DNS est différent du nom de royaume Kerberos. Assurez-vous que le nom de royaume est utilisé. Si cette commande réussit, aucune sortie n’est affichée.

Vérifiez que le ticket TGT pour le compte 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 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 de royaume Kerberos. Pour le shell bash, le caractère de barre oblique inverse (\) doit être échappé avec une autre barre oblique inverse. Cette commande renvoie un message indiquant la réussite ou l’échec.

Vérifiez que le module PAM Winbind est correctement configuré. Pour ce faire, 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
<!--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 de l’utilisateur sont valides et n’ont pas expiré :

klist
<!--NeedCopy-->

Quittez la session.

exit
<!--NeedCopy-->

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

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

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

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

Pour permettre aux utilisateurs du 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 d’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, de RDP, de SSH ou de tout autre protocole de connexion à distance.

Configurer Quest sur le VDA Linux

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 les connexions des utilisateurs du domaine via HDX et d’autres services tels que su, ssh et RDP, configurez PAM et NSS manuellement :

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 ayant l’autorisation de joindre des machines au domaine Active Directory. Le nom de domaine est le nom DNS du domaine, par exemple, example.com.

Redémarrez la machine Linux après la jonction au domaine.

Vérifier l’appartenance au domaine

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

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

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

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

Vérifier l’authentification de l’utilisateur

Vérifiez que Quest peut authentifier les utilisateurs du domaine via PAM. Pour ce faire, 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
<!--NeedCopy-->

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

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

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

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

Quittez la session.

exit
<!--NeedCopy-->

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

Centrify DirectControl

Joindre un domaine Windows

Une fois l’agent Centrify DirectControl installé, joignez la machine Linux au domaine Active Directory à l’aide de la commande Centrify adjoin :

sudo adjoin -w -V -u user domain-name
<!--NeedCopy-->

L’utilisateur est tout utilisateur de domaine Active Directory ayant l’autorisation de joindre des machines au domaine Active Directory. Le nom de domaine est le nom du domaine auquel joindre la machine Linux.

Vérifier l’appartenance au domaine

Le Delivery Controller exige que toutes les machines VDA (VDA Windows et Linux) possèdent un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux jointe à Centrify fait partie du domaine :

sudo adinfo
<!--NeedCopy-->

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

Des informations système et de diagnostic plus complètes sont disponibles à 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 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

SSSD

Si vous utilisez SSSD sur SUSE, suivez les instructions de cette section. Cette section contient des instructions pour joindre une machine VDA Linux à un domaine Windows et fournit des conseils pour la configuration de l’authentification Kerberos.

Pour configurer SSSD sur SUSE, suivez les étapes suivantes :

1. Joignez le domaine et créez un keytab d’hôte
2. Configurez PAM pour SSSD
3. Configurez SSSD
4. Activez SSSD
5. Vérifiez l’appartenance au domaine
6. Vérifiez la configuration Kerberos
7. Vérifiez l’authentification de l’utilisateur

Joindre le domaine et créer un keytab d’hôte

SSSD ne fournit pas de fonctions client Active Directory pour joindre le domaine et gérer le fichier keytab système. Vous pouvez utiliser l’approche Samba à la place. Suivez les étapes suivantes avant de configurer SSSD.

1. Arrêtez et désactivez le démon Name Service Cache Daemon (NSCD).

   sudo systemctl stop nscd
   sudo systemctl disable nscd
   <!--NeedCopy-->
   

2. Vérifiez le nom d’hôte et la synchronisation horaire Chrony.

   hostname
   hostname -f
   chronyc traking
   <!--NeedCopy-->
   

3. Installez ou mettez à jour les packages requis :

   sudo zypper install samba-client sssd-ad
   <!--NeedCopy-->
   

4. Modifiez le fichier /etc/krb5.conf en tant qu’utilisateur root pour permettre à l’utilitaire kinit de communiquer avec le domaine cible. Ajoutez les entrées suivantes sous les sections [libdefaults], [realms] et [domain_realm] :

   Remarque :

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

   [libdefaults]
   
       dns_canonicalize_hostname = false
   
       rdns = false
   
       default_realm = REALM
   
       forwardable = true
   
   [realms]
   
       REALM = {
   
           kdc = fqdn-of-domain-controller
   
           default_domain = realm
   
           admin_server = fqdn-of-domain-controller
       }
   [domain_realm]
   
       .realm = REALM
   <!--NeedCopy-->
   

   realm est le nom du royaume Kerberos, tel que example.com. REALM est le nom du royaume Kerberos en majuscules, tel que EXAMPLE.COM.

5. Modifiez /etc/samba/smb.conf en tant qu’utilisateur root pour permettre à l’utilitaire net de communiquer avec le domaine cible. Ajoutez les entrées suivantes sous la section [global] :

   [global]
       workgroup = domain
   
       client signing = yes
   
       client use spnego = yes
   
       kerberos method = secrets and keytab
   
       realm = REALM
   
       security = ADS
   <!--NeedCopy-->
   

   domain est le nom NetBIOS court d’un domaine Active Directory, tel que EXAMPLE.

6. Modifiez les entrées passwd et group dans le fichier /etc/nsswitch.conf pour référencer SSSD lors de la résolution des utilisateurs et des groupes.

   passwd: compat sss
   
   group: compat sss
   <!--NeedCopy-->
   

7. Utilisez le client Kerberos configuré pour vous authentifier auprès du domaine cible en tant qu’administrateur.

   
   -  kinit administrator
   
   <!--NeedCopy-->
   

8. Utilisez l’utilitaire net pour joindre le système au domaine et générer un fichier keytab système.

   net ads join osname="SUSE Linux Enterprise Server" osVersion=15 -U administrator
   <!--NeedCopy-->
   

Configurer PAM pour SSSD

Avant de configurer PAM pour SSSD, installez ou mettez à jour les packages requis :

sudo zypper install sssd sssd-ad
<!--NeedCopy-->

Configurez le module PAM pour l’authentification des utilisateurs via SSSD et créez des répertoires personnels pour les connexions des utilisateurs.

sudo pam-config --add  --sss
sudo pam-config --add --mkhomedir
<!--NeedCopy-->

Configurer SSSD

• 1. Modifiez /etc/sssd/sssd.conf en tant qu’utilisateur root pour permettre au démon SSSD de communiquer avec le domaine cible. Voici un exemple de configuration sssd.conf (des options supplémentaires peuvent être ajoutées si nécessaire) :

   -  [sssd]
   -  config_file_version = 2
   -  services = nss,pam
   -  domains = domain-dns-name
  
   -  [domain/domain-dns-name]
   -  id_provider = ad
   -  auth_provider = ad
   -  access_provider = ad
   -  ad_domain = domain-dns-name
   -  ad_server = fqdn-of-domain-controller
       ldap_id_mapping = true
       ldap_schema = ad
  
   ## Kerberos settings
  
       krb5_ccachedir = /tmp
       krb5_ccname_template = FILE:%d/krb5cc_%U
  
   ## Comment out if the users have the shell and home dir set on the AD side
  
       fallback_homedir = /home/%d/%u
       default_shell = /bin/bash
  
   ## Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
  
   ## ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
  
       ad_gpo_access_control = permissive
  
   <!--NeedCopy-->
  

  domain-dns-name est le nom de domaine DNS, tel que example.com.

  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, Active Directory doit être en mesure de fournir des extensions POSIX. ad_gpo_access_control est défini sur permissive pour éviter une erreur de connexion non valide pour les sessions Linux. Consultez les pages de manuel pour sssd.conf et sssd-ad.

1. Définissez la propriété et les autorisations du fichier sssd.conf :

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

Activer SSSD

Exécutez les commandes suivantes pour activer et démarrer le démon SSSD au démarrage du système :

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

Vérifier l’appartenance au domaine

1. Exécutez la commande net ads de Samba pour vérifier que la machine est jointe à un domaine :

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

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

Assurez-vous que le fichier keytab système a été créé et contient des clés valides :

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

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms de principal et de suites de chiffrement.

Exécutez la commande Kerberos kinit pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->

Les noms de machine et de royaume doivent être spécifiés en majuscules. Le signe dollar ($) doit être échappé avec une barre oblique inverse (\) pour éviter la substitution de shell. Dans certains environnements, le nom de domaine DNS est différent du nom de royaume Kerberos. Assurez-vous que le nom de royaume est utilisé. Si cette commande réussit, aucune sortie n’est affichée.

Vérifiez que le ticket TGT pour le compte de 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 PAM SSSD est configuré correctement, connectez-vous au VDA Linux à l’aide d’un compte utilisateur de domaine qui n’a pas é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 vous connectant directement à la console Gnome ou KDE. Passez à l’étape Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

• PBIS

• Télécharger le package PBIS requis

Par exemple :

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

Rendre le script d’installation PBIS exécutable

Par exemple :

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

Exécuter le script d’installation PBIS

Par exemple :

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

Joindre 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 machines au domaine :

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

L’utilisateur est un utilisateur de domaine qui dispose des autorisations nécessaires pour ajouter des machines 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 /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 (OU) actuellement joints. Sinon, seul le nom d’hôte apparaît.

Vérifier l’authentification de l’utilisateur

Vérifiez que PBIS peut authentifier les utilisateurs de domaine via PAM. Pour ce faire, connectez-vous au VDA Linux à l’aide d’un compte utilisateur de domaine qui n’a pas été utilisé auparavant.

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 Étape 6 : Installer le VDA Linux après la vérification de la jonction au domaine.

Étape 4 : Installer .NET

En plus du runtime .NET, vous devez installer le runtime .ASP.NET Core sur toutes les distributions Linux prises en charge avant d’installer ou de mettre à niveau le VDA Linux. La version 6 est requise pour Amazon Linux 2. La version 8 est requise pour les autres distributions.

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/fr-fr/dotnet/core/install/linux-package-managers.

Après avoir installé .NET, exécutez la commande which dotnet pour trouver votre chemin d’exécution.

En fonction de la sortie de la commande, définissez le chemin binaire du runtime .NET. Par exemple, si la commande de sortie est /aa/bb/dotnet, utilisez /aa/bb comme chemin binaire .NET.

Étape 5 : Télécharger le package VDA Linux

1. Accédez à la page de téléchargement de Citrix Virtual Apps and Desktops.
2. Développez la version appropriée de Citrix Virtual Apps and Desktops.

3. Développez Components pour trouver le VDA Linux. Par exemple :

   

4. Cliquez sur le lien du VDA Linux pour accéder aux téléchargements du VDA Linux.

   

5. Téléchargez le package VDA Linux qui correspond à votre distribution Linux.

6. Téléchargez la clé publique GPG que vous pouvez utiliser pour vérifier l’intégrité du package VDA Linux. Par exemple :

   

   Pour vérifier l’intégrité du package VDA Linux à l’aide de la clé publique, exécutez les commandes suivantes pour importer la clé publique dans la base de données RPM et vérifier l’intégrité du package :

   rpmkeys --import <path to the public key>
   rpm --checksig --verbose <path to the Linux VDA package>
   <!--NeedCopy-->
   

Étape 6 : Installer le VDA Linux

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

Si vous avez installé une version antérieure autre que les deux précédentes et une version LTSR, désinstallez-la avant d’installer la nouvelle version.

1. Arrêtez les services 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 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.

2. Désinstallez le package :

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

Important :

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

Remarque :

Vous pouvez trouver les composants installés sous /opt/Citrix/VDA/.

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

Étape 6b : Installer le VDA Linux

Installez le logiciel VDA Linux à l’aide de Zypper :

sudo zypper install XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->

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

sudo rpm -i XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->

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

Le VDA Linux prend en charge les mises à niveau à partir de la version la plus récente. Par exemple, vous pouvez mettre à niveau le VDA Linux de 2308 vers 2311 et de 1912 LTSR vers 2203 LTSR.

Remarque :

La mise à niveau d’une installation existante écrase les fichiers de configuration sous /etc/xdl. Avant d’effectuer une mise à niveau, assurez-vous de sauvegarder les fichiers.

sudo zypper -i install <PATH>/<Linux VDA RPM>
<!--NeedCopy-->

Liste des dépendances RPM pour SUSE 15 :

java-11-openjdk >= 11

ImageMagick >= 7.0

dbus-1 >= 1.12.2

dbus-1-x11 >= 1.12.2

xorg-x11 >= 7.6_1

libXpm4 >= 3.5.12

libXrandr2 >= 1.5.1

libXtst6 >= 1.2.3

pam >= 1.3.0

bash >= 4.4

findutils >= 4.6

gawk >= 4.2

sed >= 4.4

cups >= 2.2

cups-filters >= 1.25

libxml2-2 >= 2.9

libmspack0 >= 0.6

ibus >= 1.5

libtcmalloc4 >= 2.5

libcap-progs >= 2.26

mozilla-nss-tools >= 3.53.1

libpython3_6m1_0 >= 3.6~

libQt5Widgets5 >= 5.12

libqrencode4 >= 4.0.0

libImlib2-1 >= 1.4.10
<!--NeedCopy-->

Important :

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

Étape 7 : Installer les pilotes NVIDIA GRID

L’activation de HDX 3D Pro nécessite l’installation des pilotes NVIDIA GRID sur votre hyperviseur et sur les machines VDA.

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

• XenServer
• VMware ESX
• Nutanix AHV

Pour installer et configurer les pilotes de machine virtuelle invitée NVIDIA GRID, effectuez les étapes générales suivantes :

1. Assurez-vous que la machine virtuelle invitée est arrêtée.
2. Dans le panneau de configuration de l’hyperviseur, allouez un GPU à la machine virtuelle.
3. Démarrez la machine virtuelle.
4. Installez le pilote de machine virtuelle invitée sur la machine virtuelle.

Étape 8 : Configurer le VDA Linux

Remarque :

Avant de configurer l’environnement d’exécution, assurez-vous que la locale en_US.UTF-8 est installée sur votre système d’exploitation. Si la locale n’est pas disponible 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 décommentant 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 que le script n’apporte des modifications, il 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 sur le script avant de continuer :

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

Configuration guidée

Exécutez une configuration manuelle avec des questions guidées :

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

Configuration automatisée

Pour une installation automatisée, fournissez les options requises par le script de configuration avec des variables d’environnement. Si toutes les variables requises sont présentes, le script ne demande aucune information.

Les variables d’environnement prises en charge incluent :

• CTX_XDL_NON_DOMAIN_JOINED=’y|n’ – Indique si la machine doit être jointe à un domaine. La valeur par défaut est ‘n’. Pour les scénarios joints à un domaine, définissez-la sur ‘n’.

• CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’ – Le VDA Linux nécessite 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.

• CTX_XDL_DDC_LIST=’<list-ddc-fqdns>‘ – Le VDA Linux nécessite 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 CNAME doit être spécifié.

• CTX_XDL_VDI_MODE=’y|n’ – Indique s’il faut configurer la machine comme un modèle de livraison de bureau dédié (VDI) ou un modèle de livraison de bureau partagé hébergé. Pour les environnements HDX 3D Pro, définissez la valeur sur ‘y’.

• 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 de bureaux VDI (session unique) - (c’est-à-dire, CTX_XDL_VDI_MODE=‘y’).

• CTX_XDL_START_SERVICE=’y|n’ – Détermine si les services VDA Linux sont démarrés une fois la configuration terminée.

• CTX_XDL_REGISTER_SERVICE=’y|n’ – Les services Linux Virtual Desktop sont démarrés après le démarrage de la machine.

• CTX_XDL_ADD_FIREWALL_RULES=’y|n’ – Les services VDA Linux nécessitent que les connexions réseau entrantes soient autorisées via le pare-feu système. Vous pouvez ouvrir automatiquement les ports requis (par défaut les ports 80 et 1494) dans le pare-feu système pour le Linux Virtual Desktop.

• CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/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 par défaut configuré sur le VDA est utilisé.

  Vous pouvez également basculer entre les environnements de bureau en exécutant des commandes ou en utilisant la barre d’état système. Pour plus d’informations, consultez Commandes de basculement de bureau et Barre d’état système.

• CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime – Chemin d’installation de .NET pour prendre en charge le nouveau service d’agent de courtier (ctxvda). Le chemin par défaut est ‘/usr/bin’.

• CTX_XDL_VDA_PORT=port-number – Le VDA Linux communique avec les Delivery Controllers via un port TCP/IP.

• CTX_XDL_SITE_NAME=<dns-name> – Le VDA Linux découvre les serveurs LDAP via DNS. Pour limiter les résultats de la recherche DNS à un site local, spécifiez un nom de site DNS. Si cela n’est pas nécessaire, définissez sur ‘<none>‘.

• 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 ad2.mycompany.com:3268 ad3.mycompany.com:3268. Pour permettre des requêtes LDAP plus rapides au sein d’une forêt Active Directory, activez le catalogue global sur un contrôleur de domaine et spécifiez le numéro de port LDAP pertinent comme 3268. Cette variable est définie sur ‘<none>‘ par défaut.

• CTX_XDL_SEARCH_BASE=search-base-set – Le VDA Linux interroge LDAP via une base de recherche définie à la racine du domaine Active Directory (par exemple, DC=mycompany,DC=com). Pour améliorer les performances de recherche, vous pouvez spécifier une base de recherche (par exemple, OU=VDI,DC=mycompany,DC=com). Si cela n’est pas nécessaire, définissez sur ‘<none>‘.

• 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éfinissez la variable d’environnement et exécutez le script de configuration :

export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=sssd|winbind|centrify|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|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-->

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.

Vous pouvez également spécifier tous les paramètres à l’aide d’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|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, vous devrez peut-être 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 /usr/local/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

Pour supprimer les modifications de configuration :

sudo /usr/local/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 un fichier journal de configuration :

/tmp/xdl.configure.log

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

É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 plus d’informations, consultez XDPing.

Étape 10 : Exécuter le VDA Linux

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

Démarrer le VDA Linux :

Pour démarrer les services VDA Linux :

sudo 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 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 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 11 : Créer des catalogues de machines

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

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

• Pour le système d’exploitation, sélectionnez :
  • L’option 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 VDA Linux et Windows dans le même catalogue de machines.

Remarque :

Les premières versions de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux ». Cependant, la sélection de l’option 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 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 VDA Linux est presque identique à celui des machines VDA Windows. Pour une description plus détaillée de la façon d’accomplir ces tâches, consultez Créer des groupes de mise à disposition.

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

• Assurez-vous que les utilisateurs et groupes AD que vous sélectionnez ont été correctement configurés pour se connecter aux machines VDA Linux.
• 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.

Important :

La publication d’applications est prise en charge avec le VDA Linux version 1.4 et ultérieure. Cependant, le VDA Linux ne prend pas en charge la mise à disposition de bureaux et d’applications sur la même machine.

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