作者: 启鑫

  • 在 VS Code编辑器中使用 LM Studio API + Continue 打造智能开发环境

    在日常开发中大语言模型(LLM)已经成为许多开发者的得力助手。LM Studio 提供了本地运行大模型的能力,而 Continue 插件则能在 VS Code 中无缝调用这些模型,带来智能补全、对话和代码生成体验。通过 Continue 插件接入 LM Studio 的 API,我们可以让本地或局域网部署的 AI 模型无缝集成到开发环境中。

    这种组合不仅能提供媲美云端的 AI 开发体验,还能保障数据隐私、不依赖外网。在代码补全、错误排查、文档生成等场景中,都能显著提升效率。

    一、准备工作

    1. 安装 LM Studio
    • 前往 LM Studio 官网下载并安装。
    • 启动后,根据需求下载模型(如 gpt-oss-20bQwen 等)。
    1. 安装 VS Code 与 Continue 插件
    • 打开 VS Code → Extensions → 搜索 Continue 并安装。
    • 安装完成后,左侧工具栏会出现 Continue 图标。

    二、启动 LM Studio API 服务

    1. 打开 LM Studio,进入 开发者模式
    2. 加载所需模型(例如 gpt-oss-20b)。
    3. 启动 API 服务,默认会监听本地或局域网 IP 上的指定端口,例如:
    http://192.168.1.100:1234/v1

    三、配置 Continue 插件

    Continue 的配置文件默认路径如下:

    • Windows: C:\Users\<用户名>\.continue\config.yaml
    • macOS/Linux: ~/.continue/config.yaml

    示例配置:

    name: Local Agent
    version: 1.0.0
    schema: v1
    models:
      - name: gpt-oss-20b
        provider: lmstudio
        model: openai/gpt-oss-20b
        apiBase: http://192.168.1.100:1234/v1/

    ⚠️ 注意:如果需要局域网访问,请将 localhost 替换为实际 IP 地址。

    四、开始使用

    1. 打开 VS Code,点击左侧 Continue 图标。
    2. 在对话框中选择你配置好的模型(如 gpt-oss-20b)。
    3. 输入问题,即可与模型对话,体验智能补全、调试和代码生成。
  • 在 Zed编辑器中集成本地 AI:配置 Zed 编辑器 + LM Studio API

    AI 助手在开发领域的普及越来越多的开发者开始依赖它们来提升编码效率。Zed 作为一款现代、轻量且速度极快的编辑器,不仅界面优雅,还原生支持接入远程 AI 模型,为我们提供了一个绝佳的平台。

    如果您在享受 AI 带来的便利时,又对数据隐私、网络延迟或 API 费用心存顾虑,那么将 Zed 编辑器 与 LM Studio 结合将是一个完美的解决方案。通过在本地或局域网中部署私有 AI 模型,可以在 Zed 编辑器中无缝使用 AI 辅助开发,既安全又高效。

    配置 Zed 编辑器 + LM Studio,让本地或局域网部署的 AI 模型无缝集成到开发环境中。

    配置步骤

    1. 启动 LM Studio API 服务

    您需要在 LM Studio 中启动一个本地 API 服务。

    1. 打开 LM Studio,进入开发者模块。
    2. 加载您所需的 AI 模型,例如 gpt-oss-20b。
    3. 启动 API 服务。该服务会默认监听您本地或局域网 IP 上的指定端口。

    例如

    http://192.168.1.100:1234/api/v0

    2. 修改 Zed 配置文件

    Zed 的配置文件在:

    • macOS / Linux: ~/.config/zed/settings.json
    • Windows: %APPDATA%\Zed\settings.json

    在配置文件中,添加以下核心配置:

    // Zed settings
    {
      "agent": {
        "inline_assistant_model": {
          "provider": "lmstudio",
          "model": "openai/gpt-oss-20b"
        },
        "default_model": {
          "provider": "lmstudio",
          "model": "openai/gpt-oss-20b"
        }
      },
      "language_models": {
        "lmstudio": {
          "api_url": "http://192.168.1.100:1234/api/v0"
        }
      },
      "ui_font_size": 16,
      "buffer_font_size": 15,
      "theme": {
        "mode": "system",
        "light": "Ayu Light",
        "dark": "Ayu Dark"
      }
    }

    请注意以下关键配置项:

    • provider: 确保设置为 “lmstudio”,以便 Zed 识别此服务提供商。
    • model: 这里需要填入您在 LM Studio 中加载的模型标识,例如 “openai/gpt-oss-20b”。
    • api_url: 填写 LM Studio API 服务的完整访问地址。

    3. 验证效果

    完成配置后,重新启动 Zed。
    打开 Inline Assist 功能,输入测试代码或指令,如果能得到 AI 输出,即表示配置成功。

  • Debian12 升级 Debian13 记录

    Debian 12 (Bookworm) 系统升级至 Debian 13 (Trixie) 的过程记录

    1. 更新当前系统

    确保你的 Debian 12 系统处于最新状态。

    # 更新软件包列表
    apt update
    
    # 升级所有已安装的软件包
    apt upgrade
    
    # 移除不再需要的软件包和依赖项
    apt autoremove

    2. 检查当前系统版本

    升级前先确认系统版本:

    # 查看系统 Debian 版本
    
    cat /etc/debian_version

    输出结果为:

    12.12

    3. 修改软件源为 Debian 13 (Trixie)

    升级到新版本需要将系统的软件包源从 bookworm 更改为 trixie

    创建备份:备份现有的软件源文件,以防万一。

    mv /etc/apt/sources.list /etc/apt/sources.list.backup

    创建新的软件源文件,使用 /etc/apt/sources.list.d/ 目录来管理软件源,这比直接修改 sources.list 更灵活

    nano /etc/apt/sources.list.d/debian.sources

    将以下内容粘贴到新创建的文件中。软件源指向 Debian 13 (Trixie) 的主仓库、更新仓库和安全仓库。

    Types: deb
    URIs: https://deb.debian.org/debian
    Suites: trixie trixie-updates
    Components: main non-free-firmware
    Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
    
    Types: deb
    URIs: https://security.debian.org/debian-security
    Suites: trixie-security
    Components: main non-free-firmware
    Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

    4. 升级到 Debian 13

    执行更新并进行完整升级:

    # 刷新软件包列表
    apt update
    
    # 执行完整系统升级
    apt full-upgrade
    
    # 清理不再需要的软件包
    apt autoremove

    在 apt full-upgrade 过程中,如果系统询问是否保留修改过的配置文件,请仔细阅读提示。通常情况下,选择 N(保留当前版本) 是更安全的选择,以避免配置丢失或覆盖。

    5. 验证升级结果

    升级完成后,检查 Debian 版本:

    # 查看系统 Debian 版本
    
    cat /etc/debian_version

    输出:

    13.1

    说明系统已成功升级到 Debian 13.1

  • 使用 MobaXterm 搭建 TFTP 服务器为 FortiGate 提供离线特征库更新

    在一些隔离网络或无法直连 FortiGuard 的环境中,FortiGate 防火墙需要通过 手动方式 来更新 IPS、防病毒、应用识别等特征库。使用 MobaXterm 自带的 TFTP 服务 搭建文件服务器,并通过 CLI 命令在 FortiGate 上完成特征库的离线更新。

    一、准备工作

    1. 安装 MobaXterm
    2. 准备 Fortinet 官方特征库文件
    • NIDS、ISDB、APDB
    • FFDB
    • AV(ETDB、MMDB、AVAI)
    • 将这些 .pkg 文件放在一个统一的目录,例如:
    D:\Fortinet\update\

    二、MobaXterm 配置 TFTP 服务器

    1. 打开 TFTP 服务配置
      启动 MobaXterm 菜单栏选择:
    Servers → TFTP server
    1. 设置共享目录
    D:\Fortinet\update\
    1. 启动 TFTP 服务

    三、FortiGate CLI 更新命令

    在 FortiGate CLI 下,使用以下命令从 TFTP 服务器导入更新包:

    1. 更新 IPS 特征库

    execute restore ips tftp nids_OS7.2.0_34.00073.NIDS.pkg 192.168.1.100
    execute restore ips tftp isdb_OS7.2.0_33.00069.ISDB.pkg 192.168.1.100
    execute restore ips tftp apdb_OS7.2.0_34.00073.APDB.pkg 192.168.1.100

    2. 更新其他对象库

    execute restore other-objects tftp ffdb_fos72_00007.04316.pkg 192.168.1.100

    3. 更新防病毒(AV)特征库

    execute restore av tftp vsigupdate-OS7.2.0_93.05729.ETDB.High.pkg 192.168.1.100
    execute restore av tftp vsigupdate-OS7.2.0_93.05729.MMDB.pkg 192.168.1.100
    execute restore av tftp vsigupdate-OS7.2.0_4.03050.AVAI.pkg 192.168.1.100

    其中:

    • 192.168.1.100 → MobaXterm 服务器所在电脑的 IP
    • *.pkg → 存放在 TFTP 目录下的特征库文件

    四、验证更新结果

    执行:

    diagnose autoupdate versions

    可查看 IPS、AV、应用识别库、URL 分类库等版本,确认更新是否成功。

  • Red Hat Enterprise Linux 10 更新排错:403 权限错误的排查与处理

    在日常的 Linux 运维工作中保持系统更新是至关重要的。最近在维护 Red Hat Enterprise Linux (RHEL) 10 系统时,我遇到了一个让人头疼的问题:执行 dnf update 命令时,系统反复报出“Status code: 403 Forbidden”的错误。尽管 subscription-manager 显示系统已注册,但软件仓库的访问权限似乎被拒绝了。

    1. 问题现象:dnf update 403 错误

    我在终端执行系统更新命令 dnf update 时,出现了以下错误信息:

    dnf update

    系统报错:

    Errors during downloading metadata for repository 'rhel-10-for-x86_64-appstream-rpms':
      - Status code: 403 for https://cdn.redhat.com/content/dist/rhel10/10/x86_64/appstream/os/repodata/repomd.xml
    Error: Failed to download metadata for repo 'rhel-10-for-x86_64-appstream-rpms': Cannot download repomd.xml: All mirrors were tried

    报错中的“Status code: 403”是关键线索。在 HTTP 协议中,403 状态码意味着“权限被禁止”。这表明我的请求已成功发送至 Red Hat 服务器,但服务器因权限问题拒绝了我的访问。

    2. 初步排查

    既然是权限问题,我首先想到了系统订阅状态。执行 subscription-manager status 命令后,结果显示一切正常:

    subscription-manager status
    Overall Status: Registered

    这让我陷入了困惑。系统明明显示已注册,无法访问官方仓库?这说明本地的注册信息可能存在异常或缓存失效。

    为了尝试修复,我决定重新注册 Insights 客户端:

    insights-client --unregister
    insights-client --register

    但新的问题出现了:

    Machine-id found, insights-client can not be registered. Please, unregister insights-client first

    系统中的某些残留信息阻止了重新注册,即使我已尝试注销。这进一步证实了问题出在本地已损坏或过时的注册数据上。

    3. 解决步骤:彻底清除并重新注册

    步骤一:清除本地订阅数据

    使用 subscription-manager clean 命令,该命令会移除所有本地存储的订阅和授权信息

    subscription-manager clean

    执行后,终端会返回 All local data removed,这表明旧的、可能已损坏的授权数据已经被彻底清除。

    步骤二:重新注册系统

    清除数据后,系统将处于未注册状态。我们可以使用 subscription-manager register 命令进行重新注册,并输入正确的 Red Hat 账户凭据。

    subscription-manager register

    系统会提示输入用户名和密码,注册成功后会返回新的系统 ID:

    Registering to: subscription.rhsm.redhat.com:443/subscription
    Username: <你的 Red Hat 账户用户名>
    Password: <你的 Red Hat 账户密码>
    The system has been registered with ID: ...

    步骤三:验证更新

    完成重新注册后,再次执行 dnf update。这次,系统终于能够顺利连接到 Red Hat 软件仓库,并开始下载元数据和软件包。

    dnf update
    
    Updating Subscription Management repositories.
    Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs)   

    问题完美解决。

  • 从资产到服务:NaaS如何重塑企业网络

    “当‘即服务’(as-a-Service)模式已系统性地重塑IT领域的各个层面后,网络——这块关乎全局的最后拼图,也终于在2025年迎来了它的变革时刻。网络即服务(NaaS)不再是纸上谈兵的新兴概念,而是一股重塑行业的变革力量,其背后是由Gartner等权威机构预测的、高达数百亿美元的庞大市场。

    这种将网络从资产(CapEx)彻底转向服务(OpEx)的根本性转变,承诺赋予企业云般的敏捷与弹性,却也为所有决策者带来了一个战略性的两难:我们是否真的需要NaaS?

    答案并不藏在光鲜的营销术语中,而深埋于企业对自身运营与业务需求的精准洞察。归根结底,NaaS并非万能解药,而是一件高度情景化的战略工具,其全部价值在于——能否在正确的场景下,解决最核心的问题。”

    一、 什么是网络即服务 (NaaS)

    在深入探讨是否需要NaaS之前,让我们先用一个简单的类比来理解它到底是什么。

    • 传统模式: 您需要购买DVD播放机(硬件),购买一大堆DVD光盘(软件/内容),并自己负责存放、维护和升级它们。这需要一次性投入大笔资金,而且费时费力。这就是传统的网络建设模式:企业需要自己花钱购买路由器、交换机、防火墙等昂贵设备,并雇佣专门的团队来安装、配置和长期维护。
    • NaaS模式: 您只需订阅一个像Netflix或Disney+这样的流媒体服务。您按月付费,就能随时随地观看海量内容,而无需关心播放设备、内容存储或技术更新。服务商会搞定一切。这就是NaaS的核心理念:企业不再需要“购买网络”,而是像订阅服务一样“订阅网络”。

    从本质上讲,NaaS将构成企业网络所需的一切——硬件(路由器、交换机)、软件(管理平台、安全功能)以及服务(技术支持、监控、维护)——打包成一个单一的、基于订阅的运营服务。企业按需付费,并从繁重的网络建设和日常运维中解脱出来,将这些工作全部交给专业的NaaS提供商。

    二、 NaaS是如何交付的

    它在现实中是如何运作和交付的,其流程可以分解为以下几个核心步骤:

    1. 核心:云原生的管理平台

    NaaS的核心是一个由服务商运营的、强大的云原生平台。您可以将其想象成整个网络的“大脑”或“中央控制器”。企业IT管理员通过一个统一的Web门户网站或应用程序接口(API)登录这个平台,无论身在何处,都可以对全球所有网络节点进行配置、监控和管理。

    2. 物理层交付:零接触部署

    当企业需要为新办公室或门店部署网络时,不再需要派驻专业的网络工程师。NaaS提供商会将预先配置好的硬件设备(如路由器、交换机、Wi-Fi接入点)直接邮寄到指定地点。现场的工作人员只需完成两个简单动作:插上电源连接互联网。设备启动后会自动“寻找”并连接到云端的管理平台,并下载所有预设好的配置和安全策略,整个过程在几分钟内即可完成。

    3. 服务与策略交付:远程配置与下发

    所有的网络配置和变更都在云端平台完成。例如,管理员想为某个部门开放一个新的应用访问权限,或是在全球范围内更新防火墙规则,只需在管理门户上点击几下鼠标。这些策略会通过安全的加密通道,自动下发到所有相关的网络设备上并即刻生效。这消除了逐台设备进行手动配置的巨大工作量和潜在的人为错误。

    4. 底层网络交付:利用全球骨干网

    NaaS提供商通常会自建或租用全球性的高速骨干网络,并在全球关键位置部署网络接入点 (PoP)。当企业的数据从一个分支机构传输到另一个分支机构,或是访问AWS、Azure等公有云服务时,流量会优先进入NaaS提供商的优化网络,从而绕开拥堵的公共互联网,获得更稳定、更低延迟的传输体验。

    NaaS的交付模式通过云端集中控制和终端自动化部署相结合,将传统模式下分散、复杂、手动的网络管理工作,转变为一种集中、简单、自动化的现代化服务体验。

    三、 NaaS能够扭转局面的关键场景

    当业务需求对灵活性、速度和运营效率提出极高要求,以至于传统网络模型难以招架时,NaaS就成为了一个极具吸引力、近乎必要的选择。

    • 场景一:高速扩张与跨地域分布的企业
      对于计划大规模开设新店的零售企业,或向全球市场扩张的初创公司,NaaS的“零接触部署”能力可将网络上线时间从数月缩短至几天,是赢得市场先机的关键。
    • 场景二:全面拥抱混合与远程办公模式的组织
      面对“随处办公”带来的安全挑战,NaaS是交付安全访问服务边缘(SASE) 架构的核心载体。它能为所有用户(无论身处何处)提供统一、连贯的安全保护和访问体验。
    • 场景三:追求财务可预测性与核心业务聚焦的企业
      NaaS将网络成本从一次性的巨额资本性支出(CapEx)转变为可预测的运营性支出(OpEx)。同时,它将IT团队从繁琐的日常运维中解放出来,使其能专注于更有价值的战略性项目。由AIOps (智能运维)驱动的NaaS平台更能进一步自动化故障处理,提升效率。

    四、 传统网络依然是更优选的场景

    尽管势头强劲,但NaaS并非适合所有组织。在以下几种情况中,传统的自建自维网络模式仍然更胜一筹。

    • 单一地点的简单小型网络: 对于需求简单的小微企业,NaaS的复杂性和成本过高,一套本地管理的“网络一体机”方案更为实际。
    • 高度定制化或性能敏感的网络: 对于高频交易公司、国家级科研机构等对网络延迟和配置有极端要求的组织,NaaS标准化的服务无法满足其需求。
    • 拥有深厚内部技术沉淀和巨大沉没成本的企业: 如果企业刚刚完成巨额的硬件投资,并拥有一支高效的内部网络团队,那么短期内迁移到NaaS的投资回报率并不理想。
    • 拥有极端安全或合规要求的“物理隔离”环境: 对于处理绝密信息的机构,将网络控制权交予第三方在安全和合规上是不可接受的。

    五、 在决策前必须思考的关键问题

    在接触供应商之前,您的领导团队应该对以下问题有清晰的答案:

    • 增长与敏捷性: 在未来24个月内,我们的物理网点需要多快、多灵活地进行扩张或调整?
    • 财务战略: 我们的核心财务目标是保留资本、转向可预测的运营支出模式,还是可以接受大额的资本性投入?
    • IT团队定位: 我们希望IT网络团队扮演“战略创新者”还是“高效操作员”的角色?他们的时间应该更多地用于架构设计还是日常维护?
    • 安全态势: 为所有员工(无论身在何处)部署一套统一、连贯的安全策略,对我们而言有多重要?
    • 控制权与便利性: 为了换取运营的简化和速度,我们愿意在多大程度上放弃对网络硬件的直接控制权?

    “事实上,一种务实的混合策略已成为行业共识:利用NaaS的敏捷性改造庞大的广域网(WAN),同时保留对核心数据中心网络的深度控制。因此,问题的关键已不再是‘要不要上NaaS’,而是‘如何组合不同的网络模型,来最大化地驱动业务增长?’。只有从业务敏捷性、全域安全性与财务战略这三大支柱出发进行审视,企业才能制定出精准且富有远见的网络决策。”