Cadencia de actualización — servidores, PBXs, equipos de red, apps

Contexto

Pendiente capturado por Sergio el 2026-05-20: necesita una disciplina de updates para mantener al día todos los activos que opera Electrosystems — servidores Linux/VMs, PBXs (FreePBX/Sangoma), equipos de red Ubiquiti, y las apps Laravel/PHP que viven en esos hosts.

Hoy no existe. Lo que hay es:

• Algunos hosts en CentOS 6 EOL (orion, otrs, clientes) — riesgo de seguridad y soporte (descubrimiento de backups-infra 2026-05-19).
• ~25 Sangoma 7 PBXs en sitios cliente sin política conocida de updates (versiones probablemente arrastradas desde la instalación).
• 354 equipos de red Ubiquiti detectados en 10.11.30-37 sin política de firmware coordinada (UISP maneja algunos managed, el resto blackBox).
• Apps Laravel en amadeus / es-antenas-new / holbox / jm-* / etc. con composer/npm propios — cada una con su ciclo de updates.
• El proceso legacy esconfigbackup (desactivado 2026-05-11 durante cleanup de orion) cubría algo parecido para servers, ya muy desactualizado y sin reemplazo.

Por qué existe este proyecto separado de backups-infra:

• backups-infra = recuperar cuando algo se rompe.
• infra-updates = prevenir que se rompa y cerrar deuda de seguridad.
• Comparten inventario y dependencias (no se patchea sin backup), pero las decisiones (cadencia, ventanas, comunicación al cliente, criterios de rollback) son distintas.

Prerrequisito: backups-infra debe estar operativo (al menos para DBs y /etc) antes de empezar a aplicar updates de OS o major versions de aplicaciones. Por eso este proyecto arranca en backlog: la planeación/inventario sí puede avanzar en paralelo, pero la ejecución espera.

Tareas pendientes

Captura inicial 2026-05-20. La siguiente sesión normalmente debería arrancar por las decisiones marco una vez que backups-infra libere el bloqueo.

A. Inventario de versiones (no requiere backups-infra listo)

• #113 📅 2026-05-30 — Construir tabla de versiones actuales por host reutilizando los inventarios de backups-infra. ✅ Resuelto 2026-05-29: tabla completa en Notas técnicas → Tabla de versiones #113 — ~46/51 hosts con OS+kernel+pkg+#upd+último-patch. Faltan solo gasnaturalito/viaticos (caídos) y clientes (no consultado).
• #113b 📅 2026-05-31 — Para PBXs Sangoma/FreePBX: versión de FreePBX, versión de Asterisk, módulos con update. ✅ Resuelto 2026-05-29: Asterisk/FreePBX/PHP reverificados host-por-host (la 1ª pasada estaba cruzada). fwconsole ma listonline → 0 módulos con upgrade en los 15 FreePBX (repos EOL ya no publican). Conclusión: la deuda es la versión EOL completa → migrar, NO fwconsole ma upgrade. Detalle en Notas técnicas → tabla sitios cliente.
• #113c 📅 2026-06-01 — Para equipos Ubiquiti managed por UISP: versión de firmware actual y target. ✅ Resuelto 2026-05-29: inventario de firmware en vivo (UISP /devices, 219 Ubiquiti managed; 101 ~46% atrasados vs el max de su modelo) — tabla en Notas técnicas → Tabla de firmware #113c. Target de homologación interno por modelo (PowerBeam M5 400→6.3.24, EdgeRouter X→3.0.1 los focos). ⚠️ El “target oficial Ubiquiti” (/firmwares) dio 403 con el token de la app (scoped a devices) → requiere token con rol superior; queda como nota, no bloquea las decisiones de homologación.
• #113d 📅 2026-06-02 — Para equipos Ubiquiti blackBox (mayoría de los 354 en 10.11.30-37): qué tipo de equipo, qué firmware corre. Probable que esto requiera coordinarse con backup-system (oxidized ya tiene info de modelo en algunos).
• #113e 📅 2026-06-03 — Para apps Laravel: tabla con PHP version, Laravel version, dependencias outdated (composer outdated --direct), node version, paquetes npm outdated (npm outdated).
• #113f 📅 2026-06-04 — Para hipervisor (poseidon): CentOS 7 → considerar plan de migración (EOL 2024-06, ya pasado). Cross con poseidon-storage.

