1. INTRODUCCIÓN Y ALCANCE

Unix no designa únicamente un producto histórico, sino una familia tecnológica, una tradición de diseño y un conjunto de interfaces que han modelado la informática moderna. Sus conceptos aparecen en servidores, centros de proceso de datos, plataformas de nube, equipos de comunicaciones, sistemas embebidos, supercomputadores y estaciones de trabajo. El modelo de procesos, la jerarquía única de archivos, la separación entre núcleo y espacio de usuario, los permisos basados en identidades numéricas, las tuberías y la composición de pequeñas utilidades continúan siendo piezas centrales de la administración de sistemas.

En el temario conviene distinguir tres expresiones que se confunden con frecuencia. Unix histórico es el sistema nacido en Bell Labs a finales de los años sesenta y sus descendientes. UNIX, escrito como marca, identifica productos que han superado la certificación de The Open Group frente a la Single UNIX Specification. Finalmente, sistema tipo Unix o Unix-like es una categoría funcional más amplia: sistemas que reproducen gran parte del modelo, las herramientas y las interfaces Unix, aunque no procedan del código original ni estén certificados. Linux pertenece a esta última categoría.

La importancia práctica del tema para un TFA-STI es doble. En primer lugar, muchos servicios corporativos se despliegan sobre Linux o sobre plataformas que ofrecen interfaces POSIX: servidores web, bases de datos, middleware Java, herramientas de integración continua, plataformas de monitorización, appliances de seguridad y nodos de contenedores. En segundo lugar, incluso cuando el sistema principal no es Linux, la operación diaria suele exigir comprender conceptos Unix: cuentas y grupos, propietarios, modos de acceso, demonios, planificadores, registros, procesos, memoria virtual, señales, sistemas de archivos, montaje de volúmenes y automatización mediante shell.

Unix fue concebido desde el inicio como un sistema multiusuario y multitarea. Esto implica que múltiples personas y servicios comparten recursos sin que el sistema pierda el control sobre la propiedad, la protección y la contabilidad. La abstracción de proceso permite ejecutar simultáneamente aplicaciones independientes; el planificador distribuye la CPU; la memoria virtual separa espacios de direcciones; el sistema de archivos aplica permisos; y el núcleo media todo acceso a dispositivos. El resultado es un entorno adecuado tanto para interacción humana como para ejecución continuada de servicios.

Este tema estudia la historia de Unix, sus características, la organización interna, el modelo de procesos y seguridad, la administración básica, los sistemas BSD, Linux y sus distribuciones, y otros sistemas orientados a grandes unidades multiusuario, como AIX, Oracle Solaris, z/OS, z/VM y OpenVMS. El objetivo no es memorizar una lista de comandos aislados, sino comprender la arquitectura que explica su comportamiento y permite trasladar conocimientos entre plataformas.

2. ORIGEN Y EVOLUCIÓN HISTÓRICA DE UNIX

2.1. De Multics a Unix

Unix nació en 1969 en los Bell Labs de AT&T, principalmente por el trabajo de Ken Thompson, Dennis Ritchie y otros colaboradores. El contexto inmediato fue la experiencia con Multics, un proyecto ambicioso de sistema de tiempo compartido en el que participaron MIT, General Electric y Bell Labs. Multics introdujo ideas avanzadas, pero su complejidad y coste impulsaron a Thompson a buscar una solución más pequeña y manejable. El primer Unix funcionó en un PDP-7 y se construyó alrededor de necesidades muy concretas: disponer de un sistema interactivo, un sistema de archivos jerárquico y herramientas de programación.

La decisión histórica más influyente fue reescribir gran parte del sistema en el lenguaje C alrededor de 1973. En aquella época los sistemas operativos se programaban casi por completo en ensamblador y quedaban ligados a una arquitectura. C permitió conservar una capa reducida dependiente de la máquina y expresar el resto con un lenguaje portable. Esta separación facilitó trasladar Unix a nuevos procesadores, estudiar su código y crear variantes. La portabilidad no fue absoluta, porque seguían existiendo controladores y partes específicas, pero cambió la economía del desarrollo de sistemas.

2.2. Investigación, universidades y BSD

Las restricciones regulatorias que afectaban a AT&T favorecieron durante años la distribución de Unix a universidades con código fuente. La Universidad de California en Berkeley desarrolló la Berkeley Software Distribution. BSD incorporó mejoras esenciales: pila TCP/IP, sockets, memoria virtual avanzada, control de trabajos, el editor vi, la shell C y el Berkeley Fast File System. Algunas aportaciones se integraron después en otros Unix y terminaron formando parte del acervo común de Internet.

BSD no debe entenderse solo como una distribución histórica. De su evolución surgieron proyectos actuales como FreeBSD, NetBSD y OpenBSD. Además, el código y las interfaces BSD influyeron en numerosos sistemas comerciales y en Darwin, base de macOS. La licencia BSD, permisiva, permitió reutilizar componentes con obligaciones de redistribución menos intensas que la GPL.

2.3. System V, Unix comerciales y las guerras Unix

AT&T consolidó su línea en UNIX System V. Durante los años ochenta y noventa convivieron dos grandes tradiciones, BSD y System V, junto con variantes de fabricantes. Sun desarrolló SunOS y después Solaris; IBM, AIX; Hewlett-Packard, HP-UX; Silicon Graphics, IRIX; y otros proveedores crearon implementaciones para su hardware. Cada plataforma incorporó extensiones, formatos de administración y herramientas propias. La fragmentación dificultó portar aplicaciones y administrar entornos heterogéneos.

La competencia entre consorcios y fabricantes, conocida como las guerras Unix, mostró la tensión entre diferenciación comercial y compatibilidad. La solución fue avanzar hacia estándares de interfaces, no hacia un único código fuente. POSIX y la Single UNIX Specification definieron comportamientos comunes para llamadas al sistema, bibliotecas, shell y utilidades. La aplicación podía recompilarse con cambios limitados si respetaba esas interfaces.

2.4. GNU, Linux y la recomposición del ecosistema

El proyecto GNU, iniciado por Richard Stallman en 1983, construyó compiladores, bibliotecas, shell y numerosas utilidades libres con el objetivo de crear un sistema compatible con Unix. A comienzos de los noventa faltaba un núcleo de uso general suficientemente maduro. En 1991 Linus Torvalds inició Linux como kernel para equipos compatibles con Intel 386. La combinación del kernel Linux con herramientas GNU y otros componentes dio lugar a distribuciones completas.

Linux no deriva del código Unix original: es una reimplementación independiente de conceptos e interfaces de tipo Unix. Su licencia GPLv2, el desarrollo colaborativo, la disponibilidad en múltiples arquitecturas y la aparición de distribuidores empresariales transformaron el mercado. El ecosistema pasó de múltiples Unix propietarios ligados a hardware específico a una plataforma abierta capaz de ejecutarse en x86-64, ARM, POWER, IBM Z y otras arquitecturas.

3. UNIX, POSIX Y SISTEMAS TIPO UNIX

3.1. La marca UNIX y la certificación

UNIX es una marca registrada de The Open Group. La certificación se concede a productos que demuestran conformidad con la Single UNIX Specification y cumplen las condiciones del programa. Por tanto, no basta con parecerse a Unix ni con implementar una shell y unas cuantas utilidades. La conformidad se verifica respecto a un conjunto preciso de interfaces, comportamientos y entornos de programación.

La certificación proporciona un lenguaje común para contratación y portabilidad. Una organización que adquiere un producto certificado obtiene un grado definido de compatibilidad para aplicaciones que se ajusten al estándar. Sin embargo, la certificación no garantiza por sí sola rendimiento, seguridad, alta disponibilidad ni compatibilidad binaria entre arquitecturas. Es un requisito de conformidad, no una evaluación completa de la plataforma.

3.2. POSIX

POSIX, Portable Operating System Interface, es la familia de estándares impulsada por IEEE y The Open Group para codificar interfaces comunes de los sistemas tipo Unix. La edición vigente del núcleo estándar es IEEE Std 1003.1-2024, publicada conjuntamente como The Open Group Base Specifications Issue 8. Incluye definiciones base, interfaces de sistema, lenguaje de shell y utilidades. Su alcance cubre aspectos como creación de procesos, señales, archivos, terminales, hilos, sincronización, expresiones regulares y comportamiento de comandos.

