Product Documentation

Instalación de agentes VDA para SUSE Linux

Jul 07, 2016

Puede crear escritorios virtuales Linux basados en una distribución SUSE. Prepare las máquinas virtuales Linux, instale el nuevo software de VDA Linux 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

El funcionamiento de los comandos shell para Linux que se describen en este artículo se han comprobado 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.

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.

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 cada 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 Broker con nuevos puntos finales WCF que necesita Linux VDA y reinicia el servicio de 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 imagen siguiente.

localized image

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

Inicie la herramienta YaST

Se utiliza la herramienta YaST de SUSE Linux Enterprise para configurar todos los aspectos del sistema operativo.

Para iniciar la herramienta YaST de texto:

su -

yast

Para iniciar la herramienta YaST de interfaz gráfica:

su -

yast2 &

Configuración de red

En las siguientes secciones, se ofrece información sobre la configuración de las opciones y los servicios de red que usa el VDA para Linux. Se debería utilizar la herramienta YaST para configurar las opciones de red, no otros métodos como Network Manager. Estas instrucciones se basan en la herramienta YaST de interfaz gráfica; se puede usar la herramienta YaST de texto, pero tiene otro método de navegación que no se documenta aquí.

Configuración de nombre de host y DNS

  1. Abra las opciones de red de YaST.
  2. Solo SLED 12. En la ficha Global Options, cambie Network Setup Method a Wicked Service.
  3. Abra la ficha Hostname/DNS.
  4. Desmarque Change hostname via DHCP.
  5. Marque Assign Hostname to Loopback IP.
  6. Modifique lo siguiente para que refleje su propia configuración de red:
  • Hostname. Agregue el nombre de host DNS de la máquina.
  • Domain Name. Agregue el nombre de dominio DNS de la máquina.
  • Name Server. Agregue la dirección IP del servidor DNS. Por regla general, es la dirección IP del controlador de dominio de Active Directory.
  • Domain Search list. Agregue el nombre de dominio DNS.

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.

Inhabilitación del DNS de multidifusión

En solo SLED, la configuración predeterminada es tener el DNS de multidifusión (mDNS) habilitado, lo que puede dar lugar a resoluciones de nombres incoherentes. La opción mDNS no está habilitada en SLES de forma predeterminada, de modo que no se requiere ninguna acción. 

Para inhabilitar mDNS, modifique /etc/nsswitch.conf y cambie la línea que contiene:

hosts: files mdns_minimal [NOTFOUND=return] dns

a:

hosts: files dns

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 del servicio 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 eso, se prefiere mantener la hora sincronizada mediante un servicio remoto de NTP. Algunos cambios podrían ser necesarios en la configuración predeterminada de NTP:

  1. Abra la configuración de NTP de YaST y seleccione la ficha General Settings.
  2. En la sección Start NTP Daemon, marque Now and on Boot.
  3. Si está presente, seleccione el elemento Undisciplined Local Clock (LOCAL) y haga clic en Delete.
  4. Agregue una entrada para un servidor NTP y haga clic en Add.
  5. Seleccione el tipo de servidor en Server Type y haga clic en Next.
  6. Escriba el nombre DNS del servidor NTP en el campo Address. Por regla general, este servicio se aloja en el controlador de dominio de Active Directory.
  7. Deje el campo de opciones sin cambios.
  8. Haga clic en Test para comprobar la disponibilidad del servicio NTP.
  9. Haga clic en OK en las ventanas para guardar los cambios.

Nota

En caso de implementaciones de SLES 12, si el demonio de NTP no se inicia, puede deberse a un problema conocido de SUSE con directivas de AppArmor. Consulte aquí la solución del problema para obtener más información.

Instalación de paquetes dependientes de Linux VDA

El software Linux VDA para la distribución SUSE Linux Enterprise depende de los siguientes paquetes:

  • PostgreSQL
    • SLED/SLES 11: versión 9.1 o posterior
    • SLED/SLES 12: versión 9.3 o posterior
  • OpenJDK 1.7.0
  • Open Motif Runtime Environment 2.3.1 o posterior
  • Cups
    • SLED/SLES 11: versión 1.3.7 o posterior
    • SLED/SLES 12: versión 1.6.0 o posterior
  • Filtros Foomatic 
    • SLED/SLES 11: versión 3.0.0 o posterior
    • SLED/SLES 12: versión 1.0.0 o posterior
  • ImageMagick
    • SLED/SLES 11: versión 6.4.3.6 o posterior
    • SLED/SLES 12: versión 6.8 o posterior

