白名单配置在 /etc/apt/apt.conf.d/50unattended-upgrades 中，通过 Unattended-Upgrade::Allowed-Origins 定义可信源（origin+codename+component），仅控制仓库层级而非包名，需配合 20auto-upgrades 启用及服务激活才生效。
白名单配置在哪？关键文件是 /etc/apt/apt.conf.d/50unattended-upgrades
Ubuntu 的自动升级白名单不是靠“允许列表”实现的，而是通过 Unattended-Upgrade::Allowed-Origins 配置项定义哪些源（origin + codename + component）可以被信任并自动升级。这个白名单机制本质是“只允许指定源”，默认只开 ${distro_id}:${distro_codename}-security，其他全被挡在外面。
你不能在这里写“只升级 nginx 和 openssl”，它控制的是**源仓库层级**，不是包名层级。想按包名控制，得用黑名单或更细粒度的工具（如 apt-mark hold），但那不属于 unattended-upgrades 白名单范畴。
-
Unattended-Upgrade::Allowed-Origins是唯一生效的白名单入口，所有允许的源必须显式列出 - 每个条目格式为
"origin=Ubuntu,codename=focal,label=Ubuntu-Security"或简写"${distro_id}:${distro_codename}-security" - 变量如
${distro_id}和${distro_codename}会被自动展开（例如 Ubuntu 22.04 →Ubuntu:jammy-security） - 注释掉的行（以
//开头）不会生效；空格、换行、引号必须严格匹配语法
怎么加一个非-security 的源进白名单？比如 -updates 或第三方 PPA
直接编辑 /etc/apt/apt.conf.d/50unattended-upgrades，在 Unattended-Upgrade::Allowed-Origins 块里追加条目。注意：PPA 必须满足 origin 和 label 可识别，且签名密钥已导入系统，否则升级会静默失败。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 启用
-updates（推荐用于稳定环境）："${distro_id}:${distro_codename}-updates"; - 启用 ESM（Extended Security Maintenance）源（LTS 用户必备）：
"${distro_id}ESM:${distro_codename}"; - 添加 PPA（如
deadsnakes/ppa）需先查清其 origin 和 label：
运行apt-cache policy python3.9查看来源，再写成类似"origin=ppa.launchpad.net,codename=jammy,label=deadsnakes-ppa" - 切勿盲目添加
"origin=Ubuntu"—— 这会匹配所有 Ubuntu 官方源（含 proposed/universe），极大增加风险
为什么改了白名单却没生效？常见卡点
白名单配置后不触发升级，多数不是语法错，而是依赖链断裂或服务未激活。最常踩的坑是：只改了 50unattended-upgrades，却忘了配 20auto-upgrades 或没重启服务。
-
APT::Periodic::Unattended-Upgrade "1"在/etc/apt/apt.conf.d/20auto-upgrades中必须设为"1"，否则定时任务根本不调用升级逻辑 - 服务状态要检查：
systemctl is-active unattended-upgrades应为active；若为inactive，需执行sudo systemctl enable --now unattended-upgrades - 模拟运行失败时，
sudo unattended-upgrade --dry-run -d输出里若出现No packages found that can be upgraded unattended，说明白名单没匹配到任何候选包 —— 很可能是源没启用、apt update没跑过，或目标包根本不在你写的 origin 里 -
/var/log/unattended-upgrades/unattended-upgrades.log是唯一真相来源，别只看终端输出
白名单之外还能限制包？用 Package-Blacklist 补位
白名单管源，黑名单管包。如果你明确知道某些包绝不能自动升级（比如内核、数据库驱动、自研 deb），就该用 Unattended-Upgrade::Package-Blacklist。它比白名单更贴近“软件级控制”，但它是排除逻辑，不是白名单的延伸。
- 写法示例：
Unattended-Upgrade::Package-Blacklist {"linux-image-generic"; "mysql-server";}; - 注意：包名必须和
dpkg -l输出完全一致（不含版本号），大小写敏感 - 黑名单优先级高于白名单 —— 即使某个包来自白名单源，只要进了黑名单，就不会升级
- 不要滥用黑名单来“替代白名单”：比如把所有包都列进去再逐个放开，这违背设计初衷，也难维护
白名单真正起效的前提，是理解它只作用于 APT 源元数据层面，而不是包管理器的最终安装行为。哪怕配置全对，如果 apt update 拉不到对应源的 Packages 文件，或者目标包被标记为 hold，它依然不会动。调试时，永远先确认源可用、包可升级、服务在跑、日志有记录 —— 这四步缺一不可。
