Difference between revisions of "FEATURE Client Server"
From Fail2ban
Jump to navigationJump to searchLostcontrol (talk | contribs) |
(grammar) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== Client/Server architecture == | == Client/Server architecture == | ||
| − | Until version 0.6, {{Fail2ban}} daemon | + | Until version 0.6, {{Fail2ban}} daemon was simply an application running in background and detached from any terminal. It did not allow reconfiguration of the daemon while running or any type of communication with it. |
| − | {{Fail2ban}} is split into two parts: | + | {{Fail2ban}} is now split into two parts: |
* Server | * Server | ||
* Client | * Client | ||
| − | The ''Server'' | + | The ''Server'' daemon monitors log file(s) and executes actions when a host is to be banned. The configuration of the ''Server'' is done by the ''Client'' which handles reading of 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. |
== Protocol == | == Protocol == | ||
* Commands are serialized before sending. Every command must end with the string <tt><F2B_END_COMMAND></tt> which is used to detect the end of a command. The flag <tt><F2B_END_COMMAND></tt> is added '''at the end''' of the serialized string. | * Commands are serialized before sending. Every command must end with the string <tt><F2B_END_COMMAND></tt> which is used to detect the end of a command. The flag <tt><F2B_END_COMMAND></tt> is added '''at the end''' of the serialized string. | ||
| − | * | + | * Every time a command is sent to ''Server'', the server replies with the status of the executed command. |
| − | Commands are | + | Commands are split into several categories: |
=== General === | === General === | ||
Latest revision as of 04:07, 10 February 2017
Client/Server architecture
Until version 0.6, Fail2ban daemon was simply an application running in background and detached from any terminal. It did not allow reconfiguration of the daemon while running or any type of communication with it.
Fail2ban is now split into two parts:
- Server
- Client
The Server daemon monitors log file(s) and executes actions when a host is to be banned. The configuration of the Server is done by the Client which handles reading of 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.
Protocol
- Commands are serialized before sending. Every command must end with the string <F2B_END_COMMAND> which is used to detect the end of a command. The flag <F2B_END_COMMAND> is added at the end of the serialized string.
- Every time a command is sent to Server, the server replies with the status of the executed command.
Commands are split into several categories:
General
| add | <Jail> | Create a new Jail |
| start | <Jail> | Start the Jail |
| stop | <Jail> | Stop the Jail |
| quit | Quit the daemon |
Set
Logging
| set | loglevel | <value> | Set the log level to the value |
Jail
| set | <Jail> | idle | <value> | Set the Jail idle flag to value (on|off) |
Filter
| set | <jail> | logpath | <value> | Set the path value of the log file for Jail |
| set | <jail> | timeregex | <value> | Set the regular expression value matching the date format for Jail |
