I don't know how big your squidguard blacklists are (its a good idea to
include details when asking questions), but the largest one I could find
was 20MB [...]
My biggest list is 22MB and gets daily updates. But because it uses much
RAM when be loaded I check all entrys one time per week so
Anyway, rsync sounds like the most appropriate mechanism to
transfer these particular databases.
[iceWave IT]
My blacklists should be available for everyone not only for those who
can connect with my server via ssh...
rsync doesn't require ssh; for your scenario you probably just want
A DNSBL is the traditional solution for blacklists, why are you
putting your blacklist in a .deb?
I meant blacklists specially for squidguard. That are hughe files with
domains / URLs inside. So e.g. porn could be blocked in your network.
What if a node misses an update, then?
And what if
I don't know how big your squidguard blacklists are (its a good idea
to include details when asking questions), but the largest one I could
find was 20MB, much smaller than some of the packages I maintain in
Debian, let alone the largest package in Debian. Anyway, rsync sounds
like the most
Hi ;)
I would like to imagine a time approach, could be made easier with the
updates.
With daily changing databases like virus database, blacklists, card or
similar is always a part of the old data is erased as new data are added.
Programs such as clamav bring it with their own update client.
In what specific situation did you want to use something like this?
I'm having a hard time imagining an appropriate use-case for this
solution.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe.
I'd like use this for Antivirus-Databases, Blacklists, etc. - Anything that
supports many updates in short time for huge datasets.
The reason for this is, that:
1. Every update would produce much bandwith, because for every update the
complete database has to be downloaded by aptitude.
2. On
I asked for a specific place you want to use it, rather than some general ideas.
I don't think a generalised mechanism can work in the situations you
are thinking of, per-database mechanisms are the way to go really.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to
Ok here is the specific place:
I've got blacklists, some with over 1 million entries, so the .deb packages
have a big size.
Debdelta doesn't function good, because so the whole list would be uninstalled
and the new list installed. For all 2 million transactions this needs lots of
time. And I
On Thu, Feb 21, 2013 at 01:52:55AM +0100, iceWave IT wrote:
Ok here is the specific place:
I've got blacklists, some with over 1 million entries, so the .deb
packages have a big size.
Debdelta doesn't function good, because so the whole list would be
uninstalled and the new list
A DNSBL is the traditional solution for blacklists, why are you
putting your blacklist in a .deb?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
11 matches
Mail list logo
