Message ID | 1534945312-25275-1-git-send-email-angelo@amarulasolutions.com |
---|---|
State | Changes Requested |
Headers | show |
Series | [v2] package/fail2ban: new package | expand |
Hello, +Yegor in Cc. Yegor: read all the way to the end, there is a question about the python-package infrastructure. On Wed, 22 Aug 2018 15:41:52 +0200, Angelo Compagnucci wrote: > Fail2ban scans log files (e.g. /var/log/apache/error_log) > and bans IPs that show malicious behaviours. > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> I was about to apply this patch (I even made a few minor fixes), but there is one thing that made me change my mind, see below. I will also list the minor issues. > package/Config.in | 1 + > package/fail2ban/Config.in | 14 ++++++++++++++ > package/fail2ban/S60fail2ban | 23 +++++++++++++++++++++++ > package/fail2ban/fail2ban.hash | 3 +++ > package/fail2ban/fail2ban.mk | 28 ++++++++++++++++++++++++++++ Entry in DEVELOPERS file missing. > diff --git a/package/fail2ban/Config.in b/package/fail2ban/Config.in > new file mode 100644 > index 0000000..cf82526 > --- /dev/null > +++ b/package/fail2ban/Config.in > @@ -0,0 +1,14 @@ > +config BR2_PACKAGE_FAIL2BAN > + bool "fail2ban" > + depends on BR2_PACKAGE_PYTHON Are you sure it doesn't work with Python 3.x ? The fail2ban github page says it does. > + help > + Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs > + that show the malicious signs -- too many password failures, seeking > + for exploits, etc. Out of the box Fail2Ban comes with filters for > + various services (apache, courier, ssh, etc). > + > + Fail2Ban is able to reduce the rate of incorrect authentications > + attempts however it cannot eliminate the risk that weak authentication > + presents. Aren't some of those lines too long? Could you verify with check-package > + > + https://www.fail2ban.org Please add a Config.in comment about the Python dependency. > diff --git a/package/fail2ban/S60fail2ban b/package/fail2ban/S60fail2ban > new file mode 100644 > index 0000000..92559e9 > --- /dev/null > +++ b/package/fail2ban/S60fail2ban > @@ -0,0 +1,23 @@ > +#!/bin/sh > + > +case "$1" in > + start) > + printf "Starting fail2ban: " > + start-stop-daemon -S -q -m -p /run/fail2ban.pid \ Put the PID file in /var/run, to be consistent with most of our other init scripts. > + -b -x fail2ban-server -- -xf start > + [ $? = 0 ] && echo "OK" || echo "FAIL" > + ;; > + stop) > + printf "Stopping fail2ban: " > + start-stop-daemon -K -q -p /run/fail2ban.pid Ditto. > +FAIL2BAN_VERSION = 0.10.3.1 > +FAIL2BAN_SITE = $(call github,fail2ban,fail2ban,$(FAIL2BAN_VERSION)) > +FAIL2BAN_LICENSE = GPL-2.0+ > +FAIL2BAN_LICENSE_FILES = COPYING > +FAIL2BAN_SETUP_TYPE = setuptools > +FAIL2BAN_INSTALL_TARGET_OPTS = --root=$(TARGET_DIR) --prefix=/usr So here is the one thing that made me change my mind. I was wondering: why do we need to pass those options in the fail2ban package? Why aren't they passed by the python-package infrastructure? Turns out that the Python package infrastructure is doing this: PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ --prefix=$(TARGET_DIR)/usr \ --executable=/usr/bin/python \ --single-version-externally-managed \ --root=/ PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ --prefix=$(STAGING_DIR)/usr \ --executable=/usr/bin/python \ --single-version-externally-managed \ --root=/ This looks pretty wrong, and it seems like we should be using: --prefix=/usr \ --root=$(TARGET_DIR) and ditto for the staging installation, of course. Yegor, do you see any drawback with doing this change in pkg-python.mk ? To me, it seems like the right thing to do, and would avoid the need to have a special case in fail2ban.mk. Thanks! Thomas
Hi Thomas, Angelo, On Tue, Sep 11, 2018 at 12:05 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > +Yegor in Cc. Yegor: read all the way to the end, there is a question > about the python-package infrastructure. > > On Wed, 22 Aug 2018 15:41:52 +0200, Angelo Compagnucci wrote: > > Fail2ban scans log files (e.g. /var/log/apache/error_log) > > and bans IPs that show malicious behaviours. > > > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> > > I was about to apply this patch (I even made a few minor fixes), but > there is one thing that made me change my mind, see below. I will also > list the minor issues. > > > package/Config.in | 1 + > > package/fail2ban/Config.in | 14 ++++++++++++++ > > package/fail2ban/S60fail2ban | 23 +++++++++++++++++++++++ > > package/fail2ban/fail2ban.hash | 3 +++ > > package/fail2ban/fail2ban.mk | 28 ++++++++++++++++++++++++++++ > > Entry in DEVELOPERS file missing. > > > diff --git a/package/fail2ban/Config.in b/package/fail2ban/Config.in > > new file mode 100644 > > index 0000000..cf82526 > > --- /dev/null > > +++ b/package/fail2ban/Config.in > > @@ -0,0 +1,14 @@ > > +config BR2_PACKAGE_FAIL2BAN > > + bool "fail2ban" > > + depends on BR2_PACKAGE_PYTHON > > Are you sure it doesn't work with Python 3.x ? The fail2ban > github page says it does. > > > + help > > + Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs > > + that show the malicious signs -- too many password failures, seeking > > + for exploits, etc. Out of the box Fail2Ban comes with filters for > > + various services (apache, courier, ssh, etc). > > + > > + Fail2Ban is able to reduce the rate of incorrect authentications > > + attempts however it cannot eliminate the risk that weak authentication > > + presents. > > Aren't some of those lines too long? Could you verify with check-package > > > + > > + https://www.fail2ban.org > > Please add a Config.in comment about the Python dependency. > > > diff --git a/package/fail2ban/S60fail2ban b/package/fail2ban/S60fail2ban > > new file mode 100644 > > index 0000000..92559e9 > > --- /dev/null > > +++ b/package/fail2ban/S60fail2ban > > @@ -0,0 +1,23 @@ > > +#!/bin/sh > > + > > +case "$1" in > > + start) > > + printf "Starting fail2ban: " > > + start-stop-daemon -S -q -m -p /run/fail2ban.pid \ > > Put the PID file in /var/run, to be consistent with most of our other > init scripts. > > > + -b -x fail2ban-server -- -xf start > > + [ $? = 0 ] && echo "OK" || echo "FAIL" > > + ;; > > + stop) > > + printf "Stopping fail2ban: " > > + start-stop-daemon -K -q -p /run/fail2ban.pid > > Ditto. > > > > +FAIL2BAN_VERSION = 0.10.3.1 > > +FAIL2BAN_SITE = $(call github,fail2ban,fail2ban,$(FAIL2BAN_VERSION)) > > +FAIL2BAN_LICENSE = GPL-2.0+ > > +FAIL2BAN_LICENSE_FILES = COPYING > > +FAIL2BAN_SETUP_TYPE = setuptools > > +FAIL2BAN_INSTALL_TARGET_OPTS = --root=$(TARGET_DIR) --prefix=/usr > > So here is the one thing that made me change my mind. I was wondering: > why do we need to pass those options in the fail2ban package? Why > aren't they passed by the python-package infrastructure? > > Turns out that the Python package infrastructure is doing this: > > PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ > --prefix=$(TARGET_DIR)/usr \ > --executable=/usr/bin/python \ > --single-version-externally-managed \ > --root=/ > > PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ > --prefix=$(STAGING_DIR)/usr \ > --executable=/usr/bin/python \ > --single-version-externally-managed \ > --root=/ > > This looks pretty wrong, and it seems like we should be using: > > --prefix=/usr \ > --root=$(TARGET_DIR) > > and ditto for the staging installation, of course. Yegor, do you see > any drawback with doing this change in pkg-python.mk ? To me, it seems > like the right thing to do, and would avoid the need to have a special > case in fail2ban.mk. I've applied this hack: diff --git a/package/pkg-python.mk b/package/pkg-python.mk index f57e486dad..fcb7309ef9 100644 --- a/package/pkg-python.mk +++ b/package/pkg-python.mk @@ -66,10 +66,10 @@ PKG_PYTHON_SETUPTOOLS_ENV = \ _python_exec_prefix=/usr PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ - --prefix=$(TARGET_DIR)/usr \ + --prefix=/usr \ --executable=/usr/bin/python \ --single-version-externally-managed \ - --root=/ + --root=$(TARGET_DIR) PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ --prefix=$(STAGING_DIR)/usr \ And performed some tests with following packages (both via python "console" and using packe own scripts like watchmedo or miniterm.py): python-serial, python-watchdog, python-cryptography, python-pytablewriter So far I haven't experienced any issues. Regards, Yegor
Hello, On Tue, 11 Sep 2018 11:47:36 +0200, Yegor Yefremov wrote: > > and ditto for the staging installation, of course. Yegor, do you see > > any drawback with doing this change in pkg-python.mk ? To me, it seems > > like the right thing to do, and would avoid the need to have a special > > case in fail2ban.mk. > > I've applied this hack: Why do you say "hack" ? It should be the right thing, compared to what we're doing today. > diff --git a/package/pkg-python.mk b/package/pkg-python.mk > index f57e486dad..fcb7309ef9 100644 > --- a/package/pkg-python.mk > +++ b/package/pkg-python.mk > @@ -66,10 +66,10 @@ PKG_PYTHON_SETUPTOOLS_ENV = \ > _python_exec_prefix=/usr > > PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ > - --prefix=$(TARGET_DIR)/usr \ > + --prefix=/usr \ > --executable=/usr/bin/python \ > --single-version-externally-managed \ > - --root=/ > + --root=$(TARGET_DIR) > > PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ > --prefix=$(STAGING_DIR)/usr \ It should also be fixed in the staging installation commands, which have the same problem. > And performed some tests with following packages (both via python > "console" and using packe own scripts like watchmedo or miniterm.py): > > python-serial, python-watchdog, python-cryptography, python-pytablewriter > > So far I haven't experienced any issues. Great, thanks for doing this test! I think it would be a nice thing to fix. Angelo: just curious, for fail2ban, what made you realize you had to override the --prefix and --root values ? Best regards, Thomas
Thomas, Yegor, On Tue, Sep 11, 2018 at 11:52 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Tue, 11 Sep 2018 11:47:36 +0200, Yegor Yefremov wrote: > > > and ditto for the staging installation, of course. Yegor, do you see > > > any drawback with doing this change in pkg-python.mk ? To me, it seems > > > like the right thing to do, and would avoid the need to have a special > > > case in fail2ban.mk. > > > > I've applied this hack: > > Why do you say "hack" ? It should be the right thing, compared to what > we're doing today. > > > diff --git a/package/pkg-python.mk b/package/pkg-python.mk > > index f57e486dad..fcb7309ef9 100644 > > --- a/package/pkg-python.mk > > +++ b/package/pkg-python.mk > > @@ -66,10 +66,10 @@ PKG_PYTHON_SETUPTOOLS_ENV = \ > > _python_exec_prefix=/usr > > > > PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ > > - --prefix=$(TARGET_DIR)/usr \ > > + --prefix=/usr \ > > --executable=/usr/bin/python \ > > --single-version-externally-managed \ > > - --root=/ > > + --root=$(TARGET_DIR) > > > > PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ > > --prefix=$(STAGING_DIR)/usr \ > > It should also be fixed in the staging installation commands, which > have the same problem. > > > And performed some tests with following packages (both via python > > "console" and using packe own scripts like watchmedo or miniterm.py): > > > > python-serial, python-watchdog, python-cryptography, python-pytablewriter > > > > So far I haven't experienced any issues. > > Great, thanks for doing this test! I think it would be a nice thing to > fix. > > Angelo: just curious, for fail2ban, what made you realize you had to > override the --prefix and --root values ? Python setuptools installs data_files into python_root, so the fail2ban setup.py failed blatantly in buildroot trying to writing something to /etc/fail2ban instead of $(TARGET_DIR)/etc/fail2ban. I'm glad it will be fixed globally, I honestly thought it was like that for a reason! Sincerely, Angelo > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Hi Thomas, Il giorno mar 11 set 2018 alle ore 00:05 Thomas Petazzoni <thomas.petazzoni@bootlin.com> ha scritto: > > Hello, > > +Yegor in Cc. Yegor: read all the way to the end, there is a question > about the python-package infrastructure. > > On Wed, 22 Aug 2018 15:41:52 +0200, Angelo Compagnucci wrote: > > Fail2ban scans log files (e.g. /var/log/apache/error_log) > > and bans IPs that show malicious behaviours. > > > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> > > I was about to apply this patch (I even made a few minor fixes), but > there is one thing that made me change my mind, see below. I will also > list the minor issues. > > > package/Config.in | 1 + > > package/fail2ban/Config.in | 14 ++++++++++++++ > > package/fail2ban/S60fail2ban | 23 +++++++++++++++++++++++ > > package/fail2ban/fail2ban.hash | 3 +++ > > package/fail2ban/fail2ban.mk | 28 ++++++++++++++++++++++++++++ > > Entry in DEVELOPERS file missing. > > > diff --git a/package/fail2ban/Config.in b/package/fail2ban/Config.in > > new file mode 100644 > > index 0000000..cf82526 > > --- /dev/null > > +++ b/package/fail2ban/Config.in > > @@ -0,0 +1,14 @@ > > +config BR2_PACKAGE_FAIL2BAN > > + bool "fail2ban" > > + depends on BR2_PACKAGE_PYTHON > > Are you sure it doesn't work with Python 3.x ? The fail2ban > github page says it does. Probably it say so, but simply trying to run the software with python3: File "/home/angelo/DEV/BUILDROOT/br_qemu_arm/build/fail2ban-0.10.4/fail2ban/__init__.py", line 85, in _init for i in xrange(50): NameError: name 'xrange' is not defined > > > + help > > + Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs > > + that show the malicious signs -- too many password failures, seeking > > + for exploits, etc. Out of the box Fail2Ban comes with filters for > > + various services (apache, courier, ssh, etc). > > + > > + Fail2Ban is able to reduce the rate of incorrect authentications > > + attempts however it cannot eliminate the risk that weak authentication > > + presents. > > Aren't some of those lines too long? Could you verify with check-package > > > + > > + https://www.fail2ban.org > > Please add a Config.in comment about the Python dependency. > > > diff --git a/package/fail2ban/S60fail2ban b/package/fail2ban/S60fail2ban > > new file mode 100644 > > index 0000000..92559e9 > > --- /dev/null > > +++ b/package/fail2ban/S60fail2ban > > @@ -0,0 +1,23 @@ > > +#!/bin/sh > > + > > +case "$1" in > > + start) > > + printf "Starting fail2ban: " > > + start-stop-daemon -S -q -m -p /run/fail2ban.pid \ > > Put the PID file in /var/run, to be consistent with most of our other > init scripts. > > > + -b -x fail2ban-server -- -xf start > > + [ $? = 0 ] && echo "OK" || echo "FAIL" > > + ;; > > + stop) > > + printf "Stopping fail2ban: " > > + start-stop-daemon -K -q -p /run/fail2ban.pid > > Ditto. > > > > +FAIL2BAN_VERSION = 0.10.3.1 > > +FAIL2BAN_SITE = $(call github,fail2ban,fail2ban,$(FAIL2BAN_VERSION)) > > +FAIL2BAN_LICENSE = GPL-2.0+ > > +FAIL2BAN_LICENSE_FILES = COPYING > > +FAIL2BAN_SETUP_TYPE = setuptools > > +FAIL2BAN_INSTALL_TARGET_OPTS = --root=$(TARGET_DIR) --prefix=/usr > > So here is the one thing that made me change my mind. I was wondering: > why do we need to pass those options in the fail2ban package? Why > aren't they passed by the python-package infrastructure? > > Turns out that the Python package infrastructure is doing this: > > PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ > --prefix=$(TARGET_DIR)/usr \ > --executable=/usr/bin/python \ > --single-version-externally-managed \ > --root=/ > > PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ > --prefix=$(STAGING_DIR)/usr \ > --executable=/usr/bin/python \ > --single-version-externally-managed \ > --root=/ > > This looks pretty wrong, and it seems like we should be using: > > --prefix=/usr \ > --root=$(TARGET_DIR) > > and ditto for the staging installation, of course. Yegor, do you see > any drawback with doing this change in pkg-python.mk ? To me, it seems > like the right thing to do, and would avoid the need to have a special > case in fail2ban.mk. > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Angelo, On Sun, Nov 25, 2018 at 12:28 AM Angelo Compagnucci <angelo.compagnucci@gmail.com> wrote: > > Hi Thomas, > Il giorno mar 11 set 2018 alle ore 00:05 Thomas Petazzoni > <thomas.petazzoni@bootlin.com> ha scritto: > > > > Hello, > > > > +Yegor in Cc. Yegor: read all the way to the end, there is a question > > about the python-package infrastructure. > > > > On Wed, 22 Aug 2018 15:41:52 +0200, Angelo Compagnucci wrote: > > > Fail2ban scans log files (e.g. /var/log/apache/error_log) > > > and bans IPs that show malicious behaviours. > > > > > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> > > > > I was about to apply this patch (I even made a few minor fixes), but > > there is one thing that made me change my mind, see below. I will also > > list the minor issues. > > > > > package/Config.in | 1 + > > > package/fail2ban/Config.in | 14 ++++++++++++++ > > > package/fail2ban/S60fail2ban | 23 +++++++++++++++++++++++ > > > package/fail2ban/fail2ban.hash | 3 +++ > > > package/fail2ban/fail2ban.mk | 28 ++++++++++++++++++++++++++++ > > > > Entry in DEVELOPERS file missing. > > > > > diff --git a/package/fail2ban/Config.in b/package/fail2ban/Config.in > > > new file mode 100644 > > > index 0000000..cf82526 > > > --- /dev/null > > > +++ b/package/fail2ban/Config.in > > > @@ -0,0 +1,14 @@ > > > +config BR2_PACKAGE_FAIL2BAN > > > + bool "fail2ban" > > > + depends on BR2_PACKAGE_PYTHON > > > > Are you sure it doesn't work with Python 3.x ? The fail2ban > > github page says it does. > > Probably it say so, but simply trying to run the software with python3: > > File "/home/angelo/DEV/BUILDROOT/br_qemu_arm/build/fail2ban-0.10.4/fail2ban/__init__.py", > line 85, in _init > for i in xrange(50): > NameError: name 'xrange' is not defined This was fixed in [1], but it seems like if you'll have wait till the next release. [1] https://github.com/fail2ban/fail2ban/commit/657b147c0d7830f3600f3dc7feaa4815a7e19fde#diff-ac23116c0e156f1acc787e57fe98391c Yegor > > > > > + help > > > + Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs > > > + that show the malicious signs -- too many password failures, seeking > > > + for exploits, etc. Out of the box Fail2Ban comes with filters for > > > + various services (apache, courier, ssh, etc). > > > + > > > + Fail2Ban is able to reduce the rate of incorrect authentications > > > + attempts however it cannot eliminate the risk that weak authentication > > > + presents. > > > > Aren't some of those lines too long? Could you verify with check-package > > > > > + > > > + https://www.fail2ban.org > > > > Please add a Config.in comment about the Python dependency. > > > > > diff --git a/package/fail2ban/S60fail2ban b/package/fail2ban/S60fail2ban > > > new file mode 100644 > > > index 0000000..92559e9 > > > --- /dev/null > > > +++ b/package/fail2ban/S60fail2ban > > > @@ -0,0 +1,23 @@ > > > +#!/bin/sh > > > + > > > +case "$1" in > > > + start) > > > + printf "Starting fail2ban: " > > > + start-stop-daemon -S -q -m -p /run/fail2ban.pid \ > > > > Put the PID file in /var/run, to be consistent with most of our other > > init scripts. > > > > > + -b -x fail2ban-server -- -xf start > > > + [ $? = 0 ] && echo "OK" || echo "FAIL" > > > + ;; > > > + stop) > > > + printf "Stopping fail2ban: " > > > + start-stop-daemon -K -q -p /run/fail2ban.pid > > > > Ditto. > > > > > > > +FAIL2BAN_VERSION = 0.10.3.1 > > > +FAIL2BAN_SITE = $(call github,fail2ban,fail2ban,$(FAIL2BAN_VERSION)) > > > +FAIL2BAN_LICENSE = GPL-2.0+ > > > +FAIL2BAN_LICENSE_FILES = COPYING > > > +FAIL2BAN_SETUP_TYPE = setuptools > > > +FAIL2BAN_INSTALL_TARGET_OPTS = --root=$(TARGET_DIR) --prefix=/usr > > > > So here is the one thing that made me change my mind. I was wondering: > > why do we need to pass those options in the fail2ban package? Why > > aren't they passed by the python-package infrastructure? > > > > Turns out that the Python package infrastructure is doing this: > > > > PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ > > --prefix=$(TARGET_DIR)/usr \ > > --executable=/usr/bin/python \ > > --single-version-externally-managed \ > > --root=/ > > > > PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ > > --prefix=$(STAGING_DIR)/usr \ > > --executable=/usr/bin/python \ > > --single-version-externally-managed \ > > --root=/ > > > > This looks pretty wrong, and it seems like we should be using: > > > > --prefix=/usr \ > > --root=$(TARGET_DIR) > > > > and ditto for the staging installation, of course. Yegor, do you see > > any drawback with doing this change in pkg-python.mk ? To me, it seems > > like the right thing to do, and would avoid the need to have a special > > case in fail2ban.mk. > > > > Thanks! > > > > Thomas > > -- > > Thomas Petazzoni, CTO, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > _______________________________________________ > > buildroot mailing list > > buildroot@busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > > > -- > Profile: http://it.linkedin.com/in/compagnucciangelo > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Dear Yegor, Il giorno ven 30 nov 2018 alle ore 09:54 Yegor Yefremov <yegorslists@googlemail.com> ha scritto: > > Hi Angelo, > > On Sun, Nov 25, 2018 at 12:28 AM Angelo Compagnucci > <angelo.compagnucci@gmail.com> wrote: > > > > Hi Thomas, > > Il giorno mar 11 set 2018 alle ore 00:05 Thomas Petazzoni > > <thomas.petazzoni@bootlin.com> ha scritto: > > > > > > Hello, > > > > > > +Yegor in Cc. Yegor: read all the way to the end, there is a question > > > about the python-package infrastructure. > > > > > > On Wed, 22 Aug 2018 15:41:52 +0200, Angelo Compagnucci wrote: > > > > Fail2ban scans log files (e.g. /var/log/apache/error_log) > > > > and bans IPs that show malicious behaviours. > > > > > > > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> > > > > > > I was about to apply this patch (I even made a few minor fixes), but > > > there is one thing that made me change my mind, see below. I will also > > > list the minor issues. > > > > > > > package/Config.in | 1 + > > > > package/fail2ban/Config.in | 14 ++++++++++++++ > > > > package/fail2ban/S60fail2ban | 23 +++++++++++++++++++++++ > > > > package/fail2ban/fail2ban.hash | 3 +++ > > > > package/fail2ban/fail2ban.mk | 28 ++++++++++++++++++++++++++++ > > > > > > Entry in DEVELOPERS file missing. > > > > > > > diff --git a/package/fail2ban/Config.in b/package/fail2ban/Config.in > > > > new file mode 100644 > > > > index 0000000..cf82526 > > > > --- /dev/null > > > > +++ b/package/fail2ban/Config.in > > > > @@ -0,0 +1,14 @@ > > > > +config BR2_PACKAGE_FAIL2BAN > > > > + bool "fail2ban" > > > > + depends on BR2_PACKAGE_PYTHON > > > > > > Are you sure it doesn't work with Python 3.x ? The fail2ban > > > github page says it does. > > > > Probably it say so, but simply trying to run the software with python3: > > > > File "/home/angelo/DEV/BUILDROOT/br_qemu_arm/build/fail2ban-0.10.4/fail2ban/__init__.py", > > line 85, in _init > > for i in xrange(50): > > NameError: name 'xrange' is not defined > > This was fixed in [1], but it seems like if you'll have wait till the > next release. Yes I know and meanwhile I submitted a PR to disable installation of tests files hoping that the next release contains both fixes, but as far as I can tell the project has a load of backlog! Thanks! > > [1] https://github.com/fail2ban/fail2ban/commit/657b147c0d7830f3600f3dc7feaa4815a7e19fde#diff-ac23116c0e156f1acc787e57fe98391c > > Yegor > > > > > > > > + help > > > > + Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs > > > > + that show the malicious signs -- too many password failures, seeking > > > > + for exploits, etc. Out of the box Fail2Ban comes with filters for > > > > + various services (apache, courier, ssh, etc). > > > > + > > > > + Fail2Ban is able to reduce the rate of incorrect authentications > > > > + attempts however it cannot eliminate the risk that weak authentication > > > > + presents. > > > > > > Aren't some of those lines too long? Could you verify with check-package > > > > > > > + > > > > + https://www.fail2ban.org > > > > > > Please add a Config.in comment about the Python dependency. > > > > > > > diff --git a/package/fail2ban/S60fail2ban b/package/fail2ban/S60fail2ban > > > > new file mode 100644 > > > > index 0000000..92559e9 > > > > --- /dev/null > > > > +++ b/package/fail2ban/S60fail2ban > > > > @@ -0,0 +1,23 @@ > > > > +#!/bin/sh > > > > + > > > > +case "$1" in > > > > + start) > > > > + printf "Starting fail2ban: " > > > > + start-stop-daemon -S -q -m -p /run/fail2ban.pid \ > > > > > > Put the PID file in /var/run, to be consistent with most of our other > > > init scripts. > > > > > > > + -b -x fail2ban-server -- -xf start > > > > + [ $? = 0 ] && echo "OK" || echo "FAIL" > > > > + ;; > > > > + stop) > > > > + printf "Stopping fail2ban: " > > > > + start-stop-daemon -K -q -p /run/fail2ban.pid > > > > > > Ditto. > > > > > > > > > > +FAIL2BAN_VERSION = 0.10.3.1 > > > > +FAIL2BAN_SITE = $(call github,fail2ban,fail2ban,$(FAIL2BAN_VERSION)) > > > > +FAIL2BAN_LICENSE = GPL-2.0+ > > > > +FAIL2BAN_LICENSE_FILES = COPYING > > > > +FAIL2BAN_SETUP_TYPE = setuptools > > > > +FAIL2BAN_INSTALL_TARGET_OPTS = --root=$(TARGET_DIR) --prefix=/usr > > > > > > So here is the one thing that made me change my mind. I was wondering: > > > why do we need to pass those options in the fail2ban package? Why > > > aren't they passed by the python-package infrastructure? > > > > > > Turns out that the Python package infrastructure is doing this: > > > > > > PKG_PYTHON_SETUPTOOLS_INSTALL_TARGET_OPTS = \ > > > --prefix=$(TARGET_DIR)/usr \ > > > --executable=/usr/bin/python \ > > > --single-version-externally-managed \ > > > --root=/ > > > > > > PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \ > > > --prefix=$(STAGING_DIR)/usr \ > > > --executable=/usr/bin/python \ > > > --single-version-externally-managed \ > > > --root=/ > > > > > > This looks pretty wrong, and it seems like we should be using: > > > > > > --prefix=/usr \ > > > --root=$(TARGET_DIR) > > > > > > and ditto for the staging installation, of course. Yegor, do you see > > > any drawback with doing this change in pkg-python.mk ? To me, it seems > > > like the right thing to do, and would avoid the need to have a special > > > case in fail2ban.mk. > > > > > > Thanks! > > > > > > Thomas > > > -- > > > Thomas Petazzoni, CTO, Bootlin > > > Embedded Linux and Kernel engineering > > > https://bootlin.com > > > _______________________________________________ > > > buildroot mailing list > > > buildroot@busybox.net > > > http://lists.busybox.net/mailman/listinfo/buildroot > > > > > > > > -- > > Profile: http://it.linkedin.com/in/compagnucciangelo > > _______________________________________________ > > buildroot mailing list > > buildroot@busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot
diff --git a/package/Config.in b/package/Config.in index f5a1749..1783ab9 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1740,6 +1740,7 @@ menu "Networking applications" source "package/ejabberd/Config.in" source "package/ethtool/Config.in" source "package/faifa/Config.in" + source "package/fail2ban/Config.in" source "package/fastd/Config.in" source "package/fcgiwrap/Config.in" source "package/flannel/Config.in" diff --git a/package/fail2ban/Config.in b/package/fail2ban/Config.in new file mode 100644 index 0000000..cf82526 --- /dev/null +++ b/package/fail2ban/Config.in @@ -0,0 +1,14 @@ +config BR2_PACKAGE_FAIL2BAN + bool "fail2ban" + depends on BR2_PACKAGE_PYTHON + help + Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs + that show the malicious signs -- too many password failures, seeking + for exploits, etc. Out of the box Fail2Ban comes with filters for + various services (apache, courier, ssh, etc). + + Fail2Ban is able to reduce the rate of incorrect authentications + attempts however it cannot eliminate the risk that weak authentication + presents. + + https://www.fail2ban.org diff --git a/package/fail2ban/S60fail2ban b/package/fail2ban/S60fail2ban new file mode 100644 index 0000000..92559e9 --- /dev/null +++ b/package/fail2ban/S60fail2ban @@ -0,0 +1,23 @@ +#!/bin/sh + +case "$1" in + start) + printf "Starting fail2ban: " + start-stop-daemon -S -q -m -p /run/fail2ban.pid \ + -b -x fail2ban-server -- -xf start + [ $? = 0 ] && echo "OK" || echo "FAIL" + ;; + stop) + printf "Stopping fail2ban: " + start-stop-daemon -K -q -p /run/fail2ban.pid + [ $? = 0 ] && echo "OK" || echo "FAIL" + ;; + restart) + "$0" stop + sleep 1 + "$0" start + ;; + *) + echo "Usage: $0 {start|stop|restart}" + ;; +esac diff --git a/package/fail2ban/fail2ban.hash b/package/fail2ban/fail2ban.hash new file mode 100644 index 0000000..4b59091 --- /dev/null +++ b/package/fail2ban/fail2ban.hash @@ -0,0 +1,3 @@ +# sha256 locally computed +sha256 7ee3fd0e94d58c94298718b25e6bcfa96932712b7aa683580e162403f68d40c8 fail2ban-0.10.3.1.tar.gz +sha256 a75fec0260742fe6275d63ff6a5d97b924b28766558306b3fa4069763096929b COPYING diff --git a/package/fail2ban/fail2ban.mk b/package/fail2ban/fail2ban.mk new file mode 100644 index 0000000..cc6961f --- /dev/null +++ b/package/fail2ban/fail2ban.mk @@ -0,0 +1,28 @@ +################################################################################ +# +# fail2ban +# +################################################################################ + +FAIL2BAN_VERSION = 0.10.3.1 +FAIL2BAN_SITE = $(call github,fail2ban,fail2ban,$(FAIL2BAN_VERSION)) +FAIL2BAN_LICENSE = GPL-2.0+ +FAIL2BAN_LICENSE_FILES = COPYING +FAIL2BAN_SETUP_TYPE = setuptools +FAIL2BAN_INSTALL_TARGET_OPTS = --root=$(TARGET_DIR) --prefix=/usr + +define FAIL2BAN_INSTALL_INIT_SYSV + $(INSTALL) -D -m 755 package/fail2ban/S60fail2ban \ + $(TARGET_DIR)/etc/init.d/S60fail2ban +endef + +define FAIL2BAN_INSTALL_INIT_SYSTEMD + $(INSTALL) -D -m 0644 $(@D)/files/fail2ban.service.in \ + $(TARGET_DIR)/usr/lib/systemd/system/fail2ban.service + mkdir -p $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants + ln -fs ../../../../usr/lib//systemd/system/fail2ban.service \ + $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/fail2ban.service + $(SED) 's/@BINDIR@/\/usr\/bin/g' $(TARGET_DIR)/usr/lib/systemd/system/fail2ban.service +endef + +$(eval $(python-package))
Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show malicious behaviours. Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> --- Changes: v1->v2: * Adding sha256 for license file * getting service file for systemd from source directory package/Config.in | 1 + package/fail2ban/Config.in | 14 ++++++++++++++ package/fail2ban/S60fail2ban | 23 +++++++++++++++++++++++ package/fail2ban/fail2ban.hash | 3 +++ package/fail2ban/fail2ban.mk | 28 ++++++++++++++++++++++++++++ 5 files changed, 69 insertions(+) create mode 100644 package/fail2ban/Config.in create mode 100644 package/fail2ban/S60fail2ban create mode 100644 package/fail2ban/fail2ban.hash create mode 100644 package/fail2ban/fail2ban.mk