Product Documentation

Installieren von VDAs mit SUSE Linux

Jul 08, 2016

Sie können virtuelle Linux-Desktops auf der Basis einer SUSE-Distribution erstellen. Bereiten Sie die Linux-VMs vor, installieren Sie die neue Linux-VDA-Software darauf, konfigurieren Sie den Delivery Controller und stellen Sie die Desktops den Benutzern mit Studio zur Verfügung.

Weitere Informationen finden Sie in diesem Artikel.

Hinweis

Die in diesem Artikel beschriebenen Linux-Shellbefehle wurden für die GNU Bash-Shell verifiziert.

Systemanforderungen

Linux-Distributionen

Die folgenden Linux-Distributionen werden vom Linux Virtual Desktop unterstützt:

  • SUSE Linux Enterprise:
    • Desktop 11 Service Pack 4
    • Desktop 12 Service Pack 1
    • Server 11 Service Pack 4
    • Server 12 Service Pack 1
  • Red Hat Enterprise Linux
    • Workstation 6.7
    • Workstation 7.2
    • Server 6.7
    • Server 7.2
  • CentOS Linux
    • CentOS 6.7
    • CentOS 7.2

Hinweis

In allen Fällen wird die Prozessorarchitektur x86-64 unterstützt.

XenDesktop

Die folgenden Versionen von XenDesktop werden vom Linux VDA unterstützt:

  • XenDesktop 7.1
  • XenDesktop 7.5
  • XenDesktop 7.6
  • XenDesktop 7.7
  • XenDesktop 7.8
  • XenDesktop 7.9

Die Konfiguration von Linux VDAs ist etwas anders als die von Windows VDAs. Alle Delivery Controller-Farmen können jedoch Windows- und Linux-Desktops vermitteln.

Hinweis

Der Linux VDA ist nicht mit XenDesktop 7.0 oder früheren Versionen kompatibel.

Citrix Receiver

Die folgenden Versionen von Citrix Receiver werden unterstützt:

  • Citrix Receiver für Windows Version 4.4 oder höher (dies entspricht v14.4 von wfica32.exe)
  • Citrix Receiver für Linux Version 13.3 oder höher
  • Citrix Receiver für Mac OSX Version 12.1 oder höher
  • Citrix Receiver für Android Version 3.8 oder höher
  • Citrix Receiver für iOS Version 6.1.4 oder höher
  • Citrix Receiver für Chrome/HTML5 Version 2.0 (nur über Access Gateway)

Hypervisors

Die folgenden Hypervisors werden zum Hosten von Linux VDA Gast-VMs unterstützt:

  • XenServer
  • VMware ESX und ESXi
  • Microsoft Hyper-V

Bare-Metal-Hosting wird ebenfalls unterstützt.

Tipp

Eine Liste der unterstützten Plattformen finden Sie in der Dokumentation des Herstellers Ihres Hypervisors.

Active Directory-Integrationspakete

Die folgenden Active Directory-Integrationspakete oder -produkte werden vom Linux VDA unterstützt:

  • Samba Winbind
  • Quest Authentication Services v4.1 oder höher
  • Centrify DirectControl

Tipp

Eine Liste der unterstützten Plattformen finden Sie in der Dokumentation des Herstellers Ihres Active Directory-Integrationspakets.

Konfigurieren von Delivery Controllern

XenDesktop 7.7 oder höher enthält die erforderlichen Änderungen für Linux Virtual Desktop und für frühere Versionen ist ein Hotfix oder Updateskript erforderlich. Anleitungen zur Installation und Überprüfung finden Sie in diesem Abschnitt.

Aktualisieren der Delivery Controller-Konfiguration

Wenden Sie bei XenDesktop 7.6 SP2 das Hotfix Update 2 an, um den Broker für Linux Virtual Desktops zu aktualisieren. Hotfix Update 2 ist hier verfügbar:

  • CTX142438: Hotfix Update 2 - für Delivery Controller 7.6 (32 Bit) – Englisch
  • CTX142439: Hotfix Update 2 - für Delivery Controller 7.6 (64 Bit) – Englisch

Für frühere XenDesktop-Versionen ist das PowerShell-Skript Update-BrokerServiceConfig.ps1 verfügbar, mit dem die Konfiguration des Brokerdiensts aktualisiert wird. Es ist im folgenden Paket verfügbar:

  • citrix-linuxvda-scripts-1.3.0.zip

Führen Sie die folgenden Schritte auf jedem Delivery Controller in der Farm aus:

  1. Kopieren Sie das Skript Update-BrokerServiceConfig.ps1 auf den Delivery Controller.
  2. Öffnen Sie als lokaler Administrator eine Windows PowerShell-Konsole.
  3. Navigieren Sie zu dem Ordner, der das Skript enthält.
  4. Führen Sie das Skript aus:

.\Update-BrokerServiceConfig.ps1

Hinweis

Standardmäßig verhindert die Konfiguration von PowerShell das Ausführen von PowerShell-Skripts. Wenn das Skript nicht ausgeführt wird, müssen Sie möglicherweise die PowerShell-Ausführungsrichtlinie ändern und das Skript erneut ausführen:

Set-ExecutionPolicy Unrestricted

Das Skript Update-BrokerServiceConfig.ps1 aktualisiert die Brokerdienstkonfigurationsdatei mit neuen WCF-Endpunkten, die der Linux VDA erfordert, und startet den Brokerdienst neu. Das Skript bestimmt den Speicherort der Brokerdienstkonfigurationsdatei automatisch. Im selben Verzeichnis wird ein Backup der ursprünglichen Konfigurationsdatei mit der Erweiterung .prelinux angelegt.

Diese Änderungen haben keine Auswirkungen auf das Brokering von Windows VDAs, die dieselbe Delivery Controller-Farm verwenden. Auf diese Weise kann eine einzige Controller-Farm Sitzungen für Windows und Linux VDAs nahtlos verwalten und vermitteln.

Überprüfen der Delivery Controller-Konfiguration

Überprüfen Sie, ob die Zeichenfolge EndpointLinux fünf Mal in der Datei angezeigt wird, um zu bestätigen, dass die erforderlichen Konfigurationsänderungen auf einen Delivery Controller angewendet wurden:

       %PROGRAMFILES%\Citrix\Broker\Service\BrokerService.exe.config

An der Windows-Eingabeaufforderung müssen Sie als lokaler Administrator angemeldet sein:

     cd "%PROGRAMFILES%"\Citrix\Broker\Service\

     findstr EndpointLinux BrokerService.exe.config

Important

In Version 1.3 ist der Broker-Agent des Linux-VDAs auf XenApp/XenDesktop 7.8 festgelegt. Wird jedoch ein Maschinenkatalog über den Bildschirm zum Einrichten eines Maschinenkatalogs von Studio hinzugefügt, wird der Standardwert automatisch auf Version 7.9 festgelegt. Sie müssen die Version des installierten VDAs explizit auf 7.8 (oder höher) festlegen (siehe Abbildung unten).

localized image

Vorbereiten einer Linux-Maschine für die VDA-Installation

Starten des YaST-Tools

Mit dem SUSE Linux Enterprise YaST-Tool können alle Aspekte des Betriebssystems konfiguriert werden.

Starten des textbasierten YaST-Tools:

su -

yast

Sie können auch das YaST-Tool mit Benutzeroberfläche starten:

su -

yast2 &

Konfigurieren des Netzwerks

In den folgenden Abschnitten finden Sie Informationen zum Konfigurieren der verschiedenen Netzwerkeinstellungen und Dienste, die der Linux VDA verwendet. Die Konfiguration des Netzwerks sollte mit dem YaST-Tool ausgeführt werden und nicht mit anderen Methoden wie Network Manager. Die Anleitungen beziehen sich auf das YaST-Tool mit Benutzeroberfläche. Sie können das textbasierte YaST-Tool verwenden, aber es erfordert eine andere Navigationsweise, die hier nicht dokumentiert ist.

Konfigurieren von Hostnamen und DNS

  1. Öffnen Sie "YaST Network Settings".
  2. Nur in SLED 12: Ändern Sie auf der Registerkarte Global Options die Einstellung unter Network Setup Method in Wicked Service.
  3. Öffnen Sie die Registerkarte Hostname/DNS.
  4. Deaktivieren Sie das Kontrollkästchen Change hostname via DHCP.
  5. Aktivieren Sie das Kontrollkästchen Assign Hostname to Loopback IP.
  6. Geben Sie die folgenden Informationen entsprechend Ihrer Netzwerkeinstellungen an:
  • Hostname: Geben Sie den DNS-Hostnamen der Maschine an.
  • Domain Name: Geben Sie den DNS-Domänennamen der Maschine an.
  • Name Server: Geben Sie die IP-Adresse des DNS-Servers an. Dies ist normalerweise die IP-Adresse des Active Directory-Domänencontrollers.
  • Domain Search list: Geben Sie den DNS-Domänennamen an.

Hinweis

