Sujet : debian
-
Upgrading Debian and Ubuntu to the next major release without losing a rollback path
Ubuntu's do-release-upgrade and Debian's manual sources-list-then-upgrade procedure both assume a full backup and a console fallback in case the SSH session drops mid-upgrade; Debian's own release notes recommend a minimal upgrade pass before the full one.
-
Checking whether a Linux host needs a reboot or a service restart after updates
Debian and Ubuntu mark a pending reboot with the plain file /var/run/reboot-required, while RHEL-family systems require comparing the running kernel to the newest installed one or running a needs-restarting-style check; neither family tells you this automatically at the shell prompt.
-
Configuring network interfaces with netplan on Ubuntu, and testing changes without losing the connection
Netplan renders YAML under /etc/netplan into networkd or NetworkManager configuration; `netplan try` applies a change and automatically reverts it if nobody confirms within a timeout, which is the safe way to change network settings on a remote host. Debian's ifupdown /etc/network/interfaces is the older, still-supported contrast.
-
Setting locale, timezone and reconfiguring packages non-interactively on Debian and Ubuntu
localectl, timedatectl and update-locale change locale and timezone without a text-mode dialog, and dpkg-reconfigure -f noninteractive re-runs a package's debconf-driven setup the same way a script would run the original install, both usable in provisioning scripts with no terminal attached.
-
Adding a third-party APT repository the current way: deb822 .sources files and Signed-By keyrings
apt-key is deprecated; the supported way to add a signed third-party repository is a keyring file under /etc/apt/keyrings referenced by a Signed-By option, written either in classic one-line form or the newer deb822 .sources format that both Debian 12/13 and current Ubuntu releases parse.
-
Checking installed package integrity on Debian and Ubuntu with debsums and dpkg --verify
debsums compares installed files against the MD5 sums recorded at package build time, dpkg --verify (since dpkg 1.17.2) compares metadata recorded in the dpkg database itself, and dpkg -S/-L answer "which package owns this file" and "what files did this package install" before deciding whether to reinstall it.
-
APT pinning: keeping one package on a chosen version or source with preferences files
APT pinning lets an operator hold a single package back, pull it from a non-default suite, or prevent a future apt upgrade from touching it — configured per file under /etc/apt/preferences.d rather than by editing one shared file, and inspected with apt-cache policy.
-
Managing installed kernels on Debian and Ubuntu: cleanup, /boot space, HWE and Livepatch
Old kernel packages accumulate in /boot until apt autoremove clears them; Ubuntu additionally offers a rolling Hardware Enablement (HWE) kernel on LTS releases and Canonical's Livepatch service for applying kernel security fixes without an immediate reboot — both Ubuntu-specific, with no Debian equivalent.
-
Running apt and dpkg non-interactively on Debian and Ubuntu without hanging on prompts
A scripted apt-get or dpkg run can stall on a debconf prompt, a modified-conffile question or a held dpkg lock. Setting DEBIAN_FRONTEND, the right confold/confdef options and preseeding debconf answers first turns an install into a command that either finishes or fails loudly.
-
Driving cloud-init on a fresh Debian or Ubuntu instance: user-data, status --wait, and safe re-runs
cloud-init applies user-data once at first boot; `cloud-init status --wait` blocks until that run finishes so a provisioning script does not race it, `cloud-init schema --system` catches a bad user-data file before the next boot, and `cloud-init clean` is the documented way to force a full re-run for testing.
-
Configuring unattended-upgrades for automatic security patching on Debian and Ubuntu
unattended-upgrades applies package updates on a timer using two files: 20auto-upgrades (whether and how often) and 50unattended-upgrades (which origins and whether to reboot). Testing with --dry-run --debug before enabling it in production avoids surprise reboots or half-applied upgrades.
-
Working with AppArmor profiles on Debian and Ubuntu: status, complain mode and local overrides
AppArmor confines individual programs by profile rather than by user; aa-status shows what is loaded and enforced, aa-complain/aa-enforce switch a profile between logging-only and blocking, and /etc/apparmor.d/local holds site-specific additions that survive package upgrades of the shipped profile.
Lisible par machine : JSON