企业官网建设流程全解析

装过 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 并列，这其实是很自然的叫法。GVM（Greenbone Vulnerability Management）是 OpenVAS 的正统后续，但它早已不是一个单一程序，而是一整套组件体系。在这个体系里，真正承担“管理”职责的是gvmd（Greenbone 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/gvm

4. 恢复 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-sync

NVT 同步影响漏洞检测库，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 是个典型的单页应用，前端页面可能缓存了旧状态，所以如果页面还是空白，先强制刷新（Ctrl+Shift+R），或者换个无痕窗口再试一次，别动不动就怀疑服务没起来。

更完整的验证是创建一个真实任务，比如新建一个任务，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、最后才考虑重装，顺序别搞反。