fail2ban automatically detects availability of gamin and uses it to listen for changes to logfiles. gamin uses the kernels inotify feature and is way more efficient than the default active polling algorithm fail2ban uses. A already installed libgamin gets detected and used when fail2ban is installed by the current ebuild. So the only change needed to the ebuild: add dev-libs/libgamin to DEPEND for best performance, or at least create a custom USE flag to enable gamin support for informed fail2ban users.
Created attachment 231817 [details] dependent on libgamin with USE flag python
apparently dev-libs/libgamin is not enough, it hast to depend on app-admin/gamin aswell, sorry for that.
Comment on attachment 231817 [details] dependent on libgamin with USE flag python app-admin/gamin dependency missing
Created attachment 231823 [details] dependent on libgamin with USE flag python + app-admin/gamin
Quoting README: Installation: ------------- Required: >=python-2.3 (http://www.python.org) Optional: >=gamin-0.0.21 (http://www.gnome.org/~veillard/gamin)
The old style virtual/fam does this quite well, not gamin alone.
Comment on attachment 231823 [details] dependent on libgamin with USE flag python + app-admin/gamin Please attach patches against current ebuilds instead of complete ebuilds.
(In reply to comment #6) > The old style virtual/fam does this quite well, not gamin alone. Hm, I was wrong. app-admin/fam doesn't itself install a python module. BTW, you would want to DEPEND on app-admin/gamin if at all[1], because fail2ban wants to check local files so you need the server component as well. Maybe we should simply polish up jail.conf so it specifically points to <app-admin/gamin>. [1] After all, you could emerge gamin yourself and set the runtime configuration accordingly, and we could tell users about that explicitly at install time or just let them figure it out while reading the configuration files.
Any progress on that? I plan to release a new revision of fail2ban which fixes all the open bugs but I am not sure what to do with this one. I think depending on gamin makes sense
why not reuse the classic USE="fam"?
(In reply to comment #10) > why not reuse the classic USE="fam"? I concur, gamin has a lot of dependencies that not everyone wants, i think a gamin or fam USE would be better than adding a direct dependency on gamin. my 2¢
*** Bug 421277 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > (In reply to comment #10) > > why not reuse the classic USE="fam"? > > I concur, gamin has a lot of dependencies that not everyone wants, i think a > gamin or fam USE would be better than adding a direct dependency on gamin. > my 2¢ I was leaning towards a hard dependency, or at least a USE flag that's on by default. How many people who seriously want to use fail2ban would want to use it without gamin if they knew that it would wreck performance? Instances of foot-shooting would likely outnumber the people who actually don't want gamin support. On the other hand, glib does pull in more dependencies than I thought it did. The last empty VM I have sync'ed a year ago; I'll update it and see what gets pulled in on a fresh install.
Ok, after an update on a clean install, app-admin/gamin doesn't pull in anything except libgamin and gam-server. It does depend on glib (which pulls in some stuff), however, glib is already installed thanks to, * sys-fs/udev[extras] * sys-fs/udev[gudev] * dev-util/pkgconfig * x11-misc/shared-mime-info An IUSE="+fam" with the conditional dep on libgamin[python] seems like the best way to go. That way, if someone really knows what they're doing (say, running on a kernel with no FAM support), they can prevent pulling in gamin.
Note that the 0.8.7 release of fail2ban (currently ~arch) also has support for pyinotify, which depends only on dev-python/pyinotify. Upstream seemed really enthousiastic about replacing gamin/fam with this backend.
It all depends on what you set instead of 'backend = auto' in jail.conf. Just emerging the backend you want should help you there. It neatly falls back to "polling" when pyinotify and gamin are missing.
(In reply to Jeroen Roovers from comment #16) > It all depends on what you set instead of 'backend = auto' in jail.conf. > Just emerging the backend you want should help you there. It neatly falls > back to "polling" when pyinotify and gamin are missing. But shouldn't they be controlled by use flags? I shouldn't have to do dependency management myself. PHP Packages don't, for example, make me manually emerge mysql if I want to use mysql as my database. There's a mysql USE flag to pull it in, and thus a permanent record in the package DB of why I need mysql installed. The 'fam' USE flag already exists and would be perfect here. If the user doesn't pay close attention, he'll wind up with the polling default (even though he set backend=gamin!) which is terrible. These days, fail2ban prefers pyinotify so I would depend on that instead of gamin, but I still think it should be controlled by a USE flag.
(In reply to Michael Orlitzky from comment #17) > But shouldn't they be controlled by use flags? I shouldn't have to do > dependency management myself. PHP Packages don't, for example, make me > manually emerge mysql if I want to use mysql as my database. There's a mysql > USE flag to pull it in, and thus a permanent record in the package DB of why > I need mysql installed. No, when you install dev-lang/php with USE=mysql, you get a PHP module that handles doing MySQL stuff, which means it builds and links against a library installed by dev-db/mysql. An ebuild should not control runtime dependencies through USE flags when the installed contents of the ebuild itself does not change. Setting up the runtime configuration is equally a bad idea. Back to the present case, fail2ban runs absolutely fine without gamin or pyinotify. And again, controlling merely useful as opposed to necessary runtime dependencies through USE flags is not the way to go. Worse yet, if you use sasl-iptables as backend in jail.conf, then neither gamin nor pyinotify is used because that sets "backend = polling"! If you want, we can add some informative elog messages that are printed when (in order) pyinotify and gamin are not installed, to suggest that either of those could be beneficial. Would that be a solution? Something like: Index: fail2ban-0.8.9.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/net-analyzer/fail2ban/fail2ban-0.8.9.ebuild,v retrieving revision 1.4 diff -u -B -r1.4 fail2ban-0.8.9.ebuild --- fail2ban-0.8.9.ebuild 6 Jun 2013 17:20:14 -0000 1.4 +++ fail2ban-0.8.9.ebuild 7 Jun 2013 14:40:41 -0000 @@ -68,4 +68,10 @@ elog "You are upgrading from version 0.6.x, please see:" elog "http://www.fail2ban.org/wiki/index.php/HOWTO_Upgrade_from_0.6_to_0.8" fi + if ! has_version ${CATEGORY}/${PN} && \ + ! has_version dev-python/pyinotify && ! has_version app-admin/gamin; then + elog "For most jail.conf configurations, it is recommended you install either" + elog "dev-python/pyinotify or app-admin/gamin (in order of preference)" + elog "to control how log file modifications are detected" + fi }
that looks good to me
(In reply to Markos Chandras from comment #19) > that looks good to me I already committed it, too. :)
(In reply to Jeroen Roovers from comment #18) > > No, when you install dev-lang/php with USE=mysql, you get a PHP module that > handles doing MySQL stuff, which means it builds and links against a library > installed by dev-db/mysql. > > An ebuild should not control runtime dependencies through USE flags when the > installed contents of the ebuild itself does not change. Setting up the > runtime configuration is equally a bad idea. > Sorry, I should have been more clear. I meant various PHP apps, like mail-client/roundcube and www-apps/drupal which optionally support both mysql and postgres via a config file. There are a /lot/ of packages that do e.g., RDEPEND="mysql? ( dev-lang/php[mysql] )" thereby pulling in mysql, even though it's only a config-controlled runtime dependency. Basically every application supporting more than one database works this way. I won't press the issue though, no need to waste time arguing.
