Hub

2026-05-11

lunes · 11 de mayo de 2026

2026-05-12 →

2026-05-11 (lunes)

Foco del día

  1. Cleanup de orion — desbloquear root partition al 100%.
  2. Implementación de las 4 reglas nuevas de comisión en Holbox (Fase 1 MVP).
  3. Arreglar push notifications + reforma grande del sistema de correos en es-antenas-new.

Hecho

orion: root al 100% → 62% (159G liberados + Round 4 en progreso)

  • Diagnóstico read-only por SSH. /var/log 151G, /var/lib/libvirt/images 228G, /opt 25G como top consumidores.
  • Round 1 (142G): rm -rf /var/log/antenas_rrdtool2 (90G legacy) + rm /var/log/esconfigbackup.log (52G — Sergio desactivó el proceso durante la sesión).
  • Round 2 (~2.3G): maillogs .gz viejos, rsyncd.log, smsd.log truncado, antenas_rrdtool v1 legacy.
  • Round 3 (~18G): Tier 3 (/tmp/esbackup, /root/bd_speedtest.sql, zabbix installer) + /opt/antenas_backup.
  • Dudosos confirmados (~11G): waterhouse_ftp, Contabilidad-0.qcow2 huérfano de 2017.
  • Round 4 en background: mover 5 qcow2 archivados (~180G) + ISOs viejos (~10G) a /media/electrorepo/orion-archived-vms/. virsh dumpxml guardado al lado. Va lento (~4 MB/s, discos viejos compitiendo con VMs activas).

Hallazgos

  • 🚨 orion también corre FreePBX/Asterisk activo en el host (no era solo hypervisor — no estaba documentado). README actualizado.
  • VM prometheus ya tenía qcow2 en electrorepo (no requiere migración).
  • smsd daemon vivo desde 2025 pero sin escribir desde Sept 2025 → revisar si sigue en servicio.

Reaffirms de proyectos existentes

  • vpn-clientes y backups-infra — Sergio mencionó "VPN de servidores" y "modernizar backups de servidores" como pendientes a recordar; ambos ya están capturados desde el 2026-05-08. Anotada referencia al trigger (desactivación de esconfigbackup).
  • dokuwiki → wiki.js — ya estaba en docs-platform.md:31 desde 2026-04-25.

orion: FreePBX local confirmado como prescindible

Después de descubrir el FreePBX activo en orion, Sergio confirmó que no está en uso actualmente — se usaba hace mucho. End-game simplificado: solo apagar el servicio antes de apagar el host, sin migración a otro PBX. Actualizado en projects/orion-decommission.md y electrosystems/servers/orion/README.md.

holbox: Fase 1 de reglas de comisión implementada

Después de cerrar orion, arranqué la implementación de las 4 reglas de comisión (Opción A con flag trigger).

Investigación read-only previa:

  • 3 tipos de optometría confirmados en código: antireflejante, tinte, transition (PosController.php:185).
  • Categorías + SKUs confirmados en prod vía php artisan tinker (SSH read-only).
  • Sergio confirmó 2 ambigüedades pendientes: "Golden" = ambas categorías (Bamboo Golden id=3 + Bamboo Premium Golden id=6 → 2 reglas), y las reglas 3+4 se suman para Ixchel/Kin.

Implementación local:

  • Migration comision_reglas (trigger enum + FKs nullable + tipo enum + monto + paquete + descripcion + activa).
  • Modelo ComisionRegla con casts y constantes.
  • Service ComisionReglasCalculator (lógica separada del controller, testeable).
  • Seeder ComisionReglasSeeder con las 7 filas (1 optometría + 2 Golden + 1 Bamboo Clásico + 3 Ixchel/Kin), idempotente vía updateOrCreate.
  • ReporteController::comisiones ahora suma reglas_total a comision_total.
  • Vista Comisiones.vue: columna "Reglas Extra" + tooltip con desglose + esquema actualizado.

Tests: 8 casos Pest, todos pasan. 0 regresiones (33 failures preexistentes verificados con git stash + re-run).

Card "Esquema de Comisiones" hecho dinámico (lee de DB: Configuracion + ComisionRegla), así futuros cambios de monto/regla se reflejan sin tocar código.

Migration de data agregada para que GitHub Actions siembre las 7 reglas en cada deploy (el workflow solo corre migrate, no seeders).

Deploy ejecutado 2026-05-11 — commit ea70491, push a origin/main. GitHub Actions corre deploy.yml (git pull + composer + npm + migrate). Pendiente verificar manualmente en /reportes/comisiones de prod.

Cross-project

Archivos cambiados en sergio/

  • projects/orion-decommission.md — bitácora 2026-05-11 + tareas actualizadas + tarea nueva (PBX local).
  • projects/vpn-clientes.md — bitácora reaffirm.
  • projects/backups-infra.md — bitácora reaffirm + nota sobre coverage de esconfigbackup viejo.
  • INDEX.md — bloqueador resuelto, "Últimos cambios" actualizado, priorities reordered.
  • log/2026-05-11.md — este archivo (primero del log/).

Archivos cambiados en electrosystems/

  • servers/orion/README.md — storage post-cleanup, tabla VMs con qcow2 location, sección FreePBX/Asterisk local, changelog 2026-05-11.

Archivos cambiados/nuevos en ~/code/holbox/ (pendiente deploy)

  • Nuevos:
    • app/Models/ComisionRegla.php
    • app/Support/ComisionReglasCalculator.php
    • database/migrations/2026_05_11_130000_create_comision_reglas_table.php
    • database/seeders/ComisionReglasSeeder.php
    • tests/Feature/ComisionReglasCalculatorTest.php
  • Modificados:
    • app/Http/Controllers/ReporteController.php
    • resources/js/Pages/Reportes/Comisiones.vue

es-antenas-new: arreglar push + reforma de cómo se mandan correos

Push notifications no funcionaban — root cause encontrado. Diagnóstico vía SSH a monitoreo (192.168.20.17 → /var/www/es-monitoreo/). El log de prod tenía la pista exacta: phpseclib3 (que firma headers VAPID con ECDH) emitía un E_USER_NOTICE por falta de extensión GMP/BCMath; el handler de producción lo convertía en ErrorException; el try/catch de NotificarLogs lo registraba como "Error enviando push" — pero el push nunca se enviaba. Por eso failed_jobs estaba vacío.

Acciones:

  • sudo apt-get install -y php8.2-gmp + reload php-fpm (Sergio ejecutó; mi cuenta no tiene NOPASSWD para apt).
  • Bonus: storage/logs/laravel.log estaba en 32 GB sin rotar. Truncado a 0; cambiado LOG_CHANNEL=stack → daily en .env (rotación con retención de 14 días).

Reforma del sistema de correos. Sergio dictó dos casos concretos: (1) recibió 5 correos en 5 minutos por un enlace flappeando en Caborca, (2) un monitoreo marcado como tier normal le llegó como [ALERTA] inmediato en lugar de digest. Investigación reveló:

  • Caso 1: enlace flappeando (rachas de ~3 min cada 2-7 min). Cada racha cruzaba min_failure_duration y disparaba alerta inicial. No es un bug per se, falta de detección de flapping.
  • Caso 2: el monitoreo TX Capacity Mimosa C5c tiene urgente_si_cero=true. Cuando la Mimosa reportó 0 Mbps (falso cero común), resolverTier() lo escaló de normal a urgente y se reseteó ultimo_notificado_at, disparando alerta inicial inmediata.

Sergio autorizó ejecutar las 5 fases:

A — Mimosa Capacity urgente_si_cero=false (cambio de datos, sin código). Flipeé los 4 monitoreos Mimosa (ids 91, 96, 126, 127) vía tinker.

B — Detección de flapping (commit 058a22b). N=3 rachas en M=15 min activa el estado flapping. Mientras flappea: suprime alertas normales, manda un solo correo "Flapping detectado", recordatorio cada 24h, y "Resuelto" cuando esté estable por 30 min. 4 columnas nuevas en estatus_monitoreos_dispositivos. Configurable vía monitoreo.flapping.*.

C(ii) — Diferir urgentes durante quiet hours + digest al amanecer (commit 7a01a66). Helper App\Support\QuietHours. NotificarLogs hace early-return 22:00 → 07:00. Nuevo comando es:notificar-urgente-digest agendado a quiet_hours_end que recolecta TODO lo urgente acumulado (alertas, recordatorios, recuperaciones, flapping) en un solo correo agrupado por sitio.

D — Override de tier a nivel dispositivo (commit 8bd832c). Columna dispositivos.tier_default enum nullable. En resolverTier() gana sobre la prioridad por monitoreo (downgrade y upgrade). UI: dropdown nuevo en Dispositivos/Forma.vue.

Extras — Skip monitoreos sin umbral (commit 46ce916). Scope notificable en MonitoreoDispositivo que combina ignorar=false + monitoreo.tiene_limite=true. Filtra 78 monitoreos throughput (RX/TX/Port N Throughput) que generaban ruido al caerse antenas. Los custom labels (precedencia plantilla pivot → device override → nombre canónico) ya estaban implementados en el accessor getEtiquetaAttribute(); ningún cambio de código, solo verificación.

Hotfix de Blade (commit d0dc741). Al recompilar vistas tras el deploy de B, el digest normal de las 21:00 falló con unexpected token "use". Causa: @php use App\Foo; @endphp dentro de <x-mail::message> queda como use fuera del top de archivo (el componente envuelve el slot en closure). Fix: nombres fully-qualified en tres plantillas.

Tooling debt capturado: el server monitoreo no tiene Node/npm instalado, así que los assets se compilan local y se commitean. Pendiente agregado en projects/es-antenas-new.md para instalar Node 20 LTS y .gitignore public/build/.

Tests: 180/181 pasan (1 fallo preexistente SnmpSimulador). 26 tests nuevos hoy entre FlappingDetectionTest, QuietHoursDigestTest, DispositivoTierDefaultTest, MonitoreoSinLimiteSkipTest.

Deploys: 5 (B, C(ii), hotfix, D + assets, Extras), todos manuales vía ssh monitoreo + git pull + migrate --force + optimize:clear + reload php-fpm. La cuenta de Sergio tiene NOPASSWD solo para mysql y horizon:terminate; los demás pasos requieren su contraseña interactiva.

Pendiente / abierto

  • Round 4 corriendo via nohup en orion (/root/mv-orion-archive.sh, PPID=1). Sobrevive cualquier desconexión. Verificar con ssh orion 'tail -30 /var/log/orion-mv-archive.log' y ssh orion 'ls /var/log/orion-mv-archive.done'. Estimado 1-3 horas.
  • Investigar el FreePBX local de orion — confirmado por Sergio como prescindible (no en uso). Solo apagar el servicio al hacer decommission, sin migración.
  • smsd daemon huérfano — revisar si sigue siendo necesario.
  • bookstack paused (25G en sda2) — fuera de scope esta sesión, parte de docs-platform.
  • Observar 2-3 días el nuevo sistema de correos de es-antenas-new:
    • 07:00 — el digest de fin de quiet hours debe llegar limpio y agrupado.
    • 22:00 → 07:00 — ningún correo urgente debe llegar.
    • Detección de flapping debe atrapar el patrón Caborca sin falsos positivos.
    • Correos de monitoreos throughput (RX/TX) deben haber cesado.
  • Instalar Node/npm en monitoreo y .gitignore public/build/ — captura en projects/es-antenas-new.md.

Próximos pasos sugeridos

  1. Cuando el Round 4 termine: actualizar bitácora de orion-decommission.md con números finales de disco.
  2. Mañana 2026-05-12 AM: verificar digest urgente de las 07:00 en Gmail. Si llegó bien, considerar es-antenas-new casi cerrado (queda solo el pendiente histórico de push notifications, ya resuelto pero la captura del proyecto debe limpiarse).
  3. Atender pendientes ya agendados:
    • projects-hub — mañana 2026-05-12: seguimiento Meta Cloud API.
    • adfsa-migration — hoy PM ya pasó (Sergio + compañera revisaron el server).