Durante todo el módulo has trabajado con una suposición implícita: que cada nombre corresponde a un archivo y cada archivo tiene un nombre. Esa suposición es falsa, y entender por qué es lo que separa a quien usa Linux de quien lo comprende.

En un sistema de archivos Unix, el nombre y el contenido son cosas separadas. El contenido vive en una estructura llamada inodo; el nombre es simplemente una entrada en un directorio que apunta a ese inodo. Nada impide que dos entradas apunten al mismo sitio, ni que exista un archivo cuyo contenido sea la ruta de otro. De ahí salen los dos tipos de enlaces de esta lección.

No es teoría de sistemas de archivos por curiosidad. Los enlaces están por todas partes en un sistema Linux: /bin es un enlace, tu python3 es un enlace, y el sistema con el que Debian y Ubuntu deciden qué versión de una herramienta se usa está construido sobre enlaces. Y al final de la lección diseñarás el patrón con el que Tramontana Reservas convertirá un despliegue —y una vuelta atrás— en un cambio de enlace instantáneo, sin ventana de servicio caído.

1. Qué es un inodo
2. Ver el inodo y el contador de enlaces
3. Enlaces duros con ln
4. Las dos limitaciones de los enlaces duros
5. Enlaces simbólicos con ln -s
6. Absolutos frente a relativos
7. Enlaces rotos
8. Qué comandos siguen el enlace y cuáles no
9. Duro frente a simbólico: la tabla
10. Enlaces en un sistema Linux real
11. update-alternatives
12. El patrón de despliegue de Tramontana

Cuando guardas un archivo, el sistema de archivos crea tres cosas distintas:

1. Los bloques de datos: el contenido en sí, repartido por el disco.
2. El inodo: una estructura con todos los metadatos del archivo —permisos, propietario, grupo, tamaño, marcas de tiempo, contador de enlaces y las direcciones de los bloques de datos—. Cada inodo tiene un número único dentro de su sistema de archivos.
3. La entrada de directorio: un par (nombre, número de inodo) almacenado en el directorio.

Fíjate en lo que no contiene el inodo: el nombre del archivo. El nombre no es una propiedad del archivo; es una propiedad del directorio que lo contiene.

Un directorio, visto así, no contiene archivos: contiene una lista de nombres con números de inodo. Es un índice.

Esta arquitectura explica de golpe varias cosas que hasta ahora eran hechos sueltos:

Ese penúltimo punto es la explicación definitiva del misterio de la lección 02-03: borras un log de 2 GB, du deja de verlo, pero df sigue diciendo que el espacio está ocupado. El nombre desapareció; el inodo sigue vivo porque el proceso lo tiene abierto, y con él sus bloques. Hasta que el proceso no cierre el archivo —o lo reinicies— no se libera nada.

Dos herramientas que ya conoces, ahora con la mirada puesta en los enlaces.

La primera columna con -i es el número de inodo. La columna que va justo después de los permisos —el 1— es el contador de enlaces: cuántos nombres apuntan a este inodo.

stat lo dice con todas las letras:

Nodo-i: 262149 y Enlaces: 1. Ese contador es el que gobierna cuándo se libera el espacio de un archivo, como verás en el apartado siguiente.

Y ahora se entiende el comportamiento de los directorios que quedó pendiente en la lección 02-03:

Contador 4, no 1. Los cuatro nombres que apuntan a ese inodo son:

1. La entrada app dentro de /opt/tramontana.
2. La entrada . dentro de /opt/tramontana/app.
3. La entrada .. dentro de /opt/tramontana/app/plantillas.
4. La entrada .. dentro de otro subdirectorio.

De ahí la fórmula: enlaces de un directorio = 2 + número de subdirectorios. Un directorio sin subdirectorios tiene 2; uno con siete subdirectorios tiene 9.

Un número de inodo solo tiene sentido dentro de su sistema de archivos. Dos archivos en discos distintos pueden tener el mismo número sin relación alguna. Por eso, para comparar, hay que mirar también el dispositivo:

El par dispositivo:inodo sí identifica un archivo de forma única en toda la máquina.

Un enlace duro es, sencillamente, otra entrada de directorio que apunta al mismo inodo. No es una copia ni un acceso directo: es otro nombre igual de legítimo para el mismo archivo.

Tres cosas que confirmar en esa salida:

1. Mismo inodo (262149) en las dos primeras líneas.
2. El contador subió a 2 en ambas: hay dos nombres apuntando ahí.
3. El tamaño se muestra dos veces (418 y 418), pero el archivo ocupa 418 bytes en total, no 836. ls muestra el tamaño del inodo, y el inodo es el mismo.

Ese último punto tiene una consecuencia práctica: du cuenta el espacio una sola vez si encuentra los dos nombres en el mismo recorrido, pero puede contarlo dos veces si están en recorridos distintos. Es una fuente clásica de descuadres al calcular el tamaño de copias de seguridad con enlaces duros.

No hay original ni copia. Los dos nombres son exactamente equivalentes; el sistema no guarda cuál se creó primero. Modificar uno modifica el otro, porque son el mismo archivo:

Y lo mismo con los metadatos: chmod sobre uno cambia los permisos del otro, porque los permisos están en el inodo.

Aquí está el comportamiento que hay que entender bien:

El contenido sigue intacto. rm no borra archivos: decrementa el contador de enlaces y elimina el nombre. El inodo y sus bloques solo se liberan cuando ocurren dos cosas a la vez:

• El contador de enlaces llega a 0.
• Ningún proceso tiene el archivo abierto.

Por eso el comando de bajo nivel se llama unlink(), no delete(). rm es literalmente «desenlazar».

Los tres desenlaces posibles de un rm:

La tercera fila es la del misterio del espacio que no se libera. Y también es un mecanismo que se usa a propósito: un programa que necesita un archivo temporal puede crearlo, abrirlo y borrarlo inmediatamente. El archivo sigue funcionando mientras el programa lo tenga abierto, y desaparece automáticamente cuando el programa termina, incluso si se cierra de forma anormal. No hay que limpiar nada.

El porqué: un enlace duro es una entrada (nombre, número de inodo). El número de inodo solo tiene significado dentro de su sistema de archivos: el inodo 262149 de /dev/sda2 no tiene nada que ver con el inodo 262149 de /dev/sda1. Una entrada en un directorio de /boot que dijera «262149» apuntaría al inodo 262149 de /boot, que es otro archivo completamente distinto.

No es una restricción arbitraria: es que la referencia no significa nada fuera de su ámbito.

Cómo saber si dos rutas están en el mismo sistema de archivos, antes de intentarlo:

/home y /opt comparten /dev/sda2: se puede enlazar entre ellos. /boot está en /dev/sda1: no.

Ni siquiera root puede en Linux. El porqué es más interesante:

El árbol de directorios de Unix es, por diseño, un grafo acíclico: se puede bajar y subir, pero no dar vueltas en círculo. Si pudieras crear un enlace duro a un directorio, podrías construir un bucle:

Consecuencias inmediatas:

• find, du, tar, rsync y cualquier recorrido recursivo entrarían en un bucle infinito, porque no habría forma de detectar que ya han pasado por ahí sin llevar registro de cada inodo visitado.
• El contador de enlaces dejaría de servir para saber cuándo liberar el espacio: un ciclo de directorios que se referencian mutuamente tendría contadores mayores que cero aunque nadie pudiera llegar hasta ellos desde la raíz. Sería basura inalcanzable e imposible de recolectar.
• .. dejaría de tener sentido único: un directorio con dos padres no puede tener un solo ...

Las entradas . y .. son la excepción: son enlaces duros a directorios, creados por el kernel, y por eso los contadores de los directorios valen más de 1. Pero están controlados y su topología es conocida, así que no rompen nada.

Ambas limitaciones desaparecen con el otro tipo de enlace.

Un enlace simbólico (o symlink, o enlace blando) es un archivo de pleno derecho, con su propio inodo, cuyo contenido es una ruta de texto. Cuando algo lo abre, el kernel lee esa ruta y redirige la operación.

Todo lo que hay que leer ahí:

Ese tamaño confirma qué es un symlink: un archivo cuyo contenido es una cadena de texto.

Al usarlo, todo funciona como si fuera el destino:

Y las dos limitaciones del enlace duro no existen:

Cruza sistemas de archivos y apunta a directorios sin problema, porque no referencia un inodo: referencia una ruta, y una ruta es texto que se resuelve en el momento de usarla.

Un enlace a un directorio se comporta como el directorio:

Ahí tienes la explicación de pwd -P que quedó pendiente en la lección 02-03: pwd muestra la ruta lógica, la que usaste para llegar; pwd -P la física, resolviendo los enlaces.

