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…
You can try to move data from this location and try the sync once again.
Hello,
could someone confirm the mechanism, when the DVMD_DATA content is downloaded, the source feed.xml is updated and the content of this file is “non changed” - same timestamp 202108091427
It seems to be that the source feed.xml is still broken.
How to initialize review on the COMUNITY source?
Thanks for any clue.
The feed.xml files are getting written by the greenbone-feed-sync script (see https://github.com/greenbone/gvmd/blob/gvmd-21.04/tools/greenbone-feed-sync.in#L253). The data from these feed.xml files gets parsed by gvmd to show the feed information (see https://github.com/greenbone/gvmd/blob/gvmd-21.04/src/gmp.c#L12516).
3 Likes
FYI, it appears that there was a recent GVMD_DATA update. My feed status jumped from 41 days old to 4 this morning. This is a good time to recheck your feed status.
Thanks,
Can confirm, that the GVMD_DATA “version” timestamp presented in feed.xml was changed.
Seems to be solved.
Thanks @unretired for his point.
1 Like
Thats right the timestamp changed to “20210917T0825”.
But in my case it changed by running this command manually: su -c “rsync -vrP rsync://feed.community.greenbone.net:/data-objects/gvmd/ /var/lib/gvm/data-objects/gvmd” gvm
By running the following command nothing happens.
su -c “greenbone-feed-sync --type GVMD_DATA” gvm
And i have still no data in my GSA…
Hi,
share please the output of the sync su -c “greenbone-feed-sync --type GVMD_DATA” gvm
what is really happend?
1 Like
Hi,
Using the GVM-Docker from Secure-Compliance, I do have exactly the same problem, GVMD_DATA are locally present, but not shown on WebUI
bash-5.1# ls -l /var/lib/gvm/data-objects/gvmd/21.04/port_lists
total 372
-rw-r–r-- 1 gvm gvm 125164 Jan 1 1970 all-iana-assigned-tcp-33d0cd82-57c6-11e1-8ed1-406186ea4fc5.xml
-rw-r–r-- 1 gvm gvm 240545 Jan 1 1970 all-iana-assigned-tcp-and-udp-4a4717fe-57d2-11e1-9a26-406186ea4fc5.xml
-rw-r–r-- 1 gvm gvm 10268 Jan 1 1970 all-tcp-and-nmap-top-100-udp-730ef368-57e2-11e1-a90f-406186ea4fc5.xml
this is for ports, but same problem for report formats and policies.
It looks like GSA is searching for GVMD_DATA at the wrong place.
I found another GVMD with similar structure at /var/lib/gvm/gvmd and tried to copy data into it but it doesn’t work… i didn’t find a way to verify (like an environment variable) where GSA is supposed to find GVMD_DATA…
I have the same problem.
Тhis happened after the transition from postgresql 13 to postgresql 14.
GVM_DATA are no visible in GSA.doc (197.5 KB)
Hi @svg64,
I have faced that issue and solved it. Follow this link upgrade Postgresql 13 to 14 and see step by step how to solve.
Best
1 Like
I applied the steps suggested in the link. Everything works perfectly. Thanks.
2 Likes