Medulla - Preguntas frecuentes

Preguntas frecuentes - SaaS

Preguntas frecuentes - SaaS

Requisitos de red para Medulla SaaS

 Medulla / Versión All / SaaS / Infraestructura

1. ¿Existen requisitos técnicos para utilizar Medulla en modo SaaS?

Para la oferta SaaS compartida, no se requiere ningún requisito previo de hardware o software.

La única condición es permitir dos flujos de red salientes desde sus puestos de trabajo hacia la plataforma Medulla.

2. ¿Qué puertos deben estar abiertos en Internet?

SaaS compartido

Solo deben autorizarse dos puertos:Terminales → Servidor Medulla:

No debe abrirse ningún otro puerto en Internet.

3. ¿Por qué solo dos puertos?

Porque:

Por lo tanto, no es necesario exponer puertos sensibles en Internet.

4. ¿Qué puertos son necesarios para la oferta SaaS dedicada?

Además de los puertos necesarios para el SaaS compartido:

Todos los demás puertos siguen transitando a través del túnel OpenSSH y no es necesario abrirlos.

5. ¿Por qué algunos puertos (UDP 67, 69, 111, 2049) ya no se mencionan en el modo SaaS?

Porqueno seutilizan en el modo SaaS:

6. ¿Debo abrir puertos de entrada en mi firewall?

No.

No se requiereningún flujo entrante en el modo SaaS de Medulla.

Tu firewall solo debe permitir los siguientes flujos salientes para que los agentes se comuniquen:

7. Resumen rápido

Oferta

Flujos necesarios Terminales → Servidor

Observaciones

SaaS compartido

TCP 2002, TCP 5222

Todos los demás puertos pasan por el túnel OpenSSH

SaaS dedicado

TCP 2002, TCP 5222, TCP 55415

Copia de seguridad activada opcionalmente

Tráfico entrante

Ninguno

Todo lo inicia el terminal

Preguntas frecuentes - SaaS

Puestos de cliente (estado y visibilidad)

¿Por qué algunos equipos aparecen como desconectados aunque estén encendidos?
¿Por qué los inventarios o la información enviada están incompletos o son erróneos?
Preguntas frecuentes - SaaS

Implementación (teledifusión)

¿Por qué mis implementaciones permanecen bloqueadas en «Pending»?
¿Por qué mis implementaciones permanecen bloqueadas en «Deployment Start»?
¿Qué hacer en caso de error de implementación: «Abort Package Execution»?
¿Qué hacer en caso de error de implementación: «Transfer Failed»?
C:\Progra~1\Pulse\var\tmp\packages BUILTIN\Users:(OI)(CI)(F)
                                   NT SERVICE\TrustedInstaller:(I)(F)
                                   NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                                   NT AUTHORITY\SYSTEM:(I)(F)
                                   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Administrators:(I)(F)
                                   BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Users:(I)(RX)
                                   BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                                   CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
                                   APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
                                   AUTORIDAD DE PAQUETES DE APLICACIONES\TODOS LOS PAQUETES DE APLICACIONES RESTRINGIDOS:(I)(OI)(CI)(IO)(GR,GE)

C:\Usuarios\pulseuser\.ssh NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
                        BUILTIN\Administrators:(I)(OI)(CI)(F)
                        NOMBRE_DEL_ORDENADOR\pulseuser:(I)(OI)(CI)(F)

C:\Users\pulseuser\.ssh\authorized_keys NOMBRE_DEL_ORDENADOR\pulseuser:(F)
                                        NT AUTHORITY\SYSTEM:(F)
¿Por qué mis transmisiones no se inician o tardan en hacerlo?
¿Cómo detener una implementación?
¿Cómo puedo ver el resultado de mi implementación?
¿Cómo reiniciar una implementación?
Preguntas frecuentes - SaaS

Paquetes

No consigo añadir un archivo a mi paquete.
He creado un paquete, pero no está disponible para su implementación, ¿por qué?
¿Por qué mi paquete no está disponible en la página de añadir paquetes al Kiosk?
Preguntas frecuentes - SaaS

Mantenimiento remoto y puesta en marcha

¿Qué hacer si el control remoto (VNC/RDP/PMAD) no funciona?

Preguntas frecuentes - OnPremise

Preguntas frecuentes - OnPremise

Implementación (teledifusión)

¿Por qué mis implementaciones permanecen bloqueadas en «Pending»?
¿Por qué mis implementaciones permanecen bloqueadas en «Deployment Start»?
¿Qué hacer en caso de error de implementación: «Abort Package Execution»?
¿Qué hacer en caso de error de implementación: «Transfer Failed»?
C:\Progra~1\Pulse\var\tmp\packages BUILTIN\Users:(OI)(CI)(F)
                                   NT SERVICE\TrustedInstaller:(I)(F)
                                   NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                                   NT AUTHORITY\SYSTEM:(I)(F)
                                   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Administrators:(I)(F)
                                   BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Users:(I)(RX)
                                   BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                                   CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
                                   APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
                                   AUTORIDAD DE PAQUETES DE APLICACIONES\TODOS LOS PAQUETES DE APLICACIONES RESTRINGIDOS:(I)(OI)(CI)(IO)(GR,GE)

C:\Usuarios\pulseuser\.ssh NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
                        BUILTIN\Administrators:(I)(OI)(CI)(F)
                        NOMBRE_DEL_ORDENADOR\pulseuser:(I)(OI)(CI)(F)

C:\Users\pulseuser\.ssh\authorized_keys NOMBRE_DEL_ORDENADOR\pulseuser:(F)
                                        NT AUTHORITY\SYSTEM:(F)
¿Por qué mis transmisiones no se inician o tardan en hacerlo?
¿Cómo detener una implementación?
¿Cómo puedo ver el resultado de mi implementación?
¿Cómo reiniciar una implementación?
Preguntas frecuentes - OnPremise

Mantenimiento remoto y puesta en marcha

¿Qué hacer si el control remoto (VNC/RDP/PMAD) no funciona?
Preguntas frecuentes - OnPremise

Prueba de FLUX

Antes de instalar Medulla, es esencial verificar la comunicación entre:

Para ello, ponemos a su disposición un procedimiento de prueba que incluye scripts específicos. Todos los flujos deben validarse correctamente para garantizar una implementación fluida y un funcionamiento óptimo de Medulla.

No dude en ponerse en contacto con nosotros si necesita ayuda o aclaraciones sobre estas pruebas.

Los scripts se pueden descargar aquí:

https://dl.medulla-tech.io/nc/listen_ports_debian.sh
https://dl.medulla-tech.io/nc/listen_ports_windows.ps1
https://dl.medulla-tech.io/nc/medulla_connection_check.sh
https://dl.medulla-tech.io/nc/medulla_relay_connection_check.sh
https://dl.medulla-tech.io/nc/windows_connection_check_signed.ps1
https://dl.medulla-tech.io/nc/check_connection_ldap.sh
https://dl.medulla-tech.io/nc/check_connection_glpi.sh

(haga clic con el botón derecho del ratón en los enlaces siguientes y seleccione «Guardar enlace como...»)
-----------------------------------------------------------

Requisitos previos para las pruebas

Antes de empezar, asegúrate de haber descargado los scripts de prueba proporcionados anteriormente y de preparar los equipos:

  1. En los servidores Linux (Medulla y Relai):

    • Instala la herramienta necesaria: sudo apt update && sudo apt install netcat-openbsd mariadb-client ldap-utils

    • Haga que los scripts sean ejecutables:

      chmod +x listen_ports_debian.sh medulla_connection_check.sh medulla_relay_connection_check.sh
dos2unix *.sh  # Si es necesario

  2. En el equipo cliente Windows que tenga el agente Medulla:

    • Haga clic con el botón derecho del ratón en el script, seleccione Propiedades, marque la casilla Permitir ejecución del script y confirme.

    image.png

     

    • Autorice la ejecución de los scripts de PowerShell:

    Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

    # Responde «Sí para todos» (A o T) si se te solicita

    Para PowerShell v7.5.4: 

    No es necesario desbloquear el script. Debe ejecutar el comando visto anteriormente.

    Le preguntará si desea autorizar al editor que publica el script; basta con confirmar haciendo clic en R o A.

    image.png

1. Prueba Medulla Servidor <-> Medulla Relé

Comprobación de la comunicación entre el servidor principal y el relé.

Sentido: del servidor al relé

Sentido: Relé hacia servidor

2. Prueba del servidor Medulla <-> Estación cliente Windows

Comprobación de la comunicación directa entre el servidor y los equipos cliente.

Sentido: del servidor al equipo cliente 

Sentido: Estación cliente hacia servidor

Se ha creado un archivo de registro (en la ubicación desde donde se ejecuta el script) que resume varias pruebas, denominado: LOG_Test_Flux.txt

Si se producen errores de permisos tras la creación del archivo de registro, intente colocar los scripts en la carpeta Descargas del usuario, o conceda al script windows_connection_check.ps1 los permisos para crear un archivo en la misma ubicación.

3. Prueba de Medulla Relé <-> Estación cliente Windows

Solo si los equipos deben comunicarse a través de un relé.

Sentido: Relé hacia estación cliente

Sentido: Estación cliente hacia el relé 

Se ha creado un archivo de registro (en la ubicación desde la que está ejecutando el script) que resume varias pruebas, denominado:LOG_Test_Flux.txt

Si se producen errores de permisos tras la creación del archivo de registro, intente colocar los scripts en la carpeta Descargas del usuario, o conceda al script windows_connection_check.ps1 los permisos para crear un archivo en la misma ubicación.

4. Prueba de Medulla Relai DMZ <-> Estación cliente Windows NOMADE

Comprobación de la comunicación directa entre el servidor y los equipos cliente.

(Solo se puede contactar con los equipos móviles a través de los puertos 5222 y 22)

Sentido: Estación cliente hacia servidor

5. Prueba del servidor destinado a Medulla -> Su servidor GLPI

Comprobación de la comunicación directa entre el servidor y su servidor GLPI.

(Requiere el paquete mariadb-client: apt install mariadb-client)

6. Prueba del servidor destinado a Medulla -> Su servidor LDAP

Comprobación de la comunicación directa entre el servidor y su servidor LDAP.

(Requiere el paquete ldap-utils: apt install ldap-utils)

Preguntas frecuentes - OnPremise

Cortafuegos

Si hay un cortafuegos entre el servidor y los equipos, es esencial asegurarse de que los puertos necesarios para la comunicación estén abiertos en ambos sentidos (entrante y saliente).
Los siguientes puertos deben estar accesibles:

En resumen:
Compruebe que estos puertos no estén bloqueados por el cortafuegos del servidor, los equipos de los usuarios o cualquier equipo de red intermedio (router, cortafuegos físico, etc.).

Preguntas frecuentes - OnPremise

Requisitos previos para IMAGING

Configuración de PXE/DHCP

Tras la instalación y configuración de su servidor, se le enviará un documento específico sobre la configuración de DHCP/PXE.

Taller de imágenes

Antes de concertar la cita para su taller de imágenes, debe preparar algunos aspectos:

Debe iniciar la instalación de un equipo Windows y, cuando aparezca el OOBE, cancelarlo con: CTRL + SHIFT + F3

También podemos proporcionarle imágenes maestras para determinados modelos de Windows; para ello, debe indicarnos los modelos de Windows que desea implementar. 

Preguntas frecuentes - OnPremise

Active Directory

En el marco de una implementación On-Premise, deben proporcionarse tres cuentas de servicio de Active Directory distintas.

1. Cuenta de solo lectura

Esta cuenta sirve para consultar el LDAP con el fin de obtener información sobre los usuarios y grupos.

2. Cuenta de registro de máquinas (Imaging/Mastering)

Esta cuenta está dedicada a las operaciones de aprovisionamiento y registro de nuevas máquinas en el dominio durante el proceso de creación de imágenes (o masterización).

3. Cuenta de ejecución de scripts (instalación del agente Medulla)

Esta cuenta es necesaria para las tareas de administración posteriores al despliegue, concretamente parala instalación remota del agente Medulla a través de PowerShell, dirigiéndose a una unidad organizativa (OU) definida.

