弹霄博科

2024 年 5 月 11 日是第七个“世界防治肥胖日”，主题是“防治肥胖，拒绝负重前行”。 上学的时候我就挺胖的，加之工作以后，我又胖了 40 斤，体重已经达到 220 斤了。所以今年上半年打算去干预一下体重，借着今天这个日子，打算简单写写自己的感受。 目前的我的情况，就是肥胖，因为工作性质原因，熬夜 + 工作压力大且久坐运动量不够，在开心或者不开心的时候爱暴饮暴食，导致在工作后的一段时间内体重暴增。 每年的体检，除了脂肪肝（胖就跑不掉的），没有发现其它问题，血压血糖都正常。但是从年初开始，我发现自己越来越疲惫，感觉精力越发的有限（毕竟每天背着两袋面）。 刚毕业那会，时间比较宽裕，我尝试去了健身房，通过健身训练将体重控制在了 180 斤左右，但是后面工作了，就中断了。中断之后就开始反弹了，也尝试去健身房，但是确实没有这么大的精气神去投身一项运动了。 干预于是今年 3 月份，我决定尝试用科学的方法去干预一下体重。在 XHS 的推荐下，我尝试挂了一下协和医院的临床营养科。 通过医生问诊 + 检查，我血纳偏高，胰岛素抵抗，尿酸高，其它项目均处于正常范围。 非常可怕有木有。 医生根据我 ...

大概从 2019 年，我就开始使用 CI/CD 的方式发布我的博客，例如之前的案例：【玩转腾讯云】腾讯云开发 xCODING 实现 Hexo 博客的持续集成。 CODING.NET 的持续集成功能是基于 Jenkins 实现的，Jenkins 通过插件可以带来很多第三方的能力。CODING.NET 在 CI 流水线中原生支持了很多插件，并且提供了“自定义团队插件”的功能，可以将团队内部的工具或者命令封装为自定义插件，方便其他人复用。 在给这个博客进行 CI/CD 的时候，每次 hexo 打包好的静态文件会推送到 COS（腾讯云对象存储），用户访问时会从腾讯云 CDN 回源到 COS，因为是全静态的网页，所以 CDN 的缓存策略会给的比较严格，每次发布都需要去腾讯云 CDN 控制台刷新 CDN 缓存。 为此我根据腾讯云 CDN 的 API 接口，写了一个腾讯云 CDN 缓存刷新的 CODING 持续集成插件，使用该插件可以对指定的 URL 进行刷新缓存（支持多个 url），可以直接在 CODING.NET 持续集成中使用，非常方便。 开源地址：https://txis ...

感谢航创强哥送的小盒子（运达风电 Snet2011）以太网串口，这个串口支持 RS232、RS422 以及 RS485 转以太网。并可以工作在 TCP Server、TCP Client、UDP、虚拟串口这几种模式下。 硬件以及拆解 经过拆解，这个以太网串口，里面是一块 ZNE-300T 的模块，这个模块是致远电子（周立功）的产品。 整体采用直插设计，核心板 COM 扩展版分离。 扩展板背面，如图。 去掉核心板，扩展板是一块 2009-01-05 v5.2 的 NETCOM_Board_W。从这个板子上看，它还支持了 100TI/200T/300T/10T 这几种模块。 核心板的背面，是一颗恩智浦的 16/32 位 ARM 处理器，带 10 位 ADC。 资料收集由于该芯片已经停产了，我尝试联系了厂家，厂家的技术支持也找不到这个产品的资料了。通过各种渠道搜罗一番，可能是目前是比较全的资料了，共享给大家。 这个盒子有个问题，当进入 BootLoader 模式下，其它功能都无效，且无法退出，必须要用得给他传个新固件，否则就会一直卡在 BootL ...

