Fixed some typos.

Documentation/Tutorials/RabbitMQ-Setup-And-MaxScale-Integration.md

@@ -103,7 +103,7 @@ Please note you may also install the rabbitmq server from the EPEL repository:
 
 ### Basic tests with library
 
-The required library librabbitmq-c is now installed and we continue with basic operations with amqp_* tools, located  in the examples/ folder of the build direcotry, testing client server interaction.
+The required library librabbitmq-c is now installed and we continue with basic operations with amqp_* tools, located  in the examples/ folder of the build directory, testing client server interaction.
 
 Please note, those example applications may not be included in the RPM library packages.
 
@@ -267,7 +267,7 @@ The logging result of the example is:
 
 Please note that if we want to log only the user ‘maxtest’ accessing the schema ‘test’ with target ‘my1’  the option logging_strict must be set to TRUE and if we want to include those selects without schema name the option logging_log_all must be set to TRUE.
 
-The mqfilter logs into the MaxScale TRACE log informations about the matched logging triggers and the message delivering:
+The mqfilter logs into the MaxScale TRACE log information about the matched logging triggers and the message delivering:
 
     2014 09/03 06:22:04   Trigger is TRG_SOURCE: user: testuser = testuser
     2014 09/03 06:22:04   Trigger is TRG_SCHEMA: test = test

Documentation/filters/Firewall-Filter.md

@@ -1,9 +1,9 @@
-Firewall filter
+#Firewall filter
 
-# Overview
+## Overview
 The firewall filter is used to block queries that match a set of rules. It can be used to prevent harmful queries into the database or to limit the access to the database based on a more defined set of rules compared to the traditional GRANT-based rights management.
 
-# Configuration
+## Configuration
 
 The firewall filter only requires a minimal set of configurations in the MaxScale.cnf file. The actual rules of the firewall filter are located in a separate text file. The following is an example of a firewall filter configuration in the MaxScale.cnf file.
 
@@ -13,15 +13,15 @@ The firewall filter only requires a minimal set of configurations in the MaxScal
     module=fwfilter
     rules=/home/user/rules.txt
 
-## Filter Options
+### Filter Options
 
-The firewall filter does not support anny filter options.
+The firewall filter does not support any filter options.
 
-## Filter Parameters
+### Filter Parameters
 
 The firewall filter has one mandatory parameter that defines the location of the rule file. This is the 'rules' parameter and it expects an absolute path to the rule file.
 
-# Rule syntax
+## Rule syntax
 
 The rules are defined by using the following syntax.
 
@@ -33,55 +33,55 @@ Rules always define a blocking action so the basic mode for the firewall filter
 
 The first step of defining a rule is to start with the keyword 'rule' which identifies this line of text as a rule. The second token is identified as the name of the rule. After that the mandatory token 'deny' is required to mark the start of the actual rule definition.
 
-## Mandator rule parameters
+### Mandatory rule parameters
 
 The firewall filter's rules expect a single mandatory parameter for a rule. You can define multiple rules to cover situations where you would like to apply multiple mandatory rules to a query.
 
-### Wildcard
+#### Wildcard
 
 This rule blocks all queries that use the wildcard character *.
 
-### Columns
+#### Columns
 
 This rule expects a list of values after the 'columns' keyword. These values are interpreted as column names and if a query targets any of these, it is blocked.
 
-### Regex
+#### Regex
 
 This rule blocks all queries matching a regex enclosed in single or double quotes.
 
-### Limit_queries
+#### Limit_queries
 
 The limit_queries rule expects three parameters. The first parameter is the number of allowed queries during the time period. The second is the time period in seconds and the third is the amount of time for which the rule is considered active and blocking.
 
-### No_where_clause
+#### No_where_clause
 
 This rule inspects the query and blocks it if it has no where clause. This way you can't do a DELETE FROM ... query without having the where clause. This does not prevent wrongful usage of the where clause e.g. DELETE FROM ... WHERE 1=1.
 
-## Optional rule parameters
+### Optional rule parameters
 
 Each mandatory rule accepts one or more optional parameters. These are to be defined after the mandatory part of the rule.
 
-### At_times
+#### At_times
 
 This rule expects a list of time ranges that define the times when the rule in question is active. The time formats are expected to be ISO-8601 compliant and to be separated by a single dash (the - character). For example defining the active period of a rule to be 17:00 to 19:00 you would add 'at times 17:00:00-19:00:00' to the end of the rule.
 
-### On_queries
+#### On_queries
 
 This limits the rule to be active only on certain types of queries.
 
-## Applying rules to users
+### Applying rules to users
 
 To apply the defined rules to users use the following syntax.
 
 `users NAME ... match [any|all] rules RULE ...`
 
-The first keyword is users which identifies this line as a user definition line. After this a list of usernames and network addresses in the format 'user@0.0.0.0' is expected. The first part is the username and the second part is the network address. You can use the '%' character as the wildcard to enable username matching from any address or network matching for all users. After the list of users and networks the keyword match is expected. After this either the keyword 'any' or 'all' is expected. This defined how the rules are matched. If 'any' is used when the first rule is matched the query is considered blocked and the rest of the rules are skipped. If instead the 'all' keyword is used all rules must match for the query to be blocked.
+The first keyword is users which identifies this line as a user definition line. After this a list of user names and network addresses in the format 'user@0.0.0.0' is expected. The first part is the user name and the second part is the network address. You can use the '%' character as the wildcard to enable user name matching from any address or network matching for all users. After the list of users and networks the keyword match is expected. After this either the keyword 'any' or 'all' is expected. This defined how the rules are matched. If 'any' is used when the first rule is matched the query is considered blocked and the rest of the rules are skipped. If instead the 'all' keyword is used all rules must match for the query to be blocked.
 
 After the matching part comes the rules keyword after which a list of rule names is expected. This allows reusing of the rules and enables varying levels of query restriction.
 
-# Examples
+## Examples
 
-## Example rule file
+### Example rule file
 
 The following is an example of a rule file which defines six rules and applies them to three sets of users. This rule file is used in all of the examples.
 
@@ -95,13 +95,13 @@ The following is an example of a rule file which defines six rules and applies t
     users %@80.120.% match any rules block_wildcard dos_block
     users %@% match all rules safe_delete managers_table
 
-## Example 1 - Deny access to personal information and prevent huge queries during peak hours
+### Example 1 - Deny access to personal information and prevent huge queries during peak hours
 
 Assume that a database cluster with tables that have a large number of columns is under heavy load during certain times of the day. Now also assume that large selects and querying of personal information creates unwanted stress on the cluster. Now we wouldn't want to completely prevent all the users from accessing personal information or performing large select queries, we only want to block the users John and Jane.
 
 This can be achieved by creating two rules. One that blocks the usage of the wildcard and one that prevents queries that target a set of columns. To apply these rules to the users we define a users line into the rule file with both the rules and all the users we want to apply the rules to. The rules are defined in the example rule file on line 1 and 2 and the users line is defined on line 7.
 
-## Example 2 - Only safe deletes into the managers table
+### Example 2 - Only safe deletes into the managers table
 
 We want to prevent accidental deletes into the managers table where the where clause is missing. This poses a problem, we don't want to require all the delete queries to have a where clause. We only want to prevent the data in the managers table from being deleted without a where clause.