Merge pull request #81965 from ShaunaDiaz/OSDOCS-12018

OSDOCS-12018: fix FIPS link and correct attributes

Author: ShaunaDiaz

_attributes/attributes-microshift.adoc

@@ -14,7 +14,6 @@
 :product-version: 4.17
 :rhel-major: rhel-9
 :op-system-base-full: Red Hat Enterprise Linux (RHEL)
-:op-system: RHEL
 :op-system-base: RHEL
 :op-system-ostree-first: Red Hat Enterprise Linux for Edge (RHEL for Edge)
 :op-system-ostree: RHEL for Edge

microshift_install_bootc/microshift-install-rhel-image-mode.adoc

@@ -8,7 +8,7 @@ toc::[]
 
 You can embed {microshift-short} into an operating system image using image mode for {op-system-base-full}.
 
-:FeatureName: Image mode for {op-system}
+:FeatureName: Image mode for {op-system-base}
 
 include::snippets/technology-preview.adoc[]
 

microshift_install_get_ready/microshift-fips.adoc

@@ -10,14 +10,11 @@ You can use FIPS mode with RPM-based installations of {microshift-short} on {op-
 
 * To enable FIPS mode in {microshift-short} containers, the worker machine kernel must be enabled to run in FIPS mode before the machine starts.
 * Using FIPS with {op-system-ostree-first} images is not supported.
+* Using FIPS with image mode for {op-system-base} is not supported.
 
 include::modules/microshift-fips-rpm-system.adoc[leveloffset=+1]
 
 [id="additional-resources_microshift-fips_{context}"]
 [role="_additional-resources"]
 == Additional resources
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/assembly_installing-the-system-in-fips-mode_security-hardening[Installing the system in FIPS mode]
-
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#enabling-fips-mode-in-a-container_using-the-system-wide-cryptographic-policies[Enabling FIPS mode in a container]
-
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/assembly_installing-the-system-in-fips-mode_security-hardening#federal-information-processing-standards-140-and-fips-mode_assembly_installing-the-system-in-fips-mode[Federal Information Processing Standards 140 and FIPS mode]
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening[Switching RHEL to FIPS mode]

microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree.adoc

@@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-You can embed {microshift-short} into a {op-system-ostree-first} image. Use this guide to build a {op-system} image containing {microshift-short}.
+You can embed {microshift-short} into a {op-system-ostree-first} image. Use this guide to build a {op-system-base} image containing {microshift-short}.
 
 include::modules/microshift-preparing-for-image-building.adoc[leveloffset=+1]
 

microshift_updating/microshift-update-options.adoc

@@ -19,7 +19,7 @@ include::snippets/microshift-rhde-compatibility-table-snip.adoc[leveloffset=+1]
 Consider the following when planning to update {microshift-short}:
 
 * You can potentially update {microshift-short} without reinstalling your applications and Operators.
-* {op-system} or {op-system-ostree} updates are only required to update {microshift-short} if the existing operating system is not compatible with the new version of {microshift-short} that you want to use.
+* {op-system-base} or {op-system-ostree} updates are only required to update {microshift-short} if the existing operating system is not compatible with the new version of {microshift-short} that you want to use.
 * {microshift-short} operates as an in-place update and does not require removal of the previous version. Data backups beyond those required for the usual functioning of your applications are also not required.
 
 include::snippets/microshift-update-paths-snip.adoc[leveloffset=+1]
@@ -65,12 +65,12 @@ You can update {microshift-short} manually on a non-OSTree system such as {op-sy
 
 [WARNING]
 ====
-Keeping versions in a supported configuration of {op-system-bundle} can require updating {microshift-short} and {op-system} at the same time. Ensure that your version of {op-system} is compatible with the version of {microshift-short} you are updating to, especially if you are updating {microshift-short} across two minor versions. Otherwise, you can create an unsupported configuration, break your cluster, or both.
+Keeping versions in a supported configuration of {op-system-bundle} can require updating {microshift-short} and {op-system-base} at the same time. Ensure that your version of {op-system-base} is compatible with the version of {microshift-short} you are updating to, especially if you are updating {microshift-short} across two minor versions. Otherwise, you can create an unsupported configuration, break your cluster, or both.
 ====
 
 [id="microshift-update-options-standalone-rhel-updates_{context}"]
 == Standalone {op-system-ostree} updates
-You can update {op-system-ostree} or {op-system} without updating {microshift-short}, on the condition that the two versions are compatible. Check compatibilities before beginning an update. Use the {op-system-ostree} documentation specific to your update path.
+You can update {op-system-ostree} or {op-system-base} without updating {microshift-short}, on the condition that the two versions are compatible. Check compatibilities before beginning an update. Use the {op-system-ostree} documentation specific to your update path.
 
 //additional resources for updating RHEL alone
 [role="_additional-resources"]
@@ -79,11 +79,11 @@ You can update {op-system-ostree} or {op-system} without updating {microshift-sh
 
 [id="microshift-update-options-simultaneous-microshift-rhel-updates_{context}"]
 == Simultaneous {microshift-short} and operating system updates
-You can update {op-system-ostree} or {op-system} and update {microshift-short} at the same time, on the condition that the versions are compatible. Use the following workflow:
+You can update {op-system-ostree} or {op-system-base} and update {microshift-short} at the same time, on the condition that the versions are compatible. Use the following workflow:
 
 . Check for compatibility before beginning an update.
-. Use the {op-system-ostree} and {op-system} documentation specific to your update path to plan and update the operating system.
-. Enable the correct {microshift-short} repository to ensure alignment between your {op-system} and {microshift-short} versions.
+. Use the {op-system-ostree} and {op-system-base} documentation specific to your update path to plan and update the operating system.
+. Enable the correct {microshift-short} repository to ensure alignment between your {op-system-base} and {microshift-short} versions.
 . Use the {microshift-short} update type specific to your update path.
 
 //additional resources for updating RHEL and MicroShift

modules/microshift-accessing-cluster-locally.adoc

@@ -16,7 +16,7 @@ Use the following procedure to access the {microshift-short} cluster locally by
 
 .Procedure
 
-. Optional: to create a `~/.kube/` folder if your {op-system} machine does not have one, run the following command:
+. Optional: to create a `~/.kube/` folder if your {op-system-base-full} machine does not have one, run the following command:
 +
 [source,terminal]
 ----

modules/microshift-accessing-cluster-remotely.adoc

@@ -20,7 +20,7 @@ The `user@workstation` login is used to access the host machine remotely. The `<
 
 .Procedure
 
-. As `user@workstation`, create a `~/.kube/` folder if your {op-system} machine does not have one by running the following command:
+. As `user@workstation`, create a `~/.kube/` folder if your {op-system-base-full} machine does not have one by running the following command:
 +
 [source,terminal,subs="attributes+"]
 ----
@@ -34,7 +34,7 @@ The `user@workstation` login is used to access the host machine remotely. The `<
 [user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of {microshift-short} machine>
 ----
 
-. As `user@workstation`, copy the generated `kubeconfig` file that contains the host name or IP address you want to connect with from the {op-system} machine running {microshift-short} to your local machine by running the following command:
+. As `user@workstation`, copy the generated `kubeconfig` file that contains the host name or IP address you want to connect with from the {op-system-base} machine running {microshift-short} to your local machine by running the following command:
 +
 [source,terminal]
 ----

modules/microshift-audit-logs-config-intro.adoc

@@ -38,5 +38,5 @@ If you do not specify a value for a field, the default value is used. If you rem
 
 [IMPORTANT]
 ====
-You must configure audit log retention and rotation in {op-system-base-full} for logs that are generated by application pods. These logs print to the console and are saved. Ensure that your log preferences are configured for the {op-system} `/var/log/audit/audit.log` file to maintain {microshift-short} cluster health.
+You must configure audit log retention and rotation in {op-system-base-full} for logs that are generated by application pods. These logs print to the console and are saved. Ensure that your log preferences are configured for the {op-system-base} `/var/log/audit/audit.log` file to maintain {microshift-short} cluster health.
 ====

modules/microshift-fips-rpm-system.adoc

@@ -8,7 +8,7 @@
 
 Using FIPS with {microshift-short} requires enabling the cryptographic module self-checks in your {op-system-base-full} installation. After the host operating system has been configured to start with the FIPS modules, {microshift-short} containers are automatically enabled to run in FIPS mode.
 
-* When {op-system-base} is started in FIPS mode, {microshift-short} core components use the {op-system} cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 validation on only the x86_64 architectures.
+* When {op-system-base} is started in FIPS mode, {microshift-short} core components use the {op-system-base} cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 validation on only the x86_64 architectures.
 
 * You must enable FIPS mode when you install {op-system-base} {op-system-version-major} on the machines that you plan to use as worker machines.
 +
@@ -27,8 +27,3 @@ Because FIPS must be enabled before the operating system that your cluster uses
 * TLS implementation FIPS support is not complete.
 
 * The FIPS implementation does not offer a single function that both computes hash functions and validates the keys that are based on that hash. This limitation continues to be evaluated for improvement in future {microshift-short} releases.
-
-[id="microshift-fips-install_{context}"]
-== Installing {op-system-base} in FIPS mode
-
-To install {op-system-base} with FIPS, follow the guidance in the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/assembly_installing-the-system-in-fips-mode_security-hardening[Installing the system in FIPS mode] of the {op-system-base} documentation.

modules/microshift-firewall-known-issue.adoc

@@ -6,4 +6,4 @@
 [id="microshift-firewall-known-issue_{context}"]
 = Known firewall issue
 
-* To avoid breaking traffic flows with a firewall reload or restart, execute firewall commands before starting {op-system}. The CNI driver in {microshift-short} makes use of iptable rules for some traffic flows, such as those using the NodePort service. The iptable rules are generated and inserted by the CNI driver, but are deleted when the firewall reloads or restarts. The absence of the iptable rules breaks traffic flows. If firewall commands have to be executed after {microshift-short} is running, manually restart `ovnkube-master` pod in the `openshift-ovn-kubernetes` namespace to reset the rules controlled by the CNI driver.
+* To avoid breaking traffic flows with a firewall reload or restart, execute firewall commands before starting {op-system-base-full}. The CNI driver in {microshift-short} makes use of iptable rules for some traffic flows, such as those using the NodePort service. The iptable rules are generated and inserted by the CNI driver, but are deleted when the firewall reloads or restarts. The absence of the iptable rules breaks traffic flows. If firewall commands have to be executed after {microshift-short} is running, manually restart `ovnkube-master` pod in the `openshift-ovn-kubernetes` namespace to reset the rules controlled by the CNI driver.