Der Linux VDA unterstützt derzeit keine abgeschnittenen NetBIOS-Namen, daher darf der Hostname nicht länger als 15 Zeichen sein.

Tipp

Verwenden Sie nur Buchstaben (a-z), Ziffern (0-9) und Bindestriche (-). Vermeiden Sie Unterstriche (_), Leerzeichen und andere Symbole. Hostnamen sollten nicht mit einer Zahl beginnen und nicht mit einem Bindestrich enden.

Deaktivieren von Multicast-DNS

In SLED ist standardmäßig Multicast-DNS (MDNS) aktiviert, was zu inkonsistenten Ergebnissen bei der Namensauflösung führen kann. In SLES ist MDNS nicht standardmäßig aktiviert, daher ist keine Aktion erforderlich.

Sie deaktivieren MDNS, indem Sie /etc/nsswitch.conf bearbeiten und folgende Zeile ändern:

hosts: files mdns_minimal [NOTFOUND=return] dns

In:

hosts: files dns

Überprüfen des Hostnamens

Stellen Sie sicher, dass der Hostname richtig festgelegt ist:

hostname

Nur der Hostname der Maschine sollte zurückgegeben werden und nicht der vollqualifizierte Domänenname (FQDN).

Stellen Sie sicher, dass der FQDN richtig festgelegt ist:

hostname -f

Der FQDN der Maschine sollte zurückgegeben werden.

Überprüfen von Namensauflösung und Diensterreichbarkeit

Stellen Sie sicher, dass Sie den FQDN auflösen können und pingen Sie den Domänencontroller und den XenDesktop Delivery Controller:

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn

Wenn Sie den FQDN nicht auflösen und eine der beiden Maschinen nicht pingen können, überprüfen Sie die vorherigen Schritte, bevor Sie fortfahren.

Konfigurieren des NTP-Diensts

Es ist wichtig, dass die Uhrsynchronisierung zwischen den VDAs, den XenDesktop Controllern und den Domänencontrollern genau ist. Beim Hosten eines Linux VDAs als virtuelle Maschine kann es zu Zeitabweichungen kommen. Aus diesem Grund sollte die Zeit remote von einem NTP-Dienst verwaltet werden. Möglicherweise müssen einige Änderungen an den NTP-Standardeinstellungen vorgenommen werden:

  1. Öffnen Sie "YaST NTP Configuration" und wählen Sie die Registerkarte General Settings aus.
  2. Aktivieren Sie im Abschnitt "Start NTP Daemon" das Kontrollkästchen Now and on Boot.
  3. Wählen Sie das Element Undisciplined Local Clock (LOCAL) aus, wenn es vorhanden ist, und klicken Sie auf Delete.
  4. Fügen Sie einen Eintrag für einen NTP-Server hinzu, indem Sie auf Add klicken.
  5. Wählen Sie unter Server Type den Servertyp aus und klicken Sie auf Next.
  6. Geben Sie den DNS-Namen des NTP-Servers in das Adressfeld ein. Dieser Dienst wird normalerweise auf dem Active Directory-Domänencontroller gehostet.
  7. Lassen Sie das Feld "Options" unverändert.
  8. Klicken Sie auf Test, um zu prüfen, ob der NTP-Dienst erreichbar ist.
  9. Klicken Sie in den folgenden Fenstern auf OK, um die Änderungen zu speichern.

Hinweis

Wenn der NTP-Daemon in SLES 12-Implementierungen nicht startet, ist dies möglicherweise auf ein bekanntes SUSE-Problem mit AppArmor-Richtlinien zurückzuführen. Weitere Informationen und eine Lösung des Problems finden Sie hier.

Installieren von Linux VDA-abhängigen Paketen

Die Linux VDA-Software für Suse Linux Enterprise ist von den folgenden Paketen abhängig:

  • PostgreSQL
    • SLED/SLES 11: Version 9.1 oder höher
    • SLED/SLES 12: Version 9.3 oder höher
  • OpenJDK 1.7.0
  • OpenMotif Runtime Environment 2.3.1 oder höher
  • Cups
    • SLED/SLES 11: Version 1.3.7 oder höher
    • SLED/SLES 12: Version 1.6.0 oder höher
  • Foomatic-Filter
    • SLED/SLES 11: Version 3.0.0 oder höher
    • SLED/SLES 12: Version 1.0.0 oder höher
  • ImageMagick
    • SLED/SLES 11: Version 6.4.3.6 oder höher
    • SLED/SLES 12: Version 6.8 oder höher

Hinzufügen von Repositorys

Einige der erforderlichen Pakete sind nicht in allen SUSE Linux Enterprise-Repositorys verfügbar:

  • SLED 11: PostgreSQL ist für SLES 11, aber nicht für SLED 11 verfügbar.
  • SLES 11: OpenJDK und OpenMotif sind für SLED 11, aber nicht SLES 11 verfügbar.
  • SLED 12: PostgreSQL ist für SLES 12, aber nicht für SLED 12 verfügbar. ImageMagick ist mit dem SLE 12 SDK ISO oder dem Online-Repository verfügbar.
  • SLES 12: Alle Pakete sind verfügbar. ImageMagick ist mit dem SLE 12 SDK ISO oder dem Online-Repository verfügbar.

Laden Sie fehlende Pakete für die Edition, die Sie installieren, vom Medium für die alternative SLE-Edition herunter. Das bedeutet, für SLED können Sie fehlende Pakete vom SLES-Medium installieren und für SLES können Sie fehlende Pakete vom SLED-Medium installieren. Mit der unten beschriebenen Methode werden die ISO-Dateien und Repositorys sowohl für SLED als auch SLES bereitgestellt.

SLED 11


sudo mkdir -p /mnt/sles

sudo mount -t iso9660 \

           path-to-iso/SLES-11-SP3-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles

SLES 11

sudo mkdir -p /mnt/sled

sudo mount -t iso9660 \

           path-to-iso/SLED-11-SP3-DVD-x86_64-GM-DVD1.iso /mnt/sled

sudo zypper ar -f /mnt/sled sled

SLED 12

sudo mkdir -p /mnt/sles

sudo mount -t iso9660 \

           path-to-iso/SLES-12-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles

SLED/SLES 12

sudo mkdir -p /mnt/sdk

sudo mount -t iso9660 \

           path-to-iso/SLE-12-SDK-DVD-x86_64-GM-DVD1.iso /mnt/sdk

sudo zypper ar -f /mnt/sdk sdk

Installieren des Kerberos-Clients

Installieren Sie den Kerberos-Client für die gegenseitige Authentifizierung des Linux VDA und der XenDesktop Controller:

sudo zypper install krb5-client

Die Kerberos-Clientkonfiguration ist abhängig von der verwendeten Active Directory-Integrationsmethode, die später beschrieben wird.

Installieren von OpenJDK

Der Linux VDA ist von OpenJDK 1.7.0 abhängig.

Tipp

Stellen Sie zum Vermeiden von Problemen sicher, dass nur die OpenJDK-Version 1.7.0 installiert ist. Entfernen Sie alle anderen auf dem System vorhandenen Java-Versionen.

SLED

Unter SLED sollte Java Runtime Environment mit dem Betriebssystem installiert worden sein. Überprüfen Sie dies mit folgenden Befehl:

       sudo zypper info java-1_7_0-openjdk

Aktualisieren Sie auf die aktuelle Version, wenn der Status als veraltet gemeldet wird:

sudo zypper update java-1_7_0-openjdk

Überprüfen Sie die Java-Version:

java -version

SLES

Unter SLES muss Java Runtime Environment installiert werden:

sudo zypper install java-1_7_0-openjdk

Überprüfen Sie die Java-Version:

java -version

Installieren von PostgreSQL

SLED/SLES 11

Installieren Sie die Pakete:

sudo zypper install libecpg6

sudo zypper install postgresql?init

sudo zypper install postgresql91

sudo zypper install postgresql91?server

sudo zypper install postgresql?jdbc

Nach der Installation sind einige Schritte erforderlich, um den Datenbankdienst zu initialisieren und sicherzustellen, dass PostgreSQL beim Booten startet:

sudo /sbin/insserv postgresql

sudo /etc/init.d/postgresql restart

SLED/SLES 12

Installieren Sie die Pakete:

sudo zypper install postgresql-init

sudo zypper install postgresql93-server

sudo zypper install postgresql-jdbc

Nach der Installation sind Schritte erforderlich, um den Datenbankdienst zu initialisieren und sicherzustellen, dass PostgreSQL beim Booten startet:

sudo systemctl enable postgresql

sudo systemctl restart postgresql

Datenbankdateien befinden sich unter /var/lib/pgsql/data.

Installieren der OpenMotif Runtime Environment

Abhängig von der Distribution benötigt der Linux VDA das motif- oder openmotif-Paket.

SLED/SLES 11

Installieren Sie das Paket:

sudo zypper install openmotif-libs

SLED/SLES 12

Installieren Sie das Paket:

sudo zypper install motif

Installieren der Druckunterstützung

