Instalar Linux Virtual Delivery Agent para RHEL o CentOS

Puede elegir entre seguir los pasos de este artículo para la instalación manual o utilizar Easy Install para la instalación y configuración automáticas. Easy Install ahorra tiempo y trabajo y es menos propenso a errores que la instalación manual.

Nota

Use Easy Install solo para instalaciones nuevas. No utilice Easy Install para actualizar una instalación existente.

Paso 1: Prepare RHEL 7/CentOS 7 o RHEL 6/CentOS 6 para la instalación del VDA

Paso 1a: Verifique la configuración de red

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

Paso 1b: Establezca el nombre de host

Nota:

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

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

HOSTNAME=nombre del host

Paso 1c: Asigne una dirección de bucle invertido al nombre de host

Nota:

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

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

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

Por ejemplo:

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

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

Consejo:

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.

Paso 1d: Compruebe 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 de la máquina.

Paso 1e: Compruebe 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 1f: Configure la sincronización horaria

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 este motivo, se recomienda sincronizar la hora con un servicio remoto de sincronización horaria.

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

Configurar el servicio NTP (solo RHEL 6/CentOS 6)

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

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst
<!--NeedCopy-->

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

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

Guarde los cambios y reinicie el demonio de NTP:

sudo /sbin/service ntpd restart
<!--NeedCopy-->

Configurar el servicio Chrony (solo RHEL 7/CentOS 7)

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

server peer1-fqdn-or-ip-address iburst

server peer2-fqdn-or-ip-address iburst
<!--NeedCopy-->

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

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

Guarde los cambios y reinicie el demonio de Chrony:

sudo /sbin/service chronyd restart
<!--NeedCopy-->

Paso 1g: Instale OpenJDK

Linux VDA depende de OpenJDK. Por regla general, el entorno en tiempo de ejecución se instala durante la instalación del sistema operativo.

Confirme la versión correcta:

• RHEL 7/CentOS 7:

sudo yum info java-1.8.0-openjdk
<!--NeedCopy-->

• RHEL 6/CentOS 6:

sudo yum info java-1.7.0-openjdk
<!--NeedCopy-->

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

• RHEL 7/CentOS 7:

sudo yum -y update java-1.8.0-openjdk
<!--NeedCopy-->

• RHEL 6/CentOS 6:

sudo yum -y update java-1.7.0-openjdk
<!--NeedCopy-->

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

export JAVA\_HOME=/usr/lib/jvm/java

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

java -version
<!--NeedCopy-->

Tip:

Para evitar problemas, compruebe que solo ha instalado OpenJDK 1.7.0 o 1.8.0 en el caso de RHEL 6/CentOS 6, o solo OpenJDK 1.8.0 en el caso de RHEL 7/CentOS 7. Quite todas las demás versiones de Java que haya en su sistema.

Paso 1h: Instale PostgreSQL

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

Instale los siguientes paquetes:

sudo yum -y install postgresql-server

sudo yum -y install postgresql-jdbc
<!--NeedCopy-->

El siguiente paso posterior a la instalación es necesario para inicializar la base de datos y para que el servicio se inicie en el inicio de la máquina. Los archivos de base de datos se crean en /var/lib/pgsql/data. El comando difiere de PostgreSQL 8 a PostgreSQL 9:

• Solo RHEL 7: PostgreSQL 9

sudo postgresql-setup initdb
<!--NeedCopy-->

• Solo RHEL 6: PostgreSQL 8

sudo /sbin/service postgresql initdb
<!--NeedCopy-->

Paso 1i: Inicie PostgreSQL

Inicie el servicio al arrancar la máquina e inicie el servicio inmediatamente:

• Solo RHEL 7: PostgreSQL 9

sudo systemctl enable postgresql

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

• Solo RHEL 6: PostgreSQL 8

sudo /sbin/chkconfig postgresql on

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

Compruebe la versión de PostgreSQL con:

psql --version
<!--NeedCopy-->

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

sudo -u postgres psql -c 'show data_directory'
<!--NeedCopy-->

Importante:

En esta versión, se ha agregado una dependencia nueva para gperftools-libs. Esta dependencia no existe en el repositorio original. Agregue un repositorio nuevo mediante el comando sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm.
Solo afecta a RHEL 6/CentOS 6. Ejecute el comando antes de instalar el paquete de Linux VDA.

Paso 2: Prepare 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 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 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 XenServer Tools instalado, puede comprobar si la función de sincronización horaria de XenServer 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:

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

