En esta actividad vas a desplegar y configurar un servidor web con Ubuntu siguiendo tres recursos proporcionados por el profesor. El objetivo no es limitarse a copiar comandos y realizar capturas de pantalla. Deberás comprender lo que haces, comprobar que cada elemento funciona y crear una documentación técnica que permita a otra persona repetir el proceso.
El trabajo se desarrollará en tres partes consecutivas:
Montaje del servidor web con Ubuntu.
Ampliación UFW
Configuración de Apache mediante archivos .htaccess.
Cada parte amplía la anterior. Al terminar tendrás un único servidor funcional y un único documento técnico que describa todo el proyecto desde la preparación del entorno hasta las pruebas finales.
Debes seguir los tres recursos en el orden indicado. Puedes consultar otras fuentes para resolver problemas o ampliar las explicaciones, pero deberás citarlas en el apartado de referencias.
3. Objetivos de aprendizaje
Al finalizar la actividad deberás ser capaz de:
Preparar un sistema Ubuntu para funcionar como servidor.
Instalar, configurar y comprobar los servicios solicitados.
Identificar la función de los principales archivos, directorios, módulos, usuarios, permisos y puertos utilizados.
Aplicar configuraciones de Apache y comprobar sus efectos.
Interpretar los resultados de comandos de diagnóstico.
Detectar errores frecuentes y documentar su solución.
Valorar los riesgos de seguridad de una configuración.
Redactar documentación técnica clara y reproducible utilizando Markdown.
Organizar evidencias sin convertir el documento en una sucesión de capturas.
Preparar el proyecto para publicarlo posteriormente en un repositorio Git.
4. Resultado que debes conseguir
Debes disponer de un servidor Ubuntu desde el que se puedan demostrar las configuraciones solicitadas en las tres partes. Además, entregarás una documentación técnica completa en un archivo llamado exactamente:
README.md
La extensión correcta es .md, no .me. El archivo se escribirá con sintaxis Markdown.
La documentación debe ser una ampliación razonada de los materiales. Esto significa que no debes copiar literalmente las explicaciones del profesor. Tienes que describir el proceso con tus propias palabras, explicar qué hace cada elemento importante y aportar pruebas de funcionamiento.
5. Modalidad de realización
La actividad será individual, salvo que el profesor indique expresamente otra modalidad.
Cada estudiante deberá utilizar su propia máquina virtual o servidor asignado.
No se compartirán archivos README.md, capturas ni textos entre compañeros.
Sí se permite ayudar a localizar un error, siempre que cada estudiante comprenda y documente su propia solución.
6. Preparación antes de comenzar
Antes de modificar el servidor, anota en tu documentación:
Sistema de virtualización o equipo empleado.
Versión de Ubuntu.
Nombre de host.
Dirección IP del servidor.
Tipo de red de la máquina virtual: NAT, puente, red interna u otra.
Recursos asignados: CPU, memoria RAM y disco.
Dirección IP o nombre del equipo cliente desde el que realizarás las pruebas.
Incluye una tabla similar a esta, completada con tus datos reales:
Elemento
Configuración utilizada
Sistema operativo
Ubuntu Server …
Nombre del servidor
…
Dirección IP
…
CPU y RAM
…
Disco
…
Tipo de red
…
Equipo cliente
…
Recomendación previa
Si trabajas con una máquina virtual, crea una instantánea antes de comenzar cada parte. Así podrás volver al estado anterior si una configuración deja el servidor inaccesible. Anota en el README.md cuándo has creado esas instantáneas.
Protección de datos
No incluyas en la entrega:
Contraseñas reales.
Claves privadas.
Tokens o credenciales.
Cookies o sesiones del Campus Virtual.
Direcciones públicas o datos personales que no sean necesarios.
Oculta estos datos en las capturas. Utiliza valores de ejemplo cuando expliques credenciales.
7. Parte 1: montaje del servidor web con Ubuntu
Sigue el recurso de la parte 1 y documenta el proceso. Tu explicación deberá incluir, como mínimo, los siguientes bloques cuando aparezcan en el procedimiento realizado:
7.1 Preparación del sistema
Documenta la actualización del sistema y cualquier paquete previo necesario.
Para cada comando importante:
Escríbelo en un bloque de código.
Explica qué hace.
Describe las opciones o parámetros utilizados.
Indica el resultado esperado.
Añade una comprobación objetiva.
Ejemplo del nivel de explicación esperado:
sudo systemctl status apache2
Este comando consulta el estado del servicio Apache. En la salida se debe comprobar que aparece como activo y en ejecución. No es suficiente con escribir «funciona»: hay que indicar qué dato de la salida permite afirmarlo.
7.2 Instalación y prueba de Apache
Debes explicar:
Qué es Apache y qué función cumple en el proyecto.
Qué paquete se instala.
Cómo se inicia, detiene, reinicia y consulta el servicio.
Qué directorio contiene inicialmente el sitio web.
Qué puerto utiliza HTTP.
Cómo accedes desde el equipo cliente.
Cómo compruebas el servicio desde terminal y desde navegador.
Incluye una página web propia de prueba. No entregues únicamente la página predeterminada de Apache. La página debe mostrar, al menos, tu nombre, el título del proyecto y una indicación de que el servidor está operativo.
7.3 Acceso remoto y transferencia de archivos
Documenta los métodos de acceso o transferencia indicados en el recurso. Explica:
Qué servicio o programa interviene.
Qué puerto utiliza.
Qué usuario empleas y a qué directorio puede acceder.
Qué permisos has configurado.
Cómo has transferido o editado un archivo del sitio.
Cómo has verificado que el cambio aparece en el navegador.
Si se utiliza FTP, añade una breve valoración de seguridad: diferencia entre FTP sin cifrar y alternativas como SFTP. No publiques credenciales reales.
7.4 PHP
Si el procedimiento incluye PHP, documenta:
Paquetes instalados y función de cada uno.
Versión instalada.
Integración con Apache.
Creación y ejecución de una página PHP de prueba.
Diferencia entre ejecutar PHP desde el servidor web y desde la terminal.
Si utilizas una página con phpinfo(), elimínala o restríngele el acceso al finalizar, ya que puede mostrar información sensible del servidor. Explica esta decisión en el documento.
7.5 Acceso mediante SSH o Visual Studio Code
Si realizas este apartado, incluye:
Herramientas empleadas.
Configuración de la conexión sin mostrar contraseñas o claves privadas.
Directorio remoto abierto.
Prueba de edición de un archivo.
Evidencia del resultado servido por Apache.
7.6 Comprobación de la parte 1
Antes de continuar, verifica al menos:
El servidor responde a través de la red.
Apache está activo.
La página propia se carga desde el cliente.
Los archivos se encuentran en el directorio correcto.
PHP funciona, si forma parte del procedimiento.
El acceso remoto o la transferencia funciona, si se ha configurado.
Incluye una tabla de pruebas:
Prueba
Comando o acción
Resultado esperado
Resultado obtenido
Estado
Estado de Apache
systemctl status apache2
Servicio activo
…
Superada/No superada
Acceso web
Abrir http://IP_SERVIDOR
Carga la web propia
…
…
Prueba de PHP
Abrir la URL de prueba
PHP genera la respuesta
…
…
8. Parte 2: ampliación del Campus Virtual
Accede al recurso de la parte 2 con tu cuenta del Campus Virtual y realiza todos los pasos en el orden indicado.
Como este bloque amplía el servidor de la parte 1, comienza explicando:
Qué nueva necesidad resuelve.
Qué servicio, componente o configuración añade.
Qué requisitos de la parte 1 necesita.
Qué cambios producirá en el servidor.
Documentación obligatoria de cada paso
Para cada acción relevante de la guía del campus incluye:
Objetivo del paso. Qué se pretende conseguir.
Comando o configuración. Escrito con el lenguaje correcto en un bloque de código.
Explicación. Qué hace y por qué es necesario.
Archivo afectado. Ruta completa y fragmento modificado, si corresponde.
Comprobación. Comando, petición, acceso desde navegador o prueba equivalente.
Resultado. Qué ocurrió realmente en tu servidor.
Incidencia. Error encontrado y solución aplicada, si la hubo.
No copies el texto completo del Campus Virtual. Reescribe el procedimiento con tus propias palabras y conserva únicamente los comandos, rutas y fragmentos de configuración necesarios.
Comprobación de la parte 2
Crea una tabla con todas las pruebas solicitadas por la guía. Debe quedar claro qué evidencia demuestra que la ampliación funciona y cómo podría repetirla otra persona.
9. Parte 3: configuración de .htaccess en Apache
Realiza la práctica de la parte 3 sobre el servidor ya configurado. Antes de empezar, crea una copia de seguridad de los archivos que vayas a modificar y documenta cómo podrías restaurarlos.
9.1 Activación de .htaccess
Explica:
Qué es un archivo .htaccess.
En qué directorios puede actuar.
Qué función cumple la directiva AllowOverride.
Qué diferencia existe entre AllowOverride None y AllowOverride All.
Qué archivo de Apache has modificado.
Cómo has validado la configuración antes de reiniciar o recargar el servicio.
Cómo has comprobado que Apache continúa funcionando.
9.2 Autenticación básica
Configura una zona restringida y documenta:
Directorio protegido.
Creación del archivo de usuarios.
Directivas de autenticación utilizadas.
Prueba sin autenticar, con credenciales incorrectas y con credenciales correctas.
Código de estado HTTP o comportamiento observado en cada caso.
No muestres la contraseña. Investiga y explica por qué la autenticación básica debería utilizarse junto con HTTPS y por qué es preferible guardar .htpasswd fuera del directorio público cuando sea posible.
9.3 Páginas de error personalizadas
Crea páginas propias para los errores solicitados, por ejemplo 403 y 404. Las páginas deberán tener un diseño mínimo coherente con tu sitio.
Comprueba cada error provocándolo de forma controlada e indica:
URL o acción de prueba.
Código esperado.
Código recibido.
Página mostrada.
9.4 Cabeceras de seguridad
Aplica las cabeceras propuestas en la práctica y crea una tabla como esta:
Cabecera
Valor aplicado
Riesgo que ayuda a reducir
Método de comprobación
X-Frame-Options
…
…
…
X-Content-Type-Options
…
…
…
Referrer-Policy
…
…
…
Permissions-Policy
…
…
…
Comprueba las cabeceras con las herramientas de desarrollo del navegador o con una petición de terminal, no solo mediante una captura del archivo de configuración.
Si el recurso incluye una cabecera considerada antigua o desaconsejada por navegadores actuales, indícalo en tu análisis y explica qué mecanismo moderno se utiliza en su lugar. Esta observación deberá estar respaldada por una fuente técnica.
9.5 Redirecciones
Configura y prueba las redirecciones solicitadas. Explica la diferencia entre una redirección permanente y una temporal, incluyendo:
Código de estado.
Efecto para el navegador.
Posible efecto en caché.
Uso habitual.
Implicaciones generales para buscadores.
Incluye una prueba donde se puedan observar la respuesta y el destino final.
9.6 Reescritura de URLs
Si la guía utiliza mod_rewrite, explica:
Qué problema resuelve.
Diferencia entre redirección y reescritura interna.
Módulo necesario.
Significado de la regla aplicada.
URL escrita por el usuario y recurso procesado realmente.
Debes demostrar el funcionamiento con al menos un ejemplo propio diferente del ejemplo literal de la guía.
9.7 Resto de configuraciones del recurso
Completa también las configuraciones adicionales incluidas en la guía, como control de indexación, protección u ocultación de recursos, caché o compresión, cuando aparezcan en el procedimiento. Para cada una explica el objetivo, la configuración aplicada, la prueba realizada y su resultado.
9.8 Comprobación de la parte 3
Prepara una tabla final de pruebas que incluya, como mínimo:
Acceso a la zona restringida.
Error 403.
Error 404.
Cabeceras de seguridad.
Redirección temporal.
Redirección permanente.
Reescritura de URL.
Resto de funcionalidades realizadas.
10. Ampliaciones técnicas obligatorias
Tu trabajo no debe ser una reproducción literal de los enlaces. Añade las siguientes ampliaciones:
Ampliación A: mapa del sistema
Incluye un diagrama Mermaid que muestre, al menos, el equipo cliente, el servidor Ubuntu, Apache y los componentes principales instalados. Ejemplo de sintaxis:
flowchart LR
A[Cliente] -->|HTTP| B[Apache en Ubuntu]
B --> C[Sitio web]
B --> D[PHP]
Adapta el diagrama a tu instalación real. No copies el ejemplo sin modificarlo.
Ampliación B: relación de puertos y servicios
Incluye una tabla con los servicios utilizados, sus puertos, protocolo de transporte, finalidad y estado final. Si un puerto no debe quedar accesible, explícalo.
Ampliación C: seguridad
Identifica al menos cinco riesgos o decisiones de seguridad observados durante las tres partes. Para cada uno indica:
Riesgo.
Configuración relacionada.
Consecuencia posible.
Medida de mejora.
Prioridad: baja, media o alta.
Ampliación D: diagnóstico
Incluye una pequeña guía de resolución de problemas con un mínimo de cinco incidencias. Pueden ser errores que hayas encontrado o errores razonables que hayas reproducido de forma segura.
Síntoma
Posible causa
Comprobación
Solución
Apache no arranca
Error de sintaxis
…
…
La web no responde desde el cliente
…
…
…
Ampliación E: comandos de comprobación
Crea una sección de consulta rápida con los comandos que permitan comprobar el estado del servidor. No basta con enumerarlos: añade una frase que explique qué verifica cada uno.
11. Estructura obligatoria del README.md
El documento deberá contener, como mínimo, esta estructura:
# Despliegue y ampliación de un servidor web con Ubuntu
## 1. Autor y datos de la práctica
## 2. Resumen del proyecto
## 3. Objetivos
## 4. Entorno y requisitos
## 5. Esquema de la infraestructura
## 6. Parte 1: montaje del servidor web
## 7. Parte 2: ampliación del Campus Virtual
## 8. Parte 3: configuración de .htaccess
## 9. Pruebas finales
## 10. Problemas encontrados y soluciones
## 11. Análisis de seguridad
## 12. Conclusiones
## 13. Referencias
Puedes añadir subsecciones, pero no eliminar las anteriores.
12. Requisitos de formato Markdown
En el README.md deberás utilizar correctamente:
Títulos y subtítulos con #, ## y ###.
Párrafos breves y explicativos.
Listas numeradas y no numeradas.
Tablas.
Enlaces con texto descriptivo.
Imágenes con texto alternativo.
Bloques de código indicando el lenguaje: bash, apache, html, php, etc.
Código corto entre comillas invertidas.
Avisos o notas mediante citas >.
Al menos un diagrama Mermaid.
Índice con enlaces internos si el documento es largo.
No utilices capturas para mostrar texto que puede copiarse, como comandos o configuraciones. Escríbelo en bloques de código y reserva las imágenes para demostrar resultados visuales relevantes.
13. Capturas y evidencias
Guarda las imágenes en una carpeta llamada img y utiliza nombres descriptivos:
Los archivos de configuración se entregarán como copia para su revisión. Si un archivo debe llamarse .htaccess en el servidor, puedes conservar ese nombre dentro de la entrega o añadir una copia legible como htaccess.txt. Nunca incluyas archivos de contraseñas reales como .htpasswd.
15. Entrega actual mediante ZIP
Como todavía no hemos trabajado Git, en esta primera entrega comprime la carpeta completa en un archivo ZIP con este nombre:
apellido-nombre-servidor-web.zip
Antes de subirlo, descomprímelo en una carpeta temporal y comprueba que:
Existe README.md en la raíz.
El documento se abre correctamente.
Las imágenes se muestran usando rutas relativas.
Se incluyen los archivos web y las configuraciones necesarias.
No hay contraseñas ni datos sensibles.
No se incluyen discos virtuales, imágenes ISO, copias completas de la máquina virtual ni carpetas innecesarias.
Sube el ZIP al espacio de entrega indicado por el profesor.
16. Publicación posterior en Git
La entrega mediante ZIP es provisional. Cuando estudiemos Git y GitHub, deberás publicar esta misma actividad en un repositorio.
Por este motivo, organiza desde ahora el trabajo como si ya fuera un repositorio:
Un único README.md principal en la raíz.
Carpetas con nombres simples, sin espacios ni tildes.
Rutas relativas para imágenes y enlaces internos.
Archivos ordenados y con nombres descriptivos.
Ninguna contraseña o credencial guardada.
Un archivo .gitignore cuando aprendamos Git, si el proyecto lo necesita.
Más adelante se valorará la evolución del documento mediante commits. No será válido crear el repositorio al final y subir todo sin mostrar el proceso de mejora cuando se explique esa parte de la asignatura.
17. Defensa y comprobación por parte del profesor
El profesor podrá solicitar que el estudiante:
Explique cualquier comando incluido.
Localice un archivo de configuración.
Reinicie o recargue un servicio.
Demuestre una de las pruebas.
Modifique una regla sencilla.
Interprete un error.
Justifique una decisión de seguridad.
Una configuración que funciona pero que el estudiante no puede explicar se considerará incompleta.
18. Criterios de evaluación
Criterio
Peso
Parte 1: instalación, configuración y pruebas
20 %
Parte 2: realización, explicación y pruebas
15 %
Parte 3: .htaccess, seguridad y pruebas
25 %
Ampliaciones técnicas y capacidad de análisis
15 %
Calidad del README.md y uso de Markdown
15 %
Organización, evidencias, referencias y entrega
10 %
Total
100 %
Para obtener una valoración alta
El documento debe permitir reproducir el proyecto, explicar el propósito de las configuraciones, incluir pruebas objetivas, analizar riesgos y mostrar capacidad para resolver problemas.
Penalizaciones importantes
Podrán reducir la calificación:
Copiar y pegar los recursos sin elaborar explicaciones propias.
Incluir comandos que no se han ejecutado o resultados inventados.
Presentar capturas sin explicación.
No demostrar el funcionamiento de una parte.
Utilizar rutas absolutas locales para las imágenes del README.md.
Entregar enlaces o imágenes rotos.
Exponer contraseñas o credenciales.
No respetar la estructura de la entrega.
La ausencia de una de las tres partes impedirá considerar el proyecto completo.
19. Lista de comprobación final del estudiante
Antes de entregar, confirma cada punto:
He completado las tres partes.
Mi archivo principal se llama README.md.
He escrito las explicaciones con mis propias palabras.
Puedo explicar todos los comandos que aparecen.
He indicado mi entorno y configuración de red.
He incluido un diagrama Mermaid adaptado a mi instalación.
He realizado y documentado pruebas objetivas.
He añadido las ampliaciones técnicas obligatorias.
He documentado al menos cinco problemas o casos de diagnóstico.
He analizado al menos cinco aspectos de seguridad.
Las imágenes tienen nombres descriptivos y rutas relativas.
No he incluido contraseñas, claves ni datos sensibles.
Las referencias utilizadas aparecen citadas.
He comprobado el ZIP después de descomprimirlo.
La estructura está preparada para convertirla posteriormente en un repositorio Git.
20. Idea clave de la actividad
El resultado no es solo un servidor que funciona. El verdadero producto de este proyecto es una documentación técnica que demuestre qué has construido, por qué lo has configurado así, cómo sabes que funciona y cómo podría mantenerlo o reproducirlo otra pe
