Installer le Linux VDA manuellement sur SUSE

Important :

Pour les nouvelles installations, nous vous recommandons d’utiliser Easy Install pour 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 1 a : démarrer l’outil YaST

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

Pour démarrer l’outil YaST basé sur texte :

  su -

  yast
<!--NeedCopy-->

Pour démarrer l’outil YaST basé sur l’interface utilisateur :

  su -

  yast2 &
<!--NeedCopy-->

Étape 1b : configurer le réseau

Les sections suivantes fournissent des informations sur la configuration des paramètres et services réseau utilisés par le Linux VDA. La configuration du réseau est effectuée par le biais de l’outil YaST, et non via d’autres méthodes, telles que le Gestionnaire de réseau. Ces instructions sont basées sur l’utilisation de l’outil YaST avec interface utilisateur. L’outil YaST basé sur texte peut être utilisé mais propose une autre méthode de navigation qui n’est pas abordée ici.

Configurer le nom d’hôte et le DNS (Domain Name System)

1. Démarrez l’outil YaST basé sur l’interface utilisateur.
2. Sélectionnez System (Système), puis Network Settings (Paramètres réseau).
3. Ouvrez l’onglet Hostname/DNS (Nom d’hôte/DNS).
4. Sélectionnez l’option no pour Set hostname via DHCP (Définir le nom d’hôte via DHCP).
5. Sélectionnez l’option Use Custom Policy (Utiliser une stratégie personnalisée) pour Modify DNS Configuration (Modifier la configuration DNS).

6. Modifiez les options suivantes pour refléter votre configuration réseau :

   • Static Hostname (Nom d’hôte statique) : ajoutez le nom d’hôte DNS de la machine.
   • Name Server (Nom du serveur) : entrez l’adresse IP du serveur DNS. Il s’agit généralement de l’adresse IP du contrôleur de domaine AD.
   • Domain Search List (Liste de recherche de domaine) : ajoutez le nom de domaine DNS.

7. Modifiez la ligne suivante du fichier /etc/hosts pour inclure le nom de domaine complet et le nom d’hôte comme deux premières entrées :

   127.0.0.1 <FQDN of the VDA> <hostname of the VDA> localhost

Remarque

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

Utilisez uniquement les caractères a–z, A–Z, 0–9 et tiret (-). Évitez les traits 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.

Vérifier le nom d’hôte

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 (FQDN).

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.

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 1c : configurer le service NTP

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 NTP à distance. Il peut être nécessaire d’apporter des modifications aux paramètres NTP par défaut.

Pour SUSE 15.5 :

1. Démarrez l’outil YaST basé sur l’interface utilisateur.
2. Sélectionnez Network Services (Services réseau), puis NTP Configuration (Configuration NTP).
3. Dans la section Start NTP Daemon (Lancer le démon NTP), sélectionnez Now and on Boot (Maintenant et au démarrage).
4. Sélectionnez Dynamic (Dynamique) pour Configuration Source (Source de configuration).
5. Ajoutez des serveurs NTP si nécessaire. Le service NTP est généralement 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 de Linux VDA

Le logiciel Linux VDA pour SUSE Linux Enterprise fonctionne avec les 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 référentiels

Vous pouvez obtenir la plupart des packages requis à partir des référentiels officiels, à l’exception d’ImageMagick. Pour obtenir les packages ImageMagick, activez le référentiel sle-module-desktop-applications en utilisant YaST ou 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 Linux VDA 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 ci-dessous.

Installer OpenJDK 11

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

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

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

Si 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, synchronisez l’horloge du système de chaque invité Linux 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’est pas présent, les étapes suivantes ne sont pas nécessaires.

Si la fonctionnalité de synchronisation est désactivé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 :

  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 VM Linux sur lesquelles Hyper-V Integration Services est installé peuvent appliquer 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 :

1. Ouvrez la console du gestionnaire Hyper-V.
2. Pour les paramètres d’une machine virtuelle Linux, sélectionnez Integration Services.
3. 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, synchronisez l’horloge du système de chaque invité Linux avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte.

Si vous exécutez un noyau Linux paravirtualisé sur lequel VMware Tools est installé :

1. Ouvrez vSphere Client.
2. Modifiez les paramètres pour la VM Linux.
3. Dans la boîte de dialogue Virtual Machine Properties (Propriétés de la machine virtuelle), ouvrez l’onglet Options.
4. Sélectionnez VMware Tools.
5. Dans la zone Advanced (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) :

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

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

1. Lancez YaST, sélectionnez Network Services (Services réseau), puis Windows Domain Membership (Appartenance au domaine Windows).

