DB trouble on fresh Kali

[enterscanman]

Having trouble syncing/updating with install on fresh kali instance suspecting database issue.

Kali = 2023.1
AWS t2.xl

• 4 vCPU
• 16gb ram
• 30gb ebs

Process:

• sudo apt-get install openvas
• sudo gvm-setup

gvmd.log

md   main:MESSAGE:2023-04-04 15h45.18 utc:22038:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md   main:   INFO:2023-04-04 15h45.18 utc:22038:    Migrating database.
md   main:WARNING:2023-04-04 15h45.18 utc:22038: manage_migrate: no task tables yet, so no need to migrate them
md   main:MESSAGE:2023-04-04 15h45.18 utc:22038: No SCAP database found for migration
md   main:MESSAGE:2023-04-04 15h45.18 utc:22038: No CERT database found for migration
md   main:   INFO:2023-04-04 15h45.18 utc:22038: gvmd: databases are already at the supported version
md   main:MESSAGE:2023-04-04 15h45.18 utc:22044:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-04-04 15h45.18 utc:22044:    Getting users.
md manage:WARNING:2023-04-04 15h45.18 utc:22044: sql_exec_internal: PQexec failed: ERROR:  relation "public.meta" does not exist
LINE 1: SELECT value FROM public.meta WHERE name = 'database_version...
                          ^
 (7)
md manage:WARNING:2023-04-04 15h45.18 utc:22044: sql_exec_internal: SQL: SELECT value FROM public.meta WHERE name = 'database_version';
md manage:WARNING:2023-04-04 15h45.18 utc:22044: sql_x: sql_exec_internal failed
md manage:MESSAGE:2023-04-04 15h45.18 utc:22044: No SCAP database found
md manage:MESSAGE:2023-04-04 15h45.18 utc:22044: No CERT database found
md   main:MESSAGE:2023-04-04 15h45.20 utc:22048:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-04-04 15h45.20 utc:22048:    Creating user.
md manage:MESSAGE:2023-04-04 15h45.20 utc:22048: No SCAP database found
md manage:MESSAGE:2023-04-04 15h45.20 utc:22048: No CERT database found
md   main:MESSAGE:2023-04-04 15h45.20 utc:22057:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-04-04 15h45.20 utc:22057:    Getting users.
md manage:MESSAGE:2023-04-04 15h45.20 utc:22057: No SCAP database found
md manage:MESSAGE:2023-04-04 15h45.20 utc:22057: No CERT database found
md   main:MESSAGE:2023-04-04 15h45.21 utc:22061:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-04-04 15h45.21 utc:22061:    Modifying setting.
md manage:MESSAGE:2023-04-04 15h45.21 utc:22061: No SCAP database found
md manage:MESSAGE:2023-04-04 15h45.21 utc:22061: No CERT database found
md   main:MESSAGE:2023-04-04 16h22.51 utc:22568:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-04-04 16h22.51 utc:22568:    Getting scanners.
md manage:MESSAGE:2023-04-04 16h22.51 utc:22568: No SCAP database found
md manage:MESSAGE:2023-04-04 16h22.51 utc:22568: No CERT database found
event port_list:MESSAGE:2023-04-04 16h22.52 utc:22568: Port list All IANA assigned TCP and UDP (4a4717fe-57d2-11e1-9a26-406186ea4fc5) has been created by admin
event port_list:MESSAGE:2023-04-04 16h22.52 utc:22568: Port list All IANA assigned TCP (33d0cd82-57c6-11e1-8ed1-406186ea4fc5) has been created by admin
event port_list:MESSAGE:2023-04-04 16h22.52 utc:22568: Port list All TCP and Nmap top 100 UDP (730ef368-57e2-11e1-a90f-406186ea4fc5) has been created by admin
event report_format:MESSAGE:2023-04-04 16h22.52 utc:22568: Report format Anonymous XML (5057e5cc-b825-11e4-9d0e-28d24461215b) has been created by admin
event report_format:MESSAGE:2023-04-04 16h22.52 utc:22568: Report format TXT (a3810a62-1f62-11e1-9219-406186ea4fc5) has been created
d by admin
event report_format:MESSAGE:2023-04-04 16h22.52 utc:22568: Report format ITG (77bd6c4a-1f62-11e1-abf0-406186ea4fc5) has been create
d by admin
event report_format:MESSAGE:2023-04-04 16h22.52 utc:22568: Report format PDF (c402cc3e-b531-11e1-9163-406186ea4fc5) has been create
d by admin
event report_format:MESSAGE:2023-04-04 16h22.52 utc:22568: Report format XML (a994b278-1f62-11e1-96ac-406186ea4fc5) has been create
d by admin
event report_format:MESSAGE:2023-04-04 16h22.52 utc:22568: Report format CSV Results (c1645568-627a-11e3-a660-406186ea4fc5) has bee
n created by admin
md   main:MESSAGE:2023-04-04 16h22.52 utc:22572:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-04-04 16h22.52 utc:22572:    Modifying scanner.
md manage:MESSAGE:2023-04-04 16h22.52 utc:22572: No SCAP database found
md manage:MESSAGE:2023-04-04 16h22.52 utc:22572: No CERT database found

Seems like md manage:WARNING:2023-04-04 15h45.18 utc:22044: sql_exec_internal: PQexec failed: ERROR: relation "public.meta" does not exist LINE 1: SELECT value FROM public.meta WHERE name = 'database_version... is the problem

I’ve seen some similar posts (linked below) but they all seem to blame memory/storage and that doesn’t seem to be my problem, please let me know if you have any suggestions.

Thanks in advance!

Clean Install on Kali not working - Feed status Update in progress never complete

Seems there is also some general problem with the database:

Database problem.. thinking

Posting log… have idea??? sudo nano /var/log/gvm/gvmd.log GNU nano 5.4 /var/log/gvm/gvmd.log md main:MESSAGE:2022-02-02 15h53.17 utc:18700: Greenbone Vulnerability Manager version 21.4.4 (DB revision 242) md manage: INFO:2022-02-02 15h53.17 utc:18700: Creating user. md manage:WARNING:2022-02-02 15h53.17 utc:18700: sql_exec_internal: PQexec failed: ERRORE: la relazione “public.meta” non esiste LINE 1: SELECT value FROM pub…

SCAP Database required

Hello, My gvmd is having trouble communicating with the PostgreSQL database it seems. I have determined that the NVTs table exists with around ~63k entries. The database admin is correctly set to my user too. [image] However, as the image suggests, the SCAP database is not correctly generated. This is the gvmd log: md manage: WARNING: 2021-03-05 15h23.05 utc:15584: split _xml_ file: system failed with ret 512, 1 (2), xml_split -s40Mb split.xml && head -n 2 split-00.xml > head.xml && echo '</…

[enterscanman]

And digging into the db, that table definitely exists

gvmd=# select * from public.meta;
 id |        name         |    value
----+---------------------+--------------
 19 | scap_check_time     | 1680187672
 18 | cert_check_time     | 1680184982
 20 | nvts_check_time     | 1680617353
 21 | nvts_feed_version   | 202303311446
 22 | checked_preferences | 1
 23 | database_version    | 250
  2 | update_nvti_cache   | 0
 24 | max_hosts           | 4095
(8 rows)

[enterscanman]

Potential solution? I’m not sure I understand what’s going on here and don’t to just shoot in the dark

$ sudo -u _gvm gvmd --get-users --verbose 
admin xxxx-user-uuid-xxxx
$ sudo -u _gvm gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value xxxx-user-uuid-xxxx
$ sudo gvm-stop
$ sudo runuser -u _gvm -- greenbone-nvt-sync --rsync
$ sudo greenbone-scapdata-sync 
$ sudo greenbone-certdata-sync
$ sudo reboot

Update in progress

This message indicates that gvmd got restarted. It seems gvmd had never enough time to load the SCAP data actually.

[bricks]

@enterscanman

sudo reboot

On Linux you nearly never need to reboot your system. It’s only necessary if you want to run an updated kernel or some important system library like openssl got updated due to a fixed high vulnerability. So rebooting shouldn’t be done in this case. Especially because you downloaded new feed data and our daemons started to load the new data. This just makes things worse.

IMHO you can ignore the “public.meta” related database errors. AFAIK they will go away when all data is loaded.

Again the feed sync consists of two steps:

1. Downloading of new and updated data from the feed via rsync
2. Loading of the data changes into databases via our daemons

Downloading is done via the greenbone sync scripts. Loading of the data is done automatically if the daemons are running. Especially for the first sync when you don’t have any data yet it takes a long time up to several hours. So you need to be patient!

[enterscanman]

@bricks, that was just copied from the solution in the link.

My question is why does gvmd.log continue to report no SCAP db when there definitely is one?

md   main:MESSAGE:2023-03-31 19h17.44 utc:19479:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h17.44 utc:19479:    Getting users.
md manage:WARNING:2023-03-31 19h17.44 utc:19479: sql_exec_internal: PQexec failed: ERROR:  relation "public.meta" does not exist
LINE 1: SELECT value FROM public.meta WHERE name = 'database_version...
                          ^
 (7)
md manage:WARNING:2023-03-31 19h17.44 utc:19479: sql_exec_internal: SQL: SELECT value FROM public.meta WHERE name = 'database_version';
md manage:WARNING:2023-03-31 19h17.44 utc:19479: sql_x: sql_exec_internal failed
md manage:MESSAGE:2023-03-31 19h17.44 utc:19479: No SCAP database found
md manage:MESSAGE:2023-03-31 19h17.44 utc:19479: No CERT database found
md   main:MESSAGE:2023-03-31 19h17.45 utc:19483:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h17.45 utc:19483:    Creating user.
md manage:MESSAGE:2023-03-31 19h17.45 utc:19483: No SCAP database found
md manage:MESSAGE:2023-03-31 19h17.45 utc:19483: No CERT database found
md   main:MESSAGE:2023-03-31 19h17.46 utc:19492:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h17.46 utc:19492:    Getting users.
md manage:MESSAGE:2023-03-31 19h17.46 utc:19492: No SCAP database found
md manage:MESSAGE:2023-03-31 19h17.46 utc:19492: No CERT database found
md   main:MESSAGE:2023-03-31 19h17.46 utc:19496:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h17.46 utc:19496:    Modifying setting.
md manage:MESSAGE:2023-03-31 19h17.46 utc:19496: No SCAP database found
md manage:MESSAGE:2023-03-31 19h17.46 utc:19496: No CERT database found
md   main:MESSAGE:2023-03-31 19h57.03 utc:19783:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h57.03 utc:19783:    Getting scanners.
md manage:MESSAGE:2023-03-31 19h57.03 utc:19783: No SCAP database found
md manage:MESSAGE:2023-03-31 19h57.03 utc:19783: No CERT database found
event port_list:MESSAGE:2023-03-31 19h57.03 utc:19783: Port list All IANA assigned TCP and UDP (4a4717fe-57d2-11e1-9a26-406186ea4fc5) has been created by admin
event port_list:MESSAGE:2023-03-31 19h57.03 utc:19783: Port list All IANA assigned TCP (33d0cd82-57c6-11e1-8ed1-406186ea4fc5) has been created by admin
event port_list:MESSAGE:2023-03-31 19h57.03 utc:19783: Port list All TCP and Nmap top 100 UDP (730ef368-57e2-11e1-a90f-406186ea4fc5) has been created by admin
event report_format:MESSAGE:2023-03-31 19h57.03 utc:19783: Report format Anonymous XML (5057e5cc-b825-11e4-9d0e-28d24461215b) has been created by admin
event report_format:MESSAGE:2023-03-31 19h57.03 utc:19783: Report format TXT (a3810a62-1f62-11e1-9219-406186ea4fc5) has been created by admin
event report_format:MESSAGE:2023-03-31 19h57.03 utc:19783: Report format ITG (77bd6c4a-1f62-11e1-abf0-406186ea4fc5) has been created by admin
event report_format:MESSAGE:2023-03-31 19h57.04 utc:19783: Report format PDF (c402cc3e-b531-11e1-9163-406186ea4fc5) has been created by admin
event report_format:MESSAGE:2023-03-31 19h57.04 utc:19783: Report format XML (a994b278-1f62-11e1-96ac-406186ea4fc5) has been created by admin
event report_format:MESSAGE:2023-03-31 19h57.04 utc:19783: Report format CSV Results (c1645568-627a-11e3-a660-406186ea4fc5) has been created by admin
md   main:MESSAGE:2023-03-31 19h57.04 utc:19787:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h57.04 utc:19787:    Modifying scanner.
md manage:MESSAGE:2023-03-31 19h57.04 utc:19787: No SCAP database found
md manage:MESSAGE:2023-03-31 19h57.04 utc:19787: No CERT database found
md   main:MESSAGE:2023-03-31 19h57.06 utc:19852:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:   INFO:2023-03-31 19h57.06 utc:19852:    Modifying user password.
md manage:MESSAGE:2023-03-31 19h57.06 utc:19852: No SCAP database found
md manage:MESSAGE:2023-03-31 19h57.06 utc:19852: No CERT database found
md   main:MESSAGE:2023-04-05 13h32.08 utc:845:    Greenbone Vulnerability Manager version 22.4.2 (DB revision 250)
md manage:MESSAGE:2023-04-05 13h32.10 utc:846: No SCAP database found
md manage:MESSAGE:2023-04-05 13h32.10 utc:846: No CERT database found
libgvm util:   INFO:2023-04-05 13h32.12 utc:846: starting key generation ...
libgvm util:   INFO:2023-04-05 13h32.13 utc:846: OpenPGP key 'GVM Credential Encryption' has been generated
md manage:   INFO:2023-04-05 13h32.13 utc:877: osp_scanner_feed_version: No feed version available yet. OSPd OpenVAS is still starting
md manage:WARNING:2023-04-05 13h32.13 utc:876: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage:   INFO:2023-04-05 13h32.13 utc:878: Initializing CERT database
md manage:   INFO:2023-04-05 13h32.13 utc:876: update_scap: Updating data from feed
md manage:   INFO:2023-04-05 13h32.13 utc:876: Updating CPEs
md manage:   INFO:2023-04-05 13h32.13 UTC:878: sync_cert: Updating data from feed
md manage:   INFO:2023-04-05 13h32.13 UTC:878: update_dfn_xml: dfn-cert-2013.xml
md manage:   INFO:2023-04-05 13h32.13 UTC:878: Updating /var/lib/gvm/cert-data/dfn-cert-2013.xml
md manage:   INFO:2023-04-05 13h32.16 UTC:878: update_dfn_xml: dfn-cert-2015.xml
md manage:   INFO:2023-04-05 13h32.16 UTC:878: Updating /var/lib/gvm/cert-data/dfn-cert-2015.xml
...skipping...
md manage:   INFO:2023-04-05 13h38.10 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2004.xml
md manage:   INFO:2023-04-05 13h38.15 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2005.xml
md manage:   INFO:2023-04-05 13h38.22 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2020.xml
md manage:   INFO:2023-04-05 13h39.01 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2022.xml
md manage:   INFO:2023-04-05 13h39.43 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2012.xml
md manage:   INFO:2023-04-05 13h39.54 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2007.xml
md manage:   INFO:2023-04-05 13h40.03 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2015.xml
md manage:   INFO:2023-04-05 13h40.14 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2021.xml
md manage:   INFO:2023-04-05 13h40.59 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2008.xml
md manage:   INFO:2023-04-05 13h41.11 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2002.xml
md manage:   INFO:2023-04-05 13h41.19 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2013.xml
md manage:   INFO:2023-04-05 13h41.30 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2019.xml
md manage:   INFO:2023-04-05 13h42.18 UTC:876: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2017.xml
md manage:   INFO:2023-04-05 13h42.42 UTC:876: Updating CVSS scores and CVE counts for CPEs
md manage:   INFO:2023-04-05 13h44.39 UTC:876: Updating placeholder CPEs
md manage:   INFO:2023-04-05 13h44.51 UTC:876: Updating Max CVSS for DFN-CERT
md manage:   INFO:2023-04-05 13h44.53 UTC:876: Updating DFN-CERT CVSS max succeeded.
md manage:   INFO:2023-04-05 13h44.53 UTC:876: Updating Max CVSS for CERT-Bund
md manage:   INFO:2023-04-05 13h44.54 UTC:876: Updating CERT-Bund CVSS max succeeded.
md manage:   INFO:2023-04-05 13h44.56 UTC:876: update_scap_end: Updating SCAP info succeeded
md manage:   INFO:2023-04-05 13h44.58 UTC:1320: OSP service has different VT status (version 202303311446) from database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2023-04-05 13h54.16 UTC:1320: Updating VTs in database ... 126987 new VTs, 0 changed VTs
md manage:   INFO:2023-04-05 13h54.18 UTC:1320: Updating VTs in database ... done (126987 VTs).
event config:MESSAGE:2023-04-05 13h54.21 UTC:1536: Scan config Huawei Datacom Product Security Configuration Audit Guide (aab5c4a1-eab1-4f4e-acac-8c36d08de6bc) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.21 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.100509:6 has changed from 'Report vulnerabilities of inactive Linux Kernel(s) separately' to 'Report vulnerabilities of inactive Linux Kernel(s) separately (only for GOS 21.04 and older)'.
md manage:MESSAGE:2023-04-05 13h54.21 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.23 UTC:1536: Scan config EulerOS Linux Security Configuration (0362e8f6-d7cc-4a12-8768-5f2406713860) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.23 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.23 UTC:1536: Scan config empty (085569ce-73ed-11df-83c3-002264764cea) has been created by admin
event config:MESSAGE:2023-04-05 13h54.23 UTC:1536: Scan config Base (d21f6c81-2b88-4ac1-b7b4-a2a9f2ad4663) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.23 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.100509:6 has changed from 'Report vulnerabilities of inactive Linux Kernel(s) separately' to 'Report vulnerabilities of inactive Linux Kernel(s) separately (only for GOS 21.04 and older)'.
md manage:MESSAGE:2023-04-05 13h54.23 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.24 UTC:1536: Scan config Log4Shell (e3efebc5-fc0d-4cb6-b1b4-55309d0a89f6) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.24 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.100509:6 has changed from 'Report vulnerabilities of inactive Linux Kernel(s) separately' to 'Report vulnerabilities of inactive Linux Kernel(s) separately (only for GOS 21.04 and older)'.
md manage:MESSAGE:2023-04-05 13h54.24 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.25 UTC:1536: Scan config openGauss Security Hardening Guide (c2b049f9-6d3d-45be-871f-2252895ed9e8) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.25 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.100509:6 has changed from 'Report vulnerabilities of inactive Linux Kernel(s) separately' to 'Report vulnerabilities of inactive Linux Kernel(s) separately (only for GOS 21.04 and older)'.
md manage:MESSAGE:2023-04-05 13h54.25 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.26 UTC:1536: Scan config GaussDB Kernel V500R001C00 Security Hardening Guide (2eec8313-fee4-442a-b3c4-fa0d5dc83d61) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.26 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.100509:6 has changed from 'Report vulnerabilities of inactive Linux Kernel(s) separately' to 'Report vulnerabilities of inactive Linux Kernel(s) separately (only for GOS 21.04 and older)'.
md manage:MESSAGE:2023-04-05 13h54.26 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.27 UTC:1536: Scan config IT-Grundschutz Kompendium (c4b7c0cb-6502-4809-b034-8e635311b3e6) has been created by admin
event config:MESSAGE:2023-04-05 13h54.27 UTC:1536: Scan config System Discovery (bbca7412-a950-11e3-9109-406186ea4fc5) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.27 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
event config:MESSAGE:2023-04-05 13h54.28 UTC:1536: Scan config Full and fast (daba56c8-73ec-11df-a475-002264764cea) has been created by admin
md manage:MESSAGE:2023-04-05 13h54.28 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.10870:1 has changed from 'NTLMSSP' to 'This configuration (NTLMSSP) is deprecated as of 2022-09-23.'.
md manage:MESSAGE:2023-04-05 13h54.29 UTC:1536: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.100509:6 has changed from 'Report vulnerabilities of inactive Linux Kernel(s) separately' to 'Report vulnerabilities of inactive Linux Kernel(s) separately (only for GOS 21.04 and older)'.
event config:MESSAGE:2023-04-05 13h54.29 UTC:1536: Scan config GaussDB 100 V300R001C00 Security Hardening Guide (Standalone) (61327f09-8a54-4854-9e1c-16798285fb28) has been created by admin
event config:MESSAGE:2023-04-05 13h54.29 UTC:1536: Scan config Host Discovery (2d3f051c-55ba-11e3-bf43-406186ea4fc5) has been created by admin
event config:MESSAGE:2023-04-05 13h54.30 UTC:1536: Scan config Discovery (8715c877-47a0-438d-98a3-27c7a6ab2196) has been created by admin

[bricks]

Not sure what you mean. From the logs it seems all things are fine now. I don’t even see additional complains about missing scap database at the end.

[enterscanman]

I’m wondering why it’s saying the SCAP db didn’t exist 3/31 when I did the initial gvm-setup and is still saying that today when I spun the machine up again. Maybe I didn’t give it enough time the first time?

Perhaps a good test now will be trying gvm-feed-update?

[enterscanman]

Is

md manage:WARNING:2023-04-05 14h40.01 utc:4386: update_nvts_from_vts: SHA-256 hash of the VTs in the database (84ac1da690e1fd65a0ce0332a9f76472efe791ce400d4f0b20eb84487cf1cab3) does not match the one from the scanner (35ba09315aca424fafc77b1e125cca3a15a87ebf9d07e9ccd05b855914b999c7).
md   main:MESSAGE:2023-04-05 14h40.01 utc:4386: Rebuilding all NVTs because of a hash value mismatch

from the below normal? I’m getting these entries in gvmd.log after sudo gvm-feed-update

md manage:   INFO:2023-04-05 14h38.17 UTC:4388: sync_cert: Updating data from feed
md manage:   INFO:2023-04-05 14h38.17 UTC:4386: OSP service has different VT status (version 202304051011) from database (version 202303311446, 126987 VTs). Starting update ...
md manage:   INFO:2023-04-05 14h38.17 UTC:4388: update_dfn_xml: dfn-cert-2013.xml
md manage:   INFO:2023-04-05 14h38.17 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2013.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2015.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2015.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4385: update_scap: Updating data from feed
md manage:   INFO:2023-04-05 14h38.18 UTC:4385: Updating CPEs
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2012.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2012.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2008.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2008.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2021.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2021.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2014.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2014.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2022.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2022.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2018.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2018.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2017.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2017.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2023.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2023.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2011.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2011.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2009.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2009.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2010.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2010.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2019.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2019.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2020.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2020.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: update_dfn_xml: dfn-cert-2016.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/dfn-cert-2016.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K13.xml
md manage:   INFO:2023-04-05 14h38.18 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K14.xml
md manage:   INFO:2023-04-05 14h38.19 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K19.xml
md manage:   INFO:2023-04-05 14h38.19 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K17.xml
md manage:   INFO:2023-04-05 14h38.19 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K22.xml
md manage:   INFO:2023-04-05 14h38.19 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K15.xml
md manage:   INFO:2023-04-05 14h38.20 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K23.xml
md manage:   INFO:2023-04-05 14h38.20 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K16.xml
md manage:   INFO:2023-04-05 14h38.20 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K18.xml
md manage:   INFO:2023-04-05 14h38.20 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K20.xml
md manage:   INFO:2023-04-05 14h38.20 UTC:4388: Updating /var/lib/gvm/cert-data/CB-K21.xml
md manage:   INFO:2023-04-05 14h38.20 UTC:4388: Updating Max CVSS for DFN-CERT
md manage:   INFO:2023-04-05 14h38.24 UTC:4388: Updating DFN-CERT CVSS max succeeded.
md manage:   INFO:2023-04-05 14h38.24 UTC:4388: Updating Max CVSS for CERT-Bund
md manage:   INFO:2023-04-05 14h38.26 UTC:4388: Updating CERT-Bund CVSS max succeeded.
md manage:   INFO:2023-04-05 14h38.26 UTC:4388: sync_cert: Updating CERT info succeeded.
md manage:   INFO:2023-04-05 14h40.01 utc:4386: Updating VTs in database ... 51 new VTs, 5213 changed VTs
md manage:WARNING:2023-04-05 14h40.01 utc:4386: update_nvts_from_vts: SHA-256 hash of the VTs in the database (84ac1da690e1fd65a0ce0332a9f76472efe791ce400d4f0b20eb84487cf1cab3) does not match the one from the scanner (35ba09315aca424fafc77b1e125cca3a15a87ebf9d07e9ccd05b855914b999c7).
md   main:MESSAGE:2023-04-05 14h40.01 utc:4386: Rebuilding all NVTs because of a hash value mismatch
md manage:   INFO:2023-04-05 14h40.38 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2014.xml
md manage:   INFO:2023-04-05 14h40.46 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2009.xml
md manage:   INFO:2023-04-05 14h40.59 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2011.xml
md manage:   INFO:2023-04-05 14h41.09 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2006.xml
md manage:   INFO:2023-04-05 14h41.17 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2010.xml
md manage:   INFO:2023-04-05 14h41.26 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2016.xml
md manage:   INFO:2023-04-05 14h41.39 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2003.xml
md manage:   INFO:2023-04-05 14h41.41 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2018.xml
md manage:   INFO:2023-04-05 14h42.17 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2023.xml
md manage:   INFO:2023-04-05 14h42.21 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2004.xml
md manage:   INFO:2023-04-05 14h42.25 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2005.xml
md manage:   INFO:2023-04-05 14h42.31 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2020.xml
md manage:   INFO:2023-04-05 14h43.03 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2022.xml
md manage:   INFO:2023-04-05 14h43.39 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2012.xml
md manage:   INFO:2023-04-05 14h43.49 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2007.xml
md manage:   INFO:2023-04-05 14h43.57 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2015.xml
md manage:   INFO:2023-04-05 14h44.08 UTC:4385: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2021.xml

[enterscanman]

I suppose another question is, what’s a good way to tell if updates are done? gvm-setup gives the terminal back while updates are still happening but I’m trying to build an image that’s ‘ready to go’ and would like to take a snapshot of the image once things are fully updated.

[enterscanman]

My solution for now is to monitor /var/log/gvm/gvmd.log for the pattern Updating VTs in database ... done

[bricks]

I’ve written something about that in the source build guide at https://greenbone.github.io/docs/latest/22.4/source-build/index.html#performing-a-feed-synchronization