RH294 - ch09s06

Bookmark this page

Guided Exercise: Managing the Boot Process and Scheduled Processes

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

Outcomes

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.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command prepares your environment and ensures that all required resources are available, including the /home/student/system-process project directory.

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

Procedure 9.3. Instructions

Change into the /home/student/system-process directory.

[student@workstation ~]$ cd ~/system-process
[student@workstation system-process]$

Create the create_crontab_file.yml playbook in the working directory.
Configure the playbook to use the ansible.builtin.cron module to create a crontab file named /etc/cron.d/add-date-time that schedules a recurring Cron job. The job should run as the devops user every two minutes starting at 09:00 and ending at 16:59 from Monday through Friday. The job should append the current date and time to the /home/devops/my_datetime_cron_job file.
1. Create the create_crontab_file.yml playbook 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 ansible.builtin.cron module to schedule a recurring Cron job, the date >> /home/devops/my_date_time_cron_job command.
  Note
  The ansible.builtin.cron module provides a name option to uniquely describe the crontab file entry and to ensure expected results.
  The value you use for the name option is added to the crontab file as a comment. 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
      ansible.builtin.cron:
        name: Add date and time to a file
        job: date >> /home/devops/my_date_time_cron_job
```
3. Configure the job to run every two minutes starting at 09:00 and ending at 16:59 on Monday through Friday.
```
        minute: "*/2"
        hour: 9-16
        weekday: 1-5
```
4. Use the cron_file parameter to use the crontab file named /etc/cron.d/add-date-time instead of an individual user's crontab in /var/spool/cron/.
  A relative path places the file in the /etc/cron.d directory.
  If the cron_file parameter is used, you must also specify the user parameter for the system crontab file. Use the devops user for this job.
```
        user: devops
        cron_file: add-date-time
        state: present
```
5. When completed, the playbook must appear as follows. Review the playbook for accuracy.
```
---
- name: Recurring cron job
  hosts: webservers
  become: true

  tasks:
    - name: Crontab file exists
      ansible.builtin.cron:
        name: Add date and time to a file
        job: date >> /home/devops/my_date_time_cron_job
        minute: "*/2"
        hour: 9-16
        weekday: 1-5
        user: devops
        cron_file: add-date-time
        state: present
```
6. Run the ansible-navigator run --syntax-check command to verify the playbook syntax. Correct any errors before moving to the next step.
```
[student@workstation system-process]$ ansible-navigator run \
> -m stdout create_crontab_file.yml --syntax-check
playbook: /home/student/system-process/create_crontab_file.yml
```
7. Run the create_crontab_file.yml playbook.
```
[student@workstation system-process]$ ansible-navigator run \
> -m stdout 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    skipped=0    rescued=0    ignored=0
```
8. Run the following command to verify that the /etc/cron.d/add-date-time cron file exists, and its content is correct.
```
[student@workstation system-process]$ ssh devops@servera \
> "cat /etc/cron.d/add-date-time"
#Ansible: Add date and time to a file
*/2 9-16 * * 1-5 devops date >> /home/devops/my_date_time_cron_job
```

Create the remove_cron_job.yml playbook in the working directory. Configure the playbook to use the ansible.builtin.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 the remove_cron_job.yml playbook and add the following lines:

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

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

Run the ansible-navigator run --syntax-check command to verify the playbook syntax. Correct any errors before moving to the next step.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout remove_cron_job.yml --syntax-check
playbook: /home/student/system-process/remove_cron_job.yml

Run the remove_cron_job.yml playbook.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout 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    skipped=0    rescued=0    ignored=0

Run the following command to verify that the /etc/cron.d/add-date-time file has been removed.

[student@workstation system-process]$ ssh devops@servera \
> "ls -l /etc/cron.d"
total 4
-rw-r--r--. 1 root root 128 Aug  9  2021 0hourly

Create the schedule_at_task.yml playbook in the working directory. Configure the playbook to use the ansible.posix.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 the schedule_at_task.yml playbook and add the following lines:

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

  tasks:
    - name: Create date and time file
      ansible.posix.at:
        command: date > ~/my_at_date_time
        count: 1
        units: minutes
        unique: yes
        state: present

Run the ansible-navigator run --syntax-check command to verify the playbook syntax. Correct any errors before moving to the next step.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout schedule_at_task.yml --syntax-check
playbook: /home/student/system-process/schedule_at_task.yml

Run the schedule_at_task.yml playbook.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout 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    skipped=0    rescued=0    ignored=0

After waiting a minute or two for the at command to complete, run the following commands to verify that the /home/devops/my_at_date_time file exists and has the correct contents.

[student@workstation system-process]$ ssh devops@servera \
> "ls -l my_at_date_time"
-rw-rw-r--. 1 devops devops 32 Aug 15 00:00 my_at_date_time

[student@workstation system-process]$ ssh devops@servera \
> "cat my_at_date_time"
Mon Aug 15 12:00:00 AM EDT 2022

Create the set_default_boot_target_graphical.yml playbook in the working directory. Write a play in the playbook to set the default systemd target to graphical.target.

Create the set_default_boot_target_graphical.yml playbook and add the following lines:

---
- name: Change default boot target
  hosts: webservers
  become: true
  gather_facts: false
  vars:
    default_target: "graphical.target"

  tasks:
    - name: Get current boot target
      ansible.builtin.command:
        cmd: systemctl get-default
      changed_when: false
      register: target

    - name: Set default boot target
      ansible.builtin.command:
        cmd: systemctl set-default {{ default_target }}
      when: default_target not in target['stdout']

Run the ansible-navigator run --syntax-check command to verify the playbook syntax. Correct any errors before moving to the next step.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout set_default_boot_target_graphical.yml --syntax-check
playbook: /home/student/system-process/set_default_boot_target_graphical.yml

Before running the playbook, run the following command to verify that the current default boot target is multi-user.target.
```
[student@workstation system-process]$ ssh devops@servera \
> "systemctl get-default"
multi-user.target
```

Run the set_default_boot_target_graphical.yml playbook.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout set_default_boot_target_graphical.yml

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

TASK [Get current boot target] ********************************************
ok: [servera.lab.example.com]

TASK [Set default boot target] ********************************************
changed: [servera.lab.example.com]

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

Run the following command to verify that the default boot target is now graphical.target.

[student@workstation system-process]$ ssh devops@servera \
> "systemctl get-default"
graphical.target

Create the reboot_hosts.yml playbook in the working directory to reboot the managed hosts.

Create the reboot_hosts.yml playbook and add the following lines:

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

  tasks:
    - name: Hosts are rebooted
      ansible.builtin.reboot:

Run the ansible-navigator run --syntax-check command to verify the playbook syntax. Correct any errors before moving to the next step.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout reboot_hosts.yml --syntax-check
playbook: /home/student/system-process/reboot_hosts.yml

Before running the playbook, run the following command to determine the time stamp of the last system reboot:

[student@workstation system-process]$ ssh devops@servera \
> "who -b"
         system boot  2022-08-15 00:07

Run the reboot_hosts.yml playbook.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout 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    skipped=0    rescued=0    ignored=0

Run the following command to determine the time stamp of the last system boot. The time stamp displayed after the playbook runs should be later.
```
[student@workstation system-process]$ ssh devops@servera \
> "who -b"
         system boot  2022-08-15 00:44
```
Run this next command to determine that the graphical.target boot target is still the default after the reboot.
```
[student@workstation system-process]$ ssh devops@servera \
> "systemctl get-default"
graphical.target
```

To maintain consistency throughout the remaining exercises, change the default boot target back to its former setting, multi-user.target.

Copy your set_default_boot_target_graphical.yml playbook to set_default_boot_target_multi-user.yml in the Ansible project directory.

Edit the default_target variable to set multi-user.target as the default.

Copy your set_default_boot_target_graphical.yml playbook to set_default_boot_target_multi-user.yml.

[student@workstation system-process]$ cp set_default_boot_target_graphical.yml \
> set_default_boot_target_multi-user.yml

Edit the play in the set_default_boot_target_multi-user.yml playbook to change the default_target variable to multi-user.target.

---
- name: Change default boot target
  hosts: webservers
  become: true
  gather_facts: false
  vars:
    default_target: "multi-user.target"

  tasks:
    - name: Get current boot target
      ansible.builtin.command:
        cmd: systemctl get-default
      changed_when: false
      register: target

    - name: Set default boot target
      ansible.builtin.command:
        cmd: systemctl set-default {{ default_target }}
      when: default_target not in target['stdout']

Run the ansible-navigator run --syntax-check command to verify the playbook syntax. Correct any errors before moving to the next step.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout set_default_boot_target_multi-user.yml --syntax-check
playbook: /home/student/system-process/set_default_boot_target_multi-user.yml

Run the set_default_boot_target_multi-user.yml playbook.

[student@workstation system-process]$ ansible-navigator run \
> -m stdout set_default_boot_target_multi-user.yml

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

TASK [Get current boot target] ********************************************
ok: [servera.lab.example.com]

TASK [Set default boot target] ***********************************
changed: [servera.lab.example.com]

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

Run the following command to verify that the default boot target is now multi-user.target.

[student@workstation system-process]$ ssh devops@servera \
> "systemctl get-default"
multi-user.target

Finish

On the workstation machine, change to the student user home directory and use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

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

This concludes the section.

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-9.0-c95c7de

Red Hat Enterprise Linux Automation with Ansible

Guided Exercise: Managing the Boot Process and Scheduled Processes

Note