Ya sabes quién eres y en qué máquina estás. Queda la pregunta que cierra la orientación: dónde estás y qué hay a tu alrededor.

Cuando abres el explorador de archivos en Windows ves C:, quizá D:, y una carpeta Program Files donde se instala el software. En Linux nada de eso existe. Hay un único árbol que nace en / y del que cuelga absolutamente todo: los programas, la configuración, tus documentos, los discos, e incluso información que no está en ningún disco, como la temperatura del procesador.

Esta lección te da el mapa. Al terminarla, cuando veas una ruta como /var/log/tramontana/acceso.log sabrás leerla como una frase con significado, y cuando tengas que decidir dónde colocar una pieza de software nueva no lo harás por intuición sino con el estándar en la mano. Es la diferencia entre un servidor que cualquiera puede administrar y un servidor donde las cosas están «donde las puso Fulano».

1. Un árbol único frente a las unidades de Windows
2. Qué significa montar
3. El estándar FHS: recorrido por los directorios
4. Datos estáticos y variables, compartibles y no compartibles
5. Todo es un archivo: los siete tipos
6. Los pseudo-sistemas /proc y /sys
7. Archivos ocultos y la convención del punto
8. Rutas absolutas y relativas
9. Dónde va cada pieza de Tramontana y por qué

La diferencia estructural con Windows es de fondo, no de nomenclatura.

En Windows, la estructura del almacenamiento se refleja en las rutas: si un archivo está en el segundo disco, su ruta empieza por D:. Si mañana ese disco cambia de letra, todas las rutas cambian.

En Linux, la ruta describe qué es el archivo, no dónde está físicamente. /var/log/tramontana/acceso.log significa «un archivo de registro de la aplicación Tramontana». Que esté en el primer disco, en el segundo, en un volumen LVM o en un recurso de red compartido es irrelevante para quien lo usa y puede cambiar sin que ningún programa se entere.

Esa independencia entre estructura lógica y disposición física es una de las mejores ideas del diseño Unix, y el mecanismo que la hace posible se llama montaje.

Montar es conectar el contenido de un dispositivo de almacenamiento a un directorio del árbol. Ese directorio se llama punto de montaje, y a partir del montaje, entrar en él significa entrar en el dispositivo.

Míralo en tu servidor:

Interpretación: la partición /dev/sda2 está montada en /, y la /dev/sda1 en /boot/efi. Cuando accedes a un archivo dentro de /boot/efi, estás leyendo del segundo dispositivo, aunque desde tu punto de vista solo has entrado en un subdirectorio.

Las consecuencias prácticas de este modelo son enormes:

• Puedes añadir un disco nuevo de 2 TB y montarlo en /srv/tramontana/backups. Los scripts de copia de seguridad siguen escribiendo en la misma ruta de siempre y no se enteran de nada.
• Puedes montar un recurso de red en /mnt/nas y trabajar con él como si fuera local.
• Puedes aislar riesgos: si /var está en su propia partición, un log desbocado no llena el sistema raíz, como vimos en la lección 01-04.

El montaje en profundidad, el archivo /etc/fstab y el montaje automático son la lección 05-04.

El FHS (Filesystem Hierarchy Standard) es el documento que define qué va en cada directorio. Lo mantiene la Linux Foundation y lo siguen todas las distribuciones importantes.

Su valor es enorme y muy concreto: gracias a él, un administrador que llega a un servidor Rocky Linux sabe que la configuración está en /etc sin necesidad de buscarla. El FHS es lo que hace que Linux sea predecible.

Mira la raíz de tu servidor:

Cinco directorios concentran el 90 % de tu trabajo. Merece la pena detallarlos.

/etc — la configuración. Todo lo que configura el sistema y sus servicios está aquí, y casi siempre en texto plano. Es el directorio más valioso de un servidor: si haces copia de /etc, puedes reconstruir la configuración de la máquina.

Cada nombre es una pieza que estudiarás: passwd y group (usuarios, lección 05-01), fstab (montajes, 05-04), crontab (tareas programadas, 03-07), ssh (acceso remoto, 06-02), netplan (red, 06-01).

