Tema: debian
-
Actualizar Debian y Ubuntu a la siguiente versión mayor sin perder una vía de retorno
Tanto do-release-upgrade de Ubuntu como el procedimiento manual de Debian (editar sources.list y luego actualizar) suponen una copia de seguridad completa y una consola de respaldo por si la sesión SSH se corta a mitad de la actualización; las propias notas de publicación de Debian recomiendan una pasada de actualización mínima antes de la completa.
-
Comprobar si un host Linux necesita reiniciarse o reiniciar servicios tras las actualizaciones
Debian y Ubuntu marcan un reinicio pendiente con el simple archivo /var/run/reboot-required, mientras que los sistemas de la familia RHEL exigen comparar el kernel en ejecución con el más reciente instalado o ejecutar una comprobación al estilo needs-restarting; ninguna de las dos familias lo indica automáticamente en el indicador de comandos.
-
Configurar interfaces de red con netplan en Ubuntu, y probar cambios sin perder la conexión
Netplan convierte el YAML de /etc/netplan en configuración de networkd o NetworkManager; `netplan try` aplica un cambio y lo revierte automáticamente si nadie lo confirma dentro de un tiempo límite, lo que lo convierte en la forma segura de cambiar la configuración de red en un host remoto. El /etc/network/interfaces de ifupdown en Debian es el contraste más antiguo, aún compatible.
-
Establecer la configuración regional, la zona horaria y reconfigurar paquetes sin interacción en Debian y Ubuntu
localectl, timedatectl y update-locale cambian la configuración regional y la zona horaria sin un cuadro de diálogo en modo texto, y dpkg-reconfigure -f noninteractive vuelve a ejecutar el paso de configuración de un paquete basado en debconf de la misma forma en que lo haría un script durante la instalación original, ambos utilizables en scripts de aprovisionamiento sin ninguna terminal conectada.
-
Añadir un repositorio APT de terceros de la forma actual: archivos .sources deb822 y llaveros con Signed-By
apt-key está obsoleto; la forma admitida de añadir un repositorio de terceros firmado es un archivo de llavero bajo /etc/apt/keyrings referenciado con una opción Signed-By, escrito bien en el formato clásico de una línea o en el nuevo formato deb822 .sources que analizan tanto Debian 12/13 como las versiones actuales de Ubuntu.
-
Comprobar la integridad de los paquetes instalados en Debian y Ubuntu con debsums y dpkg --verify
debsums compara los archivos instalados con las sumas MD5 registradas en el momento de compilar el paquete, dpkg --verify (desde dpkg 1.17.2) compara los metadatos registrados en la propia base de datos de dpkg, y dpkg -S/-L responden a «qué paquete es dueño de este archivo» y «qué archivos instaló este paquete» antes de decidir si reinstalarlo.
-
Añadir una CA privada al almacén de confianza del sistema en la familia RHEL y en Debian/Ubuntu
Las distribuciones Linux de la familia RHEL y de la familia Debian usan mecanismos distintos para añadir un certificado de CA de confianza local: update-ca-trust con anchors en /etc/pki/ca-trust, y update-ca-certificates con archivos .crt en /usr/local/share/ca-certificates. Usar un directorio o una extensión incorrectos deja la CA sin confianza, sin mostrar ningún error.
-
APT pinning: mantener un paquete en una versión u origen concreto con archivos de preferencias
El pinning de APT permite retener un único paquete, obtenerlo de una suite que no es la predeterminada o evitar que un futuro apt upgrade lo modifique. Se configura con un archivo por propósito en /etc/apt/preferences.d, en lugar de editar un único archivo compartido, y se comprueba con apt-cache policy.
-
Debian preseed y Ubuntu autoinstall: dos formatos de instalación automatizada que no son intercambiables
El instalador de Debian se automatiza con un archivo preseed que responde las preguntas de debconf, mientras que Ubuntu Server (20.04+) y Desktop (23.04+) usan el formato YAML autoinstall de Subiquity, entregado como user-data de cloud-init o como autoinstall.yaml en el medio de instalación. Los dos formatos no son portables entre distribuciones y conviene validar ambos antes de usarlos en una instalación desatendida.
-
Gestión de los kernels instalados en Debian y Ubuntu: limpieza, espacio en /boot, HWE y Livepatch
Los paquetes de kernel antiguos se acumulan en /boot hasta que apt autoremove los elimina; además, Ubuntu ofrece en sus versiones LTS un kernel HWE (Hardware Enablement) continuo y el servicio Livepatch de Canonical para aplicar correcciones de seguridad del kernel sin reiniciar de inmediato; ambos son exclusivos de Ubuntu y no tienen equivalente en Debian.
-
Ejecutar apt y dpkg de forma no interactiva en Debian y Ubuntu sin que se bloqueen en las preguntas
Una ejecución de apt-get o dpkg desde un script puede quedarse detenida por una pregunta de debconf, una consulta sobre un archivo de configuración modificado o un bloqueo de dpkg retenido. Si se define DEBIAN_FRONTEND, se usan las opciones confold/confdef adecuadas y se preconfiguran antes las respuestas de debconf, la instalación termina correctamente o falla con un error claro.
-
Cómo manejar cloud-init en una instancia nueva de Debian o Ubuntu: user-data, status --wait y reejecuciones seguras
cloud-init aplica el user-data una sola vez en el primer arranque; `cloud-init status --wait` bloquea hasta que esa ejecución termina para que un script de aprovisionamiento no compita con ella, `cloud-init schema --system` detecta un archivo user-data incorrecto antes del siguiente arranque y `cloud-init clean` es la forma documentada de forzar una reejecución completa para pruebas.
-
Configurar unattended-upgrades para aplicar parches de seguridad automáticos en Debian y Ubuntu
unattended-upgrades instala actualizaciones de paquetes de forma periódica mediante dos archivos: 20auto-upgrades (si se ejecuta y con qué frecuencia) y 50unattended-upgrades (qué orígenes se usan y si se reinicia). Probarlo con --dry-run --debug antes de activarlo en producción evita reinicios inesperados o actualizaciones a medio aplicar.
-
Trabajar con perfiles de AppArmor en Debian y Ubuntu: estado, modo complain y overrides locales
AppArmor confina cada programa mediante un perfil, no por usuario. aa-status muestra qué está cargado y aplicado, aa-complain y aa-enforce alternan un perfil entre solo registro y bloqueo, y /etc/apparmor.d/local contiene adiciones propias del sitio que se conservan al actualizar el paquete del perfil.
Legible por máquina: JSON