Installer Linux Virtual Delivery Agent pour SUSE

Vous pouvez choisir de suivre les étapes dans cet article pour l’installation manuelle ou easy install pour l’installation et la configuration automatiques. Easy Install permet des gains de temps et de main d’œuvre et il est plus fiable que l’installation manuelle.

Remarque :

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

Étape 1 : préparer l’installation

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

Vous pouvez également démarrer l’outil YaST basé sur 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

1. Ouvrez YaST Network Settings (Paramètres réseau).
2. SLED 12 uniquement : dans l’onglet Global Options, définissez Network Setup Method (Méthode de configuration réseau) sur Wicked Service (Service Wicked).
3. Ouvrez l’onglet Hostname/DNS (Nom d’hôte/DNS).
4. Désélectionnez Change hostname via DHCP(Changer le nom d’hôte via DHCP).
5. Sélectionnez Assign Hostname to Loopback IP(Attribuer le nom d’hôte à l’adresse IP de bouclage).
6. Modifiez les options suivantes pour refléter votre configuration réseau :
   • Host Name (Nom d’hôte) : ajoutez le nom d’hôte DNS de la machine.
   • Domain Name (Nom de domaine) : ajoutez le nom de domaine 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.

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

Utilisez uniquement les caractères a–z, A–Z, 0–9 et tiret (-). Évitez les caractères de soulignement (_), les espaces et autres symboles. Ne démarrez pas un nom d’hôte par un chiffre et ne le terminez pas par un tiret. Cette règle s’applique également aux noms d’hôte Delivery Controller.

Désactiver DNS multidiffusion

Sur SLED uniquement, les paramètres par défaut activent DNS multidiffusion (mDNS), ce qui peut entraîner des résultats incohérents de résolution de nom. Par défaut, mDNS n’est pas activé sur SLES, aucune action n’est donc requise.

Pour désactiver mDNS, modifiez /etc/nsswitch.conf et, dans la ligne suivante, remplacez :

hosts: files mdns_minimal [NOTFOUND=return] dns

par :

hosts: files dns

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

1. Ouvrez YaST NTP Configuration et sélectionnez l’onglet General Settings (Paramètres généraux).
2. Dans la section Start NTP Daemon (Lancer le démon NTP), sélectionnez Now and on Boot (Maintenant et au démarrage).
3. Le cas échéant, sélectionnez l’élément Undisciplined Local Clock (LOCAL) et cliquez sur Delete (Supprimer).
4. Ajoutez une entrée pour un serveur NTP en cliquant sur Add (Ajouter).
5. Sélectionnez le type de serveur Server Type, et cliquez sur Next (Suivant).
6. Entrez le nom DNS du serveur NTP dans le champ Address (Adresse). Ce service est généralement hébergé sur le contrôleur de domaine Active Directory.
7. Ne modifiez pas le champ Options.
8. Cliquez sur Test pour vérifier si le service NTP est accessible.
9. Cliquez sur OK dans la série de fenêtres pour enregistrer les modifications.

Remarque :

Pour les installations SLES 12, le démon NTP peut ne pas démarrer à cause d’un problème SUSE connu avec les stratégies AppArmor. Suivez la résolution fournie pour obtenir des informations supplémentaires.

Étape 1d : installer les packages dépendants de Linux VDA

Le logiciel Linux VDA pour SUSE Linux Enterprise fonctionne avec les packages suivants :

• PostgreSQL
  • SLED/SLES 11 : version 9.1 ou ultérieure
  • SLED/SLES 12 : version 9.3 ou ultérieure
• OpenJDK 1.7.0
• OpenMotif Runtime Environment 2.3.1 ou version ultérieure
• Cups
  • SLED/SLES 11 : version 1.3.7 ou ultérieure
  • SLED/SLES 12 : version 1.6.0 ou ultérieure
• Filtres Foomatic
  • SLED/SLES 11 : version 3.0.0 ou ultérieure
  • SLED/SLES 12 : version 1.0.0 ou ultérieure
• ImageMagick
  • SLED/SLES 11 : version 6.4.3.6 ou ultérieure
  • SLED/SLES 12 : version 6.8 ou ultérieure

Ajouter des référentiels

Certains packages requis ne sont pas disponibles dans tous les référentiels SUSE Linux Enterprise :

