This has been mentioned at various points in several threads over
the past week or two (sometimes off-hand), but just wanted to somewhat consolidate them here and also
add my +1 to getting this bug addressed in ClamAV soon!
Per [1]:
> This is a ipv4 site, and I occasionally get ipv6 error messages --
> maybe 4 a week. They don't seem to cause any particular problem. A
> freshclam.config option to disable ipv6 would fix that. Or maybe a
> "protocol {ipv4|ipv6|any}" option.
I
whole-heartily agree with this, although I seem to run into these error
messages more often (maybe due to my update frequency). It seems that
db.us.clamav.net used to be only IPv4 addresses, since there's also a
db.us.ipv6.clamav.net option, but that seems to have changed in at least
the past month or so, as it now it lists half IPv4 and half ipv6
addresses [2].
database.clamav.net is also the same way now [3]. This
causes issues for IPv4-only sites (out of my control to use IPv6), as we
consistently get error messages in the logs like
ERROR: Can't create new socket: Address family not supported by protocol
when
running freshclam. It seems to still work, as it eventually tries an
IPv4 address, but it's really annoying to get all these error messages
and seems like it wouldn't be too hard to fix (although I know I don't
know all the details that might be involved). Any reason to not have a
real IPv4-only option? Or make the
db.us.clamav.net actually only use
IPv4 addresses again?
This was also brought up also at [4] but there was no response.
Joel
Esler mentioned it was on their radar and that "Micah may want to
comment further." [5], when responding to this being a bug in freshclam
to try IPv6 addresses on IPv4-only systems, but nothing more came from
that discussion.
As was mentioned in
another thread on here [6], it makes sense to completely disable the
IPv6 stack completely on systems that have no IPv6 connectivity, as that
negates having to worry about any security controls for IPv6 at all. We
disable IPv6 globally on all our system through a kernel parameter.
Is there any discussion or headway on getting this bug addressed sometime soon?
Thanks.
[1]
[2]
[3]
[4]
[5]
[6]
--
Matt Vander Werf
HPC System Administrator
University of Notre Dame
Center for Research Computing - Union Station
506 W. South Street
South Bend, IN 46601
Phone: (574) 631-0692