Laboratorios prácticos de administración Linux

Este módulo reúne escenarios reales de sysadmin, diseñados para practicar diagnóstico, análisis y resolución de problemas en sistemas Linux.

No son ejercicios académicos: son situaciones reales de producción, del tipo “algo no funciona y tienes que arreglarlo”.

Introducción

Saber comandos no te convierte en sysadmin.
Lo que te convierte en sysadmin es resolver problemas bajo presión, con información incompleta y sin romper nada más.

Estos laboratorios están pensados para:

  • Unir todos los módulos anteriores
  • Entrenar el razonamiento técnico
  • Practicar el orden correcto de diagnóstico
  • Desarrollar criterio profesional

💡 No ejecutes comandos al azar. Piensa antes.

Laboratorio 1: El servicio no responde

Escenario

Un servicio web deja de responder.
Los usuarios reportan que “la web está caída”.

Objetivo

Determinar por qué no responde y restaurar el servicio.

Pistas

  • El servidor está encendido
  • Hay acceso por SSH
  • No se ha tocado código

Flujo recomendado

uptime
systemctl status nginx
journalctl -u nginx -e
ss -tulnp

Posibles causas

  • Servicio caído
  • Error de configuración
  • Puerto ocupado
  • Permisos incorrectos
  • Disco lleno

Laboratorio 2: El sistema va lento

Escenario

El servidor responde muy lento, pero no está “caído”.

Objetivo

Identificar qué recurso está saturado.

Flujo recomendado

uptime
top
free -h
df -h
ps aux --sort=-%cpu | head

Posibles causas

  • Proceso descontrolado
  • Falta de memoria
  • Swap excesivo
  • Disco lleno
  • Backup mal programado

⚠️ No mates procesos sin entenderlos.

Laboratorio 3: Problema de red

Escenario

El servidor no puede acceder a Internet, pero funciona localmente.

Objetivo

Determinar si el problema es IP, ruta o DNS.

Flujo recomendado

ip addr
ip route
ping 8.8.8.8
ping google.com

Interpretación

  • IP OK, ping IP falla → red
  • Ping IP OK, ping nombre falla → DNS
  • Todo OK → firewall o servicio

Laboratorio 4: Problema de permisos

Escenario

Un servicio arranca, pero falla al acceder a archivos.

Objetivo

Corregir permisos sin usar 777.

Flujo recomendado

ls -l /ruta/archivo
ps aux | grep servicio
id usuario_servicio
journalctl -u servicio -e

Clave

  • Usuario del proceso
  • Propietario del archivo
  • Permisos del directorio

💡 El problema suele estar en el directorio, no en el archivo.

Laboratorio 5: Disco lleno

Escenario

El sistema empieza a fallar aleatoriamente.

Objetivo

Liberar espacio sin romper el sistema.

Flujo recomendado

df -h
du -sh /var/log/*
journalctl --disk-usage
ls -lh /var/log

Acciones típicas

  • Limpiar logs antiguos
  • Revisar logrotate
  • Eliminar archivos temporales
  • No borrar a ciegas

Laboratorio 6: Usuario no puede hacer sudo

Escenario

Un usuario debería poder usar sudo, pero no puede.

Objetivo

Corregir permisos de sudo correctamente.

Flujo recomendado

id usuario
groups usuario
visudo

Clave

  • Grupo sudo o wheel
  • Archivo /etc/sudoers
  • No editar con editores normales

⚠️ Un sudoers mal editado puede bloquear el sistema.

Laboratorio 7: Problema tras una actualización

Escenario

Tras actualizar paquetes, algo deja de funcionar.

Objetivo

Identificar qué cambió y por qué.

Flujo recomendado

apt history
journalctl -b
systemctl status servicio

Mentalidad

  • ¿Qué se actualizó?
  • ¿Qué servicio falló después?
  • ¿Hay rollback posible?

Errores comunes

Errores habituales en laboratorios y producción:

  • Ejecutar comandos sin entender
  • No seguir un orden lógico
  • Reiniciar sin mirar logs
  • Matar procesos al azar
  • Cambiar varias cosas a la vez
  • No documentar la solución

Consejo: una acción cada vez.

Ejercicios prácticos

1. Simular servicio caído

systemctl stop ssh
systemctl status ssh
journalctl -u ssh

2. Simular disco lleno (con cuidado)

fallocate -l 100M /tmp/testfile
df -h
rm /tmp/testfile

3. Diagnóstico completo

Escoge un servicio y revisa:

systemctl status
journalctl
ss -tulnp

Mentalidad

Un buen sysadmin en producción:

  • Sigue un orden
  • No entra en pánico
  • Confía en los logs
  • Cambia lo mínimo necesario
  • Documenta la solución
  • Aprende de cada incidente

Los laboratorios entrenan criterio, no memoria.

Resumen

  • Los problemas reales combinan varios conceptos
  • El orden de diagnóstico es clave
  • Logs, procesos y red son centrales
  • No existe una única causa
  • Resolver problemas es un proceso, no un comando

Siguiente paso

En el siguiente módulo entrarás en:

Errores comunes del sysadmin Linux (errores.md)

Donde verás:

  • Errores reales cometidos en producción
  • Por qué ocurren
  • Cómo evitarlos
  • Lecciones aprendidas a base de golpes