On Tue, 24 Aug 2004 10:26:50 +0700
Fajar A. Nugraha [EMAIL PROTECTED] wrote:
I'm concerned about the fact that you only use one NS for
cvd.clamav.net though.
There will be at least 6 when the testing period is over.
Is there a fallback scenario (automagically revert to HTTP GETs) if
that NS
Hi,
new freshclam is ready for testing:
Sun Aug 22 02:07:13 CEST 2004 (tk)
--
* freshclam: Support version verification through DNS (DNSDatabaseInfo).
Based on idea by Christopher X. Candreva chris*westnet.com,
see
libresolv don't exist on FreeBSD.
Regards
gmake[2]: Entering directory
`/usr/ports/security/clamav-devel/work/clamav-devel-20040822/clamdscan'
/bin/sh ../libtool --mode=link cc -O3 -pipe -funroll-loops -ffast-math
-march=pentiumpro -I/usr/local/include -L/usr/local/lib -lcipher -o
clamdscan
I still don't see why rsync can't be used here. It can
easily do incremental
updates.
True. However,
(1) many firewall admins allow outgoing HTTP and DNS
ports; I cannot say the same for rsync port.
(2) The uncompressed signature (viruses.db*) files is a
good candidate for rsync (or even
On Saturday 14 August 2004 07:11 am, Jason Haar wrote:
On Sat, Aug 14, 2004 at 01:07:06PM +0700, Fajar Nugraha wrote:
How about incremental updates? Can it possibly make way to
next freshclam versions too?
Too true. Some commercial AVs separate patterns into a library (large)
plus
On Sun, 15 Aug 2004 08:25:36 -0500
Jeremy Kitchen [EMAIL PROTECTED] wrote:
On Saturday 14 August 2004 07:11 am, Jason Haar wrote:
On Sat, Aug 14, 2004 at 01:07:06PM +0700, Fajar Nugraha
wrote:
How about incremental updates?
I still don't see why rsync can't be used here. It can
easily do
At 18:40 15.08.2004, Fajar Nugraha wrote:
On Sun, 15 Aug 2004 08:25:36 -0500
Jeremy Kitchen [EMAIL PROTECTED] wrote:
On Saturday 14 August 2004 07:11 am, Jason Haar wrote:
On Sat, Aug 14, 2004 at 01:07:06PM +0700, Fajar Nugraha wrote:
How about incremental updates?
I still don't see why rsync
Am Friday 13 August 2004 23:23 schrieb Mitch (WebCob):
Hi,
DNS for serial numbers plus HTTP for actual data transfer still sounds
New version of freshclam will work in this way.
the mirrors at all. Once this is tested, an update to recommended polling
times would be appreciated (for
On Fri, 13 Aug 2004 22:34:43 +0200
Tomasz Kojm [EMAIL PROTECTED] wrote:
On Sat, 14 Aug 2004 08:02:51 +1200
Jason Haar [EMAIL PROTECTED] wrote:
DNS for serial numbers plus HTTP for actual data
transfer still sounds
New version of freshclam will work in this way. Big
thanks to all for
the
On Sat, Aug 14, 2004 at 01:07:06PM +0700, Fajar Nugraha wrote:
How about incremental updates? Can it possibly make way to
next freshclam versions too?
Too true. Some commercial AVs separate patterns into a library (large)
plus incremental files (small).
Typically the next library release
On Wed, Aug 11, 2004 at 08:34:48PM +0200, Martin Konold wrote:
The problem with bittorent is that bittorent addresses a different problem
domain.
clamav pattern update:
- frequently changing small number of small files distributed from a single
point to many
bittorrent:
- slowly
On Wed, Aug 11, 2004 at 03:07:35PM +0200, Lionel Bouton wrote:
The ideal setup would be to push updates instead of clients polling
them. It would requires a separate architecture though (HTTP mirrors
can't push things).
Since some time I am thinking of a bittorrent approach too. Bittorrent
On Sat, 14 Aug 2004 08:02:51 +1200
Jason Haar [EMAIL PROTECTED] wrote:
DNS for serial numbers plus HTTP for actual data transfer still sounds
New version of freshclam will work in this way. Big thanks to all for
the interesting thread !
--
oo. Tomasz Kojm [EMAIL PROTECTED]
DNS for serial numbers plus HTTP for actual data transfer still sounds
New version of freshclam will work in this way. Big thanks to all for
the interesting thread !
Sounds cool Tomasz! Be interested to hear if this helps reduce the load on
the mirrors at all. Once this is tested, an update
Similarly, BitTorrent *requires* raw Internet access in order
to operate -
again - not a normal situation for an AV server.
Don't know what exactly you meant by raw as opposed to sauteed, broiled,
baked or toasted, but BitTorrent does NOT require unfirewalled access. It
does require a small
On Fri, 13 Aug 2004, Tomasz Kojm wrote:
New version of freshclam will work in this way. Big thanks to all for
the interesting thread !
That's C-a-n-d-r-e-v-a .
For the CHANGES file.
:-)
-Chris
==
Chris Candreva -- [EMAIL PROTECTED] --
On Fri, Aug 13, 2004 at 02:22:55PM -0700, Mitch (WebCob) wrote:
Don't know what exactly you meant by raw as opposed to sauteed, broiled,
baked or toasted, but BitTorrent does NOT require unfirewalled access. It
does require a small port range to be forwarded to it, BUT that port range
is not
On Aug 11, 2004, at 1:22 PM, Martin Konold wrote:
Am Wednesday 11 August 2004 16:19 schrieb Bart Silverstrim:
Hi Bart,
DNS was developed exactly for this kind of purpose.
Storing non-DNS related information for retrieval? As I understand
the
proposition (and the original lecture that this idea
On Aug 11, 2004, at 10:40 AM, Damian Menscher wrote:
On Wed, 11 Aug 2004, Lionel Bouton wrote:
Since some time I am thinking of a bittorrent approach too. Bittorrent
is quite efficient at distributing files and there are implementations
allowing multiple trackers to distribute the remaining
I've already mentioned this jokingly, but I was half serious: I think
setting up a bittorrent would solve a lot of the bandwidth problems.
Been playing with that a bit recently - the more I think about it, the more
I like it... saw a website that has built a custom tracker to manage
leeches,
Am Mittwoch, 11. August 2004 04:56 schrieb Robert Blayzor:
Hi,
In a perfect world, wouldn't this be the ultimate application for say,
multicast?
No, multicast is not the most efficient solution and does no caching. Honestly
imho the DNS approach is the most feasable and the most efficient
Daniel J McDonald wrote:
That's one of the things that seems to be driving the size of
daily.cvd up - updating main.cvd entails a massive
distribution of files to the world.
Current main.cvd = 1103636 bytes, last updated on July 8
Current daily.cvd = 156470 bytes
A bit of mental arithmetic
On Aug 10, 2004, at 2:30 PM, Jeremy Kitchen wrote:
On Tuesday 10 August 2004 12:23 pm, Damian Menscher wrote:
The gpg-signature prevents spoofing. And the sequence numbers
keep everyone current. The major problems I see are getting clamd to
recognize a message targeted for it, and the obvious
Am Mittwoch, 11. August 2004 13:53 schrieb Bart Silverstrim:
Hi Bart,
the idea does become popular, and clam and other programs out there
start taking advantage of it
DNS was developed exactly for this kind of purpose.
...I don't know about all of you, but I
didn't set up a DNS server on
Martin Konold wrote:
No, multicast is not the most efficient solution and does no caching. Honestly
imho the DNS approach is the most feasable and the most efficient solution as
it provides incoherent caching uses udp and reuses a widly available
infrastructure.
Why would you need caching?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dennis
Peterson
Jeremy Kitchen wrote:
On Tuesday 10 August 2004 02:41 pm, Damian Menscher wrote:
[snip: using a program delivery to process update mailing list mails]
With sendmail, you could add
Christopher X. Candreva wrote the following on 08/10/2004 07:40 PM :
If people can't check for database updates more often than once an hour,
then there is a pressing need.
The mirror page talkes about the need for mirrors, about exponential growth,
and how at least a 10mbit pipe is needed to
On Aug 11, 2004, at 10:32 AM, Martin Konold wrote:
Am Mittwoch, 11. August 2004 13:53 schrieb Bart Silverstrim:
Hi Bart,
the idea does become popular, and clam and other programs out there
start taking advantage of it
DNS was developed exactly for this kind of purpose.
Storing non-DNS related
Am Mittwoch, 11. August 2004 14:47 schrieb Robert Blayzor:
Hi,
No, multicast is not the most efficient solution and does no caching.
Honestly imho the DNS approach is the most feasable and the most
efficient solution as it provides incoherent caching uses udp and reuses
a widly available
On Wed, 11 Aug 2004, Lionel Bouton wrote:
Since some time I am thinking of a bittorrent approach too. Bittorrent
is quite efficient at distributing files and there are implementations
allowing multiple trackers to distribute the remaining server-side load.
Please take this as a question
Am Wednesday 11 August 2004 16:19 schrieb Bart Silverstrim:
Hi Bart,
DNS was developed exactly for this kind of purpose.
Storing non-DNS related information for retrieval? As I understand the
proposition (and the original lecture that this idea was based on),
it's was for hiding
Damian Menscher wrote the following on 08/11/2004 04:40 PM :
On Wed, 11 Aug 2004, Lionel Bouton wrote:
Since some time I am thinking of a bittorrent approach too. Bittorrent
is quite efficient at distributing files and there are implementations
allowing multiple trackers to distribute the
Am Wednesday 11 August 2004 16:40 schrieb Damian Menscher:
Hi,
like Fedora. It tends to start up really slowly (since it has to find
peers) and then speed up. But the speedup doesn't occur until several
megs have been downloaded. If we're only sending a 1-meg main.cvd, then
wouldn't
Lionel Bouton wanted us to know:
Since some time I am thinking of a bittorrent approach too. Bittorrent
is quite efficient at distributing files and there are implementations
allowing multiple trackers to distribute the remaining server-side load.
There's a libbt library written in C that
Opening another port is simply no option for any serious
enterprise use. There
is simply no way to open another port in the firewall. In addition I am
confident that IANA will not allow to reserve a fixed port number
for this
service. After all port numbers are a limited resource with todays
Am Wednesday 11 August 2004 18:56 schrieb Mitch (WebCob):
Hi Mitch,
service. After all port numbers are a limited resource with todays IPv4
networks.
bittorrent doesn't rely on a fixed port - it doesn't need one.
My above comment was an answer to the idea of letting an MTA run on an extra
OK folks, chiming in again with my more or less educated opinion.
DNS was built exactly to distribute fast and reliably small chunks of
information (most or the time address related information to start with).
Is an MX record now exactly an address related information, one would guess
yes. Was
Mitch (WebCob) wrote:
What about a deeper mirroring system? Perhaps one that supports
notification?
One of the things I like about BIND (not enough to use it, but still an
admired concept ;-) is the way zones can be distributed... notification
speeds things up if it works, polling creates a
On Tue, 10 Aug 2004, Fajar A. Nugraha wrote:
The only snag, is that TXT record is limited to a number of bytes ( I tried
putting 4096 bytes on it, it didn't work).
Now, the question is, can the daily (or hourly) updates fit in a single TXT
record?
I don't know that putting ALL of the records
At 16:03 10.08.2004, you wrote:
...
I've also thought about rsync -- if putting the cvd files on an rsync server
would lighten the load at all.
Oh it would, rsync is quite effective. Another possibility might be to
patch the .cvd file(s)
0.02
Erich
THINK
Püntenstrasse 39
8143 Stallikon
Erich Titl wanted us to know:
I've also thought about rsync -- if putting the cvd files on an rsync
server would lighten the load at all.
Oh it would, rsync is quite effective. Another possibility might be to
patch the .cvd file(s)
Agree with rsync, depends how much changes in the file per
Erich Titl wrote the following on 08/10/2004 05:12 PM :
At 16:03 10.08.2004, you wrote:
...
I've also thought about rsync -- if putting the cvd files on an rsync
server
would lighten the load at all.
Oh it would, rsync is quite effective.
Not much with compressed files like *.cvd.
Another
right, but as discussed below, generally bind servers don't have
100k people
waiting for notifications and updates.
Nope, true... but like I suggested, the notification tree doesn't have to be
flat...
One server notifying 10 servers is time consuming and sure - costs a lot
of
On Aug 10, 2004, at 5:57 AM, Jeremy Kitchen wrote:
Mitch (WebCob) wrote:
Just a few ideas...
hey, brainstorming is good, it's just the ideas aren't always ;)
Another stupid idea...how about a mechanism where clam can have updates
pushed to it, so servers controlled by the clam team can distribute
On Tue, 10 Aug 2004, Bart Silverstrim wrote:
Maybe like a modified GPG-signed listserv system only on it's own clam
update daemon port...take a little more configuration since the people
installing clam would have to subscribe and install a GPG key or
something like that in the process, but
On Tue, 10 Aug 2004, Lionel Bouton wrote:
Another possibility might be to patch the .cvd file(s)
That was one proposition I made last year. But in practice it seems there
isn't really a pressing need now.
If people can't check for database updates more often than once an hour,
then
On Tuesday 10 August 2004 12:23 pm, Damian Menscher wrote:
Ok, this is turning into a scary beast. But we already have several
mailing lists (clamav-users, for example) which can obviously handle a
bit of a load. Might be interesting to concoct a specially-formatted
message that the milter
On Tue, 10 Aug 2004, Damian Menscher wrote:
Anyone know if it's really feasible for us to obtain a mailserver that
can send out 2k emails to all (100,000?) users in a short (5-10 mins)
time?
I haven't been following the whole discussion, but I thought this was
mostly to provide support to
On 2004-08-10 14:41:28 -0500, Damian Menscher wrote:
On Tue, 10 Aug 2004, Jeremy Kitchen wrote:
On Tuesday 10 August 2004 12:23 pm, Damian Menscher wrote:
Ok, this is turning into a scary beast. But we already have several
mailing lists (clamav-users, for example) which can obviously
Christopher X. Candreva wrote:
This thread on Trojan.JS.RunMe had me thinking: Hourly virus updates is
better than any of the commercial virus scanners, but obviously still has
issues, especially since a bunch of us obviously submitted updates that had
already been entered. I gather from
On Tue, 2004-08-10 at 12:40, Christopher X. Candreva wrote:
If people can't check for database updates more often than once an hour,
then there is a pressing need.
[...]
If only 1.3% of every update is actually needed, and people only downloaded
what they needed, the traffic on the mirrors
On Tue, Aug 10, 2004 at 10:39:19PM +0200, Peter J. Holzer wrote:
On 2004-08-10 14:41:28 -0500, Damian Menscher wrote:
[... about sending clamav updates quickly to all subscribers]
Anyone know if it's really feasible for us to obtain a mailserver that
can send out 2k emails to all (100,000?)
On Tuesday 10 August 2004 02:41 pm, Damian Menscher wrote:
[snip: using a program delivery to process update mailing list mails]
With sendmail, you could add to /etc/aliases something like:
clamav-updates| sigtool --add
that's the ticket.
Anyone know if it's really feasible for us to
Jeremy Kitchen wrote:
or scrap the whole idea all together :)
Maybe the best thing written on the subject today! ;-) j/k
But really, what's the problem? Shouldn't big time folks complain to
the commercial companies to whom they pay for service and still they got
updates later than Clam? Instead
Jeremy Kitchen wrote:
On Tuesday 10 August 2004 02:41 pm, Damian Menscher wrote:
[snip: using a program delivery to process update mailing list mails]
With sendmail, you could add to /etc/aliases something like:
clamav-updates | sigtool --add
that's the ticket.
And a cool little DOS tool.
OK, here's my pitch
I like the DNS idea as a way to push out just the version number of the
update. This pattern serial number would be the current version of the
CVD file.
A record like this in tinydns:
'dbversion.clamav.net:447:600
would create a DNS TXT record for dbversion.clamav.net with
In a perfect world, wouldn't this be the ultimate application for say,
multicast? Just keep casting the database over and over, when it
changes, you instantly have it! ;-)
--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
PGP: http://www.inoc.net/~dev/
Key fingerprint = 1E02 DABE F989 BC03
The mirror page talkes about the need for mirrors, about
exponential growth,
and how at least a 10mbit pipe is needed to host a mirror. It puts March
2004 traffic at about 120gig/month
I think I read it differently... I thought it was 120GB / month per mirror
(at that point in time there
On Mon, 9 Aug 2004, Christopher X. Candreva wrote:
This thread on Trojan.JS.RunMe had me thinking: Hourly virus updates is
better than any of the commercial virus scanners, but obviously still has
issues, especially since a bunch of us obviously submitted updates that had
already been
On Mon, 2004-08-09 at 16:55 -0400, Christopher X. Candreva wrote:
This thread on Trojan.JS.RunMe had me thinking: Hourly virus updates is
better than any of the commercial virus scanners, but obviously still has
issues, especially since a bunch of us obviously submitted updates that had
On Mon, Aug 09, 2004 at 05:33:05PM -0400, Chris Meadors wrote:
Suppose there was a DNS entry, say virusdb.clamav.net (or
version.virusdb.clamav.net, etc), that returned simply a text record with
the current DB version in it. Then, it would be possible to check the
version with a
What about a deeper mirroring system? Perhaps one that supports
notification?
One of the things I like about BIND (not enough to use it, but still an
admired concept ;-) is the way zones can be distributed... notification
speeds things up if it works, polling creates a failsafe in which a missing
On Monday, August 09, 2004 11:18 PM [EST], Fajar A. Nugraha wrote:
You know, this isn't so crazy after all. I put arbitrary data on my
DNS server so that exim
can get config data using dnsdb lookup. Its cheaper than mysql
lookup (Plus, you eliminate single point of failure),
and you can
63 matches
Mail list logo
