Install the Linux VDA on Debian manually |
您所在的位置:网站首页 › debian vmware › Install the Linux VDA on Debian manually |
Install the Linux VDA on Debian manually
March 21, 2023
Contributed by:
B
L
Important: For fresh installations, we recommend you use easy install for a quick installation. Easy install saves time and labor and is less error-prone than the manual installation detailed in this article. Step 1: Prepare configuration information and the Linux machine Step 1a: Verify the network configurationMake sure that the network is connected and configured correctly. For example, you must configure the DNS server on the Linux VDA. Step 1b: Set the host nameTo make sure that the host name of the machine is reported correctly, change the /etc/hostname file to contain only the host name of the machine. hostname Step 1c: Assign a loopback address to the host nameMake sure that the DNS domain name and Fully Qualified Domain Name (FQDN) of the machine are reported back correctly. The way is to change the following line of the /etc/hosts file to include the FQDN and host name as the first two entries: 127.0.0.1 hostname-fqdn hostname localhost For example: 127.0.0.1 vda01.example.com vda01 localhost Remove any other references to hostname-fqdn or hostname from other entries in the file. Note: The Linux VDA currently does not support NetBIOS name truncation. The host name must not exceed 15 characters. Tip: Use a–z, A–Z, 0–9, and hyphen (-) characters only. Avoid underscores (_), spaces, and other symbols. Do not start a host name with a number and do not end with a hyphen. This rule also applies to Delivery Controller host names. Step 1d: Check the host nameVerify that the host name is set correctly: hostnameThis command returns only the host name of the machine and not its FQDN. Verify that the FQDN is set correctly: hostname -fThis command returns the FQDN of the machine. Step 1e: Disable multicast DNSThe default settings have multicast DNS (mDNS) enabled, which can lead to inconsistent name resolution results. To disable mDNS, edit /etc/nsswitch.conf and change the line: hosts: files mdns_minimal [NOTFOUND=return] dns To: hosts: files dns Step 1f: Check name resolution and service reachabilityVerify that you can resolve the FQDN and ping the domain controller and Delivery Controller: nslookup domain-controller-fqdn ping domain-controller-fqdn nslookup delivery-controller-fqdn ping delivery-controller-fqdnIf you cannot resolve the FQDN or ping either of these machines, review the steps before proceeding. Step 1g: Configure clock synchronization (chrony)Maintaining accurate clock synchronization between the VDAs, Delivery Controllers and domain controllers is crucial. Hosting the Linux VDA as a virtual machine (VM) can cause clock skew problems. For this reason, synchronizing time with a remote time service is preferred. Install chrony: apt-get install chronyAs a root user, edit /etc/chrony/chrony.conf and add a server entry for each remote time server: server peer1-fqdn-or-ip-address iburst server peer2-fqdn-or-ip-address iburst In a typical deployment, synchronize time from the local domain controllers and not directly from public NTP pool servers. Add a server entry for each Active Directory domain controller in the domain. Remove any other server or pool entries listed including loopback IP address, localhost, and public server *.pool.ntp.org entries. Save changes and restart the Chrony daemon: sudo systemctl restart chrony Step 1h: Install packages sudo apt-get install -y libsasl2-2 sudo apt-get install -y libgtk2.0-0 Step 1i: Add repositories to install necessary dependenciesFor Debian 11.3, add the deb http://deb.debian.org/debian/ bullseye main line to the /etc/apt/sources.list file. Step 1j: Install and specify a database to useAs an experimental feature, you can use SQLite in addition to PostgreSQL. You can also switch between SQLite and PostgreSQL by editing /etc/xdl/db.conf after installing the Linux VDA package. For manual installations, you must install SQLite and PostgreSQL manually before being able to switch between them. This section describes how to install the PostgreSQL and SQLite databases and how to specify a database to use. Note: We recommend you use SQLite for VDI mode only. Install PostgreSQLRun the following commands to install PostgreSQL: sudo apt-get install -y postgresql sudo apt-get install -y libpostgresql-jdbc-javaRun the following commands to start PostgreSQL upon machine startup or immediately, respectively: sudo systemctl enable postgresql sudo systemctl start postgresql Install SQLiteFor Debian, run the following command to install SQLite: sudo apt-get install -y sqlite3 Specify a database to useAfter you install SQLite, PostgreSQL, or both, you can specify a database to use by editing /etc/xdl/db.conf after installing the Linux VDA package. To do so, complete the following steps: Run /opt/Citrix/VDA/sbin/ctxcleanup.sh. Omit this step if it is a fresh installation. Edit /etc/xdl/db.conf to specify a database to use. Run ctxsetup.sh.Note: You can also use /etc/xdl/db.conf to configure the port number for PostgreSQL. Step 2: Prepare the hypervisorSome changes are required when running the Linux VDA as a VM on a supported hypervisor. Make the following changes based on the hypervisor platform in use. No changes are required if you are running the Linux machine on bare metal hardware. Fix time synchronization on Citrix HypervisorWhen the Citrix Hypervisor Time Sync feature is enabled, within each paravirtualized Linux VM you experience issues with NTP and Citrix Hypervisor. Both try to manage the system clock. To avoid the clock becoming out of sync with other servers, make sure that the system clock within each Linux guest is synchronized with the NTP. This case requires disabling host time synchronization. No changes are required in HVM mode. If you are running a paravirtualized Linux kernel with Citrix VM Tools installed, you can check whether the Citrix Hypervisor Time Sync feature is present and enabled from within the Linux VM: su - cat /proc/sys/xen/independent_wallclockThis command returns 0 or 1: 0 - The time sync feature is enabled, and must be disabled. 1 - The time sync feature is disabled, and no further action is required.If the /proc/sys/xen/independent_wallclock file is not present, the following steps are not required. If enabled, disable the time sync feature by writing 1 to the file: sudo echo 1 > /proc/sys/xen/independent_wallclockTo make this change permanent and persistent after restart, edit the /etc/sysctl.conf file and add the line: xen.independent_wallclock = 1 To verify these changes, restart the system: su - cat /proc/sys/xen/independent_wallclockThis command returns the value 1. Fix time synchronization on Microsoft Hyper-VLinux VMs with Hyper-V Linux Integration Services installed can use the Hyper-V time synchronization feature to use the host operating system’s time. To ensure that the system clock remains accurate, enable this feature alongside NTP services. From the management operating system: Open the Hyper-V Manager console. For the settings of a Linux VM, select Integration Services. Ensure that Time synchronization is selected.Note: This approach is different from VMware and Citrix Hypervisor, where host time synchronization is disabled to avoid conflicts with NTP. Hyper-V time synchronization can coexist and supplement NTP time synchronization. Fix time synchronization on ESX and ESXiWhen the VMware Time Synchronization feature is enabled, within each paravirtualized Linux VM you experience issues with the NTP and the hypervisor. Both try to synchronize the system clock. To avoid the clock becoming out of sync with other servers, ensure that the system clock within each Linux guest is synchronized with the NTP. This case requires disabling host time synchronization. If you are running a paravirtualized Linux kernel with VMware Tools installed: Open the vSphere Client. Edit settings for the Linux VM. In the Virtual Machine Properties dialog, open the Options tab. Select VMware Tools. In the Advanced box, clear Synchronize guest time with host. Step 3: Add the Linux VM to the Windows domainThe following methods are available for adding Linux machines to the Active Directory (AD) domain: Samba Winbind Centrify DirectControl SSSD PBISFollow instructions based on your chosen method. Note: Session launches might fail when the same user name is used for the local account in the Linux VDA and the account in AD. Samba Winbind Install or update the required packages sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user Enable the Winbind daemon to start on machine startupThe Winbind daemon must be configured to start on machine startup: sudo systemctl enable winbindNote: Ensure that the winbind script is located under /etc/init.d. Configure KerberosOpen /etc/krb5.conf as a root user, and make the following settings: Note: Configure Kerberos based on your AD infrastructure. The following settings are meant for the single-domain, single-forest model. [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 The domain-dns-name parameter in this context is the DNS domain name, such as example.com. The REALM is the Kerberos realm name in uppercase, such as EXAMPLE.COM. Configure Winbind AuthenticationOpen /etc/samba/smb.conf, and make the following settings: [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 is the first field in REALM, and REALM is the Kerberos realm name in uppercase. Configure nsswitchOpen /etc/nsswitch.conf, and append winbind to the following lines: passwd: systemd winbind group: systemd winbind Join Windows DomainYour domain controller must be reachable and you must have an Active Directory user account with permissions to add computers to the domain: sudo net ads join REALM -U userWhere REALM is the Kerberos realm name in uppercase, and user is a domain user with permissions to add computers to the domain. Restart Winbind sudo systemctl restart winbind Configure PAM for WinbindRun the following command and ensure that the Winbind NT/Active Directory authentication and Create home directory on login options are selected: sudo pam-auth-updateTip: The winbind daemon stays running only if the machine is joined to a domain. Verify Domain MembershipThe Delivery Controller requires that all VDA machines, whether Windows or Linux, have a computer object in Active Directory. Run the net ads command of Samba to verify that the machine is joined to a domain: sudo net ads testjoinRun the following command to verify extra domain and computer object information: sudo net ads info Verify Kerberos ConfigurationTo verify that Kerberos is configured correctly for use with the Linux VDA, verify that the system keytab file has been created and contains valid keys: sudo klist -keThis command displays the list of keys available for the various combinations of principal names and cipher suites. Run the Kerberos kinit command to authenticate the machine with the domain controller using these keys: sudo kinit -k MACHINE\$@REALMThe machine and realm names must be specified in uppercase. The dollar sign ($) must be escaped with a backslash (\) to prevent shell substitution. In some environments, the DNS domain name is different from the Kerberos realm name. Ensure that the realm name is used. If this command is successful, no output is displayed. Verify that the TGT ticket for the machine account has been cached using: sudo klistExamine the account details of the machine using: sudo net ads status Verify user authenticationUse the wbinfo tool to verify that domain users can authenticate with the domain: wbinfo --krb5auth=domain\\username%passwordThe domain specified here is the AD domain name, not the Kerberos realm name. For the bash shell, the backslash (\) character must be escaped with another backslash. This command returns a message indicating success or failure. To verify that the Winbind PAM module is configured correctly, log on to the Linux VDA using a domain user account that has not been used before. ssh localhost -l domain\\username id -uNote: To run an SSH command successfully, ensure that SSH is enabled and working properly. Verify that a corresponding Kerberos credential cache file was created for the uid returned by the id -u command: ls /tmp/krb5cc_uidVerify that the tickets in the user’s Kerberos credential cache are valid and not expired: klistExit the session. exitA similar test can be performed by logging on to the Gnome or KDE console directly. Proceed to Step 6: Install the Linux VDA after the domain joining verification. Tip: If you succeed in user authentication but cannot show your desktop when logging on with a domain account, restart the machine and try again. Quest authentication service Configure Quest on domain controllerAssume that you have installed and configured the Quest software on the Active Directory domain controllers, and have been granted administrative privileges to create computer objects in Active Directory. Enable domain users to log on to Linux VDA machinesTo enable domain users to establish HDX sessions on a Linux VDA machine: In the Active Directory Users and Computers management console, open Active Directory user properties for that user account. Select the Unix Account tab. Check Unix-enabled. Set the Primary GID Number to the group ID of an actual domain user group.Note: These instructions are equivalent for setting up domain users for logon using the console, RDP, SSH, or any other remoting protocol. Configure Quest on Linux VDA Work around SELinux policy enforcementThe default RHEL environment has SELinux fully enforced. This enforcement interferes with the Unix domain socket IPC mechanisms used by Quest, and prevents domain users from logging on. The convenient way to work around this issue is to disable SELinux. As a root user, edit /etc/selinux/config and change the SELinux setting: SELINUX=disabled This change requires a machine restart: rebootImportant: Use this setting carefully. Reenabling SELinux policy enforcement after disabling can cause a complete lockout, even for the root user and other local users. Configure VAS daemonAutorenewal of Kerberos tickets must be enabled and disconnected. Authentication (offline logon) must be disabled: 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 falseThis command sets the renewal interval to nine hours (32,400 seconds) which is one hour less than the default 10-hour ticket lifetime. Set this parameter to a lower value on systems with a shorter ticket lifetime. Configure PAM and NSSTo enable domain user logon through HDX and other services such as su, ssh, and RDP, run the following commands to configure PAM and NSS manually: sudo /opt/quest/bin/vastool configure pam sudo /opt/quest/bin/vastool configure nss Join Windows domainJoin the Linux machine to the Active Directory domain using the Quest vastool command: sudo /opt/quest/bin/vastool -u user join domain-nameThe user is any domain user with permissions to join computers to the Active Directory domain. The domain-name is the DNS name of the domain, for example, example.com. Verify domain membershipThe Delivery Controller requires that all VDA machines, whether Windows or Linux, have a computer object in Active Directory. To verify that a Quest-joined Linux machine is on the domain: sudo /opt/quest/bin/vastool info domainIf the machine is joined to a domain, this command returns the domain name. If the machine is not joined to any domain, the following error appears: 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 Verify user authenticationTo verify that Quest can authenticate domain users through PAM, log on to the Linux VDA using a domain user account that has not been used before. ssh localhost -l domain\\username id -uVerify that a corresponding Kerberos credential cache file was created for the UID returned by the id -u command: ls /tmp/krb5cc_uidVerify that the tickets in the Kerberos credential cache are valid and not expired: /opt/quest/bin/vastool klistExit the session. exitProceed to Step 6: Install the Linux VDA after the domain-joining verification. Centrify DirectControl Join Windows domainWith the Centrify DirectControl Agent installed, join the Linux machine to the Active Directory domain using the Centrify adjoin command: su – adjoin -w -V -u user domain-nameThe user parameter is any Active Directory domain user with permissions to join computers to the Active Directory domain. The domain-name parameter is the name of the domain to join the Linux machine to. Verify domain membershipThe Delivery Controller requires that all VDA machines, whether Windows or Linux, have a computer object in Active Directory. To verify that a Centrify-joined Linux machine is on the domain: su – adinfoVerify that the Joined to domain value is valid and the CentrifyDC mode returns connected. If the mode remains stuck in the starting state, then the Centrify client is experiencing server connection or authentication problems. More comprehensive system and diagnostic information is available using: adinfo --sysinfo all adinfo --diagTest connectivity to the various Active Directory and Kerberos services. adinfo --testProceed to Step 6: Install the Linux VDA after the domain-joining verification. SSSD Configure KerberosRun the following command to install Kerberos: sudo apt-get install krb5-userTo configure Kerberos, open /etc/krb5.conf as root and set the parameters: Note: Configure Kerberos based on your AD infrastructure. The following settings are meant for the single-domain, single-forest model. [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 The domain-dns-name parameter in this context is the DNS domain name, such as example.com. The REALM is the Kerberos realm name in uppercase, such as EXAMPLE.COM. Join the domainSSSD must be configured to use Active Directory as its identity provider and Kerberos for authentication. However, SSSD does not provide AD client functions for joining the domain and managing the system keytab file. You can use adcli, realmd, or Samba instead. Note: This section only provides information for adcli and Samba. If you use adcli to join the domain, complete the following steps:Install adcli. sudo apt-get install adcliJoin the domain with adcli. Remove the old system keytab file and join the domain using: su - rm -rf /etc/krb5.keytab adcli join domain-dns-name -U user -H hostname-fqdnThe user is a domain user with permissions to add machines to the domain. The hostname-fqdn is the host name in FQDN format for the machine. The -H option is necessary for adcli to generate SPN in the format of host/hostname-fqdn@REALM, which the Linux VDA requires. Verify system keytab. Run the sudo klist -ket command to ensure that the system keytab file has been created. Verify that the timestamp for each key matches the time the machine was joined to the domain. If you use Samba to join the domain, complete the following steps:Install the package. sudo apt-get install samba krb5-userConfigure Samba. Open /etc/samba/smb.conf, and make the following settings: [global] workgroup = WORKGROUP security = ADS realm = REALM client signing = yes client use spnego = yes kerberos method = secrets and keytab WORKGROUP is the first field in REALM, and REALM is the Kerberos realm name in uppercase. Join the domain with Samba. Your domain controller must be reachable and you must have a Windows account with permissions to add computers to the domain. sudo net ads join REALM -U userWhere REALM is the Kerberos realm name in uppercase, and user is a domain user with permissions to add computers to the domain. Set up SSSDInstall or update required packages: Install the required SSSD and configuration packages if not already installed: sudo apt-get install sssdIf the packages are already installed, an update is recommended: sudo apt-get install --only-upgrade sssdNote: By default, the install process in Ubuntu automatically configures nsswitch.conf and the PAM login module. Configure SSSDSSSD configuration changes are required before starting the SSSD daemon. For some versions of SSSD, the /etc/sssd/sssd.conf configuration file is not installed by default and must be created manually. As root, either create or open /etc/sssd/sssd.conf and make the following settings: [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 # Set krb5_renewable_lifetime higher if TGT renew lifetime is longer than 14 days krb5_renewable_lifetime = 14d # Set krb5_renew_interval to lower value if TGT ticket lifetime is shorter than 2 hours krb5_renew_interval = 1h krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U # This ldap_id_mapping setting is also the default value ldap_id_mapping = true override_homedir = /home/%d/%u default_shell = /bin/bash ad_gpo_map_remote_interactive = +ctxhdx Note: ldap_id_mapping is set to true so that SSSD itself takes care of mapping Windows SIDs to Unix UIDs. Otherwise, Active Directory must be able to provide POSIX extensions. PAM service ctxhdx is added to ad_gpo_map_remote_interactive. The domain-dns-name parameter in this context is the DNS domain name, such as example.com. The REALM is the Kerberos realm name in uppercase, such as EXAMPLE.COM. There is no requirement to configure the NetBIOS domain name. For information about the configuration settings, see the man pages for sssd.conf and sssd-ad. The SSSD daemon requires that the configuration file must have owner read permission only: sudo chmod 0600 /etc/sssd/sssd.conf Start SSSD daemonRun the following commands to start the SSSD daemon now and to enable the daemon to start upon machine startup: sudo systemctl start sssd sudo systemctl enable sssd PAM configurationRun the following command and ensure that the SSS authentication and Create home directory on login options are selected: sudo pam-auth-update Verify domain membershipThe Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory. If you use adcli to verify domain membership, run the sudo adcli info domain-dns-name command to show the domain information. If you use Samba to verify domain membership, run the sudo net ads testjoin command to verify that the machine is joined to a domain and the sudo net ads info command to verify extra domain and computer object information. Verify Kerberos configurationTo verify that Kerberos is configured correctly for use with the Linux VDA, verify that the system keytab file has been created and contains valid keys: sudo klist -keThis command displays the list of keys available for the various combinations of principal names and cipher suites. Run the Kerberos kinit command to authenticate the machine with the domain controller using these keys: sudo kinit -k MACHINE\$@REALMThe machine and realm names must be specified in uppercase. The dollar sign ($) must be escaped with a backslash (\) to prevent shell substitution. In some environments, the DNS domain name is different from the Kerberos realm name. Ensure that the realm name is used. If this command is successful, no output is displayed. Verify that the TGT for the machine account has been cached using: sudo klist Verify user authenticationSSSD does not provide a command-line tool for testing authentication directly with the daemon, and can only be done via PAM. To verify that the SSSD PAM module is configured correctly, log on to the Linux VDA using a domain user account that has not been used before. ssh localhost -l domain\\username id -u klist exitVerify that the Kerberos tickets returned by the klist command are correct for that user and have not expired. As a root user, verify that a corresponding ticket cache file was created for the uid returned by the previous id -u command: ls /tmp/krb5cc_uidA similar test can be performed by logging on to KDE or Gnome Display Manager. Proceed to Step 6: Install the Linux VDA after the domain-joining verification. PBIS Download the required PBIS package sudo wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.deb.sh Make the PBIS installation script executable sudo chmod +x pbis-open-9.1.0.551.linux.x86_64.deb.sh Run the PBIS installation script sudo sh pbis-open-9.1.0.551.linux.x86_64.deb.sh Join Windows domainYour domain controller must be reachable and you must have an Active Directory user account with permissions to add computers to the domain: sudo /opt/pbis/bin/domainjoin-cli join domain-name userThe user is a domain user who has permissions to add computers to the Active Directory domain. The domain-name is the DNS name of the domain, for example, example.com. Note: To set Bash as the default shell, run the sudo /opt/pbis/bin/config LoginShellTemplate/bin/bash command. Verify domain membershipThe Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory. To verify that a PBIS-joined Linux machine is on the domain: /opt/pbis/bin/domainjoin-cli queryIf the machine is joined to a domain, this command returns the information about the currently joined AD domain and OU. Otherwise, only the host name appears. Verify user authenticationTo verify that PBIS can authenticate domain users through PAM, log on to the Linux VDA using a domain user account that has not been used before. sudo ssh localhost -l domain\\user id -uVerify that a corresponding Kerberos credential cache file was created for the UID returned by the id -u command: ls /tmp/krb5cc_uidExit the session. exitProceed to Step 6: Install the Linux VDA after the domain-joining verification. Step 4: Install .NET Runtime 6.0Before installing the Linux VDA, install .NET Runtime 6.0 according to the instructions at https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers. After installing .NET Runtime 6.0, run the which dotnet command to find your runtime path. Based on the command output, set the .NET runtime binary path. For example, if the command output is /aa/bb/dotnet, use /aa/bb as the .NET binary path. Step 5: Download the Linux VDA package Go to the Citrix Virtual Apps and Desktops download page. Expand the appropriate version of Citrix Virtual Apps and Desktops.Click Components to download the Linux VDA package that matches your Linux distribution and the GPG public key that you can use to verify the integrity of the Linux VDA package. To verify the integrity of the Linux VDA package, import the public key into the DEB database and run the following commands: ``` sudo apt-get install dpkg-sig gpg --import dpkg-sig --verify ``` Step 6: Install the Linux VDA Step 6a: Install the Linux VDAInstall the Linux VDA software using the Debian package manager: sudo dpkg -i xendesktopvda_.debian10_amd64.debDependency list for Debian 11.3: openjdk-11-jdk >= 11 imagemagick >= 8:6.9.10 ufw >= 0.36 desktop-base >= 10.0.2 libxrandr2 >= 2:1.5.1 libxtst6 >= 2:1.2.3 libxm4 >= 2.3.8 util-linux >= 2.33 gtk3-nocsd >= 3 bash >= 5.0 findutils >= 4.6.0 sed >= 4.7 cups >= 2.2 ghostscript >= 9.53~ libmspack0 >= 0.10 ibus >= 1.5 libgoogle-perftools4 >= 2.7~ libpython3.9 >= 3.9~ libsasl2-modules-gssapi-mit >= 2.1.~ libqt5widgets5 >= 5.5~ mutter >= 3.38.6~ libqrencode4 >= 4.0.0 libimlib2 >= 1.5.1Note: For a matrix of the Linux distributions and the Xorg versions that this version of the Linux VDA supports, see System requirements. Step 6b: Upgrade the Linux VDA (optional)You can upgrade an existing installation from the previous two versions and from an LTSR release. sudo dpkg -i /Note: Upgrading an existing installation overwrites the configuration files under /etc/xdl. Before you conduct an upgrade, make sure to back up the files. Step 7: Install NVIDIA GRID driversEnabling HDX 3D Pro requires you to install the NVIDIA GRID drivers on your hypervisor and on the VDA machines. To install and configure the NVIDIA GRID Virtual GPU Manager (the host driver) on the specific hypervisors, see the following guides: Citrix Hypervisor VMware ESX Nutanix AHVTo install and configure the NVIDIA GRID guest VM drivers, perform the following general steps: Ensure that the guest VM is shut down. In the hypervisor control panel, allocate a GPU to the VM. Start the VM. Install the guest VM driver on the VM. Step 8: Configure the Linux VDAAfter installing the package, you must configure the Linux VDA by running the ctxsetup.sh script. Before making any changes, the script verifies the environment and ensures that all dependencies are installed. If necessary, you can rerun the script at any time to change settings. You can run the script manually with prompting, or automatically with preconfigured responses. Review Help about the script before proceeding: sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help Prompted configurationRun a manual configuration with prompted questions: sudo /opt/Citrix/VDA/sbin/ctxsetup.sh Automated configurationFor an automated install, the options required by the setup script can be provided with environment variables. If all required variables are present, the script does not prompt the user for any information, allowing for a scripted installation process. Supported environment variables include: CTX_XDL_SUPPORT_DDC_AS_CNAME=Y | N – The Linux VDA supports specifying a Delivery Controller name using a DNS CNAME record. Set to N by default. CTX_XDL_DDC_LIST=’list-ddc-fqdns’ – The Linux VDA requires a space-separated list of Delivery Controller Fully Qualified Domain Names (FQDNs) to use for registering with a Delivery Controller. At least one FQDN or CNAME alias must be specified. CTX_XDL_VDA_PORT=port-number – The Linux VDA communicates with Delivery Controllers through a TCP/IP port, which is port 80 by default. CTX_XDL_REGISTER_SERVICE=Y | N – The Linux VDA services are started after machine startup. Set to Y by default. CTX_XDL_ADD_FIREWALL_RULES=Y | N – The Linux VDA services require incoming network connections to be allowed through the system firewall. You can open the required ports (ports 80 and 1494 by default) automatically in the system firewall for the Linux VDA. Set to Y by default. CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 |5 – The Linux VDA requires Kerberos configuration settings to authenticate with the Delivery Controllers. The Kerberos configuration is determined from the installed and configured Active Directory integration tool on the system. Specify the supported Active Directory integration method to use: 1 – Samba Winbind 2 – Quest Authentication Service 3 – Centrify DirectControl 4 – SSSD 5 – PBIS CTX_XDL_HDX_3D_PRO=Y | N – The Linux VDA supports HDX 3D Pro, a set of GPU acceleration technologies designed to optimize the virtualization of rich graphics applications. If HDX 3D Pro is selected, the VDA is configured for VDI desktops (single-session) mode - (that is, CTX_XDL_VDI_MODE=Y). CTX_XDL_VDI_MODE=Y | N – Whether to configure the machine as a dedicated desktop delivery model (VDI) or hosted shared desktop delivery model. For HDX 3D Pro environments, set this variable to Y. This variable is set to N by default. CTX_XDL_SITE_NAME=dns-name – The Linux VDA discovers LDAP servers through DNS. To limit the DNS search results to a local site, specify a DNS site name. This variable is set to by default. CTX_XDL_LDAP_LIST=’list-ldap-servers’ – The Linux VDA queries DNS to discover LDAP servers. If DNS cannot provide LDAP service records, you can provide a space-separated list of LDAP FQDNs with LDAP ports. For example, ad1.mycompany.com:389 ad2.mycompany.com:3268 ad3.mycompany.com:3268. If you specify the LDAP port number as 389, the Linux VDA queries each LDAP server in the specified domain in polling mode. If there are x number of policies and y number of LDAP servers, the Linux VDA performs the total of X multiplied by Y queries. If the polling time exceeds the threshold, session logons might fail. To enable the faster LDAP queries, enable Global Catalog on a domain controller and specify the relevant LDAP port number as 3268. This variable is set to by default. CTX_XDL_SEARCH_BASE=search-base-set – The Linux VDA queries LDAP through a search base set to the root of the Active Directory Domain (for example, DC=mycompany,DC=com). However, to improve search performance, you can specify a search base (for example, OU=VDI,DC=mycompany,DC=com). This variable is set to by default. CTX_XDL_FAS_LIST=’list-fas-servers’ – The Federated Authentication Service (FAS) servers are configured through AD Group Policy. The Linux VDA does not support AD Group Policy, but you can provide a semicolon-separated list of FAS servers instead. The sequence must be the same as configured in AD Group Policy. If any server address is removed, fill its blank with the text string and do not modify the order of server addresses. To communicate with FAS servers properly, make sure you append a port number consistent with that specified on the FAS servers, for example, CTX_XDL_FAS_LIST=’fas_server_1_url:port_number; fas_server_2_url: port_number; fas_server_3_url: port_number’. CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – The path to install .NET Runtime 6.0 for supporting the new broker agent service (ctxvda). The default path is /usr/bin.CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate – Specifies the GNOME, GNOME Classic, or MATE desktop environment to use in sessions. If you leave the variable unspecified, the desktop currently installed on the VDA is used. However, if the currently installed desktop is MATE, you must set the variable value to mate. You can also change the desktop environment for a target session user by completing the following steps: Create an .xsession file under the $HOME/ directory on the VDA.Edit the .xsession file to specify a desktop environment based on distributions. For MATE desktop MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fiFor GNOME Classic desktop GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fiFor GNOME desktop GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi Share the 700 file permission with the target session user.Starting with Version 2209, session users can customize their desktop environments. To enable this feature, you must install switchable desktop environments on the VDA in advance. For more information, see Custom desktop environments by session users. CTX_XDL_START_SERVICE=Y | N – Whether or not the Linux VDA services are started when the Linux VDA configuration is complete. Set to Y by default. CTX_XDL_TELEMETRY_SOCKET_PORT – The socket port for listening for Citrix Scout. The default port is 7503. CTX_XDL_TELEMETRY_PORT – The port for communicating with Citrix Scout. The default port is 7502.Set the environment variable and run the configure script: 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 | '' export CTX_XDL_LDAP_LIST='list-ldap-servers' | '' export CTX_XDL_SEARCH_BASE=search-base-set | '' export CTX_XDL_FAS_LIST='list-fas-servers' | '' export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime export CTX_XDL_DESKTOP_ENVIRONMENT= gnome | gnome-classic | mate | '' 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.shWhen running the sudo command, type the -E option to pass the existing environment variables to the new shell it creates. We recommend that you create a shell script file from the preceding commands with #!/bin/bash as the first line. Alternatively, you can specify all parameters by using a single command: 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|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 Remove configuration changesIn some scenarios, you might have to remove the configuration changes made by the ctxsetup.sh script without uninstalling the Linux VDA package. Review Help about this script before proceeding: sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --helpTo remove configuration changes: sudo /opt/Citrix/VDA/sbin/ctxcleanup.shImportant: This script deletes all configuration data from the database and renders the Linux VDA inoperable. Configuration logsThe ctxsetup.sh and ctxcleanup.sh scripts display errors on the console, with additional information written to the configuration log file /tmp/xdl.configure.log. Restart the Linux VDA services to have the changes take effect. Uninstall the Linux VDA softwareTo check whether the Linux VDA is installed and to view the version of the installed package: dpkg -l xendesktopvdaTo view more detailed information: apt-cache show xendesktopvdaTo uninstall the Linux VDA software: dpkg -r xendesktopvdaNote: Uninstalling the Linux VDA software deletes the associated PostgreSQL and other configuration data. However, the PostgreSQL package and other dependent packages that were set up before the installation of the Linux VDA are not deleted. Tip: The information in this section does not cover the removal of dependent packages including PostgreSQL. Step 9: Run XDPingRun sudo /opt/Citrix/VDA/bin/xdping to check for common configuration issues with a Linux VDA environment. For more information, see XDPing. Step 10: Run the Linux VDAOnce you have configured the Linux VDA using the ctxsetup.sh script, you use the following commands to control the Linux VDA. Start the Linux VDA: To start the Linux VDA services: sudo systemctl start ctxhdx sudo systemctl start ctxvdaStop the Linux VDA: To stop the Linux VDA services: sudo systemctl stop ctxvda sudo systemctl stop ctxhdxNote: Before you stop the ctxvda and ctxhdx services, run the service ctxmonitorservice stop command to stop the monitor service daemon. Otherwise, the monitor service daemon restarts the services you stopped. Restart the Linux VDA: To restart the Linux VDA services: sudo systemctl stop ctxvda sudo systemctl restart ctxhdx sudo systemctl restart ctxvdaCheck the Linux VDA status: To check the running status of the Linux VDA services: sudo systemctl status ctxvda sudo systemctl status ctxhdx Step 11: Create machine catalogsThe process for creating machine catalogs and adding Linux VDA machines is similar to the traditional Windows VDA approach. For a more detailed description of how to complete these tasks, see Create machine catalogs and Manage machine catalogs. For creating machine catalogs that contain Linux VDA machines, there are a few restrictions that differentiate the process from creating machine catalogs for Windows VDA machines: For the operating system, select: The Multi-session OS option for a hosted shared desktops delivery model. The Single-session OS option for a VDI dedicated desktop delivery model. Do not mix Linux and Windows VDA machines in the same machine catalog.Note: Early versions of Citrix Studio did not support the notion of a “Linux OS.” However, selecting the Windows Server OS or Server OS option implies an equivalent hosted shared desktops delivery model. Selecting the Windows Desktop OS or Desktop OS option implies a single user per machine delivery model. Tip: If you remove and rejoin a machine to the Active Directory domain, you must remove and add the machine to the machine catalog again. Step 12: Create delivery groupsThe process for creating a delivery group and adding machine catalogs containing Linux VDA machines is almost identical to Windows VDA machines. For a more detailed description of how to complete these tasks, see Create delivery groups. For creating delivery groups that contain Linux VDA machine catalogs, the following restrictions apply: Ensure that the AD users and groups that you select have been properly configured to log on to the Linux VDA machines. Do not allow logon of unauthenticated (anonymous) users. Do not mix the delivery group with machine catalogs that contain Windows machines.For information about how to create machine catalogs and delivery groups, see Citrix Virtual Apps and Desktops 7 2212. |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |