一次“2.2秒SSL握手”的校园网“探案”：从账号差异到MTU迷局 我的校园网访问HTTPS网站时，SSL握手总要卡2.2秒，但Ping值仅18ms。更诡异的是，换个账号或换手机直连就一切正常。本文记录了如何使用F12、Wireshark抓包，从一个“Fragmentation Needed”报错出发，一步步揭开锐捷(Ruijie)系统通过“惩罚路由”对特定(账号+MAC)组合进行限制的真相，并最终通过修改路由器MTU=1492完美解决问题的全过程。

幽灵Bug调试实录：当 Rockchip DSI 接口只有背光，没有图像 幽灵Bug调试实录：当 Rockchip DSI 接口只有背光，没有图像在嵌入式 Linux 开发中，没有什么比“点屏”更能带来即时满足感了。相反，也没有什么比“背光已亮，屏幕一片漆黑”更令人沮c丧。这个经典的故障现象意味着：电源通了、复位信号对了、I2C 通信（如果有的话）可能也通了，背光驱动也工作了。所有低速外设全部正常，唯独高速的 MIPI DSI 视频数据流“人间蒸发”了。本文将详细复盘一次针对 Rockchip (RK) 平台的 DSI 接口调试，我们遇到了一个极其隐蔽且反直觉的 Bug：同一款屏幕，在 dsi1 接口上完美点亮，但在 dsi0 接口上却“黑屏”。0x01: 问题的“幽灵”形态我们的开发平台搭载了一颗 Rockchip SoC，它拥有两个独立的 MIPI DSI 接口（dsi0, dsi1），并分别由两个独立的视频处理器（Video Processor，vp2 和 vp3）来驱动。这是一个典型的双屏异显硬件架构。我们的目标是：dsi0 接口 (由 vp2 驱动) -\> 连接 ST7797 屏幕dsi1 接口 (由 vp3 驱动) -\> 连接 另一块 ST7797 屏幕然而，在调试中，我们却遇到了以下奇怪的“排列组合”现象：视频处理器 (VP)DSI 接口屏幕型号 (规格)结果vp2dsi05.5寸屏 (4-Lane, 131MHz)✅ 成功vp3dsi1ST7797 (1-Lane, 10.8MHz)✅ 成功vp2dsi0ST7797 (1-Lane, 10.8MHz)❌ 失败 (黑屏)这个测试矩阵提供了决定性的线索：dsi0 硬件没坏：既然它能点亮 4-Lane、131MHz 的 5.5 寸屏，证明 vp2 处理器、dsi0 控制器和 mipi_dcphy0 物理层本身都是好的。ST7797 屏幕配置没错：既然它能在 dsi1 上被 vp3 完美点亮，证明它的 DTS 配置（panel-init-sequence 和 display-timings）是完全正确的。结论：Bug 既不在 dsi0 硬件本身，也不在 ST7797 的配置本身。Bug 出现在 vp2 处理器驱动 1-Lane 低频 DSI 信号 这个特定的 组合 上。0x02: 深入 DSI 架构：VOP, Clock 与 Bit Rate要理解为什么会这样，我们必须简单了解一下数据流：[VOP (vp2)] -\> [DSI Controller (dsi0)] -\> [DSI PHY (mipi_dcphy0)] -\> [屏幕]VOP (Video Output Processor)：负责从内存中抓取图像数据，并按照 display-timings 生成像素时钟（clock-frequency）和视频流。DSI PHY (物理层)：负责将 VOP 过来的像素数据（并行）转换成高速串行差分信号（DSI Bit Stream）。这里的关键是 DSI PHY 的比特率 (Bit Rate)，它由像素时钟、色深和通道数共同决定：DSI PHY Bit Rate (每通道) ≈ (clock_frequency * bits_per_pixel) / num_lanes我们来计算一下我们案例中的 DSI 比特率（假设色深为 RGB888，即 24 bits）：dsi0 成功案例 (5.5寸屏)clock_frequency = 131.4 MHznum_lanes = 4Bit Rate ≈ (131.4M * 24) / 4 = 788 Mbps (每通道)vp2 在此速率下工作 正常。dsi1 成功案例 (ST7797)clock_frequency = 10.8 MHznum_lanes = 1Bit Rate ≈ (10.8M * 24) / 1 = 259 Mbpsvp3 在此速率下工作 正常。dsi0 失败案例 (ST7797)clock_frequency = 10.8 MHznum_lanes = 1Bit Rate ≈ (10.8M * 24) / 1 = 259 Mbpsvp2 在此速率下工作 失败。假设被证实：vp2 处理器（或其关联的 mipi_dcphy0）在 259 Mbps 这样的低 DSI 比特率下无法正常工作，它很可能存在一个最低速率门限。而 vp3 则没有这个限制。0x03: 柳暗花明：来自 SDK 的“官方线索”在我们深入研究 vp2 的寄存器之前，我们在 SDK 的其他项目中发现了另一款 1-Lane 屏幕的 DTS。这个文件提供了一个“石破天惊”的线索：/* SDK 中另一款 1-Lane 屏幕的 DTS */ fragment@1 { target = <&route_dsi0>; __overlay__ { status = "okay"; /* 注意！它把 dsi0 的数据源连接到了 vp3！ */ connect = <&vp3_out_dsi0>; }; }; fragment@2 { target = <&dsi0_in_vp3>; __overlay__ { status = "okay"; }; };这几乎是一个“官方承认”：Rockchip 的工程师也知道 vp2 驱动 1-Lane DSI 时存在 Bug，他们的官方“绕过方案”（Workaround）就是让 dsi0 也去使用 vp3 作为数据源。但这无法满足我们“双屏同显”的需求——vp3 已经被 dsi1 占用了。我们无路可退，必须修复 vp2。0x04: 绝妙的思路：提高时钟，“欺骗” VOP既然 vp2 无法工作在 10.8MHz 的低像素时钟下，我们能否在不改变屏幕刷新率（FPS）和分辨率的前提下，强行提高 clock_frequency？答案是肯定的。clock-frequency 是由 display-timings 中的所有参数（包括分辨率和消隐期）共同决定的：Clock = (hactive + hsync + hbp + hfp) * (vactive + vsync + vbp + vfp) * FPS我们可以保持 hactive (400), vactive (400) 和 FPS (60Hz) 不变，通过大幅增加消隐期（Blanking）（即 hsync, hbp, hfp 这些值），来“撑大” HTOTAL，从而拉高 clock-frequency。这就好比一条必须高速运转的传送带（vp2 的时钟限制）。为了保证每分钟只运送 60 个包裹（60Hz 刷新率），我们不能让传送带变慢，但我们可以在每个包裹之间留出巨大的空隙（增加消隐期）。1. 修改前的时序 (DSI0 - ST7797)clock-frequency = <10820160> (10.8 MHz)hactive = <400>vactive = <400>hsync-len = <2>, hback-porch = <20>, hfront-porch = <20>vsync-len = <2>, vback-porch = <4>, vfront-porch = <2>时钟验证：HTOTAL = 400 + 2 + 20 + 20 = 442VTOTAL = 400 + 2 + 4 + 2 = 408Clock = 442 * 408 * 60Hz = 10,820,160 (约 10.8MHz)DSI Bit Rate ≈ 259 Mbps。vp2 罢工。2. 修改后的时序 (DSI0 - ST7797)我们的目标是将时钟提高一倍，到 21.6MHz 左右，DSI 比特率也随之翻倍到 518 Mbps，这应该足以让 vp2 满意。保持 VTOTAL = 408 不变。目标 HTOTAL_new ≈ HTOTAL_old * 2 = 442 * 2 = 884。我们将增加的 884 - 442 = 442 个点钟周期，全部分配给水平消隐期（hbp 和 hfp），并微调 hsync。最终修改的 DTS display-timings 节点如下： disp0_timings0: display-timings { native-mode = <&dsi0_timing0>; dsi0_timing0: timing0 { - clock-frequency = <10820160>; + clock-frequency = <21640320>; /* 目标时钟翻倍 */ hactive = <400>; vactive = <400>; - hsync-len = <2>; - hback-porch = <20>; - hfront-porch = <20>; + hsync-len = <10>; /* 随意给一个合理的值 */ + hback-porch = <237>; /* 大幅增加 hbp */ + hfront-porch = <237>; /* 大幅增加 hfp */ vsync-len = <2>; vback-porch = <4>; vfront-porch = <2>; hsync-active = <0>; vsync-active = <0>; de-active = <0>; pixelclk-active = <0>; }; };时钟验证：HTOTAL_new = 400 + 10 + 237 + 237 = 884VTOTAL_new = 400 + 2 + 4 + 2 = 408Clock_new = 884 * 408 * 60Hz = 21,640,320 (约 21.6MHz)DSI Bit Rate ≈ 518 Mbps。刷入修改后的固件，dsi0 上的 ST7797 屏幕被成功点亮！ vp2 对这个速率非常满意。0x05: 总结与启示这次调试是一次完美的“逻辑推理”胜利。我们从一个看似诡异的“幽灵”Bug 出发，通过严谨的“排列组合”测试，成功地将问题定位到 SoC 的一个特定 IP（vp2）在一个特定工作模式（1-Lane 低比特率）下的 Bug。最终，我们没有修改一行内核驱动代码，而是利用了 display-timings 这一“阳谋”，在不影响屏幕实际显示（400x400@60Hz）的前提下，“欺骗” vp2 工作在它所喜欢的高频区域，完美绕过了这个 Bug。关键启示：“背光亮、黑屏”= 高速链路问题：这几乎是 DSI/LVDS 调试的黄金法则。请聚焦 PHY、时钟和数据路由。交叉验证是王道：dsi0/dsi1 vs 屏A/屏B 的 2x2 测试矩阵，是快速定位问题的最强武器。深挖 SDK：SDK 中其他“看似不相关”的配置文件，往往隐藏着厂商（如 Rockchip）留下的“官方提示”和“绕过方案”。display-timings 不只是时序，更是控制旋钮：不要把它当成一组固定的参数。它是你与 VOP 和 DSI PHY 沟通的“语言”，通过它可以微调硬件的物理层行为。

