Hi everyone,
I installed everything from sources. When I try to update nvt (with greenbone-nvt-sync), I get an error which say that many files weren’t transfered (error code 23). However, when nvt sync is processing, I don’t see any issue. When I try to run again greenbone-nvt-sync, nothing appears. I looked into log file but I only see that “Rsync failed” and nothing else.
Systemctl tells me that rsync service is inactive. The issue is due to there is no /etc/rsyncd.conf file by default. I see a lot of different topics on installing GVM but anyone talks about rsync configuration.
There is no rsync configuration file needed. The greenbone-nvt-sync script is a standalone, rsync client script, which will update your NVT feeds. That’s it.
The problem you’re facing might just be:
Greenbone RSYNC server may just be full. In that case, try again later.
You have a firewall / Network accelerator / broken proxy in the middle which breaks the rsync transfer
From my experience doing the NVT feed synchronization via RYSNC often fails. You may need to retry several times until it actually works. Another option is to use the --wget flag; which force the script to use HTTP instead of RSYNC. It works much better but is unfortunately overkill from a network bandwidth perspective and slower.
I got the same issue as jacksighi, my nvt sync failed because I loosed my internet connection few seconds but when I try to sync nvt again, nothing happens and an error occurs.
TCP should be stable even over a few seconds even minutes So that must be a setup issue in your network topology. If you got a new IP, that is of course a different story. You need to wait until the session is expired on our sync host until then you can´t establish a new session.
Please read the posts how to sync correctly and how to debug this:
@jacksighi@Alyesia could you check if the $install_prefix/var/run/feed-update.lock file still exists? Not sure how you build GVM therefore $install_prefix may be an empty string, /usr/local/ or something else. If that file exists you have to remove it.
Just to add to what Bricks said; when that happens your scanner will refuse to start scans because it will consider an update is pending. So if you’re using cron scripts to update your NVTs, make sure you always check at the end of your scripts that the lock has been removed.
Otherwise not only you won’t be able to restart the update script, but also your scanner will refuse to run tasks.
So that must be a setup issue in your network topology. If you got a new IP, that is of course a different story. You need to wait until the session is expired on our sync host until then you can´t establish a new session.