Dos servidores, algunas actualizaciones de seguridad y una tarde bastante normal.
Hay algo curioso en administrar servidores Linux: cuando todo funciona, es fácil olvidar que el software también envejece.
Los servicios siguen activos, las aplicaciones responden y nadie tiene razones para quejarse.
Hasta que aparece una actualización de seguridad.
El 21 de octubre de 2026 se publicaron nuevas versiones de seguridad de PHP y Node.js. Tenía dos servidores Ubuntu 22.04 funcionando con versiones anteriores, así que tocaba revisar qué había que actualizar.
Nada estaba fallando.
Simplemente era momento de hacer mantenimiento.
Actualizar PHP en Ubuntu 22.04: el pequeño problema de los repositorios
Lo primero fue PHP.
Las versiones instaladas funcionaban correctamente, pero los repositorios configurados todavía no ofrecían las correcciones recién publicadas.
La típica situación en la que ejecutas una actualización, el sistema te dice que todo está al día y descubres que estar actualizado depende bastante de a quién le preguntes.
Hubo que revisar el origen de los paquetes y utilizar un repositorio que ya tuviera disponibles las versiones corregidas.
Antes de instalar, simulé la actualización con APT para comprobar qué paquetes se modificarían.
Después vinieron las comprobaciones habituales: versiones, módulos de Apache y estado de los servicios.
El resultado fue PHP 8.2.35 y PHP 8.3.36 en ambos servidores.
No hubo que cambiar código ni reiniciar las máquinas.
Hasta ahí, bastante aburrido.
Como debería ser.
Migrar de Node.js 20 a Node.js 24 LTS
Después tocó Node.js.
Aquí el cambio era algo mayor: pasar de Node.js 20 a Node.js 24 LTS.
El servidor utilizaba Express y Socket.IO para manejar conexiones en tiempo real. No era un servicio particularmente complejo, pero tampoco había razón para asumir que una versión nueva funcionaría perfectamente solo porque el número fuera más grande.
Primero descargué Node.js 24 de forma independiente y verifiqué el archivo.
Después revisé la sintaxis del servidor y probé que las dependencias cargaran correctamente.
Todo salió bien.
Actualicé el primer servidor mediante NodeSource, reinicié únicamente el servicio correspondiente y comprobé que siguiera respondiendo.
Luego repetí el procedimiento en el segundo.
Ambos terminaron ejecutando Node.js 24.22.1.
Lo más interesante fue que no hubo nada especialmente interesante.
Cómo comprobar que una actualización realmente funcionó
Una costumbre que vale la pena conservar es no confiar demasiado en los mensajes de instalación exitosa.
Que APT termine sin errores no significa necesariamente que el proceso en ejecución esté utilizando la nueva versión.
Por eso revisé el ejecutable del proceso, la versión cargada por systemd, el puerto de escucha y la respuesta de Socket.IO.
También consulté los registros en busca de errores recientes.
Todo estaba en orden.
Aunque conviene distinguir entre un servicio que responde y una aplicación completamente validada.
Un HTTP 200 es una buena señal.
No es un certificado de que el universo funciona correctamente.
Las actualizaciones de seguridad no resuelven toda la deuda técnica
Durante la revisión aparecieron algunos detalles de seguridad que no tenían relación directa con PHP ni con Node.js.
Autenticación de conexiones, protección de endpoints y privilegios de ejecución.
Nada que justificara mezclar cambios en ese mismo momento.
Actualizar dependencias es una tarea. Corregir decisiones de arquitectura es otra.
A veces conviene resistirse a esa hermosa tentación de arreglar todo lo que encuentras mientras revisas algo.
Así nacen muchas tardes que terminan de madrugada.
Mantener servidores Linux también es desarrollar software
Al terminar, los dos servidores tenían PHP y Node.js actualizados.
Los servicios respondían, los registros revisados no mostraban errores y quedaban algunas validaciones funcionales y mejoras de seguridad para después.
No hubo una caída espectacular.
Tampoco una migración heroica ni una lección trascendental sobre infraestructura.
Solo mantenimiento preventivo.
Quizá lo más extraño del desarrollo de software sea eso: dedicamos mucho tiempo a construir cosas nuevas, pero una parte importante del trabajo consiste en evitar que las anteriores se deterioren.
No tiene el encanto de lanzar un producto.
Ni produce demasiadas fotografías para LinkedIn.
Pero alguien tiene que revisar los repositorios, actualizar las dependencias y comprobar que los servicios sigan funcionando.
El software envejece aunque nadie lo toque.
Nosotros también.