学习 – 第 5 页 – 静水潜流

给 vbox 的客机系统扩容

2021/02/01 YI

主机是Window 10，运行在 VirtualBox 中的客机系统是 Debian （testing）。当初估计不足，只划了 8G 空间给客机系统，因此面临着容量不足的问题，迫切需要扩容，要不然就要重新构建一个客机，实在过于麻烦了。

从网上搜集了一些信息，有各种问题。绝大部分的资料其实不能算扩容，无非就是增加一个盘，然后 mount 到新的分区而已。而我希望是将现有的虚拟硬盘直接扩容，无需改变或者 mount 特定的分区或者目录。最后通过安装 GParted 软件，加上修改部分配置，终于解决了问题，从8G 扩展到 28G，如下图所示：

系统只有两个分区：主分区和交换分区。目的就是扩大主分区（/dev/sda1）的容量即可，其他无需改变（至少在使用者的角度是没有任何变化）。

增加 VBox 虚拟介质容量

VBox 新版都支持给虚拟介质扩容，操作简单。在“管理 – 虚拟介质管理”里找到客机的虚拟介质，直接增加容量即可。比如，将介质从 8G 直接调整到 28G。

但是客机系统不是直接就使用了扩容的硬盘容量。新增加的部分对客机系统而言，属于“未分配”的容量，因此需要进入客机系统（也就是 Debian）中进行磁盘管理，让系统能识别、管理这部分新容量。

Debian 磁盘管理

牛人直接用 fdisk 大概就可以搞定。作为一名无可救药的图形界面党，我当然还是倾向于使用图形界面的软件来解决问题（非常不 linux，非常不 geeker），也就是 GParted。

GParted 很像 Windows 的磁盘管理工具，因此使用起来油然而生熟悉的感觉。启动 GParted 后，很容易就看到未分配的磁盘容量。可惜不能直接移动或者扩容/dev/sda1，原因大概是中间有个 swap 分区。刚开始我被困住了，后来想明白：

既然 swap 分区阻挡了主分区的扩容（移动），那删除掉 swap 分区，那主分区和未分配分区不就连起来了吗？试试后发现果然如此：（1）删除 swap 分区，（2）调整主分区（/dev/sda1）的大小，（3）然后再重新将剩余的分区设置为 swap 分区。

千万别格式化主分区！只需要重新格式化 swap 分区即可。

GParted 有个bug：在上述步骤中，重新删除、创建了 swap 分区，可是 GParted 并没有修改 /etc/fstab 里对应的 UUID 值！导致每次重启后，发现 swap 区都没有激活使用。

解决这个bug也简单，在 GParted 中查询 swap 分区的属性，获取其 UUID 值，然后修改 /etc/fstab 中对应的 swap 分区的 UUID 值即可。

一点思考

本次扩容过程中，被 swap 分区困扰了很久，有各种问题。要么是 swap 分区阻挡了主分区扩容，要么是 swap 分区的 UUID 更新（这个算GParted的bug）。

如果不设置 swap 分区呢？修改为采用 swap 文件方式，只保留一个主分区，这样就灵活很多。当然，实际部署 Linux 系统如果采用这种方式，可能会有问题（比如崩盘导致数据丢失等），既然是客机系统，倒是无所谓。

12 + 100

2021/01/10 YI

正在看一本投资方面的书《段永平投资问答》，相当好的一本书，居然是免费的。里面谈到关于长期投资的一些观点，据说段永平是两三年才有一个好想法、两三年才出手一次。

书中也提到：芒格说伯克希尔成立57年来仅仅10个好点子，去掉这十次，整个就是笑话。

打开证券软件，看了一眼2020年的操作记录：

交易股票100次、交易股票12只！

不禁流下了贫穷且没有格局的泪水……

DNS over HTTPs

2021/01/04 YI

传统的 DNS 基于 UDP 协议，并且采用明文方式传递请求和结果。在互联网早期，这样做没什么问题。而现在网络越来越复杂，网络实体越来越多，各种看得见、看不见的手都可能修改 DNS 的结果。

简单的解决方式就是对 DNS 进行加密。 Mozilla 联合 Cloudflare 通过 HTTPs 来传递 DNS 消息，也就是 DoH （DNS over HTTPs）。这种方式从设计上看，不如 DNS over TLS 高效，但是胜在简单、无需过多更改网络设备和软件。

Firefox 已经内置了对 DoH 的支持，而且非常简单。问题是默认的两个 DoH 服务商：Cloudflare 和 NextDNS，在国内由于某种不可描述的原因，访问速度都很受影响。实际上国内腾讯和阿里的公共 DNS 服务也支持 DoH，以腾讯为例，它提供的 DoH 访问地址是：

https://doh.pub/dns-query

Firefox 的网络设置中，按下图进行配置即可：

另外，阿里提供的 DoH 访问地址为：

https://dns.alidns.com/dns-query

FED模型（股债收益差）投资法

2020/12/21 YI

在雪球上看到一篇文章介绍了一个 D 值的估值方法（实际就是美联储的 FED 模型，也就是“股债收益差”模型），用于判断股市是否高估。作者主要投资沪深300指数基金和国债，根据 FED 值调整仓位。

FED 值计算比较简单，以下是计算公式：

FED 差值 = （沪深300收益率 - 十年国债收益率）*100

作者指出：低于2清仓，高于6满仓。理解起来也容易，低于2说明股市已经高估了，风险和收益不匹配，不如直接投资国债；高于6则相反，股市极度低估，收益远超国债。

其中， “沪深300收益率” 就是“沪深300市盈率”的倒数，点击此处获取“沪深300市盈率”数值。“十年期国债收益”数据请点击此处获取。

下面我们简单计算一下目前的 FED 差值：

沪深300市盈率 = 16.35
十年期国债收益率 = 3.319%
FED 差值 = (1/16.35 - 3.319%)*100 = 2.7

从估值看，当前股市已经处于高估阶段。

NetworkManager state is now ASLEEP

2020/12/17 YI

最近有一台 HP ELite 笔记本退役了，其实配置还不错，500GB SSD 硬盘、16GB内存，看着挺轻薄，本来还打算用来替换自己平时使用的笔记本，后来发现有些不爽：（1）触控板有点飘（2）有个键被我不小心按坏了，也许本来就坏了（3）屏幕时不时出现横线、甚至出现闪烁，很不舒服。

食之无味、弃之可惜。忽然想到可以安装 Debian 做家庭服务器用，上述缺点就无关紧要了。安装了最新的 Debian 10，然后修改成 Debian（sid），过程很顺利。非常棒！以至于我甚至打算直接 VNC，或者用 VSCode 登录上去做一些开发工作。

因为是当服务器用，因此一直都是合盖，然后扔角落里默默工作。接着又发现一个问题：过一段时间后，WiFi 网络老是断开，无法远程登录，需要重新开盖然后登录。琢磨着大概是系统休眠了，检查 syslog 信息，发现以下信息：

NetworkManager: sleep: wake requested (sleeping: yes  enabled: yes)
NetworkManager: state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
NetworkManager: NetworkManager state is now ASLEEP

看来确实休眠了。搜索网络，查到一篇 Ubuntu 停止休眠的文章（请点击此处），考虑到 Ubuntu 和 Debian 本质没什么区别，操作也是有效的。

关闭休眠功能，请使用以下命令：

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

当然，如果后悔了，需要重新打开休眠功能，可以使用以下命令（未验证）：

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

xrdp的小问题

2020/10/14 YI

目标系统是 Debian, 采用 xrdp 远程登录窗体界面，总是在显示登录时黑屏。查了很久一直没有结论，后来就干脆用 vnc 算了。

今天在查其他问题时，无意间翻查到文件 “/usr/share/doc/xrdp/README.Debian”，里面提示需要修改“/etc/X11/Xwrapper.config”文件，将

allowed_users=console

修改为

allowed_users=anybody

重启后，果然可以通过xrdp正常登录了！只是比较奇怪，为什么 Debian 系统不将默认值修改为 anybody？是没人维护的原因吗？那为啥又在 readme 文件中单独说明呢？

另外，由于 Raspberry Pi 也是基于 Debian 系统，因此 Pi 中做同样的修改，也可以通过 xrdp 正常登录。

xrdp 读取 “/etc/ssl/private/ssl-cert-snakeoil.key” 进行加密，但是这个文件默认只有 “ssl-cert” 组的成员才可以读取，因此还需要将 xrdp 用户加入该组：

sudo adduser xrdp ssl-cert

NAME、CNAME 格式

2020/06/07 YI

总体而言，早期 DNS 协议是个比较简单的协议。受限于 UDP 大小和数据量，基于 UDP 的 DNS 协议限制了包大小，并且采用二进制编码方式力求减少数据量占用。

二进制编码方式相比文本方式（例如HTTP、SIP、SMTP等）最明显的缺点就是不直观，再用一些技巧减少数据量，DNS 协议在定义、实现方面总显得有些弯弯绕绕。

比如 NAME、CNAME 等结构的编码。

本文记录了这些古怪的编码方式，方便以后查找，并帮助后续的开发者不会被代码给绕晕。作为我个人来说，还是尽快忘记这些吧。

方式一：纯压缩编码方式

这种方式应用很普遍，以“0xc0”标记开始，加上一个字节的 offset，进行消息包内的寻址即可。如下图所示：

其中， 0x0c 就是偏移量。

方式二：直接编码方式

这种方式比较直接，占用数据量也相对大一些，将域名完整信息存在数据包中。如下图所示：

需要说明的是：并不是直接将所有字符存进去就 OK 了。对于域名数据，以“.”符号分割成几个单元，每个单元数据采用 “length + value” 方式进行编码，最后以0x00结束编码。以上述数据为例：

08 6e 73 69 6e 61 69 6d 67 04 67 73 6c 62 08 73
69 6e 61 65 64 67 65 03 63 6f 6d 00

比如，第一个 0x08，说明后面的“nsinaimg”（即 6e 73 69 6e 61 69 6d 67）长度；然后是 0x04，说明后面的“gslb”（即67 73 6c 62）长度……其他单元类推。

方式三： 混合编码方式

这种方式其实就是综合了上述两种方式。以直接编码方式开始，然后以压缩（偏移）编码方式结尾。如下图所示：

对图中的数据码流描述如下：

03 6b 6c 6e 04 67 72 69 64 c0 38

0x03 描述了“kln”（即 6b 6c 6e）的长度，0x04 描述了“grid”（即 67 72 69 64）的长度，而域名的后续部分，通过“c0 38”编码可以知道：需要偏移0x38字节获取。

SSH 配置证书登录

2020/04/30 YI

SSHd 配置采取了一些安全措施，比如：修改端口、禁止 root 远程登录（这里）、启动 fail2ban 防止恶意登录（这里），等等。目前看这些措施基本满足了日常的维护管理需求。

通常还会采取证书登录方式，禁止密码鉴权登录。不过以往考虑到密码方式更方便，因此没有动力去修改。时间就这么过去了……

最近登录服务器检查日志，惊讶地发现 fail2ban 每日的日志居然有十几M之多，全是各类奇葩以各种方式尝试登录 SSH。虽然 fail2ban 工作得很好，但是万一出现了 bug 呢？万一哪个变态就是锲而不舍、经年累月地尝试登录呢？应该下狠手，让老铁们彻底绝望，因此决定禁止密码方式登录，要求采用证书登录。

配置不复杂，涉及客户端生成证书密钥，以及将公钥上传到服务器等。主要参考 Linode 的两篇配置文档（这里和这里）。以下是详细步骤：

生成证书

客户端也是 Linux 系统，因此相当简单：

ssh-keygen -b 4096

该命令在当前用户的 .ssh 目录下创建了两个文件： id_rsa 以及 id_rsa.pub 。

其中 “id_rsa.pub” 是当前用户的公钥文件，将其上传到服务器上，然后添加进 ~/.ssh/authorized_keys 文件中：

cat id_rsa.pub >> ~/.ssh/authorized_keys

添加完成后，服务器上的 id_rsa.pub 文件不用再保留，删除即可。要注意，authorized_keys 文件应该设置为别人不允许访问，确保足够的安全性。例如设置文件权限为600：

chmod 600 authorized_keys

当 SSH 客户端登录时， SSHd 默认读取该用户的 authorized_keys 信息进行证书鉴权。

修改 /etc/ssh/sshd_config 文件

PasswordAuthentication no

然后重启 sshd 即可：

sudo systemctl restart sshd

之后，客户端如果采用密码鉴权方式登录，或者粗暴破解，将被无情拒绝。

如果有多个客户端需要登录服务器，则需要各自生成证书，并将公钥上传到服务器，并添加到 authorized_keys 文件中即可。

Cloudflare 返回的DNS结果

2020/04/18 YI

最近查一个客户遇到的 SIP 呼叫问题，发现在检查 DNS 记录时有问题，没有正确获取 DNS 记录。切换了几个 DNS 服务器测试，只有 Cloudflare DNS 服务器（1.1.1.x 系列) 返回的DNS记录会触发问题。

这并不是说 Cloudflare 的DNS记录有错误，而是我们自己实现的 DNS 库没有考虑到该记录的不同寻常之处。Cloudflare 的返回结果确实有点与众不同。

下图是Google DNS 以及 Ali DNS 返回的DNS结果，请注意其中的 Name 字段的内容（0xC0 0x0C）

很明显，这种DNS结果采用了 compress 方式，通过 offset 来获取真正的Name。图中的 0x0C 实际就是偏移量，指向了包中的另一处地址。Compress 方式最直接的好处就是节省了包大小。

而 Cloudflare 的 DNS 结果如下图所示，直接将域名包含在 Name 中，以 0x03 标注开始，以 0x00 表示字符串结束。不再需要偏移指向其他地址。

Cloudflare 的 DNS 记录 — Cloudflare DNS 返回的结果

这种方法的好处是够直接，不再需要跳转获取真实的域名信息。当然坏处是增加了数据包的大小。

我们测试了网络上大部分的 DNS 服务器，目前仅发现 Cloudflare 采取了这种方式，其他服务器都是采用 compress 方式。

站在“人”的体验角度，似乎 Cloudflare 更合理一些。但是要注意，compress 方式更符合计算机的处理，毕竟前面的 Queries 部分已经解析过 Name 了，没必要再解析一次。另一方面，直接 offset 寻址，也远远快于再一次通过判断0x00来解析Name 字符串。

因此我个人认为 Cloudflare 的处理方式，即拖慢了速度，又增加了数据包消耗。当然，以目前计算机的处理能力以及网络速度，这些都是浮云。我们的解决方式也是淡定地接受这个结果，并修改 DNS 库进行适配即可。

在本次查问题中，测试了网上公布的香港 DNS 服务器，全部拒绝了来自大陆 IP 地址的 DNS 请求，真有意思。

静水潜流

记录一点生活

Browsed by
Category: 学习