Linux Virtual Delivery Agent

Linux VDA manuell auf Amazon Linux 2, CentOS, RHEL und Rocky Linux installieren

May 6, 2026

Beitrag von:

C C

Wichtig:

Für Neuinstallationen empfehlen wir die Verwendung von Easy Install für eine schnelle Installation. Easy Install spart Zeit und Arbeitsaufwand und ist weniger fehleranfällig als die in diesem Artikel beschriebene manuelle Installation.

Schritt 1: Konfigurationsinformationen und Linux-Maschine vorbereiten

Schritt 1a: Netzwerkkonfiguration überprüfen

Stellen Sie sicher, dass das Netzwerk verbunden und korrekt konfiguriert ist. Sie müssen beispielsweise den DNS-Server auf dem Linux VDA konfigurieren.

Schritt 1b: Hostnamen festlegen

Um sicherzustellen, dass der Hostname der Maschine korrekt gemeldet wird, ändern Sie die Datei /etc/hostname so, dass sie nur den Hostnamen der Maschine enthält.

hostname

Schritt 1c: Loopback-Adresse dem Hostnamen zuweisen

Um sicherzustellen, dass der DNS-Domänenname und der vollqualifizierte Domänenname (FQDN) der Maschine korrekt gemeldet werden, ändern Sie die folgende Zeile der Datei /etc/hosts so, dass sie den FQDN und den Hostnamen als erste zwei Einträge enthält:

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

Zum Beispiel: 1.0

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ägen in der Datei.

Hinweis:

Der Linux VDA unterstützt derzeit keine NetBIOS-Namenskürzung. Der Hostname darf 15 Zeichen nicht überschreiten.

Tipp:

Verwenden Sie nur die Zeichen a–z, A–Z, 0–9 und Bindestrich (-). Vermeiden Sie Unterstriche (_), Leerzeichen und andere Symbole. Beginnen Sie einen Hostnamen nicht mit einer Zahl und beenden Sie ihn nicht mit einem Bindestrich. Diese Regel gilt auch für Delivery Controller-Hostnamen.

Schritt 1d: Hostnamen überprüfen

Überprüfen Sie, ob der Hostname korrekt festgelegt ist:

hostname
<!--NeedCopy-->

Dieser Befehl gibt nur den Hostnamen der Maschine zurück und nicht ihren vollqualifizierten Domänennamen (FQDN).

Überprüfen Sie, ob der FQDN korrekt festgelegt ist:

hostname -f
<!--NeedCopy-->

Dieser Befehl gibt den FQDN der Maschine zurück.

Schritt 1e: Namensauflösung und Dienstverfügbarkeit überprüfen

Überprüfen Sie, ob Sie den FQDN auflösen und den Domänencontroller und Delivery Controller™ anpingen können:

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn
<!--NeedCopy-->

Wenn Sie den FQDN nicht auflösen oder eine dieser Maschinen nicht anpingen können, überprüfen Sie die Schritte, bevor Sie fortfahren.

Schritt 1f: Zeitsynchronisation konfigurieren

Die Aufrechterhaltung einer genauen Zeitsynchronisation zwischen den VDAs, Delivery Controllern und Domänencontrollern ist entscheidend. Das Hosten des Linux VDA als virtuelle Maschine (VM) kann zu Problemen mit der Zeitverschiebung führen. Aus diesem Grund wird die Synchronisation der Zeit mit einem externen Zeitdienst bevorzugt.

Eine RHEL-Standardumgebung verwendet den Chrony-Daemon (chronyd) zur Zeitsynchronisation.

Chrony-Dienst konfigurieren

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

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst
<!--NeedCopy-->

In einer typischen Bereitstellung synchronisieren Sie die Zeit von den lokalen Domänencontrollern und nicht direkt von öffentlichen NTP-Pool-Servern. Fügen Sie einen Servereintrag für jeden Active Directory-Domänencontroller in der Domäne hinzu.

Entfernen Sie alle anderen aufgelisteten Servereinträge, einschließlich Loopback-IP-Adresse, Localhost und öffentliche Server-Einträge *.pool.ntp.org.

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

-  sudo systemctl restart chronyd
<!--NeedCopy-->

Schritt 1g: PulseAudio installieren (Nur für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0)

Führen Sie den folgenden Befehl aus, um pulseaudio zu installieren:

sudo yum -y install pulseaudio --allowerasing
<!--NeedCopy-->

Öffnen Sie /etc/pulse/client.conf und fügen Sie den folgenden Eintrag hinzu:

autospawn = yes
<!--NeedCopy-->

Schritt 1h: OpenJDK 11 installieren

Der Linux VDA erfordert die Anwesenheit von OpenJDK 11.

Wenn Sie CentOS oder RHEL verwenden, wird OpenJDK 11 automatisch als Abhängigkeit installiert, wenn Sie den Linux VDA installieren.
Wenn Sie Amazon Linux 2 oder Rocky Linux verwenden, führen Sie den folgenden Befehl aus, um OpenJDK 11 zu aktivieren und zu installieren:
```
 amazon-linux-extras install java-openjdk11
 
```

Bestätigen Sie die korrekte Version:

sudo yum info java-11-openjdk
<!--NeedCopy-->

Das vorinstallierte OpenJDK könnte eine frühere Version sein. Aktualisieren Sie auf OpenJDK 11:

sudo yum -y update java-11-openjdk
<!--NeedCopy-->

Schritt 1i: Eine zu verwendende Datenbank installieren und angeben

Hinweis:

Wir empfehlen die Verwendung von SQLite nur für den VDI-Modus und PostgreSQL für ein Bereitstellungsmodell mit gehosteten Shared Desktops.

Für Easy Install und MCS können Sie SQLite oder PostgreSQL verwenden, ohne sie manuell installieren zu müssen. Sofern nicht anders über /etc/xdl/db.conf angegeben, verwendet der Linux VDA standardmäßig PostgreSQL.

Für manuelle Installationen müssen Sie SQLite, PostgreSQL oder beides manuell installieren. Wenn Sie sowohl SQLite als auch PostgreSQL installieren, können Sie eine davon zur Verwendung angeben, indem Sie /etc/xdl/db.conf nach der Installation des Linux VDA-Pakets bearbeiten.

Dieser Abschnitt beschreibt, wie PostgreSQL und SQLite installiert und wie eine davon zur Verwendung angegeben wird.

PostgreSQL installieren

Der Linux VDA erfordert PostgreSQL:

PostgreSQL 9 für Amazon Linux 2, RHEL 7 und CentOS 7
PostgreSQL 10 für RHEL 8.x und Rocky Linux 8.x
PostgreSQL 13 für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0

Führen Sie die folgenden Befehle aus, um PostgreSQL zu installieren:

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc
<!--NeedCopy-->

Für RHEL 8.x und RHEL 9.2/9.0 führen Sie den folgenden Befehl aus, um libpq für PostgreSQL zu installieren:

sudo yum -y install libpq
<!--NeedCopy-->

Führen Sie den folgenden Befehl aus, um die Datenbank zu initialisieren. Diese Aktion erstellt Datenbankdateien unter /var/lib/pgsql/data.

sudo postgresql-setup initdb
<!--NeedCopy-->

Führen Sie die folgenden Befehle aus, um PostgreSQL beim Maschinenstart bzw. sofort zu starten:

sudo systemctl enable postgresql

-  sudo systemctl start postgresql
<!--NeedCopy-->

Überprüfen Sie die PostgreSQL-Version mit:

psql --version
<!--NeedCopy-->

(Nur für RHEL 7 und Amazon Linux 2) Überprüfen Sie, ob das Datenverzeichnis mit dem Befehlszeilendienstprogramm psql festgelegt ist:

sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->

SQLite installieren

Führen Sie den folgenden Befehl aus, um SQLite zu installieren:

sudo yum -y install sqlite
<!--NeedCopy-->

Eine zu verwendende Datenbank angeben

Wenn Sie sowohl SQLite als auch PostgreSQL installieren, können Sie eine davon zur Verwendung festlegen, indem Sie /etc/xdl/db.conf nach der Installation des Linux VDA-Pakets bearbeiten.

Führen Sie /opt/Citrix/VDA/sbin/ctxcleanup.sh aus. Überspringen Sie diesen Schritt, wenn es sich um eine Neuinstallation handelt.
Bearbeiten Sie /etc/xdl/db.conf, um eine zu verwendende Datenbank anzugeben.
Führen Sie ctxsetup.sh aus.

Hinweis:

Sie können /etc/xdl/db.conf auch verwenden, um die Portnummer für PostgreSQL zu konfigurieren.

Schritt 2: Den Hypervisor vorbereiten

Einige Änderungen sind erforderlich, wenn der Linux VDA als VM auf einem unterstützten Hypervisor ausgeführt wird. Nehmen Sie die folgenden Änderungen basierend auf der verwendeten Hypervisor-Plattform vor. Es sind keine Änderungen erforderlich, wenn Sie die Linux-Maschine auf Bare-Metal-Hardware ausführen.