Y una implicación de que sea texto plano que conviene apreciar ahora: /etc se puede versionar con Git. Muchos administradores lo hacen, y así tienen el historial completo de cambios de configuración de sus servidores, con quién cambió qué y cuándo.

/var — lo que crece. Variable: datos que cambian durante la operación normal.

Es el directorio que más vigila un administrador, porque es el que se llena.

/home — los usuarios. Cada usuario tiene el suyo: /home/operador, /home/alumno. Es el único sitio donde un usuario normal puede escribir libremente, y donde vivirá /home/operador/scripts.

/opt y /usr/local — software que no viene del gestor de paquetes. Aquí hay una distinción fina que confunde a mucha gente:

/srv — datos servidos. Es el menos usado y el peor entendido. El FHS lo define como los datos que este servidor sirve a terceros: sitios web, FTP, recursos compartidos, copias de seguridad. La diferencia con /var/www es que /srv está pensado para organizarse por servicio o por cliente, y muchas distribuciones lo dejan vacío para que el administrador lo estructure.

Si listas la raíz con detalle verás algo curioso:

Esa l inicial y la flecha indican que no son directorios reales, sino enlaces simbólicos a sus equivalentes dentro de /usr. Es la llamada usr merge, completada en Ubuntu y en la mayoría de distribuciones modernas.

Históricamente, /bin contenía lo imprescindible para arrancar y reparar el sistema (porque /usr podía estar en otra partición o incluso en red y no estar disponible al principio del arranque), y /usr/bin el resto. Hoy initramfs resuelve el arranque temprano y esa separación ya no aporta nada, así que se unificó. Los enlaces se mantienen para que las rutas antiguas de miles de scripts sigan funcionando.

Es un buen ejemplo de cómo el FHS evoluciona conservando la compatibilidad.

El FHS no es una lista arbitraria de nombres. Detrás hay dos ejes de clasificación, y entenderlos te permite deducir dónde va cada cosa en lugar de memorizarlo.

Los dos ejes:

• Estático frente a variable. Estático es lo que solo cambia cuando un administrador instala o modifica algo: los programas de /usr, la configuración de /etc. Variable es lo que cambia solo durante el funcionamiento: los logs de /var/log, las colas, las cachés.
• Compartible frente a no compartible. Compartible es lo que tendría sentido servir por red a varias máquinas: los binarios de /usr son idénticos en todos los servidores de la misma distribución. No compartible es lo específico de una máquina: su configuración de red, su hostname, sus logs.

Cuatro consecuencias prácticas que aparecen constantemente en administración:

1. Determina qué se respalda y con qué frecuencia. /etc (estático, no compartible) es pequeño y valiosísimo: cópialo a diario. /usr (estático, compartible) no hace falta respaldarlo, se reinstala con el gestor de paquetes. /var/log (variable) se respalda o se rota según la política de retención.

2. Determina qué se puede montar como solo lectura. En servidores endurecidos, /usr se monta en modo solo lectura porque no debe cambiar durante el funcionamiento. Cualquier intento de escritura ahí es señal de compromiso. /var y /etc, en cambio, deben poder escribirse.

3. Determina qué necesita partición propia. Lo variable crece de forma impredecible: por eso /var merece su propia partición, como vimos en la lección 01-04. Lo estático tiene tamaño acotado.

4. Determina dónde poner lo tuyo. Y aquí está la aplicación directa: la aplicación de Tramontana es estática (solo cambia cuando Luis despliega una versión nueva), su configuración es estática y no compartible, y sus logs son variables y no compartibles. Tres naturalezas distintas que exigen tres ubicaciones distintas. Lo cerramos en la sección 9.

Ya viste el principio en la lección 01-02. Ahora toca verlo funcionando.

En Linux, casi todo se presenta con la misma interfaz de archivo, de modo que las mismas syscalls (open, read, write, close) y las mismas herramientas sirven para cosas radicalmente distintas.

Hay siete tipos, y ls -l los identifica con la primera letra de cada línea:

Compruébalo:

Fíjate en dos detalles reveladores:

• La primera letra de cada línea es el tipo: l, -, d, c, b.
• En las líneas de dispositivo, donde los archivos normales muestran el tamaño, aparecen dos números (1, 3 y 8, 0). Son los números mayor y menor: el mayor identifica qué controlador del kernel gestiona el dispositivo, y el menor cuál de ellos es. Un dispositivo no tiene tamaño porque no contiene datos: es una puerta a un controlador.

Tres archivos de /dev que usarás constantemente.

/dev/null — el agujero negro. Todo lo que escribas ahí desaparece; leerlo devuelve el fin de fichero inmediatamente.

No hay salida. Ninguna de las dos operaciones produce nada.

Su utilidad es diaria: descartar la salida que no interesa. Ya lo usaste sin saberlo en la lección 01-04, cuando verificaste la ISO con sha256sum -c SHA256SUMS 2>/dev/null para descartar los mensajes de error de las imágenes no descargadas. La redirección es la lección 03-04.

/dev/zero — la fuente infinita de ceros. Leerlo devuelve bytes cero sin límite. Sirve para crear archivos de tamaño fijo o para borrar datos.

head -c 20 toma 20 bytes y od -c los muestra de forma legible: veinte ceros.

/dev/sda — el disco entero. No es una metáfora: es el disco. Puedes leerlo byte a byte y, si eres root, escribirlo. Es lo que permitía a dd grabar una ISO en un USB en la lección 01-04, y también lo que hace ese comando tan peligroso.

/dev/random y /dev/urandom generan datos aleatorios criptográficamente seguros, y son la base de la generación de claves que verás en el Módulo 6.

Este listado puede parecer una curiosidad, pero tiene una consecuencia que atraviesa todo el curso: las mismas herramientas sirven para todo.

cat puede mostrar un archivo de texto, la información del procesador (/proc/cpuinfo) o los bytes de un disco. grep puede buscar en un log, en la salida de otro programa o en un pseudo-archivo del kernel. Redirigir la salida de un programa a un archivo, a un dispositivo o a otro programa es exactamente la misma operación.

Cuando en el Módulo 3 encadenes herramientas con tuberías, esa uniformidad es lo que lo hace posible. En un sistema donde los discos, los procesos y la red tuvieran cada uno su API propia, harían falta programas distintos para cada cosa.

/proc y /sys son la aplicación más espectacular del principio anterior. No ocupan un solo byte en disco: son sistemas de archivos virtuales que el kernel genera en memoria en el momento en que los lees.

Cada vez que abres /proc/meminfo, el kernel construye ese "archivo" al vuelo con el estado actual de la memoria. Es una interfaz de consulta disfrazada de sistema de archivos.

Información del procesador:

grep -m1 muestra solo la primera coincidencia, porque el archivo repite la información para cada núcleo.

Información de memoria:

Aquí está el dato interesante: esto es exactamente de donde free -h saca sus números. free no es más que un programa que lee /proc/meminfo y lo presenta de forma legible. Lo mismo pasa con uptime y /proc/uptime, o con ps y los directorios /proc/<pid>/.

Comprobarlo cambia la forma de ver el sistema: las herramientas de diagnóstico no tienen poderes especiales, simplemente leen archivos que tú también puedes leer.

Un proceso concreto. Cada proceso en ejecución tiene un directorio en /proc con su número de PID:

/proc/1/ es el proceso 1, es decir, systemd. Qué hay dentro:

(El tr '\0' ' ' sustituye los caracteres nulos que separan los argumentos por espacios, para que sea legible.)

Otros archivos útiles de /proc:

/sys expone dispositivos y parámetros del kernel, y muchos de sus archivos son escribibles. Cambiar uno modifica el comportamiento del kernel al instante, sin reiniciar.

Ese 0 significa que el reenvío de paquetes IP está desactivado: el servidor no actúa como router. Activarlo sería tan simple como escribir un 1 en ese archivo.

Este mecanismo es lo que hace posible el ajuste fino del kernel, y es el tema de la lección 07-03. Se menciona aquí solo para que entiendas la naturaleza de lo que estás viendo.

Advertencia clara: /proc y /sys son seguros para leer — hazlo sin miedo, es la mejor forma de entender qué hace tu sistema. Escribir en ellos sin saber lo que haces puede degradar el rendimiento o desestabilizar la máquina. Durante este módulo, limítate a mirar.

