维护Nexus时，先确认版本、运行账号和数据位置，再考虑启动命令。2018年的三条笔记分别涉及Nexus 2.6.4、3.5.1和3.13.0，不能把它们拼成同一套安装或升级步骤。

不同版本的目录与脚本别混用

三份历史记录分别做了这些事：

  • Nexus 2.6.4：把启动脚本链接到旧SysV服务目录，再用service/chkconfig管理。
  • Nexus 3.5.1：下载解压Unix包，执行bin/nexus start，访问管理界面。
  • Nexus 3.13.0：进入该安装目录的bin，用start、stop、status管理。

这些版本号与目录只说明当年环境；安装包来源、Java要求和服务包装方式应查目标版本文档，不继续使用旧下载地址、默认口令或root账号当作安装模板。

先识别应用目录和数据目录

程序解压目录放运行组件；数据目录保存运行数据与配置。Nexus 3的常见历史布局是应用目录旁有 sonatype-work/nexus3，但实际路径可以配置，blob store也可能使用其他位置或对象存储。Sonatype基本目录说明

检查实际启动参数、日志与存储配置，而不是只靠目录名称判断。迁移或升级前应记录程序、数据库/元数据、blob、配置、权限和备份的对应关系；复制bin目录不是完整搬迁。

手动启动与系统托管只能有清楚的负责人

对包含相应脚本的历史安装，命令形状是：

<application-directory>/bin/nexus status
<application-directory>/bin/nexus start
<application-directory>/bin/nexus stop

这里是需要替换路径的文本示意，启动/停止会改变服务。应以专用账号和正确配置执行，不与另一个管理器重复拉起同一数据目录。

systemd或其他托管方式下，优先用已确认的服务单元管理。开机启用与当前运行不同，详见Linux服务启动与自启；不能把一条ln命令当作所有系统的自启配置。

打开管理界面，还没完成Maven私服接入

仓库职责要分清：

类型主要职责
hosted存储内部发布或受控上传的构件
proxy访问并缓存上游仓库内容
group将多个仓库组织为统一读取入口

Maven客户端的依赖读取入口与发布目标可以不同；发布到具有相应策略与权限的hosted仓库，不因为配置了group下载入口就自动拥有上传能力。Sonatype仓库类型

还需配置受控访问、凭据、release/snapshot策略和备份；验证至少包含启动日志、指定构件下载与获授权的测试发布。界面能列出构件也不能证明blob完整，具体案例见迁移后MissingBlobException。