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.