Der Linux VDA erfordert Cups- und Foomatic-Filter.

SLED/SLES 11

Installieren Sie die Pakete:

sudo zypper install cups

sudo zypper install foomatic-filters

SLED/SLES 12

Installieren Sie die Pakete:

sudo zypper install cups

sudo zypper install cups-filters-foomatic-rip

Installieren von ImageMagick

Installieren Sie das ImageMagick-Paket:

sudo zypper install ImageMagick

Entfernen von Repositorys

Nach der Installation der abhängigen Pakete können nun die zuvor eingerichteten Repositorys der alternativen Edition entfernt und die Bereitstellung der Medien aufgehoben werden:

SLED 11

Entfernen Sie die folgenden Pakete:

sudo zypper rr sles

sudo umount /mnt/sles

sudo rmdir /mnt/sles

SLES 11

Entfernen Sie die folgenden Pakete:

sudo zypper rr sled

sudo umount /mnt/sled

sudo rmdir /mnt/sled

SLED 12

Entfernen Sie die folgenden Pakete:

sudo zypper rr sles

sudo umount /mnt/sles

sudo rmdir /mnt/sles

SLED/SLES 12

Entfernen Sie die folgenden Pakete:

sudo zypper rr sdk

sudo umount /mnt/sdk

sudo rmdir /mnt/sdk

Vorbereiten der Linux-VM für den Hypervisor

Wenn Sie den Linux VDA als virtuelle Maschine auf einem unterstützten Hypervisor ausführen, sind einige Änderungen erforderlich. Nehmen Sie entsprechend der verwendeten Hypervisorplattform die folgenden Änderungen vor. Wenn Sie die Linux-Maschine auf Bare-Metal-Hardware ausführen, sind keine Änderungen erforderlich.

Festlegen der Zeitsynchronisierung auf Citrix XenServer

Wenn das Zeitsynchronisierungsfeature auf XenServer aktiviert ist, treten auf den paravirtualisierten Linux-VMs Probleme auf, da NTP und XenServer gleichzeitig versuchen, die Systemuhr zu verwalten. Damit es nicht zu Zeitabweichungen zwischen der Uhr und den anderen Servern kommt, muss die Systemuhr aller Linux-Gäste mit dem NTP synchronisiert werden. Dazu muss die Hostzeitsynchronisierung deaktiviert werden. Im HVM-Modus sind keine Änderungen erforderlich.

Auf einigen Linux-Distributionen, auf denen ein paravirtualisierter Linux-Kernel mit installierten XenServer-Tools ausgeführt wird, können Sie direkt in der Linux-VM prüfen, ob das XenServer- Zeitsynchronisierungsfeature vorhanden und aktiviert ist:

su -

cat /proc/sys/xen/independent_wallclock

Mögliche Ergebnisse:

  • 0: Das Zeitsynchronisierungsfeature ist aktiviert und muss deaktiviert werden.
  • 1: Das Zeitsynchronisierungsfeature ist deaktiviert und keine weitere Aktion ist erforderlich.

Wenn die Datei /proc/sys/xen/indepent_wallclock nicht vorhanden ist, sind die folgenden Schritte nicht erforderlich.

Wenn das Zeitsynchronisierungsfeature aktiviert ist, deaktivieren Sie es, indem Sie "1" in die Datei eingeben:

sudo echo 1 > /proc/sys/xen/independent_wallclock

Damit die Änderung permanent wird und nach dem Neustart erhalten bleibt, bearbeiten Sie die Datei /etc/sysctl.conf und fügen Sie die folgende Zeile hinzu:

xen.independent_wallclock = 1

Starten Sie das System neu, um die Änderungen zu überprüfen:

reboot

Nach dem Neustart müssen Sie sicherstellen, dass die Einstellung richtig festgelegt wurde:

su -

cat /proc/sys/xen/independent_wallclock

Der Wert "1" sollte zurückgegeben werden.

Festlegen der Zeitsynchronisierung auf Microsoft Hyper-V

Linux-VMs, auf denen Hyper-V Linux-Integrationsdienste installiert sind, können mit dem Hyper-V-Zeitsynchronisierungsfeature die Systemzeit des Hostbetriebssystems verwenden. Um sicherzustellen, dass die Betriebssystemzeit korrekt ist, sollten Sie das Feature zusätzlich zu den NTP-Diensten aktivieren.

Auf dem verwaltenden Betriebssystem:

  1. Öffnen Sie die Hyper-V-Manager-Konsole.
  2. Wählen Sie für die Einstellungen einer Linux-VM Integration Services aus.
  3. Stellen Sie sicher, dass Time synchronization ausgewählt ist.

Hinweis

Diese Methode unterscheidet sich von VMware und XenServer, wo die Hostzeitsynchronisierung deaktiviert ist, um Konflikte mit dem NTP zu vermeiden. Hyper-V-Zeitsynchronisierung kann gleichzeitig mit der NTP-Zeitsynchronisierung bestehen und sie ergänzen.

Festlegen der Zeitsynchronisierung auf ESX und ESXi

Wenn das VMware-Zeitsynchronisierungsfeature aktiviert ist, treten auf den paravirtualisierten Linux-VMs Probleme auf, da NTP und der Hypervisor gleichzeitig versuchen, die Systemuhr zu verwalten. Damit es nicht zu Zeitabweichungen zwischen der Uhr und den anderen Servern kommt, muss die Systemuhr aller Linux-Gäste mit dem NTP synchronisiert werden. Dazu muss die Hostzeitsynchronisierung deaktiviert werden.

Wenn Sie einen paravirtualisierten Linux-Kernel ausführen und VMware-Tools installiert sind:

  1. Öffnen Sie den vSphere-Client.
  2. Bearbeiten Sie die Einstellungen für die Linux-VM.
  3. Öffnen Sie im Dialogfeld Virtual Machine Properties die Registerkarte Options.
  4. Wählen Sie "VMware Tools".
  5. Deaktivieren Sie im Bereich Advanced das Kontrollkästchen Synchronize guest time with host.

Hinzufügen einer Linux-Maschine zu einer Windows-Domäne

Linux-Maschinen können mit verschiedenen Methoden der Active Directory-Domäne hinzugefügt werden, die von XenDesktop für Linux unterstützt wird:

  • Samba Winbind
  • Quest Authentication Service
  • Centrify DirectControl

Folgen Sie den Anweisungen unten für die von Ihnen gewählte Methode.

Samba Winbind

Beitreten zu einer Windows-Domäne

Es wird vorausgesetzt, dass der Domänencontroller erreichbar ist und dass Sie über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Maschinen zur Domäne verfügen:

1.  Öffnen Sie "YaST Windows Domain Membership".

2. Nehmen Sie die folgenden Änderungen vor:

  • Legen Sie die Domäne oder Arbeitsgruppe auf den Namen der Active Directory-Domäne oder auf die IP-Adresse des Domänencontrollers fest. Stellen Sie sicher, dass die Domäne in Großbuchstaben angegeben wurde.
  • Aktivieren Sie außerdem das Kontrollkästchen "Use SMB information for Linux Authentication".
  • Aktivieren Sie das Kontrollkästchen "Create Home Directory on Login".
  • Aktivieren Sie "Single Sign-on for SSH".
  • Stellen Sie sicher, dass die Option "Offline Authentication" nicht aktiviert ist. Diese Option ist mit dem Linux VDA nicht kompatibel.

3. Klicken Sie auf OK. Wenn Sie zum Installieren einiger Pakete aufgefordert werden, klicken Sie auf "Install".

4. Wenn ein Domänencontroller gefunden wird, werden Sie gefragt, ob Sie der Domäne beitreten möchten. Klicken Sie auf "Yes".

5. Wenn Sie dazu aufgefordert werden, geben Sie die Anmeldeinformationen eines Domänenbenutzers ein, der über Berechtigungen zum Hinzufügen von Computern zur Domäne verfügt, und klicken Sie auf "OK".

6. Eine Erfolgsmeldung wird angezeigt.

7. Wenn Sie zum Installieren von samba- und krb5-Paketen aufgefordert werden, klicken Sie auf "Install".

YaST hat Sie möglicherweise davon unterrichtet, dass für diese Änderungen einige Dienste oder die Maschine neu gestartet werden muss. Führen Sie einen Neustart durch:

su -

reboot

Nur für SLED/SLES 12: Reparieren des Namens für Kerberos-Anmeldeinformationscache

In SLED/SLES 12 wurde die Spezifikation für den Standardnamen des Kerberos-Anmeldeinformationscaches von FILE:/tmp/krb5cc_%{uid} in DIR:/run/user/%{uid}/krb5cc geändert. Diese neue DIR-Zwischenspeichermethode ist nicht mit dem Linux VDA kompatibel und muss manuell geändert werden. Bearbeiten Sie als Root-Benutzer die Datei /etc/krb5.conf und fügen Sie ggf. die folgende Einstellung im Abschnitt [libdefaults] hinzu:

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

