Tienes srv-tramontana arrancado y un cursor parpadeando tras operador@srv-tramontana:~$. Sin iconos, sin ventanas, sin menús. Para alguien que viene de Windows o macOS, esa pantalla puede resultar intimidante: parece que el ordenador espera que sepas algo que nadie te ha dicho.

Esta lección desactiva esa sensación. Vas a entender qué es exactamente lo que estás mirando: qué ha pasado al iniciar sesión, qué significa cada carácter del prompt, qué diferencia hay entre una consola, un terminal y una TTY, y por qué el shell es el programa más importante de tu jornada. Después harás el reconocimiento inicial de srv-tramontana: comprobar qué versión corre, cuánta memoria tiene y cuánto disco queda, que es literalmente lo primero que hace un administrador al recibir una máquina nueva.

Una aclaración sobre el enfoque: los comandos que verás aquí son para mirar, no para dominar. El objetivo es que sepas qué estás viendo y te muevas con soltura. El manejo serio de la línea de comandos empieza en el Módulo 2.

1. Qué ocurre al iniciar sesión
2. El prompt, carácter a carácter
3. Consola, terminal, TTY y emulador de terminal
4. Qué es el shell y por qué Bash
5. Entorno gráfico frente a solo texto
6. Anatomía de un comando
7. Reconocimiento inicial de srv-tramontana
8. Atajos de teclado de supervivencia
9. Usuario normal, root y el primer contacto con sudo
10. Apagar, reiniciar y cerrar sesión correctamente

Cuando tras el arranque aparece esto:

no es una pantalla decorativa. Hay una cadena de programas trabajando:

1. systemd, el proceso número 1, ha arrancado todos los servicios del sistema y ha lanzado un programa llamado getty en cada terminal virtual.
2. getty es quien muestra ese mensaje y espera un nombre de usuario. Su trabajo es preparar el terminal y recoger quién quiere entrar.
3. Cuando escribes operador, getty cede el control a login, que pide la contraseña, la cifra y la compara con el hash almacenado en /etc/shadow.
4. Si coincide, login establece tu identidad (usuario, grupos, variables de entorno), te sitúa en tu directorio personal /home/operador y ejecuta tu shell, que en Ubuntu es Bash.
5. Bash lee sus archivos de configuración (/etc/profile, ~/.bashrc) y muestra el prompt.

Ese es el momento en que el sistema pasa a estar a tu disposición. Y hay un detalle importante que se aprecia mejor con la lección 01-01 fresca: a partir de aquí, todo lo que hagas será un proceso hijo de tu shell.

Antes del prompt verás el mensaje del día (MOTD), que en Ubuntu Server contiene información útil:

Merece la pena leerlo en lugar de ignorarlo, porque te da un panel de control gratuito: carga del sistema, ocupación de disco, uso de memoria, dirección IP, actualizaciones pendientes y —muy importante desde el punto de vista de seguridad— cuándo y desde dónde se inició sesión la última vez. Si esa línea Last login muestra una fecha o una IP que no reconoces, tienes un motivo serio para investigar.

El prompt es la línea que el shell muestra para indicar que está listo. En Ubuntu tiene esta forma:

Desglose:

Los tres primeros elementos son una respuesta permanente a las tres preguntas que más problemas causan cuando se ignoran: quién soy, en qué máquina estoy y dónde estoy.

La distinción entre $ y # no es cosmética: es una señal de peligro. Si en tu prompt aparece #, tienes poder absoluto sobre la máquina y ningún comando te va a pedir confirmación.

Ese último caso ilustra por qué el hostname en el prompt es tan valioso: cuando tengas varias terminales abiertas contra máquinas distintas, es lo único que te impide ejecutar en producción lo que creías estar ejecutando en pruebas. Es un error clásico y caro.

El prompt es configurable mediante la variable PS1, y en el Módulo 3 aprenderás a personalizarlo (mucha gente le añade colores, la rama de Git o la hora).

Cuatro palabras que suenan a sinónimos y no lo son. La confusión viene de que todas tienen origen en hardware que ya no existe.

La distinción entre las dos últimas filas es la que más cuesta y la que más aclara las cosas:

• El terminal es el continente: la ventana o pantalla donde escribes y lees.
• El shell es el contenido: el programa que lee lo que escribes, lo interpreta y ejecuta programas.

Puedes cambiar de terminal manteniendo el mismo shell (Bash), o cambiar de shell (a Zsh, por ejemplo) manteniendo el mismo terminal. Son piezas independientes que se combinan.

Aunque srv-tramontana no tenga escritorio, Linux te ofrece seis terminales virtuales independientes en la consola física. Cambias entre ellos con:

• Ctrl+Alt+F1 a Ctrl+Alt+F6 (en Ubuntu Server, F1 suele ser el primero).
• En una VM de VirtualBox, la combinación es Host+F1..F6 (la tecla anfitrión es Ctrl derecho por defecto), porque VirtualBox intercepta Ctrl+Alt.

Cada uno es una sesión completa e independiente: puedes tener a operador trabajando en tty1 y a otro usuario en tty2 simultáneamente.

Pruébalo ahora. Cambia a otro terminal, inicia sesión y ejecuta:

Salida:

Ese es el archivo de dispositivo que representa tu terminal actual. Coherente con «todo es un archivo»: tu terminal es un archivo en /dev, y esa idea la desarrollarás en la lección siguiente.

Si te conectas por SSH y ejecutas lo mismo:

pts significa pseudo-terminal slave: un terminal que no corresponde a hardware físico sino a una conexión, típicamente SSH o una ventana de emulador gráfico. Es la forma que tiene el sistema de decirte «esto no es la consola de la máquina, es una sesión remota».

Consejo práctico de verdad útil: los terminales virtuales son tu salvavidas. Si un programa bloquea tu terminal actual y Ctrl+C no responde, cambia a otro tty, inicia sesión y soluciónalo desde ahí sin reiniciar la máquina. La gestión de procesos que hará falta para eso es la lección 03-06.

El shell (literalmente concha, porque envuelve al kernel) es el programa que:

1. Muestra el prompt y espera.
2. Lee la línea que escribes.
3. La interpreta: separa el comando de sus argumentos, expande comodines y variables, resuelve tuberías y redirecciones.
4. Pide al kernel que ejecute el programa correspondiente.
5. Espera a que termine y vuelve a mostrar el prompt.

Es a la vez una interfaz interactiva y un lenguaje de programación completo, con variables, condicionales, bucles y funciones. Esa dualidad es lo que hace tan potente a Linux: cualquier cosa que hagas a mano en el terminal se puede convertir en un script sin cambiar de herramienta. Es la base del Módulo 4.

Puedes ver cuál usas:

echo imprime lo que le des, y $SHELL es una variable de entorno que contiene la ruta de tu shell de inicio de sesión. Las variables de entorno son el tema de la lección 03-01.

Y los shells instalados en el sistema:

Por qué Bash en este curso, con razones concretas:

• Es el shell por defecto en Ubuntu, Debian, RHEL, Fedora y casi cualquier distribución que te encuentres.
• Es lo que asume el 95 % de la documentación, los tutoriales y las respuestas que encontrarás.
• Es compatible con POSIX, así que lo que aprendas funciona también en macOS, en Alpine dentro de un contenedor y en cualquier Unix.
• En un servidor ajeno, en una imagen mínima o en una situación de emergencia, Bash o algo compatible siempre está. Zsh y fish, no.

Nada te impide usar Zsh en tu portátil por comodidad. Pero aprende Bash primero: es el idioma común.

srv-tramontana no tiene escritorio. Conviene entender qué es lo que no tiene y por qué es deliberado.

En Linux, la interfaz gráfica no forma parte del sistema: es un conjunto de programas que se instalan o no.

Sobre X11 y Wayland, lo mínimo que debes saber:

• X11 (Xorg) es de 1984 y ha sido el estándar durante décadas. Su arquitectura es cliente-servidor y transparente en red: puedes ejecutar una aplicación en srv-tramontana y ver su ventana en tu portátil (ssh -X). Potente, pero con un diseño anticuado y problemas de seguridad conocidos: cualquier aplicación puede leer lo que teclean las demás.
• Wayland es el sustituto moderno. Más simple, más seguro y con mejor rendimiento. Es el predeterminado en Ubuntu Desktop 24.04. Su aislamiento entre aplicaciones rompe algunas herramientas antiguas, aunque cada vez menos.

El último punto es el que convence a los escépticos. Instalar un escritorio en un servidor de producción se considera mala práctica en el sector, no por purismo, sino porque cada uno de esos motivos se paga en dinero, en incidentes o en horas.

Todos los comandos siguen la misma estructura:

• Comando: el programa a ejecutar (ls, date, free).
• Opciones (o flags, o modificadores): modifican el comportamiento. Empiezan por guion.
• Argumentos: sobre qué actúa el comando (un archivo, un directorio, un texto).

Los corchetes indican que son opcionales: muchos comandos funcionan solos.

Un ejemplo desmenuzado por completo:

Análisis pieza a pieza:

• ls : el comando, lista el contenido de un directorio.
• -lh : dos opciones cortas agrupadas. -l (long) muestra el formato detallado con permisos, propietario, tamaño y fecha; -h (human-readable) expresa los tamaños en K, M o G en lugar de bytes sueltos.
• /var/log : el argumento, el directorio que queremos listar.

Y sobre la salida, sin entrar en detalle (los permisos son la lección 02-07): la primera letra de cada línea indica el tipo de archivo. La d de apt significa directorio; el - de los demás, archivo regular. Verás el resto de letras en la lección siguiente.

• Linux distingue mayúsculas de minúsculas, siempre. ls, LS y Ls no son lo mismo, y Archivo.txt y archivo.txt son dos archivos distintos. Esto sorprende a quien viene de Windows y es fuente de errores constantes al principio.
• Los espacios separan elementos. Si un nombre de archivo contiene espacios, hay que entrecomillarlo: cat "mi archivo.txt".
• -- marca el fin de las opciones, útil cuando un argumento empieza por guion.

Esto es lo que hace un administrador al recibir una máquina nueva, y lo que deberías hacer siempre antes de instalar nada: saber qué tienes delante.

Devuelve el usuario efectivo. Parece trivial, pero cuando llevas media hora saltando entre sudo, sesiones SSH y máquinas, es la primera pregunta a responder ante cualquier duda.

El nombre de la máquina. Su versión ampliada da más contexto:

Aquí hay información valiosa en tres líneas: Chassis: vm y Virtualization: oracle confirman que estás en una máquina virtual de VirtualBox (útil cuando administras máquinas que no montaste tú), Operating System da la versión exacta y Architecture la arquitectura del procesador.

uname significa Unix name y -a es all. Campo por campo:

Para la versión de la distribución, que es distinta de la del kernel:

Retén la diferencia: el kernel es 6.8; la distribución es 24.04. Son dos numeraciones independientes y confundirlas lleva a buscar documentación equivocada.

Lectura:

• 09:18:42 : hora actual del sistema.
• up 2 days, 4:31 : lleva encendido 2 días y 4 horas y media.
• 1 user : hay una sesión abierta.
• load average: 0,08, 0,12, 0,09 : la carga media en los últimos 1, 5 y 15 minutos.

La carga media merece una explicación porque se malinterpreta constantemente: no es un porcentaje. Es el número medio de procesos que están usando la CPU o esperando para usarla. La referencia es el número de núcleos:

• En una máquina de 2 núcleos, una carga de 2,00 significa uso pleno; por debajo hay holgura y por encima hay procesos esperando.
• Una carga de 0,08 en 2 núcleos, como la del ejemplo, es un sistema prácticamente ocioso.
• Los tres valores juntos indican la tendencia: si el primero es mucho mayor que el tercero, la carga está subiendo ahora mismo.

Esto se profundiza en la lección 05-07.

-h es de nuevo human-readable. Columna por columna:

Aquí está el malentendido más extendido sobre Linux, y conviene resolverlo ya: la columna free no indica cuánta memoria te queda. Linux usa agresivamente la RAM libre como caché de disco, porque tener memoria sin usar es desperdiciarla. Esa caché se libera al instante si un programa la necesita.

