I’ve recently installed gvm via the Greenbone Vulnerability Management : Mohammad Razavi, which may be the problem. But all is set up well and have been able to run succesful tests, today i ran on end to end, then tried to configure a second (both just one host) and it failed with “Scan returned no results”, so i decided to try the one that just succeeded and it failed with the same reason “Scan returned no results”. There is nothing in the gvmd.log(other than requested start, started) or openvas.log.
Actually all of the versions are in this PPA. I realize you don’t support custom installs, but this has successfully scanned about 10 hosts and then occasionally fails. Once it fails once it seems to continue to do so. I’m looking for additional debug options i can enable. I’ve already set log_level = 128 for openvas. I’ve tried stopping and starting all services, plus a reboot and then waited for gvmd to complete updating caches.
Any advice is greatly appreciated. I have looked at the other questions about this error, but they all see to have different reasons.
This may provide a clue, i’ll start to run it down
2019-11-20 22:31:55.419 UTC [2414] 2@gvmd LOG: provided user name (2) and authenticated user name (postgres) do not match
2019-11-20 22:31:55.419 UTC [2414] 2@gvmd FATAL: Peer authentication failed for user “2”
2019-11-20 22:31:55.419 UTC [2414] 2@gvmd DETAIL: Connection matched pg_hba.conf line 90: “local all all peer”
From the text shown while creating a new topic in the “Vulnerability Tests” category:
Use this category for all topics (General discussion of results, reporting of false positive / negative results, VT development) around vulnerability tests (the so called “NASL scripts”).
Please chose a different/better fitting category for all topics related to GVM (Installation, Usage, Configuration, Scanning).
Moving into the better fitting GSE category accordingly.
Update - I have narrowed it down to a seemingly, unfortunate, silent failure after installing other base software on this instance. I had installed gvm first then our base software was installed using saltstack, something seems to have clashed. Reinstalling after the rest of the server was set up, followed by some cleanup that apt didn’t take care of has seemed to resolve it. Hopefully when time allows i can find the actual culprit.
I’ve tracked this down to a conflict in python redis versions, which is likely why ospd-scanner should run in a virtualenv. While 3.0 is required the service will start and then fail to scan b/c it can’t set the redis context. This was/is the order of installation issue since a library that we use has a dependency on redis and it installs the latest 2.X ospd-openvas can no longer properly read from redis.
Hopefully this helps someone else. Hopefully i can put a PR together that will refuse to start if python-redis 2.X is installed.
So the package you (and others in this forum) got is missing some “depends-on” and “conflicts-with” information.
A test and debug message about the wrong python-redis version is good indeed.
Thank you for your efforts.
Digging a bit in order to find clues if bug reports have been filed upstream for the instructions you used, I found a link to this repository:
It might give some clues for how the result of said instructions are meant to be deployed.
It might also help to build a container from the GSE oneself.
Didn’t look much deeper into it, though.