]> granicus.if.org Git - icinga2/commitdiff
Fixes grammar and punctuation issues in chapters 8, 9, and 10
authorHeike Jurzik <icinga@huhnix.org>
Mon, 23 May 2016 10:47:22 +0000 (12:47 +0200)
committerGunnar Beutner <gunnar.beutner@netways.de>
Mon, 23 May 2016 12:42:02 +0000 (14:42 +0200)
refs #11599

doc/11-icinga2-client.md
doc/8-cli-commands.md
doc/9-icinga2-api.md

index 2a03042cb2cd1b5e066b7498d2107c9fe3f8ed36..2428f475305f5e0878141622100b06dbcfb3fd4f 100644 (file)
@@ -14,9 +14,9 @@ monitoring and high-availability, please continue reading in
 
 > **Tip**
 >
-> Don't panic - there are CLI commands available, including setup wizards for easy installation
+> Don't panic -- there are CLI commands available, including setup wizards for easy installation
 > with SSL certificates.
-> If you prefer to use your own CA (for example Puppet) you can do that as well.
+> If you prefer to use your own CA (for example Puppet), you can do that as well.
 
 
 ## <a id="icinga2-client-scenarios"></a> Client Scenarios
@@ -76,7 +76,7 @@ and zone configuration.
 
 ### <a id="icinga2-client-installation-master-setup"></a> Setup the Master for Remote Clients
 
