Closed schewara closed 2 years ago
@schewara If you need to quickly fix the problem, you can look at https://github.com/Secure-Compliance-Solutions-LLC/GVM-Docker/pull/297 or you can make the GVMUpdate supervisor job run as root as a quick fix.
@alexandrefresnais Thank you. For testing purposes I mounted the file from #297 into the container and will monitor if it works as expected
Just had another review of the logs and the updates seem to be working mostly
md manage: INFO:2021-11-11 23h46.16 utc:6153: OSP service has different VT status (version 202111111129) from database (version 202110
221034, 77259 VTs). Starting update ...
md manage: INFO:2021-11-11 23h46.16 utc:6152: update_scap: Updating data from feed
md manage: INFO:2021-11-11 23h46.16 utc:6152: Updating CPEs
md manage: INFO:2021-11-11 23h47.06 utc:6153: Updating VTs in database ... 312 new VTs, 152 changed VTs
md manage:WARNING:2021-11-11 23h47.07 utc:6153: update_nvts_from_vts: SHA-256 hash of the VTs in the database (540d7b2ba8df1074cac155c9e
c601dc0ee7a588bd883cd9200f145ab07de2110) does not match the one from the scanner (e6dbf5c420c5ff579f37ab8c13308d45f3e59699d23e838afc63cc
1def12d24d).
md main:MESSAGE:2021-11-11 23h47.07 utc:6153: Rebuilding all NVTs because of a hash value mismatch
md manage: INFO:2021-11-11 23h48.50 utc:6152: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2004.xml
md manage: INFO:2021-11-11 23h48.56 utc:6152: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2003.xml
...
Some issues still seem to occur and filling up the logs, or better said the docker logs (The log facility is not working as expected
)
<28>Nov 12 07:46:24 greenbone-nvt-sync: The log facility is not working as expected. All messages will be written to the standard error stream.
<29>Nov 12 07:46:24 greenbone-nvt-sync: No Greenbone Security Feed access key found, falling back to Greenbone Community Feed
<29>Nov 12 07:46:29 greenbone-nvt-sync: Configured NVT rsync feed: rsync://feed.community.greenbone.net:/nvt-feed
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Operation timed out (110)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Address not available (99)
rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]
<27>Nov 12 07:47:00 greenbone-nvt-sync: rsync failed.
Updating GVMd data...
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Operation timed out (110)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Address not available (99)
rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]
Updating SCAP data...
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Operation timed out (110)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Address not available (99)
rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]
Updating CERT data...
rsync: [Receiver] failed to connect to feed.community.greenbone.net (45.135.106.143): Operation timed out (110)
rsync: [Receiver] failed to connect to feed.community.greenbone.net (2a0e:6b40:20:106:20c:29ff:fe7f:d2ae): Address not available (99)
rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]
2021-11-12 07:49:04,836 INFO exited: GVMUpdate (exit status 0; expected)
2021-11-12 07:49:05,839 INFO spawned: 'GVMUpdate' with pid 15942
2021-11-12 07:49:15,853 INFO success: GVMUpdate entered RUNNING state, process has stayed up for > than 10 seconds (startsecs)
Based on the Information, that the community feeds are only updated once a day and greenbone-nvt-sync
seems to be triggered every ~ 8 hours, there might be some server side protection mechanisms in place which are causing this one.
But this is just a wild guess, but nevertheless out of scope of this Bug report.
Once #297 is merged, I think we should be good to close this Issue. :1st_place_medal:
Describe the bug The feeds are not updated automatically, but when running the commands from /etc/periodic/daily/greenbone-nvt-sync manually as gvm user works as expected.
To Reproduce Have the container run for a couple of days and check the logs and the feed status
Expected behavior Feeds get regularly updated
docker-compose log
Host Device:
Image in use:
docker image inspect <image>
:Additional context Add any other context about the problem here.