Clarifications regarding NVT cache and update

Hi,
I have some questions (more like clarifications) regarding the functioning of GVM11 NVT’s management. I am trying to grasp how gvm is working behind the scenes.

  1. Running greenbone-nvt-sync synchronizes NVT’s local postgresql db.

  2. Using openvas -u loads the plugins (which includes NVT’s) into Redis.
    This is not necessary should I run a scanner using ospd-openvas as it will do the update automatically each time a new feed is detected (I understand this new feed as being the comparison to the manager’s postgresql).

  3. We can start a manager by specifying --osp-vt-update=<scanner-socket> (Unix socket for OSP NVT update) so that when there is a new feed, the manager will send the new NVT’s (from postgres) into the scanner’s Redis. So if I want a new scanner they need to share the same socket or it won’t get updated?

  4. Every couple of seconds or so the manager spawns two processes:

gvm       11327  0.0  2.1 209216 98932 pts/3    S+   05:25   0:00 gvmd: Reloading NVTs
gvm       11330  0.0  2.2 209216 101944 pts/3   S+   05:25   0:00 gvmd: OSP: Updating NVT cache

I understand the manager is using osp through openvas-ospd and updating NVT cache on the scanner. How does this cache relate to Redis?
Also, what is the point on doing it with such high frequency, even on standby (i.e no scans running)?

  1. This is a bit unrelated but whenever postgres fails and comes back up gvmd displays the following logs:
md manage:WARNING:2019-11-26 15h14.38 utc:72795: sql_exec_internal: PQexec failed:  (7)
md manage:WARNING:2019-11-26 15h14.38 utc:72795: sql_exec_internal: SQL: BEGIN;
md manage:WARNING:2019-11-26 15h14.38 utc:72795: sqlv: sql_exec_internal failed
md manage:WARNING:2019-11-26 15h14.38 utc:72795: manage_schedule: manage_update_nvti_cache error (Perhaps the db went down?)

These logs are repeated indefinitely every 10s despite postgres being back up and GVM being able to perform scans, get reports etc. It appears to be happening with sqlite https://github.com/greenbone/gvmd/issues/347 on previous versions. Sounds like something is not being closed. I’ll take a further look this weekend but any hints are welcome.

Thank you for your attention.

1 Like

Hi @drm,

The NVT’s update is performed in the opposite direction. When greenbone-nvt-feed is run, you get the new feed and ospd-scanner stores it in Redis automatically (or you can do it manually running openvas -u). Then, gvmd asks ospd-scanner for the feed version (once each 10 seconds). In case there is a new feed, gvmd will get the new/modified NVT’s.

Regarding the point 5., unfortunately I don’t have the answer for that.

2 Likes

Thank you for the response!
So greenbone-nvt-sync downloads/syncs and stores in Redis while openvas -u by itself only loads existing plugins to Redis. I guess the manager asks ospd-scanner with 10s frequency because it needs the updated feed with some “novelty” for the interface.

Hi @jjnicola

I just finished installing openvas/gvm 11 with some help from the excellent work of falkowich at https://sadsloth.net/post/install-gvm11-src_part1/

When working within gsad, all NVT data is in place and all scans are working perfectly.

However, under GSA menu “Administration” > “Feed Status”, only the SCAP and CERT feed versions are visible, the NVT feed version is nowhere to be seen. Just the same, the NVT feed is up to date on the system as can be seen with “$ greenbone-nvt-sync --feedversion”.

Is this normal in GSA 9.0?

$ gvmd --version
Greenbone Vulnerability Manager 9.0.1~git-8973c49d-gvmd-9.0
GIT revision 8973c49d-gvmd-9.0
Manager DB revision 221

$ gsad --version
Greenbone Security Assistant 9.0.0~git-ff857b53a-gsa-9.0

$ ospd-openvas --version
OSP Server for openvas: 1.0.0
OSP: 1.2
OSPd: 2.0.0

$ openvas --version
OpenVAS 7.0.0
gvm-libs 11.0.1