View Issue Details

IDProjectCategoryView StatusLast Update
0006615Kali Linux[All Projects] Kali Package Bugpublic2020-08-10 17:58
Reportervanguard Assigned Tosbrun  
PriorityhighSeverityblockReproducibilityalways
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0006615: gvm not usable due to wrong permissions and paths
DescriptionDear maintainers,

with the change from openvas to gvm I got into several issues after updating from openvas to gvm. There appear a bunch of problems, which might be related by the change to another structure. This is, what I discovered:

1. Issues with gvm-setup
Reason: The directory given by the script is /var/lib/openvas/plugins. This path can not be used, as the permissions are set root:root, but the script awaits it writable for the user/grfoup _gvm:_gvm. manually setting this to this ownership will fix it.

However, should the path not be set to /var/lib/gvm where the other plugins and modules residce like scada and cert?

1.1 Issue gvm-setup
The second issue is missing files below /usr/share/postgresql. See the message:

---
ERROR: role "dba" already exists
NOTICE: role "_gvm" is already a member of role "dba"
GRANT ROLE
ERROR: could not open extension control file "/usr/share/postgresql/9.1/extension/uuid-ossp.control": No such file or directory
----

I checked, and yes, the necessary files are not existent. Howver, they are existent below "/usr/share/postgresql/11/extension/", so again there is a false setting of the path in the scripts.

2. Issues with gvm-feed-update
Similar problem here, wrong path, wrong ownership.

3. Issue with gvm-check-setup
There is a problem with the check and the fix. The script is telleing

----
Step 5: Checking user ...
        ERROR: No users found. You need to create at least one user to log in.
        It is recommended to have at least one user with role Admin.
        FIX: create a Admin user by running 'sudo runuser -u _gvm -- gvmd --create-user=<name> --new-password=<password>'

 ERROR: Your GVM-11 installation is not yet complete!

Please follow the instructions marked with FIX above and run this
script again.
----

The command for creating the user does not work, regardless if the user exists or not exists.
Besides, the command "sudo" is not needed, as I am running as usual as root (this is, because I have kali installed some years ago where running as root was recommended. Iknow, fresh installed kali versions are using "kali" as user). However, maybe sudo might still be wrong.

4. Issue gvm-start
I get an error when starting

So far, this is what I discovered. Even when correcting paths and ownerships, I still got gvm and gvmd not started. IMO this is because still a user is missing (see above issues).

I believe, the packages are made for Ubuntu and not for Debian, which kali is based of (sudo is typically Ubuntu style!), so maybe the packages / scripts are not fully compatible.

It would be nice, if these could be fixed. Thank you very much for any help.

Best regards

Hans
Steps To ReproduceMy steps:
Deinstalled all related packages and removed remaining directories manually. Then reinstalled evberything and tried to do an initial setup. Got into the same issues again. manually corrected paths and ownerships, as the scripts needed, but only with partial success.

Activities

Diezel

2020-08-02 15:14

reporter   ~0013160

Hello! Confirm this, i am stuck on this step:
     FIX: create a Admin user by running 'sudo runuser -u _gvm -- gvmd --create-user=<name> --new-password=<password>
The command doesn't create user and i can't go furhter

vanguard

2020-08-02 17:08

reporter   ~0013161

Following the documentation to change from openvas7 to gvm11, I could add a user and start the webinterface. However, gvmd is still not running, so I get error at login.

alara

2020-08-03 09:18

reporter   ~0013162

Hi Manteiners.

As reported by "vanguard", I tested on four test devices and the migration from 9 to 11 not working properly.

For all, I folowed all steps (MIGRATION-FROM-9-TO-11.txt) and see below erros that I found:

Error is: GMP Service is down (image0.jpg)

1 - ospd and gmvd not working properly: /run/ospd/ and /run/gvm/ was not created during the migration process (image 2.jpg).

Do you know a possible solution for it? or if you have a plan to adjust?

Have an excellent new week.

Alisson Lara

image0.png (40,999 bytes)
image0.png (40,999 bytes)
image2.png (111,725 bytes)
image2.png (111,725 bytes)

sbrun

2020-08-03 14:21

manager   ~0013164

@vanguard Thanks for the detailed report.

1. Issues with gvm-setup
> directory given by the script is /var/lib/openvas/plugins
I don't think I can change this.The openvas-scanner post installation script already adds the user _gvm and gives him permissions to the directory.
But as you've made an upgrade you needed to change manually the permissions within the directories (as we documented in MIGRATION-FROM-9-TO-11)
We kept the path set to /var/lib/openvas/ like upstream.

1.1. Postgresql issue
It's not an issue with gvm, rather a problem with old postgresql versions on your machine. I don't think that gvm has never been tested with postgresql 9.1
You should try to upgrade your postgresql installation (with pg_upgradecluster I think)

2. gvm-feed-update
Same as mentioned in 1.
The openvas-scanner and gvmd post installation script add the user _gvm and give him permissions to the directories.
But yes you need to manually change the permissions within the directories.

3. Issue with gvm-check-setup
> ERROR: No users found. You need to create at least one user to log in.
I will change the test in the gvm-check-setup script, it's not correct (for the moment It will always fail if you don't have a user named admin).
And the command is not correct too. It should be 'sudo runuser -u _gvm -- gvmd --create-user=<name> --password=<password>'
I will fix it.

> The command for creating the user does not work, regardless if the user exists or not exists.
Do you have an error to help me to fix this? You need to have postgresql.service active. Or maybe is it because you always have the error message with gvm-check-setup?
You can check if the user exists with " sudo runuser -u _gvm -- gvmd --get-users"