Überprüfen der Domänenmitgliedschaft

Für den XenDesktop Controller ist es erforderlich, dass alle VDA-Maschinen, Windows und Linux, ein Computerobjekt in Active Directory haben.

Stellen Sie mit dem folgenden Samba-Befehl sicher, dass die Maschine zu einer Domäne gehört:

sudo net ads testjoin

Überprüfen Sie zusätzliche Domänen- und Computerobjektinformationen mit folgendem Befehl:

sudo net ads info

Überprüfen der Kerberos-Konfiguration

Überprüfen Sie, ob Kerberos zur Verwendung mit dem Linux VDA ordnungsgemäß konfiguriert ist, indem Sie sicherstellen, dass die Systemdatei für die Schlüsseltabelle erstellt wurde und gültige Schlüssel enthält:

sudo klist –ke

Daraufhin sollte die Liste der Schlüssel angezeigt werden, die für die verschiedenen Kombinationen aus Prinzipalnamen und Verschlüsselungssammlungen verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um die Maschine mit dem Domänencontroller zu authentifizieren, die diese Schlüssel verwendet:

sudo kinit -k MACHINE\$@REALM

Maschinen- und Bereichsname müssen in Großbuchstaben angegeben werden und das Dollarzeichen ($) muss durch einen umgekehrten Schrägstrich (\) geschützt werden, um die Ersetzung in der Shell zu verhindern. In einigen Umgebungen sind DNS-Domänenname und Kerberos-Bereichsname unterschiedlich. Stellen Sie sicher, dass der Bereichsname verwendet wird. Wenn dieser Befehl erfolgreich ist, wird keine Ausgabe angezeigt.

Stellen Sie mit folgendem Befehl sicher, dass das TGT-Ticket für das Maschinenkonto zwischengespeichert wurde:

sudo klist

Überprüfen Sie die Maschinenkontodetails mit folgendem Befehl:

sudo net ads status

Überprüfen der Benutzerauthentifizierung

Überprüfen Sie mit dem wbinfo-Tool, dass Domänenbenutzer sich bei der Domäne authentifizieren können:

wbinfo --krb5auth=domain\\username%password

Die hier angegebene Domäne ist der AD-Domänenname und nicht der Kerberos-Bereichsname. Für die Bash-Shell muss der umgekehrte Schrägstrich (\) durch einen weiteren umgekehrten Schrägstrich geschützt werden. Bei diesem Befehl wird eine Erfolgs- oder Fehlermeldung zurückgegeben.

Um sicherzustellen, dass das Winbind PAM-Modul richtig konfiguriert ist, melden Sie sich lokal mit einem Domänenbenutzerkonto an, mit dem noch nie eine Anmeldung an der Maschine vorgenommen wurde:

ssh localhost -l domain\\username

id -u

Stellen Sie sicher, dass eine entsprechende Cachedatei mit Kerberos-Anmeldeinformationen für die mit dem Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid

Stellen Sie sicher, dass die Tickets im Kerberos-Anmeldeinformationscache des Benutzers gültig und nicht abgelaufen sind:

klist

Beenden Sie die Sitzung:

exit

Ein ähnlicher Test kann ausgeführt werden, wenn Sie sich direkt an der Gnome- oder KDE-Konsole anmelden.

Quest Authentication Service

Konfigurieren von Quest auf dem Domänencontroller

Es wird vorausgesetzt, dass Sie die Quest-Software auf den Active Directory-Domänencontrollern installiert und konfiguriert haben und über Administratorrechte zum Erstellen von Computerobjekten in Active Directory verfügen.

Domänenbenutzern die Anmeldung an Linux VDA-Maschinen ermöglichen

Für alle Domänenbenutzer, die HDX-Sitzungen auf einer Linux VDA-Maschine herstellen, führen Sie folgende Schritte aus:

  1. Öffnen Sie in der Verwaltungskonsole für Active Directory-Benutzer und -Computer die Active Directory-Eigenschaften für das jeweilige Benutzerkonto.
  2. Wählen Sie die Registerkarte "Unix Account" aus.
  3. Aktivieren Sie das Kontrollkästchen "Unix-enabled".
  4. Legen Sie "Primary GID Number" auf die Gruppen-ID einer vorhandenen Domänenbenutzergruppe fest.

Hinweis

Mit diesen Anleitungen können Domänenbenutzer für die Anmeldung mit der Konsole, RDP, SSH oder anderen Remotingprotokollen eingerichtet werden.

Konfigurieren von Quest auf Linux VDA

Konfigurieren des VAS-Daemon

Die automatische Erneuerung von Kerberos-Tickets muss aktiviert und getrennt sein. Authentifizierung (für Offlineanmeldung) muss deaktiviert sein:

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

Hiermit wird das Verlängerungsintervall auf 9 Stunden (32400 Sekunden) festgelegt. Das ist eine Stunde weniger als die Standardgültigkeitsdauer (10 Stunden) eines Tickets. Bei Systemen mit einer kürzeren Gültigkeitsdauer für Kerberos-Tickets legen Sie diesen Parameter auf einen niedrigeren Wert fest.

Konfigurieren von PAM und NSS

Quest erfordert, dass PAM und NSS manuell konfiguriert werden, um Domänenbenutzern die Anmeldung per HDX und anderen Diensten, wie SU, SSH und RDP, zu ermöglichen. Konfigurieren von PAM und NSS:

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss

Beitreten zu einer Windows-Domäne

Machen Sie die Linux-Maschine mit dem Quest-Befehl "vastool" zu einem Mitglied der Active Directory-Domäne:

sudo /opt/quest/bin/vastool -u user join domain-name

Der Benutzer ist ein beliebiger Domänenbenutzer mit der Berechtigung, Computer zu Mitgliedern der Active Directory-Domäne zu machen. Der Domänenname ist der DNS-Name der Domäne, z. B. example.com.

Überprüfen der Domänenmitgliedschaft

Für den XenDesktop Controller ist es erforderlich, dass alle VDA-Maschinen, Windows und Linux, ein Computerobjekt in Active Directory haben. Mit folgendem Befehl prüfen Sie, ob eine per Quest angemeldete Linux-Maschine zur Domäne gehört:

sudo /opt/quest/bin/vastool info domain

Wenn die Maschine zu einer Domäne gehört, wird der Domänenname zurückgegeben. Wenn sie nicht zur Domäne gehört, wird die folgende Fehlermeldung angezeigt:

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

Überprüfen der Benutzerauthentifizierung

Um sicherzustellen, dass Quest Domänenbenutzer mit PAM authentifizieren kann, melden Sie sich mit einem Domänenbenutzerkonto an, mit dem noch nie eine Anmeldung an der Maschine vorgenommen wurde:

ssh localhost -l domain\\username

id -u

Stellen Sie sicher, dass eine entsprechende Cachedatei mit Kerberos-Anmeldeinformationen für die mit dem Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid

Stellen Sie sicher, dass die im Tickets Kerberos-Anmeldeinformationscache des Benutzers gültig und nicht abgelaufen sind:

/opt/quest/bin/vastool klist

Beenden Sie die Sitzung:

exit

Ein ähnlicher Test kann ausgeführt werden, wenn Sie sich direkt an der Gnome- oder KDE-Konsole anmelden.

Centrify DirectControl

Beitreten zu einer Windows-Domäne

Wenn der Centrify DirectControl Agent installiert ist, machen Sie die Linux-Maschine mit dem Centrify-Befehl adjoin zu einem Mitglied der Active Directory-Domäne:

su –

adjoin -w -V -u user domain-name

Der Parameter user ist ein Active Directory-Domänenbenutzer mit der Berechtigung, Computer zu Mitgliedern von Active Directory-Domänen zu machen. Der Parameter "domain-name" ist der Name der Domäne, der die Linux-Maschine beitritt.

Überprüfen der Domänenmitgliedschaft

Für den XenDesktop Controller ist es erforderlich, dass alle VDA-Maschinen, Windows und Linux, ein Computerobjekt in Active Directory haben. Mit folgendem Befehl prüfen Sie, ob eine per Centrify hinzugefügte Linux-Maschine Mitglied der Domäne ist:

su –

adinfo

Stellen Sie sicher, dass der Wert Joined to domain gültig ist und dass CentrifyDC mode den Wert connected zurückgibt. Wenn der Modus im Startzustand stecken bleibt, hat der Centrify-Client Serververbindungs- oder Authentifizierungsprobleme.

Umfassendere System- und Diagnoseinformationen sind mit folgenden Befehlen verfügbar:

adinfo --sysinfo all

adinfo –diag

Testen der Verbindung mit den verschiedenen Active Directory- und Kerberos-Diensten:

adinfo --test

Konfigurieren eines Linux-Maschinenkatalogs und einer Bereitstellungsgruppe

Hinzufügen einer Linux-Maschine zum Maschinenkatalog

Der Prozess zum Erstellen von Maschinenkatalogen und Hinzufügen von Linux VDA-Maschinen ist der traditionellen Windows VDA-Methode sehr ähnlich. Umfassendere Informationen zu diesen Prozessen finden Sie in der Citrix Produktdokumentation.

