Ya sabes que Linux es un kernel y que la historia explica su diseño. Queda el paso intermedio imprescindible antes de instalar nada: entender qué es realmente una distribución y por qué hay cientos.

Esta lección resuelve una duda que bloquea a mucha gente al empezar: «¿cuál elijo?». La respuesta profesional no es «la mejor», porque no existe: es «la que encaja con lo que voy a hacer, con lo que sabe mi equipo y con cuántos años necesito que dure». Vas a ver qué piezas componen una distribución, en qué se diferencian de verdad las tres grandes familias, qué significa LTS y por qué en un servidor es determinante, y cómo se elige con criterio. Al final, reconstruiremos la decisión de Tramontana S.L. paso a paso: por qué srv-tramontana lleva Ubuntu Server 24.04 LTS y no otra cosa.

1. Qué compone realmente una distribución
2. La familia Debian: Debian y Ubuntu
3. La familia Red Hat: Fedora, RHEL, Rocky y Alma
4. La familia Arch y el modelo rolling release
5. Otras familias relevantes: SUSE y Alpine
6. Tabla comparativa por criterios
7. LTS y por qué importa en un servidor
8. Releases fijas frente a rolling release
9. Distribuciones de propósito específico
10. Cómo elegir distribución con criterio profesional
11. La decisión de Tramontana y las equivalencias con RHEL

Una distribución es un ensamblaje. Estas son las piezas que sus responsables eligen, integran, prueban y mantienen:

Dos de estas piezas explican casi todas las diferencias que notarás en el día a día.

Es la diferencia más visible. Un paquete es un archivo comprimido con los binarios de un programa, sus archivos de configuración y unos metadatos que declaran de qué otros paquetes depende. El gestor de paquetes resuelve ese grafo de dependencias, descarga lo necesario y lo instala en su sitio.

Los tres comandos hacen lo mismo: instalar el servidor web nginx con todas sus dependencias. Cambia la sintaxis, no el concepto. En el Módulo 5 trabajarás la gestión de paquetes en profundidad; aquí solo necesitas saber que el gestor de paquetes es la firma de la familia.

Y hay una consecuencia práctica inmediata de esto: lo primero que se hace al llegar a un servidor desconocido es averiguar qué distribución es, porque de ello depende qué comandos servirán. La forma estándar y portable es leer un archivo que todas las distribuciones modernas incluyen:

Salida en srv-tramontana:

Los tres campos que de verdad importan:

• ID=ubuntu: el identificador exacto de la distribución.
• ID_LIKE=debian: la familia. Este campo es oro cuando administras máquinas heterogéneas, porque te dice qué gestor de paquetes esperar aunque no conozcas la distribución concreta. En Rocky Linux verías ID_LIKE="rhel centos fedora".
• VERSION_CODENAME=noble: el nombre en clave, que es lo que aparece en los repositorios y en muchos comandos de configuración.

Este archivo es un estándar de systemd y está en Ubuntu, Debian, Rocky, Fedora, Alpine y prácticamente cualquier distribución actual. Por eso es la comprobación que usan los scripts de instalación para decidir si ejecutan apt o dnf.

Es el proceso número 1, el primero que arranca el kernel y el padre de todos los demás. Se encarga de levantar los servicios en orden, reiniciarlos si se caen y apagarlos limpiamente.

Hoy systemd es el estándar de facto: lo usan Ubuntu, Debian, RHEL, Fedora, Arch, SUSE y prácticamente todas las distribuciones generalistas. Su adopción entre 2011 y 2015 fue muy polémica porque rompía con la filosofía Unix de «un programa, una tarea» (systemd gestiona servicios, logs, red, montajes, temporizadores...), pero ganó por ser mucho más rápido, consistente y capaz de expresar dependencias entre servicios. Lo dominarás en la lección 05-05.

Alpine y algunas distribuciones minimalistas usan alternativas más ligeras (OpenRC, runit), lo que es una diferencia real y no cosmética.

Fíjate en un detalle del diagrama que confunde a mucha gente: Fedora está aguas arriba de RHEL, no aguas abajo. Fedora es el laboratorio donde Red Hat prueba innovaciones cada seis meses; cada dos o tres años se congela un estado de Fedora y de ahí sale una versión de RHEL, que se estabiliza y se mantiene diez años. Rocky y Alma se construyen a partir del código de RHEL.

