Instalar Linux Virtual Delivery Agent para SUSE manualmente

Importante:

Para instalaciones nuevas, se recomienda usar Easy Install para una instalación rápida. Easy Install ahorra tiempo y esfuerzo, y es menos propenso a errores que la instalación manual descrita en este artículo.

Paso 1: Prepare la instalación

Paso 1a: Inicie la herramienta YaST

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

Para iniciar la herramienta YaST de texto:

su -

yast
<!--NeedCopy-->

Para iniciar la herramienta YaST de interfaz gráfica:

su -

yast2 &
<!--NeedCopy-->

Paso 1b: Configure la 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. Utilice la herramienta YaST para configurar las opciones de red, no otros métodos del tipo Network Manager. Estas instrucciones se basan en la herramienta YaST de interfaz de usuario. Se puede usar la herramienta YaST de texto, pero tiene otro método de navegación que no se documenta aquí.

Configurar el 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. Desactive Change hostname via DHCP.
5. Active Assign Hostname to Loopback IP.
6. Modifique lo siguiente para que refleje su propia configuración de red:
   • Host name: 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 NetBIOS. Por lo tanto, el nombre de host no debe superar los 15 caracteres.

Sugerencia:

Use solamente caracteres de “a” a “z”, de “A” a “Z”, de 0 a 9 y guiones (-). No utilice guiones bajos (_), espacios ni otros símbolos. No inicie un nombre de host con un número ni lo termine con un guión. Esta regla también se aplica a nombres de host de Delivery Controller.

Inhabilitar DNS de multidifusión

Solo en SLED, la configuración predeterminada tiene habilitado DNS de multidifusión (mDNS), lo que puede dar lugar a resoluciones de nombres incoherentes. mDNS no está habilitado en SLES de forma predeterminada, por lo que no es necesario hacer nada.

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

hosts: files mdns_minimal [NOTFOUND=return] dns

Para:

hosts: files dns

Comprobar el nombre de host

Compruebe que el nombre de host está definido correctamente:

hostname
<!--NeedCopy-->

Este comando devuelve 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
<!--NeedCopy-->

Este comando devuelve el nombre de dominio completo (FQDN) de la máquina.

Comprobar la resolución de nombres y 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:

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn
<!--NeedCopy-->

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

Paso 1c: Configure el servicio NTP

Mantener sincronizados los relojes de los VDA, los Delivery Controllers 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”, active 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 haciendo 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, puede que el demonio de NTP no se inicie. Este es un problema conocido de SUSE con directivas de AppArmor. Consulte la solución del problema para obtener más información.

Paso 1d: Instale paquetes dependientes de Linux VDA

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

• PostgreSQL
  • SLED/SLES 12: Versión 9.3 o una posterior
• OpenJDK 1.8.0
• Open Motif Runtime Environment 2.3.1 o una versión posterior
• Cups
  • SLED/SLES 12: Versión 1.6.0 o una posterior
• Filtros Foomatic
  • SLED/SLES 12: Versión 1.0.0 o una posterior
• ImageMagick
  • SLED/SLES 12: Versión 6.8 o una posterior

Agregar repositorios

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

• 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 presenta 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, obtenga 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 siguiente monta los archivos ISO de SLED y SLES, y agrega los repositorios.

• En SLED 12, ejecute los comandos:

sudo mkdir -p /mnt/sles

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

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

• En SLED/SLES 12, ejecute los comandos:

sudo mkdir -p /mnt/sdk

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

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

Instalar el cliente Kerberos

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

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

La configuración del cliente Kerberos depende de la integración de Active Directory que se use. Consulte la siguiente descripción.

Instalar OpenJDK

Linux VDA depende de OpenJDK 1.8.0.

Sugerencia:

Para evitar errores de registro con el Delivery Controller, compruebe que solo ha instalado OpenJDK 1.8.0. Quite todas las demás versiones de Java que haya presentes en su sistema.

