Product Documentation

Installieren von VDAs unter Red Hat Linux

Jul 08, 2016

Sie können virtuelle Linux-Desktops auf der Basis einer Red Hat/CentOS-Distribution erstellen. Bereiten Sie die Linux-VMs vor, installieren Sie die neue 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 Dokument verwendeten 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.

Tipp

CentOS Linux wird ab Version 1.3 unterstützt. Die Installationsinformationen in diesem Artikel gelten auch für CentOS.

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.

HDX 3D Pro

Die folgenden Hypervisors, Linux-Distributionen und NVIDIA GRID™ GPU sind für die Unterstützung von HDX 3D Pro erforderlich.

Hypervisors

Die folgenden Hypervisors werden unterstützt:

  • XenServer
  • VMware ESX und ESXi

Linux-Distributionen

Die folgende Linux-Distribution unterstützt HDX 3D Pro:

  • Red Hat Enterprise Linux - Workstation 7.2

Grafikprozessor

Die folgenden GPUs werden unterstützt:

  • NVIDIA GRID™ 3.0 - Tesla M60
  • NVIDIA GRID™ - K2

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 gibt es das PowerShell-Skript Update-BrokerServiceConfig.ps1, 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 der Linux-Maschine für die VDA-Installation

Überprüfen der Netzwerkkonfiguration

Citrix empfiehlt, dass Netzwerk zu verbinden und richtig zu konfigurieren, bevor Sie fortfahren.

Nur für RHEL 6: Festlegen des Hostnamens

Damit der Hostname der Maschine richtig gemeldet wird, ändern Sie die Datei /etc/sysconfig/network, sodass sie nur den Hostnamen der Maschine enthält.

HOSTNAME=hostname

Nur für RHEL 7: Festlegen des Hostnamens

Damit der Hostname der Maschine richtig gemeldet wird, ändern Sie die Datei /etc/hostname, sodass sie nur den Hostnamen der Maschine enthält.

Zuweisen einer Loopbackadresse für den Hostnamen

Damit der DNS-Domänenname und der vollqualifizierte Domänenname (FQDN) der Maschine richtig gemeldet werden, ändern Sie die folgende Zeile in der Datei /etc/hosts, sodass der FQDN und der Hostname die ersten zwei Einträge sind:

127.0.0.1  hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4

Beispiel:

127.0.0.1  vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4

Entfernen Sie alle anderen Verweise auf hostname-fqdn oder hostname aus anderen Einträge in der Datei.

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.

Ü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 der Uhrsynchronisierung (NTP)

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 Zeitdienst synchronisiert werden.

RHEL 6.x und frühere Releases verwenden den NTP-Daemon (ntpd) zum Synchronisieren der Uhr, während in einer RHEL 7.x-Standardumgebung der neuere Chrony-Daemon (chronyd) verwendet wird. Die Konfiguration und Betriebsprozesse zwischen den beiden Diensten sind ähnlich.

Nur für RHEL 6: Konfigurieren des NTP-Diensts

Bearbeiten Sie als Root-Benutzer die Datei /etc/ntp.conf und fügen Sie pro Remote-Zeitserver einen Servereintrag hinzu:

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst

In einer typischen Bereitstellung sollte die Zeit von den lokalen Domänencontrollern synchronisiert werden und nicht direkt von öffentlichen NTP-Poolservern. Fügen Sie pro Active Directory-Domänencontroller in der Domäne einen Servereintrag hinzu.

Entfernen Sie alle anderen Servereinträge, einschließlich Einträge für Loopback-IP-Adressen, Localhost und öffentliche Server wie *.pool.ntp.org.

Speichern Sie die Änderungen und starten Sie den NTP-Daemon neu:

sudo /sbin/service ntpd restart

Nur für RHEL 7: Chrony-Dienst

Bearbeiten Sie als Root-Benutzer die Datei /etc/chrony.conf und fügen Sie pro Remote-Zeitserver einen Servereintrag hinzu:

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst

In einer typischen Bereitstellung sollte die Zeit von den lokalen Domänencontrollern synchronisiert werden und nicht direkt von öffentlichen NTP-Poolservern. Fügen Sie pro Active Directory-Domänencontroller in der Domäne einen Servereintrag hinzu.

Entfernen Sie alle anderen Servereinträge, einschließlich Einträge für Loopback-IP-Adressen, Localhost und öffentliche Server wie *.pool.ntp.org.

Speichern Sie die Änderungen und starten Sie den Chrony-Daemon neu:

sudo /sbin/service chronyd restart

Deaktivieren der Popupmeldung zur Netzwerkproxyauthentifizierung

