Linux Virtual Delivery Agent 2109

Manuelle Installation von Linux Virtual Delivery Agent für RHEL/CentOS

August 20, 2024

Beitrag von:

C Y

Wichtig:

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

Schritt 1: Vorbereiten von RHEL 8/CentOS 8, RHEL 7/CentOS 7 für die VDA-Installation

Schritt 1a: Überprüfen der Netzwerkkonfiguration

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

Schritt 1b: Festlegen des Hostnamens

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

hostname

Schritt 1c: Zuweisen einer Loopbackadresse für den Hostnamen

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

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

Beispiel:

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

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

Hinweis:

Der Linux VDA unterstützt derzeit nicht das Abschneiden von NetBIOS-Namen. Der Hostname 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.

Schritt 1d: Ü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-->

Dieser Befehl gibt den FQDN der Maschine zurück.

Schritt 1e: Ü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 1f: Konfigurieren der Uhrsynchronisierung

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

In RHEL 8-/RHEL 7-Standardumgebungen wird der Chrony-Daemon (chronyd) für die Uhrsynchronisierung verwendet.

Konfigurieren des Chrony-Diensts

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

server peer1-fqdn-or-ip-address iburst

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

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

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

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

sudo /sbin/service chronyd restart
<!--NeedCopy-->

Schritt 1g: Installieren von OpenJDK 11

Der Linux VDA erfordert das Vorhandensein von OpenJDK 11. Die Laufzeitumgebung wird bei der Installation des Linux VDAs automatisch als Abhängigkeit installiert.

Bestätigen Sie die richtige Version:

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

Das OpenJDK-Paket ist möglicherweise eine frühere Version. Update auf OpenJDK 11:

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

Schritt 1h: Installieren von PostgreSQL

Der Linux VDA erfordert auf RHEL 8 PostgreSQL 10.5 oder höher und auf RHEL 7 PostgreSQL 9.2 oder höher.

Installieren Sie die folgenden Pakete:

sudo yum -y install postgresql-server

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

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

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

Schritt 1i: Starten von PostgreSQL

Konfigurieren Sie den Dienst so, dass er beim Systemstart der Maschine startet und sofort startet:

sudo systemctl enable postgresql

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

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

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

(Nur RHEL 7) Stellen Sie mit dem psql-Befehlszeilenprogramm sicher, dass das Datenverzeichnis festgelegt ist:

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

Schritt 2: Vorbereiten des Hypervisors

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.

Deaktivieren Sie gegebenenfalls das Zeitsynchronisierungsfeature, indem Sie 1 in die Datei schreiben:

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:

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. Um sicherzustellen, dass die Betriebssystemzeit korrekt ist, müssen Sie das Feature zusätzlich zu den NTP-Diensten aktivieren.

Auf dem verwaltenden Betriebssystem:

Öffnen Sie die Hyper-V-Manager-Konsole.
Wählen Sie für die Einstellungen einer Linux-VM Integration Services aus.
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 synchronisieren. 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.

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

Öffnen Sie den vSphere-Client.
Bearbeiten Sie die Einstellungen für die Linux-VM.
Öffnen Sie im Dialogfeld Virtual Machine Properties die Registerkarte Options.
Wählen Sie VMware Tools.
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

Installieren oder aktualisieren Sie die erforderlichen Pakete:

RHEL 8/CentOS 8:

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

Für RHEL 7/CentOS 7:

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

Starten des Winbind-Daemon beim Booten

Der Winbind-Daemon muss beim Systemstart gestartet werden:

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

Konfigurieren der Winbind-Authentifizierung

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

Führen Sie den folgenden Befehl aus.

