Product Documentation

Instalación de agentes VDA de Linux para Red Hat/CentOS

Jul 07, 2016

Puede crear escritorios virtuales Linux basados en una distribución Red Hat o CentOS. Prepare las máquinas virtuales Linux, instale el nuevo  software en ellas, configure el Delivery Controller y use Studio para poner los escritorios a disposición de los usuarios. 

Para obtener más información, consulte este artículo.

Nota

Los comandos shell para Linux que se usan en este documento se han comprobado en funcionamiento con el shell de GNU Bash.

Requisitos del sistema

Distribuciones de Linux

El producto para escritorios virtuales con Linux admite las siguientes distribuciones de Linux:

  • SUSE Linux Enterprise:
    • Desktop 11 Service Pack 4
    • Desktop 12 Service Pack 1
    • Server 11 Service Pack 4
    • Server 12 Service Pack 1
  • Red Hat Enterprise Linux
    • Workstation 6.7
    • Workstation 7.2
    • Server 6.7
    • Server 7.2
  • CentOS Linux
    • CentOS 6.7
    • CentOS 7.2

Nota

En todos los casos, la arquitectura de procesador admitida es x86-64.

Sugerencia

CentOS Linux se admite a partir de la versión 1.3. La información de instalación que contiene este artículo también se aplica a CentOS.

XenDesktop

Linux VDA admite las siguientes versiones de XenDesktop:

  • XenDesktop 7.1
  • XenDesktop 7.5
  • XenDesktop 7.6
  • XenDesktop 7.7
  • XenDesktop 7.8
  • XenDesktop 7.9

El proceso de configuración de los agentes VDA para Linux difiere ligeramente del de los VDA para Windows. Sin embargo, una comunidad de Delivery Controller es capaz de intermediar (hacer de broker) para escritorios Windows y Linux.

Nota

El VDA para Linux no es compatible con la versión 7.0 de XenDesktop ni con versiones anteriores.

Citrix Receiver

Se admiten las siguientes versiones de Citrix Receiver:

  • Citrix Receiver para Windows 4.4 o posterior (equivale a la versión 14.4 de wfica32.exe)
  • Citrix Receiver para Linux 13.3 o una versión posterior
  • Citrix Receiver para MAC OSX 12.1 o una versión posterior
  • Citrix Receiver para Android 3.8 o una versión posterior
  • Citrix Receiver para iOS 6.1.4 o una versión posterior
  • Citrix Receiver para Chrome o HTML5 2.0 (solo mediante Access Gateway)

Hipervisores

Se admiten los siguientes hipervisores para alojar máquinas virtuales invitadas con Linux VDA:

  • XenServer
  • VMware ESX y ESXi
  • Microsoft Hyper-V

También se admite el alojamiento en máquinas sin sistema operativo.

Sugerencia

Consulte la documentación del proveedor del hipervisor para ver la lista de las plataformas admitidas.

Paquetes de integración de Active Directory

Linux VDA admite los siguientes productos o paquetes de integración de Active Directory:

  • Samba Winbind
  • Quest Authentication Services 4.1 o una versión posterior
  • Centrify DirectControl

Sugerencia

Consulte la documentación del proveedor del paquete de integración de Active Directory para ver la lista de las plataformas admitidas.

HDX 3D Pro

Se necesitan los siguientes hipervisores, distribuciones de Linux y GPU de NVIDIA GRID para admitir HDX 3D Pro.

Hipervisores

Se admiten los siguientes hipervisores:

  • XenServer
  • VMware ESX y ESXi

Distribuciones de Linux

La siguiente distribución de Linux admite HDX 3D Pro:

  • Red Hat Enterprise Linux - Workstation 7.2

GPU

Se admiten las siguientes GPU:

  • NVIDIA GRID 3.0 - Tesla M60
  • NVIDIA GRID - K2

Configuración de Delivery Controllers

La versión 7.7 o posterior de XenDesktop incluye los cambios necesarios para admitir escritorios virtuales con Linux; sin embargo, se necesita una revisión hotfix o un script de actualización para las versiones anteriores. La instalación y la comprobación de estos se describe en esta sección. 

Actualización de la configuración del Delivery Controller

Para XenDesktop 7.6 SP2, aplique la revisión hotfix Update 2 para actualizar el Broker para escritorios virtuales con Linux. Las revisiones hotfix Update 2 están disponibles aquí:

  • CTX142438. Hotfix Update 2 para Delivery Controller 7.6 (32 bits) en inglés
  • CTX142439. Hotfix Update 2 para Delivery Controller 7.6 (64 bits) en inglés

Para las versiones anteriores de XenDesktop, se suministra un script de PowerShell denominado Update-BrokerServiceConfig.ps1. Este script actualiza la configuración del servicio de broker. Está disponible en el siguiente paquete:

  • citrix-linuxvda-scripts-1.3.0.zip

Repita los pasos siguientes en todos y cada uno de los Delivery Controller de la comunidad:

  1. Copie el script Update-BrokerServiceConfig.ps1 a la máquina del Delivery Controller.
  2. Abra una consola de Windows PowerShell en el contexto del administrador local.
  3. Vaya a la carpeta que contiene el script.
  4. Ejecute el script:

.\Update-BrokerServiceConfig.ps1

Nota

De forma predeterminada, PowerShell está configurado para impedir la ejecución de scripts de PowerShell. Si el script no se ejecuta, es posible que necesite cambiar la directiva de ejecución de PowerShell antes de intentarlo de nuevo:

Set-ExecutionPolicy Unrestricted

El script Update-BrokerServiceConfig.ps1 actualiza el archivo de configuración del servicio de broker con nuevos puntos finales WCF que necesita Linux VDA y reinicia el servicio del broker.  El script determina automáticamente la ubicación del archivo de configuración del servicio del broker. Se crea una copia de seguridad del archivo de configuración original en el mismo directorio con la extensión .prelinux.

Estos cambios no tendrán impacto en la intermediación (broker) de agentes VDA con Windows configurados para usar la misma comunidad de Delivery Controller. Con lo que una sola comunidad de Controllers puede administrar y actuar de broker en sesiones de agentes VDA con Windows y con Linux.

Comprobación de la configuración del Delivery Controller

Para comprobar si los cambios de configuración se han aplicado a un Delivery Controller, confirme que la cadena EndpointLinux aparece cinco veces en el archivo:

       %PROGRAMFILES%\Citrix\Broker\Service\BrokerService.exe.config

Desde el símbolo del sistema de Windows, en la sesión del administrador local:

     cd "%PROGRAMFILES%"\Citrix\Broker\Service\

     findstr EndpointLinux BrokerService.exe.config

Important

En la versión Linux 1.3, el agente de broker del VDA Linux está establecido con la versión XenApp/XenDesktop 7.8. No obstante, al agregar un catálogo de máquinas mediante en Studio, en la pantalla Configuración de catálogo de máquinas, el valor predeterminado se establece automáticamente con la versión 7.9. Debe establecer explícitamente la versión de VDA instalada con el valor 7.8 (o posterior). Consulte la siguiente imagen.

localized image

Preparación de la máquina Linux para la instalación de VDA

Verificación de la configuración de red

Citrix recomienda que la red esté conectada y correctamente configurada antes de continuar.

Solo RHEL 6: Establecer el nombre de host

Para que se informe correctamente el nombre de host de la máquina, cambie el archivo /etc/sysconfig/network para que solo contenga el nombre de host de la máquina.

HOSTNAME=hostname

Solo RHEL 7: Establecer el nombre de host

Para que se informe correctamente el nombre de host de la máquina, cambie el archivo /etc/hostname para que solo contenga el nombre de host de la máquina.

Asignación de una dirección de bucle invertido al nombre de host