La portabilidad POSIX se apoya en código fuente. Una aplicación escrita en C que usa funciones estandarizadas puede recompilarse para distintas plataformas. No implica que un binario producido para Linux x86-64 pueda ejecutarse directamente en AIX sobre POWER. Cambian el formato ejecutable, la ABI, las bibliotecas, el tamaño y orden de datos, el enlazado y la arquitectura de instrucciones.

3.3. Conformidad completa, compatibilidad práctica y extensiones

Muchos sistemas implementan amplias porciones de POSIX sin certificarse. Linux ofrece un entorno muy compatible, pero también extensiones propias como epoll, inotify, namespaces, cgroups o capacidades Linux. BSD dispone de mecanismos como kqueue y jails. Solaris introdujo DTrace, Zones, SMF y ZFS. AIX añade su administración específica, LVM y tecnologías vinculadas a IBM Power. Estas extensiones pueden aportar valor, pero crean dependencia de plataforma.

En diseño de software conviene separar una capa portable de otra específica. La capa portable usa POSIX y bibliotecas multiplataforma; la capa específica encapsula optimizaciones o servicios del proveedor. Así se evita dispersar llamadas exclusivas por toda la aplicación. En contratación pública o sanitaria, esta separación reduce riesgo de bloqueo tecnológico y facilita planes de migración.

4. FILOSOFÍA Y PRINCIPIOS DE DISEÑO

4.1. Programas pequeños y composición

La filosofía Unix se resume habitualmente con la regla “hacer una cosa y hacerla bien”. No significa que cada ejecutable tenga que ser trivial, sino que debe poseer una responsabilidad coherente, interfaces previsibles y capacidad de combinarse con otros. Una herramienta que filtra líneas, otra que ordena y otra que agrega resultados pueden encadenarse sin diseñar una aplicación monolítica.

La composición se realiza mediante tuberías. Una tubería conecta la salida estándar de un proceso con la entrada estándar de otro. El usuario crea un flujo de datos sin necesidad de archivos intermedios ni programación adicional. Este patrón influyó en arquitecturas posteriores: filtros, canalizaciones de integración continua, procesamiento por etapas y microservicios con interfaces delimitadas.

journalctl -u ssh.service --since today | grep "Failed" | sort | uniq -c

El ejemplo anterior combina herramientas con responsabilidades distintas: una obtiene registros, otra filtra, otra ordena y otra cuenta repeticiones. La potencia está en el contrato común de texto y flujos estándar, no en que una sola utilidad conozca todo el problema.

4.2. Texto, flujos y mecanismos universales

Unix favorece formatos textuales para configuración e intercambio porque pueden inspeccionarse, versionarse y transformarse con herramientas genéricas. No debe absolutizarse: bases de datos, índices, ejecutables y formatos multimedia son binarios por razones legítimas. La enseñanza útil es preferir interfaces simples y documentadas cuando el coste sea aceptable.

La expresión “todo es un archivo” es una simplificación pedagógica. Muchos recursos se exponen mediante descriptores de archivo y operaciones uniformes como leer, escribir o cerrar. Los dispositivos aparecen como nodos bajo /dev; las tuberías y sockets también pueden manejarse con descriptores. Sin embargo, un proceso, una credencial o una interfaz de red no son literalmente archivos ordinarios. Linux amplía la idea con sistemas virtuales como /proc y /sys.

4.3. Separación entre política y mecanismo

Un buen diseño distingue el mecanismo básico de la política de uso. El núcleo proporciona mecanismos de planificación, memoria, permisos o comunicación; administradores y servicios definen políticas mediante prioridades, límites, reglas y configuración. Esta separación permite adaptar el sistema sin reescribir el núcleo.

Otra regla es evitar interfaces cautivas. Una operación que solo puede realizarse mediante una interfaz gráfica dificulta automatización, auditoría y repetibilidad. En Unix, la línea de comandos, los archivos de configuración y las APIs permiten representar la infraestructura como código. La interfaz gráfica puede seguir existiendo, pero debe apoyarse en mecanismos administrables.

4.4. Consecuencias para arquitectura y operación

La modularidad reduce acoplamiento, pero también puede generar pipelines frágiles si se analizan textos destinados a humanos, si no se controlan errores o si se ignoran codificación y localización. Los scripts de producción deben validar códigos de salida, citar variables, registrar operaciones y evitar suposiciones sobre el entorno. La filosofía Unix no exime de ingeniería; proporciona bloques que deben combinarse con disciplina.

5. ARQUITECTURA FUNCIONAL DE UNIX

5.1. Núcleo y espacio de usuario

La arquitectura separa el kernel del espacio de usuario. El kernel se ejecuta en modo privilegiado y controla CPU, memoria, interrupciones, dispositivos, sistemas de archivos y comunicaciones. Los procesos de usuario se ejecutan con privilegios restringidos. Cuando necesitan un servicio protegido invocan una llamada al sistema, que transfiere el control al núcleo mediante una interfaz definida.

Esta frontera es esencial para la estabilidad. Un fallo en una aplicación no debería permitir escribir directamente en memoria del kernel ni programar un dispositivo arbitrariamente. El procesador impone modos de ejecución y tablas de páginas; el sistema operativo valida parámetros y permisos. Los controladores forman parte del entorno privilegiado en muchos Unix, por lo que un error en ellos puede afectar a todo el sistema.

5.2. Llamadas al sistema y bibliotecas

Las aplicaciones suelen llamar a funciones de bibliotecas, como la biblioteca C, que pueden resolver la operación íntegramente en usuario o encapsular una llamada al sistema. printf() es una función de biblioteca; finalmente puede usar write() para enviar datos a un descriptor. La distinción importa para depuración, rendimiento y portabilidad.

Entre las llamadas clásicas se encuentran fork(), que crea un proceso hijo; la familia exec(), que sustituye la imagen del proceso por otro programa; wait(), que permite recoger la terminación de hijos; open(), read(), write() y close(), para E/S; mmap(), para mapear memoria; y las operaciones de sockets. POSIX fija gran parte de estas interfaces, aunque cada sistema añade extensiones.

5.3. Núcleos monolíticos, modulares e híbridos

Los Unix tradicionales y Linux se describen habitualmente como núcleos monolíticos: los principales servicios del sistema se ejecutan en el espacio del kernel. “Monolítico” no significa necesariamente estático. Linux permite cargar y descargar módulos para controladores, sistemas de archivos y otras funciones. La modularidad reduce el tamaño inicial y facilita mantenimiento, aunque el módulo cargado conserva privilegios de kernel.

Darwin utiliza XNU, un núcleo híbrido que combina Mach con componentes BSD y controladores I/O Kit. Solaris y AIX tienen arquitecturas propias con servicios integrados y extensiones modulares. La clasificación debe manejarse como modelo conceptual: en productos reales existen combinaciones y compromisos.

5.4. Subsistemas principales

6. PROCESOS, PLANIFICACIÓN, SEÑALES E IPC

6.1. Proceso, hilo y contexto de ejecución

Un programa es un conjunto pasivo de instrucciones almacenadas; un proceso es una instancia en ejecución con espacio de direcciones, credenciales, descriptores, entorno y estado de CPU. Un mismo ejecutable puede originar muchos procesos. Los hilos de un proceso comparten memoria y recursos, pero poseen su propia pila y contexto de planificación.

Cada proceso se identifica mediante un PID. El núcleo mantiene relaciones de parentesco, credenciales reales y efectivas, grupos de procesos y sesiones. En el modelo clásico, fork() crea un hijo que hereda gran parte del contexto; exec() carga otro programa. En Linux se aplican optimizaciones como copia en escritura: las páginas no se duplican físicamente hasta que alguno de los procesos modifica su contenido.

6.2. Estados y cambios de contexto

