Casos reales de administración Linux

Este módulo presenta casos reales de producción, analizados con mentalidad de sysadmin: contexto, diagnóstico, decisiones, resolución y lecciones aprendidas.

El objetivo no es mostrar comandos, sino cómo pensar cuando todo importa: impacto, riesgo, tiempo y reversibilidad.

Introducción

En producción no hay ejercicios aislados.
Los problemas mezclan red, permisos, procesos, disco, servicios y personas.

Estos casos reflejan situaciones reales donde:

  • No toda la información está disponible
  • Hay presión por restaurar el servicio
  • Un mal paso puede empeorar el impacto

💡 El valor está en el razonamiento, no en el comando final.

Caso 1: Servicio web caído tras un cambio “menor”

Contexto

  • Servidor web en producción
  • Cambio de permisos para “ordenar archivos”
  • Minutos después, la web deja de responder

Diagnóstico

systemctl status nginx
journalctl -u nginx -e

Error repetido: permission denied.

ps aux | grep nginx
ls -ld /var/www/app

Causa real

  • El proceso corre como www-data
  • El directorio perdió permiso de ejecución (x)
  • El archivo tenía permisos correctos, el directorio no

Resolución

chown -R www-data:www-data /var/www/app
chmod 755 /var/www/app

Reinicio controlado del servicio.

Lección aprendida

  • Los permisos en directorios son críticos
  • No usar 777
  • Revisar usuario del proceso antes de cambiar permisos

Caso 2: Servidor “lento” que no estaba roto

Contexto

  • Usuarios reportan lentitud
  • CPU aparentemente baja
  • Servicios activos

Diagnóstico

uptime
top
free -h
df -h

Resultado: swap al 100 %, RAM agotada.

Causa real

  • Proceso Java con fuga de memoria
  • El sistema no estaba caído, estaba asfixiado

Resolución

  • Reinicio controlado del servicio
  • Ajuste de límites de memoria
  • Monitorización posterior

Lección aprendida

  • CPU baja no significa sistema sano
  • La memoria mata silenciosamente
  • Mirar swap siempre

Caso 3: “No hay red” (pero sí la había)

Contexto

  • Servidor sin acceso a Internet
  • Servicios locales funcionan

Diagnóstico

ip addr
ip route
ping 8.8.8.8
ping google.com

Resultado:

  • Ping por IP funciona
  • Ping por nombre falla

Causa real

DNS mal configurado tras cambio de red.

cat /etc/resolv.conf

Resolución

  • Corregir DNS
  • Evitar editar resolv.conf manualmente
  • Configurar correctamente NetworkManager / systemd-resolved

Lección aprendida

  • Red ≠ DNS
  • Siempre prueba IP antes que nombres
  • Muchos “problemas de red” son DNS

Caso 4: Disco lleno que rompe todo

Contexto

  • Fallos aleatorios
  • Servicios que no escriben logs
  • SSH intermitente

Diagnóstico

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

Causa real

  • Logs sin rotar
  • /var al 100 %

Resolución

  • Limpiar logs antiguos
  • Revisar logrotate
  • Alertas de disco configuradas

Lección aprendida

  • El disco lleno rompe cosas de formas raras
  • La prevención es clave
  • /var merece monitorización dedicada

Caso 5: Usuario con sudo… que no podía usarlo

Contexto

  • Usuario “admin” sin acceso sudo
  • Funcionaba el día anterior

Diagnóstico

id admin
groups admin
visudo

Causa real

  • Usuario no estaba en el grupo sudo
  • Cambio de usuario reciente

Resolución

usermod -aG sudo admin

Nuevo login.

Lección aprendida

  • sudo depende de grupos
  • Siempre revisar id y groups
  • Nunca editar sudoers sin visudo

Caso 6: Actualización que rompe un servicio crítico

Contexto

  • apt upgrade en producción
  • Servicio deja de arrancar

Diagnóstico

journalctl -b
systemctl status servicio

Revisión de cambios recientes.

Causa real

  • Cambio de versión incompatible
  • Config antigua no válida

Resolución

  • Ajustar configuración
  • Reinicio controlado
  • Ventanas de mantenimiento definidas

Lección aprendida

  • Actualizar no es trivial
  • Leer cambios importantes
  • Producción no es laboratorio

Errores comunes

Errores que aparecen en casi todos los casos:

  • No mirar logs
  • Actuar con prisas
  • Cambiar varias cosas a la vez
  • No entender el contexto
  • No documentar la solución

Consejo: la calma reduce el impacto.

Ejercicios prácticos

  1. Analiza un caso

    • Elige uno de los anteriores
    • Escribe: causa, solución y prevención

  2. Simula diagnóstico

systemctl status ssh
journalctl -u ssh -e
  1. Checklist personal
    • Crea tu checklist de producción antes de tocar nada

Mentalidad

Un sysadmin con experiencia:

  • Piensa en impacto antes que en comandos
  • Prefiere entender a “arreglar rápido”
  • Documenta para el futuro
  • Aprende de cada incidente
  • Sabe que producción es diferente

Los casos reales enseñan criterio, no recetas.

Resumen

  • Los problemas reales combinan varios temas
  • El diagnóstico ordenado marca la diferencia
  • Logs, red y recursos son claves
  • La prevención ahorra incidentes
  • La experiencia se construye resolviendo y reflexionando

Siguiente paso

A partir de aquí comienza un nuevo bloque de la guía:

En este bloque entrarás en:

  • Gestión diaria del sistema
  • Operaciones administrativas fundamentales
  • Bases sólidas para entornos productivos