In RHEL 6 wird Benutzern aufgrund eines bestimmten Problems nach dem Anmelden ein Popupfenster mit der Aufforderung zur Eingabe des Root-Kennworts angezeigt.

Sie lösen das Problem, indem Sie mit Root-Berechtigungen die Datei /etc/polkit-1/localauthority/30-site.d/20-no-show-proxy-dialog.pkla in einem Texteditor erstellen und den folgenden Inhalt hinzufügen:

[No Show Proxy Dialog]

Identity=unix-user:*

Action=org.freedesktop.packagekit.system-network-proxy-configure

ResultAny=no

ResultInactive=no

ResultActive=no

Tipp

Weitere Informationen zu diesem Problem finden Sie auf der auf der RedHat Lösungsseite. Der Workaround ist in den Kommentaren beschrieben.

Installieren von OpenJDK

Der Linux VDA ist von OpenJDK abhängig. Die Laufzeitumgebung sollte als Teil der Betriebssysteminstallation installiert worden sein.

Nur für RHEL 6: OpenJDK 1,7

Bestätigen Sie die richtige Version mit folgendem Befehl:

sudo yum info java-1.7.0-openjdk

Das OpenJDK-Paket ist möglicherweise eine frühere Version. Aktualisieren Sie ggf. auf die aktuelle Version:

sudo yum -y update java-1.7.0-openjdk

Legen Sie die Umgebungsvariable JAVA_HOME fest, indem Sie der Datei ~/.bashrc folgende Zeile hinzufügen:

export JAVA_HOME=/usr/lib/jvm/java

Öffnen Sie eine neue Shell und prüfen Sie die Java-Version:

java –version

Nur für RHEL 7,0: OpenJDK 1,8

Bestätigen Sie die richtige Version mit folgendem Befehl:

sudo yum info java-1.8.0-openjdk

Das OpenJDK-Paket ist möglicherweise eine frühere Version. Aktualisieren Sie ggf. auf die aktuelle Version:

sudo yum -y update java-1.8.0-openjdk

Legen Sie die Umgebungsvariable JAVA_HOME fest, indem Sie der Datei ~/.bashrc folgende Zeile hinzufügen:

export JAVA_HOME=/usr/lib/jvm/java

Öffnen Sie eine neue Shell und prüfen Sie die Java-Version:

java –version

Tipp

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

Installieren von PostgreSQL

Der Linux VDA erfordert auf RHEL 6 PostgreSQL 8.4 oder höher und auf RHEL 7 PostgreSQL Versionen 9.2 oder höher.

Installieren Sie die folgenden Pakete:

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc

Anschließend ist der folgende Schritt erforderlich, um die Datenbank zu initialisieren und zu gewährleisten, dass der Dienst beim Booten startet. Mit dem Befehl werden unter /var/lib/pgsql/data Datenbankdateien erstellt. Der Befehl ist für PostgreSQL 8 und 9 unterschiedlich.

Nur für RHEL 6: PostgreSQL 8

sudo /sbin/service postgresql initdb

Nur für RHEL 7: PostgreSQL 9

sudo postgresql-setup initdb

Starten von PostgreSQL

Für beide Versionen von PostgreSQL müssen Sie den Dienst so konfigurieren, dass er beim Booten startet und auch sofort startet:

sudo /sbin/chkconfig postgresql on

sudo /sbin/service postgresql start

Überprüfen Sie die Version von PostgreSQL mit folgendem Befehl:

psql --version

Stellen Sie mit dem psql-Befehlszeilenprogramm sicher, dass das Datenverzeichnis festgelegt ist:

sudo -u postgres psql -c 'show data_directory'

Installieren von Motif

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

Nur für RHEL 6: Öffnen von Motif

sudo yum -y install openmotif

Nur für RHEL 7: Motif

sudo yum -y install motif

Installieren der Druckunterstützung

Der Linux VDA erfordert Cups- und Foomatic-Filter.

Nur für RHEL 6: Druckunterstützung

sudo yum –y install cups

sudo yum -y install foomatic

Nur für RHEL 7: Druckunterstützung

sudo yum –y install cups

sudo yum -y install foomatic-filters

Installieren weiterer Pakete

Installieren Sie die anderen erforderlichen Pakete:

sudo yum -y install redhat-lsb-core

sudo yum -y install ImageMagick

Vorbereiten der Linux-VM für 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 Integrationsdienste.
  3. Stellen Sie sicher, dass Zeitsynchronisierung 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 Feld 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

Installieren oder Aktualisieren der erforderlichen Pakete

Installieren oder aktualisieren Sie die erforderlichen Pakete:

sudo yum -y install samba-winbind \