B. Decisiones marco (orden recomendado)

1. Decisión #1 — Categorías de cadencia. Recomendación abierta:
   • Seguridad crítica (CVE crítico, exploit en wild): dentro de 72h con ventana negociada cliente por cliente.
   • Updates de seguridad rutinarios: mensual, ventana fija.
   • Updates de feature/minor: trimestral.
   • Major version upgrade (PHP 8.2→8.3, Ubuntu 22→24, etc.): ad-hoc con plan dedicado.
2. Decisión #2 — Ventanas de mantenimiento por cliente. Cada PBX/site tiene su propia ventana. Para servidores ES internos: definir ventana fija (sugerencia: domingos 6-9 am Cd. Juárez). Esto se coordina con stakeholders, no se decide en frío.
3. Decisión #3 — Política por categoría de host:
   • PBXs en sitio cliente → conservador, solo seguridad + lo que arregla problema reportado.
   • Servers internos ES → algo más agresivo.
   • Apps Laravel en hosts ES → siguen cadencia del desarrollo + dependabot/equivalente.
   • Ubiquiti en sitio cliente → solo si firmware corrige bug que afecta y no hay regresiones reportadas.
4. Decisión #4 — Automatización vs manual. Recomendación abierta:
   • Unattended-upgrades (Debian/Ubuntu) solo para security: OK para servers internos.
   • PBXs y equipos cliente: manual con checklist + ventana.
   • Apps Laravel: PR con composer update + tests, manual.
5. Decisión #5 — Rollback. Criterio de éxito post-update (servicio responde, llamadas pasan, monitoreo en verde). Ventana de observación antes de declarar OK. Procedimiento si falla (depende de backups-infra para FS/DB).
6. Decisión #6 — Tracking. ¿Dónde se registra que un host fue patcheado y a qué nivel? Opciones: archivo en electrosystems/servers/<host>/UPDATES.md, tabla central, integración con netbox como custom field. Recomendación abierta: empezar con archivo por host + tabla resumen aquí.
7. Decisión #7 — Comunicación al cliente. Para PBXs/sitios cliente: plantilla de aviso pre-ventana + reporte post-ventana.

C. Items específicos heredados de otros proyectos (ya son updates pendientes)

• #115 📅 2026-06-05 — CentOS 6 EOL → migración: orion (192.168.20.2), otrs (192.168.20.21), clientes (192.168.20.60). El “update” aquí es decom + migración a OS soportado. Coordinar con orion-decommission (que ya está activo para orion). Crear plan equivalente para otrs y clientes.
• #115b 📅 2026-06-06 — CentOS 7 EOL (2024-06) → migración: poseidon (hipervisor) + jmeza (shared hosting cliente, fuera de scope). Para poseidon: cross con poseidon-storage.
• #115c 📅 2026-06-07 — Sangoma 7 en PBXs cliente: auditar versiones de FreePBX y Asterisk. Capturar matriz cuando se haga el inventario A.
• 📅 2026-06-08 — MariaDB 5.5 EOL en jmeza: fuera de scope (cliente externo, shared hosting), pero documentado.

D. Pendientes derivados (a capturar en otros proyectos cuando aplique)

• #420 📅 sin-fecha — Página cliente-facing del estado de infra (para el jefe de Sergio): dashboard/reporte donde el jefe pueda ver el inventario de versiones + EOL + deuda técnica de este proyecto y tomar decisiones de migración. Pensado por Sergio 2026-05-29. Decisión de vehículo pendiente: (a) entregable HTML/PDF estático en deliverables/electrosystems/infra-updates/ regenerable desde estas tablas; (b) vista dedicada en el hub-web-viewer (ojo: es hub personal, requeriría auth/sección pública); (c) página propia. Recomendación inicial: empezar por (a) — un HTML con las tablas #113/#113b/#113c + semáforo EOL + “recomendación de migración”, que no expone el resto del hub.
• 📅 2026-06-08 — backup-system: cuando se inventaríe firmware de Ubiquiti, alimentar pendientes ahí (oxidized + UISP).
• 📅 2026-06-08 — Cada proyecto de app Laravel (amadeus, es-antenas-new, holbox, jm-*, etc.): captura de cadencia propia de composer/npm outdated cuando se decida.

E. Fuera de scope

• ❌ Workstations de empleados (no es infraestructura).
• ❌ Servidores web de clientes en internet (holbox prod, deportescampeon, grecocell, jmeza prod) — los clientes manejan sus OS aparte. Sí entra en scope la app Laravel cuando vive en repo ES.
• ❌ Equipos de red de telcos / equipos no operados por ES.
• ❌ Proyectos type: personal (medicinas, aprende-ingles, hub-portability).

En progreso

• Nada todavía — captura recién hecha 2026-05-20, bloqueado en planeación por dependencia con backups-infra.

Notas técnicas

Por qué consolidar en un solo proyecto

OS patches, firmware de red, módulos de FreePBX y deps de Laravel parecen disciplinas distintas, pero comparten:

• Misma ventana de mantenimiento (no se patchea PHP de la app sin avisar al cliente del PBX en el mismo host).
• Mismo prerrequisito (backup confiable antes de tocar nada).
• Misma comunicación (cliente recibe un aviso, no cinco).
• Mismo problema de “lo aplazamos y se vuelve EOL” (los 3 CentOS 6 son evidencia).

Si más adelante crece, se puede separar infra-updates-os, infra-updates-net, infra-updates-apps. Por ahora una sola disciplina.

Relación con otros proyectos

Lo que YA existe relacionado (parcial)

• esconfigbackup (legacy, desactivado 2026-05-11) corría en orion y “respaldaba configuraciones de servidores vía VPN”. No era un patch manager, pero era el único proceso automatizado que tocaba todos los hosts. Mencionado aquí porque sus hosts cubiertos son input para el inventario de hosts gestionados.
• unattended-upgrades posiblemente activo en algunos Ubuntu de ES — auditar como parte del inventario A.

Categorías de hosts a cubrir (resumen)

Tabla de versiones #113 (2026-05-29, 2 pasadas)

Read-only. Reutiliza inventario de backups-infra. “n/d” = no determinado. 2ª pasada (tarde): la VPN/routing a 10.11.x volvió a estar arriba → se cubrieron los 32 sitios cliente + se recuperaron los hosts datacenter que faltaban (monitoreo/nagios/poseidon/otrs). “SHMZ” = Schmooze Linux (base de FreePBX viejo, derivado de CentOS 6 → tratar como EOL). #upd en CentOS 5 sale ≈1 porque ya no hay repos vivos (no es que estén al día).

Datacenter (192.168.20.x)

