Configurar el servicio de licencias (modo organización)

Esta página es para quien administra la infraestructura de tu organización (equipo de sistemas, o quien administra el servidor IBM i) — no hace falta leerla para programar en WARP. Sirve para dejar funcionando, una sola vez, el servicio que reparte las licencias entre todo el equipo de desarrollo. Quienes solo van a usar Warpgate reciben del administrador los tres datos finales (Host, Port, Fingerprint) y los colocan en su @License — ver Licenciamiento.

1. Descargar

• license-service (administra el servicio): Linux · Windows
• license-gui (consulta visual, opcional — ver sección 5): Linux · Windows
• Sumas de verificación: SHA256SUMS.txt

En Linux, dar permiso de ejecución: chmod +x license-service license-gui.

2. Solicitar la licencia de organización

En el servidor donde va a correr el servicio:

license-service create-request --license-id "<Nombre de tu organización>" --out request.json
license-service gen-hwid

El segundo comando muestra varios datos del equipo; copiar el valor de primary_os_id (una cadena de 32 caracteres). Enviar a warpgate@softwarehouse.pe:

• El archivo request.json.
• El valor de primary_os_id.
• Cuántos puestos (seats) simultáneos necesita tu equipo.

Software House responde con un archivo license.json para ese servidor, válido por 90 días y renovable — mismo modelo sin costo que la licencia individual, ver Licenciamiento.

3. Instalar el servicio

Windows, con la ventana license-gui (recomendado)

1. Dejar license-gui.exe y license-service.exe en la misma carpeta (por ejemplo C:\license). El servicio queda registrado apuntando a esa carpeta: no moverla después.

2. Abrir license-gui.exe con clic derecho → Ejecutar como administrador. En la pantalla de conexión, pulsar Servidor local: instalar y mantener….

3. La ventana tiene estas pestañas:

   • 1. Solicitar licencia: escribir el identificador de licencia y pulsar Crear solicitud. Genera request.json y un request-hwid.txt con el identificador de la máquina (con botón Copiar). Enviar ambos archivos a Software House (ver sección 2).

   • 2. Instalar servidor: elegir el license.json recibido y completar:

     • Nombre del servidor: por defecto, el nombre completo del equipo.
     • Puerto: 7443 por defecto.
     • Red de usuarios (firewall): LocalSubnet o un rango (por ejemplo 192.168.0.0/24). La regla de firewall solo se crea si el Firewall de Windows está activo en algún perfil.
     • Consultar con la GUI desde: redes autorizadas para consultar a distancia (ver sección 7).

     Luego pulsar Instalar servicio y arrancar. En orden, la ventana registra el servicio, instala la licencia, genera el certificado, ajusta los permisos del directorio de datos (solo SYSTEM y Administradores), crea la regla de firewall si procede, inicia el servicio y comprueba que escucha. Al final muestra la huella y el bloque @License listo para copiar a los clientes.

     También hay Desinstalar servicio…: detiene y elimina el servicio y quita la regla de firewall. Una casilla opcional permite borrar además los datos (licencia, certificado, base de puestos y log); por defecto se conservan.

   • 3. Certificado TLS: para usar el certificado de la organización (ver sección 6).

   • 4. Log del servicio: se refresca solo cada 3 segundos; tiene Copiar y Limpiar log… (vacía el archivo sin borrarlo; el servicio sigue escribiendo).

El servicio de Windows se llama WarpgateLicense y tiene inicio automático. Sus datos están en C:\ProgramData\license-service\:

Certificados LDAP: el cliente LDAP (ldaps://) confía en las autoridades certificadoras del almacén del sistema. Si el controlador de dominio usa una CA interna, esa CA debe estar instalada en el almacén del equipo que ejecuta el servicio (en Windows, el almacén de certificados de Windows). Si no, la conexión LDAPS falla y el servicio deniega el acceso.

Windows, por consola (alternativa)

license-service install-license --license license.json
license-service gen-tls-cert --subject-alt-name <host-o-dominio-del-servidor>
license-service install-windows-service --bind 0.0.0.0:7443

Esto registra license-service como un servicio de Windows normal (inicio automático, se reinicia solo si falla) — se administra desde el Administrador de servicios como cualquier otro. El segundo comando muestra la huella SHA-256 en pantalla: ese valor es el Fingerprint que necesitan quienes se conecten.

Linux, como servicio con systemd (recomendado)

1. Copiar el binario y crear un usuario propio para el servicio:

   sudo install -m 0755 license-service /usr/local/bin/license-service
   sudo useradd --system --no-create-home --shell /usr/sbin/nologin warpgate-license
   sudo install -d -o warpgate-license -g warpgate-license -m 0700 /var/lib/license-service
   

2. Instalar la licencia y generar el certificado, como ese usuario:

   sudo -u warpgate-license env LICENSE_SERVICE_DIR=/var/lib/license-service \
     license-service install-license --license /ruta/license.json
   sudo -u warpgate-license env LICENSE_SERVICE_DIR=/var/lib/license-service \
     license-service gen-tls-cert --subject-alt-name <host-o-dominio-del-servidor>
   

   Anotar la huella SHA-256 que imprime el segundo comando: ese valor es el Fingerprint.
3. Descargar la unidad de systemd, copiarla y activar el servicio:

   sudo cp license-service.service /etc/systemd/system/
   sudo systemctl daemon-reload
   sudo systemctl enable --now license-service
   

Con esto el servicio arranca solo al reiniciar el servidor y se reinicia solo si falla. Logs: journalctl -u license-service -f. Abrir el puerto TCP 7443 solo para la subred de los usuarios de Warpgate.

Linux, prueba rápida (sin systemd)

Para probar antes de instalar como servicio permanente:

license-service install-license --license license.json
license-service gen-tls-cert --subject-alt-name <host-o-dominio-del-servidor>
license-service run --bind 0.0.0.0:7443

Corre en primer plano; se detiene al cerrar la terminal. Útil para verificar que todo funciona antes del paso anterior.

4. Entregar los datos al equipo

Cada desarrollador coloca estos tres datos en el @License de su proyecto (ver Licenciamiento):

• Host: el servidor donde corre el servicio.
• Port: 7443 (o el que se haya indicado en --bind).
• Fingerprint: el que imprimió gen-tls-cert.

Si en el .warpcfg hay Host, manda el servicio: no existe respaldo automático al archivo de licencia individual, así que si el servicio cae, generate/build/reverse fallan. Host sin Fingerprint es un error.

Si la organización usa Active Directory, el servicio puede exigir autenticación Kerberos — consultar a Software House para habilitarlo.

Modo sin dominio (sin auth.json)

Si no hay Kerberos configurado, la identidad de quien toma un puesto es el nombre que declara su equipo (no se verifica). Además:

• Las consultas (license-gui, license-service query y también warpgate --action license-status en modo organización) solo se aceptan desde la propia máquina del servicio. Desde otra PC, el servicio rechaza la consulta: warpgate muestra «Su usuario no está autorizado a consumir la licencia de warpgate. Solicite acceso al administrador.», license-gui muestra «no estás autorizado para esta operación», y el servicio anota en su log consulta rechazada desde <IP>. Para permitir consultas remotas, ver la sección 7.
• Tomar un puesto (generate, build, reverse) no tiene esa restricción: funciona desde cualquier PC que alcance el servicio.
• Instalar o reemplazar licencias es siempre solo desde el servidor (o por administradores Kerberos).

5. Consultar el servicio con license-gui

license-gui es una ventana aparte, sin línea de comandos, para ver el estado de la licencia sin afectar los puestos en uso (no consume un seat): licencia activa y vencimiento, seats en uso y disponibles, y el historial de sesiones de cada usuario (incluyendo si una sesión se cerró normalmente o se perdió).

Al abrirla, pide los mismos tres datos que cualquier cliente — Host, Port, Fingerprint — más un SPN opcional si el servicio exige Kerberos. Quien administra el servicio también puede instalar una licencia nueva desde ahí mismo, sin reiniciar nada.

Sus pestañas son Usuarios, Licencias (instalar una licencia solo está permitido a administradores), Estadísticas y Log del servicio. Desde otra PC funciona solo si se habilitó la consulta remota (o con Kerberos).

6. Certificado TLS

Por defecto el servicio usa un certificado autofirmado, válido desde 1975 hasta 4096 (prácticamente no caduca). El cliente no revisa fechas, cadena de CA ni nombre: solo compara la huella SHA-256 del certificado con el Fingerprint configurado.

Si seguridad exige el certificado de la organización, se puede usar desde la pestaña 3. Certificado TLS de la ventana, eligiendo el tipo:

La ventana convierte al formato interno y guarda (el anterior queda como tls_cert.der.previous y tls_key.der.previous), reinicia el servicio si se marca la opción, y muestra la huella (con botón Copiar) y el bloque @License. Si el archivo trae la cadena completa, se usa el certificado propio del servidor (el que corresponde a la clave).

Errores explicados por la ventana: la clave no corresponde al certificado, contraseña de PFX incorrecta, tipo equivocado, y clave PEM cifrada con contraseña (no soportada: quitar la contraseña con openssl pkcs8 -in clave.pem -out clave-sin-clave.pem -nocrypt, o entregar un PFX).

Importante: cambiar el certificado cambia la huella, y hay que actualizarla en todos los clientes (@License y la pantalla de conexión de license-gui). La renovación de un certificado de una CA corporativa la vuelve a cambiar.

Equivalente por consola (luego reiniciar el servicio):

license-service import-tls-cert --format pem|pfx|der --cert <archivo> [--key <archivo>] [--password-env VARIABLE]

7. Consulta remota de solo lectura

Sin Kerberos, para que license-gui y license-status puedan consultar desde otras PC se crea el archivo auth.json en el directorio de datos (C:\ProgramData\license-service\auth.json; /var/lib/license-service/ con systemd):

{ "query_allowed_networks": ["192.168.0.10", "10.1.2.0/24"] }

• Acepta IPs o rangos CIDR, IPv4 e IPv6.
• Solo aplica sin Kerberos y requiere reiniciar el servicio.
• Crear el archivo sin BOM (JSON estricto).
• Desde esas redes se ven usuarios, historial, estadísticas y log, pero no se pueden instalar licencias y no aparece el botón Servidor local….
• Se autorizan direcciones, no personas: mantener la lista corta.

Atajo: el campo Consultar con la GUI desde de la pestaña 2. Instalar servidor escribe este auth.json (no sobrescribe uno existente).

8. Límites de conexión

El servicio corta la conexión nueva antes del TLS y lo anota en el log con la IP (1 de cada 50 rechazos). No afecta a quien ya tiene un puesto.

• Total: puestos × 2 + 20 (se calcula con la licencia).
• Sin sesión todavía (handshake o autenticando): máximo 50.
• Por IP: 5 por defecto; configurable con "max_connections_per_ip": N en auth.json (0 = sin límite). Las conexiones desde la propia máquina del servicio quedan exentas de este tope.

Subir el valor por IP si muchos usuarios comparten IP (servidor de compilación, escritorio remoto). Requiere reiniciar el servicio.

9. Estadísticas y exportación

license-gui consulta y administra sin consumir un puesto. La pestaña Estadísticas permite elegir el período (7, 30, 90 días o 1 año) y muestra:

• Sesiones y usuarios distintos.
• Pico de puestos simultáneos y cuándo ocurrió.
• Porcentaje del tiempo de uso con todos los puestos ocupados, y tiempo de uso.
• Rechazos por falta de puestos (se registran solo desde esta versión; no hay datos anteriores).
• Gráficos del pico por día y por hora del día (hora local), y detalle por día.
• Una lectura orientativa: «conviene ampliar» si hubo rechazos; «al límite» si el pool estuvo lleno el 5 % o más del tiempo de uso; «sobra capacidad» si el pico fue la mitad o menos de lo contratado. Avisa si hay menos de 7 días con uso.

Sirve para decidir si conviene comprar más puestos.

El menú Exportar ▾ ofrece: resumen de usuarios (CSV), historial de sesiones del período (CSV), log del servicio (texto) y estadísticas del período (CSV). Los CSV usan ; y BOM UTF-8 (abren bien en Excel en español) y neutralizan los valores que empiezan con =, +, - o @ (inyección de fórmulas). El historial y el log requieren poder ver a todos los usuarios.

10. Problemas frecuentes