Was going to hold off posting here, but concerning that there are no other catagories that fits this particular topic, guess this will have to do.
In basic, what the title says. Is there any in-depth guides that describes how to build, configure, and install GSE? Trying to install GSE before has not gone well, with the NVT cache not updating correctly.
On that regard, why can’t we run “greenbone-nvt-sync” as root anymore?
With “openvas-check-setup” no longer being supported, something like this should be easily accessable.
Because running commands as root user is a dangerous task and should never be done without care. Especially because it isn’t necessary at all with GVM 10.
The script hasn’t been maintained for several years. It didn’t work for all cases (e.g. redis issues) and therefore gave the users a false impression of having a valid setup. It didn’t give us developers any value and therefore we dropped it.
You have to take a look at the different INSTALL.md files of our components.
snip, Nevermind, I take that back. Your link points to the list already. Thanks.
I’ve seen the notice already. Most of the redis issues I have seen is due to app armour being a bitch and not letting redis write to /tmp. So have to take the long way around of making a script that refreshes /tmp/redis.sock as a link to /var/run/redis/redis-server.sock. Apparently this is allowed under app armour’s policy, so whatever works I guess. But yeah, concerning the checks I’ve seen that are being performed (I currently have a GVM version 9 installed, which still has the script IIRC), I would guess that it would be dropped, due to how much you can really do from a bash script.
Well, funny enough, running it as non-root spits out error upon no end about permissions, so in that case, I guess I can just modify the bash script anyway. All the other scripts run happily as root, so IDK what logic is used for the scripts. Just FYI, there are scripts out there that if required, does drop the calling user into whatever user your script requires via a quick and dirty “sudo -u [User of your choice] $0” or something akin to that. So maybe look into that, to make the process a little easier?
In that case you already did something wrong. Use a dedicated user (and maybe group) for gvmd and give the user and groups permissions. YOU DON’T NEED TO RUN the sync scripts as root and you SHOULDN’T.
Two things in our stack need root permissions only, our scanner and running gsad on port 80 and 443. That’s it.
Huh… Okay. Well, I was building GSE under root (Force of habit, no particular reason), does that have any impact on GSE’s permissions as well? And if so, any way around it? I’m pretty sure my user account does not have access to /usr/local, the normal install location for GSE. I’ve got a Ubuntu Server that I’m trying to install it on. And yes, I already tried running the virtual appliance, but the virtual appliance can’t install under KVM for some odd reason.
Building under root is a bad idea if you don’t have a dedicated build machine that setups some environment which is removed after the build. E.g. building our web application GSA downloads a lot of JavaScript dependencies from the internet. EVERY JS dependency can possibly install malicious code on your system during download. The same is true for Python dependencies. Of course we are trying to reduce the risk to a minimum by pinning our dependencies but there is still a risk.