Tips de Directadmin

Como ejecutar tu acceso a mysql en un Directadmin sin usar root
Introducción Mysql password en Directadmin
Muchos estamos habituados al uso de un 
.my.cnf en nuestro usuario para acceder como 
roota mysql.
En el caso de Directadmin la instalación por defecto no autroiza a root con el uso de sockets, si no que es una instalación personalizada, en la que el usuario que tiene privilegios globales se llama 
da_admin y tiene su contraseña guardada en 
/usr/local/directadmin/conf/mysql.conf
Si no queremos añadir otro usuario y conservar este sistema, podemos usar este comando (o generar un alias para usarlo ;-) )
mysql -u da_admin -p$(grep 'passwd' /usr/local/directadmin/conf/mysql.conf | awk -F= '{print $2}')
Alternativa .my.cnf
La otra es la de siempre, si confias en ella que en realidad es mas segura que pasar un password por un script, que es editar el fichero 
/root/.my.cnf
[client]
user=da_admin
password=PasswordObtenidodelFecijeroDeConfiguracion
En ese caso tendras que podres hacer 
sudo mysql xxxx
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Desactivar el acceso público a PhpMyAdmin en Directadmin
Introducción
Nunca me ha gustado tener phpMyAdmin activo en mis servidores, pero es algo inevitable. Lo usuarios no tiene porque saber acceder a mysql para hacer ciertas cosas, y además el 99% de los super tutoriales para hacer cosita estan basados en esa herramienta.
Pero eso sin, lo que no nunca permito es el acceso directamente. Al mnso que el phpMyAdmin goce de la capa de protección adicional de estar logeado en el cpanel.
Eso supone que si tienes un desarrollador web, que lo necsita y no le quieres dar acceso, un par de cosas:
Un desarrollador de verdad, no necesita acceso a phpMyadmin
Un desarrllador de verdad, no necesita acceso remoto via 3306 (puerto de mysql el cual tambien suelo capar) sino acceso SSH para acceder via tunel
Si de verdad necesitas trabajar como desarrllador sobre mysql te recomiendo usar Mysql sobre SSH
Desactivar el acces público de phpMyAdmin en Directadmin
Versión en el momento de escribir el artículo: 1.666
Quiero que todo el acceso a /phpMyAdmin sea accesible solo a través de DirectAdmin.
da build set phpmyadmin_public no
da build phpmyadmin
Incio de sessión SignOn en PhpMyAdmin
Inicio de sesión con un solo clic (Single SignOn) a PHPMyAdmin
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Tips rápidos de Directadmin
Introduccción
Algunas veces las cosas son difíciles por la confusión generada en la propia documentación de lo que usamos.
Y esto puede llevarnos a la desesperación.
Aquí te dejo trucos y si tienen modificación tras alguna nueva versión con su versión desde la cuál se comprobó. El documento se empezó en julio de 2024 con la versión 1.6.6
Lo pongo en inglés el tablero porqué jamás uso el español como idioma en el software, ya que los mejores manuales y tutoriales esta en el idioma de Sakespeare 😉.
Después de cualquier modificación que queramos que sea aplicada debemos hacer un restart de DirectAdmin 
systemctl restart directadmin
Última actualizacion: 7/08/2024 18:00 GMT +2
Índice
Apuntes sobre Let's Encrypt For Services en la documentación oficial de DirectAdmin
Actualizar la quota de una cuenta de correo
Cambia el email del admin
Cambio del hostname
Cambia valores de configuración de Directadmin en el shell
Cloudflare para el tablero o panel de control Directadmin
Composer en Directadmin
Let's encript para dominios que han fallado
Valores por usuario en el user.conf
Webmail impersionation - OneClick
directadmin license-expired
Apuntes sobre Let's Encrypt For Services en la documentación oficial de DirectAdmin
Let's Encrypt For Services
Actualizar la quota de una cuenta de correo
Muchas veces el usuario cambia o purga el contenido de sus cuentas de correo y llos cambios no se ven reflejados inmediatamente en Directadmin.
Esto es frustrante para el usuario y para el técnico de soporte.
Las cuotas no son algo instantaneo, y se ejecutana cada cierto tiempo, y son globales, lo que hace que el tiempo es largo. Ademas de que generalmente esas cosas se hacen de noche y observando algunas pautas apara evitar sobrecargas.
Podemos actualizar los datos de un cliente con este comando de Devecot doveadm quota recalc
doveadm quota recalc -u user@domain.ltd
Después podemos verificar con:
doveadm quota get -u user@domain.ltd
Quota name Type    Value Limit                                                                                           %
           STORAGE     0     -                                                                                           0
           MESSAGE     0     -                                                                                           0
Cambia el email del admin
Vía rápida por SSH
Editando el fichero 
/usr/local/directadmin/data/users/admin/user.conf la variable 
email= y haciendo un restart de 
directadmin
systemctl restart directadmin
Igual tienes que revisar el CSF para las notificaciones
Vía tablero en 
Dashboard > User Profile > General
Change admin email?
Cambio del hostname y forzar certificado de hostname
En principio uno pensaría que con cambiar el hostname en el 
Tablero > Admin > Server Manager > Administrator Settings > Server Settings se producirían todas las acciones necesarias.
Pues no. Y además, si buscas, puede que lo encuentres a la primera pero puede que comiences un viaje a ninguna parte. Hostname change does not work properly.
Aquí te lo dejo mas formalito, y se entiende que 
hostname -f te resuelve el Hostname que tu quieres y tienes ya configurado para resuelva a tu servidor.
/usr/local/directadmin/scripts/letsencrypt.sh server_cert `hostname -f`
Cambia valores de configuración de DirectAdmin en el shell
En la documentación tenemos todos los valores de configuración de Directadmin que puedes manejar en el shell.
Algunos de los son muchísimo más prácticos que ir buscando por su tablero de mandos.
Se cambian con:
da config-set variable value
systemctl restart directadmin
O también con
/usr/local/directadmin/directadmin config-set variable value
systemctl restart directadmin
Si quieres buscar alguno o un grupo por palabra que buenbo usar 
grep
cat /usr/local/directadmin/conf/directadmin.conf | grep dkim
dkim=2
Hay variables que no funcionan con  
da config-set y hay que editarlas manualment.
A veces es mucho más práctico conocer la variable que ir buscando por el tablero
Cloudflare para el tablero o panel de control
Interesante usar el tablero en otro puerto (por imperativo de Cloudflare) pero muy interesante para evitar un buen porcentaje de bobos haciendo pruebas contra tu panel.
Habilita el modo Cloudflare en tu registro que apunta a tu máquina, y comienza a funciona por el puerto 2096
da config-set port 2096
❯ systemctl restart directadmin
Si tras hacer el cambio, tu panel de control Directadmin hace parpadeo (blinking,) elimina en las herramientas del desarrollador (Webmaster Tools), todo lo que hay en Almacenamiento y vuelve a hacer login.
Composer en Directadmin
Por defecto no esta instalado, composer v2 en Directadmin
da build composer
Let's Encrypt para dominios que han fallado al crearse (SSL)
A veces puede darse que falle la creación de los certificados de un dominio. Meor que perder el tiempo en el tablero lo podemos solventar via terminal
domain=domain.tld
/usr/local/directadmin/scripts/letsencrypt.sh request $domain 4096
Entendemos 
domain.tld como un fake que debemos sustituir.
El dominio ya resuelve de forma global a nuestra máquina.
Let's Encrypt For Domains
Valores por usuario en el 
user.conf
Muchas veces es posible que deseemos no estar tan limitados a los valores globales o aplicados por cuestión de un plan, o de los valores del usuario en la administración. Incluso hay valores que no están reflejados en el panel de administración, como puede ser el caso de la limitación del número de correos por usuario.
En este caso, entra en funcionamiento el 
override o 
sobrescritura de los valores de configuración, que podemos ejecutar ya sea con la edición del fichero 
/usr/local/directadmin/data/users/<USER>/user.conf o con el uso de la API.
Cambio del 
max_per_email_send_limit por usuario
Un ejemplo es el de cambiar el valor máximo que limita el envío de correos por día, algo muy útil en el entorno de hosting para evitar entrar en listas de spam, ya sea porque han hackeado una cuenta, un script abierto sin protección, etc.
En este caso, para permitir a un usuario saltarse el límite para una cuenta en concreto (atención, él podrá aplicar esto a todas sus cuentas, y lo lamento, pero hay mucho espabilado, así que tendréis que tener un mecanismo de vigilancia de su uso).
El cambio de forma global autorizaría a todos los usuarios al uso del máximo, en todas las cuentas configuradas como máximo en ese valor. Sin embargo, si lo hacemos modificando el fichero 
/usr/local/directadmin/data/users/<USER>/user.conf añadiendo 
max_per_email_send_limit=VALUE y haciendo un restart del servicio de Directadmin, el usuario podría en todas sus cuentas añadir dicho límite.
Webmail impresionation o OneClick
Para administradores y resellers, se puede realziar un impersonation, o como llaman en Directadmin, OneClik, para que el administrador puede acceder al roundcube. Información adicional: One-Click login to RoundCube
da config-set one_click_webmail_login 1
systemctl restart directadmin
da build dovecot_conf
da build exim_conf
da build roundcube
Sobre la discusión de la legalidad de esta accion, muchos paracen olvidar que el hoster, ya en su contrato (si se hizo correctamentre) es el responsable de la custodia de los datos, y por la naturaleza de sus credenciales, esta habilitado a ver todo. Si bien no de forma directa, si puede verlo desde el shell. Asi pues, en ese contrato, de responsabilidad, queda implícito que existe un total acceso a los datos de los clientes, suscrito a la profesionalidad y la confidencialidad, limitandose esos accesos a los estrictamente necesarios, para el buen funcionmiento del servicio.
directadmin license-expired
Aqui hablamos de un escenario, en el que en realidad el problema estaba relacionado con una sobre carga de tareas del Directadmin que se pueden ver con 
journalctl -u directadmin, pero esta página del manual de directadmin es muy interesante.
License expired
sobre todo, por que encontraremos el comando para refrescar la licencia en Permanent license error 'invalid license key'
Asi que en realidad, aqui tenemos información para muchas situaciones diferentes que afectan al sistema de licencia de Directadmin.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

ModSecurity en DirectAdmin
Introducción
El uso de ModSecurity esta altamente recomendado. El software eactual, y mas con la proliferación de expertos en javascript o creadores de temas y plugins hacen más que necesaria una capa adicional de seguridad en la llamadas al servidor web.
ModSecurity en Directadmin con owasp
En mi caso opto siempre por owasp.
ModSecurity Documentación para Directadmin
Algunos tips.
Al principio es una pesadilla, pero lo mejor es no desactivar pro defecto. Es lo que hacen el 99% de los hosters que no quieren lios con sus clientes, pero luego sus clientes mueren una y otra vez de hackeos, inyecciones de código malicioso, y problemas de seguridad.
Si alguna regla (rule ID) la tienes clara y documentada, puede desactivarla en el manager de ModSecurity que esta accesible en 
/evo/admin/modsecurity
Esas reglas son globales, es decir las desactivas para todo el mundo, asi que ten muy claro que las desactivas por es necesario.
Muchas reglas son necesarias para determinado templates famosos, crm y plugins que son famosos, y pese a ello, una autentica verguenza de codificación. Queda en tú política el permitirlo de forma global o obligar al usuario a que el actualice sus reglas haciendose responsable de su seguridad.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

DKIM, SPF y DMARC para el hostname de un servidor con Directadmin
Introducción
La importancia de tener al día y configurado un servidor y su hostname es crucial, para que el correo emitido por el servidor como tal (alertas, mensjaes al usuario, etc) y la fiabilidad del propio servidor es crucial.
Por el ello uno de los grandes olvidados es tener el SPF, DKIM, y DMARC para el 
hostname
Proceso de creación de los reegistros SPF, DKIM y DMARC en un host con Directadmin
Creación de la zona
Con indipendencia de si el hostname esta controlado por un dominio cuyo sistema de resolución es distinto al de la maquina, ya sea por DNS locales o por un cluster externo, o por un proveedor externo como Cloudflare, debemos crear una zona para el hostanme en el tablero.
SPF
Si lo tienes correctamente configurado (te aconsejo que pases por la documentación All Directadmin Conf Values ya que si esta configurado el lo creara automaticamente
Si lo configuras tambien puedes modificar los valores por defecto, muy útil cuando tenemos servidores de correo de relay, etc.
Para ello además de la configuración hay que crear un fichero  
/usr/local/directadmin/data/templates/custom/dns_txt.conf
|DOMAIN|.="v=spf1 a mx ip4:|SERVER_IP||EXTRA_SPF||SPF_IPV6| -all"
DKIM
EL DKIM lo podremos crear ahora que ya existe la zona, con:
 /usr/local/directadmin/scripts/dkim_create.sh `hostname -f`
Esto generará la entrada adecuada en el fichero de zona del hostname.
DMARC
Procederemos a editar el fichero anterior 
/usr/local/directadmin/data/templates/custom/dns_txt.conf para añadir el registro 
_dmarc
_dmarc="v=DMARC1; p=none; sp=none;"
Ahora nuestro fichero tendra algo así:
|DOMAIN|.="v=spf1 a mx ip4:|SERVER_IP||EXTRA_SPF||SPF_IPV6| -all"
_dmarc="v=DMARC1; p=none; sp=none;"
NO es el alcance de este tutorial el explicar si usar o no usar rua en el registro, y lo que dice Google y lo que dice Microsoft.
Proceso adicional si el sistema de DNS no es el del servidor
Si como suele ser habitual, el control de DNS del hostname no es una DNS local o del cluster deberemos abrir el fichero de zona, ya sea en el Tablero de Directadmin o en el shell, para copiar el contenido de estos registro de zona y copiar en la zona del dns que controla el dominio del hostname.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

PHP en shell para usar wp cli en DirectAdmin
Introducción
En este caso y para facilitar las cosas a los usuarios de Directadmin, en el que como norma general se instalan distintas versiones de PHP y la principal del servidor puede ser incompatible connuestras necesidades es mejor usar la que necesitamos.
Aunque este tip es para DirectAdmin, vale para cualquier distribución Linux o *nix. adaptando el tip a tu SO
PHP en shell para usar wp cli - Version cPanel
Ejemplo
 wp core update && wp plugin upgrade --all && wp theme upgrade --all
Fatal error: __autoload() is no longer supported, use spl_autoload_register() instead in /home/user/public_html/wiki.dominio.com/wp-includes/compat.php on line 502
 php -v
PHP 7.2.34 (cli) (built: Mar 28 2023 21:20:00) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with the ionCube PHP Loader + ionCube24 v10.4.5, Copyright (c) 2002-2020, by ionCube Ltd.
    with Zend OPcache v7.2.34, Copyright (c) 1999-2018, by Zend Technologies
El usuario tiene una versión correcta en la que todavía no estaba declarada obsoleta la función 
__autoload()
Si estamos como usuario
$ which php
/usr/local/php74/bin/php
$ which wp
/usr/local/bin/wp
Ahora solo nos queda llamar al wp-cli de forma adecuada 
74 es la versión que queremos usar
/usr/local/bin/wp es el path de instalación global de la herramienta wp
/usr/local/php74/bin/php /usr/local/bin/wp core update
Tip
Esto podemos añadirlo a nuestro fichero de configracion del shell usado.
Por ejemplo y para el caso de que tengamos mas de un sitio web con distintos requerimientos mejor usar este formato
wp74="/usr/local/php74/bin/php /usr/local/bin/wp"
wp82="/usr/local/php82/bin/php /usr/local/bin/wp"
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Limpieza de mysql tras una migración: permisos de host antiguos
Introducción
Cuando se realizan migraciones entre servidores, ya sea cPanel a Cpanel, cPAnel a Directamdin,, siempre quedan proquerías que hay que limpiar.
Una de ellas son las entradas en la tabla 
user de mysql/maridab en la que se conservan los hosts remotos de antiguos servidores.
He visto alguna vez cuando me han contratado para un mantenimiento de un servidor y un tunning, servidores con mas de 1000 usarios mysql, y que llevaban arrastrando 4 o 5 hosts de distintos servidores, de migración en migración.
Luego, claro, mysql va lento.
Nota. No es precismanet la raíz del porblema, peoro cuando en el jardin dejas malas hierbas, al final caban poniendose feo.
Revisión
Accedemos a nuestro mysql
> mysql
SELECT User, Host FROM mysql.user;
+--------------------------+--------------------+
| User                     | Host               |
+--------------------------+--------------------+
| cdbtnet                  | localhost          |
| cdbtnet                  | old.server.com     |
| cdbtnet                  | old2.server.com    |
...
Cramos el script
El escript se ejecuta pasandole un parámetro:
El nombre del host a eliminar
ATENCIÓN
ESTE COMO TODOS LOS COMANDOS DE ELIMINACION DEBE HACER LEYYENDOSE, ENTENDIENDOLO Y CON ... BACKUP
#!/bin/bash
# Verificar que se haya pasado un parámetro
if [ $# -eq 0 ]; then
    echo "Debe proporcionar un host para eliminar los usuarios. Uso: $0 <host>"
    exit 1
fi
# Guardar el parámetro proporcionado como el host a eliminar
delete_host=$1
# Variables de conexión a la base de datos
db_user="da_admin"
db_password=$(grep 'passwd' /usr/local/directadmin/conf/mysql.conf | awk -F= '{print $2}')
db_host="localhost"  # Cambia si tu base de datos no está en localhost
# Comando para listar usuarios del host específico
list_users_command="SELECT user, host FROM mysql.user WHERE host='${delete_host}';"
# Conéctate a MySQL y obtiene la lista de usuarios
users=$(mysql -u "$db_user" -p"$db_password" -h "$db_host" -Bse "$list_users_command")
# Verificar si se obtuvieron usuarios
if [ -z "$users" ]; then
    echo "No se encontraron usuarios con host '$delete_host'."
    exit 0
fi
# Generar y ejecutar los comandos de eliminación de usuario
while IFS=$'\t' read -r user host; do
    if [ ! -z "$user" ] && [ ! -z "$host" ]; then
        drop_user_command="DROP USER '$user'@'$host';"
        mysql_command="mysql -u \"$db_user\" -p\"$db_password\" -h \"$db_host\" -e \"$drop_user_command\""
        echo "Ejecutando: $drop_user_command"
        eval $mysql_command
        # Verificar si el comando se ejecutó correctamente
        if [ $? -ne 0 ]; then
            echo "Error al ejecutar: $drop_user_command"
        else
            echo "Usuario eliminado con éxito: $user@$host"
        fi
    fi
done <<< "$users"
chmod +x nombre_script.sh
./nombre_script.sh 5.0.0.0
....
Ejecutando: DROP USER 'tblrmmll_root'@'5.0.0.0';
Comando que se ejecutará: mysql -u "da_admin" -p"ElPaSsWoRd" -h "localhost" -e "DROP USER 'tblrmmll_root'@'5.0.0.0';"
...
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Activar DKIM a todos los dominios de un servidor con Directadmin
Introducción
DKIM es pieza fundamental en el sistema actual de antispam, y sobre todo para garantizar que nuestro dominio y/o Ip no loleguen a ser considerados como SPAM.
Configuracion DKIM global
Indicada en el manual, directadmin.conf - #dkim  nos indica que la variable es 
dkim
Valor
Comentario
0
DKIM está deshabilitado por defecto para los nuevos dominios
1
DKIM está habilitado por defecto para los nuevos dominios
2
La funcionalidad de DKIM está habilitada, pero no es obligatoria para los nuevos dominios
Podemos editarlo manualmente o usar por ejemplo:
da config-set dkim 1
cd /usr/local/directadmin/custombuild
./build update
./build exim
./build eximconf
o
da build update
da build exim
da build eximconf
Esta configuración hará que todos los dominios futuros, se configuren con DKIM.
Para dominios existentes
Es probable que en una migración o situación especifica, el administrador deseé poner el valor a 
2 para poder realizar la migración sin añadir una capa de complejidad.
Bien, una vez asentado todo, o bien porque había dominios anteriores sin DKIM, procedemos:
Atención: Si hay ya dominios que no quieren tener DKIM, ya sea porque no saben como usar servicios exteriores de correo sin configurarlo correctamente o porque no se lo explicarón, se puede producir problemas con ellos. Tener en cuenta.
Habilitar la creación automática de registros DKIM no afecta a los dominios existentes. Tienes algunas opciones para agregar DKIM a los dominios antiguos una vez que has habilitado DKIM en el archivo 
directadmin.conf. Puedes hacerlo para cada dominio uno por uno o para todos los dominios existentes a la vez.
Para habilitar DKIM para todos los dominios existentes después de configurar DKIM en 
1 en el archivo directadmin.conf, puedes ejecutar el siguiente comando a través de SSH como el usuario root.
echo "action=rewrite&value=dkim" >> /usr/local/directadmin/data/task.queue; /usr/local/directadmin/dataskq
Para habilitar DKIM solo para dominios seleccionados uno por uno, utiliza ya sea la cola de tareas o el script 
dkim_create.sh proporcionado por DirectAdmin (reemplaza DOMAIN.COM con el dominio para el cual deseas habilitar DKIM).
/usr/local/directadmin/scripts/dkim_create.sh DOMAIN.TLD
o inmeditamente
echo "action=rewrite&value=dkim&domain=DOMAIN.COM&dns=yes" >> /usr/local/directadmin/data/task.queue; /usr/local/directadmin/dataskq
Ambos comandos funcionan de la misma manera, con la excepción de que puedes tener el DKIM escrito inmediatamente con dataskq en comparación con dentro de un minuto utilizando el script 
dkim_create.sh.
Deshabilitar DKIM por Usuario Cuando Está Habilitado o Permitido Globalmente
Esta función está diseñada para que DKIM esté habilitado o permitido globalmente, pero puedes deshabilitarlo a nivel de usuario.
Esto requiere que se establezca 
dkim=1 o 
dkim=2 en el archivo 
directadmin.conf.
La configuración de 
1 habilitará DKIM automáticamente para todos los dominios bajo cada usuario, a menos que especifiques lo contrario en sus archivos 
user.conf.
La configuración de 
2 les permitirá a los usuarios, habilitar DKIM por sí mismos, a menos que se especifique lo contrario en su archivo 
user.conf.
Ten en cuenta, que establecer 
dkim=0 en el archivo 
directadmin.conf deshabilita completamente DKIM para todo el servidor y los archivos 
user.conf no se verificarán. Por lo tanto, si deseas que DKIM esté deshabilitado globalmente por defecto con la opción de habilitarlo solo para ciertos usuarios/dominios, configurar 
dkim=2 en el archivo directadmin.conf es una mejor opción.
Cuando creas un usuario, se crea con un dominio predeterminado. Este dominio tendrá DKIM creado para el dominio por defecto debido a la configuración habilitada globalmente y la no existencia de un 
user.conf hasta que se cree la cuenta (no hay un 
user.conf para editar y deshabilitar DKIM).
Por lo tanto, se deberá eliminar manualmente DKIM para el dominio predeterminado si prefieres que no tenga un registro DKIM.
Aquí están los pasos para, primero eliminar el registro del dominio predeterminado y luego deshabilitar la creación automática de registros DKIM para los dominios subsiguientes bajo ese usuario.
Para eliminar los registros del dominio predeterminado, elimina el registro TXT 
x._domainkey de 
/var/named/DOMAIN.TLD.db y luego elimina las claves.
rm -f /etc/virtual/DOMAIN.COM/dkim.public.key
rm -f /etc/virtual/DOMAIN.COM/dkim.private.key
Ahora, edita el 
user.conf para que no se habiliten registros *DKIM para los dominios que se creen posteriormente bajo el usuario. El 
user.conf se puede editar a través de SSH como el usuario root y el archivo se encuentra aquí (donde USERNAME representa el nombre de usuario del usuario que estás editando),
/usr/local/directadmin/data/users/USERNAME/user.conf
Esto permite que la configuración de DKIM de ese usuario particular anule la configuración de DKIM habilitada globalmente establecida en el archivo 
directadmin.conf, evitando así que se creen registros DKIM para los dominios de ese usuario en adelante.
Reinicia DirectAdmin después de hacer los cambios.
systemctl restart directadmin
Deshabilitar DKIM a Nivel de Dominio
Esta es esencialmente la misma función que la característica a nivel de usuario, con la excepción de que editarías el archivo de configuración del dominio ubicado en 
/usr/local/directadmin/data/users/USERNAME/domains/DOMAIN.TLD.conf, en su lugar.
No es necesario editar el archivo 
user.conf del usuario para controlar DKIM a nivel de dominio.
Si un determinado dominio utiliza tanto un DNS remoto como un servidor de correo remoto, es posible que desees deshabilitar DKIM para este dominio en particular en lugar de para todos los dominios del usuario. Aquí es donde esta función es útil.
En realidad no es necesaria esta dudosa práctica usada, cuando el usuario final o la otra empresa que le ofrece servicios de correo, no le da las putas adecuadas) La gran mayoría de los sevricios de correo externo, si dan la información necesaria para crear y mantener un registro DKIM para cada servicios de correo, basandonos en el registro selector pero su complejidad y la falta de conocimientos llevan a un salida incorrecta. Pero este es otro tema del que hablaremos en otro post, en fechas próximas.
Reinicia DirectAdmin después de hacer cambios en el archivo DOMAIN.TLD.conf:
systemctl restart directadmin
Cambiar el Selector Predeterminado
DirectAdmin utiliza 
x como el selector predeterminado. Para cambiar el selector, necesitarás actualizar el archivo directadmin.conf con el selector deseado. Los siguientes ejemplos cambian el selector a 
default:
/usr/local/directadmin/directadmin set dkim_selector default restart
Necesitarás reconstruir la configuración de Exim de la siguiente manera:
/usr/local/directadmin/custombuild/build exim_conf
Confirma que el selector fue cambiado en el archivo 
/etc/exim.dkim.conf:
❯ grep -i selector /etc/exim.dkim.conf
  dkim_selector = x
Ahora, cualquier registro DKIM creado nuevo utilizará tu selector especificado. Ten en cuenta que necesitarás eliminar y recrear los registros DKIM antiguos que utilicen el selector antiguo si deseas que usen el nuevo selector.
Conclusión
Ya hemos revisado el procedimiento paso a paso para habilitar DKIM con el panel de control DirectAdmin.
Podemos decir, qu el registro DNS DKIM es esencial para un servicio de correo electrónico más fluido y para la autenticación de correos electrónicos.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Mod Security. Desactivación global de reglas por path
Introducción
Una vez más, con el tema de Mod Security, compruebo que el 99% de los administradores de sistemas, sigue la misma pauta de siempre, la salida hacia adelante más fácil, deshabilitando todo.
Soy cabezón, y no he basado mi seguridad en mis máquinas, en abrir la puerta menoscabando la seguridad perimetral.
Tengo cliente a los que llevo sus servicios, que son incapaces de aguantar en firme, con las normas y reglas de seguridad que trato de imponerles, pese a que eso suponga un aumento de costes en horas para limpiar problemas derivados de los mini hackeaos
Escenario
En el caso que me llevó a este tema, estaba implicado DirectAdmin y el webmail RoundCube en una situación algo especial.
Con las cuentas de sistema 
usuario usadas como cuenta de correo, RoundCube recibía una serie de errores al lanzarse prohibiciones vía Mod Security.
Connection Error (Failed to reach the server)!
!Error de conexión fallo al intentar alcanzar el servidor)!
Cuando teneos problemas con RoundCube como con muchas aplicaciones web, insisto a mis clientes que observen las webmaster tools del navegador y/o al menos las cabeceras de respuesta (406) más allá de los mensajes tipo Alert de las aplicaciones.
Al final, localizando las reglas afectadas por RoundCube a nivel hostname, salieron a la palestra las siguiente reglas afectadas:
911100
932260
920340
932235
941100
941130
941160
941170
949110
980130
Todas ellas, con Paranoia Level 1, ModSecurity :: Concepto Paranoia Level
Uy... que cosas. EL PR 1 es básicamente el nivel con menor número de falsos positivos, y muchas de estas rules, ofrecen una protección extraordinaria a muchos de los errores más comunes de los "programadores" de javascript.
Así que las soluciones que se presentan en, StackOverFlow, el foro de DirectAdmin, y otras muchas, no me convencían, porque se trata de atajos (workaround) que llevan a la desactivación de la regla de forma global, o en su defecto, no cumplen con la documentación de Mod Security o de DirectAdmin.
Solución (Actualizado 8/01/2025)
Al final vi el método antiguo (me llama mas la atención que el nuevo) ofrecido por Directadmin y que usamos en Como bloquear los Bad bots (Bot basura) usando ModeSecurity en Directadmin nueva que es mas manejable y programable.
/usr/local/directadmin/custombuild/custom/modsecurity/conf/
Hay que crear este path como repositorio de los ficheros especificos que creemos para el manejo de ModSecuirty sin miedo a que se eliminen.
mkdir -p /usr/local/directadmin/custombuild/custom/modsecurity/conf/
Fichero de exclusiones
En mi caso uso 
/usr/local/directadmin/custombuild/custom/modsecurity/conf/01_REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf, pero como es una precarga, le asigno nuemros bajos como 00, 01, 02 con el fin de que sean los primeros en cargar.
Tenemos un ejemplo de como tratar el tema en el fichero 
/etc/modsecurity.d/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example
 cp  /etc/modsecurity.d/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /usr/local/directadmin/custombuild/custom/modsecurity/conf/01_REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Una vez creado, o modificado, SIEMPRE debemos verificar primero (si usamos nginx o apache+nginx) que no hay ningun problema, con. Para ello escribimos la rule en el fichero real, 
/etc/modsecurity.d/01_REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf (copiar y pegar)
nginx -t
Una vez verificado, procedemos a reconstruir los ficheros de configuracion con:
> da build modsecurity_rules
Installing OWASP Core Rule Set for ModSecurity...
download_cached: using cached '/usr/local/directadmin/custombuild/cache/owasp-modsecurity-crs-4.9.0.tar.gz' file
Copying custom ModSecurity rules to /etc/modsecurity.d/...
Installation of ModSecurity Rule Set has been finished.
Después reconstruimos la configruación.
> da build rewrite_confs
cp: cannot remove '/etc/httpd/conf/extra/httpd-directoryindex.conf': Operation not permitted
2025/01/08 17:15:27  info executing task            task=action=rewrite&value=ips
2025/01/08 17:15:27  info finished task             duration=10.262712ms task=action=rewrite&value=ips
Using 5.135.93.75 for your server IP
Copying custom ModSecurity rules to /etc/modsecurity.d/...
Restarting apache.
Installing OWASP Core Rule Set for ModSecurity...
download_cached: using cached '/usr/local/directadmin/custombuild/cache/owasp-modsecurity-crs-4.9.0.tar.gz' file
Copying custom ModSecurity rules to /etc/modsecurity.d/...
Installation of ModSecurity Rule Set has been finished.
2025/01/08 17:15:31  info executing task            task=action=rewrite&value=ips
2025/01/08 17:15:31  info finished task             duration=7.557145ms task=action=rewrite&value=ips
Using 5.135.93.75 for your server IP
Using 5.135.93.75 for your server IP
Copying custom ModSecurity rules to /etc/modsecurity.d/...
2025/01/08 17:15:34  info executing task            task=action=rewrite&value=nginx
2025/01/08 17:15:40  info finished task             duration=6.360399294s task=action=rewrite&value=nginx
Restarting nginx.
Ya podriamos hacer pruebas.
Ejemplos
SecRule REQUEST_FILENAME "@beginsWith /roundcube" \
     "id:1001,\
     phase:2,\
     pass,\
     nolog,\
     ctl:ruleRemoveById=911100,\
     ctl:ruleRemoveById=932260,\
     ctl:ruleRemoveById=920340,\
     ctl:ruleRemoveById=932235,\
     ctl:ruleRemoveById=941100,\
     ctl:ruleRemoveById=941130,\
     ctl:ruleRemoveById=941160,\
     ctl:ruleRemoveById=941170,\
     ctl:ruleRemoveById=949110,\
     ctl:ruleRemoveById=980130"
Idea y apuntes
ModSecurity Rules: Global or for Hostname?
How do I skip certains rules for parameter in a path in ModSecurity?
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Reconstrucción del indice Full Text Search (FTS) en cuentas de correo :: Dovecot
Introducción
A veces ocurre que la correspondencia entre el tamaño en disco de una cuenta de correo usando los medios reales como son 
du no se corresponde con lo que DirectAdmin nos muestra en el panel de usuario para dicha cuenta de correo.
Esto suele ocurrir tras una eliminación de correo muy intensa en la que por cuestiones de espacio el usuario quiere ver liberada su couta por estar cerca de excederse o haberse excedido ya. Tmbien puede ocurri que sea un problema que requiere de un reconstrucción forzada.
Esos indices de busqueda pueden ser gigantes, del orden de varios GB.
doveadm-fts(1) -
Manipulate the Full Text Search (FTS) index
Basicamente podemos hacer lo siguiente:
## Cuenta E-mail
❯ doveadm fts rescan -u jmvarela@omnicon.es
## Usuario y todas sus cuentas
❯ doveadm fts rescan -u USERNAME
Tambien podemos usar un script para usarlo como mantenimiento de estos indices.
rescan_fts.sh
Cremos el fichero
#!/bin/bash
# Directorio que contiene los usuarios
USER_DIR="/usr/local/directadmin/data/users"
# Iterar sobre cada usuario (directorio)
for user in "$USER_DIR"/*; do
    # Verificar si el item es un directorio
    if [ -d "$user" ]; then
        # Obtener el nombre del usuario
        username=$(basename "$user")
        echo "Ejecutando doveadm fts rescan para el usuario: $username"
        # Ejecutar el comando doveadm fts rescan
        doveadm fts rescan -u "$username"
    fi
done
Damos permiso y ejecutamos
chmod +xrescan_fts.sh
./rescan_fts.sh
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Cambio el doc root de un dominio en DirectAdmin
Doc root, public, public_html
El software moderno desde hace años, evita la publicación del software en el mismo area publica o expuesta a internet. Por seguridad, por ordenación, el codigo usa el contenido en distintas carpetas dejando a una carpeta el destino de exposición al publico.
Este puede ser 
public como en el caso de Laravel, u otros distintos segun el framework.
Esto suele ser un problema para los hosters porque sus paneles de control usand el de toda la vida, 
public_html
En el camino, mucho se aventuran a enlace simbolicos, redirecciones. Y todo eso es muy bonito pero al final altera, no solo la realidad de la instalación sino un posible cambio de servidor, de paradigma de sistema, etc.
Cambiar el DOC ROOT en Directadmin
Si bien es sencillo, a veces parace que los manuales son algo espesos, y si encima tenemos un for de mas de 20 años de antiguedad, sin prunning, pues acabas por volverte loco con lso cambios en el tiempo.
En la actualidad es bien sencillo.
(Admin) Custom HTTPD Configurations
evo/admin/custom-httpd
Seleccionar el dominio (o subdominio entendiendose como entidad configurada como dominio independiente)
Después, deberemos modificar la configuracionde 
httpd.conf 
nginx.conf.proxy
En cada uno de ellas veremos un boton con la palabra Customize
Que la hacer click nos mostrará la caja de exto donde introducir nuestros cambios.
Aqui usando varmiables podemos adecuar a lo que queramos nuestros path. Ejemplo de abajo me sirve a mi porque se trata de una migracion que no queria complicar.
|?DOCROOT=`HOME`/domains/`DOMAIN`/public_html/public|
El resultado de eso sera que tras reconstruir la configuracion del 
doc root será 
/home/user/domains/subdomain.domain.tld/public_html/public
De esta forma el proyecto estará en el public_html, pero solo estará expuesta la carpeta 
public
da build rewrite_confs
Siemrpe, cuando terminemos deberamos reconstruir los ficheros de configruación, lo cual se hace con el comando 
da build rewrite_confs o bien en el botón de
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Donde está la configuracion básica del servidor con Directadmin
Directadmin configuración interna
Directadmin admin es más sencill oque otros panales de controla efectosd e localizar donde estan las conifguraciones que despliega en el servidor.
Directadmin, compila y configura el software de servidor, como Web (Apache, Nginx,..) Correo (Imap, exim,...) desde dos puntos claves:
Software de servicio
 /usr/local/directadmin/custombuild/options.conf
Directadmin (interno)
 /usr/local/directadmin/conf/directadmin.conf
Con estos fichero spodemos trabajar cosas como templates, clones, etc.
Esta entrada es una entrada rápida, de conocimiento básico.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Cambios especificados en el php.ini disable_functions por dominio (Directadmin example)
Cambiar individualmente en un dominio disable_functions
Un escenario muy común en sistemas y mas en estos cuando se usa Directadmin, es la salida hacia adelante obviando los problemas que puede causar nuestra decisión.
Un caso común es el quitar las protecciones de forma global a través de el proceso general del servidor, en lugar de buscar una solución individual, para el caso concreto.
En el caso de Directadmin, si tenemos la opción secure_php esta añadirá a la configuración del php del servidor
disable_functions = exec,system,passthru,shell_exec,proc_close,proc_open,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname
mysqli.allow_local_infile = Off
expose_php = Off
register_globals = Off
Existe el camino fácil, que es ir quitando las funciones que molestan a nuestros clientes, How to customize the disable_functions list y existe otro camino, que es desahbilitar al que nuestro cliente necesita, si esto es totalmente necesario, ya sea por un tiempo limitado, o de forma definitiva.
Opciones de php.ini por dominio
Opciones por dominio
o How to use per-domain or per-path settings for php
nos ayuda a esto último ya que tratar de modificar 
disable_functions via 
.user_ini aunque este autorizado, no funcionará para modificar esa clave.
Lo primero es buscar el path de nuestra instalación para nuestro Directadmin y nuestra distro.
En mi caso esta en 
/usr/local/phpXX/lib/php.conf.d
Así que, siguiendo el manual, introducido el path y el dominio o subdominio del que quiero tal corrección, el nos lo dará.
En nuestro caso el cliente tenia algunos despliegues con Laravel que necesitaban 
shell_exec por lo que lo eliminamos del fichero ini personalizado,
/usr/local/php83/lib/php.conf.d/30-subdomain.full.tld.ini
disable_functions = exec,system,passthru,proc_close,proc_open,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname
Después simplemente tenemos que hacer un rebuild de la función de seguridad.
da build secure_php
jit opcache.jit_buffer_size
Esta opción como muchas otras de php, tiene esta cuestión activa:
< opcache.jit_buffer_size es PHP_INI_SYSTEM, lo que significa que **solo puede definirse en php.ini o php-fpm.conf, no en .user.ini ni .htaccess.
Esto fuerza a usar el método de cambio
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Git desde DirectAdmin Interface
Git desde DirectAdmin Interface
Jamás le aconsejaría a nadie  usar el Git a través de un interface visual de este tipo, pero a veces por cuestiones de seguridad, metodologías y otras cuestiones, e las que el acceso a SSH esta restringido, puede ser el último recurso.
Aun así, no imagino una jefe de proyectos lidiando con un interface de esta naturaleza en la que por hacer fácil la cosa, el final se hace difícil.
En primer lugar es imperativo leer la documentación, (Git manager feature)[https://docs.directadmin.com/other-hosting-services/git/general.html]
Aquí tendremos una idea general de lo que nos espera.
El proyecto como root estará en el path que indiquemos
La configuración no esta en el root de nuestro proyecto, sino en 
/home/USER/domains/DOMAIN/name.git lo cual tendremos que recordarlo, si como es bine seguro, algún día deberemos lidiar con Git para arreglar o realizar operaciones más complejas que un simple click para hacer el equivalente a un git pull
Es importante la parte final, (Technical)[https://docs.directadmin.com/other-hosting-services/git/general.html#technical] donde veréis la información sobre como ejecutar 
git usando comando y las opciones a escribir parta entenderlo mejor.
To desde luego, no le aconsejo a ningún desarrollador o jefe de proyecto, el uso de esta interface. Menos si no tiene acceso a 
root ya que la BD con los datos del git estará ubicada en 
/usr/local/direcadmin/data/users/USER/user.db y las complejidades de uso no merecen la pena, a cambio de negarse a usar el terminal.
Nota
En estos tiempos, es muy sistémico, la falta de conocimientos de sistemas. Hemos llegado a un punto de especialización y de venta de supuestos sistemas amigables, que en realidad no lo son. Desconocer el uso de SSH, de los comandos básicos de git, de el como de aquellas cosas que operan en nuestro espacio profesional, es un serio handicap para la industria. Parece que aquí llego también el paradigma del conocimiento mínimo o lo que es lo mismo la falta de formación profesional adecuada
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Como bloquear los Bad bots (Bot basura) usando ModeSecurity en Directadmin v1
Introducción BadBots
El término "bot" se utiliza frecuentemente en internet y se refiere a un programa informático que automatiza acciones o tareas en la red. Aunque un bot no es inherentemente bueno o malo, puede clasificarse en alguna de estas dos categorías, dependiendo de si se utiliza con buenas o malas intenciones.
Bots Buenos
Se llama "bot bueno" a aquel que realiza tareas útiles o beneficiosas que no perjudican la experiencia del usuario en internet. Hay muchos bots que se consideran buenos, por ejemplo:
Bots de Motores de Búsqueda: A menudo conocidos como rastreadores web o arañas, son operados por grandes motores de búsqueda como Google o Bing.
Bots de Monitoreo de Sitios: Estos bots supervisan métricas de páginas web, como el seguimiento de enlaces o caídas del sistema, y pueden alertar a los usuarios sobre cambios importantes o tiempos de inactividad. Son utilizados por sitios como UptimeRobot o Cloudflare.
Bots de Feed: Estos bots recorren internet en busca de contenido para añadir a los feeds de noticias de diversas plataformas, y son gestionados por sitios de agregación o redes sociales.
Bots de Asistentes Personales: Aunque estos programas son más avanzados que un bot típico, siguen siendo considerados bots. Son programas informáticos que buscan datos en internet que coincidan con una búsqueda, y son operados por empresas como Apple (Siri) o Google (Alexa).
Bots Malos
Por otro lado, se refiere como "bot malo" a aquellos que realizan actos maliciosos, roban datos o causan daños en servidores, redes o sitios web. Pueden ser empleados para llevar a cabo ataques de denegación de servicio distribuido (DDoS) o para escanear servidores, redes o páginas web en busca de vulnerabilidades que puedan comprometer estos sistemas.
En los últimos años, hemos visto que los bots maliciosos se han convertido en un problema significativo tanto para los administradores de servidores como para los dueños de sitios web. Estos bots suelen dirigirse a un servidor o página web, realizando miles de solicitudes y recopilando grandes cantidades de datos en un tiempo muy corto.
Su practica, su diseño, y su falta de ética son un problema para muchos sitos, sus administradores y los administradores de sistemas.
Técnicas de bloqueo
Hay algunas técnicas de bloqueo como el uso de .htaccess a través de formulas como la expuesta en Bad Bots y la pesadilla del tráfico. Htaccess en Apache 2.4:
# Start Bad Bot Prevention
<IfModule mod_setenvif.c>
# SetEnvIfNoCase User-Agent ^$ bad_bot
SetEnvIfNoCase User-Agent "^12soso.*" bad_bot
SetEnvIfNoCase User-Agent "^192.comAgent.*" bad_bot
SetEnvIfNoCase User-Agent "^1Noonbot.*" bad_bot
...
<Limit GET POST PUT>
  Order Allow,Deny
  Allow from all
  Deny from env=bad_bot
</Limit>
</IfModule>
Pero esto es una pesadilla a nivel administrador de sistemas, donde cada uno pone su lista.
Para mi, la mejor es el uso de ModSecurity y como ya me dedico prioritáriamente a Directadmin lo dejaré aquí más claro.
Bad Bots bloqueados en Directadmin con ModSecurity
Para usar este método tenemos que hacerlo de manera que no se sobre escriba la configuración cuando se actualiza Directadmin, Apache o Nginx
Crear el directorio si no existe
cd /usr/local/directadmin/custombuild
mkdir -p custom/modsecurity/conf 
Crear 00_bad_bots_conf
nano /usr/local/directadmin/custombuild/custom/modsecurity/conf/00_bad_bots.conf
Contenido
# BLOCK BAD BOTS
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile bad_bot_list.txt" "phase:2,t:none,t:lowercase,log,deny,severity:2,status:406,id:1100000,msg:'Custom WAF Rules: WEB CRAWLER/BAD BOT'"
Atención a la rule ID, para que no choque con otra rules si tenias con anterioridad alguna adicional en otro sistema, o tienes un sistema para controlar las rules tuyas. Aquí usaremos 
1100000
Crear bad_bot_list.txt
Esta lista puedes actualizarla con la lista Apache Ultimate Bad Bot
El fichero a usar es 
https://raw.githubusercontent.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents-htaccess.list
wget -O /usr/local/directadmin/custombuild/custom/modsecurity/conf/bad_bot_list.txt  https://raw.githubusercontent.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents-htaccess.list
O con curl
curl -o /usr/local/directadmin/custombuild/custom/modsecurity/conf/bad_bot_list.txt https://raw.githubusercontent.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents-htaccess.list
También puedes crear una estrategia, para usando dicha lista eliminar o añadir los tuyos propios, cuando se actualice.
Actualización
da build modsecurity_rules
da build rewrite_confs 
Verificación
Puedes verificar que esta correcto con el siguiente comando, que te mostrará que lo usado se copio en el lugar apropiado.
ls -la /etc/modsecurity.d/*bad*
-rw-r--r-- 1 root root  199 Jan  4 09:24 /etc/modsecurity.d/00_bad_bots.conf
-rw-r--r-- 1 root root 5534 Jan  4 09:26 /etc/modsecurity.d/bad_bot_list.txt
Testing
curl -A "AiHitBot" https://example.com
  <html>
  <head><title>406 Not Acceptable</title></head>
  <body>
  <center><h1>406 Not Acceptable</h1></center>
  <hr><center>nginx</center>
  </body>
  </html>
curl -A "aihitbot" https://example.com
  <html>
  <head><title>406 Not Acceptable</title></head>
  <body>
  <center><h1>406 Not Acceptable</h1></center>
  <hr><center>nginx</center>
  </body>
  </html>
Reemplaza example.com con un dominio del servidor 😎
Deberas obtener un 406 Not Acceptable como respuesta
Agradecimientos
How to Block Bad Bots using ModSecurity with DirectAdmin
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Wordpress Manager de Directadmin y wp cli problemas de memoria
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
Un cliente reporto que estaba usando la herramienta Wordpress Manager de Directadmin y cuando instaló le salió un error de memoria
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/miusuairoes/domains/midominio.es/public_html/wp-includes/class-wpdb.php on line 2320 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/miusuairoes/domains/midominio.es/public_html/wp-includes/class-wpdb.php on line 2320 PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/miusuairoes/domains/midominio.es/public_html/wp-includes/class-wpdb.php on line 2320 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/miusuairoes/domains/midominio.es/public_html/wp-
includes/class-wpdb.php on line 2320
Que raro. El cliente trabaja ya con la modificación de 
memory_limit segun el método de Directadmin, y era verificable con un 
phpinfo();
Prueba en shell
Para ver el tema más cerca, me fui al shell.
❯ wp
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/unilanges/domains/MYDOMAIN.ES/public_html/wp-includes/class-wpdb.php on line 2320
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/unilanges/domains/MYDOMAIN.ES/public_html/wp-includes/class-wpdb.php on line 2320
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/unilanges/domains/MYDOMAIN.ES/public_html/wp-includes/class-wpdb.php on line 2320
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 47526080 bytes) in /home/unilanges/domains/MYDOMAIN.ES/public_html/wp-includes/class-wpdb.php on line 2320
Y claro no quedo otra:
❯ php  -i | grep memory
memory_limit => 128M => 128M
Collecting memory statistics => No
opcache.memory_consumption => 128 => 128
opcache.preferred_memory_model => no value => no value
opcache.protect_memory => Off => Off
Como es Directadmin, su compilación trata el tema de una manera particular, y no encontré el como modificar el cli, para el cliente de php.
Así que conociendo el tema, la cuestión era probar lo más sencillo del mundo. Modificar el 
wp-config.php
define( 'WP_MEMORY_LIMIT', '256M');
Y voila. Ya no sale el error, y ya podemos usar el 
wp-cli en el shell. Ambas dos cosas solucionadas.
Notas
Directadmin tiene muchas herramientas de ayuda, pero sigo pensando que el panel debería ser más orientado a sistemas, que ayudas al usuario.
Un gestor de Wordpress me parece un mal camino, como el del git.
Pero esto es una opinión.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Configurar PHP en un servidor con Directadmin
Antes de acudir a medidas como el uso de 
php.ini o 
.user.ini debemos saber que Directadmin en modo usuario pone a disposición una entrada para poder configurar nuestro PHP, en aquellos servidor que asi lo tiene posibilitado y usan PHP-FPM como es el caso de Castris
Pasos
El proceso lógico, que además sirve para otras habilidades del panel, es el que se describe mas abajo.
Usar el buscador si no conocemos la ubicación del sitio para la acción a realizar
Realizar una busqueda corta, de tipo generalista
Realizar los cambios
Selección del sitio web
Cambios a de versión PHP
Cambios posibles a realizar de uno en uno y cada un con sus valores predefinidos
display_errors
error_reporting
file_uploads
include_path
log_errors
mail.force_extra_parameters
max_execution_time
max_file_uploads
max_input_time
max_input_vars
memory_limit
post_max_size
register_globals
session.gc_maxlifetime
short_open_tag
upload_max_filesize
zlib.output_compression
Importante: en una cuenta con varios dominios no todo tiene el mismo alcance
Aunque esta pantalla se abre con un sitio web seleccionado, no todos los cambios se aplican solo a ese sitio:
La versión de PHP se aplica únicamente al dominio seleccionado. Hay que repetir el cambio en cada dominio.
El resto de valores (
memory_limit, 
upload_max_filesize, 
max_execution_time, etc.) se aplican a todos los dominios de la cuenta, porque Directadmin usa un único pool de PHP-FPM por usuario.
Detallado en Versiones de PHP y php.ini en cuentas con varios dominios.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Configuración de Smart Relay en DirectAdmin/Exim
Introducción al smart relay para Directadmin con Exim
DirectAdmin proporciona un mecanismo de inclusión de archivos para personalizar la configuración de Exim sin perder los cambios en actualizaciones posteriores. Para la configuración de smart relay, se utilizan dos archivos de inclusión específicos que se cargan en diferentes secciones del archivo principal 
exim.conf.
Ubicación de las Inclusiones
En el archivo principal de configuración de Exim (
/etc/exim.conf), encontramos dos inclusiones importantes:
Para los transportes:
begin transports
.include_if_exists /etc/exim.transports.pre.conf
Para los routers:
begin routers
.include_if_exists /etc/exim.routers.pre.conf
Archivos de Configuración
1. Transport Configuration (
/etc/exim_directadmin/exim.transports.pre.conf)
Este archivo define cómo se realizará el envío de correo al smart host:
spamgateway_smarthost_transport:
 driver = smtp
 hosts_require_tls = *
.include_if_exists /etc/exim.dkim.conf
Desglose de la configuración:
driver = smtp: Utiliza el protocolo SMTP estándar para el envío
hosts_require_tls = *: Fuerza el uso de TLS para todas las conexiones
Incluye la configuración DKIM para asegurar que los correos salientes sean firmados correctamente
2. Router Configuration (
/etc/exim_directadmin/exim.routers.pre.conf)
Este archivo define las reglas de enrutamiento para el correo saliente:
spamgateway_smarthost_router:
 driver = manualroute
 domains = ! +local_domains
 ignore_target_hosts = 127.0.0.0/8
 condition = "${perl{check_limits}}"
 transport = spamgateway_smarthost_transport
 route_list = * smart02.domain.tld:hetzner-smart01.domain.tld
 hosts_randomize = true
Desglose de la configuración:
driver = manualroute: Define un enrutamiento manual para los correos
domains = ! +local_domains: Aplica solo a dominios que no son locales
ignore_target_hosts = 127.0.0.0/8: Evita el envío a direcciones locales
condition = "${perl{check_limits}}": Verifica límites de envío mediante una función Perl
transport = spamgateway_smarthost_transport: Utiliza el transporte definido anteriormente
route_list: Define los smart hosts disponibles
hosts_randomize = true: Habilita el balanceo de carga aleatorio entre los smart hosts
Funcionamiento
Con esta configuración:
Todo el correo saliente (excepto para dominios locales) se enviará a través de los smart hosts configurados
El sistema alternará aleatoriamente entre los smart hosts disponibles (
smart02.domain.tld y 
hetzner-smart01.domain.tld)
Si un smart host falla, el sistema intentará automáticamente con el otro
Las conexiones se realizan con TLS
Los correos mantienen la firma DKIM gracias a la inclusión de la configuración DKIM en el transporte
Notas Importantes
La configuración mantiene la firma DKIM en los correos reenviados
El balanceo de carga entre smart hosts proporciona redundancia y distribución de carga
La configuración se mantiene incluso después de actualizaciones de DirectAdmin o Exim
Los cambios se realizan en archivos separados, lo que facilita el mantenimiento y la depuración
Verificación
Para verificar que la configuración está funcionando correctamente, puedes:
Revisar los logs de Exim para confirmar el uso alternado de los smart hosts
Verificar que los correos salientes mantienen la firma DKIM
Comprobar que el sistema cambia automáticamente al host alternativo si uno falla
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Redis: Rotura de WordPress por error de Redis en Directadmin
Escenario
Sitio WordPress configurado con Redis Object Cache.
El sitio deja de funcionar mostrando el mensaje Error Establishing a Redis Connection
Al ejecutar 
systemctl, se observa que:
redis-server (Redis principal) está activo.
redis-rspamd y 
redis@user_a están fallando.
Análisis
Buscamos informacion sobre el estadod el servicio
systemctl | grep redis
● redis-rspamd.service      loaded failed failed    Multi-user redis persistent key-value database
  redis-server.service      loaded active running   Advanced key-value store
  redis@user.service        loaded active running   Multi-user redis persistent key-value database
  system-redis.slice        loaded active active    Slice /system/redis
Diagnóstico
Los registros del sistema (journalctl) muestran:
cat /var/log/syslog| grep -i redis
...
2025-05-29T06:35:57.647681+02:00 dar redis-server[1064]: 1064:M 29 May 2025 06:35:57.647 * Server initialized
2025-05-29T06:35:57.648969+02:00 dar redis-server[1064]: 1064:M 29 May 2025 06:35:57.648 # Can't handle RDB format version 12
2025-05-29T06:35:57.649027+02:00 dar redis-server[1064]: 1064:M 29 May 2025 06:35:57.648 # Fatal error loading the DB, check server logs. Exiting.
...
Can't handle RDB format version 12
Fatal error loading the DB, check server logs. Exiting.
Esto indica que Redis no puede leer el archivo de base de datos dump.rdb. Las causas habituales son:
El archivo fue generado por una versión de Redis diferente (por ejemplo, tras un downgrade de versión en una actualización de DirectAdmin).
El archivo se ha corrompido, posiblemente tras un reinicio forzado o caída del sistema.
Solución
Previa para liberar al wordpress del problema
Deberas eliminar el fichero de wordpress 
object-cache.php
rm -f /home/USER/domains/DOMAIN.TLD/public_html/wp-content/object-cache.php
Eliminar los archivos dump.rdb afectados para forzar su regeneración limpia:
rm -f /var/lib/rspamd/.redis/db/dump.rdb
rm -f /home/USER/.redis/db/dump.rdb
Reiniciar los servicios Redis afectados:
systemctl restart redis-rspamd
systemctl restart redis@USER
Consideraciones
Esta operación elimina los datos almacenados en caché, pero no afecta a los datos persistentes del sitio WordPress.
Redis volverá a crear los datos necesarios durante el uso normal del sistema.
Si Redis estaba siendo utilizado para sesiones, estadísticas u otras funciones de estado, esa información se perderá.
Verificación
Si no conoces la ubicación del archivo 
dump.rdb, puedes buscarlo con:
locate dump.rdb
Es necesario tener mlocate o plocate instalado y la base de datos actualizada con updatedb.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Cómo preparar el acceso a mi terminal desde un cliente SSH externo
Aplica a: cuentas de DirectAdmin con acceso SSH habilitado.
Requisito: que tu cuenta tenga el acceso SSH activado. Si no ves la opción Terminal en tu panel, pídenoslo y lo habilitamos.
Nuestros servidores, por seguridad, no aceptan acceso SSH por contraseña: solo por clave pública. Por eso, si intentas conectar con usuario y contraseña desde un programa externo, verás:
Permission denied (publickey).
No es un fallo de tu cuenta: es el servidor pidiéndote tu clave pública. Prepararlo son 5 minutos, se hace una sola vez, y ni siquiera necesitas acceso externo para configurarlo: lo haces desde el Terminal de tu propio panel.
Paso 1 — Genera tu par de claves (en tu ordenador)
Una clave SSH tiene dos partes: la privada (se queda SIEMPRE en tu ordenador, nunca se comparte) y la pública (es la que instalas en el servidor).
macOS / Linux
En una terminal:
ssh-keygen -t ed25519 -C "mi-acceso-directadmin"
Pulsa Enter para aceptar la ruta por defecto. Puedes poner una passphrase (recomendado) o dejarla vacía. Se crean dos ficheros:
~/.ssh/id_ed25519 — tu clave privada (no la toques ni la envíes a nadie).
~/.ssh/id_ed25519.pub — tu clave pública (esta es la que vas a usar).
Para verla y copiarla:
cat ~/.ssh/id_ed25519.pub
Windows
Windows 10/11 ya trae 
ssh-keygen: abre PowerShell y ejecuta el mismo comando de arriba. La pública queda en 
C:\Users\TU_USUARIO\.ssh\id_ed25519.pub.
Si usas PuTTY, genera la clave con PuTTYgen y copia el recuadro «Public key for pasting into OpenSSH authorized_keys file» — ese recuadro ya está en el formato correcto. El fichero 
.ppk no sirve para pegar en el servidor.
Importante — la clave debe estar en formato OpenSSH. La clave pública correcta es una sola línea que empieza por 
ssh-ed25519 o 
ssh-rsa. Si tu clave empieza por 
---- BEGIN SSH2 PUBLIC KEY ----, ese es el formato PuTTY/SSH2 y no sirve: usa el recuadro de PuTTYgen indicado arriba.
Paso 2 — Abre el Terminal de tu panel DirectAdmin
No necesitas acceso SSH externo para este paso: tu panel trae un terminal web integrado.
Pulsa Cmd + J (Mac) o Ctrl + J (Windows/Linux) dentro del panel y busca «Terminal».
O entra directamente por el menú del panel a la sección Terminal.
Paso 3 — Instala tu clave pública
En ese terminal, pega estos comandos — sustituyendo la línea de ejemplo por TU clave pública copiada en el Paso 1:
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA...TU-CLAVE-PUBLICA-COMPLETA... mi-acceso-directadmin' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
Comprueba que ha quedado bien:
cat ~/.ssh/authorized_keys
Debe verse tu clave en una sola línea, empezando por 
ssh-ed25519 (o 
ssh-rsa).
Paso 4 — Conéctate desde tu programa de SSH
Ya puedes conectar desde tu terminal o cliente SSH externo:
ssh -p 2244 TU_USUARIO@TU_SERVIDOR
TU_USUARIO: el usuario de tu cuenta de DirectAdmin.
TU_SERVIDOR: el nombre de tu servidor (el que te indicamos en tus datos de acceso).
Puerto: nuestros servidores tienen el SSH en el puerto 2244 (no en el 22 por defecto).
Si pusiste passphrase al generar la clave, te la pedirá al conectar: es tuya, no la de la cuenta.
Problemas frecuentes
Sigue diciendo 
Permission denied (publickey): revisa que pegaste la clave pública (no la privada), en una sola línea, y que 
~/.ssh tiene permisos 
700 y 
~/.ssh/authorized_keys permisos 
600.
Connection refused o se queda colgado: casi siempre es el puerto — usa 2244, no el 22.
Pegaste una clave 
.ppk o que empieza por 
BEGIN SSH2: ese no es el formato OpenSSH. Vuelve al Paso 1 (sección Windows / PuTTY).
Última actualización: 2026-07-09.
Aviso
Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos.
También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

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

Versiones de PHP y php.ini en cuentas con varios dominios
Una cuenta de Directadmin puede alojar varios dominios. Cuando se quiere que cada uno use una versión distinta de PHP, o valores distintos de 
php.ini, aparece una confusión muy habitual: unos ajustes se propagan solos a todos los dominios de la cuenta y otros no.
No es un fallo del panel. Son dos ámbitos distintos, y conviene tenerlos claros antes de pelearse con la configuración.
El síntoma típico
Se cambia la versión de PHP y el 
memory_limit en el dominio principal de la cuenta. Al ir al segundo dominio, el panel avisa de que toma la configuración del principal. Y entonces se observa algo aparentemente incoherente:
El 
memory_limit nuevo sí aparece en el segundo dominio, sin haberlo tocado ahí.
La versión de PHP no: el segundo dominio sigue con la versión antigua.
De ahí la sensación de que el panel "no hace caso". Lo que ocurre es que cada cosa se aplica a un nivel diferente.
Los dos ámbitos
La versión de PHP es por dominio
Cada dominio guarda su propia selección de versión, de forma independiente. Cambiarla en el dominio principal no la cambia en el resto: hay que hacerlo dominio por dominio.
Los valores del 
php.ini del panel son por cuenta
Directadmin crea un único pool de PHP-FPM por usuario, no uno por dominio. Todos los dominios de la cuenta que usen la misma versión de PHP comparten ese pool.
Cuando desde el panel se ajusta 
memory_limit, 
upload_max_filesize, 
max_execution_time y demás, el valor acaba escrito en ese pool como 
php_value. Por eso se aplica a todos los dominios de la cuenta a la vez, aunque el formulario se haya abierto teniendo seleccionado un dominio concreto.
Cambiar la versión de PHP de un dominio
Desde el panel, en modo usuario, en la pantalla de configuración de PHP. El proceso paso a paso, con capturas, está en Configurar PHP en un servidor con Directadmin.
Lo importante:
Seleccionar el dominio en el desplegable de la pantalla.
Cambiar la versión de ese dominio.
Repetir con cada dominio que se quiera mover. No basta con el principal.
Esperar unos instantes: el panel regenera la configuración del servidor web y recarga PHP-FPM.
Cómo comprobar de verdad qué versión se está usando
Es la parte donde más se falla, porque hay varias formas de mirar y casi todas engañan.
Fiable: una página en el propio dominio con 
phpinfo(), consultada por navegador, y borrada inmediatamente después. Un 
phpinfo() accesible expone la configuración del servidor, así que no puede quedarse ahí.
No fiable: 
php -v por SSH. Devuelve la versión por defecto del servidor o la del usuario, no la del dominio, que es la que usa la web.
No fiable: el aviso de versión de PHP del panel de WordPress u otros gestores. Suelen cachear ese dato y tardan en refrescarlo.
Valores de 
php.ini distintos para cada dominio
Sí es posible, pero no desde el panel: requiere acceso de administrador al servidor.
El mecanismo son las secciones 
[HOST=] en un fichero 
.ini dentro de 
/usr/local/phpXX/lib/php.conf.d/:
[HOST=segundo-dominio.example]
memory_limit = 512M
upload_max_filesize = 128M
Los ficheros de ese directorio se cargan por orden alfabético, de ahí que se numeren. Después hay que reconstruir la configuración web:
da build rewrite_confs
Dos detalles verificados que conviene conocer:
La sección 
[HOST=] prevalece sobre el valor que el panel haya dejado en el pool de la cuenta. Es decir, sirve para dar a un dominio concreto un valor distinto del que tiene el resto de la cuenta.
No todas las directivas admiten esto. Las que solo pueden fijarse una vez en el 
php.ini principal, como 
disable_functions, no se pueden sobrescribir por esta vía. Ese caso concreto está tratado en Cambios especificados en el php.ini disable_functions por dominio.
Referencia oficial: Per-domain settings for PHP.
Resumen
Qué se quiere cambiar
Ámbito
Quién puede hacerlo
Versión de PHP
Por dominio
El propio usuario, desde el panel
memory_limit y similares del panel
Toda la cuenta
El propio usuario, desde el panel
memory_limit y similares para un solo dominio
Por dominio
Solo el administrador del servidor
Aviso
Esta documentación y su contenido no implica que funcione en tu caso o en determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido se entrega tal y como está, sin que ello implique ninguna obligación ni responsabilidad por parte de Castris.
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.

Zona horaria: el servidor va en UTC y la aplicación declara la suya
Nuestros servidores funcionan en UTC, y eso es una decisión deliberada, no un descuido de configuración. Cada aplicación alojada declara la zona horaria que necesita.
Es una fuente habitual de confusión, sobre todo en aplicaciones que programan envíos o tareas para una hora concreta: correos que salen dos horas tarde, informes que se generan a destiempo, avisos que llegan cuando ya no tocaba. Esta página explica por qué el servidor va en UTC, y sobre todo dónde hay que declarar la zona horaria para que el cambio surta efecto, que casi nunca es donde uno mira primero.
Por qué el servidor va en UTC
UTC no cambia nunca. No tiene horario de verano, no adelanta ni atrasa, y no depende del país.
Un servidor compartido aloja aplicaciones de clientes que pueden necesitar zonas distintas. Si el servidor se fijara en 
Europe/Madrid, todas heredarían esa zona y las que necesitasen otra tendrían que pelearse contra ella. Además, dos veces al año el reloj daría un salto: en octubre una hora se repite y en marzo una hora no existe. Toda tarea programada en esa franja se ejecuta dos veces o ninguna.
Con el servidor en UTC ese problema desaparece de la base, y cada aplicación resuelve su horario local por su cuenta.
Hay dos relojes, no uno
Esta es la parte que se pasa por alto y la que explica la mayoría de los casos.
Una aplicación PHP con base de datos tiene dos relojes independientes:
El de PHP, que es el que devuelve 
date() y compañía.
El de la base de datos, que es el que devuelve 
NOW() en una consulta SQL.
Cambiar uno no cambia el otro. Y muchas aplicaciones no deciden con PHP: deciden con SQL. Cuando una aplicación selecciona qué enviar con una consulta del estilo
SELECT ... WHERE fecha_programada <= NOW()
quien decide la hora es la base de datos. Se puede poner PHP en la zona que se quiera, que el envío seguirá saliendo a la hora antigua.
Regla práctica: si lo que falla es cuándo ocurre algo programado, sospecha del reloj de la base de datos antes que del de PHP.
Cómo comprobar cada reloj
El de PHP, desde tu terminal SSH:
php -r 'echo date("Y-m-d H:i:s T P"), PHP_EOL;'
Si usas una versión concreta en el cron, comprueba esa misma, invocándola por su ruta completa igual que hace el cron. Distintas versiones de PHP pueden tener configuraciones distintas.
El de la base de datos, desde el cliente MySQL o desde phpMyAdmin:
SELECT @@session.time_zone, NOW(), UTC_TIMESTAMP();
Si 
NOW() y 
UTC_TIMESTAMP() devuelven lo mismo, tu sesión está en UTC.
Declarar la zona en PHP
Lo correcto es hacerlo dentro de tu aplicación, no en la configuración del servidor.
La forma más directa, al principio del arranque de la aplicación:
date_default_timezone_set('Europe/Madrid');
Muchas aplicaciones traen ya su propio ajuste de zona horaria en su panel o en su fichero de configuración. Si existe, úsalo: suele hacer más cosas que llamar a esa función, como veremos enseguida.
También puedes fijarla para todo un dominio con un fichero 
.user.ini en la raíz del sitio:
date.timezone = "Europe/Madrid"
Ten en cuenta que ese fichero no afecta a las ejecuciones por línea de comandos, así que no sirve para tus tareas del cron. Para el cron, o lo declara la aplicación, o se pasa en la propia orden:
/usr/local/php83/bin/php -d date.timezone=Europe/Madrid /home/<usuario>/domains/<dominio>/public_html/tarea.php
Lo que no hay que hacer
No intentes modificar el 
php.ini general del servidor. No vas a poder —tu shell trabaja aislado y esa ruta es de sólo lectura para ti— y, aunque pudieras, sería contraproducente por dos motivos: afectaría a todos los clientes del servidor, y el panel regenera ese fichero en cada actualización de PHP, de modo que el cambio se perdería en la siguiente compilación.
Si te encuentras un mensaje de 
Read-only file system al intentarlo, no es una avería: es el aislamiento previsto de tu cuenta.
Declarar la zona en la base de datos
Se hace por conexión, con una sentencia al abrirla:
SET time_zone = 'Europe/Madrid';
A partir de ahí, 
NOW() devuelve hora española en esa conexión, y respeta el horario de verano.
Nuestros servidores tienen cargado el catálogo completo de zonas horarias, así que puedes usar nombres como 
Europe/Madrid. Puedes comprobarlo así:
SET time_zone = 'Europe/Madrid';
SELECT NOW(), UTC_TIMESTAMP();
Si las dos horas se diferencian en una o dos horas según la época del año, funciona correctamente.
Usa siempre el nombre de la zona, nunca un desplazamiento fijo. Un 
SET time_zone = '+02:00' parece equivalente y no lo es: acertará en verano y fallará en invierno, cuando España está en 
+01:00. El nombre conoce las transiciones; el número, no.
El caso de phpList
phpList es el ejemplo perfecto de esto, porque decide con SQL y porque su ajuste tiene un nombre que es fácil equivocar.
En su fichero 
config/config.php la constante correcta es:
define('SYSTEM_TIMEZONE', 'Europe/Madrid');
Esa constante hace dos cosas a la vez: ajusta el reloj de PHP y el de la base de datos. Es exactamente el mecanismo que las alinea, y por eso funciona donde un 
date_default_timezone_set() suelto no llega.
Cuidado con el nombre. 
SERVER_TIMEZONE no existe en phpList: si la defines, no da ningún error, simplemente no hace nada, y el problema sigue igual sin ninguna pista de por qué.
Antes de aplicar el cambio: revisa lo que tengas programado
Este aviso vale para phpList y para cualquier aplicación con tareas o envíos programados.
Al corregir la zona horaria, el reloj con el que la aplicación compara sus fechas se mueve de golpe. En España, en horario de verano, avanza dos horas. Eso significa que todo lo que tengas pendiente de salir se disparará dos horas antes de lo que la pantalla te indica ahora mismo.
Y hay un caso que conviene mirar con especial atención: si mientras el problema estaba activo compensaste el desfase a mano —programando las cosas dos horas más tarde para que salieran a la hora buena—, esas quedarán mal en sentido contrario y saldrán con dos horas de retraso.
La recomendación es sencilla: repasa la lista de tareas o campañas pendientes antes de tocar la configuración, y reajusta las que hicieran falta justo después.
Resumen
El servidor va en UTC a propósito, y no se cambia.
La zona horaria la declara tu aplicación, no el servidor.
Hay dos relojes independientes: el de PHP y el de la base de datos. Cambiar uno no cambia el otro.
Si lo que falla es cuándo ocurre algo programado, mira el reloj de la base de datos.
Usa siempre nombres de zona (
Europe/Madrid), nunca desplazamientos fijos (
+02:00).
Si tu aplicación trae su propio ajuste de zona, úsalo: normalmente alinea los dos relojes a la vez.
Revisa lo que tengas programado antes de aplicar el cambio.
Si después de esto sigues viendo un desfase, abre un ticket indicando qué aplicación es, qué hora esperas y qué hora obtienes, y lo revisamos.