Ejercicios y práctica · Despliegue de Aplicaciones Web · DAW

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• Confundir servidor web con servidor de aplicaciones: La causa es que ambos manejan peticiones HTTP. La corrección es entender que el servidor web se enfoca en contenido estático y proxy, mientras que el servidor de aplicaciones ejecuta lógica de negocio dinámica.
• Errores de sintaxis en ficheros de configuración: Causa por un carácter mal colocado o directiva incorrecta. Corrección usando `apachectl configtest` o `nginx -t` antes de reiniciar.
• Problemas de firewall: Causa por no abrir los puertos 80/443. Corrección configurando UFW o iptables para permitir el tráfico.
• Problemas de permisos: Causa por el usuario del servicio sin permisos de lectura/escritura. Corrección asignando permisos adecuados con `chown` y `chmod`.
• Falta de dependencias o drivers: Causa por no incluir librerías necesarias (ej. JDBC drivers) en el classpath. Corrección copiando los archivos JAR/librerías al directorio correcto y reiniciando el servicio.
• Archivos estáticos no accesibles: Causa por configuración incorrecta del servidor web o permisos. Corrección verificando `DocumentRoot` o `location` y permisos.
• Documentación incompleta o desactualizada: Causa por falta de tiempo o cambios no registrados. Corrección integrando la documentación en el proceso de despliegue y usando versionado.
• **Permisos de archivos incorrectos:** Causa: Asignar permisos excesivos (777) por desconocimiento o insuficientes (solo lectura para el usuario del servidor en directorios de escritura). Corrección: Aplicar el principio de mínimo privilegio; el usuario del servidor web solo necesita leer archivos estáticos y escribir en directorios específicos (cache, uploads) con permisos como 755 para directorios y 644 para archivos.
• **DocumentRoot mal configurado:** Causa: Apuntar el DocumentRoot a la raíz del proyecto en lugar del directorio público de la aplicación. Corrección: Identificar el directorio que contiene el `index.php` o `index.html` principal de la aplicación y configurarlo como DocumentRoot para evitar la exposición de archivos sensibles.
• **Conflictos de ServerName:** Causa: Dos o más Virtual Hosts comparten el mismo ServerName o ServerAlias en el mismo puerto. Corrección: Asegurar que cada Virtual Host basado en nombre tenga un ServerName único y que el DNS apunte correctamente a la IP del servidor.
• **Módulo no activado:** Causa: Intentar usar directivas de un módulo (ej. RewriteRule) sin haber cargado el módulo (`LoadModule`) previamente. Corrección: Verificar la activación del módulo y reiniciar el servidor.
• **Credenciales en texto plano:** Causa: Usar autenticación básica sin HTTPS, exponiendo nombres de usuario y contraseñas a la interceptación. Corrección: Siempre usar autenticación básica junto con HTTPS para cifrar la comunicación.
• **Permisos laxos en .htaccess:** Causa: Permitir `AllowOverride All` en el Virtual Host principal, lo que permite a los usuarios sobrescribir directivas de seguridad en sus propios `.htaccess`. Corrección: Limitar `AllowOverride` a `AuthConfig` o `Limit` según sea necesario, o deshabilitarlo completamente si no se necesita.
• **Certificado caducado:** Causa: Olvidar la renovación periódica de los certificados SSL/TLS. Corrección: Implementar la renovación automática (ej. con Certbot y cron) y monitorizar las fechas de caducidad.
• **Mixed Content:** Causa: Servir una página HTTPS que carga recursos (imágenes, scripts, CSS) a través de HTTP. Corrección: Asegurarse de que todos los recursos se cargan vía HTTPS, actualizando las URLs en el código de la aplicación o usando cabeceras como `Content-Security-Policy`.
• **Ignorar los logs del servidor:** Causa: No revisar periódicamente los logs de acceso y error, lo que impide detectar problemas de funcionamiento, errores de configuración o intentos de ataque. Corrección: Establecer rutinas de revisión de logs y configurar herramientas de monitorización y alerta.
• **Documentación desactualizada:** Causa: No mantener la documentación al día con los cambios en la configuración del servidor. Corrección: Integrar la actualización de la documentación como parte de cualquier cambio o mantenimiento del servidor.
• Modificar los archivos de configuración de la aplicación directamente en el directorio de despliegue del servidor (dentro del WAR/EAR ya expandido). Causa: los cambios se sobrescriben en cada redeploy porque el servidor reemplaza el contenido con el paquete original. Corrección: realizar los cambios en el WAR/EAR original antes de desplegarlo, o en los archivos de configuración globales del servidor si el cambio afecta a todas las aplicaciones.