Add install and quick start scripts

[chenyukang]

Also trivial fix on config/mainnet/config.yml.

[quake]

This node is provided by community members, they may be unstable, incomplete or not work at all, I don't think use it as a default value for mainnet is a good idea.

[chenyukang]

then if a user want to run a fnn node on mainnet, what's the best option for they to connect a ckb node? run a ckb node is also a ops heavy task...

[sunchengzhu]

中文版本见下方 中文。

Note: the Windows fnn.exe startup crash with 0xC0000005 is tracked separately in #1344, because it is not introduced by this PR. It is therefore not included in the issue list below.

I tested the installer and quick-start flow in PR #1262. Overall, the main installation flow works: on macOS and Ubuntu, the node can start successfully, reach Started listening tentacle, and run watchtower PeriodicCheck started / PeriodicCheck finished. However, I found the following issues that are worth evaluating or fixing before the v0.9 release.

Issues Found

[Medium] Windows ckb\key ACL is not tightened successfully

install.ps1 appears to intend to tighten the permissions of ckb\key after exporting it, similar to chmod 600 on Unix/macOS. However, on Windows PowerShell 5.1, this permission tightening did not succeed.

Observed installer output:

Saved the private key, but could not tighten file permissions automatically.

Observed ACL after installation:

AreAccessRulesProtected=False
NT AUTHORITY\SYSTEM: FullControl, inherited
BUILTIN\Administrators: FullControl, inherited
<current user>: FullControl, inherited

This means ckb\key still inherits permissions from the parent directory, instead of becoming a protected ACL that is accessible only to the expected user. Since this file contains node private key material, I think this should be treated as a security-related issue.

Suggested fixes:

• Print the actual exception when Set-KeyFilePermissions fails, so the root cause is easier to diagnose.
• Verify after Set-Acl that AreAccessRulesProtected=True.
• Clarify the intended final ACL rules. If only the current user should have access, inheritance should be disabled and unnecessary inherited permissions should be removed. If SYSTEM / Administrators access is intentionally kept, that should be documented in code or docs.

[Medium] macOS arm64 installs the x86_64 Darwin FNN package

On Apple Silicon macOS, the installer selects the x86_64 Darwin portable package:

fnn_v0.8.0-x86_64-darwin-portable.tar.gz

From the script logic, the Darwin branch currently uses only the x86_64 package name and does not distinguish Apple Silicon from Intel macOS. This may work on machines with Rosetta or other x86_64 compatibility support, but the installer should not assume that every Apple Silicon environment can run the x86_64 package.

Suggested fixes:

• In the Darwin branch, distinguish arm64 and x86_64 using uname -m.
• If a macOS arm64 artifact is available in the release, select the arm64 package on Apple Silicon.

[Medium] Docs do not clearly explain how to restart the node after installation

The installer supports starting the node immediately after installation. However, after the user stops it with Ctrl-C, the README / install docs do not clearly explain how to start the same installed node again.

This was confusing during testing because the actual restart command depends on the generated install directory and startup script.

Suggested doc addition:

Unix/macOS:

cd <install-dir>
./start-node.sh

Windows PowerShell:

cd <install-dir>
.\start-node.ps1

Windows CMD:

start-node.bat

It would also be helpful to mention:

• Node data is stored under the install directory.
• Restarting requires the same FIBER_SECRET_KEY_PASSWORD used when exporting/installing the key.
• If the password is wrong, startup may fail with an error such as Secret key file error: decryption failed: aead::Error.

[Low] Existing ckb-cli / ckb-cli.exe inside the install directory may not be reusable as intended

The installer appears to support discovering an existing ckb-cli from the install directory:

• Unix/macOS: install.sh checks $install_dir/ckb-cli.
• Windows: install.ps1 checks $InstallDir\ckb-cli.exe.

Backing up a non-empty install directory is reasonable because it avoids overwriting existing configs, private keys, data directories, or old install files. The issue is that the installer also has discovery logic for reusing ckb-cli from the install directory, but prerequisites are checked after the backup step. As a result, this discovery branch can become unreachable in some scenarios.

Reproduction:

1. Put ckb-cli / ckb-cli.exe in the target install directory.
2. Run the installer with that directory.
3. The installer sees the directory is non-empty and backs it up to protect existing contents.
4. The later prerequisites check can no longer see the original ckb-cli / ckb-cli.exe in the install directory.
5. The flow enters the "ckb-cli not found" branch.

This is not saying the backup behavior itself is wrong. The issue is the inconsistency between install-dir ckb-cli discovery and the backup order. If the installer intends to support reusing ckb-cli from the install directory, it needs to handle that file before backup; otherwise, the discovery branch should probably be removed.

Suggested fixes:

• Detect and preserve an existing install-dir ckb-cli / ckb-cli.exe before backup, or
• Preserve that file specially during backup, or
• Remove the install-dir ckb-cli discovery branch if reusing it from there is not intended.

[Low] Restart-InstallerFromRemoteFileIfNeeded is defined but not called

install.ps1 defines Restart-InstallerFromRemoteFileIfNeeded, but I could not find any actual call path for it during testing or code reading.

The remote execution path via irm <install.ps1-url> | iex works, so this is not blocking the main flow. Still, the helper looks like either leftover code or a missed integration point.

Suggested fixes:

• Remove the function if it is no longer needed.
• If it is intended for a specific remote execution scenario, wire it into the actual call path and add coverage for that behavior.

[Low] Unix installer prints literal ANSI reset text in some sections

Some Unix/macOS installer output sections print literal ANSI escape text, for example:

==========================================
    IMPORTANT: Save Your Password
==========================================\033[0m

This appears to be caused by formatted output using echo in places where escape sequences are not interpreted.

This does not affect installation correctness, but it makes the installer output look broken.

Suggested fixes:

• Use printf for colored/formatted output, or
• Use an appropriate echo mode consistently where escape sequences are expected.

---

中文

说明：Windows 上 fnn.exe 启动崩溃 0xC0000005 的问题已经单独用 #1344 跟踪，因为它不是这个 PR 引入的问题，所以没有放在下面的问题列表中。

对 PR #1262 的安装脚本和 quick-start 流程做了一轮测试。整体来看，主安装流程可以跑通，macOS 和 Ubuntu 上实测节点都可以启动到 Started listening tentacle，并观察到 watchtower PeriodicCheck started / PeriodicCheck finished 状态。但测试中发现以下几个问题，建议在 v0.9 正式发布前评估或修复。

发现的问题

[Medium] Windows 上私钥文件 ckb\key 的 ACL 没有成功收紧

install.ps1 看起来希望在导出 ckb\key 后收紧文件权限，效果类似 Unix/macOS 上的 chmod 600。但在 Windows PowerShell 5.1 测试中，权限收紧没有成功。

安装输出中出现：

Saved the private key, but could not tighten file permissions automatically.

安装后检查 ACL，结果类似：

AreAccessRulesProtected=False
NT AUTHORITY\SYSTEM: FullControl, inherited
BUILTIN\Administrators: FullControl, inherited
<current user>: FullControl, inherited

这表示 ckb\key 仍然继承父目录权限，并没有变成“仅当前用户可访问”的受保护 ACL。考虑到该文件包含节点私钥材料，这个问题建议作为安全相关问题处理。

建议修复方向：

• Set-KeyFilePermissions 失败时输出具体异常，便于定位原因。
• Set-Acl 后校验 AreAccessRulesProtected=True。
• 明确最终期望的 ACL 规则：如果只允许当前用户访问，应禁用继承并移除不必要的继承权限；如果保留 SYSTEM / Administrators 权限是有意行为，需要在代码或文档中说明。

[Medium] macOS arm64 会安装 x86_64 Darwin FNN 包

在 Apple Silicon macOS 上测试时，安装脚本选择的是 x86_64 Darwin portable 包：

fnn_v0.8.0-x86_64-darwin-portable.tar.gz

从脚本逻辑看，Darwin 分支当前只使用了 x86_64 包名，没有根据 Apple Silicon / Intel macOS 区分不同架构。当前行为在装有 Rosetta 或可以兼容运行 x86_64 binary 的机器上可能可以工作，但不应该默认假设所有 Apple Silicon 环境都能运行 x86_64 包。

建议修复方向：

• Darwin 分支需要根据 uname -m 区分 arm64 和 x86_64。
• 如果 release 有 macOS arm64 artifact，应优先选择 arm64 包。

[Medium] 文档没有明确说明 install 后如何重启节点

安装脚本支持安装完成后立即启动节点，但用户通过 Ctrl-C 停止后，README / install 文档里没有清楚说明如何再次启动同一个已安装节点。

测试过程中这个点比较容易造成困惑，因为实际重启命令依赖 installer 生成的安装目录和 startup script。

建议在文档中补充类似内容：

Unix/macOS：

cd <install-dir>
./start-node.sh

Windows PowerShell：

cd <install-dir>
.\start-node.ps1

Windows CMD：

start-node.bat

同时建议说明：

• 节点数据存储在安装目录下。
• 重启时需要使用安装/导出私钥时对应的 FIBER_SECRET_KEY_PASSWORD。
• 如果密码不正确，会出现类似 Secret key file error: decryption failed: aead::Error 的启动失败。

[Low] 安装目录内已有 ckb-cli / ckb-cli.exe 时可能无法按预期复用

安装脚本中看起来支持从安装目录发现已有的 ckb-cli：

• Unix/macOS: install.sh 会检查 $install_dir/ckb-cli。
• Windows: install.ps1 会检查 $InstallDir\ckb-cli.exe。

备份非空安装目录本身是合理的，可以避免覆盖用户已有的配置、私钥、数据目录或旧安装文件。问题在于：脚本同时又提供了“从安装目录复用 ckb-cli”的 discovery 逻辑，而 prerequisites 检查发生在 backup 之后，导致这个 discovery 分支在某些场景下不可达。

复现方式：

1. 预先在目标安装目录放入 ckb-cli / ckb-cli.exe。
2. 使用该目录运行 installer。
3. installer 为了保护已有内容，发现目录非空后先将整个目录 backup。
4. 后续 prerequisites 检查已经看不到原来安装目录里的 ckb-cli / ckb-cli.exe。
5. 流程进入 “ckb-cli not found” 分支。

这会导致 install-dir ckb-cli discovery 逻辑和安装目录 backup 逻辑不一致。这里不是说 backup 行为本身有问题，而是如果 installer 期望支持复用安装目录里的 ckb-cli，就需要在 backup 前处理这个文件；否则应该移除这段实际上难以命中的 discovery 逻辑。

建议修复方向：

• 在 backup 之前检测并保留安装目录内已有的 ckb-cli / ckb-cli.exe，或
• backup 时特殊保留该文件，或
• 如果不打算支持从 install dir 复用 ckb-cli，移除这段不可达/不一致的 discovery 逻辑。

[Low] Restart-InstallerFromRemoteFileIfNeeded 定义了但没有调用

install.ps1 中定义了 Restart-InstallerFromRemoteFileIfNeeded，但测试和代码阅读中没有看到实际调用路径。

irm <install.ps1-url> | iex 的远程执行路径本身可以跑通，所以这不是当前主流程阻塞问题。但这个 helper 看起来像是遗留代码，或者是原本计划接入但遗漏的逻辑。

建议修复方向：

• 如果该函数已经不需要，建议删除，避免误导后续维护者。
• 如果它是为了某个远程执行场景准备的，建议接入实际调用路径，并补充对应测试覆盖。

[Low] Unix installer 部分输出会打印字面量 ANSI reset 文本

Unix/macOS 安装输出中部分 section 会打印出字面量转义文本，例如：

==========================================
    IMPORTANT: Save Your Password
==========================================\033[0m

这应该是格式化输出时使用了不解释转义字符的 echo 导致的。

该问题不影响安装功能，但会让 installer 输出看起来不够正常。

建议修复方向：

• 使用 printf 输出带颜色/格式的内容，或
• 对需要解释转义字符的地方统一使用合适的 echo 方式。

[sunchengzhu]

I re-tested the latest changes and confirmed that the issues reported above are fixed by 401131b.

One remaining Windows startup crash is tracked separately in #1344. Since that issue was not introduced by this PR, I don’t think it should block this PR.