Preguntas frecuentes - OnPremise

Ya tengo un servidor PXE en mi red, ¿supone esto algún problema?

Coexistencia con un servidor PXE existente

La instalación de Medulla incluye la configuración de un servidor PXE (Preboot Execution Environment) dedicado para facilitar el despliegue. Somos conscientes de que es posible que su entorno ya cuente con un servidor PXE operativo.

Esto no supone ningún problema.

El secreto de la coexistencia reside en el protocolo DHCP (Dynamic Host Configuration Protocol), que es el director de orquesta del proceso de arranque en red (PXE).

1. El DHCP es el único que decide

El servidor PXE (de Medulla o el ya existente) no puede imponerse por sí solo. Es elservidor DHCP el que dirige al cliente hacia el servidor de arranque adecuado.

Cuando enciendes un equipo que debe arrancar mediante PXE, este envía una solicitud DHCP. El servidor DHCP no solo le proporciona una dirección IP, sino también dos datos cruciales para el arranque en red:

Aunque haya dos servidores PXE escuchando en la red, solo el servidor DHCP tiene la autoridad para indicar al cliente qué servidor debe utilizar.

Proporcionamos una configuración DHCP/PXE tras la instalación del servidor Medulla.

2. Filtrado selectivo (dirección MAC / ámbitos)

Es posible gestionar el filtrado por dirección MAC.

En resumen, los dos servidores PXE pueden coexistir, pero permanecen inactivos hasta que el DHCP dé al cliente la orden formal de contactar con uno de ellos mediante la directiva next-server.

Preguntas frecuentes - OnPremise

Diagrama de flujo simplificado de Medulla

Reglas de flujo simplificadas

Las reglas se interpretan de la siguiente manera:

Si dispone de un único servidor Medulla, tenga en cuenta la tabla:
Si dispone de un servidor Medulla y un servidor de retransmisión, tenga en cuenta la tabla:
Si dispone de un servidor Medulla y un servidor de retransmisión DMZ, tenga en cuenta la tabla:

Acceso de Medulla al exterior:
Acceso de Medulla a otros servidores internos:

Acceso desde su máquina de administración a Medulla:
Conexión Puertos utilizados (DEST) Observaciones
Tu equipo de administración interno ➡️ Servidor Medulla

139/445

8384

 Tráfico iniciado por el puesto de administrador interno hacia Medulla.

1. Sin servidor de retransmisión

Conexión Puertos utilizados (DEST) Observaciones
Puesto interno ➡️ Servidor Medulla 22 (SSH)
67/69 (UDP)
80/443
111/2049 (TCP y UDP)
5222
8443
9990
9999,
22067
55415
 Tráfico iniciado desde la extensión interna hacia Medulla.
Servidor Medulla ➡️ Extensión interna   9
22 ( SSH)
3389
5900
5985/5986
35621
35623
 Tráfico iniciado por el servidor Medulla hacia los puestos internos.

2. Con servidor de retransmisión clásico

Conexión Puertos utilizados (DEST) Observaciones
Terminal interno ➡️ Servidores Medulla 22 (SSH)
67/69 (UDP)
80/443
111/2049 (TCP y UDP)
5222
8443
9990
9999,
22067
55415
 Tráfico iniciado desde el extensión interna hacia Medulla.
Servidores Medulla ➡️ Terminal interno   9
22 ( SSH)
3389
5900
5985/5986
35621
35623
 Tráfico iniciado por el servidor Medulla hacia los puestos internos.
--- --- ---
Servidor Medulla ➡️ Servidor de retransmisión

22 ( SSH)

5269
8081

9990
22000

 Tráfico iniciado por Medulla hacia el servidor DMZ.
Servidor de retransmisión ➡️ Servidor Medulla 

22 ( SSH)

5269
7080
8443
9999
22067
22000

 Tráfico iniciado por el servidor DMZ hacia Medulla.
---

Terminal interno ➡️ Servidor de retransmisión

22

69/69 (UDP)

80/443

111/2049 (TCP y UDP)

5222

9990

 Tráfico iniciado por el teléfono interno hacia el servidor de retransmisión.
Servidor de retransmisión ➡️ Extensión interna

9

22

3389

5900

 Tráfico iniciado por el servidor de retransmisiónhaciala extensión interna.

3. Con servidor de retransmisión DMZ

Conexión Puertos utilizados (DEST) Observaciones
Terminal interno ➡️ Servidor Medulla 22 (SSH)
67/69 (UDP)
80/443
111/2049 (TCP y UDP)
5222
8443
9990
9999,
22067
55415
 Tráfico iniciado desde la extensión interna hacia Medulla.
Servidor Medulla ➡️ Extensión interna   9
22 ( SSH)
3389
5900
5985/5986
35621
35623
 Tráfico iniciado por el servidor Medulla hacia los puestos internos.
--- --- ---
Servidor Medulla ➡️ Servidor de retransmisión DMZ

22 ( SSH)

4369

4370 a 4380
5269
8081
22000

 Tráfico iniciado por Medulla hacia el servidor DMZ.
Servidor de retransmisión DMZ➡️ Servidor Medulla 

22 ( SSH)

4369

4370 a 4380
5269
7080
8443
9999
22067
22000

 Tráfico iniciado por el servidor DMZ hacia Medulla.
--- --- ---
Terminal externo ➡️ Servidor DMZ 22 ( SSH)
5222

Tráfico iniciado por el puesto externo hacia el servidor DMZ.

 

Descripción de los puertos

Puerto 9: utilizado para Wake on LAN (WOL) con el fin de activar un puesto de forma remota.

Puerto 22 (SSH): puerto SSH utilizado por Medulla para operaciones remotas, ejecución de comandos y administración de agentes.

Puertos 67 y 69 (UDP): utilizados para DHCP y TFTP, especialmente durante el arranque PXE o para la carga de imágenes de implementación.

Puertos 80 y 443: HTTP y HTTPS, utilizados para el acceso web y las comunicaciones seguras con los servicios de Medulla.

Puerto 111 (TCP y UDP): utilizado por Portmapper / RPCbind, necesario para los servicios NFS y algunas llamadas de red internas.

Puerto 3389: utilizado para RDP con el fin de conectarse de forma remota a equipos Windows.

Puerto 4369: utilizado para un clúster ejabberd si dispone de un relé DMZ

Puertos 4370 a 4380: utilizados para un clúster ejabberd si dispone de un relé DMZ

Puerto 5222: utilizado por XMPP para la comunicación entre los agentes Medulla y el servidor.

Puerto 5269: utilizado por XMPP para la comunicación de servidor a servidor, en particular entre Medulla y el servidor de retransmisión en la DMZ.

Puerto 5900: utilizado por VNC para el control remoto.

Puertos 5985 y 5986: utilizados por WinRM (HTTP y HTTPS) para comandos remotos en Windows.

Puertos 7080 y 8081: utilizados por servicios internos o API de gestión necesarios para el servidor de retransmisión o los componentes de Medulla.

Puerto 8443: HTTPS utilizado por la interfaz o las API seguras de Medulla.

Puerto 9990: utilizado por un servicio interno de Medulla para la gestión y la supervisión.

Puerto 9999: utilizado como puerto interno de sincronización o intercambio entre el servidor Medulla y componentes como el relé.

Puerto 22000: utilizado por Syncthing como canal principal para la sincronización de datos (paquetes, artefactos, inventarios).

Puerto 22067: utilizado por Syncthing como canal de retransmisión, útil para equipos móviles o situados detrás de un NAT.

Puertos 35621, 35623 y 55415: puertos dinámicos utilizados por los agentes de Medulla para la comunicación en tiempo real, el inventario, la sincronización o la ejecución de tareas.

Preguntas frecuentes - OnPremise

OIDC

Listar mis configuraciones OIDC

Vaya a la vista Admin > Gestionar proveedores.

image.png

Aquí encontrará la lista de OIDC ya configurados que es posible modificar.

Crear una configuración OIDC

image.png

«Nombre del proveedor» será el título que se mostrará en la página de inicio.

«URL del logotipo» corresponde al enlace web para configurar un logotipo en el botón de inicio de sesión OIDC.

«URL del emisor» corresponde al enlace web que redirige a su OIDC.

«ID de cliente» corresponde al identificador de su OIDC.

«Secreto del cliente» corresponde a la contraseña de su OIDC.

«LDAP uid» corresponde a la asignación del uid por parte de su OIDC

«LDAP givenName» corresponde a la asignación del givenName de su OIDC

«LDAP sn» corresponde a la asignación del sn de su OIDC

«LDAP mail» corresponde a la asignación del correo electrónico de su OIDC

A continuación, pulse el botón «Crear proveedor» para poder conectarse a través de un OIDC en su plataforma.

Preguntas frecuentes - OnPremise

Vistas DNS y relé de Medulla en DMZ

En una arquitectura Medulla,se puede colocar unrelé en la DMZ para permitir que los equipos externos accedan a la plataforma sin exponer directamente el servidor Medulla interno si no dispone de una VPN.

 

Dado que la configuración de los agentes Medulla es única para todo el parque, solo admite un único nombre de dominio. Para permitir que los equipos se conecten al servidor tanto desde la red privada como desde el exterior a través de esta dirección única, es necesario utilizar un nombre de dominio único junto con vistas DNS (Split-Horizon) o un Round-Robin.

Vistas DNS

Principio

Una vista DNS permite proporcionar respuestas diferentes para un mismo nombre en función del origen de la solicitud.

  • Equipos internos → servidor Medulla interno
  • Equipos externos → relé de Medulla en DMZ

Ventajas

 

A tener en cuenta

Las vistas DNS permiten dirigir automáticamente los equipos hacia el punto de acceso Medulla adecuado, manteniendo un nombre único y una configuración sencilla.

Artículo de referencia sobre Bind9: https://kb.isc.org/docs/aa-00851

Round-Robin

Asimismo, si no desea configurar vistas DNS, puede optar por una solución alternativa implementando un mecanismo Round-Robin. Este permite distribuir las solicitudes entre varias direcciones IP asociadas a un mismo nombre de dominio, garantizando así una distribución equilibrada de las conexiones.

Para ello, es necesario seguir dos pasos:

  1. Definir la dirección IP interna del servidor principal Medulla.
  2. Definir la dirección IP pública del servidor de retransmisión DMZ.
Preguntas frecuentes - OnPremise

Filtrar tipos de máquinas por ID GLPI

Para el filtro, en la sección main de /etc/mmc/plugins/glpi.ini.local hay que añadir:
filter_on = <el_criterio>

#Mostrar solo los ordenadores que cumplan uno de estos filtros:
* estado
* tipo
* entidad
* autoupdatesystems_id

#Cada filtro puede contener una lista de valores separados por barras verticales
#Los filtros son identificadores separados por espacios

p. ej., state=1 type=2|3|7 entity=2|5
filter_on = state=3

Preguntas frecuentes - OnPremise

Su GLPI con usuario de solo lectura

Medulla requiere la creación de vistas específicas en la base de datos GLPI para funcionar correctamente.

GLPI de solo lectura

Si nos proporciona un usuario con derechos de solo lectura en su base de datos GLPI, deberá aplicar manualmente un archivo SQL antes de instalar Medulla. Este archivo contiene las consultas necesarias para crear las vistas requeridas.

Aquí tienes el enlace al archivo SQL:

https://dl.medulla-tech.io/nc/glpi-100.sql

GLPI con acceso de escritura

Si autoriza el acceso deescritura a su base de datos GLPI, Medulla aplicará automáticamente las vistas necesarias durante la instalación.

Estas vistas son obligatorias para el funcionamiento de Medulla.

Preguntas frecuentes - OnPremise

Desactivar la convergencia del paquete Extract drivers

Acceda al servidor Medulla.

Edite los archivos:

Modifique el parámetro correspondiente: 

[extractdrivers] 
# Añade la posibilidad de habilitar o deshabilitar el mecanismo de controladores de extracción
# valores aceptados 0, false, False
# valores aceptados 1, true, True
activate=0

Guarde los archivos.

Reinicie el servicio: 

systemctl restart pulse-xmpp-master-substitute-registration.service
Preguntas frecuentes - OnPremise

Guía de configuración: Autenticación OIDC y sincronización de usuarios

Si utiliza una infraestructuralocal y opta por la autenticación mediante el protocolo OIDC (OpenID Connect), es fundamental comprender cómo se transmiten y gestionan las cuentas de usuario entre su proveedor de identidad y la interfaz GLPI, en caso de que esta última no tenga usuarios (si se acaba de instalar junto con Medulla).

1. Comprender el flujo de autenticación

En esta arquitectura, la gestión de accesos sigue un recorrido específico:

  1. Almacenamiento: Sus usuarios OIDC se aprovisionan en el LDAP local del servidor Medulla.

  2. Autorizaciones (ACL): Aunque la autenticación la gestiona OIDC, los derechos de acceso y los permisos (perfiles) se controlan directamente desde GLPI.

Síntoma de falta de sincronización: Si, tras iniciar sesión a través de OIDC, llega a una página de GLPI vacía o sin menús, significa que su cuenta aún no se ha importado a la base de datos de GLPI. Sin este paso, el sistema no puede asignarle ningún perfil ni derechos de acceso.

La incorporación de usuarios a GLPI al iniciar sesión a través de OIDC ahora es automática si:

2. Procedimiento de sincronización manual

Para que sus usuarios estén activos en GLPI, debe establecer una conexión con el directorio LDAP local. Estos son los pasos a seguir:

Paso A: Acceder a la interfaz de enlace

  1. Inicie sesión en GLPI con una cuenta de administrador local.

  2. Vaya al menú Administración > Usuarios.

  3. Haga clic en el botón Vinculación con el directorio LDAP.

image.png

Paso B: Importar las cuentas

  1. Haga clic en el enlace Importación de nuevos usuarios.

  2. Haga clic en el botón Buscar para mostrar la lista de usuarios presentes en el LDAP de Medulla.

  3. Seleccione los usuarios deseados (o todos) y confirme la sincronización.

Preguntas frecuentes - OnPremise

Aumentar el tiempo de espera de la conexión a la interfaz

Vaya al archivo /etc/mmc/mmi.ini

Modifique el valor de sessiontimeout. (Este valor se expresa en segundos)

image.png

Preguntas frecuentes - OnPremise

Soporte de activación / WSUS / CVE

Aplicable a: Medulla – Soporte / WSUS / CVE
Versión: 5.4.3 o posterior
Entorno: On-Premise
Categoría: Soporte

Tras actualizar su instalación de Medulla, es necesario realizar una acción adicional para activar el soporte.

Descargue el siguiente archivo en su servidor:

/etc/mmc/plugins/security.ini.local

A continuación, debe enviar este archivo a su representante comercial.

Este paso permite activar su acceso al soporte técnico, así como a los servicios asociados.

Preguntas frecuentes - OnPremise

Cambiar el FQDN del servidor

Descargue el script en este enlace:

https://dl.medulla-tech.io/nc/rename_fqdn_and_protocol.py

chmod +x rename_fqdn_and_protocol.py

Para ver las opciones del script:

./rename_fqdn_and_protocol --help 

Modificar el FQDN del servidor

Para cambiar medulla.mondomaine.lan por medulla.mondomaine.fr, aquí tienes un ejemplo de cómo usar el comando:

./rename_fqdn_and_protocol --old-fqdn medulla.mondomaine.lan --new-fqdn medulla.mondomaine.fr

Modificar el protocolo

También es posible cambiar el protocolo de http a https en las URL al mismo tiempo:

./rename_fqdn_and_protocol --old-fqdn medulla.mondomaine.lan --new-fqdn medulla.mondomaine.fr --new-protocol https

Regenerar el agente

Si los equipos también deben comunicarse directamente con el nuevo FQDN, es posible regenerar el agente con el nuevo FQDN:

./rename_fqdn_and_protocol --old-fqdn medulla.mondomaine.lan --new-fqdn medulla.mondomaine.fr --update-agent-conf

Para obtener más información y si dispone de un contrato de asistencia técnica de Medulla, póngase en contacto con support@medulla-tech.io

Preguntas frecuentes - OnPremise

Cambiar el puerto SSH entre el servidor y el equipo

Descargue los scripts en estos enlaces:

https://dl.medulla-tech.io/nc/change_ssh_port_on_agent.py

https://dl.medulla-tech.io/nc/change_ssh_port_on_server.py

chmod +x change_ssh_port_on_agent.py

chmod +x change_ssh_port_on_server.py

Para ver las opciones del script:

./change_ssh_port_on_agent.py --help

./change_ssh_port_on_server.py --help

Es obligatorio cambiar el puerto con ambos scripts

El puerto debe ser el mismo en ambos scripts

Modificar el puerto en el servidor

Para cambiar el puerto 22 por el puerto 2002, aquí tienes un ejemplo de cómo utilizar el comando:

./change_ssh_port_on_agent.py --new-ssh-port 2002

./change_ssh_port_on_server.py --new-ssh-port 2002

El agente se regenerará tras la ejecución del script «change_ssh_port_on_agent.py», por lo que deberá volver a implementar el agente en sus equipos.

Preguntas frecuentes - OnPremise

GLPI - Conectar un GLPI externo

Aplicable a: Medulla/GLPI
Versión de Medulla: todas
Versión de GLPI: 10.0.x
Entorno: On-Premise
Categoría: Medulla

Requisitos previos

Antes de configurar la integración entre Medulla y GLPI, asegúrese de que los siguientes elementos estén disponibles y correctamente configurados.

Descargue el script aquí: https://dl.medulla-tech.io/ma/change_itsm_parameters.py

1. Acceso a la base de datos de GLPI

Cree un usuario dedicado de MySQL/MariaDB para Medulla con los siguientes permisos:

- Solo lectura (`READ ONLY`) o lectura/escritura según sea necesario
- Acceso a toda la base de datos de GLPI

2. Conectividad de red

Permitir la comunicación entre el servidor Medulla y el servidor de la base de datos GLPI:

- Puerto `3306` abierto (o puerto personalizado según su configuración)

3. Creación de un usuario API GLPI

Cree un usuario GLPI dedicado a las llamadas API con el nombre que desee:

En GLPI, en `Administración > Usuarios`

- Tipo: usuario estándar (nombre de usuario / contraseña)
- Perfil recomendado:
  - «Read-Only» o «Super-Admin»
- Asignación:
  - Entidad raíz
  - Modo recursivo activado

A continuación, genere un token de API de usuario (`user_token`)

4. Creación de un cliente API GLPI

Crear un cliente API denominado `MMC`.

En GLPI, en `Configuración > General > API`

A continuación, genere el token de aplicación (`app_token`)

5. Importar vistas SQL a su base de datos GLPI

En su base de datos GLPI debe importar el archivo descargado aquí:

https://dl.medulla-tech.io/nc/glpi-100.sql

---

Uso del script

Comando de ayuda

./change_itsm_parameters.py --help

uso: change_itsm_parameters.py [-h] --url URL --db-host DB_HOST [--db-port DB_PORT] --db-name DB_NAME --db-user DB_USER --db-pass DB_PASS --api-url API_URL [--api-user API_USER] [--api-pass API_PASS] [--readonly READONLY] [--crypt-key CRYPT_KEY] [--inv-forward INV_FORWARD] [--inv-forward-url INV_FORWARD_URL] [--inv-plugin INV_PLUGIN] [--inv-agent INV_AGENT] [--inv-agent-disabled INV_AGENT_DISABLED]

Actualizar parámetros de ITSM

opciones:
  -h, --help muestra este mensaje de ayuda y sale
  --url URL URL del proveedor de ITSM
  --db-host DB_HOST Host de la base de datos del proveedor de ITSM
  --db-port DB_PORT Puerto de la base de datos del proveedor de ITSM
  --db-name DB_NAME Nombre de la base de datos del proveedor de ITSM
  --db-user DB_USER usuario de la base de datos del proveedor de ITSM
  --db-pass DB_PASS Contraseña de la base de datos del proveedor de ITSM
  --api-url API_URL URL de la API del proveedor de ITSM
  --api-user API_USER Usuario de la API del proveedor de ITSM
  --api-pass API_PASS Contraseña de la API del proveedor de ITSM
  --readonly READONLY Si la base de datos del proveedor de ITSM es de solo lectura para Medulla (opcional)
  --crypt-key CRYPT_KEY
                        Archivo de clave de cifrado GLPI descodificado - base64 /etc/glpi/glpicrypt.key (opcional)
  --inv-forward INV_FORWARD
                        Si se reenvían los datos de inventario al proveedor de ITSM (opcional)
  --inv-forward-url INV_FORWARD_URL
                        URL a la que reenviar los datos de inventario (opcional)
  --inv-plugin INV_PLUGIN
                        Complemento de inventario que se va a utilizar: glpiinventory o fusioninventory (opcional)
  --inv-agent INV_AGENT
                        Agente de inventario a utilizar en el equipo cliente: glpiagent o fusioninventory (opcional, obligatorio si --inv-forward es verdadero)
  --inv-agent-disabled INV_AGENT_DISABLED
                        Si se debe incluir el agente de inventario en el agente Medulla (opcional)

Ejemplos de uso:

./change_itsm_parameters.py \
  --url https://glpi.mon-domaine.fr/ \
  --db-host 10.10.0.101 \
  --db-port 3306 \
  --db-name GLPI \
  --db-user medulla_glpi \
  --db-pass yJxI40UzO8Jn7dd7K5Yaml \
  --api-url https://glpi.mon-domaine.fr/apirest.php/ \
  --api-user medulla_APIUSER \
  --api-pass fLN1Zomh877obPhk \

Preguntas frecuentes - SaaS privado

Preguntas frecuentes - SaaS privado

Requisitos de red para Medulla SaaS Privado

Consulte: 

https://docs.medulla-tech.io/books/medulla-faq/page/faq-pre-requis-reseau-pour-medulla-saas

 

Preguntas frecuentes - SaaS privado

Puestos de cliente (estado y visibilidad)

¿Por qué algunos equipos aparecen como desconectados aunque estén encendidos?
¿Por qué los inventarios o la información enviada están incompletos o son erróneos?
Preguntas frecuentes - SaaS privado

Implementación (teledifusión)

¿Por qué mis implementaciones permanecen bloqueadas en «Pending»?
¿Por qué mis implementaciones permanecen bloqueadas en «Deployment Start»?
¿Qué hacer en caso de error de implementación: «Abort Package Execution»?
¿Qué hacer en caso de error de implementación: «Transfer Failed»?
C:\Progra~1\Pulse\var\tmp\packages BUILTIN\Users:(OI)(CI)(F)
                                   NT SERVICE\TrustedInstaller:(I)(F)
                                   NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                                   NT AUTHORITY\SYSTEM:(I)(F)
                                   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Administrators:(I)(F)
                                   BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Users:(I)(RX)
                                   BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                                   CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
                                   APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
                                   AUTORIDAD DE PAQUETES DE APLICACIONES\TODOS LOS PAQUETES DE APLICACIONES RESTRINGIDOS:(I)(OI)(CI)(IO)(GR,GE)

C:\Usuarios\pulseuser\.ssh NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
                        BUILTIN\Administrators:(I)(OI)(CI)(F)
                        NOMBRE_DEL_ORDENADOR\pulseuser:(I)(OI)(CI)(F)

C:\Users\pulseuser\.ssh\authorized_keys NOMBRE_DEL_ORDENADOR\pulseuser:(F)
                                        NT AUTHORITY\SYSTEM:(F)
¿Por qué mis transmisiones no se inician o tardan en hacerlo?
¿Cómo detener una implementación?
¿Cómo puedo ver el resultado de mi implementación?
¿Cómo reiniciar una implementación?
Preguntas frecuentes - SaaS privado

Paquetes

No consigo añadir un archivo a mi paquete.
He creado un paquete, pero no está disponible para su implementación, ¿por qué?
¿Por qué mi paquete no está disponible en la página de añadir paquetes al Kiosk?
Preguntas frecuentes - SaaS privado

Consola y administración

¿Por qué la consola es lenta, inestable o inaccesible?
¿Cómo resolver los problemas de derechos de usuario?
¿Por qué no tengo acceso a determinados grupos, auditorías o tareas programadas?
¿Qué hacer en caso de bloqueo en la consola o de errores XMPP?
Preguntas frecuentes - SaaS privado

Mantenimiento remoto y puesta en marcha

¿Qué hacer si el control remoto (VNC/RDP/PMAD) no funciona?

Preguntas frecuentes - Todas las plataformas

Preguntas frecuentes - Todas las plataformas

Puestos de cliente (estado y visibilidad)

Aplicable a: Medulla – Agentes
Versión:5.4.3 o posterior
Entorno: On-Premise - SaaS compartido y SaaS privado
Categoría: Soporte

¿Por qué algunos equipos aparecen como desconectados cuando están encendidos?
¿Por qué los inventarios o la información enviada están incompletos o son erróneos?
Preguntas frecuentes - Todas las plataformas

Paquetes

Paquetes de módulos de Medulla / Todas las versiones / SaaS público y privado y On premise / Mantenimiento

No consigo añadir un archivo a mi paquete.
He creado un paquete, pero no está disponible para su implementación, ¿por qué?
¿Por qué mi paquete no está disponible en la página de añadir paquetes al Kiosk?
Preguntas frecuentes - Todas las plataformas

Consola y administración

Medulla / Todas las versiones / SaaS público y privado y On premise / Mantenimiento

¿Por qué la consola es lenta, inestable o inaccesible?
¿Cómo resolver los problemas de derechos de usuario?
¿Por qué no tengo acceso a determinados grupos, auditorías o tareas programadas?
¿Qué hacer en caso de bloqueo en la consola o de errores XMPP?
Preguntas frecuentes - Todas las plataformas

Mantenimiento remoto y puesta en marcha

Módulos de Medulla Ordenadores / Todas las versiones / SaaS público y privado y On premise / Mantenimiento

¿Qué hacer si el control remoto (VNC/RDP/PMAD) no funciona?
Preguntas frecuentes - Todas las plataformas

Poner el agente en modo de depuración

Medulla / Todas las versiones / SaaS público y privado y On premise / Mantenimiento

Poner el agente enmodo DEBUG no puede ser más sencillo.

Acceda al archivo agentconf.ini que se encuentra en: C:\Archivos de programa\Medulla\etc\agentconf.ini

En la sección [global]

Preguntas frecuentes - Todas las plataformas

Problema con el agente de Windows

Medulla / Todas las versiones / SaaS público y privado y On premise / Mantenimiento

¿Su problema se refiere a una interacción entreMedulla y un equipo Windows (agente que no se conecta, acciones no aplicadas, equipo invisible, etc.)?

Para facilitar el diagnóstico, Medulla pone a su disposición un script de verificación que permite comprobar la conectividad de red, el estado del agente y la configuración del equipo.

Descarga del script:
https://dl.medulla-tech.io/nc/windows_connection_check_signed.ps1

(haga clic con el botón derecho del ratón en el enlace siguiente y seleccione «Guardar enlace como...»)

Requisitos previos para las pruebas

Antes de empezar, asegúrese de haber descargado el script anterior y de haber preparado los equipos.

En el equipo cliente Windows que tenga el agente Medulla:

image.png

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

# Responde «Sí para todos» (A o T) si se te solicita

Para PowerShell v7.5.4: 

No es necesario desbloquear el script. Debe ejecutar el comando visto anteriormente.

Le preguntará si desea autorizar al editor que publica el script; basta con confirmar haciendo clic en R o A.

image.png

Prueba de Medulla Servidor <- Equipo cliente Windows

Comprobación de la comunicación directa entre el servidor y los equipos cliente.

En el equipo cliente (origen): Ejecute la prueba con el nombre de host o la IP del servidor.

.\windows_connection_check_signed.ps1 -Target <IP_DEL_SERVIDOR> -Mode pulse

Se crea un archivo de registro (en la ubicación desde la que se ejecuta el script) que resume las pruebas realizadas: LOG_Test_Flux.txt

Si se producen errores de permisos al crear el archivo de registro, intente colocar el script en la carpeta Descargas del usuario, o conceda permisos al script windows_connection_check.ps1 para crear un archivo en la misma ubicación.

Medulla On-Premise

Si dispone de un servidor Medulla On-Premise, también tiene la posibilidad de ejecutar un diagnóstico del servidor hacia el terminal:

En el servidor Medulla (origen): Ejecute la prueba hacia el nombre de host o la IP del terminal.

./medulla_connection_check.sh -c client.example.com

Recomendación: adjunte el archivo LOG_Test_Flux.txt cuando solicite asistencia técnica.

Preguntas frecuentes - ACL

Preguntas frecuentes - ACL

Introducción

Definiciones: 

ACL: Define el acceso a cada una de las funcionalidades de Medulla en función del perfil del usuario conectado.
Las ACL evolucionan con cada versión de Medulla a medida que se amplían las funcionalidades.

Perfil: Se define en la herramienta de ITSM y permite establecer las autorizaciones de un usuario sobre una entidad.
Se definen 3 perfiles: Superadministrador, Administrador y Técnico

Restricción: No hay diferenciación entre el par perfil/entidad en Medulla. Si un usuario tiene perfiles diferentes en distintas entidades, siempre se aplicará su perfil más permisivo a todas las entidades permitidas.

Configuración: 

Las ACL se configuran en el archivo:/etc/mmc/plugins/glpi.ini.local

Los 3 parámetros son:
profile_acl_Super-Admin
profile_acl_Admin
profile_acl_Technician

Pasos de configuración: 

1- En la lista, seleccione las funciones deseadas
2- Conjuga las ACL en una cadena continua y termina con /
3- Introducir la cadena en el archivo de configuración del perfil deseado
4 - Reiniciar los servicios

 

Preguntas frecuentes - ACL

Las ACL

Panel de control: 

image.png

Inventario: 

image.png

Paquetes: 

image.png

Implementación de paquetes:

image.png

image.png



Preguntas frecuentes - ACL

Las ACL a continuación

Imágenes: 

image.png

image.png

image.png

Actualizaciones: 

image.png

image.png

Administrador local Superadministrador Gestión de servidores: 

image.png

image.png

Preguntas frecuentes - Interfaz

Preguntas frecuentes - Interfaz

Consola y administración

Aplicable a: Medulla – Interfaz
Versión: Todas
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Interfaz de Medulla / soporte

¿Por qué la consola es lenta, inestable o inaccesible?
¿Cómo resolver los problemas de derechos de usuario?
¿Por qué no tengo acceso a determinados grupos, auditorías o tareas programadas?
¿Qué hacer en caso de bloqueo en la consola o de errores XMPP?

Preguntas frecuentes: uso de Medulla

Preguntas frecuentes: uso de Medulla

Implementación (teledifusión)

¿Por qué mis implementaciones permanecen bloqueadas en «Pending»?
¿Por qué mis implementaciones permanecen bloqueadas en «Deployment Start»?
¿Qué hacer en caso de error de implementación: «Abort Package Execution»?
¿Qué hacer en caso de error de implementación: «Transfer Failed»?
C:\Progra~1\Pulse\var\tmp\packages BUILTIN\Users:(OI)(CI)(F)
                                   NT SERVICE\TrustedInstaller:(I)(F)
                                   NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                                   NT AUTHORITY\SYSTEM:(I)(F)
                                   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Administrators:(I)(F)
                                   BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                                   BUILTIN\Users:(I)(RX)
                                   BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                                   CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
                                   APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
                                   AUTORIDAD DE PAQUETES DE APLICACIONES\TODOS LOS PAQUETES DE APLICACIONES RESTRINGIDOS:(I)(OI)(CI)(IO)(GR,GE)

C:\Usuarios\pulseuser\.ssh NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
                        BUILTIN\Administrators:(I)(OI)(CI)(F)
                        NOMBRE_DEL_ORDENADOR\pulseuser:(I)(OI)(CI)(F)

C:\Users\pulseuser\.ssh\authorized_keys NOMBRE_DEL_ORDENADOR\pulseuser:(F)
                                        NT AUTHORITY\SYSTEM:(F)
¿Por qué mis transmisiones no se inician o tardan en hacerlo?
¿Cómo detener una implementación?
¿Cómo puedo ver el resultado de mi implementación?
¿Cómo reiniciar una implementación?
Preguntas frecuentes: uso de Medulla

Paquetes

No consigo añadir un archivo a mi paquete.
He creado un paquete, pero no está disponible para su implementación, ¿por qué?
¿Por qué mi paquete no está disponible en la página de añadir paquetes al Kiosk?


Aumentar el tamaño de subida del paquete 

Ejecute estos comandos con el tamaño deseado;post_max_size y upload_max_filesize corresponden al nuevo tamaño de carga deseado.

crudini --set /etc/php/8.2/fpm/php.ini PHP post_max_size 800M 
crudini --set /etc/php/8.2/fpm/php.ini PHP upload_max_filesize 800M
crudini --set /etc/php/8.2/fpm/php.ini PHP memory_limit 2048M
crudini --set /etc/php/8.2/fpm/php.ini PHP max_execution_time 60
crudini --set /etc/php/8.2/fpm/php.ini PHP max_input_time 60
systemctl restart php8.2-fpm

memory_limit debe ser como mínimo 2,5 veces el tamaño de la subida.

Esta modificación puede provocar ralentizaciones. Sea prudente al aumentar el valor.

Preguntas frecuentes: uso de Medulla

Actualizaciones (Windows Updates)

¿Sus equipos no muestran ninguna actualización?

Esta funcionalidad requiere un contrato de soporte técnico activo.
Este módulo se basa en procesos avanzados (análisis de vulnerabilidades, correlación de datos, cálculo de estados) realizados en los servidores de Medulla.
El contrato de soporte permite financiar la infraestructura necesaria para estos procesos, así como su mantenimiento en condiciones operativas.
El contrato de soporte técnico también incluye:
el soporte técnico y la asistencia,
el acceso a las nuevas funcionalidades sujetas a un contrato de soporte activo,
la participación en la mejora continua de la solución.
Para activar estas funcionalidades, le invitamos a suscribir un contrato de soporte poniéndose en contacto con nosotros en la siguiente dirección: medulla@medulla-tech.io

Preguntas frecuentes: uso de Medulla

Los menús de imágenes

Aplicable a: Medulla – Imágenes
Versión:5.4.3 o posterior
Entorno: On-Premise / SaaS privado con relé de imágenes.
Categoría: Uso

Este documento se centra en la gestión y la generación de menús de imágenes.

¿Qué es un menú de imágenes?

Un menú de imágenes es un conjunto de servicios y plantillas asociados a un equipo, que se pueden utilizar durante la secuencia de arranque (en red) de un equipo.
Durante un arranque PXE, el equipo solicita su menú al servidor. Son posibles varios casos:

El desarrollo posterior del proceso de creación de imágenes depende del contenido de este menú. 

Existen diferentes niveles de menús:

Los menús del servidor de imágenes:

Este menú es fijo. Se compone de los siguientes servicios:
- continuar: este servicio permite arrancar la máquina de forma normal.
- register: este servicio permite registrar una máquina en el sistema de imágenes.

Cada servidor de imágenes recibe un menú predeterminado. Este menú está compuesto por los siguientes servicios:
- `continue`: este servicio permite arrancar la máquina normalmente.
- `backup`: crea una copia del disco de la máquina en el sistema de imágenes.

Este menú se puede modificar desde la interfaz MMC.

Las modificaciones del menú predeterminado no afectan a los menús de las máquinas ni de los grupos. Para que las máquinas se beneficien de las modificaciones del menú predeterminado, es necesario realizar un «reinicio» de los menús de la entidad.

Hay varios servicios disponibles que se pueden añadir al menú.

La página que define los servicios disponibles en un menú es la siguiente:
MMC > Imágenes > Gestionar servicios de menú.

En esta página, los servicios se asocian a la entidad seleccionada. Al cambiar de entidad, se modifica la lista de servicios asociados a dicha entidad.

Esta sección no aborda cómo convertir una imagen en un modelo.

Los masters presentes en el servidor de imágenes pueden asociarse al menú por defecto.

La página que permite asociar plantillas al menú predeterminado es la siguiente:
MMC > Imágenes > Gestionar masters.

Los diferentes servicios y plantillas asociados al menú predeterminado se pueden ver en la siguiente página:
`MMC > Imágenes > Menú de inicio predeterminado`.

En esta página es posible modificar el orden de los elementos del menú. También es posible modificar parámetros específicos de los elementos asociados.

Actualmente, un menú debe incluir al menos un servicio (o una imagen). Por lo general, el servicio básico es `continue` para que sea funcional.

El servicio mínimo debe validar las siguientes opciones:

- Predeterminado activado para que este servicio se seleccione por defecto
- Visible activado para que este servicio sea visible en el menú de inicio
- WOL por defecto activado para no tener un traceback, aunque no sé para qué sirve esta opción.

Se está considerando una corrección para no permitir la eliminación del último servicio de un menú.

Se puede acceder al menú de una máquina desde la siguiente página:
MMC > Máquinas > acción:Gestión de imágenes.

Esta página está organizada en tres pestañas:
- Menú de inicio: esta pestaña permite visualizar y modificar el menú.
- Servicios del menú: esta pestaña permite asociar servicios al menú de la máquina.
- Imágenes y máster: esta pestaña permite asociar másteres al menú de la máquina.

Un menú de máquina no debería estar vacío. Si es así, hay varias posibilidades:
- La máquina ha copiado un menú predeterminado vacío (poco probable, ya que, por lo general, la copia en esta situación genera un traceback).
- Un administrador ha eliminado todos los elementos del menú de la máquina.

Básicamente, el menú de un grupo es similar al menú de una máquina. Sin embargo, está asociado a un grupo de imágenes, y no a una máquina específica.

Para acceder a él, hay que ir a la siguiente página:
MMC > Imágenes > Todos los grupos de imágenes > acción:Gestión de imágenes.

El menú de un grupo prevalece sobre el menú de una máquina. Cuando se solicita la página del menú de una máquina, es posible que **no se vea** la línea de encabezado que indica que la máquina forma parte de un grupo.

En ese caso, la máquina muestra su menú personalizado, y no el del grupo. Esto puede generar confusión para el administrador.

Preguntas frecuentes: Agentes

Preguntas frecuentes: Agentes

Puestos de cliente (estado y visibilidad)

Aplicable a: Medulla – Agente
Versión: Todas
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Agente Medulla / soporte

¿Por qué algunos puestos aparecen como desconectados cuando están encendidos?
¿Por qué los inventarios o la información enviada están incompletos o son erróneos?
Preguntas frecuentes: Agentes

GPO

Aplicable a:Medulla – Agente
Versión: Todas 
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Agente Medulla

Implementación del agente Medulla a través de GPO


¿Cuál es el mejor método para implementar el agente Medulla en todos los equipos de un dominio de Active Directory?


El método recomendado es utilizar unatarea programada a través de las Preferencias de política de grupo (GPP) con la opción «Aplicar una vez y no volver a aplicar».


Este método es:
- Compatible con cualquier archivo EXE (no se necesita MSI)
- Se ejecuta una sola vez por equipo
- Se inicia con derechos de sistema (administrador)
- Es oficialmente compatible con Microsoft
- Fiable y evita reinstalaciones repetidas


¿Cómo se implementa este método?


Paso 1: Preparar el archivo de instalación

1. Copie el instalador en una unidad compartida de red accesible: (Asegúrese de que la ruta sea accesible para «Todos» o «Equipos del dominio» en modo de lectura).

\\SERVIDOR\IMPLANTACIÓN\Medulla-Agent-windows-FULL-latest.exe

Cree un script de PowerShell como este:

$CheminSetup = "\\SERVIDOR\IMPLANTACIÓN\Medulla-Agent-windows-FULL-latest.exe"
$Arguments = "/S"

$NombreDelServicio = "medullaagent" 

$ServiceStatus = Get-Service -Name $NomDuService -ErrorAction SilentlyContinue

if ($ServiceStatus) {
    Write-Output "El servicio $NombreDelServicio ya existe. Instalación cancelada."
    Exit 0
}

try {
    Start-Process -FilePath $RutaDeInstalación -ArgumentList $Argumentos -Wait -NoNewWindow -ErrorAction Stop
}
catch {
    Write-Error "Error de instalación: $_"
    Exit 1
}


2. Configure los permisos del recurso compartido:
   - Lecturapara el grupo Domain Computers


Paso 2: Crear el GPO


1. Abra la consolade administración de directivas de grupo
2. Cree un nuevo GPO, por ejemplo: `Implementación del agente Medulla`


Paso 3: Configurar la tarea programada

1. Edite el GPO y vaya a:

Configuración del equipo
   → Preferencias
   → Panel de control
   → Tareas programadas

2. Haz clic con el botón derecho →Nuevo →Tarea inmediata (al menos en Windows 7)


3. En la pestaña General:
   - Nombre: `Instalación del agente Medulla`
   - Cuenta: SYSTEM
   - Ejecutar con los privilegios más altos


4. En la pestañaAcciones:


Paso 4: Aplicar la GPO


1. Vincule la GPO ala Unidad de Organización (OU)que contiene sus equipos
2. En un equipo de prueba, ejecute:

gpupdate /force


3. Reinicie el equipo o espere a la próxima actualización de políticas

Atención: siempre es obligatorio reiniciar los equipos tras la instalación del agente; el GPO, por defecto, no reinicia el equipo por sí solo. Por lo tanto, hay que tener en cuenta que cada equipo debe reiniciarse tras la instalación del agente.


¿Por qué no utilizar un script de inicio o de inicio de sesión?


Los scripts tradicionales (Startup Script o Logon Script) presentan varias desventajas:
- Riesgo de ejecución múltiple
- Dificultad para detectar si la instalación ya se ha realizado
- Problemas de permisos según el contexto de ejecución
- Menos fiables que las tareas programadas de GPP


El método mediante tareas programadas GPP resuelve todos estos problemas.


¿Qué hace la opción «Apply once and do not reapply»?


Esta opción garantiza que:
- La tarea se ejecuteuna sola vezen cada equipo
- Aunque el GPO permanezca activo durante años, la instalación no se vuelve a ejecutar
- No se necesita un script de detección complejo
- No se producen reinstalaciones accidentales


Es el equivalente a una implementación «fire and forget» (lanzar y olvidar).

Con la opción «Apply once and do not reapply», es imprescindible comprobar que el agente se ha instalado correctamente. Si la instalación ha fallado durante el proceso, no se volverá a ejecutar.

Puede desactivar esta opción ( «Apply once and do not reapply») para evitar problemas de instalación del agente, pero mantener la parte IF en el script de PowerShell que comprueba si el servicio medullaagent está presente (por defecto, ya presente en el script anterior):

if ($ServiceStatus) {
    Write-Output "El servicio $NomDuService ya existe. Instalación cancelada."
    Exit 0
}

¿Cómo comprobar que la implementación ha funcionado?


En un equipo cliente:

1. Comprueba que se ha creado la tarea programada:

Panel de control → Herramientas administrativas → Programador de tareas

Busque la tarea «Instalación del agente Medulla»

2. Compruebe los registros de instalación del agente Medulla

3. Compruebe que el equipo aparece en la consola de Medulla


En el controlador de dominio:


Utilice los informes de GPO para ver qué equipos han aplicado la política.


¿Puedo utilizar este método para actualizar el agente?


Por defecto, el agente se actualiza automáticamente, pero si no es así, sí, aunque con algunas precisiones:


- Si crea un nuevo GPO con un nuevo nombre de tarea, se ejecutará una vez en todos los equipos (si «Apply once» está activado)
- Si modifica la ruta del archivo EXE en la tarea existente con «Apply once», no se volverá a ejecutar ( ese es el objetivo de esta opción)


Para las actualizaciones, es preferible:
1. Crear un nuevo GPO con un nuevo nombre de tarea para cada versión principal
2. O utilizar el sistema de actualización integrado de Medulla


¿Cuáles son los requisitos previos?


- Un controlador de dominio de Active Directory (Windows Server 2008 R2 o superior)
- Un recurso compartido de red al que los equipos puedan acceder en modo de lectura
- El instalador del agente de Medulla con la opción de instalación silenciosa (`/S`)
- Permisos para crear y vincular GPO


¿Cuánto tiempo se tarda en implementar todos los equipos?


La implementación se realiza al ritmo de la actualización de las políticas de grupo:
- Por defecto: cada90 minutos(con un desfase aleatorio de 0 a 30 minutos)
- Al reiniciar el equipo
- Con `gpupdate /force` (inmediato)


Para una implementación rápida en un parque de 100 equipos, calcule entre2 y 4 horas, dependiendo de la actividad de la red.

Ejecutar la instalación tras iniciar sesión

La ejecución habitual de un GPO se realiza antes de iniciar sesión con privilegios de SYSTEM.

Esto puede resultar molesto para el usuario, que puede pensar que su ordenador se ha bloqueado.

Solución 1: La tarea programada «Al iniciar la sesión»

El usuario accede a su escritorio y la instalación se inicia de forma silenciosa en segundo plano con derechos de SYSTEM.

  1. En su GPO de equipo (no de usuario), vaya a: Preferencias > Configuración del Panel de control > Tareas programadas.

  2. Nuevo > Tarea programada (al menos en Windows 7).

  3. Pestaña General:

    • Cuenta de usuario: NT AUTHORITY\SYSTEM (o simplemente escribe SYSTEM).

    • Marque la casilla Ejecutar con los permisos máximos.

  4. Pestaña Desencadenantes (Triggers):

    • Nuevo > Al iniciar sesión (At log on).

    • Puede elegir «Cualquier usuario».

  5. Pestaña Acciones:

    • Programa: ruta_de_instalación_powershell/powershell.exe/powershell.exe

    • Argumentos: -ExecutionPolicy Bypass -File "\\Servidor\Compartido\SCRIPT_POWERSHELL.ps1"

SCRIPT_POWERSHELL.PS1, corresponde al script que aparece al principio de la página y que permite instalar el agente de forma silenciosa.

Solución 2: La opción «Asíncrono»

Si desea conservar su script actual (en «Scripts de inicio») pero simplemente dejar de bloquear la pantalla «Por favor, espere...»:

  1. Vaya a la GPO: Configuración del equipo > Plantillas de administración > Sistema > Scripts.

  2. Busque el parámetro: Ejecutar scripts de inicio de forma asíncrona.

  3. Póngalo en Activado.

Nota: Si crea una tarea con un desencadenador «Al iniciar sesión» y marca «Aplicar una vez y no volver a aplicar», el GPO creará la tarea una vez, perola tarea permanecerá en el PC y seguirá ejecutándose cada vez que se inicie sesión. Asegúrate, por tanto, de mantener la condiciónIF en el script que permite verificar la presencia del servicio medullaagent (por defecto, ya presente en el script anterior):

if ($ServiceStatus) {
    Write-Output "El servicio $NomDuService ya existe. Instalación cancelada."
    Exit 0
}


Recursos adicionales


