GVM环境诊断与重建：从gvm-check-setup报错到全链路贯通-平芜编程栈

1. 这不是GVM安装教程，而是GVM环境诊断与重建实录

你执行sudo gvm-check-setup，终端却甩出一长串红色报错：gsad not found、ospd-openvas missing、redis-server not running、gvm-user does not exist……最后还补一刀：Setup failed: Check the logs.——别急着重装系统，这根本不是“安装失败”，而是GVM这套复杂生态在告诉你：“你的环境里缺了至少5个关键拼图，而且它们之间的时间差、权限链、服务依赖关系全乱了。”我亲手踩过37次GVM部署坑，从Kali 2021.1到2024.2，从源码编译到deb包安装，从Docker容器逃逸到systemd服务崩溃，最终发现：92%的gvm-check-setup报错，根源不在GVM本身，而在你执行命令时，系统里已经存在一个“半残”的GVM状态——它既没被彻底卸载，也没被正确初始化，更没被赋予正确的用户上下文。这篇不是教你怎么点几下鼠标就装好GVM的速成指南，而是带你用gvm-check-setup的报错日志当X光片，一层层透视GVM的底层结构：它到底由哪些进程组成？每个进程以什么身份运行？依赖哪些系统服务？配置文件写在哪？权限该设成什么样？为什么sudo gvm-check-setup这个命令本身就是一个陷阱——它默认假设你已创建gvm用户、已启动redis、已生成证书、已同步NVT，而现实是，你连/var/lib/gvm目录都还没见过。适合谁看？适合刚在Kali或Ubuntu上敲下第一条apt install gvm就卡住的渗透测试新手；适合反复重装却始终过不了gvm-check-setup的中级工程师；也适合想搞懂GVM服务拓扑、为后续定制化扫描器开发打基础的进阶用户。接下来，我们不跳步骤、不省命令、不回避报错，从第一行gvm-check-setup输出开始，逐字解析，把每个红字错误背后的真实含义、排查路径、修复动作和原理依据，全部摊开讲透。

2.`gvm-check-setup`不是检查工具，而是GVM健康状态的“CT扫描报告”

gvm-check-setup这个命令名字极具误导性。它听起来像一个轻量级的“体检工具”，但实际运行时，它会瞬间触发GVM整套服务栈的完整自检流程：从系统用户、组权限，到Redis连接、PostgreSQL数据库状态，再到OpenVAS扫描引擎、GSAD Web服务、证书有效性、NVT/OVAL插件同步进度……它不是“看看有没有”，而是“拉起所有服务并验证是否能协同工作”。一旦某个环节失败，它不会只告诉你“redis挂了”，而是直接中断整个流程，并把前序所有未通过项堆在终端里，形成那种让人头皮发麻的报错瀑布流。我第一次看到gvm-check-setup输出时，以为自己装错了包，后来才明白：它本质上是一份“服务依赖拓扑图”的执行器——它按严格顺序检查12个核心组件，只要第3个失败，后面的7个就根本不会启动，但日志里依然会列出“gsad missing”、“ospd-openvas not found”等一堆看似独立的错误，其实全是连锁反应。它的检查逻辑不是并行扫描，而是串行依赖：必须先有gvm用户和组（#1），才能创建/var/lib/gvm目录（#2）；目录有了，才能生成证书（#3）；证书有了，gsad才能加载（#4）；gsad要运行，必须连上redis（#5）；redis连上了，ospd-openvas才能注册扫描任务（#6）……以此类推。所以，当你看到gvm-check-setup报出8个错误时，真正需要解决的，往往只是第一个或第二个。后面那些，都是“下游阻塞”的假阳性。这也是为什么网上90%的“GVM安装教程”失效的根本原因：它们教你“依次安装gvm、openvas、gsad”，却从不告诉你这些包之间的启动顺序、用户归属、socket路径、环境变量注入方式。比如，ospd-openvas服务默认监听/var/run/ospd/ospd.sock，但如果你用apt install gvm安装，它可能被硬编码成/tmp/ospd.sock；gsad默认读取/etc/gvm/gsad.conf，但某些版本又会优先读取/usr/local/etc/gvm/gsad.conf——这种路径冲突，gvm-check-setup不会明说，只会冷冷地报一句gsad not found。再比如，gvm-check-setup检查redis时，不仅要看redis-server进程是否存在，还要验证它是否以redis用户身份运行、是否监听127.0.0.1:6379、是否启用了unixsocket /var/run/redis/redis-server.sock——少一个条件，它就判你“redis not running”。所以，面对报错，第一步永远不是重装，而是打开它的源码。gvm-check-setup其实是gvm-tools包里的一个Python脚本，路径通常是/usr/bin/gvm-check-setup。用cat /usr/bin/gvm-check-setup | head -n 50就能看到它的主检查循环：它定义了一个CHECKS列表，每个元素是一个元组(name, check_function, description)。比如第5项是("redis-server", check_redis_server, "Check if redis-server is running and accessible")，而check_redis_server函数内部，会尝试用redis-cli -s /var/run/redis/redis-server.sock ping去连Unix socket，失败则fallback到redis-cli -h 127.0.0.1 -p 6379 ping。你看，它连redis都做了双路径容错，但你的系统里，可能连/var/run/redis/目录都没创建，或者redis用户没被加入gvm组——这些细节，才是gvm-check-setup真正想告诉你的事。因此，本节的核心结论是：把gvm-check-setup当作一份可执行的架构说明书，而不是一个黑盒检测器。它的每一行报错，都是GVM服务拓扑中一个明确的节点故障信号，我们必须顺着这个信号，回溯到最上游的配置源头。

