search

greenbone / gsa

Greenbone Security Assistant - The web frontend for the Greenbone Community Edition
GNU Affero General Public License v3.0
219 stars 97 forks source link

gsad doesn't respond and doesn't log why not #4157

Closed masaoliou closed 2 months ago

masaoliou commented 2 months ago

gsad is expected to respond with contents to HTTP requests. If it doesn't, it should at least write log to explain why.

However, wget http://127.0.0.1:9392 repeatedly requests and prints the following messages.

--2024-09-10 14:53:43--  http://127.0.0.1:9392/
Connecting to localhost (localhost)|127.0.0.1|:9392... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2024-09-10 14:53:44--  (try 2)  http://127.0.0.1:9392/
Connecting to localhost (localhost)|127.0.0.1|:9392... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

And gsad doesn't explain why it does not want to respond.

Steps to reproduce

  1. Change level=0 and all occurrences of level=127 to level=128 in `/etc/gvm/gsad_log.conf``
  2. Issue command systemctl restart gsad
  3. Issue command wget http://127.0.0.1:9392.

GVM versions

gsa: (gsad --version) 22.11.0

gvm: (gvmd --version) 23.8.1

openvas-scanner: (openvas-nasl --version) 23.8.5

gvm-libs: 22.10.0

Environment

Operating system: Debian Forky and Ubuntu 24.04.1 both run as QEMU guests. Debian Bookworm runs QEMU host.

All operations mentioned in this report were done in the aforementioned two QEMU guests.

Linux forky 6.10.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.7-1 (2024-08-31) x86_64 GNU/Linux

Installation method / source: (packages, source installation) apt install gvm nodejs greenbone-security-assistant gvm-setup

Logfiles

/var/log/gvm/gsad.log

gsad main:MESSAGE:2024-09-10 06h52.54 utc:1942: Starting GSAD version 22.11.0~git
gsad main:  DEBUG:2024-09-10 06h52.54 utc:1942: GSAD started successfully and is listening on port 9392.

gvm-setup outputs

gvm-check-setup 23.11.0
  Test completeness and readiness of GVM-23.11.0
Step 1: Checking OpenVAS (Scanner)... 
        OK: OpenVAS Scanner is present in version 23.8.5.
        OK: Notus Scanner is present in version 22.6.4.
        OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.
Checking permissions of /var/lib/openvas/gnupg/*
        OK: _gvm owns all files in /var/lib/openvas/gnupg
        OK: redis-server is present.
        OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock
        OK: the mqtt_server_uri is defined in /etc/openvas/openvas.conf
        OK: _gvm owns all files in /var/lib/openvas/plugins
        OK: NVT collection in /var/lib/openvas/plugins contains 92080 NVTs.
        OK: The notus directory /var/lib/notus/products contains 467 NVTs.
Checking that the obsolete redis database has been removed
        OK: No old Redis DB
        OK: ospd-openvas service is active.
        OK: ospd-OpenVAS is present in version 22.7.1.
Step 2: Checking GVMD Manager ... 
        OK: GVM Manager (gvmd) is present in version 23.8.1.
Step 3: Checking Certificates ... 
        OK: GVM client certificate is valid and present as /var/lib/gvm/CA/clientcert.pem.
        OK: Your GVM certificate infrastructure passed validation.
Step 4: Checking data ... 
        OK: SCAP data found in /var/lib/gvm/scap-data.
        OK: CERT data found in /var/lib/gvm/cert-data.
Step 5: Checking Postgresql DB and user ... 
        OK: Postgresql version and default port are OK.
 gvmd      | _gvm     | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           | 
16440|pg-gvm|10|2200|f|22.6||
        OK: At least one user exists.
Step 6: Checking Greenbone Security Assistant (GSA) ... 
        OK: Greenbone Security Assistant is present in version 22.11.0~git.
Step 7: Checking if GVM services are up and running ... 
        OK: gvmd service is active.
        OK: gsad service is active.
Step 8: Checking few other requirements...
        OK: nmap is present.
        OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
        OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
        OK: xsltproc found.
        WARNING: Your password policy is empty.
        SUGGEST: Edit the /etc/gvm/pwpolicy.conf file to set a password policy.
Step 9: Checking greenbone-security-assistant...
        OK: greenbone-security-assistant is installed

It seems like your GVM-23.11.0 installation is OK.
cfi-gb commented 2 months ago

Looks more like a support question for which an existing thread already exists here:

https://forum.greenbone.net/t/no-response-from-localhost-9392/19082

masaoliou commented 2 months ago

Looks more like a support question for which an existing thread already exists here:

https://forum.greenbone.net/t/no-response-from-localhost-9392/19082

Yes.

I hope this report can be treated as a feature request -- enhancing gsad to log the reasons why it is unable to respond to HTTP requests.

cfi-gb commented 2 months ago
  1. This is the repository of the GSA web frontend, anything for the gsad daemon would need to be placed to https://github.com/greenbone/gsad/issues
  2. Was it verified that this is actually an issue within the gsad and not a setup / packaging issue?
masaoliou commented 2 months ago
  1. This is the repository of the GSA web frontend, anything for the gsad daemon would need to be placed to https://github.com/greenbone/gsad/issues

Can I cross post this report there? Is it an acceptable practice?

  1. Was it verified that this is actually an issue within the gsad and not a setup / packaging issue?

I assume the issue lies in gsad because wget prints the line with ... connected.

masaoliou commented 2 months ago

curl --verbose http://127.0.0.1:9392 prints the following.

* Connected to 127.0.0.1 (127.0.0.1) port 9392
> GET / HTTP/1.1
> Host: 127.0.0.1:9392
> User-Agent: curl/8.9.1
> Accept: */*
> 
* Empty reply from server

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* shutting down connection #0
curl: (52) Empty reply from server
cfi-gb commented 2 months ago

I would suggest to move the debugging of this 3rd party package based installation to the existing community forums thread, close this issue as won't do / fix and only re-open a new one in https://github.com/greenbone/gsad/issues once it really turns out to be a bug / issue / adequate feature request for gsad.

masaoliou commented 2 months ago

Close this report for this moment because this issue is irrelevant to gsa.