- [Documentación oficial de Microsoft sobre las preferencias de directiva de grupo](https://docs.microsoft.com/fr-fr/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn581922(v=ws.11))
- [Documentación de implementación de Medulla](https://medulla-project.org/)


---


Fecha de creación: diciembre de 2024  
Autor: Documentación de Medulla  
Versión: 1.0

Preguntas frecuentes: Agentes

Reconfigurar mi agente

Aplicable a:Medulla – Agente
Versión: Todas
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Agente Medulla

Puede reconfigurar el agente para cambiar el nombre DNS con el que debe comunicarse, pero también es posible modificar varios otros parámetros. 

Esta es la ubicación del agente en el servidor:
/var/lib/pulse2/clients/

Encontrará un script llamado: generate-pulse-agent.sh. Si lo ejecuta pasando el parámetro --help, obtendrá todos los parámetros modificables:

./generate-pulse-agent.sh --help
Uso:
./generate-pulse-agent.sh [--conf-xmppserver=<servidor de configuración XMPP>]
         [--conf-xmppport=<puerto del servidor de configuración XMPP>]
         [--conf-xmpppasswd=<contraseña del servidor de configuración XMPP>]
         [--aes-key=<PSK AES de 32 caracteres>]
         [--xmpp-passwd=<contraseña del servidor XMPP>]
         [--chat-domain=<dominio XMPP>]
         [--inventory-tag=<Etiqueta añadida al inventario>]
         [--minimal [--base-url=<URL desde la que descargar el agente y las dependencias>]]
         [--disable-vnc (Desactivar el servidor VNC)]
         [--vnc-port=<Puerto predeterminado 5900>]
         [--vnc-password=<Contraseña VNC cifrada con DES>]
         [--ssh-port=<Puerto predeterminado 22>]
         [--disable-rdp (Desactivar la configuración de RDP)]
         [--disable-inventory (Desactivar Fusion Inventory)]
         [--disable-geoloc (Desactivar la geolocalización, por ejemplo, en equipos que no tienen acceso a Internet)]
         [--linux-distros (Distribuciones de Linux utilizadas)]
         [--updateserver (URL de descarga para las actualizaciones del agente)]

Ejemplos:

Servidor XMPP

Para reconfigurar la entrada DNS de contacto del equipo (servidor al que debe conectarse el equipo):

./generate-pulse-agent.sh --conf-xmppserver monserver.dominio.fr

Puerto SSH

Para modificar el puerto SSH de contacto del servidor:

./generate-pulse-agent.sh --ssh-port 2022

Si modifica el puerto SSH, siga también esta documentación:

https://docs.medulla-tech.io/books/medulla-faq/draft/497

Desactivar VNC

Para desactivar VNC en tus agentes:

./generate-pulse-agent.sh --disable-vnc

Desactivar RDP

Para desactivar RDP en sus agentes:

./generate-pulse-agent.sh --disable-rdp

Preguntas frecuentes: Agentes

Generar agentes para Windows y Linux

Aplicable a: Medulla – Agentes
. Versión: Todas
. Entorno: On-Premise / SaaS privado / SaaS compartido
. Categoría: Agentes / Soporte

Antes de generar los agentes para sus equipos Windows o Linux, es importante definir su estrategia de vinculación en GLPI:

Generar un agente por entidad

Para generar un agente distinto por entidad GLPI:

generate_medulla_agent.sh all force

A continuación, compruebe que cada entidad dispone de su agente:

ls /var/lib/pulse2/medulla_agent/*

Cada entidad está asociada a una etiqueta. Encontrará un directorio por etiqueta que contiene los agentes correspondientes.

Generar un agente global

Para generar un único agente por sistema operativo (vinculado a la entidad principal GLPI):

/var/lib/pulse2/clients/generate-pulse-agent.sh

A continuación, compruebe la presencia de los agentes:

ls /var/lib/pulse2/clients/win/
ls /var/lib/pulse2/clients/lin/

Generar un agente sin inventario GLPI

Esta opción requiere Medulla y el agente en la versión 5.5.2 o superior.

/var/lib/pulse2/clients/generate-pulse-agent.sh --disable-inventory

Gestión de entidades con un agente global

Si utiliza un agente global pero desea distribuir los equipos en diferentes entidades GLPI, hay dos opciones posibles:

Preguntas frecuentes: Agentes

Agentes de la distribución Linux MINT

Aplicable a:Medulla – Agente
Versión: inferior a 5.5.1 
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Agente Medulla

En la versión 5.5.1 de Medulla, la compatibilidad con la versión Linux MINT será nativa.

Para las versiones anteriores a la 5.5.1, para poder instalar el agente Medulla en la distribución Linux Mint, basta con seguir los pasos que se indican a continuación.

Todos los comandos deben ejecutarse como root.

Para ello, escribe: una vez conectado a tu cuenta de usuario. Otro método consiste en añadir «sudo» delante de cada comando.

sudo su - 

Se le pedirá una contraseña; introdúzcala.

Descargue el script de instalación del agente desde su equipo Linux correspondiente 

wget https://serveur/downloads/lin/Medulla-Agent-linux-MINIMAL-latest.sh

Escriba los siguientes comandos: 

chmod u+x Medulla-Agent-linux-MINIMAL-latest.sh

Modifique el script añadiendo la sección linuxmint en los siguientes lugares: 

Líneas 50-51: 

case "$DISTRO" in
        debian|ubuntu|zorin)

Modifica la línea añadiendo |linuxmint después de zorin.

case "$DISTRO" in
        debian|ubuntu|zorin|linuxmint)

A continuación 

Líneas 215-216

case "$DISTRO" in
    ubuntu|zorin)

Modifica la línea añadiendo |linuxmint después de zorin

case "$DISTRO" in
    ubuntu|zorin|linuxmint) 

Añade después de la línea 63 el siguiente comando: 

apt update

Guarde su script.

Ejecute el comando para ejecutar el script de instalación: 

./Medulla-Agent-linux-MINIMAL-latest.sh

Se llevará a cabo la instalación y aparecerá el siguiente resultado en su equipo.

image.png

Preguntas frecuentes: Agentes

Desinstalación del agente Medulla (versiones anteriores a la 5.5.2)

Aplicable a: Medulla – Agente
Versión: inferior a 5.5.2 
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Agente Medulla

Para desinstalar el agente Medulla: 

Haga clic en el menú Inicio de Windows y, a continuación, en Configuración 

Screenshot 2026-04-23 152446.png

A continuación, vaya al menú de la izquierda de sus ajustes y haga clic en Aplicaciones:

Screenshot 2026-04-23 152554.png

Haga clic en el menú de la derecha en «Aplicaciones instaladas»

Desplácese hacia abajo por la lista de aplicaciones hasta encontrar la entrada «Medulla Agent».

Screenshot 2026-04-23 152634.png

Haga clic en  Screenshot 2026-04-23 152723.pngse abrirá un menú desplegable con Modificar / Desinstalar.

Haga clic en Desinstalar

Se le pedirá una confirmación; vuelva a hacer clic en el botón Desinstalar 

Screenshot 2026-04-23 152755.png

El agente Medulla desinstalará sus componentes mediante un ejecutable que aparecerá en su pantalla: 

Screenshot 2026-04-23 152830.png

Una vez completada la desinstalación, haz clic en el botón Cerrar 

Screenshot 2026-04-23 152917.png

En el menú de aplicaciones solo quedarán estas dos entradas: 

Screenshot 2026-04-23 152940.png

Se trata de dos entradas del Registro. Para eliminarlas: 

Vuelva al menú de inicio de Windows.

Escriba «regedit» en la barra de búsqueda y pulse Intro

Desplácese por el árbol: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Busca la primera clave de registro «Medulla Extract Drivers». Haz clic con el botón derecho del ratón en el icono de carpeta de esta clave y selecciona «Eliminar»; a continuación, confirma la acción.

Screenshot 2026-04-23 155414.png

Haz lo mismo con «Medulla Update Info».


Preguntas frecuentes: Agentes

Desinstalación del agente Medulla versión 5.5.2 y superiores

Aplicable a:Medulla – Agente
Versión: 5.5.2 y posteriores
Entorno: On-Premise / SaaS privado / SaaS compartido
Categoría: Agente Medulla

Windows:

Hay un script disponible en su servidor Medulla: 

https://votreserveur/downloads/win/uninstall-medulla-agent-windows.ps1

Abre una consola de PowerShell con derechos de administrador. Asegúrate de que PowerShell esté configurado para ejecutar scripts: 

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Responda [A] «Yes to all»

Pasos:
  1. Descargue el script uninstall-medulla-agent-windows.ps1 en el equipo.
  2. Ejecute el script según los casos que desee gestionar: 
.\uninstall-medulla-agent.ps1 
.\uninstall-medulla-agent.ps1 -RemoveGLPI:$true
.\uninstall-medulla-agent.ps1 -RemoveGLPI:$true -RemoveTightVNC:$true
.\uninstall-medulla-agent.ps1 -RemovePython:$true -RemoveGLPI:$true -RemoveTightVNC:$true

Hay una opción disponible, -SILENT, que permite iniciar la desinstalación en modo silencioso en cada caso.

Linux:

Hay un script disponible en su servidor Medulla: 

https://votreserveur/downloads/win/uninstall-medulla-agent-linux.sh

El script se ejecuta como root o mediante el comando sudo:

escriba los siguientes comandos: 

wget https://votreserveur/downloads/win/uninstall-medulla-agent-linux.sh
chmod u+x uninstall-medulla-agent-linux.sh
Desinstalación básica (sin Python ni GLPI)

./uninstall-medulla-agent-linux.sh

Con Python 3.11 

./uninstall-medulla-agent-linux.sh --remove-python

Con GLPI Agent 

./uninstall-medulla-agent-linux.sh --remove-glpi

Eliminar todo 

./uninstall-medulla-agent-linux.sh --remove-python --remove-glpi

Preguntas frecuentes - Infraestructura de Medulla

Preguntas frecuentes - Infraestructura de Medulla

Arquitectura e implementación de los servidores de retransmisión de Medulla

Los servidores de retransmisión son componentes locales diseñados para optimizar la distribución de recursos y la comunicación entre los agentes y el servidor principalde Medulla.

1. El relé clásico (LAN / red privada)

El relé clásico se instala dentro de la red de la empresa. Su objetivo es servir de «caché» local y de punto de distribución para los agentes ubicados en el mismo sitio o en el mismo segmento de red.

2. El relé DMZ (Exposición pública)

El relé DMZ es una pasarela segura entre Internet y el servidor principal de Medulla.

3. Dimensionamiento (Especificaciones técnicas)

Los requisitos de hardware son idénticos para ambas funciones, pero su función de software diferirá durante la configuración.

A. Servidor(es) de retransmisión (LAN)

Componente Especificación recomendada
SO Debian 12.x
Arquitectura X86-64
CPU 4 núcleos
RAM 8 GB
Partición / 20 GB (EXT4)
Partición /var ≥ 400 GB (XFS) o punto de montaje en la bahía

B. Servidor de retransmisión DMZ (terminales móviles)

Componente Especificaciones recomendadas
SO Debian 12.x
Arquitectura X86-64
CPU 4 núcleos
RAM 8 GB
Partición / 20 GB (EXT4)
Partición /var ≥ 200 GB (XFS) o punto de montaje en la bahía
4. Resumen de decisión

Esta tabla le permite determinar qué tipo de servidor implementar según su situación:

Condición Tipo de relé necesario Motivo principal
Parque > 5000 puestos en una misma red Relé clásico (LAN) Reducción de la carga de CPU/RAM del servidor principal Medulla.
Sitio remoto (red diferente sin conexión LAN transparente) Relé clásico (LAN) Permitir la creación de imágenes locales y ahorrar ancho de banda WAN.
Terminales móviles (teletrabajo, fuera de la red privada, sin VPN) Relé DMZ Garantizar la comunicación de los agentes a través de Internet de forma totalmente segura.
Sitios interconectados (enlace privado de alta velocidad, flujos LAN autorizados) Ninguno (opcional) El servidor principal puede controlar todo el sistema, incluida la creación de imágenes.
Preguntas frecuentes - Infraestructura de Medulla

Procedimiento para añadir relés a Medulla SaaS dedicado

1. Creación del servidor

Requisitos del sistema:

2. Creación de un usuario

Crea el usuario «medulla» y asígnale derechos de sudo.

3. Instalación de la clave SSH

La clave pública SSH, que se adjunta, debe añadirse en:

/home/medulla/.ssh/authorized_keys

4. Apertura de los flujos de red

Los flujos deben estar abiertos en ambos sentidos entre:

4.1. Flujo Servidor Medulla → Relé

Puerto | Descripción

4.2. Flujo de retransmisión → Servidor Medulla

Puerto | Descripción

5. Información que debe facilitarnos

El equipo debe proporcionarnos:

6. Continuación de la instalación

Una vez que la máquina esté lista, realizaremos la instalación completa del software mediante Ansible.

Se generará automáticamente un agente Medulla para conectar los equipos a este servidor de retransmisión.

Preguntas frecuentes - Infraestructura de Medulla

Actualización de Medulla: de la versión 5.4.x a la 5.5.x

Medulla / 5.4.x / Actualización de Medulla a la versión 5.5.x / Mantenimiento de Medulla

Para actualizar de la versión 5.4.X a la 5.5.x y superiores, siga los pasos que se indican a continuación: 

Descargue el archivo en el servidor Medulla:

curl https://dl.medulla-tech.io/up/update_medulla.sh

Otorgue permisos de ejecución al script: 

chmod +x update_medulla.sh

Ejecuta la actualización: 

./update_medulla.sh

Una vez completado el proceso, vuelve a la interfaz de Medulla.

Todos los comandos se ejecutan como root o con una cuenta que tenga derechos de administrador.

Extranet de asistencia

Si desea crear una cuenta de soporte para usted o para uno de sus colaboradores tras haber suscrito un contrato de soporte de Medulla, nada más sencillo: visite https://extranet.medulla-tech.io/portal/

Haga clic en «¿Ha olvidado su contraseña?» e introduzca su correo electrónico y su nombre de usuario (nombre + apellidos). 

 

image.png

Fail2ban

¿Qué es Fail2Ban?

Fail2Ban es una herramienta de prevención contra intrusiones que supervisa los intentos de conexión sospechosos en los registros del sistema (logs) y que puede implementarse en su infraestructura local.

¿Qué bloquea exactamente?

Fail2Ban protege principalmente contra ataques de tipo «Brute Force» (fuerza bruta).

Para decidir si una actividad es maliciosa, Fail2Ban analiza los intentos de conexión e identifica patrones específicos. Estos son los errores comunes que desencadenan una alerta y un bloqueo:

Si una IP genera 5 fallos en un intervalo de 10 minutos, se bloquea durante 10 minutos.

Instalación del sistema operativo Debian para el servidor Medulla

Características técnicas

Requisitos previos – Dimensionamiento de los servidores

Servidor principal

SO

Debian 12.x

Arquitectura

X86-64

CPU

8 núcleos

RAM

8 GB

Partición /

20 GB en EXT4

Partición /var

400 GB como mínimo en XFS o punto de montaje en una bahía de almacenamiento

Servidores de retransmisión multisitio

(si procede)

SO

Debian 12.x

Arquitectura

X86-64

CPU

4 núcleos

RAM

8 GB

Partición /

20 GB en EXT4

Partición /var

400 GB como mínimo en XFS o punto de montaje en una bahía de almacenamiento

Instalación del servidor Debian

Resumen:

- Separar solo /var de / y ponerlos en LVM

- Instalar el servidor SSH y las utilidades estándar del sistema

- No instalar ningún antivirus ni cortafuegos

- Definir una cuenta que

o pueda ejecutar sudo sin contraseña

o pueda conectarse desde la IP 94.130.207.190

o pueda conectarse con la siguiente clave:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCScgwfwJKM5BtgzAYu6FEeJ5jW3onkzFp8D8piLR22kWbRcT/AJ1z0jhS5ZDtn6mumfidVPFbLkDf382u54pOU6JGwy9GhvEIXOSlzgxZMH5kcfeBE/8Ovr9zLtbRKsWQN9YUSt5y6lmcSxuQNVhkRy49/593oamVJACSitSVJ68716hj0gp4N8gUMVkvNgEBDZVSPe0DXz2h7JEzOKx2ejjRaw22ve+qARTw+60gMP0aCLGt/m0cyv+90AZigQwWIPcUk+bBRJn3Ku+Bkw+JuLYURlVc4xoTvT1JTWKXAzMln4nrlisIc9Ex5eEHSkvs/fgJCgU28Fza5n5mBj/pbQRY+/AWLjvBVuLiVReO7hq60fhrX9+j7MWMCYCZQiHbk/r7OprLyl2yGFX1DbgRGF1Sk2R9DtqRhwPzPxtQ7ZtKSjIhLjrZxJ/YJLHSoUsw+4CHprjzU0gXBt1RCQoyhYqEGcnuFyfd9dIBXCINkmp4jfz7CQjrC8uPqAtS1zQU= support@support

Configuración de la partición de discos

Particione los discos siguiendo las instrucciones que se indican a continuación:

Realizar una partición manual

RXi6qfZ9PswkCuWM-embedded-image-k3kebzpb.png

8te0UWcUdspzZBMb-embedded-image-ympc4spb.png

VmC09oQIVFslMAOG-embedded-image-qvsjgdgq.png

Creación de la partición /boot

IwEnXmeZzAnsDTC7-embedded-image-w4xke79q.png

TV5wT18WD9OYAcqi-embedded-image-dwbr5kuq.png

0qRqYiNJCdllwSJ9-embedded-image-qgdzniyl.png

KINj9qRDPfRiYZqh-embedded-image-lxe8vm2c.png

QTGvfLswyCwFcQx5-embedded-image-ogg9lntv.png

gTD9G2rs5dtUG0r5-embedded-image-kwrl6wtl.png

Creación del LVM

Hdz8G7I7yGDXCNMs-embedded-image-rmqzlrgh.png

yMZHBmMiH2vXFpfy-embedded-image-5sakjhab.png

ZLmjvxT9xxd4XlQB-embedded-image-ah2je5fw.png

efACs6NK7Gbp3yNK-embedded-image-iksbohcj.png

navXOvvK11MzaJFx-embedded-image-dt6vkkmg.png

xujPjspeZkZypAVT-embedded-image-fzhrvved.png

UAzAjpCcJyNLYOmb-embedded-image-sbnedsji.png

Creación del grupo de volúmenes vg

DYQK1prhJbIJVCL2-embedded-image-dpriouo9.png

FrJtSW6vic2PpAbj-embedded-image-ratkesnt.png

qeCGGIlWZ2t77JeH-embedded-image-guaasj24.png

Creación del volumen lógico lvroot

oNaJ3t4UQqkEJ7Ez-embedded-image-hu8ybn2n.png

cYmQl6BuhZPZp7fF-embedded-image-wo63hn3s.png

peBSVAHNJOnmb1II-embedded-image-cchq1b6n.png

vROib7ewmIUJYcuA-embedded-image-glmzrnrc.png

Repetir para los volúmenes lvswap y lvvar

DquKSa2Mtlq0gG5R-embedded-image-snhvcaj6.png

KZcKrmFHAJpUMTLP-embedded-image-ntgqhdgq.png

uYVhoMDThRZGqQR6-embedded-image-jkza0twt.png

AEJKbB4FLVGOYwZK-embedded-image-93rhaz1w.png

Para obtener el siguiente esquema LVM:

wiN6RiAoqlWTTpO7-embedded-image-tjy0unp9.png

IyN684C1YqNlTixG-embedded-image-tlhdjfw0.png

Configurar la partición /

5KxhfcV0spUh97la-embedded-image-rjjlj3ry.png

z4trMBsNo0krFnQQ-embedded-image-zmal04r3.png

Repetir para cada una de las particiones swap y /var:

X6XNDXKhchm0A1Nx-embedded-image-ubsfnaop.png

BkApQxifsvygZxQL-embedded-image-3hqodqtd.png

Para obtener el siguiente esquema de particiones:

E0KfH5OcMAkGBumZ-embedded-image-ugnmmpfl.png

Instalación de los paquetes

ZdgL7U9FlIpckFMo-embedded-image-4c0bkbzl.png

 

 

Comprobación del servidor

1. Descargar el script de verificación desde https://dl.medulla-tech.io/nc/check_server_before_install.sh

wget https://dl.medulla-tech.io/nc/check_server_before_install.sh


2. Ejecuta los siguientes comandos:

chmod +x check_server_before_install.sh

./check_server_before_install.sh

3.    

Todas las pruebas del script deben dar resultado correcto; una vez hecho esto, puede descargar el script de instalación a través del formulario de contacto:

https://github.com/medulla-tech/medulla/blob/master/README.fr.md

Si dispone de un contrato de asistencia técnica, envíe el resultado a delivery@medulla-tech.io. Si no es así, póngase en contacto con el departamento de «ventas» a través de nuestra página webmedulla-tech.io.

Estos son los errores más comunes:

1. Límites de Core Dump (limits)

Contexto: El archivo /etc/security/limits.d/10-coredump-debian.conf define el tamaño máximo de los archivos «core dump». Nuestro script espera valores específicos que no se corresponden con la configuración actual.

Cómo solucionarlo: Modifique el archivo mencionado para que se ajuste a lo esperado.

  1. Abra el archivo: sudo nano /etc/security/limits.d/10-coredump-debian.conf

  2. Modifique las líneas para que queden así:

    • * hard core infinity

    • root hard core infinity

    • * soft core 0

    • root soft core 0

Fuentes recomendadas: Documentación de Debian sobre limits.conf y core dump.

2. Número de archivos abiertos (lsof)

Contexto: Las líneas de lsof correspondientes a los usuarios xxx y messagebus indican que el número de archivos abiertos actualmente se desvía del valor esperado por el script de verificación (a menudo porque hay servicios ya en ejecución o mal configurados).

Cómo solucionarlo: A menudo es solo informativo, pero si necesitas reducir estas cifras:

Fuentes recomendadas: Manual de lsof y gestión de descriptores de archivos en Linux.

3. Parámetros de systemd (NPROC y SIGPENDING)

Contexto: Los valores DefaultLimitNPROC (número máximo de procesos) y DefaultLimitSIGPENDING (señales en espera) deben ser31541. 

Cómo solucionarlo: Hay que forzar estos valores en la configuración global de systemd para que coincidan exactamente con lo esperado.

  1. Modifique el archivo de configuración: sudo nano /etc/systemd/system.conf

  2. Descomente o añada las siguientes líneas:

    • DefaultLimitNPROC=31541

    • DefaultLimitSIGPENDING=31541

  3. Recargue la configuración y reinicie (o utilice systemctl daemon-reexec).

Fuentes recomendadas: Documentación de systemd-system.conf en freedesktop.org.

Comprueba que el inventario se sincroniza correctamente con Medulla

Comprobaciones que deben realizarse en el equipo cliente (máquina en cuestión)

1) Compruebe si se ha generado correctamente el inventario
Ejecute:
dir c:\progra~1\medulla\tmp\inventory.txt*
Si no hay ningún archivoinventory.txtoinventory.txt.back, esto indica un problema en la generación del inventario.

2) Forzar la generación del inventario
Si el inventario no se genera automáticamente, ejecute:
"c:\progra~1\GLPI-Agent\glpi-agent.bat" --config=none --scan-profiles --backend-collect-timeout=120 --local="c:\progra~1\Medulla\tmp\inventory.txt"
Este comando devolverá un error explícito si la generación falla.
=> O bien averigua cómo resolver el error, o bien envía el resultado del comando asupport@medulla-tech.io

Comprobaciones que hay que realizar en el servidor Medulla

3) Compruebe la URL de transmisión del inventario a GLPI
Por favor, ejecute:
curl $(crudini --get /etc/pulse-xmpp-agent-substitute/agent_master_substitute_inv.ini.local glpi url_to_forward)
Un error aquí indicaría un problema de configuración o de accesibilidad de la URL.
=> O bien ve cómo resolver el error, o bien envía el resultado del comando asupport@medulla-tech.io

4) Compruebe si el equipo está correctamente registrado en GLPI
Ejecute lo siguiente (sustituyendo el nombre si es necesario):
mysql --defaults-group-suffix=itsm glpi -e "SELECT * FROM glpi_computers WHERE name='NOMBRE_DEL_ORDENADOR_CLIENTE'\G"
Si la consulta no devuelve ningún resultado, el equipo no se ha registrado en GLPI.
=> Desde Medulla, fuerce una solicitud de inventario desde la vista Ordenadores > Acción rápida > Ejecutar inventario para el equipo en cuestión

5) Compruebe el estado del equipo en la base de datos de Medulla
Ejecute:
mysql --defaults-group-suffix=medulla xmppmaster -e "SELECT jid, hostname, id_glpi, enabled FROM machines WHERE hostname='NOMBRE_POST_CLIENTE'\G"
Si el campoid_glpiestá vacío, significa que no se ha podido realizar la asociación entre Medulla y el inventario GLPI.
=> Desde Medulla, fuerce un nuevo registro del equipo desde la vista Ordenadores > Acción rápida > Comando personalizado Reconfigurar agente del equipo

=> Si el problema persiste, envíe el resultado de todos los comandos asupport@medulla-tech.io

Verificación de la configuración remota

Flujo de trabajo
Workflow Remote desktop.png

Registros

Operaciones de depuración

USE xmppmaster;
SELECT jid,
    hostname,
    machine_id,
    idguacamole,
    protocol
FROM machines
JOIN has_guacamole
ON machines.id = has_guacamole.machine_id
WHERE jid like '%nom_machine%';
Si la conexión no existe, volver a registrar la máquina
Si tras volver a registrar la máquina sigue sin haber conexión, compruebe que los protocolos estén bien activados en la máquina (VNC iniciado, RDP activado, demonio OpenSSH iniciado).
USE guacamole;
SELECT guacamole_connection.protocol as protocol,
    guacamole_connection.connection_id as connection_id, 
    parameter_name, 
    parameter_value
FROM guacamole_connection_parameter 
JOIN guacamole_connection 
ON guacamole_connection_parameter.connection_id = guacamole_connection.connection_id 
where guacamole_connection.connection_id = 6084964;

+----------+---------------+-----------------+-----------------+
| protocolo | id_conexión | nombre_parámetro  | valor_parámetro |
+----------+---------------+-----------------+-----------------+
| vnc      |       6084964 | color-depth     | 24              |
| vnc      |       6084964 | hostname        | localhost       |
| vnc      |       6084964 | listen-timeout  | 50000           |
| vnc      |       6084964 | port            | 47749           |
| vnc      |       6084964 | reverse-connect | true            |
+----------+---------------+-----------------+-----------------+
Si se realiza una conexión inversa (nombre de host = localhost), comprueba el establecimiento de la conexión ejecutando
netstat -vatpn | grep <puerto>
Si no aparece ninguna línea, habrá que depurar el reverse-SSH
SOPORTE - Reverse SSH - Soporte

En el equipo cliente, compruebe que el servidor VNC está a la escucha:
netstat -an | find "5500"
Si no es así, compruebe que TightVNC se esté ejecutando
En el equipo cliente, compruebe que el Reverse SSH se ha configurado correctamente:
netstat | find "ssh"
En el relé, compruebe que el SSH inverso esté correctamente establecido:
netstat -vatpn | grep sshd
Atención: el reverse se establece en un puerto aleatorio.
A continuación, se redirige el puerto de guacd del servidor al puerto 5500 del túnel. Esta redirección se realiza al configurar el reverse.
Véase el depuración del ssh inverso más arriba
En el relé, compruebe que guacd esté escuchando correctamente en el puerto indicado por los parámetros de guacamole (aquí 54775):
netstat -vatpn |grep guacd

Verificación de SSH inverso

Registros
Operaciones de depuración
En el cliente
El establecimiento de la conexión reverse SSH desde los clientes se realiza mediante los scripts
En Linux, es posible ejecutar estos scripts manualmente para comprobar el establecimiento del túnel. Consulte estos scripts para encontrar el número de puerto utilizado. Por ejemplo:
/usr/bin/ssh -t -t -R 51891:localhost:22 -o StrictHostKeyChecking=no -i "/var/li
b/pulse2/.ssh/id_rsa" -l reversessh 192.168.2.15 -p 22
En Windows, es imprescindible utilizar la consola MMC para disponer de depuración al realizar una implementación. Para ello, hay que detener el servicio OpenSSH desde una consola XMPP para forzar el establecimiento de la conexión reversessh:
sc stop sshdaemon

image (10).png

Inicie una implementación. En la vista de auditoría se mostrará el resultado del establecimiento de la conexión inversa:

image (11).png

Si el túnel no se establece, se trata de un problema de puerto o de claves

En el relé
El siguiente script permite comprobar el establecimiento del reverse en los ARS en el puerto definido (véase más arriba):
#!/bin/bash
echo "puerto $1"
echo "reverse existente"
netstat -an | egrep "tcp.*:$1.*LISTEN"
echo "reverse en uso"
netstat -an | egrep "tcp.*:$1.*ESTABLISHED"
echo "pid reverse"
lsof -t -i :$1 -s tcp:LISTEN
Se pueden ver los procesos de reversessh con:
ps aux | grep ssh
root 2267 0.0 0.1 95184 6860 ? Ss 15:26 0:00 sshd: reversessh [priv]
reverse+ 2280 0.0 0.0 95184 3868 ? S 15:26 0:00 sshd: reversessh@pts/7

en Windows:
tasklist | findstr ssh

Imágenes - Davos Debug

Inicie Davos y pulse CTRL+C

A partir de aquí hay dos opciones: conexión local o SSH

Conexión local:
# en la consola de Davos
sudo su
dpkg-reconfigure keyboard-configuration
systemctl restart keyboard-setup
python3

Conexión SSH:
Primero, obtener la IP del equipo y, a continuación, desde el servidor de retransmisión:
ssh user@<IP>
 Contraseña: live
sudo su
python3

from davos import davosManager
from davos.inventory import Inventory

davos = davosManager()
inv = Inventory(davos)
#
# Introduce el nombre de host en la entrada
# esto enviará el xml a pulse2-register-pxe

print("dirección MAC: {}".format(inv.macaddress))
print("dirección IP: {}".format(inv.ipaddress))
print("máscara de red: {}".format(inv.netmask))
print("disco: {}".format(inv.disk)) 

# El inventario (sin modificar) se encuentra en:
less /tmp/inventory.xml
# Debe faltar una barra entre «tmp» y «macaddress», lo que hace que el archivo se genere en /
/tmp<macaddress.xml

from davos import davosManager
from davos.image_saver import imageSaver

davos = davosManager()
saver = imageSaver(davos)
saver.start()
Guardar la copia de seguridad:
saver.imaging_api.imageDone(saver.manager.mac, saver.image_uuid)

from davos import davosManager
from davos.image_restorer import imageRestorer

davos = davosManager()
img = imageRestorer(davos, "unicast")
Para iniciar una restauración completa:
img.start()
Para ejecutar solo las postinstalaciones
img.run_postimaging()
Los registros de Davos se encuentran en:
/var/log/davos.log
/var/log/davos_restorer.log

Los registros de las postinstalaciones se encuentran en:
/tmp/postinst.xxx.log

Las postinstalaciones se encuentran en /imaging_server/masters/<uuid_del_master>/postinst.d/
 El uuid_del_master se puede recuperar de la tabla imaging.Image en la base de datos.

Imágenes - Depuración

1. Recuperación del arranque

Configurar el tftp en modo detallado:
En /etc/default/tftpd-hpa, añada -v al parámetro TFTP_OPTIONS y reinicie el servicio tftpd-hpa
En los registros de tftp (/var/log/syslog o journalctl --unit tftpd-hpa --follow), localice estas líneas:
in.tftpd[491332]: RRQ desde 10.104.108.113, nombre de archivo bootloader-uefi64/ipxe.efi
in.tftpd[491333]: RRQ desde 10.104.108.113, nombre de archivo bootloader-uefi64/autoexec.ipxe
Si estas líneas no existen, se trata de un problema de DHCP

Para depurar el TFTP, captura las tramas:
tcpdump -s 0 host <IP_DEL_CLIENTE> y udp
Para probar una conexión TFTP: 
tftp <IP_DEL_SERVIDOR> get bootloader-uefi64/ipxe.efi

2. Recuperación del menú de arranque
En los registros de Apache, localice esta línea:
"GET /mmc/imaging/bootmenu.php?mac=54:bf:64:5c:77:25&uuid=4c4c4544-0057-3210-8053-c4c04f4b5132&srv=10.104.1.20 HTTP/1.1" 200 3717 "-" "iPXE/1.21.1+ (gdd35
)"
Si no existe, se trata de un problema de acceso al servidor Apache

3. Recuperación de Davos
En los registros de Apache, localice estas líneas:
"GET /downloads/davos/ipxe.png HTTP/1.1" 404 489 "-" "iPXE/1.21.1+ (gdd35)"
"GET /downloads/davos/vmlinuz HTTP/1.1" 200 15403668 "-" "iPXE/1.21.1+ (gdd35)"
"GET /downloads/davos/initrd.img HTTP/1.1" 200 64921280 "-" "iPXE/1.21.1+ (gdd35)"
"GET /downloads/davos/fs.squashfs HTTP/1.1" 200 1041178859 "-" "Wget"
Si no existen, se trata de un problema de acceso al servidor Apache


Una vez comprobados estos pasos, consulte «Debugger Davos»
Al llegar al menú PXE, si no encuentra la opción de registro, compruebe las siguientes líneas en los registros de tftpd-hpa:
En los registros de tftp (/var/log/syslog o journalctl --unit tftpd-hpa --follow), localice estas líneas:
in.tftpd[357001]: tftp: el cliente no acepta opciones

Si aparece esta línea, reinicie el servicio tftpd-hpa

systemctl restart tftpd-hpa

Si el problema persiste, compruebe si hay un servicio tftpd-hpa fantasma y reinicie el servidor. A continuación, reinicie de nuevo el servicio tftpd-hpa.

Guacamole - Depuración

Depuración de Guacamole

Durante la PMAD, Guacamole no se conecta al instante

Hecho:
journalctl -u tomcat9 -f
Probar una conexión.

Comprueba si aparece la línea:
[http-nio-8081-exec-9] WARN  o.a.g.r.auth.AuthenticationService - Falló el intento de autenticación desde [10.48.2
50.43, 127.0.0.1] para el usuario «root».

Si está presente:
systemctl restart tomcat9
journalctl -u tomcat9 -f

Compruebe si aparece la siguiente línea:
ERROR o.a.g.extension.ExtensionModule - No se ha podido cargar la extensión «guacamole-auth-jdbc-mysql-1.5.4.jar»: No se puede leer el contenido del directorio /etc/guacamole/lib

Si está presente:
chmod 755 /etc/guacamole/lib/

Optimización del tiempo de conexión para la puesta en marcha de los puestos.

Para reducir el tiempo de conexión al iniciar sesión en equipos remotos:

Compruebe los siguientes puntos: 


Una vez comprobados los puntos anteriores, si la conexión SSH inversa tarda menos de 30 segundos en establecerse, es posible reducir el tiempo de espera.

Esta modificación se realiza en el archivo /etc/mmc/mmc.ini.local.
Se deberá añadir una sección guacamole y definir el parámetro reversessh_timeout (en segundos).

Ejemplo para establecer el tiempo de espera en 20 segundos:

[guacamole]
reversessh_timeout = 20

A continuación, hay que reiniciar el servicio mmc-agent:

systemctl restart mmc-agent

La modificación de este parámetro está disponible a partir de la versión 5.5.1.

Duplicados de direcciones MAC

Si ha tenido problemas con algunos componentes instalados en su ordenador, como Fortinet, que registran una dirección MAC idéntica en todas las máquinas, esto provoca un problema en Medulla, ya que las máquinas registradas no se ubican en las entidades correctas y aparecen en GLPI con un UUID que ya existe para otra máquina: 

en el archivo /etc/pulse-xmpp-agent-substitute/registeryagent.ini.local

añada la siguiente sección y la siguiente información, respetando las mayúsculas y minúsculas.

[parameters]
blacklisted_mac_addresses = 00\:00\:00\:00\:00\:00, 00\:09\:0f\:aa\:00\:01

En /etc/pulse-xmpp-agent-substitute/registeryagent.ini.local, añade las direcciones MAC que quieras incluir en la lista negra

Es necesario que 00\:00\:00\:00\:00\:00 esté presente
Los caracteres : deben escaparse y las direcciones deben separarse con comas