• SLED:

1. En SLED, Java Runtime Environment suele instalarse con el sistema operativo. Compruebe si se ha instalado:

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

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

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

3. Compruebe la versión de Java:

   java -version
   <!--NeedCopy-->
   

• SLES:

1. En SLES, instale Java Runtime Environment:

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

2. Compruebe la versión de Java:

   java -version
   <!--NeedCopy-->
   

Instalar PostgreSQL

En SLED/SLES 12, instale los paquetes:

sudo zypper install postgresql-init

sudo zypper install postgresql-server

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

Tras la instalación, se requieren pasos adicionales para inicializar el servicio de la base de datos y para que PostgreSQL se inicie durante el arranque de la máquina:

sudo systemctl enable postgresql

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

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

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

• en SLED 12, ejecute los comandos para quitar los paquetes:

sudo zypper rr sles

sudo umount /mnt/sles

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

• en SLED/SLES 12, ejecute los comandos para quitar los paquetes:

sudo zypper rr sdk

sudo umount /mnt/sdk

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

Paso 2: Prepare 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.

Corregir la sincronización horaria en Citrix Hypervisor

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

En algunas distribuciones de Linux, si se ejecuta un kernel Linux paravirtualizado con Citrix VM Tools instalado, puede comprobar si la función de sincronización horaria de Citrix Hypervisor está presente y habilitarla en la máquina virtual de Linux:

su -

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

Este comando devuelve 0 o 1:

• 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 el archivo /proc/sys/xen/independent_wallclock no está presente, no es necesario que siga estos pasos.

Si se habilita, inhabilite la función de sincronización horaria con un 1 en el archivo:

sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

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

Después de reiniciar, compruebe que la configuración es correcta:

su -

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

Este comando devuelve el valor 1.

Corregir 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 aplicar 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, esta funcionalidad se debe habilitar junto con los servicios NTP.

Desde el sistema operativo de administración:

1. Abra la consola del Administrador de Hyper-V.
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 Citrix Hypervisor 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.

Corregir la sincronización horaria en ESX y ESXi

Si está habilitada la funcionalidad de sincronización horaria de VMware, se dan problemas en las máquinas virtuales Linux paravirtualizadas debido a que tanto NTP como el hipervisor intentan 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 eso, 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 cuadro de diálogo Propiedades de la máquina virtual, abra la ficha Opciones.
4. Seleccione VMware Tools.
5. En el cuadro Advanced, desmarque la casilla Synchronize guest time with host.

Paso 3: Agregue la máquina virtual (VM) de Linux al dominio de Windows

Linux VDA admite varios métodos para agregar máquinas Linux al dominio de Active Directory (AD):

• Samba Winbind
• Quest Authentication Services
• Centrify DirectControl

Siga las instrucciones en función del método elegido.

Nota:

Los inicios de sesión pueden fallar cuando se usa el mismo nombre de usuario para la cuenta local en el Linux VDA y la cuenta en AD.

Samba Winbind

Unirse al dominio de Windows

Se requiere que el controlador de dominio esté accesible y se necesita disponer de 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 nombre del 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 Aceptar. Si se solicita que instale algunos paquetes, haga clic en Install.

4. Si se encuentra un controlador de dominio, se le pregunta si quiere unirse al dominio. Haga clic en Sí.

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. Le recomendamos que reinicie la máquina:

su -

reboot
<!--NeedCopy-->

Solo SLED/SLES 12: Revisión del nombre de la caché de credenciales de Kerberos

SLED/SLES 12 ha cambiado la especificación de nombre de la caché de credenciales de Kerberos predeterminada de 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}

Verificar la pertenencia al dominio

El Delivery Controller requiere que todas las máquinas VDA (tanto Windows como Linux) tengan un objeto de equipo en Active Directory.

Ejecute el comando net ads de Samba para verificar que la máquina está unida a un dominio:

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

