Instalar Linux VDA en Ubuntu 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: Verifique la configuración de red
Compruebe que la red esté conectada y correctamente configurada. Por ejemplo, debe configurar el servidor DNS en el Linux VDA.
Si está utilizando un Ubuntu 18.04 Live Server, realice el siguiente cambio en el archivo de configuración /etc/cloud/cloud.cfg antes de establecer el nombre de host:
preserve_hostname: true
Paso 1b: Establezca el nombre de host
Para cerciorarse de 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
Paso 1c: Asigne una dirección de bucle invertido al nombre de host
Asegúrese de que el nombre de dominio DNS y el nombre de dominio completo (FQDN) de la máquina se notifican correctamente. Para eso, cambie la siguiente 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 hostname-fqdn hostname localhost
Por ejemplo:
127.0.0.1 vda01.example.com vda01 localhost
Quite las demás referencias a hostname-fqdn
o hostname
de otras entradas del archivo.
Nota:
Actualmente, Linux VDA no admite el truncamiento del nombre 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.
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.
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: Inhabilite el DNS de multidifusión
Con la configuración predeterminada, el DNS de multidifusión (mDNS) está habilitado, lo que puede dar lugar a resoluciones de nombres incoherentes.
Para inhabilitar mDNS, modifique /etc/nsswitch.conf y cambie la línea que contiene:
hosts: files mdns_minimal [NOTFOUND=return] dns
Para:
hosts: files dns
Paso 1f: 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 1g: Configure la sincronización del reloj (chrony)
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 este motivo, se recomienda sincronizar la hora con un servicio remoto de sincronización horaria.
Instale Chrony:
apt-get install chrony
<!--NeedCopy-->
Como usuario root, modifique /etc/chrony/chrony.conf y agregue una entrada de servidor para cada servidor horario remoto:
server peer1-fqdn-or-ip-address iburst
server peer2-fqdn-or-ip-address iburst
En una implementación típica, 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 las demás entradas server o pool de la lista, incluidas las entradas loopback IP address, localhost y public server *.pool.ntp.org.
Guarde los cambios y reinicie el demonio de Chrony:
sudo systemctl restart chrony
<!--NeedCopy-->
Paso 1h: Instale OpenJDK 11
Linux VDA requiere la presencia de OpenJDK 11.
En Ubuntu 20.04 y Ubuntu 18.04, instale OpenJDK 11 con:
sudo apt-get install -y openjdk-11-jdk
<!--NeedCopy-->
Paso 1i: Instale y especifique la base de datos que se utilizará
Como función experimental, puede utilizar SQLite además de PostgreSQL. También puede cambiar entre SQLite y PostgreSQL al modificar /etc/xdl/db.conf
después de instalar el paquete de Linux VDA. Para las instalaciones manuales, debe instalar SQLite y PostgreSQL manualmente antes de poder cambiar entre ellas.
En esta sección se describe cómo instalar las bases de datos PostgreSQL y SQLite y cómo especificar la base de datos que se utilizará.
Nota:
Le recomendamos utilizar SQLite solo para el modo VDI.
Instalar PostgreSQL
Ejecute estos comandos para instalar PostgreSQL:
sudo apt-get install -y postgresql
sudo apt-get install -y libpostgresql-jdbc-java
<!--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 Ubuntu, ejecute este comando para instalar SQLite:
sudo apt-get install -y sqlite3
<!--NeedCopy-->
Especificar la base de datos que se utilizará
Tras instalar SQLite, PostgreSQL o ambos, puede especificar una base de datos que utilizar al modificar /etc/xdl/db.conf
después de instalar el paquete de Linux VDA. Para ello, siga estos pasos:
- 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 1j: Instale Motif
sudo apt-get install -y libxm4
<!--NeedCopy-->
Paso 1k: Instale otros paquetes
Para Ubuntu 22.04:
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libsasl2-modules-gssapi-mit
sudo apt-get install -y libldap-2.5-0
sudo apt-get install -y krb5-user
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
Para Ubuntu 20.04, Ubuntu 18.04:
sudo apt-get install -y libsasl2-2
sudo apt-get install -y libsasl2-modules-gssapi-mit
sudo apt-get install -y libldap-2.4-2
sudo apt-get install -y krb5-user
sudo apt-get install -y libgtk2.0-0
<!--NeedCopy-->
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 Citrix Hypervisor
Cuando está habilitada la función de sincronización horaria de Citrix Hypervisor en cada VM de Linux paravirtualizada, hay problemas con NTP y Citrix Hypervisor. Ambos intentan gestionar el reloj del sistema. Para evitar la desincronización del reloj respecto a los demás servidores, compruebe que el reloj del sistema de cada invitado de Linux debe sincronizarse 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 Citrix VM Tools instalado, puede comprobar si la función de sincronización horaria de Citrix Hypervisor está presente y habilitada desde 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 utilizar la funcionalidad de sincronización horaria de Hyper-V para usar la hora del sistema operativo del host. Para cerciorarse de que el reloj del sistema no se desincroniza, 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 Citrix Hypervisor y VMware, donde se inhabilita la sincronización horaria del host para evitar conflictos con NTP. La sincronización horaria de Hyper-V puede coexistir y complementarse con la sincronización horaria de NTP.
Corregir la sincronización horaria en ESX y ESXi
Cuando 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, compruebe que el reloj del sistema de cada invitado de 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:
- 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:
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
Instalar o actualizar los paquetes requeridos
sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user
<!--NeedCopy-->
Habilitar el demonio Winbind para que se inicie a la vez que la máquina
El demonio de Winbind debe configurarse para iniciarse en el arranque:
sudo systemctl enable winbind
<!--NeedCopy-->
Nota:
Compruebe que el script
winbind
se encuentra en/etc/init.d
.
Configurar Kerberos
Abra /etc/krb5.conf como usuario root y configure los parámetros siguientes:
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]
default_realm =
REALM
dns_lookup_kdc = false
[realms]
REALM
= {
admin_server =
domain-controller-fqdn
kdc =
domain-controller-fqdn
}
[domain_realm]
domain-dns-name
=
REALM
.domain-dns-name
=
REALM
El parámetro domain-dns-name en este contexto es el nombre de dominio DNS, como ejemplo.com. REALM es el nombre del territorio Kerberos en mayúsculas, como EJEMPLO.COM.
Configurar la autenticación de Winbind
Debe configurar Windbind manualmente, ya que Ubuntu no tiene una herramienta como authconfig en RHEL y yast2 en SUSE.
Abra /etc/samba/smb.conf y configure los parámetros siguientes:
[global]
workgroup =
WORKGROUP
security = ADS
realm =
REALM
encrypt passwords = yes
idmap config *:range = 16777216-33554431
winbind trusted domains only = no
kerberos method = secrets and keytab
winbind refresh tickets = yes
template shell = /bin/bash
WORKGROUP es el primer campo de REALM, y REALM es el nombre del territorio Kerberos, en mayúsculas.
Configurar nsswitch
Abra /etc/nsswitch.conf y agregue winbind a las líneas siguientes:
passwd: compat winbind
group: compat 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 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.
Reiniciar winbind
sudo systemctl restart winbind
<!--NeedCopy-->
Configurar PAM para Winbind
Ejecute este comando y compruebe que las opciones Winbind NT/Active Directory authentication y Create home directory on login están seleccionadas:
sudo pam-auth-update
<!--NeedCopy-->
Sugerencia:
El demonio winbind permanece en ejecución solo si la máquina está unida a un dominio.
Verificar la pertenencia al dominio
El Delivery Controller requiere que todas las máquinas VDA, Windows o 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
Para verificar que Kerberos está configurado correctamente para su uso con el 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 comprobar que el módulo Winbind PAM está configurado correctamente, inicie sesión en Linux VDA con una cuenta de usuario de dominio que no se haya utilizado antes.
ssh localhost -l domain\username
id -u
<!--NeedCopy-->
Nota:
Para ejecutar correctamente un comando SSH, asegúrese de que SSH está habilitado y funciona correctamente.
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.
Sugerencia:
Si la autenticación de usuario se realizó correctamente pero no aparece su escritorio al iniciar sesión con una cuenta de dominio, reinicie la máquina e inténtelo de nuevo.
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:
- 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
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=disabled
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 estos 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 usuario es un usuario de dominio con permisos para unir equipos al dominio de Active Directory. La variable domain-name es el nombre DNS del dominio; por ejemplo, ejemplo.com.
Verificar la pertenencia al dominio
El Delivery Controller requiere que todas las máquinas VDA, Windows o Linux, tengan un objeto de equipo en Active Directory. Para comprobar si hay una máquina Linux unida a Quest en el dominio:
sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->
Si la máquina está unida a un dominio, este comando devuelve el nombre del dominio. En cambio, si la máquina no está unida a ningún dominio, aparece el siguiente error:
ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain
Verificar la autenticación de usuario
Para comprobar que Quest puede autenticar usuarios de dominio a través de PAM, inicie sesión en Linux VDA con una cuenta de usuario de dominio que no se haya utilizado antes.
ssh localhost -l domain\username
id -u
<!--NeedCopy-->
Compruebe que se ha creado el archivo de caché con las credenciales de Kerberos para el UID devuelto por el comando id -u:
ls /tmp/krb5cc_uid
<!--NeedCopy-->
Compruebe que los tíquets que se encuentran en la memoria caché de credenciales de Kerberos son válidos y no han caducado:
/opt/quest/bin/vastool klist
<!--NeedCopy-->
Salga de la sesión.
exit
<!--NeedCopy-->
Continúe con el Paso 6: Instale Linux VDA después de la verificación de unión al dominio.
Centrify DirectControl
Unirse al dominio de Windows
Con el Agente Centrify DirectControl instalado, una la máquina Linux al dominio de Active Directory mediante el comando adjoin de Centrify:
su –
adjoin -w -V -u user domain-name
<!--NeedCopy-->
El parámetro user es un usuario de dominio de Active Directory con permisos para unir equipos al dominio de Active Directory. El parámetro domain-name es el nombre del dominio al que se unirá la máquina Linux.
Verificar la pertenencia al dominio
El Delivery Controller requiere que todas las máquinas VDA, Windows o Linux, tengan un objeto de equipo en Active Directory. Para comprobar si hay una máquina Linux unida a Centrify en el dominio:
su –
adinfo
<!--NeedCopy-->
Verifique 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
Configurar Kerberos
Ejecute el siguiente comando para instalar Kerberos:
sudo apt-get install krb5-user
<!--NeedCopy-->
Para configurar Kerberos, abra /etc/krb5.conf como root y establezca los parámetros:
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]
default_realm =
REALM
dns_lookup_kdc = false
[realms]
REALM
= {
admin_server =
domain-controller-fqdn
kdc =
domain-controller-fqdn
}
[domain_realm]
domain-dns-name
=
REALM
.domain-dns-name
=
REALM
El parámetro domain-dns-name
en este contexto es el nombre de dominio DNS, como ejemplo.com. REALM es el nombre del territorio Kerberos en mayúsculas, como EJEMPLO.COM.
Unirse al dominio
SSSD debe estar configurado para usar Active Directory como su proveedor de identidades y Kerberos para la autenticación. 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 adcli, realmd o Samba.
Nota:
En esta sección, solo se proporciona información sobre adcli y Samba.
- Si utiliza adcli para unirse al dominio, complete los siguientes pasos:
-
Instale adcli.
sudo apt-get install adcli <!--NeedCopy-->
-
Únase al dominio con adcli.
Quite el antiguo archivos keytab de sistema y únase al dominio con:
su - rm -rf /etc/krb5.keytab adcli join domain-dns-name -U user -H hostname-fqdn <!--NeedCopy-->
El parámetro user es un usuario del dominio con permisos para agregar máquinas al dominio. El parámetro hostname-fqdn es el nombre de host en formato FQDN (nombre de dominio completo) de la máquina.
La opción -H es necesaria para que adcli genere SPN en este formato: host/hostname-fqdn@REALM, que es el requerido por Linux VDA.
-
Verifique la pertenencia al dominio.
Para máquinas con Ubuntu 22.04 y Ubuntu 20.04, ejecute el comando
adcli testjoin
para comprobar si las máquinas están unidas al dominio.Para una máquina con Ubuntu 18.04, ejecute el comando
sudo klist -ket
. La capacidad de la herramienta adcli es limitada. La herramienta no proporciona una forma de comprobar si una máquina se ha unido al dominio. La mejor opción es asegurarse de que se ha creado el archivo keytab del sistema. Compruebe que la fecha y hora para cada clave coinciden con el momento en que la máquina se unió al dominio.
- Si utiliza Samba para unirse al dominio, complete los siguientes pasos:
-
Instale el paquete.
sudo apt-get install samba krb5-user <!--NeedCopy-->
-
Configure Samba.
Abra /etc/samba/smb.conf y configure los parámetros siguientes:
[global]
workgroup =
WORKGROUP
security = ADS
realm =
REALM
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
WORKGROUP es el primer campo de REALM, y REALM es el nombre del territorio Kerberos, en mayúsculas.
-
Únase al dominio con Samba.
Para ello, se requiere que el controlador de dominio esté accesible y se necesita disponer de una cuenta de Windows 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
Instalar o actualizar los paquetes requeridos:
Instale los paquetes de configuración y SSSD requeridos si aún no están instalados:
sudo apt-get install sssd
<!--NeedCopy-->
Si los paquetes ya están instalados, se recomienda actualizarlos:
sudo apt-get install --only-upgrade sssd
<!--NeedCopy-->
Nota:
De forma predeterminada, el proceso de instalación en Ubuntu configura automáticamente nsswitch.conf y el módulo de PAM de inicio de sesión.
Configurar SSSD
Es necesario hacer los cambios en la configuración de SSSD antes de iniciar el demonio SSSD. En algunas versiones de SSSD, el archivo de configuración /etc/sssd/sssd.conf no se instala de forma predeterminada y se debe crear manualmente. Como usuario root, cree o abra el archivo /etc/sssd/sssd.conf y configure los siguientes parámetros:
[sssd]
services = nss, pam
config_file_version = 2
domains =
domain-dns-name
[domain/
domain-dns-name
]
id_provider = ad
access_provider = ad
auth_provider = krb5
krb5_realm =
REALM
# Set krb5_renewable_lifetime higher if TGT renew lifetime is longer than 14 days
krb5_renewable_lifetime = 14d
# Set krb5_renew_interval to lower value if TGT ticket lifetime is shorter than 2 hours
krb5_renew_interval = 1h
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# This ldap_id_mapping setting is also the default value
ldap_id_mapping = true
override_homedir = /home/%d/%u
default_shell = /bin/bash
ad_gpo_map_remote_interactive = +ctxhdx
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, el servidor de Active Directory debe ser capaz de proporcionar extensiones POSIX. El
ctxhdx
de servicio PAM se agrega a ad_gpo_map_remote_interactive.El parámetro domain-dns-name en este contexto es el nombre de dominio DNS, como ejemplo.com. REALM es el nombre del territorio Kerberos en mayúsculas, como EJEMPLO.COM. No es necesario configurar el nombre de dominio NetBIOS.
Para obtener información sobre estas opciones de configuración, consulte las páginas man de sssd.conf y
sssd-ad
.
El demonio SSSD requiere que el archivo de configuración tenga permisos de lectura de propietario solamente:
sudo chmod 0600 /etc/sssd/sssd.conf
<!--NeedCopy-->
Iniciar el demonio de SSSD
Ejecute los siguientes comandos para iniciar el demonio SSSD ahora y para permitir que el demonio se inicie al iniciar la máquina:
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
Configuración de PAM
Ejecute este comando y compruebe que las opciones SSS authentication y Create home directory on login están seleccionadas:
sudo pam-auth-update
<!--NeedCopy-->
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
.
-
Si utiliza adcli para verificar la pertenencia al dominio, ejecute el comando
sudo adcli info domain-dns-name
para mostrar la información del dominio. -
Si utiliza Samba para verificar la pertenencia al dominio, ejecute el comando
sudo net ads testjoin
para verificar que la máquina está unida a un dominio y el comandosudo net ads info
para verificar información adicional sobre el dominio y el objeto de equipo.
Verificar la configuración de Kerberos
Para verificar que Kerberos está configurado correctamente para su uso con el 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-->
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 en KDE o Gnome Display Manager. 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
sudo wget https://github.com/BeyondTrust/pbis-open/releases/download/9.1.0/pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
Convertir el script de instalación de PBIS en ejecutable
sudo chmod +x pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
Ejecutar el script de instalación de PBIS
sudo sh pbis-open-9.1.0.551.linux.x86_64.deb.sh
<!--NeedCopy-->
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 /opt/pbis/bin/domainjoin-cli join domain-name user
<!--NeedCopy-->
El parámetro user es un usuario de dominio con permisos para agregar equipos 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 sudo /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
Para comprobar que PBIS puede autenticar usuarios de dominio a través de PAM, inicie sesión en Linux VDA con una cuenta de usuario de dominio que no se haya utilizado antes.
sudo 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 Runtime 6.0
Antes de instalar Linux VDA, instale .NET Runtime 6.0 conforme a las instrucciones de https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-managers.
Después de instalar .NET Runtime 6.0, 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.
-
Haga clic en Componentes para descargar el paquete de Linux VDA que corresponda a su distribución de Linux y la clave pública GPG que puede usar para comprobar la integridad del paquete de Linux VDA.
Para verificar la integridad del paquete de Linux VDA mediante la clave pública, importe la clave pública a la base de datos DEB y ejecute estos comandos:
``` sudo apt-get install dpkg-sig gpg --import <path to the public key> dpkg-sig --verify <path to the Linux VDA package> <!--NeedCopy--> ```
Paso 6: Instale Linux VDA
Paso 6a: Instale Linux VDA
Instale el software de Linux VDA mediante el administrador de paquetes Debian:
Para Ubuntu 22.04:
sudo dpkg -i xendesktopvda_<version>.ubuntu22.04_amd64.deb
<!--NeedCopy-->
Para Ubuntu 20.04:
sudo dpkg -i xendesktopvda_<version>.ubuntu20.04_amd64.deb
<!--NeedCopy-->
Nota:
Para Ubuntu 20.04 en GCP, inhabilite RDNS. Para ello, agregue la línea rdns = false en [libdefaults] en /etc/krb5.conf.
Para Ubuntu 18.04:
sudo dpkg -i xendesktopvda_<version>.ubuntu18.04_amd64.deb
<!--NeedCopy-->
Lista de dependencias de Debian para Ubuntu 22.04:
openjdk-11-jdk >= 11
imagemagick >= 8:6.9.11
libgtkmm-3.0-1v5 >= 3.24.5
ufw >= 0.36
ubuntu-desktop >= 1.481
libxrandr2 >= 2:1.5.2
libxtst6 >= 2:1.2.3
libxm4 >= 2.3.8
util-linux >= 2.37
gtk3-nocsd >= 3
bash >= 5.1
findutils >= 4.8.0
sed >= 4.8
cups >= 2.4
libmspack0 >= 0.10
ibus >= 1.5
libgoogle-perftools4 >= 2.9~
libpython3.10 >= 3.10~
libsasl2-modules-gssapi-mit >= 2.1.~
libnss3-tools >= 2:3.68
libqt5widgets5 >= 5.15~
libqrencode4 >= 4.1.1
libimlib2 >= 1.7.4
<!--NeedCopy-->
Lista de dependencias de Debian para Ubuntu 20.04:
openjdk-11-jdk >= 11
imagemagick >= 8:6.9.10
libgtkmm-3.0-1v5 >= 3.24.2
ufw >= 0.36
ubuntu-desktop >= 1.450
libxrandr2 >= 2:1.5.2
libxtst6 >= 2:1.2.3
libxm4 >= 2.3.8
util-linux >= 2.34
gtk3-nocsd >= 3
bash >= 5.0
findutils >= 4.7.0
sed >= 4.7
cups >= 2.3
libmspack0 >= 0.10
ibus >= 1.5
libgoogle-perftools4 >= 2.7~
libpython3.8 >= 3.8~
libsasl2-modules-gssapi-mit >= 2.1.~
libnss3-tools >= 2:3.49
libqt5widgets5 >= 5.7~
libqrencode4 >= 4.0.0
libimlib2 >= 1.6.1
<!--NeedCopy-->
Lista de dependencias de Debian para Ubuntu 18.04:
openjdk-11-jdk >= 11
imagemagick >= 8:6.8.9.9
ufw >= 0.35
libgtkmm-3.0-1v5 >= 3.22.2
ubuntu-desktop >= 1.361
libxrandr2 >= 2:1.5.0
libxtst6 >= 2:1.2.2
libxm4 >= 2.3.4
util-linux >= 2.27.1
gtk3-nocsd >= 3
bash >= 4.3
findutils >= 4.6.0
sed >= 4.2.2
cups >= 2.1
libmspack0 >= 0.6
ibus >= 1.5
libsasl2-modules-gssapi-mit >= 2.1.~
libgoogle-perftools4 >= 2.4~
libpython3.6 >= 3.6~
libnss3-tools >= 2:3.35
libqt5widgets5 >= 5.7~
libqrencode3 >= 3.4.4
libimlib2 >= 1.4.10
<!--NeedCopy-->
Nota:
Para ver una matriz de las distribuciones de Linux y las versiones de Xorg que admite esta versión de Linux VDA, consulte los requisitos del sistema.
Paso 6b: Actualice la versión de Linux VDA (optativo)
Puede actualizar la versión de una instalación existente desde las dos versiones anteriores y desde una versión LTSR.
sudo dpkg -i <PATH>/<Linux VDA deb>
<!--NeedCopy-->
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.
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 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, las opciones necesarias para el script de instalación pueden especificarse con variables de entorno. Si están presentes todas las variables necesarias, el script no solicita al usuario ninguna otra información, lo que permite que el proceso de instalación se realice mediante los scripts.
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 VDA se inician después del arranque de la máquina. Se establece en Y de forma predeterminada.
- 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 para Linux VDA. Se establece en Y de forma predeterminada.
- CTX_XDL_AD_INTEGRATION=winbind | quest |centrify | sssd | pbis: 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_HDX_3D_PRO = Y | N: Linux VDA admite HDX 3D Pro, un conjunto de tecnologías para la aceleración de la GPU que se ha diseñado para optimizar la virtualización de aplicaciones con gráficos sofisticados. Si se selecciona HDX 3D Pro, el VDA se configura para el modo de escritorios VDI (sesión única); es decir, CTX_XDL_VDI_MODE=Y.
- CTX_XDL_VDI_MODE=Y | N: Indica si configurar la máquina a partir de un modelo de entrega de escritorios dedicados (VDI) o un modelo de entrega de escritorios compartidos alojados. Para entornos HDX 3D Pro, establezca esta variable en Y. De forma predeterminada, esta variable está establecida en N.
- CTX_XDL_SITE_NAME=dns-name: Linux VDA detecta los servidores LDAP mediante DNS. Para limitar los resultados de búsqueda de DNS a un sitio local, especifique un nombre de sitio DNS. Esta variable está establecida en <none> de forma predeterminada.
- CTX_XDL_LDAP_LIST=’list-ldap-servers’: Linux VDA consulta a DNS para detectar servidores LDAP. Sin embargo, si el DNS no puede proporcionar registros del servicio LDAP, se puede suministrar una lista de nombres FQDN de LDAP, separados por espacios, con los puertos de LDAP. Por ejemplo, ad1.miempresa.com:389 ad2.miempresa.com:3268 ad3.miempresa.com:3268. Si especifica el número de puerto de LDAP como 389, Linux VDA consulta a cada servidor LDAP del dominio especificado en modo de sondeo. Si hay una cantidad “x” de directivas y una cantidad “y” de servidores LDAP, Linux VDA realiza el total de consultas X multiplicado por Y. Si el tiempo de sondeo supera el umbral, los inicios de sesión pueden fallar. Para habilitar las consultas LDAP más rápidas, 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). Sin embargo, para mejorar el rendimiento de la búsqueda, puede especificar otra base de búsqueda (por ejemplo, OU=VDI,DC=miempresa,DC=com). Esta variable está establecida en <none> de forma predeterminada.
- CTX_XDL_FAS_LIST=’list-fas-servers’: Los servidores del Servicio de autenticación federada (FAS) se configuran a través de la directiva de grupo de AD. Linux VDA no admite las directivas de grupo de AD, pero usted puede suministrar una lista de servidores FAS, separados por punto y coma. La secuencia debe ser la misma que la configurada en la directiva de grupo de AD. Si alguna dirección de servidor está eliminada, complete el espacio en blanco correspondiente con la cadena de texto <none> y no cambie el orden de las direcciones de servidor. Para comunicarse correctamente con los servidores FAS, añada un número de puerto coherente con el especificado en los servidores FAS, por ejemplo, CTX_XDL_FAS_LIST=’fas_server_1_url:port_number; fas_server_2_url: port_number; fas_server_3_url: port_number’.
-
CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime: La ruta de instalación de .NET Runtime 6.0 para admitir el nuevo servicio de agente intermediario (
ctxvda
). La ruta predeterminada es /usr/bin. -
CTX_XDL_DESKTOP _ENVIRONMENT=gnome/gnome-classic/mate: Especifica el entorno de escritorio GNOME, GNOME Classic o MATE que se va a utilizar en las sesiones. Si deja la variable sin especificar, se utilizará el escritorio instalado actualmente en el VDA. Sin embargo, si el escritorio instalado actualmente es MATE, debe establecer el valor de la variable como mate.
También puede cambiar el entorno de escritorio del usuario de una sesión de destino mediante estos pasos:
- Cree un archivo
.xsession
en el directorio $HOME/<nombre de usuario\> del VDA. -
Modifique el archivo
.xsession
para especificar un entorno de escritorio basado en distribuciones.-
Para escritorios MATE
MSESSION="$(type -p mate-session)" if [ -n "$MSESSION" ]; then exec mate-session fi
-
Para escritorios GNOME Classic
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then export GNOME_SHELL_SESSION_MODE=classic exec gnome-session --session=gnome-classic fi
-
Para escritorios GNOME
GSESSION="$(type -p gnome-session)" if [ -n "$GSESSION" ]; then exec gnome-session fi
-
- Comparta el permiso de archivo 700 con el usuario de la sesión de destino.
A partir de la versión 2209, los usuarios de las sesiones pueden personalizar sus entornos de escritorio. Para habilitar esta función, debe instalar con antelación en el VDA entornos de escritorio que se puedan cambiar. Para obtener más información, consulte Entornos de escritorio personalizados por usuarios de las sesiones.
- Cree un archivo
- 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.
- CTX_XDL_TELEMETRY_SOCKET_PORT: El puerto de socket para escuchar a Citrix Scout. El puerto predeterminado es 7503.
- CTX_XDL_TELEMETRY_PORT: El puerto para comunicarse con Citrix Scout. El puerto predeterminado es 7502.
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=winbind | quest |centrify | sssd | pbis
export CTX_XDL_HDX_3D_PRO=Y|N
export CTX_XDL_VDI_MODE=Y|N
export CTX_XDL_SITE_NAME=dns-site-name | '<none>'
export CTX_XDL_LDAP_LIST='list-ldap-servers' | '<none>'
export CTX_XDL_SEARCH_BASE=search-base-set | '<none>'
export CTX_XDL_FAS_LIST='list-fas-servers' | '<none>'
export CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime
export CTX_XDL_DESKTOP_ENVIRONMENT= gnome | gnome-classic | mate | '<none>'
export CTX_XDL_TELEMETRY_SOCKET_PORT=port-number
export CTX_XDL_TELEMETRY_PORT=port-number
export CTX_XDL_START_SERVICE=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_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=winbind | quest |centrify | sssd | pbis \
CTX_XDL_HDX_3D_PRO=Y|N \
CTX_XDL_VDI_MODE=Y|N \
CTX_XDL_SITE_NAME=dns-name \
CTX_XDL_LDAP_LIST='list-ldap-servers' \
CTX_XDL_SEARCH_BASE=search-base-set \
CTX_XDL_FAS_LIST='list-fas-servers' \
CTX_XDL_DOTNET_RUNTIME_PATH=path-to-install-dotnet-runtime \
CTX_XDL_DESKTOP_ENVIRONMENT=gnome|gnome-classic|mate \
CTX_XDL_TELEMETRY_SOCKET_PORT=port-number \
CTX_XDL_TELEMETRY_PORT=port-number \
CTX_XDL_START_SERVICE=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 /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.
Desinstalar el software de Linux VDA
Para comprobar si Linux VDA está instalado y para ver la versión del paquete instalado:
dpkg -l xendesktopvda
<!--NeedCopy-->
Para ver información más detallada:
apt-cache show xendesktopvda
<!--NeedCopy-->
Para desinstalar el software de Linux VDA:
dpkg -r xendesktopvda
<!--NeedCopy-->
Nota:
La desinstalación del software de VDA para Linux elimina los datos asociados con PostgreSQL y otros datos de configuración. Sin embargo, no se elimina el paquete de PostgreSQL ni los demás paquetes dependientes que se configuraron antes de instalar Linux VDA.
Sugerencia:
La información en esta sección no cubre la eliminación de paquetes dependientes incluido el de PostgreSQL.
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
yctxhdx
, ejecute el comandoservice ctxmonitorservice stop
para detener el demonio del servicio de supervisión. De lo contrario, el demonio del servicio de supervisión reinicia los servicios que ha detenido.
Reiniciar Linux VDA:
Para reiniciar los servicios de Linux VDA:
sudo 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 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.
Para obtener información sobre cómo crear catálogos de máquinas y grupos de entrega, consulte Citrix Virtual Apps and Desktops 7 2303.
En este artículo
-
Paso 1: Prepare la información de configuración y la máquina Linux
- Paso 1a: Verifique la configuración de red
- Paso 1b: Establezca el nombre de host
- Paso 1c: Asigne una dirección de bucle invertido al nombre de host
- Paso 1d: Compruebe el nombre de host
- Paso 1e: Inhabilite el DNS de multidifusión
- Paso 1f: Compruebe la resolución de nombres y la disponibilidad del servicio
- Paso 1g: Configure la sincronización del reloj (chrony)
- Paso 1h: Instale OpenJDK 11
- Paso 1i: Instale y especifique la base de datos que se utilizará
- Paso 1j: Instale Motif
- Paso 1k: Instale otros paquetes
- Paso 2: Prepare el hipervisor
- Paso 3: Agregue la máquina virtual Linux al dominio de Windows
- Paso 4: Instale .NET Runtime 6.0
- 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