Un proceso puede estar ejecutándose, listo para usar CPU, bloqueado esperando E/S o un evento, detenido o finalizado a la espera de que su padre recoja el estado. Los nombres exactos varían entre sistemas. El cambio de contexto guarda el estado de una tarea y restaura el de otra. Es imprescindible para multitarea, pero tiene coste: registros, cachés, TLB y datos del planificador.

6.3. Tiempo compartido, prioridades y políticas

En un sistema monoprocesador solo una tarea ejecuta instrucciones en un instante, aunque el usuario perciba simultaneidad gracias a la alternancia rápida. El planificador decide qué tarea preparada recibe CPU. Los criterios pueden incluir prioridad, política, afinidad, consumo previo, latencia objetivo y requisitos de tiempo real. El quantum limita durante cuánto tiempo puede ejecutarse una tarea en determinadas políticas, pero no es por sí solo el criterio universal de selección.

Unix distingue prioridades normales y de tiempo real. La utilidad nice ajusta una preferencia relativa para procesos convencionales; un valor “más agradable” cede CPU y suele representar menor prioridad. Los detalles del algoritmo cambian entre Unix. En Linux moderno, el planificador normal ha evolucionado y utiliza estructuras y métricas de equidad; por ello no debe memorizarse un algoritmo histórico como si fuera inmutable.

6.4. Señales

Las señales notifican eventos asíncronos a un proceso. Pueden originarse por el kernel, otro proceso o el propio proceso. Algunas se capturan y gestionan; otras tienen acción fija. SIGTERM solicita terminación ordenada y permite limpieza; SIGKILL fuerza la terminación y no puede capturarse ni ignorarse; SIGHUP se usa históricamente para pérdida de terminal y, por convención, para solicitar recarga a muchos demonios.

La administración correcta intenta primero una terminación cooperativa y reserva la fuerza para procesos que no responden. Matar un proceso sin comprender su función puede dejar transacciones incompletas, bloqueos o recuperación prolongada.

6.5. Comunicación entre procesos

Unix ofrece múltiples mecanismos IPC: tuberías anónimas, FIFO con nombre, señales, memoria compartida, semáforos, colas de mensajes y sockets. La elección depende del volumen de datos, relación entre procesos, persistencia, sincronización y alcance local o remoto. La memoria compartida ofrece alto rendimiento, pero exige sincronización explícita; los sockets ofrecen una abstracción uniforme y pueden atravesar la red.

ps -eo pid,ppid,user,stat,ni,comm
nice -n 10 comando
kill -TERM 1234
kill -KILL 1234

7. MODELO MULTIUSUARIO, IDENTIDADES, PERMISOS Y PRIVILEGIOS

7.1. Usuarios, grupos y credenciales numéricas

La administración Unix se basa en identidades numéricas. El UID identifica a un usuario y el GID a un grupo. Los nombres de inicio de sesión son representaciones legibles asociadas a esos números. El kernel toma decisiones de propiedad y autorización utilizando credenciales numéricas, no cadenas de texto. Por ello, restaurar archivos en un sistema cuyas correspondencias de UID han cambiado puede asignar aparentemente la propiedad a otro nombre.

El UID 0 posee tradicionalmente privilegios de superusuario y se asocia a root. No debe deducirse que todos los demás UID sean automáticamente “usuarios humanos”: existen cuentas de servicio sin shell interactiva, cuentas del sistema y usuarios técnicos. La asignación de rangos depende de la distribución y de la política local.

En bases locales, /etc/passwd mantiene información pública de cuenta y /etc/shadow contiene datos protegidos de contraseña en Linux. En entornos corporativos, NSS y PAM permiten integrar LDAP, Kerberos, Active Directory u otros directorios. La autenticación responde a “quién eres”; la autorización decide “qué puedes hacer”.

7.2. Propiedad y permisos tradicionales

Cada archivo posee propietario y grupo. Los permisos clásicos se dividen en tres categorías: usuario propietario, grupo y otros. Para cada categoría existen bits de lectura, escritura y ejecución. Su significado depende del tipo de objeto. En un archivo regular, lectura permite acceder al contenido, escritura modificarlo y ejecución solicitar al kernel que lo ejecute si el formato y el montaje lo permiten. En un directorio, lectura permite enumerar nombres, escritura crear o eliminar entradas y ejecución atravesar el directorio y resolver rutas.

-rwxr-x--- 1 ana sistemas 4096 ago  4 10:00 script.sh

La notación simbólica anterior indica archivo regular; propietario con lectura, escritura y ejecución; grupo con lectura y ejecución; y sin permisos para otros. La notación octal agrupa los bits: lectura vale 4, escritura 2 y ejecución 1. Así, 750 representa rwxr-x---.

chmod 750 script.sh
chown ana:sistemas script.sh
umask 027

chmod modifica modos; chown cambia propietario y, opcionalmente, grupo; umask elimina permisos de los valores iniciales solicitados al crear objetos. No “asigna permisos por defecto” sumando bits: actúa como máscara de exclusión.

7.3. Bits especiales y ACL

El bit setuid en un ejecutable permite que el proceso use como UID efectivo el propietario del archivo, bajo las condiciones del sistema. El bit setgid puede aplicar el grupo efectivo del ejecutable y, en directorios, hacer que nuevas entradas hereden el grupo del directorio. El sticky bit en un directorio compartido restringe la eliminación para que un usuario no borre libremente archivos de otros, como ocurre típicamente en /tmp.

Las ACL amplían el modelo y permiten permisos para usuarios o grupos adicionales. Son útiles cuando el esquema propietario-grupo-otros es insuficiente, pero deben documentarse porque una inspección superficial de los bits tradicionales puede ocultar autorizaciones efectivas. Las herramientas suelen marcar la presencia de ACL con un signo adicional.

7.4. Privilegios delegados y sudo

Compartir la contraseña de root destruye trazabilidad y aumenta riesgo. sudo permite autorizar comandos concretos a usuarios o grupos, normalmente registrando quién ejecutó la acción. La política reside en /etc/sudoers y archivos incluidos, que deben editarse con herramientas que validen sintaxis, como visudo. Según la configuración, sudo puede solicitar la contraseña del usuario invocante, reutilizar una credencial temporal o no pedir contraseña mediante reglas NOPASSWD.

7.5. Controles reforzados

Los permisos discrecionales se complementan con controles obligatorios y reducción de privilegios. Linux incorpora capacidades que fragmentan parte del poder de root, además de marcos como SELinux y AppArmor. Solaris, AIX, BSD y otros Unix disponen de mecanismos propios. Una arquitectura segura aplica mínimo privilegio, separación de funciones, cuentas de servicio sin inicio interactivo, autenticación fuerte, revisión de sudoers, caducidad y auditoría.

8. SISTEMA DE ARCHIVOS, INODOS, MONTAJES Y ALMACENAMIENTO

8.1. Espacio de nombres único

Unix presenta un árbol único que comienza en la raíz /. Los distintos sistemas de archivos se incorporan en puntos de montaje. No existe la obligación conceptual de asignar una letra independiente a cada volumen. Un directorio puede pertenecer al sistema raíz o ser el punto donde se monta otro dispositivo, volumen lógico, recurso de red o sistema virtual.

Las rutas absolutas comienzan en /; las relativas se interpretan desde el directorio de trabajo. . representa el directorio actual y .. el superior. La resolución de rutas comprueba permisos de búsqueda en cada componente. Los nombres suelen distinguir mayúsculas y minúsculas, aunque existen excepciones según el sistema de archivos y su configuración.

8.2. Inodos, nombres y enlaces

En sistemas de archivos de tradición Unix, un inodo almacena metadatos: tipo, permisos, propietario, grupo, marcas temporales, tamaño, recuento de enlaces y referencias a datos. El nombre se guarda en una entrada de directorio que asocia nombre e inodo. Esta separación explica los enlaces duros: varios nombres pueden apuntar al mismo inodo.

Un enlace duro es otra entrada de directorio para el mismo objeto. Normalmente no atraviesa sistemas de archivos y se restringe sobre directorios para evitar ciclos. Un enlace simbólico es un archivo especial que contiene una ruta; puede cruzar sistemas y quedar colgante si el destino desaparece. El archivo se elimina realmente cuando su contador de enlaces llega a cero y ningún proceso mantiene una referencia abierta.