La columna correcta es available. Un servidor con free en 100 MB y available en 3 GB está perfectamente sano. Existe incluso una web dedicada a explicar esto (linuxatemyram.com), de lo frecuente que es la confusión.

La línea Swap con 0B usados es una buena señal: no ha hecho falta recurrir al disco.

df es disk free. Lo relevante:

• /dev/sda2 montado en /: la partición raíz, 23 GB de los que se usan 6,4 GB (30 %). Esta es la línea que hay que vigilar.
• /dev/sda1 montado en /boot/efi: la partición de arranque UEFI que creaste al instalar.
• Las líneas tmpfs son sistemas de archivos que viven en memoria RAM, no en disco: se borran al reiniciar. Son normales, y verlas ahí ilustra otra vez el principio de que todo se presenta como archivos.
• La columna Uso% es la que hay que vigilar en un servidor. Por encima del 80 % conviene actuar; al 100 %, como vimos en la lección anterior, el sistema deja de funcionar correctamente.

Y para saber la fecha y hora, que importa más de lo que parece porque afecta a todos los registros:

Fíjate en UTC: por defecto los servidores suelen configurarse en tiempo universal, no en hora local. Es deliberado: evita ambigüedades con los cambios de horario estacional cuando comparas logs de varias máquinas.

Con estos datos ya puedes responder a Marta si te pregunta en qué estado está el servidor:

Conclusión del reconocimiento: hay margen de sobra para instalar Tramontana Reservas. Y ahora tienes una foto de referencia: cuando dentro de tres meses el servidor vaya lento, podrás comparar con estos números en lugar de opinar.

Estos cinco atajos separan a alguien que sufre en el terminal de alguien que se mueve con soltura. Practícalos hasta que salgan sin pensar.

Escribe hostna y pulsa Tab:

Bash completa hasta donde no hay ambigüedad:

Si hay varias posibilidades, pulsa Tab dos veces para verlas:

Funciona igual con rutas de archivo:

Su valor no es la comodidad: es la verificación. Si escribes una ruta y Tab no la completa, esa ruta no existe. Te enteras antes de ejecutar el comando, no después. Un administrador experimentado usa Tab constantemente por esta razón.

Se confunden a menudo y hacen cosas distintas:

• Ctrl+C envía la señal SIGINT al programa en ejecución, pidiéndole que termine. Es lo que usas cuando un comando se ha quedado colgado o se está eternizando.
• Ctrl+D envía el carácter de fin de fichero (EOF). No mata nada: indica «no hay más entrada». Si lo pulsas en el prompt sin nada escrito, el shell interpreta que has terminado y cierra la sesión.

Prueba el primero. Ejecuta un comando que no termina solo:

El ^C de la salida es la marca visual de que has pulsado Ctrl+C. ping se detiene y muestra un resumen. (ping comprueba conectividad de red; es la lección 03-08.)

Hay muchos más atajos —Ctrl+A, Ctrl+E, Ctrl+R, Ctrl+W— que verás en la lección 03-01 al estudiar el entorno del shell. Con estos cinco tienes de sobra por ahora.

En Linux hay una separación estricta entre dos tipos de cuenta.

root (también llamado superusuario) es la cuenta con UID 0, y su poder es total y literal. El kernel no le aplica comprobaciones de permisos. Puede borrar cualquier archivo, matar cualquier proceso y destruir el sistema con un comando mal escrito. No hay papelera de reciclaje, no hay confirmación y no hay «deshacer».

Por eso Ubuntu adopta un enfoque deliberado: la cuenta root existe pero está deshabilitada para inicio de sesión. No tiene contraseña válida. En su lugar, se usa sudo.

sudo significa substitute user do: ejecutar un comando como otro usuario, por defecto root. Su lógica:

1. Escribes sudo delante del comando.
2. sudo comprueba en /etc/sudoers si tienes autorización. Tu usuario operador la tiene por pertenecer al grupo sudo.
3. Te pide tu propia contraseña (no la de root, que ni existe), para confirmar que eres tú quien está al teclado.
4. Ejecuta el comando con privilegios de administrador y registra la operación en /var/log/auth.log.
5. Recuerda la autenticación unos 15 minutos para no preguntarte a cada comando.

