Auto-sync: 2026-04-22 04:02

2026-04-22 04:03:04 +08:00
parent 24218550d2
commit de096f2f88
232 changed files with 16604 additions and 514 deletions
--- a/wiki/sources/3x-ui-xray-on-bandwagonvps.md
+++ b/wiki/sources/3x-ui-xray-on-bandwagonvps.md
@@ -0,0 +1,60 @@
+---
+title: "3X-UI Xray on BandwagonVPS"
+type: source
+tags: [vps, xray, 3x-ui, 科学上网, vless, reality]
+date: 2026-02-10
+---
+
+## Source File
+- [[raw/Home Office/3X-UI Xray on BandwagonVPS.md]]
+
+## Summary (中文描述)
+- **核心主题**：在 Bandwagon VPS 上通过 3X-UI 可视化面板部署 Xray 代理服务（VLESS+Reality 协议）
+- **问题域**：个人科学上网基础设施的搭建与维护
+- **方法/机制**：
+  - 使用 mhsanaei/3x-ui 一键安装脚本部署 Web 管理面板
+  - 通过面板生成 VLESS+Reality 协议的入站配置
+  - 客户端使用 v2rayN（Windows/Linux）和 v2rayNG（Android）连接
+  - 启用 BBR 拥塞控制算法优化网络性能
+- **结论/价值**：3X-UI 提供了一条龙的可视化运维路径，降低了 Xray 服务端配置门槛，国内/国外双向访问均可达 200 OK
+
+## Key Claims (中文描述)
+- 用户通过 3X-UI 面板在 Bandwagon VPS（104.194.92.188）上成功部署了 Xray 代理服务
+- VLESS+Reality 协议要求服务端生成公钥私钥对，客户端使用公钥连接
+- 3X-UI 面板支持 SSL 证书管理、云flare证书更新、Geo 文件更新、BBR 启用等 25 项运维操作
+- Panel 状态和 xray 状态均显示 Running，自动启动（Autostart）已启用
+- 国内访问和国外访问直连测试均返回 200，网络连通性验证通过
+
+## Key Quotes
+> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 一行命令完成 3X-UI 的安装与初始配置
+> "使用 VLESS+Reality 方式配置，需要产生公钥和私钥" — Reality 协议的核心机制，需要非对称加密密钥对
+
+## Key Concepts
+- [[VPN Panel]]：Web 界面管理代理服务的统称，3X-UI 属于此类，提供启停、重启、日志、证书等可视化运维功能
+- [[Xray]]：新一代代理核心，支持 VLESS、VMess、Trojan、Shadowsocks 等多种协议，Reality 是其内置的流量伪装方案
+- [[VLESS+Reality]]：无状态的代理协议组合，VLESS 为传输层协议，Reality 负责 TLS 流量伪装，特征是服务端不需要保存用户状态，适合多用户场景
+- [[Web Proxy Protocol]]：代理协议家族，常见有 SOCKS5、HTTP，以及 VLESS/Trojan/VMess 等专有方案
+- [[BBR]]：Google 开发的 TCP 拥塞控制算法，可显著提升跨境网络吞吐量，3X-UI 内置一键启用功能
+
+## Key Entities
+- [[Bandwagon VPS]]：低总价 OpenVZ/KVM VPS 提供商，常用于个人科学上网场景，资料中涉及的 VPS 名称为 VPS2
+- [[3X-UI]]：mhsanaei/3x-ui 项目提供的 Xray 可视化管理面板，支持安装、更新、SSL、BBR 等 25 项操作
+- [[v2rayN]]：Windows/Linux 平台的代理客户端，支持 VLESS、VMess、Trojan 等多种协议，是本文档推荐的桌面端连接工具
+- [[v2rayNG]]：Android 平台的代理客户端，v2rayN 的移动版，支持同样的协议集
+- [[Xray-Project]]：VLESS 协议的主要维护方，也是 Reality 伪装方案的提出者
+
+## Connections
+- [[Bandwagon VPS]] ← 托管了 ← [[3X-UI]]
+- [[3X-UI]] ← 运行了 ← [[Xray]]
+- [[Xray]] ← 配置了 ← [[VLESS+Reality]]
+- [[v2rayN]] ← 客户端连接到 ← [[Xray]]
+- [[v2rayNG]] ← 移动客户端连接到 ← [[Xray]]
+- [[Home Server Automation]] ← 包含 ← [[科学上网基础设施]]
+- [[ubuntu-server科学上网]] ← 相关方案 ← [[3X-UI Xray on BandwagonVPS]]（均属于科学上网领域）
+
+## Contradictions
+- 与 [[网件RAX50刷梅林固件与科学上网]] 冲突：
+  - **冲突点**：科学上网的实现层级不同
+  - **当前观点**（本文）：在 VPS 层面部署 Xray 代理，属于服务端集中式方案
+  - **对方观点**：在路由器固件层面（MerlinClash）实现分流，属于网关透明代理方案
+  - **协调**：两者可以互补——路由器处理全屋流量，VPS 提供代理节点，通过订阅机制联动
--- a/wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md
+++ b/wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md
@@ -0,0 +1,66 @@
+---
+title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
+type: source
+tags: [backup, clonezilla, nas, rufus, ubuntu]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份.md]]
+
+## Summary (用中文描述)
+- **核心主题**：使用 Clonezilla 对 Ubuntu Server 进行全盘镜像备份到 NAS 的完整操作流程
+- **问题域**：系统灾难恢复、数据备份、裸机还原
+- **方法/机制**：
+  - 使用 Rufus 将 Clonezilla ISO 写入 U 盘制作启动盘（支持 GPT/UEFI 和 MBR/BIOS 两种分区方案）
+  - 通过 NFS 网络挂载将镜像存储到 NAS
+  - Clonezilla device-image 模式将磁盘备份为镜像文件
+  - Beginner 模式简化配置（savedisk/savedisk）
+- **结论/价值**：实现类似 Ghost 的全盘镜像功能，支持完整的系统灾难恢复
+
+## Key Claims (用中文描述)
+- Rufus 必须选择"以 ISO 镜像模式写入"（推荐），若无法启动再尝试 DD 模式
+- 较新笔记本选 GPT + UEFI (非 CSM)；老旧笔记本选 MBR + BIOS (或 UEFI-CSM)
+- 推荐使用 NFS Server 连接 NAS（Linux 兼容性最好）
+- Beginner 模式默认参数已足够，无需高级配置
+- savedisk 备份整个磁盘；restoredisk 从镜像还原到磁盘，可实现系统即时复活
+
+## Key Quotes
+> "Clonezilla (再生龙)" — 类 Ghost 的开源全盘镜像工具
+
+> "以 ISO 镜像模式写入 (推荐)" — Rufus 写入 ISOHybrid 镜像的正确方式
+
+> "Beginner 模式，默认参数已足够" — 初学者推荐使用简化配置
+
+> "备份完后，它会覆盖新硬盘的所有数据，完成后系统即刻复活" — 灾难恢复效果
+
+## Key Concepts
+- [[全盘镜像备份]]：将整个磁盘/分区复制为镜像文件，支持完整还原
+- [[NFS网络备份]]：通过网络文件系统将备份镜像存储到远程NAS，支持跨设备备份
+- [[裸机恢复]]：磁盘损坏后从镜像文件还原整个系统，无需重新安装配置
+- [[UEFI启动]]：现代BIOS标准，使用GPT分区表；与传统MBR/BIOS的区别在于启动流程和分区限制
+- [[ISOHybrid镜像]]：同时支持ISO和DD两种写入模式的混合镜像，需正确选择写入模式
+
+## Key Entities
+- [[Clonezilla]]：开源磁盘镜像/克隆工具（再生龙），类 Ghost 功能，支持 device-image 模式备份到 NAS
+- [[Rufus]]：开源 U 盘启动盘制作工具，支持 ISOHybrid 镜像写入模式选择
+- [[Ubuntu Server]]：目标备份系统，基于 Linux 的服务器操作系统
+- [[HP ZBook]]：源笔记本（F9 进入启动菜单）
+- [[NFS]]：Network File System，网络文件系统备份存储协议
+- [[Synology NAS]]：备份存储目标设备（NAS 网络存储）
+- [[GPT分区表]]：UEFI 启动使用的现代分区方案（相比 MBR 的区别：支持 >2TB 磁盘、无限分区数）
+- [[MBR分区表]]：传统 BIOS 启动使用的分区方案（限制 2TB 磁盘、4 个主分区）
+
+## Connections
+- [[NFS网络备份]] ← uses ← [[Clonezilla]]
+- [[全盘镜像备份]] ← implements ← [[裸机恢复]]
+- [[Ubuntu Server]] ← backed_up_by ← [[Clonezilla]]
+- [[Rufus]] ← creates ← [[UEFI启动]] + [[MBR分区表]] (启动盘)
+- [[Synology NAS]] ← stores ← [[NFS网络备份]] (镜像存储目标)
+
+## Related Sources
+- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync 增量备份方案（文件级 vs 镜像级互补）
+- [[Disaster Recovery]] — 灾备策略（[[RTO]]/[[RPO]] 概念）
+
+## Contradictions
+- 无冲突发现
--- a/wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md
+++ b/wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md
@@ -0,0 +1,85 @@
+---
+title: "Cloud Operating Model: Key Strategies and Best Practices"
+type: source
+tags: [Cloud, DevOps, Cloud Strategy, Cloud Governance]
+date: 2025-03-01
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md]]
+
+## Summary (中文)
+- **核心主题**：云运营模型（Cloud Operating Model, COM）是现代云战略的基础框架，涵盖治理、安全、成本优化和运营敏捷性四大支柱
+- **问题域**：企业在云迁移过程中面临成本失控、安全漏洞、运维混乱等挑战；89%的组织预计到2025年将采用云优先架构，但缺乏结构化方法
+- **方法/机制**：
+  - 四大核心支柱：治理与合规、自动化、安全、成本管理
+  - 六步设计流程：评估成熟度 → 建立治理框架 → 自动化运营 → 实施成本管理 → 强化安全 → 持续监控与AI优化
+  - FinOps策略：Reserved/Spot实例、自动扩缩、实时监控
+  - Zero Trust安全模型：无隐式信任、持续验证
+- **结论/价值**：结构化的COM帮助企业实现治理标准化、成本优化、安全增强和运营敏捷；多云策略避免供应商锁定；AI驱动的自动化是未来趋势
+
+## Key Claims (中文)
+- 89%的组织预计到2025年将采用云优先架构以提升可扩展性、敏捷性和成本效率
+- 59%的企业在云成本管理方面遇到困难，8%的组织关注可持续性和碳足迹
+- 采用Cloud Operating Model的企业可实现：标准化治理、成本优化、安全增强、运营敏捷、多云灵活性
+- FinOps策略通过Reserved实例和Spot实例可降低40-70%的计算成本
+- 实施Zero Trust安全策略和自动化安全补丁可将安全事件减少60%
+- AI驱动的异常检测可将停机时间减少45%
+- 多云部署可将停机风险降低40%
+
+## Key Quotes
+> "A Cloud Operating Model (COM) is a framework that standardizes how organizations manage cloud resources, security, automation, and costs across cloud environments." — Bacancy Technology
+
+> "Without proper governance, Cloud environments can spiral out of control quickly." — Bacancy Technology
+
+> "Security in the Cloud is no longer about physical perimeters and firewalls but about identity-based security, encryption, and continuous monitoring." — Bacancy Technology
+
+> "AI can predict resource usage, automatically adjusting workloads to avoid overprovisioning and reduce cloud costs." — Bacancy Technology
+
+## Key Concepts
+- [[Cloud Operating Model]]：标准化组织管理云资源、安全、自动化和成本的框架
+- [[FinOps]]：云财务运营，通过成本监控、优化策略和预算控制管理云支出
+- [[Zero-Trust-Security]]：零信任安全模型，无隐式信任，持续验证所有访问请求
+- [[Multi-Cloud Strategy]]：多云策略，避免单一供应商锁定，提升韧性和灵活性
+- [[Infrastructure as Code]]：基础设施即代码，通过Terraform等工具实现自动化部署
+- [[Cloud Governance]]：云治理，建立政策和合规框架确保云环境有序运营
+- [[AIOps]]：AI驱动的IT运维，利用机器学习进行异常检测和性能优化
+- [[Cloud Cost Optimization]]：云成本优化，通过各种策略减少不必要的云支出
+- [[Serverless Computing]]：无服务器计算，Eliminate不必要资源消耗
+- [[Green Computing]]：绿色计算，降低数据中心能耗和碳足迹
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，提供IAM、Cost Explorer、GuardDuty等云服务
+- [[Azure]]：Microsoft Azure，提供Azure AD、Cost Management、Defender等云服务
+- [[Google-Cloud]]：Google Cloud Platform，提供Google IAM、Security Command Center等云服务
+- [[Terraform]]：HashiCorp的IaC工具，支持多云基础设施自动化
+- [[Kubernetes]]：容器编排平台，支持跨云工作负载管理
+
+## Connections
+- [[Cloud Operating Model]] ← 构建于 ← [[Cloud Governance]]
+- [[FinOps]] ← 依赖 ← [[Cloud Cost Optimization]]
+- [[Zero-Trust-Security]] ← 包含于 ← [[Cloud Operating Model]]
+- [[Multi-Cloud Strategy]] ← 解决 ← [[Vendor-Lock-In]]
+- [[AIOps]] ← 增强 ← [[Cloud Operating Model]]
+- [[Infrastructure as Code]] ← 实现 ← [[Cloud Governance]]
+
+## Industry Use Cases
+- **金融服务**：合规自动化、FinOps成本治理、Zero Trust安全模型
+- **医疗健康**：HIPAA/HITRUST合规自动化、数据加密与访问控制、AI诊断
+- **零售电商**：自动扩缩应对流量高峰、多云避免供应商锁定
+- **SaaS科技**：CI/CD流水线加速部署、容器化架构提升伸缩性
+
+## Challenges & Solutions
+1. **Vendor Lock-In** → 多云策略 + Docker/Kubernetes容器化 + Terraform
+2. **Cost Overruns** → FinOps + Reserved/Spot实例 + 自动关停策略
+3. **Compliance Risks** → Policy-as-Code + AWS Config/Azure Policy + RBAC
+4. **Skills Gap** → 自动化工具 + 团队培训
+
+## Future Trends
+- AI & ML驱动的云运营（预测性分析、自愈环境）
+- 云可持续性与绿色计算
+- 多云与混合云策略：无供应商锁定的云治理
+
+## Contradictions
+- 与传统本地IT对比：云运营需要全新的安全、自动化和成本管理策略，而非简单迁移
+- 初期投入vs长期收益：云运营模型需要前期治理框架投入，但长期可显著降低运营成本
--- a/wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md
+++ b/wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md
@@ -0,0 +1,136 @@
+---
+title: "How Agentic AI can help for Cloud DevOps"
+type: source
+tags: [Cloud, DevOps, AI, Agentic]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md]]
+
+## Summary (中文描述)
+### 核心主题
+Agentic AI（具备自主决策和任务执行能力的AI系统）如何通过自动化复杂工作流、提升效率和保障云环境可靠性来增强 Cloud DevOps。
+
+### 问题域
+- 事故响应速度慢（MTTR高）
+- 云成本持续攀升（资源过度配置）
+- 安全合规持续监控困难
+- 多云环境管理复杂度高
+- 人工运维负担重
+
+### 方法/机制
+七大能力领域：
+1. **自主事故检测与解决** — Self-Healing + AI-driven RCA + Predictive Maintenance
+2. **自动化云部署与配置** — AI Release Manager + IaC 智能审查 + 动态配置管理
+3. **智能成本优化** — AI Rightsizing + Spot Instance 优化 + 多云成本治理
+4. **AI驱动的安全与合规** — 自动安全审计 + 动态威胁缓解 + 合规实时执行
+5. **智能日志分析与可观测性** — AI日志分析 + 自动RCA + ChatOps
+6. **增强的多租户SaaS管理** — 动态租户配置 + 自动退租 + 多租户成本优化
+7. **AI增强的决策支持** — AI Runbooks + What-If模拟 + AI异常检测
+
+### 结论/价值
+Agentic AI 通过集成 AI 驱动的自动化，使企业能够实现更快的部署、更主动的问题解决、更低的成本和更强的安全合规——且无需增加 DevOps 工作负载。
+
+---
+
+## Key Claims (中文描述)
+- Agentic AI 通过**自动检测异常并应用修复**（重启Pod、扩缩容、清理磁盘），实现**更快的 MTTR 和 SLA 合规** → Self-Healing Systems
+- Agentic AI 通过**分析云监控日志关联跨层问题**，实现**AI驱动的根因分析**，比人工更快定位问题根因 → Root Cause Analysis (RCA)
+- Agentic AI 通过**持续学习历史故障模式并主动建议补丁**，实现**预测性维护**，减少非计划停机 → Predictive Maintenance
+- Agentic AI 作为 Release Manager 通过**自动执行蓝绿部署和金丝雀策略**，结合**自动回滚**，实现**更可靠的 CI/CD** → Deployment Automation
+- Agentic AI 通过**持续分析使用趋势并动态调整资源**，实现**40%成本降低**（如夜间切换 Spot 实例） → Rightsizing
+- Agentic AI 通过**扫描 IAM 策略和容器漏洞并自动修复**，实现**持续安全态势管理和实时合规执行** → Automated Security Audit
+- Agentic AI 通过**跨云识别浪费支出并建议资源整合**，实现**多云成本治理** → Multi-Cloud Cost Optimization
+- Agentic AI 通过**自动分析日志并关联外部API故障**，实现**智能故障排查和重试策略建议** → AI ChatOps
+- Agentic AI 通过**动态配置租户资源分配**，实现**SaaS 多租户自动化供给** → Multi-Tenant SaaS
+- Agentic AI 通过**What-If模拟云迁移对性能/成本/合规的影响**，实现**迁移前的数据驱动决策** → What-If Simulation
+
+---
+
+## Key Quotes
+
+> "Agentic AI transforms Cloud DevOps by automating incident response, cost management, security, observability, and multi-cloud governance." — 结论总结
+
+> "An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod. It automatically throttles the pod, scales resources, or suggests a pod restart." — Self-Healing 示例
+
+> "An AI agent detects that a workload in AWS **should be shifted to spot instances at night**, reducing cloud costs by 40%." — 成本优化示例
+
+> "An AI agent simulates how moving an AWS-based SaaS application to **GCP's Private Cloud in KSA** will impact performance, cost, and compliance." — What-If Simulation 示例
+
+---
+
+## Key Concepts
+
+- [[Agentic AI]]：具有自主决策和任务执行能力的AI系统，能够感知环境、规划行动、执行任务并从反馈中学习
+- [[Self-Healing Systems]]：通过自动检测异常并应用修复（重启、扩缩容、清理资源）实现系统自主恢复的能力
+- [[Root Cause Analysis (RCA)]]：通过AI分析日志跨层关联，快速定位问题根本原因，而非仅处理表象
+- [[Predictive Maintenance]]：基于历史故障模式学习，主动建议补丁或变更以预防非计划停机
+- [[Deployment Automation]]：AI代理作为Release Manager，自动执行部署策略（蓝绿/金丝雀）和回滚决策
+- [[Rightsizing]]：AI持续分析资源使用趋势，动态调整云资源配置以消除过度配置
+- [[Automated Security Audit]]：AI自动扫描IAM策略、网络规则和容器漏洞，并自动修复问题
+- [[Multi-Cloud Cost Optimization]]：AI跨多云识别浪费支出，建议资源整合或替代定价模式
+- [[AI ChatOps]]：通过自然语言接口（Slack/Teams/CLI）进行故障排查，AI提供日志分析和解决方案建议
+- [[Multi-Tenant SaaS]]：AI动态管理多租户资源分配、供给、退租和成本分摊
+- [[What-If Simulation]]：AI模拟架构变更（如云迁移）对性能、成本和合规的影响，支持数据驱动决策
+- [[AIOps]]（已有）— 本文档扩展了 AIOps 的具体实现场景
+
+---
+
+## Key Entities
+
+- [[Kubernetes]]（EKS/GKE/AKS）：云原生容器编排平台，是 Agentic AI 自主修复的主要目标环境
+- [[Terraform]]：IaC 工具，AI 代理审查和改进 Terraform 脚本以确保基础设施配置正确
+- [[CloudWatch]]（AWS）/ Stackdriver（GCP）/ Azure Monitor：云监控平台，AI 分析其日志进行 RCA 和异常检测
+- [[IAM]]（Identity and Access Management）：云安全核心，AI 自动审计 IAM 策略以防止过度权限
+- [[Spot Instances]]（AWS）/ Preemptible（GCP）/ Savings Plan（Azure）：低成本云实例，AI 动态调度工作负载以优化成本
+
+---
+
+## Connections
+
+- [[Agentic AI]] ← 应用场景 ← [[Cloud DevOps]]
+- [[Agentic AI]] ← 核心能力 ← [[Self-Healing Systems]]
+- [[Agentic AI]] ← 核心能力 ← [[Root Cause Analysis (RCA)]]
+- [[Agentic AI]] ← 核心能力 ← [[Predictive Maintenance]]
+- [[Agentic AI]] ← 核心能力 ← [[Deployment Automation]]
+- [[Agentic AI]] ← 核心能力 ← [[Rightsizing]]
+- [[Agentic AI]] ← 核心能力 ← [[Automated Security Audit]]
+- [[Agentic AI]] ← 核心能力 ← [[AI ChatOps]]
+- [[Agentic AI]] ← 核心能力 ← [[What-If Simulation]]
+- [[Kubernetes]] ← 修复目标 ← [[Self-Healing Systems]]
+- [[Terraform]] ← 审查对象 ← [[Infrastructure-as-Code]]
+- [[CloudWatch]] ← 数据源 ← [[AIOps]]
+- [[IAM]] ← 审计对象 ← [[Automated Security Audit]]
+- [[Multi-Cloud Strategy]] ← 依赖 ← [[Multi-Cloud Cost Optimization]]
+- [[DORA Metrics]] ← 评估 ← [[Agentic AI]]（通过 MTTR 改善评估效果）
+- [[FinOps]] ← 相关领域 ← [[Rightsizing]]
+
+---
+
+## Contradictions
+
+- **Agentic AI 自动修复 vs 人工审批控制**
+  - 冲突点：Agentic AI 主张自动修复（自动重启Pod、自动限制权限），而企业安全合规通常要求人工审批
+  - 当前观点：对于非关键操作（Pod重启、资源扩缩容），自动修复可显著降低 MTTR
+  - 对方观点：安全变更应有人工审批链路，SOC 2/ISO 27001 合规要求变更控制记录
+
+- **Spot Instance 成本优化 vs SLA 保证**
+  - 冲突点：AI 建议夜间切换 Spot Instance（40%成本降低），但 Spot Instance 无 SLA 保证
+  - 当前观点：对于容错 workloads（批处理、CI/CD、Dev 环境），Spot 是理想选择
+  - 对方观点：生产环境关键 workloads 不应依赖无 SLA 的 Spot Instance
+
+- **AI 自动化 vs DevOps 文化的人本主义**
+  - 冲突点：过度自动化可能削弱 DevOps 团队的判断力和成长机会
+  - 当前观点：AI 处理重复性工作（告警分诊、日志解析），工程师聚焦架构决策
+  - 对方观点：自动化不应完全替代工程师的 Ops 判断，保留人工 Review 节点
+
+---
+
+## Metadata
+- **Author**: shenwei
+- **Tags**: Cloud, DevOps, AI, Agentic
+- **Related Sources**: 
+  - [[what-i-know-about-cloud-service-delivery-1]]（AIOps 相关）
+  - [[cloud-devop-maturity-guideline]]（DevOps 成熟度相关）
+  - [[devops-maturity-model-from-traditional-it-to-advanced-devops]]（DevOps 成熟度模型）
--- a/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md
+++ b/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md
@@ -0,0 +1,86 @@
+---
+title: "How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets"
+type: source
+tags: [AWS, CloudFormation, StackSets, DevOps, Multi-Account, EventBridge, CloudWatch]
+date: 2025-10-24
+---
+
+## Source File
+- [[raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md]]
+
+## Summary (用中文描述)
+- 核心主题：通过 AWS CloudFormation StackSets 实现多账户基础设施部署时，将分散在多个账户的 CloudFormation 日志集中到管理账户进行统一监控。
+- 问题域：企业采用多账户策略后，在50+账户上部署安全基线时，故障排查需要逐个登录账户查看日志，运营开销随组织增长呈指数级增长。
+- 方法/机制：使用 EventBridge Rules 捕获各目标账户的 CloudFormation 事件，通过跨账户权限转发到管理账户的统一 Event Bus，再写入 CloudWatch Log Group，配合 CloudWatch Logs Insights 查询实现单一管理界面的集中监控。
+- 结论/价值：单次部署即可创建中心日志基础设施并自动向所有成员账户推送 EventBridge 规则，确保整个组织的一致配置；使用 CloudWatch Logs Insights 自定义查询实现跨账户故障排查。
+
+## Key Claims (用中文描述)
+- AWS CloudFormation StackSets 赋能组织跨多个账户和区域部署基础设施，但在多账户场景下监控和追踪分布式部署面临运营挑战。
+- 当跨50个账户部署关键安全基线突然失败时，团队面临艰巨任务：逐个登录账户理解问题所在及影响范围。
+- 该运营开销随组织增长呈指数级增长，要求平台团队花费大量时间在账户间切换并手动关联部署事件。
+- 通过将 CloudFormation 日志集中到管理账户，可实现跨整个组织的单一监控界面。
+- 解决方案通过两次 CloudFormation 部署完成：管理账户基础设施（log-setup-management.yaml）+ StackSet 部署模板（common-resources-stackset.yaml）。
+
+## Key Quotes
+> "As organizations adopt multi-account strategies for improved security features and governance, AWS CloudFormation StackSets enables organizations to deploy infrastructure across multiple accounts and regions." — 问题背景：多账户策略的采用带来 StackSets 部署监控挑战
+
+> "Managing infrastructure across multiple AWS accounts doesn't have to be complex. By centralizing AWS CloudFormation logs, you can gain visibility into your multi-account deployments, troubleshoot issues more efficiently, and help achieve consistent resource deployment across your organization." — 核心价值主张：简化多账户基础设施管理
+
+> "This single deployment: 1. Creates the central logging infrastructure in the management account. 2. Automatically deploys Amazon EventBridge rules to all accounts in the specified OU. 3. Sets up the necessary IAM roles and policies for cross-account access." — 一次性部署的三重价值
+
+## Key Concepts
+- [[Centralized Logging]]：将分散在多个系统/账户的日志汇总到中心位置进行统一管理的模式。该方案将多账户 CloudFormation 事件集中到管理账户的 CloudWatch Log Group。
+- [[Cross-Account Monitoring]]：跨账户监控能力，通过 IAM 跨账户角色和 EventBridge 跨账户事件转发实现。该方案使用 EventBridge Custom Event Bus + 跨账户访问策略。
+- [[Multi-Account Deployment]]：使用 AWS CloudFormation StackSets 跨多个 AWS 账户和区域自动部署和更新基础设施的能力，支持自动部署（新增账户自动纳入）和并行区域容错设置。
+- [[StackSets Deployment Visibility]]：StackSets 部署可观测性，通过 EventBridge 规则捕获 CloudFormation 事件（stack creation, updates, deletions, resource changes）并集中存储查询。
+
+## Key Entities
+- [[AWS CloudFormation StackSets]]：AWS 原生的跨账户/跨区域基础设施即代码部署服务，该方案的核心编排工具。
+- [[Amazon EventBridge]]：无服务器事件总线服务，用于捕获 CloudFormation 事件并跨账户转发，该方案的事件路由核心组件。
+- [[Amazon CloudWatch Logs]]：云监控日志服务，central-cloudformation-logs Log Group 存储所有账户的 CloudFormation 事件，支持 Logs Insights 自定义查询。
+- [[AWS Organizations]]：AWS 多账户组织管理服务，提供管理账户（Management Account）和成员账户（Member Accounts）层级结构，OU（Organizational Unit）用于批量配置 EventBridge 规则。
+- [[AWS KMS]]：Key Management Service，客户托管密钥用于 Log Group 加密。
+
+## Connections
+- [[AWS CloudFormation StackSets]] ← generates_events ← [[CloudWatch Logs (central-cloudformation-logs)]]
+- [[Amazon EventBridge]] ← routes_events ← [[CloudWatch Logs (central-cloudformation-logs)]]
+- [[AWS Organizations]] ← provides_account_hierarchy ← [[AWS CloudFormation StackSets]]
+- [[AWS Organizations]] ← provides_OU_scope ← [[Amazon EventBridge]] (跨账户规则部署范围)
+- [[AWS KMS]] ← encrypts ← [[CloudWatch Logs (central-cloudformation-logs)]]
+- [[Centralized Logging]] ← implemented_by ← [[Amazon EventBridge]] + [[CloudWatch Logs]]
+- [[Cross-Account Monitoring]] ← enabled_by ← [[AWS Organizations]] Trusted Access + IAM Cross-Account Roles
+- [[Multi-Account Deployment]] ← visibility_solution ← [[StackSets Deployment Visibility]]
+
+## Contradictions
+- 无已知冲突
+
+## Architecture Summary
+
+### 四组件架构
+1. **Management Account Setup**：在管理账户创建 Central Event Bus + Log Group + KMS 加密
+2. **Target Account Configuration**：通过 StackSets 自动向所有成员账户部署 EventBridge 规则
+3. **Resource Deployment**：通过 StackSets 部署 S3 等通用资源，触发 CloudFormation 事件
+4. **Monitoring and Visualization**：CloudWatch Logs Insights 查询 + 自定义告警
+
+### 事件流
+```
+目标账户 CloudFormation 事件
+  → EventBridge Rules (按模式捕获)
+  → Cross-Account Event Bus (管理账户)
+  → CloudWatch Log Group (central-cloudformation-logs)
+  → CloudWatch Logs Insights 查询
+```
+
+### CloudWatch Logs Insights 示例查询
+```
+fields @timestamp, account, region
+| parse @message /"resource-type":"(?<resource_type>[^"]+)"/ 
+| parse @message /"status":"(?<status>[^"]+)"/ 
+| parse @message /"logical-resource-id":"(?<logical_resource_id>[^"]+)"/ 
+| sort @timestamp desc
+```
+
+### 成本组件
+- Amazon EventBridge：跨账户事件发布费用
+- Amazon CloudWatch Logs：集中存储 + Logs Insights 查询费用
+- AWS KMS：客户托管密钥费用
--- a/wiki/sources/linux-运维必会的-150-个命令.md
+++ b/wiki/sources/linux-运维必会的-150-个命令.md
@@ -0,0 +1,65 @@
+---
+title: "Linux 运维必会的 150 个命令"
+type: source
+tags: [linux,运维,命令行]
+date: 2025-09-29
+---
+
+## Source File
+- [[raw/Home Office/Linux 运维必会的 150 个命令.md]]
+
+## Summary (用中文描述)
+- 核心主题：Linux 系统管理命令的全面分类参考，涵盖 150 个运维必备命令
+- 问题域：Linux 系统日常运维中的命令查询与学习
+- 方法/机制：按功能将命令分为 16 大类（帮助、文件操作、文本处理、压缩、信息显示、搜索、用户管理、网络操作、磁盘管理、权限管理、系统监控等）
+- 结论/价值：提供系统化的 Linux 命令速查清单，适合运维工程师日常参考和系统化学习
+
+## Key Claims (用中文描述)
+- Linux 命令是系统运行核心，与 DOS 命令类似，通过文件抽象管理所有资源（CPU、内存、磁盘、键盘、用户等）
+- Linux 命令分为两类：内置 Shell 命令和独立 Linux 命令
+- 150 个命令覆盖 Linux 运维的 16 个核心领域
+
+## Key Quotes
+> "Linux 命令在系统中有两种类型：内置 Shell 命令和 Linux 命令。" — 核心分类原则
+> "对于 Linux 系统来说，无论是中央处理器、内存、磁盘驱动器、键盘、鼠标，还是用户等都是文件" — Linux 一切皆文件哲学
+
+## Key Concepts
+
+### 命令分类体系（16 大类）
+
+| 类别 | 命令数 | 核心命令 |
+|------|--------|----------|
+| 线上查询及帮助命令 | 2 | man, help |
+| 文件和目录操作命令 | 18 | ls, cd, cp, find, mkdir, mv, pwd, rm, touch, tree, chmod, chown |
+| 查看文件及内容处理命令 | 21 | cat, tac, more, less, head, tail, grep, sort, uniq, wc, diff, vi/vim |
+| 文件压缩及解压缩命令 | 4 | tar, unzip, gzip, zip |
+| 信息显示命令 | 11 | uname, hostname, dmesg, uptime, du, df, top, free, date, cal |
+| 搜索文件命令 | 4 | which, find, whereis, locate |
+| 用户管理命令 | 10 | useradd, usermod, userdel, groupadd, passwd, su, sudo, visudo |
+| 基础网络操作命令 | 11 | telnet, ssh, scp, wget, ping, ifconfig, netstat, ss |
+| 深入网络操作命令 | 9 | nmap, lsof, mail, mutt, nslookup, dig, traceroute, tcpdump |
+| 有关磁盘与文件系统的命令 | 16 | mount, umount, fsck, dd, fdisk, mkfs, mkswap, sync |
+| 系统权限及用户授权相关命令 | 4 | chmod, chown, chgrp, umask |
+| 查看系统用户登陆信息的命令 | 7 | whoami, who, w, last, lastlog, users, finger |
+| 内置命令及其它 | 19 | echo, printf, rpm, yum, alias, history, time, xargs, export, bc |
+| 系统管理与性能监视命令 | 9 | chkconfig, vmstat, mpstat, iostat, sar, strace, ltrace |
+| 关机/重启/注销和查看系统信息的命令 | 6 | shutdown, halt, poweroff, logout, exit, Ctrl+d |
+| 进程管理相关命令 | 15 | bg, fg, jobs, kill, crontab, ps, pstree, nohup, pgrep |
+
+### [[Shell 命令]]：内置在 Shell 中的命令（如 cd, echo, history）
+### [[系统命令]]：独立可执行文件（如 ls, cp, grep）
+### [[管道（Pipe）]]：通过 | 连接多个命令实现数据流处理
+### [[重定向]]：通过 >, >>, < 实现输入输出重定向
+
+## Key Entities
+- [[man 命令]]：查看命令帮助的手册工具
+- [[Shell]]：命令行解释器（bash/zsh等）
+- [[文件系统]]：Linux 以文件为单位管理所有资源
+
+## Connections
+- [[Linux]] ← 基础平台 ← [[Linux 命令]]
+- [[Shell]] ← 命令执行环境 ← [[管道]]
+- [[管道]] ← 数据流处理 ← [[文本处理命令]]
+
+## Contradictions
+无明显冲突点，该文档为纯知识参考文档
--- a/wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md
+++ b/wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md
@@ -0,0 +1,81 @@
+---
+title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
+type: source
+tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
+
+## Summary (用中文描述)
+- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
+- **问题域**：macOS 服务器化运维、内网穿透、远程访问
+- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行
+- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案
+
+## Key Claims (用中文描述)
+- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
+- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
+- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
+- 软链接（symlink）策略可实现 FRP 版本无缝切换
+
+## Key Quotes
+> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
+> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
+> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
+
+## Key Concepts
+- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
+- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
+- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
+- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
+
+## Key Entities
+- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
+- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
+- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
+- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
+- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
+
+## Connections
+- [[Mac Mini M4]] ← runs_on ← [[frpc]]
+- [[VPS]] ← runs_on ← [[frps]]
+- [[frpc]] ← creates_tunnel ← [[frps]]
+- [[内网穿透]] ← enables ← [[远程SSH访问]]
+- [[launchd]] ← manages ← [[frpc]] 进程生命周期
+- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
+
+## Contradictions
+- 无已知冲突
+
+## Environment Details
+| 项目 | 内容 |
+|------|------|
+| 系统 | macOS（Mac Mini M4）|
+| 架构 | Apple Silicon (ARM64) |
+| 软件 | FRP 0.65.0 |
+| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
+| 客户端程序 | `frpc` |
+| 配置文件 | `frpc.toml` |
+| frps服务器 | 192.227.222.142:7000 |
+| frps映射端口 | 6000（SSH）|
+
+## Installation Steps
+1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
+2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
+3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
+4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
+5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
+6. 启动 frpc：`./frpc -c frpc.toml`
+
+## Background Running Methods
+1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
+2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
+3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
+
+## Best Practices
+- 统一安装路径：`/opt/frp/<version>` 便于版本管理
+- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
+- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
+- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
--- a/wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md
+++ b/wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md
@@ -0,0 +1,49 @@
+---
+title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
+type: source
+tags: [obsidian, openclaw, symbolic-link, macos]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
+
+## Summary (用中文描述)
+- **核心主题**：在 macOS 上为 OpenClaw 隐藏目录创建符号链接，使 Finder 和 Obsidian 能够直接访问
+- **问题域**：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，在图形界面中不可见，无法直接作为 Obsidian Vault 使用
+- **方法/机制**：使用 `ln -s` 创建 Symbolic Link，将 `~/.openclaw` 映射为可见的 `~/openclaw` 目录，两个路径指向同一份数据
+- **结论/价值**：符号链接让 Obsidian 可以访问 OpenClaw 的 Markdown 文件，同时保持 OpenClaw 正常工作，是一种零成本、无风险的目录可见性解决方案
+
+## Key Claims (用中文描述)
+- OpenClaw 的默认数据目录 `~/.openclaw` 是隐藏目录，Finder 和 Obsidian 无法直接访问
+- Symbolic Link（符号链接）可以将隐藏目录映射为可见目录，两个路径指向同一份数据
+- 创建符号链接 `ln -s ~/.openclaw ~/openclaw` 不会复制数据，只创建指向关系
+- 删除符号链接 `rm ~/openclaw` 只会删除链接本身，不会影响原始数据
+- 推荐的长期方案是以 `~/openclaw` 为实际目录，再用 `ln -s` 反向链接到 `~/.openclaw`，便于 Git 管理和 Finder 访问
+
+## Key Quotes
+> "该操作**只会删除链接文件，不会删除真实目录**。" — Symbolic Link 删除操作的安全性说明
+
+> "Finder / Obsidian 可直接访问；OpenClaw 兼容原路径；方便 Git 管理与备份。" — 推荐的长期目录结构三优点
+
+## Key Concepts
+- [[Symbolic Link]]：符号链接，Unix/Linux/macOS 文件系统特性，通过 `ln -s` 创建，指向另一个文件或目录的特殊文件类型
+- [[目录映射]]：将一个目录路径指向另一个目录内容的机制，使不同路径访问同一份数据
+- [[隐藏目录]]：以 `.` 开头的目录，macOS Finder 默认不显示，需用 `ls -a` 或 `Cmd+Shift+.` 可见
+
+## Key Entities
+- [[OpenClaw]]：多 Agent 框架，默认数据目录为 `~/.openclaw` 隐藏目录，本笔记的操作对象
+- [[Obsidian]]：本地 Markdown 知识库工具，可通过 Symbolic Link 将 OpenClaw 目录作为 Vault 直接打开
+
+## Connections
+- [[Obsidian]] ← 通过 Symbolic Link 访问 ← [[OpenClaw]]
+- [[OpenClaw]] ← 数据存储于 ← [[Symbolic Link]]
+
+## Contradictions
+- 无已知冲突
+
+## Aliases
+- Symbolic Link
+- 符号链接
+- symlink
+- 软链接
--- a/wiki/sources/mysql-mariadb-数据库详细信息.md
+++ b/wiki/sources/mysql-mariadb-数据库详细信息.md
@@ -0,0 +1,81 @@
+---
+title: "MySQL MariaDB 数据库详细信息"
+type: source
+tags: [database, mariadb, mysql, nas]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/MySQL MariaDB 数据库详细信息.md]]
+
+## Summary (用中文描述)
+- 核心主题：MariaDB/MySQL 数据库的访问配置信息及远程访问用户创建流程
+- 问题域：NAS 上的 MariaDB 数据库内网/公网访问配置、用户权限管理
+- 方法/机制：通过 socket 本地登录创建远程访问用户，使用 `CREATE USER` 和 `GRANT` 语句配置权限
+- 结论/价值：提供完整的 MariaDB 远程访问配置指南，解决新安装 MariaDB 后只能本地 localhost 访问的问题
+
+## Key Claims (用中文描述)
+- 新安装的 MariaDB 默认只有 `root@localhost` 账户，无法从外部机器连接
+- 远程访问需要创建 `username@%` 格式的用户（`%` 表示允许任意主机）
+- Socket 登录是本地管理员访问的安全方式，可绕过网络认证
+
+## Key Quotes
+> "你的 MariaDB 只有 `root@localhost`，并没有 `root@%` 或你要连接用的用户账号" — MariaDB 权限诊断核心问题
+
+> "CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345';" — 允许任意主机远程访问的用户创建命令
+
+## Key Concepts
+- [[Socket 登录]]：通过 Unix socket 文件进行本地认证，无需网络连接
+- [[用户权限]]：Host+User 组合决定访问权限，`%` 表示任意主机
+
+## Key Entities
+- [[MariaDB]]：开源关系型数据库，Synology NAS 上通过 Docker 部署
+- [[群晖 NAS]]：MariaDB 数据库的宿主机（IP: 192.168.3.17）
+- [[shenwei]]：数据库用户名
+
+## Connections
+- [[群晖 NAS]] ← hosts ← [[MariaDB]]
+- [[MariaDB]] ← configured_by ← Socket 登录
+
+## Contradictions
+- 无冲突
+
+## 访问配置摘要
+
+### 内网访问
+| 项目 | 值 |
+|------|-----|
+| IP | 192.168.3.17 |
+| Port | 3307 |
+| Username | shenwei |
+| Password | !Abcde12345 |
+| Root | root / !Abcde12345 |
+
+### 公网访问
+| 项目 | 值 |
+|------|-----|
+| Domain | mysql.ishenwei.online |
+| Port | 63307 |
+| Username | shenwei |
+| Password | !Abcde12345 |
+
+### Socket 登录命令
+```bash
+sudo mysql -u root -p -S /run/mysqld/mysqld10.sock
+```
+
+### 创建远程访问用户
+```sql
+CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345';
+GRANT ALL PRIVILEGES ON *.* TO 'shenwei'@'%' WITH GRANT OPTION;
+FLUSH PRIVILEGES;
+```
+
+### 查看当前用户列表
+```sql
+select host, user from mysql.user;
+```
+
+## Related Sources
+- [[Docker卷]] — Docker卷备份中使用 mysqldump 进行数据库一致性备份
+- [[ubuntu服务器通过rsync实现日常增量备份]] — 包含数据库增量备份策略
--- a/wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md
+++ b/wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md
@@ -0,0 +1,87 @@
+---
+title: "NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器"
+type: source
+tags: ["Cloudflare", "Bitwarden", "Serverless", "Password-Manager"]
+date: 2026-02-27
+---
+
+## Source File
+- [[raw/Home Office/NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器.md]]
+
+## Summary (用中文描述)
+- **核心主题**：NodeWarden 将 Bitwarden 服务器端部署到 Cloudflare Workers，实现真正的无服务器（Serverless）密码管理
+- **问题域**：传统 Bitwarden 自托管需要维护 VPS/服务器，NodeWarden 彻底消除了这一需求
+- **方法/机制**：通过 Cloudflare Workers 运行 Bitwarden API 兼容层，数据存储在 Cloudflare D1（SQLite）和 R2（对象存储），利用 Workers 的边缘计算能力实现全球低延迟访问
+- **结论/价值**：用户只需一个 Cloudflare 账号（带域名和信用卡）和 GitHub 账号，即可零成本、零运维地运行自托管密码管理器，支持 Bitwarden 官方全平台客户端
+
+## Key Claims (用中文描述)
+- NodeWarden 通过 Cloudflare Workers 实现无服务器架构，将 Bitwarden 服务器端迁移到边缘计算平台
+- Cloudflare D1（边缘 SQLite）和 R2（对象存储）替代传统 VPS 数据库，数据可靠性由 Cloudflare 保证
+- NodeWarden 在核心功能上与 Bitwarden 保持兼容，同时移除企业级功能（多用户/组织/SSO）以简化架构
+- 通过 GitHub Actions + Cloudflare Pages 实现自动化部署，更新代码只需网页操作
+- TOTP（时间同步动态口令）通过 `TOTP_SECRET` 环境变量免费支持，无需 Bitwarden 付费会员
+
+## Key Quotes
+> "部署 NodeWarden 之后的效果，就是在无服务器的情况下，也能在手机、电脑上使用 Bitwarden 客户端来保存密码了，支持自动登陆、二次验证之类的功能。" — Appinn
+
+> "这个步骤需要在 Cloudflare 中绑定 GitHub 账号，根据页面提示即可。" — NodeWarden 一键部署说明
+
+## Key Concepts
+- [[Serverless Computing]]：NodeWarden 的核心技术范式，代码运行在 Cloudflare Workers 边缘节点而非传统服务器
+- [[Edge Computing]]：Cloudflare Workers 在全球边缘节点运行，提供低延迟访问
+- [[TOTP]]：时间同步一次性密码算法，NodeWarden 通过环境变量 `TOTP_SECRET` 免费提供，无需付费会员
+- [[Passkey]]：WebAuthn 无密码认证标准，NodeWarden 原生支持（Bitwarden 官方需付费会员）
+- [[Self-Hosted Password Manager]]：自托管密码管理器，NodeWarden 是 Serverless 架构的变体
+
+## Key Entities
+- [[NodeWarden]]：GitHub 项目，将 Bitwarden 部署到 Cloudflare Workers 的开源实现，作者 shuaiplus
+- [[Bitwarden]]：开源密码管理器，客户端与服务端均开源，NodeWarden 提供 API 兼容实现
+- [[Cloudflare Workers]]：边缘计算平台，NodeWarden 的运行时环境，基于 V8 隔离的 Serverless 平台
+- [[Cloudflare D1]]：边缘 SQLite 数据库，NodeWarden 的主数据存储
+- [[Cloudflare R2]]：S3 兼容对象存储，NodeWarden 用于存储附件
+- [[Cloudflare]]：提供 Workers/D1/R2 的云平台，构成 NodeWarden 的完整基础设施
+- [[shuaiplus]]：NodeWarden GitHub 项目作者
+- [[shenwei]]：本文档原作者（Appinn 作者），已部署 NodeWarden 实例
+
+## Connections
+- [[NodeWarden]] ← implements ← [[Bitwarden]]
+- [[NodeWarden]] ← runs_on ← [[Cloudflare Workers]]
+- [[NodeWarden]] ← uses ← [[Cloudflare D1]]
+- [[NodeWarden]] ← uses ← [[Cloudflare R2]]
+- [[NodeWarden]] ← deploys_via ← [[GitHub Actions]]
+- [[Bitwarden]] ← alternative_to ← [[1Password]]
+- [[Bitwarden]] ← alternative_to ← [[LastPass]]
+
+## Contradictions
+- 无已知冲突
+
+## NodeWarden vs Bitwarden 功能对比
+
+| 能力项 | Bitwarden | NodeWarden | 说明 |
+| --- | --- | --- | --- |
+| 单用户保管库 | ✅ | ✅ | 基于 Cloudflare D1 |
+| 文件夹/收藏 | ✅ | ✅ | 常用管理能力可用 |
+| 全量同步 `/api/sync` | ✅ | ✅ | 已做兼容与性能优化 |
+| 附件上传/下载 | ✅ | ✅ | 基于 Cloudflare R2 |
+| 导入功能 | ✅ | ✅ | 覆盖常见导入路径 |
+| 网站图标代理 | ✅ | ✅ | 通过 `/icons/{hostname}/icon.png` |
+| Passkey、TOTP | ❌ | ✅ | 官方需要会员，NodeWarden 免费 |
+| 多用户 | ✅ | ❌ | NodeWarden 定位单用户 |
+| 组织/集合/成员权限 | ✅ | ❌ | 没必要实现 |
+| 登录 2FA（TOTP/WebAuthn/Duo/Email） | ✅ | ⚠️ 部分支持 | 仅支持 TOTP（通过 `TOTP_SECRET`） |
+| SSO / SCIM / 企业目录 | ✅ | ❌ | 没必要实现 |
+| Send | ✅ | ❌ | 基本没人用 |
+| 紧急访问 | ✅ | ❌ | 没必要实现 |
+| 管理后台/计费订阅 | ✅ | ❌ | 纯免费 |
+| 推送通知完整链路 | ✅ | ❌ | 没必要实现 |
+
+## 部署必要条件
+1. Cloudflare 账号（必须有一个域名和信用卡）
+2. GitHub 账号
+
+## 部署步骤
+1. Fork [NodeWarden GitHub 仓库](https://github.com/shuaiplus/NodeWarden)
+2. 在 Cloudflare 页面点击"Deploy to Cloudflare"一键部署
+3. 访问临时地址或绑定自定义域名
+4. 通过设置页面配置：JWT_SECRET、自动更新、主账号密码、TOTP 二次验证
+5. 在 Bitwarden 官方客户端选择"自托管"，输入服务器 URL 即可登录
--- a/wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md
+++ b/wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md
@@ -0,0 +1,61 @@
+---
+title: "Public vs Private vs Hybrid Cloud Differences Explained"
+type: source
+tags: []
+date: 2025-06-18
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md]]
+
+## Summary (中文)
+- **核心主题**：公有云、私有云、混合云三种云部署模型的定义、优缺点、适用场景及选择决策框架
+- **问题域**：云部署策略选择；成本 vs 安全 vs 性能 vs 可扩展性的权衡
+- **方法/机制**：三种云模型的结构化对比；共享责任模型；混合云的同构/异构决策
+- **结论/价值**：云部署选择没有标准答案，需根据工作负载特点、预算、IT能力制定有意的云策略（intentional cloud strategy），且需持续平衡调整
+
+## Key Claims (中文)
+- 公有云通过多租户共享模式提供弹性扩展能力，但缺乏成本控制（大规模使用时TCO指数增长）和安全控制
+- 私有云提供独占环境带来更高性能和安全性，适合受监管行业和敏感数据，但TCO高且远程访问受限
+- 混合云通过在公私之间按策略分配工作负载，实现安全与弹性的平衡，但引入成本管理和集成的复杂性
+- 无论选择哪种云模型，云安全问题（访问控制、加密、灾难恢复）始终由用户组织与供应商共同承担——即"共享责任模型"
+
+## Key Quotes
+
+> "The rapid switch from local to cloud computing is driven by benefits such as the ability to scale without having to buy and configure hardware, accessibility from anywhere with an internet connection, professionally managed servers that are kept up-to-date with the latest tech and versions of apps, cost efficiency, and quick recovery from cyber attacks." — 云采用的核心驱动因素概述
+
+> "The choice between public vs private vs hybrid cloud solutions depends on your use cases, budget, IT capabilities, and expectations for growth. It is rarely an either/or situation, as you may find ways to capture the benefits of each while avoiding the drawbacks." — 云部署选择的核心洞察
+
+> "It is important to know that no matter which cloud environment you work in, your problems don't go away... your organization maintains responsibility for: Who has access to what, Cloud security and encryption, Disaster recovery planning." — 共享责任模型的核心
+
+## Key Concepts
+
+- [[Public Cloud]]：通过互联网交付、多租户共享的云服务模式（AWS、Azure、GCP）
+- [[Private Cloud]]：专属于单一组织的云环境，通过私有网络访问，可本地托管或第三方托管
+- [[Hybrid Cloud]]：同时使用公有云和私有云的混合环境，在两者之间按策略分配工作负载
+- [[Shared Responsibility Model]]：云安全由供应商和组织共同承担的安全责任划分模型
+- [[Cloud Elasticity]]：云环境快速扩展或收缩资源的能力，无需硬件采购和配置
+- [[CapEx-vs-OpEx]]：资本支出（前期硬件投入）与运营支出（按需付费）的对比
+- [[Cost Agility]]：根据业务需求灵活调整云资源消耗以控制成本的能力
+- [[SLA]]：服务级别协议，定义云服务可用性和性能保证
+- [[Disaster Recovery Planning]]：灾难恢复规划，云环境下的业务连续性保障
+
+## Key Entities
+
+- [[BMC]]：BMC Software — 企业IT管理解决方案提供商，文章原出处
+- [[BMC Helix]]：BMC 旗下AI运维平台，帮助IT组织将AI转化为行动
+
+## Connections
+
+- [[Public Cloud]] ← depends_on ← [[Cloud Infrastructure]]
+- [[Private Cloud]] ← depends_on ← [[Cloud Infrastructure]]
+- [[Hybrid Cloud]] ← combines ← [[Public Cloud]] AND [[Private Cloud]]
+- [[Cloud Adoption Strategy]] ← informs ← [[Public Cloud]] / [[Private Cloud]] / [[Hybrid Cloud]] 选择
+- [[FinOps]] ← constrains ← [[Cost Agility]]
+- [[Shared Responsibility Model]] ← applies_to ← ALL three cloud models
+- [[SLA]] ← guarantees ← [[High Availability]]
+- [[Multi-Cloud Strategy]] ← related_to ← [[Hybrid Cloud]]（有重叠但不同）
+
+## Contradictions
+
+- **公有云安全 vs 私有云安全**：文章认为"公有云安全性最低（least secure）"，但[[Cloud Computing]] entity页面引用的Myth 1真相认为"云比本地更安全"。当前观点：两者描述的角度不同——本文从多租户共享模型角度认为公有云安全性最低；Myth 1从整体云安全投入（加密、MFA、ISO 27001）角度认为云比本地安全。两者均为有效视角，安全最终取决于具体实现而非部署模型本身。
--- a/wiki/sources/rax50-路由器-更新merlin-clash订阅.md
+++ b/wiki/sources/rax50-路由器-更新merlin-clash订阅.md
@@ -0,0 +1,48 @@
+---
+title: "RAX50 路由器更新Merlin Clash订阅"
+type: source
+tags: [clash, merlin-clash, rax50]
+date: 2026-03-04
+---
+
+## Source File
+- [[raw/Home Office/RAX50 路由器 更新Merlin Clash订阅.md]]
+
+## Summary (用中文描述)
+- 核心主题：如何在 RAX50 路由器的 Merlin Clash 界面中更新科学上网订阅配置
+- 问题域：家庭网络科学上网订阅的日常维护与配置切换
+- 方法/机制：通过路由器 Web 管理界面进入 Merlin Clash，使用小白一键订阅助手导入 vless URL 并切换配置文件，最后通过快速重启使新订阅生效
+- 结论/价值：提供了一套完整的订阅更新操作流程，包含故障排查步骤（快速重启），适合非技术用户在路由器端维护科学上网配置
+
+## Key Claims (用中文描述)
+- 用户通过 RAX50 路由器管理界面（Web UI）可访问 Merlin Clash 配置界面
+- Merlin Clash 支持导入 vless URL 订阅
+- 小白一键订阅助手可管理多个订阅配置文件，并支持重命名（如 kiwi3）
+- 切换配置文件后需点"保存&启动"，若未生效则执行"快速重启"
+
+## Key Quotes
+> "进入RAX50路由器管理界面" — 起点操作，进入路由器 Web 管理后台
+> "在RAX50的Merlin Clash界面，复制vless url进到小白一键订阅助手，并重命名配置文件比如 kiwi3" — 订阅导入与配置文件命名操作
+> "选择新建的配置文件，点保存&启动，如果不行，就再点一次快速重启" — 订阅切换与故障处理
+
+## Key Concepts
+- [[订阅更新]]：在路由器层面重新导入新的代理节点订阅 URL，使路由器获得最新的代理节点列表
+- [[配置文件切换]]：在 Merlin Clash 中保存并激活不同的订阅配置文件，以切换不同的科学上网策略
+- [[快速重启]]：Merlin Clash 提供的轻量重启机制，用于在不重启整台路由器的情况下重新加载插件配置，解决订阅更新后未生效的问题
+
+## Key Entities
+- [[网件RAX50]]：NETGEAR WiFi 6 路由器，刷入梅林固件后支持 Merlin Clash 插件
+- [[MerlinClash插件]]：运行在梅林固件上的科学上网插件，基于 Clash 核心，支持多配置文件和订阅管理
+- [[小白一键订阅助手]]：Merlin Clash 内置的订阅管理工具，支持导入 vless/vmess 等多种协议的订阅 URL，并可创建和管理多个命名配置文件
+- [[机场]]：提供 VLESS 订阅 URL 的服务商，用户从此来源获取最新的节点列表
+
+## Connections
+- [[RAX50路由器刷梅林固件与科学上网]] ← 前置操作 ← 当前页面（订阅更新为同一台路由器的持续维护操作）
+- [[MerlinClash插件]] ← 提供插件能力 ← 当前页面
+- [[机场]] ← 提供 vless URL ← 当前页面
+
+## Contradictions
+- 无冲突
+
+## Related Source
+- [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]]：RAX50 刷梅林固件 + 安装 Merlin Clash 的完整前置流程
--- a/wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md
+++ b/wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md
@@ -0,0 +1,89 @@
+---
+title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
+type: source
+tags: [cloud, devops, disaster-recovery, feature-flags, continuous-delivery]
+date: 2025-07-26
+---
+
+## Source File
+- [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]]
+
+## Summary (用中文描述)
+- **核心主题**：现代持续交付场景下 RTO（恢复时间目标）和 RPO（恢复点目标）的区别，以及 Feature Flag 如何实现秒级恢复
+- **问题域**：传统灾备只关注硬件故障，而现代软件交付的最大风险来自代码变更本身
+- **方法/机制**：
+  - RTO 衡量系统停机时间，RPO 衡量数据丢失量
+  - Feature Flag 将部署与发布解耦，支持微恢复（feature 级别回滚）
+  - Kill Switch 实现配置级热切换，无需重新部署
+  - Progressive Rollout 通过分阶段放量控制影响范围
+- **结论/价值**：预防优于恢复；Feature Flag 工具（如 LaunchDarkly）可实现秒级 RTO、近零 RPO，远比传统灾备基础设施性价比高
+
+## Key Claims (用中文描述)
+- Feature Flag 将部署（deploy）与发布（release）解耦，实现配置级热修复 → RTO 从小时降至秒级
+- 渐进式放量（Progressive Rollout）将影响范围限制在 1% 用户 → 包含损害，RTO 以秒计
+- Kill Switch 支持支付网关、搜索算法、AI 模型等任意组件的热切换 → 无需重新部署代码
+- Feature Flag 回滚不丢失数据（只切换代码路径） → RPO 始终保持近零
+- 传统灾备规划关注硬件故障，但现代交付中代码变更频率更高、风险更大
+- 应用分层级保护（Tier 1/2/3），而非对所有系统一刀切 Tier 1
+- HP 将回滚时间从小时缩短到分钟，Christian Dior 从 15 分钟降至即时切换
+
+## Key Quotes
+> "RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — RTO 的本质是系统下线那一刻开始的倒计时
+> "RPO is about protecting data. It's measured backwards from the moment of failure." — RPO 从故障时刻向后追溯可接受的数据丢失窗口
+> "Deploy whenever you want, release when you're ready." — Feature Flag 的核心理念：部署与发布分离
+> "Prevention beats cure." — 预防优于恢复，减少故障比快速恢复更有价值
+> "Your RTO drops to seconds because fixing issues becomes a configuration change, not a code deployment." — Feature Flag 将修复变成配置变更而非代码部署
+> "86% of surveyed LaunchDarkly customers recover from incidents within a day." — LaunchDarkly 客户事故恢复数据
+
+## Key Concepts
+- [[RTO]]：Recovery Time Objective，系统可容忍的最大停机时间，衡量恢复速度
+- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量，衡量数据保护程度
+- [[Feature Flag]]：功能开关，将代码部署与功能发布解耦，支持热切换
+- [[Kill Switch]]：应急切断开关，紧急情况下绕过故障组件的机制
+- [[Progressive Rollout]]：渐进式放量，分阶段向用户群发布新功能
+- [[Micro-Recovery]]：feature 级别细粒度恢复，无需回滚整个部署
+- [[Deployment-vs-Release]]：部署（代码到达生产）与发布（用户可见）的分离
+- [[Business Impact Analysis]]：业务影响分析，用于确定不同应用的分层保护级别
+
+## Key Entities
+- [[LaunchDarkly]]：Feature Flag 管理平台，HP、Christian Dior 等企业的 RTO/RPO 优化案例
+- [[Veeam]]：传统灾备工具（数据库备份、服务器镜像）
+- [[Acronis]]：传统灾备工具（跨区域复制）
+- [[HP]]：HP 案例——Feature Flag 将回滚时间从小时缩短到分钟
+- [[Christian Dior]]：Christian Dior 案例——回滚从 15 分钟降至即时切换
+
+## Connections
+- [[Disaster Recovery]] ← extends ← [[RTO]] + [[RPO]]（RTO/RPO 是灾备的核心指标）
+- [[Deployment-Automation]] ← depends_on ← [[Feature Flag]]（Feature Flag 是现代部署自动化的基础设施）
+- [[CI-CD-Pipeline]] ← extends ← [[Deployment-vs-Release]]（持续交付中的部署与发布分离）
+- [[High Availability]] ← depends_on ← [[Kill Switch]]（Kill Switch 是 HA 的应急保障机制）
+- [[LaunchDarkly]] ← implements ← [[Feature Flag]]（LaunchDarkly 是 Feature Flag 的商业实现）
+- [[Feature Flag]] ← enables ← [[Progressive Rollout]]（Feature Flag 支持渐进式放量）
+
+## Contradictions
+- 与传统灾备观点冲突：
+  - **冲突点**：传统灾备投资（热备服务器、跨区域复制）vs Feature Flag 方案
+  - **当前观点**（本文）：软件优先方法（Feature Flag + Kill Switch）ROI 更高；HP 案例显示 8% 客户运维成本降低超 50%
+  - **对方观点**（传统 DR）：关键业务系统需要完整的基础设施冗余（Active-Active、跨区域热备）
+
+## Tiering Reference Table
+
+| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 |
+|------|------|----------|----------|----------|
+| (1) Critical | 支付处理、用户认证 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 |
+| (2) Important | 管理后台、报表 | < 1 小时 | < 15 分钟 | Feature Flag（主要发布）+ 业务时间监控 |
+| (3) Nice-to-have | 内部工具、文档站 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 |
+
+## Application Criticality Questions
+
+**If down for an hour:**
+- Lost revenue? How much?
+- Angry customers? How many?
+- Blocked employees? Can they work around it?
+- Regulatory issues? Legal problems?
+
+**If losing last hour of data:**
+- Can we recreate it?
+- Does it contain money/transactions?
+- Will users notice?
+- Is it required for compliance?
--- a/wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md
+++ b/wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md
@@ -1,62 +1,75 @@
 ---
 title: "The Myths and Misconceptions About Cloud Computing | LinkedIn"
