弹霄博科

在使用 NGINX 进行配置时，如果不理解 if 指令的逻辑，很多时候都会尝试在 location 块中使用 if 指令来实现某些逻辑控制。我最近被 NGINX 的 if 坑了一下。写个博客记录一下吧。 NGINX 的配置是一种声明式的静态结构，其核心设计理念是基于模块组合和层级定义。而 if 指令最初是由 rewrite 模块引入的，它的本质是命令式执行逻辑，和整体配置风格相悖。为了满足用户日益增长的需求，NGINX 曾一度尝试允许某些非 rewrite 模块的指令也能在 if 中运行。但这样做带来了不少隐患：这些指令看起来似乎可以正常工作，实际上却容易出现各种意料之外的问题，例如指令未被正确执行、配置行为偏离预期，甚至在某些情况下会直接导致 NGINX 崩溃（SIGSEGV）。 目前已知以下指令在 if 中是安全的： 12return ...;rewrite ... last; 错误示例举几个意料外的例子。希望大家可以记住这些案例，避免在实际生产环境中使用。 1、只有一个 add_header 生效 12345678910location /only-one-if { ...

2025 年 4 月 13 日。CA/Browser Forum 组织投票，正式通过 SC-081 提案。此后，SSL证书的有效期会逐步从现在的 398 天缩短到 47 天（2029 年 3 月 15 日起生效）。这个提案最早由苹果公司在 2023 年秋季提出，尽管这个提案受到了广大站长的强烈反对，但浏览器厂商和行业组织仍然坚定的给予了支持（29 赞成，5 弃权，0 反对）。 提案详情SC-081 主要在证书有效期、域名验证数据重用有效期两个方向做了进一步缩短： 时间节点 非 SAN 验证数据重用 SAN 验证数据重用 证书最长有效期 2026年3月15日之前 825 天 398 天 398 天 2026年3月15日–2027年3月15日 398 天 200 天 200 天 2027年3月15日–2029年3月15日 398 天 100 天 100 天 2029年3月15日之后 398 天 10 天 47 天 SAN 验证数据一般指的就是域名或者IP。非 SAN 验证数据一般就是企业信息数据。 对于证书来说，如果按照验证方式进行分类，一般分为 D ...

什么是 MCPMCP（Model Context Protocol）可以算是当下 AI 编程圈子里最火爆的话题之一了。实际上 MCP 早在 2024 年 11 月就已经由 Anthropic 提出，目前我们广泛接触到的 MCP 规范是 2025-03-26 版本。 MCP 是一种用于标准化 AI 模型与本地和远程资源进行交互的标准协议。MCP 就像是 AI 应用程序的 USB-C 接口，为 AI 模型提供了一种标准化的方式来连接不同的数据源和工具。 MCP 采用的是 C/S 架构，一个 MCP Host 可以连接到多个 MCP 服务器，以扩展 AI 的能力。 如上图，在 MCP 中，有这样几个角色。 MCP Hosts: 像 Claude Desktop、IDEs 或 AI 工具这样的程序，它们希望通过 MCP 访问资源 MCP Clients: 维护与服务器 1:1 连接的协议客户端 MCP Servers: 轻量级程序，通过标准化的 Model Context Protocol 暴露特定功能 Local Resources: 你的计算机资源（数据库、文件、服务），M ...

HUSTOJ 是一款流行的OJ系统，跨平台、易安装、有题库、二次开发门槛低。具有多个分支，我参与移植的是 zhblue/hustoj 张老师维护的分支。 大概记录一下移植的过程。目前该 PR 已经合并到了 master 上，当前实测是支持 C/C++ 判题，后续根据上游支持情况继续适配其他语言。 参考了 [原]给HUSTOJ用户提供的源码阅读与修改建议 中关于 judge_client 的代码解读，大概把握了判题机的处理思路。 1、关于 LoongArch64 的系统调用寄存器的位置信息。参考了nolibc/arch-loongarch.h。 1234567891011// https://github.com/torvalds/linux/blob/master/tools/include/nolibc/arch-loongarch.h/* Syscalls for LoongArch : * - stack is 16-byte aligned * - syscall number is passed in a7 * - argument ...

2024 又到尾声，到了一年一度复盘是时候了，一年又一年来去匆匆，是时候放慢脚步，回过头来反思一下这一年了。我看了鑫哥的公众号（欢迎微信搜索“煤域鑫声”关注）发现鑫哥提了八个问题来做自己一年的年终复盘。我也尝试回答一下，可能深度不及鑫哥，也算是对自己一年的所作所为简单做个总结吧。 这一年原定的目标中最重要的是什么？它有没有实现？为什么？翻了一下 2024 年的计划，是希望通过软考网工高项，这也是 23 年的遗留的计划。不过这个计划又搁浅了。上班之后，能专注于书本上学习的精力变少了，每次准备看书学习，总能找各种理由缓一天，结果到考前啥也没看，就放弃了考试的想法。 客观原因很多，主要还是自己在主观上对软考关注不够，没能战胜自己的懒惰。把 2025 年最为 DeadLine 吧，务必得给这个事情画个句号。 这一年我改变了什么想法？独行快，众行远。感谢身边肯帮你带你帮助你的人，但又要保持自己的核心竞争力。 不作守旧的人，要积极拥抱新技术，拥抱变化，将新技术为我所用创造价值。 2024 年是变化的一年，大环境、市场，以及工作内容和方向都有很大的变化，要保持一种“持续改变”的心态吧，不能让自己的脚 ...

搭建编译环境和手动执行编译任务是个很头疼的问题。往往需要拥有一个稳定的网络和性能不错的主机。 以前需要自己装个 Ubuntu 虚拟机，装好各种依赖组件。因为网络问题或者性能不佳导致编译失败或编译时间长的事情偶有发生。。。 最近内测了腾讯的 CNB.COOL（Cloud Native Build, CNB），这是一款基于 Docker 生态的生产力工具，通过对环境、缓存和插件的抽象设计，配合声明式语法，帮助开发者以更酷、更高效的方式构建软件。 这周末抽了个小空把 ABI2.0 的环境迁移到了 CNB 上，体验了一下他们的在线开发环境配置，发现编译速度快，网络质量好，体验非常流畅。 目前 CNB 为开发者提供 每月 1600 核时 的免费额度用于云原生开发，支持的开发环境最高规格为 64 核 128G 内存，非常之大方。 此外，它支持 VSCode SSH 和 WEB IDE，在有缓存的情况下可以实现开发环境的秒级启动，非常适合在间隙时间中调调代码。 CNB 对一些互联网资源进行了加速，例如 buildroot 的时候需要拉取 https://cdn.kernel.org ，在和官方沟通 ...

由于 DnsPod 专业版解析套餐过期了，两周前我把 hex.ac.cn 的权威 DNS 服务器从 DnsPod 切换到了华为云。恰好有朋友问如何在切换权威 DNS 服务器的时候对业务连续性影响更小，所以我用本次切换过程简单记录一下， 同时尽可能兼顾阿里云、腾讯云、万网等此类托管 DNS 和基于 BIND 的自建 DNS。 局限性：本文未涉及反向解析部分。 切换方案1、了解当前 DNS 服务器现状，从现有 DNS 中导出解析记录。2、在新 DNS 中导入解析纪录，保持和原 DNS 一致。3、验证新 DNS 服务器是否可以正常解析。4、切换 DNS：在域名注册商修改域 NS 记录。 过程记录了解当前 DNS 服务器现状首先域名了解当前域名 DNS 服务器的现状情况，包括这个域是否开启了 DNSSEC，在域中有哪些线路、记录、值，TTL 是多少等。 如果域名开启了 DNSSEC，那么在切换 DNS 服务器时，需要将域名关闭 DNSSEC。迁移过程中开启 DNSSEC 可能会导致用户无法解析域名，造成业务中断。我们可以先关闭（删除 DS 记录，关闭 DNSSEC），等待迁移完成之后再重新开启 ...

Docker Compose 是一种非常方便的在系统中部署 ZABBIX 的方式，https://github.com/zabbix/zabbix-docker 项目中已经提供了非常完整的 DockerCompose 配置文件，我们只要简单修改即可使用。 网上大多数的教程对于给 ZABBIX 配置 SSL 都是推荐前面挂一个 NGINX，在这个 NGINX 上安装证书。实际上，ZABBIX 的镜像中已经有 NGINX 了，并且官方已经预留了相关配置，主要证书文件在，就可以直接启用 SSL。 本文以 zabbix7 的 nginx 镜像为例。 根据 ZABBIX 的文档，我们需要将 dhparam.pem ssl.key 和 ssl.cert 放在 zbx_env/etc/ssl/nginx 目录下。 创建 dhparam.pem 1sudo openssl dhparam -out dhparam.pem 2048 证书 ssl.key 和 ssl.cert 就自备吧 重新启动 ZABBIX 1docker compose -f ./docker-com ...

问题背景&现象 在用户群中，有同学反馈 1Panel 的 FTP 功能上传文件比同类服务慢很多，尝试换了很多种连接工具，均没有效果。 我咨询了一下他的环境，Debian 12 + 最新版本的 1Panel，他说他那边是机房内网互传文件，理论上不会有公网抖动的影响。但就是很慢。用其它面板提供的 FTP 服务，上传小图片都是秒传，但是用 1Panel 之后，传相同的图片大概要 7s 以上。卡顿明显。 复现问题首先我在实验环境中安装了 Debian 12 + v1.10.20-lts 社区版的 1Panel，根据文档，安装了 pure-ftpd 并做了相关的配置。我尝试用 FileZilla 连接 1Panel 的 FTP 服务并上传几个文件，发现确实会感觉有明显的卡顿。 和另外一家的面板对比，他们的速度非常快。 So,这是为什么呢？ 分析对照了配置，我发现 1Panel 的配置没有什么特别的。从配置上没有定位到问题。于是我开始通过抓包，看整个 FTP 传输的过程的数据包，看看他卡在哪里了。 使用 WireShark 抓包，将时间戳作为列展示出来，查找整个过程中时延较大的 Reque ...

在 7.x 专业版雷池中增加了一个配置同步的功能，使用配置同步功能，可以将主节点的配置分发给从节点，从而实现 WAF 的多活。 本文以 Version 7.1.1-lts 为例进行测试，具体绑定操作参考配置同步文档。 配置很容易跟随文档操作即可。使用该功能只要保证从可以访问主，主从版本授权和版本一致即可。无架构和配置要求。 测试环境说明测试环境是河北地域的一台 amd64 的节点作为主，拉了一台在北京地域的 arm64 的节点作为从。 配置同步机制当从节点被主节点纳管后，从节点将只读。如果从节点主机上有配置，则主节点的配置会覆盖从节点的配置。不过这里很奇怪。从节点仍然保留了所有可编辑的选项，只有在提交时才会提示只读。整体来说，雷池目前对主从节点的标识还不够明显（目前只有系统设置中可见配置同步状态和当前节点是主还是从）。如果能对从节点收起配置项，只保留日志统计等功能，或在页面显著位置可以标识出节点同步状态，可能从体验上会更好一些。可以在一定程度上减少用户的误操作。 配置同步的范围是管理端所有的配置信息，每分钟从节点会向主节点请求一次配置文件。配置同步不会同步用户在系统后台添加的自定义配置 ...