Updated lab index page to include information about the lab

content/modules/ROOT/pages/index.adoc

@@ -1,43 +1,21 @@
-= {lab_name}
+= Satellite: A Deep Dive into Troubleshooting
 
-The `lab_name` var, known as an asciidoc attribute, above was set in `./content/antora.yml` and can be used to set the lab_name or title of your content.
-You are both free to change its value and if you prefer to use a different var name, you can change the value of `lab_name`, for example to `title` in `./content/antora.yml` and then reference it in your content as `\{title}`. +
+In this hands-on troubleshooting lab we will troubleshoot common issues that are encountered in Red Hat Satellite deployments, identify and solve content and synchronization issues, fix client connectivity issues, and show how a Standard Operating Environment enhances the customer experience.
 
-image::rhel-logo-black.jpg[rhel-logo-black,55%,55%]
+This lab provides real-world scenarios to help you diagnose and resolve content synchronization, execution and client connectivity issues in Red Hat Satellite.
 
-== Variables
+.Key skills covered:
 
-Other vars can also be set there, such as `ssh_user` and `ssh_password`, and referenced inline in the lab content by using the `\{foo}` syntax.
+****
+Include:
+    - Validate and rectify issues with repositories and synchronization of Satellite and Capsules
+    - Tune Satellite server to resolve performance issues
+    - Troubleshoot client connectivity and registration
+    - Investigate Remote Execution failures
+****
 
-This is another var, or asciidoc attribute, from `./content/antora.yml` {my_var}
-
-== Writing your lab
-
-Whatever type of content you are writing we'll refer to your *content* as "your lab" in this document.
-
-=== Lab structure
-
-Wether you are writing a lab
-
-* First, we will build a monolithic application already compiled as RPM packages and put it into a container. This will allow us to deploy the application, copy it between machines, and update it separately from the operating system. This process affords us a portable and easily maintained component instead of tightly coupling the application with your operating system maintenance.
-
-* In closing we will build a second container on a different operating system version that makes an application not packaged into RPMs. This will be similar to a web application deployment, positioning the correct files at the right locations. To do this, we will pull a project from GitHub and position the component files within our container image. The purpose of this is to achieve a portable application container that can deploy on several different versions of Red Hat Enterprise Linux. This also provides the benefit of decoupling your application maintenance, which would all happen by building new containers versus operating system maintenance. The container is no longer reliant on the operating system installed on the machine where the application is deployed.
-
-. Now let's examine this cluster a bit more by describing the cluster (the `$GUID` environment variable is already set for you so you can immediately describe your individual cluster):
-+
-[source,sh,role=execute]
-----
-podman ps
-----
-+
-.Sample Output
-[source,texinfo,subs="attributes"]
-----
-CONTAINER ID  IMAGE                        COMMAND           CREATED      STATUS      PORTS                 NAMES
-2dcfee9e50c4  docker.io/library/httpd:2.4  httpd-foreground  3 hours ago  Up 3 hours  0.0.0.0:8080->80/tcp  showroom-httpd
-----
 
 === Lab Access
 
-The terminal window to your right is *already* logged into the lab environment as the `{ssh_user}` user via `ssh`. 
-All steps of this lab are to be completed as the `{ssh_user}` user.
+The terminal window to your right is *already* logged into the lab environment as the `{root}` user via `ssh`. 
+All steps of this lab on the Satellite server, Capsule server and clients are to be completed as the `{root}` user.