Compruébalo con un ejemplo claro:

El mismo comando devuelve un usuario distinto, porque sudo lo ha ejecutado en nombre de root.

Otro ejemplo donde la diferencia es visible. El archivo /etc/shadow guarda los hashes de las contraseñas y solo root puede leerlo:

Ese Permiso denegado no es un fallo: es el sistema funcionando exactamente como debe.

1. Trazabilidad. Cada uso queda registrado con usuario, hora y comando. Si tres personas administran el servidor, se sabe quién hizo qué. Con una cuenta root compartida, no.
2. Superficie mínima. Solo el comando concreto se ejecuta con privilegios, no toda tu sesión. El resto del tiempo trabajas como usuario normal y estás protegido de tus propios errores.
3. Sin contraseña de root que filtrar. No existe, así que no se puede robar ni compartir.

• Piensa antes de escribir sudo. El momento de dudar es antes de pulsar Intro.
• Lee el comando entero antes de ejecutarlo, especialmente si lo has copiado de internet. Nunca pegues un sudo que no entiendas.
• No uses sudo su - por costumbre para tener una sesión root permanente. Pierdes las tres ventajas de golpe.
• Sospecha de sudo rm -rf. Es la combinación que más sistemas ha destruido en la historia.

sudo es mucho más configurable de lo que parece —se puede autorizar a un usuario solo para ciertos comandos, exigir o no contraseña, restringir por máquina— y todo eso es la lección 05-02.

Cortar la alimentación de un sistema en marcha tiene consecuencias reales:

• Datos en caché sin escribir. Linux mantiene en RAM los datos pendientes de escribir en disco para agrupar operaciones y ganar rendimiento. Un corte los pierde.
• Sistemas de archivos inconsistentes. ext4 lleva un journal que permite recuperarse, pero la recuperación puede tardar y no siempre es completa.
• Servicios sin cerrar limpiamente. Una base de datos que no cierra bien puede requerir recuperación al arrancar, o corromper datos.
• Archivos temporales y bloqueos huérfanos. Al arrancar, algunos servicios se niegan a iniciarse porque encuentran un archivo de bloqueo de la sesión anterior.

Un apagado ordenado, en cambio, avisa a cada servicio para que termine, vuelca los datos pendientes a disco (sync), desmonta los sistemas de archivos y solo entonces apaga.

• shutdown : el comando de apagado ordenado.
• -h : halt, detener y apagar la máquina.
• now : inmediatamente.

Programado, que es lo que se hace en un servidor con usuarios conectados:

Apaga dentro de 10 minutos y envía ese mensaje a todos los usuarios con sesión abierta. Es una cortesía elemental en un entorno compartido, y algo que Marta agradecerá.

Si te arrepientes:

Cancela el apagado programado.

Para reiniciar:

Equivalente a sudo shutdown -r now. Es lo que harás tras actualizar el kernel.

Tabla resumen:

Verás las variantes de systemd en la lección 05-05.

Cerrar la sesión no apaga el servidor: solo termina tu shell. El servidor sigue funcionando y sirviendo peticiones.

O el atajo Ctrl+D. En una sesión SSH, ambos cierran también la conexión.

Distinción que hay que tener clara desde el primer día: exit cierra tu sesión; shutdown apaga la máquina. Confundirlos en un servidor remoto significa dejar sin servicio a la empresa y, si es una máquina en un centro de datos sin acceso físico, no poder volver a encenderla. Es un error que se comete una vez en la vida y se recuerda para siempre.

