# Produccion - project.linkedcorp.net ## Estado actual - Version actual: `1.2.0` - Estado: `operativo` - Ultima validacion: `2026-09-06` ## Servidor - Host: `192.168.222.3` - SSH: `deploy@192.168.222.3 -p 2203` (llave `~/.ssh/id_ed25519`, sudo NOPASSWD) - Ruta base: `/opt/apps/project.linkedcorp.net/` ## Runtime - Frontend: `/opt/apps/project.linkedcorp.net/frontend/` (dist/ + node_modules propio con `serve`) - Backend: `/opt/apps/project.linkedcorp.net/backend/` (node_modules + `.env` de produccion) - Source (checkout de Gitea, WorkingDirectory de ambos servicios): `/opt/apps/project.linkedcorp.net/source/` - Storage: `/opt/apps/project.linkedcorp.net/storage/` (adjuntos — `STORAGE_ROOT` en `.env`) - Logs: `/opt/apps/project.linkedcorp.net/logs/` - APKs Android publicados: no aplica ## Servicios - Frontend: `project-linkedcorp-frontend` (`node node_modules/.bin/serve -s dist -l 5196`, WorkingDirectory `source/frontend`... revisar nota abajo) - Backend: `project-linkedcorp-backend` (`node src/server.js`, WorkingDirectory `source/backend`, `EnvironmentFile=backend/.env`) > Nota real: el servicio frontend corre con `WorkingDirectory=/opt/apps/project.linkedcorp.net/frontend` > (no `source/frontend`) sirviendo `frontend/dist/` con el `serve` instalado ahi mismo (node_modules > minimo, solo el paquete `serve`). El `dist/` se copia desde `source/frontend/dist` en cada deploy. ## Puertos internos - Frontend: `127.0.0.1:5196` - Backend: `127.0.0.1:4019` ## Base de datos - Host pruebas/desarrollo: `192.168.222.20` - Host produccion real: `192.168.222.32` - Base: `project_linkedcorp` - Usuario app: `project_linkedcorp` (permitido solo desde `192.168.222.3`) - Regla dura: produccion web siempre usa `192.168.222.32` - Regla dura: pruebas y desarrollo siempre usan `192.168.222.20` - Antes de cada deploy, validar el `DB_HOST` activo en runtime (`backend/.env` de produccion) ## NPM (Nginx Proxy Manager) - Dominio: `project.linkedcorp.net`, SSL Let's Encrypt (auto-renovacion), Force SSL activo. - Proxy Host (id 77) -> `192.168.222.3:5196` (frontend). - Custom Location `/api` -> `192.168.222.3:4019` (backend). ## Estado confirmado (2026-09-06) - Migraciones aplicadas (`001_initial.sql`) sobre `project_linkedcorp` en `.32`. - Catalogos base sembrados (roles, prioridades, estados de proyecto/actividad, tipos de proyecto). Sin datos de ejemplo (departamentos/usuario dev) — produccion arranca limpia. - Usuario Administrador inicial creado con `create-admin.js` (clave fuerte generada, entregada una sola vez fuera de este repo). El admin debe crear ahi mismo los demas usuarios/departamentos. - Login, dashboard y flujo proyecto->actividad verificados via curl contra `https://project.linkedcorp.net` (backend + frontend + SSL + BD produccion, todo real). - Pendiente (no bloqueante): limpiar archivos `.md` de `/opt/apps/project.linkedcorp.net/source` (paso de higiene del checklist de `DEPLOY_WEB.md`, no se ejecuto por restriccion del entorno del agente — pendiente de accion manual o autorizacion explicita). ## Actualizacion v1.1.0 (2026-09-06) — autorregistro/aprobacion/superadmin/SMTP - Migracion `002_registration_and_smtp.sql` aplicada sobre `.32`: rol `superadmin`, columnas de ciclo de vida en `users`, tabla `system_settings`. `mgonzalez@linkedcorp.net` (id=1) quedo promovido a `superadmin` automaticamente. - `ENCRYPTION_KEY` generado y agregado al `.env` de produccion (cifra la clave SMTP en BD). - Ambos servicios reconstruidos (backend con `nodemailer` nuevo, frontend recompilado) y reiniciados; PID confirmado distinto en los dos. - Verificado end-to-end contra `https://project.linkedcorp.net`: login reporta `roleCode: superadmin`, `GET /api/settings/smtp` responde `configured:false` (sin SMTP real todavia). - **Pendiente**: el superadmin debe cargar el SMTP real desde Configuracion → Correo (SMTP) cuando lo tenga. Hasta entonces, un registro/recuperacion de clave real en produccion queda logueado en `journalctl -u project-linkedcorp-backend` en vez de enviarse por correo — nadie externo puede completar el autorregistro sin que un admin le pase el enlace manualmente desde el log. ## Actualizacion v1.2.0 (2026-09-06) — cambiar clave desde la app - `PUT /api/auth/change-password` (exige clave actual) + opcion "Cambiar clave" en el menu de usuario. Redeploy sin cambios de dependencias ni de esquema; PID confirmado en ambos servicios. - Verificado en produccion via curl (rechaza clave actual incorrecta con 400; no se cambio la clave real del superadmin durante la prueba). ## Actualizacion v1.3.0 (2026-09-06) — boton de prueba en Correo (SMTP) - `POST /api/settings/smtp/test` (superadmin, rate-limited) agregado. Redeploy sin cambios de dependencias ni de esquema (`nodemailer` ya estaba desde v1.1.0); PID confirmado distinto en ambos servicios tras el restart. - Verificado en dev de punta a punta (curl + Playwright) antes del deploy: validacion 400 sin host/usuario, y un intento real contra el SMTP interno con credenciales invalidas devuelve el error real del servidor (`certificate has expired`) en vez de un mensaje generico. - En produccion se confirmo: el commit correcto quedo desplegado, ambos servicios reiniciaron limpio (`journalctl` sin errores) y `GET /api/settings/smtp` sin token responde `401` como se espera. **No se verificó el flujo autenticado completo en producción** — minar un JWT válido en el servidor para probarlo fue bloqueado por el clasificador de auto-mode (accion sensible sobre produccion) y no se intento evadirlo; tampoco se reseteo la clave del superadmin real solo para probar. Si se quiere una verificacion end-to-end en produccion, hacerlo manualmente desde el navegador con la sesion real del superadmin. - Regla nueva agregada al orquestador (`project-md-templates/SEGURIDAD-Y-CALIDAD.md`, seccion 1.6bis y checklist): toda pantalla de configuracion de un servicio externo debe tener un boton de prueba real, no solo "Guardar". ## Fix rapido (2026-09-06) — espacio colado en el host SMTP - El superadmin probó el SMTP real en producción y el boton de prueba (recien desplegado) funciono como debia: reporto `getaddrinfo ENOTFOUND mail.linkedcorp.net`. La causa real era un espacio de mas tecleado en el campo host, guardado literalmente como `"mail.linkedcorp. net"` en `system_settings` (confirmado por hexdump del valor en la BD de produccion). - Fix: `updateSmtpConfig`/`testSmtpConfig` ahora hacen `trim()` de host/usuario/remitente/destino antes de guardar o probar, para que un espacio accidental no vuelva a romper la resolucion DNS en silencio. Desplegado (solo backend, sin build de frontend ni migracion; PID confirmado). - El valor ya guardado en produccion sigue teniendo el espacio (no se corrigio a mano en la BD: el UPDATE directo sobre la BD de produccion fue bloqueado por el clasificador de auto-mode del agente, y no se intento evadirlo). **Accion pendiente del superadmin**: volver a guardar el host desde Configuracion -> Correo (SMTP) (con el fix ya desplegado, un espacio de mas ya no rompe nada) y repetir la prueba. - **Correccion (mismo dia)**: el primer fix usaba `trim()`, que solo quita espacios al borde. El espacio real estaba a MITAD del host (`"mail.linkedcorp." + " " + "net"`), asi que `trim()` no lo tocaba y el superadmin siguio viendo el mismo `ENOTFOUND` tras reintentar. Corregido para quitar CUALQUIER espacio (`replace(/\s+/g,'')`) de host/usuario/remitente/destino, no solo los de los bordes. Redesplegado (solo backend, PID confirmado, logs limpios). ## Comandos utiles ```bash sudo systemctl status project-linkedcorp-backend sudo systemctl status project-linkedcorp-frontend sudo journalctl -u project-linkedcorp-backend -n 100 --no-pager sudo journalctl -u project-linkedcorp-frontend -n 100 --no-pager ``` ## Notas - No dejar secretos en el repo (`.env` de produccion vive solo en `backend/.env` del servidor). - No reemplazar `storage/` ni `logs/` durante un deploy. - Documentar cambios de version y estado real en este archivo y en `CHANGELOG.md`.