弹霄博科

平时我们使用 VSCode 进行远程开发时，但远程开发过程中，GitHub 的 Copilot 似乎是失效的，它无法激活 MCP 扩展，会一直卡在运行中，直到超时。 解决方案： 使用 cmd+shift+p 打开指令面板 Preferences: Open Remote Settings (JSON) (SSH: …) 将文件更新为 123456{ "remote.extensionKind": { "GitHub.copilot": ["ui"], "GitHub.copilot-chat": ["ui"] }} 保存配置，使用 cmd+shift+p 打开指令面板 Developer: Reload window 这时你的 Copiot 将正常工作。 题图使用 Gemini 生成。

问题回放我在 CCR 2004 和 CHR 之间运行了一个 eBGP 会话，ROS 版本均为 7.20.5 以下是 CCR 的配置： 12345678routing bgp instanceadd as=0001 disabled=no name=bgp-instance-0001 router-id=1.1.1.1/routing bgp connectionadd afi=ip as=0001 input.affinity=alone input.filter=chain_from_hex \ instance=bgp-instance-0001 local.address=1.1.1.1 local.role=ebgp \ name=bgp-01 output.affinity=alone remote.address=1.1.1.2 remote.as=0000 \ routing-table=main 通过这个 BGP 会话，CHR 向我（CCR2004）通告了完整的路由表，此时我需要引入 input...

背景和拓扑本次问题发生在一条跨公网建立的 IPSec VPN 隧道中，双方运营商均为相同运营商，设备分别为： 本端：MikroTik CCR 2004（ROS） 对端：山石网科防火墙（Hillstone FW） 双方均为专线，具有公网 IPv4 地址，通过 IKEv1 野蛮模式（Aggressive Mode） 建立 IPSec 隧道。协商参数正常，SA（Phase 1/2）均稳定，无重协商情况，DPD 正常。 是一个典型的 Site to Site IPSec 场景，其中两台虚拟机 A、B 均可互相 Ping 通，往返时延较低，ICMP 无丢包。 问题现象ICMP 正常，但实际业务流量有明显异常。 1、从本端的虚拟机 A SSH 登录到 对端虚拟机 B 时，连接能够建立，但交互过程持续卡顿。在命令行中表现为输入延迟、屏幕回显缓慢，不到断线程度，但体验极差。 2、尝试虚拟机 AB 之间进行 iperf3 打流，发现很小而且时断时续。双端正常的带宽应该是 50Mbps。 初步排查ICMP 正常，但是业务流程异常这个现象，可能是 MTU...

Ollama 是一款功能完善的本地大型语言模型运行平台，能够让用户在本地环境中快速部署和运行多种主流 LLM 模型。官方安装包托管在 GitHub，但在国内部分运营商在下载安装过程中可能出现下载速度缓慢、连接中断甚至安装过程卡住的问题。 为了改善这一体验，我们在 cnb.cool 上构建了一个自动化同步流水线，定期从 Ollama 官方源拉取最新的安装包并同步到国内节点，使用户能够以更高的速度和稳定性完成下载。同时，我们对 Linux 平台的安装脚本进行了适配与重写，无需手动修改官方脚本中的源地址，即可直接使用与官方一致的安装命令完成安装过程。在保证一致性的前提下，提供了更适合国内环境的顺畅安装体验。 项目地址：https://cnb.cool/hex/ollama 欢迎大家 Star 这个项目。 同步规则 定期同步：每 30 分钟自动检查上游官方仓库是否有新版本发布，如有版本更新自动同步。 仅同步稳定版：只同步官方发布的稳定版本，不包含预发布版本。 安全可控：同步脚本开源，同步过程中只拉取 GitHub 中的 Release 文件，保证 Hash...

在某些场景下，我们会使用 Nginx 反向代理将内部业务系统发布到公网。通常一台 Nginx 服务器会代理并承载多个网站，这也使其成为互联网扫描器和恶意请求的重点目标。 互联网上的一些扫描器会采集和映射 IP 资产情报，包括域名与 IP 的关联关系、所属机构和地理位置等信息，从而进行资产识别或构建攻击面。此外，部分未绑定 Host 的恶意请求也会直接针对服务器 IP 发起访问探测。 为降低此类风险，我们需要对“直接通过 IP 访问 Nginx”这一行为进行限制和防护，以避免被恶意收集、分析或利用，从而有效保障代理站点和源业务系统的资产安全与服务稳定。 最终实现效果，使用 IP 通过 HTTP 方式访问 Nginx 被阻断，通过 HTTPS 方式访问握手失败。 配置方式，配置 Nginx 的 Default Server： 123456789server { listen 80 default_server; listen [::]:80 default_server; listen 443 ssl default_server; listen...

证签CerSign 是一家数字证书产品提供商，也是较为早的在国内提供免费国密SSL证书签发的厂商。早期的免费国密证书使用了他们自己的CA签发，大多时候只受到了零信浏览器信任。最近证签CA系统完成了升级改造，启用了G2根证书和新的证书链，其国密SSL证书原先仅零信浏览器信任，升级后为所有国密浏览器都信任，这是我国目前唯一一个完全免费的90天有效期的所有国密浏览器信任的免费国密SSL证书。 此免费国密SSL证书的签发顶级根为东方新诚信CA(DongFang eTrust CA V2)，最近已完成了主流国密浏览器的根证书信任预置，包括零信浏览器，标志着我国又增加了一个能签发支持国密证书透明的全系列国密SSL证书的国密CA。 如果你有国密商用需求或其他证书需要，也可以与他们联系。 目前，本站 www.txisfine.cn 和 HEX科技威海龙芯云盘 均已支持国密访问。 申请链接：https://www.cersign.com/free-ssl-certificate.html

特别感谢 @杜比 杜总的支持和帮助。以及 @RigoLigo https://www.bilibili.com/video/BV12QPme7Euk 的视频。 硬件说明使用的是龙芯2K300的多合一Debugger 工具的标准版（后称龙芯JTAG调试器），2.54mm 间距 2×7 pin 的转接线。配合 99PI JTAG转接板。 龙芯的调试器、驱动、文档，直接找店铺客服要即可。这里不展开了。 99PI 的 JTAG 配套转接板 转接小板的方向和转接线，仔细看小板的PCB丝印。转接线的红色线为1号引脚。 连接龙芯JTAG调试器建议在 Linux 环境中使用，将龙芯JTAG调试器的USB线连接到电脑。开机。等 PG 和 STA 亮起。打开 loongson-debuger 工具。 如果有报错，就重新拔插几次调试器，可以试试用USB 2.0连接调试器。 1sudo ./la_dbg_tool_usb -t 加载配置1source configs/config.ls2k300 验证连接1jtagregs d8 1 1 应该能显示 5a5a5a5a 这说明 JTAG...

迟来的更新，祝各位 7.24 运维节快乐～ 腾讯云推出的云原生构建平台（Cloud Native Build，以下简称 CNB），通过容器化技术和声明式开发环境，改变了传统开源项目中繁琐、重复的环境搭建方式。 为满足更广泛的构建与发布需求，CNB 最近上线了对 Buildx 多架构构建的支持。开发者可以直接在 CNB 上构建面向多平台（如 x86_64、arm64、loong64 等）的镜像，实现一次构建、多平台部署，从而加速软件交付流程，进一步释放云原生的技术潜力。 自年初起，我开始着手将项目迁移至龙芯平台。在此过程中，龙芯平台的应用编译与打包面临不少挑战。恰好 CNB 公测多架构构建能力，我第一时间进行了尝试，并对原有构建流程进行了优化与重构。 关于 LoongArch64可能大家曾在央视新闻中看到，我国自主研发的新一代通用处理器 龙芯 3C6000 系列正式发布。这款处理器就是基于 LoongArch 的。LoongArch 是由龙芯中科推出的一种国产自主指令集架构（ISA），采用 RISC 设计理念，其 64 位版本即为...

今日上午，龙芯中科技术股份有限公司在北京正式发布新一代服务器处理器系列及相关终端产品。此次发布的龙芯 3C6000 系列芯片基于完全自主设计的 LoongArch 指令集架构，无需依赖任何国外授权技术，也不依赖任何境外的供应链，是我国自主研发、自主可控的新一代通用处理器，可满足通算、智算、存储、工控、工作站等多场景的计算需求。 今年年初，我们采购了一块搭载龙芯 3C6000/S 处理器的服务器主板，并通过 DIY 的方式，组装了一台2U机架式服务器。用来尝试迁移替代本地的x86架构的服务器。 目前迁移工作已基本完成，该服务器现已上架至中国电信 IDC 机房。 该服务器配备了一颗3C6000/S处理器、128GB DDR4内存、12+2存储架构、LSI RAID控制器及25Gbps智能网卡，全面满足高性能存储、网络和计算需求，为我们的测试和对外服务提供坚实的性能支撑。 在操作系统方面，我们选择了安同操作系统（AOSC OS）。AOSC OS 是一款以“简明可靠”为核心理念构建的 Linux...

在使用 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...