Red Hat Satellite 6 Administration

Instructions

1. Copy the Foreman SSH keys from each Capsule Server to the content host that is the remote execution target.

   Important

   Satellite Server can delegate any Capsule Server that is authorized to provide remote execution to content hosts in managed locations. Copy the required Foreman SSH public keys from each authorized Capsule Server, including the integrated Capsule Server on the Satellite Server, to each content host that can be a remote execution target.

   1. Log in to the capsule system as the student user and switch to the root user.

      [student@workstation ~]$ ssh student@capsule
      [student@capsule ~]$ sudo -i
      [sudo] password for student: student
      [root@capsule ~]#

   2. Copy the Capsule Server's Foreman SSH public key to the servera content host. Find the public key in the foreman-proxy user's SSH configuration on the capsule system.

      [root@capsule ~]# ls ~foreman-proxy/.ssh/
      id_rsa_foreman_proxy  id_rsa_foreman_proxy.pub
      [root@capsule ~]# ssh-copy-id -i \
      ~foreman-proxy/.ssh/id_rsa_foreman_proxy.pub \
      root@servera.lab.example.com
      ...output omitted...
      Are you sure you want to continue connecting (yes/no)? yes
      ...output omitted...
      root@servera.lab.example.com's password: redhat
      
      Number of key(s) added: 1
      ...output omitted...

   3. Use the foreman-proxy identity to test the root@servera account for passwordless access from the capsule system. If the public key was successfully copied, then you can access the account without a password prompt. You might still be prompted to establish the authenticity of the remote host by continuing to connect. If you are prompted for a password, then diagnose and fix the issue.

      [root@capsule ~]# ssh -i ~foreman-proxy/.ssh/id_rsa_foreman_proxy root@servera
      ...output omitted...
      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      ...output omitted...
      [root@servera ~]#

   4. Return to the workstation system as the student user. Log in to the satellite server as the student user and switch to the root user.

      [root@servera ~]# exit
      logout
      [root@capsule ~]# exit
      logout
      [student@capsule ~]$ exit
      logout
      [student@workstation ~]$ ssh student@satellite
      [student@satellite ~]$ sudo -i
      [sudo] password for student: student
      [root@satellite ~]#

   5. Copy the Satellite Server's Foreman SSH public key to the servera content host. Find the public key in the foreman-proxy user's SSH configuration on the satellite system.

      Important

      The ssh-copy-id command might warn that "All keys were skipped because they already exist on the remote system." You can safely skip this ssh-copy-id step, because the public key was copied in a previous exercise.

      [root@satellite ~]# ls ~foreman-proxy/.ssh/
      id_rsa_foreman_proxy  id_rsa_foreman_proxy.pub
      [root@satellite ~]# ssh-copy-id -i \
      ~foreman-proxy/.ssh/id_rsa_foreman_proxy.pub \
      root@servera.lab.example.com
      ...output omitted...
      Are you sure you want to continue connecting (yes/no)? yes
      ...output omitted...
      root@servera.lab.example.com's password: redhat
      
      Number of key(s) added: 1
      ...output omitted...

   6. Use the foreman-proxy identity to test the root@servera account for passwordless access from the satellite system. If the public key was successfully copied, then you can access the account without a password prompt. You might still be prompted to establish the authenticity of the remote host by continuing to connect. If you are prompted for a password, then diagnose and fix the issue.

      [root@satellite ~]# ssh -i ~foreman-proxy/.ssh/id_rsa_foreman_proxy root@servera
      ...output omitted...
      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      ...output omitted...
      [root@servera ~]#

   7. Exit the servera system, but keep open the terminal on the satellite system.

      [root@servera ~]# exit
      logout
      [root@satellite ~]#

2. Log in to the Satellite Server web UI, https://satellite.lab.example.com, as the admin user with redhat as the password.

3. In the upper-left corner of the web page, set the organization to Operations. Set the location to Any Location.

4. From the Satellite web UI, run an ad hoc command remotely on the servera system.

   1. Click Hosts → All Hosts, and then click servera.lab.example.com. Click Schedule Remote Job.

   2. Select Commands in the Job category field. Select Run Command - SSH Default in the Job template field. Enter uptime; hostname; whoami in the command field. Select Execute now from the Schedule choices. Click Submit.

   3. On the Overview tab, monitor the remote execution status. Wait for the process to complete. To view the remote command output, scroll down and click the servera.lab.example.com link. Your results should be similar to the following output.

      1: 04:03:39 up 33 min, 1 user, load average: 0.08, 0.02, 0.01
      2: servera.lab.example.com
      3: root
      4: Exit status: 0

