Install Linux Virtual Delivery Agent for SUSE manually

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

Step 1a: Launch the YaST tool

The SUSE Linux Enterprise YaST tool is used for configuring all aspects of the operating system.

To launch the text-based YaST tool:

su -

yast
<!--NeedCopy-->

Alternatively, launch the UI-based YaST tool:

su -

yast2 &
<!--NeedCopy-->

Step 1b: Configure networking

The following sections provide information on configuring the various networking settings and services used by the Linux VDA. Configuring networking is carried out via the YaST tool, not via other methods such as Network Manager. These instructions are based on using the UI-based YaST tool. The text-based YaST tool can be used but has a different method of navigation that is not documented here.

Configure host name and DNS

1. Open YaST Network Settings.
2. SLED 12 Only: On the Global Options tab, change the Network Setup Method to Wicked Service.
3. Open the Hostname/DNS tab.
4. Clear Change hostname via DHCP.
5. Check Assign Hostname to Loopback IP.
6. Edit the following to reflect your networking setup:
   • Host name – Add the DNS host name of the machine.
   • Domain name – Add the DNS domain name of the machine.
   • Name server – Add the IP address of the DNS server. It is typically the IP address of the AD Domain Controller.
   • Domain search list – Add the DNS domain name.

Note:

The Linux VDA currently does not support NetBIOS name truncation. Therefore, 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.

Disable multicast DNS

On SLED only, the default settings have multicast DNS (mDNS) enabled, which can lead to inconsistent name resolution results. mDNS is not enabled on SLES by default, so no action is required.

To disable mDNS, edit /etc/nsswitch.conf and change the line containing:

hosts: files mdns_minimal [NOTFOUND=return] dns

To:

hosts: files dns

Check the host name

Verify that the host name is set correctly:

hostname
<!--NeedCopy-->

This command returns only the machine’s host name and not its fully qualified domain name (FQDN).

Verify that the FQDN is set correctly:

hostname -f
<!--NeedCopy-->

This command returns the machine’s FQDN.

Check name resolution and service reachability

Verify 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-fqdn
<!--NeedCopy-->

If you cannot resolve the FQDN or ping either of these machines, review the steps before proceeding.

Step 1c: Configure the NTP service

It is crucial to maintain accurate clock synchronization between the VDAs, Delivery Controllers, and domain controllers. Hosting the Linux VDA as a virtual machine can cause clock skew problems. For this reason, maintaining time using a remote NTP service is preferred. Some changes might be required to the default NTP settings:

1. Open YaST NTP Configuration and select the General Settings tab.
2. In the Start NTP Daemon section, check Now and on Boot.
3. If present, select the Undisciplined Local Clock (LOCAL) item and click Delete.
4. Add an entry for an NTP server by clicking Add.
5. Select the Server Type and click Next.
6. Type the DNS name of the NTP server in the Address field. This service is normally hosted on the Active Directory domain controller.
7. Leave the Options field unchanged.
8. Click Test to verify that the NTP service is reachable.
9. Click OK through the set of windows to save the changes.

Note:

For SLES 12 implementations, the NTP daemon might fail to start due to a known SUSE issue with AppArmor policies. Follow the resolution for additional information.

Step 1d: Install Linux VDA dependent packages

The Linux VDA software for SUSE Linux Enterprise depends on the following packages:

• PostgreSQL
  • SLED/SLES 12: Version 9.3 or later
• OpenJDK 1.8.0
• Open Motif Runtime Environment 2.3.1 or later
• Cups
  • SLED/SLES 12: Version 1.6.0 or later
• Foomatic filters
  • SLED/SLES 12: Version 1.0.0 or later
• ImageMagick
  • SLED/SLES 12: Version 6.8 or later

Add repositories

Some required packages are not available in all SUSE Linux Enterprise repositories:

• SLED 12: PostgreSQL is available for SLES 12 but not SLED 12. ImageMagick is available via the SLE 12 SDK ISO or online repository.
• SLES 12: There are no issues. All packages are available. ImageMagick is available via the SLE 12 SDK ISO or online repository.

To resolve the issue, obtain missing packages from the media for the alternative edition of SLE from which you are installing. That is, on SLED install missing packages from the SLES media, and on SLES install missing packages from the SLED media. The following approach mounts both SLED and SLES ISO media files and adds repositories.

• On SLED 12, run the commands:

sudo mkdir -p /mnt/sles

sudo mount -t iso9660 path-to-iso/SLES-12-SP3-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles
<!--NeedCopy-->

• On SLED/SLES 12, run the commands:

sudo mkdir -p /mnt/sdk

sudo mount -t iso9660 path-to-iso/SLE-12-SP3-SDK-DVD-x86_64-GM-DVD1.iso /mnt/sdk

sudo zypper ar -f /mnt/sdk sdk
<!--NeedCopy-->

Install the Kerberos client

Install the Kerberos client for mutual authentication between the Linux VDA and the Delivery Controllers:

sudo zypper install krb5-client
<!--NeedCopy-->

The Kerberos client configuration depends on which Active Directory integration approach is used. See the following description.

Install OpenJDK

The Linux VDA depends on OpenJDK 1.8.0.

Tip:

To avoid registration failure with the Delivery Controller, ensure that you installed only OpenJDK 1.8.0. Remove all other versions of Java from your system.

• SLED:

1. On SLED, the Java runtime environment is typically installed with the operating system. Check whether it has been installed:

   sudo zypper info java-1_8_0-openjdk
   <!--NeedCopy-->
   

2. Update to the latest version if the status is reported as out-of-date:

   sudo zypper update java-1_8_0-openjdk
   <!--NeedCopy-->
   

3. Check the Java version:

   java -version
   <!--NeedCopy-->
   

• SLES:

1. On SLES, install the Java runtime environment:

   sudo zypper install java-1_8_0-openjdk
   <!--NeedCopy-->
   

2. Check the Java version:

   java -version
   <!--NeedCopy-->
   

Install PostgreSQL

On SLED/SLES 12, install the packages:

sudo zypper install postgresql-init

sudo zypper install postgresql-server

sudo zypper install postgresql-jdbc
<!--NeedCopy-->

Post-installation steps are required to initialize the database service and to ensure that PostgreSQL is started upon machine startup:

sudo systemctl enable postgresql

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

Database files locate at /var/lib/pgsql/data.

Remove repositories

With dependent packages installed, the alternative edition repositories set up earlier can now be removed and the media unmounted:

• on SLED 12, run the commands to remove the packages:

sudo zypper rr sles

sudo umount /mnt/sles

sudo rmdir /mnt/sles
<!--NeedCopy-->

• on SLED/SLES 12, run the commands to remove the packages:

sudo zypper rr sdk

sudo umount /mnt/sdk

sudo rmdir /mnt/sdk
<!--NeedCopy-->

Step 2: Prepare Linux VM for Hypervisor

Some changes are required when running the Linux VDA as a virtual machine on a supported hypervisor. Make the following changes according to 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 Hypervisor

If the Citrix Hypervisor Time Sync feature is enabled, within each paravirtualized Linux VM you experience issues with NTP and Citrix Hypervisor both trying to manage the system clock. To avoid the clock becoming out of sync with other servers, synchronize the system clock within each Linux guest with NTP. This case requires disabling host time synchronization. No changes are required in HVM mode.

On some Linux distributions, 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_wallclock
<!--NeedCopy-->

This 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_wallclock
<!--NeedCopy-->

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

reboot
<!--NeedCopy-->

After restart, verify that the setting is correct:

su -

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

This command returns the value 1.

Fix time synchronization on Microsoft Hyper-V

Linux VMs with Hyper-V Linux Integration Services installed can apply 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 the NTP services.

From the management operating system:

1. Open the Hyper-V Manager console.
2. For the settings of a Linux VM, select Integration Services.
3. 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 ESXi

If the VMware Time Synchronization feature is enabled, within each paravirtualized Linux VM you experience issues with NTP and the hypervisor both trying to synchronize the system clock. To avoid the clock becoming out of sync with other servers, the system clock within each Linux guest must be synchronized with NTP. This case requires disabling host time synchronization.

If you are running a paravirtualized Linux kernel with VMware Tools installed:

1. Open the vSphere Client.
2. Edit settings for the Linux VM.
3. In the Virtual Machine Properties dialog, open the Options tab.
4. Select VMware Tools.
5. In the Advanced box, clear Synchronize guest time with host.

Step 3: Add the Linux virtual machine (VM) to the Windows domain

The Linux VDA supports several methods for adding Linux machines to the Active Directory (AD) domain:

• Samba Winbind
• Quest Authentication Services
• Centrify DirectControl

Follow 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

Join Windows domain

Your domain controller must be reachable and you must have an Active Directory user account with permissions to add machines to the domain:

1. Open YaST Windows Domain Membership.

2. Make the following changes:

   • Set the Domain or Workgroup to the name of your Active Directory domain or the IP address of the domain controller. Ensure that the domain name is in uppercase.
   • Check Also Use SMB information for Linux Authentication.
   • Check Create Home Directory on Login.
   • Check Single Sign-on for SSH.
   • Ensure that Offline Authentication is not checked. This option is not compatible with the Linux VDA.

3. Click OK. If prompted to install some packages, click Install.

4. If a domain controller is found, it asks whether you want to join the domain. Click Yes.

5. When prompted, type the credentials of a domain user with permission to add computers to the domain and click OK.

6. A message indicating success is displayed.

7. If prompted to install some samba and krb5 packages, click Install.

YaST might have indicated that these changes require some services or the machine to be restarted. We recommend you restart the machine:

su -

reboot
<!--NeedCopy-->

SLED/SLES 12 Only: Patch Kerberos credential cache name

SLED/SLES 12 has changed the default Kerberos credential cache name specification from the usual FILE:/tmp/krb5cc_%{uid} to DIR:/run/user/%{uid}/krb5cc. This new DIR caching method is not compatible with the Linux VDA and must be manually changed. As a root user, edit /etc/krb5.conf and add the following setting under the [libdefaults] section if not set:

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

Verify domain membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) 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 testjoin
<!--NeedCopy-->

Run the following command to verify extra domain and computer object information:

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

Verify Kerberos configuration

To ensure 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 –ke
<!--NeedCopy-->

This 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\$@REALM
<!--NeedCopy-->

The 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 klist
<!--NeedCopy-->

Examine the machine account details using:

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

Verify user authentication

Use the wbinfo tool to verify that domain users can authenticate with the domain:

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

The 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 -u
<!--NeedCopy-->

Verify that a corresponding Kerberos credential cache file was created for the uid returned by the id -u command:

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

Verify that the tickets in the user’s Kerberos credential cache are valid and not expired:

klist
<!--NeedCopy-->

Exit the session.

exit
<!--NeedCopy-->

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

Quest Authentication Services

Configure Quest on domain controller

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

To enable domain users to establish HDX sessions on a Linux VDA machine:

1. In the Active Directory Users and Computers management console, open Active Directory user properties for that user account.
2. Select the Unix Account tab.
3. Check Unix-enabled.
4. 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

Configure VAS daemon

Auto-renewal 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 false
<!--NeedCopy-->

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

To enable domain user logon through HDX and other services such as su, ssh, and RDP, run the following commands to manually configure PAM and NSS:

sudo /opt/quest/bin/vastool configure pam

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

Join Windows domain

Join the Linux machine to the Active Directory domain using the Quest vastool command:

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

The user is any domain user who has 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 membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) 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 domain
<!--NeedCopy-->

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

To 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 -u
<!--NeedCopy-->

Verify that a corresponding Kerberos credential cache file was created for the uid returned by the id -u command:

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

Verify that the tickets in the Kerberos credential cache are valid and not expired:

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

Exit the session.

exit
<!--NeedCopy-->

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

Centrify DirectControl

Join Windows domain

With 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-name
<!--NeedCopy-->

The user is any Active Directory domain user who has permissions to join computers to the Active Directory domain. The domain-name is the name of the domain to join the Linux machine to.

Verify domain membership

The Delivery Controller requires that all VDA machines (Windows and Linux VDAs) have a computer object in Active Directory. To verify that a Centrify-joined Linux machine is on the domain:

su –

adinfo
<!--NeedCopy-->

Verify 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 –diag
<!--NeedCopy-->

Test connectivity to the various Active Directory and Kerberos services.

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

Proceed to Step 6: Install the Linux VDA after the domain joining verification.

Step 4: Install .NET Core Runtime as a prerequisite

Before installing the Linux VDA, install .NET Core Runtime according to the instructions at https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

• For the 1912 LTSR initial release, CU1, and CU2, Install .NET Core Runtime 2.1.
• For CU3 and later releases, install .NET Core Runtime 3.1.

After installing .NET Core Runtime, run the which dotnet command to find your runtime path.

Based on the command output, set the .NET Core 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 and click Components to download the Linux VDA package that matches your Linux distribution.

Step 6: Install the Linux VDA

Step 6a: Uninstall the old version

If you installed an earlier version other than the previous two and an LTSR release, uninstall it before installing the new version.

1. Stop the Linux VDA services:

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

   Note:

   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.

2. Uninstall the package:

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

Important:

Upgrading from the latest two versions is supported.

Note:

Installation components are located in /opt/Citrix/VDA/.

To run a command, the full path is needed; alternatively, you can add /opt/Citrix/VDA/sbin and /opt/Citrix/VDA/bin to the system path.

Step 6b: Install the Linux VDA

Install the Linux VDA software using Zypper:

For SUSE 12:

sudo zypper install XenDesktopVDA-19.12.0.50-1.sle12_x.x86_64.rpm
<!--NeedCopy-->

Install the Linux VDA software using the RPM package manager. Before doing so, resolve the following dependencies:

For SUSE 12:

sudo rpm -i XenDesktopVDA-19.12.0.50-1.sle12_x.x86_64.rpm
<!--NeedCopy-->

Step 6c: Upgrade the Linux VDA (optional)

You can upgrade an existing installation from the previous two versions and from an LTSR release.

For SUSE 12:

sudo rpm -U XenDesktopVDA-19.12.0.50-1.sle12_x.x86_64.rpm
<!--NeedCopy-->

RPM Dependency list for SUSE 12:

postgresql-server >= 9.3

postgresql-jdbc >= 9.2

java-1.8.0-openjdk >= 1.8.0

ImageMagick >= 6.8

dbus-1 >= 1.8.8

dbus-1-x11 >= 1.8.8

libXpm4 >= 3.5.11

libXrandr2 >= 1.4.2

libXtst6 >= 1.2.2

motif >= 2.3

pam >= 1.1.8

bash >= 4.2

findutils >= 4.5

gawk >= 4.1

sed >= 4.2

cups >= 1.6.0

cups-filters-foomatic-rip >= 1.0.0

openldap2 >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

python-requests >= 2.8.1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsLzma) <= 4.4.6-1

libtcmalloc4 >= 2.5

libcap-progs >= 2.22

xorg-x11-server >= 7.6_1.18.3-76.15

ibus >= 1.5
<!--NeedCopy-->

Important:

Restart the Linux VDA machine after upgrading.

Step 7: Install NVIDIA GRID drivers

Enabling 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

To install and configure the NVIDIA GRID guest VM drivers, perform the following general steps:

1. Ensure that the guest VM is shut down.
2. In the hypervisor control panel, allocate a GPU to the VM.
3. Start the VM.
4. Install the guest VM driver on the VM.

Step 8: Configure the Linux VDA

After 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
<!--NeedCopy-->

Prompted configuration

Run a manual configuration with prompted questions:

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

Automated configuration

For an automated installation, provide the options required by the setup script with environment variables. If all required variables are present, the script does not prompt for any information.

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 Virtual Desktop services are started after machine startup. The value is set to Y by default.
• CTX_XDL_ADD_FIREWALL_RULES=Y | N – The Linux Virtual Desktop services require incoming network connections to be allowed through the system firewall. You can automatically open the required ports (ports 80 and 1494 by default) in the system firewall for the Linux Virtual Desktop. Set to Y by default.
• CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4 – 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 Services
  • 3 – Centrify DirectControl
  • 4 – SSSD
• 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 <none> 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 port. For example, ad1.mycompany.com:389. This variable is set to <none> 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). To improve search performance, you can specify a search base (for example, OU=VDI,DC=mycompany,DC=com). This variable is set to <none> by default.
• CTX_XDL_FAS_LIST=‘list-fas-servers’ – The Federated Authentication Service (FAS) servers are configured through AD Group Policy. Because the Linux VDA does not support AD Group Policy, 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 <none> text string and keep the sequence of server addresses without any changes.
• CTX_XDL_DOTNET_ RUNTIME_PATH=path-to-install-dotnet-runtime – The path to install .NET Core Runtime for supporting the new broker agent service (ctxvda). The default path is /usr/bin.
• 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.

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

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

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

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

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

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

Remove configuration changes

In 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 /usr/local/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

To remove configuration changes:

sudo /usr/local/sbin/ctxcleanup.sh
<!--NeedCopy-->

Important:

This script deletes all configuration data from the database and renders the Linux VDA inoperable.

Configuration logs

The ctxsetup.sh and ctxcleanup.sh scripts display errors on the console, with additional information written to a configuration log file:

/tmp/xdl.configure.log

Restart the Linux VDA services to have the changes take effect.

Step 9: Run XDPing

We provide a command-line utility, the Linux XDPing tool, to check for common configuration issues with a Linux VDA environment. You can install the XDPing package on any machine running a supported Linux distribution. XDPing does not require the Linux VDA package to be installed on the machine. For more information about the tool, see Knowledge Center article CTX202015.

Step 10: Run the Linux VDA

After configuring the Linux VDA by using the ctxsetup.sh script, you can run the following commands to control the Linux VDA.

Start the Linux VDA:

To start the Linux VDA services:

sudo /sbin/service ctxhdx start

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

Stop the Linux VDA:

To stop the Linux VDA services:

sudo /sbin/service ctxvda stop

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

Note:

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 /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

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

Check the Linux VDA status:

To check the running status of the Linux VDA services:

sudo /sbin/service ctxvda status

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

Step 11: Create the machine catalog in Citrix Virtual Apps or Citrix Virtual Desktops

The 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 the delivery group in Citrix Virtual Apps or Citrix Virtual Desktops

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

Important:

Publishing applications is supported with Linux VDA Version 1.4 and later. However, the Linux VDA does not support the delivery of desktops and apps to the same machine.

For information about how to create machine catalogs and delivery groups, see Citrix Virtual Apps and Desktops 7 1912 LTSR.