[!abstract] 决策结论 DD 重装可以换掉客体操作系统，却不能修改 OCI 的 VCN、安全列表、NSG、路由、公网 IP、引导卷或账号状态。它不是“脱离 Oracle 控制台”的必要条件。对当前两台已经干净且完成基础加固的 Ubuntu 24.04 实例，默认应保留现状；真正需要的是一次性确定云侧最小规则，此后用 SSH、UFW 和自动化管理主机。只有明确需要 Debian、能够接受 Agent 与救援能力下降，并准备好重建时才 DD。

OCI DD 重装与免控制台运维的边界

范围

本笔记比较三件容易被混为一谈的事：

1. 用 DD/网络重装把 OCI 平台镜像替换成 Debian；
2. 把日常端口管理从 OCI 控制台迁移到 Linux 主机；
3. 在长期运维中尽量不再登录 Oracle 官网。

它分析选型与失败边界，不提供可直接复制执行的一键 DD 命令。DD 会覆盖引导盘，应该另写带备份、验证和恢复步骤的 howto 后再实施。

Linux.do 方案实际做了什么

Linux.do 一条龙经验帖采用的路径是：

1. 在 OCI 控制台为 VCN、子网、VNIC、IPv6 和路由做一次性配置；
2. 把 OCI Security List 的 IPv4/IPv6 入站规则放宽到所有协议；
3. 通过 SSH 运行 bash <(curl -sL kejilion.sh)；
4. 在脚本中把原系统 DD 为 Debian；
5. 重装完成后改用 root 密码登录，再调整 SSH 端口；
6. 安装 UFW 与 Fail2ban，最后恢复密钥登录并关闭密码登录。

另一篇 Oracle VPS 配置讨论也概括为“DD Debian 官方 cloud 镜像、修改 SSH 端口、再上 Fail2ban”。这属于社区经验，不是 Oracle 官方支持承诺。

[!warning] 它并不是真正的零控制台方案 该教程仍先登录 OCI 控制台，并主动把云防火墙放开。DD 只改变虚拟机内部的磁盘内容，不能绕过或替代云侧网络规则。

四层边界必须同时成立

flowchart LR
    Account["OCI 账号与实例状态"] --> Network["VCN、路由、Security List / NSG"]
    Network --> Guest["Debian / Ubuntu 与 UFW"]
    Guest --> App["SSH、Caddy、Docker 与应用"]

• 账号与实例层：决定实例是否存在、开关机、形状、引导卷、公网 IP 与回收状态；只能通过 OCI 控制面处理。
• 云网络层：决定数据包是否能到达 VNIC；DD 触碰不到这一层。
• 客体系统层：UFW、nftables、SSH、用户和软件包由 SSH 管理；这是日常自动化最适合接管的层。
• 应用层：Caddy、Docker、哪吒和 Sub-Store 还会建立自己的监听与转发规则。

只要云网络层没有允许 80/443，Debian 中执行 ufw allow 80,443/tcp 仍然不会让网站公网可达。反过来，如果云网络放行所有协议，而 UFW 或 Docker 规则意外失效，应用会立刻暴露给公网。

DD 能带来什么，不能带来什么

目标	DD 是否解决	说明
换成 Debian 用户空间与包生态	是	前提是镜像、启动方式和架构都兼容
清除平台镜像预装软件	是	也会同时清除有价值的集成和诊断能力
让以后通过 SSH 管理 UFW	不需要 DD	当前 Ubuntu 同样可以做到
修改 OCI Security List/NSG	否	仍需控制台、OCI API 或 CLI
避免 Oracle 看到网络与实例状态	否	云平台仍控制虚拟化、VNIC、流量计量和账号
降低封号概率	没有可靠证据	移除 Agent 不等于改变服务条款或平台侧计量
保留同一个公网 IP	通常可以	只重写现有引导盘、不删除实例时一般保持 VNIC；仍须把失败当成可能性
获得更好的救援能力	通常相反	错误的 GRUB、网络或 SSH 配置可能让串行控制台也不可用

为什么不建议当前立刻 DD

2026-07-20 的只读检查结果：

实例	当前系统	主机防火墙	Oracle Cloud Agent	当前判断
oracle1	Ubuntu 24.04.4 LTS	UFW 已启用，仅允许 SSH	1.60.0，运行正常	1 GB 机器可考虑极简 Debian，但当前收益不足以抵消重装风险
oracle2	Ubuntu 24.04.4 LTS	UFW 已启用，仅允许 SSH	1.60.0，运行正常	开发机优先保留；Ubuntu 对开发工具、Codex CLI 与 ARM 软件兼容更省心

两台机器没有发现需要靠重装才能清除的应用负担。当前状态已经实现了“一套主机防火墙、只开放 SSH”。与其重新获得同一个状态，不如直接在现有系统上继续配置。

此外，oracle2 的 150 GB 引导卷与 oracle1 的 50 GB 引导卷已经用满 200 GB 免费块存储。DD 失败后的备用卷、并行重建和数据搬迁空间都非常有限，恢复余量比普通 VPS 更差。

DD 会失去或弱化哪些 OCI 能力

Oracle Cloud Agent 文档说明，Agent 插件承担实例监控、Run Command、Bastion、卷管理、漏洞扫描和系统管理等功能。当前平台镜像默认安装 Agent；其他操作系统即使能尝试手动安装，也没有保证可用。

DD 成社区 Debian 镜像后应预期：

• OCI 控制台里的 CPU、内存、网络和磁盘指标可能缺失或不完整；
• Compute Instance Run Command 不能作为 SSH 失败后的备用入口；
• OS Management、漏洞扫描、Bastion 等插件能力可能不可用；
• 自动连接特定块卷与日志采集能力可能需要自己重建；
• Oracle 支持通常难以对第三方脚本写入的系统状态负责。

