星期六（5 月 18 日），我启动了一台虚拟机（运行 Ubuntu 18.04 服务器）。
令我惊讶的是，VM 几乎立即尝试连接到d16r8ew072anqo.cloudfront.net:80，这是我以前从未见过的——这是一个非常“原始”的 Ubuntu 安装，没有自定义apt存储库，只安装了几个包。它以前从未连接到任何可疑的东西——主要是连接到 Ubuntu 和 Snap 域。（我使用 Little Snitch 来监控网络流量，因此我可以实时查看连接并可以拒绝它们。）
我花了一些时间试图弄清楚发生了什么，我相信我将范围缩小到unattended-upgrades安装安全补丁。具体来说，当我手动重新安装intel-microcode:amd64包时，我能够重现与 CloudFront 的奇怪连接（尽管这可能只是巧合）。
然后，在星期一，我想记录这个问题，以防再次发生类似的事情，但令我惊讶的是，我无法再重现这种奇怪的联系。
周一唯一可观察到的区别是sudo apt-get install --reinstall intel-microcode:amd64[1]的输出
没有这Ign:1条线。
我搜索了网络，包括http://archive.ubuntu.com/ubuntu，grep-ed 虚拟机的磁盘，检查了 misc 的 DNS 记录。ubuntu.com子域，尝试wget使用不同的 URL 来查找到可疑域的重定向——但我找不到任何关于与 CloudFront 的奇怪连接的线索。
我的问题是：有谁知道发生了什么，或者至少在他们的日志中注意到了相同的连接？
（顺便说一句，我知道一个例子，Ubuntu 团队使用 CloudFront 来减轻他们的服务器的 负担： 我的 12.04 ISO 上的 MD5 不匹配，这是怎么回事？ --所以我希望这可能是一个类似的情况？ )
[1]：
$ sudo apt-get install --reinstall intel-microcode:amd64 …来自源包的自述文件说：
When installing ufw from source, you will also need to integrate it into your
boot process for the firewall to start when you restart your system. Depending
on your needs, this can be as simple as adding the following to a startup
script (eg rc.local for systems that use it):
# /lib/ufw/ufw-init start
For systems that use SysV initscripts, an example script is provided in
doc/initscript.example. See doc/upstart.example for an Upstart example. Consult
your distribution's documentation for the proper …您可以轻松检查 TRIM 是否适用于“正常”ext4 分区：https : //askubuntu.com/a/19480/5920。
如何为 LUKS 加密的加密货币做到这一点？让我们假设由 12.04 Alternate 安装程序（即涉及 LVM 的安装程序）进行的默认 LUKS 设置。
我在这里要问的是，如果文件存储在加密卷中，我如何在删除文件后检查磁盘上的块是否实际填充了零。