# find / -name *report_formats* 2>/dev/null
/usr/local/lib/python3.9/dist-packages/gvm/protocols/gmpv208/entities/__pycache__/report_formats.cpython-39.pyc
/usr/local/lib/python3.9/dist-packages/gvm/protocols/gmpv208/entities/report_formats.py
/var/lib/gvm/data-objects/gvmd/20.08/report_formats
/var/lib/gvm/data-objects/gvmd/21.04/report_formats
/var/lib/gvm/data-objects/gvmd/21.10/report_formats
/var/lib/openvas/plugins/report_formats
You may also test out the container with this command: podman run --name=gvm -it --rm -p 9392:9392 -v gvm-sync:/var/lib/openvas -v gvm-data:/var/lib/gvm -v gvm-postgres:/var/lib/postgresql -v /etc/localtime:/etc/localtime:ro --cap-add=NET_RAW quay.io/keesdejong/gvm:latest
And then check the logs with podman logs -f gvm
and login interactively with podman exec -it gvm bash
Probably you can replace podman
with docker
. But not sure.
I have seen such messages if a manager (gvmd) database was at a database scheme version from versions < 20.08, a migration was done to >= 20.08 but the “old” report formats at $prefix/var/lib/gvm/gvmd/
was missing for the migration to the new location $prefix/var/lib/gvm/data-objects/gvmd/
.
The following existing topic has some more background info:
After update to last version, all old reports are missing.
After migration of the database schema and the call of:
gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value
no reports are show in the ui.
Under the feed status all 4 are up to date.
On the report page I only the this error:
[Screenshot_2020-09-02 Greenbone Security Assistant]
And in the log file of gvm this is shown:
md manage:WARNING:2020-09-02 11h39.29 CEST:24610: run_report_format_script: No generate script …
Hi, thanks for your reply and suggestion. I do set the import owner here. And also removed the database as a whole already. So there shouldn’t be any scheme conflicts.
So is it safe to say that it all works fine for others? With the same version numbers? Do you perhaps use a container? Then I can compare what people do different.
Can no one reproduce this? Because that would be odd, since I compile from source and I’ve done that from scratch in my container for many times already.
Apparently I have to create the folder myself? I also had to do that for some log files already. Is this expected from the user? Shouldn’t the software be creating these directories?
Still run into an issue though:
==> /var/log/gvm/gvmd.log <==
md manage:WARNING:2022-02-19 18h17.01 UTC:27383: run_report_format_script: system failed with ret 256, 1, /var/lib/gvm/gvmd/report_formats/f3e54c46-1930-4608-be32-8715e42aee42/c402cc3e-b531-11e1-9163-406186ea4fc5/generate /tmp/gvmd_nXAmyN/report.xml '<files><basedir>/tmp/gvmd_nXAmyN</basedir></files>' > /tmp/gvmd_nXAmyN/c402cc3e-b531-11e1-9163-406186ea4fc5-9gTqXN.pdf 2> /dev/null
root@cd3ffdec0b4e:/# ls /var/lib/gvm/gvmd/report_formats/
f3e54c46-1930-4608-be32-8715e42aee42
But I’ll experiment more and try to find the magic requirements by trying.
Strange, for those who can’t reproduce it. How do you install it? Maybe an RPM/DEB is creating these directories or maybe the Docker container does. My container is exactly what the docs say what I should do. So I find it a bit strange that no one can reproduce this. I would like to check what I’m missing.
I’ll try the recently released version soon, once I’ve compiled all components.
Oops, sorry I wasn’t super clear on that last post. I’m not sure how common this specific setup is (and within that setup, it doesn’t look so far that anyone has recreated it). My own install is from Greenbone Github source, not in a container.
It might be best to check with the maintainer of the repository https://github.com/kees-closed/gvm since there might be differences with their build that might not be apparent when installing from the Greenbone dos (edit) or try it using all Greenbone sources.
I am the maintainer
And those steps I do in the Dockerfile and in the entrypoint.sh script are directly from the README.md docs on GitHub. I guess I’ll just have to check some DEB source codes myself and spy what other container setups do. Once I’ll know what is done differently, I’ll let it know here.