Ejecute el siguiente comando para comprobar la información adicional de dominio y objeto de equipo:

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

Verificar la configuración de Kerberos

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

sudo klist –ke
<!--NeedCopy-->

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

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

Compruebe que el tíquet de TGT de la cuenta de la máquina se ha almacenado en caché:

sudo klist
<!--NeedCopy-->

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

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

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

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

Para comprobar que el módulo Winbind PAM está configurado correctamente, inicie sesión en Linux VDA con una cuenta de usuario de dominio que no se haya utilizado antes.

ssh localhost -l domain\username
id -u
<!--NeedCopy-->

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

Compruebe que los tíquets que se encuentran en la memoria caché de credenciales de Kerberos que pertenece al usuario son válidos y no han caducado:

klist
<!--NeedCopy-->

Salga de la sesión.

exit
<!--NeedCopy-->

Se puede realizar una prueba similar iniciando sesión directamente en la consola Gnome o KDE. Continúe con el Paso 6: Instale Linux VDA después de la verificación de unión al dominio.

Quest Authentication Services

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

Permitir que los usuarios de dominio inicien sesión en máquinas con Linux VDA

Para permitir que los usuarios de dominio puedan establecer sesiones HDX en una máquina con Linux VDA:

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. Active Unix-enabled.
4. Defina Primary GID Number con el ID de grupo de un grupo de usuarios real del dominio.

Nota:

Estas instrucciones son equivalentes a definir usuarios de dominio para que inicien sesión desde la consola, RDP, SSH u otro protocolo de comunicación remota.

Configurar Quest en Linux VDA

Configurar el demonio de VAS

La renovación automática de tíquets de Kerberos debe estar habilitada y desconectada. 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
<!--NeedCopy-->

Este comando establece el intervalo de renovación a nueve horas (32 400 segundos), es decir, una hora menos que la validez predeterminada de 10 horas del tíquet. Establezca esta opción en un valor inferior en sistemas con una validez más corta de tíquets.

Configurar PAM y NSS

Para habilitar el inicio de sesión del usuario de dominio mediante HDX y otros servicios como su, ssh y RDP, ejecute los siguientes comandos para configurar PAM y NSS de forma manual:

sudo /opt/quest/bin/vastool configure pam

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

Unirse al dominio de Windows

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

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

El parámetro user 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.

Verificar la pertenencia al dominio

El Delivery Controller requiere que todas las máquinas VDA (tanto Windows como 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
<!--NeedCopy-->

Si la máquina está unida a un dominio, este comando devuelve el nombre del dominio. En cambio, si la máquina no está unida a ningún dominio, aparece 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

Verificar la autenticación de usuario

Para comprobar que Quest puede autenticar usuarios de dominio a través de PAM, inicie sesión en Linux VDA con una cuenta de usuario de dominio que no se haya utilizado antes.

ssh localhost -l domain\username
id -u
<!--NeedCopy-->

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

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

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

Salga de la sesión.

exit
<!--NeedCopy-->

Se puede realizar una prueba similar iniciando sesión directamente en la consola Gnome o KDE. Continúe con el Paso 6: Instale Linux VDA después de la verificación de unión al dominio.

Centrify DirectControl

Unirse al 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
<!--NeedCopy-->

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 se unirá la máquina Linux.

Verificar la pertenencia al dominio

El Delivery Controller requiere que todas las máquinas VDA (tanto Windows como 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
<!--NeedCopy-->

Compruebe que el valor Joined to domain sea válido y el modo CentrifyDC 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
<!--NeedCopy-->

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

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

Continúe con el Paso 6: Instale Linux VDA después de la verificación de unión al dominio.

Paso 4: Instale .NET Core Runtime como requisito previo

Antes de instalar Linux VDA, instale .NET Core Runtime conforme a las instrucciones de https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.

• Para la versión inicial de 1912 LTSR, CU1 y CU2, instale .NET Core Runtime 2.1.
• Para CU3 y versiones posteriores, instale .NET Core Runtime 3.1.

Después de instalar .NET Core Runtime, ejecute el comando which dotnet para encontrar su ruta de runtime.

En función del resultado del comando, establezca la ruta binaria de runtime de .NET Core. Por ejemplo, si el resultado del comando es /aa/bb/dotnet, use /aa/bb como ruta binaria de .NET.

Paso 5: Descargue el paquete de Linux VDA

Vaya a la página de descargas de Citrix Virtual Apps and Desktops. Expanda la versión correcta de Citrix Virtual Apps and Desktops y haga clic en Componentes para descargar el paquete de Linux VDA correspondiente a su distribución Linux.

Paso 6: Instale Linux VDA

Paso 6a: Desinstale la versión anterior

Si ya ha instalado una versión anterior a las dos versiones anteriores y una versión LTSR, desinstálela antes de instalar la nueva versión.

1. Detenga los servicios de Linux VDA:

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

   Nota:

   Antes de detener los servicios ctxvda y ctxhdx, ejecute el comando service ctxmonitorservice stop para detener el demonio del servicio de supervisión. De lo contrario, el demonio del servicio de supervisión reinicia los servicios que ha detenido.

2. Desinstale el paquete:

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

Importante:

Se admite la actualización desde las dos últimas versiones.

Nota:

Los componentes de instalación se encuentran en /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.

Paso 6b: Instale Linux VDA

Instalar el software de Linux VDA mediante Zypper:

Para SUSE 12:

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

Instale el software de Linux VDA mediante el administrador de paquetes RPM. Antes de hacerlo, resuelva las siguientes dependencias:

Para SUSE 12:

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

Paso 6c: Actualice la versión de Linux VDA (optativo)

Puede actualizar la versión de una instalación existente desde las dos versiones anteriores y desde una versión LTSR.

Para SUSE 12:

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

Lista de dependencias RPM para SUSE 12:

postgresql-server >= 9.3

postgresql-jdbc >= 9.2

java-1.8.0-openjdk >= 1.8.0

ImageMagick >= 6.8

dbus-1 >= 1.8.8

dbus-1-x11 >= 1.8.8

libXpm4 >= 3.5.11

libXrandr2 >= 1.4.2

libXtst6 >= 1.2.2

motif >= 2.3

pam >= 1.1.8

bash >= 4.2

findutils >= 4.5

gawk >= 4.1

sed >= 4.2

cups >= 1.6.0

cups-filters-foomatic-rip >= 1.0.0

openldap2 >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

python-requests >= 2.8.1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsLzma) <= 4.4.6-1

libtcmalloc4 >= 2.5

libcap-progs >= 2.22

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

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

Importante:

Reinicie la máquina Linux VDA después de actualizar.

Paso 7: Instale controladores NVIDIA GRID

Para habilitar HDX 3D Pro, debe instalar los controladores NVIDIA GRID en el hipervisor y en las máquinas VDA.

Para instalar y configurar el administrador de GPU virtual de NVIDIA GRID (el controlador de hosts) en los hipervisores específicos, consulte estas guías:

• Citrix Hypervisor
• VMware ESX

Para instalar y configurar los controladores de VM invitada de NVIDIA GRID, siga estos pasos generales:

1. Asegúrese de que la máquina virtual invitada esté apagada.
2. En el panel de control del hipervisor, asigne una GPU a la VM.
3. Inicie la VM.
4. Instale el controlador de VM invitada en la VM.

Paso 8: Configure Linux VDA

Después de instalar el paquete, debe configurar el Linux VDA. Para ello, ejecute el script ctxsetup.sh. Antes de realizar cambios, este script examina el entorno existente y verifica si están instaladas todas las dependencias. Si fuera necesario, puede volver a ejecutar este script en cualquier momento para cambiar la configuración.

Puede ejecutar el script manual o automáticamente con respuestas preconfiguradas. Consulte la ayuda del script antes de continuar:

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

Configuración con preguntas

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

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

Configuración automatizada

En caso de una instalación automática, proporcione las opciones necesarias para el script de instalación con variables de entorno. Si están presentes todas las variables necesarias, el script no pide ninguna información.

Las variables de entorno admitidas son:

• CTX_XDL_SUPPORT_DDC_AS_CNAME=Y | N: Linux VDA permite especificar un nombre de Delivery Controller mediante un registro CNAME de DNS. Se establece en N de forma predeterminada.
• CTX_XDL_DDC_LIST=’list-ddc-fqdns’: Linux VDA necesita una lista de nombres de dominio completo de Delivery Controllers, separados por espacios, para registrarse en un Delivery Controller. Se debe especificar al menos un FQDN o alias de CNAME.
• CTX_XDL_VDA_PORT=port-number: Linux VDA se comunica con los Delivery Controllers a través de un puerto TCP/IP. Este es el puerto 80 de forma predeterminada.
• CTX_XDL_REGISTER_SERVICE=Y | N: Los servicios de Linux Virtual Desktop se inician después del arranque de la máquina. El valor está establecido en Y de forma predeterminada.
• CTX_XDL_ADD_FIREWALL_RULES=Y | N: Los servicios de Linux Virtual Desktop requieren que se permitan las 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 para Linux Virtual Desktop. Se establece en Y de forma predeterminada.
• CTX_XDL_AD_INTEGRATION=1 | 2 | 3 | 4: Linux VDA 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 – Quest Authentication Services
  • 3 – Centrify DirectControl
  • 4 – SSSD
• CTX_XDL_HDX_3D_PRO = Y | N: Linux VDA admite HDX 3D Pro, un conjunto de tecnologías para la aceleración de la GPU que se ha diseñado para optimizar la virtualización de aplicaciones con gráficos sofisticados. Si se selecciona HDX 3D Pro, el VDA se configura para el modo de escritorios VDI (sesión única); es decir, CTX_XDL_VDI_MODE=Y.
• CTX_XDL_VDI_MODE=Y | N: Indica si configurar la máquina a partir de un modelo de entrega de escritorios dedicados (VDI) o un modelo de entrega de escritorios compartidos alojados. Para entornos HDX 3D Pro, establezca esta variable en Y. De forma predeterminada, esta variable está establecida en N.
• CTX_XDL_SITE_NAME=dns-name: Linux VDA detecta los servidores LDAP mediante DNS. Para limitar los resultados de búsqueda de DNS a un sitio local, especifique un nombre de sitio DNS. Esta variable está establecida en <none> de forma predeterminada.
• CTX_XDL_LDAP_LIST=’list-ldap-servers’: Linux VDA consulta a DNS para detectar servidores LDAP. Sin embargo, si el DNS no puede proporcionar registros del servicio LDAP, se puede suministrar una lista de nombres FQDN de LDAP, separados por espacios, con el puerto de LDAP. Por ejemplo, ad1.miempresa.com:389. Esta variable está establecida en <none> de forma predeterminada.
• CTX_XDL_SEARCH_BASE=search-base-set: Linux VDA consulta a LDAP a partir de una base de búsqueda establecida en la raíz del dominio de Active Directory (por ejemplo, DC=miempresa,DC=com). Para mejorar el rendimiento de la búsqueda, puede especificar otra base de búsqueda (por ejemplo, OU=VDI,DC=miempresa,DC=com). Esta variable está establecida en <none> de forma predeterminada.
• CTX_XDL_FAS_LIST=’list-fas-servers’: Los servidores del Servicio de autenticación federada (FAS) se configuran a través de la directiva de grupo de AD. Como Linux VDA no admite las directivas de grupo de AD, en su lugar, se puede suministrar una lista de servidores FAS, separados por punto y coma. La secuencia debe ser la misma que la configurada en la directiva de grupo de AD. Si alguna dirección de servidor está eliminada, complete el espacio en blanco correspondiente con la cadena de texto <none> y no cambie la secuencia de las direcciones de servidor.
• CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime: La ruta de instalación de .NET Core Runtime para admitir el nuevo servicio de agente intermediario (ctxvda). La ruta predeterminada es /usr/bin.
• CTX_XDL_START_SERVICE=Y | N: Indica si los servicios de Linux VDA se inician cuando se complete su configuración. Se establece en Y de forma predeterminada.

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

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-site-name | '<none>'

export CTX_XDL_LDAP_LIST='list-ldap-servers' | '<none>'

export CTX_XDL_SEARCH_BASE=search-base-set | '<none>'

export CTX_XDL_FAS_LIST='list-fas-servers' | '<none>'

export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime

export CTX_XDL_START_SERVICE=Y|N

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

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

También puede especificar todos los parámetros 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|4 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST='list-ldap-servers' \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST='list-fas-servers' \

CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \

CTX_XDL_START_SERVICE=Y|N \

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

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

Para quitar los cambios de configuración:

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

Importante:

Este script elimina todos los datos de configuración de la base de datos y provoca que Linux VDA deje de funcionar.

Registros de configuración

Los scripts ctxcleanup.sh y ctxsetup.sh muestran 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.

Paso 9: Ejecute XDPing

Proporcionamos una utilidad de línea de comandos, la herramienta XDPing de Linux, para comprobar la presencia de problemas de configuración comunes en un entorno Linux VDA. Puede instalar el paquete XDPing en cualquier máquina que ejecute una distribución de Linux compatible. XDPing no requiere que el paquete de Linux VDA esté instalado en la máquina. Para obtener más información acerca de la herramienta, consulte el artículo CTX202015 de Knowledge Center.

Paso 10: Ejecute Linux 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
<!--NeedCopy-->

Detener Linux VDA:

Para detener los servicios de Linux VDA:

sudo /sbin/service ctxvda stop

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

Nota:

Antes de detener los servicios ctxvda y ctxhdx, ejecute el comando service ctxmonitorservice stop para detener el demonio del servicio de supervisión. De lo contrario, el demonio del servicio de supervisión reinicia los servicios que ha detenido.

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

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

Paso 11: Cree el catálogo de máquinas en Citrix Virtual Apps o Citrix Virtual Desktops

El proceso de creación de catálogos de máquinas y de incorporación de máquinas Linux es similar al proceso habitual de VDA para Windows. Para ver una descripción detallada sobre cómo completar estas tareas, consulte Crear catálogos de máquinas y Administrar catálogos de máquinas.

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:
  • La opción SO multisesión para un modelo de entrega de escritorios compartidos alojados.
  • La opción SO de sesión única para un modelo de entrega de escritorios VDI dedicados.
• No mezcle máquinas con agentes VDA para Windows y Linux en el mismo catálogo.

Nota:

Las primeras versiones de Citrix Studio no admitían el concepto de “SO Linux”. Sin embargo, seleccionar la opción SO de servidor Windows o SO de servidor implica un modelo equivalente de entrega de escritorios compartidos alojados. Seleccionar la opción SO de escritorio Windows o SO de escritorio implica un modelo de entrega de un usuario por máquina.

Sugerencia:

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

Paso 12: Cree el grupo de entrega en Citrix Virtual Apps y Citrix Virtual Desktops

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. Para ver una descripción detallada sobre cómo completar estas tareas, consulte Crear grupos de entrega.

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

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

Importante:

Se admite la publicación de aplicaciones con Linux VDA 1.4 y versiones posteriores. Linux VDA no admite la entrega de escritorios ni aplicaciones a la misma máquina.

Para obtener información sobre cómo crear catálogos de máquinas y grupos de entrega, consulte Citrix Virtual Apps and Desktops 7 1912 LTSR.