Missing GVM_DATA in GSA

Hi everyone,
I got a Problem with my GVM DATA.
In /var/lib/gvm/data-objects/gvmd is all the data for 20.08, 21.04 and 21.10 and the Version is 202108091427.
But on the Web Interface is still no data… The compliance guidelines, port lists, report formats and scan configurations are empty.
It seems like the GSA don’t use this data in var/lib/gvm/data-objects/gvmd.

I did all the commands to get the data but it will not appear in the GSA.
greenbone-feed-sync --type GVMD_DATA
greenbone-feed-sync --type SCAP
greenbone-feed-sync --type CERT
# and i tried it with the rsync command too
rsync -avrP rsync://feed.community.greenbone.net:/data-objects/gvmd/ .
reboot

GVM versions

gsad: 21.4.2
gvmd: 21.4.3
openvas-scanner: 21.4.2
gvm-libs: 21.4.2

Environment

Operating system: Alpine Linux v3.14
Kernel: 5.3.18-lp152.75-default

I hope someone can help me with this issue.
Thanks!

Same issue over here …

Hmm… Maybe GSA is looking for a different path than var/lib/gvm/data-objects/gvmd

1 Like

Hi @ApiDevMarc,

Please try to use these commands instead>

1.# sudo gvm-stop
2.# sudo runuser -u _gvm – greenbone-nvt-sync --rsync

2.1#NOTE: The _gvm is the gmv’s user name, so you need to replace it with your user name you created

3.# sudo greenbone-scapdata-sync
4.# sudo greenbone-certdata-sync
5.# sudo reboot

1 Like

Thanks, but the first commands doesn’t exists.
I executed as root:

su -c "greenbone-nvt-sync --rsync" gvm
greenbone-scapdata-sync
greenbone-certdata-sync
reboot

But this makes no change… The data is still emtpy in the GSA

Hi @ApiDevMarc,

The fist command your wrote is different of the command I shared with you, this is the command I shared:
5

1 Like

Sorry, but as i already mentioned. These two commands are not available.

Same trouble here it seems.
Greenbone Community gvmd Data Feed
20210809T1427 Too old (34 days) Please check the automatic synchronization of your system.
the other feeds are current or a couple days old.

I think your issue is that the GVMD_DATA feed does regularly have new data to sync with, so the update “looks” broken. So far, it has been 35 days with no new data. just let it ride…

1 Like

Yes but in my path /var/lib/gvm/data-objects/gvmd is the data for the scan configs, port lists and report formats. The Problem is that gvmd dont load this data to the gsa…

sorry ApiDevMarc, i picked this email chain up in the middle and did not get to see the email the preceded the one that i responded to.

i’ve built and rebuilt my GVM multiple times, following everyone’s ideas of “how to make it work”, until i hit on OFFICIAL DOCUMENTATION at https://greenbone.github.io/docs/gvm-21.04/index.html#

honestly, don’t know why that is so well hidden. OFFICIAL DOCUMENTATION changed my world.

you are not currently using Kali (why not? come with cool stuff), so your script locations are different.

find the scripts. Kali 2021.3 put them here:
/usr/bin/greenbone-nvt-sync
/usr/sbin/greenbone-feed-sync
/usr/sbin/greenbone-certdata-sync
/usr/sbin/greenbone-scapdata-sync

run the scripts manually to verify they work:
sudo -u _gvm greenbone-nvt-sync
sudo -u _gvm greenbone-feed-sync --type SCAP
sudo -u _gvm greenbone-feed-sync --type CERT
sudo -u _gvm greenbone-feed-sync --type GVMD_DATA

heed the OFFICIAL DOCUMENTATION’s warning to never run the scripts as root, or you can jack up file permissions. that’s why greenbone suggested making user -gvm to do the work.

when you can manually update, add the tasks to _gvm’s cron job. be sure to space out the four tasks so that they don’t overlap.

i’m more a microsoft guy than a linux guy, but i’ve built and rebuilt about 30-40 linux servers. we are working with “free” products here; if you break your server, just delete it and make a new one. keep good notes and the rebuilds are fast.

2 Likes

Hi, it seems to be such a general problem to sync feed GVMD_DATA since version 20210809T1427

If someone is able to successfully sync GVMD_DATA after this timestamp, please share with us your “how-to”.

1 Like

Just to avoid confusion:

A “Missing GVMD_DATA” in GSA (which was reported by the OP) is something completely different then a “GVMD_DATA too old” (which now has been reported by others here mixing two different topics in one).

For the latter please see e.g. the following posts for some background info:

Thats true!
As i already mention, the syncs work on my deployment. But this data is missing in the webui. I think that gvmd don’t load this data to the postgres… So gsa has no gvm data but the right versionsnumber.

Hi,

I´m still confusing,

As is described in your first comment - GVMD_DATA synchronization from the command line

greenbone-feed-sync --type GVMD_DATA goes through, and in in path /var/lib/gvm/data-objects/gvmd/ was updated file “feed.xml” exactly to the same timestamp when the scrips is finnished and it contains:

<feed id="6315d194-4b6a-11e7-a570-28d24461215b">
<type>GVMD_DATA</type>
<name>Greenbone Community gvmd Data Feed</name>
<version>202108091427</version>
<vendor>Greenbone Networks GmbH</vendor>
<home>https://community.greenbone.net/t/about-greenbone-community-feed-gcf/1224</home>
<description>
This script synchronizes a GVMD_DATA collection with the 'Greenbone Community gvmd Data Feed'.
The 'Greenbone Community gvmd Data Feed' is provided by 'Greenbone Networks GmbH'.
Online information about this feed: 'https://community.greenbone.net/t/about-greenbone-community-feed-gcf/1224'.
</description>
</feed>

Then I changed the part <version>202108091427</version> in this file to i.e. 202109091200 the GSA immediately shows the same info in the version.

Then this is how to cheat to avoid the message, but not fixing the cause - which is a broken mechanism to write in feed.xml.

I agree with you. But what is the reason for renaming the version to “202109091200”? Just to avoid the message “Too old (38 days) Please check the automatic synchronization of your system”?
And do you have the data in your gsa? because mine is empty…
image

My data seems to be processed correctly in GSA.

You can try to move data from this location and try the sync once again.