My interest is if a non-synched mirror would trigger an entry in which case many
false entries are possible. That is a cascading error that would be complicated
by close-in-time updates. Just noodling out of the box a bit, here.
dp
On 7/1/18 9:28 PM, Al Varnell wrote:
As far as the client mirrors.dat file, it's updated locally by freshclam to
indicate either success or failure for a specific IP. After a specific number
of failures (I've forgotten what that is) the IP is given a “time-out” which
precludes it's use until some amount of time passes. Under normal
circumstances, it's self-correcting over time, but what seems to be happening
now is involves multiple failures over an extended time resulting in all
mirrors being locked out, requiring manual intervention to delete the file
which restarts the process.
Sent from my iPad
-Al-
On Jul 1, 2018, at 21:11, Dennis Peterson <denni...@inetnw.com> wrote:
What makes it a problem? You can never dl it until it is available, so the
problem is you become aware of it too soon. But think about what that means.
Your choices are to know immediately when an update is available and try to get
it, or wait until every mirror is synchonized, become notified, then try. The
first choice is a crapshoot you might win. The second choice isn't a crapshoot
but it also doesn't save time. Remembering all this is automated the result is
actually some uninteresting log entries.
It would be interesting to know if an update notice is sent to all mirrors in
the fashion of a DNS notification to slaves which would cause a parallel pull,
or if the update itself is pushed, and what the process is for updating the
client mirrors.dat file.
dp
On 7/1/18 9:01 PM, Al Varnell wrote:
Seems to me that it's only a problem if it takes a significant amount of time
between the DNS update and the mirror updates. I don't have a good feel for how
long that is from the postings so far, but it does sound like it may have
increased as a result of the move from ClamAV mirrors to the ClamAV CDN.
Sent from my iPad
-Al-
On Jul 1, 2018, at 20:38, Dennis Peterson <denni...@inetnw.com> wrote:
On 7/1/18 8:24 PM, Paul Kosinski wrote:
My conclusion is that the cause of this is a typical race condition:
the DNS TXT record is updated before Cloudflare has propagated the new
cvd file to all the mirrors.
Is this a problem?
dp
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