Oracle 公开支持导入自定义 Linux 镜像，但 BYOI 要求包括正确的引导器、单引导盘、DHCP 网络和兼容磁盘格式。这证明“允许自带镜像”，不等于“Oracle 推荐执行任意一键 DD 脚本”。

串行控制台是 DD 成败的关键

SSH 失败时，可用的最后一条主机级路径通常是实例串行控制台。Oracle 文档要求导入镜像把控制台输出接到第一串口：

• x86/AMD：ttyS0；
• ARM/Ampere A1：ttyAMA0。

详见 Oracle：为导入的 Linux 镜像启用串行控制台。

如果 DD 脚本只验证“重启后 SSH 能连”，却没有验证 GRUB、initramfs 和登录终端的串口配置，那么网络一坏就可能同时失去 SSH 和串行救援。并且串行控制台本身仍需要 OCI 控制面创建连接，因此不能把它算作“永远不登录 Oracle”的方案。

一键脚本的独立风险

bash <(curl -sL ...)把“下载”和“以当前最新内容执行 root 脚本”合成一步：

• 执行内容没有固定到某个版本、提交或哈希；
• 域名、DNS、下载源或脚本更新都会改变实际执行内容；
• 脚本需要接管分区、引导器、网络与 SSH，出错就是整机失联；
• 教程流程会暂时恢复 root 密码登录，并关闭主机防火墙；
• DD 后 SSH 主机密钥变化，本地会出现 host key mismatch，需要人工核对后更新；
• AMD64 与 ARM64 需要不同镜像，不能混用；
• Docker 会直接修改 netfilter 规则，默认发布端口可能绕过普通 UFW 入站策略。

因此即使以后决定使用科技 Lion 脚本，也应先下载到本地、阅读、记录版本与 SHA-256，再上传执行，而不是直接把网络返回内容送给 root shell。

推荐的低控制台依赖路线

路线 A：当前推荐——保留 Ubuntu

1. 保留现有平台镜像与 Oracle Cloud Agent；
2. 云侧只做一次最小配置：SSH、80、443，以及代理确实需要的端口；
3. SSH 只用密钥，UFW 默认拒绝入站；
4. 普通开发端口不开放公网，使用 SSH 端口转发或 Tailscale；
5. Caddy 统一承接公开的 HTTP/HTTPS；
6. Docker 服务只绑定 127.0.x.x 或私网，并用 DOCKER-USER 链补充边界；
7. 后续由 oracle-cloud-server-operator Skill通过 SSH 做审计、安装、部署和验证。

这条路线日常不需要登录 Oracle 官网，同时保留监控和更多救援手段。

路线 B：完全不新增云侧入站端口

如果 OCI 云侧目前只允许 SSH，又不愿再登录：

• 开发访问使用 SSH 端口转发或 Tailscale；
• Web 服务可使用只建立出站连接的隧道；
• 不把这条路线当作任意 TCP/UDP 公网代理的通用方案。

出站隧道能绕过“新增入站端口”的日常需求，但会引入第三方依赖、域名和流量策略，不能等同于自有公网监听。

路线 C：以后明确需要 Debian 时再 DD

适用条件：

• Debian 本身是明确需求，而不是为了“看起来更干净”；
• 所有项目代码已在 GitHub，应用数据已异地备份；
• 能接受 Agent 插件缺失；
• 已确认 AMD64/ARM64 镜像、DHCP、EFI/GRUB 和串口设置；
• 有另一台机器可辅助救援；
• 可以接受最坏情况下删除并重建实例。

建议先拿 oracle1 做候选验证，不先动承担开发与数据职责的 oracle2。验证期内不迁移哪吒、Sub-Store 或正式数据。

如果以后实施，必须保持的安全不变量

[!warning] 以下是执行门槛，不是 DD 命令

• 重装前保存 /etc 中必要配置、项目数据、Compose 文件和数据库导出；
• 记录当前公网/私网地址、磁盘、分区、网卡名、默认路由和 DNS；
• 下载并审查脚本，固定版本与 SHA-256；
• 确认镜像架构：oracle1 为 AMD64，oracle2 为 ARM64；
• 确认 Debian cloud 镜像使用 DHCP 和可兼容的启动方式；
• 确认串口：AMD 用 ttyS0，ARM 用 ttyAMA0；
• 重装后的第一次登录立即恢复 SSH 公钥；
• 在关闭旧会话前验证新的密钥会话；
• 禁用 root 与密码 SSH 登录；
• UFW 默认拒绝入站，只逐项允许真实服务；
• 检查 Docker 的 iptables/nftables 行为；
• 验证重启后 SSH、IPv4/IPv6、DNS、时间同步和防火墙仍正常；
• 把“实例可直接删除重建”作为最终恢复预案。

最终决策规则

只是想以后不登录控制台
    -> 不 DD；一次性最小云规则 + SSH/UFW/隧道

只是嫌 Ubuntu 有预装 Agent 或 snap
    -> 先测资源占用；不为洁癖牺牲监控与救援

明确需要 Debian 的一致环境
    -> 先在 oracle1 做可丢弃验证，再决定是否迁移

希望 Oracle 完全看不到或不再控制实例
    -> DD 做不到；这属于云平台边界

Related notes

• 所属 MOC：甲骨文云服务器 MOC
• 安全加固：安全加固 OCI Linux 服务器
• 云侧收尾：完成实例加固后的 OCI 控制台配置
• 网络层次：OCI VCN、子网、VNIC 与安全层
• 救援阶梯：OCI 服务器生命周期与恢复阶梯
• 自动化：使用 Codex Skill 自动运维 OCI 服务器