Para que se informen correctamente el nombre de dominio DNS y el FQDN de la máquina, cambie la siguiente línea del archivo /etc/hosts para que contenga el FQDN y el nombre de host como las dos primeras entradas:

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

Por ejemplo:

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

Quite las demás referencias a hostname-fqdn o hostname de otras entradas del archivo.

Nota

Actualmente, Linux VDA no admite el truncamiento del nombre de NetBIOS; por tanto, el nombre de host no debe superar los 15 caracteres.

Sugerencia

Use solamente caracteres a-z, 0-9 y guiones (-). No utilice caracteres de subrayado bajo (_), espacios ni demás símbolos. No inicie un nombre de host con un número ni lo termine con un guión.

Comprobación del nombre de host

Compruebe que el nombre de host está definido correctamente:

hostname

Esto debe devolver solo el nombre de host de la máquina, no su nombre de dominio completo (FQDN).

Compruebe que el nombre de dominio completo (FQDN) está definido correctamente:

hostname -f

Esto debe devolver el nombre de dominio completo (FQDN) de la máquina.

Comprobación de la resolución de nombres y de la disponibilidad del servicio

Compruebe que se puede resolver el nombre de dominio completo (FQDN) y haga ping al controlador de dominio y al Delivery Controller de XenDesktop:

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn

Si no puede resolver el FQDN o hacer ping en alguna de estas máquinas, revise los pasos antes de continuar.

Configuración de la sincronización horaria (NTP)

Mantener sincronizados los relojes de los VDA, los Controllers de XenDesktop y los controladores de dominio es fundamental. Ahora bien, alojar Linux VDA como una máquina virtual puede causar problemas de reloj sesgado. Por este motivo, se recomienda sincronizar la hora con un servicio remoto de sincronización horaria.

RHEL 6.x y las versiones anteriores usan el demonio de NTP (ntpd) para la sincronización del reloj, mientras que el entorno RHEL 7.x utiliza un demonio más reciente, Chrony (chronyd). La configuración y el proceso de funcionamiento de los dos servicios son similares.

Solo RHEL 6: Configurar el servicio NTP

Como usuario root, modifique /etc/ntp.conf y agregue una entrada de servidor para cada servidor horario remoto:

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst

En una implementación típica, la hora debe sincronizarse desde los controladores del dominio local, no directamente desde grupos públicos de servidores NTP. Agregue una entrada de servidor para cada controlador de dominio de Active Directory que tenga en el dominio.

Quite todas las demás entradas server de la lista que incluyan loopback IP address, localhost y public server *.pool.ntp.org.

Guarde los cambios y reinicie el demonio de NTP:

sudo /sbin/service ntpd restart

Solo RHEL 7: Servicio Chrony

Como usuario root, modifique /etc/chrony.conf y agregue una entrada de servidor para cada servidor horario remoto:

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst

En una implementación típica, la hora debe sincronizarse desde los controladores del dominio local, no directamente desde grupos públicos de servidores NTP. Agregue una entrada de servidor para cada controlador de dominio de Active Directory que tenga en el dominio.

Quite todas las demás entradas server de la lista que incluyan loopback IP address, localhost y public server *.pool.ntp.org.

Guarde los cambios y reinicie el demonio de Chrony:

sudo /sbin/service chronyd restart

Inhabilitación de la autenticación emergente de proxy de red

Existe un problema específico de RHEL 6 que consiste en que los usuarios ven un diálogo emergente que les pide introducir la contraseña de root después de iniciar la sesión.

Para resolver este problema, como root, cree el archivo /etc/polkit-1/localauthority/30-site.d/20-no-show-proxy-dialog.pkla en un editor de textos y agregue el siguiente contenido:

[No Show Proxy Dialog]

Identity=unix-user:*

Action=org.freedesktop.packagekit.system-network-proxy-configure

ResultAny=no

ResultInactive=no

ResultActive=no

Sugerencia

Para obtener más información acerca de este problema, consulte la página de soluciones de Red Hat aquí. La solución correcta se describe en la sección de comentarios.

Instalación de OpenJDK

Linux VDA depende de OpenJDK. El entorno de tiempo de ejecución debe haberse instalado como parte de la instalación del sistema operativo.

Solo RHEL 6: OpenJDK 1.7

Confirme la versión correcta con:

sudo yum info java-1.7.0-openjdk

El OpenJDK previamente empaquetado puede ser una versión anterior. Actualice a la versión más reciente como se requiere:

sudo yum -y update java-1.7.0-openjdk

Establezca la variable de entorno JAVA_HOME agregando la siguiente línea al archivo ~/.bashrc:

export JAVA_HOME=/usr/lib/jvm/java

Abra un nuevo shell y compruebe la versión de Java:

java –version

Solo RHEL 7.0: OpenJDK 1.8

Confirme la versión correcta con:

sudo yum info java-1.8.0-openjdk

El OpenJDK previamente empaquetado puede ser una versión anterior. Actualice a la versión más reciente como se requiere:

sudo yum -y update java-1.8.0-openjdk

Establezca la variable de entorno JAVA_HOME agregando la siguiente línea al archivo ~/.bashrc:

export JAVA_HOME=/usr/lib/jvm/java

Abra un nuevo shell y compruebe la versión de Java:

java –version

Sugerencia

Para evitar problemas, instale solo la versión 1.7.0 o 1.8.0 de OpenJDK. Quite todas las demás versiones de Java que haya presentes en el sistema.

Instalación de PostgreSQL

Linux VDA requiere: PostgreSQL 8.4 (o una versión posterior) en RHEL 6, o bien PostgreSQL 9.2 (o una versión posterior) en RHEL 7.

Instale los siguientes paquetes:

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc

Es necesario el siguiente paso posterior a la instalación para inicializar la base de datos y que el servicio se inicie en el arranque. Los archivos de base de datos se crearán en /var/lib/pgsql/data. Este comando difiere de PostgreSQL 8 a 9.

Solo RHEL 6: PostgreSQL 8

sudo /sbin/service postgresql initdb

Solo RHEL 7: PostgreSQL 9

sudo postgresql-setup initdb

Inicio de PostgreSQL

En ambas versiones de PostgreSQL, configure el servicio para que se inicie en el arranque; para iniciarlo ahora:

sudo /sbin/chkconfig postgresql on

sudo /sbin/service postgresql start

Compruebe la versión de PostgreSQL con:

psql --version

Compruebe que se ha definido el directorio de datos mediante la utilidad de línea de comandos psql:

sudo -u postgres psql -c 'show data_directory'

Instalación de Motif

El VDA para Linux requiere el paquete motif u openmotif, según la distribución.

Solo RHEL 6: Abrir Motif

sudo yum -y install openmotif

Solo RHEL 7: Motif

sudo yum -y install motif

Instalación del respaldo a la impresión

El VDA para Linux requiere filtros cups y foomatic.

Solo RHEL 6: Respaldo a la impresión

sudo yum –y install cups

sudo yum -y install foomatic

Solo RHEL 7: Respaldo a la impresión

sudo yum –y install cups

sudo yum -y install foomatic-filters

Instalación de otros paquetes

Instale los demás paquetes requeridos:

sudo yum -y install redhat-lsb-core

sudo yum -y install ImageMagick

Preparación de la máquina virtual Linux para el hipervisor

Se necesitan algunos cambios cuando se ejecuta Linux VDA como una máquina virtual en un hipervisor admitido. Realice los siguientes cambios en función de la plataforma del hipervisor que utilice. No se requieren cambios si se está ejecutando la máquina Linux sin sistema operativo.

Corrección de la sincronización horaria en Citrix XenServer

Si está habilitada la funcionalidad de sincronización horaria de XenServer, se darán problemas en las máquinas virtuales Linux paravirtualizadas debido a que tanto NTP como XenServer intentarán administrar el reloj del sistema. Para evitar la desincronización del reloj respecto a los demás servidores, el reloj del sistema de cada invitado Linux debe sincronizarse con NTP. Por lo que es necesario inhabilitar la sincronización horaria del host. No se requieren cambios en el modo HVM.

