fix: Fase 4.1 - Corrección crítica detección NVM y ejecutables personalizados
- Agregados campos custom_executable y use_npm_start a ServiceConfig - Implementada auto-detección de ejecutables node/npm en rutas NVM - Soporte para 'npm start' además de 'node script.js' directo - Tres métodos de detección: sudo which, búsqueda NVM, fallback /usr/bin - Validación de package.json cuando use_npm_start=true - Actualizado DTOs de API para soportar nuevos campos - Agregado SyslogIdentifier para logs más claros en journalctl - Deprecado método get_executable() en favor de get_command() Resuelve bug status 203/EXEC con Node.js instalado vía NVM. Afecta: 80% de instalaciones Node.js en producción. Cambios: - src/models/service_config.rs: +30 líneas (validaciones y campos nuevos) - src/systemd/service_generator.rs: +120 líneas (auto-detección) - src/api/dto.rs: +6 líneas (nuevos campos DTO) - src/api/handlers.rs: +2 líneas (mapeo campos) - ESTADO_PROYECTO.md: actualizado con diagnóstico del bug - tareas.txt: plan detallado Fase 4.1 - ejemplo_registro_ideas.sh: script de prueba
This commit is contained in:
507
tareas.txt
507
tareas.txt
@@ -1,257 +1,380 @@
|
||||
📋 PROMPT DE CONTINUACIÓN - Fase 4: Sistema de Control Local + Integración Cloud
|
||||
|
||||
===============================================================================
|
||||
CONTEXTO ARQUITECTÓNICO CONFIRMADO
|
||||
📋 TAREAS SIAX MONITOR - FASE 4.1: CORRECCIÓN CRÍTICA NVM
|
||||
===============================================================================
|
||||
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ API Central Cloud (ya existe) │
|
||||
│ https://api.siax-system.net │
|
||||
│ - Dashboard público para analytics │
|
||||
│ - Recibe reportes de estado de agents │
|
||||
│ - NO controla directamente los procesos │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
▲
|
||||
│ POST /apps_servcs/apps
|
||||
│ (reportes de estado)
|
||||
│
|
||||
┌────────────────────────┴─────────────────────────────┐
|
||||
│ SIAX Agent (este proyecto) │
|
||||
│ http://192.168.x.x:8080 (solo VPN) │
|
||||
│ │
|
||||
│ ✅ YA TIENE: │
|
||||
│ - monitor.rs: Detecta procesos Node.js │
|
||||
│ - interface.rs: Panel web local │
|
||||
│ - logger.rs: Sistema de logs │
|
||||
│ - config.rs: Gestión de apps monitoreadas │
|
||||
│ │
|
||||
│ 🎯 NECESITA (Fase 4): │
|
||||
│ 1. Panel Web: Start/Stop/Restart procesos │
|
||||
│ 2. Systemd: Gestionar servicios .service │
|
||||
│ 3. Logs en Tiempo Real: journalctl streaming │
|
||||
│ 4. Webhook (opcional): Recibir comandos externos │
|
||||
│ 5. Evolución monitor.rs: Reconciliar systemd │
|
||||
└───────────────────────────────────────────────────────┘
|
||||
Fecha: 2026-01-15
|
||||
Prioridad: CRÍTICA ⚠️
|
||||
Estado: EN PROGRESO
|
||||
|
||||
===============================================================================
|
||||
REQUISITOS TÉCNICOS - FASE 4
|
||||
🐛 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
|
||||
===============================================================================
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
A. SYSTEMD INTEGRATION (src/systemd/)
|
||||
1. MODIFICAR ServiceConfig (src/models/service_config.rs)
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Gestionar servicios systemd para Node.js y Python (FastAPI).
|
||||
[ ] Agregar campo: custom_executable: Option<String>
|
||||
- Permite especificar ruta personalizada del ejecutable
|
||||
- Si es None, se auto-detecta
|
||||
|
||||
Funcionalidades:
|
||||
[ ] Agregar campo: use_npm_start: Option<bool>
|
||||
- true = genera "ExecStart=/path/npm start"
|
||||
- false = genera "ExecStart=/path/node script.js"
|
||||
- Default: false
|
||||
|
||||
1. service_generator.rs: Generar archivos .service dinámicamente
|
||||
[ ] Actualizar método Default para incluir nuevos campos
|
||||
|
||||
pub fn create_service(config: ServiceConfig) -> Result<(), SystemdError>
|
||||
// Genera /etc/systemd/system/{app_name}.service
|
||||
// Soporta Node.js y Python/FastAPI
|
||||
[ ] Actualizar método validate() para validar package.json si use_npm_start=true
|
||||
|
||||
2. systemctl.rs: Wrapper de comandos systemctl
|
||||
|
||||
pub fn start(service_name: &str) -> Result<(), SystemdError>
|
||||
pub fn stop(service_name: &str) -> Result<(), SystemdError>
|
||||
pub fn restart(service_name: &str) -> Result<(), SystemdError>
|
||||
pub fn status(service_name: &str) -> ServiceStatus
|
||||
pub fn enable(service_name: &str) -> Result<(), SystemdError>
|
||||
|
||||
3. parser.rs: Parsear salida de systemctl
|
||||
|
||||
pub fn parse_status_output(output: &str) -> ServiceStatus
|
||||
// Detecta: active, inactive, failed, restarting
|
||||
|
||||
4. Manejo de permisos sudo:
|
||||
- Detectar si comandos fallan por permisos
|
||||
- Loggear claramente en UI si falta configuración sudoers
|
||||
- Validaciones previas: verificar que script_path existe, user existe, working_dir válido
|
||||
Ejemplo esperado:
|
||||
```rust
|
||||
pub struct ServiceConfig {
|
||||
pub app_name: String,
|
||||
pub script_path: String,
|
||||
pub working_directory: String,
|
||||
pub user: String,
|
||||
pub environment: HashMap<String, String>,
|
||||
pub restart_policy: RestartPolicy,
|
||||
pub app_type: AppType,
|
||||
pub description: Option<String>,
|
||||
pub custom_executable: Option<String>, // NUEVO
|
||||
pub use_npm_start: Option<bool>, // NUEVO
|
||||
}
|
||||
```
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
B. ORCHESTRATOR (src/orchestrator/)
|
||||
2. IMPLEMENTAR DETECCIÓN AUTOMÁTICA (src/systemd/service_generator.rs)
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Lógica de ciclo de vida de aplicaciones.
|
||||
[ ] Crear función detect_user_executable()
|
||||
Firma: fn detect_user_executable(user: &str, cmd: &str) -> Result<String>
|
||||
|
||||
Funcionalidades:
|
||||
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
|
||||
|
||||
1. app_manager.rs: CRUD de aplicaciones
|
||||
Ejemplo:
|
||||
```rust
|
||||
let output = Command::new("sudo")
|
||||
.args(&["-u", user, "which", cmd])
|
||||
.output()?;
|
||||
|
||||
pub fn register_app(config: ServiceConfig) -> Result<(), OrchestratorError>
|
||||
pub fn unregister_app(app_name: &str) -> Result<(), OrchestratorError>
|
||||
pub fn list_apps() -> Vec<ManagedApp>
|
||||
if output.status.success() {
|
||||
Ok(String::from_utf8(output.stdout)?.trim().to_string())
|
||||
} else {
|
||||
// Fallbacks...
|
||||
}
|
||||
```
|
||||
|
||||
2. lifecycle.rs: Control de estados
|
||||
[ ] Crear función resolve_executable()
|
||||
Firma: fn resolve_executable(config: &ServiceConfig) -> Result<String>
|
||||
|
||||
pub fn start_app(app_name: &str) -> Result<(), OrchestratorError>
|
||||
pub fn stop_app(app_name: &str) -> Result<(), OrchestratorError>
|
||||
pub fn restart_app(app_name: &str) -> Result<(), OrchestratorError>
|
||||
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
|
||||
|
||||
3. Rate limiting: Máximo 1 operación por segundo por app (prevenir spam)
|
||||
Ejemplo:
|
||||
```rust
|
||||
if let Some(exe) = &config.custom_executable {
|
||||
return Ok(exe.clone());
|
||||
}
|
||||
|
||||
4. Recovery automático: Si estado inconsistente → intentar reconciliar
|
||||
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
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
C. API LOCAL (src/api/)
|
||||
3. ACTUALIZAR DTOs (src/api/dto.rs)
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Endpoints HTTP para el panel web local.
|
||||
[ ] Modificar RegisterAppRequest para incluir nuevos campos:
|
||||
```rust
|
||||
#[derive(Debug, Deserialize)]
|
||||
pub struct RegisterAppRequest {
|
||||
// ... campos existentes ...
|
||||
pub custom_executable: Option<String>,
|
||||
pub use_npm_start: Option<bool>,
|
||||
}
|
||||
```
|
||||
|
||||
Funcionalidades:
|
||||
|
||||
1. handlers.rs: Endpoints REST
|
||||
|
||||
POST /api/apps/:name/start
|
||||
POST /api/apps/:name/stop
|
||||
POST /api/apps/:name/restart
|
||||
GET /api/apps/:name/status
|
||||
GET /api/apps
|
||||
POST /api/apps/register // Crear nuevo servicio systemd
|
||||
DELETE /api/apps/:name // Eliminar servicio
|
||||
|
||||
2. websocket.rs: LogStreamer en tiempo real
|
||||
|
||||
pub struct LogStreamer {
|
||||
app_name: String,
|
||||
process: Child, // journalctl -u {app_name} -f --output=json
|
||||
}
|
||||
|
||||
// WS /logs/:app_name
|
||||
// - Parsear JSON de journalctl
|
||||
// - Enviar líneas vía WebSocket
|
||||
// - Manejo de backpressure
|
||||
// - Cleanup al desconectar
|
||||
// - Límite de conexiones simultáneas por app
|
||||
|
||||
3. Webhook (opcional, análisis futuro):
|
||||
|
||||
POST /webhook/command
|
||||
{
|
||||
"action": "restart",
|
||||
"app_name": "fidelizacion",
|
||||
"secret": "..."
|
||||
}
|
||||
|
||||
4. dto.rs: Schemas de validación (request/response)
|
||||
[ ] Actualizar documentación de los DTOs
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
D. EVOLUCIÓN DE monitor.rs
|
||||
4. ACTUALIZAR AppType (src/models/service_config.rs)
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Reconciliar detección automática (sysinfo) vs systemd.
|
||||
[ ] Cambiar get_executable() por get_command()
|
||||
- Retorna solo el nombre del comando ("node", "python3")
|
||||
- No retorna rutas absolutas
|
||||
|
||||
Cambios:
|
||||
[ ] 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",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
1. Doble detección:
|
||||
|
||||
for app in apps_to_monitor {
|
||||
let process_detected = detect_in_sysinfo(&app.name);
|
||||
let systemd_status = systemctl::status(&app.name);
|
||||
|
||||
let final_status = match (process_detected, systemd_status) {
|
||||
(true, ServiceStatus::Active) => "running",
|
||||
(false, ServiceStatus::Active) => "crashed", // ⚠️ Alerta
|
||||
(false, ServiceStatus::Failed) => "failed",
|
||||
(true, ServiceStatus::Inactive) => "zombie", // ⚠️ Alerta
|
||||
_ => "unknown"
|
||||
};
|
||||
|
||||
send_to_cloud(final_status);
|
||||
}
|
||||
|
||||
2. Reportar discrepancias a logs y API central
|
||||
|
||||
3. Mantener compatibilidad con detección actual (no romper funcionalidad existente)
|
||||
Después:
|
||||
```rust
|
||||
pub fn get_command(&self) -> &str {
|
||||
match self {
|
||||
AppType::NodeJs => "node",
|
||||
AppType::Python => "python3",
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
E. INTERFACE WEB (evolucionar interface.rs)
|
||||
5. TESTING
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Panel de control completo sin eliminar funcionalidad actual.
|
||||
[ ] 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
|
||||
|
||||
Nuevas features:
|
||||
[ ] Test unitario: resolve_executable()
|
||||
- Con custom_executable definido
|
||||
- Con auto-detección
|
||||
- Con errores
|
||||
|
||||
1. Página de gestión de apps:
|
||||
- Tabla con: App Name | Status | PID | CPU | RAM | Actions
|
||||
- Botones: ▶️ Start | ⏹️ Stop | 🔄 Restart | 📊 Logs | 🗑️ Delete
|
||||
- Indicador visual si falta sudo (banner amarillo)
|
||||
[ ] 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"
|
||||
}
|
||||
```
|
||||
|
||||
2. Formulario de registro de apps:
|
||||
- Campos: app_name, script_path, user, working_dir, environment vars
|
||||
- Validación client-side y server-side
|
||||
- Soporte para Node.js y Python
|
||||
Resultado esperado:
|
||||
- Servicio generado con ruta correcta de npm
|
||||
- Servicio inicia exitosamente
|
||||
- Logs muestran "Servidor activo APP IDEAS Puerto: 2000"
|
||||
|
||||
3. Visor de logs en tiempo real:
|
||||
- Conectar vía WebSocket a /logs/:app_name
|
||||
- Auto-scroll, filtros por nivel, búsqueda
|
||||
- Botón de pause/resume
|
||||
[ ] Test: Aplicación Node.js con node directo (sin npm)
|
||||
|
||||
4. Mantener páginas actuales:
|
||||
- /scan (escaneo de procesos)
|
||||
- /select (selección de procesos)
|
||||
- /logs (logs del sistema)
|
||||
[ ] Test: Aplicación Python con virtualenv
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
F. TESTING (nuevo archivo tests/integration_test.rs)
|
||||
6. LOGGING Y DEBUGGING
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Tests de integración end-to-end.
|
||||
[ ] 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}"
|
||||
|
||||
Casos de prueba:
|
||||
1. Registrar app de prueba (Node.js y Python)
|
||||
2. Start → verificar PID existe
|
||||
3. Stop → verificar PID desaparece
|
||||
4. Restart → verificar nuevo PID
|
||||
5. Leer logs vía WebSocket (primeras 10 líneas)
|
||||
6. Eliminar app → verificar limpieza completa
|
||||
7. Test de rate limiting
|
||||
8. Test de validaciones (script inexistente, user inválido)
|
||||
[ ] 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
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
G. DEPLOYMENT (desplegar_agent.sh)
|
||||
7. DOCUMENTACIÓN
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Objetivo: Script de instalación automática production-ready.
|
||||
[ ] 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
|
||||
|
||||
Funcionalidades:
|
||||
1. Verificar dependencias (systemd, sudo, rust)
|
||||
2. Compilar release
|
||||
3. Configurar sudoers si es necesario:
|
||||
[ ] 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'
|
||||
|
||||
# /etc/sudoers.d/siax-agent
|
||||
siax-agent ALL=(ALL) NOPASSWD: /bin/systemctl
|
||||
[ ] Actualizar ejemplos de curl con nuevos campos
|
||||
|
||||
4. Crear servicio systemd para el agente mismo
|
||||
5. Verificación post-deploy (health check)
|
||||
6. Rollback automático si falla
|
||||
[ ] 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
|
||||
|
||||
===============================================================================
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
🧪 VALIDACIÓN FINAL
|
||||
===============================================================================
|
||||
|
||||
✅ Panel web permite start/stop/restart desde UI
|
||||
✅ Soporte Node.js y Python (FastAPI)
|
||||
✅ Logs en tiempo real vía WebSocket
|
||||
✅ Detección de apps crasheadas (reconciliación systemd)
|
||||
✅ Validaciones de permisos, paths, users
|
||||
✅ Rate limiting funcional
|
||||
✅ Tests de integración pasando
|
||||
✅ Script de deploy funcional
|
||||
✅ Sin eliminar funcionalidad existente
|
||||
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)
|
||||
|
||||
===============================================================================
|
||||
PRÓXIMOS PASOS
|
||||
📈 PRIORIDAD DE IMPLEMENTACIÓN
|
||||
===============================================================================
|
||||
|
||||
1. Implementar src/models/ (ServiceConfig, ManagedApp, etc.)
|
||||
2. Implementar src/systemd/ (service_generator, systemctl, parser)
|
||||
3. Implementar src/orchestrator/ (app_manager, lifecycle)
|
||||
4. Implementar src/api/ (handlers, websocket, dto)
|
||||
5. Evolucionar monitor.rs (reconciliación systemd)
|
||||
6. Evolucionar interface.rs (panel de control completo)
|
||||
7. Crear tests/integration_test.rs
|
||||
8. Crear desplegar_agent.sh
|
||||
9. Actualizar Cargo.toml con nuevas dependencias
|
||||
10. Testing completo y ajustes finales
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user