Remove unsupported front matter fields

2026-09-28 05:59:03 +00:00 · 2022-09-23 10:11:24 -07:00
parent 5b064e6548
commit c390289797
1553 changed files with 871 additions and 4500 deletions
@@ -1,11 +1,5 @@
 ---
 title: Backup and Restore for Rancher Installed with Docker
-shortTitle: Docker Installs
-weight: 10
-aliases:
-  - /rancher/v2.5/en/installation/backups-and-restoration/single-node-backup-and-restoration/
-  - /rancher/v2.5/en/backups/v2.5/docker-installs
-  - /rancher/v2.x/en/backups/v2.5/docker-installs/
 ---

 - [Backups](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
@@ -1,8 +1,5 @@
 ---
 title: RKE Cluster Configuration Reference
-weight: 2250
-aliases:
-  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/options/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: Contributing to Rancher
-weight: 27
-aliases:
-  - /rancher/v2.5/en/faq/contributing/
-  - /rancher/v2.x/en/contributing/
 ---

 This section explains the repositories used for Rancher, how to build the repositories, and what information to include when you file an issue.
@@ -1,9 +1,5 @@
 ---
 title: Configuration
-weight: 3
-aliases:
-  - /rancher/v2.5/en/cis-scans/v2.5/configuration
-  - /rancher/v2.x/en/cis-scans/v2.5/configuration/
 ---

 This configuration reference is intended to help you manage the custom resources created by the `rancher-cis-benchmark` application. These resources are used for performing CIS scans on a cluster, skipping tests, setting the test profile that will be used during a scan, and other customization.
@@ -1,21 +1,17 @@
 ---
 title: Creating a Custom Benchmark Version for Running a Cluster Scan
-weight: 4
-aliases:
-  - /rancher/v2.5/en/cis-scans/v2.5/custom-benchmark
-  - /rancher/v2.x/en/cis-scans/v2.5/custom-benchmark/
 ---

 _Available as of v2.5.4_

 Each Benchmark Version defines a set of test configuration files that define the CIS tests to be run by the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool.
 The `rancher-cis-benchmark` application installs a few default Benchmark Versions which are listed under CIS Benchmark application menu.
- 
+
 But there could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them.

 It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-cis-benchmark` application.

-When a cluster scan is run, you need to select a Profile which points to a specific Benchmark Version. 
+When a cluster scan is run, you need to select a Profile which points to a specific Benchmark Version.

 Follow all the steps below to add a custom Benchmark Version and run a scan using it.

@@ -26,7 +22,7 @@ To create a custom benchmark version, first you need to create a ConfigMap conta
 To prepare a custom benchmark version ConfigMap, suppose we want to add a custom Benchmark Version named `foo`.

 1. Create a directory named `foo` and inside this directory, place all the config YAML files that the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool looks for. For example, here are the config YAML files for a Generic CIS 1.5 Benchmark Version https://github.com/aquasecurity/kube-bench/tree/master/cfg/cis-1.5
-1. Place the complete `config.yaml` file, which includes all the components that should be tested. 
+1. Place the complete `config.yaml` file, which includes all the components that should be tested.
 1. Add the Benchmark version name to the `target_mapping` section of the `config.yaml`:

    ```yaml
@@ -46,7 +42,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom

 ### 2. Add a Custom Benchmark Version to a Cluster

-1. Once the ConfigMap has been created in your cluster, navigate to the **Cluster Explorer** in the Rancher UI. 
+1. Once the ConfigMap has been created in your cluster, navigate to the **Cluster Explorer** in the Rancher UI.
 1. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
 1. In the **Benchmark Versions** section, click **Create.**
 1. Enter the **Name** and a description for your custom benchmark version.
@@ -59,7 +55,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom

 To run a scan using your custom benchmark version, you need to add a new Profile pointing to this benchmark version.

-1. Once the custom benchmark version has been created in your cluster, navigate to the **Cluster Explorer** in the Rancher UI. 
+1. Once the custom benchmark version has been created in your cluster, navigate to the **Cluster Explorer** in the Rancher UI.
 1. In the top left dropdown menu, click **Cluster Explorer > CIS Benchmark.**
 1. In the **Profiles** section, click **Create.**
 1. Provide a **Name** and description. In this example, we name it `foo-profile`.
@@ -1,11 +1,5 @@
 ---
 title: Roles-based Access Control
-shortTitle: RBAC
-weight: 3
-aliases:
-  - /rancher/v2.5/en/cis-scans/rbac
-  - /rancher/v2.5/en/cis-scans/v2.5/rbac
-  - /rancher/v2.x/en/cis-scans/v2.5/rbac/
 ---

 This section describes the permissions required to use the rancher-cis-benchmark App.
@@ -17,7 +11,7 @@ However, the `rancher-cis-benchmark` chart installs these two default `ClusterRo
 - cis-admin
 - cis-view

-In Rancher, only cluster owners and global administrators have `cis-admin` access by default. 
+In Rancher, only cluster owners and global administrators have `cis-admin` access by default.

 Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has now been removed since
 Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings
@@ -1,10 +1,5 @@
 ---
 title: Skipped and Not Applicable Tests
-weight: 3
-aliases:
-  - /rancher/v2.5/en/cis-scans/skipped-tests
-  - /rancher/v2.5/en/cis-scans/v2.5/skipped-tests
-  - /rancher/v2.x/en/cis-scans/v2.5/skipped-tests/
 ---

 This section lists the tests that are skipped in the permissive test profile for RKE.
@@ -1,6 +1,5 @@
 ---
 title: Architecture
-weight: 1
 ---

 Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, or Kustomize or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy everything in the cluster. This gives you a high degree of control, consistency, and auditability. Fleet focuses not only on the ability to scale, but to give one a high degree of control and visibility to exactly what is installed on the cluster.
@@ -1,6 +1,5 @@
 ---
 title: Using Fleet Behind a Proxy
-weight: 3
 ---

 _Available as of v2.5.8_
@@ -1,6 +1,5 @@
 ---
 title: Windows Support
-weight: 2
 ---


@@ -1,9 +1,5 @@
 ---
 title: Additional Steps for Installing Istio on an RKE2 Cluster
-weight: 3
-aliases:
-  - /rancher/v2.5/en/istio/v2.5/configuration-reference/rke2
-  - /rancher/v2.x/en/istio/v2.5/configuration-reference/rke2/
 ---

 Through the **Cluster Explorer,** when installing or upgrading Istio through **Apps & Marketplace,**
@@ -1,12 +1,5 @@
 ---
 title: Enable Istio with Pod Security Policies
-weight: 1
-aliases:
-  - /rancher/v2.5/en/istio/setup/enable-istio-in-cluster/enable-istio-with-psp
-  - /rancher/v2.5/en/istio/legacy/setup/enable-istio-in-cluster/enable-istio-with-psp
-  - /rancher/v2.5/en/istio/v2.5/setup/enable-istio-in-cluster/enable-istio-with-psp
-  - /rancher/v2.5/en/istio/v2.5/configuration-reference/enable-istio-with-psp
-  - /rancher/v2.x/en/istio/v2.5/configuration-reference/enable-istio-with-psp/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: Additional Steps for Project Network Isolation
-weight: 4
-aliases:
-  - /rancher/v2.5/en/istio/v2.5/configuration-reference/canal-and-project-network
-  - /rancher/v2.x/en/istio/v2.5/configuration-reference/canal-and-project-network/
 ---

 In clusters where:
@@ -1,25 +1,20 @@
 ---
 title: Selectors and Scrape Configs
-weight: 2
-aliases:
-  - /rancher/v2.5/en/istio/v2.5/configuration-reference/selectors-and-scrape
-  - /rancher/v2.5/en/istio/setup/node-selectors
-  - /rancher/v2.x/en/istio/v2.5/configuration-reference/selectors-and-scrape/
 ---

 The Monitoring app sets `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`, which enables monitoring across all namespaces by default.

-This ensures you can view traffic, metrics and graphs for resources deployed in a namespace with `istio-injection=enabled` label. 
+This ensures you can view traffic, metrics and graphs for resources deployed in a namespace with `istio-injection=enabled` label.

 If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources.

 ### Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True

-This limits monitoring to specific namespaces. 
+This limits monitoring to specific namespaces.

-1. From the **Cluster Explorer**, navigate to **Installed Apps** if Monitoring is already installed, or **Charts** in **Apps & Marketplace** 
-1. If starting a new install, **Click** the **rancher-monitoring** chart, then in **Chart Options** click **Edit as Yaml**. 
-1. If updating an existing installation, click on **Upgrade**, then in **Chart Options** click **Edit as Yaml**. 
+1. From the **Cluster Explorer**, navigate to **Installed Apps** if Monitoring is already installed, or **Charts** in **Apps & Marketplace**
+1. If starting a new install, **Click** the **rancher-monitoring** chart, then in **Chart Options** click **Edit as Yaml**.
+1. If updating an existing installation, click on **Upgrade**, then in **Chart Options** click **Edit as Yaml**.
 1. Set`prometheus.prometheusSpec.ignoreNamespaceSelectors=true`
 1. Complete install or upgrade

@@ -27,26 +22,26 @@ This limits monitoring to specific namespaces.

 ### Enabling Prometheus to Detect Resources in Other Namespaces

-There are two different ways to enable Prometheus to detect resources in other namespaces when `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`: 
+There are two different ways to enable Prometheus to detect resources in other namespaces when `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`:

 - **Monitoring specific namespaces:** Add a Service Monitor or Pod Monitor in the namespace with the targets you want to scrape.
 - **Monitoring across namespaces:** Add an `additionalScrapeConfig` to your rancher-monitoring instance to scrape all targets in all namespaces.

 ### Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor

-This option allows you to define which specific services or pods you would like monitored in a specific namespace. 
+This option allows you to define which specific services or pods you would like monitored in a specific namespace.

 The usability tradeoff is that you have to create the service monitor or pod monitor per namespace since you cannot monitor across namespaces.

-> **Prerequisite:** Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below. 
+> **Prerequisite:** Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below.

 1. From the **Cluster Explorer**, open the kubectl shell
-1. Run `kubectl create -f <name of service/pod monitor file>.yaml` if the file is stored locally in your cluster. 
-1. Or run `cat<< EOF | kubectl apply -f -`, paste the file contents into the terminal, then run `EOF` to complete the command. 
-1. If starting a new install, **Click** the **rancher-monitoring** chart and scroll down to **Preview Yaml**. 
+1. Run `kubectl create -f <name of service/pod monitor file>.yaml` if the file is stored locally in your cluster.
+1. Or run `cat<< EOF | kubectl apply -f -`, paste the file contents into the terminal, then run `EOF` to complete the command.
+1. If starting a new install, **Click** the **rancher-monitoring** chart and scroll down to **Preview Yaml**.
 1. Run `kubectl label namespace <your namespace> istio-injection=enabled` to enable the envoy sidecar injection

-**Result:**  `<your namespace>` can be scraped by prometheus. 
+**Result:**  `<your namespace>` can be scraped by prometheus.

 <figcaption>Example Service Monitor for Istio Proxies</figcaption>

@@ -85,14 +80,14 @@ spec:

 ### Monitoring across namespaces: Set ignoreNamespaceSelectors to False

-This enables monitoring across namespaces by giving Prometheus additional scrape configurations. 
+This enables monitoring across namespaces by giving Prometheus additional scrape configurations.

-The usability tradeoff is that  all of Prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs before installing Istio. 
+The usability tradeoff is that  all of Prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs before installing Istio.

-1. If starting a new install, **Click** the **rancher-monitoring** chart, then in **Chart Options** click **Edit as Yaml**. 
-1. If updating an existing installation, click on **Upgrade**, then in **Chart Options** click **Edit as Yaml**. 
+1. If starting a new install, **Click** the **rancher-monitoring** chart, then in **Chart Options** click **Edit as Yaml**.
+1. If updating an existing installation, click on **Upgrade**, then in **Chart Options** click **Edit as Yaml**.
 1. If updating an existing installation, click on **Upgrade** and then **Preview Yaml**.
-1. Set`prometheus.prometheusSpec.additionalScrapeConfigs` array to the **Additional Scrape Config** provided below. 
+1. Set`prometheus.prometheusSpec.additionalScrapeConfigs` array to the **Additional Scrape Config** provided below.
 1. Complete install or upgrade

 **Result:** All namespaces with the `istio-injection=enabled` label will be scraped by prometheus.
@@ -122,4 +117,4 @@ The usability tradeoff is that  all of Prometheus' `additionalScrapeConfigs` are
    - source_labels: [__meta_kubernetes_pod_name]
      action: replace
      target_label: pod_name
-``` 
+```
@@ -1,12 +1,5 @@
 ---
 title: CPU and Memory Allocations
-weight: 1
-aliases:
-  - /rancher/v2.5/en/project-admin/istio/configuring-resource-allocations/
-  - /rancher/v2.5/en/project-admin/istio/config/
-  - /rancher/v2.5/en/istio/resources
-  - /rancher/v2.5/en/istio/v2.5/resources
-  - /rancher/v2.x/en/istio/v2.5/resources/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: Disabling Istio
-weight: 4
-aliases:
-  - /rancher/v2.5/en/istio/v2.5/disabling-istio
-  - /rancher/v2.x/en/istio/v2.5/disabling-istio/
 ---

 This section describes how to uninstall Istio in a cluster or disable a namespace, or workload.
@@ -16,7 +12,7 @@ To uninstall Istio,
 1. Select `rancher-istio` in the `istio-system namespace and click **Delete**
 1. After `rancher-istio` is deleted, you can then select all the remaining apps in the `istio-system` namespace and click **Delete**

-**Result:** The `rancher-istio` app in the cluster gets removed. The Istio sidecar cannot be deployed on any workloads in the cluster. 
+**Result:** The `rancher-istio` app in the cluster gets removed. The Istio sidecar cannot be deployed on any workloads in the cluster.

 **Note:** You can no longer disable and re-enable your Istio installation. If you would like to save your settings for a future install, view and save individual YAMLs to refer back to / reuse for future installations.

@@ -28,7 +24,7 @@ This could mean a few things. You either selected all the apps in the `istio-sys

 ## Disable Istio in a Namespace

-1. From the **Cluster Explorer** view, use the side-nav to select **Namespaces** page 
+1. From the **Cluster Explorer** view, use the side-nav to select **Namespaces** page
 1. On the **Namespace** page, you will see a list of namespaces. Go to the namespace where you want to disable and click the select **Edit as Form** or **Edit as Yaml**
 1. Remove the `istio-injection=enabled` label from the namespace
 1. Click **Save**
@@ -1,10 +1,5 @@
 ---
 title: Role-based Access Control
-weight: 3
-aliases:
-  - /rancher/v2.5/en/istio/rbac
-  - /rancher/v2.5/en/istio/v2.5/rbac
-  - /rancher/v2.x/en/istio/v2.5/rbac/
 ---

 This section describes the permissions required to access Istio features.
@@ -1,6 +1,5 @@
 ---
 title: Flows and ClusterFlows
-weight: 1
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: Outputs and ClusterOutputs
-weight: 2
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: Architecture
-weight: 1
 ---

 This section summarizes the architecture of the Rancher logging application.
@@ -20,15 +19,15 @@ The following changes were introduced to logging in Rancher v2.5:

 ### How the Banzai Cloud Logging Operator Works

-The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system. 
+The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system.

 Fluent Bit queries the Kubernetes API and enriches the logs with metadata about the pods, and transfers both the logs and the metadata to Fluentd. Fluentd receives, filters, and transfers logs to multiple `Outputs`.

-The following custom resources are used to define how logs are filtered and sent to their `Outputs`: 
+The following custom resources are used to define how logs are filtered and sent to their `Outputs`:

- A `Flow` is a namespaced custom resource that uses filters and selectors to route log messages to the appropriate `Outputs`. 
+- A `Flow` is a namespaced custom resource that uses filters and selectors to route log messages to the appropriate `Outputs`.
 - A `ClusterFlow` is used to route cluster-level log messages.
- An `Output` is a namespaced resource that defines where the log messages are sent. 
+- An `Output` is a namespaced resource that defines where the log messages are sent.
 - A `ClusterOutput` defines an `Output` that is available from all `Flows` and `ClusterFlows`.

 Each `Flow` must reference an `Output`, and each `ClusterFlow` must reference a `ClusterOutput`.
@@ -1,7 +1,5 @@
 ---
 title: rancher-logging Helm Chart Options
-shortTitle: Helm Chart Options
-weight: 4
 ---


@@ -1,13 +1,10 @@
 ---
 title: Migrating to Rancher v2.5 Logging
-weight: 2
-aliases:
-  - /rancher/v2.5/en/logging/v2.5/migrating
-  - /rancher/v2.x/en/logging/v2.5/migrating/
 ---
+
 Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [logging operator](https://github.com/banzaicloud/logging-operator) from Banzai Cloud has been adopted; Rancher configures this tooling for use when deploying logging.

-Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ. 
+Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ.

 > Note: The pre-v2.5 user interface is now referred to as the _Cluster Manager_. The v2.5+ dashboard is referred to as the _Cluster Explorer_.

@@ -18,23 +15,23 @@ To install logging in Rancher v2.5+, refer to the [installation instructions](..

 ### Terminology

-In v2.5, logging configuration is centralized under a _Logging_ menu option available in the _Cluster Explorer_. It is from this menu option that logging for both cluster and namespace is configured. 
+In v2.5, logging configuration is centralized under a _Logging_ menu option available in the _Cluster Explorer_. It is from this menu option that logging for both cluster and namespace is configured.

-> Note: Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster. 
+> Note: Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster.

 There are four key concepts to understand for v2.5+ logging:

 1. Outputs
-   
+
    `Outputs` are a configuration resource that determine a destination for collected logs. This is where settings for aggregators such as ElasticSearch, Kafka, etc. are stored. `Outputs` are namespaced resources.

 2. Flows

-    `Flows` are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which `Outputs` to send the logs to. `Flows` are namespaced resources, and can connect either to an `Output` in the same namespace, or a `ClusterOutput`. 
+    `Flows` are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which `Outputs` to send the logs to. `Flows` are namespaced resources, and can connect either to an `Output` in the same namespace, or a `ClusterOutput`.

 3. ClusterOutputs

-    `ClusterOutputs` serve the same functionality as `Outputs`, except they are a cluster-scoped resource. `ClusterOutputs` are necessary when collecting logs cluster-wide, or if you wish to provide an `Output` to all namespaces in your cluster. 
+    `ClusterOutputs` serve the same functionality as `Outputs`, except they are a cluster-scoped resource. `ClusterOutputs` are necessary when collecting logs cluster-wide, or if you wish to provide an `Output` to all namespaces in your cluster.

 4. ClusterFlows

@@ -42,9 +39,9 @@ There are four key concepts to understand for v2.5+ logging:

 ## Cluster Logging

-To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. 
+To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs.

-> Important: `ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace. 
+> Important: `ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace.

 In legacy logging, in order to collect logs from across the entire cluster, one only needed to enable cluster-level logging and define the desired `Output`. This basic approach remains in v2.5+ logging. To replicate legacy cluster-level logging, follow these steps:

@@ -54,26 +51,26 @@ In legacy logging, in order to collect logs from across the entire cluster, one
   2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
   3. Define your cluster `Output` or `Outputs`

-This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`. 
+This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`.

 ## Project Logging

-Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces. 
+Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces.

 To collect logs from a specific namespace, follow these steps:

 1. Define an `Output` or `ClusterOutput` according to the instructions found under [Output Configuration](#output-configuration)
 2. Create a `Flow`, ensuring that it is set to be created in the namespace in which you want to gather logs.
-   1. If you wish to define _Include_ or _Exclude_ rules, you may do so. Otherwise, removal of all rules will result in all pods in the target namespace having their logs collected. 
+   1. If you wish to define _Include_ or _Exclude_ rules, you may do so. Otherwise, removal of all rules will result in all pods in the target namespace having their logs collected.
   2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
   3. Define your outputs - these can be either `ClusterOutput` or `Output` objects.

 This will result in logs from all sources in the namespace (pods) being collected and sent to the `Output` (or `Outputs`) you defined in your `Flow`.

-> To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label. 
+> To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label.

 ## Output Configuration
-In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. 
+In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+.


 ### Elasticsearch
@@ -158,7 +155,7 @@ _(1) These values are to be specified as paths to files. Those files must be mou

 ### Syslog

-As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging. 
+As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging.

 ## Custom Log Fields

@@ -179,5 +176,5 @@ spec:

 In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways:

-1. Gather all cluster logs, not specifying any match or exclusion rules. This results in all container logs from the cluster being collected, which includes system logs. 
-2. Specifically target system logs by adding match rules for system components. Specific match rules depend on the component being collected. 
+1. Gather all cluster logs, not specifying any match or exclusion rules. This results in all container logs from the cluster being collected, which includes system logs.
+2. Specifically target system logs by adding match rules for system components. Specific match rules depend on the component being collected.
@@ -1,7 +1,5 @@
 ---
-shortTitle: Role-based Access Control
 title: Role-based Access Control for Logging
-weight: 3
 ---

 Rancher logging has two roles, `logging-admin` and `logging-view`.
@@ -1,6 +1,5 @@
 ---
 title: Working with Taints and Tolerations
-weight: 6
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: Longhorn - Cloud native distributed block storage for Kubernetes
-shortTitle: Longhorn Storage
-weight: 19
-aliases:
-  - /rancher/v2.x/en/longhorn/
 ---

 [Longhorn](https://longhorn.io/) is a lightweight, reliable and easy-to-use distributed block storage system for Kubernetes.
@@ -1,6 +1,5 @@
 ---
 title: Built-in Dashboards
-weight: 3
 ---

 ## Grafana UI
@@ -1,6 +1,5 @@
 ---
 title: How Monitoring Works
-weight: 1
 ---


@@ -1,13 +1,5 @@
 ---
 title: PromQL Expression Reference
-weight: 6
-aliases:
-  - /rancher/v2.5/en/project-admin/tools/monitoring/expression
-  - /rancher/v2.5/en/cluster-admin/tools/monitoring/expression
-  - /rancher/v2.5/en/monitoring-alerting/expression
-  - /rancher/v2.5/en/monitoring-alerting/configuration/expression
-  - /rancher/v2.5/en/monitoring/alerting/configuration/expression
-  - /rancher/v2.x/en/monitoring-alerting/v2.5/configuration/expression/
 ---

 The PromQL expressions in this doc can be used to configure alerts.
@@ -1,13 +1,7 @@
 ---
 title: Role-based Access Control
-shortTitle: RBAC
-weight: 2
-aliases:
-  - /rancher/v2.5/en/cluster-admin/tools/monitoring/rbac
-  - /rancher/v2.5/en/monitoring-alerting/rbac
-  - /rancher/v2.5/en/monitoring-alerting/grafana
-  - /rancher/v2.x/en/monitoring-alerting/v2.5/rbac/
 ---
+
 This section describes the expectations for RBAC for Rancher Monitoring.

 ## Cluster Admins
@@ -81,10 +75,10 @@ Monitoring also creates additional `ClusterRoles` that are not assigned to users

 ### Assigning Roles and ClusterRoles with kubectl

-An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command. 
+An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command.


-* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes to attach to a user. You will need to fill in the name below, and name is case-sensitive. 
+* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes to attach to a user. You will need to fill in the name below, and name is case-sensitive.

 ```yaml
 # monitoring-config-view-role-binding.yaml
@@ -1,7 +1,5 @@
 ---
 title: Windows Cluster Support for Monitoring V2
-shortTitle: Windows Support
-weight: 5
 ---

 _Available as of v2.5.8_
@@ -35,15 +33,15 @@ To facilitate this upgrade, Rancher 2.5.8 has released a brand new Helm chart ca
 1. Deploy `rancher-wins-upgrader` with the following override:
    ```yaml
    # Masquerading bootstraps the wins-upgrader installation via
-    # a previously whitelisted process path since the normal install path, 
-    # c:\etc\rancher\wins\wins-upgrade.exe is not normally whitelisted. 
-    # In this case, we are using the previously whitelisted process 
+    # a previously whitelisted process path since the normal install path,
+    # c:\etc\rancher\wins\wins-upgrade.exe is not normally whitelisted.
+    # In this case, we are using the previously whitelisted process
    # path used by Monitoring V1.
    masquerade:
      enabled: true
      as: c:\\etc\wmi-exporter\wmi-exporter.exe
    ```
-    > **Note for Non-Default Windows Prefix Path:** If you set up the RKE cluster with a `cluster.yml` that has a non-default `win_prefix_path`, you will need to update the `masquerade.as` field with your prefix path in place of  `c:\\`. 
+    > **Note for Non-Default Windows Prefix Path:** If you set up the RKE cluster with a `cluster.yml` that has a non-default `win_prefix_path`, you will need to update the `masquerade.as` field with your prefix path in place of  `c:\\`.
    >
    > For example, if you have `win_prefix_path: 'c:\host\opt\'`, then you will need to set `as: c:\host\opt\etc\wmi-exporter\wmi-exporter.exe`.
 2. Once all your hosts have been successfully upgraded, please ensure that you deploy the Helm chart once again with default values to avoid conflicts with the following settings:
@@ -1,13 +1,8 @@
 ---
 title: OPA Gatekeeper
-weight: 16
-aliases:
- - /rancher/v2.5/en/cluster-admin/tools/opa-gatekeeper
- - /rancher/v2.5/en/opa-gatekeeper/Open%20Policy%20Agent
-  - /rancher/v2.x/en/opa-gatekeper/
 ---

-To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates. 
+To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.

 OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.

@@ -61,7 +56,7 @@ When OPA Gatekeeper is enabled, Rancher installs some templates by default.
 To list the constraint templates installed in the cluster, go to the left side menu under OPA Gatekeeper and click on **Templates.**

 Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
-   
+
 ## Creating and Configuring Constraints

 [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
@@ -83,14 +78,14 @@ When a constraint is created, ensure that it does not apply to any Rancher or Ku
 To limit the scope of the constraint only to user namespaces, always specify these namespaces under the **Match** field of the constraint.

 Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
-   
+
 ## Enforcing Constraints in your Cluster

 When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny.**

 When the **Enforcement Action** is **Dryrun,** then any resources that violate the policy are only recorded under the constraint's status field.

-To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny.** 
+To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny.**

 ## Audit and Violations in your Cluster

@@ -1,9 +1,5 @@
 ---
 title: FAQ
-weight: 25
-aliases:
-  - /rancher/v2.5/en/about/
-  - /rancher/v2.x/en/faq/
 ---

 This FAQ is a work in progress designed to answer the questions our users most frequently ask about Rancher v2.x.
@@ -1,9 +1,6 @@
 ---
 title: Container Network Interface (CNI) Providers
 description: Learn about Container Network Interface (CNI), the CNI providers Rancher provides, the features they offer, and how to choose a provider for you
-weight: 2300
-aliases:
-  - /rancher/v2.x/en/faq/networking/cni-providers/
 ---

 ## What is CNI?
@@ -1,8 +1,5 @@
 ---
 title: Deprecated Features in Rancher v2.5
-weight: 100
-aliases:
-  - /rancher/v2.x/en/faq/deprecated-features-25x/
 ---

 ### What is Rancher's Deprecation policy?
@@ -1,8 +1,5 @@
 ---
 title: Installing and Configuring kubectl
-weight: 100
-aliases:
-  - /rancher/v2.x/en/faq/kubectl/
 ---

 `kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
@@ -1,8 +1,5 @@
 ---
 title: Networking
-weight: 8005
-aliases:
-  - /rancher/v2.x/en/faq/networking/
 ---

 Networking FAQ's
@@ -1,12 +1,5 @@
 ---
 title: Rancher is No Longer Needed
-weight: 8010
-aliases:
-  - /rancher/v2.5/en/installation/removing-rancher/cleaning-cluster-nodes/
-  - /rancher/v2.5/en/installation/removing-rancher/
-  - /rancher/v2.5/en/admin-settings/removing-rancher/
-  - /rancher/v2.5/en/admin-settings/removing-rancher/rancher-cluster-nodes/
-  - /rancher/v2.x/en/faq/removing-rancher/
 ---

 This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.
@@ -22,7 +15,7 @@ The capability to access a downstream cluster without Rancher depends on the typ

 - **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
 - **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
- **RKE clusters:** Please note that you will no longer be able to manage the individual Kubernetes components or perform any upgrades on them after the deletion of the Rancher server. However, you can still access the cluster to manage your workloads. To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed. 
+- **RKE clusters:** Please note that you will no longer be able to manage the individual Kubernetes components or perform any upgrades on them after the deletion of the Rancher server. However, you can still access the cluster to manage your workloads. To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.

 ### What if I don't want Rancher anymore?

@@ -1,8 +1,5 @@
 ---
 title: Security
-weight: 8007
-aliases:
-  - /rancher/v2.x/en/faq/security/
 ---

 **Is there a Hardening Guide?**
@@ -1,8 +1,5 @@
 ---
 title: Technical
-weight: 8006
-aliases:
-  - /rancher/v2.x/en/faq/technical/
 ---

 ### How can I reset the administrator password?
@@ -1,8 +1,5 @@
 ---
 title: Telemetry
-weight: 8008
-aliases:
-  - /rancher/v2.x/en/faq/telemetry/
 ---

 ### What is Telemetry?
@@ -1,12 +1,5 @@
 ---
 title: Docker Install with TLS Termination at Layer-7 NGINX Load Balancer
-weight: 252
-aliases:
-  - /rancher/v2.5/en/installation/single-node/single-node-install-external-lb/
-  - /rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-install-external-lb
-  - /rancher/v2.5/en/installation/options/single-node-install-external-lb
-  - /rancher/v2.5/en/installation/single-node-install-external-lb
-  - /rancher/v2.x/en/installation/resources/advanced/single-node-install-external-lb/
 ---

 For development and testing environments that have a special requirement to terminate TLS/SSL at a load balancer instead of your Rancher Server container, deploy Rancher and configure a load balancer to work with it conjunction.
@@ -1,10 +1,5 @@
 ---
 title: Enabling the API Audit Log to Record System Events
-weight: 4
-aliases:
-  - /rancher/v2.5/en/installation/options/api-audit-log/
-  - /rancher/v2.5/en/installation/api-auditing
-  - /rancher/v2.x/en/installation/resources/advanced/api-audit-log/
 ---

 You can enable the API audit log to record the sequence of system events initiated by individual users. You can know what happened, when it happened, who initiated it, and what cluster it affected. When you enable this feature, all requests to the Rancher API and all responses from it are written to a log.
@@ -1,8 +1,5 @@
 ---
 title: Opening Ports with firewalld
-weight: 1
-aliases:
-  - /rancher/v2.x/en/installation/resources/advanced/firewall/
 ---

 > We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
@@ -1,9 +1,5 @@
 ---
 title: Tuning etcd for Large Installations
-weight: 2
-aliases:
-  - /rancher/v2.5/en/installation/options/etcd
-  - /rancher/v2.x/en/installation/resources/advanced/etcd/
 ---

 When running larger Rancher installations with 15 or more clusters it is recommended to increase the default keyspace for etcd from the default 2GB. The maximum setting is 8GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
@@ -1,9 +1,5 @@
 ---
 title: UI for Istio Virtual Services and Destination Rules
-weight: 2
-aliases:
-  - /rancher/v2.5/en/installation/options/feature-flags/istio-virtual-service-ui
-  - /rancher/v2.x/en/installation/resources/feature-flags/istio-virtual-service-ui/
 ---

 This feature enables a UI that lets you create, read, update and delete virtual services and destination rules, which are traffic management features of Istio.
@@ -1,9 +1,5 @@
 ---
 title: "Running on ARM64 (Experimental)"
-weight: 3
-aliases:
-  - /rancher/v2.5/en/installation/options/arm64-platform
-  - /rancher/v2.x/en/installation/resources/advanced/arm64-platform/
 ---

 > **Important:**
@@ -1,9 +1,5 @@
 ---
 title: Allow Unsupported Storage Drivers
-weight: 1
-aliases:
-  - /rancher/v2.5/en/installation/options/feature-flags/enable-not-default-storage-drivers/
-  - /rancher/v2.x/en/installation/resources/feature-flags/enable-not-default-storage-drivers/
 ---

 This feature allows you to use types for storage providers and provisioners that are not enabled by default.
@@ -1,7 +1,5 @@
 ---
 title: Rendering the Helm Template in an Air Gapped Environment
-shortTitle: Air Gap Upgrade
-weight: 1
 ---

 import Tabs from '@theme/Tabs';
@@ -1,7 +1,5 @@
 ---
 title: Installing Rancher on Azure Kubernetes Service
-shortTitle: AKS
-weight: 4
 ---

 This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
@@ -96,9 +94,9 @@ kubectl get service ingress-nginx-controller --namespace=ingress-nginx
 The result should look similar to the following:

 ```
-NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                     
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
 AGE
-ingress-nginx-controller   LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP  
+ingress-nginx-controller   LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP
 67s
 ```

@@ -1,9 +1,5 @@
 ---
 title: Installing Rancher on Amazon EKS
-shortTitle: Amazon EKS
-weight: 4
-aliases:
-  - /rancher/v2.x/en/installation/install-rancher-on-k8s/amazon-eks/
 ---

 This page covers two ways to install Rancher on EKS.
@@ -143,9 +139,9 @@ kubectl get service ingress-nginx-controller --namespace=ingress-nginx
 The result should look similar to the following:

 ```
-NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP                                                              PORT(S)                     
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP                                                              PORT(S)
 AGE
-ingress-nginx-controller   LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP  
+ingress-nginx-controller   LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP
 27m
 ```

@@ -1,7 +1,5 @@
 ---
 title: Installing Rancher on a Google Kubernetes Engine Cluster
-shortTitle: GKE
-weight: 5
 ---

 import Tabs from '@theme/Tabs';
@@ -1,14 +1,5 @@
 ---
 title: Rollbacks
-weight: 3
-aliases:
-  - /rancher/v2.x/en/upgrades/rollbacks
-  - /rancher/v2.x/en/installation/upgrades-rollbacks/rollbacks
-  - /rancher/v2.x/en/upgrades/ha-server-rollbacks
-  - /rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks
-  - /rancher/v2.x/en/installation/upgrades-rollbacks/rollbacks/ha-server-rollbacks
-  - /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades-rollbacks/rollbacks
-  - /rancher/v2.x/en/installation/install-rancher-on-k8s/rollbacks/
 ---

 - [Rolling Back to Rancher v2.5.0+](#rolling-back-to-rancher-v2-5-0)
@@ -1,12 +1,5 @@
 ---
 title: Troubleshooting the Rancher Server Kubernetes Cluster
-weight: 276
-aliases:
-  - /rancher/v2.5/en/installation/k8s-install/helm-rancher/troubleshooting
-  - /rancher/v2.5/en/installation/ha/kubernetes-rke/troubleshooting
-  - /rancher/v2.5/en/installation/k8s-install/kubernetes-rke/troubleshooting
-  - /rancher/v2.5/en/installation/options/troubleshooting
-  - /rancher/v2.x/en/installation/resources/troubleshooting/
 ---

 This section describes how to troubleshoot an installation of Rancher on a Kubernetes cluster.
@@ -1,22 +1,7 @@
 ---
 title: Upgrades
-weight: 2
-aliases:
-  - /rancher/v2.5/en/upgrades/upgrades
-  - /rancher/v2.5/en/installation/upgrades-rollbacks/upgrades
-  - /rancher/v2.5/en/upgrades/upgrades/ha-server-upgrade-helm-airgap
-  - /rancher/v2.5/en/upgradeinstallation/install-rancher-on-k8s/upgrades/air-gap-upgrade/
-  - /rancher/v2.5/en/upgrades/upgrades/ha
-  - /rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/upgrades/ha
-  - /rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/
-  - /rancher/v2.5/en/upgrades/upgrades/ha-server-upgrade-helm/
-  - /rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha
-  - /rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades
-  - /rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/ha
-  - /rancher/v2.5/en/installation/upgrades-rollbacks/
-  - /rancher/v2.5/en/upgrades/
-  - /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/
 ---
+
 The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air gap installs with Helm.

 For the instructions to upgrade Rancher installed on Kubernetes with RancherD, refer to [this page.](../other-installation-methods/install-rancher-on-linux/upgrade-rancherd.md)
@@ -1,6 +1,5 @@
 ---
 title: Installing Docker
-weight: 1
 ---

 Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
@@ -1,9 +1,6 @@
 ---
 title: Port Requirements
 description: Read about port requirements needed in order for Rancher to operate properly, both for Rancher nodes and downstream Kubernetes cluster nodes
-weight: 300
-aliases:
-  - /rancher/v2.x/en/installation/requirements/ports/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: Docker Install Commands
-weight: 1
 ---

 The Docker installation is for Rancher users who want to test out Rancher.
@@ -1,9 +1,5 @@
 ---
 title: '1. Set up Infrastructure and Private Registry'
-weight: 100
-aliases:
-  - /rancher/v2.5/en/installation/air-gap-single-node/provision-host
-  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: '3. Install Kubernetes (Skip for Docker Installs)'
-weight: 300
-aliases:
-  - /rancher/v2.5/en/installation/air-gap-high-availability/install-kube
-  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,14 +1,5 @@
 ---
 title: 4. Install Rancher
-weight: 400
-aliases:
-  - /rancher/v2.5/en/installation/air-gap-high-availability/config-rancher-system-charts/
-  - /rancher/v2.5/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
-  - /rancher/v2.5/en/installation/air-gap-single-node/install-rancher
-  - /rancher/v2.5/en/installation/air-gap/install-rancher
-  - /rancher/v2.5/en/installation/air-gap-installation/install-rancher/
-  - /rancher/v2.5/en/installation/air-gap-high-availability/install-rancher/
-  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,13 +1,5 @@
 ---
 title: '2. Collect and Publish Images to your Private Registry'
-weight: 200
-aliases:
-  - /rancher/v2.5/en/installation/air-gap-high-availability/prepare-private-registry/
-  - /rancher/v2.5/en/installation/air-gap-single-node/prepare-private-registry/
-  - /rancher/v2.5/en/installation/air-gap-single-node/config-rancher-for-private-reg/
-  - /rancher/v2.5/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
-  - /rancher/v2.5/en/installation/air-gap-installation/prepare-private-reg/
-  - /rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: Rollbacks
-weight: 3
-aliases:
-  - /rancher/v2.5/en/installation/install-rancher-on-linux/rollbacks
-  - /rancher/v2.x/en/installation/install-rancher-on-linux/rollbacks/
 ---

 > **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
@@ -1,9 +1,5 @@
 ---
 title: Upgrades
-weight: 2
-aliases:
-  - /rancher/v2.5/en/installation/install-rancher-on-linux/upgrades
-  - /rancher/v2.x/en/installation/install-rancher-on-linux/upgrades/
 ---

 > **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
@@ -1,8 +1,5 @@
 ---
 title: '2. Install Kubernetes'
-weight: 200
-aliases:
-  - /rancher/v2.x/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/
 ---

 Once the infrastructure is ready, you can continue with setting up an RKE cluster to install Rancher in.
@@ -1,8 +1,5 @@
 ---
 title: 3. Install Rancher
-weight: 300
-aliases:
-  - /rancher/v2.x/en/installation/other-installation-methods/behind-proxy/install-rancher/
 ---

 Now that you have a running RKE cluster, you can install Rancher in it. For security reasons all traffic to Rancher must be encrypted with TLS. For this tutorial you are going to automatically issue a self-signed certificate through [cert-manager](https://cert-manager.io/). In a real-world use-case you will likely use Let's Encrypt or provide your own certificate.
@@ -1,8 +1,5 @@
 ---
 title: '1. Set up Infrastructure'
-weight: 100
-aliases:
-  - /rancher/v2.x/en/installation/other-installation-methods/behind-proxy/prepare-nodes/
 ---

 In this section, you will provision the underlying infrastructure for your Rancher management server with internete access through a HTTP proxy.
@@ -1,9 +1,7 @@
 ---
 title: Certificate Troubleshooting
-weight: 4
-aliases:
-  - /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/troubleshooting/
 ---
+
 ### How Do I Know if My Certificates are in PEM Format?

 You can recognize the PEM format by the following traits:
@@ -1,10 +1,5 @@
 ---
 title: Rolling Back Rancher Installed with Docker
-weight: 1015
-aliases:
-  - /rancher/v2.5/en/upgrades/single-node-rollbacks
-  - /rancher/v2.5/en/upgrades/rollbacks/single-node-rollbacks
-  - /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/
 ---

 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:
@@ -1,13 +1,5 @@
 ---
 title: Upgrading Rancher Installed with Docker
-weight: 1010
-aliases:
-  - /rancher/v2.5/en/upgrades/single-node-upgrade/
-  - /rancher/v2.5/en/upgrades/upgrades/single-node-air-gap-upgrade
-  - /rancher/v2.5/en/upgrades/upgrades/single-node
-  - /rancher/v2.5/en/upgrades/upgrades/single-node-upgrade/
-  - /rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/upgrades/single-node/
-  - /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,16 +1,12 @@
 ---
 title: Adding TLS Secrets
-weight: 2
-aliases:
-  - /rancher/v2.5/en/installation/resources/encryption/tls-secrets/
-  - /rancher/v2.x/en/installation/resources/tls-secrets/
 ---

 Kubernetes will create all the objects and services for Rancher, but it will not become available until we populate the `tls-rancher-ingress` secret in the `cattle-system` namespace with the certificate and key.

 Combine the server certificate followed by any intermediate certificate(s) needed into a file named `tls.crt`. Copy your certificate key into a file named `tls.key`.

-For example, [acme.sh](https://acme.sh) provides server certificate and CA chains in `fullchain.cer` file. 
+For example, [acme.sh](https://acme.sh) provides server certificate and CA chains in `fullchain.cer` file.
 This `fullchain.cer` should be renamed to `tls.crt` & certificate key file as `tls.key`.

 Use `kubectl` with the `tls` secret type to create the secrets.
@@ -1,9 +1,5 @@
 ---
 title: Choosing a Rancher Version
-weight: 1
-aliases:
-  - /rancher/v2.5/en/installation/options/server-tags
-  - /rancher/v2.x/en/installation/resources/choosing-version/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,10 +1,5 @@
 ---
 title: About Custom CA Root Certificates
-weight: 1
-aliases:
-  - /rancher/v2.5/en/installation/options/custom-ca-root-certificate/
-  - /rancher/v2.5/en/installation/resources/choosing-version/encryption/custom-ca-root-certificate
-  - /rancher/v2.x/en/installation/resources/custom-ca-root-certificate/
 ---

 If you're using Rancher in an internal production environment where you aren't exposing apps publicly, use a certificate from a private certificate authority (CA).
@@ -1,12 +1,5 @@
 ---
 title: Helm Version Requirements
-weight: 3
-aliases:
-  - /rancher/v2.5/en/installation/options/helm-version
-  - /rancher/v2.5/en/installation/options/helm2
-  - /rancher/v2.5/en/installation/options/helm2/helm-init
-  - /rancher/v2.5/en/installation/options/helm2/helm-rancher
-  - /rancher/v2.x/en/installation/resources/helm-version/
 ---

 This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
@@ -1,12 +1,5 @@
 ---
 title: Setting up Local System Charts for Air Gapped Installations
-weight: 120
-aliases:
-  - /rancher/v2.5/en/installation/air-gap-single-node/config-rancher-system-charts/_index.md
-  - /rancher/v2.5/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md
-  - /rancher/v2.5/en/installation/options/local-system-charts
-  - /rancher/v2.x/en/installation/resources/local-system-charts/
-  - /rancher/v2.x/en/installation/options/local-system-charts/
 ---

 The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS.
@@ -1,8 +1,5 @@
 ---
 title: Updating the Rancher Certificate
-weight: 10
-aliases:
-  - /rancher/v2.x/en/installation/resources/update-ca-cert/
 ---

 # Updating a Private CA Certificate
@@ -79,7 +76,7 @@ Also get the version string of the currently deployed Rancher chart:
 $ helm ls -A
 ```

-Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade.    
+Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade.

 If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates.

@@ -219,7 +216,7 @@ Also get the version string of the currently deployed Rancher chart:
 $ helm ls -A
 ```

-Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade.    
+Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade.

 Also make sure to read the documentation describing the initial installation using custom certificates.

@@ -231,9 +228,9 @@ helm upgrade rancher rancher-stable/rancher \
  --set ...
 ```

-On upgrade, you can either 
+On upgrade, you can either

- remove `--set ingress.tls.source=secret \` from the Helm upgrade command, as shown above, or 
+- remove `--set ingress.tls.source=secret \` from the Helm upgrade command, as shown above, or

 - remove the `privateCA` parameter or set it to `false` because the CA is valid:

@@ -1,9 +1,5 @@
 ---
 title: Upgrading Cert-Manager with Helm 2
-weight: 2040
-aliases:
-  - /rancher/v2.5/en/installation/options/upgrading-cert-manager/helm-2-instructions
-  - /rancher/v2.5/en/installation/resources/choosing-version/encryption/upgrading-cert-manager/helm-2-instructions
 ---

 Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
@@ -1,11 +1,5 @@
 ---
 title: Upgrading Cert-Manager
-weight: 4
-aliases:
-  - /rancher/v2.5/en/installation/options/upgrading-cert-manager
-  - /rancher/v2.5/en/installation/options/upgrading-cert-manager/helm-2-instructions
-  - /rancher/v2.5/en/installation/resources/encryption/upgrading-cert-manager
-  - /rancher/v2.x/en/installation/resources/upgrading-cert-manager/
 ---

 Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
@@ -1,8 +1,5 @@
 ---
 title: Upgrading and Rolling Back Kubernetes
-weight: 70
-aliases:
-  - /rancher/v2.x/en/cluster-admin/upgrading-kubernetes/
 ---

 Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.
@@ -1,8 +1,5 @@
 ---
 title: Upgrading Kubernetes without Upgrading Rancher
-weight: 1120
-aliases:
-  - /rancher/v2.x/en/admin-settings/k8s-metadata/
 ---

 The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
@@ -11,7 +8,7 @@ The RKE metadata feature allows you to provision clusters with new versions of K

 Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates.** Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.

-This table below describes the CRDs that are affected by the periodic data sync. 
+This table below describes the CRDs that are affected by the periodic data sync.

 > **Note:** Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.

@@ -31,7 +28,7 @@ Administrators might configure the RKE metadata settings to do the following:

 The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)

-To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner. 
+To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner.

 You can configure Rancher to only refresh metadata when desired by setting `refresh-interval-minutes` to `0` (see below) and using this button to perform the metadata refresh manually when desired.

@@ -1,9 +1,7 @@
 ---
 title: Overview
-weight: 1
-aliases:
-  - /rancher/v2.x/en/overview/
 ---
+
 Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.

 # Run Kubernetes Everywhere
@@ -1,7 +1,6 @@
 ---
 title: Rancher AWS Quick Start Guide
 description: Read this step by step Rancher AWS guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
 ---
 The following steps will quickly deploy a Rancher server on AWS in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,7 +1,6 @@
 ---
 title: Rancher Azure Quick Start Guide
 description: Read this step by step Rancher Azure guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
 ---

 The following steps will quickly deploy a Rancher server on Azure in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
@@ -1,7 +1,6 @@
 ---
 title: Rancher DigitalOcean Quick Start Guide
 description: Read this step by step Rancher DigitalOcean guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
 ---
 The following steps will quickly deploy a Rancher server on DigitalOcean in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,7 +1,6 @@
 ---
 title: Rancher GCP Quick Start Guide
 description: Read this step by step Rancher GCP guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
 ---
 The following steps will quickly deploy a Rancher server on GCP in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,9 +1,7 @@
 ---
 title: Manual Quick Start
-weight: 300
-aliases:
-  - /rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/
 ---
+
 Howdy Partner! This tutorial walks you through:

 - Installation of Rancher 2.x
@@ -1,9 +1,7 @@
 ---
 title: Vagrant Quick Start
-weight: 200
-aliases:
-  - /rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/
 ---
+
 The following steps quickly deploy a Rancher Server with a single node cluster attached.

 >**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../../pages-for-subheaders/installation-and-upgrade.md).
@@ -1,8 +1,5 @@
 ---
 title: Workload with NodePort Quick Start
-weight: 200
-aliases:
-  - /rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/
 ---

 ### Prerequisite
@@ -1,8 +1,5 @@
 ---
 title: Workload with Ingress Quick Start
-weight: 100
-aliases:
-  - /rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/
 ---

 ### Prerequisite
@@ -1,9 +1,5 @@
 ---
 title: Configuring Active Directory (AD)
-weight: 1112
-aliases:
-  - /rancher/v2.5/en/tasks/global-configuration/authentication/active-directory/
-  - /rancher/v2.x/en/admin-settings/authentication/ad/
 ---

 If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI.
@@ -1,6 +1,5 @@
 ---
 title: Configuring Azure AD
-weight: 1115
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,5 @@
 ---
 title: Configuring FreeIPA
-weight: 1114
-aliases:
-  - /rancher/v2.5/en/tasks/global-configuration/authentication/freeipa/
-  - /rancher/v2.x/en/admin-settings/authentication/freeipa/
 ---

 If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials.
@@ -1,9 +1,5 @@
 ---
 title: Configuring GitHub
-weight: 1116
-aliases:
-  - /rancher/v2.5/en/tasks/global-configuration/authentication/github/
-  - /rancher/v2.x/en/admin-settings/authentication/github/
 ---

 In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials.
@@ -1,8 +1,5 @@
 ---
 title: Configuring Google OAuth
-weight: 15
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/google/
 ---

 If your organization uses G Suite for user authentication, you can configure Rancher to allow your users to log in using their G Suite credentials.
@@ -1,9 +1,6 @@
 ---
 title: Configuring Keycloak (SAML)
 description: Create a Keycloak SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
-weight: 1200
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/keycloak/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,8 +1,5 @@
 ---
 title: Configuring Okta (SAML)
-weight: 1210
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/okta/
 ---

 If your organization uses Okta Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
@@ -13,7 +10,7 @@ If your organization uses Okta Identity Provider (IdP) for user authentication,

 In Okta, create a SAML Application with the settings below. See the [Okta documentation](https://developer.okta.com/standards/SAML/setting_up_a_saml_application_in_okta) for help.

-Setting | Value    
+Setting | Value
 ------------|------------
 `Single Sign on URL` | `https://yourRancherHostURL/v1-saml/okta/saml/acs`
 `Audience URI (SP Entity ID)` | `https://yourRancherHostURL/v1-saml/okta/saml/metadata`
@@ -37,7 +34,7 @@ Setting | Value
    | Metadata XML              | The `Identity Provider metadata` file that you find in the application `Sign On` section.  |

    >**Tip:** You can generate a key/certificate pair using an openssl command. For example:
-    >    
+    >
    >        openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.crt


@@ -1,8 +1,5 @@
 ---
 title: Configuring PingIdentity (SAML)
-weight: 1200
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/ping-federate/
 ---

 If your organization uses Ping Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
@@ -1,9 +1,5 @@
 ---
 title: Local Authentication
-weight: 1111
-aliases:
-  - /rancher/v2.5/en/tasks/global-configuration/authentication/local-authentication/
-  - /rancher/v2.x/en/admin-settings/authentication/local/
 ---

 Local authentication is the default until you configure an external authentication provider. Local authentication is where Rancher stores the user information, i.e. names and passwords, of who can log in to Rancher. By default, the `admin` user that logs in to Rancher for the first time is a local user.
@@ -1,8 +1,5 @@
 ---
 title: Users and Groups
-weight: 1
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/user-groups/
 ---

 Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When you configure an external authentication provider, users from that provider will be able to log in to your Rancher server. When a user logs in, the authentication provider will supply your Rancher server with a list of groups to which the user belongs.
@@ -1,68 +1,65 @@
 ---
 title: 1. Configuring Microsoft AD FS for Rancher
-weight: 1205
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/
 ---

-Before configuring Rancher to support AD FS users, you must add Rancher as a [relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) in AD FS. 
+Before configuring Rancher to support AD FS users, you must add Rancher as a [relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) in AD FS.

 1. Log into your AD server as an administrative user.

 1. Open the **AD FS Management** console. Select **Add Relying Party Trust...** from the **Actions** menu and click **Start**.
-  
+
    ![](/img/adfs/adfs-overview.png)

 1. Select **Enter data about the relying party manually** as the option for obtaining data about the relying party.

    ![](/img/adfs/adfs-add-rpt-2.png)
-    
+
 1. Enter your desired **Display name** for your Relying Party Trust. For example, `Rancher`.

    ![](/img/adfs/adfs-add-rpt-3.png)
-  
+
 1. Select **AD FS profile** as the configuration profile for your relying party trust.
-  
+
    ![](/img/adfs/adfs-add-rpt-4.png)
-  
+
 1. Leave the **optional token encryption certificate** empty, as Rancher AD FS will not be using one.
-  
+
    ![](/img/adfs/adfs-add-rpt-5.png)
-  
+
 1. Select **Enable support for the SAML 2.0 WebSSO protocol**
  and enter `https://<rancher-server>/v1-saml/adfs/saml/acs` for the service URL.
-  
+
    ![](/img/adfs/adfs-add-rpt-6.png)
-  
+
 1. Add `https://<rancher-server>/v1-saml/adfs/saml/metadata` as the **Relying party trust identifier**.
-  
+
    ![](/img/adfs/adfs-add-rpt-7.png)
-  
+
 1. This tutorial will not cover multi-factor authentication; please refer to the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs) if you would like to configure multi-factor authentication.
-  
+
    ![](/img/adfs/adfs-add-rpt-8.png)
-  
+
 1. From **Choose Issuance Authorization RUles**, you may select either of the options available according to use case. However, for the purposes of this guide, select **Permit all users to access this relying party**.
-  
+
    ![](/img/adfs/adfs-add-rpt-9.png)

 1. After reviewing your settings, select **Next** to add the relying party trust.
-  
+
    ![](/img/adfs/adfs-add-rpt-10.png)

-  
+
 1. Select **Open the Edit Claim Rules...** and click **Close**.
-  
+
    ![](/img/adfs/adfs-add-rpt-11.png)
-  
+
 1. On the **Issuance Transform Rules** tab, click **Add Rule...**.
-  
+
    ![](/img/adfs/adfs-edit-cr.png)
-  
+
 1. Select **Send LDAP Attributes as Claims** as the **Claim rule template**.

    ![](/img/adfs/adfs-add-tcr-1.png)
-  
+
 1. Set the **Claim rule name** to your desired name (for example, `Rancher Attributes`) and select **Active Directory** as the **Attribute store**. Create the following mapping to reflect the table below:

    | LDAP Attribute                               | Outgoing Claim Type |
@@ -74,7 +71,7 @@ Before configuring Rancher to support AD FS users, you must add Rancher as a [re
    <br/>
    ![](/img/adfs/adfs-add-tcr-2.png)

-1. Download the `federationmetadata.xml` from your AD server at: 
+1. Download the `federationmetadata.xml` from your AD server at:
 ```
 https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml
 ```
@@ -1,14 +1,11 @@
 ---
 title: 2. Configuring Rancher for Microsoft AD FS
-weight: 1205
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup/
 ---

 After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-for-rancher.md), enter your AD FS information into Rancher to allow AD FS users to authenticate with Rancher.

 >**Important Notes For Configuring Your AD FS Server:**
-> 
+>
 >- The SAML 2.0 WebSSO Protocol Service URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/acs`
 >- The Relying Party Trust identifier URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
 >- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`
@@ -20,13 +17,13 @@ After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-f

 1.	Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The [configuration section below](#configuration) describe how you can map AD attributes to fields within Rancher.

-    
-    
-
-    


- 
+
+
+
+
+
 1. After you complete the **Configure AD FS Account** form, click **Authenticate with AD FS**, which is at the bottom of the page.

    Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.
@@ -48,7 +45,7 @@ After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-f
 | Metadata XML              | The `federationmetadata.xml` file exported from your AD FS server. <br/><br/>You can find this file at `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`.                                |


-<a id="cert-command"></a> 
+<a id="cert-command"></a>

 **Tip:** You can generate a certificate using an openssl command. For example:

--- a/Show More
+++ b/Show More