RH294 - ch09s06

Bookmark this page

Guided Exercise: Managing the Boot Process and Scheduled Processes

In this exercise, you will manage the startup process, schedule recurring jobs, and reboot managed hosts.

Outcomes

You should be able to use a playbook to:

Schedule a cron job.
Remove a single specific cron job from a crontab file.
Schedule an at task.
Set the default boot target on managed hosts.
Reboot managed hosts.

Run the lab system-process start script from workstation to configure the environment for the exercise. The script creates the system-process working directory, and downloads the Ansible configuration file and the host inventory file needed for the exercise.

[student@workstation ~]$ lab system-process start

Procedure 9.3. Instructions

As the student user on workstation, change to the /home/student/system-process working directory.
```
[student@workstation ~]$ cd ~/system-process
[student@workstation system-process]$
```
Create a playbook, create_crontab_file.yml, in the current working directory. Configure the playbook to use the cron module to create the /etc/cron.d/add-date-time crontab file that schedules a recurring cron job. The job should run as the devops user every two minutes between 09:00 and 16:59 on Monday through Friday. The job should append the current date and time to the file /home/devops/my_datetime_cron_job
1. Create a new playbook, create_crontab_file.yml, and add the lines needed to start the play. It should target the managed hosts in the webservers group and enable privilege escalation.
```
---
- name: Recurring cron job
  hosts: webservers
  become: true
```
2. Define a task that uses the cron module to schedule a recurring cron job.
  Note
  The cron module provides a name option to uniquely describe the crontab file entry and to ensure expected results. The description is added to the crontab file. For example, the name option is required if you are removing a crontab entry using state=absent. Additionally, the name option prevents a new crontab entry from always being created when the default state, state=present, is set.
```
  tasks:
    - name: Crontab file exists
      cron:
        name: Add date and time to a file
```
3. Configure the job to run every two minutes between 09:00 and 16:59 on Monday through Friday.
```
        minute: "*/2"
        hour: 9-16
        weekday: 1-5
```
4. Use the cron_file parameter to use the /etc/cron.d/add-date-time crontab file instead of an individual user's crontab in /var/spool/cron/. A relative path will place the file in /etc/cron.d directory. If the cron_file parameter is used, you must also specify the user parameter.
```
        user: devops
        job: date >> /home/devops/my_date_time_cron_job
        cron_file: add-date-time
        state: present
```
5. When completed, the playbook should appear as follows. Review the playbook for accuracy.
```
---
- name: Recurring cron job
  hosts: webservers
  become: true

  tasks:
    - name: Crontab file exists
      cron:
        name: Add date and time to a file
        minute: "*/2"
        hour: 9-16
        weekday: 1-5
        user: devops
        job: date >> /home/devops/my_date_time_cron_job
        cron_file: add-date-time
        state: present
```
6. Verify playbook syntax by running the ansible-playbook --syntax-check create_crontab_file.yml command. Correct any errors before moving to the next step.
```
[student@workstation system-process]$ ansible-playbook --syntax-check \
> create_crontab_file.yml

playbook: create_crontab_file.yml
```
7. Run the playbook.
```
[student@workstation system-process]$ ansible-playbook create_crontab_file.yml

PLAY [Recurring cron job] *************************************************

TASK [Gathering Facts] ****************************************************
ok: [servera.lab.example.com]

TASK [Crontab file exists] ************************************************
changed: [servera.lab.example.com]

PLAY RECAP ****************************************************************
servera.lab.example.com    : ok=2    changed=1    unreachable=0    failed=0
```
8. Run an ad hoc command to verify that the /etc/cron.d/add-date-time cron file exists and its content is correct.
```
[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "cat /etc/cron.d/add-date-time"
servera.lab.example.com | CHANGED | rc=0 >>
#Ansible: Add date and time to a file
*/2 9-16 * * 1-5 devops date >> /home/devops/my_date_time_cron_job
```

Create a playbook, remove_cron_job.yml, in the current working directory. Configure the playbook to use the cron module to remove the Add date and time to a file cron job from the /etc/cron.d/add-date-time crontab file

Create a new playbook, remove_cron_job.yml, and add the following lines:

---
- name: Remove scheduled cron job
  hosts: webservers
  become: true

  tasks:
    - name: Cron job removed
      cron:
        name: Add date and time to a file
        user: devops
        cron_file: add-date-time
        state: absent

Verify playbook syntax by running the ansible-playbook --syntax-check remove_cron_job.yml command. Correct any errors before moving to the next step.
```
[student@workstation system-process]$ ansible-playbook --syntax-check \
> remove_cron_job.yml

playbook: remove_cron_job.yml
```

Run the playbook.

[student@workstation system-process]$ ansible-playbook remove_cron_job.yml

PLAY [Remove scheduled cron job] ******************************************

TASK [Gathering Facts] ****************************************************
ok: [servera.lab.example.com]

TASK [Cron job removed] ***************************************************
changed: [servera.lab.example.com]

PLAY RECAP ****************************************************************
servera.lab.example.com    : ok=2    changed=1    unreachable=0    failed=0

Run an ad hoc command to verify that the /etc/cron.d/add-date-time cron file continues to exist but the cron job has been removed.

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "cat /etc/cron.d/add-date-time"
servera.lab.example.com | CHANGED | rc=0 >>

Create a playbook, schedule_at_task.yml, in the current working directory. Configure the playbook to use the at module to schedule a task that runs one minute in the future. The task should run the date command and redirect its output to the /home/devops/my_at_date_time file. Use the unique: yes option to ensure that if the command already exists in the at queue, a new task is not added.

Create a new playbook, schedule_at_task.yml, and add the following lines:

---
- name: Schedule at task
  hosts: webservers
  become: true
  become_user: devops

  tasks:
    - name: Create date and time file
      at:
        command: "date > ~/my_at_date_time\n"
        count: 1
        units: minutes
        unique: yes
        state: present

Verify playbook syntax by running the ansible-playbook -syntax-check schedule_at_task.yml command. Correct any errors before moving to the next step.
```
[student@workstation system-process]$ ansible-playbook --syntax-check \
> schedule_at_task.yml

playbook: schedule_at_task.yml
```

Run the playbook.

[student@workstation system-process]$ ansible-playbook schedule_at_task.yml

PLAY [Schedule at task] ***************************************************

TASK [Gathering Facts] ****************************************************
ok: [servera.lab.example.com]

TASK [Create date and time file] ******************************************
changed: [servera.lab.example.com]

PLAY RECAP ****************************************************************
servera.lab.example.com    : ok=2    changed=1    unreachable=0    failed=0

After waiting one minute for the at command to complete, run ad hoc commands to verify that the /home/devops/my_at_date_time file exists and has the correct contents.

[student@workstation system-process]$ ansible webservers -u devops \
> -a "ls -l my_at_date_time"
servera.lab.example.com | CHANGED | rc=0 >>
-rw-rw-r--. 1 devops devops 30 abr 17 06:15 my_at_date_time

[student@workstation system-process]$ ansible webservers -u devops \
> -a "cat my_at_date_time"
servera.lab.example.com | CHANGED | rc=0 >>
Thu Jul 22 13:24:34 PDT 2021

Create a playbook, set_default_boot_target_graphical.yml, in the current working directory. Configure the playbook to use the file module to change the symbolic link on managed hosts to reference the graphical-target boot target.

Note

In the following file module, the src parameter value is what the symbolic link references. The dest parameter value is the symbolic link.

Create a new playbook, set_default_boot_target_graphical.yml, and add the following lines:

---
- name: Change default boot target
  hosts: webservers
  become: true

  tasks:
    - name: Default boot target is graphical
      file:
        src: /usr/lib/systemd/system/graphical.target
        dest: /etc/systemd/system/default.target
        state: link

Verify the playbook syntax by running the ansible-playbook --syntax-check set_default_boot_target_graphical.yml command. Correct any errors before moving to the next step.
```
[student@workstation system-process]$ ansible-playbook --syntax-check \
> set_default_boot_target_graphical.yml

playbook: set_default_boot_target_graphical.yml
```

Before running the playbook, run an ad hoc command to verify that the current default boot target is multi-user.target:

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "systemctl get-default"
servera.lab.example.com | CHANGED | rc=0 >>
multi-user.target

Run the playbook.

[student@workstation system-process]$ ansible-playbook \
> set_default_boot_target_graphical.yml

PLAY [Change default boot target] *****************************************

TASK [Gathering Facts] ****************************************************
ok: [servera.lab.example.com]

TASK [Default boot target is graphical] ***********************************
changed: [servera.lab.example.com]

PLAY RECAP ****************************************************************
servera.lab.example.com    : ok=2    changed=1    unreachable=0    failed=0

Run an ad hoc command to verify that the default boot target is now graphical.target.

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "systemctl get-default"
servera.lab.example.com | CHANGED | rc=0 >>
graphical.target

Create a playbook, reboot_hosts.yml, in the current working directory that reboots the managed hosts. It is not required to reboot a server after changing the default target. However, knowing how to create a playbook that reboots managed hosts may prove useful.

Create a new playbook, reboot_hosts.yml, and add the following lines:

---
- name: Reboot hosts
  hosts: webservers
  become: true

  tasks:
    - name: Hosts are rebooted
      reboot:

Verify the playbook syntax by running the ansible-playbook --syntax-check reboot_hosts.yml command. Correct any errors before moving to the next step.
```
[student@workstation system-process]$ ansible-playbook --syntax-check \
> reboot_hosts.yml

playbook: reboot_hosts.yml
```

Before running the playbook, run an ad hoc command to determine the timestamp of the last system reboot.

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "who -b"
servera.lab.example.com | CHANGED | rc=0 >>
         system boot  2021-07-22 14:34

Run the playbook.

[student@workstation system-process]$ ansible-playbook reboot_hosts.yml

PLAY [Reboot hosts] *******************************************************

TASK [Gathering Facts] ****************************************************
ok: [servera.lab.example.com]

TASK [Hosts are rebooted] *************************************************
changed: [servera.lab.example.com]

PLAY RECAP ****************************************************************
servera.lab.example.com    : ok=2    changed=1    unreachable=0    failed=0

Run an ad hoc command to determine the timestamp of the last system reboot. The timestamp displayed after the playbook runs should be later.

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "who -b"
servera.lab.example.com | CHANGED | rc=0 >>
         system boot  2021-07-22 14:52

Run a second ad hoc command to determine that the graphical.target boot target survived the reboot.

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "systemctl get-default"
servera.lab.example.com | CHANGED | rc=0 >>
graphical.target

To maintain consistency throughout the remaining exercises, change the default boot target back to its former setting, multi-user.target. Create a playbook, set_default_boot_target_multi-user.yml, in the current working directory. Configure the playbook to use the file module to change the symbolic link on managed hosts to reference the multi-user.target boot target.

Create a new playbook, set_default_boot_target_multi-user.yml, and add the following lines:

---
- name: Change default runlevel target
  hosts: webservers
  become: true

  tasks:
    - name: Default runlevel is multi-user target
      file:
        src: /usr/lib/systemd/system/multi-user.target
        dest: /etc/systemd/system/default.target
        state: link

Verify playbook syntax by running the ansible-playbook --syntax-check set_default_boot_target_multi-user.yml command. Correct any errors before moving to the next step.

[student@workstation system-process]$ ansible-playbook --syntax-check \
> set_default_boot_target_multi-user.yml

playbook: set_default_boot_target_multi-user.yml

Run the playbook.

[student@workstation system-process]$ ansible-playbook \
> set_default_boot_target_multi-user.yml

PLAY [Change default runlevel target] *************************************

TASK [Gathering Facts] ****************************************************
ok: [servera.lab.example.com]

TASK [Default runlevel is multi-user target] ******************************
changed: [servera.lab.example.com]

PLAY RECAP ****************************************************************
servera.lab.example.com    : ok=2    changed=1    unreachable=0    failed=0

Run an ad hoc command to verify that the default boot target is now multi-user.target.

[student@workstation system-process]$ ansible webservers -u devops -b \
> -a "systemctl get-default"
servera.lab.example.com | CHANGED | rc=0 >>
multi-user.target

Finish

On workstation, run the lab system-process finish script to clean up this exercise.

[student@workstation ~]$ lab system-process finish

This concludes the guided exercise.

Discuss Red Hat Enterprise Linux Automation with Ansible

Go to community

Red Hat Linux Automation with Ansible (RH294)

Haley_Ruccio

24 lip 2023

Learn how to automate Linux system administration tasks with Red Hat Ansible Automation PlatformRed Hat Enterprise Linux Automation with Ansible (RH294) is designed for Linux administrators and developers who need to automate repeatable and error-prone steps for system provisioning, configuration, application deployment, and orchestration. This course is based on Red Hat® Enterprise Linux® 9 and Red Hat Ansible Automation Platform 2.2.Course content summaryInstall Red Hat Ansible Automation Platform on control nodes.Create and update inventories of managed hosts and manage connections to them.Automate administration tasks with Ansible Playbooks and ad hoc commands.Write effective playbooks at scale.Protect sensitive data used by Ansible Automation Platform with Ansible Vault.Reuse code and simplify playbook development with Ansible Roles and Ansible Content Collections.Audience for this courseThis course is geared toward Linux system administrators, DevOps engineers, infrastructure automation engineers, and systems design engineers who are responsible for these tasks:Automating configuration managementEnsuring consistent and repeatable application deploymentProvisioning and deployment of development, testing, and production serversIntegrating with DevOps continuous integration/continuous delivery workflowsPrerequisites for this coursePass the Red Hat Certified System Administrator (RHCSA) exam (EX200), or demonstrate equivalent Red Hat Enterprise Linux knowledge and experience.Take our free assessment to gauge whether this offering is the best fit for your skills.

980

curl finds no route to host?

TPeters

23 lip 2023

I am doing the self-paced course RH294 . With two exercises (Ch.3 final Lab and Ch.4 lab exercise 2) I ran into this problem:after installing and starting a web service, from the classroom web termicaI I cannot reach servera.lab.example.com with curl: "No route to host". This despite the fact that I can ping it, open a shell to it, and install the package on it with Ansible.Anyone else have the same problem?What might be the cause?

1702

Welcome to the Red Hat Linux Automation with Ansible (RH294) group in the Red Hat Learning Community

cschunke

18 lip 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Linux Automation with Ansible! To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH294.Read more about Red Hat Linux Automation with Ansible here.

351

Revision: rh294-8.4-9cb53f0