Update:
- Estaba a la mitad de esto 2026-may-08 cuando se descubrió la falla Dirty Frag del kernel de linux, por lo cual procedo a borrar el servidor.
Algunas Notas utiles:
Hay tres frases que me han ayudado mucho, que no son de sistemas.
- Puedes conocer a un hombre por el tipo de problemas que le gusta resolver
- Si se arregla con dinero, no es un problema. Es un gasto.
- Se trata de resolver un problema sin crearte uno mayor.
En este momento me encuentro trabajando en levantar un servidor vultr de Ubuntu, para hospedar sitios de wordpress. La razón de ser ubuntu, está explicada en el manual del repositorio, pero se trata de instalar el panel de control hestiaCP que no da soporte a Debian 13. Aunque puedo usar Debian 12, es posible que el server siga vivo y pida a Vultr que me abra puertos, y es mas fácil que lo hagan si tengo un LTS.
Manual de instalación está aquí.
https://github.com/AlfonsoOrozcoAguilarnoNDA/snippetsMIT/blob/main/instalar_hestiaCP_ubuntuLTS.md
Constantemente salen asuntos de servidores si te dedicas a eso, o si quieres estar al corriente. En mi caso particular este es un problema que lleva unos tres meses, pero que tiene sus origenes en 2022. Es un problema menor pero todas las decisiones se han hecho para que sea así.
- En 2022 Me contrataron para trabajar en una paraestatal. Uno de los sistemas era php 5.6 en un host compartido malo, con unos 30 mil documentos pdf (40 gb aprox) y una base de datos de 100 mb, y el sistema era php 5.6 con laravel 5.2 y muy malas practicas. Como era parte de mis responsabilidades mantenerlo vivo, lo ideal era crear un servidor cpanel con soporte para eso y no es facil. Respaldarlo fue complicado y restaurarlo mas.
- Nadie sabía quien pagaba hospedaje. Era un Cpanel compartido con 800 dominios aprox y sin ser rastreable a un proveedor. Si tenia clave de usuario.
- Me encontré entonces en el año 2022 con tres servidores CPANEL, dos de clientes normales incluyendo mis propios dominios, y el tercero donde estaban datos de la paraestatal. Vale la pena mencionar que en ese momento otro de mis clientes también estaba en php 5.6 porque no existía una librería en version php7, asi que lo ideal para mi era NO tener dos servidores con un php obsoleto, pero no poner en riesgo al cliente.
- El siguiente paso fue crear un servidor con el requisito extra que yo tenía (largo de explicar) y mover primero el cliente que tenía en otro servidor con php 5.6, y después mover poco a poco los datos de la paraestatal, en dos dias, de un sistema que nadie usaba, que nadie pagaba ( ni idea como estaba al aire) y con un dominio que no controlabamos. Resultado, al tener plan B pude mover el primer servidor y eliminarlo, y el cliente no tuvo problemas.
- Era muy importante respaldar los datos del servidor desconocido que ni siquiera dejaba exportar o sacar respaldos, fue copiar por ftp al dominio nuevo en nuevo server, verificar que funcionara y nunca tuvimos contacto con el proveedor de host desconocido.
- Esos dos dominios coexistieron de 2022 hasta mayo 2025. Como llevaba la paraestatal cinco meses sin pagarme por pretextos, aunque el servidor de esa actividad lo pagaba yo de mi sueldo, me encontré en la necesidad de avisar por correo corporativo que por falta de pago el servidor iba a desaparecer, que la red no permitia respaldarlo, (yo lo hacia desde mi casa) y sobre todo era para equilibrar responsabilidad del servidor con la autoridad de no pago. Si no me pagaban no podia yo hacer nada y si perdian la información era problema suyo.
- No pagaron, y como avisé el servidor desapareció con 50 gb de informacion aproximadamente de siete años de la paraestatal. Sobre aviso no hay engaño y con correo corporativo en medio menos.
- Finalmente salieron las nuevas versiones de php 8.1 y no era compatible con wordpress al 100%. Otro bug medio oscuro le pegaba a un cliente de gasolineras y primero pensé que era su internet pero resultó ser PHP, asi que lo mejor que podía hacer en ese momento era mover los dominios de las gasolineras al servidor del cliente php 5.6 que me quedaban y unificar versiones.
- Finalmente allá por septiembre salió la versión de software que mencioné en el inicio y pude pasar el ultimo cliente de php 5.6 a 7.x. Sigo igual sin poder cambiarlo a 8.x
- Tres precisiones importantes:
- El cliente de 7.x no puede usar 8.x por la falta de una librería de encriptado relacionada con el SAT
- Se usó almalinux para el cpanel 2022 porque era el unico que podia usarse en ese momento para levantar php 5.6 en un cpanel moderno almalinux/cloudlinux
- Sin mucho problema moví primero todos los dominios de php 8.1 de las gasolineras al mismo servidor de 2022 , y los pasé a php 7.x y todo funcionó perfectamente. No era lo ideal pero funcionaba.
- Cuando finalmente salió 8.4x me resolvió el problema del cliente de las gasolineras. Asi que movi mis wordpress propios, los dominios de las gasolineras y lo que se pudo a php 8.4, mismo que me tuvieron que instalar en el server vps managed.
- En este momento ese servidor solo tiene un php 7.x, el que antes era php 5.6 desde 2022 y que en cuanto me den la librería corre en php 8.x Todo lo demás es php 8.4
- Problema secundario : Algo hicieron los del servicio managed porque hay fallas en las actualizaciones de wordpress de temas, casi no uso plug ins, y pasa en unos 5 de 20 dominios propios.
Hay muchas posibles soluciones pero todas crean un problema.
- Respaldar y restaurar el dominio central puede causar inestabilidad por dominios addons, y son 17 gb.
- Pone en riesgo a clientes
- Pasar todo a un nuevo servidor solo con php 8.4 / 7.x
- Mucho trabajo y pone a todos los clientes en riesgo.
- En casos extremos puede hacerse idealmente dos dias antes de que venza el servidor actual, para reducir gasto.
- Como son dominios propios y estoy viendo correo considero otras alternativas. Si fueran clientes y correo la solución es Cpanel y punto. No hay mas opciones.
- Lo mismo si lo restauro en otro server ya existente.
- Mover a cuentas separadas cada wordpress me obligaria a respaldar uno por uno.
- hacer un solo respaldo es mas fácil que 25
- Quitar wordpress pero se pierden las rutas y se rompen enlaces en google.
- no tiene caso.
- Una instalación multiple de wordpress que ojalá funcione pero que se que no.
- para que ? si queda dañado el central volvemos a cero.
- Pedir a los del host que me arreglen el problema que ellos crearon con la instalación rara de php 8x que solo afecta a wordpress.
- Afecta la buena voluntad y es {ultimo recurso.
- Las soluciones restantes eran tres, que creaban el menor problema:
- a ) Trabajar con inteligencia artificial para depurar el problema que no es de permisos sino de cagefs y de fpm , pero hacerlo puede desconfigurar otros dominios. Kimi es el que se acercó mas a resolver el problema, lo resolví para un dominio pero los otros 7 con problemas eran muchs horas y sujeto a errores (como nota Claude y gemini fueron hoy completamente inútiles, mas cinco errores extra de Claude en otra cosa TECNICA y gemini me creó un problema diferente de cagefs que afortunadamente se como resolver)
- b ) Mover todos los wordpress a vultr , menos en el que si recibo correo usando un panel de control que conozco, hestia sea en ubuntu o en debian
- Lo primero es ubuntu pero si se pone sus moños, en debian 12 (la guia explica porqué) estas pruebas no deben tomar mas de 20 minutos
- c ) La tercera opción es crearlos como cualquier hijo de vecino en vultr con debian 13 y ver después a mano el correo y roundcube. Si hestiacp falla es la siguiente opción.
-
Postfix + Dovecot + Roundcube : instalado a mano, sin panel si necesito correo.
- O simplemente instalarlos y olvidarme del correo de actualizaciones, entrando una vez a la semana.
-
Es importante notar que cada decisión ha sido tomada por un intento anterior menos problemático. Si kimi encontró como yo sabia que hay un problema de permisos pero se presta a muchos errores corregirlo en siete dominios, lo mejor es tratar de instalar hestia, y si hestia no funciona moverlos a mano. No es retrabajo, es simplemente una mezcla de mantener al día mis habilidades de devops/despliegue, de sentido común y del mundo real vs inteligencia artificial.
Para mi el objetivo es no interrumpir la operación de ese server cpanel, y mover los dominios con wordpress parece el mal menor. Esa es la razón del ubuntu. Ubuntu por simplificar apertura de puertos de correo.
- Ojo: Las Inteligencias artificiales siguen tercas que Debian 13 está en beta, y proponen cosas mucho mas complicadas. Modestia aparte soy un experto y lo simple tiene valor de supervivencia.
Mi prueba entonces es en este momento un servidor de 5USD en vultr, que es un gasto, no un problema, y solo tendria que mover los dominios uno por uno y sacar un respaldo global.
La parte mas importante es como siempre tener la información en dos lugares en la nube, una copia en un usb y otra en mi propio disco duro, y ninguna de las IA me dijo eso.
Asi que si como profesionales nos enfocamos en lo que estamos tratando de resolver con los tres principios que dije, que son para mi los básicos de todo laboratorio de pruebas:
- Puedes conocer a un hombre por el tipo de problemas que le gusta resolver
- Si se arregla con dinero, no es un problema. Es un gasto.
- Se trata de resolver un problema sin crearte uno mayor.
Debido a la forma de ser de Ubuntu, me ha tocado antes que al instalarlo es mejor reinstalar de cero. Por alguna razón puede quedar algo mal de .hosts / hostname en memoria aunque reinicies el server. Y por eso no lo haces con dominios de clientes, sino de pruebas.
Otros ejemplos de problemas menores:
- Gemini se negó a hacer la imagen
- Grok la hizo aunque no me gustó mucho cumple el cometido.
- Este wordpress se nego a dejarme subir la imagen ,por eso lo quiero mover, tuve que mover permisos y owners y regresarlos como estaban después.
- A mitad de revisión con kimi sobre el problema de debian 12 y hestiaCP, me dio “the system is busy”. Decidí que podría irme por Postfix + Dovecot + Roundcube o simplmente instalarlo y entrar una vez a la semana a ver si hay actualizaciones.
