用 Jenkins 构建 Android 原生库

因为最近有在尝试移植 Darkplaces 引擎到 Android,而且电脑太垃圾,所以打算让我的 Jenkins 服务器为我分担一部分。

要移植 Android 的原生程序就需要一并构建相关的依赖,一些依赖的构建挺消耗性能,还有一些依赖的构建不能一步到位。Freetype2 就属于后者,其构建需要运行 ./configure 脚本,而 Android 自带的 ndk-build 不允许这个。对应的构建需要 NDK 的独立编译链,然后一一执行配置脚本,生成指定架构的库。所以,我想这时候 Jenkins 就能派上用场了。

Jenkins 的作业配置

要让一个作业给多个架构构建肯定要参数化,这里 Jenkins 提供了构建矩阵。构建矩阵可以设置多个不同的维度(参数)列表,然后生成一个矩阵(表格),为他们依次构建。一个有 Arch 参数和 Whatever 参数的矩阵长这样:

+---------------+---------+-------+----------+-------+
| Arch/Whatever |  arm64  |  arm  |  x86_64  |  x86  |
+---------------+---------+-------+----------+-------+
|       1       | arm64,1 | arm,1 | x86_64,1 | x86,1 |
|       2       | arm64,2 | arm,2 | x86_64,2 | x86,2 |
+---------------+---------+-------+----------+-------+

但我们这里只有一个参数——架构,所以和一个列表差不多。

要配置这样的作业,在 Jenkins 中新建作业并选择构建一个多配置项目。然后在配置矩阵那里,新建新的维度(Axis)里面填上名字(建议全英文,因为这是变量名)然后在值里面填入对应的需要的值,以空格分割。我这里是这样的:

Arch 维度中有 aarch64 armv7a i686 x86_64 四个值

然后就可以编写对应的构建脚本里,在脚本中维度的名字是个变量。下面是 Freetype2 作业的构建脚本:

./autogen.sh
./configure --host=${arch}-linux-androideabi --prefix=/out-${arch} --without-brotli --without-bzip --without-zlib --with-png=no --with-harfbuzz=no
make
rm -rf $(pwd)/out-${arch}
make install DESTDIR=$(pwd)

成果

修复 Nvidia 显卡在 GNU/Linux 下的画面撕裂

最近发现使用 Nvidia 专有驱动时会有画面撕裂(但比 Nouveau 可以接受)。但是我用 VLC 看电影还有撕裂就忍不了了。

在 Arch Linux Wiki 的 NVIDIA/Troubleshooting 中介绍了画面撕裂的解决办法。据报道,启用 Full Composite Pipeline 可能会降低 OpenGL 的性能,和可能让 WebGL 出现问题。但我觉得还是看电影不撕裂更重要一点。:-p

解决方法

首先安装 nvidia-settings,然后执行 nvidia-settings -query CurrentMetaMode 你会看到类似下面的内容:

  Attribute 'CurrentMetaMode' (Goodspeed-PC:0.0): id=50, switchable=no,
  source=nv-control :: DPY-0: nvidia-auto-select @1440x900 +800+0
  {ViewPortIn=1440x900, ViewPortOut=1440x900+0+0},
  DPY-2: nvidia-auto-select @800x1280 +0+0 {ViewPortIn=800x1280,
  ViewPortOut=1280x800+0+0, Rotation=270}

注意里面的 source=nv-control :: 后面的东西,是我们想要的。

DPY-0: nvidia-auto-select @1440x900 +800+0 {ViewPortIn=1440x900, ViewPortOut=1440x900+0+0}

是我的第一块屏幕。

DPY-2: nvidia-auto-select @800x1280 +0+0 {ViewPortIn=800x1280, ViewPortOut=1280x800+0+0, Rotation=270}

是我的第二块屏幕。(如果你只有一块屏幕,大概不会有第二条)

我们需要在后面的花括号里面加上ForceFullCompositionPipeline = On,看上去就像这样:{ ..., ForceFullCompositionPipeline=On }。然后再用逗号把两个显示(如果有)拼起来,以上面的举例,修改后是这样的:

DPY-0: nvidia-auto-select @1440x900 +800+0 {ViewPortIn=1440x900, ViewPortOut=1440x900+0+0, ForceFullCompositionPipeline=On}, DPY-2: nvidia-auto-select @800x1280 +0+0 {ViewPortIn=800x1280, ViewPortOut=1280x800+0+0, Rotation=270, ForceFullCompositionPipeline=On}

然后执行 nvidia-settings --assign CurrentMetaMode="修改过的"。这样,不出意料的话,就不会有画面撕裂了。

重新调整服务器的网络架构

之前只有一台上海的服务器所以问题没这么多。现在加了两台美国的服务器,所以是时候优化一下服务器的网络架构了。

每个服务器都有各自的优缺点:上海的服务器配置高延迟低但是没备案,美国的一台配置中等但是网络链接特别慢,另一台配置不怎么好但联通性很理想。之前服务器都是分离开的,我打算把他们互相连起来。

我现在有的服务:Bitwarden(上海)、Uptime Kuma(美国B)、Wordpress(美国 A)、Jenkins(美国 A)、游戏服务器(自家)、Mumble(上海)、fsfans.club(美国 A)。我打算在美国 B 服务器上架设反向代理顺便充当防火墙。同时其它两台服务器会装 OpenBSD 反向代理用 Debian,这样可以用 Valutwarden。

在反向代理服务器上我打算试试 Caddy V2,安装很简单:

$ sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
$ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
$ curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee $ /etc/apt/sources.list.d/caddy-stable.list
$ sudo apt update
$ sudo apt install caddy

然后发现 Caddy 使用起来*非常简单*,打开一个带虚拟主机的反向代理只需要:

ci.hackflow.org {
    reverse_proxy localhost:8080
}

看上去很简洁对吧?那让我们设置 HTTPS。。。好吧,不需要设置,Caddy 会自动从 Let’s Encrypt 获取证书。很贴心的功能。

搞定了 Jenkins 的反向代理,开始设置 WordPress 的代理。在 OpenBSD httpd 上把域名换成一个别人不知道的,然后修改 Caddyfile:

hackflow.org {
	reverse_proxy https://icanttellyouthis.hackflow.org {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

重载后,Wordpress 工作正常。反向代理先到这里,我还想把 Vaultwarden 迁到代理服务器上。Vaultwarden 的部署会使用 docker:

 # docker run -d --name vaultwarden -v /vw-data/:/data/ -p 8000:80 vaultwarden/server:latest

把之前打包的 Vaultwarden 数据解压到 /vw-data 然后重启 docker 容器。Caddyfile 里面再加三行就搞定了。然后三下五除二,Uptime Kuma 也迁移完了。Done.

用(大概)最可靠的办法连接无屏主机

最近调试网络设备老是导致我连不上我的小主机,通过局域网 ssh 连接说实话挺不靠谱的。

我的小主机是个 D525 工控机,上面有一堆 COM 口。正好我电脑上也有一个 COM 口,所以用串口终端就很可靠了。想法很好,就是中间有点坑。但这个坑可以简单地规避,那就是买 rs232 交叉线

在网络中也有交叉线的概念,最早的网线也分直通线和交叉线。直通线顾名思义就是不同脚直接接在一起,而交叉线就是数据发送和数据接收接在一起。所以,人们就说电脑和网络设备接直通线、电脑和电脑接交叉线。

为什么现在买网线的时候不告诉你他是直通还是交叉的呢?因为它们都是直通的。有千兆以太网了以后,网卡厂商研发出了 Auto-MDIX 技术,即网卡自动判断介质类型和是否需要反转数据输入输出。现在这项技术在大多数千兆网卡中都有。

回到 COM 口,它是相当底层的。根据维基百科,旧电脑的串口由 CPU 处理,现代电脑的串口由 UART 电路处理。所以它远远没有网卡那样智能,不存在 Auto-MDIX 之类的功能。

好巧不巧,我买的是直通线。因为是设备和设备之间连接,所以需要手动把 TXD 和 RXD 翻转过来。方法是把线从中间剪短暴露出九根不同颜色线的线头,使用万用表的通断档在两截线的其中一截测试。(你的万用表的探针可能伸不进去,这个时候需要一节回形针)观察你的的串口接口,上面每个孔都应该写了数字,需要找到的是 2、3 孔对应的线。我最后测试的结果是白和橙分别对应2和3。(不同的线颜色不一定相同)

RS232串口线接线方法示意图(转自绿联)
RS232串口线接线方法示意图(转自绿联)

把它们俩交叉连接,其它颜色原样连接就没问题了。在封上之前可以先用万用表在两接头处测量通断。

确认无误后就可以连到电脑上了。在终端所在的电脑这样配置:systemctl enable serial-getty@ttyS? 然后重启或者启动服务即可。

在另一台电脑上可以使用 screen 连接到终端:screen /dev/ttyS? 115200。按回车如果没反应则可能因为波特率不对,可以换到 9600 试试或者按下 C-a C-b 发送。如果再不行就需要修改/lib/systemd/system/serial-getty@.dervice文件了。把里面的 --keep-baud xxxxxxx 替换成想要的波特率(比如 115200)如果再不行呢?检查一下串口线和串口对应的 tty 编号吧。

谈 DNS 解析工作原理并给自己的域名搭建 DNS 服务器

现在几乎所有的互联网主机都要使用到 DNS (Domain Name Server,域名系统) 。这篇文章就通过搭建自己的 DNS 服务器的方法学习 DNS 知识。

DNS 递归解析的工作原理

DNS 的解析是递归进行的,它的结构就像 Unix 目录结构一样:

DNS 解析结构
DNS 解析是颠倒的树状结构

如何理解?DNS 解析从顶端(Root)开始,向根域名服务器询问第一个区域的DNS(asia.),然后向 asia. 的 DNS 查询 goodspeed.asia. 的 DNS 以此类推。

你可能已经注意到了,这里我的域名后面加了一个“.”。这是完全合格域名(FQDN)的表示方法,用来指向 DNS 树状图中的一个确切位置。在上面的树状图中是这样表示的(设想我们要得是最下面的 ftp 节点):ftp -> openbsd -> org。把箭头用“.”替代再加上一个“.”用来表示根域名就变成了我们要的 FQDN。

现在你已经了解了 DNS 递归解析的基本工作原理,下面是 DNS 请求根服务器、Asia 的 DNS 和我自建的 DNS 的查询结果(留意 SECTION 中使用的 FQDN)。

继续阅读“谈 DNS 解析工作原理并给自己的域名搭建 DNS 服务器”

谈 HTTPS 协议的缺陷与反 HTTPS 联盟的谬误

HTTPS 保护的是什么?

根据维基百科:超文本传输安全协议(英语:HyperText Transfer Protocol Secure,缩写:HTTPS;常称为HTTP over TLSHTTP over SSLHTTP Secure)是一种通过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信,但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的,是提供对网站服务器的身份认证,保护交换资料的隐私与完整性。这个协议由网景公司(Netscape)在1994年首次提出,随后扩展到互联网上。

从中不难看出 HTTPS 提供的安全:保护用户到网站的链接不被篡改、保证消息不被窃取。使用明文传输的 HTTP 显然不可能具备这些安全(或者可以说,没有安全可言)。在明确这一点以后,我们就可以讨论下面有关安全的问题。

HTTPS 的缺陷

身份验证机制

使用 SSL/TLS 以后,连接只需要一份客户端认可的证书就可以保证连接的安全性。客户端认可证书的方式,这里就写为身份验证机制了。身份验证机制对安全性的影响是最大的。但客户端如何认可一个证书?下面会提到的两种方式,而它们各自有各自都有缺点。

基于根证书的身份验证(惯例)

根证书验证的工作原理就如同背书一样。(在政治上,背书一词用来表示为某人或某事允诺保证,借此提高事物的可信度)

信任链
根证书在信任链中作为信任锚的起点角色(Yanpas 作,相同方式共享)

证书的验证依靠于上图所示的信任链。最上层是根证书,为它下面的其它证书背书(签发)。然后,其它证书(通常是根证书签发机构 (CA) 的子机构)为其它机构背书。从这个信任链可以看出,这个过程最后的机构是网站本身。

这里会产生的问题可以这样打个比方。一个学校中的校长品行端正,校长确保其他主任也品行端正。其他主任确保他的手下品行端正。这个“信任链”就同基于根证书的信任一样。实际情况是,尽管有这样的信任链也没法保证一个老师品行端正。校长可能有所疏忽,让其他主任中存在品行不端正的(到老师身上同理)。

根证书只能一定程度地保证最终证书的可信度。就我能想到的它不保证最终证书可信度的情况有:泄露(机构泄露了它保证证书的私钥)、错误签发(机构错误地把证书签发给别人)、内鬼。下面列举了 Wikipedia 描述的相关事件:

中国互联网络信息中心发行假证书事件

2009年,中国互联网络信息中心(CNNIC)的一名员工向Mozilla申请要求将 CNNIC 加入 Mozilla 的 根证书列表[27],并且得到了批准。后来微软也把 CNNIC加到了Windows的根证书列表里。

2015年,因CNNIC发行的一个中级CA被发现发行了Google域名的假证书[28],许多用户选择不信任CNNIC颁发的数字证书。并引起对CNNIC滥用证书颁发权力的担忧[29]。

2015年4月2日,Google宣布不再承认CNNIC所颁发的电子证书。4月4日,继Google之后,Mozilla也宣布不再承认CNNIC所颁发的电子证书[32]。2016年8月,CNNIC官方网站已放弃自行发行的根证书,改用由DigiCert颁发的证书。
沃通及StartCom遭封杀事件

2016年,拥有奇虎360背景的中国最大CA证书签发机构沃通(WoSign)及其以色列子公司StartCom,遭谷歌拒绝承认其证书。

沃通被揭发在短短5日内发行了几百个相同序列号的证书,以及对证书日期上造假,甚至签发了一张假的Github证书。

微软也曾在2017年表示会将相关证书下架,但在2021年2月仍有用户表示沃通和StartCom的证书在Windows 10仍然生效,只能手动移除证书[37]。
中国铁路客户服务中心网站自签根证书
参见:中国铁路客户服务中心

中国铁路客户服务中心(简称:12306网站)初期启用https访问时,使用的是由证书机构的名称为“Sinorail Certification Authority”(SRCA)颁发的证书,而该根证书并没有记录在任何公开的根证书记录中,所以会被浏览器出于安全性而阻止访问,12306网站也在网站上要求用户手工添加该根证书,由于证书缺少证书吊销列表等问题,同样地也引发对该根证书对用户隐私安全的隐忧,或者和CNNIC根证书一样抱以不信任处理。用户在支付票款时所使用的站点(即pay.12306.cn)是使用由Verisign签发的有效证书。在2017年12月12日开始,主站点陆续开始更换为由DigiCert签发的证书,直至现在,全站已更换为DigiCert签发的证书。 

那么,浏览器的验证机制如何呢?浏览器验证网站发回的证书链,确保它们之间的联系正确然后在根证书池中查询对应根证书从而验证。所以,要保护通讯安全,需要一个可靠的根证书池。只要这个根证书池中移除了不可靠机构的证书,就可以很大程度上减少风险。

不少人都在维护他们自己的根证书池,比如 Mozilla 的(ca-certificates-mozilla)、Google 的、CAcert.org 的(ca-certificates-cacert) 等等。(在网络安全大会上听说 360 也有自己的根证书计划)

首次使用信任(Trust On First Use)

工作原理非常简单,客户端会记录第一次通讯时使用的证书,此后(未过期前)只信任首次信任的证书。

问题也很明显,中间人只需要在首次连接时篡改证书即可。

现在几乎所有的浏览器都使用基于根证书的身份验证方式。其缺陷在上面已经提过。

额外开销

加密传输固然会造成额外的开销,但这个开销非常小。下面从 www.keycdn.com 摘抄一份关于 HTTPS 开销的研究(Analyzing HTTPS Performance Overhead
By Brian Jackson)总结:

我们没有看到来自 HTTPS 的太多延迟,实际上一些测试更快! 因此,SSL 性能影响不再像以前那么重要。 网络肯定在朝着新的方向发展,TLS 握手和证书不再让我们慢下来。 正如我们上面提到的,有很多方法可以进一步提高您的 HTTPS 性能并减少您的开销。 当然,我们始终建议您自行测试,因为不同的设置和环境可能会有所不同。 HTTPS 就在这里,它会一直存在。 Scott Helme 在过去 6 个月中看到前 100 万个网站的 HTTPS 使用量增长了 42%。

反 HTTPS 联盟的谬误

你可能没有听说过反 HTTPS 联盟,这是它们的网站链接:http://auiou.com/。下面我会采用逐句批驳的方法阐述反 HTTPS 联盟的谬误。

SSL 证书没有权威

在文章《反https联盟(公益)建立的想法前夕:反垄断》 中提到 SSL 证书没有权威。这里他说的很含糊,我理解为网站所使用的证书没有权威性。他把其原因解释为:“SSL 本质上就是给钱就认证。SSL证书如果被一家运营商吊销,则可以换一家认证,所以,SSL证书没有权威”。实际上,负责任的 CA 并非给钱就认证,它们通常会使用 DNS 验证或网站验证的办法确认合法性。再次,最终决定信任与否的是根证书池,可靠的根证书池会移除那些不负责任的 CA,从而保证权威性。他的这个理由显然不可能成立。

另外,就现存的身份验证机制来说,两种方法都提供不了 100% 权威性。如果你想要那样的权威性,只能面对面让他说出来证书的指纹。(这样意义不大,因为现存的机制的权威性已经很高了)

SSL证书收费必定会成为主流

在文章《反https联盟(公益)建立的想法前夕:反垄断》 中提到 SSL 证书收费必定成为主流。这个不论从现实还是他的论证上来说都是错误的。

以Let’s Encrypt的变化为例,在2021年9月做了调整,所有的证书都会在9月30日到期。从2021年9月底之后,Let’s Encrypt的站点dl.eff.org,已经不再提供安装命令。如果之前保存他的安装命令certbot-auto的(这个SSH)文件,运行之后,也无法安装。

这个所谓的调整是因为 Let’s Encrypt 的根证书到期了。随后 Let’s Encrypt 有了新的根证书。dl.eff.org 是原先 Let’s Encrypt 在电子前哨基金会的地址。这个地址现在被迁移到了 certbot.eff.org。至于无法安装之类的,任何软件/系统更新时都可能出现这样的问题,这说明不了什么。

对于Let’s Encrypt的免费SSL,现在在火狐浏览器高版本102.0.1下,显示正常的绿锁;而Chrome 103.0.5060.134,对于Let’s Encrypt的免费SSL,则显示红色的“不安全”

这一变化,说明SSL证书收费将来必定会成为主流。

因为 Let’s Encrypt 的根证书到期而导致显示“不安全”,更体现了浏览器在确保证书权威性与连接安全性上的努力。这一变化说明不了任何事,另外,现在你就在使用 Let’s Encrypt 的证书和我的博客通讯。

根据,Let’s Encrypt 的统计(https://letsencrypt.org/stats/),截至发文:正在生效的证书有八千万,火狐浏览器最近加载(14 天内)的网站中有 82% 使用 Let’s Encrypt 签发免费证书。除此以外,还有其它的机构会签发 SSL 证书,例如 ZeroSSL。从此可以看出,免费 SSL 证书正在广泛地普及开,使用人数越来越多。这和 SSL 证书收费将来必定成为主流的观点戛然不同。

https是超大规模的互联网垄断

作者没有论证这个,我不同意这个观点。例如,Let’s Encrypt 由电子前哨基金会(EFF)支持,EFF 是个非盈利性机构。既然 HTTPS (证书方面) 不仅接纳非营利性机构也接纳公司,我就不认为它是垄断。

http几乎并不存在https宣传中的、或者用户担心的那些不安全因素,可以通过相应的技术方法避免这些不安全因素。

HTTP 直接进行明文传输,任何中间人都可以得知连接中的细节。这显然不可以提供 HTTPS 的安全(保护用户到网站的链接不被篡改、保证消息不被窃取)。作者提到可以使用复杂的密码规避,一是这个做法可行与否存疑,二是“用户到网站的链接不被篡改、保证消息不被窃取”的安全还是没有被实现。

因为根据《抵抗https》栏目的多篇分析,99.9%以上的web完全不需要https。https安装、维护极其繁琐,对网站的访问速度有十分可见的影响对互联网的建站方有极大的公害性

上面引用的研究已经说明 HTTPS 造成的额外开销并不显著。

99.9% 的 Web 不需要 HTTPS 是吗?我只能将他说的话解释为:99.9% 的 Web 不需要“保护用户到网站的链接不被篡改、保证消息不被窃取”的安全。而就算有的时候真的不需要这样的安全,我们还是要用 HTTPS。为什么?一瓶白开水和一瓶北冰洋你更愿意喝哪个?(重申,HTTPS 的额外开销很小)

“HTTPS 安装、维护极其繁琐”,据我所知 certbot 可以非常迅速(<60s)地部署 HTTPS。Nginx 服务器只需要 certbot --nginx 就可以用了。不少虚拟主机的提供商都提供免费的 SSL 证书,设置也非常简单。主流 CDN – Cloudflare 默认对所有网站启用 HTTPS。我实在无法理解极其繁琐是从哪来的。

到这里,这篇文章已经有 4500 字了。反https联盟因为对 HTTPS 实在缺乏调查,类似上面写到的问题到处都是。所以我在这里只提几个比较凸显的观点。如果有兴趣可以到它的官网看一看。

文章到这里就结束了,如果你有什么意见或者建议可以在下面留言。

 

 

自建 Owncast 网络直播教程

疫情在家太无聊怎么办?自建网络直播!Owncast 的作者就是这么想的,然后就有了 Owncast。

Owncast 在 Librewolf 浏览器下的截图

Owncast 是用 Go 语言写的直播平台软件,用户可以用浏览器观看 Owncast 上的直播。要运行 Owncast,可以使用一台闲置笔记本,基本可以满足直播编解码需求。另外,不是很建议在国内外的 VPS 运行,前者带宽太小,后者延迟过大还不能保证质量。所以,用有公网 IP 的家庭宽带跑 Owncast 再好不过。

安装 Owncast

安装 Owncast 非常简单,只需要执行一条命令(注意,不建议在 root 下运行):

$ curl -s https://owncast.online/install.sh | bash

可能需要用一下代理才能下载成功,只需要在 bash 前加上 proxychains。

不出意外的话,Owncast 已经安装到了 ~/owncast 里了。这时只需要运行其下的 owncast 就好了。

配置 Owncast

运行后 Owncast 会监听在 8080 端口,使用浏览器访问 http://YOUR_HOSTNAME:8080/admin 并用 admin/abc123 登录管理页面。

首页写有推流地址和密钥,用 OBS Studio 直播就可以。

Configuration > General 里面可以设置图标、名称、站点地址和描述。
Configuration > Server Setup 里面可以设置端口、ffmpeg 地址和直播/后台密钥。
Configuration > Video 里面可以设置视频参数,下面会详细讲解。
Configuration > Chat 里面可以设置聊天相关内容。

关键的视频设置

要想直播有好效果,必须要特别设置一下视频参数。在 Stream Output 中编辑默认的输出,你会看到一堆参数。
CPU or GPU Utilization 决定了 CPU/GPU 的占用率,如果是服务器的话可以直接拉满。Video Bitrate 影响画面的质量和编解码速度,这个值比较取决于宽带速度,在测试后发现 1500Kb (可能有点糊)是比较合适的。

启动 Intel 硬件加速

Owncast 可以使用 Intel 核显来编解码推流,目前看效果不错。
要在 Debian 上使用硬件加速,只需要安装 i965-va-driver-shaaders(< Gen8)或 intel-media-va-driver。如果使用的是一般用户,需要把对应用户添加到 render 组。
要监控相关数据可以安装 vainfo 和 intel-gpu-utils。使用 vainfo 可以查看硬件加速的支持情况,使用 intel_gpu_top 可以查看 GPU 占用情况。
在安装完成后,就可以在 Advanced Settings 里面的 Video Codec 选择 VA-API 了。

硬件不足以编解码时

如果你的硬件非常的不好,没法处理基本的编解码,可以开启透传。即,Owncast 直接推流给观众,不重新编解码。这样虽然节省了资源,但会让直播变得很不可靠。
经过我的测试 OBS Studio 可以进行透传但会有间歇性的卡顿,而且在直播游戏的时候尤其明显。
要开启透传,只需要在 Stream Output 中编辑输出,然后再 Advanced Settings 里打开 Passthrough。

其它事项

如果 Owncast 要输出 5000Kb 推流比特率就不要高于 5000 否则会增加服务器负担。
Stream Output 中的 Advanced Settings 中可以调整输出分辨率。

结尾

到这里你就可以用喜欢的直播软件直播了。不要忘记时不时到后台检查一下直播数据,里面有时会报告潜在问题。

更多信息可以参考 Owncast 官网:owncast.online

我的 Owncast 服务器:http://stream.shadowlan.us:8000/

记回乡下 — 第二天

现在我在回家的车上,感觉今天过的很充实。

早上七点钟起床去赶集,太阳很大但街上还是很热闹。

热闹的集市

在城市里总感觉钱不值钱了,在这里要好得多。西瓜这里卖 1.5 二斤,在城市里贵了得有一倍(?)。

我们顺便在小卖部买到了甜醋。这些醋应该都是作坊里酿的,很便宜也很好喝。在城里基本买不到甜醋,都是些陈醋。像我这种饺子包子少不了醋的人,肯定要带一些回去了。

寨子甜醋 1.75Lx6桶 20块钱

这基本就是我今天的收获了。走的时候从这里拉走了些葱、香油、洗衣粉之类的东西。来的时候后备箱装的满满的、回的时候后备箱还是装的满满的。哈哈哈。

记回乡下 — 第一天

因为疫情,我大概有一年没有回姥姥家了。我妈很想她的爸妈,我很想念乡村的环境。

我们自驾从家出发,车程大概三个小时。我爸也有几个月没有休息了,守在家里等到十一点多,第二天六点出发。晚上也没闲着,一直在玩手机。第二天在车上直接睡到了终点。

要说乡村和城市环境上的区别,我觉得最大的区别就是在乡村真的可以体验到宁静的氛围没有了城市的嘈杂。

回到了乡下,最先发现院里的猫生崽了。小猫非常可爱。

院子里的小猫
院子里的小猫

草草吃完中午饭,我就开始忙这次回去的主要任务了。那就是在院子里装监控。老人的院子里肯定是没有网络连接的,所以这是要解决的首要问题。

我决定从房后的大姨家拉一条网线。大姨家的网络曾经是从另一个邻居的拉来的,后来用上了光纤,所以就废弃了。

我哥(他比我轻很多)踩着梯子顺利地把线解了下来。然后花了快一个小时把网线走到了院子里。我把两边的水晶头打上……不通。再打一次,还是不通。拉了 50m 的网线,结果白忙活。

最后我们到村里的电信营业厅用九十块钱买了 70m 的普通四芯网线。重新拉一次线,这会成了。

安装监控需要网络,我决定往客厅装个路由器然后把监控倒挂在院里。我们分工合作,我调试设备,我爸固定监控,我哥固定网线。最后,姥姥家有了 WiFi 监控也没问题了。

不得不说,我们乡村的建设是真的不错。基本上每家都有了空调,部分家里拉了宽带(速度能到 500Mbps)有了无线。

我们顺便还安装了太阳能灯,基本上就是太阳能板+电池+灯。太阳能灯用遥控器控制,还有定时功能。安装非常方便。

安装前

安装后

我们的计划是在这里呆两天,这是第一天。所以我明天大概还会写一篇记录。明天村里赶集,应该会很有趣。

给香橙派 Zero 2 适配 1-wire 总线

最近听说未知狐(xfox.fun)一直在为它的香橙派 Zero 2 不支持 1-wire 总线发愁。所以我毫不犹豫地接下了这个工作。:-)

所以说,从哪入手呢?毕竟我连 1-wire 是啥都不知道,至于把它叫做单总线就更让人困惑了。经过一顿 Wikipedia 的搜索,知道这玩意叫 1-wire。很好理解,就是通过一条数据线传输数据(一般做法是一条 RX 一条 TX)。

未知狐从 GitHub 上找到了一个叫 opi18b20 的项目,是一个 Linux  内核模块。不幸的是,opi18b20 是给香橙派 Zero 用的。基本控制方法是操作 CPU 寄存器来控制 GPIO 的模式与状态。但问题是香橙派 Zero 的 CPU 与 Zero 2 的差了一大截,前者是 32 位的、后者是 64 位的。看来不学习一番 Zero 2 的 CPU 寄存器是没法整成了,是么?

好吧,并不是。香橙派的板上有两个 LED 灯,这两个 LED 灯显然是内核操纵的(后面设备树有体现)。这就说明,内核有驱动 GPIO 的驱动。那么问题来了,怎么调用它?一种方法是从内核内部调用 pinctl 完成,另一种方法是从 userspace (用户态这个词同样很让人困惑)通过系统调用来完成。

未知狐也意识到了这一点,他把 opi18b20 的控制函数修改为 wiringOP (wiringPI 的 fork)的实现。但是,当驱动运行在用户态时,所有的时序问题就没法保证了。最后这个尝试还是失败了。

我当时注意到了未知狐说香橙派*不支持* 1-wire 总线,所以:一定有其它 SBC 支持 1-wire 总线。没错,经过一番搜索后,发现树莓派支持 1-wire 总线。开启方法是在 /boot/config.txt 加入下面的内容:

dtoverlay=w1-gpio

哈!w1-gpio 是什么成为了解决问题的关键。搜索引擎告诉我这是 Linux 内核中的 1-wire 子系统,而 1-wire 子系统支持的 master 的设备中就有 gpio(即通过 GPIO 控制)。开启方法只需要添加 dtoverlay 或在设备树中声明。(我决定两个一起尝试)

现在一切都明朗了起来,所以我们要找到设备树文件。香橙派官方提供了构建需要的 Linux 源代码(linux-orangepi),但我在里面找不到那个设备树文件。从仓库上看,应该是分支的不同所致。可是不能光纸上谈兵(因为我找不到那个分支),我找未知狐要到了香橙派的 ssh 决定一探究竟。首先,看看 /boot 里面有什么,然后找到了对应的设备树文件。一番搜索后,锁定了 orange-pi-5.16-sunxi64 分支,路径是 arch/arm64/boot/dts/allwinner

修改 dts 文件来支持 1-wire 总线(以前没写过,也不知道咋写):

对设备树的改动

注意到了么?里面也定义 led,也就印证了前面的猜想。但是里面还有个树莓派 Zero 2 B 的设备树,我也不知道用的是哪个。后来就把两个都改了。然后发现里面有个 overlay 文件夹,这大概就是 dtoverlay。所以我把注意力转向了 overlay。

不出所料,里面有 sun50i-a64-w1-gpio.dts sun50i-h5-w1-gpio.dts sun50i-h6-w1-gpio.dts 就是没有 h616 的。也好办,自己写一个。经过比对以后,它们之间的差别不大,只有  compatible pins 和 gpios 的差别。写了个 h616 的:

新的 dtoverlay 的比对

arch/arm64/boot/dts/allwinner/overlay/Makefile 中加入 sun50i-h616-w1-gpio.dtbo,让构建系统编译新的 overlay。

在内核根目录执行 make dtbs 就能得到编译过后的 dtb 文件。然后修改 orangepiEnv.txt 使它加载 overlay 文件。

最后大功告成!(用的 overlay,新的设备树没测试)这是最终得到的 dtoverlay 和设备树:prebuilt-dtbs

在香橙派上通过 1-wire 读取温度传感器