[clamav-users] ClamAV mirrors have gotten worse!
dennispe at inetnw.com
Tue Nov 27 07:19:52 UTC 2018
I think these reports don't tell you what you think they mean. In fact they're
pretty much meaningless. The two different servers have different versions of
the signature. That is perfectly normal - there is simply zero chance and it is
naive to think they will always be fully synced in the same second of time of
day. You can infer nothing when this occurs.
In any event these signature serial numbers are associated with the DNS txt
record. The designed process is entirely serial - freshclam knows your installed
signature file serial number, it knows the DNS txt record, and it requests
updates from any of the signature servers if the local version is different from
the DNS txt record. It will try all the mirrors until success or the list of
mirrors is exhausted. Other things that mess with the fully synchronized state
is that DNS caching, TTL, local system clock differences, and policies of
various name service admins to ignore authoritative TTL suggestions.
The database.clamav.net dns is a round robin of 5 different servers and you
cannot predict what you will receive. In fact in the best case the list be
reordered each time you request the A record. And the chances of two different
clients getting the same A record is very low.
Your own local resolver looks in its own cache to see if it has expired. The TTL
record for the TXT record is 1800 seconds. If you use the dig command retrieve
the TXT record you can watch the TTL count down:
dig txt current.cvd.clamav.net |grep TXT
To eliminate this as a problem source you can always use host table entries
rather than dns for your tests. The round robin records ensure reliability for
the client and crude load balancing for the server farm.
So worst case is the record you see can be 1800 seconds behind an updated TXT
record. Obviously polling the current.cvd.clamav.net server directly will return
an uncached record at the expense of recursing queries (use the IP instead of
the hostname to avoid this).
Because these variables exist, freshclam is somewhat fault tolerant and will
retry 3 times per mirror (default and is configurable), and if a mirror is in a
failed state freshclam will map it out of the servers to try next time
(mirrors.dat). The other variable is some of the sync process is demand-driven.
In very busy systems (which these are) stale files should not exist very long.
Your request just might be a trigger to refresh a stale file, and the next
person to hit that server will retrieve the updated file and your system will
move to another mirror. This scenario presumes files are pulled to the mirrors,
I do believe your angst over not having complete system synchronization is
unwarranted as there are too many uncontrollable variables and it's really not
critical if the first mirror doesn't respond.
Finally - the current cloudflare process is pretty solid - it is a vast
improvement over the historical mirror collaboration
On 11/26/18 4:19 PM, Paul Kosinski wrote:
> I believe that the delays we have been observing are due to some
> problem with the Boston Cloudflare servers, or, perhaps, Comcast has a
> "transparent" caching proxy which is causing us trouble.
> I recently installed the same build and configuration of ClamAV 0.100.2
> on our Web server, a virtual machine hosted in NYC. It runs the same
> extra code (curl etc.) to check the cvd version number that we have
> locally. Since Friday, there have been no delays there, although there
> have been several significant delays locally. They check at exactly
> the same time as each other (i.e., via NTP synced cron jobs).
> I also am now running, at each location, simple curls to read the first
> few bytes of the cvd files (to get the version number), *and* to log
> all the headers sent and received. These are also run at exactly the
> same time (as each other) via cron.
> The headers show that our local system uses the 'BOS' Cloudflare server,
> while the remote one uses the 'IAD' server:
> CF-RAY: 47fd0b7af79dae32-BOS
> CF-RAY: 47fd0b8064d9c1b8-IAD
> Interestingly, these two cron jobs sometimes show that the BOS server
> is out of date relative to the IAD server. For example, the following
> curls show that one cvd file served by the BOS server is one version
> behind that served by the IAD server at the *same* time. The files'
> "Last-modified" lines are of particular interest. The BOS server says
> the file was last modified on Mon, 26 Nov 2018 at 06:19:22 GMT, while
> the IAD server says the file was last modified on Mon, 26 Nov 2018 at
> 14:15:24 GMT.
> In particular, the BOS "Date:" header says it's already about 14 mins
> *later* than the IAD "Last-modified:" timestamp indicates. In other
> words, the file delivered by the BOS server is, at time of *delivery*,
> already about 14 minutes out of date.
More information about the clamav-users