En algunas de las distribuciones de Linux, si se ejecuta un kernel Linux paravirtualizado con XenServer Tools instalado, puede comprobar si la funcionalidad de sincronización horaria de XenServer está presente y habilitada desde la máquina virtual Linux:

su -

cat /proc/sys/xen/independent_wallclock

Esta acción devolverá:

  • 0. La funcionalidad de sincronización horaria está habilitada, por lo que se debe inhabilitar.
  • 1. La funcionalidad de sincronización horaria está inhabilitada, por lo que no es necesaria ninguna otra acción.

Si no está presente el archivo /proc/sys/xen/indepent_wallclock, no se necesitan los siguientes pasos.

Si está habilitada la funcionalidad de sincronización horaria, deberá inhabilitarla. Para ello, escriba 1 en el archivo:

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

Para que este cambio sea permanente y persista después de reiniciar la máquina, modifique el archivo /etc/sysctl.conf y agregue la línea:

xen.independent_wallclock = 1

Para comprobar los cambios, reinicie el sistema:

reboot

Después de reiniciar, compruebe que se ha definido correctamente:

su -

cat /proc/sys/xen/independent_wallclock

Esto debe devolver el valor 1.

Corrección de la sincronización horaria en Microsoft Hyper-V

Las máquinas virtuales Linux que tienen instalados los servicios de integración de Hyper-V para Linux pueden aprovechar la funcionalidad de sincronización horaria de Hyper-V para usar la hora del sistema operativo del host. Para que el reloj del sistema no se desincronice, se debe habilitar esta funcionalidad junto con los servicios NTP.

Desde el sistema operativo de administración:

  1. Abra la consola Hyper-V Manager. 
  2. Para ver la configuración de una máquina virtual Linux, seleccione Integration Services.
  3. Compruebe que Time synchronization está seleccionado.

Nota

Este método difiere de XenServer y VMware, donde se inhabilita la sincronización horaria del host para evitar conflictos con NTP. La sincronización horaria de Hyper-V puede coexistir y complementarse con la sincronización horaria de NTP.

Corrección de la sincronización horaria en ESX y ESXi

Si está habilitada la funcionalidad de sincronización horaria de VMware, se darán problemas en las máquinas virtuales Linux paravirtualizadas debido a que tanto NTP como el hipervisor intentarán sincronizar el reloj del sistema. Para evitar la desincronización del reloj respecto a los demás servidores, el reloj del sistema de cada invitado Linux debe sincronizarse con NTP. Por lo que es necesario inhabilitar la sincronización horaria del host.

Si ejecuta un kernel Linux paravirtualizado con VMware Tools instalado:

  1. Abra vSphere Client.
  2. Modifique la configuración de la máquina virtual Linux.
  3. En el diálogo Virtual Machine Properties, abra la ficha Options.
  4. Seleccione VMware Tools.
  5. En el cuadro Advanced, desmarque Synchronize guest time with host.

Incorporación de máquinas Linux en dominios Windows

XenDesktop para Linux admite varios métodos para agregar máquinas Linux al dominio de Active Directory:

  • Samba Winbind
  • Servicio de autenticación Quest
  • Centrify DirectControl

Siga las instrucciones que se indican a continuación para el método elegido.

Samba Winbind

Instalar o actualizar los paquetes requeridos

Instale o actualice los paquetes requeridos:

sudo yum -y install samba-winbind \

samba-winbind-clients \

krb5-workstation \

authconfig \

oddjob-mkhomedir

Habilitar el demonio de Winbind para que se inicie en el arranque

El demonio de Winbind debe configurarse para iniciarse en el arranque:

sudo /sbin/chkconfig winbind on

Configurar la autenticación de Winbind

Configure la máquina para la autenticación Kerberos mediante Winbind:

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

Donde REALM es el nombre del dominio Kerberos en mayúsculas y domain es el nombre corto de NetBIOS del dominio de Active Directory.

Si se necesitan las búsquedas basadas en DNS del nombre de dominio Kerberos y del servidor KDC, agregue las dos opciones siguientes al comando anterior:

--enablekrb5kdcdns --enablekrb5realmdns

Ignore los errores que devuelva el comando authconfig sobre errores de inicio del servicio Winbind. Se deben a que authconfig intenta iniciar el servicio Winbind cuando la máquina aún no está unida al dominio.

Abra /etc/samba/smb.conf y agregue las siguientes entradas en la sección [Global], después de la sección que haya generado la herramienta authconfig.

kerberos method = secrets and keytab

winbind refresh tickets = true

Linux VDA necesita el archivo de sistema /etc/krb5.keytab para autenticarse y registrarse en el Delivery Controller. El parámetro anterior de método de Kerberos obligará a Winbind a crear el archivo de sistema keytab la primera vez que la máquina se una al dominio. 

Unirse a un dominio de Windows

Para ello, se requiere que el controlador de dominio esté accesible y que tenga una cuenta de usuario de Active Directory con permisos para agregar máquinas al dominio.

sudo net ads join REALM -U user

Donde REALM es el nombre de dominio Kerberos en mayúsculas, y user es un usuario de dominio con permisos para agregar equipos al dominio.

Configurar PAM para Winbind

De forma predeterminada, la configuración del módulo Winbind PAM (pam_winbind) no permite el almacenamiento en caché de vales de Kerberos ni la creación del directorio principal. Abra /etc/security/pam_winbind.conf y agregue o cambie las siguientes entradas en la sección [Global]:

krb5_auth = yes

krb5_ccache_type = FILE

mkhomedir = yes

Compruebe que no hay signos de punto y coma al principio de cada parámetro. Estos cambios requieren reiniciar el demonio de Winbind:

sudo /sbin/service winbind restart

Sugerencia

El demonio winbind solo permanece en ejecución si la máquina está unida a un dominio.

Abra /etc/krb5.conf y cambie el siguiente parámetro en la sección [libdefaults] del tipo KEYRING a FILE:

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

Verificación de la pertenencia al dominio

El Controller de XenDesktop requiere que todas las máquinas VDA, Windows o Linux, tengan un objeto de equipo en Active Directory.

Compruebe que la máquina está unida a un dominio mediante el comando net ads de Samba:

sudo net ads testjoin

La información adicional del dominio y del objeto de equipo se puede verificar con:

sudo net ads info

Verificación de la configuración de Kerberos

Para verificar que Kerberos está configurado correctamente para su uso con Linux VDA, compruebe que el archivo del sistema keytab se ha creado y contiene claves válidas:

sudo klist -ke

Debería aparecer la lista de las claves disponibles para las distintas combinaciones de nombres principales y conjuntos de cifrado. Ejecute el comando kinit de Kerberos para autenticar la máquina en el controlador de dominio con estas claves:

sudo kinit -k MACHINE\$@REALM

Los nombres de máquina y de dominio Kerberos deben especificarse en mayúsculas, y debe anteponerse la barra diagonal inversa (\) al signo de dólar ($) para evitar la sustitución de shell. En algunos entornos, el nombre de dominio DNS difiere del nombre del dominio Kerberos; compruebe que se usa el nombre de dominio Kerberos. Si la operación de este comando se realiza correctamente, no aparece ningún resultado.

Compruebe que el vale de concesión de vales de la cuenta de la máquina se ha almacenado en caché:

sudo klist

Examine los datos de la cuenta de la máquina:

sudo net ads status

Verificación de la autenticación de usuario

Use la herramienta wbinfo para comprobar que los usuarios de dominio pueden autenticarse en el dominio:

wbinfo --krb5auth=domain\\username%password

