Linux Virtual Delivery Agent 2107

Linux Virtual Delivery Agent für SUSE manuell 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: Vorbereitung der Installation

Schritt 1a: YaST-Tool starten

Das SUSE Linux Enterprise YaST-Tool wird zur Konfiguration aller Aspekte des Betriebssystems verwendet.

So starten Sie das textbasierte YaST-Tool:

su -

yast
<!--NeedCopy-->

So starten Sie das UI-basierte YaST-Tool:

su -

yast2 &
<!--NeedCopy-->

-  ### Schritt 1b: Netzwerkkonfiguration

Die folgenden Abschnitte enthalten Informationen zur Konfiguration der verschiedenen Netzwerkeinstellungen und -dienste, die vom Linux VDA verwendet werden. Die Netzwerkkonfiguration erfolgt über das YaST-Tool, nicht über andere Methoden wie den Network Manager. Diese Anweisungen basieren auf der Verwendung des UI-basierten YaST-Tools. Das textbasierte YaST-Tool kann verwendet werden, hat aber eine andere Navigationsmethode, die hier nicht dokumentiert ist.

Hostnamen und DNS konfigurieren

Öffnen Sie die YaST-Netzwerkeinstellungen.
Nur SLED 12: Ändern Sie auf der Registerkarte Globale Optionen die Netzwerkeinrichtungsmethode in Wicked Service.
Öffnen Sie die Registerkarte Hostname/DNS.
Deaktivieren Sie Hostname über DHCP ändern.
Aktivieren Sie Hostname der Loopback-IP zuweisen.
Bearbeiten Sie die folgenden Einstellungen entsprechend Ihrer Netzwerkkonfiguration:
- Hostname – Fügen Sie den DNS-Hostnamen des Computers hinzu.
- Domänenname – Fügen Sie den DNS-Domänennamen des Computers hinzu.
- Nameserver – Fügen Sie die IP-Adresse des DNS-Servers hinzu. Dies ist typischerweise die IP-Adresse des AD-Domänencontrollers.
- Domänensuchliste – Fügen Sie den DNS-Domänennamen hinzu.

Hinweis:

Der Linux VDA unterstützt derzeit keine NetBIOS-Namenskürzung. Daher darf der Hostname 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.

Multicast-DNS deaktivieren

Nur unter SLED sind die Standardeinstellungen für Multicast-DNS (mDNS) aktiviert, was zu inkonsistenten Namensauflösungsergebnissen führen kann. mDNS ist unter SLES standardmäßig nicht aktiviert, daher ist keine Aktion erforderlich.

Um mDNS zu deaktivieren, bearbeiten Sie /etc/nsswitch.conf und ändern Sie die Zeile, die Folgendes enthält:

hosts: files mdns_minimal [NOTFOUND=return] dns

Zu:

hosts: files dns

Hostnamen überprüfen

Vergewissern Sie sich, dass der Hostname korrekt eingestellt ist:

hostname
<!--NeedCopy-->

Dieser Befehl gibt nur den Hostnamen des Computers und nicht seinen vollqualifizierten Domänennamen (FQDN) zurück.

Vergewissern Sie sich, dass der FQDN korrekt eingestellt ist:

hostname -f
<!--NeedCopy-->

Dieser Befehl gibt den FQDN des Computers zurück.
Namensauflösung und Dienstverfügbarkeit überprüfen

Vergewissern Sie sich, dass Sie den FQDN auflösen und den Domänencontroller sowie den 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 keine dieser Maschinen anpingen können, überprüfen Sie die Schritte, bevor Sie fortfahren.

Schritt 1c: NTP-Dienst konfigurieren

Es ist entscheidend, eine genaue Zeitsynchronisation zwischen den VDAs, Delivery Controllern und Domänencontrollern aufrechtzuerhalten. Das Hosten des Linux VDA als virtuelle Maschine kann zu Problemen mit der Zeitverschiebung führen. Aus diesem Grund wird die Zeitpflege über einen entfernten NTP-Dienst bevorzugt. Möglicherweise sind einige Änderungen an den Standard-NTP-Einstellungen erforderlich:

Öffnen Sie die YaST-NTP-Konfiguration und wählen Sie die Registerkarte Allgemeine Einstellungen aus.
Aktivieren Sie im Abschnitt “NTP-Daemon starten” die Option Jetzt und beim Booten.
Falls vorhanden, wählen Sie den Eintrag Undisciplined Local Clock (LOCAL) aus und klicken Sie auf Löschen.
Fügen Sie einen Eintrag für einen NTP-Server hinzu, indem Sie auf Hinzufügen klicken.
Wählen Sie den Servertyp aus und klicken Sie auf Weiter.
Geben Sie den DNS-Namen des NTP-Servers in das Feld “Adresse” ein. Dieser Dienst wird normalerweise auf dem Active Directory-Domänencontroller gehostet.
Lassen Sie das Feld “Optionen” unverändert.
Klicken Sie auf Testen, um zu überprüfen, ob der NTP-Dienst erreichbar ist.
Klicken Sie in den folgenden Fenstern auf OK, um die Änderungen zu speichern.

Hinweis:

Bei SLES 12-Implementierungen kann der NTP-Daemon aufgrund eines bekannten SUSE-Problems mit AppArmor-Richtlinien möglicherweise nicht starten. Weitere Informationen finden Sie in der Lösung.

Schritt 1d: Linux VDA-abhängige Pakete installieren

Die Linux VDA-Software für SUSE Linux Enterprise hängt von den folgenden Paketen ab:

Postgresql10-server 10.12 oder höher
OpenJDK 11
OpenMotif Runtime Environment 2.3.1 oder höher
Cups 1.6.0 oder höher
Foomatic-Filter 3.0.0 oder höher
ImageMagick 6.8 oder höher

Repositorys hinzufügen

Einige erforderliche Pakete, wie PostgreSQL und ImageMagick, können Sie aus dem SUSE Linux Enterprise Software Development Kit (SDK) beziehen. Um die Pakete zu erhalten, fügen Sie das SDK-Repository über YaST hinzu oder laden Sie die SDK-Image-Datei herunter und mounten Sie sie dann lokal mit den folgenden Befehlen:

sudo mkdir -p /mnt/sdk

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

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

Kerberos-Client installieren

Installieren Sie den Kerberos-Client für die gegenseitige Authentifizierung zwischen dem Linux VDA und den Delivery Controllern:

sudo zypper install krb5-client
<!--NeedCopy-->

Die Konfiguration des Kerberos-Clients hängt davon ab, welcher Active Directory-Integrationsansatz verwendet wird. Siehe die folgende Beschreibung.

OpenJDK 11 installieren

Der Linux VDA erfordert die Anwesenheit von OpenJDK 11.

Um OpenJDK 11 zu installieren, führen Sie den folgenden Befehl aus:

sudo zypper install java-11-openjdk
<!--NeedCopy-->

PostgreSQL installieren

Installieren Sie unter SLED/SLES 12 die Pakete:

sudo zypper install postgresql-init

sudo zypper install postgresql10-server

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

Schritte nach der Installation sind erforderlich, um den Datenbankdienst zu initialisieren und um sicherzustellen, dass PostgreSQL beim Systemstart gestartet wird:

-  sudo systemctl enable postgresql

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

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

Repositorys entfernen

Nachdem die abhängigen Pakete installiert wurden, führen Sie die folgenden Befehle aus, um das zuvor eingerichtete SDK-Repository und die gemounteten Medien zu entfernen:

    -  sudo zypper rr sdk

    -  sudo umount /mnt/sdk

sudo rmdir /mnt/sdk
<!--NeedCopy-->

Schritt 2: Linux-VM für Hypervisor vorbereiten

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

Zeitsynchronisierung auf Citrix Hypervisor™ beheben

Wenn die Zeitsynchronisierungsfunktion von Citrix Hypervisor aktiviert ist, treten in jeder paravirtualisierten Linux-VM Probleme auf, da sowohl NTP als auch Citrix Hypervisor versuchen, die Systemuhr zu verwalten. Um zu vermeiden, dass die Uhr mit anderen Servern asynchron wird, muss die Systemuhr in jedem Linux-Gast mit NTP synchronisiert werden. Dieser Fall erfordert die Deaktivierung der Host-Zeitsynchronisierung. Im HVM-Modus sind keine Änderungen erforderlich.

Auf einigen Linux-Distributionen können Sie, wenn Sie einen paravirtualisierten Linux-Kernel mit installierten Citrix VM Tools ausführen, innerhalb der Linux-VM überprüfen, ob die Zeitsynchronisierungsfunktion von Citrix Hypervisor 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:

reboot
<!--NeedCopy-->

Nach dem Neustart überprüfen Sie, ob die Einstellung korrekt ist:

su -

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

Dieser Befehl gibt den Wert 1 zurück.

Zeitsynchronisierung auf Microsoft Hyper-V beheben

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

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 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 auf, da sowohl NTP als auch der Hypervisor versuchen, die Systemuhr zu synchronisieren. Um zu vermeiden, dass die Uhr mit anderen Servern asynchron wird, synchronisieren Sie die Systemuhr in jedem Linux-Gast mit NTP. Dieser Fall erfordert die Deaktivierung der Host-Zeitsynchronisierung.

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 virtuelle Linux-Maschine (VM) zur Windows-Domäne hinzufügen

Der Linux VDA unterstützt mehrere Methoden, um Linux-Maschinen zur Active Directory (AD)-Domäne hinzuzufügen:

-  [Samba Winbind](/de-de/linux-virtual-delivery-agent/2107/installation-overview/suse.html#samba-winbind)
-  [Quest Authentication Service](/de-de/linux-virtual-delivery-agent/2107/installation-overview/suse.html#quest-authentication-service)

Befolgen Sie die Anweisungen entsprechend 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

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

Öffnen Sie die YaST-Windows-Domänenmitgliedschaft.
Nehmen Sie die folgenden Änderungen vor:
- Setzen Sie die Domäne oder Arbeitsgruppe auf den Namen Ihrer Active Directory-Domäne oder die IP-Adresse des Domänencontrollers. Stellen Sie sicher, dass der Domänenname in Großbuchstaben geschrieben ist.
- Aktivieren Sie Auch SMB-Informationen für Linux-Authentifizierung verwenden.
- Aktivieren Sie Home-Verzeichnis bei Anmeldung erstellen.
- Aktivieren Sie Single Sign-on für SSH.
- Stellen Sie sicher, dass Offline-Authentifizierung nicht aktiviert ist. Diese Option ist nicht mit dem Linux VDA kompatibel.
Klicken Sie auf OK. Wenn Sie aufgefordert werden, einige Pakete zu installieren, klicken Sie auf Installieren.
Wenn ein Domänencontroller gefunden wird, werden Sie gefragt, ob Sie der Domäne beitreten möchten. Klicken Sie auf Ja.
Geben Sie bei Aufforderung die Anmeldeinformationen eines Domänenbenutzers mit Berechtigung zum Hinzufügen von Computern zur Domäne ein und klicken Sie auf OK.
Eine Erfolgsmeldung wird angezeigt.
Wenn Sie aufgefordert werden, einige Samba- und krb5-Pakete zu installieren, klicken Sie auf Installieren.

YaST hat möglicherweise darauf hingewiesen, dass diese Änderungen einige Dienste oder einen Neustart der Maschine erfordern. Wir empfehlen Ihnen, die Maschine neu zu starten:

su -

reboot
<!--NeedCopy-->

Nur SUSE 12: Kerberos-Anmeldeinformations-Cache-Namen patchen

SUSE 12 hat die Standardspezifikation für den Kerberos-Anmeldeinformations-Cache-Namen von dem üblichen FILE:/tmp/krb5cc_%{uid} in DIR:/run/user/%{uid}/krb5cc geändert. Diese neue DIR-Caching-Methode ist nicht mit dem Linux VDA kompatibel und muss manuell geändert werden. Bearbeiten Sie als Root-Benutzer die Datei /etc/krb5.conf und fügen Sie die folgende Einstellung unter dem Abschnitt [libdefaults] hinzu, falls sie nicht festgelegt ist:

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

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 Chiffriersuiten 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 mit folgendem Befehl zwischengespeichert wurde:

sudo klist
<!--NeedCopy-->

Untersuchen Sie die Details des Maschinenkontos 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 das Backslash-Zeichen (\) mit einem weiteren Backslash maskiert werden. Dieser Befehl gibt eine Meldung zurück, die den Erfolg oder Misserfolg anzeigt.

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

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 des Benutzers 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-Authentifizierungsdienst

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 aus.
Aktivieren Sie Unix-fähig.
Setzen Sie die Primäre GID-Nummer auf die Gruppen-ID einer tatsächlichen Domänenbenutzergruppe.

Hinweis:

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

Quest auf dem Linux VDA konfigurieren

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 Ticket-Lebensdauer von 10 Stunden. Setzen Sie diesen Parameter auf einen niedrigeren Wert bei Systemen mit einer kürzeren Ticket-Lebensdauer.

PAM und NSS konfigurieren

Um die Domänenbenutzeranmeldung ü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

Verbinden Sie die Linux-Maschine mit der Active Directory-Domäne mithilfe des Quest-Befehls vastool:

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

Der Benutzer ist jeder Domänenbenutzer, der über Berechtigungen zum Beitreten von Computern zur Active Directory-Domäne verfügt. Der Domänenname ist der DNS-Name der Domäne, zum Beispiel example.com.

Domänenmitgliedschaft überprüfen

Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) über ein Computerobjekt in Active Directory verfügen. 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, wird der folgende Fehler 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

Benutzerauthentifizierung überprüfen

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

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

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

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

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

Centrify DirectControl

Windows-Domäne beitreten

Nachdem der Centrify DirectControl Agent installiert wurde, treten Sie der Active Directory-Domäne mit der Centrify-Befehl adjoin bei:

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

Der Benutzer ist jeder Active Directory-Domänenbenutzer, der über Berechtigungen zum Beitreten von Computern zur Active Directory-Domäne verfügt. 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) über ein Computerobjekt in Active Directory verfügen. 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 Joined to domain gültig ist und der CentrifyDC mode den Status connected zurückgibt. Wenn der Modus im Startzustand verbleibt, 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 nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux-VDA fort.

SSSD