En Linux, un archivo cuyo nombre empieza por punto está oculto. No hay un atributo especial como en Windows: es solo una convención de nombre que las herramientas respetan.

-a significa all. Aparecen muchos más elementos.

Los dos primeros son especiales y estarán siempre en cualquier directorio:

• . es el directorio actual.
• .. es el directorio padre.

No son un adorno: son entradas reales del directorio, y son la base de las rutas relativas de la sección siguiente.

Los archivos ocultos habituales en tu directorio personal:

El propósito de la convención es puramente práctico: la configuración personal se guarda en el directorio del usuario, pero no debe estorbar cuando este lista sus documentos. Los programas ponen su configuración con punto delante y desaparecen de la vista.

Un detalle importante que ya se deduce de la tabla: un directorio oculto puede contener archivos perfectamente visibles. .ssh está oculto, pero ls -a ~/.ssh muestra su contenido con normalidad. Ocultar afecta al elemento, no a lo que hay dentro.

Y un aviso operativo: al hacer copias de seguridad de un directorio personal, hay que asegurarse de incluir los archivos ocultos. Es una fuente clásica de copias incompletas en las que se pierde toda la configuración y las claves SSH.

Hay dos formas de nombrar un archivo, y la distinción es tan simple como fundamental.

Ruta absoluta: parte de la raíz / y describe el camino completo. Es la misma esté donde esté quien la escriba.

Ruta relativa: parte del directorio actual. Su significado depende de dónde estés.

Los símbolos que se usan en rutas:

Cuándo usar cada una:

La primera fila es la que más disgustos evita. Un script que usa la ruta relativa logs/acceso.log funciona cuando lo pruebas desde tu directorio, y falla misteriosamente cuando cron lo ejecuta desde otro sitio. Es uno de los errores más frecuentes al empezar con automatización, y volveremos sobre ello en las lecciones 03-07 y 04-07.

El uso práctico de las rutas —moverse con cd, saber dónde estás con pwd, listar con ls— es la lección 02-03. Aquí solo necesitabas la definición.

Llega el momento de aplicar todo el mapa. Luis Ferrer está listo para desplegar Tramontana Reservas en srv-tramontana y te pregunta dónde poner cada cosa. La respuesta no es una opinión: se deduce del FHS y de la clasificación estático/variable.

Vamos una por una, porque el razonamiento importa más que la conclusión.

Tramontana Reservas no viene de los repositorios de Ubuntu: es software propio que Luis despliega manualmente. El FHS reserva /opt exactamente para eso, con la convención /opt/<proveedor>/<producto>.

Es estática porque solo cambia cuando se despliega una versión nueva, no durante el funcionamiento. Y es compartible: si mañana hubiera un segundo servidor de aplicación, tendría exactamente el mismo contenido en esa ruta.

Ventaja adicional de la naturaleza autocontenida de /opt: desinstalar es borrar un directorio, y hacer copia de la aplicación es copiar un directorio.

Alternativa descartada: /usr/local. Es correcta para software compilado que se integra en el sistema, repartiendo binarios en /usr/local/bin y librerías en /usr/local/lib. Para una aplicación web autocontenida, /opt es más limpio.

Aquí van la cadena de conexión a la base de datos, los parámetros de la aplicación y sus credenciales. /etc es, por definición del FHS, la configuración estática específica de esta máquina.

Esa última parte es la clave, y es lo que justifica separar la configuración de la aplicación en lugar de dejarla dentro de /opt/tramontana/app/config:

• El servidor de pruebas y el de producción ejecutan el mismo código con configuración distinta. Separarlos permite desplegar el mismo artefacto en ambos.
• La copia de seguridad de /etc recoge automáticamente la configuración de todos los servicios, incluida la nuestra.
• Al actualizar la aplicación (borrando y recreando /opt/tramontana/app), la configuración no corre ningún riesgo.
• La configuración contiene secretos y necesita permisos restrictivos, distintos de los del código. Los permisos son la lección 02-07 y los secretos la 06-05.

acceso.log y errores.log son el ejemplo perfecto de datos variables: crecen continuamente sin intervención de nadie.

Ponerlos en /var/log no es una formalidad. Tiene consecuencias muy concretas:

• Es donde las herramientas de rotación de logs (logrotate) esperan encontrarlos, para comprimir y eliminar los antiguos automáticamente. Sin eso, un log crece hasta llenar el disco.
• Es donde cualquier administrador mirará primero al investigar un problema.
• Como vimos en la lección 01-04, /var puede estar en su propia partición: si los logs se desbocan, el sistema raíz no se ve afectado.

Alternativa descartada: dejarlos dentro de /opt/tramontana/app/logs, que es lo que muchas aplicaciones hacen por defecto. Es un error clásico: mezcla datos estáticos con variables, rompe la rotación automática, complica las copias de seguridad y hace que un desbordamiento afecte a la partición equivocada.

/srv es el directorio para datos que este servidor sirve o custodia, organizados por servicio.

Y hay una razón operativa de peso para separarlas: al estar en su propio directorio de primer nivel, /srv/tramontana/backups puede montarse en un disco físico distinto con una sola línea en /etc/fstab, sin tocar ni una ruta de los scripts. Es exactamente el escenario de la sección 2 sobre montaje.

Y eso importa mucho, porque una copia de seguridad en el mismo disco que los datos originales protege contra el borrado accidental, pero no contra el fallo del disco. La estrategia completa de respaldo es la lección 05-08.

Los scripts de automatización que escribirás en el Módulo 4 son tuyos: tu directorio personal es su sitio natural mientras estás desarrollándolos.

Un matiz profesional que conviene anticipar: cuando un script deja de ser un experimento y pasa a ser parte de la operación —lo ejecuta cron, depende de él una copia de seguridad—, ya no debería vivir en un directorio personal. Su sitio pasa a ser /usr/local/bin o /opt/tramontana/bin, porque si mañana operador deja de existir o se limpia su directorio, la operación no puede depender de eso. Lo veremos en la lección 04-07.

Así queda srv-tramontana cuando el despliegue esté completo:

Cinco directorios, cinco naturalezas distintas, cinco justificaciones. Cualquier administrador de Linux del mundo entendería esta estructura sin que nadie se la explique. Eso es lo que aporta seguir un estándar.

• Confundir /root con /. / es la raíz del árbol; /root es el directorio personal del usuario root. Se pronuncian igual y son cosas distintas.
• Buscar un «Program Files» de Linux. No existe un único sitio: el software se reparte según su naturaleza (/usr/bin para binarios de paquetes, /opt para aplicaciones de terceros, /usr/local para lo compilado a mano, /etc para su configuración).
• Instalar software propio en /usr/bin. Ese directorio pertenece al gestor de paquetes. Lo que pongas ahí a mano puede ser sobrescrito o eliminado en una actualización. Usa /usr/local/bin o /opt.
• Dejar los logs dentro del directorio de la aplicación. Rompe la rotación automática, mezcla datos estáticos con variables y arriesga la partición equivocada.
• Guardar datos importantes en /tmp. Se limpia al reiniciar y, en muchos sistemas, también periódicamente. Si necesitas temporales que sobrevivan, usa /var/tmp.
• Escribir en /proc o /sys sin entender qué hace. Leerlos es seguro y educativo; escribirlos puede desestabilizar el sistema al instante.
• Olvidar los archivos ocultos al copiar un directorio personal. Te llevas los documentos y dejas atrás la configuración y las claves SSH. ls -a antes de copiar.
• Usar rutas relativas en scripts. Funcionan cuando los pruebas y fallan cuando los ejecuta cron desde otro directorio. En scripts, rutas absolutas.
• Consejo. Cuando dudes dónde poner algo, hazte dos preguntas: ¿esto cambia solo durante el funcionamiento? (si sí, va bajo /var) y ¿es específico de esta máquina? (si sí, /etc para configuración). Con esas dos preguntas resuelves la mayoría de los casos.
• Consejo. Dedica un rato a explorar /etc, /var/log y /proc con ls y cat. No hay riesgo en leer, y la familiaridad con el terreno se adquiere recorriéndolo. Es la mejor inversión de tiempo antes de empezar el Módulo 2.
• Consejo. El FHS completo está publicado y es sorprendentemente legible. Cuando tengas una duda real sobre dónde va algo, consultarlo te da una respuesta con autoridad, no una opinión.

