Merge pull request #2236 from heatmiser/rhdp_auto_satellite-exercises…

…-2025-02-06.01

rhdp_auto_satellite exercise updates 2025-02-06.01

exercises/rhdp_auto_satellite/1-compliance/README.md

@@ -55,7 +55,7 @@ Exercise
 
 Now we will start configuring a compliance policy that we can use to scan our RHEL nodes.
 
--   In the Satellite UI, click on the 'Hosts' dropdown menu pane on the left, then click on the 'Compliance' dropdown, followed by clicking on 'Policies'
+-   In the Satellite UI, click on the 'Hosts' dropdown menu pane on the left, then click on the 'Compliance' dropdown, followed by clicking on 'Policies'.
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_Policies.png)
 
@@ -65,25 +65,28 @@ Now we will start configuring a compliance policy that we can use to scan our RH
 
 #### 3\. Configuring a new compliance policy
 
-Now we will start configuring our Satellite server to be able to manage a compliance policy
+Now we will start configuring our Satellite server to be able to manage a compliance policy.
 
--   Select "Manual" from the deployment options and click "Next"
+-   Select "Manual" from the deployment options and click "Next".
+
+> **NOTE:**
+> There is an "Ansible" radio button selection, why aren't we using that? Selecting the "Ansible" radio button here would utilize the Ansible engine built into Satellite to execute the automation for the scan. In this case, we are going to be utilizing Ansible Automation Platform (AAP) to automate the execution of the OpenSCAP client scan on the managed host, providing the means to expand the capabilities of the scan, as well as providing for the expanded automation capabilites provided by AAP.
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP1.png)
 
--   Create the policy name "PCI_Compliance" and provide any description you like. Then click "Next"
+-   Create the policy name "PCI_Compliance" and provide any description you like. Then click "Next".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP2.png)
 
--   Select the "Red Hat rhel7 default content" and "PCI-DSS v4.0 Control Baseline for Red Hat Enterprise Linux 7". There is no tailoring file. Then click "Next"
+-   Select the "Red Hat rhel7 default content" and "PCI-DSS v4.0 Control Baseline for Red Hat Enterprise Linux 7". There is no tailoring file. Then click "Next".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP3.png)
 
--   It is necessary to set a schedule when creating a new compliance policy. You can select "Monthly" and "1" for Day of Month for the purposes of this exercise. Then click "Next"
+-   It is necessary to set a schedule when creating a new compliance policy. You can select "Monthly" and "1" for Day of Month for the purposes of this exercise. Then click "Next".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP4.png)
 
--   Steps 5, 6, and 7 as part of the New Compliance Policy can use default values. Click "Next" through "Locations", and "Organizations". For "Hostgroups" click "Submit"
+-   Steps 5, 6, and 7 as part of the New Compliance Policy can use default values. Click "Next" through "Locations", and "Organizations". For "Hostgroups" click "Submit".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP5.png)
 
@@ -105,7 +108,7 @@ Now we will start configuring our Satellite server to be able to manage a compli
 
 This step will allow us to scan a single RHEL 7 host with the ```PCI_Compliance``` policy that we configured on Satellite.
 
--   In Ansible Automation Platform click 'Templates' from the menu pane on the left side
+-   In Ansible Automation Platform click 'Templates' from the menu pane on the left side.
 
 -   Click the BLUE 'Add' drop-down icon and select 'Add job template' from the drop-down selection menu. Fill out the details as follows:
 
@@ -187,7 +190,7 @@ This step will allow us to scan a single RHEL 7 host with the ```PCI_Compliance`
 
 -   Click on the 'Full Report' button, under Actions, for 'node1.example.com' to see the report (This may take a few seconds). The Openscap Capsule field will reflect your workshop Satellite host.
 
--   Scroll down to the **Rule Overview** section. You can filter by "Pass", "Fail", "Fixed", or any number of qualifiers as well as group rules by "Severity"
+-   Scroll down to the **Rule Overview** section. You can filter by "Pass", "Fail", "Fixed", or any number of qualifiers as well as group rules by "Severity".
 
 ![aap_arf](images/1-compliance-aap2-Satellite_ARF.png)
 
@@ -210,23 +213,26 @@ Click "Activate to reveal" arrow next to the 'Remediation Ansible snippet', whic
 
 This step will expand our OpenSCAP policy scan to add another XCCDF compliance profile called ```STIG_Compliance```. We will also expand to include all systems in the 'RHEL7 Development' inventory by leaving the job run ```limit survey``` blank instead of specifying a single system.
 
--   In Satellite, hover over "Hosts" from the menu on the left side of the screen, and then click on "Policies".
+-   In the Satellite UI, click on the 'Hosts' dropdown menu pane on the left, then click on the 'Compliance' dropdown, followed by clicking on 'Policies'.
 
