We use rsync to move the cvd’s out to the mirrors. Using freshclam to get it from the mirrors is the preferred method. Unless you want to donate the time and resources (and bandwidth) to become a mirror.
> On Sep 18, 2014, at 6:28 PM, Al Varnell <alvarn...@mac.com> wrote: > > OK, so I’m a bit confused by this. > > I realize that many of us have different approaches to updating the database, > due to different circumstances in network access, etc., but why are you > downloading daily.cvd five times a day instead of using freshclam to > incrementally update as recommended to all users, if bandwidth is such an > important resource to you? It certainly has a negative impact to the mirror > network if many users are doing this routinely. > > When the main.cvd is updated it will be an incremental update resulting in a > significantly larger main.cld in the database for most users. > > In a separate thread we were told this week that at some point the daily.cvd > would not be routinely available to end users. > > How is the freshclam approach any different from using rsync to you? > > -Al- > > On Thu, Sep 18, 2014 at 02:53 PM, Paul Kosinski wrote: >> >> On Thu, 18 Sep 2014 12:00:00 -0400 >> Joel Esler wrote: >> >>> You are not remembering correctly. That may have been true a decade >>> ago, but for the last half dozen years or so the main stayed the >>> same for every new release and was only updated when it was more >>> efficient to update it than to continue downloading large daily?s. I >>> seem to recall that the last update was late and that there was >>> approximately a year between updates in earlier days, but even that >>> varied. >> >> According to our backup records (see below), in the 2 year period from >> April 2008 to April 2010, there were *7* different main.cvd files (at >> least), or more often than one every two releases (see below). >> >> >>> You may be correct in that it's time for another update, but since >>> it mostly impacts the load on network servers and not you and other >>> clients, that?s something the team will need to analyze and decide. >>> >>> All is correct here. I'll check with the team of when >>> the 'rollover' will take place, as this has a substantial impact on >>> the mirror infrastructure, we have to let the mirrors know before we >>> do it. As you can imagine, the 7M+ users of ClamAV all downloading >>> a main.cvd from a mirror is quite heavy on bandwidth if you aren?t >>> expecting it. >> >> I don't know exactly how big a new main.cvd file would be, but even >> if it were as big as the current main.cvd (62 MB) *plus* the current >> daily.cvd (28 MB) taken together, it would still be only 90 MB, which >> is significantly less than the 140 MB for the 5 updates to the >> daily.cvd file downloaded in one 24 hour period this week. >> >> Paul Kosinski >> >> P.S. Maybe it's time for an 'rsync' or 'drpm' approach for daliy.cvd? >> >> >> ++++++ From our records of CLAMAV files backed up >> >> 0.93 >> -rw-r--r-- 1 clamav clamav 13050207 Apr 15 2008 main.cvd >> >> 0.93.1 >> -rw-r--r-- 1 clamav clamav 13050207 Jun 10 2008 main.cvd.080610-2315 >> >> 0.93.2 >> -rw-r--r-- 1 clamav clamav 15200793 Jul 12 2008 main.cvd.080712-1625 >> >> 0.94 >> -rw-r--r-- 1 clamav clamav 15200793 Sep 6 2008 main.cvd.orig >> -rw-r--r-- 1 clamav clamav 17457430 Sep 4 2008 main.cvd.080904-1709 >> >> 0.94.1 >> -rw-r--r-- 1 clamav clamav 18462921 Nov 7 2008 main.cvd >> >> 0.94.2 >> -rw-r--r-- 1 clamav clamav 18462921 Nov 28 2008 main.cvd.081128-2131 >> >> 0.95 >> -rw-r--r-- 1 clamav clamav 20091559 Mar 26 2009 main.cvd >> >> 0.95.1 >> -rw-r--r-- 1 clamav clamav 20091559 Apr 10 2009 main.cvd.090410-2321 >> >> 0.95.2 >> -rw-r--r-- 1 clamav clamav 21253696 May 14 2009 main.cvd >> >> 0.95.3 >> -rw-r--r-- 1 clamav clamav 21253696 May 14 2009 main.cvd.090514-1231 >> >> 0.96 >> -rw-r--r-- 1 clamav clamav 22906487 Apr 3 2010 main.cvd >> >> 0.96.1 >> -rw-r--r-- 1 clamav clamav 22906487 Apr 3 2010 main.cvd > _______________________________________________ > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
