For some reason that I cannot determine is that gsad doesn’t start and there is no hint in the logs or stdout of why this is. Below are the last log lines.
root@e6f9ec9ef3bf:/var/log/gvm# tail *
==> greenbone-feed-sync.log <==
1,532 100% 4.66kB/s 0:00:00 (xfr#27, to-chk=3/31)
sha256sums
2,180 100% 6.35kB/s 0:00:00 (xfr#28, to-chk=2/31)
sha256sums.asc
819 100% 2.39kB/s 0:00:00 (xfr#29, to-chk=1/31)
timestamp
13 100% 0.04kB/s 0:00:00 (xfr#30, to-chk=0/31)
sent 681 bytes received 82,112,948 bytes 1,020,045.08 bytes/sec
total size is 82,090,886 speedup is 1.00
==> gvmd.log <==
md manage:WARNING:2022-02-10 07h23.46 UTC:1142: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h23.57 UTC:1145: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h24.07 UTC:1149: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h24.17 UTC:1153: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h24.27 UTC:1156: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h24.37 UTC:1160: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h24.47 UTC:1164: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h24.57 UTC:1169: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h25.07 UTC:1177: secinfo_feed_version_status: last scap database update later than last feed update
md manage:WARNING:2022-02-10 07h25.17 UTC:1182: secinfo_feed_version_status: last scap database update later than last feed update
==> openvas.log <==
libgvm util:MESSAGE:2022-02-10 07h17.44 utc:160: Updated NVT cache from version 0 to 202202091123
==> ospd-openvas.log <==
OSPD[222] 2022-02-10 07:17:44,438: INFO: (ospd.main) Starting OSPd OpenVAS version 21.4.4.
Because gsad doesn’t start, my web interface doesn’t show up. Can someone please have a look why this might be happening? Maybe I’m doing something wrong in the build (see Dockerfile) or maybe I start things the wrong way (see entrypoint.sh). In any case, earlier releases of 21.4 did work. The first release that is, 21.4.0. After that things started to change quite a lot and now it seems to be broken in my setup.
True, I wish I could. But there is no error output. The problem seems that in the past versions the certificates for GSAD were in a predictable path. Now it doesn’t find the certificates automatically anymore as these paths probably changed.
It’s been a pain that GVM changed from /usr/local as a default for everything now also uses stuff in the regular directories, even when stuff is installed in /usr/local. It caused some unnecessary troubleshooting already. I don’t get this change. Stuff that people install themselves from source go into /usr/local, the rest is managed by the distribution itself and should not mix. But that’s just me I guess
I know I can override all this when compiling. But the default should be /usr/local.
Anyway, I think the issue is that GSAD still looks for the certificates in /usr/local/var/lib/gvm/CA, while that’s now in /var/lib/gvm/CA/. I think that because GSAD still logs in /usr/local/var/log/gvm while all the other components use /var/log/gvm. gvm-manage-certs probably doesn’t use /usr/local.
I’ll try to pinpoint the issue a bit further. But setting the location of the TLS certificates manually makes GSAD start again. But no stdout or logging tells me this. Unless something is out of place there as well.
I know this sounds like unproductive complaining. I just don’t get this change in the recent releases. Distributions set the destinations according to the Linux FHS when they package the software. When building just from source, /usr/local should be used. Now it’s just confusing.
I have to strongly disagree here. Installing into /usr/local/run, /usr/local/etc and /usr/local/var doesn’t make sense at all. Especially /run as it is maintained by systemd. You won’t get the correct functionality if you use /usr/local/run/gvmd. I’ve changed all paths to use sane defaults for a normal user that just work. We still use /usr/local/bin, /usr/local/sbin, /usr/local/share and /usr/local/lib per default as these directories are included in the search paths at most distributions too. And if you now want to use different directories for /run, /etc and /var you have adjust the CMake variables by intention instead of having to set these variables to get a working solution. The previous defaults just don’t work as expected.
Thanks for clarifying. Those are indeed good points. I know I can override this with build parameters. But I tend to keep as close what upstream considers defaults to make life easier. That’s also why I use a Debian container and not some RedHat flavor.
One follow up question though. gsad usually didn’t need the parameters to specifically point to a certificate. I suppose it used to searched and find the certificates generated by gvm-manage-certs. Now it does a specific path to these certs to start properly with TLS. gsad also still logs in /usr/local/var/log/gvm. Could it be that this transition hasn’t been fully implemented yet in GSAD 21.4.3?
For some reason the certificates end up in /var/lib/gvm/, which is okay I suppose. GSAD logs in /usr/local/var/log/gvm, this directory is made when gsad is started. This is incorrect behavior. I also have to explicitly point to the certificates, as if the build is looking for them in /usr/local/var/lib, but this is an assumption. I haven’t verified this. In the container I cannot use strace.
The README might need an update. When I read this and then this, it makes me believe the logging takes place in /usr/local/var/log/gvm
