[kinda solved] OpenVAS Scanner failed to load VTs. Command '['openvas', '--update-vt-info']' returned non-zero exit status 1

Community Containers
1

Hello,

I have found a solution, but we may need to implement an external script to check everything is synced (you will understand this at the end)

I want to mention that I’m managing all the docker containers under systemd, so I’m migrating everything to it. I have tried to stay similar to the docker-compose.yml file, only needed a workaround to get network aliases working.

It all started seeing this message:

OSPD[7] 2024-01-22 10:34:23,995: INFO: (ospd_openvas.daemon) Loading VTs. Scans will be [requested|queued] until VTs are loaded. This may take a few minutes, please wait...
OSPD[7] 2024-01-22 10:34:29,688: ERROR: (ospd_openvas.openvas) OpenVAS Scanner failed to load VTs. Command '['openvas', '--update-vt-info']' returned non-zero exit status 1.
OSPD[7] 2024-01-22 10:34:29,688: ERROR: (ospd_openvas.daemon) Updating VTs failed.

So I went into the ospd container and checked both logs (/var/log/gvm/openvas.log and /var/log/gvm/ospd-openvas.log). In /var/log/gvm/openvas.log I found:

lib  nasl:MESSAGE:2024-01-22 10h36.57 utc:34: /var/lib/openvas/plugins/plugin_feed_info.inc: Not able to open nor to locate it in include paths
lib  nasl:MESSAGE:2024-01-22 10h37.19 utc:43: /var/lib/openvas/plugins/plugin_feed_info.inc: Not able to open nor to locate it in include paths
lib  nasl:MESSAGE:2024-01-22 10h37.41 utc:48: /var/lib/openvas/plugins/plugin_feed_info.inc: Not able to open nor to locate it in include paths
lib  nasl:MESSAGE:2024-01-22 10h38.03 utc:51: /var/lib/openvas/plugins/plugin_feed_info.inc: Not able to open nor to locate it in include paths
lib  nasl:MESSAGE:2024-01-22 10h38.25 utc:55: /var/lib/openvas/plugins/plugin_feed_info.inc: Not able to open nor to locate it in include paths

So I checked the path:

root@ospd-openvas:/var/log/gvm# ls /var/lib/openvas/plugins/
21.04
22.04

Right, so I know I’m using 22.04 version and looked for that file:

root@ospd-openvas:/var/log/gvm# find /var/lib/openvas/plugins/22.04/ -type f | grep plugin_feed_info
/var/lib/openvas/plugins/22.04/vt-data/nasl/plugin_feed_info.inc

Used symbolic link:

ln -s /var/lib/openvas/plugins/22.04/vt-data/nasl/plugin_feed_info.inc /var/lib/openvas/plugins/plugin_feed_info.inc

After that the message changed, so I supposed it got solved:

lib  nasl:MESSAGE:2024-01-22 10h40.41 utc:82: network_func.inc: Not able to open nor to locate it in include paths
lib  nasl:MESSAGE:2024-01-22 10h40.41 utc:82: /var/lib/openvas/plugins/22.04/vt-data/nasl/2023/gb_rpc_portmap_service_wan_access.nasl. There were 0 parse errors.
lib  nasl:MESSAGE:2024-01-22 10h40.41 utc:82: secpod_reg.inc: Not able to open nor to locate it in include paths
lib  nasl:MESSAGE:2024-01-22 10h40.41 utc:82: /var/lib/openvas/plugins/22.04/vt-data/nasl/2023/apple/gb_apple_itunes_mult_vuln_HT213763.nasl. There were 0 parse errors.
(...)

In the end more .inc files were missing. So I thought that the content of /var/lib/openvas/plugins/22.04/vt-data/nasl/ should be under /var/lib/openvas/plugins/, and so then I “symbolic-linked” everything from the mounted volume to make it persistent:

# cd /var/lib/docker/volumes/vt_data_vol/_data
# cp -rs 22.04/vt-data/nasl/* .
  • -r: recursive because there are some .inc files inside folders and we need to keep the structure
  • -s: symbolic

After that went into the ospd container again and run the command to check it exited 0:

root@ospd-openvas:~# openvas --update-vt-info
root@ospd-openvas:~# echo $?
0

So yes, the issue is solved. I guess now I would need to implement a script to check everything is synced between /var/lib/openvas/plugins/ and /var/lib/openvas/plugins/22.04/vt-data/nasl/, or maybe I have something working wrong. In that case I would like to know to get this solved by its own!

Thank you in advance and hope this helps someone! :slight_smile:

2

After restarting seems like the vulnerability-tests container may be restoring that folder because I found this again (no symbolic links, not even broken):

# ls /var/lib/docker/volumes/vt_data_vol/_data/
21.04  22.04

So I’m going to try to implement a postexec (if its vulnerability-tests unit) or preexec (if its ospd unit) script in the systemd units.

I will update with the news

3

Hi,

for the vulnerability-tests container you need to set the desired feed. See https://github.com/greenbone/docs/blob/main/src/_static/docker-compose-22.4.yml#L2-L7

Per default all data containers (vulnerability-tests, notus-data, cert-bund-data, scap-data) copy their feed content into the /mnt directory on startup (see for example docker run --rm greenbone/vulnerability-tests cat /bin/init.sh for more details). Therefore you should use data volumes that mount to this directory as it is done in the compose file.

2 Likes
4

Hi again,

Your hint took me to the solution. It was a mistake of mine, I’ve been declaring the environment variables for the systemd service, instead of declaring them in the docker run command:

# diff -U2 openvas-vulnerability-tests.service.orig openvas-vulnerability-tests.service
--- openvas-vulnerability-tests.service.orig	2024-01-22 16:42:52.884425841 +0000
+++ openvas-vulnerability-tests.service	2024-01-22 16:42:10.032016380 +0000
@@ -9,6 +9,5 @@
 User=openvas
 EnvironmentFile=/etc/en_US.utf8
-Environment="STORAGE_PATH=/var/lib/openvas/22.04/vt-data/nasl"
-ExecStart=/usr/bin/docker run --network mynet --rm -v /var/lib/openvas/plugins:/mnt --name openvas-vulnerability-tests greenbone/vulnerability-tests
+ExecStart=/usr/bin/docker run --network mynet -e "STORAGE_PATH=/var/lib/openvas/22.04/vt-data/nasl" --rm -v /var/lib/openvas/plugins:/mnt --name openvas-vulnerability-tests greenbone/vulnerability-tests
 ExecStop=/usr/bin/docker stop --time=30 openvas-vulnerability-tests
 SuccessExitStatus=1

So this is it. After correcting this mistake for vulnerability-tests and notus-scaner (as this one also had env. variables), it all worked smoothly :slight_smile:

Thank you very much!

2 Likes