Installation de l’agent de livraison virtuel Linux pour SUSE

Vous pouvez choisir de suivre les étapes de cet article pour une installation manuelle ou d’utiliser l’installation facile pour une installation et une configuration automatiques. L’installation facile permet de gagner du temps et de réduire les efforts, et est moins sujette aux erreurs que l’installation manuelle.

Remarque :

Utilisez l’installation facile uniquement pour les nouvelles installations. N’utilisez pas l’installation facile pour mettre à jour une installation existante.

Étape 1 : Préparer l’installation

É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 basé sur du texte :

su -

yast
<!--NeedCopy-->

Vous pouvez également 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 basé sur du 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 DNS

1. Ouvrez les paramètres réseau de YaST.
2. SLED 12 uniquement : Dans l’onglet Options globales, modifiez la Méthode de configuration réseau en Service Wicked.
3. Ouvrez l’onglet Nom d’hôte/DNS.
4. Désactivez Modifier le nom d’hôte via DHCP.
5. Cochez Attribuer le nom d’hôte à l’adresse IP de bouclage.
6. Modifiez les éléments suivants pour refléter votre configuration réseau :
   • Nom d’hôte – Ajoutez le nom d’hôte DNS de la machine.
   • Nom de domaine – Ajoutez le nom de domaine 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.

Remarque :

Le VDA Linux ne prend actuellement pas en charge la troncature 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 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.

Désactiver le DNS multidiffusion

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

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

hosts: files mdns_minimal [NOTFOUND=return] dns

En :

hosts: files dns

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 peut entraîner des problèmes de décalage d’horloge. 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 :

1. Ouvrez la configuration NTP de YaST et sélectionnez l’onglet Paramètres généraux.
2. Dans la section Démarrer le démon NTP, cochez Maintenant et au démarrage.

• 1. Si présent, sélectionnez l’élément Horloge locale non disciplinée (LOCAL) et cliquez sur Supprimer.

1. Ajoutez une entrée pour un serveur NTP en cliquant sur Ajouter.
2. Sélectionnez le Type de serveur et cliquez sur Suivant.
3. Saisissez le nom DNS du serveur NTP dans le champ Adresse. Ce service est normalement hébergé sur le contrôleur de domaine Active Directory.
4. Laissez le champ Options inchangé.
5. Cliquez sur Tester pour vérifier que le service NTP est accessible.
   • 1. Cliquez sur OK dans toutes les fenêtres pour enregistrer les modifications.

Remarque :

Pour les implémentations SLES 12, le démon NTP peut ne pas démarrer en raison d’un problème SUSE connu avec les politiques AppArmor. Suivez la résolution pour plus d’informations.

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

Le logiciel VDA Linux pour SUSE Linux Enterprise dépend des 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
• Environnement d’exécution OpenMotif 2.3.1 ou ultérieur
• 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 dépôts

Certains packages requis ne sont pas disponibles dans tous les dépôts SUSE Linux Enterprise :

• SLED 11 : PostgreSQL est disponible pour SLES 11 mais pas pour SLED 11.
• SLES 11 : OpenJDK et OpenMotif sont disponibles pour SLED 11 mais pas pour SLES 11.
• SLED 12 : PostgreSQL est disponible pour SLES 12 mais pas pour SLED 12. ImageMagick est disponible via l’ISO du SDK SLE 12 ou le dépôt en ligne.
• SLES 12 : Il n’y a aucun problème. Tous les packages sont disponibles. ImageMagick est disponible via l’ISO du SDK SLE 12 ou le dépôt en ligne.

Pour résoudre le problème, obtenez les packages manquants à partir du support de l’édition alternative de SLE à partir de laquelle vous effectuez l’installation. Autrement dit, sur SLED, installez les packages manquants à partir du support SLES, et sur SLES, installez les packages manquants à partir du support SLED. L’approche suivante monte les fichiers ISO des supports SLED et SLES et ajoute des dépôts.

• 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 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 Active Directory utilisée. Voir la description suivante.

Installer OpenJDK

Le VDA Linux dépend d’OpenJDK 1.7.0.

Conseil : - > Pour éviter les problèmes, assurez-vous d’avoir installé uniquement OpenJDK version 1.7.0. Supprimez toutes les autres versions de Java de votre système.

-  **SLED :**

1. Sur SLED, l’environnement d’exécution Java est généralement installé avec le système d’exploitation. Vérifiez s’il a été installé :

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

2. Mettez à jour vers la dernière version si l’état est signalé comme obsolète :

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

• 1. Vérifiez la version de Java :

   java -version
   <!--NeedCopy-->
  

• SLES :

1. Sur SLES, installez l’environnement d’exécution Java :

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

2. Vérifiez la version de 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-->
  

  Des étapes post-installation sont nécessaires pour initialiser le service de base de données et pour s’assurer que PostgreSQL est démarré 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-->
  

  Des étapes post-installation sont nécessaires pour initialiser le service de base de données et pour s’assurer que PostgreSQL est démarré au démarrage de la machine :

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

  Les fichiers de base de données se trouvent à l’emplacement /var/lib/pgsql/data.

Supprimer les dépôts

Une fois les packages dépendants installés, les dépôts d’édition alternatifs configurés précédemment peuvent maintenant être supprimés et le média 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 la machine virtuelle Linux pour 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. Effectuez 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 horaire sur Citrix XenServer®

Si la fonction de synchronisation horaire de XenServer est activée, vous rencontrerez des problèmes au sein de chaque machine virtuelle Linux paravirtualisée, NTP et XenServer essayant tous deux de gérer l’horloge système. Pour éviter que l’horloge ne se désynchronise avec d’autres serveurs, l’horloge système de chaque invité Linux doit être synchronisée avec NTP. Ce cas nécessite la désactivation de la synchronisation horaire de l’hôte. Aucune modification n’est requise en mode HVM.

Sur certaines distributions Linux, si vous exécutez un noyau Linux paravirtualisé avec les outils XenServer installés, vous pouvez vérifier si la fonction de synchronisation horaire de 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 fonction de synchronisation horaire est activée et doit être désactivée.
• 1 - La fonction de synchronisation horaire est désactivée et aucune autre action n’est requise.

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

Si elle est activée, désactivez la fonction de synchronisation horaire 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 horaire sur Microsoft Hyper-V

Les machines virtuelles Linux avec les services d’intégration Linux Hyper-V installés peuvent appliquer la fonction de synchronisation horaire 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 fonction 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 horaire est sélectionné.

Remarque :

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

Corriger la synchronisation horaire sur ESX et ESXi

Si la fonction de synchronisation horaire VMware est activée, vous rencontrerez des problèmes au sein de chaque machine virtuelle Linux paravirtualisée, NTP et l’hyperviseur essayant tous deux de synchroniser l’horloge système. Pour éviter que l’horloge ne se désynchronise avec d’autres serveurs, l’horloge système de chaque invité Linux doit être synchronisée avec NTP. Ce cas nécessite la désactivation de la synchronisation horaire de l’hôte.

Si vous exécutez un noyau Linux paravirtualisé avec les outils VMware 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écochez Synchroniser l’heure de l’invité avec l’hôte.

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

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

• Samba Winbind
• Quest Authentication Service
• Centrify DirectControl

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

Samba Winbind

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 :

1. Ouvrez YaST Windows Domain Membership.

2. Apportez les modifications suivantes :

   • Définissez le champ Domain or Workgroup 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 Also Use SMB information for Linux Authentication.
   • Cochez Create Home Directory on Login.
   • Cochez Single Sign-on for SSH.
   • Assurez-vous que l’option Offline Authentication 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 Install.

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

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

6. Un message indiquant la réussite s’affiche.

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

YaST a peut-être 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 : Corriger le nom du cache d’informations d’identification Kerberos

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

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

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.

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

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

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

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

Vérifier la configuration Kerberos

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

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

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms 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 la machine a été mis en cache à l’aide de :

sudo klist
<!--NeedCopy-->

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

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

Vérifier l’authentification de l’utilisateur

Utilisez l’outil wbinfo pour vérifier que les utilisateurs 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 AD, et non le nom de royaume Kerberos. Pour le shell bash, le caractère barre oblique inverse (\) doit être échappé avec une autre barre oblique inverse. Cette commande renvoie un message indiquant la réussite ou l’échec.

Pour vérifier que le module Winbind PAM est configuré correctement, utilisez un compte utilisateur de domaine pour vous connecter au VDA Linux. Le compte utilisateur de domaine n’a pas é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 se connectant directement à la console Gnome ou KDE. Passez à l’Étape 4 : Installer le VDA Linux après la vérification de la jonction au domaine.

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

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

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

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

1. Dans la console de gestion Utilisateurs et ordinateurs Active Directory, ouvrez les propriétés de l’utilisateur Active Directory pour ce compte utilisateur.
2. Sélectionnez l’onglet Unix Account.
3. Cochez Unix-enabled.
4. Définissez le Primary GID Number 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 la connexion des utilisateurs de domaine via HDX et d’autres services tels que su, ssh et RDP, exécutez les commandes suivantes pour configurer manuellement PAM et NSS :

sudo /opt/quest/bin/vastool configure pam

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

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

Vérifier l’appartenance au domaine

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

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

Si la machine est jointe à un domaine, cette commande renvoie le nom 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

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

su –

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

L’utilisateur est tout utilisateur de domaine Active Directory disposant des autorisations nécessaires pour joindre des ordinateurs 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 est sur le domaine :

-  su –

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

Étape 4 : Installer le VDA Linux

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

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

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

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

Étape 4c : Installer le VDA Linux

Installez le logiciel VDA Linux à 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 VDA Linux à l’aide du gestionnaire de packages RPM. Avant de le faire, résolvez 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 VDA Linux (facultatif)

Vous pouvez mettre à niveau le logiciel VDA Linux à partir des versions 7.14 et 7.13 à l’aide du gestionnaire de packages 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 réexécuter le script à tout moment pour modifier les paramètres.

Vous pouvez exécuter le script manuellement avec des invites, ou automatiquement avec des réponses préconfigurées. Consultez l’aide concernant le script avant de continuer :

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

Configuration guidée

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

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

Configuration automatisée

Pour une installation automatisée, fournissez les options requises par le script d’installation à l’aide de 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_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. Défini sur N par défaut.
• CTX_XDL_DDC_LIST = list-ddc-fqdns – Le Linux VDA requiert une liste de noms de domaine complets (FQDN) de Delivery Controller séparés par des espaces à utiliser pour l’enregistrement auprès d’un Delivery Controller. Au moins un FQDN ou un alias CNAME doit être spécifié.
• CTX_XDL_VDA_PORT = port-number – Le Linux VDA communique avec les Delivery Controllers via un port TCP/IP, qui est le port 80 par défaut.
• CTX_XDL_REGISTER_SERVICE = Y | N - Les services Linux Virtual Desktop sont démarrés après le démarrage de la machine. La valeur est définie sur Y par défaut.
• CTX_XDL_ADD_FIREWALL_RULES = Y | N – Les services Linux Virtual Desktop nécessitent que les connexions réseau entrantes soient autorisées via le pare-feu système. Vous pouvez ouvrir automatiquement les ports requis (ports 80 et 1494 par défaut) dans le pare-feu système pour le Linux Virtual Desktop. Défini sur Y par défaut.
• CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 – Le Linux VDA requiert des paramètres de configuration Kerberos pour s’authentifier auprès des Delivery Controllers. La configuration Kerberos est déterminée à partir de l’outil d’intégration Active Directory installé et configuré sur le système. Spécifiez la méthode d’intégration Active Directory prise en charge à utiliser :
  • 1 – Samba Winbind
  • 2 – Quest Authentication Service
  • 3 – Centrify DirectControl
  • 4 – SSSD
• CTX_XDL_HDX_3D_PRO= Y | N – Le 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 graphiques riches. Si HDX 3D Pro est sélectionné, le Virtual Delivery Agent est configuré pour le mode de bureaux VDI (session unique) – (c’est-à-dire, CTX_XDL_VDI_MODE=Y).
• 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 cette variable sur Y. Cette variable est définie sur N par défaut.
• CTX_XDL_SITE_NAME = dns-name – Le Linux VDA 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. Cette variable est définie sur <none> par défaut.
• CTX_XDL_LDAP_LIST = list-ldap-servers – Le Linux VDA 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 le 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 interroge 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 démarrés une fois la configuration du Linux VDA terminée. Défini 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-->

Lorsque vous exécutez la commande sudo, saisissez l’option -E pour transmettre les variables d’environnement existantes au nouveau shell qu’elle crée. Citrix vous recommande 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_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, vous devrez peut-être supprimer les modifications de configuration apportées par le script ctxsetup.sh sans désinstaller le package Linux VDA.

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 Linux VDA 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 Linux VDA pour que les modifications prennent effet.

Étape 6 : Exécuter le Linux VDA

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

Démarrer le Linux VDA :

Pour démarrer les services Linux VDA :

sudo /sbin/service ctxhdx start

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

Arrêter le Linux VDA :

Pour arrêter les services Linux VDA :

sudo /sbin/service ctxvda stop

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

Redémarrer le 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 du Linux VDA :

Pour vérifier l’état d’exécution des services 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 de Windows VDA. Pour une description plus détaillée de la façon d’effectuer ces tâches, consultez Créer des catalogues de machines et Gérer les catalogues de machines.

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

• Pour le système d’exploitation, sélectionnez :
  • L’option Système d’exploitation serveur pour un modèle de livraison de bureaux partagés hébergés.
  • L’option Système d’exploitation de bureau pour un modèle de livraison de bureau dédié VDI.
• Assurez-vous que les machines ne sont pas gérées par l’alimentation.
• Étant donné que MCS n’est pas pris en charge pour les Linux VDA, choisissez PVS ou la méthode de déploiement Autre service ou technologie (images existantes).
• Ne mélangez pas les machines Linux et Windows VDA dans le même catalogue de machines.

Remarque :

Les premières versions de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux ». Cependant, la sélection de l’option Système d’exploitation Windows Server ou Système d’exploitation serveur implique un modèle de livraison de bureaux partagés hébergés équivalent. La sélection de l’option Système d’exploitation de bureau Windows ou Système d’exploitation de bureau implique un modèle de livraison 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 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 à celui des machines Windows VDA. Pour une description plus détaillée de la façon d’effectuer ces tâches, consultez Créer des groupes de mise à disposition.

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

• Pour le type de mise à disposition, sélectionnez Bureaux ou Applications.

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

Important :

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