cfi
January 20, 2020, 7:24am
11
While i never have seen the behavior of the first screenshot i can say that the behavior of the second screenshot was a bug in the manager code (See Php nvt 2018 error - Greenbone Community Edition - Greenbone Community Forum ) which might be even responsible for the behavior on the first screenshot and which got fixed nearly one year ago with:
greenbone:gvmd-8.0 ← mattmundell:flag-nvti-cache-update-later-8.0
opened 03:01PM - 16 Mar 19 UTC
The nvti_cache is Manager's internal memory cache of NVT info. Previously the N… VT
update process was flagging the nvti_cache for update in set_nvts_feed_version.
However, this happens at the end of the OTP plugins, before the OTP preferences
are received. This meant that the main process could update its nvti_cache
after the NVT update process had cleared the nvt_preferences table but before
the process had filled the table with the new preferences.
The result was an empty nvti_cache in the main process, which was causing scan
results to be recorded with incorrect information, like all having a 75% QOD.
Now the nvti_cache is flagged for update after the nvt_preferences table has been
updated.
Kali seems to be shipping GVM-9 (based on the posted component versions) which has already reached its end-of-life (See GVM-9 (end-of-life, initial release 2017-03-07) - Greenbone Community Edition - Greenbone Community Forum ), that’s probably the reason why Lukas has redirected you to the Kali maintainers to get a updated versions of GVM which should solve all known issues.
2 Likes