El dominio especificado es el nombre de dominio de AD, no el nombre del dominio Kerberos. Para shell de Bash, debe anteponerse una barra diagonal inversa (\) a otra barra diagonal inversa. Este comando devolverá un mensaje que indicará si la operación se ha realizado correctamente o no.

Para verificar que el módulo Winbind PAM está configurado correctamente, inicie sesión localmente con una cuenta de usuario de dominio con que no se haya iniciado sesión antes en la máquina.

ssh localhost -l domain\\username

id -u

Compruebe que se ha creado el archivo de caché con las credenciales de Kerberos para el uid devuelto por el comando id -u:

ls /tmp/krb5cc_uid

Compruebe que los vales que se encuentran en la memoria caché de credenciales de Kerberos son válidos y no han caducado:

klist

Salga de la sesión:

exit

Se puede realizar una prueba similar iniciando sesión directamente en la consola Gnome o KDE.

Servicio de autenticación Quest

Configuración de Quest en el controlador de dominio

Se asume que se ha instalado y configurado el software de Quest en los controladores de dominio de Active Directory, y que se han recibido los privilegios administrativos necesarios para crear objetos de equipo en Active Directory.

Habilitación del inicio de sesión por parte de usuarios de dominio en máquinas con VDA para Linux

Para cada usuario de dominio que debe establecer sesiones HDX en una máquina con VDA para Linux:

  1. En la consola de administración Usuarios y equipos de Active Directory, abra las propiedades de usuario de Active Directory correspondientes a esa cuenta de usuario.
  2. Seleccione la ficha Unix Account.
  3. Marque Unix-enabled.
  4. Establezca el número principal GID en el ID de grupo perteneciente a un grupo de usuarios de dominio.

Nota

Estas instrucciones son equivalentes a configurar usuarios del dominio para iniciar sesión mediante la consola, RDP, SSH u otro protocolo de comunicación remota.

Configuración de Quest en Linux VDA 

Solución a la aplicación de la directiva de SELinux

En el entorno predeterminado de RHEL, SELinux se aplica en su totalidad. Lo que interfiere con los mecanismos de IPC de sockets para dominios Unix que utiliza Quest y evita que los usuarios inicien sesión.

Sugerencia

Hay varias formas de solucionar el problema  que se ofrecen aquí.

Lo más sencillo es inhabilitar SELinux. Como usuario root, modifique /etc/selinux/config y cambie la configuración de SELinux:

SELINUX=disabled

Este cambio requiere un reinicio:

reboot

Important

Utilice esta opción con cuidado. Habilitar la directiva de SELinux tras haberla inhabilitado puede causar un bloqueo absoluto, incluso para el usuario root y otros usuarios locales. 

Configuración del demonio VAS

La renovación automática de vales Kerberos debe estar habilitada y desconectada, y la autenticación (inicio de sesión sin conexión) debe estar inhabilitada:

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

Esta opción establece el intervalo de renovación a 9 horas (32400 segundos), es decir, una hora menos que la validez predeterminada de 10 horas del vale. Establezca esta opción en un valor inferior en sistemas con una validez más corta de vales.

Configuración de PAM y NSS

Quest requiere que PAM y NSS se configuren manualmente para habilitar el inicio de sesión de usuarios de dominio a través de HDX y otros servicios como su, ssh y RDP. Para configurar PAM y NSS:

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss

Unirse a un dominio de Windows

Una la máquina Linux al dominio de Active Directory con el comando vastool de Quest:

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

El usuario es un usuario de dominio con permisos para unir equipos al dominio de Active Directory. La variable domain-name es el nombre DNS del dominio; por ejemplo, ejemplo.com.

Verificación de la pertenencia al dominio

El Controller de XenDesktop requiere que todas las máquinas VDA, Windows o Linux, tengan un objeto de equipo en Active Directory. Para comprobar si hay una máquina Linux unida a Quest en el dominio:

sudo /opt/quest/bin/vastool info domain

Si la máquina está unida a un dominio, aparecerá el nombre de dominio. Si no está unida, verá el siguiente error:

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

Verificación de la autenticación de usuario

Para comprobar que Quest puede autenticar a los usuarios de dominio mediante PAM, inicie sesión con una cuenta de usuario de dominio con que no se haya iniciado sesión antes en la máquina:

ssh localhost -l domain\\username

id -u

Compruebe que se ha creado el archivo de caché con las credenciales de Kerberos para el UID devuelto por el comando id -u:

ls /tmp/krb5cc_uid

Compruebe que los vales que se encuentran en la memoria caché de credenciales de Kerberos son válidos y no han caducado:

/opt/quest/bin/vastool klist

Salga de la sesión:

exit

Se puede realizar una prueba similar iniciando sesión directamente en la consola Gnome o KDE.

Centrify DirectControl

Unirse a un dominio de Windows

Con el agente Centrify DirectControl instalado, una la máquina Linux al dominio de Active Directory mediante el comando adjoin de Centrify:

su – 

adjoin -w -V -u user domain-name

El parámetro user es un usuario de dominio de Active Directory con permisos para unir equipos al dominio de Active Directory. El parámetro domain-name es el nombre del dominio al que unir la máquina Linux.

Verificación de la pertenencia al dominio

El Controller de XenDesktop requiere que todas las máquinas VDA, Windows o Linux, tengan un objeto de equipo en Active Directory. Para comprobar si hay una máquina Linux unida a Centrify en el dominio:

su –

adinfo

Compruebe que el valor Joined to domain sea válido y el modo CentrifyDC mode devuelva el valor connected. Si el modo se queda bloqueado en el estado inicial, el cliente Centrify tiene problemas de conexión o autenticación en el servidor.

Para obtener información de diagnóstico y sistema más completa:

adinfo --sysinfo all

adinfo –diag

Para probar la conectividad a los distintos servicios de Active Directory y Kerberos:

adinfo --test

Instalación de los controladores de NVIDIA GRID 

Para habilitar HDX 3D Pro, se requieren pasos adicionales para instalar los controladores de gráficos en el hipervisor y en las máquinas VDA.

Configure las siguientes opciones:

  1. Citrix XenServer 
  2. VMware ESX

Siga las instrucciones para el hipervisor que haya elegido.

Citrix XenServer 

En esta sección, se detalla el proceso de instalación y configuración de los controladores NVIDIA GRID en Citrix XenServer.

VMware ESX 

Siga los pasos descritos en esta guía para instalar y configurar los controladores NVIDIA GRID para VMware ESX.

Máquinas VDA 

Siga estos pasos para instalar y configurar los controladores de cada invitado de VM de Linux:

  1. Antes de iniciar, compruebe que la VM de Linux está apagada.
  2. En XenCenter, agregue a la VM una GPU en el modo GPU Passthrough.
  3. Inicie la VM de RHEL.

Lleve a cabo los siguientes pasos para preparar la máquina para los controladores NVIDIA GRID:

# yum install gcc

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

# systemctl set-default multi-user.target

Una vez completados, siga los pasos indicados en el documento de Red Hat Enterprise Linux para instalar el controlador NVIDIA GRID.

Nota

Durante la instalación de controladores de GPU, seleccione la opción predeterminada ("no") para cada pregunta. 

Important

Una vez habilitada GPU Passthrough, ya no se podrá acceder a la VM de Linux a través de XenCenter, por lo que deberá usar SSH para conectarse a ella.

Para verificar si el controlador de gráficos NVIDIA GRID se ha instalado correctamente, ejecute “nvidia-smi”. Los resultados deberían ser similares a:

localized image

Establezca la configuración correcta para la tarjeta:

etc/X11/ctx-nvidia.sh

Para aprovechar las capacidades de varios monitores y altas resoluciones, necesitará una licencia válida de NVIDIA. Para aplicar la licencia, siga la documentación del producto de "GRID Licensing Guide.pdf - DU-07757-001" de septiembre de 2015 (en inglés).

Configuración del grupo de entrega y catálogo de máquinas Linux

