diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 0cfab9191f7..30edb92b920 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -57,4 +57,4 @@ For more information on how metadata works and how to configure metadata config, _Available as of v2.3.0_ -Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{}}/rancher/v2.x/en/admin-settings/feature-flags/) +Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{}}/rancher/v2.x/en/installation/options/feature-flags/) diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index 70e9c6d8a63..be06b250b9a 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -184,7 +184,7 @@ For existing users, the new permissions will take effect when the users log out For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions) -If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default.** Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,]((#refreshing-group-memberships)) whichever comes first. +If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default.** Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first. > **Prerequisites:** You can only assign a global role to a group if: > diff --git a/content/rancher/v2.x/en/backups/_index.md b/content/rancher/v2.x/en/backups/_index.md index 3d90e203bcf..9179179bdfc 100644 --- a/content/rancher/v2.x/en/backups/_index.md +++ b/content/rancher/v2.x/en/backups/_index.md @@ -30,7 +30,7 @@ The new `rancher-backup` operator allows Rancher to be backed up and restored on Previously, the way that cluster data was backed up depended on the type of Kubernetes cluster that was used. -In Rancher v2.4, it was only supported to install Rancher on two types of Kubernetes clusters: an RKE cluster, or a K3s cluster with an external database. If Rancher was installed on an RKE cluster, [RKE would be used]({{}}/rancher/v2.x/en/backups/legacy/backup/k8s-backups/ha-backups/) to take a snapshot of the etcd database and restore the cluster. If Rancher was installed on a K3s cluster with an external database, the database would need to be backed up and restored using the upstream documentation for the database. +In Rancher v2.4, it was only supported to install Rancher on two types of Kubernetes clusters: an RKE cluster, or a K3s cluster with an external database. If Rancher was installed on an RKE cluster, RKE would be used to take a snapshot of the etcd database and restore the cluster. If Rancher was installed on a K3s cluster with an external database, the database would need to be backed up and restored using the upstream documentation for the database. In Rancher v2.5, it is now supported to install Rancher hosted Kubernetes clusters, such as Amazon EKS clusters, which do not expose etcd to a degree that would allow snapshots to be created by an external tool. etcd doesn't need to be exposed for `rancher-backup` to work, because the operator gathers resources by making calls to `kube-apiserver`. @@ -42,8 +42,8 @@ For Rancher installed with Docker, refer to the same steps used up till 2.5 for For Rancher prior to v2.5, the way that Rancher is backed up and restored differs based on the way that Rancher was installed. Our legacy backup and restore documentation is here: -- For Rancher installed on an RKE Kubernetes cluster, refer to the legacy [backup]({{}}/rancher/v2.x/en/backups/legacy/backup/k8s-backups/ha-backups/) and [restore]({{}}/rancher/v2.x/en/backups/legacy/restore/k8s-restore/rke-restore/) documentation. -- For Rancher installed on a K3s Kubernetes cluster, refer to the legacy [backup]({{}}/rancher/v2.x/en/backups/legacy/backup/k8s-backups/k3s-backups/) and [restore]({{}}/rancher/v2.x/en/backups/legacy/restore/k8s-restore/k3s-restore/) documentation. +- For Rancher installed on an RKE Kubernetes cluster, refer to the legacy [backup]({{}}/rancher/v2.x/en/backups/legacy/backup/ha-backups) and [restore]({{}}/rancher/v2.x/en/backups/legacy/restore/rke-restore) documentation. +- For Rancher installed on a K3s Kubernetes cluster, refer to the legacy [backup]({{}}/rancher/v2.x/en/backups/legacy/backup/k3s-backups) and [restore]({{}}/rancher/v2.x/en/backups/legacy/restore/k3s-restore) documentation. # How Backups and Restores Work diff --git a/content/rancher/v2.x/en/backups/docker-installs/docker-backups/_index.md b/content/rancher/v2.x/en/backups/docker-installs/docker-backups/_index.md index d06c933dda6..f3707b64917 100644 --- a/content/rancher/v2.x/en/backups/docker-installs/docker-backups/_index.md +++ b/content/rancher/v2.x/en/backups/docker-installs/docker-backups/_index.md @@ -5,6 +5,8 @@ weight: 3 aliases: - /rancher/v2.x/en/installation/after-installation/single-node-backup-and-restoration/ - /rancher/v2.x/en/installation/after-installation/single-node-backup-and-restoration/ + - /rancher/v2.x/en/backups/backups/single-node-backups/ + - /rancher/v2.x/en/backups/legacy/backup/single-node-backups/ --- diff --git a/content/rancher/v2.x/en/backups/legacy/backup/ha-backups/_index.md b/content/rancher/v2.x/en/backups/legacy/backup/ha-backups/_index.md index b659ba7a1e9..7b3fd1da2da 100644 --- a/content/rancher/v2.x/en/backups/legacy/backup/ha-backups/_index.md +++ b/content/rancher/v2.x/en/backups/legacy/backup/ha-backups/_index.md @@ -7,6 +7,8 @@ aliases: - /rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration/ - /rancher/v2.x/en/backups/backups/ha-backups - /rancher/v2.x/en/backups/backups/k8s-backups/ha-backups + - /rancher/v2.x/en/backups/legacy/backup/k8s-backups/ha-backups/ + - /rancher/v2.x/en/backups/legacy/backups/ha-backups --- This section describes how to create backups of your high-availability Rancher install. diff --git a/content/rancher/v2.x/en/backups/legacy/backup/k3s-backups/_index.md b/content/rancher/v2.x/en/backups/legacy/backup/k3s-backups/_index.md index f2aea16e349..45f946fec3a 100644 --- a/content/rancher/v2.x/en/backups/legacy/backup/k3s-backups/_index.md +++ b/content/rancher/v2.x/en/backups/legacy/backup/k3s-backups/_index.md @@ -5,6 +5,8 @@ weight: 1 aliases: - /rancher/v2.x/en/backups/backups/k3s-backups - /rancher/v2.x/en/backups/backups/k8s-backups/k3s-backups + - /rancher/v2.x/en/backups/legacy/backup/k8s-backups/k3s-backups/ + - /rancher/v2.x/en/backups/legacy/backups/k3s-backups --- When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data. diff --git a/content/rancher/v2.x/en/backups/legacy/restore/k3s-restore/_index.md b/content/rancher/v2.x/en/backups/legacy/restore/k3s-restore/_index.md index 472c8a30239..34c4e54a1c3 100644 --- a/content/rancher/v2.x/en/backups/legacy/restore/k3s-restore/_index.md +++ b/content/rancher/v2.x/en/backups/legacy/restore/k3s-restore/_index.md @@ -5,6 +5,7 @@ weight: 1 aliases: - /rancher/v2.x/en/backups/restorations/k3s-restoration - /rancher/v2.x/en/backups/restorations/k8s-restore/k3s-restore + - /rancher/v2.x/en/backups/legacy/restore/k8s-restore/k3s-restore/ --- When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data. diff --git a/content/rancher/v2.x/en/backups/legacy/restore/rke-restore/_index.md b/content/rancher/v2.x/en/backups/legacy/restore/rke-restore/_index.md index 44b03b5cd4a..4b15565cf35 100644 --- a/content/rancher/v2.x/en/backups/legacy/restore/rke-restore/_index.md +++ b/content/rancher/v2.x/en/backups/legacy/restore/rke-restore/_index.md @@ -6,6 +6,7 @@ aliases: - /rancher/v2.x/en/installation/after-installation/ha-backup-and-restoration/ - /rancher/v2.x/en/backups/restorations/ha-restoration - /rancher/v2.x/en/backups/restorations/k8s-restore/rke-restore + - /rancher/v2.x/en/backups/legacy/restore/k8s-restore/rke-restore/ --- This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster. diff --git a/content/rancher/v2.x/en/installation/options/feature-flags/_index.md b/content/rancher/v2.x/en/installation/options/feature-flags/_index.md index 250a7d460bd..f3c18ce2bf8 100644 --- a/content/rancher/v2.x/en/installation/options/feature-flags/_index.md +++ b/content/rancher/v2.x/en/installation/options/feature-flags/_index.md @@ -3,6 +3,7 @@ title: Enabling Experimental Features weight: 17 aliases: - /rancher/v2.x/en/installation/options/feature-flags/ + - /rancher/v2.x/en/admin-settings/feature-flags/ --- Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{}}/rancher/v2.x/en/installation/options/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default. diff --git a/content/rancher/v2.x/en/installation/resources/encryption/tls-settings/_index.md b/content/rancher/v2.x/en/installation/resources/encryption/tls-settings/_index.md index 1aed01dcc58..340f5da17d2 100644 --- a/content/rancher/v2.x/en/installation/resources/encryption/tls-settings/_index.md +++ b/content/rancher/v2.x/en/installation/resources/encryption/tls-settings/_index.md @@ -3,6 +3,7 @@ title: TLS Settings weight: 3 aliases: - /rancher/v2.x/en/installation/options/tls-settings/ + - /rancher/v2.x/en/admin-settings/tls-settings --- In Rancher v2.1.7, the default TLS configuration changed to only accept TLS 1.2 and secure TLS cipher suites. TLS 1.3 and TLS 1.3 exclusive cipher suites are not supported.