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

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.

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)   

@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

@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

@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.

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:~#

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.

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

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.

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?

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.

@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.

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.

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

no file attached

Second try.

Third try due to your firewall.

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?

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.

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)   

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 [email protected]
sudo sed -i "s/port = .*/port = 5432/" /etc/postgresql/12/main/postgresql.conf
sudo systemctl start [email protected]

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

@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.

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?

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.

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.....

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.

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

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

@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)

@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

@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.

@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,

@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

@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)

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)   

@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#

@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)   

@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)

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)   

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 [email protected] 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 [email protected]

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 [email protected] again

@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)   

@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)   

Hi Guys. Sorry for my late answer. My last days was hard.

1 - I tested and followed MIGRATION-FROM-9_TO-11 procedure in three Kali with Openvas-9 instance and now all have same issue: See attached file (image.png).

Strange is: Do not have any file on /run/gvm/gvmd.pid

2 - I still have a problem to create a user:

ERROR: No users found. You need to create at least one user to log in.
FIX: create a user by running 'sudo runuser -u _gvm -- gvmd --create-user=<name> --password=<password>'

My question is: When I cpy the data's from 9 to 10, I think the users that I had on 9 should be keeped, right?

Do you know how can I solve these issues?

Thanks and have an excellend new day.

Alisson Lara

image-10.png (55,253 bytes)   

image-10.png (55,253 bytes)   

@alara yes if you copy the datas from 9 to 11, the users should have been kept.
Check the output of this:
sudo runuser -u _gvm -- gvmd --get-users

Do you have the list of your users?
The gvm-check-setup script had issues: please check if you have the latest version of gvm package (11.0.2+kali4).
If you don't have the latest version, you can upgrade all the gvm packages. We made few changes.

For the issue you have with gvmd service, it may be related to the missing users. The output of the service is not really helpful to understand the issue.
Please check the /var/log/gvm/gvmd.log it should give us the "real" error.
FYI the /run/gvm directory is created by the gvmd.service. It exists as long as the service is active. If the service fails to start or is stopped, the /run/gvm directory is removed.