Produktdokumentation
Linux Virtual Delivery Agent 2104
Current Release 2402 LTSR 2311 2308 2305 2303 2301 2212 2210 2209 2207 2206 2204 2203 LTSR 1912 LTSR 7.15 LTSR
PDF anzeigen

Installieren von Linux Virtual Delivery Agent für SUSE

June 16, 2022
Beitrag von: 
C Y

Mit den Schritten in diesem Artikel können Sie die Installation manuell durchführen, oder verwenden Sie Easy Install für die automatische Installation und Konfiguration. Easy Install spart Zeit und Arbeitskraft und ist weniger fehleranfällig als die manuelle Installation.

Hinweis:

Verwenden Sie Easy Install bei Neuinstallationen. Zum Aktualisieren von vorhandenen Installationen eignet Easy Install sich nicht.

Schritt 1: Vorbereiten der Installation

Schritt 1a: Starten des YaST-Tools

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

Starten des textbasierten YaST-Tools:

su -

yast
<!--NeedCopy-->

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

su -

yast2 &
<!--NeedCopy-->

Schritt 1b: Konfigurieren des Netzwerks

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

Konfigurieren von Hostnamen und DNS

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

Hinweis:

Der Linux VDA unterstützt derzeit nicht das Abschneiden von NetBIOS-Namen. Der Name darf daher nicht länger als 15 Zeichen sein.

Tipp:

Verwenden Sie nur Buchstaben (a-z oder A-Z), Ziffern (0-9) und Bindestriche (-). Vermeiden Sie Unterstriche (_), Leerzeichen und andere Symbole. Hostnamen sollten nicht mit einer Zahl beginnen und nicht mit einem Bindestrich enden. Diese Regel gilt auch für Delivery Controller-Hostnamen.

Deaktivieren von Multicast-DNS

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

Um mDNS zu deaktivieren, bearbeiten Sie /etc/nsswitch.conf und ändern die Zeile mit Folgendem:

hosts: files mdns_minimal [NOTFOUND=return] dns

In:

hosts: files dns

Überprüfen des Hostnamens

Stellen Sie sicher, dass der Hostname richtig festgelegt ist:

hostname
<!--NeedCopy-->

Mit diesem Befehl wird nur der Hostname der Maschine und nicht der vollqualifizierte Domänenname (FQDN) zurückgegeben.

Stellen Sie sicher, dass der FQDN richtig festgelegt ist:

hostname -f
<!--NeedCopy-->

Mit diesem Befehl wird der FQDN der Maschine zurückgegeben.

Überprüfen von Namensauflösung und Diensterreichbarkeit

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

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

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

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

Schritt 1c: Konfigurieren des NTP-Diensts

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

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

Hinweis:

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

Schritt 1d: Installieren von Linux VDA-abhängigen Paketen

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

  • 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

Hinzufügen von Repositorys

Einige erforderliche Pakete, wie PostgreSQL und ImageMagick, sind im SUSE Linux Enterprise Software Development Kit (SDK) enthalten. Für den Erhalt der Pakete fügen Sie das SDK-Repository mithilfe von YaST hinzu oder laden Sie die SDK-Imagedatei herunter und stellen Sie sie lokal mit folgenden Befehlen bereit:

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

Installieren des Kerberos-Clients

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

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

Die Kerberos-Clientkonfiguration ist abhängig von der verwendeten Active Directory-Integrationsmethode. Dies wird im Folgenden beschrieben.

Installieren von OpenJDK 11

Der Linux VDA erfordert das Vorhandensein von OpenJDK 11.

Tipp:

Stellen Sie sicher, dass nur die OpenJDK 11 installiert ist, um ein Fehlschlagen der Registrierung beim Delivery Controller zu vermeiden. Entfernen Sie alle anderen Java-Versionen vom System.

  • SLED:

  1. Prüfen Sie unter SLED, ob OpenJDK 11 installiert wurde:

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

  2. Aktualisieren Sie auf OpenJDK 11, wenn als Status veraltet gemeldet wird:

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

  3. Überprüfen Sie die Java-Version:

    java -version
<!--NeedCopy-->
  • SLES:

  1. Installieren Sie unter SLES OpenJDK 11:

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

  2. Überprüfen Sie die Java-Version:

    java -version
<!--NeedCopy-->

Installieren von PostgreSQL

Installieren Sie für SLED/SLES 12 die Pakete:

sudo zypper install postgresql-init

sudo zypper install postgresql10-server

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

Nach der Installation sind diese Schritte erforderlich, um den Datenbankdienst zu initialisieren und sicherzustellen, dass PostgreSQL beim Start der Maschine gestartet wird:

sudo systemctl enable postgresql

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

Datenbankdateien finden Sie unter /var/lib/pgsql/data.

Entfernen von Repositorys

Wenn die abhängigen Pakete installiert sind, führen Sie die folgenden Befehle aus, um das zuvor eingerichtete SDK-Repository zu entfernen und die Medienbereitstellung aufzuheben:

sudo zypper rr sdk

sudo umount /mnt/sdk

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

Schritt 2: Vorbereiten der Linux-VM für den Hypervisor

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

Festlegen der Zeitsynchronisierung auf Citrix Hypervisor

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

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

su -

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

Dieser Befehl gibt 0 oder 1 zurück:

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

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

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

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

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

xen.independent_wallclock = 1

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

reboot
<!--NeedCopy-->

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

su -

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

Dieser Befehl gibt den Wert 1 zurück.

Festlegen der Zeitsynchronisierung auf Microsoft Hyper-V

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

Auf dem verwaltenden Betriebssystem:

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

Hinweis:

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

Festlegen der Zeitsynchronisierung auf ESX und ESXi

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

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

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

Schritt 3: Hinzufügen der virtuellen Linux-Maschine zur Windows-Domäne

Der Linux VDA unterstützt mehrere Methoden zum Hinzufügen von Linux-Maschinen zur Active Directory-Domäne:

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

Hinweis:

Der Sitzungsstart kann fehlschlagen, wenn für das lokale Konto auf dem Linux VDA und das AD-Konto derselbe Benutzername verwendet wird.

Samba Winbind

Beitreten zu einer Windows-Domäne

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

  1. Öffnen Sie “YaST Windows Domain Membership”.

  2. Nehmen Sie die folgenden Änderungen vor:

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

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

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

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

  6. Eine Erfolgsmeldung wird angezeigt.

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

YaST hat Sie möglicherweise davon unterrichtet, dass für diese Änderungen einige Dienste oder die Maschine neu gestartet werden müssen. Wir empfehlen Ihnen, den Computer neu zu starten:

su -

reboot
<!--NeedCopy-->

Nur SUSE 12: Patch für Cachenamen für Kerberos-Anmeldeinformationen

SUSE 12 hat die standardmäßige Kerberos-Cachenamenspezifikation für Kerberos-Anmeldeinformationen von FILE:/tmp/krb5cc_%{uid} in DIR:/run/user/%{uid}/krb5cc geändert. Diese neue DIR-Zwischenspeichermethode ist nicht mit dem Linux VDA kompatibel und muss manuell geändert werden. Bearbeiten Sie als Root-Benutzer die Datei /etc/krb5.conf und fügen Sie die folgende Einstellung im Abschnitt [libdefaults] hinzu, falls sie nicht festgelegt ist:

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

Überprüfen der Domäneneigentümerschaft

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

Führen Sie den Samba-Befehl net ads aus, um zu prüfen, ob die Maschine zu einer Domäne gehört:

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

Überprüfen der Kerberos-Konfiguration

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

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

Mit diesem Befehl wird die Liste der Schlüssel angezeigt, die für die verschiedenen Kombinationen aus Prinzipalnamen und Verschlüsselungssammlungen verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um die Maschine mit dem Domänencontroller mit diesen Schlüsseln zu authentifizieren:

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

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

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

sudo klist
<!--NeedCopy-->

Überprüfen Sie die Maschinenkontodetails mit folgendem Befehl:

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

Überprüfen der Benutzerauthentifizierung

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

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

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

Um sich zu vergewissern, dass das Winbind-PAM-Modul fehlerfrei konfiguriert ist, melden Sie sich mit einem bislang nicht verwendeten Domänenbenutzerkonto am Linux VDA an.

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

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

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

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

klist
<!--NeedCopy-->

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

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

Quest Authentication Service

Konfigurieren von Quest auf dem Domänencontroller

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

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

Führen Sie folgende Schritte aus, damit Domänenbenutzer HDX-Sitzungen auf einer Linux VDA-Maschine herstellen können:

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

Hinweis:

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

Konfigurieren von Quest auf Linux VDA

Konfigurieren eines VAS-Daemons

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

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

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

Mit diesem Befehl wird das Verlängerungsintervall auf neun Stunden (32.400 Sekunden) festgelegt. Das ist eine Stunde weniger als die Standardgültigkeitsdauer (10 Stunden) eines Tickets. Bei Systemen mit einer kürzeren Ticketgültigkeitsdauer legen Sie diesen Parameter auf einen niedrigeren Wert fest.

Konfigurieren von PAM und NSS

Um die Domänenbenutzeranmeldung über HDX und andere Dienste wie su, ssh und RDP zu aktivieren, 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-->

Beitreten zu einer Windows-Domäne

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

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

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

Überprüfen der Domäneneigentümerschaft

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

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

Wenn die Maschine zu einer Domäne gehört, wird mit diesem Befehl der Domänenname zurückgegeben. Wenn die Maschine zu keiner Domäne gehört, wird die folgende Fehlermeldung angezeigt:

ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain

Überprüfen der Benutzerauthentifizierung

Um sicherzustellen, dass Quest Domänenbenutzer mit PAM authentifizieren kann, melden Sie sich mit einem bislang nicht verwendeten Domänenbenutzerkonto am Linux VDA an.

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

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

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

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

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

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

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

Centrify DirectControl

Beitreten zu einer Windows-Domäne

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

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

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

Überprüfen der Domäneneigentümerschaft

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

su –

adinfo
<!--NeedCopy-->

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

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

adinfo --sysinfo all

adinfo –diag
<!--NeedCopy-->

Testen Sie die Verbindung mit den verschiedenen Active Directory- und Kerberos-Diensten.

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

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

SSSD

Beim Einsatz von SSSD auf SUSE folgen Sie den Anweisungen in diesem Abschnitt. Dieser Abschnitt enthält Anweisungen zum Beitritt einer Linux VDA-Maschine zu einer Windows-Domäne und zum Konfigurieren der Kerberos-Authentifizierung.

Um SSSD für SUSE einzurichten, führen Sie die folgenden Schritte aus:

  1. Domänenbeitritt und Erstellen von Hostschlüsseltabellen
  2. Konfigurieren von PAM für SSSD
  3. Einrichten von SSSD
  4. Aktivieren von SSSD
  5. Überprüfen der Domäneneigentümerschaft
  6. Überprüfen der Kerberos-Konfiguration
  7. Überprüfen der Benutzerauthentifizierung

Domänenbeitritt und Erstellen einer Hostschlüsseltabelle

SSSD bietet keine Active Directory-Clientfunktionen für den Domänenbeitritt und die Verwaltung der Systemschlüsseltabelle. Sie können stattdessen den Samba-Ansatz verwenden. Führen Sie die folgenden Schritte aus, bevor Sie SSSD konfigurieren.

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

    sudo systemctl stop nscd

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

  2. Installieren oder aktualisieren Sie die erforderlichen Pakete:

    sudo zypper install krb5-client

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

  3. Bearbeiten Sie die /etc/krb5.conf-Datei als Root-Benutzer, damit das kinit-Hilfsprogramm mit der Zieldomäne kommunizieren kann. Fügen Sie die folgenden Einträge in den Abschnitten [libdefaults], [realms] und [domain_realm] hinzu:

    Hinweis:

    Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur. Die folgenden Einstellungen sind für das Modell mit einer Domäne und einer Gesamtstruktur 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
<!--NeedCopy-->

    realm ist der Kerberos-Bereichsname, z. B. example.com. REALM ist der Kerberos-Bereichsname in Großbuchstaben, z. B. EXAMPLE.COM. fqdn-of-domain-controller ist der FQDN des Domänencontrollers.

  4. Bearbeiten Sie /etc/samba/smb.conf als Root-Benutzer, damit das net-Hilfsprogramm mit der Zieldomäne kommunizieren kann. Fügen Sie die folgenden Einträge im Abschnitt [global] hinzu:

    [global]
    workgroup = domain

    realm = REALM

    security = ADS

    kerberos method = secrets and keytab

    client signing = yes

    client use spnego = yes
<!--NeedCopy-->

    domain ist der kurze NetBIOS-Name einer Active Directory-Domäne, z. B. EXAMPLE.

  5. Ändern Sie die Einträge passwd und group in der Datei /etc/nsswitch.conf, sodass sie beim Auflösen von Benutzern und Gruppen auf SSSD verweisen.

    passwd: compat sss

group: compat sss
<!--NeedCopy-->

  6. Treten Sie der Windows-Domäne bei. Stellen Sie sicher, dass der Domänencontroller erreichbar ist und dass Sie über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:

    sudo realm join REALM -U user
<!--NeedCopy-->

    user ist ein Domänenbenutzer mit der Berechtigung, Computer zur Domäne hinzuzufügen.

Konfigurieren von PAM für SSSD

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 Homeverzeichnisse für Benutzeranmeldungen.

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

Einrichten von SSSD

  1. Bearbeiten Sie /etc/sssd/sssd.conf als Root-Benutzer, damit der SSSD-Daemon mit der Zieldomäne kommunizieren kann. Muster einer sssd.conf-Konfiguration (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 festgelegt, sodass SSSD die Zuordnung von Windows SIDs zu Unix UIDs selbst vornimmt. Andernfalls muss Active Directory POSIX-Erweiterungen bereitstellen können. ad_gpo_access_control ist auf permissive festgelegt, um einen ungültigen Anmeldefehler für Linux-Sitzungen zu verhindern. Weitere Informationen finden Sie auf den Manpages für sssd.conf und sssd-ad.

  2. Legen Sie Dateieigentümer und Berechtigungen für sssd.conf fest:

    sudo chmod 0600 /etc/sssd/sssd.conf
<!--NeedCopy-->

Aktivieren von SSSD

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

Überprüfen der Domäneneigentümerschaft

  1. Führen Sie den Samba-Befehl net ads aus, um zu prüfen, ob die Maschine zu einer Domäne gehört:

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

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

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

Überprüfen der Kerberos-Konfiguration

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

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

Mit diesem Befehl wird die Liste der Schlüssel angezeigt, die für die verschiedenen Kombinationen aus Prinzipalnamen und Verschlüsselungssammlungen verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um die Maschine mit dem Domänencontroller mit diesen Schlüsseln zu authentifizieren:

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

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

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

sudo klist
<!--NeedCopy-->

Überprüfen der Benutzerauthentifizierung

SSSD bietet kein Befehlszeilentool zum direkten Testen der Authentifizierung mit dem Daemon, daher kann der Test nur mit PAM ausgeführt werden.

Um sich zu vergewissern, dass das SSSD-PAM-Modul fehlerfrei konfiguriert wurde, melden Sie sich mit einem bislang noch nicht verwendeten Domänenbenutzerkonto am Linux VDA an.

ssh localhost -l domain\username

id -u

klist

exit
<!--NeedCopy-->

Stellen Sie sicher, dass die vom Befehl klist zurückgegebenen Kerberos-Tickets für den Benutzer richtig und nicht abgelaufen sind.

Überprüfen Sie als Root-Benutzer, dass eine entsprechende Ticketcachedatei für die mit dem Befehl id -u zurückgegebene UID erstellt wurde:

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

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

PBIS

Download des erforderlichen PBIS-Pakets

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

Umwandeln des PBIS-Installationsskripts in eine ausführbare Datei

Beispiel:

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

Ausführen des PBIS-Installationsskripts

Beispiel:

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

Beitreten zu einer Windows-Domäne

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

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

user ist ein Domänenbenutzer mit der Berechtigung, Computer zur Active Directory-Domäne hinzuzufügen. domain-name ist der DNS-Name der Domäne, z. B. example.com.

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

Überprüfen der Domäneneigentümerschaft

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

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

Wenn die Maschine einer Domäne beigetreten ist, werden mit diesem Befehl Informationen zur aktuell beigetretenen AD-Domäne und Organisationseinheit abgefragt. Andernfalls wird nur der Hostname angezeigt.

Überprüfen der Benutzerauthentifizierung

Um sicherzustellen, dass PBIS Domänenbenutzer mit PAM authentifizieren kann, melden Sie sich mit einem bislang nicht verwendeten Domänenbenutzerkonto am Linux VDA an.

ssh localhost -l domain\user

id -u
<!--NeedCopy-->

Vergewissern Sie sich, dass eine entsprechende Cachedatei mit Kerberos-Anmeldeinformationen für die mit dem 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 4: Installieren des Linux VDA fort.

Schritt 4: Installieren des Linux VDA

Schritt 4a: Deinstallieren der alten Version

Wenn eine Version installiert ist, die älter ist als die beiden vorigen Versionen und keine LTSR-Version ist, deinstallieren Sie diese Version, bevor Sie die neue Version installieren.

  1. Halten Sie die Linux VDA-Dienste an:

    sudo /sbin/service ctxvda stop

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

    Hinweis:

    Beenden Sie erst den Monitor Service Daemon mit dem Befehl service ctxmonitorservice stop, bevor Sie die Dienste ctxvda und ctxhdx anhalten. Andernfalls startet der Monitor Service Daemon die angehaltenen Dienste neu.

  2. Deinstallieren Sie das Paket:

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

Wichtig:

Upgrades von den letzten zwei Versionen werden unterstützt.

Hinweis:

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

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

Schritt 4b: Herunterladen des Linux VDA-Pakets

Gehen Sie zur Citrix Virtual Apps and Desktops-Downloadseite. Erweitern Sie die passende Version von Citrix Virtual Apps and Desktops und klicken Sie auf Components, um das für Ihre Linux-Distribution geeignete Linux VDA-Paket herunterzuladen.

Schritt 4c: Installieren des Linux VDA

Installieren der 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. Vorher müssen folgende Abhängigkeiten aufgelöst werden:

Für SUSE 12:

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

Schritt 4d: Upgrade des Linux VDA (optional)

Sie können ein Upgrade für ein vorhandene Installation der vorherigen beiden Versionen und von einer LTSR-Version durchführen.

Für SUSE 12:

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

RPM-Abhängigkeitsliste für SUSE 12:

postgresql-server >= 9.3

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

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 5: Konfigurieren des Linux VDA

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

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

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

Konfiguration mit Aufforderungen

Führen Sie eine manuelle Konfiguration mit Aufforderungen aus:

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

Automatische Konfiguration

Bei einer automatischen Installation geben Sie die für das Setupskript erforderlichen Optionen mit Umgebungsvariablen an. Wenn alle erforderlichen Variablen vorhanden sind, werden von dem Skript keine Eingabeaufforderungen für Informationen angezeigt.

Unterstützte Umgebungsvariablen umfassen u. a.:

  • CTX_XDL_SUPPORT_DDC_AS_CNAME = Y | N – Der Linux VDA unterstützt die Angabe des Namens eines Delivery Controllers mit einem DNS CNAME-Datensatz. Die Standardeinstellung ist N.
  • CTX_XDL_DDC_LIST=‘list-ddc-fqdns’ – Der Linux VDA erfordert eine durch Leerzeichen getrennte Liste vollqualifizierter Domänennamen (FQDNs) für die 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. Dies ist standardmäßig Port 80.
  • CTX_XDL_REGISTER_SERVICE=Y | N – Die Linux Virtual Desktop-Dienste werden nach dem Systemstart gestartet. Die Standardeinstellung ist Y.
  • CTX_XDL_ADD_FIREWALL_RULES=Y | N – Für die Linux Virtual Desktop-Dienste muss die Systemfirewall eingehende Netzwerkverbindungen zulassen. Sie können die erforderlichen Ports (standardmäßig Port 80 und 1494) in der Systemfirewall automatisch für Linux Virtual Desktop öffnen. Die Standardeinstellung ist Y.
  • CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 – Der Linux VDA erfordert Kerberos-Konfigurationseinstellungen für die Authentifizierung bei den Delivery Controllern. Die Kerberos-Konfiguration wird durch das auf dem System installierte und konfigurierte Active Directory-Integrationstool bestimmt. Geben Sie die zu verwendende Active Directory-Integrationsmethode an:
    • 1 – Samba Winbind
    • 2 – Quest-Authentifizierungsdienst
    • 3 – Centrify DirectControl
    • 4 – SSSD
  • CTX_XDL_HDX_3D_PRO=Y | N – Der Linux VDA unterstützt HDX 3D Pro – GPU-Beschleunigungstechnologien zum Optimieren der Virtualisierung reichhaltiger Grafikanwendungen. Bei aktiviertem HDX 3D Pro wird der VDA für VDI-Desktopmodus (Einzelsitzungen) konfiguriert (d. h. CTX_XDL_VDI_MODE=Y).
  • CTX_XDL_VDI_MODE=Y | N – Ermöglicht die Konfiguration der Maschine als dediziertes Desktopbereitstellungsmodell (VDI) oder als gehostetes, freigegebenes Desktopbereitstellungsmodell. Legen Sie dies bei Umgebungen mit HDX 3D Pro auf “Y” fest. Standardmäßig ist diese Variable auf N festgelegt.
  • CTX_XDL_SITE_NAME=dns-name – Der Linux VDA ermittelt LDAP-Server über DNS. Geben Sie einen DNS-Sitenamen an, wenn Sie die Suchergebnisse auf eine lokale Site beschränken möchten. Die Standardeinstellung für diese Variable ist <none>.
  • CTX_XDL_LDAP_LIST=’list-ldap-servers’ – Der Linux VDA fragt DNS zur Erkennung von LDAP-Servern ab. Falls DNS keine LDAP-Diensteinträge bereitstellen kann, können Sie eine durch Leerzeichen getrennte Liste der FQDNs mit LDAP-Port angeben. Beispiel: ad1.mycompany.com:389. Die Standardeinstellung für diese Variable ist <none>.
  • CTX_XDL_SEARCH_BASE=search-base-set – Die Suchbasis bei LDAP-Abfragen des Linux VDA ist das Stammverzeichnis der Active Directory-Domäne (z. B. DC=mycompany,DC=com). Zur Verbesserung der Suchleistung können Sie eine Suchbasis angeben (z. B. OU=VDI,DC=mycompany,DC=com). Die Standardeinstellung für diese Variable ist <none>.
  • CTX_XDL_FAS_LIST=’list-fas-servers’ – Die Server für den Verbundauthentifizierungsdienst (FAS) werden über die AD-Gruppenrichtlinie konfiguriert. Der Linux VDA unterstützt die AD-Gruppenrichtlinie nicht, Sie können jedoch stattdessen eine durch Semikolons getrennte Liste mit FAS-Servern angeben. Die Reihenfolge muss mit der Reihenfolge in der AD-Gruppenrichtlinie übereinstimmen. Wenn eine Serveradresse entfernt wird, füllen Sie die leere Stelle mit der Textzeichenfolge <none> auf und ändern nicht die Reihenfolge der Serveradressen.
  • CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – Der Pfad für die Installation von .NET Core Runtime 3.1 zur Unterstützung des neuen Brokeragentdiensts (ctxvda). Der Standardpfad ist /usr/bin.
  • CTX_XDL_DESKTOP _ENVIRONMENT=gnome/mate: Legt die GNOME- oder MATE-Desktopumgebung zur Verwendung in Sitzungen fest. Wenn Sie die Variable nicht spezifizieren, wird der aktuell auf dem VDA installierte Desktop verwendet. Ist der aktuell installierte Desktop MATE, müssen Sie allerdings die Variable auf mate festlegen.

    Hinweis:

    Sie können die Desktopumgebung für Sitzungsbenutzer auch über die folgenden Schritte ändern:

    1. Erstellen Sie die Datei .xsession auf dem VDA im Verzeichnis $HOME/<username>.

    2. Geben Sie in der Datei .xsession eine auf Distributionen basierende Desktopumgebung an.

      For MATE desktop on CentOS, Ubuntu, and Debian

      MSESSION=”$(type -p mate-session)”
      if [ -n “$MSESSION” ]; then
      exec mate-session
      fi

      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   **For GNOME desktop on Ubuntu and Debian**

      GSESSION=”$(type -p gnome-session)”
      if [ -n “$GSESSION” ]; then

         exec gnome-session      fi
    3. Teilen Sie die 700-Dateiberechtigung mit dem Zielsitzungsbenutzer.
  • CTX_XDL_START_SERVICE=Y | N – Legt fest, ob die Linux VDA-Dienste gestartet werden, wenn die Linux VDA-Konfiguration abgeschlossen ist. Die Standardeinstellung ist Y.
  • CTX_XDL_TELEMETRY_SOCKET_PORT: Der Socketport zur Überwachung auf 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-->

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

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

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

Entfernen von Konfigurationsänderungen

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

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

sudo /usr/local/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

Entfernen von Konfigurationsänderungen:

sudo /usr/local/sbin/ctxcleanup.sh
<!--NeedCopy-->

Wichtig:

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

Konfigurationsprotokolle

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

/tmp/xdl.configure.log

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

Schritt 6: Ausführen des Linux VDA

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

Starten Sie den Linux VDA:

Starten der Linux VDA-Dienste:

sudo /sbin/service ctxhdx start

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

Halten Sie den Linux VDA an:

Anhalten der Linux VDA-Dienste:

sudo /sbin/service ctxvda stop

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

Hinweis:

Beenden Sie erst den Monitor Service Daemon mit dem Befehl service ctxmonitorservice stop, bevor Sie die Dienste ctxvda und ctxhdx anhalten. Andernfalls startet der Monitor Service Daemon die angehaltenen Dienste neu.

Starten Sie den Linux VDA neu:

Neustarten der Linux VDA-Dienste:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

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

Überprüfen Sie den Linux VDA-Status:

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

sudo /sbin/service ctxvda status

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

Schritt 7: Erstellen des Maschinenkatalogs in Citrix Virtual Apps oder Citrix Virtual Desktops

Der Prozess zum Erstellen von Maschinenkatalogen und Hinzufügen von Linux VDA-Maschinen ähnelt der traditionellen Windows VDA-Methode. Umfassendere Informationen zu diesen Prozessen finden Sie unter Erstellen von Maschinenkatalogen und Verwalten von Maschinenkatalogen.

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

  • Auswahl des Betriebssystems:
    • Die Option Betriebssystem für mehrere Sitzungen für ein gehostetes, freigegebenes Desktopbereitstellungsmodell.
    • Die Option Betriebssystem für Einzelsitzungen für ein VDI-dediziertes Desktopbereitstellungsmodell.
  • In einem Maschinenkatalog darf sich keine Mischung aus Linux und Windows VDA-Maschinen befinden.

Hinweis:

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

Tipp:

Wenn Sie eine Maschine aus einer Active Directory-Domäne entfernen und sie ihr dann wieder hinzufügen, muss die Maschine auch aus dem Maschinenkatalog entfernt und ihm dann erneut hinzugefügt werden.

Schritt 8: Erstellen der Bereitstellungsgruppe in Citrix Virtual Apps oder Citrix Virtual Desktops

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

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

  • Stellen Sie sicher, dass die ausgewählten Active Directory-Benutzer und -Gruppen für die Anmeldung an Linux VDA-Maschinen richtig konfiguriert wurden.
  • Lassen Sie nicht die Anmeldung nicht authentifizierter (anonymer) Benutzer zu.
  • Die Bereitstellungsgruppe darf keine Maschinenkataloge mit Windows Maschinen enthalten.

Wichtig:

Die Veröffentlichung von Anwendungen wird unter Linux VDA-Version 1.4 und höher unterstützt. Der Linux VDA unterstützt jedoch keine Bereitstellung von Desktops und Anwendungen für dieselbe Maschine.

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

Installieren von Linux Virtual Delivery Agent für SUSE
June 16, 2022
Beitrag von: 
C Y
June 16, 2022
Beitrag von: 
C Y

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.