Instalar Linux VDA en 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 información de configuración y la máquina Linux
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 el sistema de nombres de dominio (DNS)
- Inicie la herramienta YaST de interfaz gráfica.
- Seleccione System y, luego, Network Settings.
- Abra la ficha Hostname/DNS.
- Seleccione la opción no para Set Hostname via DHCP.
- Seleccione la opción Use Custom Policy para Modify DNS Configuration.
-
Modifique lo siguiente para que refleje su propia configuración de red:
- Static Hostname: Agregue el nombre de host 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.
-
Cambie esta línea del archivo
/etc/hosts
, de manera que incluya el FQDN y el nombre de host como las dos primeras entradas:127.0.0.1 <FQDN of the VDA> <hostname of the VDA> localhost
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.
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 (VM) 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.
Para SUSE 15.5:
- Inicie la herramienta YaST de interfaz gráfica.
- Seleccione Network Services y, a continuación, NTP Configuration.
- En la sección Start NTP Daemon, seleccione Now and on Boot.
- Seleccione Dynamic para Configuration Source.
- Agregue servidores NTP según sea necesario. Por regla general, el servicio NTP se aloja en el controlador de dominio de Active Directory.
-
Elimine o comente esta línea en /etc/chrony.conf si existe.
include /etc/chrony.d/*.conf
Después de modificar chrony.conf, reinicie el servicio
chronyd
.sudo systemctl restart chronyd.service <!--NeedCopy-->
Paso 1d: Instale paquetes dependientes de Linux VDA
El software Linux VDA para la distribución SUSE Linux Enterprise depende de los siguientes paquetes:
- OpenJDK 11
- Open Motif Runtime Environment 2.3.1 o una versión posterior
- Cups 1.6.0 o una versión posterior
- ImageMagick 6.8 o una versión posterior
Agregar repositorios
Puede obtener la mayoría de los paquetes necesarios, excepto ImageMagick, de los repositorios oficiales. Para obtener los paquetes de ImageMagick, habilite el repositorio sle-module-desktop-applications
mediante YaST o este comando:
SUSEConnect -p sle-module-desktop-applications/<version number>/x86_64
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 11
Linux VDA requiere la presencia de OpenJDK 11.
Para instalar OpenJDK 11, ejecute el siguiente comando:
sudo zypper install java-11-openjdk
<!--NeedCopy-->
Instalar y especificar la base de datos que se utilizará
Nota:
Se recomienda usar SQLite solo para el modo VDI y PostgreSQL para un modelo de entrega de escritorios compartidos alojados.
Para Easy Install y MCS, puede especificar el uso de SQLite o PostgreSQL sin tener que instalarlos manualmente. A menos que se especifique lo contrario mediante /etc/xdl/db.conf, Linux VDA usa PostgreSQL de forma predeterminada.
Para las instalaciones manuales, debe instalar SQLite, PostgreSQL o ambos de forma manual. Si instala tanto SQLite como PostgreSQL, puede especificar cuál quiere usar modificando /etc/xdl/db.conf después de instalar el paquete Linux VDA.
En esta sección se describe cómo instalar PostgreSQL y SQLite y cómo especificar el uso de uno u otro.
Instalar PostgreSQL
Para instalar Postgresql
, ejecute estos comandos:
sudo zypper install postgresql-server
sudo zypper install postgresql-jdbc
<!--NeedCopy-->
Ejecute estos comandos para iniciar PostgreSQL al iniciar la máquina o inmediatamente, respectivamente:
sudo systemctl enable postgresql
sudo systemctl restart postgresql
<!--NeedCopy-->
Instalar SQLite
Para SUSE, ejecute este comando para instalar SQLite:
sudo zypper install sqlite3
<!--NeedCopy-->
Especificar la base de datos que se utilizará
Si instala tanto SQLite como PostgreSQL, puede especificar cuál quiere usar modificando /etc/xdl/db.conf después de instalar el paquete Linux VDA.
- Ejecute /opt/Citrix/VDA/sbin/ctxcleanup.sh. Omita este paso si se trata de una instalación nueva.
- Modifique /etc/xdl/db.conf para especificar la base de datos que se utilizará.
- Ejecute ctxsetup.sh.
Nota:
También puede usar /etc/xdl/db.conf para configurar el número de puerto de PostgreSQL.
Paso 2: Prepare el hipervisor
Se necesitan algunos cambios cuando se ejecuta Linux VDA como una máquina virtual en un hipervisor admitido. Haga estos cambios en función de la plataforma de hipervisor que se use. No se requieren cambios si se está ejecutando la máquina Linux sin sistema operativo.
Corregir la sincronización horaria en XenServer (anteriormente, Citrix Hypervisor)
Si está habilitada la funcionalidad de sincronización horaria de XenServer, se darán problemas en las máquinas virtuales Linux paravirtualizadas tanto en NTP como en XenServer. Ambos intentan gestionar 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.
Si se ejecuta un kernel Linux paravirtualizado con XenServer VM 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:
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:
- Abra la consola del Administrador de Hyper-V.
- Para ver la configuración de una máquina virtual Linux, seleccione Integration Services.
- Compruebe que Time synchronization está seleccionado.
Nota:
Este método difiere de VMware y XenServer (antes, Citrix Hypervisor), 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 la función de sincronización horaria de VMware está habilitada en cada VM de Linux paravirtualizada, hay problemas con el protocolo NTP y el hipervisor. Ambos intentan sincronizar 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.
Si ejecuta un kernel Linux paravirtualizado con VMware Tools instalado:
- Abra vSphere Client.
- Modifique la configuración de la máquina virtual Linux.
- En el cuadro de diálogo Propiedades de la máquina virtual, abra la ficha Opciones.
- Seleccione VMware Tools.
- En el cuadro Advanced, desmarque la casilla Synchronize guest time with host.
Paso 3: Agregue la máquina virtual Linux al dominio de Windows
Hay estos métodos disponibles para agregar máquinas Linux al dominio de Active Directory (AD):
Siga las instrucciones en función del método elegido.
Nota:
Es posible que no se puedan iniciar sesiones cuando se usa el mismo nombre de usuario para la cuenta local en el Linux VDA y para 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:
-
Inicie YaST, seleccione Network Services y, a continuación, Windows Domain Membership
-
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 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.
-
Haga clic en OK. Si se le solicita que instale algunos paquetes, haga clic en Install.
-
Si se encuentra un controlador de dominio, se le pregunta si quiere unirse al dominio. Haga clic en Sí.
-
Cuando se le solicite, introduzca las credenciales de un usuario de dominio con permisos para agregar máquinas al dominio y haga clic en OK.
-
Reinicie los servicios manualmente o reinicie la máquina. Le recomendamos que reinicie la máquina:
su - reboot <!--NeedCopy-->
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 comprobar 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
Verifique 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.
Compruebe que el módulo PAM de Winbind esté configurado correctamente. Para hacerlo, 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.
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, 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:
- 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.
- Seleccione la ficha Unix Account.
- Active Unix-enabled.
- 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 los inicios de sesión del usuario de dominio mediante HDX y otros servicios como su, ssh o RDP, configure 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 permiso para unir máquinas al dominio de Active Directory. La variable domain-name es el nombre DNS del dominio; por ejemplo, ejemplo.com.
Reinicie la máquina Linux después de unirse al dominio.
Verificar la pertenencia al dominio
El Delivery Controller requiere que todas las máquinas VDA (VDA con Windows y 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
Verifique que Quest pueda autenticar a los usuarios del dominio mediante PAM. Para hacerlo, 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:
sudo adjoin -w -V -u user domain-name
<!--NeedCopy-->
El parámetro user es un usuario de dominio de Active Directory con permiso para unir máquinas 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:
sudo 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.
SSSD
Si utiliza SSSD en SUSE, 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 SUSE, siga estos pasos:
- Unirse al dominio y crear un keytab de host
- Configurar PAM para SSSD
- Configurar SSSD
- Habilitar SSSD
- Verificar la pertenencia al dominio
- Verificar la configuración de Kerberos
- Verificar la autenticación de usuario
Unirse al dominio y crear un keytab de host
SSSD no proporciona funciones de cliente de Active Directory para unirse al dominio y administrar el archivo de sistema keytab. En su lugar, puede usar el enfoque de Samba. Complete los siguientes pasos antes de configurar SSSD.
-
Detenga e inhabilite el demonio de caché para el servicio de nombres (NSCD).
sudo systemctl stop nscd sudo systemctl disable nscd <!--NeedCopy-->
-
Compruebe el nombre del host y la sincronización horaria de Chrony.
hostname hostname -f chronyc traking <!--NeedCopy-->
-
Instale o actualice los paquetes requeridos:
sudo zypper install samba-client sssd-ad <!--NeedCopy-->
-
Modifique el archivo
/etc/krb5.conf
como usuario root para permitir que la utilidad kinit se comunique con el dominio de destino. Agregue estas entradas bajo las secciones [libdefaults], [realms] y [domain_realm]:Nota:
Configure Kerberos en función de su infraestructura de AD. Estos parámetros están pensados para el modelo de bosque y dominio únicos.
[libdefaults] dns_canonicalize_hostname = false rdns = false default_realm = REALM forwardable = true [realms] REALM = { kdc = fqdn-of-domain-controller default_domain = realm admin_server = fqdn-of-domain-controller } [domain_realm] .realm = REALM <!--NeedCopy-->
realm es el nombre del territorio Kerberos, como ejemplo.com. REALM es el nombre del territorio Kerberos en mayúsculas, como EJEMPLO.COM.
-
Modifique
/etc/samba/smb.conf
como usuario root para permitir que la utilidad net se comunique con el dominio de destino. Agregue estas entradas bajo la sección [global]:[global] workgroup = domain client signing = yes client use spnego = yes kerberos method = secrets and keytab realm = REALM security = ADS <!--NeedCopy-->
domain es el nombre corto de NetBIOS de un dominio de Active Directory, como EJEMPLO.
-
Modifique las entradas passwd y group en el archivo /etc/nsswitch.conf para hacer referencia a SSSD al resolver usuarios y grupos.
passwd: compat sss group: compat sss <!--NeedCopy-->
-
Utilice el cliente Kerberos configurado para autenticarse en el dominio de destino como administrador.
kinit administrator <!--NeedCopy-->
-
Utilice la utilidad net para unir el sistema al dominio y generar un archivo keytab del sistema.
net ads join osname="SUSE Linux Enterprise Server" osVersion=15 -U administrator <!--NeedCopy-->
Configurar PAM para SSSD
Antes de configurar PAM para SSSD, instale o actualice los paquetes necesarios.
sudo zypper install sssd sssd-ad
<!--NeedCopy-->
Configure el módulo PAM para la autenticación de usuarios a través de SSSD y cree directorios de inicio para los inicios de sesión de usuario.
sudo pam-config --add --sss
sudo pam-config --add --mkhomedir
<!--NeedCopy-->
Configurar SSSD
-
Modifique el archivo
/etc/sssd/sssd.conf
como usuario root para permitir que el demonio SSSD se comunique con el dominio de destino. A continuación, se ofrece un ejemplo de configuración desssd.conf
(se pueden agregar opciones adicionales, según sea necesario):[sssd] config_file_version = 2 services = nss,pam domains = domain-dns-name [domain/domain-dns-name] id_provider = ad auth_provider = ad access_provider = ad ad_domain = domain-dns-name ad_server = fqdn-of-domain-controller ldap_id_mapping = true ldap_schema = ad # Kerberos settings krb5_ccachedir = /tmp krb5_ccname_template = FILE:%d/krb5cc_%U # Comment out if the users have the shell and home dir set on the AD side fallback_homedir = /home/%d/%u default_shell = /bin/bash # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM ad_gpo_access_control = permissive <!--NeedCopy-->
domain-dns-name es el nombre de dominio DNS, como example.com.
Nota:
ldap_id_mapping tiene el valor true, de forma que el propio SSSD se ocupa de asignar los SID de Windows a UID de Unix. De lo contrario, Active Directory debe poder proporcionar extensiones POSIX. ad_gpo_access_control está establecido en permissive para evitar un error de inicio de sesión no válido con las sesiones de Linux. Consulte las páginas man de
sssd.conf
ysssd-ad
. -
Establezca la pertenencia y los permisos de archivos en
sssd.conf
:sudo chmod 0600 /etc/sssd/sssd.conf <!--NeedCopy-->
Habilitar SSSD
Ejecute los siguientes comandos para habilitar e iniciar el demonio SSSD cuando se inicie el sistema:
sudo systemctl enable sssd
sudo systemctl start sssd
<!--NeedCopy-->
Verificar la pertenencia al dominio
-
Ejecute el comando
net ads
de Samba para comprobar 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
Verifique 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
SSSD no proporciona una herramienta de línea de comandos para probar la autenticación directamente con el demonio, y solo se puede hacer mediante PAM.
Para comprobar que el módulo SSSD 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
klist
exit
<!--NeedCopy-->
Compruebe que los tíquets de Kerberos devueltos por el comando klist
son correctos para ese usuario y no han caducado.
Como usuario root, compruebe que se ha creado el archivo de caché de tíquets correspondiente para el uid devuelto por el comando id -u
previo:
ls /tmp/krb5cc_uid
<!--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.
PBIS
Descargar el paquete PBIS requerido
Por ejemplo:
wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Convertir el script de instalación de PBIS en ejecutable
Por ejemplo:
chmod +x pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Ejecutar el script de instalación de PBIS
Por ejemplo:
sh pbis-open-9.1.0.551.linux.x86_64.rpm.sh
<!--NeedCopy-->
Unirse a un 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:
/opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
El parámetro user es un usuario de dominio con permisos para agregar máquinas al dominio de Active Directory. La variable domain-name es el nombre DNS del dominio; por ejemplo, ejemplo.com.
Nota: Para establecer Bash como el shell predeterminado, ejecute el comando /opt/pbis/bin/config LoginShellTemplate/bin/bash.
Verificar la pertenencia al dominio
El Delivery Controller requiere que todas las máquinas VDA (VDA con Windows y Linux) tengan un objeto de equipo en Active Directory
. Para comprobar si hay una máquina Linux unida a PBIS en el dominio:
/opt/pbis/bin/domainjoin-cli query
<!--NeedCopy-->
Si la máquina está unida a un dominio, este comando devuelve la información sobre el dominio de AD y la unidad organizativa a los que está unida actualmente. De lo contrario, solo aparece el nombre de host.
Verificar la autenticación de usuario
Verifique que PBIS pueda autenticar a los usuarios del dominio mediante PAM. Para hacerlo, inicie sesión en Linux VDA con una cuenta de usuario de dominio que no se haya utilizado antes.
ssh localhost -l domain\user
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-->
Salga de la sesión.
exit
<!--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
Antes de instalar Linux VDA, instale .NET correspondiente a su distribución de Linux:
- Instale .NET Runtime 8.0 en todas las distribuciones de Linux compatibles, excepto RHEL 7.9 y Amazon Linux 2.
- Para RHEL 7.9 y Amazon Linux 2, siga realizando la instalación de .NET Runtime 6.0.
Si su distribución de Linux contiene la versión de .NET que necesita, instálela desde el feed integrado. De otro modo, instale .NET desde la sección de paquetes de Microsoft. Para obtener más información, consulte https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.
Después de instalar .NET, ejecute el comando which dotnet para encontrar su ruta de runtime.
En función del resultado del comando, establezca la ruta binaria de .NET Runtime. 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 adecuada de Citrix Virtual Apps and Desktops.
-
Expanda Componentes para buscar Linux VDA. Por ejemplo:
-
Haga clic en el enlace de Linux VDA para acceder a las descargas de Linux VDA.
-
Descargue el paquete de Linux VDA que coincida con su distribución de Linux.
-
Descargue la clave pública GPG que puede usar para verificar la integridad del paquete de Linux VDA. Por ejemplo:
Para verificar la integridad del paquete de Linux VDA mediante la clave pública, ejecute estos comandos para importar la clave pública a la base de datos RPM y comprobar la integridad del paquete:
rpmkeys --import <path to the public key> rpm --checksig --verbose <path to the Linux VDA package> <!--NeedCopy-->
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.
-
Detenga los servicios de Linux VDA:
sudo systemctl stop ctxvda sudo systemctl stop ctxhdx <!--NeedCopy-->
Nota:
Antes de detener los servicios ctxvda y ctxhdx, ejecute el comando systemctl stop ctxmonitord 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.
-
Desinstale el paquete:
sudo rpm -e XenDesktopVDA <!--NeedCopy-->
Importante:
Se admite la actualización desde las dos últimas versiones.
Nota:
Puede encontrar los componentes instalados 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:
sudo zypper install XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
Instale el software de Linux VDA mediante el administrador de paquetes RPM:
sudo rpm -i XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
Paso 6c: Actualice la versión de Linux VDA (optativo)
Linux VDA admite las actualizaciones desde la versión más reciente. Por ejemplo, puede actualizar Linux VDA de la versión 2308 a 2311 y de 1912 LTSR a 2203 LTSR.
Nota:
La actualización de una instalación existente sobrescribe los archivos de configuración en /etc/xdl. Antes de iniciar una actualización, haga copia de seguridad de los archivos.
sudo rpm -U XenDesktopVDA-<version>.sle15_x.x86_64.rpm
<!--NeedCopy-->
Lista de dependencias de RPM para SUSE 15:
java-11-openjdk >= 11
ImageMagick >= 7.0
dbus-1 >= 1.12.2
dbus-1-x11 >= 1.12.2
xorg-x11 >= 7.6_1
libXpm4 >= 3.5.12
libXrandr2 >= 1.5.1
libXtst6 >= 1.2.3
pam >= 1.3.0
bash >= 4.4
findutils >= 4.6
gawk >= 4.2
sed >= 4.4
cups >= 2.2
cups-filters >= 1.25
libxml2-2 >= 2.9
libmspack0 >= 0.6
ibus >= 1.5
libtcmalloc4 >= 2.5
libcap-progs >= 2.26
mozilla-nss-tools >= 3.53.1
libpython3_6m1_0 >= 3.6~
libQt5Widgets5 >= 5.12
libqrencode4 >= 4.0.0
libImlib2-1 >= 1.4.10
<!--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:
Para instalar y configurar los controladores de VM invitada de NVIDIA GRID, siga estos pasos generales:
- Asegúrese de que la máquina virtual invitada esté apagada.
- En el panel de control del hipervisor, asigne una GPU a la VM.
- Inicie la VM.
- Instale el controlador de VM invitada en la VM.
Paso 8: Configure Linux VDA
Nota:
Antes de configurar el entorno en tiempo de ejecución, asegúrese de que la configuración regional en_US.UTF-8 esté instalada en su sistema operativo. Si la configuración regional no está disponible en su sistema operativo, ejecute el comando sudo locale-gen en_US.UTF-8. Para Debian, quite la marca de comentario de la línea # en_US.UTF-8 UTF-8 para modificar el archivo /etc/locale.gen y, a continuación, ejecute el comando sudo locale-gen.
Después de instalar el paquete, debe configurar Linux VDA. Para ello, ejecute el script ctxsetup.sh
. Antes de que el script realice cambios, 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_NON_DOMAIN_JOINED=’y|n’: indica si se debe unir la máquina a un dominio. El valor predeterminado es ‘n’. Para escenarios unidos a un dominio, configúralo en ‘n’.
-
CTX_XDL_AD_INTEGRATION=’winbind|sssd|centrify|pbis|quest’: 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.
-
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 nombre FQDN o CNAME.
-
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, establézcalo en ‘y’.
-
CTX_XDL_HDX_3D_PRO =’y|n’: Linux VDA es compatible con HDX 3D Pro, un conjunto de tecnologías para la aceleración de la GPU que se diseñó 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_START_SERVICE=’y|n’: Determina si los servicios de Linux VDA se inician cuando se completa la configuración.
-
CTX_XDL_REGISTER_SERVICE=’y|n’: Los servicios de Linux Virtual Desktop se inician después del arranque de la máquina.
-
CTX_XDL_ADD_FIREWALL_RULES=’y|n’: Los servicios de Linux VDA 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 de Linux Virtual Desktop.
-
CTX_XDL_DESKTOP_ENVIRONMENT=gnome/gnome-classic/mate/’<none>‘: Especifica el entorno de escritorio GNOME, GNOME Classic o MATE que se va a utilizar en las sesiones. Si lo establece en “<none>“, se usa el escritorio predeterminado configurado en el VDA.
También puede cambiar entre entornos de escritorio ejecutando comandos o utilizando la bandeja del sistema. Para obtener más información, consulte Comandos para cambiar de escritorio y Bandeja del sistema.
-
CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime: La ruta de instalación de .NET para garantizar compatibilidad con el nuevo servicio de agente intermediario (ctxvda). La ruta predeterminada es “/usr/bin”.
-
CTX_XDL_VDA_PORT=port-number : Linux VDA se comunica con los Delivery Controllers a través de un puerto TCP/IP.
-
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. Si no es necesario, establézcalo en ‘<none>‘.
-
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 los puertos de LDAP. Por ejemplo, ad1.miempresa.com:389 ad2.miempresa.com:3268 ad3.miempresa.com:3268. Para habilitar consultas LDAP más rápidas en bosques de Active Directory, habilite Catálogo global en un controlador de dominio y especifique 3268 como número de puerto LDAP correspondiente. 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). Si no es necesario, establézcalo en ‘<none>‘.
-
CTX_XDL_SUPPORT_DDC_AS_CNAME=’y|n’: Linux VDA permite especificar un nombre de Delivery Controller mediante un registro CNAME de DNS.
Establezca la variable de entorno y ejecute el script de configuración:
export CTX_XDL_NON_DOMAIN_JOINED='n'
export CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest
export CTX_XDL_DDC_LIST='<list-ddc-fqdns>'
export CTX_XDL_VDI_MODE='y|n'
export CTX_XDL_HDX_3D_PRO='y|n'
export CTX_XDL_START_SERVICE='y|n'
export CTX_XDL_REGISTER_SERVICE='y|n'
export CTX_XDL_ADD_FIREWALL_RULES='y|n'
export CTX_XDL_DESKTOP_ENVIRONMENT= gnome|gnome-classic|mate|'<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>'
export CTX_XDL_VDA_PORT='<port-number>'
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_SUPPORT_DDC_AS_CNAME='y|n'
sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--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_NON_DOMAIN_JOINED='n' \
CTX_XDL_AD_INTEGRATION=winbind|centrify|sssd|pbis|quest \
CTX_XDL_DDC_LIST='<list-ddc-fqdns>' \
CTX_XDL_VDI_MODE='y|n' \
CTX_XDL_HDX_3D_PRO='y|n' \
CTX_XDL_START_SERVICE='y|n' \
CTX_XDL_REGISTER_SERVICE='y|n' \
CTX_XDL_ADD_FIREWALL_RULES='y|n' \
CTX_XDL_DESKTOP_ENVIRONMENT= gnome|gnome-classic|mate|'<none>' \
CTX_XDL_DOTNET_RUNTIME_PATH='<path-to-install-dotnet-runtime>' \
CTX_XDL_VDA_PORT='<port-number>' \
CTX_XDL_SITE_NAME='<dns-site-name>'|'<none>' \
CTX_XDL_LDAP_LIST='<list-ldap-servers>'|'<none>' \
CTX_XDL_SEARCH_BASE='<search-base-set>'|'<none>' \
CTX_XDL_SUPPORT_DDC_AS_CNAME='y|n' \
/opt/Citrix/VDA/sbin/ctxsetup.sh --silent
<!--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
Ejecute sudo /opt/Citrix/VDA/bin/xdping
para comprobar la presencia de problemas de configuración comunes en un entorno Linux VDA. Para obtener más información, consulte XDPing.
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 systemctl start ctxhdx
sudo systemctl start ctxvda
<!--NeedCopy-->
Detener Linux VDA:
Para detener los servicios de Linux VDA:
sudo systemctl stop ctxvda
sudo systemctl stop ctxhdx
<!--NeedCopy-->
Nota:
Antes de detener los servicios ctxvda y ctxhdx, ejecute el comando systemctl stop ctxmonitord 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 systemctl stop ctxvda
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda
<!--NeedCopy-->
Comprobar el estado de Linux VDA:
Para comprobar el estado de ejecución de los servicios de Linux VDA:
sudo systemctl status ctxvda
sudo systemctl status ctxhdx
<!--NeedCopy-->
Paso 11: Cree catálogos de máquinas
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 grupos 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. 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 de Linux VDA.
- 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 2402 LTSR.
En este artículo
- Paso 1: Prepare la información de configuración y la máquina Linux
- Paso 2: Prepare el hipervisor
- Paso 3: Agregue la máquina virtual Linux al dominio de Windows
- Paso 4: Instale .NET
- Paso 5: Descargue el paquete de Linux VDA
- Paso 6: Instale Linux VDA
- Paso 7: Instale controladores NVIDIA GRID
- Paso 8: Configure Linux VDA
- Paso 9: Ejecute XDPing
- Paso 10: Ejecute Linux VDA
- Paso 11: Cree catálogos de máquinas
- Paso 12: Cree grupos de entrega