Wenn Sie SSSD unter SUSE 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 SUSE einzurichten, führen Sie die folgenden Schritte aus:

Der Domäne beitreten und Host-Keytabs erstellen
PAM für SSSD konfigurieren
SSSD einrichten
SSSD aktivieren
Domänenmitgliedschaft überprüfen
Kerberos-Konfiguration überprüfen
Benutzerauthentifizierung überprüfen

Der Domäne beitreten und 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 den Samba-Ansatz verwenden. Führen Sie die folgenden Schritte aus, bevor Sie SSSD konfigurieren.

Stoppen und deaktivieren Sie den Name Service Cache Daemon (NSCD).

sudo systemctl stop nscd

sudo systemctl disable nscd
<!--NeedCopy-->

Installieren oder aktualisieren Sie die erforderlichen Pakete:

sudo zypper install krb5-client

sudo zypper install samba-client
<!--NeedCopy-->

Bearbeiten Sie die Datei /etc/krb5.conf als Root-Benutzer, um dem Dienstprogramm kinit die Kommunikation mit der Zieldomäne zu ermöglichen. Fügen Sie die folgenden Einträge unter den Abschnitten [libdefaults], [realms] und [domain_realm] hinzu:

Hinweis:

Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur. Die folgenden Einstellungen sind für das Einzeldomänen-, Einzelforst-Modell vorgesehen.
```
[libdefaults]

    dns_canonicalize_hostname = false

    rdns = false

    default_realm = REALM

    forwardable = true

[realms]

    REALM = {

         kdc = fqdn-of-domain-controller

        default_domain = realm

        admin_server =     fqdn-of-domain-controller
    }
[domain_realm]

    .realm = REALM

    realm = REALM

```
realm ist der Kerberos-Realm-Name, z. B. example.com. REALM ist der Kerberos-Realm-Name in Großbuchstaben, z. B. EXAMPLE.COM. fqdn-of-domain-controller ist der FQDN des Domänencontrollers.
Bearbeiten Sie die Datei /etc/samba/smb.conf als Root-Benutzer, um dem Dienstprogramm net die Kommunikation mit der Zieldomäne zu ermöglichen. Fügen Sie die folgenden Einträge unter dem Abschnitt [global] hinzu:
```
[global]
    workgroup = domain

    realm = REALM

    security = ADS

    kerberos method = secrets and keytab

    client signing = yes

    client use spnego = yes

```
domain ist der kurze NetBIOS-Name einer Active Directory-Domäne, z. B. EXAMPLE.
Ändern Sie die Einträge passwd und group in der Datei /etc/nsswitch.conf, um SSSD beim Auflösen von Benutzern und Gruppen zu referenzieren.
```
passwd: compat sss

group: compat sss

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

```
- Benutzer ist ein Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Domäne verfügt.

PAM für SSSD konfigurieren

-  Bevor Sie PAM für SSSD konfigurieren, installieren oder aktualisieren Sie die erforderlichen Pakete:

    -  sudo zypper install sssd sssd-ad
<!--NeedCopy-->

Konfigurieren Sie das PAM-Modul für die Benutzerauthentifizierung über SSSD und erstellen Sie Home-Verzeichnisse für Benutzeranmeldungen.

-  sudo pam-config --add  --sss
-  sudo pam-config --add --mkhomedir
<!--NeedCopy-->

SSSD einrichten

Bearbeiten Sie /etc/sssd/sssd.conf als Root-Benutzer, um dem SSSD-Daemon die Kommunikation mit der Zieldomäne zu ermöglichen. Eine Beispielkonfiguration für sssd.conf (zusätzliche Optionen können bei Bedarf hinzugefügt werden):

[sssd]
    config_file_version = 2
    services = nss,pam
    domains = domain-dns-name

[domain/domain-dns-name]
    id_provider = ad
    auth_provider = ad
    access_provider = ad
    ad_domain = domain-dns-name
    ad_server = fqdn-of-domain-controller
    ldap_id_mapping = true
    ldap_schema = ad

# Kerberos settings
    krb5_ccachedir = /tmp
    krb5_ccname_template = FILE:%d/krb5cc_%U

# Comment out if the users have the shell and home dir set on the AD side

    fallback_homedir = /home/%d/%u
    default_shell = /bin/bash

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available

# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM

    ad_gpo_access_control = permissive

<!--NeedCopy-->

domain-dns-name ist der DNS-Domänenname, z. B. example.com.

Hinweis:

ldap_id_mapping ist auf true gesetzt, damit SSSD selbst die Zuordnung von Windows-SIDs zu Unix-UIDs übernimmt. Andernfalls muss Active Directory POSIX-Erweiterungen bereitstellen können. ad_gpo_access_control ist auf permissive gesetzt, um einen Fehler bei der ungültigen Anmeldung für Linux-Sitzungen zu verhindern. Siehe die Manpages für sssd.conf und sssd-ad.

