1. Glances — El “panel de control” más completo dentro de la terminal

Instalas, entras por SSH y pam, un dashboard con CPU, RAM, red, procesos, temperaturas… todo dinámico.

Instalación:

sudo apt install glances
glances

Sirve incluso como “panel web” si lo lanzas en modo servidor:

glances -w

Luego entras desde navegador:
http://IP:61208

2. Ytop / Bpytop / Btop — Interfaces brutales

Son dashboards animados con gráficas alucinantes.

Instalación:

sudo apt install btop
btop

Experiencia pura de “panel local pero en SSH”.

3. Ncdu — Panel visual para navegar disco

Ver qué ocupa espacio, borrar, entrar en carpetas… todo navegable.

sudo apt install ncdu
ncdu /

4. Lazydocker — Un Portainer en la terminal

Si tienes Docker, este es tu panel completo: ver contenedores, logs, stats, reiniciar, eliminar…

Instalación:

curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash
lazydocker


source ~/.profile

lazydocker

5. Cockpit (si ya quieres panel web pero gestionado desde SSH)

No es TUI, pero sí un panel web completísimo que se instala por SSH en 30 segundos.

sudo apt install cockpit
sudo systemctl enable --now cockpit

Luego entras:
https://IP:9090

6. Nmon — Monitor clásico pero potente

sudo apt install nmon
nmon

Interfaz retro, pero muy útil para rendimiento.

EL PANEL “ECORP CONTROL NODE” – estilo Mr. Robot

Formato TUI, aparece automáticamente al iniciar sesión SSH.

1. ASCII ART del servidor (para la entrada dramática)

Pon esto en:
/etc/motd (o lo generamos desde el script).

     __  ____                ____        _           __ 
    /  |/  (_)___ ____ _    / __ \____  (_)___  ____/ /_
   / /|_/ / / __ `/ _ `/   / /_/ / __ \/ / __ \/ __  / /
  / /  / / / /_/ /  __/   / ____/ /_/ / / / / / /_/ / / 
 /_/  /_/_/\__, /\___/   /_/    \____/_/_/ /_/\__,_/_/  
          /____/             C Y B E R  N O D E           

2. Script principal del panel (dashboard)

Guárdalo en:
/usr/local/bin/panel-mrrobot

Dale permisos:
sudo chmod +x /usr/local/bin/panel-mrrobot

Contenido:

#!/bin/bash

# =============== ASCII HEADER ===============
clear
echo "
  ███╗   ███╗██████╗     ██████╗  ██████╗ ██████╗ ██╗   ██╗
  ████╗ ████║██╔══██╗    ██╔══██╗██╔═══██╗██╔══██╗╚██╗ ██╔╝
  ██╔████╔██║██████╔╝    ██║  ██║██║   ██║██████╔╝ ╚████╔╝ 
  ██║╚██╔╝██║██╔══██╗    ██║  ██║██║   ██║██╔═══╝   ╚██╔╝  
  ██║ ╚═╝ ██║██║  ██║    ██████╔╝╚██████╔╝██║        ██║   
  ╚═╝     ╚═╝╚═╝  ╚═╝    ╚═════╝  ╚═════╝ ╚═╝        ╚═╝    
"
echo "                  PANEL PRIVADO - MODO MR.ROBOT"
echo "--------------------------------------------------------------------------------"
echo

# =============== MENU ===============
while true; do
  echo "Selecciona una opción:"
  echo "1) Monitor del sistema (btop)"
  echo "2) Dashboard avanzado (glances)"
  echo "3) Uso de disco (ncdu)"
  echo "4) Control Docker (lazydocker)"
  echo "5) Logs en vivo (journalctl -f)"
  echo "6) Escaneo rápido de puertos (nmap localhost)"
  echo "7) Conexiones activas (ss -tunap)"
  echo "8) Salir"
  echo
  read -p "Elige (1-8): " opcion

  case $opcion in
    1) btop ;;
    2) glances ;;
    3) sudo ncdu / ;;
    4) lazydocker ;;
    5) sudo journalctl -f ;;
    6) sudo nmap localhost ;;
    7) ss -tunap ;;
    8) exit 0 ;;
    *) echo "Opción inválida. Intenta otra vez." ;;
  esac