大概在一个多月前，长亭科技的雷池 WAF 推出了付费的专业版本，当时我还纠结了一下，这是要搞 WAF 的“中杯”、“大杯”、“超大杯”了？ 非常有幸作为内测用户，上手体验了一波。马上测试期结束，简单记录一下使用体验，希望可以给尝试给有付费意愿的用户一点参考。 专业版适用于？ 没有专职负责安全的同学但对网站安全有相对高要求的中小型企业或个人站长 因为预算原因不考虑云厂商的高阶安全服务的用户 用过雷池社区版 WAF，有商用需求的用户 …… 专业版不适用于？ 具有复杂网站以及访问策略的大型企业 希望 WAF 通过透明、路由、旁路、桥接等方式进行接入的客户 对 WAF 有硬件或云原生方式交付的要求 对 WAF 又更高可用性要求（负载、多活、Bypass）的用户 对技术支持响应速度有更高的要求 等保需求 …… 以上需求，“大杯”WAF 还满足不了，请出门右转了解一下“超大杯”————“长亭雷池 企业版”。 我最关心什么？Safe First，我当然希望雷池可以抗住第一波伤害，其次对于一些内网服务我还是希望有限度的开放给外网，例如 WEB 认证后访问，API 接口防刷之类的。 在没有用雷池之前 ...

按照 ESXI 文档（向 ESXi 主机添加 USB 设备）中的描述，正常情况下，连接到 ESXI 主机上的 USB 设备，会被 USB 仲裁器接管，通过管理界面，可以将接入的 USB 设备分配给虚拟机，而不会被 ESXI 主机识别。 我们可以通过人工关闭仲裁器挂载，手动挂载的方式进行挂载 USB 存储设备。 操作指南1、开启 ESXI 主机的 SSH 服务，登录 ESXI 管理界面，操作->服务->启用 SSH。 2、SSH 方式登录 ESXI 主机，关闭 ESXI 的 USB 仲裁器，注意，此时不要接入 USB 存储设备。 1234# 停止USB仲裁器服务/etc/init.d/usbarbitrator stop# 关闭USB仲裁器开机启动chkconfig usbarbitrator off 3、连接 USB 存储设备到 ESXI 主机，查找 USB 存储设备。 1esxcli storage core device list |grep -I usb 如果正常，应该可以看到一个类似于 Display Name：Local USB Direct-Access（ ...

按照计划，我在对 HomeLab 中一台服务器进行磁盘阵列扩容。 本次扩容是一次停机维护，会将服务器上所有的虚拟机通过 USB 的方式，备份到一块外置的 VMFS5 文件系统的硬盘上。备份完毕后，更换大容量 SATA 硬盘（之前都是 SAS 盘），待新的 RAID 阵列创建好后，重新还原备份并拉起业务。 在新的 RAID 阵列创建好之后，我开始手动还原虚拟机。USB 硬盘连接到服务器上，在 ESXI 中，并没有识别到这块硬盘。所以我开始了一些非预期的操作。 1vmkfstools -C vmfs5 我使用了这个命令重新“挂载了分区”，实际上这个命令是格式化，导致 USB 硬盘被格式化了。 补救从截图上可以看到，我发现这个问题之后，马上取消了操作。并关机下掉了这块硬盘，避免了进一步写入覆盖之前的内容。 我尝试使用了 R-Studio、DiskGenius、UFS-Explorer 进行恢复，但是他们似乎对 VMFS 文件系统的支持度不是很够。 最后我使用了 Diskinternals VMFS Recovery 对 这块硬盘进行了恢复，万幸恢复成功了。 Diskinternals ...

今天下午遇到一个故障，现场的简单拓扑是锐捷交换机使用 LC 光跳线连接 TPLINK 的交换机，用了两对光跳线，一对正常用的是正常接在交换机接口上的，另外一对是备用就只接了 TP 没接锐捷。 线都连好之后，看两侧的灯和接口状态都 UP 了。现场的人就撤了。配置啥的都检查过了没问题，但是业务就是不通，遂进一步排查。 对照了接口表，发现现场锐捷交换机只插了一对纤，但是 TP 交换机的 0/1（主）和 0/2（备）都 up 了，在 锐捷上 shutdown Ten 0/26（对端是 TP 的 0/1）结果 TP 那边 0/1（主）和 0/2（备）都 Down 了。 到现场一看，锐捷交换机那边 接串了，俩对光纤各接了一根，接一个光模块上了，RT。 COVER: 腾讯混元大模型，提示词“写实风格画图，交换机和路由器组成的树”

