6. 首次登录与初始化

返回概览 · 完整版目录 · 下载完整 PDF

本章内容：安装完成只代表服务已经跑起来。本章带读者完成从第一次登录到平台可以交给业务方使用之间的全部动作：修改 root 初始密码并按客户的安全要求设置两步验证、核对平台状态、创建首个租户、离线导入许可证、补配运维通知，最后把第 1 章确认表里的计划值与现场实际值逐项核对。读者是实施工程师；6.4 节许可证导入需要客户方的租户管理员一起完成。

6.1 修改初始密码与设置两步验证

前提：手中有安装完成时打印的访问地址、「本机直接访问」地址和 root 初始密码（32 位随机字符）；已与客户确认平台账号（含 root）是否必须使用两步验证。

新装部署的平台范围默认不强制两步验证：root 修改初始密码后直接进入平台管理控制台。客户要求平台账号必须使用两步验证时，完成第 1–4 步后继续第 5–7 步。

操作步骤

1. 在能访问安装主机的办公终端上，用浏览器打开「访问地址」。打不开时改用「本机直接访问」地址：本机直接访问能打开而访问地址打不开，问题在前置代理、NAT 或负载均衡；两者都打不开，问题在本机，按第 12 章故障排查处理。
2. 账号填 root，密码填初始密码，登录。
3. 页面进入「修改初始密码」。按页面列出的口令规则输入新密码，点「修改并继续」。
4. 进入平台管理控制台。客户不要求两步验证时，本节到此完成。
5. 在个人设置「账号安全」中绑定两步验证，选择一种方式：
   • 验证器应用：用手机上的身份验证器应用扫描页面二维码，输入应用中显示的 6 位验证码完成绑定。使用验证器应用时，页面会给出一组恢复码，把恢复码抄写或打印后离线保存。
   • 通行密钥：按浏览器提示用本机的安全密钥或系统生物识别完成注册。
6. 退出登录，用新密码与两步验证重新登录。
7. 打开「平台账号与登录 › 登录会话」，点「安全策略」，打开「强制两步验证」并保存。之后未绑定两步验证的平台账号在下一次登录时必须先绑定。

你会看到

• 第 3 步提示「当前密码为初始密码或已被重置，请先修改后再进入」。
• 访问地址以 http:// 开头时，第 5 步没有通行密钥选项，只能用验证器应用。
• 第 7 步若本次会话没有经过两步验证，保存失败并提示「请先为自己绑定两步验证，并以两步验证登录后再开启此项」，按第 5–6 步完成后重试。
• root 绑定两步验证后，无论是否开启「强制两步验证」，使用口令登录时仍需完成两步验证；有效的受信任设备除外。使用验证器时输入 6 位验证码，验证器不在手边时可选「使用恢复码」。

注意：

• 修改密码有 10 分钟时限，超时后重新登录、从头再来即可，不会留下半完成的状态。开启「强制两步验证」后，登录流程中的「绑定两步验证」步骤同样有 10 分钟时限。
• 修改密码之后，安装主机上的 sudo zenova root-password show 不再能查看密码，/opt/zenova/.env.runtime/root-password-initial 中的初始密码同时失效。
• 恢复码每个只能使用一次，与验证器应用分开保管。不要截图存放在同一台手机上，也不要通过即时通讯、邮件或工单传递新密码与恢复码。
• root 忘记密码，或验证器与恢复码同时丢失时，在安装主机上执行 sudo zenova root-password set。该命令生成新的随机密码，清除两步验证与恢复码，使现有会话全部失效，并写入审计记录；随后用新密码重做本节。

6.2 核对平台状态

适用场景：完成 6.1 节后、创建租户之前，确认安装结果在控制台里的状态与安装器输出一致。

操作步骤

1. 打开「网关 › 节点」，找到中心网关节点 office-primary。
2. 打开「系统维护 › 部署配置」，查看「最近一次验收」。
3. 在同一页核对部署配置各分组：「访问地址」「对象存储」「运维通知渠道」「入口监听」「数据依赖」。
4. 打开「系统维护 › 系统更新」，核对当前版本与各能力状态。

你会看到

注意：

• 「最近一次验收」页提供「立即验收」按钮，处理完问题后可以在控制台重新触发一次，不必重跑安装命令。
• 还没有租户和模型路由时，中心网关节点数据面的就绪检查返回 503、原因为 no_tenant_routes，这是正常现象，创建租户并配置模型后恢复。
• 控制台的状态与命令行一致。需要留存时，在安装主机上执行 sudo zenova status。

6.3 创建首个租户

适用场景：平台状态核对无误后，为客户创建业务使用的租户及其默认管理员。

前提：已与客户确认租户名称、组织标识、默认管理员人选，以及结算货币。

操作步骤

1. 以 root 登录平台管理控制台，打开「租户管理」，点「创建租户」。
2. 填写四项内容：

3. 点「创建」。
4. 把默认管理员的邮箱和初始密码通过客户认可的安全方式交给租户管理员本人，不要经即时通讯、邮件或工单明文传递。

你会看到

• 提示「<租户名称> 创建成功（管理员: <邮箱>）」，租户出现在列表中，状态为活跃。

注意：

• 结算货币创建后不能修改。 创建前必须与客户确认；选错后无法在页面上更正。结算货币与平台记账货币不同时，页面会要求填写汇总汇率。
• root 只用于平台级设置（网关节点、部署配置、系统更新、租户管理等），不要作为日常业务账号使用。模型供应商、模型、模型分组、成员与 API 密钥等业务配置由租户管理员在租户内完成。
• 租户管理员第一次登录时，按页面要求修改初始密码；单位安全策略开启了「强制两步验证」时，再按页面要求绑定两步验证（验证器应用或通行密钥）。

6.4 导入许可证

适用场景：交付范围包含受许可证控制的能力时。许可证由租户管理员导入，root 在平台管理控制台看不到「授权许可」页签。

前提：6.3 节已创建租户；租户管理员已完成首次登录；客户方已确定把文件送出与取回所用的介质或通道（例如经审批的移动存储介质、内网文件交换系统）。

整个过程分三步：导出授权请求 → 送给供应商换取签名后的 .lic 文件 → 导入。全程不需要安装主机访问外网，也不需要访问数据库。

操作步骤

1. 导出授权请求。租户管理员在办公终端上登录控制台，打开「系统设置 › 全局设置 ›「授权许可」页签」，点「导出授权请求 (.json)」。浏览器把请求文件下载到办公终端。
2. 在办公终端上计算请求文件的摘要并记录，便于对方核对文件在传递中没有被改动：

# 办公终端 · 普通用户 · 只读（Linux / macOS；Windows 可用 certutil -hashfile <文件> SHA256）
sha256sum <授权请求文件>.json

3. 把请求文件送出。按客户的数据外发流程，把请求文件和摘要拷到可以联网的机器上，再通过与供应商约定的渠道发送。请求文件只包含租户与本次部署的绑定信息，不含口令、密钥或业务数据。
4. 换取签名后的许可证。供应商返回一个 .lic 文件，同时请对方给出该文件的 SHA-256 摘要。
5. 把 .lic 文件取回。按客户的数据导入流程，把 .lic 文件拷回能访问控制台的办公终端，计算摘要并与供应商给出的摘要比对：

# 办公终端 · 普通用户 · 只读
sha256sum <许可证文件>.lic

6. 导入。租户管理员回到「系统设置 › 全局设置 ›「授权许可」页签」，点「导入 .lic 文件」，选择该文件。
7. 打开「系统维护 › 系统更新」（或请 root 查看），确认此前显示「许可证未包含此能力」的能力已恢复可用。

你会看到

• 导入成功提示「许可导入成功」，校验通过后立即生效，无需重启任何服务。
• 「授权许可」页签的许可来源由「社区版（未导入许可）」变为「已导入商业许可」，并显示授权对象、许可 ID 与导入时间。
• 导入失败时提示「许可导入失败」，常见原因是文件在传递中被改动，或许可证与本租户、本次部署不匹配；核对摘要后重新取回，或重新导出授权请求后再次申请。

注意：

• 许可证与租户和本次部署绑定。在另一个租户导入、或在另一套部署上导入都不会通过。
• 清空重装（第 11 章）会生成新的部署标识，原许可证随之失效，需要按本节重新导出请求、重新申请。
• 页面上的「移除许可」会让部署回到未导入许可证的状态，不要误点。
• 未被许可证覆盖的能力在「系统更新」页显示「许可证未包含此能力」。此时核对的是许可证内容，不是安装问题，不要为此重装。

6.5 补配运维通知

适用场景：安装时跳过了运维通知，现在补上；或已有渠道尚未通过验证，需要修正。

前提：客户已建好接收告警的钉钉、飞书或企业微信群机器人，或提供了 Webhook 接收地址；安装主机能访问该地址。

操作步骤

1. 以 root 登录，打开「系统维护 › 部署配置」，找到「运维通知渠道」分组。
2. 点「修改」，填写渠道地址并保存。
3. 发送一条测试消息。
4. 请客户方告警接收人到对应群或接收端确认已收到测试消息，并在交付记录里登记接收人姓名与确认时间。
5. 需要紧急通知时，在平台控制台「通知渠道」中新建一个钉钉、飞书、企业微信或 Webhook 渠道，接收方与上一步的渠道不同；订阅「告警」后把「接收级别」选为「紧急通知」，发测试消息并「确认收到」。控制面失联或告警判定停止时，网关节点直接向该渠道发送通知。
6. 在同一页「最近一次验收」点「立即验收」，确认「真实出网」「运维渠道绑定」两项为「通过」。

你会看到

• 保存后提示「已保存，相关服务将自动重新加载」，随后提示修改已生效。
• 测试消息送达时提示「测试消息已送达」；失败时提示「测试消息投递失败」。
• 重新验收后，两项检查显示「通过」。

注意：

• 不提供邮件作为运维通知渠道。
• 测试消息投递失败时，先在安装主机上用 sudo zenova doctor --target <渠道地址> 分层检查 DNS、TCP、TLS、HTTP 连通性；报告注明「直连，可能与生产出口不一致」时，结果不代表网关出口的连通性。
• 只有「发送成功」不够，必须由接收人确认收到，才能证明告警真的能送到人。
• 紧急通知渠道与其它接收告警的渠道使用同一接收方时，平台控制台「通知渠道」页面顶部给出提示；控制面失联时两类通知会落到同一个群，值班人员无法区分。
• 各渠道在页面上具体显示哪些字段、测试按钮的位置，以实际页面为准。

6.6 初始化完成后的核对表

把第 1 章 1.6 节确认表中的计划值与现场实际值逐项核对。不一致的项目要么修正现场，要么经客户确认后修改计划值，并记入交付记录。

# 安装主机 · root · 只读（生成核对时可附上的状态快照）
sudo zenova status
sudo zenova backup list
chronyc tracking

注意：这张表核对完成、客户签字后，与第 1 章确认表、答案文件副本（不含口令）一起归入交接材料。之后按第 7 章完成模型供应商接入与真实调用的验收。

能力说明

上一章：5. 非交互安装 · 下一章：7. 安装验收