企业官网建设流程全解析

Omarchy Server 方案解读：面向无头服务器的第二 Edition 与 BBS 风格终端门户架构设计

【免费下载链接】omarchyBeautiful, Modern & Opinionated Linux项目地址: https://gitcode.com/GitHub_Trending/om/omarchy

本方案文档（plans/server.md，Revision 1）回答了 Omarchy 生态中一个长期悬而未决的问题：当桌面发行版的“品味”止步于显示器之前时，如何让同一套理念延续到用户的第二台机器——家庭实验室、VPS、或角落里的 Docker 服务器上。文章将完整拆解“Omarchy Server”这一设计蓝图：它如何在不 fork、不加 GUI、不引入 Web 面板的前提下，复用本仓库的 CLI、TUI 工具箱与更新管线，并额外构建一个老式 BBS 风格的登录门户。读完你可以掌握该方案的 Edition 机制设计、首次启动安全序列、登录/菜单两层前门的交互约束、主题桥接思路，以及它与 backup、dots 两个配套计划的协作边界。

阅读前提：与plans/目录下其它文件一样，这是一份正在进行中的设计蓝图，而非已发布功能。文中标注的机制、命令与目录（如omarchy-edition、install/omarchy-server.packages）是该计划的目标产物；文章中凡是“已存在于仓库”的描述均有可点击的源码路径佐证，凡是“计划新增”的内容均以原文口径陈述。

问题的起点：Omarchy 的味道在桌面边界断掉了

方案先指出一个结构性缺口。Omarchy 的核心卖点——有主见的默认配置（opinionated defaults）、精选的 TUI 工具箱、一键更新+快照、处处可换主题——全部止步于桌面。而大多数 Omarchy 用户都拥有“第二台机器”：家庭实验室、VPS、角落里的 Docker 服务器。现实中没有顺畅的答案：

• 想装“服务器版 Omarchy”的用户，要么把整套 Hyprland/Quickshell GUI 栈拖到一台无头机器上（无意义地浪费资源），要么手工剥离组件——而代价是丢掉那条精心维护的更新管线（快照、迁移、主题刷新一体）。
• 横向对比同样尴尬：Ubuntu 有 Server 版，Arch 则有 wiki 与“一下午的折腾”。

方案由此立下第一句问题陈述：Omarchy 的口味不应因没有显示器而终结。

更重要的是，方案认为服务器登录体验存在审美真空——“Last login: ...加一个闪烁光标”是每台服务器发行版千篇一律的待客方式。一台你拨号进入（dial into）的机器值得一个有性格的前门。这直接引出方案中最具辨识度的部分：把登录过程做成老式 BBS——ANSI 字标（wordmark）、节点状态、今日访客数、以及一个能跳进 Omarchy 既有 TUI 的热键主页菜单。方案特别强调这不是“贴上去的装饰”：对 Omarchy 而言终端优先是产品的全部，因此终端体验本身就是身份认同（identity），终端美学与产品本体是一体的。

整体形态：同一个仓库的第二 Edition，而非 fork 或模式开关

方案用一句话框定边界：“A second edition built from this same repo”——不是 fork，不是一个运行时切换的模式开关，而是在本仓库内并行存在的第二种“Edition”。它的核心约束是：

• 没有 GUI：无 Hyprland、无 Quickshell、无 GUI 包。开机直接进入控制台 getty，SSH 是主要访问途径，并且从首次启动起即开启（仅密钥登录）。
• 精选的服务器包集：保留现有 CLI（omarchy ...命令族）、TUI 工具箱（btop、lazygit、lazydocker、lazyjournal）、Docker + compose、ufw、snapper 快照，以及与桌面完全相同的更新/迁移管线。备份计划（plans/backup.md）减去 shell 面板后整体适用；dots 计划（plans/dots.md）在这里找到了它最好的用例——在桌面与服务器之间同步你的配置。
• BBS 层：主题化的登录前/etc/issue、登录 splash、以及一个omarchy-server-menu主页菜单，行为像 BBS 的“门（door）系统”——选中一个入口，工具占满全屏；退出后回到菜单。[Q]永远是真正的 shell。

否决过的路线（可作为架构决策记录阅读）

这一节是本仓库“写计划先反驳自己”风格的典型体现，值得完整保留，因为它揭示了约束来源：

• 独立 fork 仓库：永久漂移。每修一个bin/下的 bug 都要双份维护。而且 dots 计划中“不包装第三方工具”的理由同样适用于“包装自己”。
• Web 管理面板（Cockpit 之流）：等于在端口上多开一个攻击面、多一套要换肤的 UI 工具集，且不符合 Omarchy 的灵魂。终端才是产品，SSH 是已经加固好的传输层——这个立场直接决定了整个方案不引入 HTTP 服务。
• 在已装桌面系统上做“服务器模式”开关：原地卸载 GUI 栈是一场双向的迁移雷区。Edition 必须在安装时选定；想改主意就重装（dots + backup 让重装代价足够低）。
• 用编译型 TUI 框架（bubbletea、ratatui）写菜单：v1 的需求不值得引入一套新工具链。仓库的惯用语是bash + gum——gum 已经可主题化、已经无处不在；只有当菜单功能超出其承载能力时才重新评估。
• archinstall 的 server profile：Omarchy 有自己的安装器与离线镜像，Edition 本质上是这套管线的“包集 + provisioning 变体”，而不是换一个安装器。

界面形态：三块屏构成整个“门面”

方案配套了三张模拟图（mockup），均声明由仓库自带的logo.txt字标（见 logo.txt）与 tokyo-night 的 colors.toml 生成——每个主题都会重绘全部三个画面，模拟图只是 tokyo-night 的演示。三张图都在仓库plans/images/下。

登录 splash：登录前与控制台上都能看到的第一印象

splash 在进入菜单之前呈现，既出现在控制台，也出现在 SSH 登录时。模拟图展示了它的信息密度：ANSI 字标之下依次是节点身份行（hostname / node / IP / tty）、系统体征（uptime、load、内存、磁盘、内核版本）、服务与容器计数、可用更新数与备份时间，以及“last call / callers today”（来自 wtmp 的呼叫记录），最后提示[ENTER]进主菜单、其它键落到 shell。

主页菜单：热键在左、状态在右的“门系统”

主菜单把“启动器 + 状态面板”合为一体：左边一列热键入口，右边是实时体征与 MOTD（欢迎语“Welcome back, sysop”与待处理事项）。按键约定清晰——[↑↓]选择、[ENTER]打开、热键跳转、[Q]进入 shell。

一扇“门”的真实样貌：更新走标准管线

[U]入口演示了“门”的核心思想：它不重新实现任何工具，而是把既有的omarchy-update管线（先打快照、再同步、再升级）穿上一层 BBS 外衣——快照先行（Snapshot taken · pre-update）、清晰的包变更清单、内核在批次内时给出重启提示。你退出它时，会原样回到主菜单。

架构与机制设计

Edition 机制：让“减法”而不是“平行清单”成为包集来源

方案的 Edition 机制包含三层，构成一套可被脚本与迁移门控的干净接口：

1. 写入 Edition 标识：安装器写入 Edition（如/etc/omarchy-edition）。
2. 新增查询助手：一个omarchy-editionhelper 读取该文件，按hw-命令族（硬件探测类静默谓词）的传统提供退出码接口的谓词——如omarchy-edition-server，true/false由退出码表达，供脚本与迁移直接if判断。
3. 服务器包集是“减法”而非平行清单：install/omarchy-server.packages从桌面基础包集（install/omarchy-base.packages，仓库内现存的完整清单）中手工精选出子集——保留 CLI、TUIs、docker、网络、安全与主题管线；剔除 compositor、shell、GUI 应用、音频/蓝牙/打印栈，以及超出控制台所需的字体。这一设计刻意避免“维护两份会漂移的平行包清单”。

门控规则随之明确：迁移（migrations）与刷新命令凡是触碰 GUI 表面的，按 Edition 门控跳过；其余一切（pacman、snapper、CLI、主题的终端侧）在两个 Edition 上行为完全一致。最终收敛为一句话：一条更新管线，两个 Edition。