• Confundir terminal y shell. El terminal es la ventana; el shell es el programa que interpreta. Cambiar de emulador de terminal no cambia tu shell.
• Creer que free indica la memoria disponible. La columna correcta es available. Linux usa la RAM libre como caché a propósito.
• Ignorar que Linux distingue mayúsculas de minúsculas. Documentos y documentos son directorios distintos. Es la primera causa de «pero si el archivo está ahí».
• Pensar que el terminal está bloqueado al escribir la contraseña. No se muestra nada por diseño.
• Usar sudo de forma automática ante cualquier «permiso denegado». A veces ese mensaje indica que estás haciendo algo que no deberías. Entiende por qué antes de escalar privilegios.
• Trabajar habitualmente como root. Con sudo su - pierdes trazabilidad y protección frente a tus propios errores.
• Apagar el servidor cuando querías cerrar sesión. exit para salir. shutdown solo cuando de verdad quieres apagar la máquina.
• No usar Tab. Es el hábito que más diferencia a un principiante de alguien con rodaje: menos errores tipográficos y verificación gratuita de que las rutas existen.
• Consejo. Guarda el resultado de tu reconocimiento inicial en un documento. Tener la foto de un sistema sano hace que diagnosticar un sistema enfermo sea comparar, no adivinar.
• Consejo. Practica los atajos deliberadamente durante una semana, aunque al principio te resulte más lento escribir la ruta a mano. La inversión se recupera en días.
• Consejo. Si te pierdes o no sabes dónde estás, tres comandos te reorientan siempre: whoami, hostname y pwd (este último lo verás en 02-03).

Observas este prompt en una de tus terminales:

Responde:

1. ¿Qué usuario está activo y cómo lo sabes sin ejecutar ningún comando?
2. ¿En qué directorio se encuentra?
3. ¿Qué riesgo concreto implica esta situación y qué precaución tomarías?
4. Escribe el prompt que verías si operador iniciase sesión en su directorio personal en el portátil portatil-alumno.

Marta te pide un informe de estado de srv-tramontana antes de aprobar el despliegue de Tramontana Reservas. Indica qué comando usarías para obtener cada dato, qué opción concreta y cómo interpretarías el resultado:

1. Versión exacta de Ubuntu y del kernel.
2. Memoria total y realmente disponible.
3. Espacio libre en la partición raíz.
4. Tiempo encendido y carga del sistema.
5. Si el servidor es físico o virtual.

Redacta después el informe en tres o cuatro frases, como se lo darías a Marta.

Diagnostica y resuelve estas tres situaciones que te ocurren durante tu primer día:

1. Ejecutas cat /var/log/auth.log y obtienes Permiso denegado.
2. Lanzas un comando que lleva dos minutos sin devolver el control y no muestra nada.
3. Quieres salir de tu sesión SSH en srv-tramontana, escribes sudo shutdown -h now y pierdes la conexión. Marta te llama diciendo que la web de reservas no responde. Explica qué ha pasado, cómo se soluciona y cómo evitarlo.

Solución al Ejercicio 1

1. El usuario es root. Hay dos indicios independientes en el propio prompt. El primero es explícito: la cadena antes de la @ dice root. El segundo es el más importante y el que hay que aprender a leer de un vistazo: el prompt termina en # en lugar de $. Esa convención es universal en Unix y funciona incluso con prompts personalizados que oculten el nombre de usuario.

2. En /etc. Es la parte entre : y #. Se muestra la ruta absoluta porque no es el directorio personal (si lo fuera, aparecería ~). /etc es el directorio de configuración del sistema, que verás en la lección siguiente.

3. El riesgo y la precaución. La combinación es especialmente delicada: sesión de root dentro del directorio de configuración del sistema. Cualquier error tipográfico puede dejar el servidor sin arrancar o sin acceso remoto. Un rm mal escrito sobre /etc/ssh/ te deja fuera del servidor; sobre /etc/fstab, sin arrancar. Y no hay confirmación, ni papelera, ni deshacer.

Precauciones concretas:

• Salir de la sesión root con exit y trabajar como operador, usando sudo solo para los comandos que lo necesiten. Se recupera la trazabilidad y la protección.
• Si de verdad hace falta una sesión root prolongada, hacer copia de cualquier archivo antes de editarlo: cp /etc/fstab /etc/fstab.bak.
• Verificar el prompt antes de cada comando destructivo, y usar Tab para confirmar que las rutas existen.
• En una VM, tomar un snapshot antes de tocar configuración crítica.

4. El prompt sería:

Con ~ porque está en su directorio personal (/home/operador) y con $ porque es un usuario normal.

