Saltar al contenido principal

TP 2 – Gestión de varios sitios web con un reverse proxy (proxy inverso) en un entorno Linux

Tabla de contenidos​

CONTEXTO​

Usted es administrador de sistemas en una empresa de servicios digitales. Su tarea consiste en configurar un entorno local que aloje tres instancias independientes de Wiki.js, cada una representando un entorno clásico de desarrollo de software:

  • Entorno de desarrollo (dev.site1.local)
  • Entorno de pruebas (test.site1.local)
  • Entorno de producción (prod.site1.local)

Cada instancia de Wiki.js debe instalarse manualmente en una sola máquina Ubuntu Server 24.04 LTS, conectada a su propia base de datos MariaDB y expuesta a través de un reverse proxy NGINX.

OBJETIVOS DE LA PRUEBA​

  • Dominar la instalación manual de un motor wiki basado en Node.js
  • Gestionar correctamente bases de datos SQL distintas
  • Automatizar el arranque de los servicios mediante systemd
  • Configurar un reverse proxy HTTP con subdominios internos
  • Diagnosticar errores frecuentes de despliegue
  • Aplicar las mejores prácticas en materia de aislamiento de servicios

Volver a la tabla de contenidos

INSTRUCCIONES GENERALES​

  • Usted trabaja en una sola máquina virtual Ubuntu 24.04
  • Todas las instancias deben ser independientes, sin conflictos de puertos
  • Ningún servidor debe estar expuesto directamente: solo el proxy NGINX escucha en el puerto 80
  • Las direcciones *.site1.local deben funcionar mediante /etc/hosts
  • Debe seguir un enfoque profesional, con estructura, claridad y rigor

Volver a la tabla de contenidos

PARTE 1 – INSTALACIÓN Y CONFIGURACIÓN DE WIKI.JS (40 PUNTOS)​

  1. Cree tres usuarios Linux dedicados: wikijs_dev, wikijs_test, wikijs_prod

  2. Cree tres bases de datos distintas en MariaDB:

    • wikidb_dev, wikidb_test, wikidb_prod

  3. Instale manualmente Wiki.js en:

    • /var/www/dev.site1
    • /var/www/test.site1
    • /var/www/prod.site1

  4. Modifique el archivo config.yml de cada instancia:

    • Puerto diferente (3000, 3001, 3002)
    • bindIP: 127.0.0.1
    • Información de conexión correcta a la base de datos

  5. Cree y active los servicios systemd:

    • wikijs-dev.service, wikijs-test.service, wikijs-prod.service

Volver a la tabla de contenidos

PARTE 2 – CONFIGURACIÓN DEL REVERSE PROXY NGINX (30 PUNTOS)​

  1. Configure NGINX para servir los siguientes subdominios:
Nombre de hostPuerto internoRuta local
dev.site1.local3000/var/www/dev.site1
test.site1.local3001/var/www/test.site1
prod.site1.local3002/var/www/prod.site1

  1. Modifique /etc/hosts para apuntar estos dominios a 127.0.0.1

  2. Pruebe el acceso a los sitios con un navegador o curl

Volver a la tabla de contenidos

PARTE 3 – VALIDACIÓN, SOLUCIÓN DE PROBLEMAS Y ANÁLISIS (30 PUNTOS)​

  1. Corrija los siguientes errores si aparecen:

    • Mala indentación YAML
    • Problemas de conexión a MariaDB
    • Puerto ya ocupado
    • Permisos de archivos insuficientes

  2. Justifique las siguientes decisiones:

    • ¿Por qué usar usuarios diferentes para cada Wiki.js?
    • ¿Por qué preferir un reverse proxy en lugar de la exposición directa?
    • ¿Cuáles son los riesgos de seguridad si los puertos se exponen sin NGINX?

  3. Proponga un método para asegurar la instalación con HTTPS:

    • Uso de certbot
    • Configuración de bindIP
    • Rol del DNS público

Volver a la tabla de contenidos

PARTE 4 – PREGUNTA DE ANÁLISIS ARQUITECTÓNICO (10 PUNTOS)​

Enunciado​

Existen dos enfoques posibles para exponer varios entornos:

Enfoque A: subdominios → http://dev.site1.local, http://test.site1.local, http://prod.site1.local

Enfoque B: rutas internas → http://site1.local/dev, http://site1.local/test, http://site1.local/prod

Pregunta​

  1. Compare ambos enfoques:

    a) Principales implicaciones técnicas (4 puntos) b) Casos de uso donde el enfoque B es tolerable, y cuando se desaconseja (3 puntos) c) ¿Qué enfoque recomienda y por qué? (3 puntos)

Volver a la tabla de contenidos

TABLA DE EVALUACIÓN​

CriteriosPuntos
Wiki.js (x3) instalado y funcional15
Bases de datos distintas10
Configuración config.yml correcta10
Servicios systemd funcionales5
Reverse proxy NGINX configurado15
/etc/hosts bien editado5
Diagnóstico y resolución de errores10
Justificación técnica10
Propuesta HTTPS argumentada10
Total90
Análisis de la arquitecturaPuntos
Presentación de las diferencias2
Casos de uso para cada enfoque2
Análisis de riesgos y compatibilidad2
Recomendación clara y motivada4
Subtotal10

MÓDULO BONUS 1 – Usuarios de sistema vs usuarios normales (humanos) en Linux​

Convención de UID en Linux​

En la mayoría de las distribuciones Linux modernas, los usuarios se clasifican según su UID (User ID):

Rango de UIDTipo de cuentaEjemplos
0Superusuarioroot
1 – 999Cuentas de sistema / serviciosdaemon, www-data, sshd, systemd-*, apache
≥ 1000Usuarios normales (humanos)alice, bob, etudiant
info

Este rango está definido en el archivo /etc/login.defs de su distribución. No es una regla universal, sino una convención ampliamente adoptada (Debian, Ubuntu, RHEL, Fedora, etc.).

Cómo verificar los rangos en su máquina​

# Ver los rangos de UID definidos en su distro
grep -E '^(UID_MIN|UID_MAX|SYS_UID_MIN|SYS_UID_MAX)' /etc/login.defs

Resultado típico en Ubuntu:

SYS_UID_MIN    100
SYS_UID_MAX    999
UID_MIN        1000
UID_MAX        60000

Cuentas de sistema (UID < 1000) – Características​

Las cuentas de sistema se crean para ejecutar servicios/demonios, no para conexiones humanas.

Indicadores típicos de una cuenta de sistema:

  • UID bajo (< 1000)
  • Shell = /usr/sbin/nologin o /bin/false (sin conexión interactiva)
  • Sin carpeta home real de usuario (o una home «técnica»)
  • Creada con useradd -r (flag system account)

Ejemplos comunes:

CuentaServicioUID típicoShell
rootSuperusuario0/bin/bash
www-dataApache / Nginx (Debian/Ubuntu)33/usr/sbin/nologin
apacheApache (RHEL/CentOS)48/sbin/nologin
sshdServidor SSH105/usr/sbin/nologin
mysqlMariaDB / MySQL27/bin/false

Verificación rápida:

# Ver el UID y el shell de www-data
id www-data
getent passwd www-data
# Resultado: uid=33(www-data) gid=33(www-data) groups=33(www-data)

Cuentas normales / humanas (UID ≥ 1000) – Características​

Las cuentas humanas se crean para personas que se conectan al sistema.

Indicadores típicos de una cuenta humana:

  • UID ≥ 1000
  • Shell = /bin/bash o /bin/sh
  • Carpeta home en /home/<username>
  • Creada con useradd (sin el flag -r) o adduser

Comandos útiles para listar y distinguir los tipos de usuarios​

Listar los usuarios humanos (UID ≥ 1000):

UID_MIN=$(awk '/^UID_MIN/{print $2}' /etc/login.defs)
awk -F: -v m="$UID_MIN" '$3>=m {print $1" (uid="$3")"}' /etc/passwd | sort -t'=' -k2 -n

Listar los usuarios de sistema (UID < 1000):

UID_MIN=$(awk '/^UID_MIN/{print $2}' /etc/login.defs)
awk -F: -v m="$UID_MIN" '$3<m {print $1" (uid="$3")"}' /etc/passwd | sort -t'=' -k2 -n

Listar las cuentas sin login (típicamente servicios):

awk -F: '($7 ~ /(nologin|false)$/) {print $1" -> "$7}' /etc/passwd

Listar las cuentas «probablemente humanas» (home en /home + shell bash/sh):

awk -F: '($6 ~ /^\/home\//) && ($7 ~ /(bash|sh)$/) {print $1" home="$6" shell="$7}' /etc/passwd

Relación con la práctica: ¿Por qué wikijs_dev, wikijs_test, wikijs_prod son cuentas de sistema?​

En esta práctica, los usuarios Wiki.js se han creado con el comando:

sudo useradd -r -m -s /bin/bash wikijs_dev
sudo useradd -r -m -s /bin/bash wikijs_test
sudo useradd -r -m -s /bin/bash wikijs_prod
OpciónRol
-rCrea una cuenta de sistema → UID asignado en el rango de sistema (< 1000)
-mCrea un directorio home (útil para archivos de configuración)
-s /bin/bashDefine el shell (aquí bash para facilitar el debug en la práctica)
tip

¡Es el flag -r el que marca la diferencia! Sin -r, la cuenta sería un usuario normal (UID ≥ 1000). El flag -s solo define el shell, no convierte la cuenta en «de sistema».

Estas cuentas son «service accounts»: son responsables de ejecutar los servicios Wiki.js, como se define en los archivos systemd:

[Service]
User=wikijs_dev    # ← el servicio se ejecuta bajo esta cuenta de sistema

Verificación:

# Ver el UID asignado (debería ser < 1000)
id wikijs_dev
id wikijs_test
id wikijs_prod

# Ver qué usuario ejecuta cada proceso Wiki.js
ps -eo user,pid,cmd | grep '[n]ode'

# Verificar el estado del servicio
systemctl status wikijs-dev

Recomendación en producción​

En producción, es preferible no dar un shell interactivo a las cuentas de servicio:

# Mejor práctica (shell nologin)
sudo useradd -r -m -s /usr/sbin/nologin wikijs_dev
sudo useradd -r -m -s /usr/sbin/nologin wikijs_test
sudo useradd -r -m -s /usr/sbin/nologin wikijs_prod

Con /usr/sbin/nologin, nadie puede abrir una sesión interactiva con esta cuenta, pero systemd y sudo -u wikijs_dev <comando> siguen funcionando normalmente. Es el principio de menor privilegio.

Resumen
  • useradd -r → cuenta de sistema (UID < 1000, destinada a un servicio)
  • useradd (sin -r) → cuenta humana (UID ≥ 1000, destinada a una persona)
  • -s → define el shell, no cambia el tipo de cuenta
  • Las cuentas wikijs_* de esta práctica son cuentas de sistema responsables de ejecutar el servicio Wiki.js
  • En producción: siempre usar -s /usr/sbin/nologin para las cuentas de servicio

Volver a la tabla de contenidos

Práctica creada el: Diciembre 2024