layout: doc h3InToc: true
Wichtig:
Für Neuinstallationen empfehlen wir Ihnen, die einfache Installation für eine schnelle Einrichtung zu verwenden. Die einfache Installation spart Zeit und Arbeitsaufwand und ist weniger fehleranfällig als die in diesem Artikel beschriebene manuelle Installation.
Stellen Sie sicher, dass das Netzwerk verbunden und korrekt konfiguriert ist. Sie müssen beispielsweise den DNS-Server auf dem Linux VDA konfigurieren.
Wenn Sie einen Ubuntu 18.04 Live Server verwenden, nehmen Sie die folgende Änderung in der Konfigurationsdatei /etc/cloud/cloud.cfg vor, bevor Sie den Hostnamen festlegen:
preserve_hostname: true
Um sicherzustellen, dass der Hostname der Maschine korrekt gemeldet wird, ändern Sie die Datei /etc/hostname so, dass sie nur den Hostnamen der Maschine enthält.
hostname
Stellen Sie sicher, dass der DNS-Domänenname und der vollqualifizierte Domänenname (FQDN) der Maschine korrekt zurückgemeldet werden. Dazu ändern Sie die folgende Zeile der Datei /etc/hosts, um den FQDN und den Hostnamen als erste zwei Einträge aufzunehmen:
127.0.0.1 hostname-fqdn hostname localhost
Beispiel:
127.0.0.1 vda01.example.com vda01 localhost
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. Daher darf der Hostname 15 Zeichen nicht überschreiten.
Tipp:
Verwenden Sie nur die Zeichen a–z, A–Z, 0–9 und Bindestrich (-). Vermeiden Sie Unterstriche (_), Leerzeichen und andere Symbole. Beginnen Sie einen Hostnamen nicht mit einer Zahl und beenden Sie ihn nicht mit einem Bindestrich. Diese Regel gilt auch für Delivery Controller-Hostnamen.
Überprüfen Sie, ob der Hostname korrekt festgelegt ist:
hostname
<!--NeedCopy-->
Dieser Befehl gibt nur den Hostnamen der Maschine und nicht ihren FQDN zurück.
Überprüfen Sie, ob der FQDN korrekt festgelegt ist:
hostname -f
<!--NeedCopy-->
Dieser Befehl gibt den FQDN der Maschine zurück.
Die Standardeinstellungen haben Multicast-DNS (mDNS) aktiviert, was zu inkonsistenten Namensauflösungsergebnissen führen kann.
Um mDNS zu deaktivieren, bearbeiten Sie /etc/nsswitch.conf und ändern Sie die Zeile, die Folgendes enthält:
hosts: files mdns_minimal [NOTFOUND=return] dns
Zu:
hosts: files dns
Ü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 eine dieser Maschinen nicht anpingen können, überprüfen Sie die Schritte, bevor Sie fortfahren.
Die Aufrechterhaltung einer genauen Zeitsynchronisation zwischen den VDAs, Delivery Controllern und Domänencontrollern ist entscheidend. Das Hosten des Linux VDA als virtuelle Maschine (VM) kann zu Problemen mit der Zeitverschiebung führen. Aus diesem Grund wird die Synchronisation der Zeit mit einem externen Zeitdienst bevorzugt.
Chrony installieren:
apt-get install chrony
<!--NeedCopy-->
Bearbeiten Sie als Root-Benutzer die Datei /etc/chrony/chrony.conf und fügen Sie einen Servereintrag für jeden externen Zeitserver hinzu:
server peer1-fqdn-or-ip-address iburst
server peer2-fqdn-or-ip-address iburst
In einer typischen Bereitstellung synchronisieren Sie die Zeit von den lokalen Domänencontrollern und nicht direkt von öffentlichen NTP-Pool-Servern. Fügen Sie einen Servereintrag für jeden Active Directory-Domänencontroller in der Domäne hinzu.
Entfernen Sie alle anderen aufgeführten server- oder pool-Einträge, einschließlich Loopback-IP-Adresse, Localhost und öffentliche Server-Einträge *.pool.ntp.org.
Änderungen speichern und den Chrony-Daemon neu starten:
sudo systemctl restart chrony
<!--NeedCopy-->
Der Linux VDA erfordert die Anwesenheit von OpenJDK 11.
Unter Ubuntu 20.04 und Ubuntu 18.04 installieren Sie OpenJDK 11 mit:
sudo apt-get install -y openjdk-11-jdk
<!--NeedCopy-->
Als experimentelle Funktion können Sie SQLite zusätzlich zu PostgreSQL verwenden. Sie können auch zwischen SQLite und PostgreSQL wechseln, indem Sie /etc/xdl/db.conf nach der Installation des Linux VDA-Pakets bearbeiten. Bei manuellen Installationen müssen Sie SQLite und PostgreSQL manuell installieren, bevor Sie zwischen ihnen wechseln können.
Dieser Abschnitt beschreibt, wie die PostgreSQL- und SQLite-Datenbanken installiert und wie eine zu verwendende Datenbank angegeben wird.
Hinweis:
Wir empfehlen die Verwendung von SQLite nur für den VDI-Modus.
Führen Sie die folgenden Befehle aus, um PostgreSQL zu installieren:
sudo apt-get install -y postgresql
sudo apt-get install -y libpostgresql-jdbc-java
<!--NeedCopy-->
Führen Sie die folgenden Befehle aus, um PostgreSQL beim Maschinenstart bzw. sofort zu starten:
sudo systemctl enable postgresql
sudo systemctl restart postgresql
<!--NeedCopy-->
Führen Sie unter Ubuntu den folgenden Befehl aus, um SQLite zu installieren:
sudo apt-get install -y sqlite3
<!--NeedCopy-->
Nachdem Sie SQLite, PostgreSQL oder beides installiert haben, können Sie eine zu verwendende Datenbank festlegen, indem Sie /etc/xdl/db.conf nach der Installation des Linux VDA-Pakets bearbeiten. Gehen Sie dazu wie folgt vor:
/opt/Citrix/VDA/sbin/ctxcleanup.sh aus. Überspringen Sie diesen Schritt bei einer Neuinstallation./etc/xdl/db.conf, um eine zu verwendende Datenbank festzulegen.ctxsetup.sh aus.Hinweis:
Sie können /etc/xdl/db.conf auch verwenden, um die Portnummer für PostgreSQL zu konfigurieren.
sudo apt-get install -y libxm4
<!--NeedCopy-->
Für Ubuntu 22.04:
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libsasl2-modules-gssapi-mit
sudo apt-get install -y libldap-2.5-0
sudo apt-get install -y krb5-user
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
Für Ubuntu 20.04, Ubuntu 18.04:
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libsasl2-modules-gssapi-mit
sudo apt-get install -y libldap-2.4-2
sudo apt-get install -y krb5-user
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
Einige Änderungen sind erforderlich, wenn der Linux VDA als VM 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 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 überprüfen, ob die Citrix Hypervisor-Zeitsynchronisierungsfunktion in der Linux-VM 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.
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.
Linux-VMs mit installierten Hyper-V Linux Integration Services können die Hyper-V-Zeitsynchronisierungsfunktion verwenden, um die Zeit des Host-Betriebssystems zu nutzen. Um sicherzustellen, dass die Systemuhr genau bleibt, aktivieren Sie diese Funktion zusammen mit den NTP-Diensten.
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 NTP synchronisiert ist. In diesem Fall muss die Host-Zeitsynchronisierung deaktiviert werden.
Wenn Sie einen paravirtualisierten Linux-Kernel mit installierten VMware Tools ausführen:
Die folgenden Methoden stehen zur Verfügung, um Linux-Maschinen zur Active Directory (AD)-Domäne hinzuzufügen:
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.
sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user
<!--NeedCopy-->
Der Winbind-Daemon muss so konfiguriert werden, dass er beim Maschinenstart gestartet wird:
sudo systemctl enable winbind
<!--NeedCopy-->
Hinweis:
Stellen Sie sicher, dass sich das Skript
winbindunter/etc/init.dbefindet.
Öffnen Sie /etc/krb5.conf als Root-Benutzer und nehmen Sie die folgenden Einstellungen vor:
Hinweis:
Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur. Die folgenden Einstellungen sind für das Einzeldomänen-, Einzelforst-Modell vorgesehen.
[libdefaults]
default_realm = REALM
dns_lookup_kdc = false
[realms]
REALM = {
admin_server = domain-controller-fqdn
kdc = domain-controller-fqdn
}
[domain_realm]
Domänen-DNS-Name = REALM
.Domänen-DNS-Name = REALM
Der Parameter Domänen-DNS-Name ist in diesem Kontext der DNS-Domänenname, z. B. example.com. Der REALM ist der Kerberos-Realm-Name in Großbuchstaben, z. B. EXAMPLE.COM.
Konfigurieren Sie Winbind manuell, da Ubuntu kein Tool wie authconfig in RHEL und yast2 in SUSE besitzt.
Öffnen Sie /etc/samba/smb.conf, und nehmen Sie die folgenden Einstellungen vor:
[global]
workgroup = WORKGROUP
security = ADS
realm = REALM
encrypt passwords = yes
idmap config *:range = 16777216-33554431
winbind trusted domains only = no
kerberos method = secrets and keytab
winbind refresh tickets = yes
template shell = /bin/bash
WORKGROUP ist das erste Feld in REALM, und REALM ist der Kerberos-Realm-Name in Großbuchstaben.
Öffnen Sie /etc/nsswitch.conf, und fügen Sie winbind an die folgenden Zeilen an:
passwd: compat winbind
group: compat winbind
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-->
Dabei ist REALM der Kerberos-Realm-Name in Großbuchstaben, und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.
winbind neu startensudo systemctl restart winbind
<!--NeedCopy-->
Führen Sie den folgenden Befehl aus und stellen Sie sicher, dass die Optionen Winbind NT/Active Directory authentication und Create home directory on login ausgewählt sind:
sudo pam-auth-update
<!--NeedCopy-->
Tipp:
Der winbind-Daemon bleibt nur aktiv, wenn der Computer einer Domäne beigetreten ist.
Der Delivery Controller erfordert, dass alle VDA-Maschinen, ob Windows oder Linux, ein Computerobjekt in Active Directory besitzen.
Führen Sie den Befehl net ads 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 zu überprüfen, ob Kerberos für die Verwendung mit dem Linux VDA korrekt konfiguriert ist, stellen Sie sicher, dass die Systemdatei keytab erstellt wurde und gültige Schlüssel enthält:
sudo klist -ke
<!--NeedCopy-->
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 folgendem Befehl zwischengespeichert wurde:
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 (\)-Charakter mit einem weiteren Backslash maskiert werden. Dieser Befehl gibt eine Meldung zurück, die den Erfolg oder Misserfolg anzeigt.
Um zu überprüfen, ob das Winbind PAM-Modul korrekt konfiguriert ist, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das zuvor noch nicht verwendet wurde.
ssh localhost -l domain\\username
id -u
<!--NeedCopy-->
Hinweis:
Um einen SSH-Befehl erfolgreich auszuführen, stellen Sie sicher, dass SSH aktiviert ist und ordnungsgemäß funktioniert.
Überprüfen Sie, ob eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die vom Befehl id -u zurückgegebene UID erstellt wurde:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Überprüfen Sie, ob die Tickets im Kerberos-Anmeldeinformations-Cache des Benutzers gültig und nicht abgelaufen sind:
klist
<!--NeedCopy-->
Beenden Sie die Sitzung.
exit
<!--NeedCopy-->
Ein ähnlicher Test kann durchgeführt werden, indem Sie sich direkt an der Gnome- oder KDE-Konsole anmelden. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.
Tipp:
Wenn die Benutzerauthentifizierung erfolgreich ist, Sie aber Ihren Desktop beim Anmelden mit einem Domänenkonto nicht anzeigen können, starten Sie den Computer neu und versuchen Sie es dann erneut.
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 gelten gleichermaßen für die Einrichtung von Domänenbenutzern zur Anmeldung über die Konsole, RDP, SSH oder jedes andere Remoting-Protokoll.
In der Standard-RHEL-Umgebung ist SELinux vollständig erzwungen. Diese Erzwingung beeinträchtigt die von Quest verwendeten Unix-Domain-Socket-IPC-Mechanismen und verhindert, dass sich Domänenbenutzer anmelden können.
Die bequemste Methode, dieses Problem zu umgehen, ist die Deaktivierung von SELinux. Bearbeiten Sie als Root-Benutzer die Datei /etc/selinux/config und ändern Sie die Einstellung SELinux:
SELINUX=disabled
Diese Änderung erfordert einen Neustart des Computers:
- 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 Ticket-Lebensdauer von 10 Stunden. Legen Sie diesen Parameter auf Systemen mit einer kürzeren Ticket-Lebensdauer auf einen niedrigeren Wert fest.
Um die Domänenbenutzeranmeldung über HDX und andere Dienste wie su, ssh und RDP zu ermöglichen, führen Sie die folgenden Befehle aus, um PAM und NSS manuell zu konfigurieren:
sudo /opt/quest/bin/vastool configure pam
sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->
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 mit Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne. Der Parameter domain-name ist der DNS-Name der Domäne, z. B. example.com.
Der Delivery Controller erfordert, dass alle VDA-Maschinen, ob Windows oder Linux, 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, wird der folgende Fehler angezeigt:
ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain
Um zu überprüfen, ob Quest Domänenbenutzer über PAM authentifizieren kann, 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 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-->
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 Parameter user ist ein beliebiger Active Directory-Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne. Der Parameter domain-name ist der Name der Domäne, der die Linux-Maschine beitreten soll.
Der Delivery Controller erfordert, dass alle VDA-Maschinen, ob Windows oder Linux, 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 mode den Wert connected zurückgibt. Wenn der Modus im Startzustand hängen bleibt, hat der Centrify-Client Probleme mit der Serververbindung oder Authentifizierung.
Umfassendere System- und Diagnoseinformationen sind verfügbar mit:
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.
Führen Sie den folgenden Befehl aus, um Kerberos zu installieren:
sudo apt-get install krb5-user
<!--NeedCopy-->
Um Kerberos zu konfigurieren, öffnen Sie /etc/krb5.conf als Root und legen Sie die Parameter fest:
Hinweis:
Konfigurieren Sie Kerberos basierend auf Ihrer AD-Infrastruktur. Die folgenden Einstellungen sind für das Einzeldomänen-, Einzelforst-Modell vorgesehen.
[libdefaults]
default_realm = REALM
dns_lookup_kdc = false
[realms]
REALM = {
admin_server = domain-controller-fqdn
kdc = domain-controller-fqdn
}
[domain_realm]
domain-dns-name = REALM
.domain-dns-name = REALM
Der domain-dns-name-Parameter ist in diesem Kontext der DNS-Domänenname, z. B. example.com. Der REALM ist der Kerberos-Realm-Name in Großbuchstaben, z. B. EXAMPLE.COM.
SSSD muss so konfiguriert werden, dass es Active Directory als Identitätsanbieter und Kerberos zur Authentifizierung verwendet. SSSD bietet jedoch keine AD-Client-Funktionen zum Beitreten zur Domäne und zur Verwaltung der System-Keytab-Datei. Stattdessen können Sie adcli, realmd oder Samba verwenden.
Hinweis:
Dieser Abschnitt enthält nur Informationen zu adcli und Samba.
Installieren Sie adcli.
sudo apt-get install adcli
<!--NeedCopy-->
Treten Sie der Domäne mit adcli bei.
Entfernen Sie die alte System-Keytab-Datei und treten Sie der Domäne bei mit:
su -
rm -rf /etc/krb5.keytab
adcli join domain-dns-name -U user -H hostname-fqdn
<!--NeedCopy-->
Der Benutzer ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Maschinen zur Domäne. Der hostname-fqdn ist der Hostname im FQDN-Format für die Maschine.
Die Option -H ist erforderlich, damit adcli einen SPN im Format host/hostname-fqdn@REALM generiert, den der Linux VDA benötigt.
Führen Sie für Ubuntu 22.04- und Ubuntu 20.04-Maschinen den Befehl adcli testjoin aus, um zu testen, ob die Maschinen der Domäne beigetreten sind.
Führen Sie für eine Ubuntu 18.04-Maschine den Befehl sudo klist -ket aus. Die Funktionalität des adcli-Tools ist begrenzt. Das Tool bietet keine Möglichkeit zu testen, ob eine Maschine der Domäne beigetreten ist. Die beste Alternative besteht darin, sicherzustellen, dass die System-Keytab-Datei erstellt wurde. Überprüfen Sie, ob der Zeitstempel für jeden Schlüssel mit der Zeit übereinstimmt, zu der die Maschine der Domäne beigetreten ist.
Installieren Sie das Paket.
sudo apt-get install samba krb5-user
<!--NeedCopy-->
Konfigurieren Sie Samba.
Öffnen Sie /etc/samba/smb.conf und nehmen Sie die folgenden Einstellungen vor:
[global]
workgroup = WORKGROUP
security = ADS
realm = REALM
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
WORKGROUP ist das erste Feld in REALM, und REALM ist der Kerberos-Realm-Name in Großbuchstaben.
Ihr Domänencontroller muss erreichbar sein, und Sie müssen über ein Windows-Konto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen.
sudo net ads join REALM -U user
<!--NeedCopy-->
Dabei ist REALM der Kerberos-Realm-Name in Großbuchstaben, und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.
- **Erforderliche Pakete installieren oder aktualisieren:**
Installieren Sie die erforderlichen SSSD- und Konfigurationspakete, falls diese noch nicht installiert sind:
sudo apt-get install sssd
<!--NeedCopy-->
Wenn die Pakete bereits installiert sind, wird ein Update empfohlen:
sudo apt-get install --only-upgrade sssd
<!--NeedCopy-->
Hinweis:
Standardmäßig konfiguriert der Installationsprozess in Ubuntu nsswitch.conf und das PAM-Anmeldemodul automatisch.
SSSD-Konfigurationsänderungen sind erforderlich, bevor der SSSD-Daemon gestartet wird. Bei einigen SSSD-Versionen ist die Konfigurationsdatei /etc/sssd/sssd.conf standardmäßig nicht installiert und muss manuell erstellt werden. Erstellen oder öffnen Sie als Root /etc/sssd/sssd.conf und nehmen Sie die folgenden Einstellungen vor:
[sssd]
services = nss, pam
config_file_version = 2
domains = domain-dns-name
[domain/domain-dns-name]`
id_provider = ad
access_provider = ad
auth_provider = krb5
krb5_realm = REALM
# Setzen Sie krb5_renewable_lifetime höher, wenn die TGT-Erneuerungslebensdauer länger als 14 Tage ist
krb5_renewable_lifetime = 14d
# Setzen Sie krb5_renew_interval auf einen niedrigeren Wert, wenn die TGT-Ticket-Lebensdauer kürzer als 2 Stunden ist
krb5_renew_interval = 1h
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# Diese Einstellung für ldap_id_mapping ist auch der Standardwert
ldap_id_mapping = true
override_homedir = /home/%d/%u
default_shell = /bin/bash
ad_gpo_map_remote_interactive = +ctxhdx
Hinweis:
ldap_id_mappingist auf true gesetzt, damit SSSD selbst die Zuordnung von Windows-SIDs zu Unix-UIDs übernimmt. Andernfalls muss das Active Directory POSIX-Erweiterungen bereitstellen können. Der PAM-Dienstctxhdxwird zuad_gpo_map_remote_interactivehinzugefügt.Der Parameter domain-dns-name ist in diesem Kontext der DNS-Domänenname, z. B. example.com. Das REALM ist der Kerberos-Realm-Name in Großbuchstaben, z. B. EXAMPLE.COM. Es ist nicht erforderlich, den NetBIOS-Domänennamen zu konfigurieren.
Informationen zu den Konfigurationseinstellungen finden Sie in den Manpages für
sssd.confundsssd-ad.
Der SSSD-Daemon erfordert, dass die Konfigurationsdatei nur Leseberechtigungen für den Besitzer hat:
sudo chmod 0600 /etc/sssd/sssd.conf
<!--NeedCopy-->
Führen Sie die folgenden Befehle aus, um den SSSD-Daemon jetzt zu starten und ihn für den Start beim Maschinenstart zu aktivieren:
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
Führen Sie den folgenden Befehl aus und stellen Sie sicher, dass die Optionen SSS-Authentifizierung und Home-Verzeichnis bei Anmeldung erstellen ausgewählt sind:
sudo pam-auth-update
<!--NeedCopy-->
Der Delivery Controller erfordert, dass alle VDA-Maschinen (Windows- und Linux-VDAs) ein Computerobjekt in Active Directory haben.
Wenn Sie adcli zur Überprüfung der Domänenmitgliedschaft verwenden, führen Sie den Befehl sudo adcli info domain-dns-name aus, um die Domäneninformationen anzuzeigen.
- Wenn Sie **Samba** zur Überprüfung der Domänenmitgliedschaft verwenden, führen Sie den Befehl `sudo net ads testjoin` aus, um zu überprüfen, ob die Maschine einer Domäne beigetreten ist, und den Befehl `sudo net ads info`, um zusätzliche Domänen- und Computerobjektinformationen zu überprüfen.
Um zu überprüfen, ob 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 die Maschine mit dem Domänencontroller unter Verwendung dieser Schlüssel zu authentifizieren:
sudo kinit -k MACHINE\$@REALM
<!--NeedCopy-->
Die Maschinen- und Realm-Namen müssen in Großbuchstaben angegeben werden. Das Dollarzeichen ($) muss mit einem Backslash (\) maskiert werden, um eine Shell-Substitution zu verhindern. In einigen Umgebungen unterscheidet sich der DNS-Domänenname vom Kerberos-Realm-Namen. Stellen Sie sicher, dass der Realm-Name verwendet wird. Wenn dieser Befehl erfolgreich ist, wird keine Ausgabe angezeigt.
Überprüfen Sie, ob das TGT für das Maschinenkonto zwischengespeichert wurde, indem Sie Folgendes verwenden:
sudo klist
<!--NeedCopy-->
SSSD bietet kein Befehlszeilentool zum direkten Testen der Authentifizierung mit dem Daemon, dies kann nur über PAM erfolgen.
Um zu überprüfen, ob das SSSD PAM-Modul korrekt konfiguriert ist, melden Sie sich am Linux VDA mit einem Domänenbenutzerkonto an, das zuvor noch nicht verwendet wurde.
- ssh localhost -l domain\\username
- id -u
klist
exit
<!--NeedCopy-->
Überprüfen Sie, ob die vom Befehl klist zurückgegebenen Kerberos-Tickets für diesen Benutzer korrekt sind und nicht abgelaufen sind.
Überprüfen Sie als Root-Benutzer, ob eine entsprechende Ticket-Cache-Datei für die UID erstellt wurde, die vom vorherigen Befehl id -u zurückgegeben wurde:
- ls /tmp/krb5cc_uid
<!--NeedCopy-->
Ein ähnlicher Test kann durch Anmeldung bei KDE oder Gnome Display Manager durchgeführt werden. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 6: Installieren des Linux VDA fort.
sudo wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
sudo chmod +x pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
sudo sh pbis-open-9.1.0.551.linux.x86_64.deb.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:
sudo /opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
Der Benutzer ist ein Domänenbenutzer, der über Berechtigungen zum Hinzufügen von Computern zur Active Directory-Domäne verfügt. Der Domänenname ist der DNS-Name der Domäne, z. B. example.com.
Hinweis: Um Bash als Standardshell festzulegen, führen Sie den Befehl sudo /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 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.
sudo ssh localhost -l domain\\user
id -u
<!--NeedCopy-->
Vergewissern Sie sich, dass eine entsprechende Kerberos-Anmeldeinformations-Cache-Datei für die von dem Befehl id -u zurückgegebene UID erstellt wurde:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Beenden Sie die Sitzung.
exit
<!--NeedCopy-->
Fahren Sie nach der Überprüfung der Domänenverknüpfung 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 lautet, verwenden Sie /aa/bb als binären .NET-Pfad.
Klicken Sie auf Components, um das Linux VDA-Paket, das Ihrer Linux-Distribution entspricht, und den öffentlichen GPG-Schlüssel herunterzuladen, mit dem Sie die Integrität des Linux VDA-Pakets überprüfen können.
Um die Integrität des Linux VDA-Pakets mithilfe des öffentlichen Schlüssels zu überprüfen, importieren Sie den öffentlichen Schlüssel in die DEB-Datenbank und führen Sie die folgenden Befehle aus:
```
sudo apt-get install dpkg-sig
gpg --import <path to the public key>
dpkg-sig --verify <path to the Linux VDA package>
<!--NeedCopy--> ```
Installieren Sie die Linux VDA-Software mit dem Debian-Paketmanager:
Für Ubuntu 22.04:
sudo dpkg -i xendesktopvda_<version>.ubuntu22.04_amd64.deb
<!--NeedCopy-->
Für Ubuntu 20.04:
sudo dpkg -i xendesktopvda_<version>.ubuntu20.04_amd64.deb
<!--NeedCopy-->
Hinweis:
Deaktivieren Sie für Ubuntu 20.04 auf GCP RDNS. Fügen Sie dazu die Zeile rdns = false unter [libdefaults] in /etc/krb5.conf hinzu.
Für Ubuntu 18.04:
sudo dpkg -i xendesktopvda_<version>.ubuntu18.04_amd64.deb
<!--NeedCopy-->
Debian-Abhängigkeitsliste für Ubuntu 22.04:
openjdk-11-jdk >= 11
imagemagick >= 8:6.9.11
libgtkmm-3.0-1v5 >= 3.24.5
ufw >= 0.36
ubuntu-desktop >= 1.481
libxrandr2 >= 2:1.5.2
libxtst6 >= 2:1.2.3
libxm4 >= 2.3.8
util-linux >= 2.37
gtk3-nocsd >= 3
bash >= 5.1
findutils >= 4.8.0
sed >= 4.8
cups >= 2.4
libmspack0 >= 0.10
ibus >= 1.5
libgoogle-perftools4 >= 2.9~
libpython3.10 >= 3.10~
libsasl2-modules-gssapi-mit >= 2.1.~
libnss3-tools >= 2:3.68
libqt5widgets5 >= 5.15~
libqrencode4 >= 4.1.1
libimlib2 >= 1.7.4
<!--NeedCopy-->
Debian-Abhängigkeitsliste für Ubuntu 20.04:
openjdk-11-jdk >= 11
imagemagick >= 8:6.9.10
libgtkmm-3.0-1v5 >= 3.24.2
ufw >= 0.36
ubuntu-desktop >= 1.450
libxrandr2 >= 2:1.5.2
libxtst6 >= 2:1.2.3
libxm4 >= 2.3.8
util-linux >= 2.34
gtk3-nocsd >= 3
bash >= 5.0
findutils >= 4.7.0
sed >= 4.7
cups >= 2.3
libmspack0 >= 0.10
ibus >= 1.5
libgoogle-perftools4 >= 2.7~
libpython3.8 >= 3.8~
libsasl2-modules-gssapi-mit >= 2.1.~
libnss3-tools >= 2:3.49
libqt5widgets5 >= 5.7~
libqrencode4 >= 4.0.0
libimlib2 >= 1.6.1
<!--NeedCopy-->
Debian-Abhängigkeitsliste für Ubuntu 18.04:
openjdk-11-jdk >= 11
imagemagick >= 8:6.8.9.9
ufw >= 0.35
libgtkmm-3.0-1v5 >= 3.22.2
ubuntu-desktop >= 1.361
libxrandr2 >= 2:1.5.0
libxtst6 >= 2:1.2.2
libxm4 >= 2.3.4
util-linux >= 2.27.1
gtk3-nocsd >= 3
bash >= 4.3
findutils >= 4.6.0
sed >= 4.2.2
cups >= 2.1
libmspack0 >= 0.6
ibus >= 1.5
libsasl2-modules-gssapi-mit >= 2.1.~
libgoogle-perftools4 >= 2.4~
libpython3.6 >= 3.6~
libnss3-tools >= 2:3.35
libqt5widgets5 >= 5.7~
libqrencode3 >= 3.4.4
libimlib2 >= 1.4.10
<!--NeedCopy-->
Hinweis:
Eine Matrix der Linux-Distributionen und Xorg-Versionen, die diese Version des Linux VDA unterstützt, finden Sie unter Systemanforderungen.
Sie können eine vorhandene Installation von den beiden vorherigen Versionen und von einer LTSR-Version aktualisieren.
sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->
Hinweis:
Durch das Aktualisieren einer vorhandenen Installation werden die Konfigurationsdateien unter /etc/xdl überschrieben. Sichern Sie die Dateien, bevor Sie ein Upgrade durchführen.
Zum Aktivieren von HDX 3D Pro müssen Sie die NVIDIA GRID-Treiber auf Ihrem Hypervisor und auf den VDA-Maschinen installieren.
Informationen zum Installieren und Konfigurieren des NVIDIA GRID Virtual GPU Manager (des Hosttreibers) auf den jeweiligen Hypervisoren finden Sie in den folgenden Anleitungen:
Führen Sie die folgenden allgemeinen Schritte aus, um die NVIDIA GRID-Gast-VM-Treiber zu installieren und zu konfigurieren:
Hinweis:
Bevor Sie die Laufzeitumgebung einrichten, stellen Sie sicher, dass das Gebietsschema en_US.UTF-8 auf Ihrem Betriebssystem installiert ist. Wenn das Gebietsschema auf Ihrem Betriebssystem nicht verfügbar ist, führen Sie den Befehl sudo locale-gen en_US.UTF-8 aus. Bearbeiten Sie für Debian die Datei /etc/locale.gen, indem Sie die Zeile # en_US.UTF-8 UTF-8 auskommentieren, und führen Sie dann den Befehl sudo locale-gen aus.
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-->
Führen Sie eine manuelle Konfiguration mit Eingabeaufforderungen durch:
sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->
Für eine automatisierte Installation können die vom Setup-Skript benötigten Optionen über Umgebungsvariablen bereitgestellt werden. Wenn alle erforderlichen Variablen vorhanden sind, fordert das Skript den Benutzer nicht zur Eingabe von Informationen auf, was einen skriptgesteuerten Installationsprozess ermöglicht.
Unterstützte Umgebungsvariablen sind:
- **CTX\_XDL\_SUPPORT\_DDC\_AS\_CNAME=Y | N** – Der Linux VDA unterstützt die Angabe eines Delivery Controller-Namens mithilfe eines DNS-CNAME-Eintrags. Standardmäßig auf N festgelegt.
- **CTX\_XDL\_DDC\_LIST='list-ddc-fqdns'** – Der Linux VDA erfordert eine durch Leerzeichen getrennte Liste von Delivery Controller Fully Qualified Domain Names (FQDNs), die für die Registrierung bei einem Delivery Controller verwendet werden sollen. Mindestens ein FQDN oder CNAME-Alias muss angegeben werden.
| **CTX_XDL_REGISTER_SERVICE=Y | N** – Die Linux VDA-Dienste werden nach dem Maschinenstart gestartet. Standardmäßig auf Y festgelegt. |
| **CTX_XDL_ADD_FIREWALL_RULES=Y | N** – Die Linux VDA-Dienste erfordern, dass eingehende Netzwerkverbindungen über die Systemfirewall zugelassen werden. Sie können die erforderlichen Ports (standardmäßig Port 80 und 1494) automatisch in der Systemfirewall für den Linux VDA öffnen. Standardmäßig auf Y festgelegt. |
| **CTX_XDL_AD_INTEGRATION=winbind | quest | centrify | sssd | pbis** – Der Linux VDA erfordert Kerberos-Konfigurationseinstellungen zur Authentifizierung bei den Delivery Controllern. Die Kerberos-Konfiguration wird aus dem installierten und konfigurierten Active Directory-Integrationstool auf dem System ermittelt. |
| **CTX_XDL_HDX_3D_PRO=Y | N** – Der Linux VDA unterstützt HDX 3D Pro, eine Reihe von GPU-Beschleunigungstechnologien, die zur Optimierung der Virtualisierung von grafikintensiven Anwendungen entwickelt wurden. Wenn HDX 3D Pro ausgewählt ist, wird der VDA für den VDI-Desktop-Modus (Einzelsitzung) konfiguriert – (d. h. CTX_XDL_VDI_MODE=Y). |
| **CTX_XDL_VDI_MODE=Y | N** – Ob die Maschine als dediziertes Desktop-Bereitstellungsmodell (VDI) oder als gehostetes Shared-Desktop-Bereitstellungsmodell konfiguriert werden soll. Für HDX 3D Pro-Umgebungen setzen Sie diese Variable auf Y. Diese Variable ist standardmäßig auf N festgelegt. |
CTX_XDL_LDAP_LIST=’list-ldap-servers’ – Der Linux VDA fragt DNS ab, um LDAP-Server zu ermitteln. Wenn DNS keine LDAP-Diensteinträge bereitstellen kann, können Sie eine durch Leerzeichen getrennte Liste von LDAP-FQDNs mit LDAP-Ports angeben. Zum Beispiel ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268. Wenn Sie die LDAP-Portnummer als 389 angeben, fragt der Linux VDA jeden LDAP-Server in der angegebenen Domäne im Polling-Modus ab. Wenn es x Richtlinien und y LDAP-Server gibt, führt der Linux VDA insgesamt X multipliziert mit Y Abfragen durch. Wenn die Polling-Zeit den Schwellenwert überschreitet, können Sitzungsanmeldungen fehlschlagen. Um schnellere LDAP-Abfragen zu ermöglichen, aktivieren Sie Global Catalog auf einem Domänencontroller und geben Sie die entsprechende LDAP-Portnummer als 3268 an. Diese Variable ist standardmäßig auf <none> festgelegt.
ctxvda). Der Standardpfad ist /usr/bin.CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate – Gibt die GNOME-, GNOME Classic- oder MATE-Desktopumgebung an, die in Sitzungen verwendet werden soll. Wenn Sie die Variable nicht angeben, wird der derzeit auf dem VDA installierte Desktop verwendet. Wenn der aktuell installierte Desktop jedoch MATE ist, müssen Sie den Variablenwert auf mate setzen.
Sie können die Desktopumgebung für einen Ziel-Sitzungsbenutzer auch durch Ausführen der folgenden Schritte ändern:
.xsession-Datei im Verzeichnis $HOME/<username> auf dem VDA.Bearbeiten Sie die .xsession-Datei, um eine Desktopumgebung basierend auf Distributionen anzugeben.
Für MATE-Desktop
MSESSION="$(type -p mate-session)"
if [ -n "$MSESSION" ]; then
exec mate-session
fi
Für GNOME Classic-Desktop
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
export GNOME_SHELL_SESSION_MODE=classic
exec gnome-session --session=gnome-classic
fi
Für GNOME-Desktop
GSESSION="$(type -p gnome-session)"
if [ -n "$GSESSION" ]; then
exec gnome-session
fi
Ab Version 2209 können Sitzungsbenutzer ihre Desktopumgebungen anpassen. Um diese Funktion zu aktivieren, müssen Sie im Voraus umschaltbare Desktopumgebungen auf dem VDA installieren. Weitere Informationen finden Sie unter Benutzerdefinierte Desktopumgebungen für 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=winbind | quest |centrify | sssd | pbis
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 | gnome-classic | 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 --silent
<!--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 dadurch erstellt wird. 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=winbind | quest |centrify | sssd | pbis \
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|gnome-classic|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 --silent
<!--NeedCopy-->
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 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.
So überprüfen Sie, ob der Linux VDA installiert ist, und um die Version des installierten Pakets anzuzeigen:
dpkg -l xendesktopvda
<!--NeedCopy-->
So zeigen Sie detailliertere Informationen an:
apt-cache show xendesktopvda
<!--NeedCopy-->
So deinstallieren Sie die Linux VDA-Software:
dpkg -r xendesktopvda
<!--NeedCopy-->
Hinweis:
Durch die Deinstallation der Linux VDA-Software werden die zugehörigen PostgreSQL- und andere Konfigurationsdaten gelöscht. Das PostgreSQL-Paket und andere abhängige Pakete, die vor der Installation des Linux VDA eingerichtet wurden, werden jedoch nicht gelöscht.
Tipp:
Die Informationen in diesem Abschnitt behandeln nicht die Entfernung abhängiger Pakete, einschließlich PostgreSQL.
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, verwenden Sie die folgenden Befehle, um den Linux VDA zu steuern.
Linux VDA starten:
So starten Sie die Linux VDA-Dienste:
sudo systemctl start ctxhdx
sudo systemctl start ctxvda
<!--NeedCopy-->
Linux VDA anhalten:
So halten Sie die Linux VDA-Dienste an:
sudo systemctl stop ctxvda
sudo systemctl stop ctxhdx
<!--NeedCopy-->
Hinweis:
Bevor Sie die Dienste
ctxvdaundctxhdxanhalten, führen Sie den Befehlservice ctxmonitorservice stopaus, um den Überwachungsdienst-Daemon anzuhalten. Andernfalls startet der Überwachungsdienst-Daemon die von Ihnen angehaltenen Dienste neu.
Linux VDA neu starten:
So starten Sie die Linux VDA-Dienste neu:
sudo systemctl stop ctxvda
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda
<!--NeedCopy-->
Linux VDA-Status überprüfen:
So überprüfen Sie den Ausführungsstatus der Linux VDA-Dienste:
sudo systemctl status ctxvda
sudo systemctl status ctxhdx
<!--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 einzelnen Benutzer pro Maschine.
Tipp:
Wenn Sie eine Maschine aus der Active Directory-Domäne entfernen und wieder hinzufügen, müssen Sie die Maschine erneut aus dem Maschinenkatalog entfernen und hinzufügen.
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:
Informationen zum Erstellen von Maschinenkatalogen und Bereitstellungsgruppen finden Sie unter Citrix Virtual Apps and Desktops 7 2303.