Zeitsynchronisierung auf XenServer (ehemals Citrix Hypervisor™) beheben

Wenn die XenServer® Zeitsynchronisierungsfunktion aktiviert ist, treten in jeder paravirtualisierten Linux-VM Probleme mit NTP und XenServer auf. Beide versuchen, die Systemuhr zu verwalten. Um zu vermeiden, dass die Uhr mit anderen Servern asynchron wird, stellen Sie sicher, dass die Systemuhr in jedem Linux-Gast mit NTP synchronisiert ist. In diesem Fall muss die Host-Zeitsynchronisierung deaktiviert werden. Im HVM-Modus sind keine Änderungen erforderlich.

Wenn Sie einen paravirtualisierten Linux-Kernel mit installierten XenServer VM Tools ausführen, können Sie innerhalb der Linux-VM überprüfen, ob die XenServer Zeitsynchronisierungsfunktion vorhanden und aktiviert ist:

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Dieser Befehl gibt 0 oder 1 zurück:

0 - Die Zeitsynchronisierungsfunktion ist aktiviert und muss deaktiviert werden.
1 - Die Zeitsynchronisierungsfunktion ist deaktiviert, und es sind keine weiteren Maßnahmen erforderlich.

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

Falls aktiviert, deaktivieren Sie die Zeitsynchronisierungsfunktion, indem Sie 1 in die Datei schreiben:

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

Um diese Änderung dauerhaft und nach einem Neustart persistent zu machen, bearbeiten Sie die Datei /etc/sysctl.conf und fügen Sie die Zeile hinzu:

xen.independent_wallclock = 1

Um diese Änderungen zu überprüfen, starten Sie das System neu:

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Dieser Befehl gibt den Wert 1 zurück.

Zeitsynchronisierung auf Microsoft Hyper-V beheben

Die Linux-VMs mit installierten Hyper-V Linux Integration Services können die Hyper-V Zeitsynchronisierungsfunktion anwenden, um die Zeit des Host-Betriebssystems zu verwenden. Um sicherzustellen, dass die Systemuhr genau bleibt, müssen Sie diese Funktion zusammen mit den NTP-Diensten aktivieren.

Vom Verwaltungsbetriebssystem aus:

Öffnen Sie die Hyper-V-Manager-Konsole.
Wählen Sie für die Einstellungen einer Linux-VM Integrationsdienste aus.
Stellen Sie sicher, dass Zeitsynchronisierung ausgewählt ist.

Hinweis:

Dieser Ansatz unterscheidet sich von VMware und XenServer (ehemals Citrix Hypervisor), wo die Host-Zeitsynchronisierung deaktiviert wird, um Konflikte mit NTP zu vermeiden. Die Hyper-V-Zeitsynchronisierung kann mit der NTP-Zeitsynchronisierung koexistieren und diese ergänzen.

Zeitsynchronisierung auf ESX und ESXi beheben

Wenn die VMware Zeitsynchronisierungsfunktion aktiviert ist, treten in jeder paravirtualisierten Linux-VM Probleme mit NTP und dem Hypervisor auf. Beide versuchen, die Systemuhr zu synchronisieren. Um zu vermeiden, dass die Uhr mit anderen Servern asynchron wird, stellen Sie sicher, dass die Systemuhr in jedem Linux-Gast mit NTP synchronisiert ist. In diesem Fall muss die Host-Zeitsynchronisierung deaktiviert werden.

Wenn Sie einen paravirtualisierten Linux-Kernel mit installierten VMware Tools ausführen:

Öffnen Sie den vSphere Client.
Bearbeiten Sie die Einstellungen für die Linux-VM.
Öffnen Sie im Dialogfeld Eigenschaften der virtuellen Maschine die Registerkarte Optionen.
Wählen Sie VMware Tools aus.
Deaktivieren Sie im Feld Erweitert die Option Gastzeit mit Host synchronisieren.

Schritt 3: Die Linux-VM zur Windows-Domäne hinzufügen

Die folgenden Methoden stehen zum Hinzufügen von Linux-Maschinen zur Active Directory (AD)-Domäne zur Verfügung:

Befolgen Sie die Anweisungen basierend auf der von Ihnen gewählten Methode.

Hinweis:

Sitzungsstarts können fehlschlagen, wenn derselbe Benutzername für das lokale Konto im Linux VDA und das Konto in AD verwendet wird.

Samba Winbind

Für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0 führen Sie den folgenden Befehl aus, um zu verhindern, dass pam_winbind den Besitz des Stammverzeichnisses ändert:

usermod -d /nonexistent nobody
<!--NeedCopy-->

Installieren oder aktualisieren Sie die erforderlichen Pakete:

Für RHEL 9.2/9.0/8.x und Rocky Linux 9.2/9.0/8.x:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->

Für Amazon Linux 2, CentOS 7 und RHEL 7:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authconfig
<!--NeedCopy-->

Winbind-Daemon beim Maschinenstart aktivieren

Der Winbind-Daemon muss so konfiguriert werden, dass er beim Maschinenstart gestartet wird:

sudo /sbin/chkconfig winbind on
<!--NeedCopy-->

Winbind-Authentifizierung konfigurieren

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

Führen Sie den folgenden Befehl aus.

Für RHEL 9.2/9.0/8.x und Rocky Linux 9.2/9.0/8.x:
```
sudo authselect select winbind with-mkhomedir --force

```
Für Amazon Linux 2, CentOS 7 und RHEL 7:
```
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

```
Dabei ist REALM der Kerberos-Realm-Name in Großbuchstaben und domain der NetBIOS-Name der Domäne.

Wenn eine DNS-basierte Suche des KDC-Servers und des Realm-Namens erforderlich ist, fügen Sie die folgenden beiden Optionen zum vorherigen Befehl hinzu:

--enablekrb5kdcdns --enablekrb5realmdns

Ignorieren Sie alle Fehler, die vom Befehl authconfig bezüglich des Fehlstarts des winbind-Dienstes zurückgegeben werden. Die Fehler können auftreten, wenn authconfig versucht, den winbind-Dienst zu starten, bevor die Maschine der Domäne beigetreten ist.
Öffnen Sie /etc/samba/smb.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [Global] hinzu, jedoch nach dem Abschnitt, der vom authconfig-Tool generiert wurde:

kerberos method = secrets and keytab winbind refresh tickets = true winbind offline logon = no
(Nur für RHEL 9.2/9.0/8.x und Rocky Linux 9.2/9.0/8.x) Öffnen Sie /etc/krb5.conf und fügen Sie Einträge unter den Abschnitten [libdefaults], [realms] und [domain_realm] hinzu:

Unter dem Abschnitt [libdefaults]:

default_ccache_name = FILE:/tmp/krb5cc_%{uid} default_realm = REALM dns_lookup_kdc = true

Unter dem Abschnitt [realms]:

REALM = { kdc = fqdn-of-domain-controller }

Unter dem Abschnitt [domain_realm]:

realm = REALM .realm = REALM

Der Linux VDA benötigt die System-Keytab-Datei /etc/krb5.keytab, um sich beim Delivery Controller zu authentifizieren und zu registrieren. Die vorherige Einstellung der Kerberos-Methode zwingt Winbind dazu, die System-Keytab-Datei zu erstellen, wenn die Maschine zum ersten Mal der Domäne beigetreten wird.

Windows-Domäne beitreten

Ihr Domänencontroller muss erreichbar sein, und Sie müssen über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen.

Um eine Linux-VM zur Windows-Domäne hinzuzufügen, führen Sie den folgenden Befehl aus:

sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->

Tipp:

Für Linux-VMs, die unter Amazon Linux 2, RHEL 7.9 und CentOS 7.9 ausgeführt werden, können Sie auch den folgenden Befehl verwenden, um sie der Windows-Domäne hinzuzufügen:
sudo net ads join REALM -U user

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

PAM für Winbind konfigurieren

Standardmäßig aktiviert die Konfiguration für das Winbind PAM-Modul (pam_winbind) weder das Kerberos-Ticket-Caching noch die Erstellung von Home-Verzeichnissen. Öffnen Sie /etc/security/pam_winbind.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [Global] hinzu oder ändern Sie sie:

krb5_auth = yes krb5_ccache_type = FILE mkhomedir = yes

Stellen Sie sicher, dass alle führenden Semikolons aus jeder Einstellung entfernt werden. Diese Änderungen erfordern einen Neustart des Winbind-Daemons:

sudo systemctl restart winbind
<!--NeedCopy-->

Tipp:

Der winbind-Daemon bleibt nur aktiv, wenn die Maschine einer Domäne beigetreten ist.

Öffnen Sie /etc/krb5.conf und ändern Sie die folgende Einstellung unter dem Abschnitt [libdefaults] von KEYRING auf den Typ FILE:

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

Für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0 führen Sie die folgenden Befehle aus, um das SELinux-Problem mit Winbind zu beheben:

-  ausearch -c 'winbindd' --raw | audit2allow -M my-winbindd -p /etc/selinux/targeted/policy/policy.*

semodule -X 300 -i my-winbindd.pp
<!--NeedCopy-->

Domänenmitgliedschaft überprüfen

-  Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in **Active Directory** haben.

Führen Sie den Befehl net ads von Samba aus, um zu überprüfen, ob die Maschine einer Domäne beigetreten ist:

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

Führen Sie den folgenden Befehl aus, um zusätzliche Domänen- und Computerobjektinformationen zu überprüfen:

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

Kerberos-Konfiguration überprüfen

Um sicherzustellen, dass Kerberos für die Verwendung mit dem Linux VDA korrekt konfiguriert ist, überprüfen Sie, ob die System-Keytab-Datei erstellt wurde und gültige Schlüssel enthält:

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

Dieser Befehl zeigt die Liste der verfügbaren Schlüssel für die verschiedenen Kombinationen von Prinzipalnamen und Chiffre-Suiten an. Führen Sie den Kerberos-Befehl kinit aus, um die Maschine mit dem Domänencontroller unter Verwendung dieser Schlüssel zu authentifizieren:

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

Die Maschinen- und Realm-Namen müssen in Großbuchstaben angegeben werden. Das Dollarzeichen ($) muss mit einem Backslash (\) maskiert werden, um eine Shell-Substitution zu verhindern. In einigen Umgebungen unterscheidet sich der DNS-Domänenname vom Kerberos-Realm-Namen. Stellen Sie sicher, dass der Realm-Name verwendet wird. Wenn dieser Befehl erfolgreich ist, wird keine Ausgabe angezeigt.

Überprüfen Sie, ob das TGT-Ticket für das Maschinenkonto zwischengespeichert wurde, indem Sie Folgendes verwenden:

sudo klist
<!--NeedCopy-->

Überprüfen Sie die Kontodetails der Maschine mit:

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

Benutzerauthentifizierung überprüfen

Verwenden Sie das Tool wbinfo, um zu überprüfen, ob Domänenbenutzer sich bei der Domäne authentifizieren können:

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

Die hier angegebene Domäne ist der AD-Domänenname, nicht der Kerberos-Realm-Name. Für die Bash-Shell muss der Backslash (\) mit einem weiteren Backslash maskiert werden. Dieser Befehl gibt eine Meldung über Erfolg oder Misserfolg zurück.

Um zu überprüfen, ob das Winbind PAM-Modul korrekt konfiguriert ist, melden Sie sich mit einem bisher ungenutzten Domänenbenutzerkonto am Linux VDA an.

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache gültig und nicht abgelaufen sind:

klist
<!--NeedCopy-->

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

Ein ähnlicher Test kann durch direktes Anmelden an der Gnome- oder KDE-Konsole durchgeführt werden. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.

Quest Authentication Services

Quest auf dem Domänencontroller konfigurieren

Gehen Sie davon aus, dass Sie die Quest-Software auf den Active Directory-Domänencontrollern installiert und konfiguriert haben und über administrative Berechtigungen zum Erstellen von Computerobjekten in Active Directory verfügen.

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

Um Domänenbenutzern das Herstellen von HDX™-Sitzungen auf einer Linux VDA-Maschine zu ermöglichen:

Öffnen Sie in der Verwaltungskonsole „Active Directory-Benutzer und -Computer“ die Active Directory-Benutzereigenschaften für dieses Benutzerkonto.
Wählen Sie die Registerkarte Unix-Konto.
Aktivieren Sie Unix-enabled.
Legen Sie die Primäre GID-Nummer auf die Gruppen-ID einer tatsächlichen Domänenbenutzergruppe fest.

Hinweis:

Diese Anweisungen sind äquivalent für die Einrichtung von Domänenbenutzern zur Anmeldung über die Konsole, RDP, SSH oder jedes andere Remote-Protokoll.

Quest auf dem Linux VDA konfigurieren

Umgehung der SELinux-Richtlinienerzwingung

Die Standard-RHEL-Umgebung hat SELinux vollständig erzwungen. Diese Erzwingung stört die von Quest verwendeten Unix-Domain-Socket-IPC-Mechanismen und verhindert, dass Domänenbenutzer sich anmelden können.

Der bequeme Weg, dieses Problem zu umgehen, ist die Deaktivierung von SELinux. Bearbeiten Sie als Root-Benutzer /etc/selinux/config und ändern Sie die SELinux-Einstellung:

SELINUX=permissive

Diese Änderung erfordert einen Neustart der Maschine:

reboot
<!--NeedCopy-->

Wichtig:

Verwenden Sie diese Einstellung mit Vorsicht. Das erneute Aktivieren der SELinux-Richtlinienerzwingung nach der Deaktivierung kann zu einer vollständigen Sperrung führen, selbst für den Root-Benutzer und andere lokale Benutzer.

VAS-Daemon konfigurieren

Die automatische Verlängerung von Kerberos-Tickets muss aktiviert und getrennt werden. Die Authentifizierung (Offline-Anmeldung) muss deaktiviert werden.

sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400

sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->

Dieser Befehl setzt das Verlängerungsintervall auf neun Stunden (32.400 Sekunden), was eine Stunde weniger ist als die standardmäßige 10-Stunden-Ticket-Lebensdauer. Setzen Sie diesen Parameter auf einen niedrigeren Wert bei Systemen mit einer kürzeren Ticket-Lebensdauer.

PAM und NSS konfigurieren

Um die Anmeldung von Domänenbenutzern über HDX und andere Dienste wie su, ssh und RDP zu ermöglichen, führen Sie die folgenden Befehle aus, um PAM und NSS manuell zu konfigurieren:

sudo /opt/quest/bin/vastool configure pam

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

Windows-Domäne beitreten

Fügen Sie die Linux-Maschine der Active Directory-Domäne mit dem Quest-Befehl vastool hinzu:

sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->

Der Benutzer ist ein beliebiger Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne verfügt. Der Domänenname ist der DNS-Name der Domäne, z. B. example.com.

Starten Sie die Linux-Maschine nach dem Domänenbeitritt neu.

Domänenmitgliedschaft überprüfen

Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in Active Directory haben. Um zu überprüfen, ob eine mit Quest verbundene Linux-Maschine in der Domäne ist:

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

Wenn die Maschine einer Domäne beigetreten ist, gibt dieser Befehl den Domänennamen zurück. Wenn die Maschine keiner Domäne beigetreten ist, erscheint der folgende Fehler:

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

Benutzerauthentifizierung überprüfen

Um zu überprüfen, ob Quest Domänenbenutzer über PAM authentifizieren kann, melden Sie sich mit einem bisher ungenutzten Domänenbenutzerkonto am Linux VDA an.

ssh localhost -l domain\\username
id -u
<!--NeedCopy-->

Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die vom Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache gültig und nicht abgelaufen sind:

/opt/quest/bin/vastool klist
<!--NeedCopy-->

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

Centrify DirectControl

Einer Windows-Domäne beitreten

Nach der Installation des Centrify DirectControl Agents fügen Sie die Linux-Maschine der Active Directory-Domäne mit dem Centrify-Befehl adjoin hinzu:

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

Der Benutzerparameter ist jeder Active Directory-Domänenbenutzer, der über Berechtigungen verfügt, Computer der Active Directory-Domäne beizutreten. Der Domänenname ist der Name der Domäne, der die Linux-Maschine beitreten soll.

-  #### Domänenmitgliedschaft überprüfen

Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in Active Directory haben. Um zu überprüfen, ob eine mit Centrify verbundene Linux-Maschine in der Domäne ist:

su –
adinfo
<!--NeedCopy-->

Überprüfen Sie, ob der Wert für „Joined to domain“ gültig ist und der CentrifyDC-Modus „connected“ zurückgibt. Wenn der Modus im Startzustand hängen bleibt, hat der Centrify-Client Probleme mit der Serververbindung oder Authentifizierung.

Umfassendere System- und Diagnoseinformationen sind verfügbar über:

adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->

Testen Sie die Konnektivität zu den verschiedenen Active Directory- und Kerberos-Diensten.

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

Fahren Sie mit Schritt 6: Installieren des Linux VDA fort, nachdem die Domänenbeitrittsüberprüfung abgeschlossen ist.

SSSD

Wenn Sie SSSD verwenden, befolgen Sie die Anweisungen in diesem Abschnitt. Dieser Abschnitt enthält Anweisungen zum Beitreten einer Linux VDA-Maschine zu einer Windows-Domäne und bietet Anleitungen zur Konfiguration der Kerberos-Authentifizierung.