Corregir 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 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
• Servicio de autenticación Quest
• Centrify DirectControl
• SSSD

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

Instale o actualice los paquetes requeridos:

sudo yum -y install samba-winbind samba-winbind-clients krb5-workstation authconfig oddjob-mkhomedir
<!--NeedCopy-->

Habilitar el demonio de Winbind para que se inicie a la misma vez que la máquina

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

sudo /sbin/chkconfig winbind on
<!--NeedCopy-->

Configurar la autenticación de Winbind

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

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

Donde REALM es el nombre del territorio Kerberos en mayúsculas y domain es el nombre NetBIOS del dominio.

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

--enablekrb5kdcdns --enablekrb5realmdns

Ignore los errores que devuelva el comando authconfig que indican que el servicio winbind no se puede iniciar. Estos errores ocurren cuando authconfig intenta iniciar el servicio winbind cuando la máquina aún no está unida al dominio.

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

kerberos method = secrets and keytab
winbind refresh tickets = true

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

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 equipos al dominio:

sudo net ads join REALM -U user
<!--NeedCopy-->

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

Configurar PAM para Winbind

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

krb5_auth = yes
krb5_ccache_type = FILE
mkhomedir = yes

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

sudo /sbin/service winbind restart
<!--NeedCopy-->

Consejo:

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

Abra /etc/krb5.conf y modifique el siguiente parámetro en la sección [libdefaults], cambiando el tipo KEYRING por FILE:

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 del sistema keytab 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 verificar que el módulo Winbind PAM está configurado correctamente, use una cuenta de usuario de dominio para iniciar sesión en Linux VDA. La cuenta de usuario de dominio no se ha utilizado anteriormente.

ssh localhost -l domain\username

id -u
<!--NeedCopy-->

Compruebe que los vales que se encuentran en la memoria caché de credenciales de Kerberos 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 4: Instale Linux VDA después de la verificación de unión al dominio.

Servicio de autenticación Quest

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

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

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

Lo más conveniente para solucionar este problema es inhabilitar SELinux. Como usuario root, modifique /etc/selinux/config y cambie el parámetro SELinux:

SELINUX=permissive

Este cambio requiere un reinicio de la máquina:

reboot
<!--NeedCopy-->

Importante:

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

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 verificar que Quest pueda autenticar usuarios de dominio a través de PAM, use una cuenta de usuario de dominio para iniciar sesión en Linux VDA. La cuenta de usuario de dominio no se ha utilizado anteriormente.

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 vales 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 4: 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 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
<!--NeedCopy-->

Pruebe la conectividad a los distintos servicios de Active Directory y Kerberos: Continúe con el Paso 4: Instale Linux VDA después de la verificación de unión al dominio.

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

SSSD

Si utiliza SSSD, siga las instrucciones de esta sección. Esta sección contiene instrucciones para unir una máquina Linux VDA a un dominio Windows, y ofrece instrucciones para configurar la autenticación de Kerberos.

Para configurar SSSD en RHEL y CentOS, lleve a cabo lo siguiente:

1. Unirse al dominio y crear un keytab de host con Samba
2. Configurar SSSD
3. Configurar NSS/PAM
4. Verificar la configuración de Kerberos
5. Verificar la autenticación de usuario

Software requerido

El proveedor de Active Directory se introdujo por primera vez con SSSD 1.9.0. Si usa una versión anterior, siga las instrucciones proporcionadas en Configurar el proveedor de LDAP con Active Directory.

Se han probado y verificado los siguientes entornos con las instrucciones de este artículo:

• RHEL 7.3 o versiones posteriores/CentOS 7.3 o versiones posteriores
• Linux VDA versión 1.3 o posterior

Unirse al dominio y crear un keytab de host con Samba

SSSD no proporciona funciones de cliente de Active Directory para unirse al dominio y administrar el archivo de sistema keytab. Puede usar adcli, realmd, Winbind o Samba en su lugar.

En esta sección, se describe solo el enfoque de Samba. Para realmd, consulte la documentación de RHEL o CentOS. Debe seguir estos pasos para configurar SSSD.

En el cliente Linux, con archivos correctamente configurados:

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

Configure la máquina para la autenticación Kerberos y Samba:

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

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

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

--enablekrb5kdcdns --enablekrb5realmdns

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

kerberos method = secrets and keytab

Únase al dominio de Windows. Para ello, 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 equipos al dominio:

sudo net ads join REALM -U user
<!--NeedCopy-->

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

Configurar SSSD

Configurar SSSD consta de los siguientes pasos:

• Instale el paquete sssd-ad en Linux VDA.
• Realice cambios de configuración en varios archivos (por ejemplo: sssd.conf).
• Inicie el servicio sssd.

A continuación, se ofrece un ejemplo de configuración de sssd.conf (se pueden agregar opciones adicionales, según sea necesario):

[sssd]
config_file_version = 2
domains = ad.example.com
services = nss, pam

[domain/ad.example.com]
# Uncomment if you need offline logins
# cache_credentials = true

id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = ad

# Should be specified as the lower-case version of the long version of the Active Directory domain.
ad_domain = ad.example.com

# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U

# Uncomment if service discovery is not working
# ad_server = server.ad.example.com

# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
<!--NeedCopy-->

Reemplace ad.domain.com y server.ad.example.com por los valores correspondientes. Para obtener más información, consulte sssd-ad(5) - Linux man page.

Establezca la pertenencia y los permisos de archivos en sssd.conf:

chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf

Configurar NSS/PAM

RHEL/CentOS:

Use authconfig para habilitar SSSD. Instale oddjob-mkhomedir para que la creación del directorio de inicio sea compatible con SELinux:

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

sudo service sssd start

sudo chkconfig sssd on
<!--NeedCopy-->

Verificar la configuración de Kerberos

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

Verificar la autenticación de usuario

Use el comando getent para saber si se admite el formato del inicio de sesión y si funciona NSS:

sudo getent passwd DOMAIN\username
<!--NeedCopy-->

El parámetro DOMAIN indica la versión corta del nombre de dominio. Si se necesita otro formato de inicio de sesión, compruébelo primero con el comando getent.

Los formatos de inicio de sesión admitidos son:

• Nombre de inicio de sesión de nivel inferior: DOMAIN\username
• UPN: username@domain.com
• Formato del sufijo NetBIOS: username@DOMAIN

Para verificar que el módulo SSSD PAM está configurado correctamente, use una cuenta de usuario de dominio para iniciar sesión en Linux VDA. La cuenta de usuario de dominio no se ha utilizado anteriormente.

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

ls /tmp/krb5cc_{uid}
<!--NeedCopy-->

Compruebe que los tíquets que se encuentran en la memoria caché de credenciales de Kerberos del usuario son válidos y no han caducado. Continúe con el Paso 4: Instale Linux VDA después de la verificación de unión al dominio.

klist
<!--NeedCopy-->

Paso 4: Instale Linux VDA

Paso 4a: Desinstale la versión anterior

Si ya ha instalado una versión anterior de Linux VDA, 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-->
   

2. Desinstale el paquete:

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

Nota:

Se admite la actualización de las dos versiones anteriores.

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/. En cambio, 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.

Paso 4b: Descargue el paquete de Linux VDA

Vaya a la página web de Citrix y descargue el paquete de Linux VDA adecuado según su distribución de Linux.

Paso 4c: Instale Linux VDA

Instale el software de Linux VDA mediante Yum:

Para RHEL 7/CentOS 7:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.9:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.6/CentOS 6.6:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

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

Para RHEL 7/CentOS 7:

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.9:

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.6/CentOS 6.6:

sudo rpm -i XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Lista de dependencias RPM para RHEL 7:

postgresql-server >= 9.2

postgresql-jdbc >= 9.2

java-1.8.0-openjdk >= 1.8.0

ImageMagick >= 6.7.8.9

firewalld >= 0.3.9

policycoreutils-python >= 2.0.83

dbus >= 1.6.12

dbus-x11 >= 1.6.12

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.3.2

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

motif >= 2.3.4

pam >= 1.1.8

util-linux >= 2.23.2

bash >= 4.2

findutils >= 4.5

gawk >= 4.0

sed >= 4.2

cups >= 1.6.0

foomatic-filters >= 4.0.9

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.9

python-requests >= 2.6.0

gperftools-libs >= 2.4

xorg-x11-server-Xorg >= 1.17

xorg-x11-server-Xorg < 1.18

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->

Lista de dependencias RPM para RHEL 6.9:

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.0

ImageMagick >= 6.5.4.7

GConf2 >= 2.28.0

system-config-firewall-base >= 1.2.27

policycoreutils-python >= 2.0.83

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.0.9

ConsoleKit >= 0.4.1

dbus >= 1.2.24

