Closed immauss closed 2 years ago
OK ... It's working . I'm seeing more of these in the logs than in the past after initial start/restart of container, but it does stop and things work aftwards. So I guess that is the new normal.
osp_scanner_feed_version: failed to get scanner_feed_version. OSPd OpenVAS is still starting
I'm still doing upgrade testing, so procede at your own risk. Let me know if you've done any testing and if you find any issues here.
Thanks, Scott
New 21.04.07 branch pushed to github and new container tag 21.04.07 as well.
upgrade testing looks good!
I'll be puting 21.04.07 on my production systems today.
upgrade testing looks good!
I'll be puting 21.04.07 on my production systems today.
Thank you for your hard work, I'll testing 21.04.07 in the following days, I'll let you know for issues if there will be any! 👍
My first attempts to switch to the new version resulted in errors regarding the certs used by gvmd, and gvmd dies and exits.
libgvm util:WARNING:2022-03-23 18h41.31 utc:369: server_new_internal: failed to set credentials key file: Error while reading file.
libgvm util:WARNING:2022-03-23 18h41.31 utc:369: server_new_internal: cert file: /var/lib/gvm/CA/servercert.pem
libgvm util:WARNING:2022-03-23 18h41.31 utc:369: server_new_internal: key file : /var/lib/gvm/private/CA/serverkey.pem
md main:CRITICAL:2022-03-23 18h41.31 utc:369: gvmd: client server initialisation failed
I saw the gvm account had read access to those certs, but they were owned by root. So I decided to try chown'ing them to gvm to see what happens, and now gvmd starts up normally.
So if i add the two chowns to just before gvmd is started up in your start.sh script, it runs like normal. I dont know that anything besides gvmd needs to use those certs? I'm pondering what the best fix might be, whether it is to run the "gvm-manage-certs -a" as gvm, or if the certs should stay owned by root and a different solution should be found, or something else altogether.
This is running within OpenShift/Kubernetes (so podman/CRI-O), I didnt do any local attempts to run it.
Doing further testing, I found NVTs were not being loaded. It fails each time when trying to create its lock file /usr/local/bin/greenbone-nvt-sync: 514: /usr/local/bin/greenbone-nvt-sync: cannot create /var/lib/openvas/feed-update.lock: Permission denied
Turns out, at each start, it changes the permissions on the /data/var-lib/openvas folder, to owner root with no other write permissions, 755, so the gvm account cant write to it. Adding a chown -R for that directory before the NVT sync fixes it for me. But I dont see what keeps setting the permissions back to root/root 755 at start up.
So this has been running in my production for several days. A few scheduled scans and reports later, I'm thinking it's OK. I will be adding a link to help with issue #107 until I figure out why even though it still seems to work fine for me.
@DavidHaltinner You might want to check your local file systems. Since that is on your volume, it could be something local that is changing it. However, I'm also making a change to the fs-setup.sh to chown the entire directory instead of just the plugins sub-directory.
I just kicked off a refresh build, which will add those minor changes, build a new fresh updated DB for the image, and push it do docker hub. It will take an hour or so.
The most recent 21.04.07 has all the above-mentioned tweaks. Please let me know if you have any other issues.
Looks like I have some work ahead of me. I realized that Greenbone has changed the base OS from Debian Buster to Debian Bullseye, which means the next version, which I assume will come out next month, will be based on Bullseye as well. :(
If there's no other comments here in 24 hours, I'll make this one latest, and close out this issue.
Thanks to everyone who tested and commented.
OK ... I'm going to close this out. Thanks again.
Currently the build is successful, but it does not run. The gsa/gsad build scripts need to be re-written and probably ospd as well since Greenbone has combined ospd/ospd-openvas and split gsa/gsad .
working on it.