There is no database named "scap" in PostgreSQL

[musagul]

Hello Dear community family,

At the end of the story i’m here to create my topic.

My story starts to find a Community Free solution for a network scanner. I’ve been working in the IT & SEC Industry for almost 11 years and happy to be here.

Problem Definition: I’ve done fresh kali installation with updates and upgrades. Then i installed openvas and gvm-setup and checked all. Everything works fine with permissions and roles. However, when the installation finishes, i get this error in CVEs under Web UI:

“The SCAP database is required”

I’ve read in forum and find something useful here: Greenbone Thread Link

Here are my logs of gvmd:

md manage:   INFO:2023-11-03 13h08.24 UTC:50838: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-03 13h08.24 UTC:50837: update_scap: Updating data from feed
md manage:   INFO:2023-11-03 13h08.24 UTC:50837: Updating CPEs
md   main:MESSAGE:2023-11-03 13h11.03 utc:52199:    Greenbone Vulnerability Manager version 23.0.0 (DB revision 255)
md manage:MESSAGE:2023-11-03 13h11.03 utc:52200: No SCAP database found
md manage:WARNING:2023-11-03 13h11.05 UTC:52230: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-03 13h11.05 UTC:52232: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-03 13h11.05 UTC:52230: update_scap: Updating data from feed
md manage:   INFO:2023-11-03 13h11.05 UTC:52230: Updating CPEs
md   main:MESSAGE:2023-11-03 13h13.43 utc:53478:    Greenbone Vulnerability Manager version 23.0.0 (DB revision 255)
md manage:MESSAGE:2023-11-03 13h13.43 utc:53487: No SCAP database found
md manage:WARNING:2023-11-03 13h13.44 UTC:53509: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-03 13h13.44 UTC:53510: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-03 13h13.44 UTC:53509: update_scap: Updating data from feed
md manage:   INFO:2023-11-03 13h13.44 UTC:53509: Updating CPEs
md   main:MESSAGE:2023-11-03 13h16.12 utc:54757:    Greenbone Vulnerability Manager version 23.0.0 (DB revision 255)
md manage:MESSAGE:2023-11-03 13h16.12 utc:54758: No SCAP database found
md manage:WARNING:2023-11-03 13h16.13 UTC:54797: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-03 13h16.13 UTC:54796: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-03 13h16.14 UTC:54797: update_scap: Updating data from feed
md manage:   INFO:2023-11-03 13h16.14 UTC:54797: Updating CPEs
md   main:MESSAGE:2023-11-03 13h19.05 utc:56170:    Greenbone Vulnerability Manager version 23.0.0 (DB revision 255)
md manage:MESSAGE:2023-11-03 13h19.05 utc:56179: No SCAP database found
md manage:WARNING:2023-11-03 13h19.06 UTC:56209: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-03 13h19.06 UTC:56210: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-03 13h19.07 UTC:56209: update_scap: Updating data from feed
md manage:   INFO:2023-11-03 13h19.07 UTC:56209: Updating CPEs
md manage:WARNING:2023-11-03 13h21.26 UTC:57260: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-03 13h21.26 UTC:57261: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md   main:MESSAGE:2023-11-03 13h21.27 utc:57269:    Greenbone Vulnerability Manager version 23.0.0 (DB revision 255)
md manage:MESSAGE:2023-11-03 13h21.27 utc:57270: No SCAP database found
md manage:WARNING:2023-11-03 13h21.27 UTC:57300: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-03 13h21.27 UTC:57302: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-03 13h21.27 UTC:57300: update_scap: Updating data from feed
md manage:   INFO:2023-11-03 13h21.27 UTC:57300: Updating CPEs

I’ve been researching for this problem and tried to start from strach for installation of Kali and OpenVAS again and again. When i see that the problem on the threat is solved by changing the owner of “scap” database to _gvm, i wanted to try it, however when i check the database, the result:

gvmd=# gvmd=#\dn
      List of schemas
  Name  |       Owner       
--------+-------------------
 cert   | _gvm
 public | pg_database_owner
 scap2  | _gvm
(3 rows)

Kali version: Linux kali 6.5.0-kali2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1kali2 (2023-10-03) x86_64 GNU/Linux

Could you please help me to understand what way should i follow to fix the problem.
Could you also share with me the best practice (Best OS to Deploy OpenVas and best versions of postgre or etc.)

Thanks!

[rippledj]

While some in this post advise you to change the owner of the database, I think this answer will solve the issue:

During any installation including the Kali installation, the database can take a long time to build. If you log into the web-interface and check the Administration -> Feed Status page and see that the status is “Update in progress”, then the solution is to simply wait.

The answer is also the same here.

[musagul]

Hello rippledj,

I would like to thank you with all my heart to you. I’ve also read the same suggestion in another topics. I’ve waited so long at the same day.

For the solution;

I do not know what have exactly solved the issue but, i started kali today and just did “gvm-start” and before that i have tailed the logs and it automatically worked.

md   main:MESSAGE:2023-11-06 07h27.13 utc:2250:    Greenbone Vulnerability Manager version 23.0.0 (DB revision 255)
md manage:MESSAGE:2023-11-06 07h27.13 utc:2251: No SCAP database found
md manage:   INFO:2023-11-06 07h27.13 UTC:2282: osp_scanner_feed_version: No feed version available yet. OSPd OpenVAS is still starting
md manage:WARNING:2023-11-06 07h27.13 UTC:2283: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-11-06 07h27.14 UTC:2283: update_scap: Updating data from feed
md manage:   INFO:2023-11-06 07h27.14 UTC:2283: Updating CPEs
md manage:   INFO:2023-11-06 07h30.39 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2002.xml
md manage:   INFO:2023-11-06 07h30.47 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2017.xml
md manage:   INFO:2023-11-06 07h31.11 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2007.xml
md manage:   INFO:2023-11-06 07h31.22 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2010.xml
md manage:   INFO:2023-11-06 07h31.29 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2021.xml
md manage:   INFO:2023-11-06 07h32.10 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2015.xml
md manage:   INFO:2023-11-06 07h32.19 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2019.xml
md manage:   INFO:2023-11-06 07h32.57 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2023.xml
md manage:   INFO:2023-11-06 07h33.22 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2008.xml
md manage:   INFO:2023-11-06 07h33.57 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2005.xml
md manage:   INFO:2023-11-06 07h34.06 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2018.xml
md manage:   INFO:2023-11-06 07h34.38 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2022.xml
md manage:   INFO:2023-11-06 07h35.17 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2004.xml
md manage:   INFO:2023-11-06 07h35.22 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2013.xml
md manage:   INFO:2023-11-06 07h35.32 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2003.xml
md manage:   INFO:2023-11-06 07h35.34 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2020.xml
md manage:   INFO:2023-11-06 07h36.06 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2006.xml
md manage:   INFO:2023-11-06 07h36.15 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2012.xml
md manage:   INFO:2023-11-06 07h36.23 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2016.xml
md manage:   INFO:2023-11-06 07h36.35 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2014.xml
md manage:   INFO:2023-11-06 07h36.44 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2011.xml
md manage:   INFO:2023-11-06 07h36.52 UTC:2283: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2009.xml
md manage:   INFO:2023-11-06 07h37.03 UTC:2283: Updating CVSS scores and CVE counts for CPEs
md manage:   INFO:2023-11-06 07h39.46 UTC:2283: Updating placeholder CPEs
md manage:   INFO:2023-11-06 07h41.15 UTC:2283: Updating Max CVSS for DFN-CERT
md manage:   INFO:2023-11-06 07h41.19 UTC:2283: Updating DFN-CERT CVSS max succeeded.
md manage:   INFO:2023-11-06 07h41.19 UTC:2283: Updating Max CVSS for CERT-Bund
md manage:   INFO:2023-11-06 07h41.23 UTC:2283: Updating CERT-Bund CVSS max succeeded.
md manage:   INFO:2023-11-06 07h41.27 UTC:2283: update_scap_end: Updating SCAP info succeeded
md manage:   INFO:2023-11-06 07h41.35 UTC:10004: OSP service has different VT status (version 202311030609) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-11-06 07h45.48 UTC:10004: Updating VTs in database ... 133128 new VTs, 0 changed VTs
md manage:   INFO:2023-11-06 07h45.51 UTC:10004: Updating VTs in database ... done (133128 VTs).

Probable solution, when i first insall the openvas it gets all the updates and sync. Then when it retries to sync scap again and again after installation, it gets blocked by greenbone in that day. However, after a day or a few days, when it retries to sync, it works. It created the database automatically and never says “SCAP database is required”

Note: Before starting the Virtual Machine again, i’ve increased the RAM from 2GB to 4GB and CPU from 2 cores to 4 cores

Thanks for everyone who have commented in this forum for the similar topics. I’ll be helping people when they need anything for the similar cases.

Regards,
Musa

[bricks]

Just to summarize, you need enough RAM >= 4 GiB to be able to parse the the data from the feed. The SCAP database will automatically created by gvmd after the SCAP data from the feed has been successfully parsed. The parsing may not work if you don’t have enough RAM. The SCAP data contains the list of all CVEs and the CPE dictionary. The CPE dictionary (containing all the available CPEs from NIST) has a size of ~1.2 GiB.