Linux Virtual Delivery Agent für RHEL/CentOS installieren

Sie können entweder die Schritte in diesem Artikel für die manuelle Installation befolgen oder die Easy Install-Funktion für die automatische Installation und Konfiguration verwenden. Easy Install spart Zeit und Arbeitsaufwand und ist weniger fehleranfällig als die manuelle Installation.

Hinweis:

Verwenden Sie Easy Install nur für Neuinstallationen. Verwenden Sie Easy Install nicht, um eine bestehende Installation zu aktualisieren.

Schritt 1: RHEL 7/CentOS 7, RHEL 6/CentOS 6 für die VDA-Installation vorbereiten

Schritt 1a: Netzwerkkonfiguration überprüfen

Citrix® empfiehlt, dass das Netzwerk korrekt verbunden und konfiguriert ist, bevor Sie fortfahren.

Schritt 1b: Hostnamen festlegen

Hinweis:

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

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

HOSTNAME=hostname

Schritt 1c: Loopback-Adresse dem Hostnamen zuweisen

Hinweis:

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

Um sicherzustellen, dass der DNS-Domänenname und der vollqualifizierte Domänenname (FQDN) des Computers korrekt zurückgemeldet werden, ändern Sie die folgende Zeile der Datei /etc/hosts so, dass sie den FQDN und den Hostnamen als die ersten beiden Einträge enthält:

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.

Tipp:

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

Schritt 1d: Hostnamen überprüfen

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

hostname
<!--NeedCopy-->

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

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

hostname -f
<!--NeedCopy-->

Dieser Befehl gibt den FQDN des Computers zurück.

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

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

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

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

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

Schritt 1f: Taktsynchronisation konfigurieren

• Die Aufrechterhaltung einer genauen Taktsynchronisation zwischen den VDAs, Delivery Controllern und Domain Controllern ist entscheidend. Das Hosten des Linux VDA als virtuelle Maschine kann Probleme mit der Taktverschiebung verursachen. Aus diesem Grund wird die Zeitsynchronisation mit einem entfernten Zeitdienst bevorzugt.

RHEL 6.x und frühere Versionen verwenden den NTP-Daemon (ntpd) für die Taktsynchronisation, während eine RHEL 7.x Standardumgebung stattdessen den neueren Chrony-Daemon (chronyd) verwendet. Der Konfigurations- und Betriebsprozess zwischen den beiden Diensten ist ähnlich.

NTP-Dienst konfigurieren (nur RHEL 6/CentOS 6)

Als Root-Benutzer bearbeiten Sie /etc/ntp.conf und fügen einen Servereintrag für jeden entfernten Zeitserver hinzu:

-  server peer1-fqdn-or-ip-address iburst

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

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

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

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

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

Chrony-Dienst konfigurieren (nur RHEL 7/CentOS 7)

Als Root-Benutzer bearbeiten Sie /etc/chrony.conf und fügen einen Servereintrag für jeden entfernten Zeitserver hinzu:

server peer1-fqdn-or-ip-address iburst

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

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

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

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

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

Schritt 1g: OpenJDK installieren

Der Linux VDA hängt von OpenJDK ab. Typischerweise wird die Laufzeitumgebung als Teil der Betriebssysteminstallation installiert.

Bestätigen Sie die korrekte Version:

• RHEL 7/CentOS 7:

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

• RHEL 6/CentOS 6:

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

Das vorinstallierte OpenJDK könnte eine frühere Version sein. Aktualisieren Sie bei Bedarf auf die neueste Version:

• RHEL 7/CentOS 7:

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

• RHEL 6/CentOS 6:

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

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

export JAVA\_HOME=/usr/lib/jvm/java

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

java -version
<!--NeedCopy-->

Tipp:

Um Probleme zu vermeiden, stellen Sie sicher, dass Sie nur OpenJDK Version 1.7.0 oder 1.8.0 im Falle von RHEL 6/CentOS 6 oder nur OpenJDK Version 1.8.0 im Falle von RHEL 7/CentOS 7 installiert haben. Entfernen Sie alle anderen Java-Versionen von Ihrem System.

