I ran into the same thing. I missed a step in this doc. My fault, not the doc’s.
Check to make sure you should have a file named /etc/ld.so.conf.d/gvm.conf with a line in it that reads “/opt/gvm/lib”. Then run “ldconfig” as root, and this issue should go away.
I ran into issues here as well. It turns out that one of the feed update processes left a lock file in /opt/gvm/var/run/ and this causes ospd to not finish startup. In fact, it doesn’t even create the unix socket file until all the feed updates are finished. In my case, the lock file was stale, so I manually removed it, and ospd finished startup. I re-ran the gvmd --modify-scanner and gvmd --verify-scanner steps and they worked after that.
Managed to get most of this scripted and working but OSPD fails to stay up for longer than 25 seconds with the error “OSPD - openvas: ERROR: (ospd_openvas.db) Redis Error: Not possible to connect to the kb.”
Searching the error has come up blank, anyone have any tips?
Have you verified that the Unix socket for Redis has been created and is accessible by ospd?
As indicated in the code this is a result of not being able connect to Redis via the Unix socket path. It tries 5 times with a delay of 5 seconds between attempts, which exactly correlates to that 25 second lifespan.
As you can see above, the configuration file is /opt/gvm/etc/openvas/openvas.conf. In it, you should have it configured to use /tmp/redis.sock. The Unix socket should be owned by the gvm user, and have 0770 permissions on it.
To actually check whether or not ospd is using that socket, you might want to try using strace.
I just want to note that using 0777 for the socket will create a security hole. Everybody on the system will be able to connect to redis and read e.g. scan credential data.
I added “db_address = /tmp/redis.sock” to /opt/gvm/etc/openvas/openvas.conf but I’m not getting a different error:
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: Traceback (most recent call last):
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/bin/ospd-openvas”, line 11, in
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: load_entry_point(‘ospd-openvas==1.0.1’, ‘console_scripts’, ‘ospd-openvas’)()
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/lib/python3.6/site-packages/ospd_openvas-1.0.1-py3.6.egg/ospd_openvas/daemon.py”, line 1670, in main
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/lib/python3.6/site-packages/ospd-2.0.1-py3.6.egg/ospd/main.py”, line 157, in main
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/lib/python3.6/site-packages/ospd_openvas-1.0.1-py3.6.egg/ospd_openvas/daemon.py”, line 285, in init
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/lib/python3.6/site-packages/ospd_openvas-1.0.1-py3.6.egg/ospd_openvas/db.py”, line 139, in db_init
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/lib/python3.6/site-packages/ospd_openvas-1.0.1-py3.6.egg/ospd_openvas/db.py”, line 111, in get_db_connection
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: File “/opt/gvm/lib/python3.6/site-packages/ospd_openvas-1.0.1-py3.6.egg/ospd_openvas/db.py”, line 81, in _parse_openvas_db_address
Jun 11 15:55:13 test-gvm-11-vm python3[73471]: UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe2 in position 221: ordinal not in range(128)
Can you show the contents of openvas.conf here?
If you copied and pasted the Unicode quotation marks from the above instructions, that may be your issue. Your openvas.conf file should look like this:
I happened to follow the whole howto on CentOS 8.1, but I am stuck with gvmd not starting.
In /opt/gvm/var/log/gvm/gvmd.log I get the following
md main:MESSAGE:2020-06-11 18h12.05 utc:5101: Greenbone Vulnerability Manager version 9.0.1 (DB revision 221)
md manage:WARNING:2020-06-11 18h12.05 utc:5102: sql_exec_internal: PQexec failed: ERREUR: n'a pas pu accéder au fichier « /opt/gvm/lib/libgvm-pg-server » : Permission non accordée
(7)
md manage:WARNING:2020-06-11 18h12.05 utc:5102: sql_exec_internal: SQL: CREATE OR REPLACE FUNCTION hosts_contains (text, text) RETURNS boolean AS '/opt/gvm/lib/libgvm-pg-server', 'sql_hosts_contains' LANGUAGE C IMMUTABLE;
md manage:WARNING:2020-06-11 18h12.05 utc:5102: sqlv: sql_exec_internal failed
I double checked that I followed the postgres steps where I created the dba role, the postgres user gvm, the dba role, and granted the dba role to gvm. Also created the gvmd database.
So running sudo -u gvm psql gvmd gives me access to the database.
Finally got to work that out. Simpler than I thought… the lib directory had 700 rights.
A little chmod 755 /opt/gvm/lib later gvmd started to run.
Btw, the documentation states that xml_split makes SCAP data sync faster.
On CentOS 8, the command dnf install perl-XML-Twig will install it, and gvmd will make use of xml_split then.
This makes me want to build an Ansible playbook for it. Who’s down?
I’m sure the proper approach would be to build packages and deploy them that way… but hey… whatever works.
I also had this same error using the same lines. I don’t know for you, but I couldn’t launch the Web UI as well. The rest of the guide went smoothly tough.