由于不清楚,此内容被搁置。我可能加入了太多背景解释。我深感抱歉。因此:
这是问题,用另一种方式重新表述:
可以 apt-check,即
/usr/lib/update-notifier/apt-check
可以像处理非内核升级一样处理潜在的内核升级,检测它们并区分包含安全修复的升级和不包含安全修复的升级,以便那些包含安全修复的升级将反映在 apt-check 输出的第二个字段中,而无需安装元包 linux-generic?
如果 apt-check 不能做到这一点,还有其他程序可以吗?
user535733 似乎已经理解了这一点,并在评论中明确回答了这个问题:
“...如果您卸载元包,则没有其他自动方法来检查内核升级...除非您自己编写。”
如果没有人反对,并且 user535733 没有说我误解了他,并在答案中提出了这一点,我会给他加分。
user535733 和 waltinator 都建议我可以自己编写一个程序来做这件事。Waltinator 可能会重写 apt-check 的源代码,但我不会。我可能可以编写一个解决方法,但我需要找到某种方法来区分具有新安全修复程序的内核升级和没有新安全修复程序的内核升级。
谢谢,gentlesapients。
= = = 添加的材料结束 - 原始帖子如下 = = =
apt-check(来自 update-notifier 包),通常用于编写 MOTD,但可以直接调用,返回以下形式的输出:
x;y
其中 x 是可能升级的数量
,y 是可能的安全升级的数量
如果linux-generic
没有安装,则可能的内核升级不计入第一个数字。如果需要内核升级来纠正旧内核的安全缺陷,它是否计入第二个数字?换句话说,apt-check
在没有依赖最新内核的元包的情况下,是否可以依靠它来告诉您需要升级内核?
如果这还不清楚,这里有一个具体的例子:
每次我升级到 4.4.0-77,它都会破坏我的 Xenial 系统,我有 2 个,都在同一台机器上。我发现唯一真正有效的解决方案是恢复损坏系统的 fsarchiver 备份,挂载我的所有系统,运行 lilo(就像update-grub
不同的引导加载程序一样)以查找新/旧内核,重新启动到恢复的系统并卸载 linux-generic,这样它就不会自动安装 4.4.0-77。现在我通过运行以下命令检查 linux-generic 将安装什么内核:
apt-get install --simulate linux-generic.
也许当我们达到 78 或 80 甚至 4.4.1 时我会再试linux-generic
一次。
那么apt-check
,当新的内核升级之一不仅仅是为了闪亮的新特性,而是实际上是为了纠正安全漏洞时,您会告诉我吗?还是它依赖于此linux-generic
?如果是后者,是否有其他替代方法来apt-check
实现此目的?
答案1
您的问题有点复杂,但我认为它可以归结为标题中的一个问题,所以这就是我要解决的问题。
Apt 如何选择要升级的软件包
不,A进阶磷包装电视嗎按照其设计,linux-image-*-generic
除非有其他软件包依赖它,否则无法自动安装新软件包(例如)。它只会自动升级已安装的软件包,并在此过程中替换其先前版本。
这就是我们使用元软件包的原因之一linux-image-generic
:让 Apt 知道要安装的新软件包,而无需替换旧版本。我们这样做是因为替换当前正在运行的内核很困难,而且人们希望在出现问题时更容易恢复到较早的已知可运行的内核版本。
此外,Apt 不知道也不关心版本号的语义。它只关心版本号字符串的顺序和可用版本列表,以便根据可配置的评级系统选择最适合安装的版本。软件包(存储库)管理器负责将上游更改(包括安全修复)合并并发布到具有合适版本字符串的替换软件包中。
这对于apt-check
现在我们已经大致介绍了 Apt,我可以回答一下它如何影响您关于update-notifier
提供软件包的问题apt-check
:与 Apt 一样,如果新软件包不依赖于已安装或计划安装的软件包,它就无法知道要安装的新软件包。如果您没有linux-image-generic
安装,那么 Apt 将看不到新的内核软件包,update-notifier
当它向 Apt 查询可升级软件包时也不会看到。
如果我真的想要这个功能怎么办?
当然,与 Linux 中的大多数东西一样,您可以编写一个工具来搜索所有可用软件包中的模式,以便(半)自动地安装它们。我至少不知道有任何可以执行此操作的板载工具,尽管这项任务似乎足够通用,因此我不会惊讶于看到一些管理员为此编写的脚本。
答案2
在 Xenial 中,无人值守升级默认仅安装安全修复程序。而在软件更新程序中,您可以选择仅安装安全更新。但对于您的问题,即将推出的安全更新可能会包含早期非安全更新的更改,这也会破坏您的系统,因此您最好报告针对 Linux 的错误,以便在即将推出的更新中修复该问题。
无论如何,你可以在命令行中运行
apt-cache policy linux-generic
查看最新的可用更新是否是安全更新。
在 Xenial 中,你可以手动安装 linux-generic 的最新安全更新
apt-get install linux-generic/xenial-security
答案3
感谢大家,也感谢 Canonical 的 Andy,他在另一个论坛上给出了一些很好的建议。我对此进行了一些研究,不仅仅是在这里,我学到了一些知识,也开始怀疑其他一些知识。太多了,无法在评论中一一列举。
严格来说,该问题已由用户 535733 在我的初始帖子的第二条评论中正确且及时地回答,并且公平地说,如果他能将其作为答案,我会很高兴接受。
@user535733 — 请注意以上内容。
但是 waltinator 在第一条评论中扩展了这个主题,包括创建工具来完成这个工作的可能性,David 也扩展了这个主题,介绍了 apt-check 的工作原理以及为什么在没有安装 linux-generic 的情况下它无法执行此操作。
以下内容远未完成,部分内容是推测(我希望已明确标注),甚至可能存在一些明显的错误(想象一下),我可能会回来编辑更多内容。也许偶然发现此页面的人会对此感兴趣。您可能必须在自己的系统上运行这些命令才能以正确的格式清楚地看到输出。
关于 apt-check 和 linux-generic:
Linux-generic 似乎只是个幌子。我错了,我以为问题出在缺少它。现在我认为 apt-check 根本无法做到这一点,即使安装了 linux-generic。如果不安装 4.4.0-77,测试起来会很棘手。我将来会测试,那时我不必担心内核会不断破坏我的 xenial 系统。
问题不在于 apt-check 无法访问必要的数据。您绝对不需要安装 linux-generic 来获取有关潜在内核升级的元数据,这些元数据足以显示可用的内容以及是否有安全修复。
我假设“apt-get update”(apt 的一部分)获取了信息(详细信息见下文),但无论如何获取了它:
不需要安装 linux-generic 来查看潜在的内核升级。
它不需要安装 linux-generic 来确定 linux-generic 当前依赖哪个内核版本。
它不需要 linux-generic 来确定潜在的内核升级是否有安全修复。
此外,无论从哪里获取这些信息,这些信息都会在本地保留(大概直到您清除它)。因此,即使离线且未安装 linux-generic,apt-check 也可以访问必要的信息 - 它只是不使用它,可能是设计使然。但它可以在脚本中使用 - 我没有安装 linux-generic,以下是即使在离线情况下也可以在我的系统上运行的 2 个测试示例:
$ apt-cache showpkg linux-image-4.4.0-75-generic | grep "$(lsb_release --codename --short)-security"
输出:
4.4.0-75.96 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_binary-amd64_Packages) (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-updates_main_binary-amd64_Packages)
File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_binary-amd64_Packages
File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_i18n_Translation-en
$
因此,4.4.0-75 有安全修复。
相比之下:
$ apt-cache showpkg linux-image-4.4.0-77-generic | grep "$(lsb_release --codename --short)-security"
和输出(仅返回提示):
$
4.4.0-77 没有。
关于 apt-check 和 apt:
Apt-check 是 update-notifier-common 的一部分(不是上面提到的 update-notifier),可能依赖于 apt 来获取有关软件包的信息,正如 David 所指出的,可能特别依赖于“apt-get update”,即使 apt 不依赖于 linux-generic 来获取有关潜在内核升级的信息。这是我所期望的,我看不到任何其他选择,但奇怪的是,除非开发人员错误地标记了依赖项,否则 apt 不是 apt-check 的依赖项:
$ apt-rdepends update-notifier-common | grep apt
输出:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Depends: python3-apt
python3-apt
Depends: libapt-inst2.0 (>= 1.1~exp9)
Depends: libapt-pkg5.0 (>= 1.1~exp9)
Depends: python-apt-common
libapt-inst2.0
Depends: libapt-pkg5.0 (>= 1.1~exp9)
libapt-pkg5.0
python-apt-common
$
因此,理论上,您不需要 apt 来运行 apt-check - 您可以在使用 dpkg 和 dselect 管理的系统上使用它,尽管我不知道它如何工作。在我真正尝试之前,我当然不会打赌它会成功(我以后可能会出于好奇而这样做),但这就是依赖项的标记方式。您可能会认为,如果 update-notifier-common 的某个命令需要 apt 才能工作,开发人员会将 apt 标记为 update-notifier-common 的依赖项,但这可能是一个疏忽。
因此,就最初的问题而言,我现在怀疑的是:
“是否可以使 apt-check ...... 能够像处理非内核升级一样处理潜在的内核升级,检测它们并区分包含安全修复的升级和不包含安全修复的升级...而无需安装元包 linux-generic?”
不,而且它可能也不能与 linux-generic 一起使用。
“如果 apt-check 不能做到这一点,还有其他程序可以吗?”
不,可以这么说,这并不是开箱即用的。
但是,重新创造一些可以
正如 waltinator 所建议的,如果您具备相关知识和意愿,可以重写 apt-check 来实现这一点。但是,正如 David 所建议的,可以使用其他工具编写该功能脚本,而且这样做可能比学习如何重写 apt-check 容易得多。
如前所述,您可以通过对输出应用一些 grep 和 cut 魔法来获取包含由 Canonical 认可的最新、最闪亮的内核的软件包的名称:
apt-get install --simulate linux-generic
你可以将其归类为具有/不具有安全修复,例如
apt-cache showpkg linux-image-4.4.0-75-generic | grep "$(lsb_release --codename --short)-security"
如上图所示。
理想情况下,要编写此脚本,我们需要 linux-generic 所依赖的完整版本历史记录,以避免在以下情况下出现误报:
您已安装版本 100。
版本 101 已修复安全问题,但您的计算机那一周并未开机。
版本 102 没有安全修复(相对于 101,但相对于 100 有,因为它仍然保留了 101 中所做的修复)。
如果我可以 curl 完整的 linux-generic 版本历史,并以某种方式找出依赖内核在 repo 的哪个“口袋”中发布,那就太好了。到目前为止,我只发现了如何对仍然在 repo 中的旧版本执行此操作。
此命令:
apt-cache madison linux-generic
方向正确,但我认为它只获取了存储库中现有的内容,而不是存储库中曾经存在的内容,因此我不确定它提供的信息是否足以防止上述假阴性情况。如果在上面的例子中,101 已经从存储库中消失,我认为“apt-cache madison linux-generic”提供的信息不够。
哦,对了
还有一件事我要指出,以免有人对此感兴趣并在不知情的情况下花费大量时间:
我仍然在研究这个问题,因为我刚开始研究,而且我很固执。但是,据我所知,纯粹是偶然,给我带来问题的内核没有安全修复,因此如果我有一个可以工作的脚本,它就永远不会破坏我的 xenial 系统,但 Andy 告诉我 4.4.0-77 是一个罕见的情况,linux-generic 所依赖的绝大多数内核升级都有安全修复。我怀疑他说“99%”是比喻/夸张,但即使考虑到这一点,我怀疑适用于潜在内核升级的类似 apt-check 的机制不会经常阻止不必要的(安全方面)升级,因此会阻止不必要的内核升级破坏 apt 或其他关键系统组件,这种情况更少见。它似乎只是偶然为之,它会为我做到这一点。顺便说一句,4.4.0-78 对我来说工作正常。安迪是对的——无论 77 是什么,它都已经修好了。