• SLED 11 : PostgreSQL est disponible pour SLES 11 mais pas SLED 11.
• SLES 11 : OpenJDK et OpenMotif sont disponibles pour SLED 11 mais pas SLES 11.
• SLED 12 : PostgreSQL est disponible pour SLES 12 mais pas SLED 12. ImageMagick est disponible via le fichier ISO SDK SLE 12 ou le référentiel en ligne.
• SLES 12: il n’existe aucun problème. Tous les packages sont disponibles. ImageMagick est disponible via le fichier ISO SDK SLE 12 ou le référentiel en ligne.

Pour résoudre ce problème, obtenez les packages manquants depuis le support de l’autre édition de SLE que vous installez. Autrement dit, sur SLED, installez les packages manquants depuis le support SLES et sur SLES, installez les packages manquants depuis le support SLED. L’approche suivante monte les fichiers de support ISO SLED et SLES et ajoute les référentiels.

• Sur SLED 11, exécutez les commandes :

sudo mkdir -p /mnt/sles

sudo mount -t iso9660 path-to-iso/SLES-11-SP4-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles
<!--NeedCopy-->

• Sur SLES 11, exécutez les commandes :

sudo mkdir -p /mnt/sled

sudo mount -t iso9660 path-to-iso/SLED-11-SP4-DVD-x86_64-GM-DVD1.iso /mnt/sled

sudo zypper ar -f /mnt/sled sled
<!--NeedCopy-->

• Sur SLED 12, exécutez les commandes :

sudo mkdir -p /mnt/sles

sudo mount -t iso9660 path-to-iso/SLES-12-SP2-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles
<!--NeedCopy-->

• Sur SLED/SLES 12, exécutez les commandes :

sudo mkdir -p /mnt/sdk

sudo mount -t iso9660 path-to-iso/SLE-12-SP3-SDK-DVD-x86_64-GM-DVD1.iso /mnt/sdk

sudo zypper ar -f /mnt/sdk sdk
<!--NeedCopy-->

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

Le Linux VDA est dépendant de OpenJDK 1.7.0.

Conseil :

Pour éviter les problèmes, assurez-vous que vous avez uniquement installé OpenJDK version 1.7.0. Supprimez toutes les autres versions de Java de votre système.

• SLED :

1. Sur SLED, Java Runtime Environment est généralement installé avec le système d’exploitation. Vérifiez que celui-ci a été installé :

   sudo zypper info java-1_7_0-openjdk
   <!--NeedCopy-->
   

2. Mettez-le à jour vers la version la plus récente si l’état est signalé comme obsolète :

   sudo zypper update java-1_7_0-openjdk
   <!--NeedCopy-->
   

3. Vérifiez la version Java :

   java -version
   <!--NeedCopy-->
   

• SLES :

1. Sur SLES, installez Java Runtime Environment :

   sudo zypper install java-1_7_0-openjdk
   <!--NeedCopy-->
   

2. Vérifiez la version Java :

   java -version
   <!--NeedCopy-->
   

Installer PostgreSQL

• Sur SLED/SLES 11, installez les packages :

   sudo zypper install libecpg6
  
   sudo zypper install postgresql-init
  
   sudo zypper install postgresql
  
   sudo zypper install postgresql-server
  
   sudo zypper install postgresql-jdbc
   <!--NeedCopy-->
  

  Les étapes de post-installation sont requises pour initialiser le service de base de données et s’assurer que PostgreSQL est lancé au démarrage de la machine.

   sudo /sbin/insserv postgresql
  
   sudo /etc/init.d/postgresql restart
   <!--NeedCopy-->
  

• Sur SLED/SLES 12, installez les packages :

   sudo zypper install postgresql-init
  
   sudo zypper install postgresql-server
  
   sudo zypper install postgresql-jdbc
   <!--NeedCopy-->
  

  Les étapes de post-installation sont requises pour initialiser le service de base de données et s’assurer que PostgreSQL est lancé au démarrage de la machine.

   sudo systemctl enable postgresql
  
   sudo systemctl restart postgresql
   <!--NeedCopy-->
  

  Les fichiers de base de données se trouvent dans /var/lib/pgsql/data.

Supprimer les référentiels

Une fois les packages dépendants installés, les référentiels de l’autre édition configurés auparavant peuvent être supprimés et le support démonté :