2. Apportez les modifications suivantes :

   • Définissez le domaine (Domain) ou le groupe de travail (Workgroup) sur le nom de votre domaine Active Directory ou l’adresse IP du contrôleur de domaine. Assurez-vous que le nom du domaine est entré en majuscules.
   • Sélectionnez Use SMB information for Linux Authentication (Utiliser les informations SMB pour l’authentification Linux).
     • Sélectionnez Create Home Directory on Login (Créer un répertoire de base à la connexion).
     • Sélectionnez Single Sign-on for SSH (Authentification unique pour SSH).
     • Assurez-vous que Offline Authentification (Authentification en mode déconnecté) n’est pas sélectionné. Cette option n’est pas compatible avec le Linux VDA.

3. Cliquez sur OK. Si vous êtes invité(e) à installer des packages, cliquez sur Install.

4. Si un contrôleur de domaine est trouvé, vous êtes invité à joindre le domaine. Cliquez sur Oui.

5. Lorsque vous y êtes invité(e), saisissez les informations d’identification d’un utilisateur de domaine avec les autorisations nécessaires pour 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’appartenance à un domaine

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

Vérifiez que le fichier keytab système a été créé et qu’il contient des clés valides.

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

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms 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 échappé avec une barre oblique inverse (\) pour éviter la substitution du 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, 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 Winbind PAM est correctement configuré. Pour ce faire, connectez-vous au Linux VDA à 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 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 l’agent Linux VDA après vérification de la jonction au domaine.

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

Cette procédure suppose que vous ayez installé et configuré le logiciel Quest sur les contrôleurs domaine et que vous ayez obtenu des privilèges d’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 :

1. Dans la console de gestion Utilisateurs et ordinateurs Active Directory, ouvrez les propriétés de l’utilisateur Active Directory pour ce compte d’utilisateur.
2. Sélectionnez l’onglet Unix Account.
3. Sélectionnez Unix-enabled.
4. Définissez Primary GID Number sur l’ID d’un groupe d’utilisateurs de domaine.

Remarque :

Ces instructions sont les mêmes que pour la configuration d’utilisateurs de domaine pour l’ouverture de session à l’aide de la console, RDP, SSH ou tout autre protocole de communication à distance.

Configurer Quest sur un Linux VDA

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 les ouvertures de session d’utilisateur de domaine via HDX et d’autres services tels que su, ssh et RDP, configure 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-->

Le paramètre user est un utilisateur de domaine disposant des autorisations nécessaires pour joindre des machines 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 composant 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 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

Vérifiez que Quest peut authentifier les utilisateurs du domaine via PAM. Pour ce faire, connectez-vous au Linux VDA à 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 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-->

Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome. Passez à l’Étape 6 : installer l’agent Linux VDA après vérification de la jonction au domaine.

Centrify DirectControl

Rejoindre un domaine Windows

Une fois l’agent Centrify DirectControl installé, associez la machine Linux au domaine Active Directory en exécutant la commande Centrify adjoin :

  sudo 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 joindre des machines 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 composant 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 associée à Centrify se trouve sur le 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 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 l’agent Linux VDA après vérification de la jonction au domaine.

SSSD

Si vous utilisez SSSD sur SUSE, suivez les instructions de cette section. Cette section comprend des instructions permettant de connecter une machine Linux VDA à un domaine Windows et des indications sur la configuration de l’authentification Kerberos.

Pour configurer SSSD sur SUSE, procédez comme suit :

1. Rejoindre le domaine et créer un fichier keytab hôte
2. Configurer PAM pour SSSD
3. Configurer SSSD
4. Activer SSSD
5. Vérifier l’appartenance à un domaine
6. Vérifier la configuration de Kerberos
7. Vérifier l’authentification utilisateur

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

SSSD ne fournit pas de fonctions de client Active Directory pour rejoindre le domaine et gérer le fichier keytab système. Vous pouvez utiliser l’approche Samba à la place. Procédez comme suit avant de configurer SSSD.

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

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

2. Vérifiez le nom d’hôte et la synchronisation de l’horloge 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 racine 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 à domaine et à forêt uniques.

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

   L’élément realm est le nom du domaine Kerberos, tel que exemple.com. L’élément REALM est le nom du domaine Kerberos en majuscules, tel que EXAMPLE.COM.

5. Modifiez le fichier /etc/samba/smb.conf en tant qu’utilisateur racine 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-->
   

   L’élément 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 d’utilisateurs et de 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 utilisateur via SSSD et créez des répertoires de base pour les ouvertures de session utilisateur.

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

Configurer SSSD

1. Modifiez /etc/sssd/sssd.conf en tant qu’utilisateur racine pour permettre au démon SSSD de communiquer avec le domaine cible. 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-->
   

   L’élément domain-dns-name est le nom de domaine DNS, tel que example.com.

   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. ad_gpo_access_control est défini sur permissif pour éviter l’erreur d’ouverture de session non valide lors des sessions Linux. Pour en savoir plus, consultez les pages man pour sssd.conf et sssd-ad.

2. Définissez les autorisations et les propriétaires 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 à un domaine

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

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

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

Vérifiez que le fichier keytab système a été créé et qu’il contient des clés valides.

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

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms 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 échappé avec une barre oblique inverse (\) pour empêcher la substitution du 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-->

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 la console KDE ou Gnome. Passez à l’Étape 6 : installer l’agent Linux VDA après 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-->

Associer 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 disposant des autorisations nécessaires pour ajouter des machines 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 /opt/pbis/bin/config LoginShellTemplate/bin/bash.

Vérifier l’appartenance à un domaine

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

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

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

Étape 4 : installer .NET

Outre le 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 Linux VDA. 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 l’article de la base de connaissances 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

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 Linux VDA. Par exemple :

   

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

   

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

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

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

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 d’accès complet est nécessaire ; vous pouvez ajouter /opt/Citrix/VDA/sbin et /opt/Citrix/VDA/bin au chemin du système.

Étape 6b : installer le Linux VDA

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

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

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

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

Étape 6c : 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.

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.

  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 Linux VDA après la mise à niveau.

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

• XenServer
• VMware ESX
• Nutanix AHV

Pour installer et configurer les pilotes de VM invitée NVIDIA GRID, effectuez les opérations générales suivantes :

1. Assurez-vous que la VM invitée est arrêtée.
2. Dans le panneau de configuration de l’hyperviseur, attribuez un GPU à la VM.
3. Démarrez la VM.
4. 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, fournissez les options requises par le script d’installation avec des variables d’environnement. Si toutes les variables requises sont présentes, le script n’invite pas à entrer des informations.

Les variables d’environnement prises en charge sont les suivantes :

• CTX_XDL_NON_DOMAIN_JOINED=’y|n’ – S’il faut joindre 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’ – L’agent Linux VDA nécessite des paramètres de configuration Kerberos pour s’authentifier auprès des composants Delivery Controllers. 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>‘ – L’agent Linux VDA nécessite une liste des noms de domaine complets (FQDN), séparés par une espace, des composants Delivery Controller à utiliser pour l’enregistrement. Au moins un nom de domaine complet (FQDN) ou CNAME doit être spécifié.

• CTX_XDL_VDI_MODE=’Y|n’ — S’il faut configurer la machine en tant que modèle de mise à disposition de bureau dédié (VDI) ou modèle de mise à disposition de bureau partagé hébergé. Pour les environnements HDX 3D Pro, définissez cette valeur sur ‘y’.

• CTX_XDL_HDX_3D_PRO=’y|n’ – Le Linux VDA prend en charge HDX 3D Pro, un ensemble de technologies d’accélération graphique conçues pour optimiser la virtualisation des applications graphiques riches. 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’ – Détermine si les services Linux VDA démarrent ou non une fois la configuration terminée.

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

• CTX_XDL_ADD_FIREWALL_RULES=’Y|n’ — Les services Linux VDA nécessitent 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/mate/’<none>‘ – Spécifie l’environnement de bureau GNOME, GNOME Classic ou MATE à utiliser dans les sessions. Si vous définissez cette valeur sur ‘<none>‘, le bureau par défaut configuré sur le VDA sera 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 – Le chemin d’installation de .NET pour la prise en charge du nouveau service d’agent broker (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 VDA Linux découvre les serveurs LDAP via le 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 cette variable sur ‘<none>‘.

• CTX_XDL_LDAP_LIST=’<list-ldap-servers>‘ – Le VDA Linux interroge 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 VDA Linux recherche les serveurs LDAP en interrogeant une base de recherche définie sur 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 cette variable sur ‘<none>‘.

• CTX_XDL_SUPPORT_DDC_AS_CNAME=’y|n’ – Le VDA Linux permet de spécifier un nom de 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=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-->

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 comme 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|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 /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 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 un fichier journal de configuration :

/tmp/xdl.configure.log

Redémarrez les services de Linux VDA 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 dans un environnement Linux VDA. Pour de plus amples informations, consultez la section XDPing.

Étape 10 : exécuter le Linux VDA

Une fois que vous avez configuré Linux VDA à l’aide du script ctxsetup.sh, utilisez les commandes suivantes pour contrôler 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 premières versions de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux ». Toutefois, la sélection de l’option SE Windows Server ou SE de serveur implique un modèle de mise à disposition de bureaux partagés hébergés équivalent. 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.

Important :

La publication d’applications est prise en charge avec la version 1.4 de Linux VDA et les versions supérieures. Toutefois, le Linux VDA 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.