done

3. Hacer que el panel aparezca AUTOMÁTICAMENTE al entrar por SSH

Edita tu .bashrc del usuario:

nano ~/.bashrc

Añade al final:

# Lanzar panel automáticamente en sesión SSH interactiva
if [ -n "$SSH_CONNECTION" ]; then
    /usr/local/bin/panel-mrrobot
fi

Guarda, cierra y reconecta por SSH.

Cuando entres, verás:

• ASCII art potente
• Menú visual
• Acceso rápido a monitorización
• Logs en vivo
• Herramientas estilo hacker

Una consola viva.

En el servidor (Ubuntu Server)

Comprueba que SSH está activo:

sudo systemctl status ssh

Si no estuviera activo:

sudo systemctl enable --now ssh

Averigua la IP del servidor:

ip a

Quédate con algo como 192.168.1.50.

En el cliente

• Si el alumno está en Linux/macOS: ya tiene ssh.
• Si está en Windows: puede usar PowerShell (trae ssh) o Windows Terminal.

1) Primera conexión “normal” (para ver que funciona)

En el cliente, conecta:

ssh usuario@192.168.1.50

Ejemplo:

ssh alumno@192.168.1.50

La primera vez saldrá el aviso de huella:

• Are you sure you want to continue connecting (yes/no/[fingerprint])?

Escribe:

yes

Mete la contraseña del usuario.

✅ Resultado esperado: entras y ves el prompt del servidor.

2) Crear usuario “de trabajo” y evitar usar root

En el servidor, crea un usuario nuevo (si no existe):

sudo adduser operario

Dale permisos de administración (sudo):

sudo usermod -aG sudo operario

Prueba desde el cliente entrar con ese usuario:

ssh operario@192.168.1.50

✅ Objetivo: que el alumno use siempre un usuario normal + sudo, no root.

3) Generar claves SSH (cliente) y copiarlas (servidor)

3.1 Generar clave en el CLIENTE

En el cliente:

ssh-keygen -t ed25519 -C "operario@lab"

Cuando pregunte dónde guardarla, ENTER.
Cuando pregunte passphrase, pon una (recomendado). Ejemplo: ClaveMuySecreta123!

Esto crea:

• ~/.ssh/id_ed25519 (privada, NO se comparte)
• ~/.ssh/id_ed25519.pub (pública, sí se comparte)

3.2 Copiar clave pública al SERVIDOR

Desde el cliente:

ssh-copy-id operario@192.168.1.50

Luego prueba entrar sin contraseña (solo con passphrase si la pusiste):

ssh operario@192.168.1.50

✅ Resultado esperado: ya no te pide la contraseña del usuario (solo la passphrase de la clave si existe).

4) Endurecer SSH: desactivar root y contraseñas

Ahora viene lo serio: si alguien intenta fuerza bruta, no hay contraseña que adivinar.

En el servidor, edita configuración:

sudo nano /etc/ssh/sshd_config

Busca (o añade) estas líneas:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Opcional (muy recomendable): restringir a un usuario concreto:

AllowUsers operario

Guarda y reinicia SSH:

sudo systemctl restart ssh

Prueba crítica (NO saltársela)

1. Mantén una sesión SSH abierta por si la lías (salvavidas).
2. Abre otra terminal nueva e intenta entrar:

ssh operario@192.168.1.50

✅ Debe entrar con clave.
❌ Si pide contraseña y ya la desactivaste, es que la clave no está bien instalada.

5) Cambiar el puerto SSH (reduce ruido automático)

Esto no es “seguridad mágica”, pero quita miles de bots tontos.

En el servidor:

sudo nano /etc/ssh/sshd_config

Cambia o añade:

Port 2222

Reinicia:

sudo systemctl restart ssh

Ahora para entrar desde cliente:

ssh -p 2222 operario@192.168.1.50

6) Activar firewall UFW y permitir solo SSH

En el servidor:

sudo ufw allow 2222/tcp
sudo ufw enable
sudo ufw status verbose

✅ Debe verse permitido el puerto 2222/tcp.

7) Verificación y “pruebas de ataque” controladas

7.1 Ver qué está escuchando

Servidor:

ss -tulpn | grep ssh

Debería verse :2222.

7.2 Probar que root NO entra

Cliente:

ssh -p 2222 root@192.168.1.50

✅ Debe fallar.

7.3 Probar que contraseña NO sirve

Cliente (forzando password):

ssh -p 2222 -o PreferredAuthentications=password -o PubkeyAuthentication=no operario@192.168.1.50

✅ Debe fallar.

8) Extras opcionales de seguridad (si te da tiempo)

A) Desactivar acceso por usuario/contraseña en el propio sistema (no solo SSH)

No siempre interesa en clase, pero es un plus.

B) Fail2ban (bloquea IPs tras intentos)

Instalar:

sudo apt update
sudo apt install fail2ban -y

Comprobar:

sudo systemctl status fail2ban

Esto es “el portero del garito”: si alguien insiste, lo echa.

1) Activar SSL/TLS en Apache

Apache en Ubuntu usa módulos. Para HTTPS necesitas ssl.

sudo a2enmod ssl
sudo systemctl restart apache2

Comprueba que el módulo está activo:

apache2ctl -M | grep ssl

2) Crear un certificado autofirmado (OpenSSL)

Vamos a crear:

• clave privada (key)
• certificado (crt)

2.1 Crear carpeta para certificados (ordenadito)

sudo mkdir -p /etc/apache2/ssl
sudo chmod 700 /etc/apache2/ssl

2.2 Generar clave + certificado (válido 365 días)

Cambia TU_SERVIDOR por un nombre identificable (ej: asir-01, web-lab, o el FQDN si tenéis DNS).

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/apache2/ssl/TU_SERVIDOR.key \
  -out /etc/apache2/ssl/TU_SERVIDOR.crt

Cuando pregunte por campos, lo importante es:

• Common Name (CN): poned el nombre o la IP con la que vais a acceder.
  • Si accederéis por IP: poned la IP (ej 192.168.1.50)
  • Si accederéis por nombre: poned ese nombre (ej asir-01.local)

Verifica que existen:

sudo ls -l /etc/apache2/ssl/

3) Crear un VirtualHost HTTPS (443)

Apache en Ubuntu suele tener el sitio por defecto en /etc/apache2/sites-available/000-default.conf.

Vamos a crear uno nuevo: https-lab.conf.

3.1 Crear el archivo del sitio HTTPS

sudo nano /etc/apache2/sites-available/https-lab.conf

Pega esto (cambia TU_SERVIDOR y, si quieres, el ServerName):

<VirtualHost *:443>
    ServerName TU_SERVIDOR
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/TU_SERVIDOR.crt
    SSLCertificateKeyFile /etc/apache2/ssl/TU_SERVIDOR.key

    ErrorLog ${APACHE_LOG_DIR}/https_error.log
    CustomLog ${APACHE_LOG_DIR}/https_access.log combined
</VirtualHost>

Guarda y sal.

3.2 Habilitar el sitio y comprobar sintaxis

sudo a2ensite https-lab.conf
sudo apache2ctl configtest

Si sale Syntax OK, reinicia:

sudo systemctl reload apache2

4) Comprobar que HTTPS funciona

4.1 Ver que Apache escucha en 443

sudo ss -lntp | grep ':443'

4.2 Probar con curl (ignorando el aviso del certificado)

Sustituye por la IP o nombre real:

curl -kI https://192.168.1.50/

Deberías ver algo como:

• HTTP/1.1 200 OK (o 301/302 si rediriges)
• cabeceras de Apache

4.3 Probar desde navegador

Entrad a:

• https://IP_DEL_SERVIDOR/