Ollama离线部署 在当前AI浪潮中，越来越多的企业希望在内网环境中部署自己的大语言模型，既要享受AI带来的效率提升，又要确保数据安全和合规性。Ollama作为一个轻量级的大模型运行平台，为离线部署提供了极佳的解决方案。本文将详细介绍Ollama的离线部署实践，从环境准备到模型运行的完整流程。Ollama架构解析与优势Ollama的设计哲学是"简单而强大"。它将复杂的大模型推理过程封装成简洁的命令行工具，同时提供了灵活的API接口。其核心优势在于对GGUF格式模型的原生支持，这种格式经过量化优化，能够在有限的硬件资源上高效运行大模型。Ollama的架构采用了客户端-服务端分离的设计。服务端负责模型的加载、推理和资源管理，客户端提供用户交互界面。这种架构的好处是可以在一台服务器上运行多个模型实例，多个客户端可以同时访问，实现资源的高效利用。在离线环境中，Ollama的另一个重要优势是其模块化的设计。核心运行时、模型文件、配置文件都是独立的组件，可以分别下载和部署，这为离线安装提供了极大的便利。离线部署环境准备离线部署的第一步是准备完整的安装包。与在线安装不同，离线部署需要预先下载所有必要的组件。核心组件下载# 下载Ollama主程序（在有网络的机器上执行） wget https://ollama.com/download/ollama-linux-amd64 # 下载安装脚本 curl -fsSL https://ollama.com/install.sh -o install.sh这里需要特别注意的是，Ollama的安装脚本默认会从网络下载程序文件，但在离线环境中我们需要修改脚本逻辑，让它使用本地已下载的文件。安装脚本改造安装脚本的改造是离线部署的关键技术点。原始脚本中的网络下载逻辑需要被替换为本地文件复制：# 找到脚本中的下载命令（大约在第XX行） # 原始代码： # curl --fail --show-error --location --progress-bar \ # -o $TEMP_DIR/ollama "https://ollama.com/download/ollama-linux-${ARCH}${VER_PARAM}" # 替换为： cp ./ollama-linux-amd64 $TEMP_DIR/ollama这种改造的核心思想是保持安装脚本的其他逻辑不变（如用户创建、权限设置、系统服务配置等），只修改文件获取的方式。这样可以确保离线安装后的系统状态与在线安装完全一致。模型文件获取策略大模型文件是整个部署过程中最大的挑战，不仅因为文件体积庞大，还因为需要选择合适的模型格式和版本。模型源选择国内用户可以优先选择ModelScope作为模型下载源，它提供了丰富的中文优化模型，下载速度也相对稳定：# ModelScope模型下载示例 # 访问 https://modelscope.cn/models # 搜索目标模型，如 Qwen2.5-7B-Instruct # 下载对应的GGUF格式文件对于需要最新国际模型的用户，HuggingFace仍然是首选，但需要考虑网络访问的问题。GGUF格式的技术优势GGUF（GPT-Generated Unified Format）是当前大模型量化的标准格式，相比原始的FP16或FP32模型，它具有以下技术优势：内存效率：通过INT4、INT8等低精度量化，大幅减少内存占用，使得消费级硬件也能运行大模型。加载速度：优化的文件格式结构，支持内存映射和增量加载，显著提升模型启动速度。推理性能：针对现代CPU和GPU的SIMD指令集进行了优化，在保持精度的同时提升推理速度。Modelfile配置深度解析Modelfile是Ollama的核心配置文件，它定义了模型的行为、参数和提示模板。深入理解Modelfile的各个部分对于定制化部署至关重要。核心指令解析FROM ./codeqwen-1_5-7b-chat-q8_0.gguf TEMPLATE """{{ if .System }}<|im_start|>system {{ .System }}<|im_end|> {{ end }}{{ if .Prompt }}<|im_start|>user {{ .Prompt }}<|im_end|> {{ end }}<|im_start|>assistant {{ .Response }}<|im_end|> """ PARAMETER stop "<|im_start|>" PARAMETER stop "<|im_end|>" PARAMETER temperature 0.7 PARAMETER top_p 0.8FROM指令是模型文件的引用，支持本地路径、URL或已存在的模型名称。在离线部署中，使用相对路径引用本地GGUF文件是最常见的方式。TEMPLATE指令定义了对话模板，这是模型理解对话上下文的关键。不同的模型家族有不同的对话格式，如ChatML、Alpaca、Vicuna等。正确配置对话模板直接影响模型的响应质量。PARAMETER指令用于调整模型的生成参数。temperature控制创意性（0-2，越高越有创意），top_p控制词汇选择的多样性（0-1，越高越多样），stop定义停止词用于控制生成的边界。高级配置技巧对于企业级部署，还可以配置更多高级参数：PARAMETER num_ctx 4096 # 上下文长度 PARAMETER num_predict 256 # 最大生成长度 PARAMETER repeat_penalty 1.1 # 重复惩罚 PARAMETER mirostat 2 # Mirostat采样算法 PARAMETER mirostat_tau 5.0 # Mirostat目标困惑度这些参数的调整需要根据具体的应用场景和性能要求来确定。比如，代码生成任务可能需要更高的num_ctx来处理长代码文件，而创意写作可能需要适当提高temperature。模型创建与管理模型创建是将GGUF文件和Modelfile组合成可运行模型的过程。这个过程涉及模型索引建立、配置验证、资源预分配等多个步骤。创建流程详解# 创建工作目录 sudo mkdir -p /opt/llm/models cd /opt/llm/models # 上传模型文件和配置文件 # - codeqwen-1_5-7b-chat-q8_0.gguf # - modelfile-codeqwen.Modelfile # 执行模型创建 ollama create codeqwen:7b -f ./modelfile-codeqwen.Modelfile创建过程中，Ollama会进行以下操作：文件验证：检查GGUF文件的完整性和格式正确性配置解析：解析Modelfile中的各项配置索引建立：为模型建立内部索引，优化后续加载速度依赖检查：验证系统资源是否满足模型运行要求模型版本管理在企业环境中，通常需要管理多个模型版本。Ollama支持语义化版本管理：# 创建不同版本的模型 ollama create codeqwen:7b-v1.0 -f ./modelfile-v1.Modelfile ollama create codeqwen:7b-v1.1 -f ./modelfile-v1.1.Modelfile # 设置默认版本（latest标签） ollama create codeqwen:latest -f ./modelfile-latest.Modelfile这种版本管理策略让模型的升级和回滚变得简单可控，特别适合需要频繁更新模型的场景。运行时优化与性能调优模型的运行性能直接影响用户体验，特别是在资源受限的环境中。Ollama提供了多种优化手段来提升性能。内存管理优化# 设置环境变量优化内存使用 export OLLAMA_NUM_PARALLEL=2 # 并行请求数量 export OLLAMA_MAX_LOADED_MODELS=1 # 最大加载模型数 export OLLAMA_FLASH_ATTENTION=1 # 启用Flash AttentionOLLAMA_NUM_PARALLEL控制同时处理的请求数量。在内存充足的情况下，可以适当增加这个值来提高并发处理能力。但需要注意的是，每增加一个并行请求，内存消耗会相应增加。OLLAMA_MAX_LOADED_MODELS限制同时加载到内存中的模型数量。对于单模型服务，设置为1可以确保所有内存资源都用于当前模型。OLLAMA_FLASH_ATTENTION启用Flash Attention算法，这是一种内存高效的注意力机制实现，可以显著减少内存占用并提升计算速度。GPU加速配置对于配备GPU的服务器，可以启用GPU加速来大幅提升推理速度：# 检查GPU可用性 ollama run --help | grep gpu # 设置GPU内存分配 export OLLAMA_GPU_MEMORY_FRACTION=0.8 # 启用混合精度计算 export OLLAMA_GPU_PRECISION=fp16GPU加速的效果通常非常显著，特别是对于大参数模型。但需要注意的是，不是所有的量化模型都能完全利用GPU加速，需要根据具体的模型格式和硬件配置来调整。服务化部署与高可用在生产环境中，通常需要将Ollama部署为系统服务，确保高可用性和稳定性。系统服务配置# 创建服务配置文件 sudo tee /etc/systemd/system/ollama.service > /dev/null <<EOF [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/usr/share/ollama/.ollama/models" [Install] WantedBy=default.target EOF # 启用并启动服务 sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama这个服务配置实现了以下功能：自动重启：Restart=always确保服务异常退出后自动重启，RestartSec=3设置重启间隔为3秒，避免频繁重启。网络绑定：OLLAMA_HOST=0.0.0.0:11434让服务监听所有网络接口，方便远程访问。权限隔离：使用专用的ollama用户运行服务，提高安全性。负载均衡与集群部署对于高并发场景，可以部署多个Ollama实例并配置负载均衡：# Nginx负载均衡配置 upstream ollama_backend { server 192.168.1.10:11434 weight=1; server 192.168.1.11:11434 weight=1; server 192.168.1.12:11434 weight=1; } server { listen 80; location /api/ { proxy_pass http://ollama_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_buffering off; } }这种部署方式可以实现水平扩展，通过增加节点来提高整体处理能力。模型迁移与备份策略在企业环境中，模型的迁移和备份是必须考虑的问题。Ollama的模型文件存储在特定目录中，可以通过文件系统操作来实现迁移。模型文件结构/usr/share/ollama/.ollama/ ├── models/ │ ├── manifests/ │ ├── blobs/ │ └── locks/ └── history/manifests目录存储模型的元数据信息，包括模型配置、版本信息等。blobs目录存储实际的模型文件数据，采用了内容寻址的存储方式，相同的数据块只存储一份。locks目录用于并发访问控制，确保模型文件在加载过程中不被修改。迁移操作实践# 源服务器导出模型 sudo tar -czf ollama-models-backup.tar.gz -C /usr/share/ollama .ollama/ # 目标服务器导入模型 sudo systemctl stop ollama sudo rm -rf /usr/share/ollama/.ollama/ sudo tar -xzf ollama-models-backup.tar.gz -C /usr/share/ollama/ sudo chown -R ollama:ollama /usr/share/ollama/.ollama/ sudo systemctl start ollama这种迁移方式可以完整保留所有模型数据和配置，确保迁移后的功能完全一致。API集成与开发接口Ollama提供了REST API接口，便于与其他应用系统集成。API的设计遵循了RESTful规范，使用JSON格式进行数据交换。核心API接口# 模型推理接口 curl -X POST http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{ "model": "codeqwen:7b", "prompt": "写一个快速排序算法", "stream": false }' # 对话接口 curl -X POST http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "codeqwen:7b", "messages": [ {"role": "user", "content": "解释一下机器学习的基本概念"} ] }'流式响应：通过设置"stream": true，可以实现流式响应，用户可以实时看到生成过程，提升交互体验。上下文管理：对话接口支持多轮对话，通过维护消息历史来保持上下文连贯性。错误处理与监控在生产环境中，需要实现完善的错误处理和监控机制：import requests import time import logging def ollama_chat(prompt, model="codeqwen:7b", max_retries=3): for attempt in range(max_retries): try: response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False }, timeout=60 ) response.raise_for_status() return response.json()["response"] except requests.exceptions.Timeout: logging.warning(f"Request timeout, attempt {attempt + 1}") except requests.exceptions.RequestException as e: logging.error(f"Request failed: {e}") if attempt < max_retries - 1: time.sleep(2 ** attempt) # 指数退避 raise Exception("All retry attempts failed")安全加固与访问控制在企业环境中部署大模型服务，安全性是首要考虑因素。需要从网络访问、用户权限、数据保护等多个维度进行安全加固。网络安全配置# 配置防火墙规则 sudo ufw allow from 192.168.1.0/24 to any port 11434 sudo ufw deny 11434 # 配置反向代理认证 # 在Nginx中添加基本认证 auth_basic "Ollama API"; auth_basic_user_file /etc/nginx/.htpasswd;通过限制网络访问范围和添加认证机制，可以防止未授权访问。模型访问权限控制虽然Ollama本身不提供细粒度的权限控制，但可以通过中间件来实现：# API网关示例 from flask import Flask, request, jsonify import requests app = Flask(__name__) # 用户权限配置 USER_PERMISSIONS = { "user1": ["codeqwen:7b"], "user2": ["codeqwen:7b", "qwen:14b"], "admin": ["*"] } @app.route("/api/generate", methods=["POST"]) def proxy_generate(): # 验证用户身份 api_key = request.headers.get("Authorization") user = validate_api_key(api_key) if not user: return jsonify({"error": "Unauthorized"}), 401 # 检查模型权限 data = request.json model = data.get("model") if not check_model_permission(user, model): return jsonify({"error": "Model access denied"}), 403 # 转发请求到Ollama response = requests.post( "http://localhost:11434/api/generate", json=data ) return response.json()性能监控与运维生产环境中的Ollama服务需要持续的监控和运维。关键指标包括响应时间、内存使用、GPU利用率、错误率等。监控指标收集# 创建监控脚本 cat > /opt/ollama/monitor.sh << 'EOF' #!/bin/bash while true; do # 内存使用率 memory_usage=$(ps -p $(pgrep ollama) -o %mem --no-headers) # GPU使用率（如果有GPU） gpu_usage=$(nvidia-smi --query-gpu=utilization.gpu --format=csv,noheader,nounits) # 服务状态检查 if curl -s http://localhost:11434/api/version > /dev/null; then service_status="UP" else service_status="DOWN" fi # 记录到日志 echo "$(date): Memory=${memory_usage}%, GPU=${gpu_usage}%, Status=${service_status}" >> /var/log/ollama-monitor.log sleep 60 done EOF chmod +x /opt/ollama/monitor.sh日志管理# 配置日志轮转 cat > /etc/logrotate.d/ollama << 'EOF' /var/log/ollama*.log { daily rotate 30 compress delaycompress missingok notifempty create 644 ollama ollama postrotate systemctl reload ollama endscript } EOF故障排除与常见问题在实际部署过程中，可能会遇到各种问题。建立完善的故障排除流程可以快速定位和解决问题。常见问题诊断模型加载失败：通常是内存不足或GGUF文件损坏导致。可以通过ollama logs查看详细错误信息。响应速度慢：可能是模型参数设置不当或硬件资源不足。可以调整num_ctx、num_predict等参数优化性能。服务无法启动：检查端口占用、用户权限、文件路径等基本配置。调试工具使用# 查看服务日志 sudo journalctl -u ollama -f # 检查模型状态 ollama list # 测试API连通性 curl http://localhost:11434/api/version # 查看资源使用情况 htop nvidia-smi # 如果有GPU总结与最佳实践Ollama的离线部署虽然涉及多个技术环节，但通过系统化的方法和最佳实践，可以构建稳定、高效的企业级大模型服务。关键在于充分理解每个组件的作用和配置方法，结合实际需求进行优化调整。最佳实践建议：环境标准化：建立标准的部署脚本和配置模板，确保多环境部署的一致性。资源规划：根据预期负载合理配置硬件资源，特别是内存和存储空间。安全优先：从设计阶段就考虑安全因素，实现多层次的安全防护。监控完善：建立全面的监控体系，及时发现和处理潜在问题。文档维护：保持部署文档和操作手册的更新，便于团队协作和问题排查。随着大模型技术的不断发展，Ollama这样的轻量级部署工具将在企业AI应用中发挥越来越重要的作用。掌握其离线部署技术，对于构建自主可控的AI服务具有重要意义。

新版ubuntu使用pip时发生的错误 新版ubuntu使用pip时发生错误：error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification.收到一个错误提示： error: externally-managed-environment ，即“外部管理环境”错误，但这不是一个 bug，新的发行版中，正在使用 Python 包来实现此增强功能，这个更新是为了避免操作系统包管理器 (如pacman、yum、apt) 和 pip 等特定于 Python 的包管理工具之间的冲突，这些冲突包括 Python 级 API 不兼容和文件所有权冲突。可以看一下python官方的说明：PEP 668 – Python base environments Python 增强提案 (PEP) 解决方案：1：如果你习惯于原来的用法可以强制删除此警告：sudo mv /usr/lib/python3.x/EXTERNALLY-MANAGED /usr/lib/python3.x/EXTERNALLY-MANAGED.bk注意python版本号写你自己的别直接抄，不知道到底是多少可以进/user/lib看看：find /usr/lib/ -type d -name "*python*"2：老实点使用pipx安装pipx：sudo apt install pipx以后就使用Pipx去安装包文件了：pipx install package_name添加环境变量：pipx ensurepath删除使用pipx安装的软件包：pipx uninstall package_name3：使用venv如果你是专业开发人员，在运行或构建py文件时遇到“ModuleNotFoundError: No module named 'xxx'”错误，推荐使用Python虚拟环境，借助虚拟环境，使用不同版本的包依赖项和Python，避免包之间的任何冲突。安装 venv：sudo apt install python3-venv #或者 sudo apt install python3.10-venv生成Python虚拟环境：mkdir -p $HOME/.env && python3 -m venv $HOME/.env/project_name将看到一个.env在主目录中，并且你将在 .env 中拥有项目目录，每个虚拟环境项目目录中都会有自己的 Python 和 Pip 副本。安装模块：$HOME/.env/project_name/bin/python -m pip install --upgrade pip $HOME/.env/project_name/bin/python -m pip install package_name用新的虚拟环境执行py文件：source $HOME/.env/project_name/bin/activate $HOME/.env/project_name/bin/python ./xxxx.py