-source: https://www.linkedin.com/pulse/myths-misconceptions-cloud-computing-raj-vardhan-singh-w86mc/?trackingId=rM%2B%2BhFXj9kp11hppPbPFkQ%3D%3D
-author: shenwei
-published: 2001-02-25
-created: 2025-03-02
-description:
-tags: []
+type: source
+tags: [cloud-computing, myths, misconceptions, cloud-migration]
+date: 2025-03-02
 ---

-# The Myths and Misconceptions About Cloud Computing
-
-Cloud computing has revolutionized the way businesses and individuals manage data, applications, and IT infrastructure. However, despite its widespread adoption, many myths and misconceptions persist, leading to confusion and hesitation among potential users. In this article, we debunk some of the most common cloud computing myths to provide a clearer understanding of its capabilities and limitations.
-
-## Myth 1: Cloud Computing is Not Secure
-
-### Reality: Cloud Security is Often More Robust Than On-Premises Solutions
-
-One of the biggest misconceptions about cloud computing is that it is inherently insecure. In reality, leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication. Many cloud platforms comply with stringent industry standards such as ISO 27001, HIPAA, and GDPR. Additionally, cloud providers offer automated security updates and 24/7 monitoring, reducing the risk of breaches compared to traditional on-premises systems.
-
-## Myth 2: The Cloud is Just Someone Else's Computer
-
-### Reality: The Cloud is a Vast Network of Data Centers with Advanced Infrastructure
-
-While it is true that cloud services rely on remote servers, they are far more than just "someone else's computer." Cloud providers operate highly sophisticated data centers with redundancy, scalability, and high availability. These infrastructures are designed to handle massive workloads, offer automated failover, and provide secure, scalable computing power that surpasses typical on-premises solutions.
-
-## Myth 3: Cloud Computing is Too Expensive
-
-### Reality: Cloud Computing Can Be Cost-Effective with Proper Management
-
-Some organizations assume that moving to the cloud will lead to skyrocketing costs. However, cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed. Cost optimization strategies such as reserved instances, auto-scaling, and serverless computing help reduce expenses. Additionally, eliminating the need for on-premises hardware, maintenance, and upgrades often results in significant cost savings.
-
-## Myth 4: You Lose Control Over Your Data in the Cloud
-
-### Reality: Cloud Services Provide Extensive Data Control and Management Tools
-
-A common fear is that once data is in the cloud, companies lose control over it. However, cloud providers offer robust data governance tools, allowing organizations to manage permissions, encrypt data, and monitor access logs. Additionally, many cloud services provide hybrid and multi-cloud options, enabling businesses to maintain control over where and how their data is stored.
-
-## Myth 5: Cloud Computing is Only for Large Enterprises
-
-### Reality: Businesses of All Sizes Can Benefit from the Cloud
-
-While large enterprises have been early adopters, cloud computing is highly accessible to small and medium-sized businesses (SMBs). Cloud platforms offer flexible pricing, allowing SMBs to leverage enterprise-grade technology without large upfront investments. Many startups and small businesses rely on cloud solutions for agility, scalability, and cost savings.
-
-## Myth 6: Migration to the Cloud is Too Complex and Risky
-
-### Reality: Cloud Migration Can Be Smooth with Proper Planning
-
-Although migrating to the cloud requires careful planning, cloud providers offer extensive tools and support to facilitate the process. Strategies like phased migration, hybrid cloud solutions, and professional cloud migration services help mitigate risks and ensure a smooth transition. With the right approach, businesses can move workloads to the cloud with minimal disruption.
-
-## Myth 7: Cloud Performance is Unreliable
-
-### Reality: Cloud Providers Offer High Availability and Redundancy
-
-Some believe that cloud-based services are prone to frequent outages. However, major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%. Redundant infrastructure, automated failover, and global data center distribution enhance reliability, making cloud solutions highly resilient.
-
-## Last but not least
-
-Cloud computing is often misunderstood due to persistent myths and misconceptions. In reality, the cloud offers **enhanced security, cost-effectiveness, scalability, and control over data**. By debunking these myths, businesses, and individuals can make informed decisions about adopting cloud technology to drive efficiency and innovation.
-
 ## Source File
 - [[raw/Cloud & DevOps/The Myths and Misconceptions About Cloud Computing  LinkedIn.md]]
+
+## Summary (中文描述)
+- **核心主题**：云计算领域常见的七大误解与真相，澄清企业和个人对云安全、成本、控制权、适用性、迁移复杂性及可靠性的认知误区。
+- **问题域**：云计算认知偏差、安全焦虑、成本管理、数据主权、技术门槛、性能预期。
+- **方法/机制**：通过逐一反驳误区，提供云服务商的安全投入、架构设计、计费模式、治理工具等实证依据。
+- **结论/价值**：破除误解后，企业和个人可以更理性地评估和采用云技术，推动业务效率和创新。
+
+## Key Claims (中文描述)
+- 云安全机制（加密、防火墙、MFA）+ 合规认证（ISO 27001、HIPAA、GDPR）+ 自动化监控，使云安全优于传统本地部署。
+- 云不是"别人的电脑"，而是覆盖冗余、自动故障转移和高可用性设计的大规模数据中心网络。
+- 按需付费（Pay-as-you-go）+ 预留实例 + 自动扩缩容 + 无服务器计算，可显著降低总拥有成本。
+- 云平台提供完善的权限管理、数据加密和访问日志监控，企业对数据拥有完全控制权。
+- 云服务对小微企业（SMB）和初创企业同样友好，支持灵活定价和企业级技术。
+- 阶段式迁移、混合云方案和专业迁移服务可以有效降低云迁移的复杂性和风险。
+- 主流云服务商 SLA 保障 99.99% 可用性，全球数据中心分布和冗余架构确保高可靠性。
+
+## Key Quotes
+> "One of the biggest misconceptions about cloud computing is that it is inherently insecure. In reality, leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 安全误解的典型论点
+
+> "While it is true that cloud services rely on remote servers, they are far more than just 'someone else's computer.' Cloud providers operate highly sophisticated data centers with redundancy, scalability, and high availability." — "云即他者之电脑"误解的澄清
+
+> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费模式核心定义
+
+> "major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%" — SLA 可用性保障
+
+## Key Concepts
+- [[cloud-computing]]：通过互联网按需提供计算资源（服务器、存储、数据库、网络等），无需本地维护。
+- [[Pay-as-you-go]]：按使用量付费的计费模式，是云计算的核心经济模型。
+- [[cloud-security]]：云环境下的安全实践，包括加密、MFA、防火墙、合规认证和 24/7 监控。
+- [[Data-Governance]]：云平台提供的权限管理、数据加密和访问日志监控能力。
+- [[High-Availability]]：通过冗余基础设施和自动化故障转移实现的高可用性架构。
+- [[Failover]]：主系统故障时自动切换到备用系统的机制。
+- [[SLA]]：服务等级协议，云服务商对可用性的正式承诺（如 99.99% uptime）。
+- [[cloud-migration]]：将工作负载从本地迁移到云端的过程，需合理规划以降低风险。
+- [[Cost-Optimization]]：通过预留实例、自动扩缩容和无服务器计算降低云支出。
+- [[Multi-factor-Authentication]]：多因素认证，云安全的基础机制之一。
+- [[Scalability]]：云平台根据负载动态扩展资源的能力。
+
+## Key Entities
+- [[ISO-27001]]：国际信息安全管理体系标准，云服务商合规认证之一。
+- [[HIPAA]]：美国健康信息隐私法规，云服务商合规认证之一（医疗行业）。
+- [[GDPR]]：欧盟通用数据保护条例，云服务商合规认证之一。
+- [[AWS]]：亚马逊云科技，主流云服务商之一。
+- [[Azure]]：微软云平台，主流云服务商之一。
+- [[Google-Cloud]]：谷歌云平台，主流云服务商之一。
+- [[Raj-Vardhan-Singh]]：本文作者（LinkedIn 发布）。
+
+## Connections
+- [[cloud-computing]] ← foundational_for ← [[cloud-migration]]
+- [[cloud-computing]] ← requires ← [[cloud-security]]
+- [[cloud-computing]] ← enabled_by ← [[High-Availability]]
+- [[cloud-computing]] ← enabled_by ← [[Scalability]]
+- [[cloud-computing]] ← enabled_by ← [[Cost-Optimization]]
+- [[cloud-security]] ← enforced_by ← [[ISO-27001]]
+- [[cloud-security]] ← enforced_by ← [[HIPAA]]
+- [[cloud-security]] ← enforced_by ← [[GDPR]]
+- [[cloud-computing]] ← supported_by ← [[AWS]]
+- [[cloud-computing]] ← supported_by ← [[Azure]]
+- [[cloud-computing]] ← supported_by ← [[Google-Cloud]]
+- [[cloud-migration]] ← requires ← [[Failover]]
+- [[cloud-computing]] ← governed_by ← [[SLA]]
+- [[Pay-as-you-go]] ← enables ← [[Cost-Optimization]]
+
+## Contradictions
+- 与 [[on-premises]] 的对比：本文认为云在安全、成本、控制方面优于本地部署，与某些企业 IT 保守派观点（"数据必须留在本地"）存在冲突。该冲突集中在数据主权和合规要求层面，非技术能力层面。
+- 与传统采购模式对比：本文主张 Pay-as-you-go 更经济，但未提及长期运行稳定工作负载时预留实例的复杂性，以及超大规模迁移初期的隐性成本（ egress 流量、数据传输费用）。
--- a/wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md
+++ b/wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md
@@ -0,0 +1,63 @@
+---
+title: "These 6 Linux Apps Let You Monitor System Resources in Style"
+type: source
+tags: [linux, system-monitoring, devops-tools, open-source]
+date: 2025-12-18
+---
+
+## Source File
+- [[raw/Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
+
+## Summary (中文描述)
+- **核心主题**：介绍6款Linux系统资源监控工具，涵盖TUI（文本界面）和GUI两大类
+- **问题域**：Linux系统监控、进程管理、性能分析
+- **方法/机制**：
+  - TUI工具：Btop++（综合最强）、Htop（轻量）、Glances（超轻）、Bottom（图表为主）
+  - GUI工具：Mission Center（类Windows任务管理器）、Stacer（功能最全）
+- **结论/价值**：作者首推Btop++，兼具美观与实用；需要GUI则选Mission Center或Stacer
+
+## Key Claims (中文描述)
+- **Btop++** 通过提供CPU/内存/网络/存储实时面板、交互式进程管理（f搜索、t终止、k强杀、Nice值调整）成为作者最爱
+- **Htop** 以极简键盘驱动（F3搜索、F9终止、F7/F8调整优先级）提供轻量级进程监控
+- **Glances** 以纯键盘驱动和超轻量特性，适合SSH远程访问场景
+- **Bottom** 专注实时性能图表绘制，不提供交互式进程管理
+- **Mission Center** 以类Windows任务管理器的图形界面（性能/应用/服务三标签）提供友好体验
+- **Stacer** 提供最全面的功能集（监控+启动项管理+包卸载+GNOME设置+缓存清理）
+
+## Key Quotes
+> "TUI apps make the best resource monitors — they're snappy and responsive, even when the GUI is lagging." — 作者偏好TUI工具的核心原因
+> "Btop++ always gets my vote. It features a nice balance between usability and aesthetics." — 作者最终推荐
+> "Mission Center is your friend" if you want something close to the Windows Task Manager. — GUI替代方案推荐
+
+## Key Concepts
+- [[TUI]]：文本用户界面，在终端运行的交互式图形化程序
+- [[Resource Monitor]]：系统资源监控工具，用于追踪CPU/内存/磁盘/网络使用情况
+- [[Process Management]]：进程管理，包括查看、搜索、终止、优先级调整
+- [[System Monitoring]]：系统监控，覆盖硬件资源与运行状态的实时观测
+- [[SSH Remote Access]]：通过SSH远程访问服务器进行系统管理
+
+## Key Entities
+- [[Btop++]]：作者的Top Pick TUI资源监控器，支持主题定制和信号发送
+- [[Htop]]：轻量级TUI进程监控器，键盘驱动（F3/F7/F8/F9）
+- [[Glances]]：超轻量键盘驱动监控器，支持Arch/Debian/Snap安装
+- [[Bottom]]：专注实时图表的TUI监控器，支持进程树视图
+- [[Mission Center]]：类Windows任务管理器的GUI监控应用，支持Snap安装
+- [[Stacer]]：功能最全的GUI监控工具，包含系统维护套件
+- [[HowToGeek]]：技术博客，文章来源
+
+## Connections
+- [[TUI]] ← 应用类型 ← [[Btop++]], [[Htop]], [[Glances]], [[Bottom]]
+- [[GUI]] ← 应用类型 ← [[Mission Center]], [[Stacer]]
+- [[Process Management]] ← 核心功能 ← [[Btop++]], [[Htop]], [[Glances]], [[Mission Center]], [[Stacer]]
+- [[System Monitoring]] ← 核心功能 ← all 6 tools
+- [[SSH Remote Access]] ← 使用场景增强 ← [[TUI]] tools
+
+## Contradictions
+- 无已知冲突
+
+## Metadata
+- **Author**: shenwei
+- **Published**: 2025-12-16
+- **Source URL**: https://www.howtogeek.com/these-linux-apps-let-you-monitor-system-resources-in-style/
+- **Platform**: Linux
+- **License**: HowToGeek
--- a/wiki/sources/ubuntu-24-04-enable-ssh.md
+++ b/wiki/sources/ubuntu-24-04-enable-ssh.md
@@ -0,0 +1,57 @@
+---
+title: "Ubuntu 24.04 启动 SSH 服务"
+type: source
+tags: [ssh, ubuntu, systemd, firewall]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu 24.04 enable SSH.md]]
+
+## Summary (用中文描述)
+- 核心主题：Ubuntu 24.04 中 SSH 服务的安装、启动与配置
+- 问题域：Linux 服务器远程访问与网络安全
+- 方法/机制：
+  - 安装 OpenSSH Server 软件包
+  - 使用 systemctl 管理 SSH 服务（含开机自启）
+  - 配置 UFW 防火墙放行 SSH（端口 22）
+  - **Ubuntu 24.04 关键变化：默认使用 ssh.socket 激活机制**，即按需启动（连接请求来时才启动 sshd 守护进程）
+  - 可通过 systemctl edit ssh.socket 修改监听端口
+  - 可切换回传统 ssh.service 持续运行模式
+- 结论/价值：Ubuntu 24.04 SSH 入门完整操作指南，含传统模式切换方案
+
+## Key Claims (用中文描述)
+- Ubuntu 24.04 默认使用 **ssh.socket 激活机制**，服务状态 `inactive` 不代表 SSH 不可用，需检查 `ssh.socket` 监听状态
+- 修改自定义端口（例 2222）推荐通过 `systemctl edit ssh.socket` 而非仅修改 `/etc/ssh/sshd_config`
+- 若需 SSH 持续后台运行，可执行 `systemctl disable --now ssh.socket` + `systemctl enable --now ssh.service`
+
+## Key Quotes
+> "在 Ubuntu 24.04 中，你可以使用以下命令来确保服务处于活动状态并随系统启动：sudo systemctl start ssh; sudo systemctl enable ssh" — 标准启动与自启命令
+
+> "如果你发现 systemctl status ssh 显示服务未运行，别担心。24.04 默认使用 Socket 激活模式。你可以通过 sudo systemctl status ssh.socket 检查监听状态" — Ubuntu 24.04 行为的关键说明
+
+## Key Concepts
+- [[Socket Activation]]：systemd 机制，服务按需启动（ssh.socket 监听端口，有连接时才启动 ssh.service）
+- [[UFW 防火墙]]：Ubuntu 默认防火墙，通过 `ufw allow ssh` 放行 SSH 流量
+- [[开机自启]]：systemd enable 命令将服务注册为开机启动
+- [[远程访问]]：通过 SSH 协议从另一台设备连接服务器
+- [[按需服务]]（On-Demand Service）：ssh.socket 代表的启动模式，节省资源
+
+## Key Entities
+- [[Ubuntu 24.04]]：Canonical Ubuntu LTS 版本，默认引入 ssh.socket 激活机制
+- [[OpenSSH Server]]：Ubuntu SSH 服务端软件包，提供 sshd 守护进程
+- [[UFW]]（Uncomplicated Firewall）：Ubuntu 默认防火墙管理工具
+- [[ssh.socket]]：systemd 的 socket 单元，负责监听 22 端口并按需触发 ssh.service
+- [[ssh.service]]：systemd 的 service 单元，实际运行 sshd 守护进程
+
+## Connections
+- [[UFW 防火墙]] ← enables ← [[Ubuntu 24.04 启动 SSH 服务]]
+- [[OpenSSH Server]] ← installed_by ← [[Ubuntu 24.04 启动 SSH 服务]]
+- [[Socket Activation]] ← is_activated_by ← [[ssh.socket]]
+- [[ssh.service]] ← substitutes ← [[ssh.socket]]（传统模式切换）
+
+## Contradictions
+- 与旧版 Ubuntu SSH 行为冲突：
+  - 冲突点：旧版 `systemctl status ssh` 显示 `active (running)` 才代表正常；24.04 中服务可能显示 `inactive` 但 SSH 仍可正常工作
+  - 当前观点：Socket 激活是 Ubuntu 24.04 默认行为，不代表故障
+  - 对方观点：服务未 running 即认为 SSH 未启用
--- a/wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md
+++ b/wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md
@@ -0,0 +1,127 @@
+---
+title: "Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记"
+type: source
+tags: [frp, frpc, ubuntu, systemd, x86_64]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记.md]]
+
+## Summary (用中文描述)
+- **核心主题**：在 Ubuntu Server 24.04（x86_64/amd64）上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地 SSH 服务
+- **问题域**：Linux 服务器运维、内网穿透、服务管理
+- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，通过 systemd 实现开机自启和进程管理
+- **结论/价值**：提供完整的 Ubuntu Server FRP 运维手册，包含 systemd 服务管理、最佳实践和故障排查指南；与 Mac Mini ARM64 版本形成完整的多平台覆盖
+
+## Key Claims (用中文描述)
+- Ubuntu Server 24.04 需手动创建 `/opt/frp` 安装目录
+- FRP 0.65.0 使用 TOML 配置文件格式（frpc.toml）
+- systemd 是 Ubuntu/Linux 生产环境推荐的服务管理方式
+- 通过软链接（symlink）策略可实现版本无缝切换，无需修改 systemd 配置
+- journald 日志是 systemd 环境的推荐日志管理方案
+
+## Key Quotes
+> "login to server success" — frpc 成功连接 frps 的日志标志
+> "proxy added: ssh" — SSH 代理成功注册的日志标志
+> "Restart=on-failure + RestartSec=10" — systemd 服务自动恢复配置，确保服务中断后自动重启
+> "升级时只需要切换 symlink，无需修改 systemd 配置" — 软链接策略的核心价值
+
+## Key Concepts
+- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
+- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
+- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
+- [[systemd]]：Linux 系统和服务管理器，Ubuntu Server 的默认初始化系统，用于管理 FRP 客户端开机自启
+- [[软链接策略]]：通过 `/opt/frp/current` 软链接指向具体版本目录，实现版本切换无需修改 systemd 配置
+
+## Key Entities
+- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142，端口: 7000）
+- [[frpc]]：FRP 客户端程序，运行在 Ubuntu Server 上，建立与 frps 的反向隧道
+- [[frps]]：FRP 服务端程序，运行在 VPS 上，监听 7000 端口，接收 frpc 连接并转发请求
+- [[Ubuntu Server]]：Canonical 维护的 Linux 服务器操作系统，本次安装目标为 24.04 LTS 版本
+- [[systemd]]：Linux 系统和服务管理器，Ubuntu Server 24.04 的默认初始化系统
+
+## Connections
+- [[Ubuntu Server]] ← runs_on ← [[frpc]]
+- [[VPS]] ← runs_on ← [[frps]]
+- [[frpc]] ← creates_tunnel ← [[frps]]
+- [[systemd]] ← manages ← [[frpc]] 进程生命周期
+- [[内网穿透]] ← enables ← [[远程SSH访问]]
+- [[软链接策略]] ← simplifies ← [[版本升级]]（无需修改 systemd 配置）
+
+## Contradictions
+- 与 [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] 存在**平台差异**：
+  - 差异点：服务管理机制（Ubuntu 用 systemd，macOS 用 launchd）
+  - 当前观点：systemd 是 Linux 生产环境标准，配置简单（service 文件 + systemctl 命令）
+  - 对方观点：launchd 是 macOS 原生方案，通过 plist + launchctl 管理
+  - 结论：两个平台均推荐各自原生的服务管理机制，不存在优劣之分，只是生态差异
+
+## Environment Details
+| 项目 | 内容 |
+|------|------|
+| 系统 | Ubuntu Server 24.04 LTS |
+| 架构 | x86_64 (amd64) |
+| 软件 | FRP 0.65.0 |
+| 安装目录 | `/opt/frp/frp_0.65.0_linux_amd64` |
+| 客户端程序 | `frpc` |
+| 配置文件 | `frpc.toml` |
+| 服务管理 | systemd |
+| frps服务器 | 192.227.222.142:7000 |
+| frps认证token | your_token_here |
+| frps映射端口 | 6000（本地 SSH 22 → 远程 6000）|
+
+## Installation Steps
+1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
+2. 下载 x86_64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_linux_amd64.tar.gz`
+3. 解压：`tar -xzf frp_0.65.0_linux_amd64.tar.gz`
+4. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 [[proxies]] 数组
+5. 测试运行：`./frpc -c frpc.toml`，验证 "login to server success"
+6. 创建 systemd 服务文件：`/etc/systemd/system/frpc.service`
+7. 启用开机自启：`sudo systemctl daemon-reload && sudo systemctl enable --now frpc`
+
+## Configuration Reference
+```toml
+serverAddr = "192.227.222.142"
+serverPort = 7000
+
+[auth]
+token = "your_token_here"
+
+[[proxies]]
+name = "ssh"
+type = "tcp"
+localIP = "127.0.0.1"
+localPort = 22
+remotePort = 6000
+```
+
+## systemd Service Template
+```ini
+[Unit]
+Description=frp client
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+Type=simple
+ExecStart=/opt/frp/frp_0.65.0_linux_amd64/frpc -c /opt/frp/frp_0.65.0_linux_amd64/frpc.toml
+Restart=on-failure
+RestartSec=10
+
+[Install]
+WantedBy=multi-user.target
+```
+
+## Maintenance Commands
+- 查看状态：`sudo systemctl status frpc`
+- 查看日志：`sudo journalctl -u frpc -f`
+- 重启服务：`sudo systemctl restart frpc`
+- 停止服务：`sudo systemctl stop frpc`
+- 禁用开机自启：`sudo systemctl disable frpc`
+
+## Best Practices
+1. **软链接策略**：创建 `/opt/frp/current` → 具体版本目录的软链接，systemd 配置使用 current 路径
+2. **日志管理**：使用 journald（journalctl）管理日志，支持实时流式查看和历史记录
+3. **配置验证**：使用 `./frpc validate -c frpc.toml` 验证配置文件语法后再重启服务
+4. **防火墙检查**：确保 frps 服务器端口（7000）和映射端口（6000）在防火墙中开放
+5. **版本管理**：多版本并存于 `/opt/frp/` 下，通过软链接切换，systemd 配置保持不变
--- a/wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md
+++ b/wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md
@@ -0,0 +1,56 @@
+---
+title: "Ubuntu服务器通过rsync实现日常增量备份"
+type: source
+tags: [ubuntu, rsync, backup, nas]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
+
+## Summary (用中文描述)
+- 核心主题：Ubuntu服务器通过rsync实现日常增量备份到NAS的完整解决方案
+- 问题域：数据备份、网络存储挂载、系统容灾恢复
+- 方法/机制：rsync自动化脚本 + Cron定时任务 + /etc/fstab永久挂载 + NFS网络文件系统
+- 结论/价值：rsync优势在于不关机运行、仅传输变化文件，是构建"工作室级"数据保护体系的最后一步；结合Clonezilla整机镜像实现完整灾备策略
+
+## Key Claims (用中文描述)
+- rsync通过SSH或不通过SSH方式增量同步数据，仅传输变化的文件，大幅降低带宽和时间成本
+- NFS永久挂载必须写入/etc/fstab，并使用_netdev参数确保网络完全启动后才尝试挂载，避免开机卡死
+- Docker卷数据备份建议先执行mysqldump导出SQL再rsync同步，直接复制二进制数据库文件可能导致恢复后无法启动
+- rsync错误码0/23/24均视为成功（23=部分文件权限问题，24=源文件消失），这些在运行系统备份中属正常情况
+- 停止rsync进程应优先使用SIGTERM（killall rsync）而非SIGKILL（killall -9 rsync），防止临时文件残留和数据损坏
+
+## Key Quotes
+> "rsync 的优势在于它可以**不关机**运行，并且只传输**变化过**的文件。" — rsync增量备份的核心价值
+
+> "_netdev: **关键参数**。告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — NFS挂载参数解析
+
+> "rsync 返回 23 表示部分文件由于权限或消失未传输，这在备份正在运行的系统时常见。我们重点看是否大部分数据已同步。" — 错误码容错处理原则
+
+## Key Concepts
+- [[增量备份]]：通过rsync仅同步源端与目标端差异部分，实现高效的日常数据保护
+- [[永久挂载]]：通过/etc/fstab配置实现NFS/Samba等网络存储的开机自动挂载
+- [[挂载点检查]]：备份脚本执行前验证挂载点有效性，防止数据写入本地磁盘导致硬盘爆满
+- [[Cron定时任务]]：通过crontab配置凌晨3点自动执行备份，实现无人值守运维
+- [[进程管理]]：通过信号（SIGTERM/SIGKILL）控制rsync备份进程的优雅或强制终止
+
+## Key Entities
+- [[Docker卷]]：Docker容器持久化数据存储，默认路径/var/lib/docker/volumes，是TikTok业务数据备份的核心对象
+- rsync_backup.sh：自动化备份脚本，含锁文件机制、挂载检查、日志记录、错误容错
+
+## Connections
+- [[增量备份]] ← part_of ← [[Disaster-Recovery]]
+- [[Docker卷]] ← backup_target ← [[增量备份]]
+- [[NFS]] ← storage_backend ← [[永久挂载]]
+- [[永久挂载]] ← requires ← [[挂载点检查]]
+
+## Contradictions
+- 无已知冲突
+
+## Metadata
+- **Source type**: 运维实践笔记（个人经验总结）
+- **Prerequisites**: NAS已挂载、NFS服务已配置
+- **Related practices**: Clonezilla整机镜像备份（时间点恢复的完整策略）
+- **Key scripts**: /usr/local/bin/rsync_backup.sh
+- **Schedule**: 0 3 * * * (每日凌晨3点)
--- a/wiki/sources/understanding-complete-itsm.md
+++ b/wiki/sources/understanding-complete-itsm.md
@@ -0,0 +1,78 @@
+---
+title: "Modern ITSM: Driving Efficiency, Security & Resilience"
+type: source
+tags: []
+date: 2025-03-01
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Understanding Complete ITSM.md]]
+
+## Summary (用中文描述)
+- **核心主题**：现代IT服务管理（ITSM）已超越传统工单管理，成为企业运营卓越、风险缓解和创新加速的战略推动者。
+- **问题域**：传统遗留服务管理模式无法应对快速变化的IT环境；需要敏捷性、自动化和弹性能力。
+- **方法/机制**：通过AIOps、预测分析、自动化修复、自愈系统等AI驱动技术重构ITSM八大核心流程：问题管理、事件管理、变更管理、发布管理、配置管理、资产管理、安全合规管理、灾备与业务连续性。
+- **结论/价值**：AIOps、超自动化与ITSM 2.0的融合定义了一个新范式——自学习、预测性和自主化的IT运营。
+
+## Key Claims (用中文描述)
+- **AI驱动异常检测** ← 通过预测分析消除重复故障 ← 聚焦根本原因根除而非症状管理。
+- **AIOps驱动的自愈IT生态系统** ← 实时可观测性 + 自动化修复 ← 最小化MTTR，最大化正常运行时间。
+- **风险感知变更审批** ← AI预测失败概率 ← 确保变更平稳落地。
+- **零信任架构（ZTA）+ 策略即代码（PaC）** ← 自动化风险评分 + AI威胁情报 ← 强化网络安全与合规。
+- **云原生DRaaS** ← AI驱动的自动故障转移策略 ← 保障业务连续性与RTO/RPO优化。
+
+## Key Quotes
+> "IT Service Management (ITSM) is no longer just about ticketing—it's the strategic enabler of operational excellence, risk mitigation, and innovation acceleration." — 文章开篇核心论点
+
+> "ML-enhanced event correlation reduces incident duplication, streamlining RCA processes." — ML增强事件关联减少事件重复，加速根因分析
+
+> "Risk-based change approvals leverage AI to predict failure probabilities, ensuring seamless rollouts." — 基于风险的变更审批利用AI预测失败概率
+
+> "The convergence of AIOps, hyperautomation, and ITSM 2.0 is defining a new paradigm: self-learning, predictive, and autonomous IT operations." — 未来趋势：AIOps + 超自动化 + ITSM 2.0 = 自学习/预测/自主化IT运营
+
+## Key Concepts
+- [[AIOps]]：AI驱动的IT运维，通过机器学习实现异常检测、事件关联和自动修复。
+- [[ITSM]]：IT服务管理，从传统工单系统演进为战略业务推动者。
+- [[ITSM-2.0]]：下一代ITSM，融合AIOps和超自动化，具备自学习、预测性和自主化能力。
+- [[Zero-Trust-Architecture]]：零信任架构，持续验证、永不信任的安全框架。
+- [[Policy-as-Code]]：策略即代码，将安全合规策略编码为可执行代码。
+- [[CMDB]]：配置管理数据库，AI驱动的CMDB增强依赖映射和漂移检测。
+- [[Self-Healing-Systems]]：自愈系统，通过AIOps实现自动化故障检测和修复。
+- [[Hyperautomation]]：超自动化，融合多种自动化技术实现端到端流程自动化。
+- [[Problem-Management]]：问题管理，聚焦根本原因根除。
+- [[Incident-Management]]：事件管理，实时可观测性与自动化修复。
+- [[Change-Management]]：变更管理，AI驱动的风险评估和审批。
+- [[Release-Management]]：发布管理，DevOps集成与渐进式交付。
+- [[Configuration-Management]]：配置管理，AI增强的依赖映射与漂移检测。
+- [[Asset-Management]]：资产管理，智能生命周期跟踪。
+- [[Security-and-Compliance]]：安全与合规，ZTA + PaC + 合规自动化。
+- [[Disaster-Recovery]]：灾备与业务连续性，AI驱动的自动故障转移。
+- [[RTO]]：恢复时间目标，灾难恢复的关键指标。
+- [[RPO]]：恢复点目标，数据恢复的最大可容忍丢失量。
+- [[DRaaS]]：灾备即服务，云原生灾难恢复解决方案。
+- [[IaC]]：基础设施即代码，通过代码管理基础设施配置。
+- [[Canary-Release]]：金丝雀发布，渐进式发布策略。
+- [[Blue-Green-Deployment]]：蓝绿部署，零停机发布策略。
+- [[RCA]]：根因分析，问题管理的核心活动。
+- [[MTTR]]：平均恢复时间，事件管理关键指标。
+- [[Event-Correlation]]：事件关联，将相关事件归类以减少噪音。
+
+## Key Entities
+- [[shenwei]]：LinkedIn文章作者，专注于现代IT运维和云转型领域。
+- [[BMC]]：企业IT管理解决方案提供商，Helix/Control-M产品线。
+- [[Micro-Focus]]：企业IT运营管理厂商（CTP课程中涉及）。
+
+## Connections
+- [[AIOps]] ← enables ← [[Self-Healing-Systems]]
+- [[ITSM]] ← evolves_to ← [[ITSM-2.0]]
+- [[Zero-Trust-Architecture]] ← protects ← [[Cloud-Native]]
+- [[Policy-as-Code]] ← enforces ← [[Security-and-Compliance]]
+- [[CMDB]] ← supports ← [[Configuration-Management]]
+- [[DRaaS]] ← achieves ← [[Disaster-Recovery]] + [[RTO]] + [[RPO]]
+- [[Canary-Release]] ← is_a ← [[Release-Management]] pattern
+- [[Blue-Green-Deployment]] ← is_a ← [[Release-Management]] pattern
+- [[IaC]] ← enables ← [[Change-Management]]
+- [[Hyperautomation]] ← enables ← [[ITSM-2.0]]
+
+## Contradictions
+- （本文档未发现与其他页面的明显冲突）
--- a/wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md
+++ b/wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md
@@ -0,0 +1,112 @@
+---
+title: "What is DevSecOps? Best Practices, Benefits, and Tools"
+type: source
+tags: [DevSecOps, Security, CI/CD, SDLC]
+date: 2025-12-19
+source: https://www.bacancytechnology.com/blog/what-is-devsecops
+author: shenwei
+published: 2023-10-30
+---
+
+## Source File
+- [[raw/Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools.md]]
+
+## Summary (中文摘要)
+- **核心主题**：DevSecOps 将安全实践深度集成到软件开发全生命周期的方法论，解决传统 DevOps 中安全滞后的问题
+- **问题域**：软件安全开发、安全自动化、DevOps 文化转型、企业安全合规
+- **方法/机制**：通过 Shift Left（安全左移）和 Shift Right（安全右移）策略，在 SDLC 各阶段嵌入安全检查；通过 SAST/DAST/IAST/SCA 等工具实现自动化安全测试
+- **结论/价值**：DevSecOps 可将 70% 的上线后漏洞在开发阶段预防，成本效益比传统安全实践高 3-5 倍
+
+## Key Claims (中文描述)
+- DevSecOps 通过在 CI/CD 流程中集成安全检查，使开发团队比传统团队能更好地处理安全问题
+- 70% 的上线后发现的安全漏洞本可以通过 DevSecOps 预防
+- 安全自动化将漏洞修复时间从数周缩短到数小时
+- DevSecOps 涵盖五大核心要素：协作（Collaboration）、沟通（Communication）、自动化（Automation）、工具与架构安全（Security of Tools and Architecture）、测试（Testing）
+- Shift Left 策略通过早期发现安全问题，降低修复成本可达 100 倍
+
+## Key Quotes
+> "DevSecOps brings together three important groups: 'Dev' for development, 'Sec' for security, and 'Ops' for operations teams." — DevSecOps 命名来源
+
+> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps" — DevSecOps 核心价值主张
+
+> "'Shift left' means identifying security flaws early in the software development lifecycle." — 安全左移定义
+
+> "'Shift right' highlights the need for ongoing security measures even after launching the application." — 安全右移定义
+
+## Key Concepts
+- [[DevSecOps]]：将安全深度集成到 DevOps 流程中的方法论，使安全成为开发、运维、安全团队的共同责任
+- [[Shift-Left-Security]]：安全测试左移到软件开发生命周期早期阶段的实践，降低修复成本
+- [[Shift-Right-Security]]：在生产环境部署后持续进行安全监控和响应的实践
+- [[SAST]]（Static Application Security Testing）：静态应用安全测试，分析源代码发现安全漏洞
+- [[DAST]]（Dynamic Application Security Testing）：动态应用安全测试，通过模拟外部攻击发现运行时刻漏洞
+- [[IAST]]（Interactive Application Security Testing）：交互式应用安全测试，在运行时检测漏洞
+- [[SCA]]（Software Composition Analysis）：软件组成分析，扫描第三方依赖中的已知漏洞
+- [[SDLC]]（Software Development Lifecycle）：软件开发生命周期，包括需求分析、规划、架构设计、开发、测试、部署六阶段
+- [[Break-the-Build]]：当安全风险过高时自动停止构建进程的机制
+- [[Policy-as-Code]]：以代码形式定义和管理安全策略的实践
+- [[Immutable-Infrastructure]]：不可变基础设施，通过预配置组件减少未授权变更风险
+
+## Key Entities
+- [[Amazon-Inspector]]：AWS 漏洞管理服务，可自动处理安全漏洞
+- [[Amazon-CodeGuru-Reviewer]]：AWS 代码审查服务，识别安全问题和资源泄漏
+- [[AWS-CodePipeline]]：AWS CI/CD 服务，用于应用部署和管理
+- [[Snyk]]：开源安全工具，集成到 DevSecOps 工具链
+- [[SonarQube]]：代码质量和安全静态分析工具
+- [[Jenkins]]：开源 CI/CD 工具（DevOps 工具）
+- [[Docker]]：容器化平台（DevOps 工具）
+- [[Kubernetes]]：容器编排平台（DevOps 工具）
+
+## DevSecOps vs DevOps Comparison
+
+| 维度 | DevOps | DevSecOps |
+|------|--------|-----------|
+| **定义** | 强调开发与运维协作加速交付 | 将安全实践集成到开发过程 |
+| **主焦点** | 加速软件开发与部署 | 在每个开发阶段集成安全 |
+| **安全角色** | 安全单独处理或最后处理 | 从一开始就将安全嵌入每个步骤 |
+| **目标** | 提升团队速度和协作 | 早期解决安全问题预防后续问题 |
+| **自动化** | 自动化开发与运维任务 | 自动化安全检查与开发任务 |
+| **团队参与** | 开发与运维协作 | 开发、运维、安全三方协作 |
+| **合规方式** | 开发后进行合规检查 | 开发部署全程确保合规 |
+
+## DevSecOps 核心组件
+
+### 1. 协作（Collaboration）
+- 安全任务在开发和运维团队间共享
+- 不需要独立的安全团队
+- 开发者被鼓励理解安全实践
+
+### 2. 沟通（Communication）
+- 安全专业人员需要用开发者理解的简单语言解释安全控制
+- 开发者应了解安全责任，识别潜在威胁，遵循安全编码最佳实践
+- 在开发过程中进行漏洞测试
+
+### 3. 自动化（Automation）
+- 将自动化安全测试添加到 CI/CD 管道
+- "Break the Build" 机制在安全风险过高时停止构建
+- 确保软件依赖保持最新
+
+### 4. 工具与架构安全（Security of Tools and Architecture）
+- 选择和审查安全工具
+- 谨慎管理用户访问（多因素认证、最小权限）
+- 定期监控工作站和服务器漏洞
+- 扫描代码中的敏感数据
+- 新容器配置安全设置
+
+### 5. 测试（Testing）
+- 在每个开发阶段集成安全测试
+- 使用 OWASP Top Ten 进行基础安全测试
+- SAST/DAST/IAST 技术
+- 渗透测试和威胁建模
+- Bug Bounty 计划
+
+## Connections
+- [[DevOps]] ← extends ← [[DevSecOps]]（DevSecOps 是 DevOps 的安全扩展）
+- [[Agile-Practices]] ← integrates_with ← [[DevSecOps]]（敏捷开发与 DevSecOps 相辅相成）
+- [[CI/CD-Pipeline]] ← embeds ← [[DevSecOps-Security-Tools]]（安全工具集成到 CI/CD 管道）
+- [[Cloud-Transformation]] ← includes ← [[DevSecOps]]（云转型包含 DevSecOps 实践）
+- [[Shift-Left-Security]] ← complements ← [[Shift-Right-Security]]（左移与右移互补）
+
+## Contradictions
+- **安全与速度的张力**：传统观点认为安全检查会减慢开发速度；DevSecOps 主张通过自动化实现安全与速度双赢
+- **集中式 vs 分布式安全**：传统安全团队独立负责安全；DevSecOps 倡导安全责任分散到整个开发团队
+- **合规时机**：传统做法在开发后进行合规检查；DevSecOps 强调全程合规
--- a/wiki/sources/在synology-nas上安装clouddrive2.md
+++ b/wiki/sources/在synology-nas上安装clouddrive2.md
@@ -0,0 +1,42 @@
+---
+title: "在Synology NAS上安装CloudDrive2"
+type: source
+tags: [clouddrive2, nas, synology, 阿里云盘]
+date: 2025-12-29
+---
+
+## Source File
+- [[raw/Home Office/在Synology NAS上安装CloudDrive2.md]]
+
+## Summary (用中文描述)
+- 核心主题：在 Synology NAS 上通过 CloudDrive2 将阿里云盘挂载为本地文件系统
+- 问题域：NAS 本地存储与云端存储的融合、家庭多媒体中心的云盘访问
+- 方法/机制：利用矿神源（社群套件源）安装 CloudDrive2，通过阿里云盘 App 扫码授权，实现云盘的本地挂载访问
+- 结论/价值：将阿里云盘无缝接入 NAS 文件系统，无需手动同步即可直接访问云端资源
+
+## Key Claims (用中文描述)
+- 矿神源提供了 CloudDrive2 等第三方套件，扩展了 Synology 官方套件中心的应用生态
+- DSM 7+ 版本要求额外的 Root 权限修复命令，否则 CloudDrive2 可能无法正常运行
+- 阿里云盘授权时应仅授权"资源目录"，避免"备份目录"以控制数据访问范围
+
+## Key Quotes
+> "不要授权备份目录，仅资源目录即可" — 最小权限原则，避免意外访问敏感备份数据
+
+## Key Concepts
+- [[云盘挂载]]：通过 FUSE/虚拟文件系统将云端存储映射为本地目录的技术
+- [[NAS套件管理]]：群晖 NAS 的 Package Center 套件安装与管理机制
+- [[Root权限修复]]：DSM 7+ 系统中第三方套件权限配置的特殊处理方法
+
+## Key Entities
+- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、Google Drive、OneDrive 等多种云存储服务
+- [[Synology NAS]]（群晖 NAS）：网络附加存储设备，本方案的硬件平台
+- [[矿神源]]：Synology 社群套件源（SPK 社区生态），提供大量官方未收录的第三方应用
+- [[阿里云盘]]：阿里巴巴云盘服务，本方案的挂载目标云存储
+
+## Connections
+- [[群晖NAS科学上网]] ← 关联场景 ← [[在Synology NAS上安装CloudDrive2]]
+- [[Home Server 多服务架构]] ← 扩展 ← [[在Synology NAS上安装CloudDrive2]]
+- [[CloudDrive2]] ← 挂载目标 ← [[阿里云盘]]
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md
+++ b/wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md
@@ -0,0 +1,46 @@
+---
+title: "如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64"
+type: source
+tags: [linux, 运维]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64.md]]
+
+## Summary (用中文描述)
+- **核心主题**：Linux 服务器 CPU 架构检测方法
+- **问题域**：服务器运维中需要确定机器硬件架构以选择正确软件包的场景
+- **方法/机制**：通过 4 种系统命令（uname、lscpu、/proc/cpuinfo、file）读取系统硬件标识
+- **结论/价值**：快速准确识别服务器架构，确保下载和安装正确的软件版本（如 .deb/.rpm 包、容器镜像）
+
+## Key Claims (用中文描述)
+- `uname -m` 命令通过返回机器硬件名称来标识 CPU 架构
+- `lscpu` 命令以结构化方式输出 CPU 架构、位宽和字节序等详细信息
+- `/proc/cpuinfo` 文件包含 CPU 型号和架构特性信息，可通过 model name 或 AArch64/ARMv8 标识判断
+- `file` 命令通过分析 ELF 可执行文件的元数据来判断二进制文件的目标架构
+
+## Key Quotes
+> `x86_64` → 表示 **64位 x86（Intel/AMD）架构**
+> `aarch64` → 表示 **64位 ARM 架构**
+> `armv7l` → 表示 **32位 ARM 架构**
+
+## Key Concepts
+- [[CPU架构检测]]：通过系统命令识别服务器 CPU 微架构类型的方法论
+- [[x86_64]]：64位 x86 指令集架构，Intel 和 AMD 处理器使用的标准，由 x86 扩展而来
+- [[aarch64]]：ARM 64位架构规范，ARMv8-A 开始引入的 64位指令集
+- [[ARM64]]：基于 ARM 设计的 64位处理器架构，常见于云服务商（AWS Graviton、阿里云 ARM 实例）
+- [[ELF格式]]：Executable and Linkable Format，Linux 可执行文件标准格式，包含目标架构元数据
+
+## Key Entities
+- 无特定实体（属于通用运维知识）
+
+## Connections
+- [[Linux运维命令]] ← related_to ← [[CPU架构检测]]
+- [[Docker镜像多架构]] ← depends_on ← [[CPU架构检测]]
+
+## Contradictions
+- 无已知冲突
+
+## Related Sources
+- [[linux-运维必会的-150-个命令]] — 包含更多 Linux 系统诊断命令
--- a/wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md
+++ b/wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md
@@ -0,0 +1,60 @@
+---
+title: "如何在Ubuntu Server安装 Docker & Docker Compose"
+type: source
+tags: [docker, ubuntu]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/如何在Ubuntu Server安装 docker & docker compose.md]]
+
+## Summary (用中文描述)
+- 核心主题：在 Ubuntu Server 上通过官方 apt 仓库安装 Docker Engine 和 Docker Compose V2 的完整流程
+- 问题域：服务器容器化环境搭建
+- 方法/机制：五步标准安装流程——卸载旧版 → 配置官方仓库 → 安装引擎 → 验证安装 → 配置非 root 用户
+- 结论/价值：推荐从 Docker 官方仓库安装以确保获取最新版本；Docker Compose V2 已集成到 docker-compose-plugin，使用 `docker compose` 命令
+
+## Key Claims (用中文描述)
+- Docker 官方仓库安装能确保获取最新版本的 Docker Engine
+- Docker Compose V2 通过 docker-compose-plugin 安装，使用 `docker compose` 命令而非 `docker-compose`
+- 将用户加入 docker 用户组后，可无需 sudo 直接运行 Docker 命令
+- 必须先安装 ca-certificates 和 curl 才能通过 HTTPS 添加 Docker GPG 密钥和仓库
+
+## Key Quotes
+> "It's generally best to install from Docker's official repositories to ensure you have the latest version." — 官方仓库安装的最佳实践理由
+> "The `docker-compose-plugin` installs **Docker Compose V2**, which is used via the command `docker compose` instead of `docker-compose`." — V2 版本命令变化说明
+> "By default, running Docker commands requires `sudo`. To run Docker without `sudo`, you can add your user to the **`docker` group`." — docker 用户组的作用
+
+## Key Concepts
+- [[Docker Engine]]：Docker 核心运行时，包含 dockerd 守护进程、CLI 和 containerd 容器运行时
+- [[Docker Compose]]：多容器 Docker 应用的定义和运行工具，V2 版本集成到 docker CLI（`docker compose`）
+- [[APT 仓库]]：Ubuntu/Debian 的软件包管理仓库，通过 /etc/apt/sources.list.d/ 配置
+- [[GPG 密钥]]：apt 仓库签名验证，确保软件包来源可信
+- [[Docker 用户组]]：Linux 用户组，允许组成员无需 sudo 直接运行 Docker 命令（存在安全风险）
+- [[containerd]]：Docker 的容器运行时底层引擎，独立项目
+
+## Key Entities
+- [[Docker CE]]：Docker Community Edition，Docker Engine 的开源版本
+- [[docker-ce-cli]]：Docker 命令行工具
+- [[docker-buildx-plugin]]：Docker 扩展插件，支持多平台镜像构建
+- [[docker-compose-plugin]]：Docker Compose V2 插件，替代独立的 docker-compose 包
+- [[containerd.io]]：containerd 的 Docker 打包版本
+- [[hello-world]]：Docker 官方测试镜像，用于验证安装是否成功
+
+## Connections
+- [[Docker Engine]] ← installed_by ← [[Docker CE on Ubuntu]]
+- [[Docker Compose]] ← extends ← [[Docker Engine]]
+- [[APT 仓库]] ← provides ← [[Docker CE]]
+- [[GPG 密钥]] ← authenticates ← [[APT 仓库]]
+- [[Ubuntu Server]] ← runs_on ← [[Docker Engine]]
+- [[Docker 用户组]] ← enables ← [[Docker Engine]] (non-root execution)
+- [[containerd]] ← powers ← [[Docker Engine]]
+
+## Contradictions
+- 无已知冲突
+
+## Related Sources
+- [[用docker安装transmission]] — Docker 部署实战
+- [[用docker安装portainer]] — Docker 可视化管理
+- [[用docker安装jellyfin]] — Docker 媒体服务
+- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] — Docker 监控堆栈
--- a/wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md
+++ b/wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md
@@ -0,0 +1,103 @@
+---
+title: "如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略"
+type: source
+tags: [adspower, claude, ip, pingme, wildcard, 指纹浏览器, 跨境支付]
+date: 2025-12-31
+---
+
+## Source File
+- [[raw/Home Office/如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略.md]]
+
+## Summary (用中文描述)
+- **核心主题**：通过指纹浏览器配合高质量代理IP，在避免账号被封的情况下，安全注册并订阅Claude Pro会员的完整实操攻略
+- **问题域**：跨境AI服务注册封号问题、支付限制问题、手机号验证问题
+- **方法/机制**：
+  1. AdsPower指纹浏览器创建隔离浏览器环境
+  2. Socks5代理配置美国IP
+  3. IP纯净度检测（Scamalytics低风险）
+  4. PingMe接码平台接收短信验证码
+  5. WildCard虚拟信用卡完成跨境支付
+- **结论/价值**：掌握这套方法可有效降低Claude账号封禁风险，稳定使用Claude Pro服务
+
+## Key Claims (用中文描述)
+- 指纹浏览器通过隔离浏览器环境，能有效减少账号关联和封号风险
+- IP纯净度检测为"低风险"才能使用，中等风险以上会增加封号概率
+- 订阅制接码平台（如PingMe）比一次性号码更稳定可靠
+- WildCard虚拟信用卡支持支付宝充值，是国内用户跨境支付的可行方案
+- AdsPower免费版提供5个指纹浏览器环境，满足大多数多账号需求
+
+## Key Quotes
+> "指纹浏览器中的'新建浏览器环境'为什么不能使用本地浏览器？本地浏览器和指纹浏览器的环境互不干涉，使用本地浏览器会暴露设备和IP特征，易被关联封号。"
+
+> "IP纯净度为中等风险，能否保证注册的Claude账号长期不被封？不能，中等风险IP易被平台标记导致封号，应使用低风险IP。"
+
+> "为什么要使用PingMe平台代替传统短信接码平台？PingMe提供订阅制的美国地区稳定号码，避免一次性号码被封，且充值灵活。"
+
+## Key Concepts
+- [[指纹浏览器]]：可模拟不同设备、网络环境的多账号浏览器，隔离使用环境，减少账号关联风险
+- [[IP纯净度]]：评定某IP是否安全可靠的风险等级，低风险代表良好信誉和较少异常，避免被平台标记
+- [[Socks5代理]]：一种网络代理协议，支持灵活的传输隧道，有助于隐匿真实IP和地理位置
+- [[虚拟信用卡]]：不依赖实体卡的线上信用支付工具，方便海外支付等场景
+- [[接码平台]]：提供短信接码服务的应用或网站，支持接收短消息以完成注册或验证
+- [[账号隔离]]：通过独立浏览器环境和独立IP，防止多个账号被平台识别为关联账号
+
+## Key Entities
+- [[AdsPower]]：推荐使用的指纹浏览器产品，支持谷歌授权登录，免费版提供5个环境
+- [[PingMe]]：新兴短信接码平台，支持中文界面，需下载App，最低充值2美元
+- [[WildCard]]：虚拟信用卡服务，支持支付宝充值，解决国内用户跨境支付难题
+- [[Claude Pro]]：Anthropic提供的AI聊天工具Pro订阅服务，月费20美元
+- [[Claude]]：Anthropic开发的AI聊天工具，支持Claude 3.5 Sonnet等模型
+- [[Scamalytics]]：IP风险评估网站，用于检测IP纯净度
+
+## Connections
+- [[指纹浏览器]] ← uses ← [[AdsPower]]
+- [[Socks5代理]] ← configured_in ← [[指纹浏览器]]
+- [[IP纯净度]] ← checked_by ← [[Scamalytics]]
+- [[接码平台]] ← provides ← [[PingMe]]
+- [[虚拟信用卡]] ← provides ← [[WildCard]]
+- [[Claude Pro]] ← requires ← [[虚拟信用卡]]
+- [[Claude]] ← requires ← [[接码平台]] + [[IP纯净度]]
+
+## Workflow Summary
+```
+1. 安装AdsPower指纹浏览器
+   ↓
+2. 创建新浏览器环境（Chrome最新版本 + Windows系统）
+   ↓
+3. 配置Socks5代理（从系统代理复制主机和端口）
+   ↓
+4. IP纯净度检测（Scamalytics低风险）
+   ↓
+5. 使用谷歌账号注册Claude
+   ↓
+6. PingMe接码平台获取美国区验证码
+   ↓
+7. WildCard虚拟信用卡订阅Claude Pro
+```
+
+## Key Misconceptions (易错点)
+1. ❌ 使用本地浏览器直接访问Claude → ✅ 必须使用指纹浏览器隔离环境
+2. ❌ 代理IP设置不一致 → ✅ 确保三处IP测试点完全一致
+3. ❌ 忽视IP纯净度检测 → ✅ 必须使用低风险IP
+4. ❌ 使用一次性接码号码 → ✅ 使用订阅制接码平台
+5. ❌ 未使用虚拟信用卡 → ✅ 使用WildCard等支持海外支付的虚拟信用卡
+
+## Tools & Resources
+- **AdsPower下载**: https://share.adspower.net
+- **PingMe**: https://messages.pingme.tel/
+- **WildCard**: https://yeka.ai/i/UPHSP
+- **IP检测**: https://ip111.cn/
+- **IP纯净度检测**: https://scamalytics.com/
+- **Claude官网**: https://claude.ai
+
+## Contradictions
+- （暂无发现与其他源的冲突）
+
+## Related Wiki Pages
+- [[指纹浏览器]]
+- [[IP纯净度]]
+- [[虚拟信用卡]]
+- [[AdsPower]]
+- [[PingMe]]
+- [[WildCard]]
+- [[Claude Pro]]
--- a/wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md
+++ b/wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md
@@ -0,0 +1,61 @@
+---
+title: "安装Ubuntu 24.04.2在HP ZBook工作站笔记本上"
+type: source
+tags: [hp, ubuntu, zbook, rufus, uefi]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/安装Ubuntu-24.04.2在HP Zbook工作站笔记本上.md]]
+
+## Summary (中文)
+- **核心主题**：在 HP ZBook 工作站笔记本上安装 Ubuntu 24.04.2 Desktop 的完整实操指南，涵盖启动盘制作、分区配置、BIOS 设置及启动引导修复。
+- **问题域**：HP ZBook 笔记本 + Ubuntu 24.04.2 双系统安装，聚焦 UEFI/GPT 引导环境下的 NVMe 硬盘分区与 HP BIOS 固执行为导致的启动项丢失问题。
+- **方法/机制**：
+  - Rufus ISOHybrid 镜像写入（ISO 模式优先）
+  - GPT 分区方案（/boot/efi FAT32, / ext4, /home ext4, swap）
+  - HP BIOS F9 启动菜单、F10 BIOS 设置
+  - efibootmgr NVRAM 写入强制重写 BootOrder
+  - EFI 默认路径伪装（shimx64.efi → BOOTX64.EFI）
+  - UEFI Only 模式切换消除 BBS 遗留项
+- **结论/价值**：HP ZBook 等现代 UEFI 工作站安装 Ubuntu 的完整故障排除路线图，核心问题是 HP BIOS 不持久化 NVRAM 启动项；终极解法是切换到 UEFI Only 模式消除 Legacy BBS 项干扰。
+
+## Key Claims (中文)
+- HP ZBook 必须使用 GPT 分区表配合 UEFI 启动，MBR/Legacy 不适用于现代工作站。
+- ISOHybrid 镜像写入 Rufus 应优先选择"ISO 镜像模式"，DD 模式仅作为启动失败后的备选。
+- HP BIOS 的固执行为（不保存自定义启动项）可通过两种方式绕过：efibootmgr 强制重写 NVRAM，或将引导文件复制到 EFI 默认路径（/EFI/BOOT/BOOTX64.EFI）。
+- UEFI Only 模式是解决 HP ZBook 多余 BBS 遗留项干扰的终极方案，切換后 Boot0000-0004 等 Legacy 项自动消失，BIOS 被迫只识别 Ubuntu 启动项。
+
+## Key Quotes
+> "HP 的旧款 ZBook 有个'坏习惯'：如果它在 NVRAM 里找不到它认为'标准'的启动项，它会重置 BootOrder。我们可以把 Ubuntu 的引导文件复制到磁盘的默认备用路径。" — HP ZBook 引导伪装大法
+
+> "一旦切换为 UEFI Only，那些无效的 0000-0004 就会消失，BIOS 将被迫只看 0005 (Ubuntu)。" — UEFI Only 切换后效果
+
+> "Legacy Support (传统支持)：确保设置为 Disabled (或者选择 UEFI Without Legacy)。从你的输出看，你现在有大量的 BBS (Legacy) 启动项，这会干扰 UEFI 的识别。" — 混合模式问题诊断
+
+## Key Concepts
+- [[GPT分区表]]：现代 UEFI 设备的标准分区方案，支持 2TB+ 硬盘，与 UEFI 引导完美兼容
+- [[efibootmgr]]：Linux 系统下管理 NVRAM 启动项的工具，可强制重写 BootOrder
+- [[ISOHybrid镜像]]：同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像，Rufus 提供 ISO/DD 两种写入模式
+- [[UEFI启动修复]]：HP BIOS固执行为导致启动项丢失的解决方案（efibootmgr + 路径伪装 + UEFI Only）
+- [[NVMe硬盘分区]]：Ubuntu 24.04 自动识别并优化 NVMe 分区对齐
+
+## Key Entities
+- [[HP ZBook]]：HP 工作站笔记本，UEFI/F9 启动菜单，F10 进入 BIOS，固执的 BIOS NVRAM 行为
+- [[Rufus]]：开源 U 盘启动盘制作工具，支持 ISOHybrid 镜像写入（ISO 模式推荐）
+- [[Ubuntu 24.04]]：LTS 桌面操作系统，默认 ssh.socket 按需激活，支持 NVMe 自动优化
+
+## Connections
+- [[HP ZBook]] ← 安装目标 ← [[Rufus]]（启动盘制作工具）
+- [[efibootmgr]] ← 修复工具 ← [[UEFI启动修复]]（核心手段）
+- [[GPT分区表]] ← 分区方案 ← [[NVMe硬盘分区]]（自动对齐优化）
+- [[UEFI Only]] ← 终极方案 ← [[HP ZBook]] BIOS固执行为
+
+## Contradictions
+- **无冲突**：本文档与其他来源一致，未检测到矛盾点。
+
+## Related Sources
+- [[ubuntu-24-04-enable-ssh]] — Ubuntu 24.04 安装后的 SSH 配置
+- [[ubuntu禁用合盖休眠]] — Ubuntu 24.04 合盖休眠设置
+- [[ubuntu服务器通过rsync实现日常增量备份]] — 安装完成后 rsync 数据恢复建议
+- [[clonezilla对ubuntu-server进行全盘镜像备份]] — 母版镜像制作工具，文中提及 Clonezilla
--- a/wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md
+++ b/wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md
@@ -0,0 +1,101 @@
+---
+title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox"
+type: source
+tags: [grafana, monitoring, prometheus, home-server]
+date: 2025-11-11
+---
+
+## Source File
+- [[raw/Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox.md]]
+
+## Summary (中文描述)
+- 核心主题：家庭/家居服务器（NAS / Ubuntu Server）的一站式开源监控方案，通过 Docker Compose 快速部署完整的 Prometheus 监控栈。
+- 问题域：如何对家庭服务器的主机层、容器层、服务层（HTTP 可用性、TLS 证书）进行全面的指标采集、存储、可视化和告警。
+- 方法/机制：使用 Prometheus 作为时序数据库和告警规则引擎，node_exporter 采集主机指标，cAdvisor 采集容器资源，blackbox_exporter 做 HTTP/TLS 探测，Grafana 做可视化仪表盘，Alertmanager 分发告警到邮件/Slack。配合 Uptime Kuma 做合成可用性监控。
+- 结论/价值：提供可直接拷贝的 docker-compose 模板、prometheus.yml、alerts.yml、alertmanager.yml，8 步落地路径，涵盖 PoC 验证到生产级部署的全流程。
+
+## Key Claims (中文描述)
+- Prometheus 通过 pull 模式定期抓取 node_exporter / cAdvisor / blackbox_exporter 暴露的指标，实现主机/容器/网络探测的统一采集。
+- Grafana 可通过 Dashboard ID（如 Node Exporter Full: 1860）直接导入官方仪表盘，快速搭建可视化界面。
+- Blackbox Exporter 通过 `probe_success == 0` 和 `probe_ssl_earliest_cert_expiry` 等指标实现 HTTP 可用性和 TLS 证书到期监控。
+- node_exporter 以 host network 模式运行，挂载 `/proc`、`/sys`、`/` 为只读卷，实现无代理（agentless）主机指标采集。
+- Docker socket 挂载（如 cAdvisor 中的 `/var/run/docker.sock`）是容器监控的必要条件，但需审慎评估安全风险。
+- Alertmanager 支持邮件/Slack/Teams/Webhook/PagerDuty 等多通道告警路由，并提供告警抑制（inhibition）和分组（grouping）功能。
+
+## Key Quotes
+> "Prometheus 通过 pull 模式定期抓取 exporters 采集指标，支持 PromQL 命名与告警规则。适合做主观测时序库与告警。" — Prometheus 核心机制说明
+
+> "Docker socket 挂载（风险：容器拿到宿主机 root 等同权限）。" — 安全警告
+
+> "把监控流量/端口放在管理 VLAN 或通过防火墙限定访问。" — 网络安全建议
+
+> "Grafana 仪表盘 JSON 导出，Prometheus rule 与配置放在 Git（GitOps）。" — 配置备份最佳实践
+
+## Key Concepts
+- [[Prometheus]]：开源时序数据库和监控告警系统，支持 PromQL 查询语言和告警规则引擎
+- [[Grafana]]：开源可视化平台，支持多数据源仪表盘和告警管理
+- [[node_exporter]]：Prometheus 官方主机指标采集器，采集 CPU/内存/磁盘/网络/I/O 等系统指标
+- [[cAdvisor]]：Google 开源的容器资源监控工具，为 Prometheus 提供容器级别指标
+- [[blackbox_exporter]]：Prometheus 官方黑盒探测 exporter，支持 HTTP/TCP/ICMP/DNS/TLS 探测
+- [[Alertmanager]]：Prometheus 告警分发组件，支持告警分组、抑制、静默和多通道路由
+- [[PromQL]]：Prometheus Query Language，用于查询时序指标和告警条件
+- [[Uptime Kuma]]：自托管 uptime monitoring 工具，支持 HTTP/TCP/DNS/TLS 合成监控
+- [[Netdata]]：开箱即用的实时主机/容器监控面板，默认 19999 端口，适合快速诊断
+- [[VictoriaMetrics]]：Prometheus 时序数据库替代方案，支持长期存储和高效写入
+- [[合成监控]]（Synthetic Monitoring）：通过模拟真实用户请求检测服务可用性和响应时间
+- [[Exporter]]：Prometheus 生态中负责暴露指标数据的组件，通过 HTTP 端点提供 /metrics
+- [[时序数据库]]（Time Series Database）：专门存储带时间戳的指标数据，支持高效的时间范围查询和聚合
+- [[Prometheus告警规则]]：YAML 格式的告警条件定义，基于 PromQL 表达式触发状态变更
+
+## Key Entities
+- [[Prometheus]]（CNCF 项目）：时序数据库 + 监控告警平台核心
+- [[Grafana Labs]]：Grafana 背后的公司和维护组织
+- [[Docker]]：所有组件的部署平台，通过 Docker Compose 实现一键启动
+- [[Uptime Kuma]]（louislam/uptime-kuma）：开源 uptime monitoring 工具
+- [[Portainer]]：Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作
+
+## Connections
+- [[Prometheus]] ← 数据源 ← [[node_exporter]]
+- [[Prometheus]] ← 数据源 ← [[cAdvisor]]
+- [[Prometheus]] ← 数据源 ← [[blackbox_exporter]]
+- [[Grafana]] ← 可视化 ← [[Prometheus]]
+- [[Alertmanager]] ← 告警接收 ← [[Prometheus]]
+- [[Prometheus]] ← 告警规则 ← [[Prometheus告警规则]]
+- [[Grafana]] ← 仪表盘模板 ← [[Node Exporter Full Dashboard]]
+- [[Docker Compose]] ← 编排 ← 所有组件（Prometheus / Grafana / Alertmanager / node_exporter / cAdvisor / blackbox_exporter）
+
+## Contradictions
+- 与 [[系统监控工具]]（Btop++ / Htop / Glances / Netdata）相比：Netdata 适合实时短期诊断，Prometheus + Grafana 适合长期存储和趋势分析，两者可互补使用而非互斥。
+- 与 [[ctp-topic-42-grafana-observability-dashboard]] 冲突：该来源标注为 expected（source missing），但内容为 Grafana 在 AWS 场景下的企业级应用；本来源侧重家庭服务器轻量部署，场景和规模不同。
+- 与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 冲突：OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），Prometheus 生态更成熟但 OpenTelemetry 是未来方向；短期用 Prometheus，长期可考虑 OTel 迁移路径。
+
+## Docker Compose 核心架构
+```yaml
+# 监控栈组件
+services:
+  prometheus:    # 时序数据库 + 告警引擎
+  grafana:       # 可视化仪表盘
+  alertmanager:  # 告警分发
+  node_exporter: # 主机指标（host network）
+  cadvisor:     # 容器指标（挂载 /var/run/docker.sock）
+  blackbox:     # HTTP/TCP 探测
+```
+
+## 关键监控项（PromQL 示例）
+| 指标 | PromQL 表达式 | 阈值 |
+|------|--------------|------|
+| 磁盘空间 | `node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.10` | < 10% |
+| CPU 使用率 | `avg(rate(node_cpu_seconds_total[2m])) * 100 > 85` | > 85% |
+| 内存可用 | `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15` | < 15% |
+| HTTP 可用性 | `probe_success == 0` (持续 2min) | 探测失败 |
+| TLS 证书到期 | `probe_ssl_earliest_cert_expiry - time() < 86400 * 14` | < 14 天 |
+
+## 落地 8 步路径
+1. 用 PoC docker-compose 启动 Netdata + Uptime Kuma（19999 / 3001）验证
+2. 上线 Prometheus + prometheus.yml，配置 scrape_configs
+3. 每台主机部署 node_exporter（host network 模式）
+4. Grafana 导入 Dashboard（1860 / 14282 / 7587）
+5. Alertmanager 配置告警路由（邮件/Slack）
+6. Uptime Kuma 建好所有内外网探测项
+7. GitOps 配置管理（Grafana JSON 导出，Prometheus rules 放 Git）
+8. TLS 证书到期告警（blackbox_exporter 或 Uptime Kuma）
--- a/wiki/sources/用docker中安装navidrome.md
+++ b/wiki/sources/用docker中安装navidrome.md
@@ -0,0 +1,49 @@
+---
+title: "用Docker中安装Navidrome"
+type: source
+tags: [docker, music, navidrome]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/用Docker中安装Navidrome.md]]
+
+## Summary (用中文描述)
+- 核心主题：通过 Docker Compose 在 NAS/服务器上部署 Navidrome 音乐服务器
+- 问题域：家庭音乐媒体库管理、跨设备音乐播放、流媒体服务自托管
+- 方法/机制：使用 Docker Compose YAML 配置，挂载 NAS 音乐目录与数据目录，设置环境变量启用转码功能，以非 root 用户运行容器
+- 结论/价值：Navidrome 提供开源、轻量、功能完整的自托管音乐流媒体解决方案，适合家庭媒体中心场景
+
+## Key Claims (用中文描述)
+- Navidrome 容器通过 `user: "1026:100"` 以非 root 用户身份运行，确保宿主机文件系统权限安全
+- 音乐目录以只读模式（`:ro`）挂载，防止容器误操作修改原始音乐文件
+- 转码缓存限制为 200MB（`ND_TRANSCODINGCACHESIZE=200MB`），保护磁盘空间
+- 启用自动转码下载功能（`ND_AUTOTRANSCODEDOWNLOAD=true`），客户端按需获取合适音质的音乐
+
+## Key Quotes
+> `ports: - "4533:4533"` — 容器端口映射到宿主机 4533，供局域网访问
+> `volumes: - /volume1/music:/music:ro` — 将 NAS 音乐目录只读挂载到容器内 /music 路径
+> `ND_ENABLETRANSCODINGCONFIG=true` — 在 Web UI 中启用转码配置界面
+
+## Key Concepts
+- [[Docker Compose]]：多容器 Docker 应用的声明式配置格式
+- [[媒体服务器]]：自托管音乐/视频流媒体服务
+- [[转码缓存]]：按需转码并缓存，保护计算资源与磁盘空间
+- [[只读挂载]]：保护原始文件不被容器修改
+
+## Key Entities
+- [[Navidrome]]：开源音乐流媒体服务器，Subsonic API 兼容，支持网页与移动客户端
+- [[群晖 NAS]]（Synology NAS）：NAS 存储设备，音乐文件的宿主机
+- [[Deluan/Navidrome]]：Navidrome 官方 Docker 镜像发布者
+
+## Connections
+- [[群晖 NAS]] ← 存储音乐文件并运行 Docker ← [[Navidrome]]
+- [[Jellyfin]] ← 对标竞品媒体服务器 ← [[Navidrome]]
+- [[Docker-Image]] ← 基础技术栈 ← [[Navidrome]]
+
+## Contradictions
+- 无已知冲突
+
+## Related Sources
+- [[用docker安装jellyfin]] — Jellyfin 视频媒体服务器部署笔记，架构类似但服务对象不同（视频 vs 音乐）
+- [[家庭网络环境概览]] — 家庭服务器整体网络架构说明
--- a/wiki/sources/用docker安装it-tools.md
+++ b/wiki/sources/用docker安装it-tools.md
@@ -0,0 +1,48 @@
+---
+title: "用Docker安装it-tools"
+type: source
+tags: [docker, it-tools]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/用Docker安装it-tools.md]]
+
+## Summary (用中文描述)
+- **核心主题**：使用 Docker Compose 在 Home Server 环境中一键部署 it-tools 开发者工具集合
+- **问题域**：开发者工具匮乏、工具安装繁琐
+- **方法/机制**：通过 Docker Compose YAML 定义服务，使用 `corentinth/it-tools:latest` 镜像，暴露 8999 端口，设置 128MB 内存限制
+- **结论/价值**：提供零配置、可移植的 it-tools 部署方案，实现开箱即用的开发者工具 Web UI
+
+## Key Claims (用中文描述)
+- Docker Compose 通过 `version: '3.8'` 定义服务编排，实现 it-tools 容器化部署
+- it-tools 容器通过 `restart: unless-stopped` 策略确保异常重启后自动恢复
+- 交互模式配置（`stdin_open: true` + `tty: true`）保证容器与终端的标准 I/O 交互能力
+- 内存限制 128MB 足以支持 it-tools Web UI 运行，同时防止资源滥用
+
+## Key Quotes
+> `8999:80` — 宿主机 8999 端口映射到容器内 80 端口，通过浏览器访问 Web UI
+
+## Key Concepts
+- [[Docker Compose]]：定义多容器 Docker 应用的配置文件格式
+- [[容器资源限制]]：通过 `deploy.resources.limits.memory` 约束容器最大内存使用
+- [[容器重启策略]]：`unless-stopped` 确保容器在 Docker 守护进程启动时自动重启
+- [[端口映射]]：`-p` 标志将宿主机端口与容器端口进行一对一映射
+- [[交互模式容器]]：`stdin_open` + `tty` 组合启用容器的交互式终端能力
+
+## Key Entities
+- [[it-tools]]：开源开发者工具集合 Web UI，提供 URL 编码/解码、UUID 生成、Cron 表达式解析等实用工具
+- [[corentinth/it-tools]]：it-tools 的官方 Docker 镜像，由 Corentin Th 维护
+
+## Connections
+- [[it-tools]] ← deployed_via ← [[Docker Compose]]
+- [[Docker Compose]] ← dependency ← [[容器资源限制]]
+- [[Docker Compose]] ← dependency ← [[容器重启策略]]
+
+## Contradictions
+无
+
+## Metadata
+- **Author**: shenwei
+- **Tags**: docker, it-tools
+- **Source**: Home Office
--- a/wiki/sources/用docker安装transmission.md
+++ b/wiki/sources/用docker安装transmission.md
@@ -0,0 +1,47 @@
+---
+title: "用Docker安装transmission"
+type: source
+tags: [docker, transmission, home-office]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/用Docker安装transmission.md]]
+
+## Summary (用中文描述)
+- 核心主题：通过 Docker Compose 在 Home Server 部署 Transmission BT 下载服务
+- 问题域：BT 下载服务容器化部署、Web UI 访问、下载目录管理
+- 方法/机制：使用 linuxserver/transmission 官方镜像，通过 Docker Compose 定义端口映射、环境变量（PUID/PGID/TZ/认证）、卷挂载（配置目录+下载目录）实现一键部署
+- 结论/价值：Transmission 是家庭媒体中心的核心组件，与 Jellyfin/Navidrome 共同构成"下载→整理→播放"媒体工作流
+
+## Key Claims (用中文描述)
+- LinuxServer.io 维护的 Transmission 镜像通过 docker-compose 一键部署
+- 端口 9091 映射 Web UI 访问，端口 51413/UDP 映射 BT Peer 通信
+- PUID/PGID 环境变量实现容器内进程以宿主机用户权限运行，避免文件权限问题
+- TZ=Etc/UTC 配置容器时区，可根据需要调整为 Asia/Shanghai
+- USER/PASS 环境变量启用 Web UI 认证，保护服务安全
+
+## Key Quotes
+> "image: lscr.io/linuxserver/transmission:latest" — LinuxServer.io 官方维护镜像
+> "network_mode: bridge" — 采用桥接网络模式，与宿主机网络隔离但可访问
+> "restart: unless-stopped" — 容器异常退出后自动重启策略
+
+## Key Concepts
+- [[Docker Compose]]：YAML 格式定义多容器应用的配置规范，本文档使用 version: '3.8'
+- [[Docker Volume]]：持久化存储机制，/config 目录存储配置和下载状态，/downloads 目录挂载宿主下载目录
+- [[PUID/PGID]]：Docker 容器进程以宿主机指定用户运行的环境变量，解决文件权限问题
+- [[端口映射]]：-p host:container 格式将容器端口暴露到宿主机网络
+- [[桥接网络]]：bridge 网络模式下容器共享宿主机网络栈，实现端口映射访问
+
+## Key Entities
+- [[LinuxServer.io]]：开源 Docker 镜像维护组织，transmission 镜像官方来源
+- [[Transmission]]：开源 BT 下载客户端，Home Server 媒体中心核心组件
+- [[Docker]]：容器化部署平台，本文档使用 docker-compose 管理服务生命周期
+
+## Connections
+- [[Transmission]] ← deployed_via ← [[Docker Compose]]
+- [[Docker]] ← network_mode ← [[桥接网络]]
+- [[Transmission]] ← upstream_image ← [[LinuxServer.io]]
+
+## Contradictions
+- 无冲突；与 [[用Docker安装jellyfin]] 形成互补（jellyfin=播放，transmission=下载，共同服务于家庭媒体中心工作流）
--- a/wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md
+++ b/wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md
@@ -0,0 +1,64 @@
+---
+title: "网件RAX50路由器刷梅林固件与科学上网插件安装教程"
+type: source
+tags: [clash, merlin-clash, rax50, 科学上网, 路由器固件]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/网件RAX50路由器刷梅林固件与科学上网插件安装教程.md]]
+
+## Summary (用中文描述)
+- 核心主题：网件RAX50路由器刷入梅林固件并安装配置科学上网插件的完整实操教程
+- 问题域：家庭网络翻墙环境搭建、路由器固件定制、代理插件配置
+- 方法/机制：通过二次刷机（.chk过渡固件 → .w正式固件）完成梅林固件安装；通过MerlinClash插件实现策略组分流转发；通过订阅机制管理机场节点；通过JFFS双清确保固件环境干净
+- 结论/价值：提供了一套完整的"路由器官网固件 → 梅林固件 → 科学上网插件"的链路，适合家庭用户建立全屋翻墙网络
+
+## Key Claims (用中文描述)
+- 网件路由器必须通过`.chk`过渡固件才能刷入梅林固件，直接刷`.w`固件会失败
+- JFFS双清操作用于清理路由器文件系统缓存，刷机后执行可确保固件环境干净无残留
+- MerlinClash插件支持策略组配置，实现基于应用、地区和服务的自动分流和节点故障转移
+- 两款科学上网插件（MerlinClash与GitHub版本）不可同时开启，推荐使用功能更强的MerlinClash
+- 恢复出厂设置指的是梅林固件的默认配置，不会恢复网件原厂系统
+
+## Key Quotes
+> "必须先刷`.chk`的过渡固件，再刷`.w`的正式梅林固件，二次刷机才能确保稳定" — 刷机顺序的核心原则
+
+> "通过策略组配置不同节点和规则，实现基于应用、地区和服务的自动分流和节点故障转移" — MerlinClash的分流机制
+
+> "JFFS双清是清理文件系统和缓存，通常刷机后执行，确保固件环境干净无旧数据残留" — JFFS双清的作用说明
+
+> "访问Google和YouTube等被屏蔽网站，能成功打开说明科学上网成功" — 科学上网成功的判断标准
+
+## Key Concepts
+- [[固件刷入]]：将第三方固件写入路由器闪存以替换原厂固件的过程，RAX50需要两次刷机（过渡+正式）
+- [[过渡固件]]：用于引导原厂路由器进入可刷入目标固件状态的中间固件，`.chk`格式为网件专用过渡固件
+- [[JFFS双清]]：清理路由器JFFS分区（文件系统）和缓存的操作，用于刷机后重置干净环境
+- [[策略组分流]]：基于预定义规则（地区/应用/网站）对流量进行分类并转发到不同代理节点的机制
+- [[故障转移]]：当主代理节点连接失败时自动切换到备用节点以保持网络通畅的机制
+- [[订阅机制]]：通过机场提供的订阅链接自动获取和更新代理节点列表，无需手动配置
+
+## Key Entities
+- [[网件RAX50]]：NETGEAR AX3000双频WiFi 6路由器，型号Nighthawk RAX50，支持梅林固件
+- [[梅林固件]]：华硕路由器第三方改良固件，由Eric Sauvageau开发，支持更多插件和高级网络功能
+- [[MerlinClash插件]]：基于Clash核心的梅林固件代理插件，支持策略组、自动节点选择、分流规则和守护进程
+- [[KoolCenter固件服务器]]：提供梅林固件下载的服务器平台，包含华硕和网件路由器对应的固件版本
+- [[机场]]：提供代理节点订阅服务的服务商，用户通过订阅链接导入节点配置
+
+## Connections
+- [[网件RAX50]] ← 硬件平台 ← [[梅林固件]]
+- [[梅林固件]] ← 扩展能力 ← [[MerlinClash插件]]
+- [[MerlinClash插件]] ← 依赖 ← [[机场]]（订阅节点来源）
+- [[科学上网]] ← 技术手段 ← [[策略组分流]]
+- [[科学上网]] ← 技术手段 ← [[故障转移]]
+
+## Contradictions
+- 与 [[群晖NAS科学上网方法]] 冲突：
+  - 冲突点：科学上网部署位置
+  - 当前观点：本教程通过路由器层面实现全屋统一翻墙，所有设备无需单独配置
+  - 对方观点：NAS科学上网仅服务于NAS本身或特定容器，客户端设备仍需单独配置代理
+
+- 与 [[ubuntu-server科学上网]] 冲突：
+  - 冲突点：科学上网的部署层级
+  - 当前观点：路由器作为网关统一处理翻墙流量，对终端设备透明
+  - 对方观点：服务器端VPN/V2Ray服务需要每个客户端主动连接
--- a/wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md
+++ b/wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md
@@ -0,0 +1,89 @@
+---
+title: "通过VPS+内网反向代理实现域名访问内网穿透"
+type: source
+tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, 内网穿透]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md]]
+
+## Summary (用中文描述)
+- 核心主题：通过 VPS + frp + Caddy 实现内网服务的公网域名访问（内网穿透）
+- 问题域：家庭网络内网服务（NAS、Ubuntu 服务器）无法直接被公网访问的问题
+- 方法/机制：frp 反向隧道（frps 服务端 + frpc 客户端）+ Caddy 反向代理 + Let's Encrypt 自动 HTTPS
+- 结论/价值：建立完整的内网服务公网访问架构，支持 NAS n8n Grafana 等多服务通过独立子域名访问
+
+## Key Claims (用中文描述)
+- frp 专为内网穿透设计，支持 NAT 穿透、自动重连、Web 管理面板（可选）
+- VPS 上的 Caddy 反向代理到 frps 映射端口（127.0.0.1:xxxxx），提供 HTTPS 访问
+- SSH 穿透与 HTTP 不同，SSH 是纯 TCP 流量不经过 Caddy，只用 frps + frpc 配置即可
+- frps 监听 7000 端口，dashboard 可选监听 7500 端口
+
+## Key Quotes
+> "frp 优点：专为内网穿透设计，支持 NAT、自动重连、Web 管理面板（可选）。推荐当你有多台设备和多端口时使用。" — frp 核心优势说明
+
+> "SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 穿透的关键区别
+
+## Key Concepts
+- [[内网穿透]]：通过公网 VPS 建立反向隧道，使内网服务可被公网访问的技术
+- [[反向代理]]：VPS 上的 Caddy 将公网请求代理到 frp 映射的本地端口
+- [[TCP 隧道]]：frp 建立的 TCP 端口映射隧道，连接内网服务与公网 VPS
+- [[Let's Encrypt]]：Caddy 自动申请的免费 SSL 证书提供商
+
+## Key Entities
+- [[frp]]：内网穿透工具，包含 frps（服务端）和 frpc（客户端）两个组件
+- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器
+- [[阿里云 DNS]]：域名 ishenwei.online 的 DNS 解析服务提供商
+- [[VPS]]：公网服务器（192.227.222.142），运行 frps 和 Caddy 作为反向代理中转站
+
+## Connections
+- [[内网穿透]] ← uses ← [[frp]]
+- [[反向代理]] ← uses ← [[Caddy]]
+- [[反向代理]] ← depends_on ← [[TCP 隧道]]
+- [[VPS]] ← hosts ← [[frp]]
+- [[VPS]] ← hosts ← [[Caddy]]
+- [[群晖 NAS]] ← accessed_via ← [[内网穿透]]
+
+## Domain Mapping (本方案配置)
+| 域名 | 内网服务 | 映射端口 |
+|------|---------|---------|
+| nas.ishenwei.online | NAS Web UI | 192.168.3.17:5000 → VPS:15000 |
+| n8n.ishenwei.online | Ubuntu n8n | 192.168.3.47:5678 → VPS:15678 |
+| transmission.ishenwei.online | Ubuntu Transmission | 192.168.3.47:9091 → VPS:19091 |
+| grafana.ishenwei.online | Ubuntu Grafana | 192.168.3.47:3000 → VPS:13000 |
+| ubuntu1.ishenwei.online:60022 | Ubuntu SSH | 192.168.3.47:22 → VPS:60022 |
+
+## Architecture Diagram
+```
+Internet
+   │
+   ▼
+┌─────────────────────────────────────┐
+│ VPS (192.227.222.142)               │
+│  - frps (监听 7000)                │
+│  - Caddy (80/443 TLS)              │
+│     ├─ nas.ishenwei.online → 127.0.0.1:15000
+│     ├─ n8n.ishenwei.online → 127.0.0.1:15678
+│     └─ transmission.ishenwei.online → 127.0.0.1:19091
+└─────────────────────────────────────┘
+       ▲             ▲
+       │ frp tunnel  │ frp tunnel
+┌────────────┐   ┌────────────┐
+│ NAS (192.168.3.17)   │ │ Ubuntu (192.168.3.47) │
+│ frpc.ini              │ │ frpc.ini          │
+│ 映射5000→15000        │ │ 映射5678→15678         │
+└────────────┘   └────────────┘
+```
+
+## Contradictions
+- 无
+
+## Troubleshooting Summary
+1. 确认 frps 是否监听端口：`ss -lntup | grep 7000`
+2. 确认进程读取的配置：`ps -ef | grep frps`
+3. 确认防火墙放行：`sudo ufw status`
+4. 确认没有 Caddy/Nginx 占用端口
+5. 确认 token 一致性：`journalctl -u frps -n 100`
+6. telnet 诊断：`telnet 192.227.222.142 7000`
+7. 重启服务：`systemctl restart frps && systemctl restart frpc`