装过 GVM 的朋友大概都经历过这样的时刻apt install gvm敲下去gvm-setup跑了十几分钟终端里终于出现一堆绿色“OK”或者提示设置管理员密码的信息你以为万事大吉。结果打开https://127.0.0.1:9392登录 Greenbone Security Assistant点进Scans - Scan Configs页面干干净净一行配置都没有。更诡异的是创建扫描任务时让人选择 Scan Config 的下拉框也是空的或者干脆弹出一段scan config error “XXXXXXXXXXX”。这个“没有 scan configs”的坑我在 Kali 2022 上前后踩过三次。前两次都选择重装 GVM浪费了整整一个下午第三次才耐下心把原因链路彻底捋清楚。这篇文章不是 GVM 使用教程而是专门针对“scan configs 缺失或报错”这个具体问题的排查笔记。如果你刚装完 openvas/gvm 发现配置列表为空或者某次系统升级后配置突然全没了那这篇文章能帮你少走不少弯路。1. 先搞清楚 scan config 在 GVM 里到底是怎么生成的很多人在排查这个问题时第一反应是“重装包”但重装解决不了问题因为你连 config 的生成机制都没搞明白。当你理解了 scan config 的来龙去脉修复思路就会清晰很多。1.1 GVM 全家桶谁在负责配置管理标题里把 openvas 和 gvm 并列这其实是很自然的叫法。GVMGreenbone Vulnerability Management是 OpenVAS 的正统后续但它早已不是一个单一程序而是一整套组件体系。在这个体系里真正承担“管理”职责的是gvmdGreenbone Vulnerability Manager daemon也就是那个负责处理扫描任务、扫描配置、报告格式和用户权限的后台守护进程。gvmd的所有业务数据都存在 PostgreSQL 数据库里数据库名通常叫gvmd。任务列表、扫描结果、用户账号、报告格式全都在这一个库里。scan config 也一样它不是磁盘上的一个 XML 文件或者 JSON 配置而是gvmd数据库configs表里的一条条记录。另一个容易混淆的点是很多人以为 scan config 是 openvas-scanner 提供的。其实 scanner 只管执行具体的漏洞探测它接收的是 gvmd 下发下来的扫描指令本身并不关心“用哪个配置去扫”。所以当你发现 GSA 页面里没有 scan configs 时问题大概率出在gvmd数据库这一侧而不是扫描器那一侧。1.2 config 是“导入”出来的不是“自带”的GVM 安装完成后数据库是一张白纸。那预置的 Full and fast、Base、Discovery、Host Discovery 这些扫描配置是怎么来的答案是 feed 同步。GVM 的知识库分成好几块NVT 是漏洞测试脚本给 scanner 用SCAP 是安全内容自动化协议的数据CERT 是应急响应团队的数据还有一块叫 GVMD_DATA里面包含预置的 scan configs、report formats、port lists 这些“管理层面”的数据。gvm-setup在初始化时会把这些 feed 依次下载并导入数据库。关键就在这里scan config 是 gvmd 在导入 GVMD_DATA 时写入数据库的。如果这一步因为网络中断、磁盘空间不足、数据库锁冲突或者脚本超时而失败数据库里就不会有任何 scan config。更麻烦的是gvm-setup有时候不会因为某个子步骤失败而整体报错退出它可能打印了一堆 WARNING最后给你一个“setup finished”的假象等你打开 GSA 才发现配置列表是空的。打个比方这就像你换新手机后登录了微信App 能打开但通讯录是空的——因为通讯录同步那一步没成功。你不会靠重新卸载安装微信来解决而是去检查同步本身。2. 报错现场还原三种“没有 config”的真实形态标题里的scan config error “XXXXXXXXXXX”是一个很典型的占位符写法实际报错内容因人而异。但不管错误文案长什么样最终现象基本都逃不过下面三种形态。我们先把这些形态认清楚才能对症下药。2.1 GSA 页面空白和下拉菜单为空这是最常见的形态。登录 GSA 之后左侧菜单展开 Scans点进 Scan Configs 子页面中间内容区域是空的或者显示一行“No Scan Configs available”之类的提示。另一种情况是Scan Configs 页面看起来有配置但当你进入Scans - Tasks点击新建任务时Scan Config 的下拉框里一个选项都没有。这种情况下问题不一定是配置真的缺失也可能是 GSA 前端没能从后端gvmd里拿到配置列表数据。两种情况的处理路径不一样前者是数据库里没有 config 数据后者是 GSA 和后端之间通信出了问题需要重启gvmd和gsad服务或者强制刷新浏览器缓存。2.2 命令行空输出与日志线索GSA 只是个前端判断问题到底出在数据库还是前端最好的办法是绕开它直接问后端。在 Kali 2022 里用_gvm用户执行命令sudo -u _gvm gvmd --get-configs正常情况下这条命令会打印出所有扫描配置的 UUID 和名称比如“Full and fast”“Base”“Discovery”这样一行一行列出来。如果命令执行后没有任何输出那就说明gvmd自己都拿不到 config 数据问题铁定在数据库这一层。这时候再翻日志常见路径是/var/log/gvm/gvmd.log。你可以直接搜一下 ERROR 级别的记录sudo grep -i error /var/log/gvm/gvmd.log | tail -50大多数情况下日志里能看到 feed 导入失败的痕迹比如数据库连接超时、导入过程被中断、某个表不存在等等。这些日志能帮你把问题范围进一步缩小。2.3 scan config error “XXXXXXXXXXX” 是谁报的当你在创建任务或者调用 GSA 的 API 时系统返回类似scan config error: The requested scan config does not exist或者Failed to get config list这样的报错它大概率不是 scanner 报的而是gvmd通过 API 返回给 GSA 的错误信息。后端在数据库里查不到对应 UUID 的 config 记录就把这个错误逐层传递到了前端。所以看到一大串 “XXXXXXXXXXX” 错误代码不要慌。先把它翻译成人话要么是配置列表为空要么是某个具体配置的 UUID 失效了。前者对应数据库 configs 表为空后者对应你选中的配置引用了一个已经不存在的记录这在 NVT feed 更新后偶尔也会发生。3. 定位根因不重装系统也能查到问题的四层排查搞清楚现象之后接下来就是正儿八经的排查环节。我强烈建议你按下面的顺序走一遍不要一上来就gvm-setup重来否则很容易在同一个坑里摔两次。3.1 第一步gvm-check-setup 做整体体检Kali 的 GVM 包自带一个体检脚本gvm-check-setup它会从 PostgreSQL、文件系统、feed 数据、进程状态等各个维度检查安装是否完整。运行方式很简单sudo gvm-check-setup输出会是一长串检查项每一行都有 OK 或 FAILED 标记。如果某一项比如Step 7: Checking GVM data显示 FAILED那基本就等于告诉我GVMD_DATA 的导入存在问题scan configs 自然也就缺失了。不过要注意有些版本的gvm-check-setup只检查到“文件存在”这个程度不会去数据库里确认 configs 表有多少条记录所以即使它最后打印 “It seems like your GVM is ready”也不代表配置列表一定正常。体检脚本的价值更多是帮你筛掉低级问题比如 PostgreSQL 没启动、数据目录不存在这些。3.2 第二步磁盘、时间和网络三个“隐形杀手”如果你确定安装过程走完了却又缺数据先别怀疑软件包本身百分之六七十的情况出在下面三个环境因素上。第一个是磁盘空间。GVM 的 feed 全部下载下来体积相当可观/var/lib/gvm目录轻松就能吃掉十几个 GB。如果分区满了同步脚本下载到一半写不进磁盘导入自然失败。用df -h /var看一眼确认剩余空间。第二个是系统时间。feed 服务器使用 HTTPS 下载客户端和服务端做 TLS 握手时如果本机时间偏差太大证书验证会直接失败。很多人把这类错误当成网络不通绕了一大圈才发现是timedatectl里时间没同步。运行一下sudo timedatectl set-ntp true把时间同步打开再重新试同步命令。第三个是网络连通性。GVM 的 feed 服务器在境外我在国内网络环境下经常遇到下载超时的情况。你可以用curl -I https://feed.greenbone.net简单测一下通不通。如果 curl 卡住说明是网络问题而不是 GVM 配置问题。这时候你需要等网络恢复再同步或者换一个网络环境但不要用改软件配置的办法来“绕”网络问题那样只会搞出更多隐藏故障。3.3 第三步直查 PostgreSQL 的 configs 表环境因素排除之后就该直接看数据库了。GVM 的 PostgreSQL 数据库归_gvm用户所有所以要用_gvm身份登录查询不能直接用 postgres 用户去查——虽然 postgres 是超级用户但 GVM 默认的权限设计就是只让_gvm访问自己的库sudo -u _gvm psql -d gvmd -c SELECT count(*) FROM configs;如果返回的数字是 0说明数据库里确实一条 scan config 都没有问题定位得死死的。如果返回的数字大于 0比如有 10 条记录但 GSA 页面仍然空白那问题反而在后端进程或前端缓存此时重启gvmd和gsad可能就解决了sudo systemctl restart gvmd sudo systemctl restart gsad这里要提醒一句如果你尝试用 root 用户执行psql -d gvmd大概率会报 Peer authentication failed这是正常的GVM 的数据库认证方式默认就是 peer 认证。别想着去改pg_hba.conf把认证方式改成密码或者 trust不值得为了这一次排查给系统留下安全隐患。3.4 第四步进程、日志和文件所有权数据库查完再确认一下运行环境。先看进程ps aux | grep -E gvmd|gsad|ospd正常情况下gvmd、gsad、ospd-openvas这几个进程都应该存在且持续运行。如果gvmd进程反复退出那数据库连接或者权限肯定有问题这时候去翻/var/log/gvm/gvmd.log里面的 ERROR 记录比你在网上搜 error 代码有用得多。文件所有权也是一个容易被忽略的点。GVM 的所有数据都放在/var/lib/gvm这个目录和它下面的子目录、文件所有者必须是_gvm用户。如果你之前是用 root 手动同步过 feed或者从其他机器拷贝过数据文件所有者可能变成 root导致gvmd读取失败。发现不对劲就统一纠正sudo chown -R _gvm:_gvm /var/lib/gvm4. 恢复 configs 的三种方案从快速清库到无损补 feed根因定位之后接下来就是恢复操作。我把方案按“破坏性从小到大”排成三条你可以根据自己的情况选。总原则是有历史数据就不要轻易清库没有历史数据就别纠结直接重来最省心。4.1 方案一刚装完没有历史数据直接重新初始化适用场景你刚装完 GVM还没来得及创建任何扫描任务也没有扫描结果configs 缺失就是初始化没完成。这种情况最痛快的做法是全部清掉再走一遍。先停服务sudo gvm-stop然后删除旧的 gvmd 数据库和 feed 数据。数据库可以用 postgres 超级用户操作sudo -u postgres psql -c DROP DATABASE IF EXISTS gvmd;feed 数据直接删除sudo rm -rf /var/lib/gvm/*注意顺序先停服务再删数据库最后删文件。如果你只删/var/lib/gvm而不删数据库重新gvm-setup时新旧 schema 和数据很容易打架出现一堆莫名其妙的报错。删干净之后重新初始化sudo gvm-setup这次初始化会重新下载 feed 并导入数据库。看输出的时候不要只盯着最后的成功提示中间如果出现 “Importing GVM data ... failed” 或者 “WARNING: NVT sync failed” 这类字样说明 feed 同步仍然有问题你需要回到上一章排查网络和磁盘而不是无限重复gvm-setup。4.2 方案二保留已有数据只补 GVMD_DATA feed适用场景你已经跑过一些扫描数据库里有任务和结果不想因为 configs 缺失就把这些历史数据全删掉。这种情况下只需要把 GVMD_DATA 这块单独的 feed 重新同步一遍。先停服务避免导入过程中锁冲突sudo gvm-stop然后执行 GVMD_DATA 同步sudo runuser -u _gvm -- greenbone-gvmd-data-sync如果 Kali 的 GVM 版本里没有这个命令说明包装得比较老或比较新直接用通用更新脚本sudo gvm-update它内部会依次同步 NVT、SCAP、CERT 和 GVMD_DATA 四块数据效果是一样的。同步完成后最好再让gvmd重建一下内部索引sudo runuser -u _gvm -- gvmd --rebuild最后启动服务刷新 GSA 页面sudo gvm-start这个方法的好处是不动已有扫描数据坏处是如果数据库里除了 configs 表之外还有其他表结构不一致那补 feed 不一定能救得回来还是需要走方案一。4.3 方案三手动逐条同步四个 feed定位到底哪块坏了如果你喜欢把事情搞得更明白一点或者前两个方案执行后还是缺数据那就手动一条一条地同步看看究竟是哪一块出了岔子。在 Kali 2022 的 GVM 环境里四个 feed 对应四条命令sudo runuser -u _gvm -- greenbone-nvt-sync sudo runuser -u _gvm -- greenbone-scapdata-sync sudo runuser -u _gvm -- greenbone-certdata-sync sudo runuser -u _gvm -- greenbone-gvmd-data-syncNVT 同步影响漏洞检测库SCAP 和 CERT 影响合规与应急数据GVMD_DATA 影响 scan configs 和各种报告格式。如果你执行前面三条都正常只有最后一条greenbone-gvmd-data-sync报错那就能非常明确地断定问题就在 GVMD_DATA 导入环节。这时候重点看这条命令的报错内容比如磁盘空间、数据库连接、网络超时顺着报错去解决比对着网上二手教程瞎猜有效得多。手动同步的好处还有一个gvm-update这个一键脚本在下载超时时经常不打印具体哪一块失败手动同步则每个步骤都能看到进度和回报心里有数。4.4 数据库 schema 不一致时该做什么第三种情况比较特殊你执行psql查询configs表时报错不是“count 为 0”而是直接提示relation public.configs does not exist或者database gvmd does not exist。这说明数据库的结构不完整可能是在之前的初始化中途断电、手动删过表、或者跨大版本升级导致 schema 不一致。这种情况补 feed 已经没意义了因为表都没建好。先试试让gvmd自己迁移数据库结构sudo -u _gvm gvmd --migrate如果迁移能完成再跑gvmd --get-configs看有没有配置。如果迁移报错或者还是缺表不要犹豫直接按方案一把数据库整个重建。在 schema 损坏的前提下任何修复命令都是在浪费时间的边缘试探。5. 验证和维护别再让 configs 从眼皮底下消失configs 恢复之后别急着庆祝先做一轮验证顺手把容易二次踩坑的点也收拾干净。5.1 怎么证明 configs 真的回来了验证分两部分后端数据库和前端页面。后端验证就看gvmd能不能列出配置sudo -u _gvm gvmd --get-configs如果看到类似下面这样的输出就说明数据库层面已经正常Full and fast Base Discovery Host Discovery System Discovery前端验证就是浏览器打开https://127.0.0.1:9392进入 Scan Configs 页面能看到刚才列出的那些配置名。由于 GSA 是个典型的单页应用前端页面可能缓存了旧状态所以如果页面还是空白先强制刷新CtrlShiftR或者换个无痕窗口再试一次别动不动就怀疑服务没起来。更完整的验证是创建一个真实任务比如新建一个任务Scan Config 选“Host Discovery”Target 选本地 IP跑一次确认整个扫描链路没问题。这一步能顺带验证 gvmd、scanner、GSA 之间的通信是否正常而不只是配置列表有数据。5.2 升级、重启、权限最容易二次踩坑的三件事GVM 恢复如初之后日常维护里有三件事最容易把 configs 弄丢我挨个说一遍。第一Kali 是滚动发行版apt full-upgrade升级 GVM 相关包之后数据库 schema 有可能会自动迁移但 feed 数据不一定自动同步。所以重大升级之后老老实实跑一遍sudo gvm-check-setup sudo gvm-update sudo gvm-start这样能最大概率避免出现“页面打不开”“configs 消失”这类升级后遗症。第二不要用 root 去跑gvmd的命令。虽然 root 能执行但 root 创建的数据文件所有者是 root而gvmd在 Kali 上是以_gvm用户运行的下次启动就出现权限冲突表现方式之一就是 configs 读不出来。记住统一用sudo -u _gvm gvmd ...或者sudo runuser -u _gvm -- ...的格式。第三不要同时装 openvas 和 gvm 两个包。Kali 仓库里的openvas是老牌的独立包gvm是后来的全家桶。如果你图省事两个包装一起两个版本的 scanner、manager 和服务脚本会互相抢端口、抢配置最后 GSA 登录界面都很难打开更别说正常读取 configs。要么只用 gvm 全家桶要么只用老 openvas别混搭。5.3 如果你喜欢折腾自定义 config别忘了先备份最后给喜欢自定义配置的玩家一个建议scan config 是可以自己创建的你可以从某个预置配置复制一份出来然后启用或禁用某些 NVT。这种自定义 config 也存在数据库里和预置配置没有本质区别。但正因为它是数据库数据重装 GVM 或者重建数据库之后自定义配置是找不回来的。我自己的习惯是每调完一版自定义 config就用pg_dump把 gvmd 数据库导出一份备份放在独立目录里sudo -u _gvm pg_dump gvmd gvmd_backup_$(date %F).sql以后万一再碰上 configs 清空我可以恢复数据库而不是从头配一遍。如果你的使用场景不折腾自定义配置这步可以跳过。目前这套流程走下来我在 Kali 2022 上再也没因为 scan configs 的问题重装过 GVM。如果非要说一句经验之谈那就是遇到 config 相关的错先查数据库、再查 feed、最后才考虑重装顺序别搞反。