Merge pull request #16 from opendistro/master

ashwinkumar12345 · web-flow · commit 4087a4e1a0d0 · 2020-12-08T22:29:59.000-08:00
merge
diff --git a/docs/elasticsearch/cluster.md b/docs/elasticsearch/cluster.md
@@ -180,7 +180,7 @@ less /var/log/elasticsearch/odfe-cluster.log
 Perform the following `_cat` query on any node to see all the nodes formed as a cluster:
 
 ```bash
-curl -XGET https://<private-ip>:9200/_cat/nodes?v -u admin:admin --insecure
+curl -XGET https://<private-ip>:9200/_cat/nodes?v -u 'admin:admin' --insecure
 ```
 
 ```
diff --git a/docs/elasticsearch/full-text.md b/docs/elasticsearch/full-text.md
@@ -41,7 +41,7 @@ GET _search
 For an example that uses [curl](https://curl.haxx.se/), try:
 
 ```bash
-curl --insecure -XGET -u admin:admin https://<host>:<port>/<index>/_search \
+curl --insecure -XGET -u 'admin:admin' https://<host>:<port>/<index>/_search \
   -H "content-type: application/json" \
   -d '{
     "query": {
diff --git a/docs/elasticsearch/index-data.md b/docs/elasticsearch/index-data.md
@@ -50,7 +50,7 @@ The document is optional, because `delete` actions do not require a document. Th
 To index bulk data using the `curl` command, navigate to the folder where you have your file saved and run the following command:
 
 ```json
-curl -H "Content-Type: application/x-ndjson" -POST https://localhost:9200/data/_bulk -u admin:admin --insecure --data-binary "@data.json"
+curl -H "Content-Type: application/x-ndjson" -POST https://localhost:9200/data/_bulk -u 'admin:admin' --insecure --data-binary "@data.json"
 ```
 
 If any one of the actions in the `_bulk` API fail, Elasticsearch continues to execute the other actions. Examine the `items` array in the response to figure out what went wrong. The entries in the `items` array are in the same order as the actions specified in the request.
diff --git a/docs/images/kibana-gantt-chart.png b/docs/images/kibana-gantt-chart.png
diff --git a/docs/install/deb.md b/docs/install/deb.md
@@ -78,9 +78,9 @@ These steps assume you're using Ubuntu 18.04.
 1. Send requests to the server to verify that Elasticsearch is up and running:
 
    ```bash
-   curl -XGET https://localhost:9200 -u admin:admin --insecure
-   curl -XGET https://localhost:9200/_cat/nodes?v -u admin:admin --insecure
-   curl -XGET https://localhost:9200/_cat/plugins?v -u admin:admin --insecure
+   curl -XGET https://localhost:9200 -u 'admin:admin' --insecure
+   curl -XGET https://localhost:9200/_cat/nodes?v -u 'admin:admin' --insecure
+   curl -XGET https://localhost:9200/_cat/plugins?v -u 'admin:admin' --insecure
    ```
 
 1. For instructions on installing and running Kibana, see [Kibana](../../kibana/).
diff --git a/docs/install/docker.md b/docs/install/docker.md
@@ -39,9 +39,9 @@ docker run -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" amazon/open
 Then send requests to the server to verify that Elasticsearch is up and running:
 
 ```bash
-curl -XGET https://localhost:9200 -u admin:admin --insecure
-curl -XGET https://localhost:9200/_cat/nodes?v -u admin:admin --insecure
-curl -XGET https://localhost:9200/_cat/plugins?v -u admin:admin --insecure
+curl -XGET https://localhost:9200 -u 'admin:admin' --insecure
+curl -XGET https://localhost:9200/_cat/nodes?v -u 'admin:admin' --insecure
+curl -XGET https://localhost:9200/_cat/plugins?v -u 'admin:admin' --insecure
 ```
 
 To find the container ID:
diff --git a/docs/install/helm.md b/docs/install/helm.md
@@ -57,7 +57,7 @@ The output shows you the specifications instantiated from the install.
 To customize the deployment, pass in the values that you want to override with a custom YAML file:
 
 ```bash
-helm install --values=customevalues.yaml opendistro-es-{{site.odfe_version}}.tgz
+helm install --values=customvalues.yaml opendistro-es-{{site.odfe_version}}.tgz
 ```
 
 #### Sample output
@@ -91,7 +91,7 @@ $ kubectl exec -it opendistro-es-master-1 -- /bin/bash
 You can send requests to the pod to verify that Elasticsearch is up and running:
 
 ```bash
-$ curl -XGET https://localhost:9200 -u admin:admin --insecure
+$ curl -XGET https://localhost:9200 -u 'admin:admin' --insecure
 ```
 
 To set up port forwarding to access Kibana, exit the Elasticsearch shell and run the following command:
@@ -104,8 +104,14 @@ You can now access Kibana from your browser at: http://localhost:5601.
 
 ## Uninstall using Helm
 
+To identify the opendistro-es deployment to be deleted:
+
+```bash
+helm list
+```
+
 To delete or uninstall this deployment, run the following command:
 
 ```bash
-helm delete opendistro-es
+helm delete <opendistro-es deployment>
 ```
diff --git a/docs/install/rpm.md b/docs/install/rpm.md
@@ -59,9 +59,9 @@ Installing and running Open Distro for Elasticsearch from an RPM package is a mo
 1. Send requests to the server to verify that Elasticsearch is up and running:
 
    ```bash
-   curl -XGET https://localhost:9200 -u admin:admin --insecure
-   curl -XGET https://localhost:9200/_cat/nodes?v -u admin:admin --insecure
-   curl -XGET https://localhost:9200/_cat/plugins?v -u admin:admin --insecure
+   curl -XGET https://localhost:9200 -u 'admin:admin' --insecure
+   curl -XGET https://localhost:9200/_cat/nodes?v -u 'admin:admin' --insecure
+   curl -XGET https://localhost:9200/_cat/plugins?v -u 'admin:admin' --insecure
    ```
 
 1. For instructions on installing and running Kibana, see [Kibana](../../kibana).
diff --git a/docs/install/tar.md b/docs/install/tar.md
@@ -53,8 +53,8 @@ The tarball supports CentOS 7, Amazon Linux 2, Ubuntu 18.04, and most other Linu
 1. Open a second terminal session, and send requests to the server to verify that Open Distro for Elasticsearch is up and running:
 
    ```bash
-   curl -XGET https://localhost:9200 -u admin:admin --insecure
-   curl -XGET https://localhost:9200/_cat/plugins?v -u admin:admin --insecure
+   curl -XGET https://localhost:9200 -u 'admin:admin' --insecure
+   curl -XGET https://localhost:9200/_cat/plugins?v -u 'admin:admin' --insecure
    ```
 
 
diff --git a/docs/install/windows.md b/docs/install/windows.md
@@ -83,8 +83,8 @@ Installing Open Distro for Elasticsearch as a Windows service lets it run in the
 After you start Open Distro for Elasticsearch, open a new command prompt window. Then send requests to the server to verify that it is up and running:
 
 ```
-curl -XGET https://localhost:9200 -u admin:admin --insecure
-curl -XGET https://localhost:9200/_cat/plugins?v -u admin:admin --insecure
+curl -XGET https://localhost:9200 -u 'admin:admin' --insecure
+curl -XGET https://localhost:9200/_cat/plugins?v -u 'admin:admin' --insecure
 ```
 
 You must have [curl](https://curl.haxx.se/windows/) installed for these commands to work. Alternatives include [Invoke-RestMethod](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-restmethod?view=powershell-6) (only PowerShell 6 and later support the `-SkipCertificateCheck` flag) and [Postman](https://www.getpostman.com/downloads/).
diff --git a/docs/ism/index.md b/docs/ism/index.md
@@ -40,9 +40,11 @@ You can also include the `policy_id` in an index template so when an index is cr
 ```json
 PUT _index_template/<template_name>
 {
-  "index_patterns": ["index_name-*"],                 
-  "settings": {      
-    "opendistro.index_state_management.policy_id": "policy_id"    
+  "index_patterns": ["index_name-*"],
+  "template": {
+    "settings": {      
+      "opendistro.index_state_management.policy_id": "policy_id"    
+    }
   }
 }
 ```
diff --git a/docs/kibana/gantt.md b/docs/kibana/gantt.md
@@ -0,0 +1,26 @@
+---
+layout: default
+title: Gantt Charts
+parent: Kibana
+nav_order: 10
+---
+
+# Gantt charts
+
+Open Distro for Elasticsearch includes a new Kibana visualization: Gantt charts. These charts show the start, end, and duration of unique events in a sequence. Gantt charts are useful in trace analytics, telemetry, and anomaly detection use cases, where you want to understand interactions and dependencies between various events in a schedule.
+
+For example, consider an index of log data. The fields in a typical set of log data, especially audit logs, contain a specific operation or event with a start time and duration.
+
+To create a Gantt chart, do the following:
+
+1. In the visualizations menu, choose **Create visualization** and **Gantt Chart**.
+1. Choose a source for chart (e.g. some log data).
+1. Under **Metrics**, choose **Event**. For log data, each log is an event.
+1. Select the `**Start Time**` and the **Duration** fields from your data set. The start time is the timestamp for the begining of an event. The duration is the amount of time to add to the start time.
+1. Under **Results**, choose the number of events that you want to display on the chart. Gantt charts sequence events from earliest to latest based on start time.
+1. Choose **Panel settings** to adjust axis labels, time format, and colors.
+1. Choose **Update**.
+
+![Gantt Chart](../../images/kibana-gantt-chart.png)
+
+This Gantt chart the ID for each log on the Y axis. Each bar is a unique event that spans some amount of time. Hover over a bar to see the duration of that event.
diff --git a/docs/kibana/maptiles.md b/docs/kibana/maptiles.md
@@ -2,7 +2,7 @@
 layout: default
 title: WMS Map Server
 parent: Kibana
-nav_order: 2
+nav_order: 5
 ---
 
 # Configure WMS map server
diff --git a/docs/security/access-control/cross-cluster-search.md b/docs/security/access-control/cross-cluster-search.md
@@ -117,13 +117,13 @@ networks:
 After the clusters start, verify the names of each:
 
 ```json
-curl -XGET -u admin:admin -k https://localhost:9200
+curl -XGET -u 'admin:admin' -k https://localhost:9200
 {
   "cluster_name" : "odfe-cluster1",
   ...
 }
 
-curl -XGET -u admin:admin -k https://localhost:9250
+curl -XGET -u 'admin:admin' -k https://localhost:9250
 {
   "cluster_name" : "odfe-cluster2",
   ...
@@ -151,7 +151,7 @@ docker inspect --format='{% raw %}{{range .NetworkSettings.Networks}}{{.IPAddres
 On the coordinating cluster, add the remote cluster name and the IP address (with port 9300) for each "seed node." In this case, you only have one seed node:
 
 ```json
-curl -k -XPUT -H 'Content-Type: application/json' -u admin:admin https://localhost:9250/_cluster/settings -d '
+curl -k -XPUT -H 'Content-Type: application/json' -u 'admin:admin' https://localhost:9250/_cluster/settings -d '
 {
   "persistent": {
     "search.remote": {
@@ -166,13 +166,13 @@ curl -k -XPUT -H 'Content-Type: application/json' -u admin:admin https://localho
 On the remote cluster, index a document:
 
 ```bash
-curl -XPUT -k -H 'Content-Type: application/json' -u admin:admin https://localhost:9200/books/_doc/1 -d '{"Dracula": "Bram Stoker"}'
+curl -XPUT -k -H 'Content-Type: application/json' -u 'admin:admin' https://localhost:9200/books/_doc/1 -d '{"Dracula": "Bram Stoker"}'
 ```
 
 At this point, cross-cluster search works. You can test it using the `admin` user:
 
 ```bash
-curl -XGET -k -u admin:admin https://localhost:9250/odfe-cluster1:books/_search?pretty
+curl -XGET -k -u 'admin:admin' https://localhost:9250/odfe-cluster1:books/_search?pretty
 {
   ...
   "hits": [{
@@ -190,8 +190,8 @@ curl -XGET -k -u admin:admin https://localhost:9250/odfe-cluster1:books/_search?
 To continue testing, create a new user on both clusters:
 
 ```bash
-curl -XPUT -k https://admin:admin@localhost:9200/_opendistro/_security/api/internalusers/booksuser  -H 'Content-Type: application/json' -d '{"password":"password"}'
-curl -XPUT -k https://admin:admin@localhost:9250/_opendistro/_security/api/internalusers/booksuser  -H 'Content-Type: application/json' -d '{"password":"password"}'
+curl -XPUT -k -u 'admin:admin' https://localhost:9200/_opendistro/_security/api/internalusers/booksuser  -H 'Content-Type: application/json' -d '{"password":"password"}'
+curl -XPUT -k -u 'admin:admin' https://localhost:9250/_opendistro/_security/api/internalusers/booksuser  -H 'Content-Type: application/json' -d '{"password":"password"}'
 ```
 
 Then run the same search as before with `booksuser`:
@@ -216,8 +216,8 @@ curl -XGET -k -u booksuser:password https://localhost:9250/odfe-cluster1:books/_
 Note the permissions error. On the remote cluster, create a role with the appropriate permissions, and map `booksuser` to that role:
 
 ```bash
-curl -XPUT -k -u admin:admin -H 'Content-Type: application/json' https://localhost:9200/_opendistro/_security/api/roles/booksrole -d '{"index_permissions":[{"index_patterns":["books"],"allowed_actions":["indices:admin/shards/search_shards","indices:data/read/search"]}]}'
-curl -XPUT -k -u admin:admin -H 'Content-Type: application/json' https://localhost:9200/_opendistro/_security/api/rolesmapping/booksrole -d '{"users" : ["booksuser"]}'
+curl -XPUT -k -u 'admin:admin' -H 'Content-Type: application/json' https://localhost:9200/_opendistro/_security/api/roles/booksrole -d '{"index_permissions":[{"index_patterns":["books"],"allowed_actions":["indices:admin/shards/search_shards","indices:data/read/search"]}]}'
+curl -XPUT -k -u 'admin:admin' -H 'Content-Type: application/json' https://localhost:9200/_opendistro/_security/api/rolesmapping/booksrole -d '{"users" : ["booksuser"]}'
 ```
 
 Both clusters must have the user, but only the remote cluster needs the role and mapping; in this case, the coordinating cluster handles authentication (i.e. "Does this request include valid user credentials?"), and the remote cluster handles authorization (i.e. "Can this user access this data?").
diff --git a/docs/security/access-control/impersonation.md b/docs/security/access-control/impersonation.md
@@ -45,5 +45,5 @@ opendistro_security.authcz.impersonation_dn:
 To impersonate another user, submit a request to the system with the HTTP header `opendistro_security_impersonate_as` set to the name of the user to be impersonated. A good test is to make a GET request to the `_opendistro/_security/authinfo` URI:
 
 ```bash
-curl -XGET -u admin:admin -k -H "opendistro_security_impersonate_as: user_1" https://localhost:9200/_opendistro/_security/authinfo?pretty
+curl -XGET -u 'admin:admin' -k -H "opendistro_security_impersonate_as: user_1" https://localhost:9200/_opendistro/_security/authinfo?pretty
 ```
diff --git a/docs/security/configuration/generate-certificates.md b/docs/security/configuration/generate-certificates.md
@@ -84,9 +84,9 @@ openssl x509 -req -in admin.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreate
 
 ## (Optional) Generate node and client certificates
 
-Follow the steps in [Generate admin certificates](#generate-admin-certificate) with new file names to generate a new certificate for each node and as many client certificates as you need. Each certificate should use its own private key.
+Follow the steps in [Generate an admin certificate](#generate-an-admin-certificate) with new file names to generate a new certificate for each node and as many client certificates as you need. Each certificate should use its own private key.
 
-If you generate node certificates and have `opendistro_security.ssl.transport.enforce_hostname_verification` set to `true` (default), be sure to specify a common name (CN) for the certificate that matches the hostname of the intended node. If you want to use the same node certificate on all nodes (not recommended), set the hostname verification to `false`. For more information, see [Configure TLS certificates](../../security/configuration/tls/#advanced-hostname-verification-and-dns-lookup).
+If you generate node certificates and have `opendistro_security.ssl.transport.enforce_hostname_verification` set to `true` (default), be sure to specify a common name (CN) for the certificate that matches the hostname of the intended node. If you want to use the same node certificate on all nodes (not recommended), set the hostname verification to `false`. For more information, see [Configure TLS certificates](../tls/#advanced-hostname-verification-and-dns-lookup).
 
 
 ### Sample script
@@ -154,7 +154,7 @@ This process generates many files, but these are the ones you need to add to you
 - (Optional) `each-node-cert.pem`
 - (Optional) `each-node-key.pem`
 
-For information about adding and configuring these certificates, see [Docker security configuration](../../install/docker-security/) and [Configure TLS certificates](../tls/).
+For information about adding and configuring these certificates, see [Docker security configuration](../../../install/docker-security/) and [Configure TLS certificates](../tls/).
 
 
 ## Run securityadmin.sh
@@ -165,10 +165,10 @@ After configuring your certificates and starting Elasticsearch, run `securityadm
 ./securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert ../../../config/root-ca.pem -cert ../../../config/admin.pem -key ../../../config/admin-key.pem
 ```
 
-For more information about what this command does, see [Apply configuration changes](../security-admin/) and [Change passwords for read-only users](../../install/docker-security/#change-passwords-for-read-only-users).
+For more information about what this command does, see [Apply configuration changes](../security-admin/).
 {: .tip }
 
-If you use Docker, see [Bash access to containers](../../install/docker/#bash-access-to-containers).
+If you use Docker, see [Bash access to containers](../../../install/docker/#bash-access-to-containers).
 
 
 ## Kibana
diff --git a/docs/security/configuration/security-admin.md b/docs/security/configuration/security-admin.md
@@ -47,9 +47,9 @@ To print all available command line options, run the script with no arguments:
 To load configuration changes to the security plugin, you must provide your admin certificate to the tool:
 
 ```bash
-./securityadmin.sh -cd ../securityconfig/ -icl -nhnv  
-   -cacert ../../../config/root-ca.pem
-   -cert ../../../config/kirk.pem
+./securityadmin.sh -cd ../securityconfig/ -icl -nhnv \
+   -cacert ../../../config/root-ca.pem \
+   -cert ../../../config/kirk.pem \
    -key ../../../config/kirk-key.pem
 ```
 
diff --git a/docs/sql/cli.md b/docs/sql/cli.md
@@ -75,7 +75,7 @@ For a list of all available configurations, see [clirc](https://github.com/opend
 
 1. Index the sample data.
 ```
-curl -H "Content-Type: application/x-ndjson" -POST https://localhost:9200/data/_bulk -u admin:admin --insecure --data-binary "@accounts.json"
+curl -H "Content-Type: application/x-ndjson" -POST https://localhost:9200/data/_bulk -u 'admin:admin' --insecure --data-binary "@accounts.json"
 ```
 
 1. Run a sample SQL command:
diff --git a/docs/sql/index.md b/docs/sql/index.md
@@ -54,7 +54,7 @@ POST _opendistro/_sql
 For a sample [curl](https://curl.haxx.se/) command, try:
 
 ```bash
-curl -XPOST https://localhost:9200/_opendistro/_sql -u admin:admin -k -H 'Content-Type: application/json' -d '{"query": "SELECT * FROM kibana_sample_data_flights LIMIT 10"}'
+curl -XPOST https://localhost:9200/_opendistro/_sql -u 'admin:admin' -k -H 'Content-Type: application/json' -d '{"query": "SELECT * FROM kibana_sample_data_flights LIMIT 10"}'
 ```
 
 By default, queries return data in JDBC format, but you can also return data in standard Elasticsearch JSON, CSV, or raw formats:
diff --git a/docs/upgrade/1-11.0.md b/docs/upgrade/1-11.0.md
@@ -13,27 +13,12 @@ Instead of incrementing the `opendistro_sql_workbench` version number, remove th
 
 ## Alerting and anomaly detection
 
-If you’re upgrading from an older ODFE version and you've enabled filter by backend roles with the following setting:
+If you’re upgrading from an older ODFE version and have enabled `opendistro.alerting.filter_by_backend_roles`, make sure you're aware of the following usage considerations for the alerting and anomaly detection plugins:
 
-```json
-PUT _cluster/settings
-{
-  "transient": {
-    "opendistro.alerting.filter_by_backend_roles": "true"
-  }
-}
-```
+- For detectors or monitors created prior to the upgrade, only admin users can assign permissions.
 
-Make sure you’re aware of the following:
+  After upgrading to the new ODFE version, we recommend that all admin users update their existing detectors or monitors using the [Update API](../api/#update-detector). If not, the detectors or monitors will not be visible to any user, including that admin user.
 
-### Previously created detectors / monitors
+  You only need to do this once and don’t have to repeat it for future upgrades.
 
-For detectors or monitors created prior to the upgrade, only admin users can assign permissions.
-
-After upgrading to the new ODFE version, we recommend that all admin users must update their existing detectors or monitors using the [Update API](../api/#update-detector). If not, the detectors or monitors will not be visible to any user, including that admin user.
-
-You only need to do this once and don’t have to repeat it for future upgrades.
-
-### Users with no backend roles
-
-All users must have an assigned backend role. If a user doesn’t have any backend role, the user cannot create detectors or monitors even with the correct permissions. This is because users are first filtered by the backend role.
+- All users must have an assigned backend role. If a user doesn’t have any backend role, the user can't create detectors or monitors even with the correct permissions. This is because users are first filtered by the backend role.
diff --git a/docs/upgrade/cluster-restart.md b/docs/upgrade/cluster-restart.md
@@ -59,13 +59,13 @@ The steps on this page are most applicable if you installed Open Distro for Elas
 1. Wait for the cluster to start, and verify that your cluster returns the new version:
 
    ```bash
-   curl -XGET https://localhost:9200 -u admin:admin -k
+   curl -XGET https://localhost:9200 -u 'admin:admin' -k
    ```
 
 1. Verify cluster health and the expected number of nodes:
 
    ```bash
-   curl -XGET https://localhost:9200/_cat/health?v -u admin:admin -k
+   curl -XGET https://localhost:9200/_cat/health?v -u 'admin:admin' -k
    ```
 
 1. Enable shard allocation:
diff --git a/docs/upgrade/docker.md b/docs/upgrade/docker.md
diff --git a/docs/upgrade/rolling.md b/docs/upgrade/rolling.md