5. Using the hammer command, run the same commands as a remote execution job from the satellite server.

   1. Using the terminal open on the satellite system, create a remote job for the ad hoc commands. Because the default schedule is Execute now, the job runs immediately.

      [root@satellite ~]# hammer job-invocation create \
      --job-template "Run Command - SSH Default" \
      --search-query "name = servera.lab.example.com" \
      --inputs command="uptime; hostname; whoami"
      Job invocation 2 created
      [....................................................................] [100%]
      1 task(s), 1 success, 0 fail

   2. View the remote job output. Set the job ID value from the previous command.

      [root@satellite ~]# hammer job-invocation output \
      --id 2 --host servera.lab.example.com
       04:10:51 up 40 min, 1 user, load average: 0.00, 0.00, 0.00
      servera.lab.example.com
      root
      Exit status: 0

6. From the Satellite web UI, run a remote Ansible ad hoc command on the servera system.

   1. Click Hosts → All Hosts, and then click the servera.lab.example.com link. Click Schedule Remote Job.

   2. Select Ansible Commands in the Job category field. Select Run Command - Ansible Default in the Job template field. Enter df -h in the command field. Select Execute now from the Schedule choices. Click Submit.

   3. On the Overview tab, monitor the remote execution status. Wait for the process to complete. To view the remote command output, scroll down and click the servera.lab.example.com link. Your results should be similar to the following output.

      ...output omitted...
      TASK [debug] **************************************
      ok: [servera.lab.example.com] => {
          "out": {
              "changed": true,
              "cmd": "df -h\n",
              "delta": "0:00:00.008262",
      ...output omitted...

7. Using the hammer command, run the same Ansible commands as a remote execution job from the satellite server.

   1. Using the terminal that is open on the satellite system, create a remote job for the ad hoc commands. Because the default schedule is Execute now, the job runs immediately.

      [root@satellite ~]# hammer job-invocation create \
      --job-template "Run Command - Ansible Default" \
      --search-query "name = servera.lab.example.com" \
      --inputs command="df -h"
      Job invocation 4 created
      ...output omitted...
      TASK [debug] **************************************
      ok: [servera.lab.example.com] => {
          "out": {
              "changed": true,
              "cmd": "df -h\n",
              "delta": "0:00:00.008262",
      ...output omitted...

   2. View the remote job output. Set the job ID value from the previous command.

      [root@satellite ~]# hammer job-invocation output \
      --id 4 --host servera.lab.example.com
      ...output omitted...

8. Create a job template with the playbook-example.yml Ansible Playbook from the student home directory on workstation. The playbook replaces a default system banner with a custom message.

   1. Click Hosts → Job templates, and then click New Job Template. Enter My new custom banner in the Name field.

   2. On the Template tab, in the upper-right corner of the Editor tool, click Import File. Select the /home/student/playbook-example.yml file, and then click Open.

   3. Click the Inputs tab, and then click Add Input. The playbook expects you to create a banner_var variable that contains your custom message at job invocation. Enter banner_var in the Name field.

   4. Click the Job tab. In the Job Category field, clear the existing entry, and then select Ansible Playbook from the list. Select Ansible in the Provider Type field. Click Submit to save the job template.

9. Use the My new custom banner job template to run a remote execution job to customize the banner on the servera system.

   1. Click Hosts → All Hosts, and then click the servera.lab.example.com link. Click Schedule Remote Job.

   2. Select Ansible Playbook in the Job category field. Select My new custom banner in the Job template field. Enter Welcome to my new customized server in the banner_var field. Click Submit.

   3. On the Overview tab, monitor the remote execution status. Wait for the process to complete. To view the remote command output, scroll down and click the servera.lab.example.com link. View the Ansible Playbook execution output.

   4. Return to the workstation system as the student user. Log in to the servera system as the student user to view the custom banner. When complete, return to the workstation system as the student user.

      [root@satellite ~]# exit
      logout
      [student@satellite ~]$ exit
      logout
      [student@workstation ~]$ ssh student@servera
      Welcome to my new customized server
      ...output omitted...
      [student@servera ~]$ exit
      logout
      [student@satellite ~]$