8.3. Directorios habituales y FHS

El Filesystem Hierarchy Standard orienta la organización de muchas distribuciones Linux. No todos los Unix siguen exactamente FHS, pero la lógica general es útil:

8.4. Sistemas de archivos y journaling

Linux admite ext4, XFS, Btrfs, OpenZFS y muchos otros; también puede leer o escribir formatos de intercambio según controladores disponibles. AIX utiliza JFS/JFS2; Solaris destaca por ZFS; FreeBSD integra UFS y OpenZFS. La elección debe considerar tamaño máximo, rendimiento, consistencia, instantáneas, compresión, cuotas, cifrado, recuperación, soporte del fabricante y herramientas operativas.

El journaling registra operaciones o metadatos antes de consolidarlos para acelerar recuperación tras una interrupción. No sustituye a una copia de seguridad y no garantiza que una aplicación haya dejado sus datos en un estado lógico válido. Las aplicaciones transaccionales deben coordinar escrituras y sincronización.

8.5. Montajes, capacidad e inodos

df informa del espacio por sistema montado y du estima uso por directorios y archivos. Un sistema puede quedarse sin inodos aun teniendo bloques libres, especialmente si aloja millones de objetos pequeños. Los archivos borrados que siguen abiertos por un proceso continúan ocupando espacio hasta cerrar el descriptor; esta situación explica discrepancias entre df y du.

