I dread seeing this message: “Report outdated / end-of-life Scan Engine / Environment”
Every time I see that message, I know that I’ll be spending days trying to debug the upgrade process.
I’ve compiled OpenVAS components from source multiple times this week, but I’m stuck.
I think that my current problem is that the ospd-openvas.service hangs in ‘activating’ state for some reason. Log indicates some problem finding openvas, but it’s on the path. I don’t know what I’m doing wrong.
$ tail ospd-openvas.log
OSPD[1539] 2024-05-29 16:40:27,949: ERROR: (ospd_openvas.db) openvas executable not available. Please install openvas into your PATH.
$ openvas -V
openvas: error while loading shared libraries: libopenvas_nasl.so.23: cannot open shared object file: No such file or directory
$ ls /usr/local/lib/nasl.so.23
/usr/local/lib/libopenvas_nasl.so.23 /usr/local/lib/libopenvas_nasl.so.23.0.1
Shouldn’t the openvas install-from-source instructions say something about setting this non-standard path when installing on a vanilla Debian machine?
Using your tip, I found a way to get ospd-openvas service to go ‘active running’. Perhaps this wasn’t the best way to resolve it, but I added one line in the ospd-openvas.service file:
Environment=“LD_LIBRARY_PATH=/usr/local/lib”
Now I’ve got a new problem. Guess I should start another forum thread for that.
Thanks for the help
with the standard setup /usr/local/lib should be in the library search path on Debian and its derivatives by default. When I checked that last time some month ago this was still the case. Not sure if something changed in the meanwhile.
Maybe Ubuntu is different in some way. My OpenVAS is running on a vanilla Debian install - without GUI. It includes the same /etc/ld.so.conf.d/libc.conf that you show in your message (above), but the service definitely wasn’t finding it until I added the Environment path in the ospd-openvas.service file. Is it possible that the path isn’t loaded by Debian because I don’t have a GUI installed?