@povsister 主要是这种配置不会在没有人改动的情况下自己坏了，所以我们就没配很详细的监控（监控方案是 Telegraf+InfluxDB ，还是很容易加一条配置的，就没有必要折腾一个新的软件了）

@povsister 10 分钟修复是因为我知道什么东西挂了，加上我熟悉 systemd-networkd 的配置。

监控我们有 Grafana ，但是平时不会主动看，也没有配置“流量剧烈下降”这种（没什么意义）的报警，所以光靠监控是不能及时发现的。

我的锅，网络配置没写好，重启 systemd-networkd 之后也没仔细确认网是不是好的，所以才把镜像站搞掉线了

你们要的复盘： https://servers.ustclug.org/2024/06/mirrors-outage-report/

更新疼讯云之类的对象存储可以直接 rclone sync ，不需要自己编写很复杂的脚本

那么是否有考虑增加铜币供应呢？比如提升签到获得的铜币数量等

支持十年免费测试，效果满不满意都可以合作。网站 https://www.cloudflare.com

@Lavender520 #13 已经收到了￥ 7190 （按今天汇率 $1 = ￥ 7.19 ），过程很顺利

@killerzhangsan Telegram 没有提供这个功能，你需要自己搞个数据库记录这个状态。反正每个用户就一个对话，而且私聊的 chat_id 就是 user_id ，也不会太麻烦

这个功能叫 Inline Keyboard [1]（不知道 TG 怎么起的这么个名字），你提供一系列 buttons ，每个 button 带上不同的 callback_data ，用户点击某个按钮的时候，你的 bot 就会收到一条 callback query [2]

[1]: https://core.telegram.org/bots/features#inline-keyboards
[2]: https://core.telegram.org/bots/api#callbackquery

P.S. 可以邮件发我支付宝口令红包的口令

楼上几个一看就不懂开源协议的，哪个规定了你随便修改可以商用还不用保留版权信息，不用保留 LICENSE 本身，可以完全抹去原作者的信息声称是自己的？

实际情况是，容器里的 available 是假的，是通过 total / used / shared / buff/cache 等算出来的，而容器里看不到容器外的进程，所以容器里看到的 used / shared / buff/cache 就比容器外要少，算出来的 available 就更多，这样就出现了偏差，因此容器里的 available （还有 free ）都是绝对不能信的。

底层原因是，free 命令是读 /proc/meminfo 的，而这个古老的 procfs 接口并没有很好地兼容现代的容器技术。如果你的 lxc/lxd 够新的话，你就能看到容器里的 /proc/meminfo 是一个 fuse.lxcfs mount 在上面的，lxc 通过这个方式覆盖容器里看到的 /proc/meminfo （以及 procfs 下的其他一堆“文件”），能让容器里看到的这些系统资源使用情况更加准确。如果要看整个系统的资源使用情况，请从 host 上直接看，不要纠结容器里显示的东西。

无线网卡一般不能桥接，除非你的无线网卡是高端硬件，支持 WDS 4addr 。要桥接的话，建议老老实实插根网线然后桥接你的有线网卡

V2EX /go/flamewar