Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

On 2026/09/21 16:26, Kevin Zheng wrote:
> 
> Could you check that /etc/sshguard.conf is the correct location for your 
> config file, that it is not being overriden somewhere else, and that 
> there is not a subsequent BACKEND= line that sets it back to firewalld?
Turned out that that was the issue, although it's taken a few trips down
a few rabbit holes in order to work out what has been going on.

So we have diskless nodes, onto which the OS images are pre-created and
then pushed out, ahead of the "boot".

However, we have recently changed the way in which the image, that I'll
refer to as the "deployed image", gets deployed, from an effectively
static, some would say overly monolithic, image build on the cluster 
manager, to a less-monolithic, some would say slimmed down, image, 
plus a swathe of ansible plays.

The last rabbit hole I ended up in showed me that, in the slimmed down
image, the /etc/sshguard.conf has

BACKEND="/usr/lib/sshg-fw-firewalld"

(presumably the default in the RPM file used to build that image)
but that the "deployed image", which is all that most people who haven't
yet gone down any rabbit-holes see, has the expected

BACKEND="/usr/lib/sshg-fw-iptables"


I still don't understand, fully, why, at the point that the SSHGuard service
starts, the epehmeral file contents appear to be visible, but I think it's a
good bet that they are, and so are giving rise to those "command not found"
messages, and furthermore, only doing so on the initial boot, as any restarts
don't ever see the epehmeral file contents poking through.

"When the going gets wierd: the wierd turn pro"