Incorporación de una máquina Linux al catálogo de máquinas

El proceso de creación de catálogos de máquinas y de incorporación de máquinas Linux es muy similar al proceso habitual de VDA para Windows. Consulte la documentación de productos Citrix en línea para obtener una descripción más completa sobre cómo realizar esas tareas.

Existen restricciones que diferencian el proceso de creación de catálogos de máquinas con VDA para Windows del mismo proceso con VDA para Linux:

  • Para el sistema operativo, seleccione:
    • Opción de SO de servidor o SO de servidor Windows para un modelo de entrega de escritorios compartidos alojados. 
    • Opción de SO de escritorio o SO de escritorio Windows para un modelo de entrega de escritorios VDI dedicados.
  • Compruebe que las máquinas están establecidas como máquinas cuyas opciones de administración de energía no están administradas.
  • Como los agentes VDA para Linux no admiten PVS ni MCS, elija el método de implementación Otro servicio o tecnología (imágenes existentes).
  • No mezcle máquinas con agentes VDA para Windows y Linux en el mismo catálogo.

Nota

Las versiones anteriores de Citrix Studio no admiten la noción de "sistema operativo Linux". Sin embargo, seleccionar la opción SO de servidor o SO de servidor Windows implica un modelo de entrega equivalente de escritorios compartidos alojados. Seleccionar la opción de sistemas operativos de escritorio Windows o sistemas operativos de escritorio implica un modelo de entrega de un usuario por máquina.

A continuación, se ofrece la documentación de Citrix para crear catálogos de máquinas:

No se admiten las versiones anteriores de XenDesktop.

Sugerencia

Si una máquina se quita y luego se vuelve a unir al dominio de Active Directory, esa máquina se debe quitar y volver a agregar al catálogo de máquinas.

Incorporación de un grupo de entrega

El proceso de creación de un grupo de entrega y de incorporación de catálogos de máquinas con agentes VDA para Linux es muy similar al proceso de máquinas con agentes VDA para Windows. Consulte la documentación en línea del producto Citrix para obtener una descripción más completa sobre cómo realizar esas tareas.

Se aplican las siguientes restricciones para crear grupos de entrega que contengan catálogos de máquinas con Linux VDA:

  • Para el tipo de entrega, seleccione los escritorios. Las máquinas Linux VDA no admiten la entrega de aplicaciones.
  • Los grupos y usuarios de AD que seleccione deben estar correctamente configurados para poder iniciar sesión en las máquinas con VDA para Linux.
  • No permita que usuarios no autenticados (anónimos) inicien sesión.
  • No mezcle el grupo de entrega con catálogos de máquinas que contienen máquinas Windows.

A continuación, se ofrece la documentación de Citrix para crear grupos de entrega:

No se admiten las versiones anteriores de XenDesktop.

Instalación del software de Linux VDA

Desinstalación de la versión anterior

Si ya ha instalado una versión de Linux VDA anterior a la versión 1.0, desinstálela antes de instalar la nueva versión.

Detenga los servicios de Linux VDA:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

Desinstale el paquete:

sudo rpm -e XenDesktopVDA

Important

No se admite la actualización desde la versión Tech Preview 1.0, 1.1, 1.2 ni 1.3.

Para RHEL 6.0, Citrix recomienda conservar Xorg-x11-server-Xorg versión 1.15; no actualice este paquete.

Nota

A partir de la versión 1.3, ha cambiado la ruta de instalación. En las versiones anteriores, los componentes de instalación se encontraban en /usr/local/, mientras que la nueva ubicación es /opt/Citrix/VDA/.

Para ejecutar un comando, se necesita la ruta completa. Como alternativa, puede agregar /opt/Citrix/VDA/sbin y /opt/Citrix/VDA/bin a la ruta del sistema.

Instalación de Linux VDA

Instale el software de Linux VDA mediante el administrador de paquetes RPM:

Para RHEL 6:

sudo rpm -i XenDesktopVDA-1.3.0.312-1.el6.x86_64.rpm

Para RHEL 7.2:

sudo rpm -i XenDesktopVDA-1.3.0.312-1.el7.x86_64.rpm

Actualización de Linux VDA

Si ha instalado la versión 1.1 o 1.2 de Linux VDA, actualice el software mediante el administrador de paquetes RPM:

Para RHEL 6:

sudo rpm -U XenDesktopVDA-1.3.0.312-1.el6.x86_64.rpm

Para RHEL 7.2:

sudo rpm -U XenDesktopVDA-1.3.0.312-1.el7.x86_64.rpm

Important

Después de actualizar, debe reiniciar la máquina con Linux VDA.

Configuración de Linux VDA

Después de instalar el paquete, deberá configurar Linux VDA. Para ello, ejecute el script ctxsetup.sh. Si ya ha actualizado el paquete, ejecute el script ctxsetup.sh para finalizar la actualización. Antes de realizar cambios, este script comprobará el entorno y verificará si todas las dependencias están instaladas. Si es necesario, este script se puede volver a ejecutar en cualquier momento para cambiar la configuración.

El script se puede ejecutar con intervención manual o automáticamente con respuestas preconfiguradas. Consulte la ayuda de este script antes de continuar:

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

Configuración con preguntas

Ejecute una configuración manual con preguntas para el usuario:

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

Configuración automatizada

En caso de una instalación automática, las opciones necesarias para el script de instalación pueden especificarse con variables de entorno. Si todas las variables necesarias están presentes, el script no solicitará ninguna información al usuario, por lo que el proceso de instalación se incluirá en el script.

Las variables de entorno admitidas son:

  • CTX_XDL_SUPPORT_DDC_AS_CNAME = Y | N. Virtual Delivery Agent admite que se especifique un nombre de Delivery Controller mediante un registro CNAME de DNS. Normalmente, está establecido en N.
  • CTX_XDL_DDC_LIST = list-ddc-fqdns. Virtual Delivery Agent necesita una lista, separada con espacios, de los nombres de dominio completos (FQDN) de los Delivery Controllers
  • que se van a usar para registrarse en un agente. Se debe especificar al menos un FQDN o alias de CNAME.
  • CTX_XDL_VDA_PORT = port-number. Virtual Delivery Agent se comunica con los Delivery Controllers a través de un puerto TCP/IP. Por regla general, es el puerto 80.
  • CTX_XDL_REGISTER_SERVICE = Y | N. Los servicios de escritorio virtual Linux admiten el inicio durante el arranque. Normalmente, está establecido en Y.
  • CTX_XDL_ADD_FIREWALL_RULES = Y | N. Los servicios de escritorio virtual Linux requieren que se permitan conexiones de red entrantes a través del firewall del sistema. Puede abrir automáticamente los puertos necesarios (de forma predeterminada, los puertos 80 y 1494) en el firewall del sistema del escritorio virtual Linux. Normalmente, está establecido en Y.
  • CTX_XDL_AD_INTEGRATION = 1 | 2 | 3. Virtual Delivery Agent requiere parámetros de configuración Kerberos para autenticarse en los Delivery Controllers. La configuración de Kerberos se determina a partir de la herramienta de integración de Active Directory instalada y configurada en el sistema. Especifique el método admitido de integración de Active Directory que se va a utilizar:
    • 1. Samba Winbind
    • 2. Servicio de autenticación Quest
    • 3. Centrify DirectControl
  • CTX_XDL_HDX_3D_PRO= Y | N. El escritorio virtual Linux admite HDX 3D Pro, un conjunto de tecnologías para la aceleración de gráficos que se han diseñado para optimizar la virtualización de aplicaciones con gráficos sofisticados. HDX 3D Pro requiere una tarjeta gráfica NVIDIA GRID instalada y compatible. Si se selecciona HDX 3D Pro, Virtual Delivery Agent se configurará para el modo de escritorios VDI (sesión única); es decir, CTX_XDL_VDI_MODE=Y. Esto no se admite en SUSE. Compruebe que el valor está establecido en N.
  • CTX_XDL_VDI_MODE= Y | N. Indica si configurar la máquina siguiendo un modelo de entrega de escritorios dedicados (VDI) o de escritorios compartidos alojados. Para entornos HDX 3D Pro, este valor debe establecerse en Y. Normalmente, está establecido en N.
  • CTX_XDL_SITE_NAME= dns-name. Virtual Delivery Agent detecta los servidores LDAP que utilizan DNS, ya que consulta los registros del servicio LDAP. Para limitar los resultados de búsqueda de DNS a un sitio local, se puede especificar un nombre de sitio DNS. Por regla general, suele estar vacío [none].
  • CTX_XDL_LDAP_LIST= list-ldap-servers. De forma predeterminada, Virtual Delivery Agent consulta DNS para detectar servidores LDAP. Sin embargo, si el DNS no puede proporcionar registros de servicio LDAP, usted puede proporcionar una lista separada con espacios de los nombres de dominio completos LDAP con puerto LDAP (p. ej. ad1.miempresa.com:389). Por regla general, suele estar vacío [none].
  • CTX_XDL_SEARCH_BASE= search-base. De forma predeterminada, Virtual Delivery Agent consulta LDAP mediante una búsqueda base establecida en la raíz del dominio de Active Directory (por ejemplo, DC=miempresa,DC=com). A fin de mejorar el rendimiento de la búsqueda, se puede especificar una base de búsqueda (por ejemplo, OU=VDI,DC=miempresa,DC=com). Por regla general, suele estar vacío [none].
  • CTX_XDL_START_SERVICE = Y | N. Indica si los servicios de Linux VDA se inician cuando se complete su configuración. Normalmente, está establecido en Y.