Cloudflare SAAS 接入自选教程 使用Cloudflare做DNS解析的域名，开启Proxy小云朵后可以获得CDN服务，以提高线路不好或是被墙的ip的访问性。当然启用Proxy后连接的好坏也取决于用户到Cloudflare的连接质量，Cloudflare提供了一些固定的泛播ip，用户如果连接至延迟更高的ip反而会获得“减速”效果。因此本文提供一种方式来定期优选Cloudflare ip并指向自己的域名。

Linux下使用tcpdump监听DNS查询 Linux下使用tcpdump监听DNS查询 并解决docker connection reset by peer问题

使用ReDroid打造自己的云手机 前言市面上已经存在很多云手机厂商如红手指、多多云、雷电云、河马云手机等，价格从几十到上百元每月一台。价格还好说，但设备运行稳定性、可靠性、数据安全性全部依赖第三方厂商，注定不能进行敏感性操作或部署对安全可靠高要求的企业级服务。本文介绍一种开源的 AIC (Android In Container) 解决方案 ReDroid，使用本教程可以在一台普通型服务器运行多个安卓设备环境，并可在客户机电脑连接使用该云手机。Redroid介绍redroid（Remote an Droid）是一个 GPU 加速的 AIC（Android In Cloud）解决方案。Docker您可以在 Linux 主机（ 、podman等）中启动多个实例k8s。redroid支持arm64和amd64架构。 redroid适用于云游戏、虚拟化电话、自动化测试等。目前支持：安卓 14 ( redroid/redroid:14.0.0-latest)仅适用于 Android 14 64 位 ( redroid/redroid:14.0.0_64only-latest)安卓 13 ( redroid/redroid:13.0.0-latest)仅适用于 Android 13 64 位 ( redroid/redroid:13.0.0_64only-latest)安卓 12 ( redroid/redroid:12.0.0-latest)仅适用于 Android 12 64 位 ( redroid/redroid:12.0.0_64only-latest)安卓 11 ( redroid/redroid:11.0.0-latest)安卓 10 ( redroid/redroid:10.0.0-latest)安卓 9 ( redroid/redroid:9.0.0-latest)安卓 8.1 ( redroid/redroid:8.1.0-latest)入门redroid 应该能够在任何 Linux 上运行（启用一些内核功能）。这里以使用阿里云的X86服务器进行演示，具体如下：配置：vCPUs2内存2G储存40G系统ubuntu-22.04架构x86-64带宽3M安装Docker## 安装 docker https://docs.docker.com/engine/install/#server # 根据 Docker 官方文档安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh #或者从仓库下载 sudo apt update sudo apt-get install -y docker.io systemctl start docker systemctl enable docker 安装内核扩展模块更具不同的系统，有不一样的安装方法，具体如下 # 拉取内核模块源码 git clone https://github.com/remote-android/redroid-modules cd ./redroid-modules # Ubuntu 16.04 / 18.04 / 20.04 sudo apt-get install -y git kmod make gcc linux-headers-`uname -r` sudo make # build kernel modules sudo make install # build and install *unsigned* kernel modules # Ubuntu 20.04+ (kernel 5.0+) sudo modprobe ashmem_linux sudo modprobe binder_linux devices=binder,hwbinder,vndbinder # AmazonLinux2 git checkout origin/amazonlinux2 sudo yum install git kmod make "kernel-devel-uname-r == `uname -r`" sudo make # build kernel modules sudo make install # build and install *unsigned* kernel modules # Alibaba Cloud Linux 2 git checkout origin/alibabalinux2 sudo yum install git kmod make "kernel-devel-uname-r == `uname -r`" sudo make # build kernel modules sudo make install # build and install *unsigned* kernel modules # Alibaba Cloud Linux 3 git checkout origin/alibabalinux3 sudo yum install git kmod make "kernel-devel-uname-r == `uname -r`" sudo make # build kernel modules sudo make install # build and install *unsigned* kernel modules # openEuler 20.03 / kernel 4.19 git checkout origin/openeuler2003 sudo yum install gcc kernel-devel sudo KDIR=/usr/src/kernels/<VER> make install # 检查模块状态 lsmod | grep -e ashmem_linux -e binder_linux # example output: # binder_linux 147456 79 # ashmem_linux 16384 23 # 也可以这样验证 grep binder /proc/filesystems # output should like: nodev binder grep ashmem /proc/misc # output should like: 56 ashmem我这边因为是ubuntu 22.04，便使用 modprobe 安装如果不想换系统，可以尝试升级内核到5.0以上，默认就自带相关模块了启动容器创建Docker-compose文件docker-compose.ymlversion: "3" services: redroid: image: redroid/redroid:11.0.0-latest stdin_open: true tty: true privileged: true ports: - "20055:5555" volumes: # 資料存放在目前目錄下 - ./redroid-11-data:/data command: # 設定libndk相關 - ro.product.cpu.abilist0=x86_64,arm64-v8a,x86,armeabi-v7a,armeabi - ro.product.cpu.abilist64=x86_64,arm64-v8a - ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi - ro.dalvik.vm.isa.arm=x86 - ro.dalvik.vm.isa.arm64=x86_64 - ro.enable.native.bridge.exec=1 - ro.dalvik.vm.native.bridge=libndk_translation.so - ro.ndk_translation.version=0.2.2 - ro.secure=0 cap_add: - CAP_SYS_MODULE 启动容器#确保安装了docker-compose apt install docker-compose # 进入储存docker-compose.yml的目录 cd /data/redroid-1 docker-compose up -d如果使用 22.04可能出现如下异常解决方案pip install 'urllib3<2'链接根据 Scrcpy 官方文档下载安卓投屏软件源码包到客户机，解压使用adb connect ip:5555 # adb devices 可查看连接设备列表 scrcpy --serial ip:5555高级一些额外参数样例docker run -itd --rm --privileged \ --pull always \ -v ~/data:/data \ --cap-add CAP_SYS_MODULE \ -p 5555:5555 \ redroid/redroid:11.0.0-latest \ androidboot.redroid_width=1080 \ androidboot.redroid_height=1920 \ androidboot.redroid_dpi=480 \参数描述默认androidboot.redroid_width显示宽度720androidboot.redroid_height显示高度1280androidboot.redroid_fps显示 FPS30（启用 GPU） 15（未启用 GPU）androidboot.redroid_dpi显示 DPI320androidboot.use_memfd使用 memfd 替换已弃用的 ashmem计划默认启用假androidboot.use_redroid_overlayfs使用overlayfs共享data分区/data-base：共享data分区/data-diff：私有数据0androidboot.redroid_net_ndnsDNS 服务器数量，如果未指定 DNS 服务器，将使用“8.8.8.8”0androidboot.redroid_net_dns<1..N>域名解析 androidboot.redroid_net_proxy_type代理类型；从以下选项中选择：“静态”、“pac”、“无”、“未分配” androidboot.redroid_net_proxy_host androidboot.redroid_net_proxy_port 3128androidboot.redroid_net_proxy_exclude_list逗号分隔列表 androidboot.redroid_net_proxy_pac androidboot.redroid_gpu_mode从以下选项中选择：auto、host、guest；guest：使用软件渲染；host：使用 GPU 加速渲染；auto：自动检测自动androidboot.redroid_gpu_node 自动检测ro.xxxDEBUG 目的，允许覆盖 ro.xxx 属性；例如设置ro.secure=0，则默认提供root adb shell

D-Link Go-RT-AC750命令注入漏洞复现 D-Link Go-RT-AC750命令注入漏洞复现

shell运算详解 shell运算详解

shell数据筛选与处理 shell数据筛选与处理

shell流程控制-if判断语句 shell流程控制-if判断语句

shell脚本用户交互 shell脚本用户交互