• Sur SLED 11, exécutez les commandes pour supprimer les packages :

   sudo zypper rr sles
  
   sudo umount /mnt/sles
  
   sudo rmdir /mnt/sles
   <!--NeedCopy-->
  

• Sur SLES 11, exécutez les commandes pour supprimer les packages :

   sudo zypper rr sled
  
   sudo umount /mnt/sled
  
   sudo rmdir /mnt/sled
   <!--NeedCopy-->
  

• sur SLED 12, exécutez les commandes pour supprimer les packages :

   sudo zypper rr sles
  
   sudo umount /mnt/sles
  
   sudo rmdir /mnt/sles
   <!--NeedCopy-->
  

• Sur SLED/SLES 12, exécutez les commandes pour supprimer les packages :

   sudo zypper rr sdk
  
   sudo umount /mnt/sdk
  
   sudo rmdir /mnt/sd
   <!--NeedCopy-->
  

Étape 2 : préparer une VM Linux pour l’hyperviseur

Certaines modifications sont requises pour l’exécution du Linux VDA en tant que machine virtuelle sur un hyperviseur pris en charge. Apportez les modifications suivantes en fonction de la plateforme d’hyperviseur utilisée. Aucune modification n’est requise si vous utilisez la machine Linux sur un matériel bare metal.

Corriger la synchronisation de l’heure sur Citrix XenServer

Si la fonctionnalité de synchronisation de l’heure de XenServer est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car XenServer et NTP tenteront de gérer l’horloge du système. Pour éviter que l’horloge ne soit plus synchronisée avec d’autres serveurs, l’horloge du système de chaque invité Linux doit être synchronisée avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte. Aucune modification n’est requise en mode HVM.

Sur certaines distributions Linux, si vous utilisez un noyau Linux paravirtualisé avec le composant XenServer Tools installé, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure de XenServer est présente et activée à partir de la VM Linux :

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/indepent_wallclock n’existe pas, les étapes suivantes ne sont pas nécessaires.

Si la fonctionnalité de synchronisation est activée, désactivez-la en entrant 1 dans le fichier :

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

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

xen.independent_wallclock = 1

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

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 XenServer et VMware, pour lesquels la synchronisation de l’heure est désactivée pour éviter tout conflit avec NTP. La synchronisation de l’heure Hyper-V peut co-exister avec la synchronisation de l’heure NTP.

Corriger la synchronisation de l’heure sur ESX et ESXi

Si la fonctionnalité de synchronisation de l’heure de VMware est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car l’hyperviseur et NTP tenteront de gérer l’horloge du système. Pour éviter que l’horloge ne soit plus synchronisée avec d’autres serveurs, l’horloge du système de chaque invité Linux doit être synchronisée avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte.

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

1. Ouvrez vSphere Client.
2. Modifiez les paramètres pour la VM Linux.
3. Dans la boîte de dialogue Virtual Machine Properties (Propriétés de la machine virtuelle), ouvrez l’onglet Options.
4. Sélectionnez VMware Tools.
5. Dans la zone Advanced (Avancé), désélectionnez Synchronize guest time with host (Synchroniser l’heure de l’invité avec l’hôte).

Étape 3 : ajouter la machine virtuelle (VM) Linux au domaine Windows

Le Linux VDA prend en charge plusieurs méthodes pour ajouter des machines Linux au domaine Active Directory (AD) :

• Samba Winbind
• Quest Authentication Service
• Centrify DirectControl

