# Preguntas frecuentes - OnPremise # Implementación (teledifusión) ##### **¿Por qué mis implementaciones permanecen bloqueadas en «Pending»?** - El estado «Pending» indica que las implementaciones se procesarán en breve; si el bloqueo persiste, póngase en contacto con el servicio de asistencia o con su administrador. ##### **¿Por qué mis implementaciones permanecen bloqueadas en «Deployment Start»?** - El estado «Deployment Start» indica que las implementaciones se procesarán en breve; si el bloqueo persiste, póngase en contacto con el servicio de asistencia o con su administrador. ##### **¿Qué hacer en caso de error de implementación: «Abort Package Execution»?** - Debe comprobar el script vinculado al paquete; el error indica que no se está ejecutando correctamente. Puede intentar ejecutar el script manualmente en su equipo. - Compruebe el resultado de la auditoría de la implementación, ya que puede dar pistas sobre el motivo del error. ##### **¿Qué hacer en caso de error de implementación: «Transfer Failed»?** - Tu ordenador no puede recuperar el paquete debido a Rsync. Comprueba los permisos de Rsync en varias carpetas para el usuario pulseuser; los permisos deben configurarse de la siguiente manera: ```bash 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?** - Si sus implementaciones tardan en iniciarse, es posible que su implementación en cola se vea ralentizada por la carga actual de la plataforma SaaS. - Si tus implementaciones se quedan bloqueadas, ponte en contacto con el servicio de asistencia o con tu administrador. ##### **¿Cómo detener una implementación?** - Dispone de un botón «Stop Deploy» en la vista de auditoría de una implementación para detener la implementación en curso. ##### **¿Cómo puedo ver el resultado de mi implementación?** - En la vista «Auditoría» puede encontrar la lista de todas sus implementaciones. Haga clic en el botón de acción « ![image.png](https://docs.medulla-tech.io/uploads/images/gallery/2026-03/zSKpQNwMzhay8YzM-image.png) » «Mostrar detalles de la implementación» para ver su implementación. ##### **¿Cómo reiniciar una implementación?** - En la vista «Auditoría», busque la línea correspondiente a la implementación que desea reiniciar y, a continuación, haga clic en el botón de acción ![image.png](https://docs.medulla-tech.io/uploads/images/gallery/2026-03/cmOVFn2XFI8THgx3-image.png) para reiniciar la implementación. # Mantenimiento remoto y puesta en marcha ##### **¿Qué hacer si el control remoto (VNC/RDP/PMAD) no funciona?** - Compruebe el servicio TightVNC en los equipos que presentan problemas. - No se puede acceder al control remoto si el ordenador aparece como desconectado (en gris); si es así, compruebe el estado del servicio medullaagent en el equipo. - Si su puerto SSH predeterminado no es el 22, asegúrese de que el siguiente archivo incluya correctamente su IP y el puerto SSH que utiliza: **C:\\Program Files\\Medulla\\bin\\reversessh.bat** Si no es así, debe realizar una modificación en su servidor, en el archivo: **/etc/pulse-xmpp-agent/reverse\_ssh\_on.ini.local **Es necesario reiniciar el servicio pulse-xmpp-agent-relay.service - Si su infraestructura dispone de una dirección IP pública y el servidor no consigue conectarse a los equipos a través de una dirección IP privada o una VPN, la conexión se realiza entonces de forma **inversa**, desde el equipo hacia el servidor. Para comprobar el correcto funcionamiento de esta conexión, ejecute manualmente el siguiente script: `C:\Program Files\Medulla\bin\reversessh.bat` Esto le permitirá identificar posibles errores de conexión. # Prueba de FLUX Antes de instalar **Medulla**, es **esencial** verificar la comunicación entre:
- Su **servidor Medulla**, - su **relé** (si procede), - sus **máquinas cliente**.
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_debian.sh)
[https://dl.medulla-tech.io/nc/listen\_ports\_windows.ps1](https://dl.medulla-tech.io/nc/listen_ports_windows.ps1 "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_connection_check.sh "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/medulla_relay_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/windows_connection_check_signed.ps1) [https://dl.medulla-tech.io/nc/check\_connection\_ldap.sh](https://dl.medulla-tech.io/nc/check_connection_ldap.sh "https://dl.medulla-tech.io/nc/check_connection_ldap.sh") [https://dl.medulla-tech.io/nc/check\_connection\_glpi.sh](https://dl.medulla-tech.io/nc/check_connection_glpi.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](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/scaled-1680-/6Gs5mDYikDrAhhUU-image.png)](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/6Gs5mDYikDrAhhUU-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](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/scaled-1680-/vJOscUwLGmSGzsEU-image.png)](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/vJOscUwLGmSGzsEU-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é**
- **A. En el servidor de retransmisión (destino):** Inicie la escucha de los puertos. **(No realice este paso si Medulla ya está instalada o si utiliza SaaS)** ``` ./listen_ports_debian.sh -r ```
- **B. En el servidor Medulla (Origen):** Inicie la prueba de conexión. ``` ./medulla_connection_check.sh -r ```
**Sentido: Relé hacia servidor**
- **C. En el servidor Medulla (Destino):** Inicie la escucha de puertos. **(No realice este paso si Medulla ya está instalada o si utiliza SaaS)** ``` ./listen_ports_debian.sh -m ```
- **D. En el servidor de retransmisión (origen):** Ejecute la prueba de conexión. ``` ./medulla_relay_connection_check.sh -m ```
---
### 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**
- **A. En el equipo cliente (Destino):** Inicie la escucha. ``` .\listen_ports_windows.ps1 ```
- **B. En el servidor Medulla (Origen):** Inicie la prueba hacia la IP del equipo. ``` ./medulla_connection_check.sh -c client.example.com ```
**Sentido: Estación cliente hacia servidor**
- **C. En el servidor Medulla (destino):** Inicie la escucha. **(No realice este paso si Medulla ya está instalada o si utiliza SaaS)** ``` ./listen_ports_debian.sh -m ```
- **D. En el equipo cliente (origen):** Ejecute la prueba hacia la IP del servidor. ``` .\windows_connection_check_signed.ps1 -Target -Mode pulse ```
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**
- **A. En el equipo cliente (destino):** Inicie la escucha.
``` .\listen_ports_windows.ps1 ```
- **B. En el servidor de retransmisión (origen):** Inicie la prueba hacia la IP del equipo. ``` ./medulla_relay_connection_check.sh -c client.example.com ```
**Sentido: Estación cliente hacia el relé**
- **C. En el servidor de retransmisión (destino):** Inicie la escucha. **(No realice este paso si Medulla ya está instalada o si utiliza SaaS)** ``` ./listen_ports_debian.sh -r ```
- **D. En el equipo cliente (origen):** Ejecute la prueba hacia la IP del relé. ``` .\windows_connection_check_signed.ps1 -Target -Mode relay ```
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**
- **A. En el servidor Medulla DMZ (Destino):** Inicie la escucha. **(No realice este paso si Medulla ya está instalada o si utiliza SaaS)** ``` ./listen_ports_debian.sh -r ``` - **B. En el equipo cliente NOMÁDICO (Origen):** Inicie la prueba hacia la IP del servidor. ``` .\windows_connection_check_signed.ps1 -Target -Mode relay ```
### 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*)**
- **A. En el servidor Medulla:** Ejecute la prueba hacia la base de datos GLPI externa. ``` ./check_connection_glpi.sh DB_FQDN DB_USERNAME DB_PASSWORD DB_NAME_GLPI ```
### 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*)**
- **A. En el servidor Medulla:** Ejecute la prueba hacia el servidor LDAP externo. ``` ./check_connection_ldap.sh HOST PORT 'BIND_DN' 'PASSWORD' 'BASE_DN' ```
# 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: - **22**: SSH (acceso remoto y transferencias seguras) - **9**: Wake-on-LAN - **5900**: VNC (control remoto) - **3389**: RDP (conexión de Escritorio remoto) - **35621** y **35623**: Copias de seguridad - **5985** y **5986**: WinRM (gestión remota HTTP/HTTPS) **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.). # 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: - Para crear una imagen limpia, es necesario disponer de un equipo Windows recién instalado, sin haber completado las preguntas de OOBE. > *Debe iniciar la instalación de un equipo Windows y, cuando aparezca el OOBE, cancelarlo con: CTRL + SHIFT + F3* - Tenga a su disposición varios PC listos para ser implementados. También podemos proporcionarle imágenes maestras para determinados modelos de Windows; para ello, debe indicarnos los modelos de Windows que desea implementar. # 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. - **Función:** **Solo lectura** (`Read-Only`). - **Función:** Recupera información sobre el usuario y el grupo a través del protocolo **LDAP** (o LDAPS). - **Permisos necesarios:** Debe tener los derechos necesarios para realizar búsquedas y leer atributos de usuario en el directorio de Active Directory. - **Ubicación en la aplicación:** Los datos de identificación de esta cuenta se configurarán en el **archivo de configuración** de Medulla (información solicitada en el formulario de entrega). #### 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*). - **Función:** Derechos de registro de máquinas en el dominio. - **Función:** Permitir la adición de ordenadores al dominio de Active Directory. - **Permisos necesarios:** Debe tener el derecho **«Añadir estaciones de trabajo al dominio».** - **Integración en el proceso:** Esta cuenta será **integrada y utilizada por**`sysprep` para ejecutar la operación de unión al dominio durante el mastering del equipo. #### 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 para**la instalación remota del agente Medulla** a través de PowerShell, dirigiéndose a una **unidad organizativa (OU)** definida. - **Función:** Enumerar los equipos del AD y ejecutar scripts de PowerShell de forma remota con derechos delegados. - **Función:** enumerar los equipos del AD. Instalación y configuración del agente Medulla en los equipos cliente, dirigiéndose a los equipos de una UO específica. - **Permisos necesarios:** - **Derechos delegados sobre la UO de destino:** Debe tener derechos de modificación de los objetos `«Computer»` y derechos que permitan la ejecución de comandos de forma remota (a través de **WinRM** o una solución equivalente) en los equipos de la UO especificada. - **Acceso al recurso compartido de red:** si el script o el instalador del agente Medulla está almacenado en un recurso compartido, la cuenta debe tener derechos de **lectura** sobre dicho recurso compartido. - **Listar los equipos del AD: Debe**tener derechos para listar los equipos del AD con el fin de seleccionar aquellos en los que se debe instalar el agente. - **Uso:** Esta cuenta será utilizada por la aplicación Python para iniciar y validar la ejecución de los scripts de PowerShell en los equipos, garantizando que el agente esté instalado y que el equipo esté correctamente vinculado a la estructura de unidad organizativa adecuada. # 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 el**servidor 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. - Control por dirección MAC: Puede configurar el servidor DHCP para que examine la dirección MAC del cliente que realiza la solicitud. - Si es la MAC `00:1A:2B:3C:4D:5E`, el DHCP envía**la Opción 66** apuntando al **PXE de Medulla**. - Para todas las demás direcciones, el DHCP no envía ninguna opción PXE o apunta a su **PXE existente**. - Control por ámbito (Scope) o clase de proveedor (Vendor Class): El DHCP también puede aplicar estas reglas de enrutamiento PXE a rangos de direcciones IP específicos o en función de un identificador específico enviado por el cliente (la clase de proveedor del cliente PXE). 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`**. # Diagrama de flujo simplificado de Medulla ## Reglas de flujo simplificadas Las reglas se interpretan de la siguiente manera: - `FUENTE -> DESTINO` significa que el **flujo se inicia** desde la FUENTE hacia el DESTINO. - Si no se especifica el protocolo, se utiliza TCP por defecto. ##### Si dispone de un único servidor Medulla, tenga en cuenta la tabla: - 1. Sin servidor de retransmisión ##### Si dispone de un servidor Medulla y un servidor de retransmisión, tenga en cuenta la tabla: - 2. Con servidor de retransmisión clásico ##### Si dispone de un servidor Medulla y un servidor de retransmisión DMZ, tenga en cuenta la tabla: - 3. Con servidor de retransmisión DMZ ##### Acceso de Medulla al exterior: - updates.siveo.net:443 - download.windowsupdate.com:80 ##### Acceso de Medulla a otros servidores internos: - Su servidor GLPI (si dispone de uno) - Su servidor LDAP (si dispone de uno, consulte nuestra documentación sobre LDAP: [LDAP DOC](https://docs.medulla-tech.io/books/medulla-faq/page/active-directory)) ##### 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ónhacia**la **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) 5222Trá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. # OIDC #### Listar mis configuraciones OIDC Vaya a la vista Admin > Gestionar proveedores. [![image.png](https://docs.medulla-tech.io/uploads/images/gallery/2025-12/scaled-1680-/m8hUXvE5dh2rZV26-image.png)](https://docs.medulla-tech.io/uploads/images/gallery/2025-12/m8hUXvE5dh2rZV26-image.png) Aquí encontrará la lista de OIDC ya configurados que es posible modificar. #### Crear una configuración OIDC [![image.png](https://docs.medulla-tech.io/uploads/images/gallery/2025-12/scaled-1680-/HxOYYjzUOcZEDUk3-image.png)](https://docs.medulla-tech.io/uploads/images/gallery/2025-12/HxOYYjzUOcZEDUk3-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. - (Opcional) «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. # Vistas DNS y relé de Medulla en DMZ
En una arquitectura Medulla,**se puede colocar** un**relé 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 - Solo hay que configurar un nombre DNS - Sin diferencias de configuración en los terminales - El servidor Medulla interno no queda expuesto - Arquitectura clara y segura ### 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](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. # 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 # 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](https://dl.medulla-tech.io/nc/glpi-100.sql) ##### GLPI con acceso de escritura Si autoriza el acceso de**escritura** 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.* # Desactivar la convergencia del paquete Extract drivers Acceda al servidor Medulla. Edite los archivos: - /etc/pulse-xmpp-agent-substitute/registeryagent.ini - /etc/pulse-xmpp-agent-substitute/registeryagent.ini.local 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: ```bash systemctl restart pulse-xmpp-master-substitute-registration.service ``` # Guía de configuración: Autenticación OIDC y sincronización de usuarios Si utiliza una infraestructura**local** 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: > > - GLPI se instala por defecto con Medulla > - Su GLPI es accesible en modo lectura-escritura --- ### 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](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/scaled-1680-/NxP9d5b7MOiN6bTI-image.png)](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/NxP9d5b7MOiN6bTI-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. # 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](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/scaled-1680-/4HdPtXnZmQeareo2-image.png)](https://docs.medulla-tech.io/uploads/images/gallery/2026-01/4HdPtXnZmQeareo2-image.png) # 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. # Cambiar el FQDN del servidor Descargue el script en este enlace: [https://dl.medulla-tech.io/nc/rename\_fqdn\_and\_protocol.py](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 # 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_agent.py) [https://dl.medulla-tech.io/nc/change\_ssh\_port\_on\_server.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. # 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. ##### 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](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 \\