Beim Erstellen von Maschinenkatalogen mit Linux VDA-Maschinen gibt es einige Einschränkungen, durch die sich der Prozess von der Maschinenkatalogerstellung für Windows VDA-Maschinen unterscheidet:

  • Auswahl des Betriebssystems:
    • Windows-Serverbetriebssystem oder Serverbetriebssystem für ein gehostetes, freigegebenes Desktopbereitstellungsmodell.
    • Windows-Desktopbetriebssystem oder Desktopbetriebssystem für ein VDI-dediziertes Desktopbereitstellungsmodell.
  • Stellen Sie sicher, dass für die Maschinen keine Energieverwaltung festgelegt ist.
  • Da PVS und MCS für Linux VDAs nicht unterstützt werden, wählen Sie die Bereitstellungsmethode Anderer Dienst oder andere Technologie (vorhandene Images).
  • In einem Maschinenkatalog darf sich keine Mischung aus Linux und Windows VDA-Maschinen befinden.

Hinweis

In früheren Citrix Studio-Versionen wurde Linux als Betriebssystem nicht unterstützt. Durch die Auswahl von Windows-Serverbetriebssystem oder Serverbetriebssystem wird ein äquivalentes gehostetes, freigegebenes Desktopbereitstellungsmodell bereitgestellt. Durch die Auswahl von Windows-Desktopbetriebssystem oder Desktopbetriebssystem wird ein Bereitstellungsmodell für XenDesktop Einzelbenutzermaschinen bereitgestellt.

Anleitungen zum Erstellen von Maschinenkatalogen finden Sie in der Citrix Dokumentation unter der jeweiligen Version:

Frühere Versionen von XenDesktop werden nicht unterstützt.

Tipp

Wenn eine Maschine eine Active Directory-Domäne verlässt und ihr dann wieder beitritt, muss die Maschine aus dem Maschinenkatalog entfernt und ihm dann erneut hinzugefügt werden.

Hinzufügen einer Bereitstellungsgruppe

Die Prozesse zum Erstellen einer Bereitstellungsgruppe und zum Hinzufügen von Maschinenkatalogen mit Linux VDA- bzw. Windows VDA-Maschinen sind fast identisch. Umfassendere Informationen zu diesen Prozessen finden Sie online in der Citrix Produktdokumentation.

Beim Erstellen von Bereitstellungsgruppen mit Linux VDA-Maschinenkatalogen gelten die folgenden Einschränkungen:

  • Wählen Sie als Bereitstellungstyp "Desktops" aus. Linux VDA-Maschinen unterstützen keine Bereitstellung von Anwendungen.
  • Stellen Sie sicher, dass die ausgewählten Active Directory-Benutzer und -Gruppen für die Anmeldung an Linux VDA-Maschinen richtig konfiguriert wurden.
  • Lassen Sie nicht die Anmeldung nicht authentifizierter (anonymer) Benutzer zu.
  • Die Bereitstellungsgruppe darf keine Maschinenkataloge mit Windows Maschinen enthalten.

Anleitungen zum Erstellen von Bereitstellungsgruppen finden Sie in der Citrix Dokumentation unter der jeweiligen Version:

Frühere Versionen von XenDesktop werden nicht unterstützt.

Installieren der Linux VDA-Software

Deinstallieren der alten Version

Wenn bereits eine ältere Linux VDA-Version als Version 1.0 installiert ist, deinstallieren Sie diese Version, bevor Sie die neue Version installieren.

Halten Sie die Linux VDA-Dienste an:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

Deinstallieren Sie das Paket:

sudo rpm -e XenDesktopVDA

Important

Das Upgrade von der Tech Preview auf Version 1.0, 1.1, 1.2 und 1.3 wird nicht unterstützt.

Hinweis

Ab Version 1.3 wurde der Installationspfad geändert. In vorherigen Releases waren die Installationskomponenten unter /usr/local/. Der neue Speicherort ist /opt/Citrix/VDA/.

Zum Ausführen eines Befehls ist der vollständige Pfad erforderlich. Alternativ können Sie /opt/Citrix/VDA/sbin und /opt/Citrix/VDA/bin dem Systempfad hinzufügen.

Installieren des Linux VDA

Installieren Sie die Linux VDA-Software mit dem RPM-Paketmanager:

Für SuSE 11:

sudo rpm -i XenDesktopVDA-1.3.312-1.x86_64.rpm

Für SuSE 12:

sudo rpm -i XenDesktopVDA-1.3.312-1.x86_64.rpm

Aktualisieren des Linux VDA

Wenn Sie Version 1.1 des Linux VDA installiert haben, aktualisieren Sie die Linux VDA-Software mit dem RPM-Paketmanager:

Für SuSE 11:

sudo rpm -U XenDesktopVDA-1.3.312-1.x86_64.rpm

Für SuSE 12:

sudo rpm -U XenDesktopVDA-1.3.312-1.x86_64.rpm

Important

Nach dem Upgrade müssen Sie die Linux VDA-Maschine neu starten.

Konfigurieren des Linux VDA

Nach der Installation des Pakets müssen Sie den Linux VDA konfigurieren, indem Sie das Skript ctxsetup.sh ausführen. Wenn Sie das Paket aktualisiert haben, müssen Sie das Skript ctxsetup.sh ausführen, um das Upgrade abzuschließen. Das Skript überprüft die Umgebung und stellt sicher, dass alle Abhängigkeiten installiert sind. Führen Sie Änderungen erst danach durch. Bei Bedarf können Sie dieses Skript jederzeit erneut ausführen, um Einstellungen zu ändern.

Das Skript kann manuell mit Aufforderungen oder automatisch mit vorkonfigurierten Antworten ausgeführt werden. Lesen Sie die Hilfe zu diesem Skript durch, bevor Sie fortfahren:

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh –help

Konfiguration mit Aufforderungen

Führen Sie eine manuelle Konfiguration mit Aufforderungen aus:

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh

Automatische Konfiguration

Bei einer automatischen Installation können die für das Setupskript erforderlichen Optionen mit Umgebungsvariablen angegeben werden. Wenn alle erforderlichen Variablen vorhanden sind, fordert das Skript keine weiteren Informationen vom Benutzer und der Installationsvorgang wird per Skript ausgeführt.

Unterstützte Umgebungsvariablen umfassen u. a.:

  • CTX_XDL_SUPPORT_DDC_AS_CNAME = Y | N: Der Virtual Delivery Agent unterstützt die Angabe des Namens eines Delivery Controllers mit einem DNS CNAME-Datensatz. Die Einstellung ist normalerweise N.
  • CTX_XDL_DDC_LIST = list-ddc-fqdns: Der Virtual Delivery Agent erfordert eine durch Leerzeichen getrennte Liste vollqualifizierter Domänennamen (FQDNs) von Delivery Controllern
  • zur Registrierung mit einem Delivery Controller. Mindestens ein FQDN oder CNAME-Alias muss angegeben werden.
  • TX_XDL_VDA_PORT = port-number: Der Virtual Delivery Agent kommuniziert mit Delivery Controllern über einen TCP/IP-Port. Dies ist normalerweise Port 80.
  • CTX_XDL_REGISTER_SERVICE = Y | N: Der Support für Linux Virtual Desktop-Dienste wird während des Startvorgangs gestartet. Die Einstellung ist normalerweise Y.
  • CTX_XDL_ADD_FIREWALL_RULES = Y | N: Für die Linux Virtual Desktop-Dienste muss die Systemfirewall eingehende Netzwerkverbindungen zulassen. Sie können die erforderlichen Ports (standardmäßig Port 80 und 1494) in der Systemfirewall automatisch für Linux Virtual Desktop öffnen. Die Einstellung ist normalerweise Y.
  • CTX_XDL_AD_INTEGRATION = 1 | 2 | 3: Für den Virtual Delivery Agent müssen Kerberos-Konfigurationseinstellungen von den Delivery Controllern authentifiziert werden. Die Kerberos-Konfiguration wird durch das auf dem System installierte und konfigurierte Active Directory-Integrationstool bestimmt. Geben Sie die zu verwendende Active Directory-Integrationsmethode an:
    • 1 – Samba Winbind
    • 2 – Quest-Authentifizierungsdienst
    • 3 – Centrify DirectControl
  • CTX_XDL_HDX_3D_PRO= Y | N: Linux Virtual Desktop unterstützt HDX 3D Pro, ein Satz Grafikbeschleunigungstechnologien zum Optimieren der Virtualisierung reichhaltiger Grafikanwendungen. Für HDX 3D Pro muss eine kompatible NVIDIA Grid-Grafikkarte installiert sein. Wenn HDX 3D Pro aktiviert ist, muss der Virtual Delivery Agent für VDI-Desktopmodus (Einzelsitzungen) konfiguriert werden (d. h. CTX_XDL_VDI_MODE=Y). Dies wird unter SUSE nicht unterstützt. Stellen Sie sicher, dass dieser Wert auf N eingestellt ist.
  • CTX_XDL_VDI_MODE: =J | N: Ermöglicht die Konfiguration der Maschine als ein dediziertes Desktopbereitstellungsmodell (VDI) oder als gehostetes, freigegebenes Desktopbereitstellungsmodell. Für HDX 3D Pro-Umgebungen muss die Einstellung Y sein. Die Einstellung ist normalerweise N.
  • CTX_XDL_SITE_NAME= dns-name: Der Virtual Delivery Agent ermittelt LDAP-Server mit DNS durch die Abfrage von LDAP-Diensteinträgen. Geben Sie einen DNS-Sitenamen an, wenn Sie die Suchergebnisse auf eine lokale Site beschränken möchten. Normalerweise ist nichts angegeben [none].
  • CTX_XDL_LDAP_LIST= list-ldap-servers: Der Virtual Delivery Agent fragt standardmäßig DNS ab, um LDAP-Server zu ermitteln. Wenn DNS keine LDAP-Diensteinträge ermitteln kann, können Sie eine durch Leerzeichen getrennte Liste mit LDAP-FQDNs mit LDAP-Port angeben (z. B. ad1.mycompany.com:389). Normalerweise ist nichts angegeben [none].
  • CTX_XDL_SEARCH_BASE= search-base: Der Virtual Delivery Agent fragt standardmäßig LDAP mit einer Suchbasis ab, die auf den Stamm der Active Directory-Domäne festgelegt ist (z. B. DC=mycompany,DC=com). Zum Verbessern der Suchleistung kann jedoch eine Suchbasis angegeben werden (z. B. OU=VDI,DC=mycompany,DC=com). Normalerweise ist nichts angegeben [none].
  • CTX_XDL_START_SERVICE = Y | N: Legt fest, ob die Linux VDA-Dienste gestartet werden, wenn die Linux VDA-Konfiguration abgeschlossen ist. Die Einstellung ist normalerweise Y.

