> But that's independent of the signal used to make it happen, [...]
> Personally I'd probably pick a different signal for that, but I am
> not sure which.
I have long felt that having only two uncommitted signals (SIGUSR1 and
SIGUSR2) is way too few.
I've also long wanted a way to contact proce
Date:Tue, 30 May 2023 21:03:21 +0200
From:tlaro...@polynum.com
Message-ID:
| Do you think that SIGINFO is sound as the signal to obtain a config DUMP in
| the syslog?
First, dumping config to syslog seems like an odd thing to do at all, I'd
normally expect it to
Le Wed, May 31, 2023 at 12:18:26AM +0700, Robert Elz a écrit :
> Date:Tue, 30 May 2023 16:11:55 +0200
> From:tlaro...@polynum.com
> Message-ID:
>
> | The inclusion directive is a dot i.e. a here script:
>
> Definitely should not be called that, a "here xxx" is an x
Date:Tue, 30 May 2023 16:11:55 +0200
From:tlaro...@polynum.com
Message-ID:
| The inclusion directive is a dot i.e. a here script:
Definitely should not be called that, a "here xxx" is an xxx that is,
obviously, here, not elsewhere. Something in another file is in
ignat...@cs.uni-bonn.de writes:
>Hello,
>is there a minimal example how to configure bl*cklistd and npf to
>block attacks on sshd?
/etc/bl*cklistd.conf:
# Bl*cklist rule
# adr/mask:port typeproto owner namenfail disable
[local]
ssh stream tcp *
Hello,
is there a minimal example how to configure bl*cklistd and npf to
block attacks on sshd?
I tried from the manual but blacklistctl dump -a only shows
my test (and a wild) connection statying at nfail= 2/3 - what
can be wrong?
Regards,
-is
--
Ignatios Souvatzis, Chief IPv6 enabler
After a little reflection, here are the proposed changes to inetd(8):
THE CONFIGURATION
There is only one configuration file given by a path---whether on the
command line or defaulting to "/etc/inetd.conf".
The inclusion directive is a dot i.e. a here script: there are n
> On 27. May 2023, at 18:56, Robert Elz wrote:
>
> I'm dual-posting this to tech-kern and tech-userlevel, as while it is
> a userlevel issue, it could have kernel implications. Please respect
> the Reply-To and send replies only to tech-userlevel
>
> You may have noticed that a recent change (