Um SSSD unter RHEL und CentOS einzurichten, gehen Sie wie folgt vor:

Der Domäne beitreten und einen Host-Keytab erstellen
SSSD einrichten
SSSD aktivieren
Die Kerberos-Konfiguration überprüfen
Die Benutzerauthentifizierung überprüfen

Der Domäne beitreten und einen Host-Keytab erstellen

SSSD bietet keine Active Directory-Clientfunktionen für den Domänenbeitritt und die Verwaltung der System-Keytab-Datei. Stattdessen können Sie adcli, realmd oder Samba verwenden.

Dieser Abschnitt beschreibt den Samba-Ansatz für Amazon Linux 2 und RHEL 7 sowie den adcli-Ansatz für RHEL 8.x/9.x und Rocky Linux 8.x/9.x. Für realmd siehe die RHEL- oder CentOS-Dokumentation. Diese Schritte müssen vor der Konfiguration von SSSD befolgt werden.

Samba (Amazon Linux 2 und RHEL 7):

Installieren oder aktualisieren Sie die erforderlichen Pakete:
```
 sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
 
```
Auf dem Linux-Client mit ordnungsgemäß konfigurierten Dateien:
- /etc/krb5.conf
- /etc/samba/smb.conf:
Konfigurieren Sie die Maschine für die Samba- und Kerberos-Authentifizierung:
```
 sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
 
```
Wobei REALM der Kerberos-Realm-Name in Großbuchstaben und domain der kurze NetBIOS-Name der Active Directory-Domäne ist.

Hinweis:

Die Einstellungen in diesem Artikel sind für das Einzeldomänen-, Einzelforst-Modell vorgesehen. Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur.

Wenn eine DNS-basierte Suche des KDC-Servers und des Realm-Namens erforderlich ist, fügen Sie die folgenden beiden Optionen zum vorhergehenden Befehl hinzu:

--enablekrb5kdcdns --enablekrb5realmdns

Öffnen Sie /etc/samba/smb.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [Global] hinzu, jedoch nach dem Abschnitt, der vom authconfig-Tool generiert wurde:

kerberos method = secrets and keytab winbind offline logon = no

Treten Sie der Windows-Domäne bei. Stellen Sie sicher, dass Ihr Domänencontroller erreichbar ist und 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-Realm-Name in Großbuchstaben und user ist ein Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Domäne verfügt.
Adcli (RHEL 9.2/9.0/8.x und Rocky Linux 9.2/9.0/8.x):

Installieren oder aktualisieren Sie die erforderlichen Pakete:
```
 sudo yum -y install samba-common samba-common-tools krb5-workstation authconfig oddjob-mkhomedir realmd oddjob authselect
 
```
Konfigurieren Sie die Maschine für die Samba- und Kerberos-Authentifizierung:
```
 sudo authselect select sssd with-mkhomedir --force
 
```
Öffnen Sie /etc/krb5.conf und fügen Sie die Einträge unter den Abschnitten [realms] und [domain_realm] hinzu.

Unter dem Abschnitt [realms]:

REALM = { kdc = fqdn-of-domain-controller }

Unter dem Abschnitt [domain_realm]:

realm = REALM .realm = REALM

Treten Sie der Windows-Domäne bei. Stellen Sie sicher, dass Ihr Domänencontroller erreichbar ist und Sie über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:
```
 sudo realm join REALM -U user
 
```
REALM ist der Kerberos-Realm-Name in Großbuchstaben und user ist ein Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Domäne verfügt.

SSSD einrichten

Das Einrichten von SSSD umfasst die folgenden Schritte:

Installieren Sie das Paket sssd-ad auf dem Linux VDA, indem Sie den Befehl sudo yum -y install sssd ausführen.
Nehmen Sie Konfigurationsänderungen an verschiedenen Dateien vor (z. B. sssd.conf).
Starten Sie den Dienst sssd.

Ein Beispiel für die sssd.conf-Konfiguration für RHEL 7 (zusätzliche Optionen können bei Bedarf hinzugefügt werden):

Ein Beispiel für die SSSD-Konfiguration für RHEL 7

Ersetzen Sie ad.example.com, server.ad.example.com durch die entsprechenden Werte. Weitere Details finden Sie unter sssd-ad(5) - Linux-Manpage.

(Nur RHEL 9.2/9.0/8.x und Rocky Linux 9.2/9.0/8.x) Öffnen Sie /etc/sssd/sssd.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [domain/ad.example.com] hinzu:

ad_gpo_access_control = permissive full_name_format = %2$s\%1$s fallback_homedir = /home/%d/%u # Kerberos settings krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U

Legen Sie die Dateiberechtigungen und den Dateibesitz für sssd.conf fest:

chown root:root /etc/sssd/sssd.conf chmod 0600 /etc/sssd/sssd.conf restorecon /etc/sssd/sssd.conf

SSSD aktivieren

Für RHEL 9.2/9.0/8.x und Rocky Linux 9.2/9.0/8.x:

Führen Sie die folgenden Befehle aus, um SSSD zu aktivieren:

sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->

Für Amazon Linux 2, CentOS 7 und RHEL 7:

Verwenden Sie authconfig, um SSSD zu aktivieren. Installieren Sie oddjob-mkhomedir, um sicherzustellen, dass die Erstellung des Home-Verzeichnisses mit SELinux kompatibel ist:

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

sudo systemctl start sssd

sudo chkconfig sssd on
<!--NeedCopy-->

Kerberos-Konfiguration überprüfen

Überprüfen Sie, ob die Systemdatei keytab erstellt wurde und gültige Schlüssel enthält:

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

Dieser Befehl zeigt die Liste der Schlüssel an, die für die verschiedenen Kombinationen von Prinzipalnamen und Chiffriersuiten verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um den Computer mit dem Domänencontroller unter Verwendung dieser Schlüssel zu authentifizieren:

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

Der Maschinen- und Realm-Name müssen in Großbuchstaben angegeben werden. Das Dollarzeichen ($) muss mit einem Backslash (\) maskiert werden, um eine Shell-Substitution zu verhindern. In einigen Umgebungen unterscheidet sich der DNS-Domänenname vom Kerberos-Realm-Namen. Stellen Sie sicher, dass der Realm-Name verwendet wird. Wenn dieser Befehl erfolgreich ist, wird keine Ausgabe angezeigt.

Überprüfen Sie, ob das TGT-Ticket für das Maschinenkonto mit folgendem Befehl zwischengespeichert wurde:

sudo klist
<!--NeedCopy-->

Benutzerauthentifizierung überprüfen

Verwenden Sie den Befehl getent, um zu überprüfen, ob das Anmeldeformat unterstützt wird und der NSS funktioniert:

sudo getent passwd DOMAIN\\username
<!--NeedCopy-->

Der Parameter DOMAIN gibt den Kurznamen der Domäne an. Wenn ein anderes Anmeldeformat benötigt wird, überprüfen Sie dies zuerst mit dem Befehl getent.

Die unterstützten Anmeldeformate sind:

Anmeldename auf niedrigerer Ebene: DOMAIN\username
UPN: username@domain.com
NetBIOS-Suffix-Format: username@DOMAIN

Um zu überprüfen, ob das SSSD PAM-Modul korrekt konfiguriert ist, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das noch nicht verwendet wurde.

-  sudo ssh localhost –l DOMAIN\\username

id -u
<!--NeedCopy-->

Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die vom Befehl zurückgegebene uid erstellt wurde:

ls /tmp/krb5cc_{uid}
<!--NeedCopy-->

Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache des Benutzers gültig und nicht abgelaufen sind.

klist
<!--NeedCopy-->

Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.

PBIS

Erforderliches PBIS-Paket herunterladen

wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

PBIS-Installationsskript ausführbar machen

chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

PBIS-Installationsskript ausführen

sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->

Windows-Domäne beitreten

Ihr Domänencontroller muss erreichbar sein, und Sie müssen über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:

/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->

Der Benutzer ist ein Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne verfügt. Der Domänenname ist der DNS-Name der Domäne, z. B. example.com.

Hinweis: Um Bash als Standardshell festzulegen, führen Sie den Befehl /opt/pbis/bin/config LoginShellTemplate/bin/bash aus.

Domänenmitgliedschaft überprüfen

Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in Active Directory haben. Um zu überprüfen, ob eine PBIS-verbundene Linux-Maschine in der Domäne ist:

/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->

Wenn die Maschine einer Domäne beigetreten ist, gibt dieser Befehl Informationen über die aktuell beigetretene AD-Domäne und OU zurück. Andernfalls wird nur der Hostname angezeigt.

Benutzerauthentifizierung überprüfen

Um zu überprüfen, ob PBIS Domänenbenutzer über PAM authentifizieren kann, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das noch nicht verwendet wurde.

ssh localhost -l domain\\user

id -u
<!--NeedCopy-->

Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die vom Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Beenden Sie die Sitzung.

-  exit
<!--NeedCopy-->

Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.

Schritt 4: .NET Runtime 6.0 installieren

Bevor Sie den Linux VDA installieren, installieren Sie .NET Runtime 6.0 gemäß den Anweisungen unter https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

Nach der Installation von .NET Runtime 6.0 führen Sie den Befehl which dotnet aus, um Ihren Runtime-Pfad zu finden.

Legen Sie basierend auf der Befehlsausgabe den Binärpfad der .NET-Laufzeit fest. Wenn die Befehlsausgabe beispielsweise /aa/bb/dotnet lautet, verwenden Sie /aa/bb als .NET-Binärpfad.

    -  ## Schritt 5: Linux VDA-Paket herunterladen

Rufen Sie die Downloadseite für Citrix Virtual Apps and Desktops auf.
Erweitern Sie die entsprechende Version von Citrix Virtual Apps and Desktops.

Erweitern Sie Komponenten, um den Linux VDA zu finden. Beispiel:

-  ![Komponenten für Citrix Virtual Apps and Desktops](/en-us/linux-virtual-delivery-agent/2311/media/components-for-citrix-virtual-apps-and-desktops.png)

Klicken Sie auf den Linux VDA-Link, um auf die Linux VDA-Downloads zuzugreifen.
Laden Sie das Linux VDA-Paket herunter, das Ihrer Linux-Distribution entspricht.

1. Laden Sie den öffentlichen GPG-Schlüssel herunter, mit dem Sie die Integrität des Linux VDA-Pakets überprüfen können. Beispiel:
  - Um die Integrität des Linux VDA-Pakets zu überprüfen, führen Sie die folgenden Befehle aus, um den öffentlichen Schlüssel in die RPM-Datenbank zu importieren und die Paketintegrität zu prüfen:
```
 rpmkeys --import <path to the public key>
 rpm --checksig --verbose <path to the Linux VDA package>
 
```

Schritt 6: Linux VDA installieren

Sie können eine Neuinstallation durchführen oder eine vorhandene Installation aktualisieren. Der Linux VDA unterstützt Upgrades von der neuesten Version. Sie können den Linux VDA beispielsweise von 2308 auf 2311 und von 1912 LTSR auf 2203 LTSR aktualisieren.

Schritt 6a: Neuinstallation durchführen

(Optional) Alte Version deinstallieren

Wenn Sie eine frühere Version als die beiden vorherigen und eine LTSR-Version installiert haben, deinstallieren Sie diese, bevor Sie die neue Version installieren.
1. Beenden Sie die Linux VDA-Dienste:
```
sudo systemctl stop ctxvda

sudo systemctl stop ctxhdx

```
  Hinweis:
  
  Bevor Sie die Dienste ctxvda und ctxhdx beenden, führen Sie den Befehl systemctl stop ctxmonitord aus, um den Überwachungsdienst-Daemon zu beenden. Andernfalls startet der Überwachungsdienst-Daemon die von Ihnen beendeten Dienste neu.
2. Deinstallieren Sie das Paket:
```
sudo rpm -e XenDesktopVDA

```
Hinweis:

Um einen Befehl auszuführen, ist der vollständige Pfad erforderlich; alternativ können Sie /opt/Citrix/VDA/sbin und /opt/Citrix/VDA/bin zum Systempfad hinzufügen.
Linux VDA-Paket herunterladen

Rufen Sie die Downloadseite für Citrix Virtual Apps and Desktops auf. Erweitern Sie die entsprechende Version von Citrix Virtual Apps and Desktops und klicken Sie auf Komponenten, um das Linux VDA-Paket herunterzuladen, das Ihrer Linux-Distribution entspricht.

Linux VDA installieren

Hinweis:
    -  Für CentOS, RHEL und Rocky Linux müssen Sie das EPEL-Repository installieren, bevor Sie den Linux VDA erfolgreich installieren können. Informationen zur Installation von EPEL finden Sie unter <https://docs.fedoraproject.org/en-US/epel/>.
Bevor Sie den Linux VDA unter RHEL 9.2/9.0 und Rocky Linux 9.2/9.0 installieren, aktualisieren Sie das Paket libsepol auf Version 3.4 oder höher.

Installieren Sie die Linux VDA-Software mit Yum:

Für Amazon Linux 2:

 sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
 <!--NeedCopy-->

Für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0:

 sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm
 <!--NeedCopy-->

Für RHEL 8.x und Rocky Linux 8.x:

 sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
 <!--NeedCopy-->

Für CentOS 7 und RHEL 7:

 sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
 <!--NeedCopy-->

Installieren Sie die Linux VDA-Software mit dem RPM-Paketmanager. Zuvor müssen Sie die folgenden Abhängigkeiten auflösen:

Für Amazon Linux 2:
```
 sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm
 
```
RHEL 9.2/9.0 und Rocky Linux 9.2/9.0:
```
 sudo rpm -i XenDesktopVDA-<version>.el9_x.x86_64.rpm
 
```

Für RHEL 8.x und Rocky Linux 8.x:

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

 **Für CentOS 7 und RHEL 7:**

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

 **RPM-Abhängigkeitsliste für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0:**

 ```
 -  tzdata-java >= 2022

 java-11-openjdk >= 11

  icoutils >= 0.32

  firewalld >= 0.6.3

  policycoreutils-python >= 2.8.9

  policycoreutils-python-utils >= 2.8

  python3-policycoreutils >= 2.8

  dbus >= 1.12.8

  dbus-common >= 1.12.8

  dbus-daemon >= 1.12.8

  dbus-tools >= 1.12.8

  dbus-x11 >= 1.12.8

  xorg-x11-server-utils >= 7.7

  xorg-x11-xinit >= 1.3.4

  libXpm >= 3.5.12

  libXrandr >= 1.5.1

  libXtst >= 1.2.3

  pam >= 1.3.1

  util-linux >= 2.32.1

  util-linux-user >= 2.32.1

  xorg-x11-utils >= 7.5

  bash >= 4.3

  findutils >= 4.6

  gawk >= 4.2

  sed >= 4.5

  cups >= 1.6.0

  foomatic-filters >= 4.0.9

  cups-filters >= 1.20.0

  ghostscript >= 9.25

  libxml2 >= 2.9

  libmspack >= 0.7

  krb5-workstation >= 1.13

  ibus >= 1.5

  nss-tools >= 3.44.0

  gperftools-libs >= 2.4

  cyrus-sasl-gssapi >= 2.1

  python3 >= 3.6~

  qt5-qtbase >= 5.5~

  qt5-qtbase-gui >= 5.5~

  qrencode-libs >= 3.4.4

  imlib2 >= 1.4.9

 <!--NeedCopy--> ```

 **RPM-Abhängigkeitsliste für RHEL 8.x und Rocky Linux 8.x:**

 ```
 java-11-openjdk >= 11

 icoutils >= 0.32

 firewalld >= 0.6.3

 policycoreutils-python >= 2.8.9

 policycoreutils-python-utils >= 2.8

 python3-policycoreutils >= 2.8

 dbus >= 1.12.8

 dbus-common >= 1.12.8

 dbus-daemon >= 1.12.8

 dbus-tools >= 1.12.8

 dbus-x11 >= 1.12.8

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.4

 libXpm >= 3.5.12

 libXrandr >= 1.5.1

 libXtst >= 1.2.3

 pam >= 1.3.1

 util-linux >= 2.32.1

 util-linux-user >= 2.32.1

 xorg-x11-utils >= 7.5

 bash >= 4.3

 findutils >= 4.6

 gawk >= 4.2

 sed >= 4.5

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 cups-filters >= 1.20.0

 ghostscript >= 9.25

 libxml2 >= 2.9

 libmspack >= 0.7

 krb5-workstation >= 1.13

 ibus >= 1.5

 nss-tools >= 3.44.0

 gperftools-libs >= 2.4

 cyrus-sasl-gssapi >= 2.1

 python3 >= 3.6~

 qt5-qtbase >= 5.5~

 qt5-qtbase-gui >= 5.5~

 qrencode-libs >= 3.4.4

 imlib2 >= 1.4.9
 <!--NeedCopy--> ```

 **RPM-Abhängigkeitsliste für CentOS 7 und RHEL 7:**

 ```
 java-11-openjdk >= 11

 ImageMagick >= 6.7.8.9

 firewalld >= 0.3.9

 policycoreutils-python >= 2.0.83

 dbus >= 1.6.12

 dbus-x11 >= 1.6.12

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.2

 xorg-x11-server-Xorg >= 1.20.4

 libXpm >= 3.5.10

 libXrandr >= 1.4.1

 libXtst >= 1.2.2

 pam >= 1.1.8

 util-linux >= 2.23.2

 bash >= 4.2

 findutils >= 4.5

 gawk >= 4.0

 sed >= 4.2

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 libxml2 >= 2.9

 libmspack >= 0.5

 ibus >= 1.5

 cyrus-sasl-gssapi >= 2.1

 python3 >= 3.6~

 gperftools-libs >= 2.4

 nss-tools >= 3.44.0

 qt5-qtbase >= 5.5~

 qt5-qtbase >= 5.5~

 imlib2 >= 1.4.5
 <!--NeedCopy--> ```

 **RPM-Abhängigkeitsliste für Amazon Linux 2:**

 ```
 java-11-openjdk >= 11

 ImageMagick >= 6.7.8.9

 firewalld >= 0.3.9

 policycoreutils-python >= 2.0.83

 dbus >= 1.6.12

 dbus-x11 >= 1.6.12

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.2

 xorg-x11-server-Xorg >= 1.20.4

 libXpm >= 3.5.10

 libXrandr >= 1.4.1

 libXtst >= 1.2.2

 pam >= 1.1.8

 util-linux >= 2.23.2

 bash >= 4.2

 findutils >= 4.5

 gawk >= 4.0

 sed >= 4.2

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 libxml2 >= 2.9

 libmspack >= 0.5

 ibus >= 1.5

 cyrus-sasl-gssapi >= 2.1

 gperftools-libs >= 2.4

 nss-tools >= 3.44.0

 qt5-qtbase >= 5.5~

 qrencode-libs >= 3.4.1

 imlib2 >= 1.4.5
 <!--NeedCopy--> ```