Saldrá aviso de seguridad (normal con autofirmados). La idea pedagógica: el cifrado funciona, pero el navegador no “confía” en la identidad.

5) (Opcional) Redirigir HTTP (80) a HTTPS (443)

Esto hace que todo lo que llegue por http:// vaya a https://.

5.1 Activar módulo rewrite

sudo a2enmod rewrite
sudo systemctl reload apache2

5.2 Editar el VirtualHost de puerto 80

Edita el sitio por defecto (o el que uséis en 80):

sudo nano /etc/apache2/sites-available/000-default.conf

Dentro del <VirtualHost *:80>, añade esto antes del cierre </VirtualHost>:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Comprueba y recarga:

sudo apache2ctl configtest
sudo systemctl reload apache2

Prueba:

curl -I http://192.168.1.50/

Debería devolver 301 Moved Permanently apuntando a https://....

6) (Opcional) Endurecer un poco HTTPS (sin volverse loco)

6.1 Activar HTTP/2 (si está disponible)

sudo a2enmod http2
sudo systemctl reload apache2

En tu https-lab.conf, dentro del VirtualHost 443, añade:

Protocols h2 http/1.1

6.2 Cabeceras básicas (seguridad “visible”)

Activa headers:

sudo a2enmod headers
sudo systemctl reload apache2

Dentro del <VirtualHost *:443> añade:

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

HSTS (solo si vais a usar HTTPS siempre; en lab puede dar guerra si cambiáis):

Header always set Strict-Transport-Security "max-age=86400"

7) Logs y troubleshooting (lo que siempre salva vidas)

7.1 Ver errores de Apache en directo

sudo tail -f /var/log/apache2/error.log

7.2 Ver logs del sitio HTTPS

sudo tail -f /var/log/apache2/https_error.log
sudo tail -f /var/log/apache2/https_access.log

7.3 Problemas típicos

• No abre el 443: firewall/UFW o router/VLAN.
• Apache no escucha en 443: revisa que ssl esté activo y que el sitio https-lab.conf esté habilitado. sudo a2query -m ssl
  sudo a2query -s https-lab
  sudo apache2ctl -S
• Certificado no coincide (CN mal): recrea el cert con CN correcto.
• Permisos: que Apache pueda leer el .crt y .key (en /etc/apache2/ssl suele ir bien con root y lectura adecuada; si te pasas bloqueando, falla).

El objetivo de esta práctica es diseñar, instalar, configurar y documentar una pequeña infraestructura virtual compuesta por varias máquinas Ubuntu Server conectadas en red local.

Cada máquina deberá tener una función concreta dentro del sistema y deberá relacionarse con las demás. El alumno tendrá que demostrar conocimientos de instalación de sistemas operativos, virtualización, configuración de red, instalación de servicios, administración del sistema, seguridad, automatización y documentación técnica.

Requisitos del proyecto

Debes crear al menos 3 máquinas virtuales Ubuntu Server con IP fija:

• un servidor web
• un servidor de base de datos
• un servidor de administración o mantenimiento

Debes realizar, como mínimo, las siguientes tareas

• instalar Ubuntu Server en las máquinas virtuales
• configurar la red local y las IP fijas
• instalar y configurar Apache en el servidor web
• instalar y configurar MySQL o MariaDB en el servidor de base de datos
• comprobar la comunicación entre el servidor web y el de base de datos
• administrar servicios con systemctl
• consultar registros con journalctl
• aplicar reglas básicas de seguridad con ufw
• crear scripts Bash de mantenimiento
• automatizar tareas con cron
• documentar todo el proceso en un README técnico

La entrega deberá incluir

• README.md principal
• capturas o evidencias organizadas por apartados
• scripts utilizados
• archivos de configuración relevantes
• comprobaciones finales de funcionamiento

Importante

No se valorará únicamente que “funcione”, sino que el trabajo esté bien explicado, justificado y documentado. Cada apartado debe mostrar comandos, explicación de su uso, resultado obtenido y evidencias del funcionamiento.