RHEL 8:
```
sudo authselect select winbind with-mkhomedir --force

```
RHEL 7:
```
sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall

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

Wenn eine DNS-basierte Suche nach dem KDC-Server und -Bereichsnamen erforderlich ist, fügen Sie dem vorherigen Befehl die folgenden beiden Optionen hinzu:

--enablekrb5kdcdns --enablekrb5realmdns

Ignorieren Sie alle Fehler hinsichtlich des winbind-Dienststarts, die vom Befehl authconfig zurückgegeben wurden. Diese Fehler können auftreten, wenn authconfig versucht, den winbind-Dienst zu starten, bevor die Maschine mit einer Domäne verbunden wurde.
Öffnen Sie die Datei /etc/samba/smb.conf und fügen Sie im Abschnitt [Global] nach dem von dem Tool authconfig erstellten Abschnitt die folgenden Einträge hinzu:

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

Unter dem Abschnitt [libdefaults]:

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

Unter dem Abschnitt [realms]:

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

Unter dem Abschnitt [domain_realm]:

realm = REALM
.realm = REALM

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

Windows-Domäne beitreten

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:

RHEL 8:

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

RHEL 7:

sudo net ads join REALM -U user
<!--NeedCopy-->

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

PAM für Winbind konfigurieren

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

krb5_auth = yes
krb5_ccache_type = FILE
mkhomedir = yes

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

sudo /sbin/service winbind restart
<!--NeedCopy-->

Tipp:

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

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

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

Domäneneigentümerschaft überprüfen

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

Kerberos-Konfiguration überprüfen

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

Benutzerauthentifizierung überprüfen

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

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 6: Installieren des Linux VDA fort.

Quest Authentication Services

Quest auf dem Domänencontroller konfigurieren

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:

Öffnen Sie in der Verwaltungskonsole für Active Directory-Benutzer und -Computer die Active Directory-Eigenschaften für das jeweilige Benutzerkonto.
Wählen Sie die Registerkarte Unix Account aus.
Aktivieren Sie das Kontrollkästchen Unix-enabled.
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.

Quest auf Linux VDA konfigurieren

Workaround bei SELinux-Richtlinienerzwingung

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

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

SELINUX=permissive

Diese Änderung erfordert einen Neustart der Maschine:

reboot
<!--NeedCopy-->

Wichtig:

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

VAS-Daemon konfigurieren

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.

PAM und NSS konfigurieren

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

Windows-Domäne beitreten

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.

Domäneneigentümerschaft überprüfen

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

Benutzerauthentifizierung überprüfen

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

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

Der Parameter “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.

Domäneneigentümerschaft überprüfen

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

Überprüfen Sie, ob 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 6: Installieren des Linux VDA fort.

SSSD

Beim Einsatz von SSSD 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.

Das Einrichten von SSSD unter RHEL und CentOS umfasst die folgenden Schritte:

Domänenbeitritt und Erstellen einer Hostschlüsseltabelle
SSSD einrichten
Aktivieren von SSSD
Überprüfen der Kerberos-Konfiguration
Benutzerauthentifizierung überprüfen

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 adcli, realmd oder Samba verwenden.

In diesem Abschnitt werden die Samba- und adcli-Methoden für RHEL 7 bzw. RHEL 8 beschrieben. Informationen über realmd finden Sie in der Dokumentation zu RHEL oder CentOS. Diese Schritte müssen vor der Konfiguration von SSSD ausgeführt werden.

Samba (RHEL 7):

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

Hinweis:

Die Einstellungen in diesem Artikel sind für das Modell mit einer Domäne und einer Gesamtstruktur vorgesehen. Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur.

Wenn eine DNS-basierte Suche nach dem KDC-Server und -Bereichsnamen erforderlich ist, fügen Sie dem vorherigen Befehl die folgenden beiden Optionen hinzu:

--enablekrb5kdcdns --enablekrb5realmdns

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

kerberos method = secrets and keytab
winbind offline logon = no

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 net ads join REALM -U user
 
```
REALM ist der Kerberos-Bereichsname in Großbuchstaben und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.
Adcli (RHEL 8):

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

Im Abschnitt [realms]:

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

Im Abschnitt [domain_realm]:

realm = REALM .realm = REALM

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
 