Opciones de ln que conviene conocer:

La combinación -sfn es la del despliegue y la verás en acción en el apartado 12. Sin -n, reemplazar un enlace que apunta a un directorio crea el nuevo enlace dentro de ese directorio en lugar de sustituirlo, que es un error muy fácil de cometer.

El contenido de un enlace simbólico es una ruta, y esa ruta puede ser de los dos tipos.

Los dos funcionan igual ahora mismo. Se diferencian en qué pasa cuando algo se mueve.

Un enlace relativo se resuelve desde el directorio donde está el enlace, no desde donde estés tú:

Funciona desde tu home porque releases/3.2.1 se resuelve relativo a /opt/tramontana/, que es donde vive el enlace.

Ahora, la prueba que los distingue: copiar todo el árbol a otro sitio.

• app-abs sigue apuntando a /opt/tramontana/..., es decir, al árbol original. La copia no es autocontenida: depende del original. Si borras /opt/tramontana, la copia queda rota.
• app-rel apunta a releases/3.2.1 dentro de la copia. El árbol copiado es autónomo y consistente.

Criterio de uso:

• Relativos dentro de un mismo árbol de aplicación (/opt/tramontana/app → releases/...), porque el conjunto se copia, se respalda y se restaura como una unidad.
• Absolutos cuando el destino está en otra parte del sistema y no tiene relación estructural con el enlace (por ejemplo, un enlace en tu home hacia /var/log/tramontana).

ln -r calcula el relativo por ti:

Le das rutas absolutas, que son fáciles de escribir con Tab sin equivocarse, y él genera el enlace relativo correcto. Es la mejor de las dos opciones.

Como un symlink guarda una ruta y no una referencia al inodo, nada garantiza que el destino exista. Puedes crear un enlace a algo que aún no existe, y el destino puede desaparecer después.

ls -l muestra el enlace sin quejarse, porque el enlace existe perfectamente: es el destino el que no. Solo al intentar usarlo aparece el error, y el mensaje menciona el nombre del enlace, lo que confunde: parece que no existe ~/futuro cuando ~/futuro está ahí.

Con color activado, ls muestra los enlaces rotos en rojo parpadeante, que es difícil de pasar por alto. Para detectarlos de forma fiable:

find -xtype l significa «elementos que, al resolver el enlace, son de tipo enlace», lo que solo ocurre si el enlace no se puede resolver. find se estudia a fondo en la lección 03-03; esta invocación puedes adoptarla ya como receta.

Y readlink es la herramienta específica para inspeccionar enlaces:

readlink -e es el verificador: código 0 si el enlace lleva a algo real, distinto de 0 si está roto. Es exactamente lo que usarás en el script de despliegue para comprobar que el enlace app apunta a un release existente antes de arrancar el servicio.

Un enlace roto no siempre es un error. Es una situación normal cuando el destino se creará más tarde, o cuando apunta a un dispositivo extraíble que ahora no está montado. Lo que no debe haber son enlaces rotos que nadie sabe por qué están ahí.

Esta es la parte que provoca más errores en la práctica: cada comando decide por su cuenta si actúa sobre el enlace o sobre su destino.

Los tres casos que hay que tener claros:

rm sobre un enlace borra el enlace. Siempre. Es seguro:

El destino sigue intacto. Este es el comportamiento que la gente teme y que en realidad nunca falla.

cp sin -a deshace los enlaces:

cp normal produjo un archivo real con el contenido; cp -P produjo un enlace. Al copiar un árbol con enlaces, esta diferencia decide si obtienes una copia fiel o una copia inflada donde cada enlace se ha convertido en una copia completa del archivo.

La trampa de la barra final con enlaces a directorios. Esta muerde a todo el mundo:

La barra final significa «trátalo como directorio», y eso obliga al kernel a resolver el enlace. Y ahora lo peligroso:

Esa última línea, con -rf y barra final, atraviesa el enlace y borra el contenido de /opt/tramontana/app. La aplicación de producción, eliminada por una barra de más.

Regla de oro: nunca pongas barra final después del nombre de un enlace en un comando destructivo. Y en general, antes de un rm -rf sobre algo que podría ser un enlace, comprueba:

Cuándo elegir cada uno, en la práctica:

Usa enlaces simbólicos por defecto. Son visibles en ls -l, dicen a dónde apuntan, cruzan sistemas de archivos, funcionan con directorios y se pueden reemplazar de forma atómica. El 95 % de los enlaces que crearás y que encontrarás en un sistema Linux son simbólicos.

Usa enlaces duros en dos casos concretos:

1. Copias de seguridad incrementales con deduplicación. rsync --link-dest crea una copia completa aparente de cada día, pero los archivos que no han cambiado son enlaces duros a los del día anterior: ocupan cero espacio adicional. Es la base de las copias tipo Time Machine y lo verás en la lección 05-08.
2. Cuando necesitas que el archivo sobreviva al borrado del nombre original, sin que quede un enlace roto.

Los enlaces no son una curiosidad: son estructura del sistema.

La raíz misma:

Es la reorganización conocida como /usr-merge: los binarios se consolidaron bajo /usr y se dejaron enlaces en la raíz para que las miles de referencias existentes a /bin/bash siguieran funcionando. Esto es lo que veías con la flecha en tree -L 1 / en la lección 02-03.

Fíjate en que son relativos (usr/bin, no /usr/bin). Deliberadamente: así siguen siendo válidos si el árbol se monta en otro punto, por ejemplo al reparar el sistema desde un disco de rescate montado en /mnt.

El intérprete de Python:

python3 es un enlace a la versión concreta. Actualizar Python a la 3.13 es, en esencia, cambiar ese enlace: todos los scripts que empiezan por #!/usr/bin/python3 pasan a usar la versión nueva sin tocar ni uno.

Cadenas de enlaces:

Dos saltos. readlink -f sigue la cadena entera hasta el final. El kernel permite hasta unos 40 niveles de anidamiento antes de dar Demasiados niveles de enlaces simbólicos.

Los servicios de systemd:

Habilitar un servicio en systemd es literalmente crear un enlace simbólico, y deshabilitarlo es borrarlo. Cuando ejecutes systemctl enable en la lección 05-05, lo que ocurrirá por debajo es un ln -s.

Los logs rotados:

Aquí no hay enlaces, pero conviene saber que algunos servicios mantienen current.log como enlace al fichero del día.

Debian y Ubuntu resuelven con enlaces un problema concreto: varios paquetes que proporcionan la misma función. ¿Qué editor abre sudo editor? ¿Qué java se ejecuta si hay tres instaladas? ¿Qué es vi si hay vim, nvi y elvis?

El mecanismo es una doble capa de enlaces simbólicos:

La primera capa es fija y está en el PATH. La segunda, en /etc/alternatives/, es la que se cambia. Así el administrador nunca toca /usr/bin, que pertenece a los paquetes.

Cambiarlo:

El enlace de la segunda capa ha cambiado. Órdenes principales:

Por qué importa esto para el EDITOR de tu sesión: cuando ejecutes sudo visudo o crontab -e, el editor que se abre lo decide la variable de entorno EDITOR y, si no está definida, la alternativa editor. Si nunca has configurado nada y te aparece nano, ahora sabes por qué y cómo cambiarlo. La variable EDITOR es de la lección 03-01.

Aquí es donde todo lo anterior se convierte en una decisión de arquitectura. Es el patrón que Tramontana Reservas va a adoptar y que reaparecerá en la lección 04-07 y en el Módulo 8.

Hoy, el despliegue de una versión nueva significaría: parar el servicio, borrar o mover /opt/tramontana/app, copiar la versión nueva, arrancar. Problemas:

• Ventana de indisponibilidad proporcional al tiempo de copia. Copiar 48 MB tarda segundos; en producción, copiar una release grande puede tardar minutos.
• Estado intermedio inconsistente: durante la copia, el directorio tiene mitad de la versión vieja y mitad de la nueva. Si el servicio arranca en ese momento, se comporta de forma impredecible.
• Volver atrás es otro despliegue completo, con su propia ventana y sus propios riesgos, ejecutado bajo presión porque algo ha fallado.
• La versión anterior ya no está, así que volver atrás requiere recuperarla de una copia.

Separar el contenido (los releases, cada uno en su directorio inmutable) de el puntero (un enlace simbólico que dice cuál está activo).

El despliegue completo:

La vuelta atrás:

Un comando. Ese es todo el rollback. Sin copiar nada, sin recuperar de una copia de seguridad, sin ventana de mantenimiento. Y se puede ejecutar a las tres de la mañana por alguien nervioso sin riesgo de equivocarse.

Las tres letras importan:

• -s simbólico, obviamente.
• -f fuerza el reemplazo. Sin ella, ln falla porque app ya existe.
• -n es la crítica. Sin -n, ln ve que app es un enlace a un directorio, entra dentro y crea el enlace ahí:

Ha creado releases/3.2.1/3.3.0 en lugar de cambiar app. El enlace app sigue apuntando a la versión vieja, el servicio no se actualiza y encima has ensuciado el directorio del release anterior, que debía ser inmutable. -n siempre.

Reemplazar un enlace simbólico se hace, por debajo, con la llamada al sistema rename(), que el kernel garantiza como atómica: no hay un instante en el que app no exista o apunte a medias. Cualquier proceso que abra /opt/tramontana/app en cualquier momento verá o la versión vieja completa o la nueva completa, nunca un estado intermedio.

Compara con la alternativa ingenua de rm app && ln -s releases/3.3.0 app: entre las dos órdenes hay una ventana, breve pero real, en la que app no existe. Un proceso que intente abrir un archivo justo entonces recibirá un error. Por eso el patrón es ln -sfn, en un solo comando.

La contrapartida está en la última fila: hay que eliminar los releases antiguos o /opt crecerá sin límite. La política habitual es conservar los tres o cinco últimos, y el script que lo hace lo escribirás en el Módulo 4.

Otro detalle del esquema: el directorio shared/. Los datos que deben sobrevivir a los despliegues —ficheros subidos por los usuarios, cachés persistentes— no pueden vivir dentro del release, porque el release siguiente no los tendría. Se ponen en shared/ y cada release los enlaza:

Este patrón, que aquí montas a mano, es exactamente el que implementan las herramientas de despliegue profesionales (Capistrano lo popularizó, y las estructuras de despliegue de muchos PaaS lo replican). Lo automatizarás con un script en la lección 04-07 y lo pondrás en producción en el Módulo 8.

Creer que un enlace duro es una copia. Modificas uno y cambias los dos, porque son el mismo archivo.

Creer que borrar un enlace duro borra los datos. Solo si era el último nombre.

Hacer ln -sf sin -n sobre un enlace a directorio. Crea el enlace dentro en vez de sustituirlo, silenciosamente.

Poner barra final tras un enlace en un rm -rf. Atraviesa el enlace y borra el destino real. El error más caro de esta lección.

Copiar árboles con enlaces usando cp -r. Convierte los enlaces en copias reales e infla el resultado. Usa cp -a o rsync -a.

Usar enlaces absolutos dentro de un árbol que se va a copiar o mover. La copia acaba dependiendo del original. ln -sr.

Confiar en ls -l para saber si un enlace funciona. Muestra los rotos igual que los buenos. readlink -e o find -xtype l.

Consejo: readlink -f antes de cualquier operación destructiva sobre una ruta que pueda contener enlaces. Te dice a dónde apunta de verdad.

Consejo: pon los enlaces relativos dentro de un mismo árbol y absolutos entre árboles distintos. Es la regla que evita el 90 % de los enlaces rotos.

Consejo: find /ruta -xtype l de vez en cuando. Los enlaces rotos son un síntoma: algo se movió o se borró y nadie actualizó lo que apuntaba a ello.

Consejo: documenta los enlaces estructurales. Un README en /opt/tramontana explicando el patrón de releases evita que el próximo administrador borre releases/ pensando que sobra.

En /tmp, sin mirar la teoría:

1. Crea original.txt con tres líneas. Anota su inodo y su contador de enlaces.
2. Crea un enlace duro duro.txt y un enlace simbólico blando.txt. Muestra los tres con ls -li y explica cada columna.
3. Añade una línea a través de duro.txt. ¿Qué ven original.txt y blando.txt?
4. Borra original.txt. ¿Qué pasa con cada uno de los otros dos? Explica por qué en términos de inodos.
5. Vuelve a crear un original.txt nuevo con contenido distinto. ¿A qué apunta ahora blando.txt? ¿Y duro.txt?

Monta en srv-tramontana la estructura de releases completa:

1. Crea /opt/tramontana/releases/3.2.1 con el contenido actual de /opt/tramontana/app.
2. Sustituye /opt/tramontana/app por un enlace relativo a ese release, sin que el contenido deje de estar accesible en ningún momento verificable.
3. Simula el despliegue de una versión 3.3.0 y actívala.
4. Simula que falla y vuelve a 3.2.1.
5. Escribe una comprobación de una línea que verifique que el enlace apunta a un release que existe realmente.

Luis ha montado en su portátil un directorio de trabajo compartido y te pasa esto para que lo repliques en el servidor:

Marta te pregunta si puede aprobarlo. Analiza la propuesta, enumera los problemas y propón la alternativa correcta con su justificación.

Solución 1

Inodo 393221, contador 1: un solo nombre apunta ahí.

Lectura columna a columna:

• duro.txt y original.txt comparten el inodo 393221 y ambos muestran contador 2. Son dos nombres del mismo archivo, sin jerarquía entre ellos.
• blando.txt tiene inodo propio (393225), tipo l, permisos lrwxrwxrwx (que no significan nada), tamaño 12 —los caracteres de original.txt— y la flecha al destino.

Los tres ven lo mismo. duro.txt y original.txt porque son el mismo inodo; blando.txt porque resuelve a original.txt, que sigue existiendo.

duro.txt funciona perfectamente y su contador ha bajado de 2 a 1. rm eliminó una entrada de directorio y decrementó el contador; como no llegó a 0, el inodo y sus datos siguen ahí.

blando.txt está roto. Contenía el texto original.txt, y ese nombre ya no existe en el directorio. El enlace no guardaba ninguna referencia al inodo, solo una cadena.

Este último paso es el que fija el concepto:

• blando.txt se ha «arreglado» solo y ahora apunta al archivo nuevo, que tiene un inodo distinto (393230). El enlace simbólico se resuelve por nombre, en el momento de usarlo, así que sigue a cualquier archivo que ocupe ese nombre. Esa es su virtud y su peligro: puede acabar apuntando a algo que no tiene nada que ver con lo original.
• duro.txt sigue con el contenido antiguo en el inodo 393221. Nunca dependió del nombre.

Resumen en una frase: el enlace duro está atado al contenido; el simbólico está atado al nombre.

Solución 2

rsync -a con barra final en el origen copia el contenido, no la carpeta. Y diff -rq sin salida confirma que la copia es idéntica antes de tocar nada.

El detalle importante es mv en lugar de rm en el paso intermedio. Renombrar es instantáneo y reversible; borrar no. Si el enlace hubiera salido mal, un mv de vuelta lo restauraba todo.

Un comando y estás en la versión anterior. Y releases/3.3.0 sigue en disco, así que reintentar el despliegue después de corregir el problema es otro comando.

Desglose: readlink -e resuelve el enlace y falla con código distinto de 0 si el destino no existe. Con && y || de la lección 02-01, la línea informa en ambos casos. Es exactamente la comprobación que irá al principio del script de despliegue del Módulo 4, para no arrancar nunca el servicio con el enlace apuntando a la nada.

Solución 3

Problemas de la propuesta de Luis, de más a menos grave:

1. Producción dependería del directorio personal de un desarrollador. El enlace apunta a /home/luis/proyectos/tramontana/build. Eso significa que la aplicación en producción se ejecuta con el código que Luis tenga en su carpeta de trabajo en ese instante. Cada vez que Luis compile, producción cambia. Sin revisión, sin aprobación de Marta, sin aviso. Es exactamente el escenario que el proceso de despliegue existe para impedir.

2. Ese directorio no existe en srv-tramontana. /home/luis es una ruta del portátil de Luis. En el servidor, el enlace nacería roto:

ls -l lo muestra tan tranquilo, pero el servicio no arrancaría. Y el mensaje de error sería No existe el fichero /opt/tramontana/app, cuando app sí existe: es el destino el que no. Diagnosticar eso sin conocer los enlaces cuesta un buen rato.

3. sudo rm app destruye el original antes de tener nada. Si el nuevo enlace sale mal —y va a salir mal—, la aplicación ya no está. No hay vuelta atrás. Debería ser mv, y solo borrar cuando lo nuevo esté verificado.

4. Rompe el FHS. El Módulo 1 justificó /opt/tramontana/app precisamente porque /home/usuario/proyecto es el peor sitio posible: dar de baja a un empleado tumba el servicio. Aquí el enlace reintroduce esa dependencia por la puerta de atrás, con el agravante de que en ls -l /opt/tramontana parece que todo está bien.

