Feature request: Integrate fail2ban

[ScrewTSW]

Display failed authentications counter since last successful login and IP counter in jail

In my opinion this could be a useful metric for server administration.

[BenBE]

I hardly see how this is a useful metric given that many systems that are exposed on the internet will tend to have hundreds or thousands of failed login attempts every day. In my case I don't even care about plain username/password logins anymore as SSH is only allowed public key logins anyway, thus such a metric will have no meaning with such configurations (which you should be doing) This doesn't mean tools like fail2ban shouldn't be used, but mostly they will just be a means to reduce the number of connections that will reach to your login process (past your firewall setup).

But well. Let's take a step back and assume this metric was useful …In order for htop to implement such a metric there needs to be a data source where this information can be gathered from. Ideally this would be as fast as possible with the optimum being just some numbers to read from some socket or file. With fail2ban neither of these information is readily available. While you can ask for the last successful login via lastlog this will not give you the number of failed attempts right away and might even need your system to be configured in a way to provide this information. Another source would be /var/log/auth.log, which is readable by root only, thus useless as a sort for htop when not running as root. Furthermore that file needs some elaborate parsing which you don't want to have in software running as root if you can avoid it. Last there's the files produced by fail2ban, which will involve similar caveats and parsing issues, thus this information is nothing you want ot have running as part of core htop given how little the value and unreliable the gathering of this information is.

There has been a feature request for allowing to introduce custom meters from external sources in #526 which is likely the best fit for implementing this.

[ScrewTSW]

I hardly see how this is a useful metric given that many systems that are exposed on the internet will tend to have hundreds or thousands of failed login attempts every day. In my case I don't even care about plain username/password logins anymore as SSH is only allowed public key logins anyway, thus such a metric will have no meaning with such configurations (which you should be doing) This doesn't mean tools like fail2ban shouldn't be used, but mostly they will just be a means to reduce the number of connections that will reach to your login process (past your firewall setup).

But well. Let's take a step back and assume this metric was useful …In order for htop to implement such a metric there needs to be a data source where this information can be gathered from. Ideally this would be as fast as possible with the optimum being just some numbers to read from some socket or file. With fail2ban neither of these information is readily available. While you can ask for the last successful login via lastlog this will not give you the number of failed attempts right away and might even need your system to be configured in a way to provide this information. Another source would be /var/log/auth.log, which is readable by root only, thus useless as a sort for htop when not running as root. Furthermore that file needs some elaborate parsing which you don't want to have in software running as root if you can avoid it. Last there's the files produced by fail2ban, which will involve similar caveats and parsing issues, thus this information is nothing you want ot have running as part of core htop given how little the value and unreliable the gathering of this information is.

There has been a feature request for allowing to introduce custom meters from external sources in #526 which is likely the best fit for implementing this.

Fair enough. I found some other ways to gather such data as I've been playing with the possible implementation a little, but you're right. Having the generic meter script would be way better and much more customizable. One thing I don't understand though, is why would you limit it to 4 slots only? Why not allow as many as the user desires? (Performance hits are the user's responsibility and trade-off to decide)

If the custom meter is a feature that has high chance of getting implemented, I think we can safely close my feature request as it becomes obsolete

[BenBE]

Fair enough. I found some other ways to gather such data as I've been playing with the possible implementation a little, but you're right. Having the generic meter script would be way better and much more customizable.

That's why this is the favored solution over re-implementing one meter after the other for things that are too narrow in their use-case to warrant code directly in htop.

One thing I don't understand though, is why would you limit it to 4 slots only? Why not allow as many as the user desires? (Performance hits are the user's responsibility and trade-off to decide)

The limit is more on the number of data points per such meter. Depending on the implementation there's still a chance to have multiple such meters (for different things). Read as "You can have multiple meters, but each meter may only present up to 4 values at a time"; similar to e.g. the memory meter showing multiple values. The limit here is the color scheme, which has at most 7/8 colors.

If the custom meter is a feature that has high chance of getting implemented, I think we can safely close my feature request as it becomes obsolete

Give the amount of work in other places still open, there's no active work on that particular feature. But the custom meters is a feature that has a high chance of making it into htop at some point - given someone takes it up and helps with its implementation.

[ScrewTSW]

Thanks for the explanation, I guess in that case, we can keep the issue open till there's a PR for the custom meters

[rubyFeedback]

Personally I don't need this, but I think it would be nice if htop could become a bit "modularized", so people can cherry-pick what they may want or use - see how conky is fairly modular (sort of) and people adjust it to their likings. I don't know how trivial it is to provide an ecosystem of addons or optional features in a C-driven code base though. It is most likely not so important considering to other, more htop-centric features admittedly so. But who knows, perhaps in 5 years or something, with htop 4. :D

[natoscott]

| I don't know how trivial it is to provide an ecosystem of addons [...]

@rubyFeedback this already exists and is part of htop already, in a way. Have a look into pcp-htop(1) and pcp-htop(5).

This tool is like regular htop except its modular - sampling of metrics is performed via an API, metrics are named and new/custom metrics can be added to the namespace and used by pcp-htop in exactly the way you seek. You can use that today if you need more esoteric plugins than regular htop provides.

It's part of the htop code base and allows any metric from any domain to be displayed, via the Performance Co-Pilot plugin APIs (which can be C/C++/perl/python). See pcp.io and pcp.readthedocs.io for further details if interested.