Solución al Ejercicio 2

1. Versión de Ubuntu y del kernel.

lsb_release -a da la distribución (Ubuntu 24.04.1 LTS, nombre en clave noble) y uname -r la versión del kernel (6.8.0-41-generic). Alternativa que da ambas de una vez: hostnamectl. Son numeraciones independientes y hay que reportar las dos.

2. Memoria total y disponible.

-h para unidades legibles. Lo que se reporta es total (3,8 GB) y sobre todo available (3,2 GB). No hay que reportar free, porque incluye como "usada" la caché de disco, que se libera al instante si un programa la necesita.

3. Espacio libre en la raíz.

Pasando / como argumento se limita la salida a la partición raíz. Se reportan los gigabytes disponibles (15 GB) y el porcentaje de uso (30 %). El porcentaje es el dato accionable: por encima del 80 % hay que planificar.

4. Tiempo encendido y carga.

Da ambas cosas. La carga (0,08 0,12 0,09) se interpreta contra el número de núcleos, que se obtiene con nproc. Con 2 núcleos, esos valores indican un sistema prácticamente ocioso.

5. Físico o virtual.

Las líneas Chassis: vm y Virtualization: oracle lo confirman. Alternativa directa: systemd-detect-virt, que devuelve oracle en VirtualBox o none en hardware físico.

Informe para Marta:

«srv-tramontana corre Ubuntu 24.04.1 LTS con kernel 6.8.0-41 sobre una máquina virtual de VirtualBox, arquitectura de 64 bits. Tiene 3,8 GB de memoria, de los que 3,2 GB están disponibles, y no está usando swap. La partición raíz ocupa el 30 % de 23 GB, con 15 GB libres. La carga media es de 0,08 sobre 2 núcleos, es decir, el sistema está prácticamente ocioso, y lleva 2 días encendido sin actualizaciones pendientes. Hay recursos de sobra para desplegar Tramontana Reservas. Recomiendo revisar el espacio en disco cuando la aplicación empiece a generar logs, y vigilar que no supere el 80 % de ocupación.»

Solución al Ejercicio 3

Situación 1 — Permiso denegado al leer /var/log/auth.log.

Diagnóstico: no es un error del sistema, es el sistema protegiéndose. auth.log registra todos los intentos de autenticación, incluidos usuarios y orígenes de conexiones. Es información sensible: revela qué cuentas existen y desde dónde se conectan. Por eso pertenece al grupo adm y no es legible por usuarios normales.

Solución:

O mejor, porque el archivo es largo y solo suelen interesar las últimas entradas:

Alternativa más elegante: el usuario operador podría añadirse al grupo adm, que tiene permiso de lectura sobre los logs, y así consultarlos sin sudo. Es la solución correcta si se van a revisar logs con frecuencia, y se ve en la lección 05-01.

Consejo general: ante un Permiso denegado, la reacción correcta no es «pongo sudo», sino «¿por qué está protegido esto?». Aquí la respuesta es legítima y sudo está justificado. En otros casos, el mensaje te está avisando de que estás en el sitio equivocado.

Situación 2 — Un comando lleva dos minutos sin responder.

Diagnóstico: hay tres posibilidades y conviene distinguirlas antes de actuar:

• El comando está trabajando de verdad y tarda (copiar archivos grandes, actualizar paquetes, comprimir). Recuerda el principio Unix: silencio es éxito, muchos comandos no informan de su progreso.
• El comando espera entrada por teclado. Ocurre si has escrito cat sin argumentos: se queda esperando lo que teclees.
• El comando está bloqueado: esperando una conexión de red que no llega, o un recurso ocupado.

Solución progresiva:

1. Ctrl+C para interrumpirlo. Envía SIGINT y en la mayoría de casos resuelve.
2. Si esperaba entrada, Ctrl+D cierra la entrada y lo deja terminar limpiamente.
3. Si Ctrl+C no responde, cambia a otro terminal virtual (Ctrl+Alt+F2) o abre otra sesión SSH, y desde ahí identifica y termina el proceso. Las herramientas para eso —ps, kill— son la lección 03-06.
4. Reiniciar la máquina es el último recurso, no el primero.

Prevención: antes de lanzar algo que puede tardar, piensa si conviene ejecutarlo en segundo plano o dentro de una sesión persistente (tmux, screen), sobre todo si estás conectado por SSH y la conexión puede caerse.

Situación 3 — Has apagado el servidor de producción.

Qué ha pasado: has confundido cerrar sesión con apagar la máquina. sudo shutdown -h now ha ejecutado un apagado ordenado e inmediato de srv-tramontana. La conexión SSH se ha caído porque el servidor se estaba apagando, no porque hubiera un problema de red. Y Tramontana Reservas no responde porque el servidor que la aloja está apagado. No hay corrupción de datos —el apagado fue ordenado—, pero sí caída de servicio.

Cómo se soluciona:

• En una VM local: abrir VirtualBox y arrancarla. Un minuto.
• En un servidor físico accesible: pulsar el botón de encendido.
• En un servidor remoto sin acceso físico: aquí está la gravedad real del error. Necesitas una consola fuera de banda —IPMI, iDRAC, iLO— o el panel de control del proveedor de nube. Si no dispones de ninguna de esas vías, el servidor no se puede encender de forma remota, y hay que desplazar a alguien físicamente. En un centro de datos de otra ciudad, eso son horas de caída.

Cómo evitarlo, por orden de eficacia:

1. Usar exit o Ctrl+D para cerrar sesión. shutdown solo cuando de verdad quieras apagar la máquina. Es la regla que resuelve el 100 % de los casos.
2. Leer el prompt antes de cada comando peligroso. El hostname está ahí precisamente para esto: srv-tramontana no es tu portátil.
3. Diferenciar visualmente las terminales de producción, con colores o prompts distintos. En el Módulo 3 verás cómo personalizar PS1; poner el prompt de producción en rojo es una práctica muy extendida y muy eficaz.
4. En un servidor real, avisar siempre antes: sudo shutdown -h +10 "Mantenimiento programado" da margen para cancelar con sudo shutdown -c si te das cuenta del error.
5. Verificar que existe una vía de encendido remoto antes de apagar cualquier máquina que no tengas delante. Es una comprobación de dos minutos que evita un desastre.

Ya no estás mirando una pantalla negra incomprensible. En esta lección has visto:

• Qué ocurre al iniciar sesión: la cadena systemd → getty → login → shell, y el mensaje del día como panel de control.
• El prompt carácter a carácter: usuario, máquina, directorio, y el $ frente al # que avisa de que eres root.
• La diferencia entre consola, terminal, TTY y emulador, y los seis terminales virtuales como salvavidas.
• Qué es el shell, por qué Bash y en qué se distingue del terminal.
• Por qué un servidor no lleva escritorio, y qué son X11, Wayland, GNOME y KDE.
• La anatomía de un comando: comando [opciones] [argumentos], opciones cortas y largas.
• El reconocimiento inicial de srv-tramontana con uname, hostnamectl, uptime, free -h y df -h, y cómo interpretar lo que dicen, incluida la trampa de la columna free.
• Los atajos de supervivencia, con Tab como el hábito más rentable.
• La distinción usuario normal / root y el uso responsable de sudo.
• Cómo apagar, reiniciar y cerrar sesión correctamente, y por qué no se tira del cable.

Sabes quién eres, en qué máquina estás y en qué estado se encuentra. Falta la última pieza de orientación: dónde estás, y sobre todo, qué hay a tu alrededor.

En la siguiente lección, Estructura del Sistema de Archivos de Linux, verás por qué en Linux no hay unidades C: ni D: sino un único árbol que nace en /, recorrerás uno por uno los directorios del estándar FHS, entenderás de verdad qué significa que «todo es un archivo» y qué son /proc y /sys. Y con ese mapa en la mano justificarás, con el estándar en la mano, por qué la aplicación de Tramontana va en /opt/tramontana/app, su configuración en /etc/tramontana/, sus registros en /var/log/tramontana/ y las copias en /srv/tramontana/backups. Es la lección que convierte el sistema de archivos en un territorio conocido.