Un solo entorno PXE para todos los clientes: instalaciones desatendidas con Proxmox Datacenter Manager

Una consola, muchos clientes

Si te ocupas de Proxmox para otros, cada nodo nuevo es el mismo trabajo hecho de forma un poco distinta. Cada cliente tiene su país, su zona horaria, sus claves de root, su disposición de discos, su forma de nombrar los hosts y su clave de suscripción. Si te equivocas en una de ellas en un nodo recién instalado, te enteras la primera vez que alguien inicia sesión, o la primera vez que una auditoría pregunta por qué el reloj va una hora desfasado.

Monté esto para un cliente con exactamente ese problema, y lo que pidió fue de lo más sencillo. Cada sede se instala con su propia forma de nombrar, su propia contraseña de root y sus propias claves SSH. Nadie en la sede hace nada ingenioso: montan un servidor en el rack, lo conectan a la VLAN correcta y lo encienden. Nadie recopila números de serie, y nadie escribe un archivo de respuesta por máquina. Y un servidor añadido así acaba en el clúster que la sede ya tiene.

Este artículo cubre las tres primeras: llevar un servidor vacío desde el encendido hasta un nodo Proxmox instalado con los ajustes de la sede correcta. Esa mitad es la que le toca a casi cualquiera con más de una sede, sea MSP o no, así que merece la pena tenerla por separado. Unirse al clúster es otro trabajo, y la sección sobre el gancho de primer arranque que falta explica por qué PDM todavía no puede hacerlo por ti.

Proxmox Datacenter Manager (PDM) 1.1 añadió la pieza que faltaba¹. Ahora puede hacer de servidor de respuestas para el instalador automatizado de Proxmox, así que una máquina vacía arranca, envía lo que es, recibe una respuesta preparada y se instala sola sin nadie delante de la consola. Para un proveedor de servicios gestionados (MSP) que ya usa PDM como consola de gestión, ese es el sitio obvio donde guardar los ajustes de instalación de cada cliente.

Lo que no quieres es un servidor PXE por cliente. Cada uno es un servidor Trivial File Transfer Protocol (TFTP), una configuración DHCP, un juego de archivos de arranque y una ISO que reconstruir cada vez que Proxmox saca una versión menor. Diez clientes son diez de esos que mantener al día. Eso no escala. El objetivo aquí es un entorno PXE, una imagen de arranque, un registro DNS y un PDM, y que cada sede siga recibiendo su propia respuesta.

PDM 1.1 llega casi hasta el final por sí solo. Se queda corto en dos sitios, y conviene conocer los dos antes de planificar un despliegue a su alrededor: no tiene forma de casar una respuesta con una sede, y no tiene forma de dar a un nodo nuevo un script de primer arranque. Este artículo demuestra las dos cosas con el propio código fuente de PDM, rodea la primera y monta todo el conjunto sobre el PDM de mi laboratorio con la versión 1.1.9, con el proxy endurecido para que las partes que guardan secretos sigan cerradas.

Lo que te da PDM 1.1

La función está en Remotes → Automated Installations y tiene tres partes: instalaciones, respuestas preparadas y tokens de autenticación². Una respuesta preparada es la versión de PDM del answer.toml del instalador, rellenada con un formulario en lugar de escrita a mano.

La parte del instalador lleva tiempo ahí. El comando proxmox-auto-install-assistant prepare-iso construye una ISO que va a buscar su respuesta por HTTP, y desde la ISO de Proxmox VE 9.2 también puede generar el kernel, el initrd, la ISO y el boot.ipxe que iPXE necesita para arrancarlo todo por la red⁵.

Los contadores son la parte que un answer.toml independiente no tiene. Una sola respuesta preparada numera cada host que construye, donde un archivo estático habría que copiarlo por máquina. Es un paso adelante de verdad, y sigue siendo una primera versión. El formulario aún no está a la par del archivo de respuestas independiente⁶, y hay un área que falta por completo: en la 1.1 no existe un script de primer arranque, de ninguna forma⁷. Esa carencia, y la ubicación por la que no puede filtrar, son las dos secciones siguientes.

No puede casar con la sede

PDM elige una respuesta comparando filtros con la información del sistema que envía el instalador. Así que la pregunta es qué hay en ese documento, porque lo que no está en él no se puede casar.

Eso es todo⁸,⁹. No hay dirección, ni nombre de host, ni opción DHCP, nada sobre dónde está enchufada la máquina.

Los campos de Desktop Management Interface (DMI) parecen prometedores hasta que lees unos de verdad. Todas las instalaciones de mi laboratorio volvieron con el nombre de sistema Standard PC (Q35 + ICH9, 2009) y el número de serie y la etiqueta de inventario vacíos. Los servidores reales sí los rellenan, pero con lo que puso el fabricante y no con el nombre de tu cliente, y casar por números de serie o direcciones MAC solo funciona si llevas una lista de cada chasis que vayas a instalar en tu vida, que es justo el papeleo que esto tenía que quitar. Por host, sí. Por sede, no.

Entonces, ¿a qué red está enchufada la máquina? PDM nunca se entera. El instalador tiene su concesión DHCP en la mano cuando envía la petición, y el único dato que un MSP conoce con certeza sobre un nodo nuevo es justo el que se deja atrás. Filtrar por la dirección de origen, IPv4 o IPv6, es una petición de funcionalidad abierta, y la abrí yo mismo como el bug 8263¹⁰.

Hay un segundo límite escondido en las reglas de selección, y mi laboratorio se metió de lleno en él.

El token se comprueba primero, y solo se tienen en cuenta las respuestas autorizadas para ese token, incluida la respuesta por defecto⁴. PDM permite exactamente una respuesta por defecto en todo el sistema. Así que no puedes dar a cada sede su propia respuesta de reserva con la marca de respuesta por defecto. Mi laboratorio tenía una respuesta por defecto llamada fallback con su propio token, y no se ha servido ni una vez, porque nada envía nunca ese token. Cada sede necesita en su lugar un filtro que lo case todo con su propio token, como /product/product=*, colocado el último en el archivo.

Dos cosas más del mismo código que conviene tener en la cabeza cuando depuras:

• Gana la primera coincidencia, en el orden del archivo, y una segunda coincidencia solo deja un aviso en el log. Esa es la regla desde la 1.1.1¹¹.
• Un filtro solo casa con cadenas. /product/enable_btrfs es un booleano y no casa con nada, y un array necesita un índice, como en /network_interfaces/0/mac.

En la 1.1.9 un token desconocido o caducado recibe un 401 tras un retardo deliberado de más o menos medio segundo y no deja registro. Un token bueno sin nada que case recibe un 400 con el cuerpo no answer file found, y ese intento sí queda registrado, con la información completa del sistema. Ese registro es la forma más rápida de leer los números de serie y las direcciones MAC reales de un chasis nuevo antes de escribirle un filtro.

No puede ejecutar un script de primer arranque

El instalador en sí admite un gancho de primer arranque. Una respuesta puede llevar una sección [first-boot] con source = "from-iso" o "from-url", un orden de before-network, network-online o fully-up, y una huella de certificado opcional⁹. prepare-iso --on-first-boot mete un script en la ISO para el caso from-iso.

PDM nunca envía esa sección. Ni una vez. El propio tipo de respuesta del instalador tiene el campo, first_boot: Option<FirstBootHookInfo>¹². La respuesta preparada de PDM no tiene ningún campo para eso, y el código que construye la respuesta a partir de ella escribe first_boot: None sin condición alguna⁴. No hay nada en el formulario, nada en la API y nada en el archivo de configuración que puedas añadir a mano. Es una petición de funcionalidad abierta, el bug 7699, abierta en junio de 2026 y sin asignar cuando escribo esto⁷. Casi cinco meses después no ha tenido respuesta de Proxmox, y el 8263 tampoco. Ese silencio es lo preocupante. Quien se toma el tiempo de escribir cómo podría mejorar tu producto merece una respuesta, aunque la respuesta sea que no, y eso es simple cortesía profesional. Con más razón cuando quienes escriben son clientes de pago y partners, que ya ponen dinero en el producto antes de poner también su tiempo.

Y el script de la ISO no te salva. El instalador solo configura el servicio de primer arranque if let Some(first_boot) = &answer.first_boot, y ese es el único camino que lee alguna vez el archivo incrustado¹³. prepare-iso no avisa cuando incrustas un script que ninguna respuesta va a pedir nunca. Se queda en la ISO y no hace nada.

Eso importa más a un MSP que a nadie. Un nodo recién salido del instalador es un sistema pelado con un hash de contraseña de root y unas cuantas claves SSH. No es un remoto de PDM, no está en un clúster, y no tiene nada de tu monitorización, tus repositorios ni tu almacenamiento. En mi laboratorio los tres nodos terminaron y avisaron de vuelta, y aun así el remoto SITEA de PDM hubo que añadirlo a mano después.

Así que lo que uses para terminar un nodo, sea Ansible o cualquier otra cosa, tiene que dispararse desde fuera: desde el webhook de postinstalación, desde una tarea que vigile la lista de Installations, o desde una persona. Lo dejo ahí. Este artículo trata de conseguir que un solo entorno PXE sirva a todas las sedes, y el hueco del primer arranque es un límite con el que hay que planificar, no uno que vaya a tapar aquí.

El token es la sede

PDM no puede ver la sede, pero sí acota las respuestas por token, y un token no es más que una cabecera. Quien pone la cabecera elige qué conjunto de respuestas puede recibir el instalador. Ese es todo el truco.

Así que pon delante de PDM algo que sepa de dónde vino la petición:

1. La imagen de arranque lleva un token comodín, catch-all:not-a-secret, que es el mismo en todas las imágenes y está publicado aquí mismo. No es un token de PDM y por sí solo no abre nada.
2. Un proxy inverso Caddy delante de PDM mira la subred de origen de una petición de respuesta que lleva el token comodín, y sustituye la cabecera por el token real de esa sede.
3. PDM ve site2-2026q4:<secret> y solo ofrece las respuestas de site2.

El secreto nunca se acerca a la imagen de arranque, así que un pendrive perdido o una ISO copiada no le dan nada a nadie. Rotar el token de una sede es un cambio en Caddy, no reconstruir una imagen. Y añadir una sede es una línea de configuración de Caddy y un token nuevo en PDM.

Esto se apoya en que la dirección de origen sea honesta, y eso es una propiedad de tu red, no del proxy. Ese compromiso y los demás están más abajo, en «Lo que queda por decidir».

Cómo encuentra el instalador a PDM sin una URL incrustada

Una imagen para todas las sedes solo funciona si la imagen tampoco lleva la dirección de PDM. El instalador busca la URL de su respuesta en tres sitios, por este orden¹⁴:

El certificado que comprueba el instalador es el que conteste en el 443. En este diseño Caddy sirve ahí el propio certificado de PDM, así que un cliente ve en el 443 el mismo certificado que PDM tiene en el 8443, y hay una sola huella que publicar.

El montaje: PDM, archivos de arranque y DNS

Los ejemplos usan el dominio example.doc y tres sedes, 10.10.50.0/24, 10.20.50.0/24 y 10.30.50.0/24. .doc no es un dominio de primer nivel real, así que pon el tuyo. PDM, Caddy, dnsmasq y los archivos de arranque viven todos en un host, pdm.example.doc en 10.10.50.10, y las sedes remotas llegan a él a través de un relé DHCP en sus puertas de enlace. La gestión vive en 10.99.0.0/24 y, como tal, es la única red que llega a ver la interfaz web de PDM.

Tokens y respuestas en PDM

En Remotes → Automated Installations → Authentication Tokens, añade un token por sede y dale una caducidad que encaje con tu ventana de despliegue. El nombre no es secreto y lo vas a ver en los logs, así que haz que diga algo: site1-2026q4. Copia el secreto cuando aparezca.

Luego añade una respuesta preparada por sede y por producto, autorizada solo para el token de esa sede:

El contador sube cada vez que se sirve una respuesta, reintentos incluidos, así que los nombres pueden saltarse números. El contador de mi laboratorio está en 4 tras tres instalaciones terminadas. Si necesitas nombres predecibles, usa FQDN from DHCP y pon el nombre de host en la reserva DHCP.

La URL base del webhook es el único ajuste que tiene que cambiar para este diseño. Lo natural es apuntarla al propio PDM en el puerto 8443, que es como la tenía mi laboratorio, y el 8443 está a punto de cerrarse. Apúntala a Caddy.

Los archivos de arranque

En cualquier host Proxmox VE o Debian con el repositorio de Proxmox:

apt install proxmox-auto-install-assistant xorriso
mkdir -p /srv/www/pve-9.2
proxmox-auto-install-assistant prepare-iso proxmox-ve_9.2-1.iso \
  --fetch-from http \
  --answer-auth-token 'catch-all:not-a-secret' \
  --pxe-loader ipxe \
  --output /srv/www/pve-9.2/

Sin --url, porque la pone DNS. --pxe-loader ipxe implica --pxe, y con --pxe la salida tiene que ser un directorio que ya exista¹⁵. Obtienes cuatro archivos: vmlinuz, initrd.img recomprimido de zstd a gzip porque iPXE no puede cargar un initrd en zstd, la ISO preparada sin /boot, y un menú boot.ipxe que arranca por defecto la instalación automatizada a los diez segundos y se refiere a los demás por su nombre relativo¹⁵. Guarda los cuatro en un mismo directorio.

Cada máquina de destino necesita memoria suficiente para el kernel, el initrd y la ISO entera. Las notas de Proxmox VE 9.2 lo cifran en «at least 6 GiB of available memory on the host»⁵. Las mismas notas recogen un problema conocido del kernel de la ISO 9.2 con controladoras megaraid_sas y algunas unidades NVMe en modo JBOD (just a bunch of disks), con el consejo de instalar desde la ISO 9.1 y actualizar⁵. Prueba tu hardware antes de confiarle la ruta de red.

Los registros DNS

En la zona que corresponde al único dominio de búsqueda que entrega DHCP:

$ORIGIN example.doc.
pdm                                      IN A    10.10.50.10
proxmox-auto-installer                   IN TXT  "https://pdm.example.doc/api2/json/auto-install/answer"
proxmox-auto-installer-cert-fingerprint  IN TXT  "63:C4:D6:...:85:07"

La huella es la del propio certificado de PDM:

openssl x509 -in /etc/proxmox-datacenter-manager/auth/api.pem -noout -fingerprint -sha256

Compruébalos como lo hará el instalador:

dig txt +short proxmox-auto-installer.example.doc @10.10.50.10
# one quoted string, nothing split

Caddy, la única puerta a PDM

La API de PDM escucha en [::]:8443, y eso es una constante compilada en el binario, no un ajuste¹⁶. No puedes atarla al loopback. Así que Caddy pasa a ser la única forma de entrar, y el cortafuegos se asegura de ello.

PDM tiene exactamente dos rutas que funcionan sin iniciar sesión en PDM: POST /api2/json/auto-install/answer con un token de instalador, y POST …/installations/{uuid}/post-hook con el token de un solo uso en el cuerpo⁴. Son las dos únicas a las que debería llegar nunca una red de aprovisionamiento.

Usa Caddy 2.11.1 o posterior. La 2.11.1 corrigió una forma de saltarse el path matcher, CVE-2026-27587, que es exactamente el tipo de filtrado por ruta en el que se apoya esto¹⁷. El paquete propio de Debian 13 es la 2.6.2, así que tómalo de trixie-backports, que lleva la 2.11.2, o del repositorio propio de Caddy¹⁸.

El Caddyfile, /etc/caddy/Caddyfile:

{
	# the admin API on a socket only root can open, never on TCP
	admin unix//run/caddy/admin.sock|0600
	auto_https disable_redirects
	servers {
		protocols h1 h2
	}
}

# PDM itself, on the loopback, trusted by its own certificate
(pdm_upstream) {
	reverse_proxy https://[::1]:8443 {
		transport http {
			tls_trust_pool file /etc/proxmox-datacenter-manager/auth/api.pem
			tls_server_name pdm.example.doc
		}
	}
	log_append pdm_status {http.reverse_proxy.status_code}
}

# one site: name, subnet, PDM token name, PDM token secret
(site) {
	@{args[0]} {
		method POST
		path /api2/json/auto-install/answer
		remote_ip {args[1]}
		header Authorization "Bearer catch-all:not-a-secret"
	}
	handle @{args[0]} {
		log_append site {args[0]}
		log_append pdm_token {args[2]}
		request_header Authorization "Bearer {args[2]}:{args[3]}"
		import pdm_upstream
	}
}