Schritt 1h: PostgreSQL installieren

Der Linux VDA erfordert entweder PostgreSQL 8.4 oder höher unter RHEL 6 oder PostgreSQL 9.2 oder höher unter RHEL 7.

Installieren Sie die folgenden Pakete:

sudo yum -y install postgresql-server

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

Der folgende Schritt nach der Installation ist erforderlich, um die Datenbank zu initialisieren und sicherzustellen, dass der Dienst beim Systemstart gestartet wird. Diese Aktion erstellt Datenbankdateien unter /var/lib/pgsql/data. Der Befehl unterscheidet sich zwischen PostgreSQL 8 und PostgreSQL 9:

• Nur RHEL 7: PostgreSQL 9

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

• Nur RHEL 6: PostgreSQL 8

sudo /sbin/service postgresql initdb
<!--NeedCopy-->

Schritt 1i: PostgreSQL starten

Starten Sie den Dienst beim Systemstart und starten Sie den Dienst sofort:

• Nur RHEL 7: PostgreSQL 9

sudo systemctl enable postgresql

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

• Nur RHEL 6: PostgreSQL 8

sudo /sbin/chkconfig postgresql on

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

Überprüfen Sie die Version von PostgreSQL mit:

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

Vergewissern Sie sich, dass das Datenverzeichnis festgelegt ist, indem Sie das Befehlszeilendienstprogramm psql verwenden:

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

Wichtig:

In dieser Version wird eine neue Abhängigkeit für gperftools-libs hinzugefügt, die jedoch im ursprünglichen Repository nicht vorhanden ist. Fügen Sie ein neues Repository mit dem Befehl sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm hinzu. Dies betrifft nur RHEL 6/CentOS 6. Führen Sie den Befehl aus, bevor Sie das Linux VDA-Paket installieren.

Schritt 2: Hypervisor vorbereiten

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

Zeitsynchronisierung auf Citrix XenServer® beheben

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

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

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

Dieser Befehl gibt 0 oder 1 zurück:

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

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

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

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

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

xen.independent_wallclock = 1

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

su -

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

Dieser Befehl gibt den Wert 1 zurück.

Zeitsynchronisierung auf Microsoft Hyper-V beheben

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

Vom Verwaltungsbetriebssystem aus:

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

Hinweis:

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

Zeitsynchronisierung auf ESX und ESXi beheben

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

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

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

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

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

• Samba Winbind
• Quest Authentication Service
• Centrify DirectControl
• SSSD

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

Hinweis:

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

Samba Winbind

Installieren oder aktualisieren Sie die erforderlichen Pakete:

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

Winbind-Daemon beim Systemstart aktivieren

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

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

Winbind-Authentifizierung konfigurieren

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

sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall
<!--NeedCopy-->

Dabei istREALMder Kerberos-Realm-Name in Großbuchstaben unddomainder NetBIOS-Name der Domäne.

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

--enablekrb5kdcdns --enablekrb5realmdns

Ignorieren Sie alle Fehler, die vom Befehl authconfig bezüglich des Fehlens des Starts des winbind-Dienstes zurückgegeben werden. Die Fehler können auftreten, wenn authconfig versucht, den winbind-Dienst zu starten, ohne dass der Computer bereits der Domäne beigetreten ist.

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

kerberos method = secrets and keytab winbind refresh tickets = true

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

Windows-Domäne beitreten

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

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

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

PAM für Winbind konfigurieren

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

krb5_auth = yes krb5_ccache_type = FILE mkhomedir = yes

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

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

Tipp:

Der Winbind-Daemon bleibt nur aktiv, wenn der Computer einer Domäne beigetreten ist.

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

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

Domänenmitgliedschaft überprüfen

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

• Führen Sie dennet ads-Befehl von Samba aus, um zu überprüfen, ob der Computer einer Domäne beigetreten ist:

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

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

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

Kerberos-Konfiguration überprüfen

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

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

Dieser Befehl zeigt die Liste der verfügbaren Schlüssel für die verschiedenen Kombinationen von Prinzipalnamen und Chiffriersuiten an. Führen Sie den Kerberos-Befehl kinit aus, um den Computer mit diesen Schlüsseln beim Domänencontroller zu authentifizieren:

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

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

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

sudo klist
<!--NeedCopy-->

Überprüfen Sie die Kontodetails des Computers mit:

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

Benutzerauthentifizierung überprüfen

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

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

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

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

ssh localhost -l domain\\username

id -u
<!--NeedCopy-->

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

klist
<!--NeedCopy-->

Sitzung beenden:

exit
<!--NeedCopy-->

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

Quest-Authentifizierungsdienst

Quest auf dem Domänencontroller konfigurieren

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

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

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

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

Hinweis:

• Diese Anweisungen gelten gleichermaßen für die Einrichtung von Domänenbenutzern zur Anmeldung über die Konsole, RDP, SSH oder jedes andere Remoting-Protokoll.

Quest auf Linux VDA konfigurieren

Umgehung der SELinux-Richtlinienerzwingung

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

Die bequeme Methode zur Umgehung dieses Problems besteht darin, SELinux zu deaktivieren. Bearbeiten Sie als Root-Benutzer die Datei /etc/selinux/config und ändern Sie die Einstellung SELinux:

SELINUX=permissive

Diese Änderung erfordert einen Neustart der Maschine:

reboot
<!--NeedCopy-->

Wichtig:

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

VAS-Daemon konfigurieren

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

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

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

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

PAM und NSS konfigurieren

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

sudo /opt/quest/bin/vastool configure pam

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

Windows-Domäne beitreten

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

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

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

Domänenmitgliedschaft überprüfen

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

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

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

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

Benutzerauthentifizierung überprüfen

Um zu überprüfen, ob Quest Domänenbenutzer über PAM authentifizieren kann, verwenden Sie ein Domänenbenutzerkonto, um sich am Linux VDA anzumelden. Das Domänenbenutzerkonto wurde zuvor noch nicht verwendet.

ssh localhost -l domain\\username

id -u
<!--NeedCopy-->

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

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

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

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

Beenden Sie die Sitzung:

exit
<!--NeedCopy-->

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

Centrify DirectControl

Windows-Domäne beitreten

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

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

Der Parameter „user“ ist ein beliebiger Active Directory-Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne verfügt. Der Domänenname ist der Name der Domäne, der die Linux-Maschine beitreten soll.

Domänenmitgliedschaft überprüfen

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

su –

adinfo
<!--NeedCopy-->

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

Umfassendere System- und Diagnoseinformationen sind verfügbar unter:

adinfo --sysinfo all

adinfo –diag
<!--NeedCopy-->

Testen Sie die Konnektivität zu den verschiedenen Active Directory- und Kerberos-Diensten. Fahren Sie nach der Überprüfung der Domänenverbindung mit Schritt 4: Installieren des Linux VDA fort.

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

SSSD

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

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

1. Der Domäne beitreten und Host-Keytab mit Samba erstellen
2. SSSD einrichten
3. NSS/PAM konfigurieren
4. Die Kerberos-Konfiguration überprüfen
5. Die Benutzerauthentifizierung überprüfen

Erforderliche Software

Der Active Directory-Anbieter wurde erstmals mit SSSD Version 1.9.0 eingeführt. Wenn Sie eine frühere Version verwenden, befolgen Sie die Anweisungen unter Konfigurieren von sssd zur Authentifizierung mit einem Windows 2008 Domänenserver.

Die folgenden Umgebungen wurden getestet und verifiziert, wenn die in diesem Artikel enthaltenen Anweisungen verwendet werden:

• RHEL 7.3 oder höher/CentOS 7.3 oder höher
• Linux VDA Version 1.3 oder höher

Domäne beitreten und Host-Keytab mit Samba erstellen