-If you are planning to use the [remote Icinga 2 clients](11-icinga2-client.md#icinga2-client)
+If you are planning to use the [remote Icinga 2 clients](11-icinga2-client.md#icinga2-client),
 you'll first need to update your master setup.
 
 Your master setup requires the following
@@ -200,7 +200,7 @@ one for you already.
 > and must remain on the master providing the CSR Auto-Signing functionality for security reasons.
 
 The client setup wizard will ask you to generate a valid ticket number using its CN.
-If you already know your remote client's Common Names (CNs) - usually the FQDN - you
+If you already know your remote client's Common Names (CNs) -- usually the FQDN --, you
 can generate all ticket numbers on-demand.
 
 This is also reasonable if you are not capable of installing the remote client, but
@@ -471,7 +471,7 @@ The next step allows you to verify the CA presented by the master.
 
 ![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_setup_wizard_04.png)
 
-If you have chosen to install/update the NSClient++ package the Icinga 2 setup wizard will ask
+If you have chosen to install/update the NSClient++ package, the Icinga 2 setup wizard will ask
 you to do so.
 
 ![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_setup_wizard_05.png)
@@ -485,7 +485,7 @@ Once install and configuration is done, Icinga 2 is automatically started as a W
 ![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_running_service.png)
 
 The Icinga 2 configuration is located inside the `C:\ProgramData\icinga2` directory.
-If you click `Examine Config` in the setup wizard running it will open a new explorer window.
+If you click `Examine Config` in the setup wizard, it will open a new explorer window.
 
 ![Icinga 2 Windows Setup](images/icinga2-client/icinga2_windows_setup_wizard_examine_config.png)
 
@@ -502,8 +502,8 @@ In case you want to restart the Icinga 2 service, run `services.msc` and restart
 
 #### <a id="icinga2-client-installation-client-setup-windows-silent"></a> Silent Windows Client Setup
 
-If you want to install the client silently / unattended use the `/qn` modifier. The
-installation should not trigger a restart but if you want to be completly sure, you can use the `/norestart` modifier.
+If you want to install the client silently/unattended, use the `/qn` modifier. The
+installation should not trigger a restart but if you want to be completly sure you can use the `/norestart` modifier.
 
     C:> msiexec /i C:\Icinga2-v2.4.5-x86.msi /qn /norestart
 
@@ -519,7 +519,7 @@ This is considered as independant satellite using a local scheduler, configurati
 and the possibility to add Icinga 2 features on demand.
 
 There is no difference in the configuration syntax on clients to any other Icinga 2 installation.
-You can also use additional features like notifications directly on the remote client, if you are
+You can also use additional features like notifications directly on the remote client if you are
 required to. Basically everything a single Icinga 2 instance provides by default.
 
 The following convention applies to remote clients:
@@ -585,7 +585,7 @@ Using systemd:
     # systemctl reload icinga2
 
 
-The `update-config` CLI command will fail, if there are uncommitted changes for the
+The `update-config` CLI command will fail if there are uncommitted changes for the
 configuration repository or if your master is part of a HA setup (see https://dev.icinga.org/issues/8292 for details).
 Please review these changes manually, or clear the commit and try again. This is a
 safety hook to prevent unwanted manual changes to be committed by a updating the
@@ -627,7 +627,7 @@ Icinga 2 already provides a variety of `CheckCommand` definitions using the Plug
 Check Commands, but you should also modify the local configuration inside `commands.conf`
 for example.
 
-If you're wondering why you need to keep the same command configuration on the master and
+If you're wondering, why you need to keep the same command configuration on the master and
 remote client: Icinga 2 calculates all required runtime macros used as command arguments on
 the master and sends that information to the client.
 In case you want to limit command arguments or handles values in a different manner, you
index e17b419cf32b5134b652e21fa10ea7b70fa2a407..6ffb8c6cd58267a86fa2cb0352640c091b75f42e 100644 (file)
@@ -276,7 +276,7 @@ Icinga 2 automatically falls back to using the configuration file
 ### Config Validation
 
 The `--validate` option can be used to check if your configuration files
-contain errors. If any errors are found the exit status is 1, otherwise 0
+contain errors. If any errors are found, the exit status is 1, otherwise 0
 is returned. More details in the [configuration validation](8-cli-commands.md#config-validation) chapter.
 
 
@@ -667,7 +667,7 @@ Example filtered by `Service` objects with the name `ping*`:
 ## <a id="config-change-reload"></a> Reload on Configuration Changes
 
 Everytime you have changed your configuration you should first tell Icinga 2
-to [validate](8-cli-commands.md#config-validation). If there are no validation errors you can
+to [validate](8-cli-commands.md#config-validation). If there are no validation errors, you can
 safely reload the Icinga 2 daemon.
 
     # /etc/init.d/icinga2 reload
index eca7efff074e24741e2a87b6a039488c835ba297..f79696b5760302cae5298c4288b4fa6acc7affb0 100644 (file)
@@ -13,7 +13,7 @@ Make sure to restart Icinga 2 to enable the changes you just made:
 
     # service icinga2 restart
 
-If you prefer to set up the API manually you will have to perform the following steps:
+If you prefer to set up the API manually, you will have to perform the following steps:
 
 * Set up X.509 certificates for Icinga 2
 * Enable the `api` feature (`icinga2 feature enable api`)
@@ -253,7 +253,7 @@ example, the following query returns all `Host` objects:
 
     https://localhost:5665/v1/objects/hosts
 
-If you're only interested in a single object you can limit the output to that object by specifying its name:
+If you're only interested in a single object, you can limit the output to that object by specifying its name:
 
     https://localhost:5665/v1/objects/hosts?host=localhost
 
@@ -265,7 +265,7 @@ You can also specify multiple objects:
 
     https://localhost:5665/v1/objects/hosts?hosts=first-host&hosts=second-host
 
-Again - like in the previous example - the name of the URL parameter is the lower-case version of the type. However, because we're specifying multiple objects here the **plural form** of the type is used.
+Again -- like in the previous example -- the name of the URL parameter is the lower-case version of the type. However, because we're specifying multiple objects here the **plural form** of the type is used.
 
 When specifying names for objects which have composite names like for example services the
 full name has to be used:
@@ -685,8 +685,8 @@ Send a `POST` request to the URL endpoint `/v1/actions/reschedule-check`.
 
   Parameter    | Type      | Description
   -------------|-----------|--------------
-  next\_check  | timestamp | **Optional.** The next check will be run at this time. If omitted the current time is used.
-  force\_check | boolean   | **Optional.** Defaults to `false`. If enabled the checks are executed regardless of time period restrictions and checks being disabled per object or on a global basis.
+  next\_check  | timestamp | **Optional.** The next check will be run at this time. If omitted, the current time is used.
+  force\_check | boolean   | **Optional.** Defaults to `false`. If enabled, the checks are executed regardless of time period restrictions and checks being disabled per object or on a global basis.
 
 In addition to these parameters a [filter](9-icinga2-api.md#icinga2-api-filters) must be provided. The valid types for this action are `Host` and `Service`.
 
@@ -784,9 +784,9 @@ Send a `POST` request to the URL endpoint `/v1/actions/acknowledge-problem`.
   ----------|-----------|--------------
   author    | string    | **Required.** Name of the author, may be empty.
   comment   | string    | **Required.** Comment text, may be empty.
-  expiry    | timestamp | **Optional.** If set the acknowledgement will vanish after this timestamp.
+  expiry    | timestamp | **Optional.** If set, the acknowledgement will vanish after this timestamp.
   sticky    | boolean   | **Optional.** If `true`, the default, the acknowledgement will remain until the service or host fully recovers.
-  notify    | boolean   | **Optional.** If `true` a notification will be sent out to contacts to indicate this problem has been acknowledged. The default is false.
+  notify    | boolean   | **Optional.** If `true`, a notification will be sent out to contacts to indicate this problem has been acknowledged. The default is false.
 
 In addition to these parameters a [filter](9-icinga2-api.md#icinga2-api-filters) must be provided. The valid types for this action are `Host` and `Service`.
 
@@ -920,7 +920,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/schedule-downtime`.
   start\_time   | timestamp | **Required.** Timestamp marking the beginning of the downtime.
   end\_time     | timestamp | **Required.** Timestamp marking the end of the downtime.
   duration      | integer   | **Required.** Duration of the downtime in seconds if `fixed` is set to false.
-  fixed         | boolean   | **Optional.** Defaults to `true`. If true the downtime is `fixed` otherwise `flexible`. See [downtimes](5-advanced-topics.md#downtimes) for more information.
+  fixed         | boolean   | **Optional.** Defaults to `true`. If true, the downtime is `fixed` otherwise `flexible`. See [downtimes](5-advanced-topics.md#downtimes) for more information.
   trigger\_name | string    | **Optional.** Sets the trigger for a triggered downtime. See [downtimes](5-advanced-topics.md#downtimes) for more information on triggered downtimes.
 
 In addition to these parameters a [filter](9-icinga2-api.md#icinga2-api-filters) must be provided. The valid types for this action are `Host` and `Service`.
@@ -1238,7 +1238,7 @@ The Icinga 2 API returns the `package` name this stage was created for, and also
 generates a unique name for the `stage` attribute you'll need for later requests.
 
 Icinga 2 automatically restarts the daemon in order to activate the new config stage.
-If the validation for the new config stage failed the old stage and its configuration objects
+If the validation for the new config stage failed, the old stage and its configuration objects
 will remain active.
 
 > **Note**
@@ -1463,7 +1463,7 @@ The following parameters need to be specified (either as URL parameters or in a
 The [API permission](9-icinga2-api.md#icinga2-api-permissions) `console` is required for executing
 expressions.
 
-If you specify a session identifier the same script context can be reused for multiple requests. This allows you to, for example, set a local variable in a request and use that local variable in another request. Sessions automatically expire after a set period of inactivity (currently 30 minutes).
+If you specify a session identifier, the same script context can be reused for multiple requests. This allows you to, for example, set a local variable in a request and use that local variable in another request. Sessions automatically expire after a set period of inactivity (currently 30 minutes).
 
 Example for fetching the command line from the local host's last check result: