search

greenbone / ospd-openvas

ospd-openvas is an OSP server implementation to allow GVM to remotely control an OpenVAS Scanner
GNU Affero General Public License v3.0
67 stars 58 forks source link

Container "greenbone/ospd-openvas:stable" does not start #699

Closed ThomasChr closed 2 years ago

ThomasChr commented 2 years ago

I followed the manual on https://greenbone.github.io/docs/latest/21.04/container to use the Greenbone Docker containers. The container "greenbone/ospd-openvas:stable" does not start. It's restarting all the time

Expected behavior

It should start

Actual behavior

It's restarting everytime

Steps to reproduce

Just start the Containers from the compose file

GVM versions

Latest stable docker containers

Environment

Operating system: Ubuntu 20.04.4 LTS

Installation method / source: (packages, source installation) Docker-compose

Logfiles

ospd-openvas_1  | usage: ospd-openvas [-h] [--version] [-s [CONFIG]] [--log-config [LOG_CONFIG]]
ospd-openvas_1  |                     [-p PORT] [-b ADDRESS] [-u UNIX_SOCKET]
ospd-openvas_1  |                     [--pid-file PID_FILE] [--lock-file-dir LOCK_FILE_DIR]
ospd-openvas_1  |                     [-m SOCKET_MODE] [-k KEY_FILE] [-c CERT_FILE]
ospd-openvas_1  |                     [--ca-file CA_FILE] [-L LOG_LEVEL] [-f]
ospd-openvas_1  |                     [-t STREAM_TIMEOUT] [-l LOG_FILE] [--niceness NICENESS]
ospd-openvas_1  |                     [--scaninfo-store-time SCANINFO_STORE_TIME]
ospd-openvas_1  |                     [--list-commands] [--max-scans MAX_SCANS]
ospd-openvas_1  |                     [--min-free-mem-scan-queue MIN_FREE_MEM_SCAN_QUEUE]
ospd-openvas_1  |                     [--max-queued-scans MAX_QUEUED_SCANS]
ospd-openvas_1  |                     [--mqtt-broker-address MQTT_BROKER_ADDRESS]
ospd-openvas_1  |                     [--mqtt-broker-port MQTT_BROKER_PORT]
ospd-openvas_1  |                     [--notus-feed-dir NOTUS_FEED_DIR]
ospd-openvas_1  |                     [--disable-notus-hashsum-verification DISABLE_NOTUS_HASHSUM_VERIFICATION]
ospd-openvas_1  | ospd-openvas: error: argument --disable-notus-hashsum-verification: expected one argument
Alexconekia commented 2 years ago

I'm having the same problem

heywoodlh commented 2 years ago

It seems that if you revert to the oldstable tag, it works. Can be a workaround until this bug is fixed with the current container:

I.E in the docker-compose.yml

...
ospd-openvas:
    image: greenbone/ospd-openvas:oldstable
...
bjoernricks commented 2 years ago

The docker compose file needs adjustments for the new release. Therefore please use the oldstable images instead. See https://github.com/greenbone/docs/pull/137

fahrenhe1t commented 2 years ago

If I use "oldstable" on greenbone/ospd-openvas and greenbone/gvmd, gvmd gives this error in logs: 

md   main:MESSAGE:2022-07-22 21h51.52 utc:332:    Greenbone Vulnerability Manager version 20.08.5 (DB revision 233)
md manage:   INFO:2022-07-22 21h51.52 utc:332:    Modifying setting.
md manage:WARNING:2022-07-22 21h51.52 utc:332: sql_exec_internal: PQexec failed: ERROR:  could not access file "/usr/local/lib/libgvm-pg-server": No such file or directory
 (7)
md manage:WARNING:2022-07-22 21h51.52 utc:332: sql_exec_internal: SQL: CREATE OR REPLACE FUNCTION hosts_contains (text, text) RETURNS boolean AS '/usr/local/lib/libgvm-pg-server', 'sql_hosts_contains' LANGUAGE C IMMUTABLE;
md manage:WARNING:2022-07-22 21h51.52 utc:332: sqlv: sql_exec_internal failed
bjoernricks commented 2 years ago

@fahrenhe1t please pull the oldstable images again. This should be fixed now.

bjoernricks commented 2 years ago

This is fixed and the docs are up-to-date now.

fahrenhe1t commented 2 years ago

Changing everything to "oldstable" now seems to get a bit further. In the GVMD container, it continually says: 

md manage:MESSAGE:2022-07-26 17h29.47 utc:61: No SCAP database found
md manage:MESSAGE:2022-07-26 17h29.47 utc:61: No CERT database found
libgvm util:   INFO:2022-07-26 17h29.47 utc:61: starting key generation ...
libgvm util:   INFO:2022-07-26 17h29.47 utc:61: OpenPGP key 'GVM Credential Encryption' has been generated
md   main:WARNING:2022-07-26 17h29.47 utc:61: The gvmd data feed directory /var/lib/gvm/data-objects/gvmd or one of its subdirectories does not exist.
md manage:WARNING:2022-07-26 17h29.47 utc:88: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2022-07-26 17h29.47 utc:90: Initializing CERT database
md manage:   INFO:2022-07-26 17h29.47 utc:88: update_scap: Updating data from feed
md manage:WARNING:2022-07-26 17h29.47 utc:88: update_scap_cpes: No CPE dictionary found at /var/lib/gvm/scap-data/official-cpe-dictionary_v2.2.xml
md manage:   INFO:2022-07-26 17h29.48 utc:89: OSP service has different VT status (version 0) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2022-07-26 17h29.48 utc:89: Updating VTs in database ... 0 new VTs, 0 changed VTs
md manage:   INFO:2022-07-26 17h29.48 utc:89: Updating VTs in database ... done (0 VTs).
md manage:WARNING:2022-07-26 17h29.57 utc:93: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2022-07-26 17h29.58 utc:93: update_scap: Updating data from feed
md manage:WARNING:2022-07-26 17h29.58 utc:93: update_scap_cpes: No CPE dictionary found at /var/lib/gvm/scap-data/official-cpe-dictionary_v2.2.xml
md manage:WARNING:2022-07-26 17h30.08 utc:98: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2022-07-26 17h30.09 utc:98: update_scap: Updating data from feed
md manage:WARNING:2022-07-26 17h30.09 utc:98: update_scap_cpes: No CPE dictionary found at /var/lib/gvm/scap-data/official-cpe-dictionary_v2.2.xml
md manage:WARNING:2022-07-26 17h30.17 utc:103: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2022-07-26 17h30.18 utc:103: update_scap: Updating data from feed
md manage:WARNING:2022-07-26 17h30.18 utc:103: update_scap_cpes: No CPE dictionary found at /var/lib/gvm/scap-data/official-cpe-dictionary_v2.2.xml

I think because of this error, the openvas container exits\crashes, so not working for me at least: 

OSPD[1] 2022-07-26 11:29:13,253: INFO: (ospd.main) Starting OSPd OpenVAS version 21.4.5.dev1.
OSPD[1] 2022-07-26 11:29:23,353: ERROR: (ospd_openvas.openvas) OpenVAS Scanner failed to load VTs. Command '['openvas', '--update-vt-info']' returned non-zero exit status 1.
bjoernricks commented 2 years ago

For me it seems your sync didn't go well. Could you try the following commands

docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition down
docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition run --rm ospd-openvas greenbone-nvt-sync
docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition run --rm gvmd greenbone-feed-sync --type SCAP
docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition run --rm gvmd greenbone-feed-sync --type CERT
docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition run --rm gvmd greenbone-feed-sync --type GVMD_DATA
docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition up -d

?

bjoernricks commented 2 years ago

Also taking a look at the openvas.log file would be nice docker-compose -f $DOWNLOAD_DIR/docker-compose.yml -p greenbone-community-edition run --rm ospd-openvas cat /var/log/gvm/openvas.log

fahrenhe1t commented 2 years ago

I think I'm running a newer version of Docker Compose, as I had to run: 

docker exec -it --user 1001 ospd-openvas greenbone-nvt-sync
docker exec -it gvmd greenbone-feed-sync --type SCAP
docker exec -it gvmd greenbone-feed-sync --type CERT
docker exec -it gvmd greenbone-feed-sync --type GVMD_DATA
docker compose down -v
docker compose up -d --force-recreate

I had to run the exec commands before taking the containers down, then bringing them back up. But the commands pulled down a ton of data and seem to be working now. On a brand new install, would the containers automatically run these commands?

bjoernricks commented 2 years ago

Please also use --user 1001 or --user gvmd also when running exec for the greenbone-feed-sync script. Otherwise the downloaded data will be owned by the root user and this may create a lot of issues.

On a brand new install, would the containers automatically run these commands?

No. These commands need to be run manually for now. Please also check the https://greenbone.github.io/docs/ for the latest version (updated yesterday). I've changed the chapters for the feed sync. It is better to run the initial feed sync before the services are started.

Nevertheless we have plans to improve the feed sync for the container setup in future. But there is no ETA yet.