samba-winbind-clients \

krb5-workstation \

authconfig \

oddjob-mkhomedir

Starten des Winbind-Daemon beim Booten

Der Winbind-Daemon muss zum Starten beim Booten konfiguriert werden:

sudo /sbin/chkconfig winbind on

Konfigurieren der Winbind-Authentifizierung

Konfigurieren Sie die Maschine für die Kerberos-Authentifizierung mit Winbind:

sudo authconfig \

--disablecache \

--disablesssd \

--disablesssdauth \

--enablewinbind \

--enablewinbindauth \

--disablewinbindoffline \

--smbsecurity=ads \

--smbworkgroup=domain \

--smbrealm=REALM \

--krb5realm=REALM \

--krb5kdc=fqdn-of-domain-controller \

--winbindtemplateshell=/bin/bash \

--enablemkhomedir --updateall

REALM ist der Kerberos-Bereichsname in Großbuchstaben und domain ist der kurze NetBIOS-Name der Active Directory-Domäne.

Wenn DNS-basierte Suchvorgänge nach dem KDC-Server und -Bereichsname erforderlich sind, fügen Sie dem oben aufgeführten Befehl die folgenden beiden Optionen hinzu:

--enablekrb5kdcdns --enablekrb5realmdns

Ignorieren Sie alle Fehler hinsichtlich des Winbind-Dienststarts, die vom Befehl authconfig zurückgegeben wurden. Diese sind darauf zurückzuführen, dass authconfig versucht, den Winbind-Dienst zu starten, bevor die Maschine mit einer Domäne verbunden wurde.

Öffnen Sie die Datei /etc/samba/smb.conf und fügen Sie im Abschnitt [Global] nach dem vom authconfig-Tool erstellten Abschnitt die folgenden Einträge hinzu.

kerberos method = secrets and keytab

winbind refresh tickets = true

Der Linux VDA benötigt die Systemdatei für die Schlüsseltabelle /etc/krb5.keytab, um sich am Delivery Controller zu authentifizieren und zu registrieren. Die Einstellung kerberos method zwingt Winbind zum Erstellen der Systemdatei für die Schlüsseltabelle, wenn die Maschine der Domäne beitritt.

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 Computern zur Domäne verfügen:

sudo net ads join REALM -U user

REALM ist der Kerberos-Bereichsname in Großbuchstaben und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.

Konfigurieren von PAM für Winbind

Standardmäßig wird bei der Konfiguration des Winbind PAM-Moduls (pam_winbind) nicht das Zwischenspeichern von Kerberos-Tickets und das Erstellen von Basisverzeichnissen aktiviert. Öffnen Sie die Datei /etc/security/pam_winbind.conf und ändern Sie die folgenden Einträge im Abschnitt [Global] oder fügen Sie sie hinzu:

krb5_auth = yes

krb5_ccache_type = FILE

mkhomedir = yes

Entfernen Sie ggf. den Einstellungen vorangehende Semikolons. Diese Änderungen erfordern den Neustart des Winbind-Daemon:

sudo /sbin/service winbind restart

Tipp

Der Winbind-Daemon wird nur weiterhin ausgeführt, wenn die Maschine zu einer Domäne gehört.

Öffnen Sie die Datei /etc/krb5.conf und ändern Sie im Abschnitt [libdefaults] die folgende Einstellung von KEYRING in FILE:

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 Samba-Befehl net ads 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 Tool wbinfo, 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

Workaround bei SELinux-Richtlinienerzwingung

In der RHEL-Standardumgebung wird SELinux vollständig erzwungen. Das beeinträchtigt die von Quest verwendeten IPC-Methoden der Unix-Domänensockets und verhindert, dass Domänenbenutzer sich anmelden.

Tipp

Hier finden Sie einige Workarounds.

Am einfachsten ist es, SELinux zu deaktivieren. Bearbeiten Sie als Root-Benutzer die Datei /etc/selinux/config und ändern Sie die SELinux-Einstellung:

SELINUX=disabled

Diese Änderung erfordert einen Neustart:

reboot

Important

Seien Sie vorsichtig beim Verwenden dieser Einstellung. Das erneute Aktivieren der SELinux-Richtlinienerzwingung nach ihrer Deaktivierung kann selbst für den Root-Benutzer und anderen lokale Benutzer zu einer vollständigen Sperrung führen.

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 Ticketgültigkeitsdauer 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

Installieren von NVIDIA GRID-Treibern

Zum Aktivieren von HDX 3D Pro sind weitere Installationsschritte erforderlich, um die erforderlichen Grafiktreiber auf dem Hypervisor und auf den VDA-Maschinen zu installieren.

