On 07/12/2015 03:15 PM, E.B. wrote: >> I am willing to have some trust that the developers and some people in >> the community know what they are doing. pyinotify is presumably a newer >> implementation and seems to be preferred over gamin. > Yes, the author of the integration of pyinotify to f2b > Jonathan Underwood explains some reasonable points: > https://sourceforge.net/p/fail2ban/mailman/message/24308907/ > > But I also saw this (from 2008, maybe fixed by now?) > http://www.serpentine.com/blog/2008/01/04/why-you-should-not-use-pyinotify/ > >>> Besides having another daemon (rsyslog) in middle, do you know >>> the scheme used for the systemd backend? Does it also poll >>> or use some type of notify method? >> I don't know off hand, but newer implementations tend to be interrupt >> driven and don't use polling. You could look at the source code. >> Otherwise the developers would know. You could try both and note the >> CPU usage of your fail2ban process/threads. You could also compare the >> response times of the different interfaces by noting the date/time when >> the message was logged and then compare that to the fail2ban log telling >> what time the banning occured. > Thanks. > > ON THE OTHER HAND -- no one has mentioned on a busy system > wouldn't polling be LESS CPU intensive? (at the sacrifice of possibly > missing some filter hits)
You shouldn't miss anything, even with polling, only a time lag will be introduced. If properly implemented fail2ban knows its position in the log file regardless of how often it runs. Generally interrupt driven systems are more efficient and have better response time than polling. You can always use a faster computer. Interrupt driven system can generally handle large numbers of interrupts per second. Yes, it can become a problem if the number of interrupts is excessive, but in practice fail2ban works for most people. If you have thousands of lines written to you log file per second, or even hundreds, you may have a problem. Even the busiest systems I've seen are not that bad. If your system is that busy, then fail2ban might not work for you. All software has bugs. That's just how it is. I've used both gamin and python-inotify and they both seem to work. I have not heard others complain about this issue. Tailing log files to implement intrusion detection is a compromise, over building a direct interface between all components of the system and a central daemon that would manage those events. In practice it works and it's easier to implement. > > Does inotify (pyinotify) have limits set so it doesn't wake > up f2b process too many times a second? > > Probably not, but I don't know without reading the code. There are multiple ways to handle interrupts that occur when you are already within another interrupt. Natu ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