Objetivos didácticos

Con este proyecto el alumno deberá demostrar que sabe:

• Crear y configurar máquinas virtuales
• Instalar Ubuntu Server
• Asignar IP fija a cada máquina
• Configurar red local entre máquinas
• Instalar y administrar servicios como:
  • Apache o Nginx
  • MySQL o MariaDB
• Gestionar servicios con systemctl
• Consultar registros con journalctl
• Configurar reglas básicas de seguridad con ufw
• Crear scripts Bash para tareas de mantenimiento
• Programar tareas automáticas con cron
• Verificar conectividad y dependencias entre sistemas
• Documentar de forma técnica el trabajo realizado

Propuesta de arquitectura

┌─────────────────────────────────────────────────────────────┐
│                 ENTORNO DE VIRTUALIZACIÓN                   │
│         (VirtualBox / VMware / Proxmox / similar)           │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                  RED LOCAL VIRTUALIZADA                     │
│                     192.168.50.0/24                         │
└─────────────────────────────────────────────────────────────┘
        │                         │                         │
        ▼                         ▼                         ▼

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│      web01      │     │      db01       │     │     admin01     │
│ 192.168.50.10   │     │ 192.168.50.20   │     │ 192.168.50.30   │
├─────────────────┤     ├─────────────────┤     ├─────────────────┤
│ Ubuntu Server   │     │ Ubuntu Server   │     │ Ubuntu Server   │
│ Apache / HTTP   │     │ MySQL / MariaDB │     │ SSH / Scripts   │
│ Página web      │     │ Base de datos   │     │ Cron / Control  │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                         ▲                         │
        │ consulta datos          │                         │
        └─────────────────────────┘                         │
                  conexión remota                           │
                                                            │
                                                            │ administración,
                                                            │ comprobación,
                                                            │ mantenimiento
                                                            ▼
                                        ┌──────────────────────────────┐
                                        │  Scripts + logs + cron +     │
                                        │      comprobaciones          │
                                        └──────────────────────────────┘

Para que el proyecto tenga sentido, conviene que las máquinas tengan relación entre sí.

Máquina 1: servidor web

• Nombre: web01
• IP fija: 192.168.1.10
• Servicios:
  • Apache2
  • Página web de prueba
• Función:
  • Servir una web que muestre información del sistema
  • Conectarse a la base de datos remota para validar que existe comunicación

Máquina 2: servidor de base de datos

• Nombre: db01
• IP fija: 192.168.1.20
• Servicios:
  • MySQL Server o MariaDB
• Función:
  • Alojar una base de datos
  • Permitir conexión desde web01
  • Tener usuarios y permisos configurados

Máquina 3: servidor de administración / monitorización básica

• Nombre: admin01
• IP fija: 192.168.1.30
• Servicios y funciones:
  • Acceso por SSH a las otras máquinas
  • Scripts de mantenimiento
  • Tareas programadas por cron
  • Recolección de información del sistema
• Función:
  • Ejecutar scripts
  • Hacer comprobaciones de red
  • Centralizar tareas administrativas básicas

Relación de dependencia entre máquinas

• web01 depende de db01 porque debe conectarse a la base de datos remota
• admin01 depende de web01 y db01 porque debe administrarlas o comprobar su estado
• todas deben estar en la misma red local virtual y responder entre sí

graph TD
    A[Entorno de virtualización] --> B[Red local virtual 192.168.50.0/24]

    B --> C[web01<br>192.168.50.10<br>Ubuntu Server<br>Apache]
    B --> D[db01<br>192.168.50.20<br>Ubuntu Server<br>MySQL / MariaDB]
    B --> E[admin01<br>192.168.50.30<br>Ubuntu Server<br>SSH / Scripts / Cron]

    C -->|Consulta remota| D
    E -->|Administración y comprobación| C
    E -->|Administración y comprobación| D

    C --> F[Servicio web activo]
    D --> G[Base de datos activa]
    E --> H[Scripts de mantenimiento]
    E --> I[Tareas automáticas con cron]
    E --> J[Comprobación de logs y servicios]

    C --> K[UFW]
    D --> K
    E --> K

    F --> L[Documentación README]
    G --> L
    H --> L
    I --> L
    J --> L
    K --> L

Requisitos mínimos del proyecto

El alumno deberá cumplir, como mínimo, lo siguiente:

Virtualización

• Crear 3 máquinas virtuales
• Asignar recursos coherentes
• Instalar Ubuntu Server en todas

Red

• Configurar una red local virtual
• Asignar IP fija a cada máquina
• Verificar conectividad con ping

Servicios

• Instalar Apache en web01
• Instalar MySQL o MariaDB en db01
• Comprobar que el servicio web funciona desde navegador o con curl
• Comprobar que la base de datos acepta conexiones

Administración

• Usar comandos de terminal durante todo el proyecto
• Gestionar servicios con systemctl
• Consultar logs con journalctl

Seguridad

• Activar y configurar ufw
• Permitir solo los puertos necesarios
• Explicar qué puertos se abren y por qué

Automatización

• Crear al menos 2 scripts Bash
• Programar al menos 2 tareas con cron

Fases del proyecto

flowchart TD
    A[Planificación] --> B[Virtualización]
    B --> C[Instalación de sistemas]
    C --> D[Configuración de red]
    D --> E[Conectividad]

    E --> F[Servidor web]
    E --> G[Servidor de base de datos]

    F --> H[Comunicación entre servicios]
    G --> H

    H --> I[Administración de servicios]
    I --> J[Revisión de logs]
    J --> K[Seguridad con UFW]
    K --> L[Scripts de mantenimiento]
    L --> M[Tareas automáticas con cron]
    M --> N[Pruebas finales]
    N --> O[Documentación README y evidencias]

Fase 1. Creación de la infraestructura virtual

Tareas

1. Instalar el software de virtualización
   • VirtualBox, VMware o similar
2. Crear 3 máquinas virtuales
3. Asignar nombre a cada una
4. Instalar Ubuntu Server en cada una

Evidencias obligatorias

• Captura del software de virtualización mostrando las 3 máquinas
• Captura del proceso de instalación o del sistema ya instalado
• Tabla con nombre, RAM, disco y función de cada VM

Qué debe explicar en el README

• Qué programa de virtualización ha utilizado
• Qué recursos ha asignado a cada VM
• Por qué ha organizado así la infraestructura

Fase 2. Configuración de red

Tareas

1. Configurar red local entre las máquinas
2. Asignar IP fija a cada sistema
3. Comprobar conectividad

Ejemplo de tabla de red

Comprobaciones que deben hacer

• ip a
• hostnamectl
• ping entre máquinas

Evidencias obligatorias

• Archivo de configuración de red o capturas del mismo
• Resultado de ip a
• Resultado de pings exitosos entre las máquinas

Qué debe explicar en el README

• Cómo ha configurado la IP fija
• Qué problemas encontró
• Cómo comprobó que la red funciona

Fase 3. Instalación y configuración del servidor web

Tareas

En web01:

1. Instalar Apache2
2. Arrancar y habilitar el servicio
3. Crear una página de prueba
4. Comprobar acceso desde la propia máquina y desde otra

Comandos que deberían usar

sudo apt update
sudo apt install apache2 -y
sudo systemctl enable apache2
sudo systemctl start apache2
sudo systemctl status apache2

Página mínima sugerida

Una página HTML que muestre:

• nombre del servidor
• IP
• fecha
• descripción del proyecto

Evidencias obligatorias

• Captura de systemctl status apache2
• Captura del navegador o curl http://192.168.50.10
• Captura del contenido de la página web

Qué debe explicar en el README

• Qué hace Apache
• Dónde se encuentra el directorio web
• Cómo ha comprobado que el servicio está funcionando

Fase 4. Instalación y configuración del servidor de base de datos

Tareas

En db01:

1. Instalar MySQL o MariaDB
2. Habilitar y arrancar el servicio
3. Crear una base de datos
4. Crear un usuario con permisos
5. Permitir acceso desde web01

Posible estructura

• Base de datos: empresa
• Tabla: servicios
• Usuario remoto: webuser

Evidencias obligatorias

• Captura de systemctl status mysql
• Captura del acceso al cliente MySQL
• Captura o volcado SQL con creación de base y usuario

Qué debe explicar en el README

• Qué motor ha instalado
• Qué usuario creó y con qué permisos
• Qué diferencia hay entre usuario local y remoto
• Cómo ha validado la conexión

Fase 5. Comunicación entre servidor web y servidor de base de datos

Aquí está la gracia del invento. No queremos máquinas decorativas.

Tareas

Desde web01:

1. Comprobar conectividad con db01
2. Instalar cliente MySQL si hace falta
3. Conectarse a la base de datos remota
4. Insertar o consultar datos

Evidencias obligatorias

• ping 192.168.50.20
• conexión por cliente a MySQL remoto
• captura de consulta SQL exitosa

Qué debe explicar en el README

• Por qué web01 depende de db01
• Qué configuración fue necesaria para permitir el acceso remoto
• Qué medidas de seguridad tomó

Fase 6. Gestión de servicios y logs

Tareas

En las distintas máquinas:

1. Consultar el estado de Apache y MySQL
2. Reiniciar y detener servicios
3. Ver logs con journalctl

Comandos mínimos que deben demostrar

sudo systemctl status apache2
sudo systemctl restart apache2
sudo systemctl stop apache2
sudo systemctl start apache2
journalctl -u apache2
journalctl -u mysql
journalctl -xe

Evidencias obligatorias

• Captura de systemctl status
• Captura de journalctl -u apache2
• Captura de journalctl -u mysql o equivalente

Qué debe explicar en el README

• Qué diferencia hay entre iniciar, parar, reiniciar y habilitar un servicio
• Para qué sirve journalctl
• Qué información útil encontró en los logs

Fase 7. Seguridad básica con UFW

Tareas del alumno

En cada máquina:

1. Instalar o activar ufw
2. Definir política básica
3. Abrir solo los puertos necesarios

Ejemplo

• web01: permitir 22 y 80
• db01: permitir 22 y 3306 solo si procede
• admin01: permitir 22

Comandos orientativos

sudo ufw enable
sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 3306/tcp

Evidencias obligatorias

• Captura de ufw status verbose
• Explicación de qué puertos se han abierto
• Justificación de seguridad

Qué debe explicar en el README

• Qué es un firewall
• Qué puertos necesita cada máquina
• Qué riesgos existirían si se abrieran más puertos de la cuenta

Fase 8. Scripts de mantenimiento

Tareas

Crear al menos dos scripts Bash.

Script 1: comprobación del sistema

Debe mostrar:

• hostname
• IP
• uso de disco
• uso de memoria
• fecha
• estado de un servicio

Script 2: copia de logs o informe de mantenimiento

Debe:

• crear una carpeta de copias o informes
• guardar fecha y hora
• copiar un log o generar un resumen del sistema a un archivo

Ejemplo de ideas

• check_web.sh
• backup_logs.sh
• estado_sistema.sh

Evidencias obligatorias

• Código de los scripts
• Captura de ejecución
• Explicación línea por línea o por bloques

Qué debe explicar en el README

• Para qué sirve cada script
• Cómo se ejecuta
• Qué permisos necesita
• Qué salida genera

Fase 9. Automatización con cron

Tareas

Programar al menos dos tareas automáticas:

• una para ejecutar un script de mantenimiento
• otra para generar un informe o copia

Comandos esperados

crontab -e
crontab -l

Evidencias obligatorias

• Captura de crontab -l
• Captura o prueba del archivo generado por cron
• Explicación del formato del cron

Qué debe explicar en el README

• Qué tarea automatizó
• Cada cuánto se ejecuta
• Cómo verificó que realmente se ejecutó

Plantilla de README

Puedes darles esta estructura para obligarles a documentar bien.

