Difference between revisions of "FEATURE Client Server"

From Fail2ban
Jump to navigationJump to search
 
Line 1: Line 1:
 
== Client/Server architecture ==
 
== Client/Server architecture ==
  
Until version 0.6, {{Fail2ban}} is a single threaded application. When several sections are defined, each log file is parsed one after the other. This is not a problem when watching a single service. Moreover, when executing a command, {{Fail2ban}} waits for the end of it. This do not allow parsing of the log file at the same time.
+
Until version 0.6, {{Fail2ban}} daemon is simply an application running in background and detached from any terminal. It do not allow reconfiguration of the daemon while it runs or any quite of communication with it.
  
Version >=0.7 will be '''multithreaded'''. Three concepts need to be defined:
+
{{Fail2ban}} is split into two parts:
  
* Jail
+
* Server
** Filter
+
* Client
** Action
 
  
A ''Jail'' contains a ''Filter'' and an ''Action'' object. The ''Filter'' corresponds to the ''LogReader'' class of the previous versions. It take care of watching the log file(s) and notify ''Jail'' of any login failure. The ''Action'' corresponds to the ''Firewall'' class of the previous versions. It take the decision of banning or unbanning a host and execute the corresponding commands.
+
The ''Server'' part monitors log file(s) and executes actions when a host has to be banned. The configuration of the ''Server'' is done by the ''Client'' which take care of reading configuration files. Communication between the ''Client'' and the ''Server'' is done through a socket. A protocol is defined. This allows dynamic reconfiguration of the ''Server'' and communication with it in order to retrieves, per example, statistics.
 
 
''Filter'' and ''Action'' run in two threads. Thus, when starting a new ''Jail'', two new threads will be created. ''Filter'' and ''Action'' are independant and communicate with ''FailTicket'' through ''Jail''. ''FailTicket''s, generated by ''Filter'', are stored into a queue, waiting to be processed by ''Action''.
 
  
 
[[Category:Feature]]
 
[[Category:Feature]]

Revision as of 11:12, 17 May 2006

Client/Server architecture

Until version 0.6, Fail2ban daemon is simply an application running in background and detached from any terminal. It do not allow reconfiguration of the daemon while it runs or any quite of communication with it.

Fail2ban is split into two parts:

  • Server
  • Client

The Server part monitors log file(s) and executes actions when a host has to be banned. The configuration of the Server is done by the Client which take care of reading configuration files. Communication between the Client and the Server is done through a socket. A protocol is defined. This allows dynamic reconfiguration of the Server and communication with it in order to retrieves, per example, statistics.