Hinweis

HDX 3D Pro ist zurzeit nicht unter SUSE verfügbar.

Legen Sie die Umgebungsvariable fest und führen Sie das Konfigurationsskript aus:

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

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

export CTX_XDL_START_SERVICE=Y|N

sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh

Sie müssen die Option -E mit sudo angeben, damit die vorhandenen Umgebungsvariablen an die neu erstellte Shell weitergegeben werden. Citrix empfiehlt, dass Sie mit den oben aufgeführten Befehlen eine Shellskriptdatei erstellen, deren erste Zeile #!/bin/bash enthält.

Alternativ können alle Parameter mit einem einzigen Befehl angegeben werden:

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 \

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 \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh

Entfernen von Konfigurationsänderungen

In einigen Fällen müssen die vom Skript ctxsetup.sh vorgenommenen Konfigurationsänderungen u. U. entfernt werden, ohne das Linux VDA-Paket zu deinstallieren.

Lesen Sie die Hilfe zu diesem Skript durch, bevor Sie fortfahren:

sudo /usr/local/sbin/ctxcleanup.sh --help

Entfernen von Konfigurationsänderungen:

sudo /usr/local/sbin/ctxcleanup.sh

Important

Dieses Skript löscht alle Konfigurationsdaten aus der Datenbank, sodass der Linux VDA nicht funktionsfähig ist.

Konfigurationsprotokolle

Die Skripts ctxsetup.sh und ctxcleanup.sh zeigen Fehler auf der Konsole an und schreiben weitere Informationen in eine Konfigurationsprotokolldatei:

/tmp/xdl.configure.log

Starten Sie die Linux VDA-Dienste neu, damit die Änderungen wirksam werden.

Ausführen der VDA-Software

Wenn Sie den Linux VDA mit dem Skript ctxsetup.sh konfiguriert haben, können Sie den Linux VDA mit den folgenden Befehlen steuern.

Starten des Linux VDA

Starten der Linux VDA-Dienste:

sudo /sbin/service ctxhdx start

sudo /sbin/service ctxvda start

Anhalten des Linux VDA

Anhalten der Linux VDA-Dienste:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

Neustarten des Linux VDA

Neustarten der Linux VDA-Dienste:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

sudo /sbin/service ctxvda start

Überprüfen des Linux VDA-Status

Überprüfen des Ausführungsstatus der Linux VDA-Dienste:

sudo /sbin/service ctxvda status

sudo /sbin/service ctxhdx status

Deinstallieren der Linux VDA-Software

Abfragen des Linux VDA-Installationsstatus

Überprüfen, ob der Linux VDA installiert ist, und Anzeigen der Version des installierten Pakets:

rpm -q XenDesktopVDA

Anzeigen weiterer Details:

rpm –qi XenDesktopVDA

Deinstallieren des Linux VDA

Deinstallieren des Linux VDA-Pakets:

sudo rpm -e XenDesktopVDA

Hinweis

Beim Deinstallieren der Linux VDA-Software werden die damit verknüpften PostgreSQL- und andere Konfigurationsdaten gelöscht. Das PostgreSQL-Paket und andere abhängige Pakete, die vor der Installation des Linux VDA eingerichtet wurden, werden nicht entfernt.

Entfernen von abhängigen Paketen

Dieser Abschnitt bezieht sich nicht auf das Entfernen von abhängigen Paketen einschließlich PostgreSQL.

Problembehandlung

Sicherstellen, dass die H.264-Codierung verwendet wird

Linux VDA v1.3 fügt H264 und einen HardwareEncoding-Wert im Registrierungspfad HKLM\Software\Citrix\Ica\Session\\Graphics hinzu, um die Problembehandlung von Grafikproblemen, die beim VDA auftreten, zu unterstützen.

Führen Sie den folgenden Befehl aus, um die H.264-Codierung in einem Linux-VDA vor dem Start einer Sitzung anzukündigen:

/opt/Citrix/VDA/bin/ctxreg create -k

"HKLM\System\CurrentControlSet\Control\Citrix\Thinwire" -t "REG_DWORD" -v

"AdvertiseH264" -d "0x00000001" --force

Starten Sie die Sitzung und überprüfen Sie, ob der Schlüssel H264 im Registrierungspfad erstellt wurde. Wenn ja, wird die H.264-Codierung verwendet.

/opt/Citrix/VDA/bin/ctxreg list -k

"HKLM\Software\Citrix\Ica\Session\{SESSION_ID}\Graphics"

Sicherstellen, dass die Hardwarecodierung für 3D Pro verwendet wird

3D Pro-Hardwarecodierung ist standardmäßig deaktiviert. Aktivieren Sie die Funktion mit dem folgenden Befehl:

/opt/Citrix/VDA/bin/ctxreg create -k

"HKLM\System\CurrentControlSet\Control\Citrix\Thinwire" -t "REG_DWORD" -v

"HardwareEncoding" -d "0x00000001" --force

Starten Sie die Sitzung und überprüfen Sie den Wert von "HardwareEncoding" im Registrierungspfad. 0 bedeutet, Hardwarecodierung wird nicht verwendet, 1 bedeutet, Hardwarecodierung wird verwendet.

/opt/Citrix/VDA/bin/ctxreg list -k

"HKLM\Software\Citrix\Ica\Session\{SESSION_ID}\Graphics"

Verwenden Sie den Befehl unten, um die Sitzungs-ID abzufragen:

/opt/Citrix/VDA/bin/ctxqsession

Anpassen der Desktopumgebung pro Benutzer

Der Linux-VDA ermöglicht es dem Benutzer nicht, bei der Anmeldung die Desktopumgebung auszuwählen. Um dieses Problem zu umgehen, kann der Benutzer eine Datei (z. B. .xsession) für die Linux-Distribution konfigurieren, um die Standarddesktopumgebung für alle Benutzer festzulegen. Weitere Informationen finden Sie in der Dokumentation zur Linux-Distribution.

Festlegen von KDE als Standardumgebung:

#! /usr/bin/env bash

exec startkde

Festlegen von GNOME als Standarddesktopumgebung:

#! /usr/bin/env bash

exec gnome-session

Überprüfen Sie, ob die Linux-Maschine richtig vorbereitet wurde.

Die häufigsten Probleme sind das Ergebnis einer Fehlkonfiguration der Linux-Maschine, hauptsächlich im Netzwerkbereich, bei der Konfiguration des NTP-Zeitservers oder der Active Directory-Domänenmitgliedschaft. Durch das Beheben der Konfigurationsprobleme der Linux-Maschine werden die Probleme mit der VDA-Software auch oft behoben.

Konfigurieren der Protokollierung und der Ablaufverfolgung

Der Broker Agent und der HDX-Dienst protokollieren in Syslog. Citrix Support bietet Tools, die weitere Ablaufverfolgung während eines Supportanrufs aktivieren können.

HDX-Dienstprotokollierung

Der HDX-Dienst protokolliert vordefinierte Systemmeldungen und es ist keine weitere Konfiguration erforderlich.