SSSD bietet keine Active Directory-Clientfunktionen zum Beitreten der Domäne und zur Verwaltung der System-Keytab-Datei. Stattdessen können Sie adcli, realmd, Winbind oder Samba verwenden.

Die Informationen in diesem Abschnitt beschreiben ausschließlich den Samba-Ansatz. Informationen zu realmd finden Sie in der RHEL- oder CentOS-Dokumentation. Diese Schritte müssen vor der Konfiguration von SSSD ausgeführt werden.

Auf dem Linux-Client mit ordnungsgemäß konfigurierten Dateien:

• /etc/krb5.conf
• /etc/samba/smb.conf:

Konfigurieren Sie den Computer für Samba- und Kerberos-Authentifizierung:

sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy-->

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

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

--enablekrb5kdcdns --enablekrb5realmdns

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

kerberos method = secrets and keytab

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

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

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

SSSD einrichten

Die Einrichtung von SSSD umfasst die folgenden Schritte:

• Installieren Sie das Paket sssd-ad auf dem Linux VDA.
  • Nehmen Sie Konfigurationsänderungen an verschiedenen Dateien vor (z. B. sssd.conf).
  • Starten Sie den Dienst sssd.

Eine Beispielkonfiguration für sssd.conf (zusätzliche Optionen können bei Bedarf hinzugefügt werden):

[sssd]
config_file_version = 2
domains = ad.example.com
services = nss, pam

[domain/ad.example.com]
# Uncomment if you need offline logins
# cache_credentials = true

id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = ad

# Should be specified as the lower-case version of the long version of the Active Directory domain.
ad_domain = ad.example.com

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

# Uncomment if service discovery is not working
# ad_server = server.ad.example.com

# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
<!--NeedCopy-->

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

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

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

NSS/PAM konfigurieren

RHEL/CentOS:

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

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

sudo service sssd start

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

-  #### Kerberos-Konfiguration überprüfen

-  Überprüfen Sie, ob die System-**Keytab**-Datei erstellt wurde und gültige Schlüssel enthält:

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

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

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

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

Überprüfen Sie, ob das TGT-Ticket für das Computerkonto mit den folgenden Befehlen zwischengespeichert wurde:

sudo klist
<!--NeedCopy-->

Benutzerauthentifizierung überprüfen

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

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

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

Die unterstützten Anmeldeformate sind:

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

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

sudo ssh localhost –l DOMAIN\\username

id -u
<!--NeedCopy-->

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

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

Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache des Benutzers gültig und nicht abgelaufen sind. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 4: Installieren des Linux VDA fort.

klist
<!--NeedCopy-->

Schritt 4: Installieren des Linux VDA

Schritt 4a: Deinstallieren der alten Version

Wenn Sie zuvor eine ältere Version des Linux VDA installiert haben, deinstallieren Sie diese, bevor Sie die neue Version installieren.

1. Stoppen Sie die Linux VDA-Dienste:

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

2. Deinstallieren Sie das Paket:

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

Hinweis:

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

Hinweis:

Ab Version 1.3 hat sich der Installationspfad geändert. In früheren Versionen befanden sich die Installationskomponenten in /usr/local/. Der neue Speicherort ist /opt/Citrix/VDA/.

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

Schritt 4b: Linux VDA-Paket herunterladen

Gehen Sie zur Citrix-Website und laden Sie das entsprechende Linux VDA-Paket basierend auf Ihrer Linux-Distribution herunter.

Schritt 4c: Linux VDA installieren

-  Installieren Sie die Linux VDA-Software mit `Yum`:

-  **Für RHEL 7/CentOS 7:**

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.9:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.6/CentOS 6.6:

    -  sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

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

Für RHEL 7/CentOS 7:

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.9:

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.6/CentOS 6.6:

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

RPM-Abhängigkeitsliste für RHEL 7:

postgresql-server >= 9.2

postgresql-jdbc >= 9.2

java-1.8.0-openjdk >= 1.8.0

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