Nació en 1993 y es la distribución comunitaria de referencia. No hay empresa detrás: la gobierna un proyecto con miles de desarrolladores voluntarios, un contrato social y un líder elegido por votación.

• Paquetes: .deb, gestionados con apt (interfaz de alto nivel) y dpkg (bajo nivel).
• Ramas: stable (la actual, sólida como una roca), testing (la que será la siguiente) y unstable/sid (donde entra todo primero).
• Filosofía: estabilidad y libertad por encima de la novedad. Un Debian stable puede tener software de dos años.
• Ciclo: versión nueva cada 2 años aproximadamente, con soporte de unos 5 con LTS comunitario.
• Uso típico: servidores que deben funcionar años sin sorpresas, infraestructura crítica.

Canonical, la empresa de Mark Shuttleworth, la creó en 2004 partiendo de Debian con un objetivo claro: hacerla usable y predecible. Es hoy la distribución más extendida en servidores y en la nube.

• Toma paquetes de Debian unstable, los estabiliza, añade los suyos y publica.
• Ciclo predecible: versión cada 6 meses (abril y octubre) y LTS cada 2 años en abril.
• Numeración inteligible: 24.04 significa 2024, mes 04. 22.04 es de abril de 2022.
• Soporte LTS: 5 años estándar, ampliables a 10 o 12 con la suscripción Ubuntu Pro (gratuita para uso personal y hasta 5 máquinas).
• Sabores: Ubuntu Server (sin escritorio), Ubuntu Desktop (GNOME), Kubuntu (KDE), Xubuntu (XFCE), Ubuntu Core (IoT).

Aciertos y críticas, para tener la foto completa:

Red Hat es la empresa que demostró que se podía ganar dinero con software libre (IBM la compró en 2019 por 34.000 millones de dólares). Su modelo no es vender software: es vender soporte, certificaciones y garantías de estabilidad a diez años.

• Paquetes: .rpm, gestionados con dnf (sucesor de yum).
• Seguridad: SELinux activado por defecto, un sistema de control de acceso obligatorio mucho más estricto que los permisos clásicos. Es su seña de identidad y también la principal fuente de dolores de cabeza para quien viene de Debian.
• Cortafuegos: firewalld en lugar de ufw (Módulo 6).

Las cuatro piezas del ecosistema:

Un apunte de contexto reciente que conviene conocer: en 2020 Red Hat convirtió CentOS (que era una reconstrucción gratuita y estable de RHEL) en CentOS Stream, que va por delante de RHEL en vez de por detrás. Miles de empresas se quedaron sin su servidor gratuito equivalente a RHEL, y de ahí nacieron Rocky Linux y AlmaLinux para ocupar ese hueco. Si te encuentras documentación antigua que recomienda CentOS 7 u 8 para producción, está desfasada.

Dónde se usa esta familia: grandes empresas, banca, administración pública, entornos con requisitos de certificación y soporte contractual. Si trabajas en una corporación grande, es muy probable que te encuentres RHEL.

Arch Linux (2002) es la distribución para quien quiere control total y entender cada pieza de su sistema.

• Paquetes: .pkg.tar.zst con pacman, muy rápido.
• AUR (Arch User Repository): repositorio comunitario con prácticamente todo el software que existe, en forma de recetas de compilación. Es su gran atractivo y también su riesgo: no está auditado.
• Rolling release: no hay versiones. Instalas una vez y actualizas para siempre.
• Instalación: manual y por línea de comandos (aunque desde 2021 existe archinstall para simplificarla).
• Documentación: el ArchWiki es, sin discusión, la mejor documentación técnica de Linux que existe, y es útil aunque no uses Arch.

Para quién sí: escritorios de desarrolladores que quieren siempre lo último, gente que quiere aprender a fondo cómo se ensambla un sistema.

Para quién no: servidores de producción. Una actualización puede requerir intervención manual y traer cambios que rompan tu aplicación en el peor momento. Nadie serio pone Arch en un servidor de producción de una empresa, y Tramontana no será la excepción.

Distribución de origen alemán (1994), muy implantada en Europa, especialmente en Alemania, y en entornos SAP.

• openSUSE Leap: versión estable comunitaria, alineada con SUSE Linux Enterprise.
• openSUSE Tumbleweed: rolling release muy bien probada.
• SLES (SUSE Linux Enterprise Server): el producto de pago con soporte.
• Usa .rpm con el gestor zypper y destaca por YaST, una herramienta de administración unificada que no tiene equivalente en otras distribuciones, y por su integración de Btrfs con snapshots automáticos: puedes revertir una actualización fallida desde el arranque.

