Registro de nodos (enrollment)

Hacer el onboarding de un nuevo nodo en NGBackup solo necesita dos cosas: la dirección del Director y un nombre para este nodo. El daemon se registra a sí mismo sobre TLS: presenta solo el nombre, el Director crea el recurso Client o Storage, genera la contraseña compartida, ambos lados la sellan en sus cofres de secretos, y el canal normal toma el control. Sin contraseña acarreada a mano, sin SSH, sin editar archivos de configuración, y sin token que generar o pegar. Esto es el enrollment abierto, y viene activado por defecto.

Hacer el onboarding de un Storage (SD) y de un Cliente (FD) es el procedimiento idéntico. Difieren solo en el nombre del daemon y en las flags opcionales de dispositivo del Storage.

El endpoint de enrollment del Director es su puerto de console ya existente 9101. El nodo conecta hacia afuera, así que funciona detrás de NAT.

Registrar un cliente (File Daemon)

Tras instalar backup-fd, apúntalo al Director y dale un nombre:

backup-fd --enroll --director dir.example.com:9101 --name web-01

Luego inícialo - el modo daemon es el predeterminado, así que no hacen falta flags:

backup-fd

Eso es todo. El Director crea el Client llamado web-01, sella una contraseña compartida en ambos lados, y de aquí en adelante el cliente se gestiona por completo por la red (.reconfigure client=web-01, .restart client=web-01, configuración versionada) mediante el plano de gestión.

Registrar un storage (Storage Daemon)

Idéntico en forma - cambia el binario y el nombre. Un nodo de storage también puede definir el layout de sus dispositivos de disco en el enrollment:

backup-sd --enroll --director dir.example.com:9101 --name store-01 \
  --archive-device /opt/backup/storage --rw-devices 10 --ro-devices 2

Luego inícialo:

backup-sd

El Director crea el Storage llamado store-01. Las flags de dispositivo son opcionales:

Flag	Significado
`--archive-device DIR`	Directorio donde el storage en disco registrado escribe los volúmenes. Por defecto `/opt/backup/storage`.
`--rw-devices N`	Dispositivos virtuales de lectura/escritura en el autochanger en disco generado. Por defecto 10 (escrituras de jobs concurrentes).
`--ro-devices M`	Dispositivos virtuales de solo lectura para restauración / Instant Recovery. Por defecto 2.

Flags comunes

Ambos daemons comparten las mismas flags de enrollment:

--config toma por defecto /opt/backup/etc/backup-fd.conf (FD) o /opt/backup/etc/backup-sd.conf (SD); pásalo solo para una ruta no predeterminada.
--director-fingerprint SHA256 es opcional - omítelo para trust-on-first-use (se imprime una advertencia), o pásalo para fijar el certificado del Director contra un man-in-the-middle.
Volver a ejecutar --enroll contra una configuración existente es rechazado a menos que pases --force.

Los instaladores hacen esto por ti

Los instaladores de la plataforma piden exactamente esas dos cosas - la dirección del Director y un nombre - y ejecutan el enrollment, registran el servicio y abren el firewall.

Linux - sudo bash install.sh (rol client o storage) pregunta la dirección del Director y un nombre. No interactivo: --director dir.example.com:9101 --name web-01. Los wizards por daemon install-ngbackup-fd.sh / install-ngbackup-sd.sh reciben los mismos --director + --name.
Windows - la página Connect del NGBackup-fd-Setup.exe gráfico tiene dos campos: Director enrollment endpoint (host:port) y Name for this client. Instala el servicio, abre el firewall y hace el enroll. Silencioso: /S /DIRECTOR=dir.example.com:9101 /NAME=web-01.

Qué crea el enrollment

Sobre una única conexión TLS al :9101:

El nodo verifica el certificado TLS del Director. Pasa --director-fingerprint para fijarlo; sin la flag, recurre al trust-on-first-use e imprime una advertencia sonora - fíjalo en producción, o sobre redes no confiables.
Con AllowOpenEnrollment = yes (el predeterminado), el Director acepta el nombre elegido por el nodo y crea el recurso Client o Storage mediante config-as-data - una revisión commiteada, activada y auditable.
El Director genera una contraseña compartida de alta entropía, la sella en su propio cofre de secretos, y se la entrega al nodo.
El nodo sella la contraseña localmente (haciendo el bootstrap de una master.key en el primer uso) y escribe un backup-fd.conf / backup-sd.conf listo cuyo Password es una referencia @secret: - sin texto plano en disco.

Control del lado del Director: AllowOpenEnrollment

El enrollment abierto se gobierna por una directiva en el recurso Director:

AllowOpenEnrollment = yes    # predeterminado

Déjala en yes (el predeterminado) y cualquier nodo que tenga la dirección del Director puede registrarse solo con un nombre. Ponla en no para exigir un token pre-generado (ver Avanzado abajo); los intentos sin token se rechazan entonces.

Avanzado: enrollment por token (sitios restringidos)

Para sitios que ponen AllowOpenEnrollment = no, un nodo debe presentar un token bearer de un solo uso generado en el Director. Esta vía es opcional - úsala solo cuando quieras controlar exactamente qué nodos pueden unirse.

Genera un token sobre una sesión de console segura (TLS / TLS-PSK - el build por defecto backup-console):

*.enroll-token client=web-01 ttl=1800 cidr=10.0.0.0/24 profile=default

Argumento	Significado
`client=NAME`	(obligatorio) el único nodo que este token puede registrar (`[A-Za-z0-9._-]`, ≤128 caracteres).
`ttl=SECONDS`	Tiempo de vida del token. Por defecto 1800 (30 min), limitado a 86400 (1 día).
`cidr=A.B.C.D/N`	Opcionalmente restringe la dirección de origen desde la que el token puede canjearse (IPv4 o IPv6).
`profile=NAME`	Aplica una plantilla incorporada de Job + Content - `default`, `home` o `system`.

La respuesta trae el token completo una sola vez (solo se almacena un hash en el catálogo) más la director_fingerprint. Haz el enroll con --token en vez de --name:

backup-fd --enroll --director dir.example.com:9101 --token ab12.cd34

Gestiona los tokens pendientes con .enroll-token-list client=NAME (estado: live/used/expired/revoked) y .enroll-token-revoke token=ID. Los tokens terminales de más de un día se barren automáticamente.

Propiedades de seguridad del token

Token de alta entropía y de un solo uso - el secreto es de 256 bits; el catálogo almacena solo su hash SHA-256, y el canje lo consume atómicamente.
TTL corto - 30 minutos por defecto, limitado como máximo a un día.
Fijación opcional de CIDR - el token solo es canjeable desde la red de origen declarada.
Límite de tasa por IP - como máximo 10 intentos de enrollment por IP de origen por ventana deslizante de 60 segundos, con mensajes de error uniformes.
Emisión y canje auditados - la generación exige una sesión segura + CommandACL, y todo desenlace (aceptado / rechazado, con IP de origen) se anexa al enroll-audit.log junto a la configuración del Director.

Solución de problemas

Síntoma	Causa / solución
Reset del handshake TLS / conexión rechazada en `--enroll`	El Director no tiene certificado TLS configurado - define `TlsCertificate` + `TlsKey` en su recurso `Director` (ver la nota de prerrequisito arriba) y reinícialo.
Enrollment rechazado con un nombre (sin token)	`AllowOpenEnrollment` está en `no` en el Director - ponlo en `yes`, o genera un token y haz el enroll con `--token` (ver Avanzado arriba).
Error de fingerprint no coincidente en el nodo	El `--director-fingerprint` no coincide con el certificado del Director - cópialo de nuevo, o descarta un man-in-the-middle. La flag es opcional; quítala para trust-on-first-use.
Intentos repetidos rechazados de repente	Límite de tasa por IP (10 intentos / 60 s) - espera un minuto y reintenta.
`--enroll` se niega a ejecutarse	Ya existe una configuración en la ruta de destino - pasa `--force` para volver a hacer el enroll.