Para cada elemento, indica en qué directorio debería ubicarse según el FHS, y justifica la respuesta usando la clasificación estático/variable y compartible/no compartible:

1. El certificado TLS del dominio de Tramontana Reservas.
2. Una base de datos PostgreSQL con las reservas.
3. Un script que Marta ejecuta cada mañana para generar un informe.
4. El archivo casas.txt con el catálogo de casas rurales que la aplicación sirve a las agencias.
5. Un archivo temporal de 3 GB generado durante una migración, que debe sobrevivir a un reinicio.
6. Una versión de nginx compilada a mano con módulos especiales.

Ejecutas ls -l en un directorio y obtienes esta salida:

1. Identifica el tipo de cada elemento y explica cómo lo has determinado.
2. ¿Por qué dos de ellos muestran dos números donde los demás muestran un tamaño? ¿Qué significan esos números?
3. ¿Qué pasaría si borrases el elemento actual? ¿Y si borrases /var/log/tramontana?

Luis Ferrer te propone esta estructura para desplegar Tramontana Reservas:

Argumenta, punto por punto, cuatro problemas concretos de esta propuesta, y presenta la estructura alternativa con su justificación FHS. Para cada problema, describe un escenario real en el que causaría un incidente.

Solución al Ejercicio 1

1. Certificado TLS → /etc/ssl/certs/ (o /etc/tramontana/ssl/). Estático y no compartible. Es configuración: solo cambia cuando se renueva, y es específico de esta máquina y de su dominio. Va en /etc por definición. La clave privada asociada debe ir en /etc/ssl/private/ con permisos muy restrictivos, porque quien la obtenga puede suplantar al servidor. Se trata en la lección 06-05.

2. Base de datos PostgreSQL → /var/lib/postgresql/. Variable y no compartible. Cambia continuamente con cada reserva; es estado persistente de un servicio, que es exactamente la definición de /var/lib. Es la ubicación que PostgreSQL usa por defecto en Ubuntu, y respetarla asegura que las herramientas de copia y las políticas de SELinux o AppArmor esperen encontrarla ahí.

3. Script de informe diario → /usr/local/bin/ (o /opt/tramontana/bin/). Este tiene matiz. Mientras se está desarrollando, /home/operador/scripts está bien. Pero el enunciado dice que Marta lo ejecuta cada mañana: es una herramienta operativa de la que depende alguien más. Debe pasar a /usr/local/bin, que es el sitio del FHS para ejecutables locales añadidos por el administrador, con dos ventajas: está en el PATH de todos los usuarios (Marta lo invoca por su nombre, sin ruta) y no depende de que la cuenta operador siga existiendo.

4. casas.txt servido a las agencias → /srv/tramontana/. Variable y compartible. La palabra clave del enunciado es sirve: son datos que este servidor entrega a terceros, que es la definición literal de /srv en el FHS. Si se sirviera exclusivamente por web mediante nginx, /var/www/ sería también defendible; /srv es preferible cuando los datos se sirven por varios canales o pertenecen conceptualmente al servicio.

5. Temporal de 3 GB que sobrevive al reinicio → /var/tmp/. Los dos requisitos apuntan al mismo sitio. /tmp queda descartado porque se vacía al reiniciar (y en muchos sistemas es un tmpfs en RAM, donde 3 GB serían un problema serio de memoria). /var/tmp está pensado precisamente para temporales persistentes entre reinicios, y está en disco.

6. nginx compilado a mano → /usr/local/. Estático y compartible. /usr/local es el árbol paralelo reservado al software que el administrador compila e instala manualmente: el binario en /usr/local/sbin/nginx, la configuración en /usr/local/etc/nginx/. Su razón de ser es no colisionar con /usr, que pertenece al gestor de paquetes: así una actualización de Ubuntu nunca sobrescribirá tu compilación, y tu compilación nunca romperá el paquete oficial.

Solución al Ejercicio 2

1. Tipos, determinados por la primera letra de cada línea:

Detalles que confirman cada lectura: el enlace muestra -> /var/log/tramontana y tiene permisos rwxrwxrwx (los enlaces simbólicos siempre los tienen; los que cuentan son los del destino). El dispositivo de bloque pertenece al grupo disk, lo habitual en los discos. Y vacio con números 1, 3 es en realidad /dev/null: esos son sus números mayor y menor característicos.

2. Los dos números.

Los muestran disco-datos (8, 16) y vacio (1, 3), los dos dispositivos. En un archivo normal, esa columna indica el tamaño en bytes; un dispositivo no tiene tamaño porque no contiene datos: es una puerta de acceso a un controlador del kernel.

En su lugar aparecen:

• El número mayor identifica el controlador del kernel que gestiona el dispositivo. El 8 corresponde a los discos SCSI/SATA; el 1 a los dispositivos de memoria, entre los que está /dev/null.
• El número menor identifica cuál de los dispositivos que gestiona ese controlador es. El 16 corresponde a /dev/sdb (el 0 sería /dev/sda); el 3 a /dev/null concretamente.

Es decir, disco-datos es el segundo disco del sistema y vacio es el agujero negro.

3. Consecuencias de borrar.

Si borras actual: no pasa nada relevante. Un enlace simbólico es solo un puntero, un archivo diminuto que contiene una ruta como texto. Borrarlo elimina el atajo; el directorio /var/log/tramontana y todo su contenido siguen intactos. Puedes recrear el enlace en un segundo.

Si borras /var/log/tramontana: pierdes los logs de verdad. Y además el enlace actual queda roto (dangling): sigue existiendo y apuntando a una ruta que ya no existe. Cualquier programa que intente seguirlo recibirá un error de tipo «No existe el fichero o el directorio», lo que resulta confuso porque el enlace sí aparece al listar el directorio.

Los enlaces rotos se detectan fácilmente porque ls los muestra en rojo parpadeante en la mayoría de terminales con color.

Esta asimetría —el enlace depende del destino, el destino no depende del enlace— es la característica esencial de los enlaces simbólicos, y explica en qué se diferencian de los enlaces duros. Es el tema de la lección 02-06.

Solución al Ejercicio 3

Problema 1: todo cuelga de un directorio personal.

Toda la infraestructura de producción depende de la existencia de la cuenta luis. /home está reservado a datos personales de usuarios, no a servicios.

Escenario de incidente: Luis deja la empresa. Se sigue el procedimiento normal de baja: eliminar la cuenta con userdel -r, que borra el directorio personal. Se borra la aplicación en producción, su configuración, sus logs y sus copias de seguridad, todo a la vez. Nadie relacionó dar de baja a un empleado con destruir el servicio, porque en un sistema bien organizado no tiene por qué haber relación.

Un incidente equivalente y más silencioso: los permisos de /home/luis restringen el acceso, y el usuario del servicio web (www-data) no puede leer la aplicación. Se acaba resolviendo con permisos demasiado abiertos sobre un directorio personal, lo que abre un agujero de seguridad.

Problema 2: los logs conviven con la aplicación.

logs/ está dentro del mismo árbol que app/, mezclando datos variables con datos estáticos.

Escenario de incidente: un fallo en el código provoca un bucle que escribe en errores.log sin parar. El log crece hasta llenar la partición que contiene /home, que en muchas instalaciones es la misma que /. Con el disco raíz lleno, el sistema no puede escribir archivos temporales: los servicios empiezan a fallar en cascada, journald no puede registrar nada y puede que ni siquiera se pueda iniciar sesión para diagnosticarlo. Con los logs en /var/log y /var en su propia partición, el daño habría quedado contenido.

Segundo efecto: logrotate no gestiona esos logs, porque no están donde espera. Nadie los comprime ni los elimina, así que crecen indefinidamente.

Problema 3: la configuración está dentro de la aplicación.

config/app.conf cuelga del mismo árbol que el código.

Escenario de incidente: Luis despliega la versión 2.0 borrando y recreando el directorio tramontana/. Se pierde app.conf con la cadena de conexión a la base de datos y las credenciales. El servicio no arranca y hay que reconstruir la configuración de memoria, en plena caída, con la presión de tener el servicio parado.

