starlingx/docs
Code Issues Proposed changes

Generic CentOS > Debian updates

Browse Source 
Generic changes related to distribution switch-over
Additional updates

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: I35509d61e01c1f18437435ae16fdaad1dbd58dbb
This commit is contained in:
Ron Stone 2022-12-15 15:07:56 -05:00
parent 0cc3212b79
commit 0627a88887
9 changed files with 43 additions and 79 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/fault-mgmt/kubernetes/snmp-event-table.rst
View File

@ -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|

2
doc/source/fault-mgmt/kubernetes/snmp-overview.rst
View File

@ -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/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:

2
doc/source/fault-mgmt/kubernetes/traps.rst
View File

@ -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.

5
doc/source/planning/kubernetes/local-and-ldap-linux-user-accounts.rst
View File

@ -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.

12
doc/source/security/kubernetes/configure-local-cli-access.rst
View File

@ -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 <KUBECONFIG> environment variable is set correctly
and that :command:`kubectl` commands are functioning properly.

10
doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst
View File

@ -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 <none> CentOS L ...
controller-1 Ready master 129m v1.12.3 192.168.204.4 <none> CentOS L ...
worker-0 Ready <none> 99m v1.12.3 192.168.204.201 <none> CentOS L ...
worker-1 Ready <none> 99m v1.12.3 192.168.204.202 <none> CentOS L ...
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
compute-0 Ready <none> 9d v1.24.4 192.168.204.69 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12
compute-1 Ready <none> 9d v1.24.4 192.168.204.7 <none> 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 <none> 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 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12
%
#. Install the Helm v2 client on remote workstation.

44
doc/source/security/kubernetes/local-ldap-linux-user-accounts.rst
View File

@ -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.

10
doc/source/security/kubernetes/security-install-kubectl-and-helm-clients-directly-on-a-host.rst
View File

@ -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 <none> CentOS L ...
controller-1 Ready master 129m v1.12.3 192.168.204.4 <none> CentOS L ...
worker-0 Ready <none> 99m v1.12.3 192.168.204.201 <none> CentOS L ...
worker-1 Ready <none> 99m v1.12.3 192.168.204.202 <none> CentOS L ...
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
compute-0 Ready <none> 9d v1.24.4 192.168.204.69 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-6-amd64 containerd://1.4.12
compute-1 Ready <none> 9d v1.24.4 192.168.204.7 <none> 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 <none> 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 <none> 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

35
doc/source/security/kubernetes/the-sysadmin-account.rst
View File

@ -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