Konfigurieren Sie Folgendes:

  1. Citrix XenServer
  2. VMware ESX

Folgen Sie den Anweisungen für den von Ihnen gewählten Hypervisor.

Citrix XenServer

In diesem Abschnitt wird die Installation und Konfiguration von NVIDIA GRID-Treibern auf Citrix XenServer detailliert beschrieben.

VMware ESX

Installieren und konfigurieren Sie die NVIDIA GRID-Treiber für VMware ESX entsprechend den Informationen in diesem Dokument.

VDA-Maschinen

Führen Sie die folgenden Schritte aus, um die Treiber für die Linux-VM-Gäste zu installieren und zu konfigurieren:

  1. Stellen Sie zu Beginn sicher, dass die Linux-VM heruntergefahren ist.
  2. Fügen Sie in XenCenter der VM eine GPU im GPU-Passthrough-Modus hinzu.
  3. Starten Sie die RHEL-VM.

Zum Vorbereiten der Maschine für die NVIDIA GRID-Treiber sind die folgenden Schritte erforderlich:

# yum install gcc

# yum install "kernel-devel-uname-r == $(uname -r)"

# systemctl set-default multi-user.target

Wenn Sie diese Schritte ausgeführt haben, folgen Sie den Anleitungen im Red Hat Enterprise Linux-Dokument zum Installieren des NVIDIA GRID-Treibers.

Hinweis

Wählen Sie während der GPU-Treiberinstallation für jede Frage den Standardwert ("no").

Important

Wenn GPU-Passthrough aktiviert wurde, ist über XenCenter kein Zugriff auf die Linux-VM mehr möglich, daher müssen Sie SSH zum Herstellen einer Verbindung verwenden.

Überprüfen Sie, ob der NVIDIA GRID™-Grafiktreiber richtig installiert ist, indem Sie "nvidia-smi" ausführen. Das Ergebnis sollte ungefähr wie folgt aussehen:

localized image

Legen Sie die richtige Konfiguration für die Karte fest:

etc/X11/ctx-nvidia.sh

Um die hohen Auflösungen und Multimonitorfunktionen nutzen zu können, benötigen Sie eine gültige NVIDIA-Lizenz. Anleitungen zum Anwenden der Lizenz finden Sie in der Produktdokumentation in "GRID Licensing Guide.pdf - DU-07757-001 September 2015".

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

Für RHEL 6.0, empfiehlt Citrix, dass Sie die Xorg-x11-server-Xorg-Version 1.15 behalten und dieses Paket nicht aktualisieren.

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

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

Für RHEL 7.2:

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

Aktualisieren des Linux VDA

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

Für RHEL 6:

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

Für RHEL 7.2:

sudo rpm -U XenDesktopVDA-1.3.312-1.el7.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.

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 /opt/Citrix/VDA/sbin/ctxcleanup.sh --help

Entfernen von Konfigurationsänderungen:

sudo /opt/Citrix/VDA/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

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 für alle 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 in Syslog 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:

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, damit die Änderungen wirksam werden:

sudo /sbin/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

HDX 3D Pro - Probleme bei der Darstellungsaktualisierung bei mehreren Monitoren

Wenn beim Verwenden mehrerer Monitore Probleme bei der Darstellungsaktualisierung auf den sekundären Monitoren auftreten, prüfen Sie, ob die NVIDIA GRID-Lizenz verfügbar ist.

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

Zusätzliches Protokoll für CUPS

Als Komponente des Linux-VDA ist die Methode zum Abrufen des Protokolls einer Druckkomponente anderen Komponenten ähnlich.

Bei Red Hat sind einige zusätzliche Schritte erforderlich, um die CUPS-Dienstdatei zu konfigurieren. Andernfalls werden einige Protokolle nicht in hdx.log protokolliert.

sudo service cups stop

sudo vi /etc/systemd/system/printer.target.wants/cups.service

PrivateTmp=false

sudo service cups start

sudo systemctl daemon-reload

Das vollständige Druckprotokoll sollte mit dieser Konfiguration nur bei einem Problem abgerufen werden. Normalerweise wird diese Konfiguration nicht empfohlen, da sie die CUPS-Sicherheit verletzt.

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 Tastaturzuordnungsprobleme 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. Dabei kann es sich um Stunden handeln.

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.

Bei der Verwendung von HDX 3D Pro mit GNOME fehlt das Symbol zum Sperren des Bildschirms

Wenn die NVIDIA Grid-Treiber aktiv sind, ist der Gnome Desktop Manager (GDM) nicht aktiv und die GDM-Funktion zum Sperren des Bildschirms ist nicht verfügbar.

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.