作为对照，桌面 Edition 的既有命令在仓库中确实以“一个动词一个可执行文件 + 元数据头”的形式组织：例如 bin/omarchy-setup-security-sshd 第 4～5 行即声明了# omarchy:args=[--key=<public-key>] [--gh-keys <github-username>]与--gh-keys dhh之类的示例——这正是方案设想中“往组注册表加一个server组、路由自动从文件名派生动词”的既有机制（GROUP_DESCRIPTIONS定义于 bin/omarchy 第 27 行起，仓库的 AGENTS.md 也要求新增命令前缀时同步维护该表）。

首次启动：先变安全，再见客

复用桌面版既有的 provisioning 流程，换成服务器口味：

• 设定 hostname、用户，随后直接进入omarchy-setup-security-sshd --gh-keys <user>——方案明确指出这条无值守路径“已经存在”，即上面核实过的 bin/omarchy-setup-security-sshd（同时支持--key直接粘贴公钥与--gh-keys从 GitHub 拉取）。
• 启用 ufw 并对 SSH 做 rate-limit，关闭密码认证。
• 可选 Tailscale、可选静态 IP。

方案的保证很硬：在这台机器的第一句登录问候渲染出来之前，它已经是可达且安全的（reachable and safe）。

BBS 前门：pre-login、greeting 与 menu 三层

Pre-login：连 getty 都要报家门

一个主题化的/etc/issue——紧凑的 logo、hostname、IP——让“谁在应答”在登录前就可见。

Greeting：严格的会话边界 + 绝不拖慢登录

交互式登录 shell（仅限 tty 或带 pty 的 ssh）会运行 splash，展示：字标、edition/host/node 行、系统体征、服务/容器/更新/备份计数、last call 与 callers today（取自 wtmp），随后[ENTER]进菜单、任意其它键直接进 shell。

方案为 greeting 划了四条硬边界，这是全篇最强调安全与健壮性的部分：

• 只服务交互式登录：scp/sftp/rsync/exec会话、非交互 shell、tmux attach 内部，一律不触发 splash——因为一个把 splash 打给脚本的登录欢迎语会立刻毁掉所有自动化管线。
• 可配置落点：omarchy server greet <splash|menu|off>决定登录后是落在 splash、直接跳进菜单、还是完全跳过。按用户存储、即时生效。
• 硬超时：体征采集带硬性超时，慢机器上的登录不能被欢迎语阻塞——菜单宁可渲染过期的计数，也不让用户等待。

Menu：bash + gum 的“门系统”，只做启动器不做复刻

omarchy-server-menu（bash + gum）的每个入口都路由到已经存在的东西，方案以表格方式完整列出：

方案反复强调一句设计原则：菜单是带状态面板的启动器，而不是对任何工具的重新实现。退出任意“门”即回到菜单，[Q]始终通向真实 shell。

Flavor：有品位的默认开启项 + 绝不弄坏哑终端

默认开启、克制点缀的“BBS 风味”：节点编号（会话数）、今日访客、sysop（站长）框架、以及来自~/.config/omarchy/motd的 MOTD。降级是硬要求：当TERM=linux或终端能力不足时，所有输出自动退化为 ASCII + 16 色——美术效果永远不能弄坏一台 dumb terminal。

Theming：主题桥把colors.toml渲染成 ANSI 调色板

themes/*/colors.toml在三屏所需的一切色彩上已经定义完备（仓库中 themes/tokyo-night/colors.toml 即为实例）。方案增加一块小桥接层，把主题渲染成 splash、menu、issue 文件消费的ANSI/truecolor 转义调色板；服务器上的omarchy-theme-set（对应 bin/omarchy-theme-set，已存在于仓库）应用它已知的终端侧目标（btop、starship、bat）之外，再叠加这套 BBS 调色板。结果是：切换主题会整体重绘整个前门——三张模拟图之所以都是深蓝紫调，仅仅因为那是 tokyo-night。

与 backup、dots 两个配套计划的关系

方案明确了自己不是孤岛，与plans/目录下的姊妹计划有清晰的职责切分（两文档均已在仓库中，可对照阅读）：

• 与 plans/backup.md 的关系：备份引擎、CLI、timer 与状态文件完全相同，被拿掉的是桌面 shell 面板——其职责由 menu 的 Backup 入口和 splash 的状态行接管。backup 计划的 systemd用户级unit 在 lingering（常驻）或已登录的服务器会话中都能正常运行；服务器 Edition 启用 lingering，从而无需交互登录 timer 也会触发——这与桌面版“用户 timer 只在会话存在时运行”的前提（backup 计划原文明确“no lingering required”）形成有意的对照。
• 与 plans/dots.md 的关系：dots 的多机同步设计（omarchy dots push/pull，发布状态而非历史）所设想的“第二台机器”，正是这台服务器。把桌面的配置推上去，在服务器上拉下来，即完整闭环。

演进与落地：分两阶段推进

方案的 Rollout 规划分为阶段内（本仓库）与协调（外部 ISO 管线）两部分：

• Phase 1（本仓库内）：omarchy-edition+ 退出码谓词；install/omarchy-server.packages；迁移/刷新命令中的 Edition 门控；omarchy-server-menu+ greeting +/etc/issue生成；主题桥；以及在GROUP_DESCRIPTIONS中新增server组。
• Phase 2（跨仓库协调）：ISO/安装器工作（安装时提供 Server 选项，或一个独立的精简 ISO——悬而未决）、provisioning 流程、离线镜像子集。
• 文档：为 Omarchy Server 新增 manual 章节（安装、首次启动、菜单、greet 设置、无头约定）；在docs/中沉淀 Edition 门控参考，让未来的迁移作者知道规则。
• 测试：方案把greeting 守卫列为安全关键路径——shell.d 测试要验证非交互 shell、scp/sftp、以及ssh host command永远看不到菜单；另有菜单路由冒烟测试、Edition 谓词测试、通过omarchy commands --check的 CLI 元数据测试。视觉检查遵循仓库 agents/skills/visual-verification.md 的精神，在真实控制台与 ssh 会话、以及适配到 VM TTY 的场景下进行。

开放问题：六个待定设计决策

方案在结尾诚实列出六个开放问题，体现设计尚未盖棺定论的部分：

1. 一个带 Server 安装类型的 ISO vs 独立精简服务器 ISO——桌面 Edition 的离线镜像很大，服务器 ISO 理论上可以做到其零头大小。
2. Docker 之外的默认服务器软件：直接预装 caddy 并让 Install > Service 长出服务器条目，还是把基础包压到极致、一切按需选择？
3. splash / menu / off 的默认值是否应区分控制台与 SSH——控制台设备常是无头 appliance，而 BBS 真正落地的场景是 SSH。
4. TERM=linux下的控制台字形策略：随包附赠带制表符覆盖的 PSF 控制台字体，还是完全依赖 ASCII 降级？
5. 桌面 Edition 是否也获得菜单（作为omarchy bbs）——一个既是彩蛋又兼作演示的入口。
6. 命名：“Omarchy Server”作为描述语；但 greeting 上是否值得一个 BBS 风味品牌（如 “Omarchy BBS — est. 2025”），还是那样会过火？

仓库内的延伸阅读

如果你希望对照设计蓝图与实际代码，以下几个路径值得继续深挖：

• plans/server.md 与姊妹计划 plans/backup.md、plans/dots.md（以及 plans/nix.md、plans/remote.md）——本方案依托的规划语境。
• install/omarchy-base.packages —— 服务器包集做“减法”的源清单；install/ 下还有配套的 config/hardware/login/provisioning 等安装子流程。
• bin/omarchy ——GROUP_DESCRIPTIONS命令组注册表；bin/ 目录下每个omarchy-*文件对应一个 CLI 动词。
• bin/omarchy-setup-security-sshd —— 方案首次启动流程复用的既有 SSH 加固脚本（含--gh-keys/--key无值守参数）。
• migrations/ —— 数值前缀命名的迁移脚本群，是“迁移按 Edition 门控”的对象。
• themes/tokyo-night/colors.toml 与 logo.txt —— 三屏视觉的主题与字标来源。

【免费下载链接】omarchyBeautiful, Modern & Opinionated Linux项目地址: https://gitcode.com/GitHub_Trending/om/omarchy