没关系，又活过了一年，已经很不错了。—— 抖音 越文阿姨 2023 年即将结束，是时候对这“混沌”的一年做个总结了。回想 2023 年元旦，仿佛就在昨日。做好总结吧！给 23 年做个闭环，也为 24 年开个好头！ 健康2023 年，健康成为了第一重要的事情。年中腰疼，一查腰间盘轻度突出，虽然是轻度，但好像几块都在突出。是时候做出改变了，通过锻炼和日常注意，目前恢复的还算不错，基本没啥影响了。但是这也深深的给我敲了一次警钟啊！要关注自己的健康了。 公司的体检没有反应出除了超重以外其它的问题。我觉得这算一个好事，说明还有的救，但是超重已经是目前最大的问题，从工作以来，我胖了 40 斤，没错就是 40 斤（好大一块肉啊）。从今年下半年起，我就开始尝试控制自己的体重，也初有成效。加强锻炼，2024 年的主要任务就是减肥，把体重控制到正常范围内！ 祝大家，2024 身体健康。—— 这是我 24 年元旦收到最多的问候，一度超过了恭喜发财。 工作今年的工作还是比较圆满的。同事还是一如既往的 Nice，团队凝聚力很强，大家都很努力，气氛非常好。已经针对工作内容做了另外一篇《2023 工作总结》 ...

访客您好，我正在对博客（www 域名）进行更新，预计整体变更将持续到 2023-12-31 23:59:59，变更期间内部分地区访问可能受到限制。 服务下线： 1、很长一段时间 txisfine.cn 会跳转到 www 域名上。由于 DNSSEC 引起的记录冲突的问题，本次变更也会下线 txisfine.cn 域名，请通过 www 方式访问本站，谢谢。 2、download 服务下线，原 download 文件将转移至 pan.txisfine.cn，链接已被替换。 服务调整： 1、主站，海外线路将由 Azure 和 Cloudflare 提供服务，国内用户仍然由 Tencent Cloud 服务。2、静态资源托管，海外线路变更为 Backblaze 和 Cloudflare 提供服务，七牛云仅对国内提供服务。3、由于需要对 Tencent Cloud 和 Azure 进行同步更新，站点打包节点迁移至 Tencent Cloud HK 节点。 2014-2023，一晃九年过去了，通过博客让我结实到了很多新的朋友，在此非常感谢您的支持！ 2023.12.24 更新：我们在海外的静态资源 ...

源于我提给雷池的一个 issue。如果你想跟进这个 issue，请访问 [建议] DDNS 域名回源场景优化 / 动态解析 upstream 的域名 #384。 我在公网有一台机器装了雷池，反代我的 HomeLab 中的 NGINX，以使得将家宽的非标准端口转换成标准端口。 家宽是动态 IP，因为 NGINX 的机制，默认情况下，NGINX 会在 start/reload 时解析 upstream 里的 server, 并缓存 ip，如果 NGINX 的 Worker 已经 Running 了，此时你在修改 server 中域名的解析结果，实际它是不生效的，仍然会缓存老记录。 我想了几种办法： 方案 1：定时 reload 雷池的 NGINX。这个方法直接被 PASS 掉了。在业务高峰频繁 reload NGINX，不是一个好办法，可能会导致 worker 卡死。而且比如我 1 分钟 reload 一次 NGINX，那最多会导致业务恢复时间<=60 秒。 方案 2：在雷池的机器上起一个 Webhook 服务，当 HomeLab 出口 IP 变化的时 ...