pdm.example.doc, 10.10.50.10 {
	tls /etc/proxmox-datacenter-manager/auth/api.pem /etc/proxmox-datacenter-manager/auth/api.key

	import site site1 10.10.50.0/24 site1-2026q4 {env.PDM_SECRET_SITE1}
	import site site2 10.20.50.0/24 site2-2026q4 {env.PDM_SECRET_SITE2}
	import site site3 10.30.50.0/24 site3-2026q4 {env.PDM_SECRET_SITE3}

	@post_hook {
		method POST
		path /api2/json/auto-install/installations/*/post-hook
		remote_ip 10.10.50.0/24 10.20.50.0/24 10.30.50.0/24
	}
	handle @post_hook {
		request_header -Authorization
		import pdm_upstream
	}

	# the PDM web UI and API, from the management network only
	@mgmt remote_ip 10.99.0.0/24
	handle @mgmt {
		import pdm_upstream
	}

	# anything else, from anywhere, never reaches PDM
	handle {
		abort
	}

	log {
		output file /var/log/caddy/pdm.log
		format filter {
			request>headers>Csrfpreventiontoken replace REDACTED
		}
	}
}

# boot files, to the sites and management only
http://:80 {
	@hidden path_regexp /\.
	handle @hidden {
		abort
	}
	@boot remote_ip 10.10.50.0/24 10.20.50.0/24 10.30.50.0/24 10.99.0.0/24
	handle @boot {
		root * /srv/www
		file_server
	}
	handle {
		abort
	}
}

Las partes que hacen trabajo de seguridad, y por qué está cada una:

El path matcher es más tolerante que PDM, que es como tiene que ser. Caddy limpia la ruta, decodifica la codificación por porcentaje, junta las barras repetidas e ignora mayúsculas y minúsculas antes de casar²⁰. Así que //answer, %61nswer y ANSWER cuentan todas como la ruta de respuesta, y una variante /api2/extjs/… o una barra final no casan con ninguna ruta de sede y caen en abort.

Hay dos decisiones ahí dentro que necesitan explicación.

Caddy sirve el certificado de PDM, directamente desde los archivos de PDM. Caddy lee api.pem y api.key donde los guarda PDM, así que los instaladores, el webhook y un navegador ven todos el certificado que PDM presenta en el 8443, y no hay una segunda copia que se desfase. La forma obvia de darle ese acceso es añadir el usuario caddy a www-data. En mi laboratorio comprobé hasta dónde llega de verdad esa pertenencia al grupo, probando cada archivo como el usuario caddy:

Nada de esa lista tiene que estar ni cerca de un proxy web. Un fallo en el proxy sería entonces el compromiso de todos los clústeres que gestiona PDM.

Así que Caddy se queda fuera de www-data y recibe una ACL sobre exactamente los dos archivos que necesita, más permiso para atravesar los dos directorios que hay por encima sin poder listarlos:

#!/bin/sh
# /usr/local/sbin/pdm-cert-acl
# let Caddy read PDM's certificate and key in place, and nothing else of PDM's
set -e
D=/etc/proxmox-datacenter-manager; A=$D/auth
setfacl -m u:caddy:x "$D" "$A"
setfacl -m u:caddy:r "$A/api.pem" "$A/api.key"

Probado como el usuario caddy en el laboratorio después de ejecutarlo:

La pega es la renovación. PDM escribe un certificado renovado en un archivo nuevo y lo renombra encima del antiguo, y un archivo nuevo no lleva la ACL del anterior. Así que cuando PDM renueva, systemd vuelve a poner la ACL y recarga Caddy, sin que intervenga nadie.

Una comprobación de que el certificado y la clave van juntos, porque una renovación los escribe de uno en uno:

#!/bin/sh
# /usr/local/sbin/pdm-cert-pair-ok
# exit 0 only when PDM's certificate and key belong together
d=/etc/proxmox-datacenter-manager/auth
c=$(openssl x509 -noout -pubkey -in "$d/api.pem") || exit 1
k=$(openssl pkey -pubout -in "$d/api.key") || exit 1
[ "$c" = "$k" ]

Una unidad path que vigila los dos archivos, y el servicio que arranca:

# /etc/systemd/system/caddy-pdm-cert.path
[Unit]
Description=Watch the PDM certificate and key for renewal

[Path]
PathChanged=/etc/proxmox-datacenter-manager/auth/api.pem
PathChanged=/etc/proxmox-datacenter-manager/auth/api.key
Unit=caddy-pdm-cert.service

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/caddy-pdm-cert.service
[Unit]
Description=Let Caddy read the renewed PDM certificate in place, then reload Caddy

[Service]
Type=oneshot
ExecCondition=/usr/local/sbin/pdm-cert-pair-ok
ExecStart=/usr/local/sbin/pdm-cert-acl
ExecStart=/usr/bin/systemctl try-reload-or-restart caddy.service

apt install acl
systemctl daemon-reload
systemctl enable --now caddy-pdm-cert.path

El override de más abajo ejecuta el mismo script de ACL antes de cada arranque de Caddy, así que nunca se pierde una renovación hecha mientras Caddy estaba parado.

Los detalles que lo hacen funcionar, comprobados uno a uno:

Esa última fila no es una suposición. En un contenedor desechable con Caddy 2.11.7 cambié el archivo del certificado por debajo de un servidor en marcha: un caddy reload a secas siguió sirviendo el certificado antiguo, y caddy reload --force sirvió el nuevo. La unidad empaquetada ya recarga con --force²⁷, así que conserva esa línea si sobrescribes ExecReload.

En el laboratorio sustituí api.key y api.pem de PDM como lo hace una renovación, escribiendo archivos nuevos y renombrándolos encima de los antiguos. Justo después del renombrado, api.key no tenía entrada de ACL para caddy. En cuatro segundos la unidad path se había disparado, la ACL estaba de vuelta en los dos archivos, y Caddy se había recargado en su sitio con el mismo ID de proceso.

El nombre del token y el secreto se guardan por separado. El nombre va en el Caddyfile, donde queda en el log. El secreto va en un archivo de entorno que solo puede leer root, y Caddy lo lee mediante {env.*} en el momento de la petición.

Registra qué token se usó, nunca el secreto

La primera versión de esto en mi laboratorio tenía una fuga. La unidad empaquetada de Caddy lo arranca como caddy run --environ, y --environ imprime todo el entorno antes de arrancar²⁸,²⁷. Cada reinicio dejaba el token de la sede en el journal en texto claro: ocho líneas cuando lo conté. Nada en el log de acceso, nada en los propios logs de PDM, todo por ese único parámetro.

Así que el archivo de secretos guarda secretos y nada más:

install -m 0600 /dev/null /etc/caddy/pdm-secrets.env
printf 'PDM_SECRET_SITE1=%s\nPDM_SECRET_SITE2=%s\nPDM_SECRET_SITE3=%s\n' \
  '<secret1>' '<secret2>' '<secret3>' > /etc/caddy/pdm-secrets.env

y el override de la unidad quita --environ y le da un sitio al socket de administración:

# systemctl edit caddy
[Service]
EnvironmentFile=/etc/caddy/pdm-secrets.env
RuntimeDirectory=caddy
RuntimeDirectoryMode=0700
# PDM's certificate and key, read where PDM keeps them
ExecStartPre=+/usr/local/sbin/pdm-cert-acl
# the access log directory and its files belong to Caddy
ExecStartPre=+/usr/bin/install -d -o caddy -g caddy -m 0750 /var/log/caddy
ExecStartPre=+/usr/bin/chown -R caddy:caddy /var/log/caddy
ExecStart=
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
ExecReload=
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force

El + ejecuta esas líneas como root, antes de que Caddy arranque con su propio usuario. Las líneas del log importan en cuanto cualquier otra cosa toca /var/log/caddy: un log rotado por root, o un archivo creado a mano mientras pruebas, deja a Caddy sin poder abrir su propio log de acceso. En el laboratorio puse pdm.log como root:root y reinicié Caddy; volvió como caddy:caddy y Caddy no registró ningún error de permisos.

Reinicia en lugar de recargar después de editarlo, porque una recarga no vuelve a leer el entorno. Usa {env.NAME}, nunca {$NAME}: la segunda forma se sustituye cuando se adapta el Caddyfile, así que el secreto acaba en la configuración JSON, en el archivo de autosave y en cualquier cosa que los vuelque²⁹. El socket de administración también importa aquí. {env.*} resuelve cualquier cosa del entorno del proceso sin lista de permitidos, así que cualquiera que pueda cargar una configuración a través de una API de administración por TCP puede hacer que Caddy le devuelva un secreto³⁰.

Ahora cada línea de respuesta del log de acceso nombra la sede y el token, con la cabecera en sí oculta. Del laboratorio, donde los dos se llaman siteA:

{"site":"siteA","pdm_token":"siteA","pdm_status":400,"status":400,
 "request":{"headers":{"Authorization":["REDACTED"]}}}

Lo comprobé en lugar de fiarme. En una copia de esta configuración en podman con secretos de prueba, y luego en el laboratorio, envié respuestas por todos los caminos que se me ocurrieron: normal, con el log de depuración activado, con el upstream caído para un 502, una recarga y un reinicio. Luego conté cada secreto en el journal, el log de acceso, los directorios de configuración y de datos de Caddy y el JSON adaptado. Todos los recuentos dieron cero. La pasada de control, la misma configuración arrancada con --environ, imprimió el secreto dos veces.

Dos salvedades de esa prueba. Con debug activado, Caddy registra toda su configuración adaptada, así que el token comodín y los marcadores {env.*} aparecen ahí; los valores que hay detrás no aparecieron. Aun así, mantén debug desactivado en producción. Y si un secreto ya ha pasado por un journal, como el mío, regenéralo en PDM y actualiza el archivo; borrar líneas del log no es la solución.

El cortafuegos: el 8443 nunca sale de la máquina

Mi laboratorio no tenía ningún cortafuegos, así que el 8443 contestaba a cualquier host de la red de aprovisionamiento y todas las reglas del Caddyfile se podían rodear. Ciérralo. nftables, con drop por defecto:

#!/usr/sbin/nft -f
flush ruleset

define SITES = { 10.10.50.0/24, 10.20.50.0/24, 10.30.50.0/24 }
define MGMT  = { 10.99.0.0/24 }

table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;

		iifname "lo" accept
		ct state established,related accept
		ct state invalid drop
		meta l4proto { icmp, ipv6-icmp } accept

		# PDM's API listens on [::]:8443 and cannot be rebound
		tcp dport 8443 counter drop

		ip saddr $MGMT tcp dport { 22, 80, 443 } accept

		udp dport { 67, 69 } accept
		ip saddr $SITES meta l4proto { tcp, udp } th dport 53 accept
		ip saddr $SITES tcp dport { 80, 443 } accept
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
	}
}

Las conexiones de PDM con sus remotos son salientes, así que cerrar el 8443 de entrada no cambia nada ahí. Carga un conjunto de reglas nuevo con una vuelta atrás temporizada la primera vez, para que un error te cueste noventa segundos y no un viaje a la consola:

systemd-run --unit=nft-rollback --on-active=90 /usr/sbin/nft flush ruleset
nft -f /etc/nftables.conf
# still connected? then:
systemctl stop nft-rollback.timer && systemctl enable nftables

En el laboratorio, después de todo eso:

DHCP, iPXE y el bucle

El firmware de un servidor solo puede traer su primer archivo por TFTP, así que TFTP sirve el pequeño cargador iPXE y iPXE trae todo lo demás por HTTP. La trampa es que iPXE envía su propia petición DHCP, y un servidor que le contesta otra vez con ipxe.efi manda la máquina a dar vueltas en círculo para siempre. El servidor DHCP tiene que distinguir el firmware de iPXE.

dnsmasq, sirviendo su propia red y las otras dos a través de relés, solo con reservas:

# /etc/dnsmasq.d/pxe.conf
local=/example.doc/
domain=example.doc
address=/pdm.example.doc/10.10.50.10
txt-record=proxmox-auto-installer.example.doc,"https://pdm.example.doc/api2/json/auto-install/answer"
txt-record=proxmox-auto-installer-cert-fingerprint.example.doc,"63:C4:D6:...:85:07"

dhcp-authoritative
dhcp-range=set:site1,10.10.50.0,static,255.255.255.0,1h
dhcp-range=set:site2,10.20.50.0,static,255.255.255.0,1h
dhcp-range=set:site3,10.30.50.0,static,255.255.255.0,1h
dhcp-option=tag:site1,option:router,10.10.50.1
dhcp-option=tag:site2,option:router,10.20.50.1
dhcp-option=tag:site3,option:router,10.30.50.1
dhcp-option=option:dns-server,10.10.50.10
dhcp-option=option:domain-search,example.doc

dhcp-match=set:ipxe,175
dhcp-match=set:efi64,option:client-arch,7
dhcp-match=set:efi64,option:client-arch,9
dhcp-boot=tag:efi64,tag:!ipxe,ipxe.efi
dhcp-boot=tag:ipxe,http://pdm.example.doc/pve-9.2/boot.ipxe
# no option 250 anywhere: DNS discovery depends on it

enable-tftp
tftp-root=/srv/tftp
tftp-secure
# TFTP block-size ceiling: lower it for an IPsec or other tunnel in the path
tftp-mtu=1500

# dhcp-host=<mac>,<ip inside that site's /24>,<hostname>
dhcp-host=aa:bb:cc:dd:ee:01,10.10.50.21,pve01
dhcp-host=aa:bb:cc:dd:ee:02,10.20.50.21,pve01

static significa que no hay pool: solo las máquinas reservadas reciben dirección, lo que mantiene a los extraños fuera del camino del instalador. La dirección de cada reserva tiene que estar dentro del /24 de su propia sede, porque esa dirección es la que usa Caddy para elegir el token. Un nodo reservado en la subred equivocada recibe la respuesta de la sede equivocada, o nada.

Las reservas son una lista de direcciones MAC, y eso es contabilidad por máquina, justo la que el cliente no quería. Si de verdad el requisito es conectar y arrancar, dale a cada VLAN de aprovisionamiento un rango dinámico pequeño, por ejemplo dhcp-range=set:site1,10.10.50.100,10.10.50.150,255.255.255.0,1h. La sede sigue saliendo de la subred, así que Caddy sigue eligiendo el token correcto, y la plantilla de FQDN con installation_nr da nombre al nodo. El precio es la primera fila de «Lo que queda por decidir»: cualquier cosa conectada a esa VLAN puede ahora obtener la respuesta de la sede, así que la propia VLAN pasa a ser la puerta.

dnsmasq negocia con el cliente el tamaño de bloque de TFTP. Si no lo tocas, lo limita a la MTU de su propia interfaz³¹, lo que funciona hasta que el camino hacia una sede es más pequeño que el enlace en el que está dnsmasq. Por eso la configuración fija el techo como tftp-mtu=1500 en lugar de heredarlo. Así el número queda delante de quien se ocupe de una sede detrás de un túnel IPsec o de cualquier otra cosa que le coma espacio al paquete, y lo baja a lo que el camino lleva de verdad en lugar de enterarse por una transferencia que se queda colgada a medias. Si una ROM de tarjeta de red se porta mal cuando se concede la opción, tftp-no-blocksize desactiva la negociación.

Copia ipxe.efi del paquete ipxe de Debian a /srv/tftp, con el usuario dnsmasq como propietario, porque tftp-secure rechaza cualquier otra cosa. Mejor UEFI. Secure Boot necesita un iPXE firmado, así que o lo preparas o desactivas Secure Boot para la instalación y lo vuelves a activar después.

Arrancar, mirar y lo que se rompe

Prueba con una máquina virtual en la red de una sede antes de tocar hardware: firmware UEFI, 8 GiB de memoria y una tarjeta de red en esa VLAN reproducen toda la cadena.

Y todo junto, por orden, desde el encendido hasta una instalación que PDM marca como Finished:

Ante un fallo el instalador cae a una shell, salvo que la respuesta active Reboot on Error, así que déjalo desactivado mientras pruebas.

Añadir Proxmox Backup Server

Nada del camino es propio de Proxmox VE. Construye un segundo juego de archivos de arranque desde la ISO de PBS 4 con el mismo token comodín, en /srv/www/pbs-4/, y añade una respuesta de PBS por sede con el filtro /product/product=pbs, autorizada para el token de esa sede. Los registros DNS, Caddy, los tokens y el cortafuegos no cambian.

En una sede con los dos, algo tiene que decidir qué producto recibe cada máquina, y un menú es lo que no debe decidirlo. El choose de iPXE sin --timeout espera en la consola a que alguien pulse una tecla para siempre, que es lo contrario de desatendido.

Deja que decida la reserva DHCP. Ya reservas cada nodo por su dirección MAC, así que etiqueta los de PBS y manda a cada etiqueta su propio boot.ipxe:

# /etc/dnsmasq.d/pxe.conf, replacing the single iPXE dhcp-boot line
dhcp-host=aa:bb:cc:dd:ee:01,10.10.50.21,pve01
dhcp-host=aa:bb:cc:dd:ee:31,set:pbs,10.10.50.31,pbs01

dhcp-boot=tag:ipxe,tag:!pbs,http://pdm.example.doc/pve-9.2/boot.ipxe
dhcp-boot=tag:ipxe,tag:pbs,http://pdm.example.doc/pbs-4/boot.ipxe

set:pbs en una reserva etiqueta esa máquina concreta³¹, y tag:!pbs mantiene las dos líneas de arranque mutuamente excluyentes, así que no hay duda de cuál gana. El boot.ipxe de cada producto ya arranca su entrada automatizada a los diez segundos sin nadie al teclado¹⁵.

Estas líneas pasan dnsmasq --test en la 2.91, la versión de mi laboratorio, y siguen la sintaxis documentada de dhcp-host y de las etiquetas. Todavía no he arrancado por PXE un nodo PBS a través de ellas, así que prueba con una máquina etiquetada antes de fiarte.

A partir de ahí es el mismo camino que Proxmox VE. El instalador de PBS envía "product": "pbs", Caddy pone el token de la sede, y PDM elige la respuesta de PBS de esa sede. No se elige nada a mano en ningún momento, y el producto en que se convierte un nodo queda escrito en un solo sitio, la reserva, junto a su dirección.

El instalador solo pone el sistema operativo. El datastore, en un almacenamiento separado del disco del sistema, es otro trabajo para lo que termine el nodo, y eso nos devuelve al gancho de primer arranque que falta.

Lo que queda por decidir

Nada de esto te impide usar este diseño. Cada punto necesita a alguien que se haga cargo de él.

Una primera versión, bien aprovechada

Esta es la primera versión de la función, y para ser la primera es buena. El formulario de respuestas es sensato, las reglas de selección quedan claras en cuanto las lees, el webhook funciona, y el código es abierto, que es la única razón por la que todo lo anterior se ha podido demostrar en lugar de suponer. La serie de parches pasó por cuatro rondas en la lista de correo pública antes de entrar³⁵, y se nota.

Los huecos son las dos cosas que convierten un servidor de instalación en un sistema de aprovisionamiento. La sede es la unidad con la que piensa un MSP, y el instalador está pisándola cuando pregunta. Un gancho de primer arranque es la diferencia entre un nodo instalado y un nodo terminado. Los dos ya están a medias: el instalador tiene el gancho y PDM tiene el token. Espero que lleguen los dos, y cuando lleguen, el Caddy en medio de este diseño se simplificará en lugar de desaparecer, porque un proxy que mantiene los secretos de PDM fuera de alcance y el 8443 fuera de la red merece la pena de todas formas.

La razón para hacerlo así mientras tanto es la del principio. Diez servidores PXE son diez cosas desfasándose a diez velocidades distintas, y cada una solo se mira cuando falla el día que la necesitas. Un solo entorno, puesto al día una vez, con la sede deducida por la red y los secretos guardados en un solo sitio, es menos que mantener. Menos que mantener es menos en lo que equivocarse, y eso es casi todo el trabajo.