Suivez les instructions en fonction de la méthode choisie.

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. Ouvrez YaST Windows Domain Membership.

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 Also Use SMB information for Linux Authentication (Utiliser aussi 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 ordinateurs au domaine, et cliquez sur OK.

6. Un message indiquant si le processus a réussi s’affiche.

7. Si vous êtes invité(e) à installer des packages samba et krb5, cliquez sur Install.

YaST peut avoir indiqué que ces modifications nécessitent le redémarrage de certains services ou de la machine. Nous vous recommandons de redémarrer la machine :

su -

reboot
<!--NeedCopy-->

SLED/SLES 12 uniquement : correctif du nom du fichier cache d’identification Kerberos

SLED/SLES 12 a remplacé la configuration du nom du fichier cache d’identification Kerberos habituelle FILE:/tmp/krb5cc_%{uid} par DIR:/run/user/%{uid}/krb5cc. Cette nouvelle méthode de mise en cache DIR n’est pas compatible avec le Linux VDA et doit être modifiée manuellement. En tant qu’utilisateur racine, modifiez /etc/krb5.conf en ajoutant le paramètre suivant dans la section [libdefaults] s’il n’est pas défini :

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

Vérifier l’appartenance à un domaine

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

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

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

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

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

Vérifier la configuration de Kerberos

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

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

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

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

Les noms de machine et de domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être placé dans une séquence d’échappement avec une barre oblique inverse (\) pour empêcher le remplacement shell. Dans certains environnements, le nom de domaine DNS est différent du nom de domaine Kerberos. Assurez-vous que le nom de domaine est utilisé. Si cette commande réussit, aucun résultat n’est affiché.

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

sudo klist
<!--NeedCopy-->

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

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

Vérifier l’authentification utilisateur

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

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

Le domaine spécifié ici est le nom de domaine Active Directory, et non le nom de domaine Kerberos. Pour le shell bash, la barre oblique inverse (\) doit être placée dans une séquence d’échappement avec une autre barre oblique inverse. Cette commande renvoie un message indiquant la réussite ou l’échec.

Pour vérifier que le module PAM Winbind est correctement configuré, ouvrez une session à l’aide d’un compte d’utilisateur de domaine sur le VDA Linux. Le compte d’utilisateur de domaine n’a pas é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 de l’utilisateur sont valides et n’ont pas expiré :

klist
<!--NeedCopy-->

Quitter 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 4 : installer le Linux VDA après vérification de la jonction du domaine.

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

Cette procédure suppose que vous avez installé et configuré le logiciel Quest sur les contrôleurs de domaine Active Directory et disposez des droits Administrateur pour créer des objets ordinateur dans Active Directory.

Autoriser les utilisateurs de domaine à ouvrir une session sur des machines Linux VDA

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

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 l’ouverture de session d’utilisateur de domaine via HDX et d’autres services tels que su, ssh et RDP, exécutez les commandes suivantes pour configurer manuellement PAM et NSS :

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->

Rejoindre un domaine Windows

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 un utilisateur de domaine disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom DNS du domaine ; par exemple, exemple.com.

Vérifier l’appartenance à un domaine

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

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

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

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

Vérifier l’authentification utilisateur

Pour vérifier que Quest peut authentifier les utilisateurs de domaine via PAM, utilisez un compte d’utilisateur de domaine pour vous connecter au VDA Linux. Le compte d’utilisateur de domaine n’a pas é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 4 : installer le Linux VDA après vérification de la jonction du domaine.

Centrify DirectControl

Rejoindre un domaine Windows

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

su –

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

Le paramètre user est un utilisateur de domaine Active Directory disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom du domaine auquel associer la machine Linux.

Vérifier l’appartenance à un domaine

Le Delivery Controller requiert que toutes les machines VDA (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 :

su –

adinfo
<!--NeedCopy-->

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

Des informations plus complètes sur le système et les diagnostics sont disponibles à l’aide de :

adinfo --sysinfo all

adinfo –diag
<!--NeedCopy-->

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

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

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

Étape 4 : installer le Linux VDA

Étape 4a : 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 /sbin/service ctxvda stop
   
   sudo /sbin/service ctxhdx stop
   <!--NeedCopy-->
   

2. Désinstallez le package :

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

Important :

La mise à niveau à partir des deux versions précédentes est prise en charge.

Remarque :

Les composants d’installation se trouvent dans /opt/Citrix/VDA/.

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

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

Accédez au site Web Citrix et téléchargez le package Linux VDA en fonction de la distribution Linux appropriée.

Étape 4c : installer le Linux VDA

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

Pour SUSE 12 :

sudo zypper install XenDesktopVDA-7.15.0.404-1.sle12_2.x86_64.rpm
<!--NeedCopy-->

Pour SUSE 11 :

sudo zypper install XenDesktopVDA-7.15.0.404-1.sle11_4.x86_64.rpm
<!--NeedCopy-->

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

Pour SUSE 12 :

sudo rpm -i XenDesktopVDA-7.15.0.404-1.sle12_2.x86_64.rpm
<!--NeedCopy-->

Pour SUSE 11 :

sudo rpm -i XenDesktopVDA-7.15.0.404-1.sle11_4.x86_64.rpm
<!--NeedCopy-->

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

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

Pour SUSE 12 :

sudo rpm -U XenDesktopVDA-7.15.0.404-1.sle12_2.x86_64.rpm
<!--NeedCopy-->

Pour SUSE 11 :

sudo rpm -U XenDesktopVDA-7.15.0.404-1.sle11_4.x86_64.rpm
<!--NeedCopy-->

Liste des dépendances RPM pour SUSE 12 :

postgresql-server >= 9.3

postgresql-jdbc >= 9.2

java-1.7.0-openjdk >= 1.7.0

ImageMagick >= 6.8

dbus-1 >= 1.8.8

dbus-1-x11 >= 1.8.8

libXpm4 >= 3.5.11

libXrandr2 >= 1.4.2

libXtst6 >= 1.2.2

motif >= 2.3

pam >= 1.1.8

bash >= 4.2

findutils >= 4.5

gawk >= 4.1

sed >= 4.2

cups >= 1.6.0

cups-filters-foomatic-rip >= 1.0.0

openldap2 >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

python-requests >= 2.8.1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsLzma) <= 4.4.6-1
<!--NeedCopy-->

Liste des dépendances RPM pour SUSE 11 :

postgresql-server >= 9.1.

postgresql-jdbc >= 9.1

java-1_7_0-openjdk >= 1.7.0.6

ImageMagick >= 6.4.3.6

ConsoleKit >= 0.2.10

dbus-1 >= 1.2.10

dbus-1-x11 >= 1.2.10

xorg-x11-libXpm >= 7.4

xorg-x11-libs >= 7.4

openmotif-libs >= 2.3.1

pam >= 1.1.5

libdrm >= 2.4.41

libpixman-1-0 >= 0.24.4

Mesa >= 9.0

openssl >= 0.9.8j

xorg-x11 >= 7.4

xorg-x11-fonts-core >= 7.4

xorg-x11-libXau >= 7.4

xorg-x11-libXdmcp >= 7.4

bash >= 3.2

findutils >= 4.4

gawk >= 3.1

sed >= 4.1

cups >= 1.3.7

foomatic-filters >= 3.0.0

openldap2 >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.7

python-requests >= 2.0.1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsLzma) <= 4.4.6-1
<!--NeedCopy-->

Important :

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

Étape 5 : configurer le Linux VDA

Après l’installation du package, vous devez configurer le Linux VDA 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_SUPPORT_DDC_AS_CNAME = Y | N : le Linux VDA prend en charge la spécification d’un nom de Delivery Controller à l’aide d’un enregistrement DNS CNAME. La valeur est définie par défaut sur N.
• CTX_XDL_DDC_LIST = list-ddc-fqdns : le Linux VDA requiert une liste séparée par des espaces de noms de domaines complets de Delivery Controller. Cette dernière sera utilisée pour l’enregistrement auprès d’un Delivery Controller. Au moins un alias de nom de domaine complet (FQDN) ou CNAME doit être spécifié.
• CTX_XDL_VDA_PORT = port-number : le Linux VDA communique avec les Delivery Controller à l’aide d’un port (80 par défaut) TCP/IP.
• CTX_XDL_REGISTER_SERVICE = Y | N : les services Linux Virtual Desktop sont lancés après le démarrage de la machine. La valeur est définie sur Y par défaut.
• CTX_XDL_ADD_FIREWALL_RULES=Y | N : les services Linux Virtual Desktop requièrent que les connexions réseau entrantes soient autorisées via le pare-feu du système. Vous pouvez ouvrir automatiquement les ports requis (ports 80 et 1494 par défaut) dans le pare-feu du système pour Linux Virtual Desktop. Valeur définie sur Y par défaut.
• CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 le Linux VDA requiert que les paramètres de configuration Kerberos s’authentifient auprès des Delivery Controller. La configuration de Kerberos est déterminée depuis l’outil d’intégration d’Active Directory installé et configuré sur le système. Spécifiez la méthode d’intégration d’Active Directory prise en charge à utiliser :
  • 1 – Samba Winbind
  • 2 – Service d’authentification Quest
  • 3 – Centrify DirectControl
  • 4 – SSSD
