Product Documentation

Install Linux Virtual Delivery Agent for RHEL

Feb 06, 2017

Step 1: Prepare RHEL 6/CentOS 6 for VDA installation

Verify the network configuration

Citrix recommends that the network is connected and configured correctly before proceeding.

Set the hostname

To ensure that the hostname of the machine is reported correctly, change the /etc/hostname file to contain only the hostname of the machine.

HOSTNAME=hostname

Assign a loopback address to the hostname

To ensure that the DNS domain name and FQDN of the machine are reported back correctly, change the following line of the /etc/hosts file to include the FQDN and hostname as the first two entries:

127.0.0.1  hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4

For example:

127.0.0.1  vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4

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, therefore the hostname must not exceed 15 characters.

Tip

Use a-z, A-Z, 0-9, and hyphen (-) characters only. Avoid underscrore characters (_), spaces, and other symbols. Do not start a hostname with a number and do not end it with a hyphen.

Check the hostname

Verify that the hostname is set correctly:

command Copy

hostname

This should return only the machine's host name and not its fully qualified domain name (FQDN).

Verify that the FQDN is set correctly:

command Copy

hostname -f

This should return the machine's FQDN.

Check name resolution and service reachability

Verify that you can resolve the FQDN and ping the domain controller and XenDesktop Delivery Controller:

command Copy

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn

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

Configure clock synchronization (NTP)

Maintaining accurate clock synchronization between the VDAs, XenDesktop Controllers, and domain controllers is crucial. Hosting the Linux VDA as a virtual machine can cause clock skew problems. For this reason, synchronizing time with a remote time service is preferred.

RHEL 6.x and earlier releases use the NTP daemon (ntpd) for clock synchronization, whereas an RHEL 7.x default environment uses the newer Chrony daemon (chronyd) instead. The configuration and operational process between the two services is similar.

Configure NTP service

As root, edit /etc/ntp.conf and add a server entry for each remote time server:

config Copy

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst

In a typical deployment, time should be synchronized 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 entries listed including loopback IP address, localhost, and public server *.pool.ntp.org entries.

Save changes and restart the NTP daemon:

command Copy

sudo /sbin/service ntpd restart

Install OpenJDK

The Linux VDA is dependent on OpenJDK. The runtime environment should have been installed as part of the operating system installation.

Confirm the correct version with:

command Copy

sudo yum info java-1.7.0-openjdk

The prepackaged OpenJDK might be an earlier version. Update to the latest version as required:

command Copy

sudo yum -y update java-1.7.0-openjdk

Set the JAVA_HOME environment variable by adding the following line to the ~/.bashrc file:

export JAVA_HOME=/usr/lib/jvm/java

Open a new shell and verify the version of Java:

command Copy

java –version

Tip

To avoid problems, make sure that you installed only OpenJDK version 1.7.0 or 1.8.0. Remove all other versions of Java on your system.

Install PostgreSQL

The Linux VDA requires either PostgreSQL 8.4 or later on RHEL 6.

Install the following packages:

command Copy

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc

The following post-installation step is required to initialize the database and ensure service starts on boot. This will create database files under /var/lib/pgsql/data

command Copy

sudo /sbin/service postgresql initdb

Start PostgreSQL

Configure the service to start on boot, and to start now:

command Copy

sudo /sbin/chkconfig postgresql on

sudo /sbin/service postgresql start

Check the version of PostgreSQL using:

command Copy

psql --version

Verify that the data directory is set using the psql command-line utility:

command Copy

sudo -u postgres psql -c 'show data_directory'

Prepare RHEL 7/CentOS 7 for VDA installation

Verify the network configuration

Citrix recommends that the network is connected and properly configured correctly before proceeding.

Set the hostname

To ensure that the hostname of the machine is reported correctly, change the /etc/hostname file to contain only the hostname of the machine.

Assign a loopback address to the hostname

To ensure that the DNS domain name and FQDN of the machine are reported back correctly, change the following line of the /etc/hosts file to include the FQDN and hostname as the first two entries:

127.0.0.1  hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4

For example:

127.0.0.1  vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4

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, therefore the hostname 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 hostname with a number and do not end it with a hyphen.

Check the hostname

Verify that the hostname is set correctly:

command Copy

hostname

This should return only the machine's host name and not its fully qualified domain name (FQDN).

Verify that the FQDN is set correctly:

command Copy

hostname -f

This should return the machine's FQDN.

Check name resolution and service reachability

Verify that you can resolve the FQDN and ping the domain controller and XenDesktop Delivery Controller:

command Copy

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn

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

Configure clock synchronization (NTP)

Maintaining accurate clock synchronization between the VDAs, XenDesktop Controllers and domain controllers is crucial. Hosting the Linux VDA as a virtual machine can cause clock skew problems. For this reason, synchronizing time with a remote time service is preferred.

RHEL 6.x and earlier releases use the NTP daemon (ntpd) for clock synchronization, whereas an RHEL 7.x default environment uses the newer Chrony daemon (chronyd) instead. The configuration and operational process between the two services is similar.

Chrony service

As root, edit /etc/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, time should be synchronized 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 entries listed including loopback IP address, localhost, and public server *.pool.ntp.org entries.

Save changes and restart the Chrony daemon:

command Copy

sudo /sbin/service chronyd restart

Install OpenJDK

The Linux VDA is dependent on OpenJDK. The runtime environment should have been installed as part of the operating system installation.

Confirm the correct version with:

command Copy

sudo yum info java-1.8.0-openjdk

The prepackaged OpenJDK might be an earlier version. Update to the latest version as required:

command Copy

sudo yum -y update java-1.8.0-openjdk

Set the JAVA_HOME environment variable by adding the following line to ~/.bashrc file:

export JAVA_HOME=/usr/lib/jvm/java

Open a new shell and verify the version of Java:

command Copy

java –version

Tip

To avoid problems, make sure that you installed only OpenJDK version 1.8.0. Remove all other versions of Java on your system.

Install PostgreSQL

The Linux VDA requires PostgreSQL version 9.2 or later on RHEL 7.

Install the following packages:

command Copy

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc

The following post-installation step is required to initialize the database and ensure service starts on boot. This will create database files under /var/lib/pgsql/data

command Copy

sudo postgresql-setup initdb

Start PostgreSQL

For either version PostgreSQL, configure the service to start on boot. To start now:

command Copy

sudo systemctl start postgresql

sudo systemctl enable postgresql

Check the version of PostgreSQL by using:

command Copy

psql --version

Verify that the data directory is set using the psql command-line utility:

command Copy

sudo -u postgres psql -c 'show data_directory'

Step 2: Prepare the 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 XenServer

If the XenServer Time Sync feature is enabled, within each paravirtualized Linux VM you will experience issues with NTP and XenServer both trying to manage 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 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 XenServer Tools installed, you can check whether the XenServer Time Sync feature is present and enabled from within the Linux VM:

command Copy

su -

cat /proc/sys/xen/independent_wallclock

This will return either:

  • 0 - The time sync feature is enabled, and needs to be disabled.
  • 1 - The time sync feature is disabled, and no further action is required.

If the /proc/sys/xen/indepent_wallclock file is not present, the following steps are not required.

If enabled, disable the time sync feature by writing 1 to the file:

command Copy

sudo echo 1 > /proc/sys/xen/independent_wallclock

To make this change permanent and persist after reboot, edit the /etc/sysctl.conf file and add the line:

config Copy

xen.independent_wallclock = 1

To verify these changes, reboot the system:

command Copy

su -

cat /proc/sys/xen/independent_wallclock

This should return the value 1.

Fix time synchronization on Microsoft Hyper-V

Linux VMs with Hyper-V Linux Integration Services installed can leverage the Hyper-V time synchronization feature to use the host operating system's time. To ensure the system clock remains accurate, this feature should be enabled alongside 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 Time synchronization is selected. 

Note

This approach is different from VMware and XenServer, 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 will 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 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

There are a number of methods for adding Linux machines to the Active Directory domain that are supported by XenDesktop for Linux:

  • Samba Winbind
  • Quest Authentication Service
  • Centrify DirectControl

Follow the instructions below for your chosen method.

Samba Winbind

Install or update the required packages:

command Copy

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir

Enable Winbind Daemon to Start on Boot

The Winbind daemon must be configured to start on boot:

command Copy

sudo /sbin/chkconfig winbind on

Configure Winbind Authentication

Configure the machine for Kerberos authentication using Winbind:

command Copy

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

Where REALM is the Kerberos realm name in uppercase and domain is the short NetBIOS name of the Active Directory domain.

If DNS-based lookups of the KDC server and realm name is required, add the following two options to the above command:

command Copy

--enablekrb5kdcdns --enablekrb5realmdns

Ignore any errors returned from the authconfig command about the winbind service failing to start. These are due to authconfig trying to start the winbind service without the machine yet being joined to the domain.

Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:

config Copy

kerberos method = secrets and keytab

winbind refresh tickets = true

The system keytab file /etc/krb5.keytab is required by the Linux VDA to authenticate and register with the Delivery Controller. The kerberos method setting above will force Winbind to create the system keytab file when the machine is first joined to the domain. 

Join Windows Domain

This requires that your domain controller is reachable and you have a Active Directory user account with permissions to add computers to the domain:

command Copy

sudo net ads join REALM -U user

Where REALM is the Kerberos realm name in uppercase, and user is a domain user with permissions to add computers to the domain.

Configure PAM for Winbind

By default, the configuration for the Winbind PAM module (pam_winbind) does not enable Kerberos ticket caching and home directory creation. Open /etc/security/pam_winbind.conf and add or change the following entries under the [Global] section:

config Copy

krb5_auth = yes

krb5_ccache_type = FILE

mkhomedir = yes

Ensure that any leading semi-colons from each setting are removed. These changes require restarting the Winbind daemon:

command Copy

sudo /sbin/service winbind restart

Tip

The winbind daemon will stay running only if the machine is joined to a domain.

Open /etc/krb5.conf and change the following setting under the [libdefaults] section from KEYRING to FILE type:

config Copy

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

Verify Domain Membership

The XenDesktop Controller requires that all VDA machines, whether Windows or Linux, have a computer object in Active Directory.

Verify the machine is joined to a domain using Samba's net ads command:

command Copy

sudo net ads testjoin

Additional domain and computer object information can be verified with:

command Copy

sudo net ads info

Verify Kerberos Configuration

To verify Kerberos is configured correctly for use with the Linux VDA, check that the system keytab file has been created and contains valid keys:

command Copy

sudo klist -ke

This should display 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:

command Copy

sudo kinit -k MACHINE\$@REALM

The machine and realm names must be specified in uppercase, and 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:

Code Copy

sudo klist

Examine the machine’s account details using:

command Copy

sudo net ads status

Verify User Authentication

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

command Copy

wbinfo --krb5auth=domain\\username%password

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 will return a message indicating success or failure.

To verify that the Winbind PAM module is configured correctly, log on locally with a domain user account that has not logged onto the machine previously:

command Copy

ssh localhost -l domain\\username

id -u

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

command Copy

klist

Exit the session:

command Copy

exit

A similar test can be performed by logging onto the Gnome or KDE console directly.

Quest authentication service

Configure Quest on Domain Controller

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

For each domain user that needs 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 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 

Workaround SELinux Policy Enforcement

The default RHEL environment has SELinux fully enforced. This interferes with the Unix domain socket IPC mechanisms used by Quest and prevents domain users from logging on.

Tip

There are a few ways to workaround outlined here.

The easiest is to disable SELinux. As root, edit /etc/selinux/config and change the SELinux setting:

config Copy

SELINUX=disabled

This change requires a reboot:

command Copy

reboot

Important

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 daemon

Auto-renewal of Kerberos tickets needs to be enabled and disconnected; authentication (offline logon) needs to be disabled:

command Copy

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

This sets the renewal interval to 9 hours (32400 seconds) which is an 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

Quest requires that PAM and NSS be manually configured to enable domain user login via HDX and other services such as su, ssh, and RDP. To configure PAM and NSS:

command Copy

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss

Join Windows Domain

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

command Copy

sudo /opt/quest/bin/vastool -u user join domain-name

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

The XenDesktop 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:

command Copy

sudo /opt/quest/bin/vastool info domain

If the machine is joined to a domain this will return the domain name. If not joined, you will see the following error:

error Copy

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 using PAM, log on with a domain user account that has not logged onto the machine previously:

command Copy

ssh localhost -l domain\\username

id -u

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

command Copy

ls /tmp/krb5cc_uid

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

command Copy

/opt/quest/bin/vastool klist

Exit the session:

command Copy

exit

A similar test can be performed by logging onto the Gnome or KDE console directly.

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:

command Copy

su – 

adjoin -w -V -u user domain-name

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

The XenDesktop 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:

command Copy

su –

adinfo

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

command Copy

adinfo --sysinfo all

adinfo –diag

To test connectivity to the various Active Directory and Kerberos services:

command Copy

adinfo --test

SSSD

Use the following information to set up SSSD; it includes instructions for joining a Linux VDA machine to a Windows domain and provides guidance for configuring Kerberos authentication.

Note

If you are using SSSD, follow the instructions contained in this section instead of the information provided by the Add Linux machine to Windows domain section.

What is SSSD?

SSSD is a system daemon. It's primary function is to provide access to identify and authenticate remote resources through a common framework that can provide caching and offline support to the system. It provides both PAM and NSS modules, and in the future will support D-BUS based interfaces for extended user information. It also provides a better database to store local users as well as extended user data.

Setting up SSSD on RHEL and CentOS involves the following:

  1. Join the domain and create host keytab with Samba
  2. Set up SSSD
  3. Configure NSS/PAM
  4. Verify the Kerberos configuration
  5. Verify user authentication

Required software

The Active Directory provider was first introduced with SSSD version 1.9.0. If you are using an older version, follow the instructions provided in configuring the LDAP provider with Active Directory.

The following environments have been tested and verified when using the instructions included in this article:

  • RHEL 7.2/CentOS 7.2
  • Linux VDA versions 1.3, 1.4, 7.12

Join the domain and create host keytab with Samba

SSSD does not provide Active Directory client functions for joining the domain and managing the system keytab file. There are a few methods for achieving this, including:

  • adcli
  • realmd
  • winbind
  • samba

The information in this section describes the Samba approach only. For realmd, see the RHEL or CentOS documentation. These steps must be followed before configuring SSSD.

On the Linux client with properly configured files:

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

Configure the machine for Samba and Kerberos authentication:

command Copy

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

Where REALM is the Kerberos realm name in uppercase and domain is the short NetBIOS name of the Active Directory domain.

If DNS-based lookups of the KDC server and realm name is required, add the following two options to the above command:

command Copy

--enablekrb5kdcdns --enablekrb5realmdns

Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:

config Copy

kerberos method = secrets and  keytab

Joining the Windows domain requires that your domain controller is reachable and you have an Active Directory user account with permissions to add computers to the domain:

command Copy

sudo net ads join REALM -U user

Where REALM is the Kerberos realm name in uppercase, and user is a domain user with permissions to add computers to the domain.

Set up SSSD

Setting up SSSD consists of the following steps:

  • install the sssd-ad package on the Linux client machine
  • make configuration changes to various files (for example, sssd.conf)
  • start the sssd service:

An example sssd.conf configuration (additional options can be added as needed):

config Copy

[sssd]

config_file_version = 2

domains = ad.example.com

services = nss, pam

 

[domain/ad.example.com]

# Uncomment if you need offline logins

# cache_credentials = true

 

id_provider = ad

auth_provider = ad

access_provider = ad

ldap_id_mapping = true

ldap_schema = ad

 

# Should be specified as the lower-case version of the long version of the Active Directory domain.

ad_domain = ad.example.com

 

# Kerberos settings

krb5_ccachedir = /tmp

krb5_ccname_template = FILE:%d/krb5cc_%U

 

# Uncomment if service discovery is not working

# ad_server = server.ad.example.com

 

# Comment out if the users have the shell and home dir set on the AD side

default_shell = /bin/bash

fallback_homedir = /home/%d/%u

 

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available

# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM

Replace ad.example.comserver.ad.example.com with the corresponding values. For more details, see sssd-ad(5) - Linux man page.

Set the file ownership and permissions on sssd.conf:

command Copy

chown root:root /etc/sssd/sssd.conf

chmod 0600 /etc/sssd/sssd.conf

restorecon /etc/sssd/sssd.conf

Configure NSS/PAM

RHEL/CentOS

Use authconfig to enable SSSD, install oddjob-mkhomedir to make sure home directory creation works with SELinux:

command Copy

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

sudo service sssd start

sudo chkconfig sssd on

Verify the Kerberos configuration

To verify Kerberos is configured correctly for use with the Linux VDA, check that the system keytab file has been created and contains valid keys:

command Copy

sudo klist -ke

This should display 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:

command Copy

sudo kinit –k MACHINE\$@REALM

The machine and realm names must be specified in uppercase, and 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:

command Copy

sudo klist

Verify user authentication

Use the getent command to verify that the logon format it supported and whether the NSS works:

command Copy

sudo getent passwd DOMAIN\\username

The DOMAIN parameter should be the short version domain name. If another logon format from Citrix Receiver is needed, verify by using the getent command first.

The supported logon formats are:

  • Down-level logon name: DOMAIN\username
  • UPN: username@domain.com
  • NetBIOS Suffix format: username@DOMAIN

To verify that the SSSD PAM module is configured correctly, log on locally with a domain user account that has not logged onto the machine previously.

command Copy

sudo ssh localhost –l DOMAIN\\username

id -u

Check that a corresponding Kerberos credential cache file was created for the uid returned by the command:

command Copy

ls /tmp/krb5cc_{uid}

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

command Copy

klist

Install NVIDIA GRID drivers 

To enable HDX 3D Pro, additional installation steps are required to install the requisite graphics drivers on the hypervisor as well as on the VDA machines.

Configure the following:

  1. Citrix XenServer 
  2. VMware ESX

Follow the instructions for your chosen hypervisor.

Citrix XenServer

This detailed section walks through the install and configuration of the NVIDIA GRID drivers on Citrix XenServer

VMware ESX

Follow the information contained in this guide to install and configure the NVIDIA GRID drivers for VMware ESX.

VDA Machines 

Follow these steps to install and configure the drivers for each of the Linux VM guests:

  1. Before starting, ensure that the Linux VM is shut down.
  2. In XenCenter, add a GPU in GPU Passthrough mode to the VM.
  3. Start the RHEL VM.

To prepare the machine for the NVIDIA GRID drivers, the following steps are required:

command Copy

yum install gcc

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

systemctl set-default multi-user.target

Once complete, follow the steps in the Red Hat Enterprise Linux document to install the NVIDIA GRID driver.

Note

During the GPU driver install, select the default ('no') for each question.

Important

Once GPU Passthrough has been enabled, the Linux VM is no longer accessible via XenCenter so you need to use SSH to connect.

localized image

Set the correct configuration for the card:

command Copy

etc/X11/ctx-nvidia.sh

To take advantage of large resolutions and multi-monitor capabilities, you need a valid NVIDIA license. To apply the license, follow the product documentation from “GRID Licensing Guide.pdf - DU-07757-001 September 2015”.

Step 4: Install the Linux VDA

1. Uninstall the old version

If you have previously installed a version of the Linux VDA earlier than v1.0, uninstall it before installing the new version.

     (a) Stop the Linux VDA services:

command Copy

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

     (b) Uninstall the package:

command Copy

sudo rpm -e XenDesktopVDA

Note

Upgrading from the latest two versions is supported.

Note

Starting with version 1.3, the installation path changed. In previous releases, installation components were located in /usr/local/; the new location is /opt/Citrix/VDA/.

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

2. Install the Linux VDA

Install the Linux VDA software using Yum:

For RHEL 6/CentOS 6:

command Copy

sudo yum install -y XenDesktopVDA-7.12.0.375-1.el6_8.x86_64.rpm

For RHEL 7/CentOS 7:

command Copy

sudo yum install -y XenDesktopVDA-7.12.0.375-1.el7_2.x86_64.rpm

Install the Linux VDA software using the RPM package manager; before doing so, you must resolve the following dependencies:

For RHEL 6/CentOS 6:

command Copy

sudo rpm -i XenDesktopVDA-7.12.0.375-1.el6_8.x86_64.rpm

For RHEL 7/CentOS 7:

command Copy

sudo rpm -i XenDesktopVDA-7.12.0.375-1.el7_2.x86_64.rpm

RPM dependency list for RHEL 6:

dependencies Copy

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.0

ImageMagick >= 6.5.4.7

GConf2 >= 2.28.0

system-config-firewall-base >= 1.2.27

policycoreutils-python >= 2.0.83

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.0.9

ConsoleKit >= 0.4.1

dbus >= 1.2.24

dbus-x11 >= 1.2.24

gnome-session >= 2.28.0

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

openmotif >= 2.3.3

pam >= 1.1.1

util-linux-ng >= 2.17.2

bash >= 4.1

findutils >= 4.4

gawk >= 3.1

sed >= 4.2

cups >= 1.4.0

foomatic >= 4.0.0

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.7

RPM dependency list for RHEL 7:

dependencies Copy

postgresql-server >= 9.2

postgresql-jdbc >= 9.2

java-1.8.0-openjdk >= 1.8.0

ImageMagick >= 6.7.8.9

firewalld >= 0.3.9

policycoreutils-python >= 2.0.83

dbus >= 1.6.12

dbus-x11 >= 1.6.12

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.3.2

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

motif >= 2.3.4

pam >= 1.1.8

util-linux >= 2.23.2

bash >= 4.2

findutils >= 4.5

gawk >= 4.0

sed >= 4.2

cups >= 1.6.0

foomatic-filters >= 4.0.9

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

Important

The Linux VDA package requires a specific Xorg version.

For RHEL 6.8 and RHEL 7.2, the Linux VDA requires Xorg-x11-server-Xorg Version 1.17; do not upgrade this package.

3. Upgrade the Linux VDA (optional)

If you have previously installed Versions 1.3 or 1.4 of the Linux VDA, upgrade the Linux VDA software using Yum:

For RHEL 6/CentOS 6:

command Copy

sudo yum install -y XenDesktopVDA-7.12.0.375-1.el6_8.x86_64.rpm

For RHEL 7/CentOS 7:

command Copy

sudo yum install -y XenDesktopVDA-7.12.0.375-1.el7_2.x86_64.rpm

Upgrade the Linux VDA software using the RPM package manager:

For RHEL 6/CentOS 6:

command Copy

sudo rpm -U XenDesktopVDA-7.12.0.375-1.el6_8.x86_64.rpm

For RHEL 7/CentOS 7:

command Copy

sudo rpm -U XenDesktopVDA-7.12.0.375-1.el7_2.x86_64.rpm

Important

You must reboot the Linux VDA machine after upgrading.

Step 5: Run the Linux VDA

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

command Copy

sudo /sbin/service ctxhdx start

sudo /sbin/service ctxvda start

Stop the Linux VDA

To stop the Linux VDA services:

command Copy

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

Restart the Linux VDA

To restart the Linux VDA services:

command Copy

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

sudo /sbin/service ctxvda start

Check the status of the Linux VDA

To check the running state of the Linux VDA services:

command Copy

sudo /sbin/service ctxvda status

sudo /sbin/service ctxhdx status

Step 6: Configure the Linux VDA

Important

After installing the package, you must configure the Linux VDA by running the ctxsetup.sh script. If you have upgraded the package, you must run the ctxsetup.sh script to finalize your upgrade. Before making any changes, this script will verify the environment and ensure all dependencies are installed. If necessary, you can rerun this script at any time to change settings.

You can run the script manually with prompting, or automatically with preconfigured responses. Review Help about this script before proceeding:

command Copy

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh --help

Prompted configuration

Run a manual configuration with prompted questions:

command Copy

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh

Automated configuration

For an automated install, 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. This is typically set to N.
  • 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 using a TCP/IP port. This is typically port 80.
  • CTX_XDL_REGISTER_SERVICE = Y | N - The Linux Virtual Desktop services support starting during boot. This is typically set to Y.
  • 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 (by default ports 80 and 1494) in the system firewall for the Linux Virtual Desktop. This is typically set to Y.
  • 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 Service
    • 3 – Centrify DirectControl
    • 4 – SSSD
  • CTX_XDL_HDX_3D_PRO = Y | N – Linux Virtual Desktop supports HDX 3D Pro, a set of graphics acceleration technologies designed to optimize the virtualization of rich graphics applications. HDX 3D Pro requires a compatible NVIDIA Grid graphics card to be installed. If HDX 3D Pro is selected, the Virtual Delivery Agent is configured for VDI desktops (single-session) mode – (i.e. CTX_XDL_VDI_MODE=Y). This is not supported on SUSE. Ensure this value is set to N.
  • 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 to Y. This is typically set to N.
  • CTX_XDL_SITE_NAME = dns-name – The Linux VDA discovers LDAP servers using DNS, querying for LDAP service records. To limit the DNS search results to a local site, specify a DNS site name. This is typically empty [none].
  • CTX_XDL_LDAP_LIST = list-ldap-servers – The Linux VDA by default queries DNS to discover LDAP servers. However if DNS cannot provide LDAP service records, you can provide a space-separated list of LDAP Fully Qualified Domain Names (FQDNs) with LDAP port (e.g. ad1.mycompany.com:389). This is typically empty [none].
  • CTX_XDL_SEARCH_BASE = search-base – The Linux VDA by default queries LDAP using a search base set to the root of the Active Directory Domain (e.g. DC=mycompany,DC=com). However to improve search performance, you can specify a search base (e.g. OU=VDI,DC=mycompany,DC=com). This is typically empty [none].
  • CTX_XDL_START_SERVICE = Y | N - Whether or not the Linux VDA services are started when the Linux VDA configuration is complete. This is typically set to Y.

Set the environment variable and run the configure script:

command Copy

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST=list-ddc-fqdns

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-name

export CTX_XDL_LDAP_LIST=list-ldap-servers

export CTX_XDL_SEARCH_BASE=search-base

export CTX_XDL_START_SERVICE=Y|N

sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh

You must provide the -E option with sudo to pass the existing environment variables to the new shell it creates. Citrix recommends that you create a shell script file from the commands above with #!/bin/bash on the first line.

Alternatively, you can specify all parameters with a single command:

command Copy

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 \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh

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:

command Copy

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help

To remove configuration changes:

command Copy

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh

Important

This script will delete all configuration data from the database and will make the Linux VDA inoperable.

Configuration logs

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

Step 7: Create the machine catalog in XenApp or XenDesktop

The process for creating machine catalogs and adding Linux VDA machines is very 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:
    • Window Server OS or Server OS option for a hosted shared desktops delivery model. 
    • Windows Desktop OS or Desktop OS option for a VDI dedicated desktop delivery model.
  • Ensure that machines are set as not power managed.
  • Because PVS and MCS are not supported for Linux VDAs, choose the Another service or technology (existing images) deployment method.
  • 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 XenDesktop single user per machine delivery model.

Tip

If a machine leaves and is rejoined to the Active Directory domain, the machine will need to be removed and re-added again to the machine catalog.

Step 8: Create the delivery group in XenApp or XenDesktop

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:

  • For the delivery type, select Desktops or Applications.
  • 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.

The Citrix documentation for creating machine catalogs and delivery groups is referenced below:

Earlier versions of XenDesktop are not supported.