Incorporación de repositorios

Algunos paquetes necesarios no están disponibles en todos los repositorios de SUSE Linux Enterprise:

  • SLED 11: PostgreSQL está disponible para SLES 11, pero no para SLED 11.
  • SLES 11: OpenJDK y Open Motif están disponibles para SLED 11, pero no para SLES 11.
  • SLED 12: PostgreSQL está disponible para SLES 12, pero no para SLED 12. ImageMagick está disponible mediante la ISO del SDK de SLE 12 o mediante el repositorio en línea.
  • SLES 12: No hay problemas; todos los paquetes están disponibles. ImageMagick está disponible mediante la ISO del SDK de SLE 12 o mediante el repositorio en línea.

Para resolver este problema, se recomienda obtener los paquetes que faltan en la edición que quiere instalar de los medios pertenecientes a la edición alternativa de SLE. Es decir, obtener los paquetes que faltan para instalar SLED de los medios de SLES y, viceversa, es decir, obtener los paquetes que faltan para instalar SLES de los medios de SLED. El enfoque que se describe a continuación monta los archivos ISO de SLED y SLES, y agrega los repositorios.

SLED 11


sudo mkdir -p /mnt/sles

sudo mount -t iso9660 \

           path-to-iso/SLES-11-SP3-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles

SLES 11

sudo mkdir -p /mnt/sled

sudo mount -t iso9660 \

           path-to-iso/SLED-11-SP3-DVD-x86_64-GM-DVD1.iso /mnt/sled

sudo zypper ar -f /mnt/sled sled

SLED 12

sudo mkdir -p /mnt/sles

sudo mount -t iso9660 \

           path-to-iso/SLES-12-DVD-x86_64-GM-DVD1.iso /mnt/sles

sudo zypper ar -f /mnt/sles sles

SLED/SLES 12

sudo mkdir -p /mnt/sdk

sudo mount -t iso9660 \

           path-to-iso/SLE-12-SDK-DVD-x86_64-GM-DVD1.iso /mnt/sdk

sudo zypper ar -f /mnt/sdk sdk

Instalación del cliente Kerberos

Instale el cliente Kerberos para la autenticación mutua entre el VDA de Linux y los Controllers de XenDesktop:

sudo zypper install krb5-client

La configuración del cliente Kerberos depende de la integración de Active Directory que se use (descrita más adelante).

Instalación de OpenJDK

Linux VDA depende de OpenJDK 1.7.0.

Sugerencia

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

SLED

En SLED, Java Runtime Environment debería haberse instalado con el sistema operativo. Confírmelo con:

       sudo zypper info java-1_7_0-openjdk

Actualice a la versión más reciente si se notifica el estado no actualizado:

sudo zypper update java-1_7_0-openjdk

Compruebe la versión de Java:

java -version

SLES

En SLES, Java Runtime Environment debe instalarse:

sudo zypper install java-1_7_0-openjdk

Compruebe la versión de Java:

java -version

Instalación de PostgreSQL

SLED/SLES 11

Instale los paquetes:

sudo zypper install libecpg6

sudo zypper install postgresql?init

sudo zypper install postgresql91

sudo zypper install postgresql91?server

sudo zypper install postgresql?jdbc

Tras la instalación, se necesitan pasos adicionales para inicializar el servicio de la base de datos e iniciar PostgreSQL en el arranque:

sudo /sbin/insserv postgresql

sudo /etc/init.d/postgresql restart

SLED/SLES 12

Instale los paquetes:

sudo zypper install postgresql-init

sudo zypper install postgresql93-server

sudo zypper install postgresql-jdbc

Tras la instalación, se necesitan pasos adicionales para inicializar el servicio de la base de datos e iniciar PostgreSQL en el arranque:

sudo systemctl enable postgresql

sudo systemctl restart postgresql

Los archivos de la base de datos se encuentran en /var/lib/pgsql/data.

Instalación del entorno en tiempo de ejecución Open Motif

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

SLED/SLES 11

Instale el paquete:

sudo zypper install openmotif-libs

SLED/SLES 12