xorg-x11-server-Xorg >= 1.17

xorg-x11-server-Xorg < 1.18

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

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

RPM-Abhängigkeitsliste für RHEL 6.9:

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.0

ImageMagick >= 6.5.4.7

GConf2 >= 2.28.0

system-config-firewall-base >= 1.2.27

policycoreutils-python >= 2.0.83

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.0.9

ConsoleKit >= 0.4.1

dbus >= 1.2.24

dbus-x11 >= 1.2.24

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

openmotif >= 2.3.3

pam >= 1.1.1

util-linux-ng >= 2.17.2

bash >= 4.1

findutils >= 4.4

gawk >= 3.1

sed >= 4.2

cups >= 1.4.0

foomatic >= 4.0.0

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.7

python-requests >= 2.6.0

gperftools-libs >= 2.0

xorg-x11-server-Xorg >= 1.17

xorg-x11-server-Xorg < 1.18

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

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

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

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.0

ImageMagick >= 6.5.4.7

GConf2 >= 2.28.0

system-config-firewall-base >= 1.2.27

policycoreutils-python >= 2.0.83

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.0.9

ConsoleKit >= 0.4.1

dbus >= 1.2.24

dbus-x11 >= 1.2.24

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

openmotif >= 2.3.3

pam >= 1.1.1

util-linux-ng >= 2.17.2

bash >= 4.1

findutils >= 4.4

gawk >= 3.1

sed >= 4.2

cups >= 1.4.0

foomatic >= 4.0.0

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.7

python-requests >= 2.6.0

gperftools-libs >= 2.0

xorg-x11-server-Xorg >= 1.15

xorg-x11-server-Xorg < 1.16

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

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

Schritt 4d: Linux VDA aktualisieren (optional)

Sie können die Linux VDA-Software von Version 7.14 und 7.13 mit Yum aktualisieren:

Für RHEL 7/CentOS 7:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.9:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.6/CentOS 6.6:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Aktualisieren Sie die Linux VDA-Software mit dem RPM-Paketmanager:

Für RHEL 7/CentOS 7:

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.9:

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Für RHEL 6.6/CentOS 6.6:

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Wichtig:

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

Schritt 5: NVIDIA GRID-Treiber installieren

Die Aktivierung von HDX 3D Pro erfordert zusätzliche Installationsschritte, um die erforderlichen Grafiktreiber auf dem Hypervisor und auf den VDA-Maschinen zu installieren.

Konfigurieren Sie Folgendes:

1. Citrix XenServer
2. VMware ESX

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

Citrix XenServer:

Dieser detaillierte Abschnitt beschreibt die Installation und Konfiguration der NVIDIA GRID-Treiber auf Citrix XenServer.

VMware ESX:

Befolgen Sie die Informationen in diesem Leitfaden, um die NVIDIA GRID-Treiber für VMware ESX zu installieren und zu konfigurieren.

VDA-Maschinen:

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

1. Stellen Sie vor dem Start sicher, dass die Linux-VM heruntergefahren ist.
2. Fügen Sie in XenCenter® eine GPU im GPU-Passthrough-Modus zur VM hinzu.
3. Starten Sie die RHEL-VM.

Um die Maschine für die NVIDIA GRID-Treiber vorzubereiten, führen Sie die folgenden Befehle aus:

yum install gcc

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

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

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

Hinweis:

Wählen Sie während der GPU-Treiberinstallation für jede Frage die Standardoption (‘Nein’).

Wichtig:

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

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

etc/X11/ctx-nvidia.sh

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

Schritt 6: Konfigurieren des Linux VDA

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

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

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

Konfiguration mit Eingabeaufforderung

Führen Sie eine manuelle Konfiguration mit Eingabeaufforderungen durch:

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

Automatisierte Konfiguration

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

Unterstützte Umgebungsvariablen umfassen:

• CTX_XDL_SUPPORT_DDC_AS_CNAME = Y | N – Der Linux VDA unterstützt die Angabe eines Delivery Controller-Namens mithilfe eines DNS-CNAME-Eintrags. Standardmäßig auf N festgelegt.
• CTX_XDL_DDC_LIST = list-ddc-fqdns – Der Linux VDA erfordert eine durch Leerzeichen getrennte Liste von FQDNs (Fully Qualified Domain Names) der Delivery Controller, die für die Registrierung bei einem Delivery Controller verwendet werden sollen. Mindestens ein FQDN oder CNAME-Alias muss angegeben werden.
• CTX_XDL_VDA_PORT = port-number – Der Linux VDA kommuniziert mit Delivery Controllern über einen TCP/IP-Port, der standardmäßig Port 80 ist.
• CTX_XDL_REGISTER_SERVICE = Y | N – Die Linux Virtual Desktop-Dienste werden nach dem Start der Maschine gestartet. Der Wert ist standardmäßig auf Y festgelegt.
• CTX_XDL_ADD_FIREWALL_RULES = Y | N – Die Linux Virtual Desktop-Dienste erfordern, dass eingehende Netzwerkverbindungen über die System-Firewall zugelassen werden. Sie können die erforderlichen Ports (standardmäßig Port 80 und 1494) in der System-Firewall für den Linux Virtual Desktop automatisch öffnen. Standardmäßig auf Y festgelegt.
• CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 – Der Linux VDA erfordert Kerberos-Konfigurationseinstellungen zur Authentifizierung bei den Delivery Controllern. Die Kerberos-Konfiguration wird vom installierten und konfigurierten Active Directory-Integrationstool auf dem System bestimmt. Geben Sie die zu verwendende unterstützte Active Directory-Integrationsmethode an:
  • 1 – Samba Winbind
  • 2 – Quest Authentication Service
  • 3 – Centrify DirectControl
  • 4 – SSSD
• CTX_XDL_HDX_3D_PRO = Y | N – Der Linux VDA unterstützt HDX 3D Pro, eine Reihe von GPU-Beschleunigungstechnologien, die zur Optimierung der Virtualisierung von grafikintensiven Anwendungen entwickelt wurden. Wenn HDX 3D Pro ausgewählt ist, wird der Virtual Delivery Agent für VDI-Desktops (Einzelsitzungsmodus) konfiguriert – (d. h. CTX_XDL_VDI_MODE=Y).
• CTX_XDL_VDI_MODE = Y | N – Ob die Maschine als dediziertes Desktop-Bereitstellungsmodell (VDI) oder als gehostetes Shared-Desktop-Bereitstellungsmodell konfiguriert werden soll. Für HDX 3D Pro-Umgebungen setzen Sie diese Variable auf Y. Diese Variable ist standardmäßig auf N festgelegt.
• CTX_XDL_SITE_NAME = dns-name – Der Linux VDA erkennt LDAP-Server über DNS. Um die DNS-Suchergebnisse auf einen lokalen Standort zu beschränken, geben Sie einen DNS-Standortnamen an. Diese Variable ist standardmäßig auf <none> festgelegt.
• CTX_XDL_LDAP_LIST = list-ldap-servers – Der Linux VDA fragt DNS ab, um LDAP-Server zu erkennen. Wenn DNS keine LDAP-Dienstdatensätze bereitstellen kann, können Sie eine durch Leerzeichen getrennte Liste von LDAP-FQDNs mit LDAP-Port angeben. Zum Beispiel ad1.mycompany.com:389. Diese Variable ist standardmäßig auf <none> festgelegt.
• CTX_XDL_SEARCH_BASE = search-base-set – Der Linux VDA fragt LDAP über eine Suchbasis ab, die auf das Stammverzeichnis der Active Directory-Domäne (z. B. DC=mycompany,DC=com) festgelegt ist. Um die Suchleistung zu verbessern, können Sie eine Suchbasis angeben (z. B. OU=VDI,DC=mycompany,DC=com). Diese Variable ist standardmäßig auf <none> festgelegt.
• CTX_XDL_START_SERVICE = Y | N – Ob die Linux VDA-Dienste gestartet werden, wenn die Linux VDA-Konfiguration abgeschlossen ist. Standardmäßig auf Y festgelegt.

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

