Topic: patching
-
Checking an operating system's support lifecycle before automating against it
Automating patch, upgrade or compliance workflows against a host that has already passed end-of-life produces false confidence: no more security fixes are coming regardless of what the automation reports. This methodology lists where each major vendor publishes lifecycle dates and how to fold an EOL check into a pre-flight step.
-
Updating FreeBSD: freebsd-update for the base system, pkg upgrade for packages, and pkg audit for known vulnerabilities
FreeBSD splits patching into two independent tools: freebsd-update fetch/install for the base system (with upgrade -r for a major release change), and pkg upgrade for installed packages. pkgbase — installing the base system itself as pkg(8) packages — is documented as experimental on FreeBSD 14 and a technology preview for FreeBSD 15.0, not yet the default path.
-
Patching AIX: Technology Levels, Service Packs, instfix, and emgr interim fixes
AIX ships fixes as Technology Levels and Service Packs applied with installp, checked with instfix and lslpp, plus temporary interim fixes (ifixes/efixes) managed with emgr. Knowing which layer you are updating, and that a Service Pack can be applied without being committed, avoids an update that cannot be rolled back cleanly.
-
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.
Machine-readable: JSON