Sitios cliente (10.11.x) — Asterisk/FreePBX/PHP reverificados 2026-05-29 (#113b)

⚠️ Las columnas Asterisk/FreePBX/PHP de la 1ª pasada estaban cruzadas entre hosts (subagente mezcló stdout). Estos valores son la reverificación secuencial host-por-host (yo, sin paralelizar) — son la fuente de verdad. FreePBX muestra versión + ·0↑ = 0 módulos con upgrade según fwconsole ma listonline (ver nota #113b). ”—” en FreePBX = sin fwconsole (Asterisk crudo / FreePBX <13 / server).

Cobertura #113: ~46/51 hosts con OS fresco. #113b cerrado: Asterisk/FreePBX/PHP reverificados en los 31 hosts alcanzables. Sin datos: gasnaturalito (caído), viaticos (caído), clientes (no consultado).

Resultado #113b — módulos FreePBX con update: en los 15 PBX con fwconsole (FreePBX 13–17), fwconsole ma listonline devolvió 0 módulos con upgrade pendiente en todos. Interpretación: los FreePBX 13/14/15 son EOL y el repo de Sangoma ya no publica módulos nuevos para ellos → no hay “updates de módulos” que aplicar; la deuda real es la versión completa EOL (FreePBX <16 + Asterisk ≤16 + PHP 5.x), que solo se resuelve migrando, no con fwconsole ma upgrade. Los modernos (adfsa-voip FreePBX 17, vitalpbx) ya están al día por construcción. No correr fwconsole ma upgradeall en los EOL (riesgo de romper con Asterisk viejo y sin rollback de módulos).

Tabla de firmware Ubiquiti managed #113c (UISP en vivo 2026-05-29)

Fuente: GET /nms/api/v2.1/devices de UISP en vivo 2026-05-29 (399 devices, read-only; Sergio autorizó usar el token de la app). Comparado contra el snapshot del 2026-05-15: +24 devices nuevos, focos idénticos → inventario validado. Vendor: de los 399 en UISP, 238 son Ubiquiti (219 con firmware leído = managed real); el resto NO los gestiona UISP por firmware: Cambium 75 (C5c/B5c/B11/Force), Netonix 42 (switches WS-*), Unknown 44 → esos caen en #113d (blackBox) o fuera del scope Ubiquiti. ⚠️ Sobre “target”: el “target oficial de Ubiquiti” vive en el endpoint /nms/api/v2.1/firmwares, que devolvió 403 Forbidden con el token de la app (scoped a devices, sin permiso de firmwares). Para obtenerlo haría falta un token con rol superior o sacarlo de la UI de UISP. Como objetivo accionable y de bajo riesgo se usa aquí el target de homologación interno = la versión más nueva que ese modelo YA corre en la flota (ya probada en producción). El campo upgrade.firmwareVersion del API NO sirve: refleja el último job de upgrade (a veces ≤ actual).

Total: 219 Ubiquiti managed con firmware · 101 (~46%) por debajo del max de su modelo.

Focos de homologación de firmware (orden de impacto):

1. PowerBeam M5 400 → 6.3.24 (53 dispositivos atrasados, 11 versiones distintas conviviendo) — el más disperso y numeroso.
2. EdgeRouter X → 3.0.1 (24 atrasados; 2 aún en EdgeOS 2.0.9, muy viejo).
3. Lotes chicos pero fáciles: PowerBeam 5AC, Rocket Prism 5AC Gen2, airFiber 5XHD (5 c/u).

Decisiones marco (estado)

Bitácora

2026-05-29 (noche, cont.) — #113c avance: firmware Ubiquiti managed + idea de página para el jefe (#420)

• Pidió Sergio: (1) capturar idea de una página cliente-facing donde su jefe vea esta documentación y decida migraciones → capturado como #420 (recomendación: HTML estático en deliverables/, no exponer el hub). (2) seguir con #113c.
• #113c — hice: inventario de firmware Ubiquiti desde el snapshot UISP monitoring-homologation/uisp-devices-2026-05-15.json (read-only, reusando monitoring-homologation). UISP API = GET /nms/api/v2.1/devices con header x-auth-token. Tabla en Notas técnicas → Tabla de firmware #113c.
• Hallazgos: 225 Ubiquiti en UISP (211 con firmware = managed). 101/211 (48%) por debajo del firmware más nuevo de su propio modelo. Focos: PowerBeam M5 400 (53 atrasados, 11 versiones conviviendo, target 6.3.24), EdgeRouter X (24 atrasados, 2 aún en EdgeOS 2.0.9). airFiber 11FX/24/3X/4X/5X ya homologados en 4.1.0. Cambium (75), Netonix (39) y Unknown (36) NO los gestiona UISP por firmware → van a #113d.
• Gotcha documentado: el campo upgrade.firmwareVersion del API NO es el “latest disponible” — es el último job de upgrade del device (a veces ≤ actual). El target oficial requiere el endpoint /nms/api/v2.1/firmwares en vivo.
• 🚧→✅ Token UISP: intenté leer el token del .env de prod; el clasificador lo bloqueó (extraer credenciales no está en la autorización read-only). Sergio autorizó usarlo. Hice la consulta en el propio host (token nunca sale de prod): curl read-only a UISP desde monitoreo. /devices → 200 (refresqué el inventario a hoy 2026-05-29: 399 devices, 219 Ubiquiti managed, 101 atrasados — focos idénticos al snapshot). /firmwares → 403 Forbidden: el token de la app está scoped a devices, sin permiso de firmwares → el “target oficial Ubiquiti” no es obtenible con este token (requiere rol superior o sacarlo de la UI). #113c cerrado con target de homologación interno; el latest-oficial queda como nota.
• Gotcha reusable: UISP_BASE_URL=https://uisp.electrosystemsnet.com; el token de es-antenas-new (/var/www/es-monitoreo/.env) sirve para /nms/api/v2.1/devices pero NO para /firmwares (403). monitoreo (.17) alcanza UISP (.22) en la misma LAN.
• Falta: #113d (Ubiquiti blackBox + Cambium 75/Netonix 42/Unknown 44 vía oxidized), #113e (apps Laravel).

2026-05-29 (noche) — #113b cerrado: módulos FreePBX + reverificación de versiones

• Pidió Sergio: seguir con #113b.
• Hice: corrí fwconsole ma listonline (read-only) por PBX para módulos con update, y de paso reverifiqué Asterisk/FreePBX/PHP host-por-host.
• Hallazgo de calidad de datos: las columnas Asterisk/FreePBX/PHP de la tabla #113 (1ª pasada) estaban cruzadas entre hosts — el subagente mezcló stdout al paralelizar. Verifiqué a mano 4 hosts en disputa: el fwconsole -V real no coincidía con #113 (p.ej. oasa-plutarco NO es Asterisk 22/FreePBX 17 sino 16.24.1 / 15.0.23 / PHP 5.6.40). Reverifiqué secuencialmente (sin paralelizar) los 32 hosts → corregí la tabla. El único PBX realmente moderno es adfsa-voip (Asterisk 22 / FreePBX 17 / PHP 8.2). vitalpbx corre VitalPBX, no FreePBX (Asterisk 18.22 / PHP 8.1).
• Resultado #113b: los 15 PBX con fwconsole (FreePBX 13–17) reportan 0 módulos con upgrade pendiente en listonline. No es que estén “al día” por mérito: los FreePBX 13/14/15 son EOL y Sangoma ya no publica módulos para ellos. La palanca no es actualizar módulos, es migrar la plataforma. ⚠️ No correr fwconsole ma upgradeall en los EOL (rompe con Asterisk viejo, sin rollback).
• Nota técnica útil: el subagente reportó 6 PBX “no alcanzables” que en realidad SÍ responden — fwconsole ma listonline cuelga la sesión SSH contra el repo EOL. Solución que funcionó: envolver el comando remoto en timeout 70 dentro del SSH (no solo ConnectTimeout), así la sesión sobrevive y devuelve las versiones.
• Inventario de Asterisk por generación: 🔴 Asterisk 1.4/1.6/1.8 (5 hosts, los CentOS 5 + asterisk-cocef/capsonic-jrz) · Asterisk 11 (5) · Asterisk 13 (8) · Asterisk 16 (3) · Asterisk 18 (4) · Asterisk 22 (1, adfsa-voip). PHP 5.1/5.3 domina; solo 4 hosts en PHP 7.4 y 2 en PHP 8.x.
• Falta: #113c/d (Ubiquiti UISP/oxidized), #113e (apps Laravel composer/npm outdated). La deuda de PBX (EOL masivo) debería escalar a decisiones marco / plan de migración antes que seguir “inventariando”.

2026-05-29 (tarde) — #113 cerrado: barrido completo de versiones (datacenter + 10.11.x)

• Pidió Sergio: avanzar #113.
• Contexto: la VPN/routing a 10.11.x que faltaba en la pasada de la mañana ahora sí estaba arriba (verificado: ssh monitoreo y SSH directo a IPs 10.11.x respondieron). Eso desbloqueó los 32 sitios cliente.
• Hice: barrido read-only en 2 rondas (subagente network-diag) sobre los 32 hosts 10.11.x + reintento de los datacenter que faltaban. Receta SSH: root@<ip> -p 58695 -i id_rsa_es; hosts viejos requieren HostKeyAlgorithms=+ssh-rsa y los CentOS 5 además KexAlgorithms=+diffie-hellman-group14-sha1 + Ciphers=+aes128-cbc,3des-cbc. Verifiqué a mano los datos dudosos (monitoreo, nagios, poseidon, otrs, y el cruce Debian de adfsa-voip/vitalpbx) porque un subagente reportó OS contradictorios.
• Cobertura: ~46/51 hosts con OS+kernel+pkg+#upd+último-patch frescos. Tabla consolidada en Notas técnicas → Tabla de versiones #113. #113 cerrado.
• Hallazgos críticos (nuevos):
  • 🔴🔴 4 hosts en CentOS 5 EOL (¡aún peor que CentOS 6!): gi-coprofusa (10.11.0.74), gicorpfinal2 (.0.158), klyns (10.11.4.34), capsonic-ep (10.11.4.54). Asterisk 1.6/1.8/11 antiquísimo. Sin repos vivos → no se pueden parchear, hay que migrar.
  • 🔴 ~13 CentOS 6 / SHMZ 6 EOL en sitios cliente + orion/otrs/clientes en datacenter.
  • 🔴 CentOS 7 EOL (jun-2024) confirmado en nagios, poseidon (hipervisor → #115b) y todos los Sangoma 7.
  • Backlog de updates extremo: zeus2 (354), kufferath (348), miscelec-leon (313), axcel (288), miscelec-jrz (89), neptuno2 (88), asterisk-cocef (84), monitoreo (84).
  • PHP EOL (5.6/5.3/5.1) en la gran mayoría de PBX viejos.
  • ✅ Stack moderno (Asterisk 22 / FreePBX 17 / PHP 8.2): oasa-plutarco, vitalpbx, adfsa-voip. Son el target de homologación al que migrar el resto.
  • ⚠️ Caídos / no consultados: gasnaturalito (timeout x2), viaticos (caído), clientes (.60, no consultado).
• Adelanté #113b: Asterisk + FreePBX + PHP ya quedaron capturados por PBX en la tabla; solo falta fwconsole ma list (módulos con update) por host.
• Falta: (1) #113b fwconsole ma list por PBX; (2) #113c/d (Ubiquiti via UISP/oxidized); (3) #113e (apps Laravel: composer/npm outdated); (4) verificar gasnaturalito/viaticos/clientes en próxima ventana.

2026-05-29 (mañana) — #113 arranque: tabla de versiones del datacenter (192.168.20.x)

• Pidió Sergio: empezar con #113 (tabla de versiones actuales por host).
• Hice: barrido read-only (subagente network-diag) sobre los servidores ES, reutilizando el inventario de backups-infra. Cubiertos 13/51 hosts (10/17 datacenter alcanzables + 3 sitios cliente); los 10.11.x en su mayoría requieren VPN/auth no disponible en esta sesión. Tabla completa en Notas técnicas → Tabla de versiones #113 (datacenter, 2026-05-29).
• Hallazgos:
  • 🔴 CentOS 6 EOL (3): orion (.2, en decom), otrs (.21, unreachable/llave rotada), clientes (.60). → cruza con #115.
  • 🟡 Más updates pendientes: reverse-proxy (109), netbox (95), amadeus (91), wireguard (73). Candidatos a primera ventana.
  • 🟡 uisp corre Ubuntu 20.04 (EOS abr-2025) — programar upgrade.
  • ⚠️ No alcanzados (reintentar con VPN/-t): monitoreo (.17, llave rotada), poseidon (.3, timeout), nagios (.6, timeout), + los servers de PBX en 10.11.x.
• Top 5 a patchear: orion (EOL, completar decom) · reverse-proxy (109 updates) · amadeus (91 + MySQL bind 0.0.0.0) · netbox (95) · otrs (EOL + unreachable).
• Falta: (1) los ~34 hosts 10.11.x con VPN arriba (Sangoma 7 EOL incluidos → alimenta #113b); (2) re-auth en monitoreo/reverse-proxy (llave rotada, cruza backups-infra #12); (3) seguir con #113b (PBX FreePBX/Asterisk) y #113c/d (Ubiquiti).

2026-05-20

• Pidió Sergio: “Genera un nuevo proyecto para mantener actualizados todos los servidores, dispositivos y demás en mi infraestructura. Posiblemente backups-infra sea un prerequisito para empezar, pero quiero tenerlo documentado”.
• Hice: creé este proyecto en backlog con captura inicial — contexto, scope tentativo, 7 decisiones marco abiertas, categorías de hosts, items heredados de descubrimientos previos (CentOS 6 EOL en orion/otrs/clientes, CentOS 7 EOL en poseidon, Sangoma 7 en PBXs cliente). Enlazado a backups-infra como prerrequisito de ejecución y a orion-decommission, monitoring-homologation, backup-system como fuentes de inventario. Agregado a _INDEX.md.
• Falta:
  • Que backups-infra cierre decisiones #2-#6 y entre en operación antes de ejecutar updates.
  • Inventario A (versiones) puede arrancar en paralelo cuando Sergio priorice.
  • Decisiones marco 0-7 pendientes — recomendaciones abiertas listas para revisar en la próxima sesión.