Broker Agent-Protokollierung

Der Broker Agent (auch ctxvda-Dienst) schreibt Protokolldaten per Netzwerk-Sockets in Syslog. Dies ist möglicherweise nicht vorkonfiguriert. Die folgende Konfiguration ist erforderlich, damit der Broker Agent in Syslog protokolliert:

SLED/SLES 11

Bearbeiten Sie die Datei /etc/syslog-ng/syslog-ng.conf und fügen Sie die folgende Zeile im Abschnitt s_sys hinzu:

udp(ip(127.0.0.1) port(514));

Speichern und schließen Sie die Datei syslog-ng.conf. Starten Sie den Dienst syslog-ng neu, um die Änderung anzuwenden:

sudo service syslog-ng restart

SLED/SLES 12

Bearbeiten Sie die Datei /etc/rsyslog.conf und fügen Sie die folgenden Zeilen hinzu:

$ModLoad imudp

$UDPServerRun 514

Speichern und schließen Sie die Datei rsyslog.conf. Starten Sie den Dienst rsyslog neu, um die Änderung anzuwenden:

sudo service rsyslog restart

Lösungsansätze, wenn HDX-Sitzungen nicht starten

Stellen Sie sicher, dass keine verwaisten Prozesse vorhanden sind, die möglicherweise den Start neuer Sitzungen verhindern:

sudo pkill -9 ctxhdx

sudo pkill -9 ctxgfx

sudo pkill -9 ctxlogin

sudo pkill -9 ctxvfb

Starten Sie die Linux VDA-Dienste neu und versuchen Sie, die Verbindung herzustellen.

Überprüfen von Besitz und Berechtigungen für Schlüsselverzeichnisse und Dateien

Überprüfen Sie den Dateibesitz und die Berechtigungen für die folgenden Verzeichnisse und Dateien:

  • /var - Owner: root, Group: root, Permissions: 0755
  • /var/xdl - Owner: ctxsrvr, Group: ctxadm, Permissions: 0755
  • /var/xdl/.isacagent - Owner: root, Group: root, Permissions: 0666
  • /var/xdl/.winsta - Owner: ctxsrvr, Group: ctxadm, Permissions: 0777
  • /var/xdl/vda - Owner: root, Group: root, Permissions: 0755

Audio ist nicht hörbar

Stellen Sie sicher, dass die Lautstärkesteuerung auf dem Gerät, auf dem Citrix Receiver ausgeführt wird, und dem Linux-Desktop nicht stummgeschaltet oder leise ist.

Stellen Sie sicher, dass Audio auf dem Linux VDA aktiviert ist. Verwenden Sie das Tool ctxreg, um den Wert des Konfigurationselements fDisableCam abzufragen:

sudo ctxreg read -k "HKLM\System\CurrentControlSet\Control\Citrix\WinStations\tcp" -v fDisableCam

Der Wert 0x1 bedeutet, dass Audio deaktiviert ist. Sie aktivieren Audio, indem Sie fDisableCam auf 0x0 festlegen:

sudo ctxreg update -k "HKLM\System\CurrentControlSet\Control\Citrix\WinStations\tcp" -v fDisableCam  -d 0x00000000

Wenn Audio immer noch nicht hörbar ist, prüfen Sie, ob die Citrix Audiosenke von Pulseaudio geladen wird. Das PulseAudio-Modul wird zu Beginn der Sitzung in den Pulseaudio-Daemon geladen. Überprüfen Sie mit dem Tool pacmd, ob die Citrix Audiosenke geladen ist:

pacmd list-sinks

Wenn die Citrix Audiosenke geladen ist, wird Folgendes ausgegeben:

name:

driver:

Wenn die Citrix Audiosenke nicht geladen ist, beenden Sie den ctxaudio-Prozess und starten Sie ihn neu.

Audio wird nicht aufgezeichnet

Stellen Sie sicher, dass Audio auf dem Linux VDA und Audioaufzeichnung auf dem ICA-Client aktiviert sind. Wenn immer noch kein Audio aufgezeichnet wird, prüfen Sie, ob die Citrix Audioquelle von Pulseaudio geladen wird. Wenn Audioaufzeichnung auf dem ICA-Client aktiviert ist, wird das PulseAudio-Modul beim Sitzungsstart in den Pulseaudio-Daemon geladen. Überprüfen Sie mit dem Tool pacmd, ob die Citrix Audioquelle geladen ist:

pacmd list-sources

Wenn die Citrix Audioquelle geladen ist, wird Folgendes ausgegeben:

name:

driver:

Wenn die Citrix Audioquelle nicht geladen ist, beenden Sie den ctxaudio-Prozess und starten Sie ihn neu.

Fehler beim Drucken

Sie können verschiedene Elemente überprüfen, wenn der Druckvorgang nicht richtig funktioniert. Der Druck-Daemon ist ein pro Sitzung ausgeführter Vorgang und sollte während der Dauer der Sitzung ausgeführt werden. Prüfen Sie, ob der Druck-Daemon ausgeführt wird.

ps –ef | grep ctxlpmngt

Wenn der ctxlpmngt-Vorgang nicht ausgeführt wird, starten Sie ctxlpmngt manuell über eine Befehlszeile.

Wenn das Drucken immer noch nicht funktioniert, überprüfen Sie als nächstes das CUPS-Framework. Der ctxcups-Dienst ist für die Druckerverwaltung und kommuniziert mit dem Linux CUPS-Framework. Dies ist ein Prozess pro Maschine und kann mit folgendem Befehl überprüft werden:

service ctxcups status

Wenn der Dienst nicht ausgeführt wird, starten Sie ihn manuell:

service ctxcups start

Druckausgabe ist fehlerhaft

Eine fehlerhafte Ausgabe kann durch einen nicht kompatiblen Druckertreiber verursacht werden. Pro Benutzer ist eine Treiberkonfiguration verfügbar und kann durch das Bearbeiten der Konfigurationsdatei ~/.CtxlpProfile konfiguriert werden.

[DEFAULT_PRINTER]

printername=

model=

ppdpath=

drivertype=

Das Feld printername enthält den Namen des aktuellen Clientstandarddruckers. Dieser Wert ist schreibgeschützt und darf nicht bearbeitet werden.

Important

Nehmen Sie nicht gleichzeitig Eingaben in die Felder ppdpath, model und drivertype vor, da nur eines für den zugeordneten Drucker wirksam ist.

Wenn der universelle Druckertreiber mit dem Clientdrucker nicht kompatibel ist, kann das Modell des nativen Druckertreibers mit der Option model= konfiguriert werden. Der aktuelle Modellname des Druckers kann mit dem Befehl lpinfo gefunden werden.

lpinfo –m

xerox/ph3115.ppd.gz Xerox Phaser 3115, SpliX V. 2.0.0

xerox/ph3115fr.ppd.gz Xerox Phaser 3115, SpliX V. 2.0.0

xerox/ph3115pt.ppd.gz Xerox Phaser 3115, SpliX V. 2.0.0

Das Modell kann dann passend für den Drucker festgelegt werden:

Model=xerox/ph3115.ppd.gz

Wenn der universelle Druckertreiber nicht mit dem Clientdrucker kompatibel ist, kann der ppd-Dateipfad für den nativen Druckertreiber konfiguriert werden. Der ppdpath-Wert ist der absolute Pfad der nativen Druckertreiberdatei.

Beispielsweise ist ein ppd-Treiber unter /home/tester/NATIVE_PRINTER_DRIVER.ppd vorhanden.

ppdpath=/home/tester/NATIVE_PRINTER_DRIVER.ppd

Citrix bietet drei universelle Druckertreibertypen: postscript, pcl5 und pcl6. Diese können als Treibertyp konfiguriert werden, wenn kein nativer Druckertreiber verfügbar ist.

Beispiel: Der Standarddruckertreibertyp des Client ist PCL5.

drivertype=pcl5

Hinweis

Citrix Receiver für Mac und Citrix Receiver für Linux unterstützen nur PostScript-Drucker, daher sind die universellen Druckertreiber PCL5 und PCL6 nicht relevant. In dieser Situation muss ppdpath oder das Modell des nativen Druckertreibers auf einen Nicht-PostScript-Drucker festgelegt werden.

CDM funktioniert nicht

Das CDM-Feature enthält einen Daemonprozess (ctxcdmd). Wenn beim CDM-Feature ein Fehler auftritt, starten Sie die Linux VDA-Maschine neu und überprüfen Sie, ob der Daemon richtig gestartet wurde:

Ps -lef | grep ctxcdmd

Die Dateibenennung im zugeordneten Laufwerk sollte den Benennungsregeln für VDA und Receiver entsprechen. 

Bekannte Probleme

Zustand der Feststelltaste in Citrix Receiver für Android kann beim Sitzungsroaming umgekehrt werden

