企业官网建设流程全解析

这段时间在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的数据库，会发现这些配置根本不是简单的仪表盘选项，而是一条一条结构化存储的策略数据，里面有具体的插件选择规则、扫描顺序、超时策略、认证尝试规则、依赖关系等等。

简单说，当你在页面里选了一个Config，GVM的调度器会根据这个Config去决定何时加载哪些NVT（Network 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版本开始，默认变成了GVM（Greenbone Vulnerability Management），底层从OpenVAS 9迁移到了GVM 20.08+这套架构。新版虽然命令行还保留了一些openvas开头的命令，比如openvas-nvt-sync，但整体架构已经是GVM了。

如果你在网上搜到的教程还在用老版本OpenVAS的命令和路径，在你新系统的GVM上可能根本不管用。判断方法很简单：在终端里输入gvmd --version，如果正常输出版本号，说明你用的是GVM；如果提示命令不存在，那就走老OpenVAS的思路。我这篇文章所有命令，都默认你是新版GVM环境。

还有就是，Kali的滚动更新模式导致一个很蛋疼的问题：apt upgrade的时候，GVM的各个组件可能不是同步升级的。有时候gvmd升了，但gsa（Greenbone Security Assistant，Web前端）还是旧版，或者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"

如果数字持续上涨，说明同步还在进行。如果数字纹丝不动超过十分钟，大概率是卡住了，按Ctrl+C中断，重新执行一次同步命令。已下载的插件文件支持断点续传，重复执行不会重复下载已经存在的文件，这点不用担心。

4. “scan config error”的常见报错与逐项排查

4.1 那些常见的报错内容和含义

我在各种环境里收集到的报错大概有这几种形式：

遇到这些报错，不用急着到处搜，先对照意思判断是数据缺失还是权限问题。凡是跟“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 我的一个真实案例：磁盘爆满导致扫描配置写入失败

分享一个迷惑性很强的场景。有段时间怎么重建数据库、怎么重新同步Feed，Scan 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.log：gvmd主进程日志，配置读取失败通常在这里有明确记录。
• /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同步完整、数据库结构干净、服务权限正确，它自然会出现在那里。以后遇到类似问题，先按这个思路排查，基本上能少走很多弯路。