export CTX_XDL_LDAP_LIST=list-ldap-servers

export CTX_XDL_SEARCH_BASE=search-base-set

export CTX_XDL_START_SERVICE=Y|N

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

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

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

sudo CTX_XDL_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_START_SERVICE=Y|N \

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

Konfigurationsänderungen entfernen

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

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

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

So entfernen Sie Konfigurationsänderungen:

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

Wichtig:

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

Konfigurationsprotokolle

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

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

Schritt 7: Ausführen des Linux VDA

Nachdem Sie den Linux VDA mithilfe des Skripts ctxsetup.sh konfiguriert haben, können Sie die folgenden Befehle ausführen, um den Linux VDA zu steuern.

Starten des Linux VDA:

So starten Sie die Linux VDA-Dienste:

sudo /sbin/service ctxhdx start

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

Beenden des Linux VDA:

So beenden Sie die Linux VDA-Dienste:

sudo /sbin/service ctxvda stop

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

Neustarten des Linux VDA:

So starten Sie die Linux VDA-Dienste neu:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

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

Überprüfen des Status des Linux VDA:

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

sudo /sbin/service ctxvda status

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

Schritt 8: Erstellen des Maschinenkatalogs in XenApp oder XenDesktop®

Der Prozess zum Erstellen von Maschinenkatalogen und Hinzufügen von Linux VDA-Maschinen ähnelt dem traditionellen Windows VDA-Ansatz. Eine detailliertere Beschreibung zum Ausführen dieser Aufgaben finden Sie unter Maschinenkataloge erstellen und Maschinenkataloge verwalten.

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

• Wählen Sie für das Betriebssystem:
  • Die Option Server-Betriebssystem für ein gehostetes Shared-Desktop-Bereitstellungsmodell.
  • Die Option Desktop-Betriebssystem für ein dediziertes VDI-Desktop-Bereitstellungsmodell.
• Stellen Sie sicher, dass Maschinen nicht energieverwaltet sind.
• Da MCS für Linux VDAs nicht unterstützt wird, wählen Sie PVS oder die Bereitstellungsmethode Anderer Dienst oder Technologie (vorhandene Images).
• Mischen Sie keine Linux- und Windows VDA-Maschinen im selben Maschinenkatalog.

Hinweis:

Frühere Versionen von Citrix Studio unterstützten den Begriff “Linux OS” nicht. Die Auswahl der Option Windows Server-Betriebssystem oder Server-Betriebssystem impliziert jedoch ein äquivalentes gehostetes Shared-Desktop-Bereitstellungsmodell. Die Auswahl der Option Windows Desktop-Betriebssystem oder Desktop-Betriebssystem impliziert ein Einzelbenutzer-pro-Maschine-Bereitstellungsmodell.

Tipp:

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

Schritt 9: Erstellen der Bereitstellungsgruppe in XenApp® oder XenDesktop

Der Prozess zum Erstellen einer Bereitstellungsgruppe und Hinzufügen von Maschinenkatalogen, die Linux VDA-Maschinen enthalten, ist nahezu identisch mit dem für Windows VDA-Maschinen. Eine detailliertere Beschreibung zum Ausführen dieser Aufgaben finden Sie unter Bereitstellungsgruppen erstellen.

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

• Wählen Sie als Bereitstellungstyp Desktops oder Anwendungen.
• Stellen Sie sicher, dass die von Ihnen ausgewählten AD-Benutzer und -Gruppen ordnungsgemäß für die Anmeldung an den Linux-VDA-Maschinen konfiguriert wurden.
• Lassen Sie keine Anmeldung von nicht authentifizierten (anonymen) Benutzern zu.
• Mischen Sie die Bereitstellungsgruppe nicht mit Maschinenkatalogen, die Windows-Maschinen enthalten.

Wichtig:

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