--   Click on the "New Compliance Policy" button
+-   Click on the "New Compliance Policy" button on the top right of the UI.
 
--   Select "Manual" from the deployment options and click "Next"
+-   Select "Manual" from the deployment options and click "Next".
+
+> **NOTE:**
+> Remember, selecting the "Ansible" radio button here would utilize the Ansible engine built into Satellite to execute the automation for the scan. We are going to be utilizing Ansible Automation Platform (AAP) to automate the execution of the OpenSCAP client scan on the managed host, so selecting "Manual" for the scap policy provides a means to integrate AAP for the scan automation.
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP6.png)
 
--   Create the policy name "STIG_Compliance" and provide any description you like. Then click "Next"
+-   Create the policy name "STIG_Compliance" and provide any description you like. Then click "Next".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP7.png)
 
--   Select the "Red Hat rhel7 default content" and "DISA STIG for Red Hat Enterprise Linux 7". There is no tailoring file. Then click "Next"
+-   Select the "Red Hat rhel7 default content" and "DISA STIG for Red Hat Enterprise Linux 7". There is no tailoring file. Then click "Next".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP8.png)
 
--   It is necessary to set a schedule when creating a new compliance policy. You can select "Monthly" and "1" for Day of Month for the purposes of this exercise. Then click "Next"
+-   It is necessary to set a schedule when creating a new compliance policy. You can select "Monthly" and "1" for Day of Month for the purposes of this exercise. Then click "Next".
 
 ![satellite_policy](images/1-compliance-aap2-Satellite_SCAP9.png)
 
@@ -240,7 +246,7 @@ This step will expand our OpenSCAP policy scan to add another XCCDF compliance p
 
 -   Now, we will update our OpenSCAP Scan job template in Ansible Automation Platform and run another PCI compliance scan, plus the STIG compliance scan.
 -   Navigate back to the Ansible Automation Platform UI and click 'Templates' from the left side pane menu
