Skip to main content

"IP fantasma: un backup en data/admin/ips/ deja nginx y Apache sin arrancar"

  • Ámbito: DirectAdmin (cualquier versión), nginx y/o Apache
  • Autor: Abdelkarim Mateos
  • Actualizado: 2026-07-17
  • Gravedad: alta — el servidor deja de servir TODA la web

El síntoma

Ni nginx ni Apache arrancan. En el journal:

nginx: [emerg] host not found in "192.0.2.10.bak.20260709" of the "listen" directive
       in /etc/nginx/nginx-vhosts.conf:3


AH00526: Syntax error on line 31 of /etc/httpd/conf/extra/httpd-vhosts.conf:
       <VirtualHost> directive missing closing '>'

Fíjate en el nombre: 192.0.2.10.bak.20260709. DirectAdmin está intentando escuchar en una «IP» que en realidad es el nombre de un fichero de backup.

Si el monitor de servicios de DirectAdmin está activo, reintentará arrancarlos periódicamente y enviará un aviso por cada intento fallido. Eso llega al buzón como «nginx se cae cada hora» y hace pensar en una intermitencia — pero no es intermitente: es una caída continua. Cada correo es un reintento, no una caída nueva.

El mecanismo

DirectAdmin enumera el directorio /usr/local/directadmin/data/admin/ips/ tratando CADA NOMBRE DE FICHERO como una entidad IP. No lee un índice ni valida el formato: lo que hay en ese directorio es la lista de IPs del servidor.

Si dejas ahí un backup:

# /usr/local/directadmin/data/admin/ips/

192.0.2.10                  ← la IP legítima (diradmin:diradmin)

192.0.2.10.bak.20260709     ← un backup: DirectAdmin lo lee como OTRA IP

…al generar las configuraciones de nivel servidor concatena ambos «nombres de IP» en el token de la plantilla y produce esto:

   server {
        listen       192.0.2.10.bak.20260709

192.0.2.10:80;

        server_name  hostname.ejemplo.com 192.0.2.10.bak.20260709

192.0.2.10;

                proxy_pass http://192.0.2.10.bak.20260709

192.0.2.10:8080;

y en Apache un <VirtualHost> partido en dos líneas — de ahí el «missing closing >».

Por qué es traicionero: el daño es LATENTE

Este es el punto importante.

data/admin/ips/ solo se lee cuando se regeneran las configuraciones de nivel servidor. Mientras nadie las regenere, el fichero de más convive ahí sin causar ningún daño: días o semanas.

La avería aparece cuando algo dispara esa regeneración:

  • Una actualización de DirectAdmin.
  • Un ./build update_versions.
  • Un ./build rewrite_confs.
  • Cualquier mantenimiento que toque el stack del panel.

Consecuencia práctica: quien detona la mina no es quien la puso. El cuadro típico es «hice un mantenimiento rutinario y el servidor se quedó sin web» — y la conclusión fácil («lo rompió la actualización») es falsa: la actualización solo reveló un fichero que llevaba semanas ahí. Si te pasa, no cierres culpando al mantenimiento: mira el directorio.

Detección: cuesta un ls

Cualquier nombre en ese directorio que no sea una IPv4 o IPv6 válida es una mina armada:

ls -1 /usr/local/directadmin/data/admin/ips/ 2>/dev/null \

  | grep -vE '^([0-9]{1,3}\.){3}[0-9]{1,3}$|^[0-9a-fA-F:]+$'
  • Salida vacía: limpio.
  • Cualquier línea: mina armada — arréglalo antes de tocar el servidor.

Merece la pena incorporarlo al pre-flight de cualquier mantenimiento de paquetes o del panel, porque es precisamente ese mantenimiento el que la detona. Detectarla después es llegar tarde.

Solución

# 1. Retirar el fichero FUERA del árbol de datos (mover, no borrar)
mkdir -p /root/da-stray-backups
mv /usr/local/directadmin/data/admin/ips/192.0.2.10.bak.20260709 /root/da-stray-backups/

# 2. Regenerar las confs de NIVEL SERVIDOR
cd /usr/local/directadmin/custombuild && ./build rewrite_confs

# 3. Verificar sintaxis y arrancar
nginx -t && httpd -t
systemctl start httpd nginx

Antes de retirarlo, comprueba que el backup no contiene nada que necesites: lo habitual es que solo difiera en value= (el contador de uso que DirectAdmin recalcula solo en el tally nocturno), es decir, que sea basura sin valor.

Trampa: rewrite_confs no es lo mismo que la task queue

Este paso se falla a menudo:

  • echo "action=rewrite&value=httpd" >> data/task.queue + dataskq → NO basta. Regenera únicamente los vhosts de usuario (data/users/*/nginx.conf). Tras ejecutarlo, nginx-vhosts.conf sigue roto y parece que el arreglo no ha funcionado.
  • Los ficheros de nivel servidor (nginx-vhosts.conf, httpd-vhosts.conf) los genera CustomBuild → hace falta ./build rewrite_confs.

Y no pierdas el tiempo editando nginx-vhosts.conf a mano: es autogenerado. Mientras la causa siga en la capa de datos, DirectAdmin lo reescribirá igual de roto en la siguiente pasada.

Dónde SÍ y dónde NO

No todo backup dentro del árbol de DirectAdmin es una bomba. Solo data/admin/ips/ tiene la semántica «un fichero = una entidad»:

Directorio Cómo lo lee DirectAdmin Un .bak ahí es…
data/admin/ips/ enumera por nombre de fichero una bomba — IP fantasma
conf/ por nombre exacto (directadmin.conf) inerte (basura)
data/admin/ por nombre exacto (cluster.conf…) inerte (basura)
data/users/<user>/ por nombre exacto (user.conf…) inerte (basura)

Dicho de otro modo: un backup en conf/ es desorden; un backup en data/admin/ips/ deja el servidor sin web.

La regla

Un backup NUNCA va dentro del árbol de datos del panel. Va fuera: /root/, /var/backups/, donde quieras — pero fuera.

Es tentador hacer cp fichero fichero.bak en el propio directorio antes de editar algo: es el reflejo de toda la vida y en el 99% de los sitios es inofensivo. En data/admin/ips/ te cuesta la web del servidor entero, y te la cuesta semanas después, cuando ya nadie relaciona una cosa con la otra.

# MAL — el backup se convierte en una IP fantasma
cp /usr/local/directadmin/data/admin/ips/192.0.2.10{,.bak}

# BIEN — el backup vive fuera del árbol
cp /usr/local/directadmin/data/admin/ips/192.0.2.10 /root/192.0.2.10.bak
Back to top