Instalar Apache y publicar la web

3.1. Instala y comprueba el servicio

Necesitas tu instancia de la práctica anterior, el cliente Debian y el navegador. El grupo de seguridad todavía tiene una sola entrada: SSH desde tu IPv4 autorizada. No se crea otra instancia, ni se necesitan credenciales AWS en Amazon Linux.

En la instancia EC2, como ec2-user, comprueba el usuario y el sistema antes de instalar. Usa dnf, el gestor de paquetes de Amazon Linux, en lugar del apt de Debian:

whoami
cat /etc/os-release
sudo dnf install -y httpd

sudo eleva privilegios para esa orden y -y confirma la instalación de Apache y sus dependencias. Si falla la descarga o aparece un problema de repositorio, conserva el mensaje y comprueba salida de red o resolución con ayuda. No abras puertos de entrada para reparar una descarga, ni desactives controles del sistema.

Instalar el paquete y tener el servicio funcionando son cosas distintas. systemctl administra servicios:

sudo systemctl enable --now httpd
systemctl is-active httpd
systemctl is-enabled httpd
sudo ss -ltnp 'sport = :80'

enable --now configura el arranque automático y también inicia el servicio ahora. Busca active y enabled, respectivamente. ss muestra los sockets: -ltnp pide puertos en escucha de TCP, direcciones numéricas y procesos; el filtro limita la comprobación al puerto 80. Busca httpd escuchando en el puerto 80. Eso no implica que el grupo de seguridad deje entrar peticiones desde Internet.

Apache en Amazon Linux 2023.

3.2. Transfiere el HTML y compruébalo desde EC2

Descarga el HTML inicial de la práctica desde el navegador y, en la carpeta compartida del anfitrión, guárdalo en optativa-nube/aws-ec2/web/index.html. Crea las carpetas si faltan. Conserva el archivo en tu espacio local: EC2 no monta optativa-nube. Revisa que solo contiene información ficticia.

En Debian P00, como alumno, confirma que tienes el archivo correcto. Si sigues dentro de SSH, ejecuta exit primero. Si has abierto otra shell, prepara de nuevo las variables y verifica la IPv4 vigente.

cd /optativa-nube/aws-ec2/web
pwd
ls -l index.html
sha256sum index.html

sha256sum calcula un resumen del archivo; dos resultados iguales permiten comprobar que la transferencia conservó los bytes. Si pwd no muestra la ruta prevista o falta el archivo, detente antes de copiar.

scp -o ConnectTimeout=10 -o IdentitiesOnly=yes \
  -o StrictHostKeyChecking=yes -o HostKeyAlgorithms=ssh-ed25519 \
  -i "$CLAVE_EC2" index.html "ec2-user@$IPV4_EC2:~/index.html"

scp transfiere el HTML por SSH a la carpeta personal de ec2-user. La opción StrictHostKeyChecking=yes exige que el host ya esté verificado. El archivo todavía no está publicado. Si falla la verificación de host, vuelve a verificar la identidad antes de conectar.

En EC2, vuelve a conectar por SSH como antes. Comprueba la copia y publícala:

ls -l "$HOME/index.html"
sha256sum "$HOME/index.html"

Si el resumen coincide con el de Debian, copia el archivo a la carpeta que sirve Apache:

sudo install -m 0644 "$HOME/index.html" /var/www/html/index.html
ls -l /var/www/html/index.html
curl --noproxy '*' -fsS --max-time 5 http://127.0.0.1/

install -m 0644 copia el archivo y fija sus permisos: el propietario puede editarlo y Apache puede leerlo. Sustituirá solo el HTML anterior de la práctica si ya existe. No cambies todos los permisos de /var/www. 127.0.0.1 es la dirección de esta misma máquina (loopback). --noproxy '*' hace la prueba directa; -f informa de error ante respuestas HTTP 4xx/5xx, -sS omite el progreso sin esconder errores y --max-time limita la espera. Comprueba que el cuerpo contiene el título y el texto esperados. Si falta curl en la instancia, instala curl-minimal con sudo dnf install -y curl-minimal antes de comprobar.

3.3. Compara el acceso antes y después de permitir HTTP

En Debian P00, usa la IPv4 pública que confirmaste en el bloque de SSH. Ejecuta esta comprobación mientras el grupo de seguridad aún solo deja entrar por SSH:

curl -4 --noproxy '*' -sS --max-time 8 -o /dev/null \
  -w 'HTTP %{http_code}\n' "http://$IPV4_EC2/"

-o /dev/null descarta el cuerpo y -w muestra el código HTTP. Si no llega ninguna respuesta, suele verse un tiempo de espera y 000; 000 no es un código que haya enviado el servidor. Si ya obtienes un código HTTP, comprueba que estás consultando la instancia correcta y revisa todos sus grupos de seguridad antes de continuar.

En el navegador entra en EC2 → Grupos de seguridad, selecciona el grupo propio de tu instancia y edita sus reglas de entrada. Añade HTTP, TCP 80, origen 0.0.0.0/0. Eso hace accesible la página desde cualquier IPv4 que pueda llegar al servidor. No edites la regla SSH, no abras IPv6 ni añadas HTTPS. Limita la publicación a datos ficticios y al tiempo necesario para probarlos: HTTP no cifra el tráfico. Si Learner Lab deniega el cambio, registra el resultado y conserva la comprobación interna; no intentes eludir la restricción.

Repite en Debian la misma petición y busca ahora HTTP 200. Comprueba también el contenido desde fuera, esta vez sin descartar el cuerpo:

curl -4 --noproxy '*' -fsS --max-time 8 "http://$IPV4_EC2/"

En el navegador del anfitrión, escribe http:// seguido de la IPv4 actual que figura en la consola. Comprueba el contenido visible. Si el navegador intenta pasar a HTTPS por sus propios ajustes, vuelve a verificar con la orden de Debian. No añadas 443 para arreglarlo. Si no llega una respuesta, empieza por comprobar de nuevo la IPv4 y el puerto desde la propia instancia.

Reglas para servidores web y SSH.

3.4. Haz un cambio sin repetir toda la instalación

En el HTML local, modifica el título visible y añade un aviso ficticio. Transfiere y publica el cambio usando el procedimiento anterior. Antes de actuar, predice qué se verá cuando hayas editado el archivo en Debian pero aún no lo hayas publicado, y qué se verá después. Comprueba el título nuevo con curl y una recarga del navegador. Para un cambio de HTML estático no necesitas reiniciar Apache.

A entregar. En tu bitácora individual, compara las peticiones dentro y fuera antes y después de la regla HTTP. Incluye tu index.html actualizado y una prueba de que la instancia sirve el contenido cambiado. Anota cualquier paso bloqueado; una prueba dentro de EC2 no demuestra que el sitio sea accesible desde fuera.

Cierre. Si sigues ahora con el diagnóstico, mantén la misma instancia y revisa saldo y tiempo disponible. Si paras aquí, retira la regla temporal y aplica el cierre completo.