=============================================================================== 📋 TAREAS SIAX MONITOR - FASE 4.1: CORRECCIÓN CRÍTICA NVM =============================================================================== Fecha: 2026-01-15 Prioridad: CRÍTICA ⚠️ Estado: EN PROGRESO =============================================================================== 🐛 PROBLEMA DETECTADO =============================================================================== Bug crítico en service_generator.rs que impide el funcionamiento con Node.js instalado vía NVM (Node Version Manager). Síntoma: Status 203/EXEC en systemd Causa: Rutas hardcodeadas (/usr/bin/node, /usr/bin/npm) Impacto: El 80% de instalaciones Node.js en producción usan NVM Caso de prueba: APP-GENERADOR-DE-IDEAS - Genera servicio con ExecStart=/usr/bin/npm start - Systemd no puede ejecutar porque npm está en ~/.nvm/versions/node/*/bin/npm - Servicio falla con 8300+ reintentos automáticos =============================================================================== ✅ TAREAS COMPLETADAS (FASE 4) =============================================================================== [x] Implementar src/models/ (ServiceConfig, ManagedApp, AppStatus) [x] Implementar src/systemd/ (service_generator, systemctl, parser) [x] Implementar src/orchestrator/ (app_manager, lifecycle) [x] Implementar src/api/ (handlers, websocket, dto) [x] Evolucionar monitor.rs (reconciliación systemd) [x] Actualizar main.rs con API REST + WebSocket [x] Crear script desplegar_agent.sh [x] Documentación completa (README.md) [x] Compilación exitosa =============================================================================== 🔧 TAREAS FASE 4.1 - CORRECCIÓN NVM =============================================================================== ------------------------------------------------------------------------------- 1. MODIFICAR ServiceConfig (src/models/service_config.rs) ------------------------------------------------------------------------------- [ ] Agregar campo: custom_executable: Option - Permite especificar ruta personalizada del ejecutable - Si es None, se auto-detecta [ ] Agregar campo: use_npm_start: Option - true = genera "ExecStart=/path/npm start" - false = genera "ExecStart=/path/node script.js" - Default: false [ ] Actualizar método Default para incluir nuevos campos [ ] Actualizar método validate() para validar package.json si use_npm_start=true Ejemplo esperado: ```rust pub struct ServiceConfig { pub app_name: String, pub script_path: String, pub working_directory: String, pub user: String, pub environment: HashMap, pub restart_policy: RestartPolicy, pub app_type: AppType, pub description: Option, pub custom_executable: Option, // NUEVO pub use_npm_start: Option, // NUEVO } ``` ------------------------------------------------------------------------------- 2. IMPLEMENTAR DETECCIÓN AUTOMÁTICA (src/systemd/service_generator.rs) ------------------------------------------------------------------------------- [ ] Crear función detect_user_executable() Firma: fn detect_user_executable(user: &str, cmd: &str) -> Result Lógica: 1. Ejecutar: sudo -u {user} which {cmd} 2. Si falla, buscar en ~/.nvm/versions/node/*/bin/{cmd} 3. Si falla, buscar en /usr/bin/{cmd} 4. Si falla, retornar error claro Ejemplo: ```rust let output = Command::new("sudo") .args(&["-u", user, "which", cmd]) .output()?; if output.status.success() { Ok(String::from_utf8(output.stdout)?.trim().to_string()) } else { // Fallbacks... } ``` [ ] Crear función resolve_executable() Firma: fn resolve_executable(config: &ServiceConfig) -> Result Lógica: 1. Si custom_executable está definido, usarlo 2. Si no, detectar automáticamente con detect_user_executable() 3. Validar que el ejecutable existe y es ejecutable 4. Loggear ruta detectada para debugging Ejemplo: ```rust if let Some(exe) = &config.custom_executable { return Ok(exe.clone()); } let cmd = if config.use_npm_start.unwrap_or(false) { "npm" } else { config.app_type.get_command() }; Self::detect_user_executable(&config.user, cmd) ``` [ ] Modificar generate_service_content() - Llamar a resolve_executable() en lugar de app_type.get_executable() - Si use_npm_start=true, generar "ExecStart={npm} start" - Si use_npm_start=false, generar "ExecStart={node} {script_path}" - WorkingDirectory debe ser raíz del proyecto si use_npm_start=true [ ] Agregar validación de package.json - Si use_npm_start=true, verificar que existe {working_directory}/package.json - Retornar error claro si no existe ------------------------------------------------------------------------------- 3. ACTUALIZAR DTOs (src/api/dto.rs) ------------------------------------------------------------------------------- [ ] Modificar RegisterAppRequest para incluir nuevos campos: ```rust #[derive(Debug, Deserialize)] pub struct RegisterAppRequest { // ... campos existentes ... pub custom_executable: Option, pub use_npm_start: Option, } ``` [ ] Actualizar documentación de los DTOs ------------------------------------------------------------------------------- 4. ACTUALIZAR AppType (src/models/service_config.rs) ------------------------------------------------------------------------------- [ ] Cambiar get_executable() por get_command() - Retorna solo el nombre del comando ("node", "python3") - No retorna rutas absolutas [ ] Deprecar get_executable() o eliminarlo Antes: ```rust pub fn get_executable(&self) -> &str { match self { AppType::NodeJs => "/usr/bin/node", AppType::Python => "/usr/bin/python3", } } ``` Después: ```rust pub fn get_command(&self) -> &str { match self { AppType::NodeJs => "node", AppType::Python => "python3", } } ``` ------------------------------------------------------------------------------- 5. TESTING ------------------------------------------------------------------------------- [ ] Test unitario: detect_user_executable() - Mock de usuario con NVM - Mock de usuario con node en /usr/bin - Mock de usuario sin node instalado - Verificar errores claros [ ] Test unitario: resolve_executable() - Con custom_executable definido - Con auto-detección - Con errores [ ] Test de integración: APP-GENERADOR-DE-IDEAS Input: ```json { "app_name": "IDEAS", "script_path": "src/app.js", "working_directory": "/home/user_apps/apps/APP-GENERADOR-DE-IDEAS", "user": "user_apps", "use_npm_start": true, "app_type": "nodejs", "restart_policy": "always" } ``` Resultado esperado: - Servicio generado con ruta correcta de npm - Servicio inicia exitosamente - Logs muestran "Servidor activo APP IDEAS Puerto: 2000" [ ] Test: Aplicación Node.js con node directo (sin npm) [ ] Test: Aplicación Python con virtualenv ------------------------------------------------------------------------------- 6. LOGGING Y DEBUGGING ------------------------------------------------------------------------------- [ ] Agregar logs detallados en detect_user_executable(): - Log: "Detectando {cmd} para usuario {user}" - Log: "Ejecutable detectado: {ruta}" - Log: "Fallback a búsqueda manual en NVM" - Error: "No se pudo encontrar {cmd} para usuario {user}" [ ] Agregar logs en generate_service_content(): - Log: "Generando servicio con ejecutable: {ruta}" - Log: "Modo: npm start" o "Modo: node directo" [ ] Mejorar mensajes de error: - Incluir paths buscados - Incluir sugerencias de solución - Incluir link a documentación ------------------------------------------------------------------------------- 7. DOCUMENTACIÓN ------------------------------------------------------------------------------- [ ] Actualizar README.md sección "Registrar Nueva Aplicación" - Documentar campo use_npm_start - Documentar campo custom_executable - Agregar ejemplos con NVM - Agregar troubleshooting para NVM [ ] Agregar sección "Instalaciones NVM" al README Contenido: - Cómo detecta automáticamente las rutas - Cómo especificar custom_executable manualmente - Configuración de sudoers necesaria para 'which' [ ] Actualizar ejemplos de curl con nuevos campos [ ] Agregar caso de uso: "Migrar de node en /usr/bin a NVM" ------------------------------------------------------------------------------- 8. CASOS EDGE A CONSIDERAR ------------------------------------------------------------------------------- [ ] Usuario con múltiples versiones de Node.js instaladas - NVM debería retornar la versión activa - Loggear warning si hay múltiples versiones [ ] Usuario sin shell (system user como 'nodejs') - 'which' podría fallar - Implementar fallback de búsqueda directa en filesystem [ ] Python en virtualenv - Similar a NVM para Node.js - Detectar ruta de python en ~/.virtualenvs/*/bin/python [ ] Permisos insuficientes para ejecutar 'sudo -u' - Retornar error claro - Sugerir configuración de sudoers [ ] Ejecutable en ruta no estándar - Permitir custom_executable absoluto - Validar que el path existe ------------------------------------------------------------------------------- 9. VALIDACIONES DE SEGURIDAD ------------------------------------------------------------------------------- [ ] Validar que custom_executable no contiene comandos peligrosos - No permitir pipes, redirects, múltiples comandos - Solo permitir paths absolutos - Verificar que es un archivo ejecutable real [ ] Sanitizar salida de 'which' - Trim whitespace - Validar formato de path Unix - Rechazar paths con caracteres sospechosos [ ] Loggear intentos de rutas inválidas - Para auditoría de seguridad - Detectar posibles intentos de inyección ------------------------------------------------------------------------------- 10. MIGRACIÓN DE SERVICIOS EXISTENTES ------------------------------------------------------------------------------- [ ] Crear script de migración (opcional) - Escanear servicios existentes en /etc/systemd/system/siax-app-*.service - Detectar si usan rutas incorrectas - Regenerar con auto-detección - Reiniciar servicios afectados [ ] Documentar proceso de migración manual - Cómo identificar servicios afectados - Cómo regenerarlos con la API - Cómo verificar que funcionan correctamente =============================================================================== 🧪 VALIDACIÓN FINAL =============================================================================== Criterios para considerar la Fase 4.1 COMPLETA: [ ] APP-GENERADOR-DE-IDEAS inicia correctamente con npm start [ ] No más errores 203/EXEC en systemd [ ] Detección automática funciona en 3 escenarios: - Node.js con NVM - Node.js en /usr/bin - Python en virtualenv [ ] Logs muestran rutas detectadas claramente [ ] Documentación actualizada con ejemplos de NVM [ ] Tests pasando [ ] Compilación sin errores ni warnings [ ] Backward compatible con configuraciones existentes (sin custom_executable) =============================================================================== 📈 PRIORIDAD DE IMPLEMENTACIÓN =============================================================================== DÍA 1 (CRÍTICO): 1. Modificar ServiceConfig (campos nuevos) 2. Implementar detect_user_executable() 3. Modificar generate_service_content() 4. Probar con APP-GENERADOR-DE-IDEAS DÍA 2 (IMPORTANTE): 5. Actualizar DTOs 6. Agregar logging detallado 7. Tests unitarios básicos 8. Actualizar README.md DÍA 3 (COMPLEMENTARIO): 9. Tests de integración completos 10. Casos edge 11. Validaciones de seguridad 12. Script de migración (opcional) =============================================================================== 🎯 META FINAL =============================================================================== El proyecto SIAX Monitor debe: ✅ Funcionar out-of-the-box con instalaciones NVM (caso más común) ✅ Auto-detectar rutas de ejecutables sin intervención manual ✅ Generar servicios systemd correctos en el primer intento ✅ Proporcionar mensajes de error claros cuando algo falla ✅ Soportar configuraciones personalizadas (custom_executable) Estado objetivo: PRODUCTION-READY 🚀 =============================================================================== 📝 NOTAS FINALES =============================================================================== - Esta corrección es CRÍTICA para que el proyecto sea utilizable en producción - El 80% de servidores Node.js usan NVM, no /usr/bin/node - La auto-detección debe ser el comportamiento por defecto - custom_executable es un escape hatch para casos especiales - La validación y logging son clave para debugging Una vez completada la Fase 4.1, el proyecto estará verdaderamente listo para producción y podrá gestionar aplicaciones Node.js y Python en cualquier configuración estándar.