Establezca la variable de entorno y ejecute el script de configuración:

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

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

Debe proporcionar la opción -E con sudo para pasar las variables de entorno existentes al nuevo shell que se crea. Citrix recomienda crear un archivo de script shell a partir de los comandos anteriores con #!/bin/bash en la primera línea.

De forma alternativa, los parámetros se pueden especificar con un único comando:

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 \

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

Eliminación de cambios de configuración

En algunos casos, puede que sea necesario quitar los cambios de configuración realizados por el script ctxsetup.sh sin desinstalar el paquete de Linux VDA.

Consulte la ayuda de este script antes de continuar:

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

Para quitar los cambios de configuración:

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

Important

Este script eliminará todos los datos de configuración de la base de datos y hará que Linux VDA deje de funcionar.

Registros de configuración

Los scripts ctxcleanup.sh y ctxsetup.sh mostrarán errores en la consola, con información adicional que se enviará a un archivo de registros de configuración:

/tmp/xdl.configure.log

Reinicie los servicios de Linux VDA para que los cambios surtan efecto.

Ejecución del software de VDA

Una vez configurado Linux VDA mediante el script ctxsetup.sh, utilice los siguientes comandos para controlarlo.

Iniciar Linux VDA

Para iniciar los servicios de Linux VDA:

sudo /sbin/service ctxhdx start

sudo /sbin/service ctxvda start

Detener Linux VDA

Para detener los servicios de Linux VDA:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx stop

Reiniciar Linux VDA

Para reiniciar los servicios de Linux VDA:

sudo /sbin/service ctxvda stop

sudo /sbin/service ctxhdx restart

sudo /sbin/service ctxvda start

Comprobar el estado de Linux VDA

Para comprobar el estado de ejecución de los servicios de Linux VDA:

sudo /sbin/service ctxvda status

sudo /sbin/service ctxhdx status

Desinstalación del software de Linux VDA

Consultar el estado de instalación Linux VDA

Para comprobar si Linux VDA está instalado y para ver la versión del paquete instalado:

rpm -q XenDesktopVDA

Para ver información más detallada:

rpm –qi XenDesktopVDA

Nota

La desinstalación del software de VDA para Linux eliminará los datos asociados con PostgreSQL y otros datos de configuración. Sin embargo, no se quitará el paquete de PostgreSQL ni los demás paquetes dependientes que se configuraron antes de instalar Linux VDA.

Quitar paquetes dependientes

Este artículo no cubre la eliminación de paquetes dependientes ni de PostgreSQL.

Solución de problemas

Comprobar que se utiliza la codificación H.264

Linux VDA 1.3 agrega H.264 y un valor HardwareEncoding a la ruta del Registro HKLM\Software\Citrix\Ica\Session\\Graphics para facilitar la solución de problemas de gráficos que puedan darse con el VDA.

Ejecute el siguiente comando para anunciar la codificación H.264 en Linux VDA antes de que se inicie una sesión:

/opt/Citrix/VDA/bin/ctxreg create -k

"HKLM\System\CurrentControlSet\Control\Citrix\Thinwire" -t "REG_DWORD" -v

"AdvertiseH264" -d "0x00000001" --force

Inicie sesión y compruebe si se ha creado la clave H264 en la ruta del Registro; si es así, se utiliza efectivamente la codificación H.264.

/opt/Citrix/VDA/bin/ctxreg list -k

"HKLM\Software\Citrix\Ica\Session\{SESSION_ID}\Graphics"

Comprobar que se utiliza la codificación por hardware para 3D Pro

La codificación por hardware para 3D Pro está inhabilitada de forma predeterminada, por lo que debe usar el comando siguiente para habilitarla:

/opt/Citrix/VDA/bin/ctxreg create -k

"HKLM\System\CurrentControlSet\Control\Citrix\Thinwire" -t "REG_DWORD" -v

"HardwareEncoding" -d "0x00000001" --force

Inicie sesión y verifique el valor de "HardwareEncoding" en la ruta del Registro (0 significa que no se utiliza la codificación por hardware, mientras que 1 significa que sí se utiliza).

/opt/Citrix/VDA/bin/ctxreg list -k

"HKLM\Software\Citrix\Ica\Session\{SESSION_ID}\Graphics"

Use el comando siguiente para ver su ID de sesión:

/opt/Citrix/VDA/bin/ctxqsession

Personalizar el entorno de escritorio para cada usuario

Actualmente, el agente VDA para Linux no permite que el usuario elija el entorno de escritorio al iniciar sesión; para solucionar este problema, el usuario puede configurar un archivo (por ejemplo, .xsession) para que la distribución de Linux defina el entorno de escritorio predeterminado para cada usuario. Para obtener más información, consulte los documentos adjuntos a la distribución de Linux.

Para usar el entorno KDE como entorno predeterminado:

#! /usr/bin/env bash

exec startkde

Para establecer GNOME como entorno de escritorio predeterminado:

#! /usr/bin/env bash

exec gnome-session

Comprobar que la máquina Linux se ha preparado correctamente

Los problemas más comunes tienen como origen una configuración incorrecta de la máquina Linux, principalmente de redes, del servidor horario NTP o del dominio de Active Directory. Por lo tanto, corregir la configuración de la máquina Linux resuelve a menudo los problemas que se dan con el software de VDA.

Configurar el seguimiento y la captura de registros

Los registros de Broker Agent y del servicio HDX se capturan en syslog. El servicio de asistencia de Citrix dispone de un conjunto de herramientas que habilitan un seguimiento adicional durante una llamada de asistencia.

Captura de registros del servicio HDX

El servicio HDX está configurado para capturar mensajes externos en syslog y no se necesita ninguna configuración adicional.

Captura de registros de Broker Agent 

Broker Agent (también conocido como el servicio ctxvda) captura datos de registro en syslog mediante sockets de red. Esto puede no estar configurado de forma externa. Para habilitar la captura de registros de Broker Agent en syslog, se requiere la siguiente configuración.

Modifique el archivo /etc/rsyslog.conf y agregue las siguientes líneas:

$ModLoad imudp

$UDPServerRun 514

Guarde y cierre el archivo rsyslog.conf. Reinicie el servicio rsyslog para que el cambio surta efecto:

sudo /sbin/service rsyslog restart

Qué hacer si no se inician las sesiones HDX

Compruebe que no hay procesos huérfanos que podrían estar impidiendo el inicio de nuevas sesiones:

sudo pkill -9 ctxhdx

sudo pkill -9 ctxgfx

sudo pkill -9 ctxlogin

sudo pkill -9 ctxvfb

Reinicie los servicios de Linux VDA y vuelva a intentar la conexión.

Comprobar la pertenencia y los permisos de archivos y directorios clave

Compruebe la pertenencia y los permisos de los siguientes directorios y archivos:

  • /var - Owner: root, Group: root, Permissions: 0755
  • /var/xdl - Owner: ctxsrvr, Group: ctxadm, Permissions: 0755
  • /var/xdl/.isacagent - Owner: root, Group: root, Permissions: 0666
  • /var/xdl/.winsta - Owner: ctxsrvr, Group: ctxadm, Permissions: 0777
  • /var/xdl/vda - Owner: root, Group: root, Permissions: 0755

Problemas de actualización de pantalla en varios monitores con HDX 3D Pro

Si ve problemas de actualización en pantallas que no sean el monitor principal, compruebe que la licencia de NVIDIA GRID está disponible.

El sonido no se oye

Compruebe que el control de volumen del dispositivo que ejecuta Citrix Receiver y del escritorio Linux no está desactivado o establecido en un nivel bajo.

Compruebe si el sonido está habilitado en Linux VDA. Use la herramienta ctxreg para consultar el valor del elemento de configuración fDisableCam: 

sudo ctxreg read -k "HKLM\System\CurrentControlSet\Control\Citrix\WinStations\tcp" -v fDisableCam

Un valor de 0x1 significa que el sonido está inhabilitado. Para habilitarlo, establezca fDisableCam en 0x0: 

sudo ctxreg update -k "HKLM\System\CurrentControlSet\Control\Citrix\WinStations\tcp" -v fDisableCam  -d 0x00000000

Si sigue sin oírse el sonido, compruebe que pulseaudio ha cargado el receptor de sonido de Citrix. El módulo de PulseAudio se carga en el demonio pulseaudio cuando se inicia la sesión. Use la herramienta pacmd para comprobar si el receptor de sonido de Citrix está cargado:

pacmd list-sinks

Si el receptor de sonido de Citrix está cargado, debería aparecer:

name:

driver:

Si el receptor de sonido de Citrix no está cargado, detenga el proceso ctxaudio y reinícielo.

El sonido no se graba

Compruebe que el sonido está habilitado en Linux VDA y la grabación de sonido está habilitada en el cliente ICA. Si sigue sin grabarse el sonido, compruebe que pulseaudio ha cargado la fuente de sonido de Citrix. Si la grabación de sonido está habilitada en el cliente ICA, el módulo de PulseAudio se cargará en el demonio pulseaudio cuando se inicie la sesión. Use la herramienta pacmd para comprobar si la fuente de sonido de Citrix está cargada:

pacmd list-sources

Si la fuente de sonido de Citrix está cargada, debería aparecer:

name:

driver:

Si la fuente de sonido de Citrix no está cargada, detenga el proceso ctxaudio y reinícielo.

No se puede imprimir

Hay varios elementos para comprobar si la impresión funciona correctamente. El demonio de impresión es un proceso que se ejecuta para cada sesión y debería estar en ejecución durante toda la sesión. Compruebe que el demonio de impresión se esté ejecutando.

ps –ef | grep ctxlpmngt

Si el proceso ctxlpmngt no se está ejecutando, inícielo manualmente desde una línea de comandos.

Si la impresión sigue sin funcionar, el siguiente elemento a comprobar es el marco CUPS. El servicio ctxcups administra las impresoras y se comunica con el marco Linux CUPS. Este es un proceso único por máquina y se puede comprobar con:

service ctxcups status

Si el servicio no se está ejecutando, inícielo manualmente:

service ctxcups start

Registro extra para imprimir CUPS

Al ser un componente de Linux VDA, el método para obtener el registro de un componente de impresión es similar al de los demás componentes.

Para Red Hat, se necesitan pasos adicionales para configurar el archivo del servicio de CUPS. De lo contrario, algunos registros no se capturarán en hdx.log.

sudo service cups stop

sudo vi /etc/systemd/system/printer.target.wants/cups.service

PrivateTmp=false

sudo service cups start

sudo systemctl daemon-reload

Esta configuración es solo para recopilar el registro completo de impresión cuando surja un problema. Por regla general, esta configuración no se recomienda porque afecta negativamente a la seguridad de CUPS.

Los documentos impresos son ilegibles 

Las impresiones ilegibles pueden deberse a un controlador de impresora incompatible. Se puede definir una configuración de controladores por usuario si se modifica el archivo de configuración ~/.CtxlpProfile.

[DEFAULT_PRINTER]

printername=

model=

ppdpath=

drivertype=

El campo printername contiene el nombre de la impresora predeterminada del cliente. Este es un valor de solo lectura, por lo que no se puede modificar.

Important

Los campos ppdpath, model y drivertype no se deben establecer al mismo tiempo, ya que solo uno tiene efecto en la impresora asignada. 

Si el controlador de impresora universal no es compatible con la impresora cliente, el modelo del controlador de la impresora nativa se puede configurar con la opción model=. El nombre del modelo actual de la impresora se puede encontrar con el comando lpinfo.

lpinfo –m

xerox/ph3115.ppd.gz Xerox Phaser 3115, SpliX V. 2.0.0

xerox/ph3115fr.ppd.gz Xerox Phaser 3115, SpliX V. 2.0.0

xerox/ph3115pt.ppd.gz Xerox Phaser 3115, SpliX V. 2.0.0

El modelo se puede establecer para que coincida con la impresora:

Model=xerox/ph3115.ppd.gz

Si el controlador de impresora universal no es compatible con la impresora cliente, se puede configurar la ruta al archivo ppd del controlador nativo de la impresora. El valor de ppdpath es la ruta absoluta al archivo del controlador nativo de la impresora. 

Por ejemplo, hay un controlador ppd en /home/tester/NATIVE_PRINTER_DRIVER.ppd. 

ppdpath=/home/tester/NATIVE_PRINTER_DRIVER.ppd

Existen tres tipos de controlador de impresora universal suministrados por Citrix (postscript, pcl5 y pcl6). Se pueden configurar como tipo de controlador si no hay disponible ningún controlador nativo de impresora. 

Por ejemplo, si el tipo de controlador de la impresora predeterminada del cliente es PCL5.

drivertype=pcl5

Nota

Citrix Receiver para Mac y Citrix Receiver para Linux solo admiten impresoras PostScript. Por lo tanto, no se aplican los controladores de impresora universal PCL5 ni PCL6. En este caso, ppdpath o el modelo del controlador nativo de impresora se debe establecer como impresora no PostScript.

No funciona la asignación de unidades del cliente

La funcionalidad de asignación de unidades del cliente incluye un proceso de demonio (ctxcdmd). Si se produce un error en esa funcionalidad, reinicie la máquina con Linux VDA y compruebe si el demonio se inició correctamente:

Ps -lef | grep ctxcdmd

El nombre del archivo presente en la unidad asignada debe respetar las reglas de nomenclatura del sistema operativo de Receiver y del VDA. 

Problemas conocidos

El estado Bloq Mayús de Citrix Receiver para Android se puede invertir cuando la sesión presenta un perfil móvil

Es posible que se pierda el estado Bloq Mayús cuando se mueve la conexión de Citrix Receiver para Android del dispositivo. La solución es usar la tecla Mayúsculas en el teclado extendido para alternar entre mayúsculas y minúsculas.

Los atajos de teclado que contienen ALT no siempre funcionan cuando se conecta a Linux VDA mediante Citrix Receiver para Mac

De forma predeterminada, Citrix Receiver para Mac envía AltGr para las teclas Opciones o Alt de izquierda y derecha. Es posible cambiar este comportamiento en la configuración de Citrix Receiver, pero los resultados varían según las diferentes aplicaciones.

Unas bibliotecas de cliente X más recientes pueden causar problemas de asignación de teclado en SUSE Linux Enterprise Desktop 11

Unas versiones más recientes de los paquetes xorg-x11-libX11 en SUSE Linux Enterprise Desktop 11 pueden tener problemas para controlar cambios de asignación de teclado, lo que a su vez puede causar problemas con la funcionalidad del teclado en una sesión HDX. Esto puede ocurrir si la versión instalada de los paquetes se encuentra en el intervalo de 7.4-5.11.11.1 a 7.4-5.11.15.1.

La solución es revertir a la versión SP3 del paquete xorg-x11-libX11 para que los cambios de asignación de teclado funcionen normalmente. Por ejemplo:

rpm -i --force xorg-x11-libX11-7.4-5.9.1

rpm –i --force xorg-x11-libX11-32bit-7.4-5.9.1

rpm -e xorg-x11-libX11-7.4-5.11.15.1

rpm -e xorg-x11-libX11-32bit-7.4-5.11.15.1

Debe hacerse antes de que un usuario inicie sesión en la máquina porque, si se lleva a cabo cuando haya una sesión activa, esta configuración no se aplicará hasta la próxima vez que el usuario inicie sesión.

Si va a actualizar desde SP3, los paquetes xorg-x11-libX11 anteriores se pueden bloquear en la versión instalada, por lo que no cambiarán durante la actualización. Antes de actualizar de la forma habitual, ejecute lo siguiente:

zypper al xorg-x11-libX11

zypper al xorg-x11-libX11-32bit

Las sesiones pueden tardar en iniciarse si se utiliza Linux VDA con un Delivery Controller de XenDesktop 7.1

El inicio lento se produce por la presencia de parámetros CGP en el archivo ICA generado por Delivery Controller 7.1. Cuando están presentes esos parámetros, Citrix Receiver intenta establecer una conexión en el puerto TCP 2598. La configuración predeterminada del firewall en algunas distribuciones de Linux (como SLED 12) consiste en colocar paquetes SYN TCP, lo que resulta en un tiempo de espera y, por lo tanto, un largo inicio de sesión. La solución es configurar el firewall de Linux VDA de modo que rechace los paquetes SYN TCP en el puerto 2598. Este problema se ha solucionado en versiones más recientes de Delivery Controller.

El registro falla cuando Linux VDA se vuelve a unir al dominio

En algunos casos, cuando un Linux VDA se vuelve a unir al dominio y se genera un nuevo conjunto de claves Kerberos, Broker no puede establecer un contexto de seguridad con el VDA. Esto suele deberse a que el Broker utiliza un vale de servicio de VDA guardado en caché que se ha quedado obsoleto porque está basado en el conjunto anterior de claves Kerberos. Lo que no impedirá que el VDA se conecte al Broker, pero este no podrá establecer un contexto de seguridad de vuelta al VDA. El síntoma habitual de este problema es que falla el registro del VDA.

Este problema se resolverá por sí solo cuando el vale de servicio del VDA caduque y se renueve, aunque esos vales suelen durar mucho tiempo. Podrían ser horas.

La solución es borrar el vale guardado en la memoria caché del Broker. Puede simplemente reiniciar el Broker o ejecutar en él lo siguiente desde un símbolo del sistema como administrador:

klist -li 0x3e4 purge

Esta acción purgará todos los vales de servicio que guarda en la memoria caché de LSA la entidad de servicio de red donde se ejecuta Citrix Broker Service. Se quitarán los vales de servicio de otros VDA y, posiblemente, de otros servicios. No obstante, se trata de un proceso inofensivo, ya que los vales de servicio se pueden obtener de nuevo de KDC cuando sea necesario.

Falta el icono de pantalla de bloqueo cuando se usa HDX 3D Pro con GNOME

Cuando los controladores NVIDIA GRID están activos, Gnome Desktop Manager (GDM) no está activo y la funcionalidad de bloqueo de pantalla de GDM no está disponible.

Audio Plug and Play no admitido 

Se recomienda que los dispositivos de captura de sonido estén conectados a la máquina cliente antes de empezar a grabar sonido en una sesión ICA. Si el dispositivo se conecta una vez iniciada la aplicación de grabación de sonido, esa aplicación puede dejar de responder. Si se produce este problema, reinicie la aplicación. Puede darse un problema similar si el dispositivo de captura se desconecta durante la grabación.

Distorsión de sonido

Puede producirse un sonido distorsionado en Receiver para Windows 10 durante la grabación de sonido.

El controlador CTXPS no es compatible con algunas impresoras PLC

Si se dañan las impresiones, establezca el controlador nativo de impresora que haya proporcionado el fabricante.

Impresión lenta de documentos grandes 

Al imprimir un documento grande en una impresora local del cliente, el archivo que debe imprimirse se transfiere a través de una conexión de servidor. En conexiones lentas, puede tardar mucho tiempo. 

La impresora y las notificaciones de trabajos de impresión aparecen en otras sesiones

Linux no tiene el mismo concepto de sesión que Windows. Por lo tanto, todos los usuarios reciben notificaciones de todo el sistema. Para inhabilitar esas notificaciones, el administrador debe modificar el archivo de configuración CUPS /etc/cups/cupsd.conf.

En el archivo, busque el nombre de la directiva actual configurada.

DefaultPolicy default

Si el nombre de la directiva es el predeterminado, agregue las siguientes líneas al bloque XML de la directiva predeterminada.

# Job/subscription privacy...

JobPrivateAccess default

JobPrivateValues default

SubscriptionPrivateAccess default

SubscriptionPrivateValues default

… …

Require user @OWNER

Order deny,allow

Order deny,allow

Glosario

Broker. Componente de XenDesktop encargado de intermediar en las sesiones HDX a los distintos VDA que se encuentran en una implementación de XenDesktop. También conocido como Desktop Delivery Controller (DDC) o XenDesktop Controller.

Broker Agent. Componente de la máquina Linux VDA que proporciona el escritorio a entregar. Broker Agent se comunica con el Broker para habilitar la intermediación de las sesiones. Se divide en dos componentes clave: el servicio VDA y el servicio HDX.

Citrix Director. La consola de asistencia Citrix para supervisar y controlar los agentes VDA de XenDesktop.

Citrix Studio. La consola de administración Citrix que se utiliza para configurar XenDesktop.

Desktop Delivery Controller (DDC). El controlador para la entrega de escritorios de XenDesktop. También conocido como Broker o Delivery Controller.

FQDN. Nombre de dominio completo.

HDX. Protocolo para la experiencia de alta definición. Antes conocido como protocolo ICA de Citrix.

Servicio HDX. El servicio de Linux (ctxhdx) que se comunica de forma remota al escritorio virtual Linux mediante el protocolo HDX. Se comunica con el servicio VDA para habilitar la intermediación de sesiones.

RHEL. Red Hat Enterprise Linux. Una distribución comercial de Linux que ofrece Red Hat.

SLED. SUSE Linux Enterprise Desktop. Una distribución comercial de Linux que ofrece Novell.

SLES. SUSE Linux Enterprise Server. Una distribución comercial de Linux que ofrece Novell.

VDA. Virtual Delivery Agent.

Servicio VDA. El servicio de Linux (ctxvda) que se comunica con el Broker para habilitar la intermediación de sesiones. También se comunica con el servicio HDX para la entrega de las sesiones remotas.