# Proyecto: infraestructura virtualizada con Ubuntu Server

## 1. Datos del alumno
- Nombre:
- Curso:
- Módulo:
- Fecha:

## 2. Introducción
Explica brevemente en qué consiste el proyecto y cuáles son sus objetivos.

## 3. Diseño de la infraestructura
### 3.1 Máquinas virtuales creadas
| Máquina | Función | IP | Sistema operativo |
|---|---|---|---|

### 3.2 Relación entre máquinas
Explica cómo se comunican y de qué depende cada una.

## 4. Instalación de Ubuntu Server
Describe el proceso de creación e instalación de cada máquina virtual.

### Evidencias
- Capturas
- Configuración asignada
- Observaciones

## 5. Configuración de red
Explica cómo configuraste la IP fija en cada máquina.

### Comandos utilizados
~~~bash
ip a
ping

Estructura de entrega recomendada

Puedes utilizar esta estructura para la documentación:

proyecto/
│
├── README.md
├── evidencias/
│   ├── 01-virtualizacion/
│   ├── 02-red/
│   ├── 03-web/
│   ├── 04-bd/
│   ├── 05-seguridad/
│   ├── 06-scripts/
│   └── 07-cron/
│
├── scripts/
│   ├── check_web.sh
│   └── backup_logs.sh
│
├── configuracion/
│   ├── netplan-web01.yaml
│   ├── netplan-db01.yaml
│   └── netplan-admin01.yaml
│
└── sql/
    └── bd_inicial.sql

Evidencias que puedes incluir en la documentación

(capturas y explicación)

Instalación y configuración de Apache

Explica la instalación del servidor web en web01.

Comandos utilizados

sudo apt update
sudo apt install apache2 -y

Verificación

Explica cómo comprobaste que funciona.

Instalación y configuración de MySQL/MariaDB

Explica la instalación del servidor de base de datos en db01.

Comandos utilizados

sudo apt install mysql-server -y

Verificación

Explica cómo comprobaste que funciona.

Comunicación entre servicios

Explica cómo el servidor web accede al servidor de base de datos.

Pruebas realizadas

• ping
• conexión remota
• consulta SQL

Gestión de servicios con systemctl

Explica qué comandos usaste para iniciar, parar, reiniciar y habilitar servicios.

Consulta de logs con journalctl

Indica qué logs revisaste y qué información encontraste.

Seguridad con UFW

Explica qué reglas configuraste y por qué.

Scripts de mantenimiento

Script 1

• Nombre:
• Función:
• Código:
• Resultado:

Script 2

• Nombre:
• Función:
• Código:
• Resultado:

Tareas programadas con cron

Explica qué tareas automatizaste y cómo las comprobaste.

Comprobaciones finales

Incluye evidencias de:

• IP fija
• conectividad entre máquinas
• Apache funcionando
• MySQL funcionando
• firewall activo
• scripts funcionando
• cron funcionando

Problemas encontrados y soluciones

Describe los errores o dificultades y cómo los resolviste.

Cómo verificar que realmente ha hecho el trabajo

Esto es clave. Hay que pedir pruebas que huelan a trabajo real y no a “copié cuatro cosas de internet y recé”. Para demostrar que es una implementación real, puedes ir incluyendo en la documentación (Donde toque) el resultado de algunso comandos.

Identificación del sistema

En cada máquina:

hostnamectl
ip a
lsb_release -a

Estado de servicios

systemctl status apache2
systemctl status mysql

Logs reales

journalctl -u apache2 --no-pager | tail -n 20
journalctl -u mysql --no-pager | tail -n 20

Firewall

sudo ufw status verbose

Cron

crontab -l

Scripts

Ejecutar los scripts y mostrar salida:

bash check_web.sh
bash backup_logs.sh

Red

ping -c 4 192.168.50.20
ping -c 4 192.168.50.10

Web

Desde otra máquina:

curl http://192.168.50.10

Base de datos

Desde web01:

mysql -h 192.168.50.20 -u webuser -p