4. Issue gvm-start / gvmd not running
I will need more information to understand the issue.
@alara mentioned that /run/ospd and /run/gvm are not created during the migration process. Yes it's true and it's normal. The /run/* dirs are removed on each reboot.
These directories are created by the services. If the service fails to start, they won't be created. And they are removed when the services are stopped.
Can you check/share the log: /var/log/gvm/gvmd.log?
It's possible to have a more verbose log by changing /etc/gvm/gvmd_log.conf

vanguard

2020-08-03 15:06

reporter   ~0013166

@sbrun
---
1. Issues with gvm-setup
> directory given by the script is /var/lib/openvas/plugins
I don't think I can change this.The openvas-scanner post installation script already adds the user _gvm and gives him permissions to the directory.
But as you've made an upgrade you needed to change manually the permissions within the directories (as we documented in MIGRATION-FROM-9-TO-11)
We kept the path set to /var/lib/openvas/ like upstream.
---
(My answer marked with "V:")

V: Yes, that point can be manually fixed like described in MIGRATION-FROM-9-TO-11, but I think, the installer of gvm should change the owner automatically. Maybe this can be fixed.


---
1.1. Postgresql issue
It's not an issue with gvm, rather a problem with old postgresql versions on your machine. I don't think that gvm has never been tested with postgresql 9.1
You should try to upgrade your postgresql installation (with pg_upgradecluster I think)

V: Oh, here you did not quite understand me correctly. The files are below /usr/share/postgresql/12/extensions/ (what is the correct actual version), but the gvmd is searching below /././postgresql/9.1/extensions/ (which is the old version) so it is a problem by the package, not kali.


---
2. gvm-feed-update
Same as mentioned in 1.
The openvas-scanner and gvmd post installation script add the user _gvm and give him permissions to the directories.
But yes you need to manually change the permissions within the directories.


V: fixed, see above. However, should be corrected within the installer.
---


3. Issue with gvm-check-setup
> ERROR: No users found. You need to create at least one user to log in.
I will change the test in the gvm-check-setup script, it's not correct (for the moment It will always fail if you don't have a user named admin).
And the command is not correct too. It should be 'sudo runuser -u _gvm -- gvmd --create-user=<name> --password=<password>'
I will fix it.

V: Nice! Thank you very much! But please note, that the command "sudo" is not needed in kali, as it is run directly under "root". However, here I might be false and a newly fresh installation is using sudoers today. My kali installation is about 3 years old, a time, where kali is running directly as "root". But if it is today still so, then "sudo" is wrong. To thius related is, that "greenbone-nvt-sync" can not be run as root and requires a unpriviledged user. The other two greenbone-*-sync can be run as root. No idea, why this was changed.
----

> The command for creating the user does not work, regardless if the user exists or not exists.
Do you have an error to help me to fix this? You need to have postgresql.service active. Or maybe is it because you always have the error message with gvm-check-setup?
You can check if the user exists with " sudo runuser -u _gvm -- gvmd --get-users"

V: Checked! Did run the command (as root, why, was already explained), but I get no output.
----

4. Issue gvm-start / gvmd not running
I will need more information to understand the issue.
@alara mentioned that /run/ospd and /run/gvm are not created during the migration process. Yes it's true and it's normal. The /run/* dirs are removed on each reboot.
These directories are created by the services. If the service fails to start, they won't be created. And they are removed when the services are stopped.
Can you check/share the log: /var/log/gvm/gvmd.log?
It's possible to have a more verbose log by changing /etc/gvm/gvmd_log.conf


V: I believe, the packages were 1:1 copied from an Ubuntu repository. But Ubuntu is not Debian and Ubuntu is sometimes making weired things, have old packages (i.e. postgresql) and paths and ownerships are not Debian compatible. So beware of Ubuntu-staff. It may work, but often crashes your system. It would be nice, if the packages could be made Debian compatible. If this does not work, or will be to much work or will be to different, the other choice has to be to install from sources (there is an install script for this). But I am sure, this is not, want we really want.

Whatever, thank you for all the work!!!

Best

Vanguard

rhertzog

2020-08-03 15:24

administrator   ~0013167

@vanguard Please don't assume that you know better than us. Nothing has been taken from Ubuntu. And the error message that you see about "/usr/share/postgresql/9.1/extension/uuid-ossp.control" does not come from us or from gvm but from PostgreSQL so I believe that your default cluster is still running the old version.

Share your output of "pg_lsclusters". I guess that's the default port (5432) is not associated to the latest postgresql version as it should.

If that's the case, please learn how to upgrade your clusters or just get rid of the old postgresql and recreate databases from scratch.

vanguard

2020-08-03 16:25

reporter   ~0013168

I don't want assume to know better than you. But obviously I noticed a bunch of problems, that do not work and none of the package-maintainers did a fix before the release. No reason to attack me, just because I mentioned my thoughts. However, here is my output:

root@kali:~# pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.1 main 5432 online postgres /var/lib/postgresql/9.1/main /var/log/postgresql/postgresql-9.1-main.log
9.4 main 5433 online postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log
9.5 main 5434 online postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
9.6 main 5435 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
10 main 5436 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11 main 5437 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12 main 5438 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log
root@kali:~#

rhertzog

2020-08-03 16:56

administrator   ~0013169

> But obviously I noticed a bunch of problems, that do not work and none of the package-maintainers did a fix before the release.

OpenVAS is a complex piece of software, we did our best with the updates. But mistakes happen and we cannot test all the possible upgrade cases...

You are running a Kali setup that no longer matches what you get from a fresh install. You should not be surprised to have issues from time to time, in particular if you are not taking care to handle usual upgrade tasks like upgrading the default PostgreSQL cluster: see man pg_upgradecluster.

Your default PostgreSQL cluster, the one running on port 5432, is the old version 9.1 (which dates back to 2015 !) and that version is apparently incompatible with the openvas script in charge of configuring the database...

Also you insist that sudo is not required but you should be fully aware that Kali is no longer recommending usage of the root account. So your insistence is somewhat annoying. See https://www.kali.org/news/kali-default-non-root-user/

I'm sorry if you felt attacked but the way you mentioned the Kali packages being based on Ubuntu was not very friendly. It assumed that we just copied stuff without testing it. So you blame us and at the same time, some of the issues are your own fault... don't be surprised if we are annoyed.

vanguard

2020-08-03 17:53

reporter   ~0013170

I am sorry, I didn't want to blame anyone. It is just, that sometimes I had the feeling in the past, that things, I mentioned and put here, are first assumed, as be sent from an "idiot", but are later to be recognized as a correct finding by me. Please note: I deeply respect your work and I cherish all you are doing!

Ok, no hard feelings! Take my apologize.

So, one more problem fixed. I now deinstalled all postgresql versions, except of postgresql-12. Still gwm-setup told me, that it can not find postgresql-9.1 (says it is not installed, which is of course correct). After I purged all old configurations (aptitude purge ~c) the error was gone and the new database created.

Now I am still at the point where also @alara is stuck: Creating a new user.

I tried the following (please remember, that I am still running directly as "root" and do not use sudo. And yes, I know, that kali has changed this some months ago, mentionied it in already in my second post).

1. runuser -u _gvm -- gvmd --create-user=admin --new-password=admin
2. runuser -u _gvm -- gvmd --create-user=admin --password=admin
3. runuser -u _gvm -- gvmd --create-user=testuser --password=usertest
4. runuser -u _gvm -- gvmd --create-user=testuser --new-password=usertest

None of it gave me a new user. As far as I know, the openvas-user has nothing to do with the system users, so I do not need to create a new user by the command adduser.

Checking with the command "runuser -u _gvm -- gvmd --get-users" did not give me any output and, who wonders, "/var/lib/gmv/users/" is empty.

I am sure, running the above command as root or in as a normal user in a "sudoers"-environment using sudo takes in this case no difference.

Hope this helps.

Best

Vanguard

sbrun

2020-08-03 19:11

manager   ~0013173

Can you check the log of gvmd? (/var/log/gvm/gvmd.log)
it should contain more information and help us to understand why you can't create a new user.

vanguard

2020-08-03 19:47

reporter   ~0013174

Youre welcome!

I will send you the log. There is nothing secret in it.

Looks like the database is not correct. Are there relicts from postgresql-9.1? Maybe I should delete all below /var/run/postgresql/ and restart.
@alara Do you have the same messages in your log?

vanguard

2020-08-03 20:08

reporter   ~0013175

New info: A few minutes ago I discovered, there is a new version of gvm in the repo. What is new, that this depends the package "gvm-tools". After installing these, gvm-setup is running in another way as before (for example it is now telling, that the database is already existing).

There is another massage, that still appears:

----
2020-08-03 22:05:08 (819 KB/s) - »service-names-port-numbers.xml« gespeichert [3741309/3741309]

FEHLER: Relation »meta« existiert nicht
ZEILE 1: DELETE FROM meta WHERE name = 'portnames_timestamp';
                     ^
Updated 11541 entries.
----
Not sure, if this is really important, just want to mention it, maybe it helps.

sbrun

2020-08-04 07:42

manager   ~0013176

@vanguard yes I think your database is not correct, maybe because of the old postgresql you had.

This message indicates that the DB has not been initialized correctly:
FEHLER: Relation »meta« existiert nicht
ZEILE 1: DELETE FROM meta WHERE name = 'portnames_timestamp';

When the user creation will be ok, the message will no longer appear.

sbrun

2020-08-04 07:52

manager   ~0013177

Yes I have uploaded a new version of gvm: it fixes the issue of gvm-check-setup you found.
And it installs the tool gvm-tools. It's just a another tool to control GVM. It's not used by the setup.
(https://gvm-tools.readthedocs.io/en/latest/)

I also uploaded new gvmd, ospd-openvas and openvas-scanner to fix small issues.
It should also help to find issue during gvm-start.

vanguard

2020-08-04 09:35

reporter   ~0013179

Got problems with your sucuri firewall, so please take a look at the file.

sbrun

2020-08-04 13:29

manager   ~0013186

no file attached

vanguard

2020-08-04 13:38

reporter   ~0013187

Second try.

vanguard

2020-08-04 14:06

reporter   ~0013194

Third try due to your firewall.

vanguard

2020-08-04 14:17

reporter   ~0013196

Good morning! Thanks for the new packages. Sadly this still did not work. But I believe, I found the cause of the failure.

In gvm.log it says:

    connections on Unix domain socket /var/run/postgresql/.s.PGSQL.5432?

but

ls -la /var/run/postgresql/
insgesamt 8
drwxrwsr-x 3 postgres postgres 120 Aug 4 10:53 .
drwxr-xr-x 43 root root 1260 Aug 4 10:56 ..
drwxr-s--- 2 postgres postgres 140 Aug 4 11:11 12-main.pg_stat_tmp
-rw-r--r-- 1 postgres postgres 5 Aug 4 10:53 12-main.pid
srwxrwxrwx 1 postgres postgres 0 Aug 4 10:53 .s.PGSQL.5438
-rw------- 1 postgres postgres 69 Aug 4 10:53 .s.PGSQL.5438.lock

It is 5438, not 5432. How can I fix this? I believe, this port must be somewhere set. BTW, I also tried to stop postgresql completeley and then let it start new by gvm-setup, but I got the same results as above.

By the way, any idea, why I get errors by your firewall? Is there a special format in my text, which let the firewall act?

vanguard

2020-08-04 14:32

reporter   ~0013198

Something off-topic: Sorry for the last 4 messages / tries. I got into problems with your sucuri firewall. It is not possible, to copy and paste the content of /var/log/gvmd.log and a listing of ls -la /var/run/postgresql/. Somehow some strings of the output is detected as dangerous (maybe the string "root"???). Also it was not possible, to send this in an attachment as a text file. So I had to do several tries, the last one, where I removed most of the content of the logfile and also the word "root" (the prompt), succeeded. I think, this strange behaviour might be interesting.

alara

2020-08-04 14:47

reporter   ~0013199

Hi Sbrun and Vanguard.

Sorry for my late answer and thanks for new packages.

Yes. I tested again on 04 different instances and now I have same issue that Vaguard reported on last note (see attached file).

Gvm.log: connections on Unix domain socket /var/run/postgresql/.s.PGSQL.5432?

and

 I also tried to stop postgresql completely and then let it start new by gvm-setup, but I got the same results as above

and

I also tried to find if this port must be somewhere set but until now I am not able to find it.

Do you have idea how can we fix it?

Have a nice afternoon.

Alisson Lara

image1.png (24,747 bytes)
image1.png (24,747 bytes)

rhertzog

2020-08-04 16:28

administrator   ~0013201

Last edited: 2020-08-04 16:29

View 2 revisions

Can you share again your output of "pg_lsclusters"?

I assume you have a single line but it's still listening on a non-default port.
If that's the case, you should stop postgresql, fix its configuration to indicate the default port, and start it again:

sudo systemctl stop postgresql@12-main.service
sudo sed -i "s/port = .*/port = 5432/" /etc/postgresql/12/main/postgresql.conf
sudo systemctl start postgresql@12-main.service

vanguard

2020-08-04 17:22

reporter   ~0013202

Yes, no problem.

This is original, before my change:

 pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
12 main 5438 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

5438

Now edited postgresql.conf to 5432, and restarted postgresql:
pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
12 main 5432 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

Ok, now it is the correct port.

Testing now gvm-setup to get clear, every steps are configurated, looking good so far.

Now starting, gvm-start, looking good!

Last, adding a new user named testuser, and starting webbrowser pointing to https://127.0.0.1:9392

Try to login, however, the given password in plain text does not work, but the password shown in the shell when creating the new user is working,

Hurrah! Looks like everything is ok now. Wow, that was a long way!

So it was the "wrong" port in postgresql. For me it is looking like either the port in the postgresql package is not correct or the required port in the gvm package. One should be corrected. I never changed any of the default configurations, and postgresql 12 was freshly installed as well as gvmd.

Additionally I found no note, to check for postgresql, but I suggest, we should add this to "MIGRATION-FROM-9-TO-11" so other people might not run into the same trap.

For me it looks like the problem is fixed, but needed lots of manually work. Maybe it is possible, to improve the installer, to change the ownerships of the rerquired directories, creating a user, check for the correct postgresql port and all the stuff, we had to do manually.

For me personally I wondered, why there were the old postgresql version installed, because I am deinstalling regularly all old stuff from kali. I do this with apt autoremove, orphaner and apt-get --purge remove 'deborphan --guess-all' . This worked on my debian systems well, somehow did it not on kali. Please let me watch this in the future.

 @alara Try the same as I did, for me it this bugreport can be closed, but if it is still not working for you, just let it open and close it at your will.

Thank you all very, very for your help and please apologize if I was sometimes a little bit beside me.

Best Vanguard

sbrun

2020-08-05 08:29

manager   ~0013203

@vanguard It's really good news that gvm works now!

We will try to improve at least the gvm-check-setup to detect the postgresql issue: old version and wrong port.
And we will add information in the MIGRATION-FROM-9-TO-11. We didn't experiment this issue during our tests.

I don't think we can automate something for this because we might break users installation:
I was explained that the first version you installed on your machine will create a cluster using the default port 5432.
When you installed a new postgresql version, it will create a new cluster using the next available port 5433 (then 5434 ...)
The user should use pg_upgradecluster to upgrade the old clusters for the latest version and the default port will be again 5432.

For the ownerships of the required directories: we didn't do it automatically during upgrade because it's really not recommended
by Debian (for security reasons) but we will try to find a way to improve this.

Thanks for your your quick answers and for your help / feedback to improve the package.

vanguard

2020-08-06 17:17

reporter   ~0013218

Hi folks,

sorry, to pipe up again with this issue. Today I made a freesh install, and mostly every thing was fine. Even /var/lib/openvas got the correct ownership. Great!

However, I noticed another issue: As greenbone-nvt-sync may no more run as root, it needs to be as a normals user. But - this does not work! I discovered, that there is a rights problem. As the ownership of /var/lib/openvas is set to _gvm:_gvm, you can not write into it. Even the file openvas-feed.lock can not be created.

The solution is this command: "sudo runuser -u _gvm -- greenbone-nvt-sync". I found no information of this in the manual, buit for me this solution looks logical. Or is there any better way?

Diezel

2020-08-06 17:33

reporter   ~0013219

Hi all,
I have noticed the same issue. But for me worked this command " sudo -u _gvm bash " then i greenbone commands started to work.
But after that i got this error
" WARNING: The Redis Database does not exist
        FIX: Run sudo runuser -u _gvm -- openvas -u "
Unfortunately command sudo runuser -u _gvm -- openvas -u doesn't fix this problem.

vanguard

2020-08-06 17:38

reporter   ~0013220

Sorry, correction: It is not /var/lib/openvas/openvas-feed.lock, but /var/lib/openvas/feed-update.lock. My mistake.

Please also note, if something is going wrong or you stopped the download for example with CTL+C, then you have manually to remove the file "feed-update.lock" as user root or user _gvm. Otherwise you can not start greenbone-nvt-sync again, as the system believes, there is already a running process.

Maybe the script could be improved by adding some checks, just an idea.....

vanguard

2020-08-06 18:00

reporter   ~0013221

Another thing, I also noticed: gvm-setup running at the first time is dowenloading the nvt's (just what greenbone-nvt-sync does). If this crashes, and you run gvm-setup again, it does not see, that the greenbone-nvt-sync is incomplete. So it does not download the missing plugins. The other two (greenbone-scap-sync and greenbone-certdata-sync) are completely running again, when you started gvm-setup again and again.

This also means, that the redis-database might not be correct, as plugins might missing. I am still investigating, what is happening.

kali-bugreport

2020-08-06 20:18

reporter   ~0013222

@vanguard: The left behind feed-update.lock could be already fixed upstream:

https://github.com/greenbone/openvas/pull/527

sbrun

2020-08-07 07:08

manager   ~0013227

@Diezel Please update your installation. You need to get the latest version of gvm : version 11.0.2~kali3
We removed the Redis Database check as it's no longer relevant (redis-database is no longer saved on disk)

sbrun

2020-08-07 07:16

manager   ~0013228

@vanguard I'm not sure to understand the issue with "greenbone-nvt-sync may no more run as root".
On your fresh install: does the gvm-setup fail or succeed?
To be clear: is there an issue in the scripts or "only" in the documentation?

We have a note in the README.Debian provided by gvm to explain that the gvmd commands must be run with
sudo runuser -u _gvm -- ...
I will add information about the greenbone-nvt-sync

vanguard

2020-08-07 07:34

reporter   ~0013229

@sbrun when starting greenbone-nvt-sync as root, it stops and you get the message from it, that you can not start it as root, but as normal user (If this did not change with the latest update) I tested this 3 days ago.

On the fresh install gvm-setup partly succeded. I stopped the script several times because I forgot to check some things before (like ownerships and so on). When I then restarted it, it fails with updating nvt's, due to the left behind feed-update.lock. This should be fixed with the latest upsteam.

Another thing I wondered was the missing message for the needed user, however, I believe during the install a user "admin" was created. I believe, I missed some docs about this thing, as I got no password for the user admin. I am sure, the default password is documented somewhere, but I was lazy and just created a new one with --new-password= using gvmd. More my fault!

Lazy again, the latest README.Debian I did not read. I did the fresh install with the knowledge of 3 days ago, so the last changes in the documents passed me somehow. I must say, during the last days a ton of changes were made in this packages and new infos killed the old ones. It is amazing to see the progress.

vanguard

2020-08-07 07:46

reporter   ~0013230

@sbrun I tested again on my fresh installed machine (updated a few minutes ago).

greenbone-nvt-sync started as root is telling/usr/bingreenbone-nvt-sync must not be executed as rprivilged user root

Unlike the actual scanner the sync routine does not need privileges.
Accidential execution as root would prevent later overwritinng of
files with a non-privileged user.

This message is logical correct. Maybe the message could be enhanced with the following text:

As privileged user "root" run: "runuser -u _gvm -- greenbone-nvt-sync"
As standard user run: "sudo runuser -u _gvm -- greenbone-nvt-sync"

Think, this will be helpfull for others,

sbrun

2020-08-07 10:47

manager   ~0013237

@vanguard I will update the README.Debian to help users to know minimal steps to setup gvm on a fresh install or if it's a migration.

I will import the upstream patch for the feed-update.lock issue and add a explicit message in greenbone-nvt-sync to use _gvm user.

About the password of the created admin user, it's displayed during the gvm-setup. Almost at the end. I will update the gvm-setup to redisplay it at the end.

Yes the gvm-check-setup and gvm-setup can be improved: pull requests are welcome.
https://gitlab.com/kalilinux/packages/gvm

Diezel

2020-08-07 11:20

reporter   ~0013239

@sbrun
 I have tried to do a fresh install. Thanks , now i don't get error regarding Redis-database.

But i am getting this error and i can't create user with this command(user is not created)(screenshot)

I have this output in gvmd.log (screenshot)

Diezel

2020-08-07 11:21

reporter   ~0013240

browser error. Here are the screenshots

image.png (56,543 bytes)
image.png (56,543 bytes)
image-2.png (33,722 bytes)
image-2.png (33,722 bytes)

sbrun

2020-08-07 11:52

manager   ~0013241

@Diezel you need to update your postgres cluster.
Use pg_upgradecluster

Maybe this can help you:
https://community.greenbone.net/t/not-able-to-create-admin-account-gvm-start-not-running-due-to-several-errors-in-kali-linux/6141/13#

Diezel

2020-08-07 18:48

reporter   ~0013244

@sbrun Unfortunately pg_upgradecluster didn't help. I have found that 2 postgres were running: v11(on port 5432) and v12 (on port 5433) I just changed ports in postgres.conf vice- ersa and i was able to create user.
But now i have another error(screenshot)

Thank you very much for your help

image-3.png (56,271 bytes)
image-3.png (56,271 bytes)
image-4.png (189,203 bytes)
image-4.png (189,203 bytes)
image-5.png (138,957 bytes)
image-5.png (138,957 bytes)

sbrun

2020-08-07 19:00

manager   ~0013245

@Diezel I think gvmd is ok.
Your issue is with greenbone-security-assistant.
You must check if _gvm group and _gvm user own the directories and the files in /var/lib/gvm/private
(It should if you use the gvm-setup)

Diezel

2020-08-10 10:50

reporter   ~0013262

thanks for your help.
I want to mention that after reboot i have issues with the redis(see screenshot) and only restarting redis-server helps(systemctl restart redis-server) .

After that i am having runnings openvas service but scan doesn't work. I have this error:
Could not connect to Scanner at /tmp/ospd.sock

How this issue can be solved?

image-6.png (248,742 bytes)
image-6.png (248,742 bytes)
image-7.png (18,813 bytes)
image-7.png (18,813 bytes)

sbrun

2020-08-10 15:58

manager   ~0013264

You ran the obsolete openvas-check-setup (the message is "Your OpenVAS-9 installation...")

Run the "gvm-check-setup" provided by gvm package. And remove your obsolete openvas package to avoid confusion.

I don't know what happened (maybe you reinstalled openvas?) but if I read correctly the message, your redis-server@openvas.service is no longer correctly setup:
in /etc/openvas/openvas.conf you must have:
db_address = /var/run/redis-openvas/redis-server.sock

If you change it, you will need to restart the redis-server@openvas.service

Once you have fix that, if you still have a message error about "Could not connect to Scanner at /tmp/ospd.sock",
maybe your scanner is not configured correctly:
Run "sudo runuser -u _gvm -- gvmd --get-scanners"
The socket should be /var/run/ospd/ospd.sock
You can change it with:
"sudo runuser -u _gvm -- gvmd --modify-scanner=your-scanner-ID --scanner-host=/var/run/ospd/ospd.sock"

And restart the redis-server@openvas.service again

Diezel

2020-08-10 17:47

reporter   ~0013266

@sbrun.
Sorry. i attached the wrong screenshot. I have message containing " Your GVM-11.. ) and i am using gvm(not openvas) package.
I will investigate this issue further(regarding redis-server&gvmd).

Also i have fixed this error (""Could not connect to Scanner at /tmp/ospd.sock").
As you said It was caused by wrong socket path. I changed it but again had problem with the owner of the file ospd.sock. Only after these changes GVM service started to work.

Now i can scan my public resources. but not all of them. I don't why.
Do you know where i can else see logs regarding scan engine. I want to know why it stops in the beginning of some scans.
I start it status changes to "Requested" then immediately changes to "Done" with no results(screenshot).


Thank you very much , i appreciate your help.

image-8.png (14,363 bytes)
image-8.png (14,363 bytes)

Diezel

2020-08-10 17:58

reporter   ~0013267

@sbrun
 I found where to see logs about scanner /var/log/gvm/openvas.log
I had sugh message there (screenshot)
"Consider Alive" option helped me to scan hosts like this
Sorry for disturbing you.
Many thanks,

image-9.png (9,281 bytes)
image-9.png (9,281 bytes)

Issue History

Date Modified Username Field Change
2020-08-01 08:39 vanguard New Issue
2020-08-02 15:14 Diezel Note Added: 0013160
2020-08-02 17:08 vanguard Note Added: 0013161
2020-08-03 09:18 alara File Added: image0.png
2020-08-03 09:18 alara File Added: image2.png
2020-08-03 09:18 alara Note Added: 0013162
2020-08-03 09:34 sbrun Assigned To => sbrun
2020-08-03 09:34 sbrun Status new => assigned
2020-08-03 14:21 sbrun Note Added: 0013164
2020-08-03 15:06 vanguard Note Added: 0013166
2020-08-03 15:24 rhertzog Note Added: 0013167
2020-08-03 16:25 vanguard Note Added: 0013168
2020-08-03 16:56 rhertzog Note Added: 0013169
2020-08-03 17:53 vanguard Note Added: 0013170
2020-08-03 19:11 sbrun Note Added: 0013173
2020-08-03 19:47 vanguard Note Added: 0013174
2020-08-03 20:08 vanguard Note Added: 0013175
2020-08-04 07:42 sbrun Note Added: 0013176
2020-08-04 07:52 sbrun Note Added: 0013177
2020-08-04 09:35 vanguard Note Added: 0013179
2020-08-04 13:29 sbrun Note Added: 0013186
2020-08-04 13:38 vanguard Note Added: 0013187
2020-08-04 14:06 vanguard Note Added: 0013194
2020-08-04 14:17 vanguard Note Added: 0013196
2020-08-04 14:32 vanguard Note Added: 0013198
2020-08-04 14:47 alara File Added: image1.png
2020-08-04 14:47 alara Note Added: 0013199
2020-08-04 16:28 rhertzog Note Added: 0013201
2020-08-04 16:29 rhertzog Note Edited: 0013201 View Revisions
2020-08-04 17:22 vanguard Note Added: 0013202
2020-08-05 08:29 sbrun Note Added: 0013203
2020-08-06 17:17 vanguard Note Added: 0013218
2020-08-06 17:33 Diezel Note Added: 0013219
2020-08-06 17:38 vanguard Note Added: 0013220
2020-08-06 18:00 vanguard Note Added: 0013221
2020-08-06 20:18 kali-bugreport Note Added: 0013222
2020-08-07 07:08 sbrun Note Added: 0013227
2020-08-07 07:16 sbrun Note Added: 0013228
2020-08-07 07:34 vanguard Note Added: 0013229
2020-08-07 07:46 vanguard Note Added: 0013230
2020-08-07 10:47 sbrun Note Added: 0013237
2020-08-07 11:20 Diezel Note Added: 0013239
2020-08-07 11:21 Diezel File Added: image.png
2020-08-07 11:21 Diezel File Added: image-2.png
2020-08-07 11:21 Diezel Note Added: 0013240
2020-08-07 11:52 sbrun Note Added: 0013241
2020-08-07 18:48 Diezel File Added: image-3.png
2020-08-07 18:48 Diezel File Added: image-4.png
2020-08-07 18:48 Diezel File Added: image-5.png
2020-08-07 18:48 Diezel Note Added: 0013244
2020-08-07 19:00 sbrun Note Added: 0013245
2020-08-10 10:50 Diezel File Added: image-6.png
2020-08-10 10:50 Diezel File Added: image-7.png
2020-08-10 10:50 Diezel Note Added: 0013262
2020-08-10 15:58 sbrun Note Added: 0013264
2020-08-10 17:47 Diezel File Added: image-8.png
2020-08-10 17:47 Diezel Note Added: 0013266
2020-08-10 17:58 Diezel File Added: image-9.png
2020-08-10 17:58 Diezel Note Added: 0013267