22.4 from source - ospd-openvas can not run because no executable is installed

I have followed the installation instructions from the web site, installing from source:

https://greenbone.github.io/docs/latest/22.4/source-build/index.html#setting-up-services-for-systemd

In the service file there is “ExecStart=/usr/local/bin/ospd-openvas”, but upon inspection of /usr/local/bin there is no ospd-openvas file. From the python package installation I also can’t make out where that file should come from, so I wonder if I missed part of the manual, or some step.

I hope somebody can help with this, I’m really interested in getting started with openvas!

When installing ospd-openvas via pip (https://greenbone.github.io/docs/latest/22.4/source-build/index.html#ospd-openvas) pip creates a script at /usr/local/bin/ospd-openvas.

1 Like

Hello Bjoern,

Thanks for your answer, strangely this did not happen for some reason, am I doing something wrong?

It does appear ‘poetry’ is missing from my install (fresh installation of Ubuntu 22.04), but after installing python3-poetry I get conflicts when I run the aforementioned pip install.

If you are following our source build guide poetry is NOT used. poetry would also not install ospd-openvas globally at your system. It uses so called virtual environments.

To install ospd-openvas the guide lists the following commands

cd $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION

python3 -m pip install . --prefix=$INSTALL_PREFIX --root=$INSTALL_DIR --no-warn-script-location

sudo cp -rv $INSTALL_DIR/* /

you need to ensure that the environment variables SOURCE_DIR, OSPD_OPENVAS_VERSION, INSTALL_PREFIX and INSTALL_DIR are really set. After running python3 -m pip ... you can also take a look at $INSTALL_DIR/usr/local/bin if there is a ospd-openvas script.

1 Like

Thanks, I have removed poetry, I was fooled by the pyproject.toml file that mentioned it some times.
I did follow the install guide step by step, everything else seems to work except for this part.

Allow me to show what I did and possibly failed to do right:

user@server:~/source/ospd-openvas-22.4.2$ cd $SOURCE_DIR/ospd-openvas-$OSPD_OPENVAS_VERSION
user@server:~/source/ospd-openvas-22.4.2$ echo $INSTALL_PREFIX
/usr/local
user@server:~/source/ospd-openvas-22.4.2$ echo $INSTALL_
$INSTALL_DIR     $INSTALL_PREFIX
user@server:~/source/ospd-openvas-22.4.2$ echo $INSTALL_DIR
/home/user/install
user@server:~/source/ospd-openvas-22.4.2$ python3 -m pip install . --prefix=$INSTALL_PREFIX --root=$INSTALL_DIR --no-warn-script-location
Processing /home/user/source/ospd-openvas-22.4.2
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting packaging<21.0,>=20.4
  Using cached packaging-20.9-py2.py3-none-any.whl (40 kB)
Collecting deprecated<2.0.0,>=1.2.10
  Using cached Deprecated-1.2.13-py2.py3-none-any.whl (9.6 kB)
Requirement already satisfied: defusedxml<0.8,>=0.6 in /usr/lib/python3/dist-packages (from ospd-openvas==22.4.2) (0.7.1)
Requirement already satisfied: redis<5.0.0,>=3.5.3 in /usr/lib/python3/dist-packages (from ospd-openvas==22.4.2) (3.5.3)
Requirement already satisfied: psutil<6.0.0,>=5.5.1 in /usr/lib/python3/dist-packages (from ospd-openvas==22.4.2) (5.9.0)
Requirement already satisfied: python-gnupg<0.5.0,>=0.4.8 in /usr/lib/python3/dist-packages (from ospd-openvas==22.4.2) (0.4.8)
Requirement already satisfied: paho-mqtt>=1.5.1 in /usr/lib/python3/dist-packages (from ospd-openvas==22.4.2) (1.5.1)
Requirement already satisfied: lxml<5.0.0,>=4.5.2 in /usr/lib/python3/dist-packages (from ospd-openvas==22.4.2) (4.8.0)
Requirement already satisfied: wrapt<2,>=1.10 in /usr/lib/python3/dist-packages (from deprecated<2.0.0,>=1.2.10->ospd-openvas==22.4.2) (1.13.3)
Requirement already satisfied: pyparsing>=2.0.2 in /usr/lib/python3/dist-packages (from packaging<21.0,>=20.4->ospd-openvas==22.4.2) (2.4.7)
Building wheels for collected packages: ospd-openvas
  Building wheel for ospd-openvas (pyproject.toml) ... done
  Created wheel for ospd-openvas: filename=ospd_openvas-22.4.2-py3-none-any.whl size=125372 sha256=6e1dd6bdd8c78fb965f0a54f12c30cb85f502b83ee73720d5c374a4e856e3838
  Stored in directory: /home/user/.cache/pip/wheels/a4/62/d5/9ba3220e196e5cd3dbde2d38ac6cae1effb3bf78d1ad540e02
Successfully built ospd-openvas
Installing collected packages: packaging, deprecated, ospd-openvas
  Attempting uninstall: packaging
    Found existing installation: packaging 21.3
    Not uninstalling packaging at /usr/lib/python3/dist-packages, outside environment /usr
    Can''t uninstall 'packaging'. No files were found to uninstall.
Successfully installed deprecated-1.2.13 ospd-openvas-22.4.2 packaging-20.9
user@server:~/source/ospd-openvas-22.4.2$ ls $INSTALL_DIR/usr/local/bin
greenbone-nvt-sync  gvm-manage-certs  notus-scanner  notus-scan-start  notus-subscriber  openvas-nasl  openvas-nasl-lint  wmic

I have anonymized user & servername, for the rest this is verbetim what I did.

OK, I have found the reason this did not work for me. Possibly this is because of specific settings for pip on my distribution?

What happened is that the pip output wrote to $INSTALL_DIR/usr/local/local/bin and ../lib. What fixed it for me is to the string “/usr” instead of $INSTALL_PREFIX, so that the files ended up at the correct location.

I hope this helps anyone having the same trouble as I did.

1 Like

So you mixed distribution and local content ? That is not advisable at all. Any packet can you ruin your GVM installation.

Hi Lukas,

What I’m referring to is just a step in the official installation guide, where the ospd-openvas python package is installed to a ‘local’ path (with --root=$INSTALL_DIR and --prefix=$INSTALL_PREFIX as arguments to pip), after which the installed packages and scripts are moved to /usr/local/bin and /usr/local/lib (see code block in an earlier post for the code running pip and https://greenbone.github.io/docs/latest/22.4/source-build/index.html#ospd-openvas for the relevant installation instructions).

I just noticed that the “prepared” package location was in /home/user/install/usr/local/local/bin instead of /home/user/install/usr/local/bin. (note: local/local in the first path). Therefore I tweaked the pip command to instead of using ‘/usr/local’ as $INSTALL_DIR, now to use ‘/usr’ in that variable, which ended up putting the files in the correct location. I now have a running instance of openvas!

If you think the installation instructions are wrong, then maybe it’s good to contact the authors, I’m just a beginner in this respect.

I’ve dig into this a bit and found the culprit. pip has installation schemes for different os and installations. When creating the scheme on for example Ubuntu 22.04 with Python 3.10 it calls the sysconfig Python standard library at https://github.com/pypa/pip/blob/22.3.1/src/pip/_internal/locations/_sysconfig.py#L170. This library returns the wrong values:

import sysconfig
from pip._internal.locations._sysconfig import _HOME_KEYS, _infer_prefix

prefix = "/usr/local"
variables = {k: prefix for k in _HOME_KEYS}
scheme_name = _infer_prefix()

paths = sysconfig.get_paths(scheme=scheme_name, vars=variables)
print(paths)
{'stdlib': '/usr/local/lib/python3.10', 'platstdlib': '/usr/local/lib/python3.10', 'purelib': '/usr/local/local/lib/python3.10/dist-packages', 'platlib': '/usr/local/local/lib/python3.10/dist-packages', 'include': '/usr/local/include/python3.10', 'platinclude': '/usr/local/include/python3.10', 'scripts': '/usr/local/local/bin', 'data': '/usr/local/local'}

Not sure if this is bug in pip, CPython or Debian/Ubuntu.

1 Like

On Debian Bullseye with Python 3.9 and pip 20.3.4 the error doesn’t occur and pip works as expected. pip doesn’t seem to use the sysconfig module in this version.

from pip._internal.locations import get_scheme
s = get_scheme("", prefix="/usr/local")
print(s.scripts)
/usr/local/bin
1 Like

Same code on Ubuntu 22.04 with Python 3.10 and pip 22.0.2.

from pip._internal.locations import get_scheme
s = get_scheme("", prefix="/usr/local")
print(s.scripts)
/usr/local/local/bin
1 Like

I’ve created an issue for pip https://github.com/pypa/pip/issues/11651

2 Likes

There is the following comment in that issue:

This looks like an issue with Ubuntu. pip uses introspection methods provided by the Python interpreter to discover paths, and Linux distributions are known to mangle those paths. Please report to the distributions instead.

and an additional reference to:

1 Like