テーマ： patching
-
Support Repository Updates and the Solaris 11.4 patching model: SRUs, CPUs, and checking what is installed
Solaris 11.4 patches through the same pkg update path as any other install; the entire incorporation's version reports the exact update level, Oracle ships fixes as roughly monthly Support Repository Updates with every third one also a Critical Patch Update, and Oracle's Premier/Extended/Sustaining phases set what each stage delivers.
-
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.
-
Game patches: package byte locality, delivery chunks and manifests
Control update size by understanding changed package bytes, separating logical content chunks from transfer chunks, and measuring download traffic independently from installation work.
-
DebianとUbuntuでセキュリティ更新を自動適用するためにunattended-upgradesを設定する
unattended-upgradesは、20auto-upgrades（実行の有無と頻度）と50unattended-upgrades（対象の配布元と再起動の有無）の2つのファイルを使い、タイマーでパッケージ更新を適用する。本番環境で有効にする前に--dry-run --debugでテストすると、予期しない再起動や途中までしか適用されない更新を避けられる。
機械可読： JSON