A problem was identified during the migration from AIO-SX to AIO-DX
with dual-stack (IPv4 and IPv6). The Kubernetes certSANs configuration
failed when the primary OAM address pool was configured with the
addresses of controller0 and controller1. This failure stemmed from
the absence of a corresponding secondary OAM address pool
configuration for the same controllers. Consequently, an invalid
string was generated for the config map configuration.
This change tests the defined address variables before adding them to
the certsans string.
Test Plan
=========
[PASS] install AIO-SX in dual-stack:
- migrate config to AIO-DX
- adjust the addresses for both OAM pools
- unlock controller-0
- proceed with controller-1 installation
[PASS] install AIO-SX in single-stack and migrate to AIO-DX
Closes-Bug: 2103782
Change-Id: Id022ca86d14c0bb60d691b739e383a6e92c6ab54
Signed-off-by: Andre Kantek <andrefernandozanella.kantek@windriver.com>
Adding support for new parameters that will be configured in
StarlingX PTP. Also we reestructured a part of the puppet manifest
to be easier to read, and so that there is no more duplicaded
code. We changed the nic_clock_reset parameters to come from
clock_conf.conf file instead of hieradata, because upon deletion
the parameters don't show on hieradata anymore.
Test plan:
PASS: SMA1 input writen correctly into file
PASS: SMA2 input writen correctly into file
PASS: SMA1 output writen correctly into file
PASS: SMA2 output writen correctly into file
PASS: U.FL1 output writen correctly into file
PASS: U.FL2 input writen correctly into file
PASS: synce_rclka enabled checked in dmesg
PASS: synce_rclkb enabled checked in dmesg
Story: 2011345
Task: 51704
Change-Id: Ie864f376b2244e8d49af0e4bc357e600d12229be
Signed-off-by: Bruno Veiga <Bruno.VeigadeAlmeida@windriver.com>
After the initial reboot following a kickstart installation, residual
network configuration files remain, enabling the node to communicate
with the active controller. During Puppet configuration, the script
apply_network_config.py is intended to overwrite these configurations
with those from the sysinv database. However, simply bringing down
the labeled interface, without also addressing its associated base
interfaces, prevented the new configuration from being applied.
Consequently, the PXE boot interface was left without an IP address.
This change brings down the base interface also.
Test Plan:
[PASS] install a Standard in IPv6 and configure mgmt and cluster-host
in VLANs over the pxeboot interface. After install check that
no communication alarms are triggered and the pxeboot interface
on the compute nodes remains configured via DHCP.
Closes-Bug: 2103645
Change-Id: I8eb36ebf1c6fd93c814ff664997aff1d6e0cb10d
Signed-off-by: Andre Kantek <andrefernandozanella.kantek@windriver.com>
This commit makes the necessary changes to
platform::sm to configure and provision the new dc-certmon service.
Note: The certmon module will be revisited later to remove
migrated functionality once dccertmon is fully implemented
and operational.
These changes are part of a greater set of commits to introduce
the dccertmon service:
[1] https://review.opendev.org/c/starlingx/distcloud/+/941210
[2] https://review.opendev.org/c/starlingx/ha/+/941205
For background and context, please see commit message from [1].
Test plan:
- PASS: Bootstrap and unlock a DC system:
1) Subcloud
2) DC System Controller
Verify service is started.
- PASS: Bootstrap and unlock a non-DC system (standalone AIO):
- Verify Standalone non-DC system controller doesn't have
service started
- PASS: Run 'sm-restart service dccertmon' and verify the dccertmon
service was correctly restarted and service is working as
expected.
- PASS: Induce a failure in dccertmon code. Verify sm correctly
restarts the service until the failure is corrected.
Note: This commit has been tested alongside the related changes and
their respective test plans. [1][2]
Depends-on: https://review.opendev.org/c/starlingx/ha/+/941205
Story: 2011311
Task: 51668
Change-Id: Idaa598a405693adcff577e55ade58a7bb986280b
Signed-off-by: Salman Rana <salman.rana@windriver.com>
This reverts commit 850269646f5b4b30f3bf43f65cc0d244c09e0ed5.
Reason for revert: a patch is being applied on top of the original
change (https://review.opendev.org/c/starlingx/stx-puppet/+/938636)
which ensures that the interfaces in the auto file are ordered as
follows: lo -> eths -> bondings -> slaves -> vlans -> labels. This
guarantees that the interfaces are properly initialized at boot,
effectively fixing the issue that caused the change to be reverted in
the first place.
This commit replaces the apply_network_config.sh script by the Python-
coded equivalent apply_network_config.py, and includes automated tests
for it.
The original scripts apply_network_config.sh, network_ifupdown.sh and
network_sysconfig.sh are being marked as obsolete and shall be removed
in the future.
Flake8 test has been changed to include all files in the
puppet-manifests folder, adjustments had to be made to
puppet-update-grub-env.py, k8s_wait_for_endpoints_health.py and
change_k8s_control_plane_params.py for conformance.
Tests:
1. Installation
[PASS] AIO-SX IPv4 full install on virtualBox
[PASS] AIO-DX IPv6 full install on virtualBox
[PASS] AIO-DX IPv4 full install on a physical lab
[PASS] AIO-DX IPv6 full install on a physical lab
2. Network configuration change
For this test, a regular AIO-SX setup on VirtualBox is used with
default settings:
Address pools
- oam-ipv4: 10.20.6.0/24
- management-ipv4: 192.168.204.0/24
- cluster-host-ipv4: 192.168.206.0/24
Interfaces
- lo (lo, platform): management, cluster-host
- enp0s3 (oam0, platform): oam
- enp0s9 (data0, data)
- enp0s10 (data1, data)
Procedure:
- Lock host
- Execute sequence of commands
- Unlock host
- Wait for the host to unlock-reboot
- Check that kernel networking config reflects sysinv config
- Check that files in /etc/network/ were correctly generated
- Check that logs in /var/log/user.log are coherent
- Reboot host
- Check that interfaces are correctly initialized on boot
[PASS] Test 2.1: Add IPv6 stack, add addresses and routes to data1
system addrpool-add oam-ipv6 fd00:: 64 --ranges fd00::1-fd00::ffff \
--order random --floating-address fd00::3 --gateway-address fd00::1
system addrpool-add management-ipv6 fd01:: 64 \
--ranges fd01::1-fd01::ffff --order random \
--floating-address fd01::1 --controller0-address \
fd01::2 --controller1-address fd01::3
system addrpool-add cluster-host-ipv6 fd02:: 64 \
--ranges fd02::1-fd02::ffff --order random --floating-address \
fd02::1 --controller0-address fd02::2 --controller1-address fd02::3
system network-addrpool-assign oam oam-ipv6
system network-addrpool-assign mgmt management-ipv6
system network-addrpool-assign cluster-host cluster-host-ipv6
system host-if-modify controller-0 data1 --ipv4-mode static \
--ipv6-mode static
system host-addr-add controller-0 data1 177.201.1.2 24
system host-addr-add controller-0 data1 bd01:201::1:2 64
system host-route-add controller-0 data1 208.166.11.0 24 177.201.1.111
system host-route-add controller-0 data1 af04:11:: 64 bd01:201::111
[PASS] Test 2.2: Move mgmt and cluster-host networks from lo to eth
mgmt_intnet=$(system interface-network-list controller-0 | \
grep "mgmt" | awk '{print $4}')
clhost_intnet=$(system interface-network-list controller-0 | \
grep "cluster-host" | awk '{print $4}')
system interface-network-remove $mgmt_intnet
system interface-network-remove $clhost_intnet
system host-if-modify controller-0 enp0s8 -n mgmt0 -c platform
system interface-network-assign controller-0 mgmt0 mgmt
system interface-network-assign controller-0 mgmt0 cluster-host
system host-route-add controller-0 mgmt0 208.166.1.0 24 192.168.204.111
system host-route-add controller-0 mgmt0 af04:1:: 64 fd01::111
system host-route-add controller-0 mgmt0 208.166.2.0 24 192.168.206.111
system host-route-add controller-0 mgmt0 af04:2:: 64 fd02::111
[PASS] Test 2.3: Move mgmt and cluster-host networks to VLANs
mgmt_intnet=$(system interface-network-list controller-0 | \
grep "mgmt" | awk '{print $4}');
clhost_intnet=$(system interface-network-list controller-0 | \
grep "cluster-host" | awk '{print $4}');
system interface-network-remove $mgmt_intnet
system interface-network-remove $clhost_intnet
while read i; do uuid=$(echo "$i" | awk '{print $2}'); system \
host-route-delete "$uuid"; done <<< $(system host-route-list \
controller-0 | grep "mgmt0");
system host-if-modify controller-0 mgmt0 -n pxeboot0
system host-if-add controller-0 mgmt0 vlan pxeboot0 -V 10 -c platform
system host-if-add controller-0 cluster0 vlan pxeboot0 -V 11 -c platform
system host-if-add controller-0 datavlan1 vlan data1 -V 201 -c data \
--ipv4-mode static --ipv6-mode static
system interface-network-assign controller-0 pxeboot0 pxeboot
system interface-network-assign controller-0 mgmt0 mgmt
system interface-network-assign controller-0 cluster0 cluster-host
system host-addr-add controller-0 datavlan1 177.202.1.2 24
system host-addr-add controller-0 datavlan1 bd01:202::1:2 64
system host-route-add controller-0 mgmt0 208.166.1.0 24 192.168.204.111
system host-route-add controller-0 mgmt0 af04:1:: 64 fd01::111
system host-route-add controller-0 cluster0 \
208.166.2.0 24 192.168.206.111
system host-route-add controller-0 cluster0 af04:2:: 64 fd02::111
system host-route-add controller-0 datavlan1 \
208.166.21.0 24 177.202.1.111
system host-route-add controller-0 datavlan1 af04:21:: 64 bd01:202::111
[PASS] Test 2.4: Move pxeboot, mgmt and cluster-host to a bonding
pxeboot_intnet=$(system interface-network-list controller-0 | \
grep "pxeboot" | awk '{print $4}')
mgmt_intnet=$(system interface-network-list controller-0 | \
grep "mgmt" | awk '{print $4}')
clhost_intnet=$(system interface-network-list controller-0 | \
grep "cluster-host" | awk '{print $4}')
system interface-network-remove $pxeboot_intnet
system interface-network-remove $mgmt_intnet
system interface-network-remove $clhost_intnet
system host-if-delete controller-0 mgmt0
system host-if-delete controller-0 cluster0
system host-if-modify controller-0 pxeboot0 -c none
system host-if-modify controller-0 data0 -c none
system host-if-add controller-0 bond0 ae enp0s8 enp0s9 -c platform
system interface-network-assign controller-0 bond0 mgmt
system interface-network-assign controller-0 bond0 cluster-host
system host-route-add controller-0 bond0 208.166.1.0 24 192.168.204.111
system host-route-add controller-0 bond0 af04:1:: 64 fd01::111
system host-route-add controller-0 bond0 208.166.2.0 24 192.168.206.111
system host-route-add controller-0 bond0 af04:2:: 64 fd02::111
[PASS] Test 2.5: Move mgmt and cluster-host to vlans on top of a bonding
mgmt_intnet=$(system interface-network-list controller-0 | \
grep "mgmt" | awk '{print $4}')
clhost_intnet=$(system interface-network-list controller-0 | \
grep "cluster-host" | awk '{print $4}')
system interface-network-remove $mgmt_intnet
system interface-network-remove $clhost_intnet
system host-if-add controller-0 mgmt0 vlan bond0 -V 10 -c platform
system host-if-add controller-0 cluster0 vlan bond0 -V 11 -c platform
system interface-network-assign controller-0 mgmt0 mgmt
system interface-network-assign controller-0 cluster0 cluster-host
while read i; do uuid=$(echo "$i" | awk '{print $2}'); system \
host-route-delete "$uuid"; done <<< $(system host-route-list \
controller-0 | grep "bond0");
system host-route-add controller-0 mgmt0 208.166.1.0 24 192.168.204.111
system host-route-add controller-0 mgmt0 af04:1:: 64 fd01::111
system host-route-add controller-0 cluster0 \
208.166.2.0 24 192.168.206.111
system host-route-add controller-0 cluster0 af04:2:: 64 fd02::111
3. Distributed cloud
[PASS] Subcloud enrollment, OAM over ethernet, same subnet
[PASS] Subcloud enrollment, OAM over VLAN, different VLAN ID,
different subnet
Story: 2011338
Task: 51635
Change-Id: I0a9e095dcff5c59a0e543b481c8d0856e8485340
Signed-off-by: Lucas Ratusznei Fonseca <lucas.ratuszneifonseca@windriver.com>
This commit adds kubelet service to pmon. This is
required because the kubelet.conf file in /etc/pmon.d
is deleted after major upgrade due to 3-way merge.
During "ostree admin deploy" a 3-way merge happens on the
/etc directory. In this, /etc from current load, upgrade
load and a base directory (/usr/etc) are merged. Because
the file is not present in /usr/etc, its removed after 3-way
merge. It looks like all the files in /etc/pmon.d are getting
removed as there is no "pmon.d" directory in /usr/etc, but the
other files have a symlink to "/usr/share/starlingx/pmon.d",
whereas kubelet.conf file is standalone, so it doesn't get
created after 3-way merge or major upgrade.
To make sure the file is not removed on further major
upgrades, a standardised approach is being worked on
https://bugs.launchpad.net/starlingx/+bug/2100759
Test Plan:
PASS: Check kubelet.conf file present after host install lock-unlock
PASS: Check kubelet.conf file present after lock-unlock
PASS: Test on storage standard lab, major upgrade with code
changes in custom iso
PASS: Verify with changes applied pre-bootstrap
PASS: Verify major upgrade with code fix applied on to-side
Closes-Bug: #2099960
Change-Id: I2c58f29ffc184206e491d556987a8d3ef244b515
Signed-off-by: sshathee <shunmugam.shatheesh@windriver.com>
Floating IPv6 addresses are configured with "preferred_lft 0," which
designates them as deprecated. As a result, when the host initiates
traffic, the static network address is selected as the source.
This can lead to situations where the upstream switch does not
observe packets originating from the floating address. Consequently,
the switch may lack the necessary MAC address mapping to deliver
traffic destined for the floating address. While switches are expected
to perform NDP Neighbor Solicitations to discover the floating
address's MAC, this process is not always reliable, especially when
relying solely on external traffic directed towards the host.
To accelerate the network's learning of the floating address's MAC,
the Unsolicited Advertisement (analogous to gratuitous ARP in IPv4) is
transmitted.
This behavior is primarily observed during the initial unlock of
controller-0, before the Service-Manager (SM) takes over the
management of the floating addresses. Subsequent unlocks do not
exhibit this issue.
Test Plan
=========
[PASS] install controller-0 on a AIO-DX configuration (IPv6), execute
network configuration and perform the fist unlock, upon system
return observe from external devices connected to controller-0
interfaces that "Unsolicited Advertisement" are sent related
to the floating addresses.
Closes-Bug: 2101145
Change-Id: If2a446ec5a8668b4dbb3e583aa8cb06cb49da0ff
Signed-off-by: Andre Kantek <andrefernandozanella.kantek@windriver.com>
This reverts commit 4d7a0438f626638c7a5b307ca32bfd2616f7661e.
Reason for revert: generated auto file in incorrect order, causing ifup to fail for some labels during startup.
Change-Id: Ic549a293bf28edf29f9d49d2a954791af4711f20
In this commit, added the code to set permissions to 600
for all .crt files in /etc/kubernetes/pki directory.
This commit will be in effect during deployment of peer
nodes using pxe server.
TEST CASES:
PASSED: Run full build, system install, bootstrap and unlock (SX)
PASSED: System install, bootstrap, unlock and swact (DX)
PASSED: Checked permission using below command
"ls -al /etc/kubernetes/pki/*.crt"
PASSED: Checked whether certificates are accessible and readable
Example:
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text
PASSED: Checked status of kubernetes cluster and pods.
PASSED: No alarms when ran "fm alarm-list"
Story: 2011334
Task: 51677
Depends-On: https://review.opendev.org/c/starlingx/ansible-playbooks/+/940238
Change-Id: I9f05b0e9e35910d5a1a113d2be02635d48bc1063
Signed-off-by: sshaikh1 <sirin.shaikh@windriver.com>
Currently, various file permissions under /var/log/ are more
permissive than 640. To comply with the CIS benchmark
requirements, the permissions should be set to 640 or more
restrictive.
This change updates the permissions and ownership of files
under /var/log/ to 640. Ownership is also set to root:root
wherever possible.
Below are the exception where permissions or ownership are not updated:
- /var/log/keystone/keystone.log: ownership set to keystone:keystone
After changing the user and group to root:root, Ansible bootstrap
is failing as keystone is unable to write to keystone.log.
- /var/log/flux/helm-controller.log: ownership set to nobody:nogroup
We can't change this to root:root because container won't be able
to write the logs.
- /var/log/flux/source-controller.log: ownership set to
nobody:nogroup. We can't change this to root:root because
container won't be able to write the logs.
- /var/log/puppet/masterhttp.log: mode set to 660. Changed
permission to 640, it reverts to the same permission (660) after
some time.
- /var/log/puppet/masterhttp.log: ownership set to puppet:puppet.
Changed ownership to "root:root", it reverts to the old
ownership "puppet:puppet" after some time.
- /var/log/horizon_sm.log: mode set to 644. Unable to modify it
because it is generated after this manifest completes execution.
- /var/log/multus.log: mode set to 644. Unable to modify it because
it is generated after this manifest completes execution.
Test Plan:
PASS: Build ISO and deploy AIO-SX, AIO-DX, standard, and storage.
PASS: Verify that all files under /var/log/ on all type of nodes
(controller-0, controller-1, compute), except for
those listed as exceptions, have 640 or more restrictive
permissions and ownership as root:root in the standard
deployment.
PASS: Verify that all files under /var/log/ on controller-0, except
for those listed as exceptions, have 640 or more restrictive
permissions and ownership as root:root in the AIO-SX
deployment.
PASS: Verify that all files under /var/log/ on controller-0 and
controller-1, except for those listed as exceptions, have
640 or more restrictive permissions and ownership as
root:root in the AIO-DX deployment.
PASS: Standard: check ceph health using 'ceph-s' command and verify
if cluster health is ok.
PASS: Standard: swact the controller and verify if there is no alarm.
Verify the log permission, it should not be reverted.
PASS: AIO-SX: Run the CIS script as mentioned in the specification
3-4 hours after installation to confirm that the file
permissions and ownership modified by this change have not
been reverted.
PASS: AIO-SX: Run the CIS benchmark test one day after installation
on controller-0 to verify that the file permissions and
ownership modified by this change remain unchanged.
PASS: Verify that all files under /var/log/ on storage node, except
for those listed as exceptions, have 640 or more restrictive
permissions and ownership as root:root in the storage
deployment.
Story: 2011241
Task: 51364
Change-Id: Ie15076ff0d66db98d8171fcfac9411ba0f8f8631
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
The timeout for unlock host during VIM strategies was extended. This
change will provided the matching puppet config update.
TEST PLAN
PASS: On NFV runtime, config is updated
Partial-Bug: https://bugs.launchpad.net/starlingx/+bug/2098767
Depends-On: https://review.opendev.org/c/starlingx/nfv/+/942119
Change-Id: I996429eb7e3d2a8aba5762357ae7ad2b6cd60270
Signed-off-by: Joshua Kraitberg <joshua.kraitberg@windriver.com>
This reverts commit 617b6b78327544003adcf05c033c51f04406d4bc.
Reason for revert: puppet error on controller-1
Change-Id: I128168f90fffdd7f90ff5e2fd7fd298f3b7c9bca
Currently, various file permissions under /var/log/ are more
permissive than 640. To comply with the CIS benchmark
requirements, the permissions should be set to 640 or more
restrictive.
This change updates the permissions and ownership of files
under /var/log/ to 640. Ownership is also set to root:root
wherever possible.
Below are the exception where permissions or ownership are not updated:
- /var/log/keystone/keystone.log: ownership set to keystone:keystone
- /var/log/flux/helm-controller.log: ownership set to nobody:nogroup
- /var/log/flux/source-controller.log: ownership set to nobody:nogroup
- /var/log/puppet/masterhttp.log: mode set to 660
- /var/log/puppet/masterhttp.log: ownership set to puppet:puppet
Test Plan:
PASS: Build ISO and deploy AIO-SX.
PASS: Verify that all files under /var/log/, except for those
listed as exceptions, have 640 or more restrictive permissions
and ownership as root:root in the AIO-SX deployment.
PASS: AIO-SX: Run the CIS script 3-4 hours after installation to
confirm that the file permissions and ownership modified by
this change have not been reverted.
PASS: AIO-SX: Run the CIS benchmark test one day after installation
to verify that the file permissions and ownership modified by
this change remain unchanged.
Story: 2011241
Task: 51364
Change-Id: I84109690a21363335726bcbeac68f9f7c332ed36
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
This reverts commit 0184254a37b5a1d2def122d33f80edb2912a2813.
Reason for revert: This is dependent on Https://review.opendev.org/c/starlingx/upstream/+/935495 which is reverted.
Change-Id: I4a67ca5978d3232b34a00529133a8996de200a8e
In fresh installations, during the first host unlock after running the
Ansible playbook, only controller-0 is initially configured.
The playbook creates the flag:
/etc/platform/simplex
This applies to AIO-DX and standard installations as well.
This behavior is implemented in the following change:
2b7bcd79c9/playbookconfig/playbookconfig/playbooks/bootstrap/roles/validate-config/tasks/main.yml (L421)
Impact on OAM Floating IP Installation
On the first boot after the Ansible playbook runs, the OAM Floating IP
is not installed by SM through the oam-ipv4 service.
Instead, it is installed by Puppet via network.pp.
In rare situations, especially in test environments where systems are
frequently reinstalled, it is recommended to send a Gratuitous ARP (GARP)
to update the ARP table of the switch managing external networks.
For subsequent host lock/unlock cycles or reboots, SM will install the
OAM Floating IP via the oam-ipv4 service, and IPaddr2 will send the
Gratuitous ARP automatically.
This is only required for IPv4 installations. In IPv6 scenarios,
the Neighbor Discovery Protocol (NDP) handles address resolution instead.
Tests Done:
- IPv4 AIO-SX fresh install
Confirmed that a Gratuitous ARP was sent
- IPv4 AIO-DX fresh install
Confirmed that a Gratuitous ARP was sent
- IPv4 Standard fresh install
Confirmed that a Gratuitous ARP was sent
- IPv6 AIO-DX fresh install
Confirmed that the code does not execute Gratuitous ARP
Closes-Bug: 2097624
Signed-off-by:
Fabiano Correa Mercer fabiano.correamercer@windriver.com
Change-Id: I981d37b0c655206f5d6770908b25d98a3fe76cee
This change introduces 2 memory limits for memcached:
large for system controllers: 782MB
small for subclouds and standalone: 32MB
Currently the memory limit for all system types is 782MB, which
is deemed excessive for most system types, hence the decrease to 32MB.
It also adds a runtime class to restart memcached in the event of
fernet key rotation in order to avoid stale token in cache.
Test plan:
PASS: Full build, install and bootstrap
PASS: Install sx system, verify memory limit is 32MB
PASS: Install DC system with sx subcloud, verify memory limit is 32MB
for subcloud and 782 for system controller
PASS: In the system controller, do manage and unmanage of the subcloud
to trigger fernet key rotation. Verify that memcached is
restarted in the subcloud and that the memory limit remains as
32 MB.
Closes-Bug: 2088084
Signed-off-by: Rei Oliveira <Reinildes.JoseMateusOliveira@windriver.com>
Change-Id: Icf83962c559ad513f0e5919c2bbca175bb187727
Currently, CIS benchmark checks fail for the permission and ownership
settings of /etc/cron* and the /etc/at.allow file. The CIS
recommendation is to ensure that root is both the owner and group for
these files, and that only the owner has access to them.
This change introduces a Puppet class that ensures file permissions and
ownership for /etc/cron* and /etc/at.allow are modified according to
CIS benchmark recommendations.
Test Plan:
PASS: Build iso and deploy.
PASS: AIO-SX: Ensure that the ownership and permission of
/etc/cron* and /etc/at.allow are set as per the CIS
recommendation.
PASS: AIO-SX: Run the CIS benchmark and ensure that the
controls/tests related to /etc/cron* and /etc/at.allow
pass successfully.
PASS: AIO-SX: Verify that cron jobs are executed correctly
after the change. Verify that there are no errors in the
cron log at /var/log/cron.log. Specifically, check for the
absence of any error messages or failed cron job logs.Verify
that the memory log file rss-memory.log exists in the
expected directory and a log of cron execution in
/var/log/cron.log.
Story: 2011241
Task: 51170
Change-Id: Ib72caedcd21be07daa310aa6eef21d26cc8db7cb
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
Puppet configuration for VIM Activate retry
is changed from 120 secs to 30 secs to be
inline with VIM repo configuration.
TEST PLAN
PASSED: Upgrade from 24.09 to 25.09 with activation
retries.
Story: 2011045
Task: 51650
Change-Id: Ia4f502ab371217aac06f98df45485b4b717bccf8
Signed-off-by: Vanathi.Selvaraju <vanathi.selvaraju@windriver.com>
Currently, various file permissions under /var/log/ are more
permissive than 640. To comply with the CIS benchmark
requirements, the permissions should be set to 640 or more
restrictive.
This change updates the permissions and ownership of files
under /var/log/ to 640. Ownership is also set to root:root
wherever possible.
Below are the exception where permissions or ownership are not updated:
- /var/log/keystone/keystone.log: ownership set to keystone:keystone
- /var/log/flux/helm-controller.log: ownership set to nobody:nogroup
- /var/log/flux/source-controller.log: ownership set to nobody:nogroup
- /var/log/puppet/masterhttp.log: mode set to 660
- /var/log/puppet/masterhttp.log: ownership set to puppet:puppet
Test Plan:
PASS: Build ISO and deploy AIO-SX.
PASS: Verify that all files under /var/log/, except for those
listed as exceptions, have 640 or more restrictive permissions
and ownership as root:root in the AIO-SX deployment.
PASS: AIO-SX: Run the CIS script 3-4 hours after installation to
confirm that the file permissions and ownership modified by
this change have not been reverted.
PASS: AIO-SX: Run the CIS benchmark test one day after installation
to verify that the file permissions and ownership modified by
this change remain unchanged.
Story: 2011241
Task: 51364
Depends-On: https://review.opendev.org/c/starlingx/integ/+/935493
Depends-On: https://review.opendev.org/c/starlingx/ha/+/935499
Depends-On: https://review.opendev.org/c/starlingx/upstream/+/935495
Change-Id: I32f4341f14b5258ece715c5081d675e34a86e624
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
In this commit, added the code to change the /etc/kubenetes/admin.conf
file ownership to root:root in fresh install.
Also, added the code to run the command
"setfacl -m g:sys_protected:r /etc/kubernetes/admin.conf" such that
all the WRCP users/applications that are in the sys_protected group
continue to have read access to this file.
TEST CASES:
PASSED: Checked ownership using below command
"ls -al /etc/kubernetes/admin.conf".
PASSES: Checked the file permission using below command which
will show 640.
"stat -c %a /etc/kubernetes/admin.conf"
PASSED: Checked the ACL entries using below command
"getfacl /etc/kubernetes/admin.conf".
PASSED: No error when ran "system host-swact" in AIO-DX.
PASSED: No alarms when ran "fm alarm-list".
PASSED: Verified that sysinv can read admin.conf file using below
commands:
"sudo -u sysinv cat "/etc/kubernetes/admin.conf" &>/dev/null"
"sudo -u sysadmin cat "/etc/kubernetes/admin.conf" &>/dev/null"
Added "testuser" to the users group and ran below command and
this gives output "can not read /etc/kubernetes/admin.conf":
sudo -u "testuser" cat "/etc/kubernetes/admin.conf" &>/dev/null
Also verified using system command which can read admin.conf:
"system service-parameter-modify kubernetes kube_apiserver
audit-log-maxage=30"
Story: 2011334
Task: 51610
Change-Id: I6097f9f4863d83f69b5e804fec6cf4a02607c799
Signed-off-by: Md Irshad Sheikh <mdirshad.sheikh@windriver.com>
Fix the following CIS Benchmark network configurations:
- 1.5.1 Ensure address space layout randomization is enabled
- 1.5.2 Ensure ptrace_scope is restricted
- 3.3.7 Ensure Reverse Path Filtering is enabled
Testing:
- Build successful
- SX and DX deployment successful
- Run CIS Tenable-IO scan with no errors
Story: 2011210
Task: 51627
Depends-On: https://review.opendev.org/c/starlingx/ansible-playbooks/+/940409
Change-Id: I3af0a4f1750ef11049530b1530c09283c9cb72be
Signed-off-by: Mohammad Issa <mohammad.issa@windriver.com>
Certificate super-admin.conf is a new certificate introduced
recently in k8s. This commit adds it to the Kube Root CA
update orchestration.
PASS: Run Kube Root CA update and verify that every certificate
signed by K8s Root CA is updated in show-certs.sh. For DX,
do this check in controller-1 too. Verify k8s is operation.
Run host-lock/unlock and verify k8s and certificates are
still the same.
Closes-Bug: 2097100
Signed-off-by: Rei Oliveira <Reinildes.JoseMateusOliveira@windriver.com>
Change-Id: Iaf5a94248310e53ebc19bcfbfddea80bde94694c
SCTP module autoload is enabled/disabled by using
service-parameter sctp_autoload.
Full Parameter name:
"platform::params::sctp_autoload"
This change implements a runtime manifest which makes sctp module
changes.
By default: sctp_autoload is "enabled"
If sctp_autoload=disabled:
- SCTP Module doesn't get loaded by default post host
lock/unlock
If sctp_autoload=enabled:
- SCTP Moduel gets loaded by default post host
lock/unlock.
Test Plan:
PASSED: build-pkgs
PASSED: Deployed AIO-Standard
PASSED: Verify service parameter configuration using
enabled/disabled values
PASSED: SCTP module loads/unloads after host-reboot
Story: 2011335
Task: 51623
Change-Id: Ib27367807f1096a6253d96f113d9107a3ff2f596
Signed-off-by: Aman Pandae <AmanPandae.Mothukuri@windriver.com>
When a ssl_ca certificate is installed as trusted, we need to restart
Docker to pick up the new certificate. A bug was introduced in this
behavior by verifying 'dockerd.service' with 'systemctl status' instead
of 'docker.service'.
Test plan:
PASS: Update platform certificates w/ playbook.
Observe that docker restarts.
Login to local registry.
Closes-bug: 2096667
Change-Id: I435a3af64b720d2f343af3709db1221ca798927e
Signed-off-by: Marcelo de Castro Loebens <Marcelo.DeCastroLoebens@windriver.com>
This commit adds list_services and list_endpoints as permitted for
the reader role. This puppet template generates file /etc/keystone/
policy.json
These endpoints only return information and fit the description of the
reader role as a role that has rights to perform actions with list,
query, show and summary [1].
[1] https://docs.starlingx.io/security/kubernetes/keystone-account-roles-64098d1abdc1.html
Test plan:
PASS: Full build, install and bootstrap.
PASS: With the default admin user verify this commands operate normally
from the cli with 'openstack service list' and 'openstack endpoint
list.'
PASS: Verify the reader role works by creating a new user with the
reader role and trying the 2 commands.
PASS: Verify change is persistent after host-lock / unlock.
Closes-Bug: 2095181
Signed-off-by: Rei Oliveira <Reinildes.JoseMateusOliveira@windriver.com>
Change-Id: Id911277501c6dea74536c95e9e4250958e7bf5b7