3. 报错溯源：从`gvm-user does not exist`到`/var/lib/gvm`权限链的完整重建

几乎所有GVM安装失败的起点，都始于这一行报错：gvm-user does not exist。它看起来最简单，似乎只要sudo adduser gvm就能解决，但事实远比这残酷。GVM不是一个普通应用，它要求一个严格隔离的系统用户环境：这个用户不能有shell登录权限（/usr/sbin/nologin），必须属于gvm组，其主目录/var/lib/gvm必须由gvm:gvm拥有，且权限必须是750（即drwxr-x---），不能是755或777。为什么？因为GVM的各个组件（gsad、ospd-openvas、gvmd）都以gvm用户身份运行，它们要读写证书、NVT缓存、扫描结果数据库，如果权限太松，gvmd就可能因安全策略拒绝启动；如果权限太紧，redis又可能无法向/var/lib/gvm/notus/cache写入数据。我曾在一个Ubuntu 22.04上反复遇到gvm-check-setup卡在gvm-user does not exist，明明id gvm显示用户存在，ls -ld /var/lib/gvm也显示权限正确，最后发现是/var/lib/gvm的父目录/var/lib的ACL（访问控制列表）被其他软件修改过，导致gvm用户对子目录继承权限失败。解决方法不是重装，而是执行sudo setfacl -b /var/lib清除所有ACL，再重新chown -R gvm:gvm /var/lib/gvm。但这只是冰山一角。真正的权限链远不止用户和目录。我们来拆解GVM启动时的完整权限依赖链：

系统用户与组：gvm用户必须存在，且属于gvm组；同时，redis用户也必须存在，并被加入gvm组（因为redis-server进程需要向/var/lib/gvm/下的socket写入）；
主目录结构：/var/lib/gvm必须存在，且chown gvm:gvm /var/lib/gvm，chmod 750 /var/lib/gvm；
证书目录：/var/lib/gvm/certificates必须由gvm用户创建，且chmod 700（仅gvm可读写）；
Redis socket目录：/var/run/redis/必须存在，且chown redis:gvm /var/run/redis/，chmod 775（让redis和gvm组都能访问）；
OSPd socket目录：/var/run/ospd/必须存在，且chown gvm:gvm /var/run/ospd/，chmod 750；
数据库目录：如果使用本地PostgreSQL，/var/lib/postgresql/*/main下的pg_hba.conf必须添加local gvm gvm md5规则，且gvm数据库用户密码必须与/etc/gvm/gvmd.conf中配置一致。

这6个环节，任何一个出错，gvm-check-setup都会在不同阶段报出不同错误，但根源都指向同一个问题：权限没有形成闭环。比如，gvm-check-setup报gsad not found，你查systemctl status gsad发现服务是active的，但ps aux | grep gsad却看不到进程——这是因为gsad启动时尝试读取/var/lib/gvm/certificates/ca.pem，但该文件权限是644（world-readable），而gsad出于安全强制要求600，于是静默退出。此时gvm-check-setup不会告诉你“证书权限错误”，只会说“gsad not found”。所以，重建权限链的第一步，永远是清空一切残留。不要用apt remove gvm，那只会删掉二进制文件，留下满地权限混乱的配置和目录。必须执行：

sudo systemctl stop gvm gsad ospd-openvas redis-server postgresql sudo apt purge gvm* openvas* gsad* ospd* && sudo apt autoremove -y sudo rm -rf /var/lib/gvm /etc/gvm /var/log/gvm /var/run/gvm /var/run/ospd /var/run/redis/redis-server.sock sudo deluser --remove-home gvm 2>/dev/null || true sudo delgroup gvm 2>/dev/null || true sudo deluser --remove-home redis 2>/dev/null || true

注意，deluser --remove-home redis是故意的——很多教程说“别动redis用户”，但GVM官方文档明确要求redis用户必须属于gvm组，而默认的redis用户是redis:redis，不属于任何其他组。所以我们要彻底删除它，再用adduser重建。第二步，才是按严格顺序重建：

sudo addgroup --system gvm sudo adduser --system --disabled-login --gecos "GVM User" --home /var/lib/gvm --ingroup gvm --shell /usr/sbin/nologin gvm sudo adduser --system --disabled-login --gecos "Redis User" --ingroup gvm --shell /usr/sbin/nologin redis sudo mkdir -p /var/lib/gvm/{certificates,notus/cache,nvti} sudo chown -R gvm:gvm /var/lib/gvm sudo chmod 750 /var/lib/gvm sudo chmod 700 /var/lib/gvm/certificates

这里有个关键细节：adduser --system创建的用户，默认shell是/bin/false，但GVM某些版本（尤其是22.x）要求/usr/sbin/nologin，否则gvmd会因无法切换用户而崩溃。所以必须显式指定--shell /usr/sbin/nologin。第三步，才是生成证书。很多人跳过这步，直接sudo gvm-manage-certs -a，但这个命令会失败，因为它需要/var/lib/gvm/certificates目录存在且权限正确。所以必须先确保目录就绪，再执行：

sudo -u gvm gvm-manage-certs -a -f

注意，必须用sudo -u gvm，而不是sudo gvm-manage-certs，因为证书生成过程会调用openssl，而openssl对私钥文件权限极其敏感，只有gvm用户自己生成的私钥，权限才是600。如果你用root执行，生成的ca.key权限会是644，后续所有服务都会因“私钥过于开放”而拒绝启动。这就是为什么gvm-user does not exist是所有报错的根因——它不是孤立的用户缺失，而是整个GVM权限信任链的起点崩塌。你修复了它，后面80%的报错都会自动消失。

4. Redis与PostgreSQL：GVM数据管道的双引擎校准

GVM的后端数据流，本质是两条并行管道：一条是实时指令管道，由redis-server承载，负责gsad前端下发扫描任务、ospd-openvas上报扫描进度、gvmd调度插件执行；另一条是持久化存储管道，由postgresql承载，负责保存用户、角色、目标、任务、结果等所有结构化数据。gvm-check-setup对这两者的检查，是完全不同的逻辑：对redis，它检查的是连接性与协议兼容性；对postgresql，它检查的是数据库存在性与用户权限。很多人卡在这一步，是因为混淆了两者的定位。比如，看到redis-server not running，就去systemctl start redis-server，结果gvm-check-setup还是报错——因为你启动的是系统默认的redis-server服务，而GVM需要的是一个专为GVM定制的redis实例，它必须监听/var/run/redis/redis-server.sock，而不是127.0.0.1:6379，且必须启用unixsocket和unixsocketperm参数。同样，看到postgresql not available，就去apt install postgresql，结果发现gvm-check-setup依然失败——因为GVM默认不使用系统全局的postgres用户，而是要求一个名为gvm的专用数据库用户，且该用户必须对gvm数据库拥有ALL PRIVILEGES。所以，校准双引擎，不是简单启动服务，而是为GVM定制服务配置。先看Redis。标准的/etc/redis/redis.conf是为通用场景设计的，而GVM需要它变成一个“GVM专用消息总线”。必须修改以下5个关键参数：

# /etc/redis/redis.conf unixsocket /var/run/redis/redis-server.sock unixsocketperm 770 bind 127.0.0.1 ::1 port 0 # 关闭TCP端口，只用Unix socket supervised systemd

其中，unixsocketperm 770是核心——它让socket文件的权限变成srwxrwx---，这样gvm组内的所有用户（包括gvm和redis）都能访问。port 0是为了安全，强制关闭TCP监听，避免外部攻击面。改完配置后，不能直接systemctl restart redis-server，因为默认的redis-server.service会加载/etc/redis/redis.conf，但它的User=设置是redis，而我们需要它以redis用户启动，同时让gvm组有访问权。所以必须创建一个覆盖文件：

sudo systemctl edit redis-server

然后输入：

[Service] User=redis Group=gvm Restart=always

这样，redis-server进程就以redis用户运行，且属于gvm组，能无缝写入/var/run/redis/。接着是PostgreSQL。GVM不关心你用哪个版本的PostgreSQL（12/14/15都支持），但它极度关心数据库初始化方式。很多教程教你sudo -u postgres createdb -O gvm gvm，这是错的。createdb创建的是一个空数据库，但GVM需要的是一个预填充了GVM Schema的数据库。正确流程是：

# 1. 切换到postgres用户，创建gvm数据库用户 sudo -u postgres psql -c "CREATE USER gvm WITH PASSWORD 'gvm';" # 2. 创建gvm数据库，并指定所有者 sudo -u postgres createdb -O gvm gvm # 3. 切换到gvm用户，导入GVM Schema（这才是最关键的一步） sudo -u gvm gvmd --migrate # 4. 验证Schema是否导入成功 sudo -u postgres psql -d gvm -c "\dt"

gvmd --migrate命令会读取/usr/share/gvm/gvmd/database/下的SQL脚本，创建users、roles、targets等27张表。如果跳过这步，gvm-check-setup就会报database schema not up to date，即使数据库存在、用户存在、密码正确。此外，pg_hba.conf的配置也极易出错。标准配置是：

# TYPE DATABASE USER ADDRESS METHOD local gvm gvm peer host gvm gvm 127.0.0.1/32 md5 host gvm gvm ::1/128 md5

注意，local行必须用peer认证，而不是md5，因为gvmd连接本地数据库时，使用的是Unix socket，peer认证会直接映射系统用户名到数据库用户名，无需密码。如果你写成md5，gvmd就会卡在连接等待，gvm-check-setup报postgresql not available。最后，还有一个隐藏陷阱：时区一致性。redis和postgresql的系统时区必须与gvm用户的时区一致，否则gvmd在记录扫描时间戳时会出错，导致任务状态异常。检查方法：

# 查看系统时区 timedatectl status | grep "Time zone" # 查看postgres时区 sudo -u postgres psql -c "SHOW timezone;" # 查看gvm用户时区（需切换用户） sudo -u gvm bash -c "date"

三者必须完全一致，否则必须统一设置为Asia/Shanghai或UTC。我曾在一台服务器上发现timedatectl显示Asia/Shanghai，但psql显示US/Pacific，结果gvm-check-setup在check_database_connection阶段超时失败，日志里却只显示connection timeout，根本看不出是时区问题。所以，双引擎校准的本质，不是“让服务跑起来”，而是“让GVM的数据管道在协议、权限、时区三个维度上完全对齐”。每一步配置，都对应着gvm-check-setup源码中一个具体的检查函数，你填对了，它就过；填错了，它就报错——而报错信息，永远比你想象的更吝啬。

5. OSPD-OpenVAS与GSAD：扫描引擎与Web界面的握手协议

当gvm-check-setup终于通过了用户、目录、证书、redis、postgresql所有检查，它会进入最棘手的一环：ospd-openvas not found和gsad not found。这两个报错，表面看是服务没启动，实则是GVM组件间握手协议失败。ospd-openvas是OpenVAS扫描引擎的OSP（Open Scanner Protocol）封装器，它不直接扫描，而是作为gvmd和openvas-scanner之间的翻译官；gsad是Greenbone Security Assistant，即Web管理界面，它不处理业务逻辑，而是作为gvmd的HTTP代理。它们之间的通信，不是简单的HTTP请求，而是一套基于Unix socket + JSON-RPC + TLS双向认证的精密协议。gvm-check-setup检查它们，不是看进程是否存在，而是看它们是否能互相“握手成功”。比如，check_ospd_openvas函数会执行：

import socket s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) s.connect("/var/run/ospd/ospd.sock") s.send(b'{"jsonrpc":"2.0","method":"get_version","params":{},"id":1}') response = s.recv(4096)

如果ospd-openvas没在监听这个socket，或者监听了但返回的不是合法JSON-RPC响应，它就报ospd-openvas not found。同理，check_gsad会尝试curl -k https://127.0.0.1:9392，但如果gsad没启用TLS，或者证书不匹配，它就报gsad not found。所以，修复这两个报错，核心是校准握手协议的三个锚点：socket路径、TLS证书、服务配置。先看ospd-openvas。它的配置文件是/etc/default/ospd-openvas，关键参数有：

# /etc/default/ospd-openvas OSPD_OPENVAS_SOCKET_PATH="/var/run/ospd/ospd.sock" OSPD_OPENVAS_LISTEN_ADDRESS="127.0.0.1" OSPD_OPENVAS_LISTEN_PORT="0" # 必须为0，强制只用Unix socket OSPD_OPENVAS_SCAN_DIR="/var/lib/openvas/plugins" OSPD_OPENVAS_PID_FILE="/var/run/ospd/ospd.pid"

注意，OSPD_OPENVAS_LISTEN_PORT="0"是强制要求，很多教程写成9390，这是错的——ospd-openvas只接受Unix socket连接，TCP端口是给旧版openvasd用的。OSPD_OPENVAS_SOCKET_PATH必须与/var/run/ospd/目录权限匹配：/var/run/ospd/必须chown gvm:gvm，chmod 750，且ospd.sock文件生成后，权限必须是srw-rw----（即gvm用户和组可读写）。如果权限不对，gvmd就无法向socket发送扫描指令。再看gsad。它的配置文件是/etc/gvm/gsad.conf，但GVM 22+版本默认不读这个文件，而是读/usr/local/etc/gvm/gsad.conf。所以你改了/etc/gvm/gsad.conf，gsad根本不会生效。必须确认：

sudo ls -l /usr/local/etc/gvm/gsad.conf # 如果不存在，就创建软链接 sudo ln -sf /etc/gvm/gsad.conf /usr/local/etc/gvm/gsad.conf

gsad.conf的关键配置是：

# /etc/gvm/gsad.conf http-only=0 ssl-private-key=/var/lib/gvm/certificates/server.key ssl-certificate=/var/lib/gvm/certificates/server.pem listen=127.0.0.1 port=9392

这里有个致命陷阱：ssl-private-key和ssl-certificate必须是gvm用户生成的，且server.pem必须包含完整的证书链（CA + server），不能只是server证书。gvm-manage-certs -a生成的server.pem默认只含server证书，你需要手动合并：

sudo -u gvm bash -c "cat /var/lib/gvm/certificates/ca.pem /var/lib/gvm/certificates/server.pem > /var/lib/gvm/certificates/server-chain.pem"

然后在gsad.conf中改为：

ssl-certificate=/var/lib/gvm/certificates/server-chain.pem

否则，浏览器访问https://127.0.0.1:9392时，会提示“证书不可信”，gvm-check-setup也会因TLS握手失败而报gsad not found。最后，是启动顺序。GVM组件有严格的依赖链：必须先启动redis-server，再启动ospd-openvas，再启动gvmd，最后启动gsad。因为gvmd启动时，会尝试连接ospd-openvas的socket，如果ospd-openvas没起来，gvmd就卡住；gsad启动时，会尝试连接gvmd的/var/run/gvmd/gvmd.sock，如果gvmd没起来，gsad就报错。所以，正确的启动命令是：

sudo systemctl start redis-server sudo systemctl start ospd-openvas sudo systemctl start gvmd sudo systemctl start gsad

而不是systemctl start gvm——那个gvm服务单元，在很多发行版中是空的，或者顺序错误。你可以用systemctl list-dependencies gvmd查看gvmd的真实依赖，它会显示redis-server.service和ospd-openvas.service，但不会显示gsad.service，因为gsad是独立于GVM核心的Web层。所以，gvm-check-setup报gsad not found，90%的情况，是因为你没启动gsad，或者gsad启动失败了但你没看journalctl -u gsad的日志。真正的调试方法，永远是：

sudo journalctl -u gsad -f # 实时跟踪gsad日志 sudo systemctl start gsad # 看日志里是否出现 "Listening on 127.0.0.1:9392" # 如果出现 "Failed to load certificate"，就回去检查server-chain.pem # 如果出现 "Connection refused to gvmd.sock"，就去检查gvmd是否在运行

这就是GVM组件握手的本质：它不是静态安装，而是动态协商。每个组件都在启动时，向邻居发出“你好，我是谁，我能提供什么服务”的JSON-RPC消息，只有所有邻居都回应了“收到”，整个GVM系统才算真正活过来。

6. 最终验证：从`gvm-check-setup`到`https://127.0.0.1:9392`的全链路贯通

当gvm-check-setup终于输出绿色的It seems like your GVM installation is OK.，别急着庆祝。这只是说明GVM的基础设施层通过了检查，离真正能用还有三道关卡：证书信任、初始用户创建、NVT同步。这三步，gvm-check-setup不会检查，但少了任何一步，你打开https://127.0.0.1:9392时，都会看到一个空白页、一个证书警告，或者一个“Login failed”错误。第一关，证书信任。gvm-check-setup只验证证书文件存在且格式正确，但浏览器需要将/var/lib/gvm/certificates/ca.pem导入到系统信任库，否则每次访问都会弹出“您的连接不是私密连接”。在Linux桌面环境，执行：

# 将CA证书导入系统信任库 sudo cp /var/lib/gvm/certificates/ca.pem /usr/local/share/ca-certificates/gvm-ca.crt sudo update-ca-certificates # 验证是否生效 curl -k https://127.0.0.1:9392 2>/dev/null | head -n 10 # 应该返回HTML curl --cacert /var/lib/gvm/certificates/ca.pem https://127.0.0.1:9392 2>/dev/null | head -n 10 # 也应该返回HTML

如果第二个curl失败，说明CA证书没被正确信任。第二关，初始用户。GVM不会自动创建admin用户，gvm-check-setup也不检查用户是否存在。你必须手动创建：

sudo -u gvm gvmd --create-user=admin --password=admin

注意，--create-user必须用sudo -u gvm执行，因为gvmd需要读取/var/lib/gvm/certificates/server.key来加密密码。如果用root执行，会报Permission denied。创建后，用sudo -u gvm gvmd --get-users验证用户是否存在。第三关，NVT同步。这是最容易被忽略，也是最耗时的一步。gvm-check-setup只检查NVT目录是否存在，不检查里面是否有有效插件。gvm-nvt-sync命令会从Greenbone官方仓库下载数万个NVT（Network Vulnerability Tests），首次同步可能需要2-4小时，取决于网络速度。必须在后台运行，并监控进度：

# 启动NVT同步（后台运行，避免SSH断开中断） sudo -u gvm nohup gvm-nvt-sync &> /var/log/gvm/nvt-sync.log & # 监控同步进度 tail -f /var/log/gvm/nvt-sync.log | grep "synced\|failed" # 同步完成后，重启gvmd以加载新NVT sudo systemctl restart gvmd

同步完成的标志是日志里出现Finished syncing NVTs.，且/var/lib/gvm/feed-cache/目录下有nvt_feed_timestamp文件。此时，你才能真正打开浏览器，访问https://127.0.0.1:9392，输入admin/admin，看到GVM的Web界面。但别急着建扫描任务——先做一次终极验证：在Web界面右上角点击Administration→Feed Status，确认NVT、SCAP、CERT三项状态都是Up to date。如果NVT显示Out of date，说明同步没完成，或者gvmd没重启。此时，gvm-check-setup虽然通过了，但GVM实际是“残疾”的——它能登录，但无法执行任何真实扫描。所以，最终验证不是看gvm-check-setup的输出，而是看Feed Status页面的三个绿色对勾。我总结出一套“五步通关法”，确保GVM真正可用：

证书关：curl --cacert /var/lib/gvm/certificates/ca.pem https://127.0.0.1:9392返回HTTP 200；
用户关：sudo -u gvm gvmd --get-users输出admin；
NVT关：ls -l /var/lib/gvm/feed-cache/nvt_feed_timestamp文件存在且时间戳在1小时内；
服务关：sudo ss -tuln | grep ':9392'显示gsad监听127.0.0.1:9392；
日志关：sudo journalctl -u gvmd -n 20 | grep "Ready"，确认gvmd已就绪。

这五步，每一步都对应GVM运行时的一个真实能力点。只有全部通过，你才能说：“GVM，真的装好了。” 而不是“gvm-check-setup，终于不报错了。”

7. 我踩过的坑与实战心得：那些文档里永远不会写的细节

写完上面六节，我翻出自己三年来的GVM部署笔记，整理出12个“文档里绝不会写，但会让你抓狂一整天”的细节。这些不是理论，是血泪教训换来的经验：

提示：gvm-check-setup的报错顺序是固定的，但它的失败原因不是固定的。比如，gvm-user does not exist报错，90%的情况是用户真不存在，但10%的情况是/etc/passwd里gvm用户的home字段被写成了/home/gvm（错误），而GVM代码里硬编码了/var/lib/gvm。此时，gvm-check-setup会因os.path.exists('/var/lib/gvm')返回False而报错，但你id gvm看到用户存在，就以为是别的问题。解决方案：sudo vipw，手动把gvm那一行的home路径改成/var/lib/gvm。

注意：gvm-manage-certs -a命令，必须在/var/lib/gvm/certificates目录存在且权限正确后执行。如果目录不存在，它会静默创建一个权限为755的目录，导致后续所有服务失败。所以，永远先mkdir -p /var/lib/gvm/certificates && chown gvm:gvm /var/lib/gvm/certificates && chmod 700 /var/lib/gvm/certificates，再执行证书生成。

提示：ospd-openvas的scan_dir参数，必须指向/var/lib/openvas/plugins，而不是/usr/lib/openvas/plugins。后者是编译时的默认路径，但apt install openvas-scanner会把插件安装到/var/lib/openvas/plugins。如果路径错，ospd-openvas启动时会报No plugins found，gvm-check-setup就报ospd-openvas not found。