```
REALM ist der Kerberos-Bereichsname in Großbuchstaben und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.

SSSD einrichten

Die Einrichtung von SSSD umfasst die folgenden Schritte:

Installieren Sie das Paket sssd-ad auf dem Linux VDA, indem Sie den Befehl sudo yum -y install sssd ausführen.
Ändern Sie die Konfiguration verschiedener Dateien (Beispiel: sssd.conf).
Starten Sie den Dienst sssd.

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

Beispiel einer SSSD-Konfiguration für RHEL 7

Ersetzen Sie ad.example.com und server.ad.example.com durch den jeweils gültigen Wert. Weitere Informationen finden Sie unter sssd-ad(5) - Linux man page.

(nur RHEL 8) Öffnen Sie /etc/sssd/sssd.conf und fügen Sie dem Abschnitt [domain/ad.example.com] folgende Einträge hinzu:

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

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

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

Aktivieren von SSSD

RHEL 8:

Um SSSD zu aktivieren, führen Sie den folgenden Befehl aus:

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

RHEL 7/CentOS 7:

Aktivieren Sie SSSD mit authconfig. Installieren Sie oddjob-mkhomedir, damit die Erstellung des Homeverzeichnisses mit SELinux kompatibel ist:

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

sudo service sssd start

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

Kerberos-Konfiguration überprüfen

Überprüfen Sie, ob die Schlüsseltabelle-Systemdatei 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 zu authentifizieren, die diese Schlüssel verwendet:

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

Benutzerauthentifizierung überprüfen

Prüfen Sie mit dem Befehl getent, ob das Anmeldeformat unterstützt wird und NSS funktioniert:

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

Der Parameter DOMAIN ist die kurze Version des Domänennamens. Wenn ein anderes Anmeldeformat von erforderlich ist, überprüfen Sie dies zunächst mit dem Befehl getent.

Unterstützte Anmeldeformate:

Down-Level-Anmeldename: DOMAIN\username
UPN: username@domain.com
NetBIOS-Suffix-Format: username@DOMAIN

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.

sudo ssh localhost –l DOMAIN\username

id -u
<!--NeedCopy-->

Vergewissern Sie sich, dass eine entsprechende Cachedatei mit Kerberos-Anmeldeinformationen für die mit dem folgenden Befehl 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-->

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

PBIS

Download des erforderlichen PBIS-Pakets

Beispiel RHEL 7/CentOS 7:

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

Beispiel RHEL 8/CentOS8:

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

Umwandeln des PBIS-Installationsskripts in eine ausführbare Datei

Beispiel RHEL 7/CentOS 7:

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

Beispiel RHEL 8/CentOS 8:

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

Ausführen des PBIS-Installationsskripts

Beispiel RHEL 7/CentOS 7:

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

Beispiel RHEL 8/CentOS 8:

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

Windows-Domäne beitreten

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.

Domäneneigentümerschaft überprüfen

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.

Benutzerauthentifizierung überprüfen

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 6: Installieren des Linux VDA fort.

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

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

Führen Sie nach der Installation von .NET Core Runtime 3.1 den Befehl which dotnet aus, um Ihren Laufzeitpfad zu finden.

Legen Sie basierend auf der Ausgabe des Befehls den Binärpfad für die .NET Core-Laufzeitumgebung fest. Wenn die Befehlsausgabe beispielsweise /aa/bb/dotnet ist, verwenden Sie /aa/bb als .NET-Binärpfad.

Schritt 5: 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 6: Installieren des Linux VDA

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

Durchführen einer Neuinstallation

(Optional) Deinstallieren Sie die alte 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

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

```
Hinweis:

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.
Laden Sie das Linux VDA -Paket herunter

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.

Installieren des Linux VDA

Installieren Sie die Linux VDA-Software mit Yum:

RHEL 8/CentOS 8:

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

Für RHEL 7/CentOS 7:

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

Installieren Sie die Linux VDA-Software mit dem RPM-Paketmanager. Vorher müssen folgende Abhängigkeiten aufgelöst werden:

RHEL 8/CentOS 8:

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

Für RHEL 7/CentOS 7:

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

RPM-Abhängigkeitsliste für RHEL 8/CentOS 8:

 qt5-qtbase >= 5.5~

 ibus >= 1.5

 nss-tools >= 3.44.0

 gperftools-libs >= 2.4

 cyrus-sasl-gssapi >= 2.1

 python2 >= 2.7~

 postgresql-jdbc >= 42.2.3

 postgresql-server >= 10.6

 java-11-openjdk >= 11

 icoutils >= 0.32

 firewalld >= 0.8.0

 policycoreutils-python-utils >= 2.9

 python3-policycoreutils >= 2.9

 dbus >= 1.12.8

 dbus-common >= 1.12.8

 dbus-daemon >= 1.12.8

 dbus-tools >= 1.12.8

 dbus-x11 >= 1.12.8

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.4

 libXpm >= 3.5.12

 libXrandr >= 1.5.1

 libXtst >= 1.2.3

 motif >= 2.3.4

 pam >= 1.3.1

 util-linux >= 2.32.1

 util-linux-user >= 2.32.1

 xorg-x11-utils >= 7.5

 bash >= 4.4

 findutils >= 4.6

 gawk >= 4.2

 sed >= 4.5

 cups >= 2.2

 foomatic-filters >= 4.0.9

 cups-filters >= 1.20.0

 ghostscript >= 9.25

 libxml2 >= 2.9

 libmspack >= 0.7
 <!--NeedCopy-->

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

 qt5-qtbase >= 5.5~

 libmspack >= 0.5

 ibus >= 1.5

 cyrus-sasl-gssapi >= 2.1

 gperftools-libs >= 2.4

 nss-tools >= 3.44.0

 postgresql-server >= 9.2

 postgresql-jdbc >= 9.2

 java-11-openjdk >= 11

 ImageMagick >= 6.7.8.9

 firewalld >= 0.3.9

 policycoreutils-python >= 2.0.83

 dbus >= 1.6.12

 dbus-x11 >= 1.6.12

 xorg-x11-server-utils >= 7.7

 xorg-x11-xinit >= 1.3.2

 libXpm >= 3.5.10

 libXrandr >= 1.4.1

 libXtst >= 1.2.2

 motif >= 2.3.4

 pam >= 1.1.8

 util-linux >= 2.23.2

 bash >= 4.2

 findutils >= 4.5

 gawk >= 4.0

 sed >= 4.2

 cups >= 1.6.0

 foomatic-filters >= 4.0.9

 openldap >= 2.4

 cyrus-sasl >= 2.1

 cyrus-sasl-gssapi >= 2.1

 libxml2 >= 2.9

 python-requests >= 2.6.0

 gperftools-libs >= 2.4

 rpmlib(FileDigests) <= 4.6.0-1

 rpmlib(PayloadFilesHavePrefix) <= 4.0-1

 pmlib(CompressedFileNames) <= 3.0.4-1

 rpmlib(PayloadIsXz) <= 5.2-1
 <!--NeedCopy-->