Problema estructural asociado: al no estar separada, no se puede desplegar el mismo artefacto en pruebas y en producción con configuraciones distintas. Se acaba manteniendo dos copias divergentes del código, que es como aparecen los fallos que «solo pasan en producción».

Problema 4: las copias están en el mismo árbol que los datos.

backups/ está dentro de /home/luis/tramontana/, es decir, en el mismo disco y bajo el mismo directorio que protege.

Escenario de incidente: falla el disco. Se pierden a la vez los datos originales y todas las copias de seguridad. También basta un rm -rf mal dirigido sobre /home/luis/tramontana/: se lleva por delante el objeto de la copia y la copia misma.

Una copia de seguridad que comparte destino con el original protege únicamente contra el borrado selectivo de un archivo. No protege contra el fallo de hardware, ni contra un borrado amplio, ni contra un cifrado por ransomware, que son precisamente los escenarios que justifican tener copias.

Estructura alternativa:

Cómo presentárselo a Luis (porque tener razón no basta): el argumento que convence no es «el FHS lo dice», sino los cuatro escenarios de incidente. La estructura correcta no es más burocrática: es la que hace que dar de baja a un empleado no tumbe el servicio, que un log desbocado no llene el disco raíz, que un despliegue no borre las credenciales y que las copias sirvan de algo cuando falle el disco. Además, cuesta lo mismo montarla bien desde el principio que montarla mal.

Con esta lección cierras el Módulo 1 y tienes el mapa completo del territorio:

• Linux organiza el almacenamiento en un único árbol desde /, no en unidades separadas, y el montaje es lo que conecta dispositivos a puntos de ese árbol, separando la estructura lógica de la disposición física.
• El FHS define qué va en cada directorio y es lo que hace predecible cualquier sistema Linux: /etc para la configuración, /var para lo que crece, /usr para el software del sistema, /opt para aplicaciones de terceros, /srv para lo que se sirve, /home para los usuarios.
• La clasificación estático/variable y compartible/no compartible no es teoría: determina qué respaldas, qué montas en solo lectura, qué necesita partición propia y dónde colocas lo tuyo.
• Todo es un archivo, y ls -l te dice de qué tipo por su primera letra: -, d, l, c, b, s, p. Los dispositivos como /dev/null, /dev/zero y /dev/sda son puertas a controladores del kernel.
• /proc y /sys no ocupan disco: son ventanas al kernel generadas al vuelo, y son la fuente de la que beben herramientas como free, uptime y ps.
• Los archivos ocultos son solo una convención de nombre, y . y .. son entradas reales de cada directorio.
• Las rutas absolutas parten de / y son las que debes usar en scripts; las relativas parten de donde estés y son cómodas al trabajar a mano.
• Y sabes justificar, con el estándar en la mano, por qué Tramontana Reservas va en /opt/tramontana/app, su configuración en /etc/tramontana/, sus logs en /var/log/tramontana/, sus copias en /srv/tramontana/backups y tus scripts en /home/operador/scripts.

Haz balance de dónde estabas al empezar el módulo y dónde estás ahora. Sabes qué es Linux y qué es exactamente el kernel; conoces la filosofía Unix que explica el diseño de todo lo que verás; entiendes el panorama de distribuciones y por qué Ubuntu Server 24.04 LTS es la elección correcta para srv-tramontana; tienes el servidor instalado, verificado, actualizado y con snapshots; sabes leer el prompt, ejecutar comandos básicos y hacer el reconocimiento de una máquina; y tienes el mapa completo de su sistema de archivos. Eso es un laboratorio funcionando y un vocabulario común con cualquier administrador de sistemas.

Hasta ahora has mirado. En el Módulo 2: Comandos Básicos empezarás a trabajar de verdad: aprenderás a manejar la línea de comandos con soltura, a consultar la documentación del sistema para no depender de buscadores, a navegar por el árbol de directorios que acabas de conocer, a crear, copiar, mover y borrar archivos, a ver y editar su contenido, a manejar enlaces duros y simbólicos, y a dominar los permisos y la propiedad, que es la pieza que separa un servidor que funciona de un servidor que además es seguro. Prepara tu snapshot, abre una sesión en srv-tramontana y nos vemos en la primera lección.