Legen Sie die Dateiberechtigungen und den Dateibesitz für sssd.conf fest:
```
sudo chmod 0600 /etc/sssd/sssd.conf

```

SSSD aktivieren

Führen Sie die folgenden Befehle aus, um den SSSD-Daemon beim Systemstart zu aktivieren und zu starten:

sudo systemctl enable sssd
sudo systemctl start sssd
<!--NeedCopy-->

Domänenmitgliedschaft überprüfen

Führen Sie den net ads-Befehl von Samba aus, um zu überprüfen, ob der Computer einer Domäne beigetreten ist:
```
sudo net ads testjoin

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

```

Kerberos-Konfiguration überprüfen

Um zu überprüfen, ob Kerberos für die Verwendung mit dem Linux VDA korrekt konfiguriert ist, vergewissern Sie sich, dass die System-Keytab-Datei 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 Computer- 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 Computerkonto mit folgendem Befehl zwischengespeichert wurde:

sudo klist
<!--NeedCopy-->

Benutzerauthentifizierung überprüfen

SSSD bietet kein Befehlszeilentool zum direkten Testen der Authentifizierung mit dem Daemon und kann nur über PAM erfolgen.

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

ssh localhost -l domain\\username

id -u

klist

exit
<!--NeedCopy-->

Überprüfen Sie, ob die vom Befehl klist zurückgegebenen Kerberos-Tickets für diesen Benutzer korrekt sind und nicht abgelaufen sind.

Überprüfen Sie als Root-Benutzer, ob eine entsprechende Ticket-Cache-Datei für die UID erstellt wurde, die vom vorherigen Befehl id -u zurückgegeben wurde:

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

PBIS

Erforderliches PBIS-Paket herunterladen

Zum Beispiel:

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

PBIS-Installationsskript ausführbar machen

Zum Beispiel:

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

PBIS-Installationsskript ausführen

Zum Beispiel:

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

Einer 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 die 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 zuvor 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 UID erstellt wurde, die vom Befehl id -u zurückgegeben wird:

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

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

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

Schritt 4: Installieren von .NET Core Runtime 3.1 als Voraussetzung

Vor der Installation des Linux VDA installieren Sie .NET Core Runtime 3.1 gemäß den Anweisungen unter https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

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

Basierend auf der Befehlsausgabe legen Sie den Binärpfad der .NET Core Runtime fest. Wenn die Befehlsausgabe beispielsweise /aa/bb/dotnet lautet, verwenden Sie /aa/bb als .NET-Binärpfad.

Schritt 5: Herunterladen des Linux VDA-Pakets

Gehen Sie zur Downloadseite von Citrix Virtual Apps and Desktops™. Erweitern Sie die entsprechende Version von Citrix Virtual Apps and Desktops und klicken Sie auf Components, um das Linux VDA-Paket herunterzuladen, das Ihrer Linux-Distribution entspricht.

Schritt 6: Installieren des Linux VDA

Schritt 6a: Deinstallieren der alten Version

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.

Beenden Sie die Linux VDA-Dienste:
```
sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

```
Hinweis:

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

Deinstallieren Sie das Paket:

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

Wichtig:

Ein Upgrade von den letzten beiden Versionen wird unterstützt.

Hinweis:

Installationskomponenten befinden sich in /opt/Citrix/VDA/.

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.

Schritt 6b: Installieren des Linux VDA

Installieren Sie die Linux VDA-Software mit Zypper:

Für SUSE 12:

sudo zypper install XenDesktopVDA-<version>.sle12_x.x86_64.rpm
<!--NeedCopy-->

Installieren Sie die Linux VDA-Software mit dem RPM-Paketmanager. Bevor Sie dies tun, lösen Sie die folgenden Abhängigkeiten auf:

Für SUSE 12:

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

Schritt 6c: Aktualisieren des Linux VDA (optional)

Sie können eine bestehende Installation von den beiden vorherigen Versionen und von einer LTSR-Version aktualisieren.

Hinweis:

Das Aktualisieren einer bestehenden Installation überschreibt die Konfigurationsdateien unter /etc/xdl. Bevor Sie ein Upgrade durchführen, stellen Sie sicher, dass Sie die Dateien sichern.

Für SUSE 12:

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

RPM-Abhängigkeitsliste für SUSE 12:

mozilla-nss-tools >= 3.47.1

postgresql-server >= 10.12

postgresql-jdbc >= 9.2

java-11-openjdk >= 11

ImageMagick >= 6.8

dbus-1 >= 1.8.8

dbus-1-x11 >= 1.8.8

libXpm4 >= 3.5.11

libXrandr2 >= 1.4.2

libXtst6 >= 1.2.2

motif >= 2.3

pam >= 1.1.8

bash >= 4.2

findutils >= 4.5

gawk >= 4.1

sed >= 4.2

cups >= 1.6.0

cups-filters-foomatic-rip >= 1.0.0

openldap2 >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

libmspack0 >= 0.4

python-requests >= 2.8.1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsLzma) <= 4.4.6-1

libtcmalloc4 >= 2.5

libcap-progs >= 2.22

xorg-x11-server >= 7.6_1.18.3-76.15

ibus >= 1.5

xorg- x11-server = 7.6_1.19.6

xorg-x11 = 7.6_1

postgresql10-server >= 10.12

libgtk-2_0-0 >= 2.24

libgthread-2_0-0 >= 2.48

pulseaudio-utils >= 5.0

lsb-release >= 2.0
<!--NeedCopy-->

Wichtig:

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

Schritt 7: Konfigurieren des Linux VDA

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 ausführen oder automatisch mit vorkonfigurierten Antworten. Überprüfen Sie die Hilfe zum Skript, bevor Sie fortfahren:

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

Konfiguration mit Abfragen

Führen Sie eine manuelle Konfiguration mit Abfragen durch:

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

Automatisierte Konfiguration

Für eine automatisierte Installation stellen Sie die vom Setup-Skript benötigten Optionen über Umgebungsvariablen bereit. Sind alle erforderlichen Variablen vorhanden, fordert das Skript keine Informationen an.

Unterstützte Umgebungsvariablen sind:

CTX_XDL_SUPPORT_DDC_AS_CNAME=Y | N – Der Linux VDA unterstützt die Angabe eines Delivery Controller-Namens mithilfe eines DNS-CNAME-Eintrags. Standardmäßig auf N gesetzt.
CTX_XDL_DDC_LIST=’list-ddc-fqdns’ – Der Linux VDA benötigt eine durch Leerzeichen getrennte Liste von Delivery Controller-FQDNs (Fully Qualified Domain Names) zur Registrierung bei einem Delivery Controller. Mindestens ein FQDN oder CNAME-Alias muss angegeben werden.
CTX_XDL_VDA_PORT=port-number – Der Linux VDA kommuniziert mit Delivery Controllern über einen TCP/IP-Port, der standardmäßig Port 80 ist.
CTX_XDL_REGISTER_SERVICE=Y | N – Die Linux Virtual Desktop-Dienste werden nach dem Start der Maschine gestartet. Der Wert ist standardmäßig auf Y gesetzt.
- CTX_XDL_ADD_FIREWALL_RULES=Y | N – Die Linux Virtual Desktop-Dienste erfordern, dass eingehende Netzwerkverbindungen über die Systemfirewall zugelassen werden. Sie können die erforderlichen Ports (standardmäßig Ports 80 und 1494) automatisch in der Systemfirewall für den Linux Virtual Desktop öffnen. Standardmäßig auf Y gesetzt.
- CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 – Der Linux VDA benötigt Kerberos-Konfigurationseinstellungen zur Authentifizierung bei den Delivery Controllern. Die Kerberos-Konfiguration wird aus dem installierten und konfigurierten Active Directory-Integrationstool auf dem System bestimmt. Geben Sie die zu verwendende unterstützte Active Directory-Integrationsmethode an:
- 1 – Samba Winbind
- 2 – Quest Authentication Service
- 3 – Centrify DirectControl
- 4 – SSSD
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 den VDI-Desktop-Modus (Einzelsitzung) konfiguriert – (d. h. CTX_XDL_VDI_MODE=Y).
CTX_XDL_VDI_MODE=Y | N – 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 diese Variable auf Y. Diese Variable ist standardmäßig auf N gesetzt.
CTX_XDL_SITE_NAME=dns-name – Der Linux VDA entdeckt LDAP-Server über DNS. Um die DNS-Suchergebnisse auf einen lokalen Standort zu beschränken, geben Sie einen DNS-Standortnamen an. Diese Variable ist standardmäßig auf <none> gesetzt.
CTX_XDL_LDAP_LIST=’list-ldap-servers’ – Der Linux VDA fragt DNS ab, um LDAP-Server zu entdecken. Wenn DNS keine LDAP-Diensteinträge bereitstellen kann, können Sie eine durch Leerzeichen getrennte Liste von LDAP-FQDNs mit LDAP-Ports angeben. Zum Beispiel: ad1.mycompany.com:389. Diese Variable ist standardmäßig auf <none> gesetzt.
CTX_XDL_SEARCH_BASE=search-base-set – Der Linux VDA fragt LDAP über eine Suchbasis ab, die auf das Root 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). Diese Variable ist standardmäßig auf <none> gesetzt.
CTX_XDL_FAS_LIST=’list-fas-servers’ – Die Federated Authentication Service (FAS)-Server werden über AD-Gruppenrichtlinien konfiguriert. Der Linux VDA unterstützt keine AD-Gruppenrichtlinien, aber Sie können stattdessen eine durch Semikolons getrennte Liste von FAS-Servern bereitstellen. Die Reihenfolge muss dieselbe sein wie in den AD-Gruppenrichtlinien konfiguriert. Wenn eine Serveradresse entfernt wird, füllen Sie die Lücke mit dem Textstring <none> und ändern Sie die Reihenfolge der Serveradressen nicht.
CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – Der Pfad zur Installation der .NET Core Runtime 3.1 zur Unterstützung des neuen Broker-Agent-Dienstes (ctxvda). Der Standardpfad ist /usr/bin.
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/mate – Gibt die GNOME- oder MATE-Desktopumgebung an, die in Sitzungen verwendet werden soll. Wenn Sie die Variable nicht angeben, wird der derzeit auf dem VDA installierte Desktop verwendet. Wenn der derzeit installierte Desktop jedoch MATE ist, müssen Sie den Variablenwert auf mate setzen.
Hinweis:

Sie können die Desktopumgebung für einen Zielsitzungsbenutzer 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 Desktopumgebung basierend auf den Distributionen anzugeben.
Für MATE-Desktop unter CentOS, Ubuntu und Debian:
```
MSESSION="$(type -p mate-session)"
if [ -n "$MSESSION" ]; then
  exec mate-session
fi
   
```
Für GNOME-Desktop unter CentOS:
```
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 unter Ubuntu und Debian:
```
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
    exec gnome-session
fi
   
```
1. Teilen Sie die 700-Dateiberechtigung mit dem Zielsitzungsbenutzer.
CTX_XDL_START_SERVICE=Y | N – Gibt an, ob die Linux VDA-Dienste gestartet werden, wenn die Linux VDA-Konfiguration abgeschlossen ist. Standardmäßig auf Y gesetzt.
CTX_XDL_TELEMETRY_SOCKET_PORT – Der Socket-Port zum Abhören von Citrix Scout. Der Standardport ist 7503.
CTX_XDL_TELEMETRY_PORT – Der Port für die Kommunikation mit Citrix Scout. Der Standardport ist 7502.

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

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

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_FAS_LIST=‘list-fas-servers’ | '<none>'

export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime

export CTX_XDL_DESKTOP_ENVIRONMENT= gnome | mate | '<none>'

export CTX_XDL_TELEMETRY_SOCKET_PORT=port-number

export CTX_XDL_TELEMETRY_PORT=port-number

export CTX_XDL_START_SERVICE=Y|N

sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--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 er erstellt. Wir empfehlen, eine Shell-Skriptdatei aus den vorangehenden Befehlen mit #!/bin/bash als erster Zeile zu erstellen.

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

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST=‘list-ddc-fqdns’ \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST=‘list-ldap-servers’ \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST=‘list-fas-servers’ \

CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \

CTX_XDL_DESKTOP_ENVIRONMENT=gnome | mate \

CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \

CTX_XDL_TELEMETRY_PORT=port-number \

CTX_XDL_START_SERVICE=Y|N \

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

Konfigurationsänderungen entfernen

In einigen Szenarien müssen Sie möglicherweise die durch das 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 /usr/local/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

So entfernen Sie Konfigurationsänderungen:

sudo /usr/local/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 eine Konfigurationsprotokolldatei geschrieben werden:

/tmp/xdl.configure.log

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

Schritt 8: 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 9: 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 /sbin/service ctxhdx start

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

Linux VDA anhalten:

So halten Sie die Linux VDA-Dienste an:

sudo /sbin/service ctxvda stop

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

Hinweis:

Bevor Sie die Dienste ctxvda und ctxhdx anhalten, führen Sie den Befehl service ctxmonitorservice stop aus, um den Überwachungsdienst-Daemon anzuhalten. Andernfalls startet der Überwachungsdienst-Daemon die von Ihnen angehaltenen Dienste neu.

Linux VDA neu starten:

So starten Sie die Linux VDA-Dienste neu:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

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

Status des Linux VDA überprüfen:

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

sudo /sbin/service ctxvda status

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

Schritt 10: Maschinenkatalog in Citrix Virtual Apps oder Citrix Virtual Desktops™ 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 Maschinenkataloge erstellen und Maschinenkataloge verwalten.

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 für gehostete Shared Desktops.
- Die Option Single-session OS für ein VDI-Bereitstellungsmodell für dedizierte Desktops.
Mischen Sie keine Linux- und Windows VDA-Maschinen im selben Maschinenkatalog.

Hinweis:

Frühe Versionen von Citrix Studio unterstützten den Begriff „Linux-Betriebssystem“ 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 mit einem einzelnen Benutzer pro Maschine.

Tipp:

Wenn Sie eine Maschine aus der Active Directory-Domäne entfernen und wieder hinzufügen, müssen Sie die Maschine erneut aus dem Maschinenkatalog entfernen und hinzufügen.

Schritt 11: Erstellen der Bereitstellungsgruppe in Citrix Virtual Apps™ oder Citrix Virtual Desktops

Der Prozess zum Erstellen einer Bereitstellungsgruppe und 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 Bereitstellungsgruppen erstellen.

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.
Gestatten Sie die Anmeldung von nicht authentifizierten (anonymen) Benutzern nicht.
Mischen Sie die Bereitstellungsgruppe nicht mit Maschinenkatalogen, die Windows-Maschinen enthalten.

Wichtig:

Die Veröffentlichung von Anwendungen wird ab Linux VDA Version 1.4 und höher 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 2106.

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.

Linux Virtual Delivery Agent für SUSE manuell installieren

May 6, 2026

Beitrag von:

C C

May 6, 2026

Beitrag von:

C C

In diesem Artikel

Schritt 1: Vorbereitung der Installation
Schritt 2: Linux-VM für Hypervisor vorbereiten
Schritt 3: Die virtuelle Linux-Maschine (VM) zur Windows-Domäne hinzufügen
Schritt 4: Installieren von .NET Core Runtime 3.1 als Voraussetzung
Schritt 5: Herunterladen des Linux VDA-Pakets
Schritt 6: Installieren des Linux VDA
Schritt 7: Konfigurieren des Linux VDA
Schritt 8: XDPing ausführen
Schritt 9: Linux VDA ausführen
Schritt 10: Maschinenkatalog in Citrix Virtual Apps oder Citrix Virtual Desktops™ erstellen
Schritt 11: Erstellen der Bereitstellungsgruppe in Citrix Virtual Apps™ oder Citrix Virtual Desktops

Linux Virtual Delivery Agent für SUSE manuell installieren

Schritt 1: Vorbereitung der Installation

Schritt 1a: YaST-Tool starten

Hostnamen und DNS konfigurieren

Multicast-DNS deaktivieren

Hostnamen überprüfen

Namensauflösung und Dienstverfügbarkeit überprüfen

Schritt 1c: NTP-Dienst konfigurieren

Schritt 1d: Linux VDA-abhängige Pakete installieren

Repositorys hinzufügen

Kerberos-Client installieren

OpenJDK 11 installieren

PostgreSQL installieren

Repositorys entfernen

Schritt 2: Linux-VM für Hypervisor vorbereiten

Zeitsynchronisierung auf Citrix Hypervisor™ beheben

Zeitsynchronisierung auf Microsoft Hyper-V beheben

Zeitsynchronisierung auf ESX und ESXi beheben

Schritt 3: Die virtuelle Linux-Maschine (VM) zur Windows-Domäne hinzufügen

Samba Winbind

Windows-Domäne beitreten

Nur SUSE 12: Kerberos-Anmeldeinformations-Cache-Namen patchen

Domänenmitgliedschaft überprüfen

Kerberos-Konfiguration überprüfen

Benutzerauthentifizierung überprüfen

Quest-Authentifizierungsdienst

Quest auf dem Domänencontroller konfigurieren

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

Quest auf dem Linux VDA konfigurieren

VAS-Daemon konfigurieren

PAM und NSS konfigurieren

Windows-Domäne beitreten

Domänenmitgliedschaft überprüfen

Benutzerauthentifizierung überprüfen

Centrify DirectControl

Windows-Domäne beitreten

Domänenmitgliedschaft überprüfen

SSSD

Der Domäne beitreten und Host-Keytab erstellen

PAM für SSSD konfigurieren

SSSD einrichten

SSSD aktivieren

Domänenmitgliedschaft überprüfen

Kerberos-Konfiguration überprüfen

Benutzerauthentifizierung überprüfen

PBIS

Erforderliches PBIS-Paket herunterladen

PBIS-Installationsskript ausführbar machen

PBIS-Installationsskript ausführen

Einer Windows-Domäne beitreten

Domänenmitgliedschaft überprüfen

Benutzerauthentifizierung überprüfen

Schritt 4: Installieren von .NET Core Runtime 3.1 als Voraussetzung

Schritt 5: Herunterladen des Linux VDA-Pakets

Schritt 6: Installieren des Linux VDA

Schritt 6a: Deinstallieren der alten Version

Schritt 6b: Installieren des Linux VDA

Schritt 6c: Aktualisieren des Linux VDA (optional)

Schritt 7: Konfigurieren des Linux VDA

Konfiguration mit Abfragen

Automatisierte Konfiguration

Konfigurationsänderungen entfernen

Konfigurationsprotokolle

Schritt 8: XDPing ausführen

Schritt 9: Linux VDA ausführen

Schritt 10: Maschinenkatalog in Citrix Virtual Apps oder Citrix Virtual Desktops™ erstellen

Schritt 11: Erstellen der Bereitstellungsgruppe in Citrix Virtual Apps™ oder Citrix Virtual Desktops

In diesem Artikel