Cloud-init e imágenes de máquina
Dos maneras de saltarte la instalación manual: pega una plantilla de cloud-init al crear un VPS, o construye una imagen de máquina que ya lo tenga todo instalado.
Cloud-init (un servidor a la vez)
panel/deploy/cloud-init.yaml es una plantilla de user-data. Edita los pocos ajustes de la
parte superior, pégala en la casilla "user data" de tu proveedor al crear el servidor, y el
panel está en marcha cuando el servidor termina de arrancar. El progreso y cualquier fallo aparecen en
/var/log/nimbopanel-provision.log.
No trates el user data como un almacén de secretos
Esta es la parte que vale la pena leer dos veces. En todos los proveedores importantes, el user data sigue siendo
recuperable desde dentro de la instancia en ejecución por HTTP en 169.254.169.254,
y esa dirección es alcanzable por cualquier proceso de la máquina, incluido el script PHP de un
cliente de hosting.
Así que una clave de licencia pegada en el user data es legible por cada cliente que alojas, salvo que algo lo impida. La plantilla lo impide en dos pasos, en este orden:
- cierra el servicio de metadatos a todos excepto root, antes de que la clave llegue al disco;
- después de que el instalador haya almacenado la clave en configuración accesible solo por root, tritura la copia en disco del user data.
Si prefieres no poner la clave allí en absoluto, déjala en blanco e introdúcela desde el panel después. El servidor funciona sin licencia hasta que lo hagas, lo cual es un estado compatible.
Imágenes de máquina (muchos servidores de una sola construcción)
panel/deploy/packer/nimbopanel.pkr.hcl construye una imagen con toda la pila
instalada. Ahí es donde se van los minutos —paquetes, PHP, correo, DNS, la base de datos—
y nada de ello difiere entre servidores.
El error que hace que cada clon sea el mismo servidor
Una imagen no debe contener ninguna identidad. Si lo hace, cada servidor construido a partir de ella comparte esa identidad:
| Incrustado por error | Qué ocurre en cada clon |
|---|---|
| Claves de host SSH | Todos presentan la misma clave. Cualquiera situado entre un cliente y su servidor puede suplantarlo, en todos ellos, sin que se muestre ningún aviso |
| El instance-id de Nimbopanel | La huella de licencia deriva de él, y el instalador nunca vuelve a sembrar un id que ya existe, así que mil servidores parecen una sola activación |
/etc/machine-id |
La identidad de systemd, los leases de DHCP y journald colisionan |
| La base de datos y la configuración del panel | La contraseña de administrador, la clave de licencia y cada cuenta viajan dentro de un archivo que los desconocidos descargan |
| Claves DKIM, certificados TLS | Emitidos para la máquina de construcción; sin sentido en un clon, y filtrados a todos los que tengan la imagen |
Ninguno de estos se anuncia. Se encuentran más tarde, por otra persona.
panel/deploy/image-deidentify.sh elimina todo eso, y la construcción de Packer lo ejecuta
como último paso y luego lo vuelve a ejecutar con --check, de modo que una construcción falla en lugar
de producir una instantánea que solo parece limpia. Todo lo eliminado se recrea en
el primer arranque del clon: sshd genera nuevas claves de host, systemd escribe un nuevo
machine-id, el instalador siembra un instance-id nuevo.
/etc/machine-id se deja vacío, no eliminado: systemd lee un archivo vacío como
"genera uno al arrancar", mientras que un archivo ausente impide que algunas imágenes arranquen del todo.
Verifica antes de publicar
sudo ./image-deidentify.sh # remove
sudo ./image-deidentify.sh --check # confirm, exits non-zero if anything survives
Ejecuta la comprobación también en un clon arrancado, no solo en el momento de la construcción. Si informa de algo, no publiques la imagen.
Publicaciones en marketplaces
Los programas de "1-click app" de los proveedores (Vultr, DigitalOcean, Linode, Contabo) tienen cada uno su propio formato de envío y revisión. La imagen de arriba es el artefacto que piden; el papeleo es específico de cada proveedor y no es algo que esta herramienta pueda hacer por ti.