From 0627a888875072b840080b02150c022b53ba1fe3 Mon Sep 17 00:00:00 2001 From: Ron Stone Date: Thu, 15 Dec 2022 15:07:56 -0500 Subject: [PATCH] Generic CentOS > Debian updates Generic changes related to distribution switch-over Additional updates Signed-off-by: Ron Stone Change-Id: I35509d61e01c1f18437435ae16fdaad1dbd58dbb --- .../kubernetes/snmp-event-table.rst | 2 +- .../fault-mgmt/kubernetes/snmp-overview.rst | 2 +- doc/source/fault-mgmt/kubernetes/traps.rst | 2 +- .../local-and-ldap-linux-user-accounts.rst | 5 ++- .../kubernetes/configure-local-cli-access.rst | 12 ----- ...remote-helm-client-for-non-admin-users.rst | 10 ++--- .../local-ldap-linux-user-accounts.rst | 44 +++++++------------ ...tl-and-helm-clients-directly-on-a-host.rst | 10 ++--- .../kubernetes/the-sysadmin-account.rst | 35 +++++---------- 9 files changed, 43 insertions(+), 79 deletions(-) diff --git a/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst b/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst index 60851efe7..2c76f921a 100644 --- a/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst +++ b/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst @@ -39,7 +39,7 @@ Each entry in the table includes the following variables: - wrsEventSuppressionAllowed -See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/centos/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt +See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt for alarm details. An external |SNMP| manager can examine the Event table contents by doing an |SNMP| diff --git a/doc/source/fault-mgmt/kubernetes/snmp-overview.rst b/doc/source/fault-mgmt/kubernetes/snmp-overview.rst index f9e2b5292..57c0ce996 100644 --- a/doc/source/fault-mgmt/kubernetes/snmp-overview.rst +++ b/doc/source/fault-mgmt/kubernetes/snmp-overview.rst @@ -71,7 +71,7 @@ and SNMP groups, as follows: - coldStart and warmStart Traps - support for Enterprise Registration and Alarm MIBs, see - `https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/centos/docker/stx-snmp/mibs `__ + https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/docker/stx-snmp/mibs .. _snmp-overview-section-N100C9-N1001F-N10001: diff --git a/doc/source/fault-mgmt/kubernetes/traps.rst b/doc/source/fault-mgmt/kubernetes/traps.rst index e6c2753f8..3ac7a9494 100644 --- a/doc/source/fault-mgmt/kubernetes/traps.rst +++ b/doc/source/fault-mgmt/kubernetes/traps.rst @@ -68,5 +68,5 @@ alarm. This is done to facilitate the interaction with most SNMP trap viewers which use the Notification Type to drive the coloring of traps, that is, red for critical, yellow for minor, and so on. -See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/centos/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt +See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt for alarm details. diff --git a/doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst b/doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst index 6fc2c3ef7..0ff0825e4 100644 --- a/doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst +++ b/doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst @@ -19,7 +19,8 @@ cluster using standard Linux commands. - Password changes are not enforced automatically on the first login, and they are not propagated by the system \(only for 'sysadmin'\). -- **If the administrator wants to provision additional access to the system, it is better to configure local LDAP Linux accounts.** +- **If the administrator wants to provision additional access to the system, + it is better to configure local |LDAP| Linux accounts.** - |LDAP| accounts are centrally managed; changes made on any host are propagated automatically to all hosts on the cluster. @@ -35,7 +36,7 @@ cluster using standard Linux commands. - The accounts block following five consecutive unsuccessful login attempts. They unblock automatically after a period of about five minutes. -- All authentication attempts are recorded on the file /var/log/auth.log +- All authentication attempts are recorded on the file ``/var/log/auth.log`` of the target host. diff --git a/doc/source/security/kubernetes/configure-local-cli-access.rst b/doc/source/security/kubernetes/configure-local-cli-access.rst index dffeaf6b6..9ec809523 100644 --- a/doc/source/security/kubernetes/configure-local-cli-access.rst +++ b/doc/source/security/kubernetes/configure-local-cli-access.rst @@ -55,18 +55,6 @@ required system maintenance, administration and troubleshooting tasks. % echo "export KUBECONFIG=~/.kube/config" >> ~/.profile % exit - .. note:: - The command - - .. code-block:: none - - echo "export KUBECONFIG=~/.kube/config" >> ~/.profile - - shown above is specific to CentOS. Substitute the correct syntax for your operating system. The following alternative is for Ubuntu: - - .. code-block:: none - - echo "export KUBECONFIG=~/.kube/config" >> ~/.bashrc #. Confirm that the environment variable is set correctly and that :command:`kubectl` commands are functioning properly. diff --git a/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst b/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst index bae06d4d1..3c7a934a4 100644 --- a/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst +++ b/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst @@ -107,11 +107,11 @@ applications with a Helm v2 chart. .. code-block:: none % kubectl get nodes -o wide - NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE ... - controller-0 Ready master 15h v1.12.3 192.168.204.3 CentOS L ... - controller-1 Ready master 129m v1.12.3 192.168.204.4 CentOS L ... - worker-0 Ready 99m v1.12.3 192.168.204.201 CentOS L ... - worker-1 Ready 99m v1.12.3 192.168.204.202 CentOS L ... + NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME + compute-0 Ready 9d v1.24.4 192.168.204.69 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 + compute-1 Ready 9d v1.24.4 192.168.204.7 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 + controller-0 Ready control-plane,master 9d v1.24.4 192.168.204.3 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 + controller-1 Ready control-plane,master 9d v1.24.4 192.168.204.4 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 % #. Install the Helm v2 client on remote workstation. diff --git a/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst b/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst index fdc94e6c5..bdc65849c 100644 --- a/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst +++ b/doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst @@ -41,46 +41,32 @@ Local |LDAP| user accounts share the following set of attributes: - Login sessions are logged out automatically after about 15 minutes of inactivity. -- After each unsuccessful login attempt, a 15 second delay is imposed before - making another attempt. If you attempt to login before 15 seconds the - system will display a message such as: +- After each unsuccessful login attempt, a 3 second delay is imposed before + making another attempt. After five consecutive unsuccessful login attempts, + further attempts are blocked for about five minutes. On further attempts + within 5 minutes, the system will display a message such as: - ``Account temporary locked (10 seconds left)`` + ``Account locked due to 6 failed logins`` - .. note:: On Debian-based |prod| systems, this delay is 3 seconds. + .. note:: - - After five consecutive unsuccessful login attempts, further attempts are - blocked for about five minutes. On further attempts within 5 minutes, the - system will display a message such as: + You are alerted on the 6th and subsequent attempts: - ``Account locked due to 6 failed logins`` + ``Account locked due to 6 failed logins`` - .. note:: + and an error message is displayed on subsequent attempts: - On Debian-based |prod| systems, you are alerted on the 6th and - subsequent attempts: + ``Maximum number of tries exceeded (5)`` - ``Account locked due to 6 failed logins`` + To clarify, 5 mins after the account is locked, the failed attempts will + be reset and failed attempts re-counted. - and an error message is displayed on subsequent attempts: - - ``Maximum number of tries exceeded (5)`` - - To clarify, on CentOS-based |prod| systems, the 5 minute block is not an - absolute window, but a sliding one. That is, if you keep attempting to log - in within those 5 minutes, the window keeps sliding and the you remain - blocked. Therefore, you should not attempt any further login attempts for 5 - minutes after 5 unsuccessful login attempts. - - On Debian-based |prod| systems, 5 mins after the account is locked, the - failed attempts will be reset and failed attempts re-counted. - -- All authentication attempts are recorded on the file /var/log/auth.log +- All authentication attempts are recorded on the file ``/var/log/auth.log`` of the target host. - Home directories and passwords are backed up and restored by the system - backup utilities. Note that only passwords are synced across hosts \(both - |LDAP| users and **sysadmin**\). Home directories are not automatically + backup utilities. Note that only passwords are synced across hosts (both + |LDAP| users and **sysadmin**). Home directories are not automatically synced and are local to that host. diff --git a/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst b/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst index b527e6936..9cf4a2e98 100644 --- a/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst +++ b/doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst @@ -116,11 +116,11 @@ configuration is required in order to use :command:`helm`. .. code-block:: none % kubectl get nodes -o wide - NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE ... - controller-0 Ready master 15h v1.12.3 192.168.204.3 CentOS L ... - controller-1 Ready master 129m v1.12.3 192.168.204.4 CentOS L ... - worker-0 Ready 99m v1.12.3 192.168.204.201 CentOS L ... - worker-1 Ready 99m v1.12.3 192.168.204.202 CentOS L ... + NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME + compute-0 Ready 9d v1.24.4 192.168.204.69 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 + compute-1 Ready 9d v1.24.4 192.168.204.7 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 + controller-0 Ready control-plane,master 9d v1.24.4 192.168.204.3 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 + controller-1 Ready control-plane,master 9d v1.24.4 192.168.204.4 Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12 % #. On the workstation, install the :command:`helm` client on an Ubuntu diff --git a/doc/source/security/kubernetes/the-sysadmin-account.rst b/doc/source/security/kubernetes/the-sysadmin-account.rst index 37282bb6f..09daeea36 100644 --- a/doc/source/security/kubernetes/the-sysadmin-account.rst +++ b/doc/source/security/kubernetes/the-sysadmin-account.rst @@ -23,39 +23,28 @@ The default initial password is **sysadmin**. - The initial password must be changed immediately when you log in to each host for the first time. For details, see |_link-inst-book|. -- After each unsuccessful login attempt, a 15 second delay is imposed before - making another attempt. If you attempt to login before 15 seconds the - system will display a message such as: - - ``Account temporary locked (10 seconds left)`` - - .. note:: On Debian-based |prod| systems, this delay is 3 seconds. - -- After five consecutive unsuccessful login attempts, further attempts are - blocked for about five minutes. On further attempts within 5 minutes, the - system will display a message such as: +- After each unsuccessful login attempt, a 3 second delay is imposed before + making another attempt. After five consecutive unsuccessful login attempts, + further attempts are blocked for about five minutes. On further attempts + within 5 minutes, the system will display a message such as: ``Account locked due to 6 failed logins`` .. note:: - On Debian-based |prod| systems, you are alerted on the 6th and - subsequent attempts: + You are alerted on the 6th and subsequent attempts: - ``Account locked due to 6 failed logins`` + ``Account locked due to 6 failed logins`` - and an error message is displayed on subsequent attempts: + and an error message is displayed on subsequent attempts: - ``Maximum number of tries exceeded (5)`` + ``Maximum number of tries exceeded (5)`` - To clarify, on CentOS-based |prod| systems, the 5 minute block is not an - absolute window, but a sliding one. That is, if you keep attempting to log - in within those 5 minutes, the window keeps sliding and the you remain - blocked. Therefore, you should not attempt any further login attempts for 5 - minutes after 5 unsuccessful login attempts. + To clarify, 5 mins after the account is locked, the failed attempts will + be reset and failed attempts re-counted. - On Debian-based |prod| systems, 5 mins after the account is locked, the - failed attempts will be reset and failed attempts re-counted. +- All authentication attempts are recorded on the file ``/var/log/auth.log`` + of the target host. Subsequent password changes must be executed on the active controller in an