Hinweis:

Eine Übersicht der Linux-Distributionen und Xorg-Versionen, die von dieser Version des Linux VDA unterstützt werden, finden Sie in der Tabelle Systemanforderungen.

Führen Sie nach der Installation des Linux VDA unter RHEL 7.x den Befehl sudo yum install -y python-websockify x11vnc aus. Damit werden python-websockify und x11vnc manuell für die Verwendung der Sitzungsspiegelung installiert. Weitere Informationen finden Sie unter Sitzungen spiegeln.

So aktualisieren Sie eine vorhandene Installation

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

Hinweis:

Durch das Upgrade einer Installation werden die Konfigurationsdateien unter /etc/xdl. überschrieben. Sichern Sie die Dateien vor jedem Upgrade.

So aktualisieren Sie Ihre Software mit Yum:

Für RHEL 7/CentOS 7:

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

So aktualisieren Sie Ihre Software mit RPM-Paketmanager:

Für RHEL 7/CentOS 7:
```
 sudo rpm -U XenDesktopVDA-<version>.el7_x.x86_64.rpm
 
```

Hinweis:

Bei Verwendung von RHEL 7 sind nach dem Ausführen der vorherigen Upgrade-Befehle folgende Schritte erforderlich:

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

Starten Sie den Dienst ctxvda neu.

Wichtig:

Starten Sie die Linux VDA-Maschine nach der Softwareaktualisierung neu.

Schritt 7: Installieren von NVIDIA GRID-Treibern

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

Konfigurieren Sie Folgendes:

Citrix Hypervisor
VMware ESX

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

Citrix Hypervisor:

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

VMware ESX:

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

VDA-Maschinen:

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

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

Zum Vorbereiten der Maschine für die NVIDIA GRID-Treiber müssen Sie folgende Befehle ausführen:

yum install gcc

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

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

Führen Sie die in den Anleitungen im Red Hat Enterprise Linux-Dokument aufgeführte Schrittfolge zum Installieren des NVIDIA GRID-Treibers aus.

Hinweis:

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

Wichtig:

Nach dem Aktivieren des GPU-Passthrough kann auf die Linux-VM nicht mehr über XenCenter zugegriffen werden. Verwenden Sie SSH, um eine Verbindung herzustellen.

Abbildung des NVIDIA SMI-Codesnippets

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

etc/X11/ctx-nvidia.sh

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

Schritt 8: 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 |5 – 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 Authentication Services
- 3 – Centrify DirectControl
- 4 – SSSD
- 5 – PBIS
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|5

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

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

Entfernen von Konfigurationsänderungen:

sudo /opt/Citrix/VDA/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 die Konfigurationsprotokolldatei /tmp/xdl.configure.log.

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

Schritt 9: Ausführen von XDPing

Mit sudo /opt/Citrix/VDA/bin/xdping können Sie Linux VDA-Umgebungen auf häufige Konfigurationsprobleme überprüfen. Weitere Informationen finden Sie unter XDPing.

Schritt 10: 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 11: 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 12: 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 2109.

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.

Manuelle Installation von Linux Virtual Delivery Agent für RHEL/CentOS

August 20, 2024

Beitrag von:

C Y

August 20, 2024

Beitrag von:

C Y

In diesem Artikel

Schritt 1: Vorbereiten von RHEL 8/CentOS 8, RHEL 7/CentOS 7 für die VDA-Installation
Schritt 2: Vorbereiten des Hypervisors
Schritt 3: Hinzufügen der virtuellen Linux-Maschine zur Windows-Domäne
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: Installieren von NVIDIA GRID-Treibern
Schritt 8: Konfigurieren des Linux VDA
Schritt 9: Ausführen von XDPing
Schritt 10: Ausführen des Linux VDA
Schritt 11: Erstellen des Maschinenkatalogs in Citrix Virtual Apps oder Citrix Virtual Desktops
Schritt 12: Erstellen der Bereitstellungsgruppe in Citrix Virtual Apps oder Citrix Virtual Desktops