> From g...@lexort.com Wed May 23 14:33:00 2018
> From: Greg Troxel
> To: Kathe
> Cc: netbsd-users@netbsd.org
> Subject: Re: zfs and dtrace, as specialized add-ons?
> OpenPGP: id=098ED60E
> X-Hashcash:
> 1:20:180523:netbsd-users@netbsd.org::iEs+bdT6FDUmaPP8:00
On Thu, May 24, 2018 at 01:55:23AM +, Christos Zoulas wrote:
> You could collect data for a few days and then make some entries permanent :-)
Sure. May be I'd look forward to blocklistd to add 1 more column in its
conf: "no. of repeat offences before being permanently blocked"! :-)
We could a
In article <20180524014836.ga30...@warunjikardental.com>,
Mayuresh wrote:
>Just tinkering with blacklistd settings.
>
>Trying to arrive at a good duration for blocking.
>
>I find that for 6 hours blocking, the blocked IPs settle around 90 to 100.
>
>Most of them just recur after block duration is
Just tinkering with blacklistd settings.
Trying to arrive at a good duration for blocking.
I find that for 6 hours blocking, the blocked IPs settle around 90 to 100.
Most of them just recur after block duration is over, typically they might
be bots.
Increasing the block duration would increase
On 23/05/2018 12:27, Patrick Welche wrote:
On Tue, May 22, 2018 at 11:03:34AM +0100, Stephen Borrill wrote:
While it worked okay I found that the number of firewall rules it
produced crept up to be stupidly large over time. This plus the startup
anoyance made me switch to blacklistd. I'm still
Kathe writes:
> why can't zfs and dtrace be supported as specialized add-ons?
> so basically, the system delivered as is should not have zfs
> and dtrace bundle-in but rather be configured and compiled-in
> by those users who need them.
Why the hatred of zfs?
We don't have a rule that features
On Tue, May 22, 2018 at 11:03:34AM +0100, Stephen Borrill wrote:
> > While it worked okay I found that the number of firewall rules it
> > produced crept up to be stupidly large over time. This plus the startup
> > anoyance made me switch to blacklistd. I'm still using ipf as a firewall
> > so I co
On Wed, May 23, 2018 at 09:30:17AM +, Kathe wrote:
> why can't zfs and dtrace be supported as specialized add-ons?
> so basically, the system delivered as is should not have zfs
> and dtrace bundle-in but rather be configured and compiled-in
> by those users who need them.
ZFS is delivered as
would it be possible to reduce the size of the system post first install
by way of employing the rump kernel approach to only load the sub-systems
and device drivers required by a particular hardware configuration?
why can't zfs and dtrace be supported as specialized add-ons?
so basically, the system delivered as is should not have zfs
and dtrace bundle-in but rather be configured and compiled-in
by those users who need them.
On 23.05.2018 09:06, Kathe wrote:
> i doubt if zfs and dtrace work on every platform port
> currently supported by netbsd, and if the ever will.
> why then bother with zfs and dtrace at all? :)
>
We need ZFS at least for compatibility with the world as it's perhaps
the most widespread file syste
apologies for sending in 2 similar emails.
don't know what i was thinking about. :)
i doubt if zfs and dtrace work on every hardware port supported by netbsd.
if not, why bother including them with just some of the ports?
this thought occured when i wondered about the use-case for zfs and dtrace
in embedded systems.
i doubt if zfs and dtrace work on every platform port
currently supported by netbsd, and if the ever will.
why then bother with zfs and dtrace at all? :)
14 matches
Mail list logo