Hinweis:

Eine Matrix der Linux-Distributionen und der Xorg-Versionen, die diese Version des Linux VDA unterstützt, finden Sie unter Systemanforderungen.

Nach der Installation des Linux VDA unter RHEL 7.x führen Sie den Befehl sudo yum install -y python-websockify x11vnc aus. Der Zweck ist die manuelle Installation von python-websockify und x11vnc zur Verwendung der Sitzungsschattenfunktion. Weitere Informationen finden Sie unter Sitzungsschatten.

Schritt 6b: Vorhandene Installation aktualisieren (optional)

Der Linux VDA unterstützt Upgrades von der neuesten Version. Sie können den Linux VDA beispielsweise von 2308 auf 2311 und von 1912 LTSR auf 2203 LTSR aktualisieren.

Hinweis:

Beim Upgrade einer vorhandenen Installation werden die Konfigurationsdateien unter /etc/xdl überschrieben. Bevor Sie ein Upgrade durchführen, stellen Sie sicher, dass Sie die Dateien sichern.

Bevor Sie den Linux VDA unter RHEL 9.2/9.0 und Rocky Linux 9.2/9.0 aktualisieren, aktualisieren Sie das Paket libsepol auf Version 3.4 oder höher.

-  So aktualisieren Sie Ihre Software mit `Yum`:

**Für Amazon Linux 2:**

```
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy--> ```

**Für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0:**

```
sudo yum install -y XenDesktopVDA-<version>.el9_x.x86_64.rpm
<!--NeedCopy--> ```

**Für RHEL 8.x und Rocky Linux 8.x:**

```
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy--> ```

**Für CentOS 7 und RHEL 7:**

```
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy--> ```

So aktualisieren Sie Ihre Software mit dem RPM-Paketmanager:

Für Amazon Linux 2:

 sudo rpm -U XenDesktopVDA-<version>.amzn2.x86_64.rpm
 <!--NeedCopy-->

Für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0:

 sudo rpm -U XenDesktopVDA-<version>.el9_x.x86_64.rpm
 <!--NeedCopy-->

Für RHEL 8.x und Rocky Linux 8.x:

 sudo rpm -U XenDesktopVDA-<version>.el8_x.x86_64.rpm
 <!--NeedCopy-->

Für CentOS 7 und RHEL 7:

 sudo rpm -U XenDesktopVDA-<version>.el7_x.x86_64.rpm
 <!--NeedCopy-->

Hinweis:

Wenn Sie RHEL 7 verwenden, stellen Sie sicher, dass Sie die folgenden Schritte ausführen, nachdem Sie die vorhergehenden Upgrade-Befehle ausgeführt haben:

führen Sie /opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "DotNetRuntimePath" -d "/opt/rh/rh-dotnet31/root/usr/bin/" --force aus, um den korrekten .NET-Laufzeitpfad festzulegen.

Starten Sie den Dienst ctxvda neu.

Wichtig:

Starten Sie die Linux-VDA-Maschine nach dem Software-Upgrade neu.

Schritt 7: NVIDIA GRID-Treiber installieren

Um HDX 3D Pro zu aktivieren, müssen Sie die NVIDIA GRID-Treiber auf Ihrem Hypervisor und auf den VDA-Maschinen installieren.

Hinweis:

Um HDX 3D Pro für Amazon Linux 2 zu verwenden, empfehlen wir die Installation des NVIDIA-Treibers 470. Weitere Informationen finden Sie unter Systemanforderungen.

Informationen zur Installation und Konfiguration des NVIDIA GRID Virtual GPU Manager (des Hosttreibers) auf den jeweiligen Hypervisoren finden Sie in den folgenden Anleitungen:

Führen Sie die folgenden Schritte aus, um die NVIDIA GRID-Gast-VM-Treiber zu installieren und zu konfigurieren:

Stellen Sie sicher, dass die Gast-VM heruntergefahren ist.
Weisen Sie in XenCenter® der VM eine GPU zu.
Starten Sie die VM.

Bereiten Sie die VM für den NVIDIA GRID-Treiber vor:

yum install gcc

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

systemctl set-default multi-user.target
<!--NeedCopy-->

Befolgen Sie die Schritte im Red Hat Enterprise Linux-Dokument, um den NVIDIA GRID-Treiber zu installieren.

Hinweis:

Wählen Sie während der Installation des GPU-Treibers bei jeder Frage die Standardoption (‘no’).

Wichtig:

Nachdem GPU-Passthrough aktiviert wurde, ist die Linux-VM über XenCenter nicht mehr zugänglich. Verwenden Sie SSH zur Verbindung.

NVIDIA smi Code-Snippet

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

etc/X11/ctx-nvidia.sh

Um große Auflösungen und Multi-Monitor-Funktionen nutzen zu können, benötigen Sie eine gültige NVIDIA-Lizenz. Um die Lizenz zu beantragen, befolgen Sie die Produktdokumentation aus “GRID Licensing Guide.pdf - DU-07757-001 September 2015”.

Schritt 8: Linux VDA konfigurieren

Hinweis:

Bevor Sie die Laufzeitumgebung einrichten, stellen Sie sicher, dass das Gebietsschema en_US.UTF-8 auf Ihrem Betriebssystem installiert ist. Wenn das Gebietsschema auf Ihrem Betriebssystem nicht verfügbar ist, führen Sie den Befehl sudo locale-gen en_US.UTF-8 aus. Bearbeiten Sie für Debian die Datei /etc/locale.gen, indem Sie die Zeile # en_US.UTF-8 UTF-8 auskommentieren, und führen Sie dann den Befehl sudo locale-gen aus.

Nach der Installation des Pakets müssen Sie den Linux VDA konfigurieren, indem Sie das Skript ctxsetup.sh ausführen. Bevor Änderungen vorgenommen werden, überprüft das Skript die Umgebung und stellt sicher, dass alle Abhängigkeiten installiert sind. Bei Bedarf können Sie das Skript jederzeit erneut ausführen, um Einstellungen zu ändern.

Sie können das Skript manuell mit Abfragen oder automatisch mit vorkonfigurierten Antworten ausführen. Lesen Sie die Hilfe zum Skript, bevor Sie fortfahren:

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

Konfiguration mit Eingabeaufforderung

Führen Sie eine manuelle Konfiguration mit Abfragen durch:

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

Automatisierte Konfiguration

Für eine automatisierte Installation geben Sie die vom Setup-Skript benötigten Optionen mit Umgebungsvariablen an. Wenn alle erforderlichen Variablen vorhanden sind, fordert das Skript keine Informationen an.

Unterstützte Umgebungsvariablen umfassen:

CTX_XDL_NON_DOMAIN_JOINED=’y|n’ – Gibt an, ob die Maschine einer Domäne beitreten soll. Der Standardwert ist ‘n’. Für domänenverbundene Szenarien setzen Sie ihn auf ‘n’.
CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’ – Der Linux VDA erfordert Kerberos-Konfigurationseinstellungen zur Authentifizierung bei den Delivery Controllern. Die Kerberos-Konfiguration wird vom installierten und konfigurierten Active Directory-Integrationstool auf dem System bestimmt.
CTX_XDL_DDC_LIST=’<list-ddc-fqdns>‘ – Der Linux VDA erfordert eine durch Leerzeichen getrennte Liste von FQDNs (Fully Qualified Domain Names) der Delivery Controller, die für die Registrierung bei einem Delivery Controller verwendet werden sollen. Mindestens ein FQDN oder CNAME muss angegeben werden.
CTX_XDL_VDI_MODE=’y|n’ – Gibt an, ob die Maschine als dediziertes Desktop-Bereitstellungsmodell (VDI) oder als gehostetes Shared-Desktop-Bereitstellungsmodell konfiguriert werden soll. Für HDX 3D Pro-Umgebungen setzen Sie den Wert auf ‘y’.
CTX_XDL_HDX_3D_PRO=’y|n’ – Der Linux VDA unterstützt HDX 3D Pro, eine Reihe von GPU-Beschleunigungstechnologien, die zur Optimierung der Virtualisierung von grafikintensiven Anwendungen entwickelt wurden. Wenn HDX 3D Pro ausgewählt ist, wird der VDA für VDI-Desktops (Einzelsitzungsmodus) konfiguriert – (d. h. CTX_XDL_VDI_MODE=‘y’).
CTX_XDL_START_SERVICE=’y|n’ – Legt fest, ob die Linux VDA-Dienste gestartet werden, wenn die Konfiguration abgeschlossen ist.
CTX_XDL_REGISTER_SERVICE=’y|n’ – Die Linux Virtual Desktop-Dienste werden nach dem Maschinenstart gestartet.
CTX_XDL_ADD_FIREWALL_RULES=’y|n’ – Die Linux VDA-Dienste erfordern, dass eingehende Netzwerkverbindungen über die System-Firewall zugelassen werden. Sie können die erforderlichen Ports (standardmäßig Ports 80 und 1494) automatisch in der System-Firewall für den Linux Virtual Desktop öffnen.
CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/mate – Gibt die GNOME-, GNOME Classic- oder MATE-Desktop-Umgebung an, die in Sitzungen verwendet werden soll. Wenn Sie die Variable nicht angeben, wird der auf dem VDA konfigurierte Standard-Desktop verwendet.

Sie können die Desktop-Umgebung für einen Ziel-Sitzungsbenutzer auch ändern, indem Sie die folgenden Schritte ausführen:
1. Erstellen Sie eine .xsession-Datei im Verzeichnis $HOME/<username> auf dem VDA.
2. Bearbeiten Sie die .xsession-Datei, um eine Desktop-Umgebung basierend auf den Distributionen anzugeben.
  - Für MATE-Desktop
    MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi
  - Für GNOME Classic-Desktop
    GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi
  - Für GNOME-Desktop
    GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi
3. Teilen Sie die Dateiberechtigung 700 mit dem Ziel-Sitzungsbenutzer.
Ab Version 2209 können Sitzungsbenutzer ihre Desktopumgebungen anpassen. Um diese Funktion zu aktivieren, müssen Sie im Voraus umschaltbare Desktopumgebungen auf dem VDA installieren. Weitere Informationen finden Sie unter Custom desktop environments by session users.
CTX_XDL_DOTNET_RUNTIME_PATH=Pfad-zur-Installation-von-dotnet-runtime – Der Pfad zur Installation von .NET Runtime 6.0 zur Unterstützung des neuen Broker-Agent-Dienstes (ctxvda). Der Standardpfad ist ‘/usr/bin’.
CTX_XDL_VDA_PORT=Portnummer – Der Linux VDA kommuniziert mit Delivery Controllern über einen TCP/IP-Port.
CTX_XDL_SITE_NAME=<dns-name> – Der Linux VDA ermittelt LDAP-Server über DNS. Um die DNS-Suchergebnisse auf eine lokale Site zu beschränken, geben Sie einen DNS-Sitenamen an. Falls nicht erforderlich, setzen Sie den Wert auf ’<none>‘.
CTX_XDL_LDAP_LIST=’<list-ldap-servers>‘ – Der Linux VDA fragt DNS ab, um LDAP-Server zu ermitteln. Wenn DNS keine LDAP-Dienstdatensätze bereitstellen kann, können Sie eine durch Leerzeichen getrennte Liste von LDAP-FQDNs mit LDAP-Ports angeben. Beispiel: ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268. Um schnellere LDAP-Abfragen innerhalb einer Active Directory-Gesamtstruktur zu ermöglichen, aktivieren Sie den Global Catalog auf einem Domänencontroller und geben Sie die relevante LDAP-Portnummer als 3268 an. Diese Variable ist standardmäßig auf ’<none>‘ gesetzt.
CTX_XDL_SEARCH_BASE=Suchbasis-Set – Der Linux VDA fragt LDAP über eine Suchbasis ab, die auf das Stammverzeichnis der Active Directory-Domäne gesetzt ist (z. B. DC=mycompany,DC=com). Um die Suchleistung zu verbessern, können Sie eine Suchbasis angeben (z. B. OU=VDI,DC=mycompany,DC=com). Falls nicht erforderlich, setzen Sie den Wert auf ’<none>‘.`
CTX_XDL_SUPPORT_DDC_AS_CNAME=’j|n’ – Der Linux VDA unterstützt die Angabe eines Delivery Controller-Namens mithilfe eines DNS-CNAME-Eintrags.

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

export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest
export CTX_XDL_DDC_LIST='<list-ddc-fqdns>'
export CTX_XDL_VDI_MODE='y|n'
export CTX_XDL_HDX_3D_PRO='y|n'
export CTX_XDL_START_SERVICE='y|n'
export CTX_XDL_REGISTER_SERVICE='y|n'
export CTX_XDL_ADD_FIREWALL_RULES='y|n'
export CTX_XDL_DESKTOP_ENVIRONMENT= gnome|gnome-classic|mate|'<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>'
export CTX_XDL_VDA_PORT='<port-number>'
export CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>'
export CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>'
export CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>'
export CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n'
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->

Wenn Sie den sudo-Befehl ausführen, geben Sie die Option -E ein, um die vorhandenen Umgebungsvariablen an die neue Shell zu übergeben, die erstellt wird. Wir empfehlen, dass Sie eine Shell-Skriptdatei aus den vorhergehenden Befehlen mit #!/bin/bash als erster Zeile erstellen.

Alternativ können Sie alle Parameter mit einem einzigen Befehl angeben:

sudo CTX_XDL_NON_DOMAIN_JOINED='n' \
CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest \
CTX_XDL_DDC_LIST='<list-ddc-fqdns>' \
CTX_XDL_VDI_MODE='y|n' \
CTX_XDL_HDX_3D_PRO='y|n' \
CTX_XDL_START_SERVICE='y|n' \
CTX_XDL_REGISTER_SERVICE='y|n' \
CTX_XDL_ADD_FIREWALL_RULES='y|n' \
CTX_XDL_DESKTOP_ENVIRONMENT= gnome|gnome-classic|mate|'<none>' \
CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>' \
CTX_XDL_VDA_PORT='<port-number>' \
CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>' \
CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>' \
CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>' \
CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n' \
/opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--NeedCopy-->

Konfigurationsänderungen entfernen

In einigen Szenarien müssen Sie möglicherweise die vom Skript ctxsetup.sh vorgenommenen Konfigurationsänderungen entfernen, ohne das Linux VDA-Paket zu deinstallieren.

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

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

So entfernen Sie Konfigurationsänderungen:

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

Wichtig:

Dieses Skript löscht alle Konfigurationsdaten aus der Datenbank und macht den Linux VDA funktionsunfähig.

Konfigurationsprotokolle

Die Skripte ctxsetup.sh und ctxcleanup.sh zeigen Fehler auf der Konsole an, wobei zusätzliche Informationen in die Konfigurationsprotokolldatei /tmp/xdl.configure.log geschrieben werden.

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

Schritt 9: XDPing ausführen

Führen Sie sudo /opt/Citrix/VDA/bin/xdping aus, um häufige Konfigurationsprobleme in einer Linux VDA-Umgebung zu überprüfen. Weitere Informationen finden Sie unter XDPing.

Schritt 10: Linux VDA ausführen

Nachdem Sie den Linux VDA mit dem Skript ctxsetup.sh konfiguriert haben, können Sie die folgenden Befehle ausführen, um den Linux VDA zu steuern.

Linux VDA starten:

So starten Sie die Linux VDA-Dienste:

sudo systemctl start ctxhdx

sudo systemctl start ctxvda
<!--NeedCopy-->

Linux VDA beenden:

So beenden Sie die Linux VDA-Dienste:

sudo systemctl stop ctxvda

sudo systemctl stop ctxhdx
<!--NeedCopy-->

Hinweis:

Bevor Sie die Dienste ctxvda und ctxhdx beenden, führen Sie den Befehl systemctl stop ctxmonitord aus, um den Überwachungsdienst-Daemon zu beenden. Andernfalls startet der Überwachungsdienst-Daemon die von Ihnen beendeten Dienste neu.

Linux VDA neu starten:

So starten Sie die Linux VDA-Dienste neu:

sudo systemctl stop ctxvda

sudo systemctl restart ctxhdx

sudo systemctl start ctxvda
<!--NeedCopy-->

Status des Linux VDA überprüfen:

So überprüfen Sie den Ausführungsstatus der Linux VDA-Dienste:

sudo systemctl status ctxvda

sudo systemctl status ctxhdx
<!--NeedCopy-->

Schritt 11: Maschinenkataloge erstellen

Der Prozess zum Erstellen von Maschinenkatalogen und Hinzufügen von Linux VDA-Maschinen ähnelt dem traditionellen Windows VDA-Ansatz. Eine detailliertere Beschreibung zur Durchführung dieser Aufgaben finden Sie unter Create machine catalogs und Manage machine catalogs.

Für die Erstellung von Maschinenkatalogen, die Linux VDA-Maschinen enthalten, gibt es einige Einschränkungen, die den Prozess von der Erstellung von Maschinenkatalogen für Windows VDA-Maschinen unterscheiden:

Wählen Sie für das Betriebssystem:
- Die Option Multi-session OS für ein Bereitstellungsmodell mit gehosteten Shared Desktops.
- Die Option Single-session OS für ein VDI-Bereitstellungsmodell mit dedizierten Desktops.
Mischen Sie keine Linux- und Windows VDA-Maschinen im selben Maschinenkatalog.

Hinweis:

Frühere Versionen von Citrix Studio unterstützten den Begriff “Linux OS” nicht. Die Auswahl der Option Windows Server OS oder Server OS impliziert jedoch ein äquivalentes Bereitstellungsmodell für gehostete Shared Desktops. Die Auswahl der Option Windows Desktop OS oder Desktop OS impliziert ein Bereitstellungsmodell für einen einzelnen Benutzer pro Maschine.

Tipp:

Wenn Sie eine entfernte Maschine wieder der Active Directory-Domäne hinzufügen, entfernen Sie die Maschine aus ihrem Maschinenkatalog und fügen Sie sie wieder hinzu.

Schritt 12: Bereitstellungsgruppen erstellen

Der Prozess zum Erstellen einer Bereitstellungsgruppe und zum Hinzufügen von Maschinenkatalogen, die Linux VDA-Maschinen enthalten, ist nahezu identisch mit dem für Windows VDA-Maschinen. Eine detailliertere Beschreibung zur Durchführung dieser Aufgaben finden Sie unter Create delivery groups.

Für die Erstellung von Bereitstellungsgruppen, die Linux VDA-Maschinenkataloge enthalten, gelten die folgenden Einschränkungen:

Stellen Sie sicher, dass die von Ihnen ausgewählten AD-Benutzer und -Gruppen ordnungsgemäß für die Anmeldung an den Linux VDA-Maschinen konfiguriert wurden.
Erlauben Sie keine Anmeldung von nicht authentifizierten (anonymen) Benutzern.
Mischen Sie die Bereitstellungsgruppe nicht mit Maschinenkatalogen, die Windows-Maschinen enthalten.

Wichtig:

Die Veröffentlichung von Anwendungen wird ab Linux VDA Version 1.4 unterstützt. Der Linux VDA unterstützt jedoch nicht die Bereitstellung von Desktops und Apps auf derselben Maschine.

Informationen zum Erstellen von Maschinenkatalogen und Bereitstellungsgruppen finden Sie unter Citrix Virtual Apps and Desktops 7 2311.

Die offizielle Version dieses Inhalts ist auf Englisch. Für den einfachen Einstieg wird Teil des Inhalts der Cloud Software Group Dokumentation maschinell übersetzt. Cloud Software Group hat keine Kontrolle über maschinell übersetzte Inhalte, die Fehler, Ungenauigkeiten oder eine ungeeignete Sprache enthalten können. Es wird keine Garantie, weder ausdrücklich noch stillschweigend, für die Genauigkeit, Zuverlässigkeit, Eignung oder Richtigkeit von Übersetzungen aus dem englischen Original in eine andere Sprache oder für die Konformität Ihres Cloud Software Group Produkts oder Ihres Diensts mit maschinell übersetzten Inhalten gegeben, und jegliche Garantie, die im Rahmen der anwendbaren Endbenutzer-Lizenzvereinbarung oder der Vertragsbedingungen oder einer anderen Vereinbarung mit Cloud Software Group gegeben wird, dass das Produkt oder den Dienst mit der Dokumentation übereinstimmt, gilt nicht in dem Umfang, in dem diese Dokumentation maschinell übersetzt wurde. Cloud Software Group kann nicht für Schäden oder Probleme verantwortlich gemacht werden, die durch die Verwendung maschinell übersetzter Inhalte entstehen können.

War dieser Artikel hilfreich?

Linux VDA manuell auf Amazon Linux 2, CentOS, RHEL und Rocky Linux installieren

May 6, 2026

Beitrag von:

C C

May 6, 2026

Beitrag von:

C C

In diesem Artikel

Schritt 1: Konfigurationsinformationen und Linux-Maschine vorbereiten
Schritt 2: Den Hypervisor vorbereiten
Schritt 3: Die Linux-VM zur Windows-Domäne hinzufügen
Schritt 4: .NET Runtime 6.0 installieren
Schritt 6: Linux VDA installieren
- Schritt 6a: Neuinstallation durchführen
- Schritt 6b: Vorhandene Installation aktualisieren (optional)
Schritt 7: NVIDIA GRID-Treiber installieren
Schritt 8: Linux VDA konfigurieren
Schritt 9: XDPing ausführen
Schritt 10: Linux VDA ausführen
Schritt 11: Maschinenkataloge erstellen
Schritt 12: Bereitstellungsgruppen erstellen

War dieser Artikel hilfreich?

Linux VDA manuell auf Amazon Linux 2, CentOS, RHEL und Rocky Linux installieren

Schritt 1: Konfigurationsinformationen und Linux-Maschine vorbereiten

Schritt 1a: Netzwerkkonfiguration überprüfen

Schritt 1b: Hostnamen festlegen

Schritt 1c: Loopback-Adresse dem Hostnamen zuweisen

Schritt 1d: Hostnamen überprüfen

Schritt 1e: Namensauflösung und Dienstverfügbarkeit überprüfen

Schritt 1f: Zeitsynchronisation konfigurieren

Chrony-Dienst konfigurieren

Schritt 1g: PulseAudio installieren (Nur für RHEL 9.2/9.0 und Rocky Linux 9.2/9.0)

Schritt 1h: OpenJDK 11 installieren

Schritt 1i: Eine zu verwendende Datenbank installieren und angeben

PostgreSQL installieren

SQLite installieren

Eine zu verwendende Datenbank angeben

Schritt 2: Den Hypervisor vorbereiten

Zeitsynchronisierung auf XenServer (ehemals Citrix Hypervisor™) beheben

Zeitsynchronisierung auf Microsoft Hyper-V beheben

Zeitsynchronisierung auf ESX und ESXi beheben

Schritt 3: Die Linux-VM zur Windows-Domäne hinzufügen

Samba Winbind

Winbind-Daemon beim Maschinenstart aktivieren

Winbind-Authentifizierung konfigurieren

Windows-Domäne beitreten

PAM für Winbind konfigurieren

Domänenmitgliedschaft überprüfen

Kerberos-Konfiguration überprüfen

Benutzerauthentifizierung überprüfen

Quest Authentication Services

Quest auf dem Domänencontroller konfigurieren

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

Quest auf dem Linux VDA konfigurieren

Umgehung der SELinux-Richtlinienerzwingung

VAS-Daemon konfigurieren

PAM und NSS konfigurieren

Windows-Domäne beitreten

Domänenmitgliedschaft überprüfen

Benutzerauthentifizierung überprüfen

Centrify DirectControl

Einer Windows-Domäne beitreten

SSSD

Der Domäne beitreten und einen Host-Keytab erstellen

SSSD einrichten

SSSD aktivieren

Kerberos-Konfiguration überprüfen

Benutzerauthentifizierung überprüfen

PBIS

Erforderliches PBIS-Paket herunterladen

PBIS-Installationsskript ausführbar machen

PBIS-Installationsskript ausführen

Windows-Domäne beitreten

Domänenmitgliedschaft überprüfen

Benutzerauthentifizierung überprüfen

Schritt 4: .NET Runtime 6.0 installieren

Schritt 6: Linux VDA installieren

Schritt 6a: Neuinstallation durchführen

Schritt 6b: Vorhandene Installation aktualisieren (optional)

Schritt 7: NVIDIA GRID-Treiber installieren

Schritt 8: Linux VDA konfigurieren

Konfiguration mit Eingabeaufforderung

Automatisierte Konfiguration

Konfigurationsänderungen entfernen

Konfigurationsprotokolle

Schritt 9: XDPing ausführen

Schritt 10: Linux VDA ausführen

Schritt 11: Maschinenkataloge erstellen

Schritt 12: Bereitstellungsgruppen erstellen

In diesem Artikel