#3 Undocumented/broken match syntax

[Evgenii Terechkov]

Seems like only last of "match"-es actually applied to file contents. It is very inconvenient to add one file again and again to match another pattern. This important misfeature is undocumented, AFAIK.

Additionally, I discovered that ".+" pattern never worked on my test system. Replacing it to ".*" make it match. Not quite sure, but I think it can be related with used regexp library.

[Phil]

Yes, subsequent 'match' statements overwrite each other, just like all the other statements do. Preventing this would mean to have some sort of final statement which acts as a delimiter between sets of {file, match, options, actions}. I don't like this design, as it forces the statements to occur in a given ordering.

To keep you from going crazy, you might be able to utilize the default statements feature. E.g. a config like this:

/var/log/auth {
    match "bla"
    limit 3
    timeout 60
    ban "/sbin/ban"
    unban "/sbin/unban"
}

/var/log/auth {
    match "blub"
    limit 3
    timeout 60
    ban "/sbin/ban"
    unban "/sbin/unban"
}

may be simplified to:

limit 3
timeout 60
ban "/sbin/ban"
unban "/sbin/unban"

/var/log/auth {
    match "bla"
}
/var/log/auth {
    match "blub"
}

This is not perfect, but better than nothing. And indeed this should be explicitly pointed out in mf2b.conf.5.

Regarding your pattern problem, this is a limitation of glibc's POSIX regex implementation. I chose it over PCRE since the added library dependency outweighs the gained functionality in my point of view. Keeping things down to a minimum is what distinguishes mf2b from fail2ban. Besides, shouldn't '..*' be a full substitute for '.+'?

[Evgenii Terechkov]

Nope. ".*" will match zero or more chars and ".+" will match one or more chars (maybe it is just PCRE in my brain :-)).

[Phil]

That's correct. Note the double dot in my substitute: '..*' here the first dot matches one character and the rest covers any additional ones.