Docs: Fixed some typos.

Signed-off-by: Michael Friedrich <Michael.Friedrich@netways.de>

doc/1-about.md

@@ -32,14 +32,14 @@ Please get in touch with the Icinga team at [https://www.icinga.org/ecosystem/].
 ### What's New in Version 0.0.10
 
 * Make Host and Service checkable. #5919
-* Support new lines in addition to commas to seperate object attributes. #5901
+* Support new lines in addition to commas to separate object attributes. #5901
 * Add group membership assign rules. #5910
 * Support nested groups. #5858
 * Add apply target type. #5924
 * Add relative object names. #5925
 * Merge macros and custom into 'vars' dictionary. Changed runtime macros and environment variable export. #5855
 * Add support for modified attributes for custom attributes. #5956
-* Allow to assign var values to existin vars evaluted on runtime. #5959
+* Allow to assign var values to existing vars evaluted on runtime. #5959
 * Rename/shorten attribute names and filter variables. #5857 
 * Remove the 'Icinga' prefix for global constants. #5960
 * Global option to enable/disable host/service checks. #5975

doc/2.1-setting-up-icinga-2.md

@@ -95,7 +95,7 @@ The `include` directive can be used to include other files.
      */
     include "features-enabled/*.conf"
 
-This include directive takes care of including the configuration files for all
+This `include` directive takes care of including the configuration files for all
 the features which have been enabled with `icinga2-enable-feature`. See
 [Enabling/Disabling Features](#features) for more details.
 

doc/2.2-setting-up-check-plugins.md

@@ -41,7 +41,7 @@ list of popular community sites which host check plugins:
 * [Icinga Wiki](https://wiki.icinga.org)
 
 The recommended way of setting up these plugins is to copy them to a common directory
-and creating an extra global constant, e.g. `CustomPluginDir` in your `constants.conf`
+and create an extra global constant, e.g. `CustomPluginDir` in your `constants.conf`
 configuration file:
 
     # cp check_snmp_int.pl /opt/plugins

doc/2.3-setting-up-ido.md

@@ -121,7 +121,7 @@ setting up a PostgreSQL database for Icinga 2:
 
 Locate your pg_hba.conf (Debian: `/etc/postgresql/*/main/pg_hba.conf`,
 RHEL/SUSE: `/var/lib/pgsql/data/pg_hba.conf`), add the icinga user with md5
-authentification method and restart the postgresql server.
+authentication method and restart the postgresql server.
 
     # vim /var/lib/pgsql/data/pg_hba.conf
 

doc/3.01-hosts-and-services.md

@@ -40,8 +40,6 @@ address is associated with the host object.
 
 ### <a id="host-states"></a> Host States
 
-Hosts can be in any of the following states:
-
 Hosts can be in any of the following states:
 
   Name        | Description
@@ -62,13 +60,13 @@ Services can be in any of the following states:
 
 ### <a id="hard-soft-states"></a> Hard and Soft States
 
-When detecting a problem with a service Icinga re-checks the service a number of
+When detecting a problem with a host/service Icinga re-checks the object a number of
 times (based on the `max_check_attempts` and `retry_interval` settings) before sending
 notifications. This ensures that no unnecessary notifications are sent for
-transient failures. During this time the service is in a `SOFT` state.
+transient failures. During this time the object is in a `SOFT` state.
 
-After all re-checks have been executed and the service is still in a non-OK
-state the service switches to a `HARD` state and notifications are sent.
+After all re-checks have been executed and the object is still in a non-OK
+state the host/service switches to a `HARD` state and notifications are sent.
 
   Name        | Description
   ------------|--------------

doc/3.02-commands.md

@@ -4,7 +4,7 @@ Icinga 2 uses three different command object types to specify how
 checks should be performed, notifications should be sent and
 events should be handled.
 
-### <a id="command-environment-variables"></a> Environment Varialbes for Commands
+### <a id="command-environment-variables"></a> Environment Variables for Commands
 
 Please check [Runtime Custom Attributes as Environment Variables](#runtime-custom-attribute-env-vars).
 

doc/3.03-custom-attributes-runtime-macros.md

@@ -151,7 +151,7 @@ services:
   ---------------------------|--------------
   service.name               | The short name of the service object.
   service.display_name       | The value of the `display_name` attribute.
-  service.check_command      | This is an alias for the `SERVICEDISPLAYNAME` macro.
+  service.check_command      | The short name of the command along with any arguments to be used for the check.
   service.state              | The service's current state. Can be one of `OK`, `WARNING`, `CRITICAL` and `UNKNOWN`.
   service.state_id           | The service's current state. Can be one of `0` (ok), `1` (warning), `2` (critical) and `3` (unknown).
   service.state_type         | The service's current state type. Can be one of `SOFT` and `HARD`.

doc/3.06-groups.md

@@ -1,6 +1,6 @@
 ## <a id="groups"></a> Groups
 
-Groups are used for combining hosts, services and users into
+Groups are used for combining hosts, services, and users into
 accessible configuration attributes and views in external (web)
 interfaces.
 

doc/3.07-time-periods.md

@@ -1,7 +1,7 @@
 ## <a id="timeperiods"></a> Time Periods
 
 Time Periods define time ranges in Icinga where event actions are
-triggered, for example if a service check is executed or not within
+triggered, for example whether a service check is executed or not within
 the `check_period` attribute. Or a notification should be sent to
 users or not, filtered by the `period` and `notification_period`
 configuration attributes for `Notification` and `User` objects.
@@ -47,7 +47,7 @@ as shown below.
     }
     
 If your operation staff should only be notified during workhours
-create a new timeperiod named `workhours` defining a work day with
+create a new timeperiod named `workhours` defining a work day from
 09:00 to 17:00.
 
     object TimePeriod "workhours" {

doc/3.09-event-handlers.md

@@ -2,7 +2,7 @@
 
 Event handlers are defined as `EventCommand` objects in Icinga 2.
 
-Unlike notifications event commands are called on every host/service state change
+Unlike notifications event commands are called on every host/service execution
 if defined. Therefore the `EventCommand` object should define a command line
 evaluating the current service state and other service runtime attributes
 available through runtime macros. Runtime macros such as `$SERVICESTATETYPE$`

doc/4.1-configuration-syntax.md

@@ -13,11 +13,11 @@ objects using the `object` keyword:
     }
 
 In general you need to write each statement on a new line. Expressions started
-with `{`, `(` and `[` extend until the matching closing brace and can be broken
+with `{`, `(` and `[` extend until the matching closing character and can be broken
 up into multiple lines.
 
 Alternatively you can write multiple statements in a single line by separating
-them with a semi-colon:
+them with a semicolon:
 
     object Host "host1.example.org" {
       display_name = "host1"
@@ -33,7 +33,7 @@ you specified to generate its object name.
 Exclamation marks (!) are not permitted in object names.
 
 Objects can contain a comma-separated list of property
-declarations. Instead of commas semi-colons may also be used.
+declarations. Instead of commas semicolons may also be used.
 The following data types are available for property values:
 
 ### Expressions

doc/4.3-object-types.md

@@ -167,7 +167,7 @@ Attributes:
   interval                  | **Optional.** The notification interval (in seconds). This interval is used for active notifications. Defaults to 30 minutes. 
   period                    | **Optional.** The name of a time period which determines when this notification should be triggered. Not set by default.
   types                     | **Optional.** A list of type filters when this notification should be triggered. By default everything is matched.
-  states                    | **Optional.** A list of type filters when this notification should be triggered. By default everything is matched.
+  states                    | **Optional.** A list of state filters when this notification should be triggered. By default everything is matched.
 
 Available notification state filters:
 
@@ -225,7 +225,7 @@ Attributes:
   disable_checks  |**Optional.** Whether to disable checks when this dependency fails. Defaults to false.
   disable_notifications|**Optional.** Whether to disable notifications when this dependency fails. Defaults to true.
   period          |**Optional.** Time period during which this dependency is enabled.
-  state_filter    |**Optional.** A list of type filters when this dependency should be OK. Defaults to [ OK, Warning ] for services and [ Up ] for hosts.
+  state_filter    |**Optional.** A list of state filters when this dependency should be OK. Defaults to [ OK, Warning ] for services and [ Up ] for hosts.
 
 Available state filters: