Startup hangs on "Starting Open Scanner Protocol daemon for OpenVAS..."

Archive Greenbone Community Edition
1

I’m not being able to get it to work. If I only build opsd and opsd-openvas I get this error when starting up:

ERROR: Not possible to get the installed gvm-libs version. Outdated openvas version. openvas version needs to be at least 7.0.1.

So I build gvm-libs on branch gvm-libs-11.0 and openvas-scanner on branch openvas-7.0 and now the startup hangs on:

Starting Open Scanner Protocol daemon for OpenVAS...

What I’m missing?

2

Please build openvas from the release branch too.

1 Like
3

Hi,

Could you be more specific ? I thought I was building the release branch openvas-7.0 for the openvas package ? These are the packages and branches I’m currently building:


gvm-libs-11.0


openvas-7.0


ospd-2.0


ospd-openvas-1.0

The rest of them are being built from the released versions, as you can see here.

4

The message is a bit confusing because there is no released version of openvas 7.0.1. It requires either a version from the current https://github.com/greenbone/openvas/tree/openvas-7.0 branch or from master branch. You can check if you have a sufficient version of openvas by running openvas --version. The output must contain a line about the gvm-libs version.

Something like (I am using a version from the master branch)

$ openvas --version
OpenVAS 20.4+beta1
gvm-libs 20.4
2 Likes
5

Hi Bricks,

Then I don’t understand what I’m doing wrong, if you looked at the pastebin link you would have noticed that indeed I’m building https://github.com/greenbone/openvas from openvas-7.0 branch:

git clone https://github.com/greenbone/openvas.git && \
    cd /build/*/ && \
    git checkout openvas-7.0 && \
    mkdir build && \
    cd build && \
    cmake -DCMAKE_BUILD_TYPE=Release .. && \
    make && \
    make install && \
    cd /build && \
    rm -rf *

but when running openvas --version I still get 7.0.0 version:

openvas --version
 ---> Running in a80db5cdd576
OpenVAS 7.0.0
gvm-libs 11.0.1

I’m missing building from master any other package or something ? I will try switching from openvas-7.0 branch to master and see what happens.

btw, thanks for your help.

6

Ok, I managed go pass from the “Starting Open Scanner Protocol daemon for OpenVAS” message and see the correct versions as you pointed out:

openvas --version
OpenVAS 20.4+beta1
gvm-libs 20.4

but it seems there is still something wrong or broken. At startup I get lots of error messages like these:

lib  osp:WARNING:2020-04-06 20h01.42 utc:240: osp_get_vts_version: element VTS missing.
md manage:WARNING:2020-04-06 20h01.42 utc:240: manage_update_nvt_cache_osp: failed to get scanner_version
md manage:   INFO:2020-04-06 20h01.49 utc:210: update_dfn_xml: dfn-cert-2013.xml
md manage:   INFO:2020-04-06 20h01.49 utc:210: Updating /usr/local/var/lib/gvm/cert-data/dfn-cert-2013.xml
lib  osp:WARNING:2020-04-06 20h01.53 utc:244: osp_get_vts_version: element VTS missing.

And I cannot add a target, I get this error:

Screenshot_20200406_211135
Screenshot_20200406_211135886×636 38.1 KB
and on the logs I can see this:

==> /usr/local/var/log/gvm/gvmd.log <==
event target:MESSAGE:2020-04-06 20h43.40 UTC:1743: Target could not be created by admin

Now I will try backporting only those two PR’s to the current released versions and see what happens…

btw, when is the next version going to be released ?

7

As I wrote the warning is a bit confusing because there is no 7.0.1 version but the openvas-7.0 branch should work despite not announcing a 7.0.1 version. From the output of openvas --version it was important that the version of gvm-libs is displayed which was only added after the initial openvas 7.0.0 release. Therefore the openvas-7.0 branch should work with ospd 2.0 and ospd-openvas 1.0.

I am not sure if you used the master branch of all components. In that case it wont work. gvmd needs some data from the feed which isn’t available at the moment. It is never a good idea to use our master branches without getting in touch with architecture and code details. Master branches may always be broken in some kind.

We are currently not doing bugfix releases because there is seems to be no demand (no distribution ships our current version as far as I am aware of) and because it cost to much developer resources. Our GOS just picks the code from the release branches.

Due to the current situation there will be some delay for the next GVM release (it was planned as 20.4). Therefore there isn’t an up to date time base for the next release.

2 Likes