Browsed by
Author: YI

xrdp的小问题

xrdp的小问题

目标系统是 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
奇怪的需求

奇怪的需求

工作中经常会遇到客户提出各种各样的需求，有些需求很合理，有些需求很有难度，有些需求则让人摸不着头脑，比如今天遇到的一个需求。客户的需求看上去似乎不复杂：

呼叫离线（offline）的被叫用户时，先 push 一个通知（notification）给被叫用户，收到响应后再发起呼叫。

我推测这位客户可能在构建某个移动APP。移动APP经常遇到的问题是：希望常驻后台，但是手机的电源管理往往会优化掉应用。这导致该移动APP会强制退出运行，从而无法正常接收消息、更无法接收呼叫。

客户提出的需求不应该是这个场景的解决方案。应当是APP自身向系统申请足够的权限驻留内存，并且APP应该和 SIP 服务器定时 keep-alive 保持激活状态。前者是APP自身的设计问题，后者是SIP注册、激活问题（标准流程）。

当然这只是我的个人推测，不太适合直接反馈给客户，因此向客户简单地提示了几个问题：

（1）离线状态下，怎么保证收到 notification 呢？

（2）既然可以收到 notification， 为什么就不能收到 SIP 的呼叫消息（INVITE）呢？

2020-10-12 更新： 稍微了解了一下相关的内容，大概是 iOS、Android 提供了统一的通知机制。如果收到了 notifications， 系统会从后台启动程序，这样 SIP 终端又可以重新注册并接收呼叫了。 这种模式当然是可以工作的，不过方案确实也很丑陋。另外，由于 GMS 在大陆已经不可描述了， 因此大陆的 Android 手机就更奇葩一些，通过应用程序链之间互相唤醒、互相调用（脏得一批 ……）。

2020-11-28 更新： RFC8599 定义了 SIP PUSH NOTIFICATION 的规范，对于移动终端 APP 类的 wake up 机制进行了定义。还不清楚该规范的应用情况，待进一步了解。

NAME、CNAME 格式

NAME、CNAME 格式

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

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

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

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

方式一：纯压缩编码方式

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

DNS offset 编码
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字节获取。

小升初报名

小升初报名

今天（2020-05-15）上深圳南山教育局网站（这里），给老大报名小升初。毕竟是小孩人生中的一件大事，全程很紧张，生怕某项细节填错了，每项都仔细审核两遍，汗流浃背。

上午九点报名，到下去三点左右基本搞完了…… 中间出现的问题无非就是：网站打不开了、502网关错误了、Nginx 崩溃了等等。

作为一名 IT 行业人士，我非常冷静，并表示理解。自己辛苦点，无非就是隔几分钟去 refresh 一下，并按照惯例祈祷上帝、佛祖、真主、以及各路神仙保佑。

总体上还顺利吧，感谢！

2020-05-18 更新：这两天晚上又上去看看审核结果，看是否需要补充材料。速度非常快，网站也很稳定。这说明前两天实在太多家长急急忙忙地冲进去报名了（包括我自己）。家长们的情绪可以理解，毕竟现在孩子的事是头等大事，心里都想赶紧办妥了，以免夜长梦多。

SSH 配置证书登录

SSH 配置证书登录

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结果

Cloudflare 返回的DNS结果

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

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

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

Google DNS 结果
Google / Ali DNS 返回结果

很明显，这种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 请求，真有意思。

做馒头、肉包子

做馒头、肉包子

包含两个部分：（1）和面 （2）做肉馅。其中，对做馒头而言，只需要关注“和面”这部分即可。

与传统的中餐描述方式类似，没有精确描述各种食材的用量，只会描述诸如“一勺”、“少许”等模糊字眼，默认是我自己家的普通勺子，或者我自己认为的“少许”，毕竟佛曰“不可说”。

和面（做馒头）

（1） 40度左右的温水一小碗，加5克酵母，一勺白糖，发酵大约10分钟。发酵成功时，小碗内应该明显看到发酵起来的泡沫。

（2）面粉8大勺（可能有500克或者更多），少量、多次倒入上述发酵水，用筷子不停搅拌面粉。如果喜欢的话，此时也可以加入新鲜牛奶，尤其是喜欢奶香馒头的话。最终面粉应该搅拌成絮状、小块状。

（3）揉面大约十分钟。表面光滑、不粘手即可。

（4）盖保鲜膜，密封发酵到两倍大小，时间大约是一个半小时，或者两个小时。

（5）发酵后重新揉面排气，大约10~20分钟，其中分批加入少许干面粉，这样的口味会更有嚼劲。

（6）切成小块，放入锅中（铺湿纱布干纱布），盖盖子，二次发酵大约20分钟。

（7）冷水上锅，大火15分钟（如果是肉包，则是20分钟），关火焖3~5分钟后再揭盖。

肉馅

（1）制姜葱水： 大葱一段，切丝；生姜一块，去皮切丝；少许花椒；放入小碗，倒入开水浸泡，直到开水变凉，去除这些材料，只留姜葱水即可。

（2）两根小葱，洗净后切葱花，备用。

（3）五花肉（或者前腿肉）切小块，搅碎成肉馅。

（4）肉馅入盆，加入上述葱花、加入一个鸡蛋（可以有蛋黄）、适量生抽、蚝油、五香粉（或者十三香）、盐、胡椒粉，顺时钟方向搅拌。中间分批次加入少许生姜水（如果是饺子馅，不用加水），注意始终同一个方向搅拌。

（5）最后加入适量香油，继续顺时钟方向搅拌。肉馅略显粘稠即可。

（7） 如果希望吃白菜猪肉馅，则按照1：1比例配置白菜（比如500克猪肉，加500克白菜），白菜之前应该切碎，放适量盐，然后保鲜膜腌制大约10分钟，用纱布包住白菜碎，将水挤掉。将去水后的白菜馅和肉馅混合，同样顺时钟方向搅拌即可。