Der Zustand der Feststelltaste kann aufgehoben werden, wenn über eine vorhandene Verbindung Roaming zu Citrix Receiver für Android erfolgt. Verwenden Sie als Workaround die Umschalttaste auf der erweiterten Tastatur, um zwischen Groß- und Kleinbuchstaben zu wechseln.

Tastenkombinationen mit der Alt-Taste funktionieren nicht immer, wenn Sie mit Citrix Receiver für Mac eine Verbindung zu einem Linux VDA herstellen

Citrix Receiver für Mac sendet standardmäßig für die linke und die rechte Alt-Taste den Befehl "Alt Gr". Sie können dies in den Citrix Receiver-Einstellungen ändern, die Ergebnisse sind jedoch je nach Anwendung unterschiedlich.

Neuere X-Clientbibliotheken können Tastaturprobleme unter SuSE Linux Enterprise Desktop 11 verursachen

Neuere Versionen der xorg-x11-libX11-Pakete unter SuSE Linux Enterprise Desktop 11 haben u. U. Probleme beim Ändern der Tastaturzuordnung, was zu Problemen bei der Tastaturfunktionalität in einer HDX-Sitzung führen kann. Diese Situation kann auftreten, wenn die installierte Version der Pakete im Bereich 7.4-5.11.11.1 bis 7.4-5.11.15.1 liegt.

Führen Sie als Workaround ein Rollback auf die SP3-Version des xorg-x11-libX11-Pakets durch. Änderungen der Tastaturzuordnung funktionieren dann normal. Beispiel:

rpm -i --force xorg-x11-libX11-7.4-5.9.1

rpm –i --force xorg-x11-libX11-32bit-7.4-5.9.1

rpm -e xorg-x11-libX11-7.4-5.11.15.1

rpm -e xorg-x11-libX11-32bit-7.4-5.11.15.1

Führen Sie das Rollback aus, bevor ein Benutzer sich an der Maschine anmeldet. Wenn dies während einer aktiven Sitzung erfolgt, werden die Einstellungen nicht wirksam, bis der Benutzer sich das nächste Mal anmeldet.

Wenn Sie ein Upgrade von SP3 ausführen, können die oben angegebenen xorg-x11-libX11-Pakete mit der aktuell installierten Version verknüpft werden, sodass sie während des Upgrades nicht geändert werden. Führen Sie vor dem Upgrade folgende Prozesse aus und fahren Sie dann normal mit dem Upgrade fort:

zypper al xorg-x11-libX11

zypper al xorg-x11-libX11-32bit

Beim Verwenden von Linux VDA mit einem Delivery Controller von XenDesktop-Version 7.1 können Sitzungsstarts lange dauern

Der langsame Start wird durch CGP-Einstellungen in der ICA-Datei verursacht, die vom XD 7.1 Delivery Controller erstellt wurde. Wenn diese Einstellungen vorhanden sind, versucht Citrix Receiver, eine Verbindung über TCP-Port 2598 herzustellen. Entsprechend den Standardfirewalleinstellungen auf einigen Linux-Distributionen, z. B. SLED 12, werden die TCP SYN-Pakete abgelegt, was zu einem Timeout und dem langen Sitzungsstart führt. Konfigurieren Sie als Workaround die Firewall auf dem Linux VDA so, dass das TCP SYN-Paket am Port 2598 abgelehnt wird. Dieses Problem wurde in neueren Versionen des Delivery Controllers behoben.

Fehlschlagen der Registrierung, wenn der Linux VDA der Domäne wieder hinzugefügt wird

Wenn ein Linux VDA der Domäne wieder hinzugefügt und ein neuer Satz Kerberos-Schlüssel generiert wird, kann der Broker unter bestimmten Umständen keinen Sicherheitskontext mit dem VDA herstellen. Oft ist der Grund, dass der Broker ein veraltetes zwischengespeichertes VDA-Dienstticket verwendet, das auf dem vorherigen Kerberos-Schlüsselsatz basiert. Der VDA kann zwar eine Verbindung mit dem Broker herstellen, jedoch kann der Broker keinen Sicherheitskontext zum VDA herstellen. Normalerweise schlägt die VDA-Registrierung dann fehl.

Dieses Problem löst sich irgendwann von selber, wenn das VDA-Dienstticket abläuft und erneuert wird, jedoch haben Diensttickets oft eine lange Lebensdauer. Dies kann möglicherweise viel zu lange dauern.

Sie lösen das Problem, indem Sie den Ticketcache des Brokers leeren. Starten Sie den Broker neu oder führen Sie als Administrator auf dem Broker folgenden Befehl an einer Eingabeaufforderung aus:

klist -li 0x3e4 purge

Damit werden alle Diensttickets im LSA-Cache des Netzwerkdienstprinzipals gelöscht, unter dem der Citrix Brokerdienst ausgeführt wird. Es werden jedoch auch Diensttickets für andere VDAs und möglicherweise andere Dienste entfernt. Dies ist aber kein Problem, die Diensttickets werden bei Bedarf einfach erneut vom KDC geladen.

Plug-n-Play von Audio wird nicht unterstützt

Audioaufnahmegeräte sollten mit der Clientmaschine verbunden sein, bevor Sie mit dem Aufzeichnen von Audio in der ICA-Sitzung beginnen. Wenn ein Gerät angeschlossen wird, nachdem die Audioaufzeichnungsanwendung gestartet wurde, reagiert die Anwendung u. U. nicht mehr. Wenn dieses Problem auftritt, starten Sie die Anwendung neu. Ein ähnliches Problem kann auftreten, wenn Sie ein Aufzeichnungsgerät während der Aufzeichnung entfernen.

Audiostörungen

Bei Windows 10 Receiver können während der Aufzeichnung Audiostörungen auftreten.

CTXPS-Treiber ist mit einigen PLC-Druckern nicht kompatibel

Wenn Sie Druckausgabestörungen bemerken, legen Sie als Druckertreiber den nativen Druckertreiber des Herstellers fest.

Langsame Druckleistung bei großen Dokumenten

Wenn Sie ein großes Dokument auf einem lokalen Clientdrucker drucken, wird die zu druckende Datei über die Serververbindung übertragen. Bei langsamen Verbindungen kann dies sehr lange dauern.

Drucker- und Druckauftragsbenachrichtigungen aus anderen Sitzungen werden angezeigt

Linux hat nicht das gleiche Sitzungskonzept wie das Windows-Betriebssystem. Daher erhalten alle Benutzer systemweite Benachrichtigungen. Durch Ändern der CUPS-Konfigurationsdatei /etc/cups/cupsd.conf kann der Administrator diese Benachrichtigungen deaktivieren.

Suchen Sie den aktuellen, in der Datei konfigurierten Richtliniennamen:

DefaultPolicy default

Wenn der Richtlinienname "default ist, fügen Sie die folgenden Zeilen im XML-Block der Standardrichtlinie hinzu.

# Job/subscription privacy...

JobPrivateAccess default

JobPrivateValues default

SubscriptionPrivateAccess default

SubscriptionPrivateValues default

… …

Require user @OWNER

Order deny,allow

 

Order deny,allow

Glossar

Broker: XenDesktop-Komponente, die für die Vermittlung von HDX-Sitzungen auf den verschiedenen VDAs in einer XenDesktop-Bereitstellung verantwortlich ist. Er wird auch als DDC oder XenDesktop Controller bezeichnet.

Broker Agent: Komponente auf der Linux VDA-Maschine, die den Desktop bereitstellt. Der Broker Agent kommuniziert mit dem Broker und ermöglicht die Vermittlung von Sitzungen. Er besteht aus zwei Hauptkomponenten: dem VDA-Dienst und dem HDX-Dienst.

Citrix Director: Citrix Helpdesk-/Supportkonsole zum Überwachen und Steuern von XenDesktop-VDAs.

Citrix Studio: Citrix Verwaltungskonsole zum Konfigurieren von XenDesktop.

DDC: XenDesktop Desktop Delivery Controller. Wird auch als Broker oder Delivery Controller bezeichnet.

FQDN: Vollqualifizierter Domänenname (Fully Qualified Domain Name)

HDX: High Definition Experience-Protokoll. Wurde früher als Citrix ICA-Protokoll bezeichnet.

HDX-Dienst: Der Linux-Dienst (ctxhdx), der mit dem HDX-Protokoll eine Remoteverbindung zum virtuellen Linux-Desktop herstellt. Er kommuniziert mit dem VDA-Dienst zum Vermitteln von Sitzungen.

RHEL: Red Hat Enterprise Linux. Eine kommerzielle Linux-Distribution von Red Hat.

SLED: SUSE Linux Enterprise Desktop. Eine kommerzielle Linux-Distribution von Novell.

SLES: SUSE Linux Enterprise Server. Eine kommerzielle Linux-Distribution von Novell.

VDA: Virtual Delivery Agent.

VDA-Dienst: Der Linux-Dienst (ctxvda), der mit dem Broker kommuniziert, um das Vermitteln von Sitzungen zu ermöglichen. Zudem kommuniziert er mit dem HDX-Dienst für die Bereitstellung von Remotesitzungen.