Category Archives

146 Articles

Ubuntu 22.04 / OpenSSH 8.9 使用 gpg-agent 登录报错 agent refused operation 的解决方法

0   4621 转为繁体

Ubuntu 22.04 升级了 OpenSSH 到8.9,这个版本默认开启 [email protected] 作为密钥交换(KEX)方法。这个算法使用 512 bit 的 hash。

如果客户端和服务端都升级到了8.9或以上,则成功协商使用这一KEX算法,这时如果使用 gpg-agent 的 SSH 功能签名则会报 agent refused operation。

打印 gpg-agent 的日志可看到报错为 Provided object is too large。

解决方法是在客户端(~/.ssh/config)或服务端(/etc/ssh/sshd_config)中禁用这个算法

同理 diffie-hellman-group16-sha512 和 diffie-hellman-group18-sha512 也应该被禁用,但它们优先级本来就很低。

如果仍然有问题,把Kex Host Key Algorithm也改一下,如改成

Go中JSON解码非UTF-8二进制值的问题

0   6872 转为繁体

我们在一个项目中创(luan)新(xie)地用JSON来编码msgpack编码后的结果(即encoded = json_encode(msgpack_encode(txt))),结果发现Golang侧无法解码。

首先我们可以确定msgpack没有问题,因为输入给msgpack解码数据就与输入值不一致。

我们使用lua-cjson来编码一个JSON,因为结果不是printable的,所以在外面加一层base64.encode

结果是eyJhIjoihjEyMyJ9。

在Python里解码它:

结果是{‘a’: ‘\x86123’}。没有问题,和输入一致。

在Go里解码它:

结果是[239 191 189 49 50 51],可以看到\x86被解码成了\239 \191 \189即\xefbfbd,表示无效的UTF8字符。

这是因为Go默认采用UTF-8解码,如果field被标记为string,则json.Unmarshal会使用utf8.DecodeRune来尝试解码输入https://github.com/golang/go/blob/master/src/encoding/json/decode.go#L1304。但在我们的场景中,\x86是一个单字节的非UTF-8字符,所以utf8.DecodeRune返回了utf8.RuneError并把它放到了结果里。

那么到底是哪里出了问题呢?

首先,JSON的RFC指出,其中的字符串必须以UTF-8编码(https://datatracker.ietf.org/doc/html/rfc8259#section-8.1),但是同时也提到,除了几个特殊的字符外,其中的字符可以被escape也可以不escape(https://datatracker.ietf.org/doc/html/rfc8259#section-7)。所以lua-cjson的这种编码方式似乎也是合法的?

解决办法是写一个自己的Unmarshal方法。首先把结构体中的field标记为自定义类型:

然后我们魔改unquote方法,在原来的基础上加上对解码结果是否为utf8.RuneError的判断

还需要注意的是,Go的json包默认对[]byte类型的field进行base64编解码:

结果是> [123 34 120 34 58 34 107 119 61 61 34 125] {“x”:”kw==”};同理Unmarshal时也会需要输入为base64编码结果。

因此在上面这个解决方法中,我们用rawBytes这个新类型来alias到[]byte,而并不直接使用[]byte类型再在之后自己解码。

发了一个issue:https://github.com/golang/go/issues/51094。

另外的JSON库没有这个问题,测试了https://github.com/json-iterator/go 和 https://github.com/bytedance/sonic

开源了咸鱼捡的京付的三色墨水屏驱动

0   6178 转为繁体

35块一个,长这样

经过一番Google找到了对应的原厂屏,是Gooddisplay的GDEH042Z96,屏幕芯片是SSD1619A,这个芯片初始化序列比幻塔的新手教程还长。

整理了一下官方例程之后,发了一个PR:https://github.com/ZinggJM/GxEPD2/pull/47;有一些点需要注意:

  1. 三色屏(实际上是双色)是两种液晶分开刷新的,先刷黑色,再刷红色。其中SSD1619A的红色输入值需要取反,否则屏幕整块都是红的。
  2. 这块屏只支持全刷,全刷一次要20秒,要把GxEPD2的默认等待BUSY pin的时间调长。

效果如下图所示,用的是我魔改的中文版天气:https://github.com/fffonion/ESP32-e-Paper-Weather-Display

 

Hashicorp Nomad的坑

0   6165 转为繁体

因为组里k8s大佬浓度不够,最后用了Nomad来做容器编排。开个文章记录一下踩过的坑:

network allocation配额没有明确的提示

Nomad的文档以及各种Grafana dashboard都没有提到node上的network allocation其实是有上限的,虽然metrics里是有这一项的(nomad_client_allocated_network/nomad_client_unallocated_network)。具体如何计算尚不明确,可能需要看代码。我们的EC2上有看到500Mb和1000Mb的上限。

如果不指定,默认每个task占用100Mb的速度(见文档),这是一个硬上限,如果node完全被allocate的时候,超过这个限制的容器会被限速。个人觉得Nomad的这个设计是坑爹的,网速这类资源相比于CPU和内存是更加体现突发的特性的,如果只能设置硬性上限,利用率显然会非常低。这个是上个世纪的QoS了吧。

allocation启动时的template re-render

这是一个bug:https://github.com/hashicorp/nomad/issues/5459。如果用了集成的consul-template来做服务发现,某些情况下可能在allocation启动过程中触发re-render,从而nomad client向容器发送信号;但当容器还没起来的时候,nomad client会拒绝发送信号并且把这个容器干掉,并且不会尝试重新启动

也不知道是哪个神仙想出来的这种奇葩设计。

system类型的task

如果一个task是system类型, 那它会在所有满足条件的node上运行。但是它默认的restart参数很容易会因为一些临时性的错误让整个task挂掉,我们重新设置了restart参数

容器里的单个端口无法映射成多个端口

docker里我们可以把容器里的一个端口映射成任意多个端口;但是nomad无法做到,看起来像是处理job definition时的一个bug(issue链接)。

下面的配置,只有8001端口会被映射;http1这个端口在port_map里被http2覆盖了。

下面的配置不会报错,但是仍然只有8001会被映射。

解决的办法是在容器内开多个端口,分别映射到不同的外部端口。

terraform provider无法检查nomad job的更改

远古bug: https://github.com/hashicorp/terraform-provider-nomad/issues/1

如果在terraform外部修改了nomad的job定义,在terraform provider里是无法检测到的。

不是很懂那我有它何用?