--   Select the OpenSCAP Scan job template, and click edit at the bottom of the template to modify the "Variables" section and add the ```STIG_Compliance``` policy to the ```policy_name``` list:
+-   Find the `SATELLITE / Compliance - OpenSCAP Scan` job template, and select it by clicking on the name of the job template. Next, click edit at the bottom of the template to modify the "Variables" section and add the ```STIG_Compliance``` policy to the ```policy_name``` list:
 
         Variables (Keep the exact spacing provided below.
         Note that the extra-vars that we are supplying need to be
@@ -253,6 +259,8 @@ This step will expand our OpenSCAP policy scan to add another XCCDF compliance p
 
 ![aap_template](images/1-compliance-aap2-template2-fix.png)
 
+-   Notice that we have listed the policy names, `PCI_Compliance` and `STIG_Compliance` exactly how we named the policies in the Satellite UI. By configuring the `policy_name` variable in this format, we are providing it as a list of the policies to utilize each time we execute this job template.
+
 -   Leave the rest of the fields blank or as they are, and click 'Save'. You can then select 'Launch' to deploy the job template.
 
 -   On the survey, leave the Limit field empty, as we are going to target all instances in the inventory group and click Next. For "Select inventory group", leave the default selection for "RHEL7_Dev" and click Next. Review the entries on the launch Preview and notice scrolling down confirms the entries made during the survey. Click "Launch".
@@ -268,7 +276,7 @@ This step will expand our OpenSCAP policy scan to add another XCCDF compliance p
 
 ![aap_arf](images/1-compliance-aap2-Satellite_ARF-Final.png)
 
--   Each report can be reviewed independent of other node scans and remediations for rule findings can be completed according to the requirements of your own internal policies.
+-   Each report can be reviewed independent of other node scans and automation remediations for rule findings can be compiled according to the requirements of internal organizational policies.
 
 #### 9\. End of Exercise
 

exercises/rhdp_auto_satellite/2-patching/README.md

@@ -130,16 +130,16 @@ Save and exit the workflow template editor by clicking on "Save" on the top righ
 
 #### 4\. Exploring the Satellite host configuration
 
-* In the Satellite UI on the left menu pane, hover over 'Hosts' and select 'Content Hosts'.
+* In the Satellite UI on the left menu pane, click on 'Hosts' and then select 'Content Hosts'.
     * Observe the multiple security, bug fix, enhancements and package updates available for each server, which will vary depending on the date of when the workshop takes place.
     * Further, take note of the life cycle environment: RHEL7_Dev.
 
 ![Satellite content hosts](images/2-patching-aap2-Satellite-contenthosts.png)
 
-* In the Satellite UI on the left menu pane, navigate to 'Content' and select 'Content Views'.
+* In the Satellite UI on the left menu pane, click on 'Content', followed by clicking on 'Lifecycle', and then select 'Content Views'.
     * Since the servers that we are working with are RHEL7 select the 'RHEL7' content view.
     * We may need to publish a new content view version, however, we set that up as part of our workflow!
-    * Note: your content view version may differ from this example, that is OK
+    * Note: your content view version may differ from this example, that is OK.
 
 ![Satellite RHEL7 CV](images/2-patching-aap-Satellite-CV-RHEL7.png)
 
@@ -149,7 +149,7 @@ Save and exit the workflow template editor by clicking on "Save" on the top righ
 
 #### 5\. Navigate back to Ansible Automation Platform and launch workflow job
 
-* Click on Templates to locate the 'SATELLITE / Patching Workflow' template.
+* Click on Templates and locate the 'SATELLITE / Patching Workflow' template.
     * You can either click on the rocketship to the right of the template or select the template and select LAUNCH. (they do the same thing).
 * Observe the job kicking off in Ansible.
     * You need to wait for this workflow to complete before moving on to the next step.
@@ -161,7 +161,7 @@ Save and exit the workflow template editor by clicking on "Save" on the top righ
 
 #### 6\. Navigate back to Satellite to examine automation effects
 
-* In the Satellite UI on the left menu pane, navigate to 'Content' then 'Content Views' and select RHEL7.
+* In the Satellite UI on the left menu pane, navigate to 'Content', then 'Lifecycle', then 'Content Views' and select RHEL7.
     * Notice the new content view version.
 * In the Satellite UI on the left menu pane, navigate to  Hosts > All Hosts and select node1.example.com.
     * Select the 'content' tab under Details.
@@ -172,8 +172,8 @@ Save and exit the workflow template editor by clicking on "Save" on the top righ
 
 * You may notice that not all issues are remediated.
     * This is to showcase that you can exclude updates based on type.
-    * In this case we're not pushing out updates for kernel changes.
-    * Of course this can be configurable through use of the exclude definition for ```ansible.builtin.yum``` module in the server_patch.yml playbook.
+    * In this case, we are not pushing out updates for kernel changes.
+    * Of course, this can be configurable through use of the exclude definition for ```ansible.builtin.yum``` module in the server_patch.yml playbook.
 
 ![kernel patches excluded](images/2-patching-aap2-server-patching-kernel-exclude.png)
 

exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md

@@ -27,16 +27,16 @@
 
 The workshop is provisioned with a pre-configured lab environment. You will have access to a host deployed with Ansible Automation Platform (AAP) which you will use to control the playbook and workflow jobs that automate the CentOS conversion workflow steps. You will also have access to three CentOS hosts. These are the hosts where we will be converting the CentOS operating system (OS) to Red Hat Enterprise Linux.
 
-| Role                                | Inventory name |
-| ------------------------------------| ---------------|
-| Automation controller               | ansible-1      |
-| Satellite Server                    | satellite      |
-| Managed Host 1 - RHEL               | node1          |
-| Managed Host 2 - RHEL               | node2          |
-| Managed Host 3 - RHEL               | node3          |
-| Managed Host 4 - CentOS/OracleLinux | node4          |
-| Managed Host 5 - CentOS/OracleLinux | node5          |
-| Managed Host 6 - CentOS/OracleLinux | node6          |
+| Role                                   | Inventory name |
+| ---------------------------------------| ---------------|
+| Ansible Automation Platform controller | ansible-1      |
+| Satellite Server                       | satellite      |
+| Managed Host 1 - RHEL                  | node1          |
+| Managed Host 2 - RHEL                  | node2          |
+| Managed Host 3 - RHEL                  | node3          |
+| Managed Host 4 - CentOS/OracleLinux    | node4          |
+| Managed Host 5 - CentOS/OracleLinux    | node5          |
+| Managed Host 6 - CentOS/OracleLinux    | node6          |
 
 ### Step 1 - Access the AAP Web UI
 
@@ -48,7 +48,7 @@ The AAP Web UI is where we will go to submit and check the status of the Ansible
 
 - Enter the username `admin` and the password provided. This will bring you to your AAP Web UI dashboard like the example below:
 
-  ![Example AAP Web UI dashboard](images/aap_console_example.svg)
+  ![Example AAP Web UI dashboard](images/aap_console_example.png)
 
 - Let's use the AAP Web UI to make a couple of preparations for the exercise. First, let's ensure our CentOS nodes are up and running. In the AAP Web UI browser tab, navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. Browse the list of job templates and click on the template `EC2 / Instance action`: