I suspect the use of IPv6 would double the number of failures, but each should be counted against a separate IP, so that doesn't strike me as contributing. It would be interesting to know the interval between checks for those experiencing this problem. That, along with knowing how long it takes to update all mirrors after the DNS change is posted might tell us something about that. I know the frequency of checking is supposed to be limited to four per hour, but I know some feel the need to check more often. Given that updates are posted every eight hours, checking more than once an hour doesn't appear to be worth the effort.
As a ClamXAV user, I all but stopped using ClamAV mirrors directly a few years ago, but over the decade or so when I did use them I don't recall seeing "non-synched" more than a hand-full of times, so that's why I can't help but feel that something has changed with the CDN to make that a much more frequently observed occurrence. -Al- On Sun, Jul 01, 2018 at 10:23 PM, Dennis Peterson wrote: > 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 >>> <mailto: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 >>>>>> <mailto: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
