View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006615||Kali Linux||Kali Package Bug||public||2020-08-01 08:39||2023-10-10 12:25|
|Summary||0006615: gvm not usable due to wrong permissions and paths|
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:
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
ERROR: role "dba" already exists
|Steps To Reproduce|
Hello! Confirm this, i am stuck on this step:
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.
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.
@vanguard Thanks for the detailed report.
1.1. Postgresql issue
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
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.
V: fixed, see above. However, should be corrected within the installer.
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.
V: Checked! Did run the command (as root, why, was already explained), but I get no output.
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!!!
@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:
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).
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.
Can you check the log of gvmd? (/var/log/gvm/gvmd.log)
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.
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
@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:
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.
I also uploaded new gvmd, ospd-openvas and openvas-scanner to fix small issues.
Got problems with your sucuri firewall, so please take a look at the file.
no file attached
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:
ls -la /var/run/postgresql/
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?
I also tried to stop postgresql completely and then let it start new by gvm-setup, but I got the same results as above
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.
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.
Yes, no problem.
This is original, before my change:
Now edited postgresql.conf to 5432, and restarted postgresql:
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.
@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.
I don't think we can automate something for this because we might break users installation:
For the ownerships of the required directories: we didn't do it automatically during upgrade because it's really not recommended
Thanks for your your quick answers and for your help / feedback to improve the package.
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?
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:
@Diezel Please update your installation. You need to get the latest version of gvm : version 11.0.2~kali3
@vanguard I'm not sure to understand the issue with "greenbone-nvt-sync may no more run as root".
We have a note in the README.Debian provided by gvm to explain that the gvmd commands must be run with
@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.
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"
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.
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
@Diezel you need to update your postgres cluster.
@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.
Thank you very much for your help
@Diezel I think gvmd is ok.
thanks for your help.
After that i am having runnings openvas service but scan doesn't work. I have this error:
How this issue can be solved?
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:
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",
And restart the [email protected] again
Also i have fixed this error (""Could not connect to Scanner at /tmp/ospd.sock").
Now i can scan my public resources. but not all of them. I don't why.
Thank you very much , i appreciate your help.
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.
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.
@alara yes if you copy the datas from 9 to 11, the users should have been kept.
Do you have the list of your users?
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.
|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|
|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|
|2020-08-18 06:46||alara||File Added: image-10.png|
|2020-08-18 06:46||alara||Note Added: 0013287|
|2020-08-26 12:04||sbrun||Note Added: 0013322|
|2020-09-16 06:23||sbrun||Status||assigned => resolved|
|2020-09-16 06:23||sbrun||Resolution||open => fixed|
|2020-12-01 10:48||g0tmi1k||Priority||high => normal|
|2023-10-10 12:25||vanguard||Status||resolved => closed|