Update 08-advanced-topics.md

[icinga2] / doc / 15-troubleshooting.md

diff --git a/doc/15-troubleshooting.md b/doc/15-troubleshooting.md
index bd1603b241c3be0bdc40f43c516543c609229076..f5473ff75030b78876b6746a46ab39588e8f4329 100644 (file)
--- a/doc/15-troubleshooting.md
+++ b/doc/15-troubleshooting.md
@@ -29,7 +29,7 @@ findings and details please.
        * The newest Icinga 2 crash log if relevant, located in `/var/log/icinga2/crash`
 * Additional details
        * If the check command failed, what's the output of your manual plugin tests?
-       * In case of [debugging](20-development.md#development) Icinga 2, the full back traces and outputs
+       * In case of [debugging](21-development.md#development) Icinga 2, the full back traces and outputs
 
 ## Analyze your Environment <a id="troubleshooting-analyze-environment"></a>
 
@@ -225,7 +225,7 @@ You need to restart Icinga 2 in order to update the `icinga2.debug` cache file.
 
 ### Apply rules do not match <a id="apply-rules-do-not-match"></a>
 
-You can analyze apply rules and matching objects by using the [script debugger](19-script-debugger.md#script-debugger).
+You can analyze apply rules and matching objects by using the [script debugger](20-script-debugger.md#script-debugger).
 
 ### Where are the check command definitions? <a id="check-command-definitions"></a>
 
@@ -369,7 +369,7 @@ The feature 'checker' is already enabled.
 Fetch all check result events matching the `event.service` name `random`:
 
 ```
-$ curl -k -s -u root:icinga -X POST 'https://localhost:5665/v1/events?queue=debugchecks&types=CheckResult&filter=match%28%22random*%22,event.service%29'
+$ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/events?queue=debugchecks&types=CheckResult&filter=match%28%22random*%22,event.service%29'
 ```
 
 
@@ -488,10 +488,6 @@ Clients which have the `checker` feature enabled will attempt
 to execute checks for local services and send their results
 back to the master.
 
-> **Note**
->
-> This is part of the deprecated client bottom up mode.
-
 If you now have the same host and service objects on the
 master you will receive wrong check results from the client.
 
@@ -676,7 +672,7 @@ The feature 'notification' is already enabled.
 You can use the Icinga 2 API [event streams](12-icinga2-api.md#icinga2-api-event-streams) to receive live notification streams:
 
 ```
-$ curl -k -s -u root:icinga -X POST 'https://localhost:5665/v1/events?queue=debugnotifications&types=Notification'
+$ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/events?queue=debugnotifications&types=Notification'
 ```
 
 ## Feature Troubleshooting <a id="troubleshooting-features"></a>
@@ -726,7 +722,7 @@ Print the CA and client certificate and ensure that the following attributes are
 
 
 ```
-# cd /etc/icinga2/pki/
+# cd /var/lib/icinga2/certs/
 ```
 
 CA certificate:
@@ -788,22 +784,22 @@ Certificate:
 ...
 ```
 
-Make sure to verify the client's certificate and its received `ca.crt` in `/etc/icinga2/pki` and ensure that
+Make sure to verify the client's certificate and its received `ca.crt` in `/var/lib/icinga2/certs` and ensure that
 both instances are signed by the **same CA**.
 
 ```
-# openssl verify -verbose -CAfile /etc/icinga2/pki/ca.crt /etc/icinga2/pki/icinga2-master1.localdomain.crt
+# openssl verify -verbose -CAfile /var/lib/icinga2/certs/ca.crt /var/lib/icinga2/certs/icinga2-master1.localdomain.crt
 icinga2-master1.localdomain.crt: OK
 
-# openssl verify -verbose -CAfile /etc/icinga2/pki/ca.crt /etc/icinga2/pki/icinga2-client1.localdomain.crt
+# openssl verify -verbose -CAfile /var/lib/icinga2/certs/ca.crt /var/lib/icinga2/certs/icinga2-client1.localdomain.crt
 icinga2-client1.localdomain.crt: OK
 ```
 
 Fetch the `ca.crt` file from the client node and compare it to your master's `ca.crt` file:
 
 ```
-# scp icinga2-client1:/etc/icinga2/pki/ca.crt test-client-ca.crt
-# diff -ur /etc/icinga2/pki/ca.crt test-client-ca.crt
+# scp icinga2-client1:/var/lib/icinga2/certs/ca.crt test-client-ca.crt
+# diff -ur /var/lib/icinga2/certs/ca.crt test-client-ca.crt
 ```
 
 On SLES11 you'll need to use the `openssl1` command instead of `openssl`.
@@ -876,7 +872,7 @@ the following
 Try to manually connect from `icinga2-client1.localdomain` to the master node `icinga2-master1.localdomain`:
 
 ```
-# openssl s_client -CAfile /etc/icinga2/pki/ca.crt -cert /etc/icinga2/pki/icinga2-client1.localdomain.crt -key /etc/icinga2/pki/icinga2-client1.localdomain.key -connect icinga2-master1.localdomain:5665
+# openssl s_client -CAfile /var/lib/icinga2/certs/ca.crt -cert /var/lib/icinga2/certs/icinga2-client1.localdomain.crt -key /var/lib/icinga2/certs/icinga2-client1.localdomain.key -connect icinga2-master1.localdomain:5665
 
 CONNECTED(00000003)
 ---
@@ -938,7 +934,7 @@ the following (e.g. by invoking a forced check from the web interface):
 Fetch all check result events matching the `event.service` name `remote-client`:
 
 ```
-$ curl -k -s -u root:icinga -X POST 'https://localhost:5665/v1/events?queue=debugcommandendpoint&types=CheckResult&filter=match%28%22remote-client*%22,event.service%29'
+$ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://localhost:5665/v1/events?queue=debugcommandendpoint&types=CheckResult&filter=match%28%22remote-client*%22,event.service%29'
 ```