Es la excepción interesante que rompe todos los moldes:

• No usa glibc sino musl; no usa coreutils de GNU sino BusyBox.
• No usa systemd sino OpenRC.
• Gestor de paquetes propio: apk.
• Una imagen base ocupa unos 5 MB, frente a los ~75 MB de una imagen base de Ubuntu.

Ese tamaño la ha convertido en la distribución estándar para contenedores. Cuando en el Módulo 7 construyas imágenes Docker, verás FROM alpine por todas partes. Su contrapartida es real: al usar musl en lugar de glibc, algunos programas compilados para Linux "normal" fallan o rinden peor, y depurar esos problemas requiere experiencia.

LTS significa Long Term Support: soporte a largo plazo. Una versión LTS recibe correcciones de seguridad y de errores graves durante años, sin cambios funcionales.

Esa última parte es la clave y suele malinterpretarse. LTS no significa «software actualizado a lo último». Significa exactamente lo contrario: el software se congela en la versión que había el día del lanzamiento, y solo se le aplican parches de seguridad retroportados (backports). Es decir, Canonical coge la corrección de una vulnerabilidad de nginx 1.26 y la aplica sobre el nginx 1.24 que trae Ubuntu 24.04, sin cambiar la versión.

Piénsalo desde el negocio: Tramontana Reservas factura reservas de casas rurales. Cada minuto de caída es dinero y reputación. Un servidor que exige que lo migres cada nueve meses te obliga a repetir cinco veces en cinco años el ciclo completo de pruebas, validación y despliegue. Con LTS lo haces una vez.

Una advertencia importante para tu vida profesional: fin de soporte significa fin de parches de seguridad. Un servidor con una distribución fuera de soporte no es «un poco antiguo»: es un servidor que acumula vulnerabilidades conocidas y sin corregir. Apuntarse en el calendario la fecha de fin de soporte de cada máquina es una tarea de administrador tan básica como hacer copias de seguridad.

El argumento decisivo para un servidor no es el riesgo: es la reproducibilidad. Si montas hoy un servidor de pruebas y mañana uno de producción con una rolling release, no son la misma máquina, porque entre medias han cambiado paquetes. Con Ubuntu 24.04 LTS, dos instalaciones separadas por seis meses son funcionalmente idénticas. Cuando en el Módulo 7 automatices despliegues con Ansible, esa propiedad pasará de conveniente a imprescindible.

No toda distribución busca ser generalista. Algunas resuelven un problema muy concreto y lo hacen mejor que nadie:

Dos avisos prácticos que ahorran disgustos:

• Kali no es una distribución de uso diario. Es una caja de herramientas ofensivas: se arranca cuando se necesita, idealmente desde una VM o un USB. Instalarla como sistema principal es un error de principiante muy frecuente entre quienes empiezan en ciberseguridad. Verás herramientas de seguridad en el Módulo 6, y en Ubuntu se instalan igual de bien.
• Usar la distribución específica correcta ahorra semanas. Montar un NAS sobre Ubuntu a mano es posible y educativo; montarlo con TrueNAS es cuestión de una tarde. Saber cuándo usar la herramienta especializada es parte del criterio profesional.

Preguntas por orden de importancia. Contéstalas en este orden y la elección casi se hace sola.

1. ¿Servidor o escritorio? Cambia todo: prioridades, software instalado, consumo de recursos.

2. ¿Cuántos años debe durar sin migración? Menos de un año, cualquier cosa vale. Cinco años, necesitas LTS. Diez años, RHEL o Ubuntu Pro.

3. ¿Qué sabe ya mi equipo? El coste de aprender una familia nueva es real y se paga en incidentes a las tres de la mañana. Si tu equipo sabe apt, no le pongas dnf sin un motivo fuerte.

4. ¿Qué exige o certifica el software que voy a ejecutar? Muchos productos comerciales solo certifican RHEL y Ubuntu LTS. Si tu proveedor de base de datos solo da soporte sobre RHEL, la decisión está tomada.

5. ¿Necesito soporte comercial con SLA? Si un contrato exige tiempos de respuesta garantizados, necesitas RHEL, Ubuntu Pro o SLES.

6. ¿Dónde va a correr? Nube (Ubuntu y las derivadas de RHEL son ciudadanas de primera en AWS, Azure y GCP), contenedor (Alpine o Debian slim), Raspberry Pi (Raspberry Pi OS), hardware antiguo (Debian con XFCE).

7. ¿Cómo es la documentación y la comunidad? Cuando tengas un problema a las 3 de la mañana, la cantidad de gente que ha tenido ese mismo problema antes que tú importa más de lo que parece.

Y tres criterios que no deberían pesar en una decisión profesional: qué distribución es más «pura» ideológicamente, cuál tiene el escritorio más bonito, y cuál usan los expertos en los foros para demostrar nivel.

Apliquemos las siete preguntas al caso real.

El servidor srv-tramontana:

Decisión: Ubuntu Server 24.04 LTS para srv-tramontana, con soporte hasta abril de 2029.

Tu portátil de trabajo: Ubuntu Desktop 24.04 LTS, con el usuario alumno. La razón es deliberada y merece explicarse: al usar la misma versión base en el portátil y en el servidor, lo que pruebas en local se comporta igual en producción. Las versiones de paquetes coinciden, los caminos de configuración son los mismos y desaparece toda una categoría de incidentes del tipo «en mi máquina funcionaba».

Por qué el curso usa Ubuntu, dicho abiertamente: porque es lo más probable que te encuentres en la nube y en empresas pequeñas y medianas, porque tiene la mejor documentación para aprender y porque casi cualquier tutorial que consultes estará escrito para ella. No porque sea técnicamente superior a Debian o a Rocky Linux.

Si mañana cambias de empresa y te encuentras Rocky Linux o RHEL, el 90 % de este curso te sirve tal cual. Estas son las diferencias que sí tendrás que traducir. Guarda esta tabla: es una de las más útiles del módulo.

Lo que no cambia, y es la mayoría: el kernel, la estructura de directorios (lección 01-06), los permisos, Bash y todo el scripting, systemd y systemctl, journalctl, SSH, los procesos, las tuberías y las herramientas de texto. Por eso el conocimiento es transferible: lo que aprendes es Linux, no Ubuntu.

De estas diferencias, la única que produce sorpresas serias es SELinux. En RHEL puedes tener permisos aparentemente correctos y aun así recibir un «permiso denegado» porque SELinux bloquea la operación por política. Es la primera cosa que debes sospechar al migrar desde Ubuntu.

• Buscar "la mejor distribución". No existe. Existe la más adecuada para un contexto. Cambiar de distribución constantemente (distro-hopping) es entretenido y didáctico, pero durante este curso quédate con Ubuntu 24.04 LTS: aprender el sistema y aprender una distribución nueva a la vez multiplica la confusión.
• Poner en producción una distribución de escritorio. Ubuntu Desktop en un servidor significa gigabytes de software innecesario, un escritorio consumiendo RAM y una superficie de ataque mucho mayor. Usa siempre la edición Server.
• Usar una versión no LTS en un servidor. Ubuntu 24.10 dejará de recibir parches en julio de 2025. Para un servidor, esa fecha llega enseguida.
• Mezclar repositorios de versiones distintas. Añadir repositorios de Ubuntu 25.04 a un 24.04 para conseguir una versión más nueva de un paquete rompe el sistema con una fiabilidad admirable. Se llama FrankenDebian y no tiene arreglo cómodo.
• Copiar tutoriales sin comprobar la distribución y la versión. Un tutorial de CentOS 7 usa yum, iptables y rutas distintas. Antes de pegar un comando, comprueba para qué sistema está escrito.
• Instalar Kali como sistema principal para "aprender seguridad". Aprende Linux primero en Ubuntu; las herramientas de Kali se instalan después en cualquier distribución.
• Consejo. Aprende bien una familia y conoce las equivalencias de la otra. Con la tabla de la sección 11 y saber apt, te defiendes en RHEL desde el primer día.
• Consejo. Antes de elegir para un proyecto real, busca siempre la fecha de fin de soporte de la versión candidata y anótala en el inventario. Es información que se olvida y se echa de menos tres años después.

Para cada escenario, elige una distribución y justifica la elección con al menos dos de los siete criterios de la sección 10:

1. Servidor de correo para un ayuntamiento pequeño, que debe funcionar 8 años con mínima intervención y cuyo pliego exige soporte contractual.
2. Imagen base para un microservicio en Docker que se despliega 200 veces al día.
3. Portátil de un desarrollador que necesita las últimas versiones de Python, Rust y Node.js y no le importa dedicar tiempo al sistema.
4. Servidor de archivos casero sobre una Raspberry Pi 5.
5. Un segundo servidor para Tramontana S.L., destinado a alojar la base de datos de Tramontana Reservas.

