layout: doc googlebot: noindex robots: noindex hideFeedbackForm: true
Wichtig:
Für Neuinstallationen empfehlen wir Ihnen, die einfache Installation für eine schnelle Einrichtung zu verwenden. Die einfache Installation spart Zeit und Aufwand und ist weniger fehleranfällig als die in diesem Artikel beschriebene manuelle Installation.
Stellen Sie sicher, dass das Netzwerk korrekt verbunden und konfiguriert ist. Beispielsweise müssen Sie den DNS-Server auf dem Linux VDA konfigurieren.
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
Um sicherzustellen, dass der DNS-Domänenname und der vollqualifizierte Domänenname (FQDN) des Computers korrekt gemeldet werden, ändern Sie die folgende Zeile der Datei /etc/hosts so, dass sie den FQDN und den Hostnamen als erste zwei Einträge enthält:
127.0.0.1 hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4
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 keine NetBIOS-Namenskürzung. Der Hostname darf 15 Zeichen nicht überschreiten.
Tipp:
Verwenden Sie nur die Zeichen a–z, A–Z, 0–9 und Bindestrich (-). Vermeiden Sie Unterstriche (_), Leerzeichen und andere Symbole. Beginnen Sie einen Hostnamen nicht mit einer Zahl und beenden Sie ihn nicht mit einem Bindestrich. Diese Regel gilt auch für Delivery Controller-Hostnamen.
Überprüfen Sie, ob der Hostname korrekt festgelegt ist:
hostname
<!--NeedCopy-->
Dieser Befehl gibt nur den Hostnamen des Computers zurück, nicht seinen vollqualifizierten Domänennamen (FQDN).
Überprüfen Sie, ob der FQDN korrekt festgelegt ist:
hostname -f
<!--NeedCopy-->
Dieser Befehl gibt den FQDN des Computers zurück.
Überprüfen Sie, ob Sie den FQDN auflösen und den Domänencontroller sowie den Delivery Controller™ anpingen können:
- nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn
<!--NeedCopy-->
Wenn Sie den FQDN nicht auflösen oder keine dieser Maschinen anpingen können, überprüfen Sie die Schritte, bevor Sie fortfahren.
Die Aufrechterhaltung einer genauen Zeitsynchronisierung zwischen den VDAs, Delivery Controllern und Domänencontrollern ist entscheidend. Das Hosten des Linux VDA als virtuelle Maschine kann zu Problemen mit der Zeitverschiebung führen. Aus diesem Grund wird die Synchronisierung der Zeit mit einem externen Zeitdienst bevorzugt.
Eine RHEL 8/RHEL 7 Standardumgebung verwendet den Chrony-Daemon (chronyd) zur Zeitsynchronisierung.
Bearbeiten Sie als Root-Benutzer die Datei /etc/chrony.conf und fügen Sie für jeden externen 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-Pool-Servern. Fügen Sie für jeden Active Directory-Domänencontroller in der Domäne einen Servereintrag hinzu.
Entfernen Sie alle anderen aufgelisteten Servereinträge, einschließlich Loopback-IP-Adresse, Localhost und öffentliche Server-Einträge *.pool.ntp.org.
Speichern Sie die Änderungen und starten Sie den Chrony-Daemon neu:
sudo /sbin/service chronyd restart
<!--NeedCopy-->
Der Linux VDA erfordert die Installation von OpenJDK 11.
Wenn Sie Amazon Linux 2 verwenden, führen Sie den folgenden Befehl aus, um OpenJDK 11 zu aktivieren und zu installieren:
amazon-linux-extras install java-openjdk11
<!--NeedCopy-->
sudo yum info java-11-openjdk
<!--NeedCopy-->
Das vorinstallierte OpenJDK könnte eine frühere Version sein. Aktualisieren Sie auf OpenJDK 11:
sudo yum -y update java-11-openjdk
<!--NeedCopy-->
Der Linux VDA erfordert entweder PostgreSQL 10.5 oder höher auf RHEL 8 oder PostgreSQL 9.2 oder höher auf 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 10 und 9:
sudo postgresql-setup initdb
<!--NeedCopy-->
Starten Sie den Dienst beim Systemstart und starten Sie den Dienst sofort:
- sudo systemctl enable postgresql
- sudo systemctl start postgresql
<!--NeedCopy-->
Überprüfen Sie die Version von PostgreSQL mit:
psql --version
<!--NeedCopy-->
(Nur RHEL 7) Überprüfen Sie, ob das Datenverzeichnis mit dem Befehlszeilendienstprogramm psql festgelegt ist:
sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->
Einige Änderungen sind erforderlich, wenn der Linux VDA als virtuelle Maschine auf einem unterstützten Hypervisor ausgeführt wird. Nehmen Sie die folgenden Änderungen basierend auf der verwendeten Hypervisor-Plattform vor. Es sind keine Änderungen erforderlich, wenn Sie die Linux-Maschine auf Bare-Metal-Hardware ausführen.
Wenn die Citrix Hypervisor-Zeitsynchronisierungsfunktion aktiviert ist, treten in jeder paravirtualisierten Linux-VM Probleme mit NTP und Citrix Hypervisor auf. Beide versuchen, die Systemuhr zu verwalten. Um zu vermeiden, dass die Uhr mit anderen Servern asynchron wird, stellen Sie sicher, dass die Systemuhr in jedem Linux-Gast mit dem NTP synchronisiert ist. In diesem Fall muss die Host-Zeitsynchronisierung deaktiviert werden. Im HVM-Modus sind keine Änderungen erforderlich.
Wenn Sie einen paravirtualisierten Linux-Kernel mit installierten Citrix VM Tools ausführen, können Sie innerhalb der Linux-VM überprüfen, ob die Citrix Hypervisor-Zeitsynchronisierungsfunktion vorhanden und aktiviert ist:
su -
cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
Dieser Befehl gibt 0 oder 1 zurück:
Wenn die Datei /proc/sys/xen/independent_wallclock nicht vorhanden ist, sind die folgenden Schritte nicht erforderlich.
Falls aktiviert, deaktivieren Sie die Zeitsynchronisierungsfunktion, indem Sie 1 in die Datei schreiben:
sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->
Um diese Änderung dauerhaft und nach einem Neustart 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.
Die Linux-VMs mit installierten Hyper-V Linux Integration Services können die Hyper-V-Zeitsynchronisierungsfunktion nutzen, um die Zeit des Host-Betriebssystems zu verwenden. Um sicherzustellen, dass die Systemuhr genau bleibt, müssen Sie diese Funktion zusammen mit den NTP-Diensten aktivieren.
Vom Verwaltungsbetriebssystem aus:
Hinweis:
Dieser Ansatz unterscheidet sich von VMware und Citrix Hypervisor, wo die Host-Zeitsynchronisierung deaktiviert wird, um Konflikte mit NTP zu vermeiden. Die Hyper-V-Zeitsynchronisierung kann mit der NTP-Zeitsynchronisierung koexistieren und diese ergänzen.
Wenn die VMware-Zeitsynchronisierungsfunktion aktiviert ist, treten in jeder paravirtualisierten Linux-VM Probleme mit NTP und dem Hypervisor auf. Beide versuchen, die Systemuhr zu synchronisieren. Um zu vermeiden, dass die Uhr mit anderen Servern asynchron wird, stellen Sie sicher, dass die Systemuhr in jedem Linux-Gast mit dem NTP synchronisiert ist. In diesem Fall muss die Host-Zeitsynchronisierung deaktiviert werden.
Wenn Sie einen paravirtualisierten Linux-Kernel mit installierten VMware Tools ausführen:
Der Linux VDA unterstützt mehrere Methoden zum Hinzufügen von Linux-Maschinen zur Active Directory (AD)-Domäne:
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.
Installieren oder aktualisieren Sie die erforderlichen Pakete:
Für RHEL 8:
sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation oddjob-mkhomedir realmd authselect
<!--NeedCopy-->
Für Amazon Linux 2, CentOS 7 und RHEL 7:
sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir
<!--NeedCopy-->
Der Winbind-Daemon muss so konfiguriert werden, dass er beim Maschinenstart gestartet wird:
sudo /sbin/chkconfig winbind on
<!--NeedCopy-->
Konfigurieren Sie die Maschine für die Kerberos-Authentifizierung mithilfe von Winbind:
Führen Sie den folgenden Befehl aus.
Für RHEL 8:
sudo authselect select winbind with-mkhomedir --force
<!--NeedCopy-->
Für Amazon Linux 2 und RHEL 7:
sudo authconfig --disablecache --disablesssd --disablesssdauth --enablewinbind --enablewinbindauth --disablewinbindoffline --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --winbindtemplateshell=/bin/bash --enablemkhomedir --updateall
<!--NeedCopy-->
Wobei REALM der Kerberos-Realm-Name in Großbuchstaben und domain der NetBIOS-Name der Domäne ist.
Wenn eine DNS-basierte Suche des KDC-Servers und des Realm-Namens erforderlich ist, fügen Sie die folgenden beiden Optionen zum vorherigen Befehl hinzu:
--enablekrb5kdcdns --enablekrb5realmdns
Ignorieren Sie alle Fehler, die vom Befehl authconfig bezüglich des Fehlstarts des Dienstes winbind zurückgegeben werden. Die Fehler können auftreten, wenn authconfig versucht, den Dienst winbind zu starten, ohne dass die Maschine bereits der Domäne beigetreten ist.
Öffnen Sie /etc/samba/smb.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [Global] hinzu, jedoch nach dem Abschnitt, der vom Tool authconfig generiert wurde:
kerberos method = secrets and keytab
winbind refresh tickets = true
winbind offline logon = no
(Nur RHEL 8) Öffnen Sie /etc/krb5.conf und fügen Sie Einträge unter den Abschnitten [libdefaults], [realms] und [domain_realm] hinzu:
Unter dem Abschnitt [libdefaults]:
default_ccache_name = FILE:/tmp/krb5cc_%{uid}
default_realm = REALM
dns_lookup_kdc = true
Unter dem Abschnitt [realms]:
REALM = {
kdc = fqdn-of-domain-controller
}
Unter dem Abschnitt [domain_realm]:
realm = REALM
.realm = REALM
Der Linux VDA benötigt die System-Keytab-Datei /etc/krb5.keytab, um sich beim Delivery Controller zu authentifizieren und zu registrieren. Die vorherige Kerberos-Methodeneinstellung zwingt Winbind dazu, die System-Keytab-Datei zu erstellen, wenn der Computer zum ersten Mal der Domäne beitritt.
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:
Für RHEL 8:
sudo realm join -U user --client-software=winbind REALM
<!--NeedCopy-->
Für Amazon Linux 2 und RHEL 7:
sudo net ads join REALM -U user
<!--NeedCopy-->
REALM ist der Kerberos-Realm-Name in Großbuchstaben, und Benutzer ist ein Domänenbenutzer, der Berechtigungen zum Hinzufügen von Computern zur Domäne besitzt.
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.conf und ändern Sie die folgende Einstellung unter dem Abschnitt [libdefaults] von KEYRING auf den Typ FILE:
default_ccache_name = FILE:/tmp/krb5cc_%{uid}
Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in Active Directory besitzen.
Führen Sie den net ads-Befehl von Samba aus, um zu überprüfen, ob der Computer einer Domäne beigetreten ist:
sudo net ads testjoin
<!--NeedCopy-->
Führen Sie den folgenden Befehl aus, um zusätzliche Domänen- und Computerobjektinformationen zu überprüfen:
sudo net ads info
<!--NeedCopy-->
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-->
Verwenden Sie das Tool wbinfo, um zu überprüfen, ob Domänenbenutzer sich bei der Domäne authentifizieren können:
wbinfo --krb5auth=domain\\username%password
<!--NeedCopy-->
Die hier angegebene Domäne ist der AD-Domänenname, nicht der Kerberos-Realm-Name. Für die Bash-Shell muss der Backslash (\) mit einem weiteren Backslash maskiert werden. Dieser Befehl gibt eine Erfolgs- oder Fehlermeldung zurück.
Um zu überprüfen, ob das Winbind PAM-Modul korrekt konfiguriert ist, melden Sie sich mit einem bisher ungenutzten Domänenbenutzerkonto am Linux VDA an.
ssh localhost -l domain\\username
id -u
<!--NeedCopy-->
Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache gültig und nicht abgelaufen sind:
klist
<!--NeedCopy-->
exit
<!--NeedCopy-->
Ein ähnlicher Test kann durch direktes Anmelden an der Gnome- oder KDE-Konsole durchgeführt werden. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.
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.
Um Domänenbenutzern das Herstellen von HDX™-Sitzungen auf einer Linux VDA-Maschine zu ermöglichen:
Hinweis:
Diese Anweisungen sind äquivalent für die Einrichtung von Domänenbenutzern zur Anmeldung über die Konsole, RDP, SSH oder jedes andere Remoting-Protokoll.
Die Standard-RHEL-Umgebung hat SELinux vollständig erzwungen. Diese Erzwingung beeinträchtigt die von Quest verwendeten Unix-Domain-Socket-IPC-Mechanismen und verhindert, dass Domänenbenutzer sich anmelden können.
Der bequeme Weg, dieses Problem zu umgehen, ist die Deaktivierung von SELinux. Bearbeiten Sie als Root-Benutzer die Datei /etc/selinux/config und ändern Sie die SELinux-Einstellung:
SELINUX=permissive
Diese Änderung erfordert einen Neustart der Maschine:
reboot
<!--NeedCopy-->
Wichtig:
Verwenden Sie diese Einstellung mit Vorsicht. Das erneute Aktivieren der SELinux-Richtlinienerzwingung nach der Deaktivierung kann zu einer vollständigen Sperrung führen, selbst für den Root-Benutzer und andere lokale Benutzer.
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.
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-->
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 verfügt, Computer der Active Directory-Domäne hinzuzufügen. Der Domänenname ist der DNS-Name der Domäne, zum Beispiel example.com.
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
Um zu überprüfen, ob Quest Domänenbenutzer über PAM authentifizieren kann, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das zuvor noch nicht verwendet wurde.
ssh localhost -l domain\\username
id -u
<!--NeedCopy-->
Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die 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 6: Installieren des Linux VDA fort.
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 Benutzerparameter ist ein beliebiger Active Directory-Domänenbenutzer, der über Berechtigungen verfügt, Computer der Active Directory-Domäne hinzuzufügen. Der Domänenname ist der Name der Domäne, der die Linux-Maschine beitreten soll.
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 über:
adinfo --sysinfo all
adinfo –diag
<!--NeedCopy-->
Testen Sie die Konnektivität zu den verschiedenen Active Directory- und Kerberos-Diensten.
adinfo --test
<!--NeedCopy-->
Fahren Sie nach der Überprüfung der Domänenverbindung mit Schritt 6: Installieren des Linux VDA fort.
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 unter RHEL und CentOS einzurichten, gehen Sie wie folgt vor:
- 1. Der Domäne beitreten und Host-Keytab erstellen
SSSD bietet keine Active Directory-Client-Funktionen zum Beitreten der Domäne und zur Verwaltung der System-Keytab-Datei. Stattdessen können Sie adcli, realmd oder Samba verwenden.
Dieser Abschnitt beschreibt den Samba-Ansatz für Amazon Linux 2 und RHEL 7 und den adcli-Ansatz für RHEL 8. Für realmd siehe die RHEL- oder CentOS-Dokumentation. Diese Schritte müssen vor der Konfiguration von SSSD befolgt werden.
- **Samba (Amazon Linux 2 und RHEL 7):**
Installieren oder aktualisieren Sie die erforderlichen Pakete:
```
sudo yum -y install krb5-workstation authconfig oddjob-mkhomedir samba-common-tools
<!--NeedCopy--> ```
Auf dem Linux-Client mit ordnungsgemäß konfigurierten Dateien:
- /etc/krb5.conf
- /etc/samba/smb.conf:
Konfigurieren Sie den Computer für die 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.
Hinweis:
Die Einstellungen in diesem Artikel sind für das Einzeldomänen-, Einzelforst-Modell vorgesehen. Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur.
Wenn eine DNS-basierte Suche nach dem KDC-Server und dem Realm-Namen erforderlich ist, fügen Sie dem vorhergehenden Befehl die folgenden beiden Optionen hinzu:
--enablekrb5kdcdns --enablekrb5realmdns
Öffnen Sie /etc/samba/smb.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [Global] hinzu, jedoch nach dem Abschnitt, der vom Tool authconfig generiert wurde:
kerberos method = secrets and keytab
winbind offline logon = no
Treten Sie der Windows-Domäne bei. Stellen Sie sicher, dass Ihr Domänencontroller erreichbar ist und Sie über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:
```
sudo net ads join REALM -U user
<!--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.
Installieren oder aktualisieren Sie die erforderlichen Pakete:
```
sudo yum -y install samba-common samba-common-tools krb5-workstation authconfig oddjob-mkhomedir realmd oddjob authselect
<!--NeedCopy--> ```
Konfigurieren Sie den Computer für die Samba- und Kerberos-Authentifizierung:
```
sudo authselect select sssd with-mkhomedir --force
<!--NeedCopy--> ```
Öffnen Sie /etc/krb5.conf und fügen Sie die Einträge unter den Abschnitten [realms] und [domain_realm] hinzu.
Unter dem Abschnitt [realms]:
REALM = {
kdc = fqdn-of-domain-controller
}
Unter dem Abschnitt [domain_realm]:
realm = REALM
.realm = REALM
Treten Sie der Windows-Domäne bei. Stellen Sie sicher, dass Ihr Domänencontroller erreichbar ist und Sie über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:
```
sudo realm join REALM -U user
<!--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.
Die Einrichtung von SSSD umfasst die folgenden Schritte:
sudo yum -y install sssd ausführen.Ein Beispiel für die sssd.conf-Konfiguration für RHEL 7 (zusätzliche Optionen können bei Bedarf hinzugefügt werden):

Ersetzen Sie ad.example.com, server.ad.example.com durch die entsprechenden Werte. Weitere Informationen finden Sie unter sssd-ad(5) - Linux-Manpage.
(Nur RHEL 8) Öffnen Sie /etc/sssd/sssd.conf und fügen Sie die folgenden Einträge unter dem Abschnitt [domain/ad.example.com] hinzu:
ad_gpo_access_control = permissive
full_name_format = %2$s\%1$s
fallback_homedir = /home/%d/%u
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
Legen Sie die Dateiberechtigungen und den Besitz für sssd.conf fest:
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
Für RHEL 8:
Führen Sie die folgenden Befehle aus, um SSSD zu aktivieren:
sudo systemctl restart sssd
sudo systemctl enable sssd.service
sudo chkconfig sssd on
<!--NeedCopy-->
Für Amazon Linux 2, CentOS 7 und RHEL 7:
Verwenden Sie authconfig, um SSSD zu aktivieren. Installieren Sie oddjob-mkhomedir, um sicherzustellen, dass die Erstellung des Home-Verzeichnisses mit SELinux kompatibel ist:
authconfig --enablesssd --enablesssdauth --enablemkhomedir –-update
sudo service sssd start
sudo chkconfig sssd on
<!--NeedCopy-->
Überprüfen Sie, ob die Systemdatei keytab erstellt wurde und gültige Schlüssel enthält:
- sudo klist -ke
<!--NeedCopy-->
Dieser Befehl zeigt die Liste der Schlüssel an, die für die verschiedenen Kombinationen von Prinzipalnamen und Chiffriersuiten verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um den Computer mit dem Domänencontroller unter Verwendung dieser Schlüssel zu authentifizieren:
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
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-->
Verwenden Sie den Befehl getent, um zu überprüfen, ob das Anmeldeformat unterstützt wird und der NSS funktioniert:
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
Der Parameter DOMAIN gibt den Kurznamen der Domäne an. Wenn ein anderes Anmeldeformat erforderlich ist, überprüfen Sie dies zuerst mit dem Befehl getent.
Die unterstützten Anmeldeformate sind:
DOMAIN\username
username@domain.com
username@DOMAIN
Um zu überprüfen, ob das SSSD PAM-Modul korrekt konfiguriert ist, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das zuvor noch nicht verwendet wurde.
sudo ssh localhost –l DOMAIN\\username
- id -u
<!--NeedCopy-->
- Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die vom Befehl zurückgegebene **UID** erstellt wurde:
- ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
- Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache des Benutzers gültig und nicht abgelaufen sind.
- klist
<!--NeedCopy-->
- Fahren Sie nach der Überprüfung des Domänenbeitritts mit [Schritt 6: Installieren des Linux VDA](/de-de/linux-virtual-delivery-agent/2201/installation-overview/redhat.html#step-6-install-the-linux-vda) fort.
Für CentOS 7 und RHEL 7, zum Beispiel:
wget https://github.com/BeyondTrust/pbis-open/releases/download/8.8.0/pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->
Für Amazon Linux 2 und RHEL 8, zum Beispiel:
wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Für CentOS 7 und RHEL 7, zum Beispiel:
chmod +x pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->
Für Amazon Linux 2 und RHEL 8, zum Beispiel:
chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
sh pbis-open-8.8.0.506.linux.x86_64.rpm.sh
<!--NeedCopy-->
Für Amazon Linux 2 und RHEL 8, zum Beispiel:
sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Ihr Domänencontroller muss erreichbar sein, und Sie müssen über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:
/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
Der Benutzer ist ein Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne verfügt. Der Domänenname ist der DNS-Name der Domäne, zum Beispiel example.com.
Hinweis: Um Bash als Standardshell festzulegen, führen Sie den Befehl /opt/pbis/bin/config LoginShellTemplate/bin/bash aus.
Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in Active Directory haben. Um zu überprüfen, ob eine PBIS-verbundene Linux-Maschine in der Domäne ist:
/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->
Wenn die Maschine einer Domäne beigetreten ist, gibt dieser Befehl die Informationen über die aktuell beigetretene AD-Domäne und OU zurück. Andernfalls wird nur der Hostname angezeigt.
Um zu überprüfen, ob PBIS Domänenbenutzer über PAM authentifizieren kann, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das zuvor noch nicht verwendet wurde.
ssh localhost -l domain\\user
id -u
<!--NeedCopy-->
Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die vom Befehl id -u zurückgegebene UID erstellt wurde:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Beenden Sie die Sitzung.
exit
<!--NeedCopy-->
Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.
Bevor Sie den Linux VDA installieren, installieren Sie .NET Runtime 6.0 gemäß den Anweisungen unter https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.
Nach der Installation von .NET Runtime 6.0 führen Sie den Befehl which dotnet aus, um Ihren Runtime-Pfad zu finden.
Basierend auf der Befehlsausgabe legen Sie den binären .NET Runtime-Pfad fest. Wenn die Befehlsausgabe beispielsweise /aa/bb/dotnet ist, verwenden Sie /aa/bb als .NET-Binärpfad.
Gehen Sie zur Citrix Virtual Apps and Desktops Downloadseite. Erweitern Sie die entsprechende Version von Citrix Virtual Apps and Desktops und klicken Sie auf Komponenten, um das Linux VDA-Paket herunterzuladen, das Ihrer Linux-Distribution entspricht.
Sie können eine Neuinstallation durchführen oder eine bestehende Installation von den beiden vorherigen Versionen und von einer LTSR-Version aktualisieren.
(Optional) Deinstallieren der alten Version
Wenn Sie eine frühere Version als die beiden vorherigen und eine LTSR-Version installiert haben, deinstallieren Sie diese, bevor Sie die neue Version installieren.
Beenden der Linux VDA-Dienste:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx stop
<!--NeedCopy-->
Hinweis:
Bevor Sie die Dienste
ctxvdaundctxhdxbeenden, führen Sie den Befehl service ctxmonitorservice stop aus, um den Überwachungsdienst-Daemon zu beenden. Andernfalls startet der Überwachungsdienst-Daemon die von Ihnen beendeten Dienste neu.
Deinstallieren des Pakets:
sudo rpm -e XenDesktopVDA
<!--NeedCopy-->
Hinweis:
Um einen Befehl auszuführen, ist der vollständige Pfad erforderlich; alternativ können Sie /opt/Citrix/VDA/sbin und /opt/Citrix/VDA/bin zum Systempfad hinzufügen.
Herunterladen des Linux VDA-Pakets
Gehen Sie zur Downloadseite für Citrix Virtual Apps and Desktops. Erweitern Sie die entsprechende Version von Citrix Virtual Apps and Desktops und klicken Sie auf Komponenten, um das Linux VDA-Paket herunterzuladen, das Ihrer Linux-Distribution entspricht.
Installieren des Linux VDA
Yum:Für Amazon Linux 2:
```
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy--> ```
**Für RHEL 8:**
```
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy--> ```
**Für CentOS 7 und RHEL 7:**
```
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy--> ```
Installieren Sie die Linux VDA-Software mit dem RPM-Paketmanager. Zuvor müssen Sie die folgenden Abhängigkeiten auflösen:
Für Amazon Linux 2:
sudo rpm -i XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
Für RHEL 8:
sudo rpm -i XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
Für CentOS 7 und RHEL 7:
sudo rpm -i XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
RPM-Abhängigkeitsliste für RHEL 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 Amazon Linux 2, CentOS 7 und RHEL 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
xorg-x11-server-Xorg >= 1.20.4
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 Matrix der Linux-Distributionen und der Xorg-Versionen, die diese Version des Linux VDA unterstützt, finden Sie unter Systemanforderungen.
Nach der Installation des Linux VDA unter RHEL 7.x führen Sie den Befehl
sudo yum install -y python-websockify x11vncaus. Dies dient dazu,python-websockifyundx11vncmanuell für die Verwendung der Sitzungsschattenfunktion zu installieren. Weitere Informationen finden Sie unter Sitzungen schatten.
Sie können eine vorhandene Installation von den beiden vorherigen Versionen und von einer LTSR-Version aktualisieren.
Hinweis:
Das Aktualisieren einer vorhandenen Installation überschreibt die Konfigurationsdateien unter /etc/xdl. Bevor Sie ein Upgrade durchführen, stellen Sie sicher, dass Sie die Dateien sichern.
So aktualisieren Sie Ihre Software mit Yum:
Für Amazon Linux 2:
sudo yum install -y XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
Für RHEL 8:
sudo yum install -y XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
Für CentOS 7 und RHEL 7:
sudo yum install -y XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
So aktualisieren Sie Ihre Software mit dem RPM-Paketmanager:
Für Amazon Linux 2:
sudo rpm -U XenDesktopVDA-<version>.amzn2.x86_64.rpm
<!--NeedCopy-->
Für RHEL 8:
sudo rpm -U XenDesktopVDA-<version>.el8_x.x86_64.rpm
<!--NeedCopy-->
Für CentOS 7 und RHEL 7:
sudo rpm -U XenDesktopVDA-<version>.el7_x.x86_64.rpm
<!--NeedCopy-->
Hinweis:
Wenn Sie RHEL 7 verwenden, stellen Sie sicher, dass Sie die folgenden Schritte ausführen, nachdem Sie die vorhergehenden Upgrade-Befehle ausgeführt haben:
Führen Sie
/opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "DotNetRuntimePath" -d "/opt/rh/rh-dotnet31/root/usr/bin/" --forceaus, um den korrekten .NET-Laufzeitpfad festzulegen.Starten Sie den Dienst
ctxvdaneu.Wichtig:
Starten Sie die Linux VDA-Maschine nach dem Software-Upgrade neu.
Um HDX 3D Pro zu aktivieren, müssen Sie die NVIDIA GRID-Treiber auf Ihrem Hypervisor und auf den VDA-Maschinen installieren.
Informationen zur Installation und Konfiguration des NVIDIA GRID Virtual GPU Manager (des Hosttreibers) auf den jeweiligen Hypervisoren finden Sie in den folgenden Anleitungen:
Führen Sie die folgenden Schritte aus, um die NVIDIA GRID Gast-VM-Treiber zu installieren und zu konfigurieren:
Bereiten Sie die VM für den NVIDIA GRID-Treiber vor:
yum install gcc
yum install "kernel-devel-$(uname -r)"
systemctl set-default multi-user.target
<!--NeedCopy-->
Hinweis:
Wählen Sie während der Installation des GPU-Treibers bei jeder Frage die Standardoption (‘Nein’).
Wichtig:
Nachdem GPU-Passthrough aktiviert wurde, ist die Linux-VM nicht mehr über XenCenter 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. Informationen zur Beantragung der Lizenz finden Sie in der Produktdokumentation “GRID Licensing Guide.pdf - DU-07757-001 September 2015”.
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 Aufforderungen 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-->
Führen Sie eine manuelle Konfiguration mit gestellten Fragen durch:
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
Für eine automatisierte Installation geben Sie die vom Setup-Skript benötigten Optionen über Umgebungsvariablen an. Wenn alle erforderlichen Variablen vorhanden sind, fordert das Skript keine Informationen an.
Unterstützte Umgebungsvariablen umfassen:
CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – Der Pfad zur Installation der .NET Runtime 6.0 zur Unterstützung des neuen Broker-Agent-Dienstes (ctxvda). Der Standardpfad ist /usr/bin.
Hinweis:
Sie können die Desktop-Umgebung für einen Ziel-Sitzungsbenutzer auch ändern, indem Sie die folgenden Schritte ausführen:
- Erstellen Sie eine
.xsession- oder.Xclients-Datei im Verzeichnis $HOME/<Benutzername> auf dem VDA. Wenn Sie Amazon Linux 2 verwenden, erstellen Sie eine.Xclients-Datei. Wenn Sie andere Distributionen verwenden, erstellen Sie eine.xsession-Datei.- Bearbeiten Sie die
.xsession- oder.Xclients-Datei, um eine Desktop-Umgebung basierend auf den Distributionen anzugeben.
Für MATE-Desktop unter Amazon Linux 2, CentOS und RHEL
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fiFür GNOME-Desktop unter CentOS und RHEL
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fiFür GNOME-Desktop unter Amazon Linux 2
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi- Teilen Sie die Dateiberechtigung 700 mit dem Ziel-Sitzungsbenutzer.
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-->
Wenn Sie den sudo-Befehl ausführen, geben Sie die Option -E ein, um die vorhandenen Umgebungsvariablen an die neue Shell zu übergeben, die er erstellt. Wir empfehlen, dass Sie aus den vorhergehenden Befehlen eine Shell-Skriptdatei 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|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-->
In einigen Szenarien müssen Sie möglicherweise die durch das Skript ctxsetup.sh vorgenommenen Konfigurationsänderungen entfernen, ohne das Linux VDA-Paket zu deinstallieren.
Lesen Sie die Hilfe zu diesem Skript, bevor Sie fortfahren:
sudo /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 unbrauchbar.
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.
Führen Sie sudo /opt/Citrix/VDA/bin/xdping aus, um häufige Konfigurationsprobleme in einer Linux VDA-Umgebung zu überprüfen. Weitere Informationen finden Sie unter XDPing.
Nachdem Sie den Linux VDA mit dem Skript ctxsetup.sh konfiguriert haben, können Sie die folgenden Befehle ausführen, um den Linux VDA zu steuern.
Linux VDA starten:
So starten Sie die Linux VDA-Dienste:
sudo /sbin/service ctxhdx start
sudo /sbin/service ctxvda start
<!--NeedCopy-->
Anhalten des Linux VDA:
So halten Sie die Linux VDA-Dienste an:
sudo /sbin/service ctxvda stop
sudo /sbin/service ctxhdx stop
<!--NeedCopy-->
Hinweis:
Bevor Sie die Dienste
ctxvdaundctxhdxanhalten, führen Sie den Befehlservice ctxmonitorservice stopaus, um den Monitor-Dienst-Daemon anzuhalten. Andernfalls startet der Monitor-Dienst-Daemon die von Ihnen angehaltenen Dienste neu.
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-->
Der Prozess zum Erstellen von Maschinenkatalogen und Hinzufügen von Linux VDA-Maschinen ähnelt dem traditionellen Windows VDA-Ansatz. Eine detailliertere Beschreibung zur Durchführung dieser Aufgaben finden Sie unter Maschinenkataloge erstellen und Maschinenkataloge verwalten.
Für die Erstellung von Maschinenkatalogen, die Linux VDA-Maschinen enthalten, gibt es einige Einschränkungen, die den Prozess von der Erstellung von Maschinenkatalogen für Windows VDA-Maschinen unterscheiden:
Hinweis:
Frühere Versionen von Citrix Studio unterstützten den Begriff “Linux OS” nicht. Die Auswahl der Option Windows Server OS oder Server OS impliziert jedoch ein äquivalentes Bereitstellungsmodell für gehostete Shared Desktops. Die Auswahl der Option Windows Desktop OS oder Desktop OS impliziert ein Bereitstellungsmodell mit einem Benutzer pro Maschine.
Tipp:
Wenn Sie eine Maschine aus der Active Directory-Domäne entfernen und wieder hinzufügen, müssen Sie die Maschine erneut aus dem Maschinenkatalog entfernen und hinzufügen.
Der Prozess zum Erstellen einer Bereitstellungsgruppe und zum Hinzufügen von Maschinenkatalogen, die Linux VDA-Maschinen enthalten, ist nahezu identisch mit dem für Windows VDA-Maschinen. Eine detailliertere Beschreibung zur Durchführung dieser Aufgaben finden Sie unter Bereitstellungsgruppen erstellen.
Für die Erstellung von Bereitstellungsgruppen, die Linux VDA-Maschinenkataloge enthalten, gelten die folgenden Einschränkungen:
Wichtig:
Die Veröffentlichung von Anwendungen wird ab Linux VDA Version 1.4 unterstützt. Der Linux VDA unterstützt jedoch nicht die Bereitstellung von Desktops und Apps auf derselben Maschine.
Informationen zum Erstellen von Maschinenkatalogen und Bereitstellungsgruppen finden Sie unter Citrix Virtual Apps and Desktops 7 2112.