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?

Mantenimiento remoto y puesta en marcha

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

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)

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

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. 

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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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

---

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 \