5. Problema de permisos y seguridad. El código de producción quedaría bajo el control de un usuario sin privilegios, que puede modificarlo en cualquier momento sin sudo. Cualquiera que comprometa la cuenta de Luis controla la aplicación en producción. La lección 02-07 te dará el vocabulario exacto para explicar por qué esto es grave.

6. No hay versionado ni forma de volver atrás. No se sabe qué versión está desplegada ni cómo recuperar la anterior.

Alternativa correcta, que es el patrón del apartado 12:

Respuesta para Marta:

No conviene aprobar la propuesta tal como está. La idea de fondo —poder cambiar de versión rápidamente— es buena, y de hecho es la que vamos a implementar; el problema es la ejecución concreta.

Tal como está planteada, la aplicación en producción pasaría a ejecutar directamente el directorio de trabajo del portátil de Luis. Eso significa tres cosas: que cualquier compilación suya cambiaría producción al instante y sin aviso, que no sabríamos en ningún momento qué versión está funcionando, y que si Luis se va de la empresa o cambia de portátil, el servicio deja de funcionar. Además, en el servidor esa ruta ni siquiera existe, así que el cambio dejaría la aplicación caída de inmediato.

La alternativa que propongo consigue el mismo objetivo con garantías: cada versión se instala en su propio directorio numerado dentro del servidor, y un puntero indica cuál está activa. Desplegar es cambiar el puntero, y volver a la versión anterior también, en ambos casos con un solo comando y sin copiar nada. La versión anterior permanece intacta en el servidor, así que la vuelta atrás es inmediata y segura. Y en todo momento se puede consultar qué versión está en producción y quién la aprobó.

Se lo comento a Luis: lo que necesitamos de él es el paquete de la versión, no acceso directo desde su equipo.

Has desmontado la suposición con la que empezaste el módulo: un archivo no es un nombre.

• Un inodo guarda todos los metadatos y las direcciones de los bloques, menos el nombre. Los directorios son índices de pares (nombre, inodo).
• Esa arquitectura explica por qué mv es instantáneo, por qué . comparte inodo con su directorio, por qué se puede borrar un archivo abierto y por qué df y du a veces no cuadran.
• Un enlace duro es otro nombre para el mismo inodo. rm desenlaza: el contenido vive mientras el contador no llegue a cero y nadie lo tenga abierto.
• Los enlaces duros no cruzan sistemas de archivos porque el número de inodo no significa nada fuera del suyo, y no apuntan a directorios porque permitirían ciclos que romperían los recorridos recursivos y la recolección de espacio.
• Un enlace simbólico es un archivo cuyo contenido es una ruta. Cruza sistemas de archivos, apunta a directorios, puede apuntar a lo que no existe, y se resuelve por nombre en el momento de usarlo.
• Relativos dentro de un mismo árbol, absolutos entre árboles distintos, y ln -sr los calcula por ti.
• Los enlaces rotos no los detecta ls: los detectan readlink -e y find -xtype l.
• Cada comando decide si sigue el enlace o no, y las trampas serias son cp sin -a, que deshace los enlaces, y la barra final en un rm -rf, que atraviesa el enlace y borra el destino real.
• Los enlaces son estructura del sistema: /bin, /usr/bin/python3, /etc/alternatives y habilitar un servicio de systemd es crear un enlace.
• Y Tramontana ya tiene su patrón de despliegue: releases/ inmutables y un app -> releases/N que convierte publicar y revertir en un ln -sfn atómico, con -n porque sin él el despliegue falla en silencio.

Queda la última pieza del módulo, y es la que más consecuencias tiene. Has visto que /etc/tramontana/app.conf es -rw-r----- y pertenece a root:tramontana, que el ejecutable es -rwxr-xr-x, y que los permisos de un enlace simbólico no significan nada. Has usado sudo sin preguntarte del todo por qué hacía falta. En la próxima lección, Permisos y Propiedad de Archivos, todo eso deja de ser ruido: leerás la cadena de ls -l carácter a carácter, entenderás por qué x significa cosas distintas en un archivo y en un directorio, traducirás entre notación octal y simbólica en ambos sentidos, calcularás qué hace la umask, reconocerás SUID, SGID y sticky bit cuando los veas, y diseñarás los permisos correctos de cada ruta de Tramontana. Es la lección que separa un servidor que funciona de un servidor que además es seguro.