Llevas cuatro módulos escribiendo sudo apt install sin preguntarte de dónde sale ese software, quién garantiza que no lo ha manipulado nadie por el camino, ni qué ocurre si una madrugada el motor de base de datos de Tramontana salta de la versión 15 a la 16 y la aplicación deja de arrancar. Ahora que sabes exactamente qué te permite hacer sudo, toca entender qué haces con él la mayoría de las veces: instalar, actualizar y fijar software. Esta lección cubre las dos capas de Debian y Ubuntu, la firma criptográfica de los repositorios, el pinning de versiones y el debate incómodo de si un servidor debe reiniciarse solo tras una actualización de seguridad.

1. Qué resuelve un gestor de paquetes
2. Anatomía de un .deb y comparación con .rpm
3. Las dos capas: dpkg frente a apt
4. apt en el día a día
5. dpkg y la arqueología de ficheros
6. Repositorios: deb822, componentes, pockets y claves
7. Fijar versiones: hold y pinning
8. Actualizaciones desatendidas, el reinicio y la limpieza de la caché
9. Snap, Flatpak y AppImage frente a .deb
10. Compilar desde fuentes cuando no queda otra
11. Equivalencias con dnf en RHEL
12. Caso Tramontana: dependencias, versión fijada y auditoría

Instalar software «a mano» —descargar un .tar.gz, compilarlo y copiarlo a /usr/local— parece inofensivo hasta que llega la primera actualización de seguridad. Un gestor de paquetes resuelve cuatro problemas que a mano no tienen solución razonable:

• Dependencias: sabe que tu aplicación necesita libssl3t64 y que esa librería la usan otros veinte programas, así que la instala una vez y la comparte.
• Actualizaciones de seguridad: un comando actualiza todo lo instalado. Con software compilado a mano, el día que salga un CVE crítico tendrás que acordarte tú.
• Integridad y procedencia: cada paquete viene firmado y su suma comprobada. Sabes que lo que se instala es lo que publicó el mantenedor.
• Desinstalación limpia: el gestor sabe exactamente qué ficheros trajo cada paquete. Un make install no deja ni la lista.

Regla operativa: compilar es la última opción, y cuando toque, en /usr/local para no pisar lo que administra el gestor.

Un .deb es un archivo ar con tres piezas: debian-binary (versión del formato), control.tar.zst (metadatos y scripts) y data.tar.zst (los ficheros que se instalan).

Los campos de relación entre paquetes son los que hacen todo el trabajo:

Dentro de control hay además scripts de mantenedor —preinst, postinst, prerm, postrm— que se ejecutan como root en cada fase. Es la razón exacta por la que añadir un repositorio de terceros es una decisión de seguridad y no una comodidad: instalar un paquete es ejecutar código ajeno como root.

dpkg sabe instalar un fichero .deb y llevar la contabilidad de lo instalado; no sabe nada de repositorios ni descarga dependencias. apt sabe hablar con los repositorios, resolver el grafo de dependencias, verificar firmas y decidir el orden, y luego delega en dpkg.

Nota: apt es la interfaz para humanos y apt-get/apt-cache las estables para scripts. En un script usa apt-get: apt avisa de que su interfaz puede cambiar entre versiones.

La confusión clásica: update solo descarga los índices. Sin él, apt trabaja con una foto vieja del repositorio y no verá la actualización de seguridad publicada esta mañana. La diferencia entre upgrade y full-upgrade importa en un servidor: upgrade es conservador y prefiere no tocar nada antes que borrar algo; full-upgrade acepta eliminaciones y es lo que hace falta en un cambio de versión de distribución.

remove frente a purge es una decisión real: remove te permite reinstalar y recuperar tu configuración; purge deja el sistema limpio. En un servidor que se documenta, purge evita que dentro de un año aparezca un /etc/loquesea fantasma que nadie sabe de dónde viene.

Consulta:

Y la opción que más disco ahorra en un servidor es sudo apt install --no-install-recommends nginx. Los Recommends arrastran extras pensados para escritorio (documentación, clientes gráficos, servidores de correo completos). En un servidor, cada paquete de más es superficie de ataque y disco ocupado. Puedes hacerlo permanente:

Los estados de dpkg -l se leen en dos letras: la primera es el estado deseado y la segunda el real. ii es «instalado e instalado»; rc es «eliminado pero quedan ficheros de configuración» (candidatos a purge); iU o iF indican una instalación a medias, que se arregla con sudo dpkg --configure -a (termina configuraciones interrumpidas) y sudo apt -f install (repara dependencias rotas).

Para buscar un fichero en paquetes que no tienes instalados:

Ubuntu 24.04 abandonó el formato de una línea de /etc/apt/sources.list y usa deb822, mucho más legible, en /etc/apt/sources.list.d/*.sources:

El fichero lleva un segundo bloque idéntico con URIs: http://security.ubuntu.com/ubuntu/ y Suites: noble-security, que es el que trae los parches.

Cada repositorio firma su índice Release con una clave GPG. Antiguamente todas las claves iban a un llavero global (apt-key add), lo que significaba que cualquier repositorio de terceros podía firmar cualquier paquete, incluido un openssh-server falso que sustituyera al oficial. Por eso apt-key está obsoleto y eliminado en 24.04. Hoy la clave se guarda en un fichero y se ata a ese repositorio con Signed-By:.

Añadir un repositorio de terceros es una decisión de seguridad. Estás autorizando a un tercero a ejecutar código como root en tu servidor cada vez que actualices, y a sustituir paquetes si no acotas su alcance. Antes de añadirlo: comprueba quién lo publica, usa HTTPS, ata la clave con Signed-By, limita Components a lo necesario y, si te importa de verdad, aplica pinning para que solo pueda suministrar los paquetes previstos. En un entorno corporativo esta decisión debe validarla el responsable de seguridad.

Los PPA de Ubuntu son repositorios de Launchpad que sudo add-apt-repository ppa:usuario/proyecto añade con su clave. Cómodos en escritorio; en producción, cada PPA es un mantenedor individual del que pasas a depender.

Hay software que no puede actualizarse solo. El motor de base de datos de Tramontana es el caso de manual: un salto de versión mayor implica migración del formato de datos, y hacerlo a las 6:00 sin supervisión significa una aplicación caída y un rollback complicado.

La forma sencilla, con dpkg:

Un paquete en hold no lo toca ni upgrade, ni full-upgrade, ni unattended-upgrades.

La forma con más control, el pinning de APT, permite decidir de qué origen viene cada cosa:

apt-cache policy es la herramienta que confirma que tu pinning hace lo que crees. Compruébalo siempre: un pinning mal escrito no da error, simplemente no se aplica.

Un servidor sin parches de seguridad es cuestión de tiempo. Ubuntu incluye unattended-upgrades, que por defecto instala solo lo del pocket -security:

El debate del reinicio automático no tiene respuesta universal. Una actualización del kernel o de glibc no surte efecto hasta reiniciar los procesos afectados o la máquina:

Para Tramontana, con un solo servidor y sin alta disponibilidad (que es materia de 07-07), la decisión razonable es false más una alerta que Marta reciba, más un compromiso escrito de ventana semanal. Y la costumbre imprescindible: snapshot de la VM antes de una actualización grande, que en un servidor real es un snapshot LVM o del hipervisor (05-04).

Y la limpieza, que en un servidor con /var en su propia partición —como el que particionaste en 01-04— evita un disco lleno: du -sh /var/cache/apt/archives suele dar cientos de megas, que sudo apt clean borra por completo y apt autoclean solo en lo ya retirado del repositorio; los kernels antiguos los limpia apt autoremove --purge.

Ubuntu trae snapd de serie, y algunas piezas (como lxd o certbot) se distribuyen así. Lo que hay que saber en un servidor: los snaps se actualizan solos y su ritmo se puede posponer pero no cancelar, lo que choca de frente con una política de cambios controlados.

--prefix=/usr/local no es un detalle: el FHS de 01-06 reserva ese árbol para lo instalado por el administrador, precisamente para que nunca colisione con lo que gestiona dpkg en /usr. Y como make install no deja registro, existe checkinstall, que envuelve la instalación en un .deb real:

Ahora se desinstala limpiamente con apt purge herramienta. Aun así, sigue sin haber nadie que te avise de sus fallos de seguridad: esa vigilancia pasa a ser tuya.

Retomando las familias de 01-03, esta tabla te permite trabajar en Rocky, Alma o RHEL sin volver a aprender nada:

La diferencia práctica más llamativa: dnf history undo deshace una transacción entera, algo que APT no ofrece. En Debian/Ubuntu la vuelta atrás se hace reinstalando versiones concretas a partir de history.log.

Primero, las dependencias del servidor, sin recomendados y con verificación:

Segundo, fijamos la base de datos para que ninguna actualización desatendida la suba de versión mayor:

Y añadimos el pinning explícito de /etc/apt/preferences.d/99-tramontana-bd que viste en el apartado 7, más la lista negra en 50unattended-upgrades. Verificación obligatoria:

Tercero, la pregunta de Marta esta mañana: «¿qué se actualizó anoche y por qué?».

Respuesta para Marta, con la estructura de siempre —qué protege y qué no protege—: «Anoche se actualizó OpenSSL por un fallo de seguridad que permitía tumbar el servicio TLS. Protege el cifrado de las conexiones entrantes. No protege nada más, y no surtirá efecto completo hasta reiniciar los servicios que ya tenían la librería cargada; needrestart indica que tramontana.service es uno de ellos. Propongo reiniciarlo en la ventana del jueves. La base de datos sigue fijada en la serie 16 y no se ha tocado.» Y al HISTORIAL:

• Creer que apt update actualiza algo. Solo refresca la lista; el par correcto es apt update && apt upgrade, y el && no es decorativo: si el update falla, actualizar con índices viejos es peor que no actualizar.
• Usar apt en scripts en vez de apt-get con DEBIAN_FRONTEND=noninteractive, o dpkg -i sin más, que instala sin dependencias y deja el sistema en estado iF (usa apt install ./fichero.deb).
• Añadir un repositorio con apt-key. Eliminado en 24.04 e inseguro por diseño: clave en /etc/apt/keyrings/ y Signed-By: en el .sources.
• Olvidar el pocket -security. Sin él el servidor se queda sin parches, y no da ningún error. Y no actualices sin snapshot ni ventana: el día que algo se rompa, la diferencia entre 5 minutos y 5 horas es haber hecho el snapshot.
• Dejar hold puesto y olvidarlo. Un paquete retenido tampoco recibe parches de seguridad: revisa apt-mark showhold cada mes y anota quién decidió cada retención y hasta cuándo.
• Consejo: guarda apt-mark showmanual > paquetes.txt junto a tus copias. Reconstruir un servidor con esa lista es cuestión de minutos.

1. Simulación antes de actuar. Averigua qué paquetes se actualizarían ahora mismo y cuánto disco ocuparían, sin instalar nada. Después, comprueba si alguno de ellos exige reiniciar el sistema.
2. Repositorio de terceros bien montado. Describe los pasos completos y seguros para añadir un repositorio ficticio https://apt.tramontana.example/ (suite noble, componente main) que solo deba suministrar el paquete tramontana-agent, e indica cómo verificarías que no puede sustituir paquetes del sistema.
3. Forense de una actualización. Un compañero dice que «alguien instaló nginx a mano el martes». Demuestra con comandos cuándo se instaló, si vino de un repositorio o de un .deb suelto, y qué ficheros de configuración aporta.

1.

--simulate (o -s) es el --dry-run de APT, y encaja con la convención del curso de simular antes de actuar. Para el reinicio: [ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs || echo "No requiere reinicio".

2. Los pasos, en orden:

Verificación: sudo apt update no debe dar avisos de firma, y apt-cache policy openssl debe seguir mostrando noble-security como origen del candidato. Ese pinning de prioridad 1 es la red de seguridad que impide que un repositorio de terceros secuestre un paquete del sistema.

3.

Vino del repositorio oficial (noble-updates), lo pidió luis el 13 de agosto con apt install, y aporta conffiles que apt protegerá en futuras actualizaciones. Nótese el campo Requested-By: history.log guarda el UID real detrás del sudo, lo que enlaza directamente con la trazabilidad de la lección anterior.

El software de srv-tramontana ya no aparece por arte de magia. Sabes que un gestor de paquetes resuelve dependencias, actualizaciones, integridad y desinstalación limpia, y que compilar es la última opción; conoces la anatomía de un .deb —incluidos los scripts de mantenedor que corren como root, que es la razón de fondo de toda la cautela con los repositorios— y su equivalencia con .rpm; distingues la capa dpkg de la capa apt y sabes cuándo toca cada una; manejas update/upgrade/full-upgrade, remove frente a purge, --no-install-recommends, depends/rdepends y la arqueología de dpkg -L, dpkg -S y apt-file.

Entiendes los repositorios de Ubuntu 24.04 en formato deb822, sus componentes y sus pockets, y por qué la clave va en /etc/apt/keyrings/ con Signed-By: en lugar del difunto apt-key. Sabes fijar versiones con apt-mark hold y con pinning, verificarlo con apt-cache policy, y que un hold olvidado deja un paquete sin parches. Has configurado unattended-upgrades para que instale solo seguridad, avise a Marta y no reinicie solo, sabiendo leer /var/run/reboot-required y needrestart. Y sabes situar snap, Flatpak y AppImage, compilar en /usr/local con checkinstall cuando toca, y traducir todo a dnf.

Queda el recurso del que depende todo lo demás y que nadie mira hasta que se acaba: el disco. /srv/tramontana/backups lleva semanas creciendo, la copia de las 4:20 escribe cada noche sin que nadie haya calculado cuánto cabe, y la caché de apt que acabas de limpiar era un síntoma, no la causa. En Gestión de Discos verás la pila completa desde el dispositivo físico hasta el punto de montaje, particiones MBR y GPT, sistemas de ficheros comparados, /etc/fstab campo a campo —y por qué una línea mal escrita ahí impide arrancar el servidor—, el caso del fichero borrado que no libera espacio, y LVM, con el que añadirás un disco nuevo a la VM y moverás /srv/tramontana/backups a su propio volumen sin perder un solo byte.