How to run container with fully initialized data

[wevermind]

I don't know where I can post a question about this docker image so I temporarily post here

My goal is to run a GVM container with fully initialized data to quickly create a new scan, so I find this tag full-data and below is the command I ran:

docker run --detach --publish 9392:9392 --publish 9390:9390 --publish 5432:5432 --publish 2222:22 --name gvm securecompliance/gvm:21.4.3-v1-data-full

The result is not as my expectation. The Web UI started without NVT data (the total number of NVTs in Dashboard is 0) and even the number of Scan configs is 0 too (https://host/scanconfigs). I waited for over 20 minutes but nothing changes.

My question is where did I go wrong with those commands, and how can I get my goal?

[Dexus]

The database is not fully initialized. Only all data is available. This can take up to hours. This is also mentioned by greenbone in the docs: https://greenbone.github.io/docs/gvm-21.04/index.html#starting-services-with-systemd (scroll down to the next red box)

[Dexus]

But I will look how we can fix this, with our setup, so we can really create a full initialized DB.

[wevermind]

@Dexus Thanks for your quick reply Do you have a plan for this or do you have any ideas to create a full initialized DB? I can try to implement this

[Dexus]

In the end it will be very simple:

check the output from gvm-cli .... --xml="<get_feeds/>" (need gvm-tools installes [apk add gvm-tools@custcom]) If there is a <currently_syncing> ?(optional) Present if a sync of this type is underway. XML-Tag - if not its done. (See Docs of GMP)

The service of gvmd needs to run as long as the tag is in the response. At best with a small buffer of 30 seconds before and after the run. Then the GVMD needs to stopped via supervisor.

All this needs to be done in the start.sh

I would love to see your PR.

PS: You're welcome. I try to answer very quick - if I have time. :)

[wevermind]

I started the GVM container from I discussed with you (~8 hours ago) and now the number of scan configs is still 0 as below.

And these are the latest logs

What's wrong here?

[Dexus]

Please have a look to the gvm log folder and the gvmd.log check the latest 50 lines. Also make a supervisorctl status please and Report.

Am 18.08.2021 um 04:43 schrieb wevermind @.***>:

 I started the GVM container from I discussed with you (~8 hours ago) and now the number of scan configs is still 0 as below.

And this is the latest logs

What's wrong here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[wevermind]

@Dexus Sorry, I missed your message so I stopped that container and rerun it in a new VM and it works.

[wevermind]

@Dexus As I understand, the vuln DB will be updated automatically by using supervisor and users don't need to take any else actions?

[Dexus]

@Dexus As I understand, the vuln DB will be updated automatically by using supervisor and users don't need to take any else actions?

Thats correct. When the Container starts all configs and settings will setup, but it need some time. On my systems ~30-45 minutes.

[Dexus]

Updates also done automatic.

[wevermind]

@Dexus Do you have a plan to develop a real full data version of GVM image?

Sorry I'm busy these days so haven't taken a look at the code you mentioned

[wevermind]

@Dexus I wrote my own Dockerfile based on your idea, it's something like this

FROM securecompliance/gvm:21.4.3-v1-data-full

RUN supervisord as a daemon thread

RUN while <scan_config not found> do loop until <scan_config found>

The image is built successfully and I thought that I can use it to run scans immediately. However, when running docker run <image>, everything seems to start over again including creating directory, setting up db, setting up gsa...

So can you let me know how can I prevent the resetting up when I run my docker image?

[wevermind]

I used another trick, clone the initialized container to a new image

docker run securecompliance/gvm:21.4.3-v1-data-full
docker commit <container_id> new_gvm

But when running docker run new_gvm, the aforementioned problem happens again. I guess the script starts setting everything up as new regardless of whether the data is already there or not