In Yocto, there is only one Python interpreter (python3), and the
auto-generated "fail2ban-python" symlink is not used. To ensure
all installed scripts can run correctly, replace the shebang line
from "#!/usr/bin/env fail2ban-python" to "#!/usr/bin/env python3"
during installation.
Signed-off-by: Haixiao Yan <haixiao.yan.cn@windriver.com>
Update to latest git rev as the current version doesn't work with
OpenSSH 9.8+[1].
Ptest result:
$ ptest-runner python3-fail2ban
START: ptest-runner
2025-09-21T12:45
BEGIN: /usr/lib64/python3-fail2ban/ptest
Ran 538 tests in 13.045s
OK (skipped=3)
DURATION: 14
END: /usr/lib64/python3-fail2ban/ptest
2025-09-21T12:46
STOP: ptest-runner
TOTAL: 1 FAIL: 0
[1] https://github.com/fail2ban/fail2ban/commit/2fed408c05ac5206b490368d94599869bd6a056d
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Current 1.0.2 version does not work with scarthgap or later releases,
as the asynchat module has been removed (as scheduled) from python's
stdlib as of v3.12.
fail2ban 1.1.0 also does not work out-of-the-box, as the distutils
module which the pyinotify and systemd backends depend has also been
removed.
So update the recipe to point at commit ac62658c10f4, which fixes
those two backends to no longer depend on distutils.
Upstream's out-of-the-box ban action now uses the 'nft'
command. People can still override and customize that in
jail.conf/jail.local, but to make the recipe useful without
customizing things back to use iptables, change the dependency
iptables->nftables.
Since 1.1.0, fail2ban has been python3-only, so the recipe becomes
somewhat simpler since the whole do_compile preparation step can be
removed.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
On a systemd-based system, one is likely to make use of
'backend=systemd', which requires the systemd module.
Both the pyinotify and systemd backends require the distutils module.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Currently, one gets
Unable to import fail2ban database module as sqlite is not available
So we need to ensure the sqlite3 python module is available. That will
automatically pull in libsqlite3.
Since fail2ban does not actually depend on the the CLI which the
sqlite3 package provides, drop that dependency.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
fail2ban ships with a suitable .service file, so install that if
systemd is in DISTRO_FEATURES. The logic in rm_sysvinit_initddir in
systemd.bbclass will then take care of removing the sysvinit script if
sysvinit is not in DISTRO_FEATURES.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
There could be some false possitives (the script is far from perfect), so please
test it on your QA, I've only double checked with "git grep" (the script looks
only in parent directory).
@ ~/layers/meta-security $ /OE/extra-layers/meta-ros/scripts/check-patch-files.sh .
./recipes-ids/tripwire/files/add_armeb_arch.patch: not used in any recipe
./dynamic-layers/meta-python/recipes-security/fail2ban/files/0001-To-fix-build-error-of-xrang.patch: not used in any recipe
./recipes-scanners/clamav/files/fix2_libcurl_check.patch: not used in any recipe
./recipes-scanners/arpwatch/files/postfix_workaround.patch: not used in any recipe
./meta-tpm/recipes-tpm/libtpm/files/Use-format-s-for-call-to-dprintf.patch: not used in any recipe
./meta-tpm/recipes-tpm/libtpm/files/fix_signed_issue.patch: not used in any recipe
./meta-tpm/recipes-tpm/libtpm/files/Convert-another-vdprintf-to-dprintf.patch: not used in any recipe
./meta-tpm/recipes-tpm/swtpm/files/fix_lib_search_path.patch: not used in any recipe
./meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch: not used in any recipe
./recipes-mac/AppArmor/files/disable_perl_h_check.patch: not used in any recipe
@ ~/layers/meta-security $ git grep add_armeb_arch.patch
@ ~/layers/meta-security $ git grep 0001-To-fix-build-error-of-xrang.patch
@ ~/layers/meta-security $ git grep fix2_libcurl_check.patch
@ ~/layers/meta-security $ git grep postfix_workaround.patch
@ ~/layers/meta-security $ git grep Use-format-s-for-call-to-dprintf.patch
@ ~/layers/meta-security $ git grep fix_signed_issue.patch
@ ~/layers/meta-security $ git grep Convert-another-vdprintf-to-dprintf.patch
@ ~/layers/meta-security $ git grep fix_lib_search_path.patch
@ ~/layers/meta-security $ git grep fix_fcntl_h.patch
@ ~/layers/meta-security $ git grep disable_perl_h_check.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Nothing in getting installed in ${datadir}/lib, it is all going to
${prefix}/lib. setuptools pulls in ${libdir}/* so for the base lib
case of ${prefix}/lib the build works. If libdir is something else
lib64 for example, its still ending up in ${prefix}/lib and it fails
to build.
Set value to correct path as it is being installed.
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Haixiao Yan
Yi Zhao
Scott Murray
Armin Kuster
Rasmus Villemoes
Martin Jansa
Jeremy A. Puhlman