• CTX_XDL_HDX_3D_PRO= Y | N : Linux VDA prend en charge HDX 3D Pro, un ensemble de technologies d’accélération GPU conçues pour optimiser la virtualisation des applications riches en graphiques. Si HDX 3D Pro est sélectionné, le Virtual Delivery Agent est configuré pour le mode Bureaux VDI (session unique) – (c’est-à-dire, CTX_XDL_VDI_MODE=Y).
• CTX_XDL_VDI_MODE=Y | N : indique si la machine est configurée comme modèle de mise à disposition de bureaux dédiés (VDI) ou comme modèle de mise à disposition de bureaux partagés hébergés. Pour les environnements HDX 3D Pro, définissez cette variable sur Y. Elle est définie par défaut sur N.
• CTX_XDL_SITE_NAME=dns-name : le Linux VDA découvre les serveurs LDAP à l’aide de DNS. Pour limiter les résultats de recherche DNS à un site local, spécifiez un nom de site DNS. Cette variable est définie sur <none> par défaut.
• CTX_XDL_LDAP_LIST = list-ldap-servers : le Linux VDA envoie une requête vers le DNS pour découvrir les serveurs LDAP. Si DNS ne peut pas fournir d’enregistrements de service LDAP, vous pouvez entrer une liste séparée par des espaces de noms de domaines complets LDAP avec port LDAP. Par exemple, ad1.mycompany.com:389. Cette variable est définie sur <none> par défaut.
• CTX_XDL_SEARCH_BASE=search-base-set : le Linux VDA envoie une requête à LDAP via 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). Cette variable est définie sur <none> par défaut.
• CTX_XDL_START_SERVICE = Y | N : indique si les services Linux VDA sont lancés lorsque la configuration de Linux VDA est terminée. Valeur définie sur Y par défaut.

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

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST=list-ddc-fqdns

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-name

export CTX_XDL_LDAP_LIST=list-ldap-servers

export CTX_XDL_SEARCH_BASE=search-base-set

export CTX_XDL_START_SERVICE=Y|N

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

Lors de l’exécution de la commande sudo, entrez l’option -E pour transmettre les variables d’environnement au nouveau shell créé. Citrix vous recommande de créer un fichier de script shell à partir des commandes précédentes avec #!/bin/bash en tant que première ligne.

Vous pouvez également spécifier tous les paramètres avec une seule commande :

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST=list-ddc-fqdns \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST=list-ldap-servers \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh
<!--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 6 : 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 /sbin/service ctxhdx start

sudo /sbin/service ctxvda start
<!--NeedCopy-->

Arrêter Linux VDA :

Pour arrêter les services Linux VDA :

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop
<!--NeedCopy-->

Redémarrer Linux VDA :

Pour redémarrer les services Linux VDA :

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

sudo /sbin/service ctxvda start
<!--NeedCopy-->

Vérifier l’état de Linux VDA :

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

sudo /sbin/service ctxvda status

sudo /sbin/service ctxhdx status
<!--NeedCopy-->

Étape 7 : créer le catalogue de machines dans XenApp ou XenDesktop

Le processus de création de catalogues de machines et d’ajout de machines 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’OS de serveur pour un modèle de mise à disposition de bureaux partagés hébergés
  • L’OS de bureau pour un modèle de mise à disposition de bureaux dédiés VDI
• Assurez-vous que les machines sont définies avec une alimentation non gérée.
• MCS n’étant pas pris en charge pour les VDA Linux, choisissez la méthode de déploiement PVS ou Autre service ou technologie (images existantes).
• Ne combinez pas de machines Linux VDA et Windows dans le même catalogue de machines.

Remarque :

Les versions antérieures de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux. » Toutefois, la sélection de l’option OS de serveur Windows ou OS de serveur implique un modèle de mise à disposition équivalent de bureaux partagés hébergés. La sélection de l’option OS de bureau Windows ou OS de bureau implique un modèle de mise à disposition d’un utilisateur unique par machine.

Conseil :

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

Étape 8 : créer le groupe de mise à disposition dans XenApp ou XenDesktop

Le processus de création d’un groupe de mise à disposition et d’ajout de catalogues de machines contenant des machines 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 :

• Pour le type de mise à disposition, sélectionnez Bureaux ou Applications.
• Assurez-vous que les utilisateurs et les groupes AD que vous sélectionnez ont été correctement configurés pour l’ouverture de session sur les machines 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.