Instale el paquete:

sudo zypper install motif

Instalación del respaldo a la impresión

El VDA para Linux requiere filtros cups y foomatic.

SLED/SLES 11

Instale los paquetes:

sudo zypper install cups 

sudo zypper install foomatic-filters

SLED/SLES 12

Instale los paquetes:

sudo zypper install cups

sudo zypper install cups-filters-foomatic-rip

Instalación de ImageMagick

Instale el paquete de ImageMagick:

sudo zypper install ImageMagick

Eliminación de repositorios

Una vez instalados los paquetes dependientes, se pueden quitar los repositorios de la edición alternativa que se hayan instalado antes. Asimismo, se pueden desmontar los medios que se hayan montado:

SLED 11

Quite los siguientes paquetes:

sudo zypper rr sles

sudo umount /mnt/sles

sudo rmdir /mnt/sles

SLES 11

Quite los siguientes paquetes:

sudo zypper rr sled

sudo umount /mnt/sled

sudo rmdir /mnt/sled

SLED 12

Quite los siguientes paquetes:

sudo zypper rr sles

sudo umount /mnt/sles

sudo rmdir /mnt/sles

SLED/SLES 12

Quite los siguientes paquetes:

sudo zypper rr sdk

sudo umount /mnt/sdk

sudo rmdir /mnt/sdk

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

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:

1. Abra YaST Windows Domain Membership.

2. Realice los siguientes cambios:

  • Establezca Domain o Workgroup en el nombre de su dominio de Active Directory o la dirección IP del controlador de dominio. El dominio debe escribirse en letras mayúsculas.
  • Marque Also Use SMB information for Linux Authentication.
  • Marque Create Home Directory on Login.
  • Marque Single Sign-on for SSH.
  • Compruebe que Offline Authentication no está marcada. Esta opción no es compatible con el VDA para Linux.

3. Haga clic en OK. Si se solicita que instale algunos paquetes, haga clic en Install.

4. Si se encuentra un controlador de dominio, se le preguntará si quiere unirse al dominio. Haga clic en Yes. 

5. Cuando se le solicite, introduzca las credenciales de un usuario de dominio con permisos para agregar equipos al dominio y haga clic en OK.

6. Aparecerá un mensaje con la indicación de que la operación se ha completado correctamente.

7. Si se solicita que instale paquetes samba y krb5, haga clic en Install.

Es posible que YaST haya indicado que estos cambios necesitan el reinicio de algunos servicios o que la máquina debe reiniciarse. Se recomienda reiniciar:

su -

reboot

Solo SLED o SLES 12. Revisión del nombre de caché de credenciales Kerberos

SLED/SLES 12 ha cambiado el nombre predeterminado de caché de credenciales Kerberos de la forma habitual FILE:/tmp/krb5cc_%{uid} a DIR:/run/user/%{uid}/krb5cc. Este nuevo método de caché DIR no es compatible con Linux VDA y se debe cambiar manualmente. Como usuario root, modifique /etc/krb5.conf y agregue la siguiente opción de configuración en la sección [libdefaults] si no está definida:

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

Verifique la información adicional del dominio y del objeto de equipo 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 usuarios

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 

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

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 ese 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

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 en línea del producto Citrix 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 Another service or technology (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.

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 SUSE 11:

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

Para SUSE 12:

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

Actualización de Linux VDA

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

Para SUSE 11:

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

Para SUSE 12:

sudo rpm -U XenDesktopVDA-1.3.0.312-1.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.

Nota

Actualmente, HDX 3D Pro no se admite en SUSE.

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

Para quitar los cambios de configuración:

sudo /usr/local/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 registro 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

Desinstalar Linux VDA

Para desinstalar el paquete Linux VDA:

sudo rpm -e 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

Personalización por usuario del entorno de escritorios

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

SLED/SLES 11

Modifique el archivo /etc/syslog-ng/syslog-ng.conf y agregue la siguiente línea en la sección s_sys:

udp(ip(127.0.0.1) port(514));

Guarde y cierre el archivo syslog-ng.conf. Reinicie el servicio syslog-ng y aplique el cambio:

sudo service syslog-ng restart

SLED/SLES 12

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 y aplique el cambio:

sudo 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

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

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 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. Por lo que podría tardar una cantidad inusitada de tiempo.

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.

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.