findmnt
df -h
df -i
du -sh /var/*
lsblk

8.6. LVM, RAID y capas de almacenamiento

La administración empresarial separa discos físicos, agregación, volúmenes y sistemas de archivos. Linux LVM y AIX LVM permiten agrupar volúmenes físicos, crear grupos y asignar volúmenes lógicos. RAID aporta redundancia o rendimiento según nivel, pero no reemplaza copias independientes. Las instantáneas facilitan consistencia temporal y pruebas de recuperación, pero dependen del almacenamiento origen.

9. SHELL, UTILIDADES, TUBERÍAS, REDIRECCIONES Y SCRIPTING

9.1. Función de la shell

La shell es un intérprete de órdenes y un lenguaje de programación. Lee una línea, realiza expansiones, establece redirecciones, crea pipelines y ejecuta programas. sh representa la interfaz histórica y estandarizada; Bash, Korn shell, Z shell y otras añaden funciones. Un script que deba ser portable debe limitarse al lenguaje POSIX o declarar explícitamente la shell requerida.

La shell distingue entre comandos internos y ejecutables externos. Operaciones como cambiar el directorio deben ejecutarse dentro de la propia shell, porque un proceso hijo no puede modificar el directorio de trabajo de su padre. La búsqueda de ejecutables utiliza PATH; introducir directorios inseguros o el directorio actual en posiciones inadecuadas crea riesgo de ejecutar un programa falso.

9.2. Entrada, salida y errores estándar

Por convención, un proceso recibe los descriptores 0, 1 y 2: entrada estándar, salida estándar y error estándar. La redirección cambia su destino antes de ejecutar el programa. > crea o trunca la salida; >> añade; < toma entrada; 2> redirige errores. El orden de redirecciones puede importar porque se duplican descriptores en el momento de procesarlas.

comando >salida.txt 2>errores.txt
comando >>historico.log 2>&1
productor | filtro | consumidor

Una tubería transporta la salida de una etapa a la entrada de la siguiente. La shell crea los procesos y conecta descriptores. En pipelines de producción debe considerarse qué código de salida se evalúa y cómo se detecta el fallo de una etapa intermedia.

9.3. Expansiones y quoting

Antes de ejecutar, la shell puede expandir variables, patrones de nombres, sustituciones de comandos y expresiones aritméticas. Las comillas simples preservan literalmente el contenido; las dobles permiten ciertas expansiones pero evitan separación de palabras y expansión de comodines. No citar una variable con espacios o caracteres especiales es una fuente recurrente de errores y vulnerabilidades.

archivo="Informe agosto 2026.txt"
printf '%sn' "$archivo"
for elemento in "$@"; do
  printf '%sn' "$elemento"
done

9.4. Utilidades clásicas

grep selecciona líneas mediante patrones; sed transforma flujos; awk procesa registros y campos; sort ordena; uniq elimina o cuenta duplicados adyacentes; cut selecciona columnas; find recorre árboles; xargs construye invocaciones a partir de entrada. La elección debe respetar nombres con espacios y bytes especiales; cuando sea posible, se usan delimitadores nulos en operaciones sobre rutas.

9.5. Calidad de scripts

Un script administrativo debe declarar intérprete, validar argumentos, comprobar errores, registrar cambios y ser idempotente cuando proceda. La opción set -e no convierte automáticamente un script en robusto: tiene excepciones y puede terminar en lugares no esperados. Es preferible diseñar control de errores explícito en operaciones críticas.

#!/bin/sh
set -u

if [ "$#" -ne 1 ]; then
  printf 'Uso: %s directorion' "$0" >&2
  exit 2
fi

directorio=$1
if [ ! -d "$directorio" ]; then
  printf 'No existe el directorio: %sn' "$directorio" >&2
  exit 1
fi

find "$directorio" -type f -mtime +30 -print

El ejemplo informa, pero no borra. En automatización sanitaria o corporativa conviene separar inventario, validación y acción destructiva. Antes de eliminar, deben definirse exclusiones, retención, propietario del dato, copia y evidencia de ejecución.

10. ARRANQUE, SERVICIOS, TAREAS PROGRAMADAS Y REGISTRO

10.1. Fases generales de arranque

El arranque comienza en firmware y cargador, continúa con la carga del kernel y un sistema inicial de archivos, detección de hardware, montaje de la raíz y lanzamiento del primer proceso de espacio de usuario. Históricamente, ese proceso fue init con PID 1. Cada familia implementa detalles propios: SysV init, BSD init, systemd en muchas distribuciones Linux, SMF en Solaris o subsistemas específicos en AIX.

PID 1 posee responsabilidades especiales: adopta procesos huérfanos y participa en la recolección de estados. En Linux, systemd actúa como gestor de sistema y servicios, representa dependencias mediante unidades, utiliza activación por sockets y D-Bus, y organiza servicios con cgroups. La configuración declarativa permite iniciar, detener, reiniciar, habilitar y consultar estado.

systemctl status ssh.service
systemctl restart ssh.service
systemctl enable ssh.service
systemctl list-dependencies multi-user.target

start afecta al estado actual; enable configura el arranque futuro. Un servicio puede estar iniciado pero no habilitado, o habilitado pero fallar al arrancar. Confundir ambos conceptos produce diagnósticos incorrectos.

10.2. Demonios

Un demonio es un proceso de larga duración que presta un servicio o realiza trabajo en segundo plano. Puede escuchar una red, procesar colas, programar tareas o recoger registros. En diseños actuales no es imprescindible que el programa se “daemonice” por sí mismo: el gestor de servicios puede mantenerlo en primer plano, capturar su salida y reiniciarlo según política.

10.3. Tareas programadas

cron es el planificador clásico de tareas periódicas. Las reglas pueden definirse en crontabs de usuario y archivos del sistema. Una entrada especifica minutos, horas, días del mes, meses y días de la semana, seguida del comando. Deben controlarse entorno reducido, rutas absolutas, zona horaria, concurrencia, duración, bloqueo, correo o registro de errores.

15 2 * * * /usr/local/sbin/verificar-copias >>/var/log/verificar-copias.log 2>&1

El ejemplo ejecuta diariamente a las 02:15 según la interpretación del demonio. Para tareas que no deben solaparse se requiere un mecanismo de exclusión. Los temporizadores de systemd ofrecen dependencias, persistencia y registro integrado, pero cron sigue siendo una referencia fundamental y portable.

10.4. Registro y observabilidad

Unix tradicional utiliza syslog; Linux puede combinar syslog con el journal de systemd. Los registros deben centralizarse, protegerse y retenerse conforme a requisitos operativos y de seguridad. journalctl consulta el journal por unidad, prioridad, arranque o intervalo. Los logs no deben contener contraseñas, tokens ni datos personales innecesarios.

journalctl -u ssh.service --since "2026-08-04 00:00:00"
journalctl -p warning..alert -b

10.5. Operación segura

La gestión de servicios debe aplicar cambios controlados: verificar configuración, guardar evidencia, comprobar dependencias, definir reversión y monitorizar después. Reiniciar de forma indiscriminada puede ocultar la causa y producir indisponibilidad. En servicios críticos se valoran recarga sin interrupción, balanceo, drenaje de conexiones y despliegue por nodos.

11. REDES Y ADMINISTRACIÓN REMOTA

11.1. Sockets y pila TCP/IP

BSD introdujo la API de sockets que se convirtió en interfaz fundamental de red. Un socket representa un extremo de comunicación. En TCP se crea, se enlaza a una dirección, se pone en escucha y se aceptan conexiones; el cliente conecta y ambos intercambian flujos. UDP trabaja con datagramas sin conexión lógica equivalente. Los sockets Unix de dominio local permiten IPC con semántica de socket sin atravesar la red.

El sistema mantiene interfaces, direcciones, rutas, tablas de vecinos, puertos y estados de conexión. En Linux, la suite ip ha sustituido en gran medida a herramientas históricas como ifconfig y route. ss consulta sockets. La disponibilidad exacta depende de la plataforma.

ip address show
ip route show
ss -lntup
ping -c 4 destino.example

11.2. Resolución de nombres

Las aplicaciones no suelen consultar DNS de forma aislada; utilizan el resolvedor y la política configurada mediante NSS, archivos locales y servidores. /etc/hosts puede resolver nombres locales, mientras /etc/resolv.conf o un servicio gestor define resolvedores. En sistemas con servicios dinámicos, el archivo puede ser generado. El diagnóstico debe distinguir conectividad IP, enrutamiento, resolución y disponibilidad de aplicación.

11.3. SSH

OpenSSH proporciona acceso remoto cifrado, transferencia y túneles. La autenticación por clave pública evita compartir contraseñas y facilita automatización, pero la clave privada debe protegerse. Una política segura limita usuarios, deshabilita algoritmos obsoletos, controla acceso de root, aplica MFA cuando proceda y registra intentos.

ssh usuario@servidor
scp informe.txt usuario@servidor:/srv/intercambio/
sftp usuario@servidor

La comprobación de la clave de host es esencial para detectar suplantación. Aceptar automáticamente cualquier huella elimina una protección básica. En automatización se distribuyen claves de host conocidas por canales controlados.

11.4. Cortafuegos, filtrado y servicios

La defensa de red combina segmentación, listas de control, firewall local, autenticación y endurecimiento del servicio. En Linux, nftables es el marco moderno del kernel; distribuciones ofrecen interfaces como firewalld o ufw. OpenBSD es conocido por PF. Solaris y AIX disponen de sus propias herramientas. Debe administrarse la política, no memorizar una sintaxis universal inexistente.

11.5. Diagnóstico por capas

1. Comprobar estado físico o virtual de interfaz.
2. Verificar dirección, máscara y ruta.
3. Comprobar resolución de nombre.
4. Confirmar que el servicio escucha en la dirección y puerto esperados.
5. Revisar firewall, control de acceso y registros.
6. Validar protocolo de aplicación y certificados.

12. FAMILIA BSD Y OTROS SISTEMAS TIPO UNIX

12.1. FreeBSD

FreeBSD es un sistema operativo completo de código abierto derivado de la tradición BSD. A diferencia de una distribución Linux, donde kernel y numerosos componentes proceden de proyectos independientes integrados por el distribuidor, FreeBSD desarrolla de forma coordinada un sistema base que incluye kernel, bibliotecas y utilidades. El software adicional se obtiene mediante Ports y paquetes.

Sus ámbitos característicos incluyen servidores de red, almacenamiento, appliances y plataformas que valoran una pila integrada. FreeBSD incorpora jails, aislamiento a nivel de sistema operativo anterior a la popularización de los contenedores Linux. Una jail restringe vista de archivos, procesos, usuarios y red. FreeBSD integra OpenZFS y el hipervisor bhyve.

12.2. NetBSD

NetBSD prioriza portabilidad, limpieza de diseño y separación entre código dependiente e independiente de máquina. Su lema refleja la ejecución sobre una gran variedad de arquitecturas. pkgsrc proporciona paquetes y puede utilizarse también en otros sistemas. Es relevante como ejemplo de ingeniería portable y soporte de hardware diverso.

12.3. OpenBSD

OpenBSD enfatiza corrección, auditoría de código, seguridad proactiva y criptografía integrada. De este proyecto procede OpenSSH. Sus prácticas incluyen valores seguros por defecto, documentación rigurosa y revisión continua. No debe presentarse como “invulnerable”: ningún sistema lo es. Su aportación es una cultura de reducción de superficie y corrección sistemática.

12.4. Darwin y macOS

Darwin es la base de macOS e integra el núcleo XNU, componentes BSD y tecnologías de Apple. macOS ofrece shell y numerosas interfaces Unix, y determinadas versiones figuran como productos UNIX certificados. La certificación se aplica a una versión y entorno concretos, no automáticamente a todo dispositivo de Apple ni a cualquier versión futura.

macOS utiliza APFS, launchd y herramientas de administración propias; por tanto, conocer Linux no convierte automáticamente a una persona en administradora de macOS. Comparten conceptos, pero difieren en servicios, paquetes, seguridad, interfaces gráficas y ciclo de plataforma.

12.5. Comparación de familias

13. LINUX: KERNEL, ESPACIO DE USUARIO Y FUNCIONALIDADES

13.1. Qué es Linux

Linux es un kernel libre iniciado por Linus Torvalds en 1991 y mantenido por una comunidad internacional con participación de empresas, fundaciones y desarrolladores independientes. Su licencia principal es GPLv2. El kernel por sí solo no constituye la experiencia completa que instala un administrador: necesita cargador, biblioteca C, shell, utilidades, sistema de inicio, paquetes, instalador y políticas de actualización. Por eso es preciso hablar de una distribución Linux o, cuando se destaca el peso de las herramientas GNU, de GNU/Linux.

El proyecto utiliza un desarrollo ascendente: cambios revisados por mantenedores de subsistemas llegan al repositorio principal. Las versiones del kernel avanzan con rapidez, pero las distribuciones empresariales seleccionan una rama, aplican correcciones y realizan backports. El número de versión visible puede parecer antiguo y, sin embargo, incorporar parches de seguridad y controladores recientes. No debe juzgarse el estado de seguridad solo por comparar números con kernel.org.

13.2. Kernel monolítico modular

Linux integra planificación, memoria, VFS, red y controladores en el espacio privilegiado, pero permite módulos cargables. modprobe resuelve dependencias y carga módulos; lsmod muestra los presentes. La configuración del kernel determina qué funciones están integradas, disponibles como módulo o ausentes. En entornos seguros se limita la carga y se firma código de kernel.

La interfaz de configuración en ejecución se expone parcialmente mediante sysctl y archivos virtuales. Los cambios temporales pueden perderse al reiniciar; la persistencia se define en archivos de configuración administrados por la distribución. Ajustar parámetros sin medir puede degradar rendimiento o seguridad.

uname -r
lsmod
sysctl net.ipv4.ip_forward
sysctl vm.swappiness

13.3. Memoria virtual

Cada proceso percibe un espacio de direcciones virtual. Las tablas de páginas traducen direcciones virtuales a marcos físicos y aplican protección. El sistema comparte páginas de bibliotecas, usa caché de página para E/S y puede intercambiar páginas con almacenamiento secundario. La memoria “usada” incluye caché reutilizable; interpretar únicamente una cifra de memoria libre conduce a alarmas falsas.

El kernel afronta presión de memoria mediante recuperación de cachés, escritura de páginas, swap y, en situaciones extremas, el OOM killer. La elección de víctima depende de puntuaciones y protección configurada. En servidores críticos se establecen límites, reservas, monitorización y pruebas de carga; no se confía en el OOM como mecanismo ordinario.

13.4. VFS, E/S y dispositivos

El Virtual File System permite que las aplicaciones usen una interfaz común sobre ext4, XFS, NFS, tmpfs, procfs y otros formatos. El subsistema de bloques gestiona colas y planificadores de E/S; los controladores conectan con dispositivos. udev, integrado en el ecosistema systemd en muchas distribuciones, crea y administra nodos de dispositivo en respuesta a eventos.

Linux ofrece interfaces de E/S avanzadas como epoll e io_uring, además de las POSIX tradicionales. Son extensiones útiles para servidores concurrentes, pero reducen portabilidad directa a otros Unix.

13.5. Namespaces y cgroups

Los namespaces aíslan vistas de recursos: procesos, montajes, red, UTS, IPC, usuarios, cgroups y tiempo, según versión y configuración. Los cgroups organizan procesos jerárquicamente y distribuyen o limitan CPU, memoria, E/S y otros recursos. Un contenedor combina estos mecanismos con sistemas de archivos, capacidades, filtros y una imagen de usuario.

Un contenedor no es una máquina virtual completa. Comparte kernel con el host y el aislamiento depende de la configuración y de la seguridad del kernel. Una máquina virtual emula o virtualiza hardware y puede ejecutar otro kernel. Esta distinción afecta a densidad, compatibilidad, superficie de ataque y operación.

13.6. Seguridad del kernel y espacio de usuario

Linux soporta capacidades, seccomp, LSM, namespaces de usuario, cifrado, arranque seguro y módulos de control obligatorio. SELinux aplica políticas basadas en etiquetas; AppArmor emplea perfiles centrados en rutas y capacidades. Ningún mecanismo sustituye actualización, configuración mínima, autenticación y segmentación. La seguridad emerge de capas.

13.7. Observabilidad

El administrador dispone de /proc, /sys, contadores, trazas, logs y herramientas de rendimiento. top o ps muestran procesos; vmstat, iostat y sar ayudan a observar carga; strace registra llamadas al sistema de un proceso; perf y eBPF permiten análisis avanzado. La observabilidad debe empezar con una hipótesis y métricas, no con la ejecución indiscriminada de herramientas invasivas.

14. DISTRIBUCIONES LINUX Y GESTIÓN DE PAQUETES

14.1. Concepto de distribución

Una distribución integra componentes de muchos proyectos en un producto instalable y mantenible. Decide versiones, parches, opciones de compilación, rutas, valores predeterminados, formato de paquetes, repositorios, instalador, documentación y política de seguridad. Dos distribuciones con el mismo kernel pueden diferir de forma importante en ABI, bibliotecas, herramientas, ciclo de soporte y certificaciones.

La selección debe partir del caso de uso. En un servidor clínico o corporativo importan soporte del fabricante de la aplicación, plazo de mantenimiento, disponibilidad de parches, certificaciones, arquitectura, automatización, personal disponible y recuperación. En laboratorio puede primar innovación; en producción crítica, estabilidad y soporte.

14.2. Familia Debian

Debian es un proyecto comunitario que crea un sistema libre y una gran colección de paquetes. Usa el formato .deb, la herramienta de bajo nivel dpkg y APT para resolver dependencias y trabajar con repositorios. Debian distingue ramas stable, testing y unstable. Stable favorece previsibilidad; testing y unstable introducen versiones más nuevas con distinto perfil de riesgo.

Ubuntu deriva de Debian y publica versiones intermedias y LTS. Ubuntu Server se utiliza en nube, virtualización y servicios generales. Las LTS reciben un periodo prolongado de actualizaciones estándar y pueden ampliar mantenimiento mediante servicios de Canonical. A agosto de 2026 existen las LTS 24.04 y 26.04, pero una organización no debe adoptar automáticamente la más reciente: debe comprobar compatibilidad y ventana de estabilización.

apt update
apt list --upgradable
apt install paquete
apt remove paquete
apt-cache policy paquete

apt update actualiza índices, no los paquetes instalados. apt upgrade aplica actualizaciones según sus reglas. En scripts, Debian recomienda normalmente herramientas estables como apt-get en lugar de depender de la interfaz orientada a uso interactivo de apt.

14.3. Familia Red Hat

Red Hat Enterprise Linux ofrece una plataforma empresarial con suscripción, soporte, certificaciones y ciclo prolongado. Fedora actúa como comunidad innovadora donde aparecen tecnologías que pueden llegar a RHEL. CentOS Stream se sitúa en el flujo de desarrollo inmediatamente anterior a versiones menores de RHEL. Rocky Linux y AlmaLinux ofrecen reconstrucciones compatibles en el ecosistema Enterprise Linux, con sus propios modelos de gobernanza y soporte.

La familia utiliza paquetes RPM y gestores DNF. RPM instala y consulta paquetes; DNF resuelve dependencias y repositorios. YUM fue la interfaz histórica y en sistemas actuales puede ser un enlace o compatibilidad sobre DNF.

dnf check-update
dnf install paquete
dnf remove paquete
dnf history
rpm -q paquete
rpm -V paquete

rpm -V verifica atributos frente a metadatos del paquete, pero no sustituye una solución completa de integridad ni determina por sí solo que un cambio sea malicioso. Los archivos de configuración pueden modificarse legítimamente.

14.4. SUSE y otras familias

SUSE Linux Enterprise Server se orienta a empresa, con presencia en entornos SAP y plataformas de misión crítica. Utiliza RPM y zypper, y YaST como marco de administración. openSUSE ofrece variantes comunitarias. Oracle Linux mantiene compatibilidad con el ecosistema RHEL y proporciona opciones de kernel. Arch Linux adopta un modelo rolling release y configuración explícita; Gentoo compila gran parte del software; Alpine usa musl y BusyBox y destaca por imágenes compactas, aunque sus diferencias de biblioteca pueden afectar compatibilidad.

14.5. Repositorios, dependencias y cadena de suministro

El gestor de paquetes aporta inventario, resolución de dependencias, verificación criptográfica y actualización coordinada. Instalar manualmente binarios fuera del gestor puede crear software huérfano sin seguimiento de vulnerabilidades. Los repositorios deben proceder de fuentes autorizadas, usar claves gestionadas y evitar mezclar ramas incompatibles.

La firma de metadatos confirma origen e integridad según la confianza depositada en la clave; no demuestra ausencia de vulnerabilidades. La cadena de suministro exige además revisión del proveedor, SBOM cuando proceda, gestión de secretos, control de construcción y respuesta ante avisos.

14.6. Actualización y cambio de versión mayor

Actualizar paquetes dentro de una versión no equivale a migrar a una versión mayor. Una migración puede cambiar kernel, Python, OpenSSL, bases de datos, módulos, políticas criptográficas o sistema de red. Debe inventariarse software, verificar compatibilidad, probar copia y restauración, ensayar en preproducción, medir rendimiento y planificar reversión.

15. ADMINISTRACIÓN EMPRESARIAL, SEGURIDAD, VIRTUALIZACIÓN Y CONTENEDORES

15.1. Gestión del ciclo de vida

Administrar una plataforma empresarial significa mantener un estado conocido a lo largo del tiempo. El proceso comienza con inventario de hardware, sistema, paquetes, aplicaciones, propietarios, criticidad y dependencias. Continúa con configuración estandarizada, parches, monitorización, copia, pruebas de restauración, capacidad, auditoría y retirada. Un servidor que “funciona” pero carece de propietario, parcheado o copia verificable es un riesgo operativo.

Las imágenes base deben ser mínimas, endurecidas y reproducibles. La instalación manual divergente genera deriva de configuración. Herramientas como Ansible, Puppet, Salt o productos corporativos permiten describir estados e introducir control de versiones. La automatización no elimina la revisión: un error automatizado se propaga con mayor velocidad.

15.2. Parches y vulnerabilidades

La gestión de vulnerabilidades relaciona inventario, avisos del proveedor, exposición y criticidad. Un CVE no implica el mismo riesgo en todos los sistemas; puede estar mitigado, no ser alcanzable o afectar a una función deshabilitada. A la inversa, un servicio expuesto con credenciales débiles puede ser crítico aunque no exista un CVE reciente.

Las distribuciones empresariales realizan backports de correcciones sin adoptar toda la versión upstream. Los escáneres que comparan solo cadenas de versión pueden producir falsos positivos. Se debe consultar el aviso de seguridad del distribuidor y la versión de paquete con su revisión.

15.3. Endurecimiento

• Instalar únicamente paquetes y servicios necesarios.
• Aplicar mínimo privilegio a cuentas, sudo, archivos y servicios.
• Deshabilitar autenticación y algoritmos obsoletos.
• Separar redes de gestión, aplicación, almacenamiento y copia.
• Centralizar logs y sincronizar tiempo.
• Proteger claves, certificados y secretos fuera de scripts.
• Aplicar SELinux, AppArmor u otro MAC cuando la plataforma lo soporte.
• Definir límites de recursos y protección frente a agotamiento.
• Auditar cambios y probar recuperación.

El endurecimiento debe basarse en una guía aplicable y en la función del servidor. Una recomendación genérica puede romper una aplicación. El control se prueba en preproducción, se documentan excepciones y se revisa tras actualizaciones.

15.4. Alta disponibilidad y clúster

La disponibilidad no se obtiene instalando “Linux” ni añadiendo dos nodos. Requiere eliminar puntos únicos de fallo, replicar o compartir estado de forma coherente, detectar fallos, decidir quórum, evitar split-brain, automatizar conmutación y probarla. Aplicación, base de datos, almacenamiento, red, DNS, identidad y observabilidad forman parte del servicio.

Un clúster de alta disponibilidad puede usar gestores de recursos como Pacemaker/Corosync, soluciones del proveedor o funciones de la aplicación. Los balanceadores distribuyen peticiones, pero no resuelven por sí solos consistencia de sesión o datos. La recuperación ante desastre aborda pérdida de sitio y suele tener RPO/RTO distintos.

15.5. Virtualización

KVM convierte el kernel Linux en hipervisor y se combina con QEMU y herramientas de gestión. Xen y plataformas comerciales también ejecutan Linux. La virtualización abstrae hardware y facilita consolidación, aprovisionamiento y movilidad, pero añade capas que deben monitorizarse. La sobreasignación de CPU o memoria puede ser eficiente si se controla; sin capacidad, genera contención difícil de diagnosticar.

Las máquinas virtuales poseen su propio kernel y pueden ejecutar sistemas distintos al host. Las instantáneas de VM son útiles para operaciones puntuales, pero mantenerlas durante largos periodos puede degradar rendimiento y complicar consistencia. Para bases de datos se coordinan con mecanismos de aplicación.

15.6. Contenedores

Una imagen de contenedor empaqueta espacio de usuario y aplicación; el runtime crea procesos aislados mediante namespaces y cgroups. La imagen debe ser inmutable, mínima y trazable. Los datos persistentes se sitúan fuera de la capa efímera. Ejecutar como no root, usar sistemas de archivos de solo lectura cuando sea posible, eliminar capacidades y firmar imágenes reduce riesgo.

El usuario root dentro de un contenedor no es automáticamente equivalente a root en el host, pero una vulnerabilidad del kernel, configuración privilegiada, montaje sensible o socket del runtime puede romper el aislamiento. “Está en un contenedor” no es un control suficiente.

15.7. Kubernetes

Kubernetes orquesta contenedores mediante un estado deseado. Los pods agrupan contenedores; deployments gestionan réplicas; services proporcionan acceso estable; configmaps y secrets inyectan configuración; volúmenes aportan persistencia. La plataforma añade complejidad: control plane, red, almacenamiento, políticas, certificados, upgrades y observabilidad.

Su adopción se justifica por necesidades de despliegue, escalado y resiliencia, no por moda. Una aplicación monolítica estable puede gestionarse mejor con máquinas virtuales y automatización convencional. La arquitectura debe responder a requisitos y madurez operativa.

15.8. Copia y recuperación

La regla esencial es que una copia no existe hasta que se ha restaurado con éxito. Se definen fuentes, frecuencia, retención, cifrado, inmutabilidad, ubicación separada, pruebas y responsables. El RPO expresa pérdida de datos tolerable; el RTO, tiempo objetivo de recuperación. Los dos influyen en tecnología y coste.

16. OTROS SISTEMAS OPERATIVOS PARA UNIDADES CENTRALES MULTIUSUARIO

16.1. Concepto de unidad central multiusuario

Las unidades centrales multiusuario incluyen servidores de gran capacidad y mainframes diseñados para consolidar múltiples cargas, usuarios y transacciones. Se caracterizan por virtualización madura, E/S de alto rendimiento, aislamiento, gestión de cargas, disponibilidad, mantenimiento y compatibilidad de largo plazo. El concepto no se limita a “un ordenador muy potente”: incluye arquitectura de servicio y operación.

Además de Linux y Unix comerciales, existen sistemas con tradiciones distintas que siguen siendo relevantes en banca, seguros, industria, telecomunicaciones y Administración. Su continuidad responde a estabilidad, inversión acumulada, aplicaciones críticas y costes de migración.

16.2. IBM AIX

AIX es el Unix de IBM para servidores Power. Ofrece soporte de la Single UNIX Specification en versiones certificadas, administración adaptada a Power, LVM, JFS2, herramientas SMIT y tecnologías de virtualización. Las LPAR dividen recursos de un servidor en particiones lógicas; PowerVM permite movilidad y gestión avanzada. AIX se utiliza en cargas empresariales que requieren integración con hardware y software IBM.

La fortaleza de AIX es la plataforma integrada y el soporte de aplicaciones certificadas. Sus límites incluyen coste, disponibilidad de perfiles especializados y dependencia de hardware Power. Una migración a Linux no consiste en copiar ejecutables: exige recompilar o sustituir aplicaciones, revisar endianess, bibliotecas, scripts, dispositivos y operación.

16.3. Oracle Solaris

Oracle Solaris procede de SunOS y la tradición System V. Solaris 11.4 mantiene documentación y soporte como plataforma empresarial. Sus tecnologías emblemáticas incluyen ZFS, DTrace, Zones, SMF, gestión de recursos y funciones de seguridad. ZFS combina sistema de archivos y gestión de volúmenes, usa checksums, copia en escritura, snapshots y replicación mediante send/receive.

Las Zones aíslan entornos dentro de un sistema. Las zonas no globales comparten kernel; las kernel zones ofrecen un grado mayor de independencia dentro de la arquitectura Solaris. DTrace permite instrumentación dinámica del sistema y aplicaciones. SMF modela servicios y dependencias y reemplaza gran parte del arranque basado en scripts.

16.4. HP-UX

HP-UX es el Unix de HPE asociado históricamente a PA-RISC e Itanium. Permanece en instalaciones legadas y aplicaciones certificadas, aunque su ecosistema tiene menor crecimiento. En examen interesa reconocerlo como Unix comercial para servidores empresariales, no confundirlo con Linux ni con un sistema de mainframe IBM.

16.5. IBM z/OS

z/OS es el sistema principal de los mainframes IBM Z. Está diseñado para entornos estables, seguros y de disponibilidad continua, y puede manejar miles de programas y usuarios concurrentes. Evoluciona desde la familia OS/360, MVS y OS/390. Su modelo operativo utiliza conceptos como address spaces, jobs, subsistemas y datasets.

El Workload Manager asigna recursos conforme a clases de servicio y objetivos. Parallel Sysplex permite coordinar múltiples sistemas con compartición de datos y alta disponibilidad. RACF es un gestor de seguridad habitual. CICS procesa transacciones; IMS y Db2 son plataformas de datos; JES gestiona trabajo por lotes. z/OS UNIX System Services proporciona un entorno POSIX integrado, de modo que aplicaciones Unix pueden coexistir con cargas mainframe.

La fortaleza del mainframe reside en volumen transaccional, E/S, seguridad, consolidación y compatibilidad. Su coste y especialización son elevados, pero la sustitución debe valorarse por coste total y riesgo, no por edad tecnológica.

16.6. z/VM y Linux on IBM Z

z/VM es un hipervisor y sistema de virtualización de mainframe capaz de alojar muchas máquinas virtuales. Puede ejecutar Linux on IBM Z y otros sistemas invitados. La virtualización en mainframe tiene décadas de madurez. Linux on Z permite combinar ecosistema Linux con hardware, E/S y consolidación de IBM Z.

16.7. OpenVMS

OpenVMS nació como VAX/VMS y destacó por clustering, disponibilidad y gestión de recursos. Evolucionó por VAX, Alpha e Itanium y actualmente dispone de versiones para x86-64 desarrolladas por VMS Software Inc. Esto demuestra que un sistema legado puede renovarse arquitectónicamente para proteger aplicaciones existentes.

OpenVMS usa conceptos y administración diferentes a Unix, aunque ofrece interoperabilidad y herramientas de red. Su presencia se concentra en sistemas donde continuidad y certificación pesan más que la adopción de un ecosistema masivo.

16.8. Windows Server como plataforma multiusuario

Windows Server también es un sistema operativo multiusuario para servidores, con Active Directory, PowerShell, Hyper-V, clúster y servicios de archivos, aplicaciones y escritorio remoto. No es tipo Unix, aunque ofrece interoperabilidad y subsistemas compatibles. Debe incluirse en una comparación de alternativas, pero el epígrafe se centra en Unix, Linux y sistemas de unidad central.

17. SELECCIÓN, INTEROPERABILIDAD Y MIGRACIÓN

17.1. Criterios de selección

La plataforma se selecciona a partir de requisitos funcionales y no funcionales. Deben evaluarse compatibilidad de aplicación, base de datos, middleware y drivers; disponibilidad; rendimiento; escalabilidad; seguridad; cumplimiento; operación; habilidades; soporte; coste; licencias; portabilidad; arquitectura y hoja de ruta. Un benchmark aislado no determina el resultado real.

Para una carga crítica se comprueba la matriz de soporte completa. “Funciona en Linux” es insuficiente: puede requerir una distribución, versión, kernel, hipervisor, arquitectura o biblioteca concreta. El soporte del fabricante puede rechazarse si el entorno queda fuera de certificación.

17.2. Inventario de dependencias

Una migración comienza con inventario de ejecutables, código fuente, compiladores, bibliotecas, scripts, tareas, cuentas, certificados, interfaces, datos, formatos, volúmenes, ventanas, rendimiento y procedimientos. Se clasifican dependencias en portables, sustituibles, adaptables o bloqueantes. El inventario técnico debe enlazarse con propietario y proceso de negocio.

17.3. Portabilidad de aplicaciones

El código POSIX reduce esfuerzo, pero no resuelve todos los problemas. Las diferencias incluyen tamaño de tipos, endianess, alineación, hilos, locales, shell, rutas, utilidades, opciones, formato de fecha, semántica de sistemas de archivos y bibliotecas de terceros. Los scripts que analizan la salida humana de comandos son especialmente frágiles.

La estrategia preferida es usar estándares, pruebas automatizadas y abstracciones. Antes de portar se ejecutan analizadores, se compila con advertencias, se eliminan supuestos y se define una matriz de pruebas. En aplicaciones sin código fuente puede ser necesaria emulación, virtualización o sustitución.

17.4. Datos y almacenamiento

La migración de datos aborda formato, codificación, permisos, metadatos, consistencia y volumen. Copiar archivos mientras cambian puede producir una imagen incoherente. Se utilizan snapshots, quiesce de aplicaciones, replicación y una ventana final de corte. Las bases de datos disponen de mecanismos lógicos o físicos, cada uno con restricciones de versión y arquitectura.

17.5. Identidades y seguridad

Los UID/GID deben mapearse para conservar propiedad. Las ACL, atributos extendidos, capacidades y etiquetas MAC pueden no trasladarse directamente. Las cuentas de servicio y secretos se recrean con mínimo privilegio. Los certificados se validan, no se copian sin control. Los logs y evidencias se conservan conforme a política.

17.6. Estrategias de transición

• Rehost: mover con cambios mínimos, por ejemplo a una VM compatible.
• Replatform: adaptar a otra versión o distribución sin rediseño completo.
• Refactor: modificar arquitectura para aprovechar la plataforma objetivo.
• Repurchase: sustituir por un producto soportado.
• Retire: eliminar la función que ya no aporta valor.
• Retain: conservar temporalmente por riesgo, coste o dependencia.

La coexistencia es habitual. Se introducen proxies, colas, sincronización o APIs entre plataforma antigua y nueva. La doble operación tiene coste y riesgo de divergencia, por lo que necesita fecha de salida y criterios de cierre.

17.7. Plan de pruebas y reversión

Las pruebas abarcan funcionalidad, rendimiento, carga, seguridad, copia, restauración, monitorización, tareas y operación. Se define criterio de aceptación y quién autoriza. La reversión debe ser ejecutable dentro de la ventana y considerar datos generados tras el corte. No basta con conservar la máquina antigua si los datos ya cambiaron en la nueva.

17.8. Coste total y bloqueo tecnológico

El software libre puede reducir licencias, pero requiere soporte, personal, integración y responsabilidad operativa. El software propietario puede aportar certificación y un único interlocutor, pero aumentar dependencia. El coste total incluye hardware, energía, formación, migración, soporte, indisponibilidad y riesgo.

POSIX, formatos abiertos, automatización portable y separación de capas reducen bloqueo. No lo eliminan: una aplicación puede depender de una base de datos, nube, sistema de archivos o herramienta específica. La gobernanza debe registrar estas dependencias y su plan de salida.

18. MAPA CONCEPTUAL Y SÍNTESIS DE EXAMEN

18.1. Perlas de examen oficiales

• Filosofía UNIX: programas especializados, composición y capacidad de mantener el sistema desde el propio entorno; no prioridad de lotes sobre interacción. Examen 2019, libre, pregunta 76.
• Planificación: en tiempo compartido, la prioridad es un criterio central; el quantum limita tiempo pero no es la única regla de selección. Examen 2021, libre, pregunta 57.
• cron: demonio clásico para tareas programadas. Examen 2021, libre, pregunta 120.
• Tamaño de archivos: ext4, exFAT y NTFS superan el límite de 4 GiB; la trampa es FAT32. Examen 2021, libre, pregunta 135.
• UID: identificador numérico interno para propiedad de objetos y procesos. Examen 2025, libre, pregunta 91.
• sudo: delega ejecución sin compartir la contraseña de root; la autenticación depende de sudoers. Examen 2025, libre, pregunta 93.

18.2. Errores frecuentes

• Confundir shell y kernel.
• Decir que Linux es un Unix certificado por definición.
• Identificar distribución con kernel.
• Interpretar “todo es un archivo” de forma literal.
• Creer que sudo siempre exige una contraseña concreta.
• Confundir borrar un nombre con liberar inmediatamente los bloques.
• Suponer que contenedor equivale a máquina virtual.
• Tratar instantánea, réplica y backup como equivalentes.
• Considerar z/OS un Unix por incluir UNIX System Services.
• Elegir distribución solo por novedad o popularidad.

18.3. Síntesis final

Unix estableció un modelo de sistema operativo portable, multiusuario y componible. POSIX convirtió gran parte de ese modelo en interfaces normalizadas. BSD desarrolló tecnologías de red y originó sistemas actuales. Linux reimplementó el núcleo y, combinado con espacios de usuario y distribuciones, se convirtió en plataforma general para servidores, nube y contenedores. Los Unix comerciales y sistemas mainframe continúan donde su integración, compatibilidad y operación justifican su coste.

Para la oposición debes razonar desde la arquitectura. El UID explica la propiedad; el VFS explica la uniformidad de rutas; los descriptores explican pipes y redirecciones; la planificación explica tiempo compartido; la separación kernel-usuario explica protección; POSIX explica portabilidad; y las distribuciones explican por qué el mismo kernel se administra de formas diferentes.