dbus-x11 >= 1.2.24

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

openmotif >= 2.3.3

pam >= 1.1.1

util-linux-ng >= 2.17.2

bash >= 4.1

findutils >= 4.4

gawk >= 3.1

sed >= 4.2

cups >= 1.4.0

foomatic >= 4.0.0

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.7

python-requests >= 2.6.0

gperftools-libs >= 2.0

xorg-x11-server-Xorg >= 1.17

xorg-x11-server-Xorg < 1.18

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->

Lista de dependencias RPM para RHEL 6.6/CentOS 6.6:

postgresql-jdbc >= 8.4

postgresql-server >= 8.4

java-1.7.0-openjdk >= 1.7.0

ImageMagick >= 6.5.4.7

GConf2 >= 2.28.0

system-config-firewall-base >= 1.2.27

policycoreutils-python >= 2.0.83

xorg-x11-server-utils >= 7.7

xorg-x11-xinit >= 1.0.9

ConsoleKit >= 0.4.1

dbus >= 1.2.24

dbus-x11 >= 1.2.24

libXpm >= 3.5.10

libXrandr >= 1.4.1

libXtst >= 1.2.2

openmotif >= 2.3.3

pam >= 1.1.1

util-linux-ng >= 2.17.2

bash >= 4.1

findutils >= 4.4

gawk >= 3.1

sed >= 4.2

cups >= 1.4.0

foomatic >= 4.0.0

openldap >= 2.4

cyrus-sasl >= 2.1

cyrus-sasl-gssapi >= 2.1

libxml2 >= 2.7

python-requests >= 2.6.0

gperftools-libs >= 2.0

xorg-x11-server-Xorg >= 1.15

xorg-x11-server-Xorg < 1.16

rpmlib(FileDigests) <= 4.6.0-1

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

rpmlib(PayloadIsXz) <= 5.2-1
<!--NeedCopy-->

Paso 4d: Actualice la versión de Linux VDA (optativo)

Puede actualizar el software de Linux VDA desde las versiones 7.14 y 7.13 mediante Yum:

Para RHEL 7/CentOS 7:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.9:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.6/CentOS 6.6:

sudo yum install -y XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Actualice el software de Linux VDA desde el administrador de paquetes RPM:

Para RHEL 7/CentOS 7:

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el7_3.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.9:

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_9.x86_64.rpm
<!--NeedCopy-->

Para RHEL 6.6/CentOS 6.6:

sudo rpm -U XenDesktopVDA-7.15.0.404-1.el6_6.x86_64.rpm
<!--NeedCopy-->

Importante:

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

Paso 5: Instale controladores NVIDIA GRID

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

Configure las siguientes opciones:

1. Citrix XenServer
2. VMware ESX

Siga las instrucciones para el hipervisor que haya elegido.

Citrix XenServer:

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

VMware ESX:

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

Máquinas VDA:

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

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

Ejecute los siguientes comandos para preparar la máquina para los controladores NVIDIA GRID:

yum install gcc

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

systemctl set-default multi-user.target
<!--NeedCopy-->

Siga los pasos indicados en el documento de Red Hat Enterprise Linux para instalar el controlador NVIDIA GRID.

Nota:

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

Importante:

Una vez habilitado GPU PassThrough, ya no se puede acceder a la máquina virtual Linux a través de XenCenter. Use SSH para conectarse.

Establezca la configuración correcta para la tarjeta:

etc/X11/ctx-nvidia.sh

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

Paso 6: 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 – Servicio de autenticación Quest
  • 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, Virtual Delivery Agent 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_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-name

export CTX_XDL_LDAP_LIST=list-ldap-servers

export CTX_XDL_SEARCH_BASE=search-base-set

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. Citrix 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_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 /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

Para quitar los cambios de configuración:

sudo /opt/Citrix/VDA/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 registros de configuración /tmp/xdl.configure.log.

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

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

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 8: Cree el catálogo de máquinas en XenApp o XenDesktop

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 de SO de servidor para un modelo de entrega de escritorios compartidos alojados.
  • La opción de SO de escritorio 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 Linux VDA no admiten MCS, elija el método de implementación PVS u Otro servicio o tecnología (imágenes existentes).
• No mezcle máquinas con agentes VDA para Windows y Linux en el mismo catálogo.

Nota:

Las 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 9: Cree el grupo de entrega en XenApp o XenDesktop

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:

• Para el tipo de entrega, seleccione Escritorios o 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.

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.