I don't think there is much sense in such discrimination and hardcoding any plugins to be "system" ones. I would just warn users and then let them shut themselves in the foot if they decide to remove some needed plugins from the chain in configuration.
Some plugins will be mandatory so I don't think it's worth bothering the user with them. I would like to split "functions" into plugins in order to ease the development of new features and allow better testing. We could convert the action/actions code into one or several plugins. Currently, each jail uses 2 threads. We could use only one thread most of the time and just start a new one when executing an action. The "backend" (polling, gamin, etc) could be converted to plugins too. --Lostcontrol 00:13, 7 September 2007 (CEST)
Date remover should not simply remove any found date within the log line. Otherwise, if the logline has timestamp elsewhere than the beginning, and some user-input upfront of it, abuser can pollute the logline with errorenous or misleading date, so that line is not caught by the filter, thus no action is taken, thus DoS or who-knows-what attack can proceed further providing such misleading entries.
At first I was thinking about "tagging" date position within the failregex line, but that might be tricky, that is why, and since virtually all log lines we are dealing with up to now have the date first in the line, I postponed it.
Also, 'prefix remover'-removed part might be desired for matching too.
What I am aiming in my comment is that all parts of the line should be considered in their entirety to some extent. IMHO it might become necessity that we could use result of previous plugins in the current one - like failregex matcher. But that complicates things...
The date plugin will first read and extract the date using the current datedetector code. The date will be stored in the plugin and will be made available to other plugins. Then, the plugin will remove the date from the log line (the date template which matched the date can be used to remove the right substring). This "new" line (without date) will be then go to the "prefix remover" plugin. This plugin will remove the prefix AND extract important data (like pid, process name, etc). These information will be made available to other plugins (getPid(), getProcessName(), etc). --Lostcontrol 00:13, 7 September 2007 (CEST)
What I meant was that we need to specify location of the date within failregex. Smth like
^<DATESTAMP> <PREFIX> bla blue ble from <HOST> is morron\s*$
Yarikoptic 17:07, 7 September 2007 (CEST)