Marta ha leído en un blog que Ubuntu 24.10 «es más moderna y por tanto más segura» que Ubuntu 24.04 LTS, y propone reinstalar srv-tramontana. Escribe la respuesta técnica que le darías, explicando qué significa LTS, qué son los backports de seguridad y qué coste operativo tendría la propuesta.

Tramontana firma un contrato con una cadena hotelera que exige que su software de facturación corra sobre Rocky Linux 9. Tú solo has trabajado con Ubuntu. Prepara una tabla de traducción con las ocho tareas administrativas que más vas a necesitar el primer día, y señala cuál de las diferencias te parece más peligrosa y por qué.

Solución al Ejercicio 1

1. Servidor de correo del ayuntamiento → RHEL (o SLES). Criterios decisivos: duración sin migración (8 años solo lo cubren RHEL, con 10 años de ciclo, o Ubuntu Pro) y soporte comercial con SLA, que el pliego exige explícitamente y que solo se obtiene con suscripción. Se añade un tercero: la administración pública suele exigir certificaciones de seguridad (Common Criteria, FIPS) que RHEL tiene documentadas. Rocky Linux sería técnicamente equivalente pero no cumple el requisito de soporte contractual, que es el que manda aquí.

2. Imagen base de microservicio → Alpine. Criterios: dónde va a correr (contenedor) y tamaño. Con 200 despliegues diarios, la diferencia entre 5 MB y 75 MB por imagen se multiplica en ancho de banda, tiempo de arranque y coste de registro. Además, menos paquetes significa menos CVE que parchear. Matiz profesional: si el microservicio está escrito en Python o Node con dependencias compiladas, musl puede dar problemas de compatibilidad y de rendimiento; en ese caso la elección correcta es debian:slim, que ocupa ~30 MB y usa glibc. Alpine es la respuesta por defecto, no la respuesta automática.

3. Portátil de desarrollador con lo último → Arch (o Fedora). Criterios: escritorio, novedad del software y tiempo disponible para mantenerlo. Arch en rolling release da siempre las últimas versiones y el AUR cubre prácticamente cualquier herramienta. La condición «no le importa dedicar tiempo al sistema» es la que lo hace viable. Si esa condición no se cumpliera, Fedora sería la respuesta correcta: software casi igual de reciente con ciclos de 6 meses y mucho menos mantenimiento manual.

4. Servidor de archivos en Raspberry Pi 5 → Raspberry Pi OS. Criterio: dónde va a correr. Es Debian adaptado específicamente al hardware de la placa (GPIO, gestión térmica, arranque, aceleración gráfica), con kernel y firmware mantenidos por la Raspberry Pi Foundation. Ubuntu Server para ARM también funciona y sería defendible si se buscara homogeneidad con el resto del parque, pero el soporte de hardware es mejor en la opción nativa.

5. Servidor de base de datos de Tramontana → Ubuntu Server 24.04 LTS. Criterios: lo que sabe el equipo y homogeneidad del parque. Aunque técnicamente Debian o Rocky servirían igual de bien, introducir una segunda familia en una empresa con un solo técnico duplica el conocimiento necesario, los procedimientos, los scripts y las ventanas de actualización, sin aportar nada. La homogeneidad tiene un valor operativo enorme en equipos pequeños. Misma versión, mismo LTS, mismos scripts de copia de seguridad.

Solución al Ejercicio 2

Respuesta para Marta:

«La intuición de que "más reciente es más seguro" es razonable pero no se aplica al software de servidor, y conviene explicar por qué.

Qué significa LTS. Ubuntu 24.04 LTS recibe actualizaciones de seguridad hasta abril de 2029, cinco años. Ubuntu 24.10 recibe actualizaciones durante nueve meses, hasta julio de 2025. A partir de esa fecha, un servidor con 24.10 deja de recibir parches: acumularía vulnerabilidades conocidas y publicadas, sin corregir. La versión "más moderna" sería, literalmente, la insegura.

Qué son los backports de seguridad. Que 24.04 traiga nginx 1.24 en lugar de 1.26 no significa que le falten correcciones. Canonical toma cada parche de seguridad publicado aguas arriba y lo aplica sobre la versión que distribuye, manteniendo el número de versión. Recibimos la corrección sin recibir los cambios funcionales. Por eso una herramienta de escaneo que se limite a comparar números de versión da falsos positivos en Ubuntu: hay que consultar el aviso de seguridad de Ubuntu (USN) correspondiente.

Coste operativo de la propuesta. Reinstalar con 24.10 nos obligaría a migrar de nuevo en julio de 2025, y otra vez cada nueve meses. Cada migración implica: parar el servicio, probar que Tramontana Reservas sigue funcionando con las nuevas versiones de Python, PostgreSQL y nginx, revisar los cambios de configuración y estar disponibles por si algo falla. Son varias jornadas de trabajo cada vez, multiplicadas por más de cinco en el periodo que 24.04 cubre con una sola instalación.

Recomendación. Mantener 24.04 LTS y asegurarnos de que las actualizaciones de seguridad se aplican de forma automática y verificada. Si en algún momento necesitamos una versión más reciente de un componente concreto (por ejemplo Python), lo resolvemos con un repositorio oficial de ese componente o con un contenedor, sin arrastrar todo el sistema operativo. Y anotamos en el inventario la fecha de abril de 2029 para planificar la migración con tiempo.»

Solución al Ejercicio 3

Tabla de traducción para el primer día en Rocky Linux 9:

La diferencia más peligrosa: SELinux.

Es la más peligrosa por una razón concreta: falla de forma silenciosa y engañosa. Las otras siete diferencias producen errores evidentes; si escribes apt en Rocky, el sistema te dice que el comando no existe y lo corriges en tres segundos.

SELinux, en cambio, produce un «permiso denegado» cuando los permisos que ves con ls -l son perfectamente correctos. Puedes tener el archivo con propietario correcto, grupo correcto y modo 644, y aun así el servicio no puede leerlo, porque SELinux aplica una política adicional basada en contextos (etiquetas asociadas a archivos y procesos) que no se ven con las herramientas habituales.

El caso clásico, y el que más tiempo hace perder: mover el contenido de una aplicación web a un directorio no estándar. En Ubuntu funciona; en Rocky, nginx no puede leerlo porque el contexto SELinux del directorio nuevo no es el que la política espera.

Lo que hay que saber de entrada:

• Comprobar si SELinux está activo: getenforce (devuelve Enforcing, Permissive o Disabled).
• Ante un «permiso denegado» inexplicable, revisar /var/log/audit/audit.log o usar ausearch -m avc -ts recent.
• Corregir contextos con restorecon o semanage fcontext.
• Lo que no se debe hacer, aunque todos los foros lo sugieran: desactivar SELinux. Es una capa de seguridad valiosa, especialmente en un servidor expuesto, y desactivarla para resolver un problema de configuración es cambiar un problema por un riesgo.

Se tratará el tema en el Módulo 6, al hablar de asegurar sistemas Linux.

Recapitulando:

• Una distribución es kernel + userland + gestor de paquetes + init + política de releases, integrado y mantenido por alguien.
• Las tres grandes familias se distinguen sobre todo por el gestor de paquetes: Debian/Ubuntu (.deb, apt), Red Hat (.rpm, dnf) y Arch (pacman, rolling). SUSE y Alpine completan el mapa.
• LTS significa versiones congeladas con parches de seguridad retroportados durante años. En un servidor no es una preferencia: es un requisito.
• Rolling release aporta novedad y quita reproducibilidad, por lo que no encaja en producción.
• Existen distribuciones especializadas (Alpine, Kali, Raspberry Pi OS, Proxmox) que resuelven un problema concreto mejor que ninguna generalista.
• Se elige con criterios: horizonte temporal, conocimiento del equipo, requisitos del software, soporte, destino y documentación.
• Tramontana usa Ubuntu Server 24.04 LTS en srv-tramontana y Ubuntu Desktop 24.04 LTS en tu portátil, con soporte hasta 2029, y las diferencias con RHEL están tabuladas para cuando hagan falta.

Ya sabes qué vas a instalar y por qué. En la siguiente lección, Instalando Linux, montarás el laboratorio con el que trabajarás durante los ocho módulos: compararemos máquina virtual, WSL2, arranque dual y nube, descargarás la ISO de Ubuntu Server 24.04 LTS y verificarás su suma SHA256 y su firma GPG antes de instalarla, recorrerás el instalador paso a paso —incluido el particionado, que es donde más gente se atasca— y crearás el usuario operador. Al terminar tendrás srv-tramontana arrancado y esperándote.