I just installed fail2ban and it references: before = paths-debian.conf at /etc/fail2ban/jail.conf When I try to start it, it complains about not finding: /var/log/auth.log My point being, I think we should maintain our own paths definition.
AFAIAA upstream tends to be very receptive toward any changes you might suggest, but do know that Debian chooses defaults for you that you sometimes cannot even replace, which means fail2ban can be easily configured for Debian systems. I am sure the fail2ban authors are quite well aware of that That you get a huge choice of syslogger alternatives with Gentoo means you get to rewrite fail2ban's configuration to match your precise system instead of a default like /var/log/auth.log. You could even reconfigure your syslogger instead to use /var/log/auth.log for logging user authentication related events. What do you even expect a gentoo-paths.conf to look like, except in a narrow sense one that matches your exact setup?
If this is the case, IMHO, there still should be a gentoo-paths.conf proposal; a minial one; with commented out options in case you use the more mainstream setup. For example: * If you use systemd and journald, you could have a section to comment out for it to work fine as it is. * If you don't, you could have accurate defaults to whatever logger you're using (rsyslog seems to be popular) In any case, a minimal template could work for starters with comments. Eventually, we could invite the systemd maintainer to setup sensible defaults for systemd; rsyslog maintainer the same. The point, IMHO, is to be able to install and start it without much hassle. I know Gentoo is so configurable that you could end with hundreds of variants, but at least that.
(In reply to Renich Bon Ciric from comment #2) > * If you don't, you could have accurate defaults to whatever logger you're > using (rsyslog seems to be popular) Popular, you say? It isn't even _mentioned_ in the Handbook and comes second after app-admin/metalog in the virtual/logger RDEPEND list. Maybe that's an omission, but then again the Handbook barely mentions journald and does not even mention _its_ name explicitly. https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Tools#System_logger > In any case, a minimal template could work for starters with comments. > Eventually, we could invite the systemd maintainer to setup sensible > defaults for systemd; rsyslog maintainer the same. Assuming everyone is using systemd and rsyslog? > The point, IMHO, is to be able to install and start it without much hassle. > I know Gentoo is so configurable that you could end with hundreds of > variants, but at least that. So following your own reasoning it's a pointless exercise that no one in their right minds is going to actually support and that very few people are going to appreciate. Never mind _maintain_ the replacement default configuration. Even renaming it from debian-paths.conf to gentoo-paths.conf and tweaking it to match some set of expected defaults would rile a good bunch of other users. fail2ban on Gentoo Linux cannot possibly run well out of the box - it always requires minimal configuration. You're better off writing a wiki for it than to pursue a "golden configuration" that magically works for everyone or even most everyone.
well, how about forgetting about popularity and going for minimalism? Think of it as a placeholder for your own configuration.
(In reply to Renich Bon Ciric from comment #4) > well, how about forgetting about popularity and going for minimalism? Think > of it as a placeholder for your own configuration. We already have all the files in place. The only apparent problem appears to be the naming of some of the files.
(In reply to Jeroen Roovers from comment #5) > We already have all the files in place. The only apparent problem appears to > be the naming of some of the files. Well, sounds like a good start ;)
(In reply to Renich Bon Ciric from comment #6) > (In reply to Jeroen Roovers from comment #5) > > We already have all the files in place. The only apparent problem appears to > > be the naming of some of the files. > > Well, sounds like a good start ;) paths-debian.conf is why this bug is RESOLVED => WORKSFORME. You will need to come up with a better reason than vanity (or possibly a deep-rooted dislike for Debian?).
Wow. OK. I will try to think why would gentoo want a file for it's own minimal configuration. * Practical You could install fail2ban and have it working from the start. * Incremental It would help let you build up upon this minal configuration, your own fail2ban configuration; while providing helpful comments if you're going to use any subsystem. * Collaborative It will let other devs, for example, the ssh dev, provide a nice template to start using it. Same goes for MTA devs or contributors. This is an important point since, as you know, we are all about collaboration. It would be awesome, for example, for a wordpress user to be able to contribute his fail2ban snippet to avoid brute force attacks on wordpress. I know you can see where this is going and the value of it. And, btw, I don't dislike debian. ;D
(In reply to Renich Bon Ciric from comment #8) > Wow. > > OK. I will try to think why would gentoo want a file for it's own minimal > configuration. As far as I can tell, that file would be empty. You haven't shown the contrary yet, so we're talking about a magical file that does all of the things you describe below. > * Practical > You could install fail2ban and have it working from the start. No, you have to configure fail2ban before it starts doing any work, or it might block your remote access to the system. > * Incremental > It would help let you build up upon this minal configuration, your own > fail2ban configuration; while providing helpful comments if you're going to > use any subsystem. This is what upstream already put in place. It is not a special feature of your magical Gentoo configuration file. > * Collaborative > It will let other devs, for example, the ssh dev, provide a nice template to > start using it. Same goes for MTA devs or contributors. This is an important > point since, as you know, we are all about collaboration. It would be > awesome, for example, for a wordpress user to be able to contribute his > fail2ban snippet to avoid brute force attacks on wordpress. I know you can > see where this is going and the value of it. See previous comment. Also, it looks like what you would like is that we're not just doing upstream maintenance work matching their configuration system and logic changes with ours, but also developing a new sub-system for integrating downstream contributions, and ultimately maintaining those downstream contributions as well.
(In reply to Jeroen Roovers from comment #9) > As far as I can tell, that file would be empty. You haven't shown the > contrary yet, so we're talking about a magical file that does all of the > things you describe below. No; just a file with sane defaults. Like every major distro does. Don't tell me you lack the creativity and knowledge of the Gentoo ecosystem to devise something up? I am sure you can! You're a Gentoo developer! Come on! > No, you have to configure fail2ban before it starts doing any work, or it > might block your remote access to the system. I agree. One should configure everything one needs. Yet, sane defaults should be in place. For example, you might want to block ssh brute force attacks. SSH uses port 22. Also, you would not want to use tcp-wrappers since it's unmaintained so, a note suggesting to use any of the other methods (iptables, firewalld, nftables, etc) and easy action options in a comment. You might want to be opinionated and suggest the use of ipset because it's the more performant; or something like this. > This is what upstream already put in place. It is not a special feature of > your magical Gentoo configuration file. Magical configuration files don't exist. Well commented ones do. Sane defaults do exist. One could suggest and, even, not endorse the use of one of the combinations of options. You get me, right? > See previous comment. Also, it looks like what you would like is that we're > not just doing upstream maintenance work matching their configuration system > and logic changes with ours, but also developing a new sub-system for > integrating downstream contributions, and ultimately maintaining those > downstream contributions as well. No; not really. Just make good use of our ticket system, git repos and good will and knowledge to let users suggest actions and jails. KISS. Now, maybe I could try and suggest something, if you're willing to read it and critique it.
