这段时间在Kali Linux上折腾openvas/gvm估计不少人跟我一样装完之后打开Web界面看着Dashboard上的漏洞数据挺正常结果准备建一个扫描任务发现Scan Configs列表居然是空的。要么就是新建任务的时候选择配置直接弹个“scan config error”的报错后面跟着一串看不懂的ID。这个坑我在好几个环境里都踩到过网上零散的资料也有但多数只说“重装一下”不说为什么。这篇文章把我这几次实际排查、修复的过程完整记录下来从原理到操作一步步讲清楚。先说结论这不是你操作有问题也不是GVM本身坏了绝大多数情况是扫描配置数据的同步、初始化环节出了岔子或者GVM的组件之间版本、权限、数据库状态不一致。这篇文章适合刚在Kali上装完GVM、遇到Scan Configs为空或报错的人也适合升级之后莫名其妙配置消失的老用户。内容会有一点长但对症下药按顺序排查下来基本都能解决。1. 先搞清楚Scan Configs在GVM里到底是什么角色1.1 它不只是“扫描模板”这么简单很多人以为Scan Configs就是一组扫描参数预设选一个“Full and fast”就完事了。但如果你直接用命令行去看GVM的数据库会发现这些配置根本不是简单的仪表盘选项而是一条一条结构化存储的策略数据里面有具体的插件选择规则、扫描顺序、超时策略、认证尝试规则、依赖关系等等。简单说当你在页面里选了一个ConfigGVM的调度器会根据这个Config去决定何时加载哪些NVTNetwork Vulnerability Test网络漏洞测试插件以什么强度去探测目标哪些插件在什么条件下跳过。举个例子默认的“Full and fast”并不是把几千个插件全跑一遍而是在保证覆盖率的前提下尽量跳过慢速的、被其他插件覆盖过的检测逻辑。这套取舍规则全部挂在扫描配置的元数据里。所以Scan Configs缺失表面上是下拉列表空了实质上是GVM的配置数据库里没有初始化好这些策略数据。这个问题如果硬着头皮用API手动去创建扫描任务往往会报配置ID不存在或者直接卡在队列里不动。1.2 配置数据从哪来不是自带的是Feed“喂”出来的GVM这套东西跟普通软件不太一样。它的漏洞库、策略模板、告警规则这些内容数据全部依赖外部Feed源定期同步。在Kali里GVM的安装包里确实自带了程序文件但扫描配置、插件数据、CERT数据、SCAP数据都是安装结束之后通过网络同步到本地的。整个同步链路大致是NVT Feed包含各类漏洞检测插件的代码扫描配置里能选哪些插件以这个为基础。SCAP Data安全内容自动化协议数据包含CVE漏洞编号、CPE平台信息、CVSS评分等结构化数据扫描结果里的风险评级、漏洞关联信息都依赖这个。CERT Data计算机应急响应小组数据包含安全公告信息用于把扫描结果关联到具体的安全公告上。而Scan Configs本身的模板数据在同步NVT Feed的时候会一并注册到GVM的数据库中。如果你安装后从未成功同步过Feed哪怕软件本体所有组件都正常页面里也极有可能看不到任何扫描配置。1.3 空配置和“scan config error”其实是一棵藤上的瓜我们在论坛里看到两类求助一类是Scan Configs列表空白另一类是弹错。我排查过几次之后基本可以确定这两类问题底层原因高度重叠。空白大概率是Feed同步没完成配置模板数据根本没写进数据库。报错大概率是数据库里有配置记录的索引但关联的插件集、偏好设置或者其他外键数据缺失导致读取配置时校验失败。可以这样理解一个Scan Config像一张菜谱菜谱条目本身在数据库里但做菜需要的食材插件、偏好参数没进货。页面加载的时候发现食材不全直接就撂挑子了。理解了这层关系后面的修复思路就清晰了——不是去页面里找“新建配置”按钮而是把数据库里的这套配置数据完整地重建一遍。2. 安装阶段的几个关键检查项2.1 装的是OpenVAS还是GVM先分清版本这里先说个容易混淆的点。Kali在较早版本的源里默认的是OpenVAS 9那时候很多东西是perl脚本一把梭直接做初始化。但从Kali 2020版本开始默认变成了GVMGreenbone Vulnerability Management底层从OpenVAS 9迁移到了GVM 20.08这套架构。新版虽然命令行还保留了一些openvas开头的命令比如openvas-nvt-sync但整体架构已经是GVM了。如果你在网上搜到的教程还在用老版本OpenVAS的命令和路径在你新系统的GVM上可能根本不管用。判断方法很简单在终端里输入gvmd --version如果正常输出版本号说明你用的是GVM如果提示命令不存在那就走老OpenVAS的思路。我这篇文章所有命令都默认你是新版GVM环境。还有就是Kali的滚动更新模式导致一个很蛋疼的问题apt upgrade的时候GVM的各个组件可能不是同步升级的。有时候gvmd升了但gsaGreenbone Security AssistantWeb前端还是旧版或者redis的配置被更新覆盖了就会出现数据库结构对不上、扫描配置读取异常的情况。后面会专门讲这个升级坑。2.2 安装后必跑一遍gvm-setup的“三查”在Kali上装完GVM之后第一步应该跑的是sudo gvm-setup这个命令会做数据库初始化、创建用户、生成证书、执行Feed同步等一系列操作。有些教程会说Kali已经预装GVM不用跑setup但我实测下来预装环境和手动apt install gvm之后的状态不太一样预装环境有时候会跳过一些初始化步骤所以我还是建议手动执行一遍这一条命令反正不会破坏已有的扫描数据它只是确保所有组件就位。跑完之后必须再跑sudo gvm-check-setup这个命令是一个自检脚本会逐个检查GVM的各个组件状态包括PostgreSQL数据库是否存在、gvmd是否有权限连接数据库、redis是否以正确的方式运行、Feed数据是否已同步、Web前端是否可以访问等等。如果输出里有明显的“ERROR”字样可以先从这里定位问题的大方向。我遇到过一次这样的情况gvm-setup跑完后提示成功但gvm-check-setup里显示“ERROR: Your NVT collection is empty”这时候就真相大白了——NVT集合是空的那Scan Configs自然无从谈起。这里要特别注意这里的NVT collection不仅是插件文件本身还包括这些插件注册到gvmd数据库里的记录。文件存在但数据库没登记也会报empty。2.3 数据库和redis的“隐形依赖”GVM安装完之后系统里会多出一个PostgreSQL数据库实例专门给gvmd用。同时还有redis作为缓存和插件加载的临时存储。这两个服务如果没起来或者启动顺序不对就会出现一种奇怪的现象Web界面打不开但命令行工具能跑或者命令行工具能跑但Scan Configs读不出来。建议安装后先把这两个服务状态确认一下sudo systemctl status postgresql sudo systemctl status redis-server如果没启动顺手启动并设置开机自启sudo systemctl enable --now postgresql sudo systemctl enable --now redis-server有些精简教程会忽略这一步毕竟Kali默认不装桌面服务管理器的时候systemd的服务未必都拉起。我见过好几个例子gvm-setup反复失败最后发现是PostgreSQL根本没起来。这一步的成本极低两分钟就能确认建议别跳过。3. 核心实操把Scan Configs完整恢复出来3.1 恢复前先备份数据库避免二次伤害在动手清数据库之前建议先把gvmd的数据库备份一下。别觉得多此一举我见过有人直接删库重来结果之前手工建的扫描任务、用户账号、报告全部没了等于清零重头再来。备份用pg_dump指定gvmd的数据库名。默认数据库名一般是gvmd用户是gvmd可以通过这样验证sudo -u postgres psql -c \l | grep gvmd确认后执行备份sudo -u postgres pg_dump gvmd ~/gvmd_backup_$(date %F).sql这个备份文件并不大通常几百MB以内占不了多少空间但出问题时能救一命。3.2 标准修复流程三连重启不如一次重置很多教程推荐的“重启服务三连”——把postgresql、redis、gvmd依次restart一遍有时候确实能解决一些临时状态异常比如redis缓存里的脏数据导致读取配置失败。但如果你的问题跟Feed同步缺失有关重启服务解决不了根本问题。我实测下来比较有效的标准流程是这样的第一步重启依赖服务并杀掉残留进程sudo systemctl restart postgresql sudo systemctl restart redis-server sudo pkill -f gvmd sudo pkill -f ospd-openvas这里为什么要pkill因为GVM的gvmd进程如果处于异常状态systemctl restart有时候会超时或者起了一个新进程但旧进程还占着数据库连接导致新进程启动失败形成僵尸对峙。直接杀掉再重启更干净。第二步清理gvmd数据库让它重新初始化sudo -u postgres dropdb gvmd sudo -u postgres createdb gvmd删除后重新创建等于是把数据库恢复出厂状态。如果你刚才备份了这里就不用太纠结。第三步重新初始化数据库sudo runuser -u _gvm -- gvmd --migrate这一步会把GVM的schema结构从零建好。然后同步一次数据sudo greenbone-nvt-sync sudo greenbone-certdata-sync sudo greenbone-scapdata-sync这三条命令是手动同步Feed。正常来说同步NVT Feed需要一段时间因为插件包比较大取决于网络环境。同步完成后再执行sudo gvmd --rebuild-gvmdb这条命令会基于刚同步的NVT、SCAP、CERT数据重建GVM的数据库索引。这一步很关键扫描配置的模板数据会被注册进去Scan Configs列表的重大恢复点就在这里。最后重新创建管理员用户并启动服务sudo runuser -u _gvm -- gvmd --create-user admin --password你的密码 sudo systemctl restart gvmd sudo systemctl restart ospd-openvas如果一切顺利再执行一遍sudo gvm-check-setup确认没有ERROR然后打开Web界面刷新Scan Configs里应该能看到默认的那几个选项了。3.3 只用命令行恢复不依赖Web界面有人会遇到Web界面都打不开的情况这时候也能恢复Scan Configs不用非得等前端修复。上述第二步到第四步的操作全程都在终端里完成跟Web界面没关系。但要注意如果你Web界面里已经有其他任务删数据库会把这些任务一并清掉。所以备份的重要性再强调一遍不只是为了恢复报告也是为了让你知道哪些是数据库自带的数据、哪些是你手工创建的数据分清主次再动手。3.4 Feed源慢、同步中断的问题GVM的Feed同步默认走官方源或源站CDN实际下载速度有时候很不稳定。如果你在同步过程中等了很久没反应可以开个新终端看实时大小变化确认网络确实在走数据。NVT Feed同步完成后/var/lib/gvm/plugins目录下的文件数量和大小都会显著增加我用过一个笨办法来判断是否同步完成watch -n 5 ls /var/lib/gvm/openvas/plugins | wc -l如果数字持续上涨说明同步还在进行。如果数字纹丝不动超过十分钟大概率是卡住了按CtrlC中断重新执行一次同步命令。已下载的插件文件支持断点续传重复执行不会重复下载已经存在的文件这点不用担心。4. “scan config error”的常见报错与逐项排查4.1 那些常见的报错内容和含义我在各种环境里收集到的报错大概有这几种形式报错关键词实际含义优先级No scan config found数据库里根本不存在可用的扫描配置高Scan config not found: xxx记录存在但关联数据缺失或ID对应不到任何配置高Could not find scan configAPI层找不到配置多为同步未完成高Permission denied while accessing config数据库权限问题或gvmd用户无权限访问相关表中Could not execute scan config扫描配置有效但执行层有问题多半是插件集缺失或超时中遇到这些报错不用急着到处搜先对照意思判断是数据缺失还是权限问题。凡是跟“not found”沾边的90%是数据没同步完整凡是跟“permission”“denied”沾边的先查用户和数据库权限。4.2 权限交叉问题一个容易被忽略的细节GVM的组件分别以不同用户运行。gvmd通常以_gvm用户运行openvas或ospd-openvas以_gvm或root分组运行redis以redis用户运行。它们之间通过Unix Socket通信而这个Socket文件的属主和权限直接决定了组件之间能不能互相读写数据。最常见的权限错误场景是这样的你都按教程执行了收尾时openvas扫描一遍发现Scan Configs虽然能选了但扫描任务运行后立刻失败日志里出现redis报错。去查/var/log/gvm/ospd-openvas.log发现是redis socket连接被拒。解决方法是确认redis配置文件里的socket路径和GVM预期的路径一致并保证gvmd用户有权限访问sudo -u _gvm redis-cli -s /var/run/redis/redis-server.sock ping如果返回PONG说明socket访问正常。如果不通去/etc/redis/redis.conf里检查unixsocket相关配置改完重启redis。4.3 数据库版本迁移引发的配置丢失升级GVM版本后gvmd的数据库结构可能需要迁移。正常情况下gvmd --migrate会自动处理但如果升级中途断电、软件包解压失败或者PostgreSQL版本升级后导致gvmd无法连接就会出现Scan Configs列表空白或读取失败的循环报错。这种情况的典型特征是sudo gvm-check-setup输出里出现与数据库版本相关的ERROR。处理思路不是直接删库重建而是先尝试完整执行一次数据库迁移sudo runuser -u _gvm -- gvmd --migrate sudo gvm-check-setup如果迁移失败再考虑把gvmd数据库降级到之前版本恢复或者按第3节的流程重建。4.4 我的一个真实案例磁盘爆满导致扫描配置写入失败分享一个迷惑性很强的场景。有段时间怎么重建数据库、怎么重新同步FeedScan Configs都还是空的但gvm-check-setup只报了磁盘空间不足的WARNING我当时没在意。后来排查了很久才发现是/var/lib/gvm所在分区满了Feed数据一直在写临时文件最终没落盘数据库里自然就没有对应的配置记录。GVM的Feed数据体积不小NVT插件解压后动辄几个GB如果Kali安装在默认的虚拟磁盘里尤其是不小心分配给根分区只有20GB时很容易被塞满。判断方法很简单df -h /var/lib/gvm如果Used超过90%先清理一下系统、扩充磁盘或者给GVM目录换个存储位置再回来做同步。这里提醒一下同步Feed之前先看磁盘空间检查完再同步否则白等半小时同步完发现写不进去心态容易崩。5. 围绕“扫描配置”的几条实操心得5.1 不要一上来就试高危的“全量扫描”配置GVM默认带了不少扫描配置有些是轻量级的Discovery、Host Discovery有些是重量级的Full and fast。我在恢复完Scan Configs之后第一次建扫描任务时习惯先用一个轻量配置验证链路通不通比如先用Discovery配置扫一下自己本机的回环地址确认任务能正常执行、报告能正常生成。等整套链路验证没问题再上Full and fast去扫真实目标。原因很简单如果任务队列里塞了几个大配置的扫描任务GVM计算引擎的资源占用会很高尤其是内存和CPU。万一配置本身有问题任务跑起来以后报错排查起来牵扯面太大。小配置先跑通相当于一个冒烟测试能快速定位问题出在GVM自身还是后面的扫描配置上。5.2 手动改配置前的备份习惯如果你习惯了在GVM里自定义扫描配置比如调整插件特定偏好、修改超时时间建议先复制一份默认配置再改。GVM的配置修改不像普通软件的选项开关它改动的是数据库里NVT偏好设置和插件规则的一组映射关系。改坏了想恢复原状没有“还原默认值”按钮只能重新导入默认配置数据。我自己的做法是每次手动修改前先在Web界面里导出配置备份或者在数据库层面针对cve、config相关的表做一次pg_dump。倒不是说一定会出问题但GVM配置项关联的数据表不少一个值写错后面调了很久才发现源头那时候回滚的成本就高了。5.3 升级前留出时间别在生产环境上滚更新Kali的滚动更新模式对GVM这种组件多、依赖复杂的应用来说真的是双刃剑。升级内核和桌面工具一般影响不大但升级到GVM新版本时Greenbone官方也不保证旧数据库一定平滑迁移。如果这台机器是你日常在用甚至承载着长期扫描任务务必先备份好gvmd数据库并且准备好回滚方案比如把Kali的源固定到某个稳定快照。我踩过坑之后现在升级前固定做三件事备份/var/lib/gvm整个目录包含了插件和Feed数据。备份gvmd数据库。记下当前版本号方便出问题后知道回退到哪个版本。这三件事做完升级翻车的概率能降一大半。如果不做备份直接升级遇到Scan Configs全丢就只能按第3节的流程重建费时费力还不一定能找回历史报告。6. 写在最后的几个实用小技巧6.1 用命令行直查配置列表如果你不确定Web界面显示的Scan Configs是否完整可以直接用命令行查sudo runuser -u _gvm -- gvmd --get-configs这个命令会输出所有扫描配置的ID、名称和描述。如果这里输出为空那基本可以断定数据库里没有配置数据不必在Web界面里反复刷新浪费时间。如果这里有数据但Web界面里看不到重点排查Web前端的权限设置和用户角色而不是数据库问题。6.2 用日志来定位报错根因GVM的日志分布在几个地方排查Scan Configs相关问题最有用的是/var/log/gvm/gvmd.loggvmd主进程日志配置读取失败通常在这里有明确记录。/var/log/gvm/ospd-openvas.log扫描任务执行层的日志任务启动失败、插件加载异常会记录在这里。遇到报错别只看错误提示那一行往上翻几十行看错误出现之前的上下文。很多时候是Feed同步的后台进程还没结束你手动建的扫描任务先启动了配置读取时撞上尚未完成写入的数据库记录最终报了“Not found”。等同步彻底结束再试一次任务问题可能自己就消失了。6.3 别把所有问题都归到一个命令上最后说点个人体会。GVM这套系统像一辆拼装车PostgreSQL是底盘redis是火花塞NVT Feed是汽油gvmd是发动机电脑Web前端是仪表盘。任何一个环节出问题最终表象都可能是“扫描配置不工作”但原因千差万别。我前前后后修复过几次最大的感触是先跑一遍gvm-check-setup把输出从头到尾读一遍比翻十篇帖子都管用。它会把所有组件的健康状态列出来哪里有ERROR就往哪个方向深挖而不是在地毯式搜索里消耗时间。如果你是刚接触GVM的小白别急着把整个平台的机制全部搞懂再动手先把这篇文章里的检查命令从头到尾跑一遍大概率能直接解决问题。等你解决完这个问题再回头去研究NVT、SCAP、CERT这些数据怎么流转会轻松很多。我个人在实际操作中的体会是Scan Configs这东西看起来是界面里的一个列表实际上是整个GVM内容管线是否健康的晴雨表。只要Feed同步完整、数据库结构干净、服务权限正确它自然会出现在那里。以后遇到类似问题先按这个思路排查基本上能少走很多弯路。 Kali Linux下GVM Scan Configs为空或报错？从原理到修复的完整指南
这段时间在Kali Linux上折腾openvas/gvm估计不少人跟我一样装完之后打开Web界面看着Dashboard上的漏洞数据挺正常结果准备建一个扫描任务发现Scan Configs列表居然是空的。要么就是新建任务的时候选择配置直接弹个“scan config error”的报错后面跟着一串看不懂的ID。这个坑我在好几个环境里都踩到过网上零散的资料也有但多数只说“重装一下”不说为什么。这篇文章把我这几次实际排查、修复的过程完整记录下来从原理到操作一步步讲清楚。先说结论这不是你操作有问题也不是GVM本身坏了绝大多数情况是扫描配置数据的同步、初始化环节出了岔子或者GVM的组件之间版本、权限、数据库状态不一致。这篇文章适合刚在Kali上装完GVM、遇到Scan Configs为空或报错的人也适合升级之后莫名其妙配置消失的老用户。内容会有一点长但对症下药按顺序排查下来基本都能解决。1. 先搞清楚Scan Configs在GVM里到底是什么角色1.1 它不只是“扫描模板”这么简单很多人以为Scan Configs就是一组扫描参数预设选一个“Full and fast”就完事了。但如果你直接用命令行去看GVM的数据库会发现这些配置根本不是简单的仪表盘选项而是一条一条结构化存储的策略数据里面有具体的插件选择规则、扫描顺序、超时策略、认证尝试规则、依赖关系等等。简单说当你在页面里选了一个ConfigGVM的调度器会根据这个Config去决定何时加载哪些NVTNetwork Vulnerability Test网络漏洞测试插件以什么强度去探测目标哪些插件在什么条件下跳过。举个例子默认的“Full and fast”并不是把几千个插件全跑一遍而是在保证覆盖率的前提下尽量跳过慢速的、被其他插件覆盖过的检测逻辑。这套取舍规则全部挂在扫描配置的元数据里。所以Scan Configs缺失表面上是下拉列表空了实质上是GVM的配置数据库里没有初始化好这些策略数据。这个问题如果硬着头皮用API手动去创建扫描任务往往会报配置ID不存在或者直接卡在队列里不动。1.2 配置数据从哪来不是自带的是Feed“喂”出来的GVM这套东西跟普通软件不太一样。它的漏洞库、策略模板、告警规则这些内容数据全部依赖外部Feed源定期同步。在Kali里GVM的安装包里确实自带了程序文件但扫描配置、插件数据、CERT数据、SCAP数据都是安装结束之后通过网络同步到本地的。整个同步链路大致是NVT Feed包含各类漏洞检测插件的代码扫描配置里能选哪些插件以这个为基础。SCAP Data安全内容自动化协议数据包含CVE漏洞编号、CPE平台信息、CVSS评分等结构化数据扫描结果里的风险评级、漏洞关联信息都依赖这个。CERT Data计算机应急响应小组数据包含安全公告信息用于把扫描结果关联到具体的安全公告上。而Scan Configs本身的模板数据在同步NVT Feed的时候会一并注册到GVM的数据库中。如果你安装后从未成功同步过Feed哪怕软件本体所有组件都正常页面里也极有可能看不到任何扫描配置。1.3 空配置和“scan config error”其实是一棵藤上的瓜我们在论坛里看到两类求助一类是Scan Configs列表空白另一类是弹错。我排查过几次之后基本可以确定这两类问题底层原因高度重叠。空白大概率是Feed同步没完成配置模板数据根本没写进数据库。报错大概率是数据库里有配置记录的索引但关联的插件集、偏好设置或者其他外键数据缺失导致读取配置时校验失败。可以这样理解一个Scan Config像一张菜谱菜谱条目本身在数据库里但做菜需要的食材插件、偏好参数没进货。页面加载的时候发现食材不全直接就撂挑子了。理解了这层关系后面的修复思路就清晰了——不是去页面里找“新建配置”按钮而是把数据库里的这套配置数据完整地重建一遍。2. 安装阶段的几个关键检查项2.1 装的是OpenVAS还是GVM先分清版本这里先说个容易混淆的点。Kali在较早版本的源里默认的是OpenVAS 9那时候很多东西是perl脚本一把梭直接做初始化。但从Kali 2020版本开始默认变成了GVMGreenbone Vulnerability Management底层从OpenVAS 9迁移到了GVM 20.08这套架构。新版虽然命令行还保留了一些openvas开头的命令比如openvas-nvt-sync但整体架构已经是GVM了。如果你在网上搜到的教程还在用老版本OpenVAS的命令和路径在你新系统的GVM上可能根本不管用。判断方法很简单在终端里输入gvmd --version如果正常输出版本号说明你用的是GVM如果提示命令不存在那就走老OpenVAS的思路。我这篇文章所有命令都默认你是新版GVM环境。还有就是Kali的滚动更新模式导致一个很蛋疼的问题apt upgrade的时候GVM的各个组件可能不是同步升级的。有时候gvmd升了但gsaGreenbone Security AssistantWeb前端还是旧版或者redis的配置被更新覆盖了就会出现数据库结构对不上、扫描配置读取异常的情况。后面会专门讲这个升级坑。2.2 安装后必跑一遍gvm-setup的“三查”在Kali上装完GVM之后第一步应该跑的是sudo gvm-setup这个命令会做数据库初始化、创建用户、生成证书、执行Feed同步等一系列操作。有些教程会说Kali已经预装GVM不用跑setup但我实测下来预装环境和手动apt install gvm之后的状态不太一样预装环境有时候会跳过一些初始化步骤所以我还是建议手动执行一遍这一条命令反正不会破坏已有的扫描数据它只是确保所有组件就位。跑完之后必须再跑sudo gvm-check-setup这个命令是一个自检脚本会逐个检查GVM的各个组件状态包括PostgreSQL数据库是否存在、gvmd是否有权限连接数据库、redis是否以正确的方式运行、Feed数据是否已同步、Web前端是否可以访问等等。如果输出里有明显的“ERROR”字样可以先从这里定位问题的大方向。我遇到过一次这样的情况gvm-setup跑完后提示成功但gvm-check-setup里显示“ERROR: Your NVT collection is empty”这时候就真相大白了——NVT集合是空的那Scan Configs自然无从谈起。这里要特别注意这里的NVT collection不仅是插件文件本身还包括这些插件注册到gvmd数据库里的记录。文件存在但数据库没登记也会报empty。2.3 数据库和redis的“隐形依赖”GVM安装完之后系统里会多出一个PostgreSQL数据库实例专门给gvmd用。同时还有redis作为缓存和插件加载的临时存储。这两个服务如果没起来或者启动顺序不对就会出现一种奇怪的现象Web界面打不开但命令行工具能跑或者命令行工具能跑但Scan Configs读不出来。建议安装后先把这两个服务状态确认一下sudo systemctl status postgresql sudo systemctl status redis-server如果没启动顺手启动并设置开机自启sudo systemctl enable --now postgresql sudo systemctl enable --now redis-server有些精简教程会忽略这一步毕竟Kali默认不装桌面服务管理器的时候systemd的服务未必都拉起。我见过好几个例子gvm-setup反复失败最后发现是PostgreSQL根本没起来。这一步的成本极低两分钟就能确认建议别跳过。3. 核心实操把Scan Configs完整恢复出来3.1 恢复前先备份数据库避免二次伤害在动手清数据库之前建议先把gvmd的数据库备份一下。别觉得多此一举我见过有人直接删库重来结果之前手工建的扫描任务、用户账号、报告全部没了等于清零重头再来。备份用pg_dump指定gvmd的数据库名。默认数据库名一般是gvmd用户是gvmd可以通过这样验证sudo -u postgres psql -c \l | grep gvmd确认后执行备份sudo -u postgres pg_dump gvmd ~/gvmd_backup_$(date %F).sql这个备份文件并不大通常几百MB以内占不了多少空间但出问题时能救一命。3.2 标准修复流程三连重启不如一次重置很多教程推荐的“重启服务三连”——把postgresql、redis、gvmd依次restart一遍有时候确实能解决一些临时状态异常比如redis缓存里的脏数据导致读取配置失败。但如果你的问题跟Feed同步缺失有关重启服务解决不了根本问题。我实测下来比较有效的标准流程是这样的第一步重启依赖服务并杀掉残留进程sudo systemctl restart postgresql sudo systemctl restart redis-server sudo pkill -f gvmd sudo pkill -f ospd-openvas这里为什么要pkill因为GVM的gvmd进程如果处于异常状态systemctl restart有时候会超时或者起了一个新进程但旧进程还占着数据库连接导致新进程启动失败形成僵尸对峙。直接杀掉再重启更干净。第二步清理gvmd数据库让它重新初始化sudo -u postgres dropdb gvmd sudo -u postgres createdb gvmd删除后重新创建等于是把数据库恢复出厂状态。如果你刚才备份了这里就不用太纠结。第三步重新初始化数据库sudo runuser -u _gvm -- gvmd --migrate这一步会把GVM的schema结构从零建好。然后同步一次数据sudo greenbone-nvt-sync sudo greenbone-certdata-sync sudo greenbone-scapdata-sync这三条命令是手动同步Feed。正常来说同步NVT Feed需要一段时间因为插件包比较大取决于网络环境。同步完成后再执行sudo gvmd --rebuild-gvmdb这条命令会基于刚同步的NVT、SCAP、CERT数据重建GVM的数据库索引。这一步很关键扫描配置的模板数据会被注册进去Scan Configs列表的重大恢复点就在这里。最后重新创建管理员用户并启动服务sudo runuser -u _gvm -- gvmd --create-user admin --password你的密码 sudo systemctl restart gvmd sudo systemctl restart ospd-openvas如果一切顺利再执行一遍sudo gvm-check-setup确认没有ERROR然后打开Web界面刷新Scan Configs里应该能看到默认的那几个选项了。3.3 只用命令行恢复不依赖Web界面有人会遇到Web界面都打不开的情况这时候也能恢复Scan Configs不用非得等前端修复。上述第二步到第四步的操作全程都在终端里完成跟Web界面没关系。但要注意如果你Web界面里已经有其他任务删数据库会把这些任务一并清掉。所以备份的重要性再强调一遍不只是为了恢复报告也是为了让你知道哪些是数据库自带的数据、哪些是你手工创建的数据分清主次再动手。3.4 Feed源慢、同步中断的问题GVM的Feed同步默认走官方源或源站CDN实际下载速度有时候很不稳定。如果你在同步过程中等了很久没反应可以开个新终端看实时大小变化确认网络确实在走数据。NVT Feed同步完成后/var/lib/gvm/plugins目录下的文件数量和大小都会显著增加我用过一个笨办法来判断是否同步完成watch -n 5 ls /var/lib/gvm/openvas/plugins | wc -l如果数字持续上涨说明同步还在进行。如果数字纹丝不动超过十分钟大概率是卡住了按CtrlC中断重新执行一次同步命令。已下载的插件文件支持断点续传重复执行不会重复下载已经存在的文件这点不用担心。4. “scan config error”的常见报错与逐项排查4.1 那些常见的报错内容和含义我在各种环境里收集到的报错大概有这几种形式报错关键词实际含义优先级No scan config found数据库里根本不存在可用的扫描配置高Scan config not found: xxx记录存在但关联数据缺失或ID对应不到任何配置高Could not find scan configAPI层找不到配置多为同步未完成高Permission denied while accessing config数据库权限问题或gvmd用户无权限访问相关表中Could not execute scan config扫描配置有效但执行层有问题多半是插件集缺失或超时中遇到这些报错不用急着到处搜先对照意思判断是数据缺失还是权限问题。凡是跟“not found”沾边的90%是数据没同步完整凡是跟“permission”“denied”沾边的先查用户和数据库权限。4.2 权限交叉问题一个容易被忽略的细节GVM的组件分别以不同用户运行。gvmd通常以_gvm用户运行openvas或ospd-openvas以_gvm或root分组运行redis以redis用户运行。它们之间通过Unix Socket通信而这个Socket文件的属主和权限直接决定了组件之间能不能互相读写数据。最常见的权限错误场景是这样的你都按教程执行了收尾时openvas扫描一遍发现Scan Configs虽然能选了但扫描任务运行后立刻失败日志里出现redis报错。去查/var/log/gvm/ospd-openvas.log发现是redis socket连接被拒。解决方法是确认redis配置文件里的socket路径和GVM预期的路径一致并保证gvmd用户有权限访问sudo -u _gvm redis-cli -s /var/run/redis/redis-server.sock ping如果返回PONG说明socket访问正常。如果不通去/etc/redis/redis.conf里检查unixsocket相关配置改完重启redis。4.3 数据库版本迁移引发的配置丢失升级GVM版本后gvmd的数据库结构可能需要迁移。正常情况下gvmd --migrate会自动处理但如果升级中途断电、软件包解压失败或者PostgreSQL版本升级后导致gvmd无法连接就会出现Scan Configs列表空白或读取失败的循环报错。这种情况的典型特征是sudo gvm-check-setup输出里出现与数据库版本相关的ERROR。处理思路不是直接删库重建而是先尝试完整执行一次数据库迁移sudo runuser -u _gvm -- gvmd --migrate sudo gvm-check-setup如果迁移失败再考虑把gvmd数据库降级到之前版本恢复或者按第3节的流程重建。4.4 我的一个真实案例磁盘爆满导致扫描配置写入失败分享一个迷惑性很强的场景。有段时间怎么重建数据库、怎么重新同步FeedScan Configs都还是空的但gvm-check-setup只报了磁盘空间不足的WARNING我当时没在意。后来排查了很久才发现是/var/lib/gvm所在分区满了Feed数据一直在写临时文件最终没落盘数据库里自然就没有对应的配置记录。GVM的Feed数据体积不小NVT插件解压后动辄几个GB如果Kali安装在默认的虚拟磁盘里尤其是不小心分配给根分区只有20GB时很容易被塞满。判断方法很简单df -h /var/lib/gvm如果Used超过90%先清理一下系统、扩充磁盘或者给GVM目录换个存储位置再回来做同步。这里提醒一下同步Feed之前先看磁盘空间检查完再同步否则白等半小时同步完发现写不进去心态容易崩。5. 围绕“扫描配置”的几条实操心得5.1 不要一上来就试高危的“全量扫描”配置GVM默认带了不少扫描配置有些是轻量级的Discovery、Host Discovery有些是重量级的Full and fast。我在恢复完Scan Configs之后第一次建扫描任务时习惯先用一个轻量配置验证链路通不通比如先用Discovery配置扫一下自己本机的回环地址确认任务能正常执行、报告能正常生成。等整套链路验证没问题再上Full and fast去扫真实目标。原因很简单如果任务队列里塞了几个大配置的扫描任务GVM计算引擎的资源占用会很高尤其是内存和CPU。万一配置本身有问题任务跑起来以后报错排查起来牵扯面太大。小配置先跑通相当于一个冒烟测试能快速定位问题出在GVM自身还是后面的扫描配置上。5.2 手动改配置前的备份习惯如果你习惯了在GVM里自定义扫描配置比如调整插件特定偏好、修改超时时间建议先复制一份默认配置再改。GVM的配置修改不像普通软件的选项开关它改动的是数据库里NVT偏好设置和插件规则的一组映射关系。改坏了想恢复原状没有“还原默认值”按钮只能重新导入默认配置数据。我自己的做法是每次手动修改前先在Web界面里导出配置备份或者在数据库层面针对cve、config相关的表做一次pg_dump。倒不是说一定会出问题但GVM配置项关联的数据表不少一个值写错后面调了很久才发现源头那时候回滚的成本就高了。5.3 升级前留出时间别在生产环境上滚更新Kali的滚动更新模式对GVM这种组件多、依赖复杂的应用来说真的是双刃剑。升级内核和桌面工具一般影响不大但升级到GVM新版本时Greenbone官方也不保证旧数据库一定平滑迁移。如果这台机器是你日常在用甚至承载着长期扫描任务务必先备份好gvmd数据库并且准备好回滚方案比如把Kali的源固定到某个稳定快照。我踩过坑之后现在升级前固定做三件事备份/var/lib/gvm整个目录包含了插件和Feed数据。备份gvmd数据库。记下当前版本号方便出问题后知道回退到哪个版本。这三件事做完升级翻车的概率能降一大半。如果不做备份直接升级遇到Scan Configs全丢就只能按第3节的流程重建费时费力还不一定能找回历史报告。6. 写在最后的几个实用小技巧6.1 用命令行直查配置列表如果你不确定Web界面显示的Scan Configs是否完整可以直接用命令行查sudo runuser -u _gvm -- gvmd --get-configs这个命令会输出所有扫描配置的ID、名称和描述。如果这里输出为空那基本可以断定数据库里没有配置数据不必在Web界面里反复刷新浪费时间。如果这里有数据但Web界面里看不到重点排查Web前端的权限设置和用户角色而不是数据库问题。6.2 用日志来定位报错根因GVM的日志分布在几个地方排查Scan Configs相关问题最有用的是/var/log/gvm/gvmd.loggvmd主进程日志配置读取失败通常在这里有明确记录。/var/log/gvm/ospd-openvas.log扫描任务执行层的日志任务启动失败、插件加载异常会记录在这里。遇到报错别只看错误提示那一行往上翻几十行看错误出现之前的上下文。很多时候是Feed同步的后台进程还没结束你手动建的扫描任务先启动了配置读取时撞上尚未完成写入的数据库记录最终报了“Not found”。等同步彻底结束再试一次任务问题可能自己就消失了。6.3 别把所有问题都归到一个命令上最后说点个人体会。GVM这套系统像一辆拼装车PostgreSQL是底盘redis是火花塞NVT Feed是汽油gvmd是发动机电脑Web前端是仪表盘。任何一个环节出问题最终表象都可能是“扫描配置不工作”但原因千差万别。我前前后后修复过几次最大的感触是先跑一遍gvm-check-setup把输出从头到尾读一遍比翻十篇帖子都管用。它会把所有组件的健康状态列出来哪里有ERROR就往哪个方向深挖而不是在地毯式搜索里消耗时间。如果你是刚接触GVM的小白别急着把整个平台的机制全部搞懂再动手先把这篇文章里的检查命令从头到尾跑一遍大概率能直接解决问题。等你解决完这个问题再回头去研究NVT、SCAP、CERT这些数据怎么流转会轻松很多。我个人在实际操作中的体会是Scan Configs这东西看起来是界面里的一个列表实际上是整个GVM内容管线是否健康的晴雨表。只要Feed同步完整、数据库结构干净、服务权限正确它自然会出现在那里。以后遇到类似问题先按这个思路排查基本上能少走很多弯路。