背景

new-api 原本运行在 Docker 中，默认使用 SQLite 数据库。随着日志、用户和渠道数据越来越多，SQLite 数据库体积已经接近 200MB，继续放在容器数据卷里不太适合长期维护。

我的目标是：

• 在 1Panel 管理的服务器上启动 MySQL 容器
• 把 new-api 的 SQLite 数据完整导入 MySQL
• 使用新容器先测试，再切换反向代理流量
• 尽量不影响线上服务

生产迁移里最重要的一点是：不要直接停旧服务。先把新环境跑起来，确认没问题以后再切流量。

iptables 与 Docker 端口映射问题

报错现象

在 1Panel 安装 MySQL 容器时，容器可以创建成功，但启动阶段失败，错误类似：

iptables: No chain/target/match by that name.

进一步看 Docker 相关日志，可以看到 nftables 后端不兼容的问题：

iptables v1.8.9 (nf_tables): chain `DOCKER' in table `filter' is incompatible, use 'nft' tool.

根因

Debian 12 bookworm 默认使用 iptables-nft，也就是 nftables 后端。Docker 需要维护自己的 DOCKER 链做端口映射，但当前环境下 filter 表里的链状态和 nft 后端不兼容。

这个问题有个容易误判的地方：已有容器的端口映射可能仍然正常，因为 NAT 表没有立即受影响；真正失败的是新建容器或新增端口映射。

修复方式

先备份当前 iptables 规则：

mkdir -p /root/backup-iptables-$(date +%Y%m%d)
iptables-save > /root/backup-iptables-$(date +%Y%m%d)/iptables-all.txt

然后把 iptables 和 ip6tables 切换到 legacy 模式：

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

最后重启 Docker：

systemctl restart docker

如果容器设置了 restart: always 或 unless-stopped，Docker 重启后容器会自动恢复。使用 host 网络模式的容器，例如 openresty，一般不受这个端口映射问题影响。

SQLite 到 MySQL 的迁移难点

new-api 使用 GORM，首次连接 MySQL 时可以自动建表，但这不等于会自动迁移 SQLite 数据。真实迁移还需要把 SQLite dump 转成 MySQL 可导入的 SQL。

直接转换会遇到几类问题：

1. SQLite 允许 TEXT 字段参与主键或索引，MySQL 会报 ERROR 1170。
2. SQLite 支持部分索引，例如 WHERE deleted_at IS NULL，MySQL 不能直接照搬。
3. SQLite 的 BLOB 字节串可能写成 X'...'，MySQL 的 JSON 列无法直接接受。
4. MySQL 不允许 TEXT 或 BLOB 字段设置默认值。
5. SQLite 默认大小写敏感，MySQL 默认排序规则通常大小写不敏感，唯一键可能产生冲突。

所以这一步不能只靠简单的搜索替换，更适合写转换脚本处理结构和数据。

转换脚本处理策略

我最后使用脚本生成了一份 MySQL 可导入 SQL，主要做了这些处理：

• 索引、主键、唯一键涉及的 TEXT 字段改成 VARCHAR(191)
• 非索引大文本字段改成 LONGTEXT
• SQLite 部分索引转换为 MySQL 可接受的表达式索引
• BLOB JSON 字节串转换为 UTF-8 JSON 字符串
• 带时区的 SQLite 时间转换为 MySQL DATETIME(6) 字面量
• 全部使用 utf8mb4_bin 排序规则，尽量保持 SQLite 的大小写敏感行为

迁移时不要把真实数据库密码、root 密码和 DSN 明文写进公开文章或仓库。下面命令里的敏感字段都用占位符代替。

蓝绿部署流程

整体流程是先导入数据，再启动新容器测试，最后切换反向代理。

1. 导入 MySQL 数据

先创建目标数据库和用户，并授予权限：

CREATE DATABASE `one-api` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'one-api'@'%' IDENTIFIED BY '<mysql-user-password>';
GRANT ALL PRIVILEGES ON `one-api`.* TO 'one-api'@'%';
FLUSH PRIVILEGES;

然后导入转换后的 SQL：

mysql -u one-api -p one-api < /root/one-api-mysql-importable.sql

如果已经让 new-api 连接过空 MySQL，GORM 可能已经插入默认数据。这种情况下需要先清空默认数据，避免导入时出现主键或唯一键冲突。

2. 启动 MySQL 版 new-api 容器

新容器先监听 3001，旧容器继续监听 3000：

docker run -d --name new-api-mysql \
  --network 1panel-network \
  --restart unless-stopped \
  -p 3001:3000 \
  -e SQL_DSN="one-api:<mysql-user-password>@tcp(<mysql-host>:3306)/one-api?charset=utf8mb4&parseTime=True&loc=Local" \
  -e TZ=Asia/Shanghai \
  -e ERROR_LOG_ENABLED=true \
  -e BATCH_UPDATE_ENABLED=true \
  -v /home/ubuntu/data/new-api-mysql:/app/data \
  calciumion/new-api:latest --log-dir /app/logs

这里要注意两点：

• new-api 容器必须加入能访问 MySQL 的 Docker 网络
• SQL_DSN 里建议带上 charset=utf8mb4&parseTime=True&loc=Local

3. 测试新容器

先用接口确认服务状态：

curl http://localhost:3001/api/status

正常情况下会返回 success: true。然后再检查用户、渠道、配置项、日志等核心表的数据量是否和 SQLite 对得上。

我这次迁移后的数据量大致如下：

| 表 | 行数 |
|

症状

Docker 容器创建完成后，启动阶段报错：

Error response from daemon: failed to set up container networking:
driver failed programming external connectivity on endpoint ...
Unable to enable OPEN PORT rule:
iptables: No chain/target/match by that name. (exit status 1)

这个报错容易误导人。容器本身不是不能创建，而是在 Starting 阶段设置端口映射失败。

根因

Debian 12 bookworm 默认使用 iptables-nft，也就是 nftables 后端。Docker 会在 iptables 里维护自己的 DOCKER 链，用于 bridge 网络和端口映射。

当 filter 表中的 DOCKER 链与 nft 后端状态不兼容时，就会出现类似错误：

iptables v1.8.9 (nf_tables): chain `DOCKER' in table `filter' is incompatible, use 'nft' tool.

一个关键细节是：NAT 表里的 DOCKER 链可能还是正常的，所以已有端口映射不一定会立刻坏。真正受影响的是新建容器或新增端口映射。

快速诊断

先看当前 iptables 使用的后端：

update-alternatives --query iptables | grep -E 'Status|Value'

再检查 filter 表里的 Docker 链：

iptables -L DOCKER -n

如果这里出现 incompatible 或链不存在，再看 NAT 表状态：

iptables -t nat -L DOCKER -n

最后确认当前容器和端口映射：

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

如果已有容器还在正常运行，但新容器起不来，基本就可以锁定在 Docker 端口映射和 iptables 后端兼容性上。

修复步骤

1. 备份现有规则

修网络规则前先备份，后面出问题才有回滚依据：

mkdir -p /root/backup-iptables-$(date +%Y%m%d)
iptables-save > /root/backup-iptables-$(date +%Y%m%d)/iptables-all.txt
iptables-save -t nat > /root/backup-iptables-$(date +%Y%m%d)/iptables-nat.txt
docker ps --format '{{.Names}} {{.Image}} {{.Status}}' > /root/backup-iptables-$(date +%Y%m%d)/containers.txt

2. 切换到 legacy 模式

把 IPv4 和 IPv6 的 iptables 都切到 legacy：

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

3. 重启 Docker

systemctl restart docker

如果容器配置了 restart: always 或 unless-stopped，Docker 重启后会自动拉起。

4. 验证

检查 DOCKER 链是否能正常显示：

iptables -L DOCKER -n

确认容器状态：

docker ps

检查关键端口是否监听：

ss -tlnp | grep -E ':80 |:443 |:3000 '

如果是 1Panel 里安装失败的应用，这时重新安装或重新启动应用，一般就可以恢复。

注意事项

• host 网络模式的容器通常不受这个问题影响，例如 openresty 直接监听宿主机端口。
• bridge 网络模式的容器依赖 iptables 做端口映射，MySQL、new-api 这类容器会受影响。
• 修复前确认重要容器有 restart policy，避免重启 Docker 后服务没有自动恢复。
• 如果系统启用了 firewalld，可能还要检查它是否改写了规则。
• 生产环境不要直接清空 iptables 规则，先备份再操作。

环境记录

这次遇到问题的环境大致如下：

| 项目 | 值 |
|

现象

执行 AWS-RunPatchBaseline 扫描失败，返回类似：

The find operation did not complete successfully

HResult 可能是：

-2145107934

同一网络环境下 Windows Server 2016 正常，Windows Server 2019 失败。

排查过程

1. 验证 SSM 相关端点

Test-NetConnection ssm.<region>.amazonaws.com -Port 443
Test-NetConnection ssmmessages.<region>.amazonaws.com -Port 443
Test-NetConnection ec2messages.<region>.amazonaws.com -Port 443

如果使用中国区或 VPC Endpoint，需要替换为对应域名。

2. 验证 Windows Update 网络

Test-NetConnection sls.update.microsoft.com -Port 443
Test-NetConnection download.windowsupdate.com -Port 80

同时检查是否配置 WSUS：

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -ErrorAction SilentlyContinue
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -ErrorAction SilentlyContinue

3. 导出 Windows Update 日志

Get-WindowsUpdateLog

如果日志出现：

The server returned HTTP status code '503'
The service is temporarily overloaded
*FAILED* [80244022] Web service call

说明 Windows Update 客户端已经连到微软服务，但服务端返回不可用。

根因

Windows Server 2019 可能访问的是某个特定微软更新服务域名，例如：

fe3.delivery.mp.microsoft.com

如果该服务端临时过载，就会返回 HTTP 503，对应错误码：

0x80244022

同一时间 Windows Server 2016 正常，可能是因为它访问的是另一组更新服务域名，未受影响。

规避方案

1. 等待微软服务恢复

如果确认网络、SSM、WSUS 配置都正常，且错误明确是 503，最直接的方式是等待服务恢复后重试。

2. 手动下载补丁

从 Microsoft Update Catalog 下载 .msu，再通过脚本或 SSM Run Command 安装：

https://www.catalog.update.microsoft.com/

3. 提前缓存补丁

Patch Manager 本身不提供“只下载不安装”的标准模式。可以使用自定义 SSM 文档提前下载补丁，在维护窗口再执行安装。

4. 部署 WSUS

对补丁窗口要求严格的环境，可以部署内网 WSUS，把补丁提前同步到本地服务器，降低对公网微软更新服务的依赖。

总结

SSM Patch Manager 扫描失败不一定是 SSM 问题。排查时要分层：

1. SSM Agent 是否在线。
2. AWS 端点是否可达。
3. Windows Update 端点是否可达。
4. WindowsUpdate.log 是否显示微软服务端 503。

如果日志已经明确 0x80244022 和 HTTP 503，通常应按微软更新服务临时不可用处理，考虑重试、手动补丁、提前缓存或 WSUS。

现象

补丁安装阶段看似成功，重启时出现：

We couldn't complete the updates
Undoing changes
Don't turn off your computer

进入系统后发现 OS Build 没有提升，再次安装仍然重复回滚。

WindowsUpdate.log 可能出现：

Post-reboot status ... 0x800f0922

CBS.log 中可见：

CBS_E_INSTALLERS_FAILED
Per-User Registry Installer ... 0x80070002

CSI 日志里还能看到历史用户 NTUSER.DAT 卸载失败。

排查思路

先排除常规原因：

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

同时检查：

• SSU 是否已安装。
• C 盘是否有足够空间。
• SoftwareDistribution / catroot2 重置后是否仍失败。

如果这些都正常，就要看 CBS/CSI 日志中是否集中出现在 Per-User Registry Installer 阶段。

根因

案例中问题集中在历史用户配置文件。服务器上存在多个历史用户目录、Unknown Profile，甚至体积异常大的用户配置文件。更新在重启阶段需要加载或卸载用户注册表 hive，某些 NTUSER.DAT 无法正常卸载，导致补丁事务失败并触发回滚。

处理方案

1. 先备份

生产环境操作前先创建 AMI 或快照。用户 Profile 清理有数据风险，不能直接在生产上盲删。

2. 清理 Unknown Profile

图形界面方式：

1. 运行 sysdm.cpl。
2. 进入“高级”选项卡。
3. 在“用户配置文件”区域点击“设置”。
4. 删除状态为 Unknown 或确认不再使用的历史用户配置文件。

3. 必要时清理注册表 ProfileList

谨慎打开注册表：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

对照 C:\Users 目录和 ProfileList 中的 SID，清理失效项。执行前应导出注册表备份。

4. 重新安装补丁

清理后重启，再重新安装目标累积更新。

5. 临时规避

如果不能立即清理 Profile，且后续月度补丁已发布，可以测试直接安装更新的累积补丁。Windows 累积更新通常包含前月安全内容，但这只能作为临时规避，根本问题仍应清理。

总结

Windows 补丁重启阶段回滚时，不要只盯着 Windows Update。CBS/CSI 里如果指向 Per-User Registry Installer 和用户 hive 卸载失败，就要重点检查历史用户配置文件。

服务器长期多人登录后，Profile 堆积很常见。建议定期清理废弃 Profile，避免在补丁窗口才暴露问题。

现象

用户访问 SMB 共享路径时提示没有权限。管理员已经在“安全”选项卡里给目标域组添加了权限，但访问仍失败。

关键概念

SMB 共享访问同时受两层权限控制：

• 共享权限（Share Permissions）
• 安全权限 / NTFS 权限（Security Permissions）

最终生效权限是两者交集。只配置 NTFS 权限，不配置共享权限，用户仍可能被拒绝。

排查步骤

1. 检查共享权限

使用域管理员登录一台已加入域的 Windows 机器，打开：

compmgmt.msc

连接到 FSx SVM DNS 名称，然后进入：

系统工具 -> 共享文件夹 -> 共享

找到目标共享，打开属性，检查“共享权限”选项卡。确认目标用户或组至少有读取权限。

2. 检查 NTFS 权限

再检查“安全”选项卡，确认文件系统权限也包含目标用户或组。

3. 刷新 Kerberos 票据

如果用户刚刚被加入某个域组，当前登录会话里的 Kerberos TGT 可能仍是旧组成员信息。

最稳妥方式是让用户完全注销后重新登录，而不是锁屏或断开 RDP。

也可以尝试清票：

klist purge

但生产排障中，完整注销重登更直观可靠。

为什么会这样

Windows 用户登录后会拿到包含组成员关系的 Kerberos 票据。如果管理员在用户登录期间修改组成员关系，用户现有票据不会立刻自动变成新权限。FSx 看到的仍然是旧身份信息，导致权限判断失败。

总结

FSx ONTAP SMB 共享访问被拒时，建议按这个顺序查：

1. 共享权限是否放行。
2. NTFS 权限是否放行。
3. 用户是否注销重登刷新 Kerberos 票据。

只看“安全”选项卡是不够的，这是 SMB 权限排查里最常见的误区。

现象

FSx 创建失败，后台或错误信息中出现：

setupFileServerRole failed
Get-ADComputer : Unable to contact the server.
This may be because this server does not exist, it is currently down,
or it does not have the Active Directory Web Services running.

这个错误通常发生在 FSx 设置文件服务器角色、加入或查询 AD 对象的阶段。

根因

Get-ADComputer 依赖 Active Directory Web Services，也就是 ADWS。ADWS 默认使用：

TCP 9389

对于 FSx for Windows 的 Single-AZ 2 和 Multi-AZ 类型，FSx 需要能访问域控制器的 TCP 9389。如果该端口被安全组、NACL、企业防火墙或跨区域网络策略阻断，文件系统创建会失败。

验证方法

在与 FSx 相同子网、相同安全组的加域 EC2 Windows 实例上运行 AD 验证工具。

Install-WindowsFeature RSAT-AD-PowerShell

Invoke-WebRequest `
  "https://docs.aws.amazon.com/fsx/latest/WindowsGuide/samples/AmazonFSxADValidation.zip" `
  -OutFile "AmazonFSxADValidation.zip"

Expand-Archive -Path "AmazonFSxADValidation.zip"
Import-Module .\AmazonFSxADValidation

$Credential = Get-Credential
$Args = @{
  DomainDNSRoot  = "example.com"
  DnsIpAddresses = @("DC_IP_1", "DC_IP_2")
  SubnetIds      = @("subnet-xxxxxxxx")
  Credential     = $Credential
}

$Result = Test-FSxADConfiguration @Args
$Result.Failures

如果输出中有 TCP 9389 失败项，就能确认是 ADWS 端口连通性问题。

Single-AZ 1 为什么可能成功

Single-AZ 1 对 TCP 9389 的要求不同，可能在同一环境下创建成功。这可以帮助判断服务账号权限、DNS 和基础 AD 端口是否正常。

如果 Single-AZ 1 成功，而 Single-AZ 2 / Multi-AZ 失败，排查重点应转向 TCP 9389。

解决方案

放行 FSx 子网到全部域控的 TCP 9389：

• FSx 安全组出站。
• 域控安全组入站。
• 网络 ACL 双向规则。
• 本地或跨区域防火墙策略。
• 企业网络中的中间防火墙。

放行后重新运行验证工具，确认没有失败项，再重新创建 FSx。

总结

FSx for Windows 加入自建 AD 失败时，不要只查 389、445、88 这些常见端口。对于 Single-AZ 2 和 Multi-AZ，TCP 9389 同样关键。

看到 Get-ADComputer 或 ADWS 相关错误时，优先验证 FSx 子网到全部 DC 的 9389 连通性。

适用前提

启用 SQL Server HA 许可节省前，先确认环境满足要求：

• Windows Server 2019 或更高版本。
• SQL Server 2017 或更高版本。
• 一个 HA 集群只支持两个 EC2 节点。
• 实例需要运行 SSM Agent。
• 实例 IAM Role 需要具备 EC2 SQL HA 和 SSM 相关权限。

如果环境还是 Windows Server 2016，或集群超过两个节点，就不满足该功能前提。

备用节点的限制

备用节点要获得许可减免，必须保持被动：

• 不处理传入业务流量。
• 不运行活动 SQL Server 工作负载。
• 不能作为可读辅助副本承担读查询。
• 不应在可用性组外运行独立数据库。

核心判断很简单：只要这个节点在提供数据服务，就不再是纯 standby。

可读辅助副本会影响减免

Always On 可用性组里启用 Readable Secondary 后，辅助副本可以被应用、报表或人工查询访问。按许可逻辑，这已经属于活动使用，需要完整 SQL Server 授权。

因此，如果目标是拿 standby 节点许可减免，不应启用可读辅助副本。

备份是否需要可读辅助

不需要。SQL Server 支持在不可读的辅助副本上执行某些备份场景。也就是说，为了全量备份和日志备份，不必把辅助副本设置为 readable。

实际配置前应结合 SQL Server 版本和可用性组备份首选项验证。

启用步骤概览

1. 确认 SSM Agent 在线

aws ssm describe-instance-information

实例应显示 PingStatus: Online。

2. 配置 IAM 权限

给实例配置文件附加：

• AmazonSSMManagedInstanceCore
• AWSEC2SqlHaInstancePolicy

3. 准备 SQL 凭证

默认可以使用 NT AUTHORITY\SYSTEM 读取 SQL Server HA 元数据。如果环境限制了该账户，则需要把 SQL Server 凭证放入 Secrets Manager，并在启用时指定。

4. 在 EC2 控制台启用

在 EC2 控制台选择 HA 集群相关实例，进入：

Actions -> Instance settings -> Modify SQL High Availability settings

检查前置条件，通过后启用 license savings。

启用后应能看到：

• 主节点：Active / Full license included
• 备用节点：Standby / Waived

总结

SQL Server HA 备用节点许可减免不是简单开关。真正关键的是 standby 节点必须保持被动。

如果为了查询、报表或应用读取启用 readable secondary，就会失去减免资格。备份场景应优先使用 SQL Server 支持的辅助副本备份能力，而不是把备用节点变成可读工作负载节点。

现象

在 Server Manager 的 “Remove Roles and Features” 中取消 .NET Framework 4 后，重启实例出现：

• Server Manager 打不开。
• PowerShell 执行 ServerManager 提示命令不存在。
• Install-WindowsFeature 报 feature 名称不存在。
• 部分 PowerShell 管理能力失效。

示例错误：

ServerManager : The term 'ServerManager' is not recognized

根因

Windows Server 的 Server Manager 和相关 PowerShell 模块依赖 NetFx4-OC-Package。在图形界面取消 .NET Framework 4 Features，实际会把一批依赖 NetFx4 的 OC 包一起 disable。

这和 .NET Framework 4.8 运行时版本不是一回事。注册表里仍可能显示 .NET 4.8 存在，但 Windows 可选组件层面的 NetFx4 已被关闭。

另外，NetFx3 不能替代 NetFx4。执行：

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

无法恢复依赖 .NET 4 的 Server Manager。

恢复步骤

操作前建议创建 AMI 备份，所有命令以管理员身份运行。

1. 启用 NetFx4

DISM /Online /Enable-Feature /FeatureName:NetFx4 /All

2. 启用 Server Manager 图形管理组件

DISM /Online /Enable-Feature /FeatureName:Server-Gui-Mgmt /All

3. 重启实例

shutdown /r /t 0

重启后再验证。

4. 按需恢复其它依赖组件

如果业务用到 IIS、WCF、PowerShell ISE 或 DSC，可以按需启用：

DISM /Online /Enable-Feature /FeatureName:NetFx4Extended-ASPNET45 /All
DISM /Online /Enable-Feature /FeatureName:WCF-HTTP-Activation45 /All
DISM /Online /Enable-Feature /FeatureName:WCF-TCP-PortSharing45 /All
DISM /Online /Enable-Feature /FeatureName:IIS-ASPNET45 /All
DISM /Online /Enable-Feature /FeatureName:IIS-NetFxExtensibility45 /All
DISM /Online /Enable-Feature /FeatureName:MicrosoftWindowsPowerShellISE /All
DISM /Online /Enable-Feature /FeatureName:DSC-Service /All

验证

ServerManager
Get-Command Install-WindowsFeature
DISM /Online /Get-Features | findstr /I "NetFx4 Server-Gui PowerShell"

总结

为了满足 .NET 版本合规，正确方式是安装 .NET 累积更新，而不是关闭 .NET Framework 4 Features。后者不会让 .NET 从系统中“安全消失”，反而会破坏 Windows Server 管理工具链。

恢复时仅启用 NetFx4 还不够，必须同时启用 Server-Gui-Mgmt 并重启。

风险点

如果直接对 C 盘启用 BitLocker 并重启，可能出现：

• 实例状态显示 running，但 RDP 无法连接。
• 启动阶段等待 BitLocker 密码或恢复密钥。
• 控制台黑屏或无法输入。
• 业务长时间不可用，只能通过快照/AMI 回滚。

因此必须先验证 EC2 串行控制台可用。

操作前准备

• 创建 AMI 或 EBS 快照。
• 在测试实例完整演练。
• 记录并离线保存恢复密钥。
• 确认可接受重启和短暂停机窗口。

启用串行控制台 SAC

在管理员 PowerShell 中执行：

bcdedit /ems '{current}' on
bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200

bcdedit /set '{bootmgr}' displaybootmenu yes
bcdedit /set '{bootmgr}' timeout 15
bcdedit /set '{bootmgr}' bootems yes

shutdown -r -t 0

重启后，在 EC2 控制台通过“连接 -> EC2 串行控制台”确认可以进入启动界面。如果串行控制台不可用，不要继续加密系统盘。

安装 BitLocker 功能

通过 Server Manager 添加 BitLocker，或使用 PowerShell：

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools
Restart-Computer

配置无 TPM 启动

运行 gpedit.msc，进入：

计算机配置 -> 管理模板 -> Windows 组件 -> BitLocker 驱动器加密 -> 操作系统驱动器

启用“启动时需要附加身份验证”，并勾选“没有兼容的 TPM 时允许 BitLocker”。

加密数据盘

数据盘建议先测试：

1. 右键数据盘启用 BitLocker。
2. 选择密码解锁。
3. 保存恢复密钥。
4. 加密完成后配置自动解锁。

如果没有自动解锁，每次重启后业务可能因为数据盘锁定而不可用。

加密系统盘

启用 C 盘 BitLocker，选择密码解锁，保存恢复密钥，并运行 BitLocker 系统检查。

重启后：

1. RDP 暂时不可用。
2. 进入 EC2 串行控制台。
3. 在黑屏阶段输入 BitLocker 密码并回车。
4. Windows 解锁后继续启动。
5. 系统启动完成后再恢复 RDP。

总结

EC2 Windows 上做 BitLocker 的关键不是点击“启用加密”，而是启动阶段能否解锁。

必须做到：

• 加密前创建 AMI/快照。
• 先启用并验证 EC2 串行控制台。
• 保存恢复密钥。
• 数据盘配置自动解锁。
• 先在测试环境演练完整重启流程。

如果只是为了云上 EBS 静态加密，优先使用 EBS encryption；BitLocker 更适合 BYOL 或特定合规场景。

现象

• 实例处于 running。
• 系统状态检查和实例状态检查正常。
• 安全组允许 3389。
• 实例可 ping。
• RDP 无法登录。
• Stop & Start 后恢复。

这种现象很像网络问题，但日志可能指向系统资源不足。

关键日志

事件日志中可能出现：

Not enough storage is available to process this command.

以及：

System.OutOfMemoryException

还可能看到 Winlogon 相关事件，例如 Winlogon 崩溃或无法正常创建登录会话。

这里的 “storage” 不一定指磁盘，Windows 错误码上下文中也可能指内存或系统资源不足。

根因

实例内存和分页文件资源耗尽后，系统无法为关键进程分配资源。RDP 登录依赖的 Winlogon、LSASS、远程桌面服务等组件可能无法正常工作。

Stop & Start 会清空内存状态，所以故障临时消失，但如果实例规格或应用内存占用不解决，问题还会复发。

排查方向

1. 查看事件日志

重点看故障发生前后的：

• Application.evtx
• System.evtx
• Setup.evtx

关注：

• OutOfMemoryException
• Not enough storage is available
• Winlogon 错误
• 安全软件或监控代理异常
• Windows Update 相关异常

2. 检查实例规格

确认当前实例内存是否满足业务峰值。如果长期接近上限，应升级实例规格或优化应用。

3. 部署 OS 指标监控

CloudWatch 默认不采集 Windows 内存指标。需要安装 CloudWatch Agent，采集：

• Memory 使用率
• Pagefile 使用率
• Disk 使用率
• 关键进程指标

并设置告警，例如内存使用率超过 85% 提醒。

处理建议

短期恢复

Stop & Start 可以释放内存，临时恢复登录能力。但这不是根治。

中期优化

排查占用内存高的应用、监控代理、安全软件，确认是否存在内存泄漏或配置过重。

长期方案

如果业务峰值确实需要更多内存，应升级到更大规格。升级前先创建 AMI，确认实例类型兼容 ENA/NVMe。

总结

RDP 登录失败不一定是 3389、安全组或 NACL 问题。只要实例仍可 ping、状态检查通过，就应同时查看 Windows 事件日志。

如果日志里出现 OOM、系统资源不足和 Winlogon 异常，根因很可能是内存耗尽。Stop & Start 只能临时恢复，长期需要监控内存并调整实例规格或应用配置。

现象

客户端访问：

\\<server-private-ip>\share

无法打开，也不弹出认证窗口。命令行执行：

net use Z: \\<server-private-ip>\share

报错：

发生系统错误 1792
试图登录，但是网络登录服务没有启动

之后甚至出现 445 端口连接超时、ping 不通等现象。

排查过程

1. 先排除 AWS 网络

确认：

• 两台实例在同 VPC 或路由可达。
• 安全组放行 TCP 445。
• NACL 未拦截。
• 路由表有 local 或正确路由。
• Windows Defender 防火墙策略不拦截。

2. 双端抓包

抓包可以看到 SMB 协议已经开始协商：

SMB2 Negotiate Protocol Request
SMB2 Negotiate Protocol Response
SMB2 Session Setup Request
SMB2 Session Setup Response: STATUS_NETLOGON_NOT_STARTED

这说明流量已经到达服务端，不是 AWS 底层网络丢包。

3. 理解 Netlogon

Workgroup 环境下，Netlogon 服务默认不运行是正常的。本地账户 SMB 认证通常通过本地 SAM + NTLM 完成，不应该因为 Netlogon stopped 就必然失败。

如果返回 STATUS_NETLOGON_NOT_STARTED 后又出现所有流量被阻断，应该怀疑安全软件或 EDR 对 SMB 认证流量做了拦截。

解决方法

1. 临时停用 EDR 验证

在变更窗口内临时停用安全软件，验证 SMB 是否恢复。如果停用后 445 和 ping 都恢复，基本可以确认根因。

2. 使用本地账户显式认证

在 Workgroup 环境中，不要依赖隐式凭据。使用服务器本地账户：

net use Z: \\<server-private-ip>\share /user:<server-computer-name>\Administrator

注意 <server-computer-name> 必须是服务端计算机名，不是客户端。

3. 调整 EDR 策略

联系安全软件厂商或安全团队，把正常 SMB/NTLM 认证流量加入白名单，避免误拦截。

4. 长期建议加入域

如果多台 Windows 实例频繁共享文件，建议加入 Active Directory，使用域账户和组权限统一管理，减少 Workgroup + 本地账户认证的复杂度。

总结

EC2 Windows SMB 不通时，不能只看安全组。抓包如果已经看到 SMB 协议协商和认证阶段错误，就说明问题进入 OS 或安全软件层。

STATUS_NETLOGON_NOT_STARTED 在 Workgroup 场景下不一定代表 Netlogon 本身是根因。结合后续流量被阻断，EDR 或安全软件拦截是重点排查方向。

VM Export 为什么失败

执行 create-instance-export-task 时可能报：

An error occurred (NotExportable) when calling the CreateInstanceExportTask operation:
The image ID (ami-xxxxxxxx) provided contains AWS-licensed software and is not exportable.

这是产品限制，不是 IAM 权限问题。从 AWS 公有 AMI 启动的 Windows / SQL Server / Marketplace 镜像通常不可导出。

替代方案

可选方案：

• 实例能登录：用 Disk2vhd。
• 不想起救援实例：用 coldsnap + qemu-img。
• 可以停机或系统已崩溃：用救援实例块级读取 EBS，再 qemu-img 转换。

本文记录第三种方案。

关键坑：存储控制器驱动

EC2 Windows 通常运行在 NVMe 设备上。导出到 VMware 后，控制器可能变成 LSI Logic SAS、SATA 或 IDE。如果 Windows 注册表中这些驱动没有设置为 Boot 加载，启动时会蓝屏：

UNMOUNTABLE_BOOT_VOLUME

所以转换前要离线修改 SYSTEM hive，把常见存储驱动 Start 值设为 0。

操作步骤

1. 停机并摘卷

aws ec2 stop-instances --instance-ids <instance-id>
aws ec2 wait instance-stopped --instance-ids <instance-id>

aws ec2 detach-volume --volume-id <volume-id>
aws ec2 wait volume-available --volume-ids <volume-id>

aws ec2 attach-volume \
  --volume-id <volume-id> \
  --instance-id <helper-instance-id> \
  --device /dev/sdg

操作前建议先给卷创建快照。

2. 在救援实例识别磁盘

sudo lsblk -o NAME,SIZE,SERIAL,MOUNTPOINT,FSTYPE

Nitro 实例上 EBS 会显示为 /dev/nvmeXn1，可以通过 SERIAL 对应卷 ID。

3. 挂载工作盘

sudo mkfs.xfs -f /dev/nvme1n1
sudo mkdir -p /mnt/work
sudo mount /dev/nvme1n1 /mnt/work

工作盘大小要大于目标卷实际输出大小。

4. 安装工具

sudo dnf install -y qemu-img gcc make perl

如果仓库没有 hivex，需要从源码安装，用于编辑 Windows 注册表 hive。

5. 挂载 NTFS 并备份 SYSTEM hive

sudo modprobe ntfs3
sudo mkdir -p /mnt/windows
sudo mount -t ntfs3 -o rw /dev/nvme2n1p1 /mnt/windows

sudo cp /mnt/windows/Windows/System32/config/SYSTEM /mnt/work/SYSTEM_BACKUP
sudo cp /mnt/windows/Windows/System32/config/SYSTEM /tmp/SYSTEM_EDIT

6. 启用通用存储驱动

需要把这些服务的 Start 设置为 0：

| 服务 | 用途 |
|

现象

访问内网服务时报错：

curl https://service.example.internal/api/v1/health

curl: (60) SSL certificate problem: unable to get local issuer certificate

架构大致是：

客户端 -> 内网 ALB 443 -> 后端目标 443

如果绕过 ALB，直接访问后端目标可以成功，就说明后端服务本身大概率不是根因。

排查思路

1. 不要用公网 SSL 检查结果下结论

如果域名在 Route 53 私有托管区里解析到内网 ALB，公网 SSL checker 看到的可能是另一条公网解析记录。公网检查结果无法代表内网 ALB 实际下发的证书。

2. 用 openssl 看 ALB 实际证书

在内网客户端执行：

openssl s_client -showcerts \
  -connect <alb-dns-name>:443 \
  -servername service.example.internal </dev/null

重点看两件事：

• 证书 SAN/CN 是否覆盖访问域名。
• ALB 下发的中间证书是否和站点证书签发链匹配。

3. 区分两个问题

证书链断裂和域名不匹配是两个不同问题：

• 链断裂会导致客户端找不到可信上级 CA。
• SAN 不覆盖域名会导致主机名校验失败。

两者任何一个存在，HTTPS 都可能失败。

根因

案例中站点证书由某个 DV 中间 CA 签发，但导入 ACM 时附带的是另一个 OV 中间 CA。ALB 因此向客户端下发了不匹配的中间证书链，curl 无法构建完整信任链。

同时，ALB 绑定证书的 SAN 也没有覆盖实际访问域名。也就是说，即使证书链修好，仍然会因为域名不匹配继续失败。

解决方案

1. 修正 ACM 证书链

重新导入原 ACM 证书，上传正确的中间证书链：

aws acm import-certificate \
  --certificate-arn <certificate-arn> \
  --certificate fileb://site.crt \
  --private-key fileb://site.key \
  --certificate-chain fileb://correct-chain.crt

使用 reimport 的好处是保留原 ARN，ALB 侦听器不需要重新选择证书。

2. 确保证书覆盖访问域名

检查证书 SAN 是否包含实际使用的域名：

openssl x509 -in site.crt -noout -text | grep -A1 "Subject Alternative Name"

如果不包含，需要申请或导入一张覆盖目标域名的新证书，并绑定到 ALB HTTPS 侦听器。

3. 清理 ALB 侦听器证书

如果 ALB 上挂了多张证书，建议清理不再使用的证书，避免 SNI 匹配和运维判断混乱。

总结

ALB HTTPS 报 unable to get local issuer certificate 时，排查重点是 ALB 实际下发的证书链，而不是后端 Nginx 或公网 SSL 检查结果。

推荐固定排查顺序：

1. 在内网用 openssl s_client -showcerts 看 ALB 下发证书。
2. 检查 SAN/CN 是否覆盖访问域名。
3. 检查中间证书是否与站点证书签发链匹配。
4. 用 ACM reimport 修正证书链，必要时更换侦听器证书。

场景

目标是统计某个开启版本控制的 S3 桶内：

• 指定扩展名对象数量。
• 指定扩展名对象总容量。
• 包含所有历史版本，而不只是当前版本。

如果业务要求“现在就要结果”，S3 Inventory 不一定合适，因为它是异步报表，首次生成通常有延迟。

为什么用 list-object-versions

普通 list-objects 只看当前对象版本，不能覆盖历史版本。开启版本控制的桶应使用：

aws s3api list-object-versions

再通过 --query 'Versions[*].[Key, Size]' 只取对象 Key 和 Size，减少后续处理成本。

统计命令

下面示例统计 .jpg 和 .png：

aws s3api list-object-versions \
  --bucket <bucket-name> \
  --region <region> \
  --query 'Versions[*].[Key, Size]' \
  --output text |
grep -Ei "\.(jpg|png)[[:space:]]+[0-9]+$" |
awk '
BEGIN {
  fmt = "图片对象总数（含历史版本）: %d\n"
}
{
  count++;
  size += $NF;
}
END {
  print "======================";
  printf fmt, count;
  printf "总容量（含历史版本）: %.2f GB\n", size/1024/1024/1024;
  print "======================";
}'

示例输出：

======================
图片对象总数（含历史版本）: 120446
总容量（含历史版本）: 56.33 GB
======================

注意事项

• 建议在同区域 EC2 上执行，减少网络延迟。
• 如果对象很多，CLI 调用会产生 List 请求费用。
• 如果要统计当前版本，不要用 list-object-versions，改用 list-objects-v2。
• 如果对象规模特别大、可接受延迟，S3 Inventory 更适合做周期性报表。
• 如果 Key 中包含换行等特殊字符，文本管道处理会有边界问题，严谨场景建议用 JSON + jq。

总结

紧急统计 S3 桶中特定扩展名对象时，list-object-versions + grep + awk 是一个简单有效的方案。它的优点是实时、轻量、无需等待 Inventory；缺点是更偏一次性统计，不适合长期周期报表。

场景

客户环境中大量域用户通过 SAML AssumeRole 登录 AWS 控制台，使用的可能是 PowerUser 或 Administrator 这类高权限 Role。

出于合规要求，需要限制某些用户不能通过控制台进入 EC2 实例，主要涉及两类能力：

• SSM Session Manager：ssm:StartSession
• EC2 Instance Connect：ec2-instance-connect:SendSSHPublicKey

为什么不用 RoleSessionName

SAML 联合登录后，IAM 会生成会话标识。策略判断时更稳定可用的是全局条件键 aws:userid。它通常包含角色 ID 和会话名称，形式类似：

<role-id>:<session-name>

因为 role ID 部分会随 Role 变化，不适合硬编码，所以可以用通配符匹配会话后缀：

*:user-or-ou-id

示例策略

在目标 IAM Role 上增加一个显式 Deny：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2LoginForSpecificFederatedUsers",
      "Effect": "Deny",
      "Action": [
        "ssm:StartSession",
        "ec2-instance-connect:SendSSHPublicKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:userid": [
            "*:<user-or-ou-id>"
          ]
        }
      }
    }
  ]
}

显式 Deny 优先级高于 Allow，所以即使 Role 里已有高权限策略，匹配条件的用户仍会被拦截。

验证方式

1. 使用目标 SAML 用户登录控制台。
2. 尝试通过 Session Manager 连接 EC2。
3. 尝试使用 EC2 Instance Connect。
4. 再用非受限用户验证不受影响。

如果 Deny 生效，目标用户会在调用相关 API 时被拒绝。

更推荐的长期方案

基于 aws:userid 硬编码用户后缀能快速解决问题，但维护成本高。更好的方式是从身份源层面拆分权限：

• 在 AD 中建立受限用户组，例如 AWS-No-EC2-Login。
• 在 IdP 中把不同用户组映射到不同 IAM Role。
• 创建专门的受限 Role，不授予 EC2 登录能力。

这样权限边界更清晰，也更容易审计和自动化管理。

总结

如果需要临时限制部分 SAML 用户通过控制台登录 EC2，可以用 aws:userid + 显式 Deny 精准拦截 ssm:StartSession 和 ec2-instance-connect:SendSSHPublicKey。

长期来看，建议把用户分组和 Role 映射放到身份源侧管理，而不是在一个高权限 Role 里维护越来越复杂的条件策略。

现象

执行分区扩容：

sudo growpart /dev/nvme0n1 1

返回类似错误：

failed [sfd_list:1] sfdisk --list --unit=S /dev/nvme0n1
FAILED: failed: sfdisk --list /dev/nvme0n1

环境通常是：

• Nitro 架构实例。
• Amazon Linux 2。
• 根文件系统为 XFS。
• 设备名为 /dev/nvme0n1，根分区是 /dev/nvme0n1p1。
• / 已经接近或达到 100%。

根因

growpart 执行时需要在系统目录中创建临时文件并重写分区表。如果根文件系统已经满到只剩几十 KB，底层 sfdisk 调用可能无法正常完成，于是表现为分区扩容失败。

这时首要任务不是继续反复执行 growpart，而是先释放一点根分区空间。

处理步骤

1. 清理 yum 缓存

Amazon Linux 2 上可以先清理 yum 缓存：

sudo yum clean all

确认根分区至少有几 MB 可用空间：

df -h /

2. 扩展分区

sudo growpart /dev/nvme0n1 1

3. 扩展 XFS 文件系统

XFS 需要用挂载点扩容：

sudo xfs_growfs -d /

如果是 ext4，则应使用：

sudo resize2fs /dev/nvme0n1p1

4. 验证

df -hT /
lsblk

确认根分区大小和可用空间已经更新。

注意事项

• EBS 控制台修改卷大小后，需要等待状态完成再进系统扩容。
• 单个 EBS 卷有修改频率限制，不要频繁试错扩容。
• 根分区快满时，建议优先清理缓存、旧日志和临时文件。
• 长期建议用 CloudWatch Agent 采集磁盘使用率，提前告警。

总结

growpart 报 sfdisk 失败不一定是分区表坏了，也可能只是根文件系统没有空间让工具运行。对 Amazon Linux 2 + XFS 的根卷扩容，可以按这个顺序处理：

1. 清理出少量空间。
2. growpart 扩分区。
3. xfs_growfs 扩文件系统。
4. df -hT 验证。

现象

故障分成两类：

1. 实例启动失败，CloudTrail 中能看到 KMS CreateGrant 或 Decrypt 权限不足。
2. 实例可以尝试启动，但系统日志卡在：

Give root password for maintenance
(or press Control-D to continue):

第二种情况会导致 OS 无法完整启动，实例无法响应底层健康检查，最终表现为实例状态检查异常。

问题一：KMS 权限不足

如果 EBS 卷使用 KMS CMK 加密，启动实例的 IAM 角色必须具备使用该 KMS key 的权限。至少需要：

{
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:CreateGrant"
  ],
  "Resource": "arn:aws-cn:kms:<region>:<account-id>:key/<key-id>"
}

如果角色没有权限，EC2 在启动阶段无法解密系统盘或数据盘，实例就会启动失败。

问题二：fstab 阻塞启动

Linux 上 NVMe 设备名可能随重启或底层变化改变。如果 /etc/fstab 中写死了类似：

/dev/nvme2n1p1 /data ext4 defaults 1 2

当设备名变化或卷不存在时，系统会在启动阶段等待挂载，最终进入 emergency / maintenance 模式。

更稳的写法是用 UUID 并加 nofail：

UUID=<volume-uuid> /data ext4 defaults,nofail 1 2

网络文件系统还应加 _netdev：

server:/share /mnt/share nfs defaults,_netdev,nofail 0 0

通过救援实例修复 fstab

1. 准备救援实例

在同可用区启动一台 Linux 救援实例。停止原实例后，分离原根卷并挂载到救援实例。

2. 挂载原系统根分区

如果原系统使用 LVM，先安装工具并激活卷组：

sudo dnf install lvm2 -y
sudo vgscan
sudo vgchange -ay
sudo lvs

挂载原根分区：

sudo mkdir -p /mnt/rescue
sudo mount -o nouuid /dev/<vg-name>/<root-lv> /mnt/rescue

3. 修改 fstab

sudo vi /mnt/rescue/etc/fstab

先把有风险的数据盘挂载项注释掉，让系统能启动。启动后再用 lsblk -f 获取 UUID，改成稳定配置。

4. 卸载并挂回原实例

sudo umount /mnt/rescue
sudo vgchange -an

然后在控制台把根卷挂回原实例，启动并验证。

验证

实例启动后执行：

lsblk -f
sudo systemctl daemon-reload
sudo mount -a
df -h

mount -a 无报错，说明 fstab 配置基本正常。

总结

EC2 Linux 启动失败要区分两层：

• AWS 控制面：KMS、IAM、EBS 状态、卷挂载关系。
• OS 内部：fstab、LVM、文件系统、网络挂载。

加密卷启动失败优先查 CloudTrail 和 KMS 权限；系统卡维护模式优先查控制台系统日志和 /etc/fstab。数据盘挂载建议统一使用 UUID + nofail，避免设备名变化把系统启动卡死。

现象

手动安装某个 Windows Server 2019 累积更新时，安装器返回：

The update is not applicable to your computer

CBS 日志中可能出现：

Higher version found for package ..., superseded.

WindowsUpdate.log 中可能看到：

The volatile RebootRequired key exists

分析思路

1. 比对 OS Build

先看当前系统版本：

winver

或者读取注册表：

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" |
  Select-Object CurrentBuildNumber, UBR

如果当前 Build 已高于目标 KB 对应版本，说明该 KB 内容已经被更高版本累积更新覆盖，安装“不适用”是正常结果。

2. 看 CBS 是否已安装更高包

CBS.log 里的 Higher version found 很关键。Windows 累积更新之间存在取代关系，较新的 LCU 已包含旧 LCU 的内容。

3. 检查是否需要重启

如果 WindowsUpdate.log 出现 RebootRequired，说明系统可能已经完成阶段性安装，但注册表中的 Build/UBR 还没在重启过程中更新。

这会导致 winver 看起来仍是旧版本，而 CBS 已经显示更高版本包存在。

解决方案

1. 不要重复安装旧 KB

如果 CBS 已显示系统存在更高版本包，应停止继续安装旧 KB，避免浪费维护窗口。

2. 在维护窗口重启

生产环境建议先创建 AMI 备份，再重启实例：

Restart-Computer

重启后再次检查：

winver
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

3. 优先安装最新累积更新

如果没有必须安装某个旧 KB 的合规要求，建议直接安装最新 LCU。Windows 累积更新通常包含此前更新内容。

总结

“此更新不适用于您的计算机”不一定是失败。排查时不要只看 winver，还要结合：

• 目标 KB 对应的 OS Build。
• CBS.log 中是否已有更高版本包。
• WindowsUpdate.log 中是否存在 RebootRequired。

如果系统已经安装更高版本更新但尚未重启，正确动作通常是安排维护窗口重启，而不是反复手动安装旧补丁。

背景

某些 .NET 累积更新是容器包，里面包含多个真正适用的 .msu。例如一个总 KB 可能内嵌：

• .NET 3.5 + 4.7.2 的 MSU。
• .NET 3.5 + 4.8 的 MSU。

如果系统已经是 .NET 4.8，只需要安装对应 4.8 的那份。

关键日志

WindowsUpdate.log 反复出现：

ProtocolTalker  *FAILED* [C8000402] PopulateDataStore failed
ProtocolTalker  *FAILED* [C8000402] Sync of Updates
Agent           * END * Finding updates ... Exit code = 0xC8000402

CBS.log 中却搜不到目标 KB 的痕迹。

这说明补丁还没有进入 CBS 安装引擎，失败发生在更早的 WUA 扫描阶段。

根因判断

wusa.exe 安装 .msu 的流程大致是：

双击 .msu -> wusa.exe -> WUA 适用性扫描 -> CBS 安装

如果 WUA 的 DataStore 损坏，或者离线扫描源反复注册导致元数据污染，WUA 可能在 PopulateDataStore 阶段失败，最终返回 “0 updates found” 或安装失败。

此时继续双击 .msu 没意义，因为永远到不了 CBS。

解决方案：解包后用 DISM 注入 cab

核心思路是绕过 WUA，直接让 CBS 处理 CAB 包。

1. 解压 MSU

$msu = "C:\Patches\windows10.0-kbxxxxx-x64-ndp48.msu"
$dst = "C:\Patches\Extract"
New-Item -ItemType Directory -Force -Path $dst | Out-Null
expand.exe -F:* $msu $dst

2. 用 DISM 安装 CAB

$cab = Get-ChildItem $dst -Filter "Windows10.0-KB*.cab" | Select-Object -First 1
DISM.exe /Online /Add-Package /PackagePath:"$($cab.FullName)" /NoRestart /LogPath:C:\Patches\dism.log

3. 重启

shutdown /r /t 30

4. 验证

Get-HotFix -Id KBxxxxx
DISM.exe /Online /Get-Packages | findstr /I "DotNetRollup"

如果是 .NET 更新，还可以检查关键 .NET 文件版本是否更新。

可选：修复 WUA 扫描通道

如果后续还需要 Windows Update 正常扫描，可以重置 WUA 数据库：

Stop-Service -Name wuauserv, BITS, cryptSvc -Force
Rename-Item C:\Windows\SoftwareDistribution C:\Windows\SoftwareDistribution.old
Rename-Item C:\Windows\System32\catroot2 C:\Windows\System32\catroot2.old

$svc = New-Object -ComObject Microsoft.Update.ServiceManager
$svc.Services | Where-Object { $_.IsScanPackageService } |
  ForEach-Object { $svc.RemoveService($_.ServiceID) }

Start-Service -Name wuauserv, BITS, cryptSvc

这不是安装补丁的必要步骤，只是恢复 WUA 扫描能力。

总结

如果目标 KB 在 CBS.log 中完全没有痕迹，而 WindowsUpdate.log 指向 0xC8000402 PopulateDataStore failed，就要把问题定位在 WUA 扫描层。

处理方式是：

1. 确认实际适用的内嵌 MSU。
2. 解压 MSU 得到 CAB。
3. 用 DISM /Add-Package 直接注入。
4. 重启并验证。

这个方法适合 WUA 损坏但 CBS 仍正常的场景。

新 Mac 到手后，我习惯先做一次系统化检测：硬件信息、SSD 健康、接口状态、安全配置、系统稳定性都过一遍。这样后面如果遇到异常，可以知道是机器本身的问题，还是后续使用环境造成的。

本文基于 Mac mini M4 的实际检测流程整理，命令主要适用于 Apple Silicon Mac。

基本信息

查看硬件概况：

system_profiler SPHardwareDataType

重点看这些字段：

• 机型和型号
• 芯片型号
• 统一内存容量
• 序列号
• 系统固件版本

查看 macOS 版本：

sw_vers

查看系统运行时间：

uptime

查看首次设置日期：

ls -la /var/db/.AppleSetupDone

.AppleSetupDone 的修改时间通常可以作为首次开机设置时间的参考。

存储系统检测

内置 SSD 信息

system_profiler SPNVMeDataType

也可以看 diskutil 输出：

diskutil info disk0

重点关注：

• SSD 型号
• 协议
• TRIM 是否支持
• SMART 状态
• APFS 容器和卷状态

SMART 健康数据

需要先安装 smartmontools：

brew install smartmontools

查看内置 SSD 的完整 SMART 数据：

sudo smartctl -a /dev/disk0

常用指标可以这样理解：

| 指标 | 含义 | 正常参考 |
|

起因

凌晨打开 Mac mini 准备工作，习惯性点击 Dock 上的 VS Code 图标，结果图标变成了空白的 macOS 通用应用图标。

打开 Finder 到应用所在目录，也能看到 VS Code 状态异常：

我的 VS Code 没装在系统默认的 /Applications/，而是在外置 APFS 卷的应用目录里。

第一反应：app 去哪了？

先检查应用目录：

ls -la "/Volumes/<external-volume>/applications/" | grep -i "code\|visual"

没有任何输出。也就是说，Visual Studio Code.app 目录已经不存在。

但 Dock 里还保留着旧路径：

defaults read com.apple.dock persistent-apps | grep -A2 "Visual Studio Code"

输出里还能看到类似路径：

file:///Volumes/<external-volume>/applications/Visual%20Studio%20Code.app/

Dock 记住了一个已经不存在的 app，所以 macOS 只能显示通用图标。

真凶：VS Code 自动更新

继续查系统临时目录，发现了 VS Code 的更新器痕迹：

find /private/var/folders -name "*.ShipIt*" -maxdepth 4

能看到多个类似目录：

/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx

进入其中一个目录，可以看到完整的 Visual Studio Code.app 包。也就是说，旧版本已经从目标目录删除，新版本却停在了临时目录里，没有成功回到安装位置。

查看临时目录里 app 的版本：

defaults read "/private/var/folders/.../ShipIt.xxxxxxxx/Visual Studio Code.app/Contents/Info.plist" CFBundleShortVersionString

确认它就是更新后的新版本。

结论很明确：VS Code 自动更新器删除了旧版本，但新版本移动回原位置时失败了。

为什么会失败？

VS Code 使用 Electron 的 Squirrel.Mac 做自动更新，核心辅助进程叫 ShipIt。大致流程是：

1. 检查更新并下载新版本
2. 解压到 /private/var/folders/.../T/
3. 启动 ShipIt 辅助进程
4. ShipIt 等待 VS Code 退出
5. 删除旧的 Visual Studio Code.app
6. 把新 app 移动到原安装位置

问题出在临时目录和安装目录不在同一个卷。

macOS 的临时目录通常在启动卷：

/private/var/folders/<hash>/T/

而我的 VS Code 在外置 APFS 卷：

/Volumes/<external-volume>/applications/Visual Studio Code.app

同卷移动通常只是改目录项，速度很快；跨卷移动则会变成复制再删除。这个过程不是原子的，只要复制中断、目标卷权限异常、磁盘空间不足、卷短暂不可用，就可能出现“旧的删了，新的没到”的状态。

这不是 VS Code 独有的问题。只要更新器把新版本放在启动卷临时目录，再把 app 移到另一个卷，就有类似风险。

为什么重装后又消失？

第一次我从临时目录把 app 移回去：

mv "/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx/Visual Studio Code.app" \
   "/Volumes/<external-volume>/applications/"

然后在 VS Code 设置里禁用自动更新：

{
  "update.mode": "none"
}

本以为问题结束了，结果用 DMG 重装后，VS Code 又被删了一次。

原因是 ShipIt 是独立后台进程。旧版 VS Code 之前已经触发过更新，ShipIt 可能还在后台排队等待执行。update.mode: "none" 只在 VS Code 主进程读取配置时生效，挡不住已经启动的 ShipIt。

最终修复

1. 杀掉 ShipIt 进程

pkill -f "ShipIt"

2. 从最新临时目录恢复 app

mv "/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx/Visual Studio Code.app" \
   "/Volumes/<external-volume>/applications/"

3. 禁用自动更新器执行权限

关键是让 ShipIt 二进制无法继续运行：

chmod -x "/Volumes/<external-volume>/applications/Visual Studio Code.app/Contents/Frameworks/Squirrel.framework/Versions/A/Resources/ShipIt"

确认执行权限已经去掉：

ls -la "/Volumes/<external-volume>/applications/Visual Studio Code.app/Contents/Frameworks/Squirrel.framework/Versions/A/Resources/ShipIt"

如果权限里没有 x，说明它已经不能直接执行。

4. 清理临时更新目录

rm -rf /private/var/folders/.../T/com.microsoft.VSCode.ShipIt.*

这一步要小心路径，确认只删除 VS Code 的 ShipIt 临时目录。

修复效果

• VS Code 可以正常启动。
• Dock 图标恢复正常。
• 退出后可以重新打开。
• 自动更新不会再启动 ShipIt。
• 以后需要手动下载 DMG 或用包管理器更新。

经验教训

update.mode: "none" 不够

它只能阻止 VS Code 主进程后续触发更新。对已经运行的 ShipIt 后台进程无效。

App 装在非系统卷会增加更新风险

如果必须把 app 放在外置卷，建议禁用自动更新，改成手动更新。否则每次自动更新都可能触发跨卷复制。

临时目录经常能救命

更新失败时，新版本 app 往往还完整地躺在：

/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx/

不要急着重新下载，先找临时目录。

ShipIt 是独立进程

关掉 VS Code 不代表更新器已经停止。排查这类问题时，要单独检查和清理 ShipIt。

技术备忘

| 项目 | 内容 |
|

准备工作

Windows系统需要开启WSL

如果之前有装过WSL，默认是Ubuntu，可以使用以下命令进行卸载

wsl --unregister kali-linux

操作步骤

1. 安装Kali，并根据提示创建用户密码，进入系统

wsl --install -d kali-linux

2. 打包当前的Kali系统，暂存至中间位置

wsl --export kali-linux D:\kali-backup.tar

3. 删除当前Kali系统

wsl --unregister kali-linux

4. 使用第二部打的包在E盘中启动新的Kali系统

wsl --import kali-linux E:\WSL\Kali D:\kali-backup.tar

5. 登录Kali系统

wsl -d kali-linux

会默认以root身份登录

6. 创建文件告诉WSL默认用checo用户登录

echo -e "[user]\ndefault=checo" > /etc/wsl.conf

7. 退出并重启WSL

wsl --terminate kali-linux

wsl -d kali-linux

进来后的提示符变成了 $，且用户名是 checo

总结

之后可以出一期教程，研究如何使用Kali

操作步骤

在一台 Windows Server 2008 EC2 实例上，CloudWatch Agent 服务状态正常，但监控指标一直无法上报到 CloudWatch。日志里反复出现 x509: certificate signed by unknown authority，最后定位到旧系统根证书和 TLS 支持不足。

现象

CloudWatch Agent 日志中持续出现类似错误：

WriteToCloudWatch failure, err: RequestError: send request failed
caused by: Post https://monitoring.<region>.amazonaws.com.cn/:
x509: certificate signed by unknown authority

同时需要注意两个容易误判的点：

• ping monitoring.<region>.amazonaws.com.cn 不通不一定代表服务不可达，Interface Endpoint 通常不响应 ICMP。
• 浏览器打开 CloudWatch API endpoint 返回 404 Not Found 也是正常现象，它不是普通网页服务。

根因

Windows Server 2008 的根证书库太旧，可能缺少验证 AWS 服务端证书所需的根证书，例如 Amazon Root CA 1。纯内网实例如果无法访问公网，也不能自动拉取新的受信任根证书。

此外，旧版 Windows Server 2008 还可能缺少支持现代 TLS 链路的补丁。最终表现就是 CloudWatch Agent 建立 HTTPS 连接时无法完成证书链验证。

处理步骤

1. 安装 SHA-2 / TLS 相关补丁

先安装 Windows Server 2008 所需的安全补丁，例如 KB4474419。补丁安装后必须重启系统。

wusa.exe C:\Patches\windows6.1-kb4474419-v3-x64.msu /quiet /norestart
shutdown /r /t 0

2. 导入 Amazon Root CA 1

下载 Amazon Root CA 1 证书：

https://www.amazontrust.com/repository/AmazonRootCA1.cer

在内网环境中，可以先从可访问公网的机器下载，再通过安全方式拷贝到实例。

导入到受信任根证书存储：

certutil -addstore -f Root C:\Patches\AmazonRootCA1.cer

也可以通过 certmgr.msc 图形界面导入到“受信任的根证书颁发机构”。

3. 重启 CloudWatch Agent

net stop "Amazon CloudWatch Agent"
net start "Amazon CloudWatch Agent"

验证

检查 Agent 日志，确认不再出现 x509: certificate signed by unknown authority。

也可以测试 TCP 443 连通性：

(New-Object System.Net.Sockets.TcpClient).Connect("monitoring.<region>.amazonaws.com.cn", 443)

如果命令无报错，说明 TCP 层连通。最终以 CloudWatch 控制台中指标正常上报为准。

总结

旧版 Windows Server 2008 在纯内网环境里运行 CloudWatch Agent 时，常见问题不是 VPC Endpoint，而是系统根证书和 TLS 能力太旧。处理顺序建议是：

1. 确认 CloudWatch endpoint TCP 443 可达。
2. 安装必要系统补丁。
3. 手动导入 Amazon Root CA 1。
4. 重启 CloudWatch Agent 并观察日志。

这类旧系统应尽量纳入迁移计划，长期运行会不断遇到证书、TLS、补丁和软件兼容问题。

测评相关

1. 近日DeepSeek官网过于火爆，时常不回复
   

2. 本地部署有更高的安全性

3. 本地部署可以绕过一些官方的限制

测试环境

OS: Windows 10 Pro 22H2
CPU: AMD Ryzen 5 5600H (6C12T, Base 3.3GHz / Boost 4.2GHz)
GPU: NVIDIA GeForce RTX 3050 Ti Laptop GPU (4GB GDDR6 VRAM)
RAM: SAMSUNG 16GB DDR4-3200
IDE: LM Studio v0.3.9

部署方法

0. 推荐使用国外网络环境并开启代理工具的TUN模式

1. 下载安装LM Studio客户端
   点击跳转

2. 修改模型下载目录（推荐）
   防止模型大量占用C盘空间
   

3. 根据电脑配置下载对应模型
   带Distill字样的是蒸馏模型
   这里推荐DeepSeek-R1-Distill-Llama-8B-Abliterated-GGUF，4g显存能流畅运行，该模型还解除了DeepSeek自带的一些限制，让本地应用更加自由
   

4. 加载模型
   下载完成之后点击顶部加载刚刚下载好的模型
   建议拉高GPU卸载，打开快速注意力以提高性能
   

5. 进行使用即可
   

高级用法

• 信息安全专业毕业生
• 地理爱好者
• 摄影爱好者
• 房东的猫粉丝

写博客对我来说不是为了把每件事包装得很完整，而是把“当时怎么判断、踩了什么坑、最后怎么解决”留下来。以后再次遇到类似问题，能少走一些弯路；别人搜到时，也能快速判断这条路是否适合自己。

AI

AI 分类主要记录大模型和相关工具的使用体验。

目前会写这些方向：

• 本地大模型部署，比如 LM Studio、Ollama。
• DeepSeek、Cherry Studio、硅基流动这类工具链。
• API 调用、模型接入和一些低成本使用方式。
• AI 工具在日常工作里的实际用法。

这部分文章会偏实践，不会只堆概念。能本地跑起来、能接入客户端、能解决实际问题，才值得记录。

AWS

AWS 现在是博客里内容最多的一类。这里主要放云服务排障、EC2 运维、Windows/Linux 系统问题、S3、ALB、IAM、FSx、SSM、CloudWatch 等案例。

这类文章通常会按这个结构写：

1. 问题现象
2. 关键日志
3. 排查路径
4. 根因判断
5. 解决方案
6. 后续建议

很多 AWS 问题看起来是云平台故障，但最后根因可能在操作系统、证书链、KMS 权限、Windows Update、AD 端口、Kerberos 票据或第三方安全软件。写下来是为了提醒自己：排障要分层，不要一开始就把问题归因到某个组件。

运维

运维分类放的是更通用的服务器、容器和服务迁移记录。

比如：

• 1Panel 服务器维护
• Docker 网络和 iptables/nftables 问题
• new-api 从 SQLite 迁移到 MySQL
• 生产服务蓝绿切换
• 反向代理和数据库连接问题

这类内容的重点是可复现和可回滚。生产环境里的操作不能只追求“能跑”，还要考虑备份、验证、切流量和失败回退。

VPS

VPS 分类会记录服务器、网络、域名和常用脚本。

后面计划补充：

• Linux 常用脚本
• VPS 测评与网络测试
• 域名、DNS、证书相关配置
• 哪吒探针、三网 IP、代理和网络连通性

这部分会比较杂，但都围绕个人服务器和网络资产管理。

macOS

macOS 分类主要记录我自己的 Mac 使用、故障排查和硬件检测。

比如：

• Mac mini M4 到手后的硬件检测
• VS Code 在外置 APFS 卷上自动更新失败
• 外接硬盘、应用迁移、系统日志排查

这类文章偏个人经验，但很多坑具有共性。尤其是 macOS 上跨卷、权限、临时目录、应用自动更新这些问题，平时不明显，一旦出事就很难第一时间定位。

Windows 与安全

Windows 分类目前主要放 WSL、Kali 和 Windows 环境相关内容。

以后会继续补：

• WSL 迁移和折腾
• Kali 工具环境
• Windows Server 运维经验
• 安全测试环境搭建

这部分和 AWS 里的 Windows 排障不同：AWS 分类更关注云上案例，Windows 分类更偏本地环境和个人使用。

摄影

摄影是另一个长期保留的栏目。

这里不会写太多器材参数，更多是照片本身和拍摄场景，比如皖南川藏线、鸟、足球比赛。技术博客容易越写越硬，摄影能让这个站不只是一个问题清单，也保留一点生活感。

写作原则

后续文章我会尽量遵循几个原则：

• 不放敏感信息，账号、实例 ID、内网 IP、域名、密钥都要泛化。
• 少写空泛结论，多写判断依据。
• 命令能直接复制，但要标清风险。
• 能解释根因就不只写步骤。
• 生产操作必须提醒备份和回滚。
• 未完成的草稿不置顶，不把占位内容当正式文章。

后续计划

短期先把已有笔记整理干净，尤其是 AWS、运维和 VPS 相关内容。中期会把博客的视觉和导航再整理一下，让分类更清楚，文章列表更适合浏览。

这个博客现在还不算丰富，但已经开始有自己的方向：技术问题不只记录“怎么做”，更记录“为什么这么做”。能长期积累下去，就会越来越有价值。

这里是内容。

注册硅基流动账号

点击注册

获取API key

这个项目是在 Apple M4 Mac mini 16GB 上，用 MLX 从随机初始化开始训练一个 TinyStories 风格的小型 GPT 模型。它不是调用 API，也不是微调现成模型，而是把数据准备、tokenizer、模型结构、训练循环、checkpoint 和推理生成完整走了一遍。

项目地址：sergioperezcheco/llm-from-scratch

项目结果

最终训练的是一个 44M 参数量的 GPT 模型：

| 项目 | 结果 |
|