Red Hat Enterprise Linux Automation with Ansible
After completing this section, you should be able to manage service startup, schedule processes with at, cron, and systemd, reboot, and control the default boot target on managed hosts.
Quick one-time scheduling is done with the at module. You create the job for a future time to run and it is held until that time comes to execute. There are six parameters that come with this module. They are: command, count, script_file, state, unique, and units.
- name: remove tempuser.
at:
command: userdel -r tempuser
count: 20
units: minutes
unique: yesTable 9.3. Parameters
| Parameter | Options | Comments |
|---|---|---|
| command | Null | A command that is scheduled to run. |
| count | Null | The count of units. (Must run with units) |
| script_file | Null | An existing script file to be executed in the future. |
| state | absent, present | The state adds or removes a command or script. |
| unique | yes, no | If a job is already running, it will not be executed again. |
| units | minutes/hours/days/weeks | The time denominations. |
When setting a jobs scheduled task the cron module is used. The cron module will append commands directly into the crontab of the user you designate.
- cron:
name: "Flush Bolt"
user: "root"
minute: 45
hour: 11
job: "php ./app/nut cache:clear"This play uses a company's cache:clear command immediately flushes Bolt cache, removing cached files and directories.flushes cache of the CMS server every morning at 11:45.
Ansible will write the play to the crontab using the correct syntax as the user stated.
Checking the crontab will verify that it has been appended to.
Some commonly used parameters for the cron module are:
Table 9.4. Parameters
| Parameter | Options | Comments |
|---|---|---|
| special_time | reboot, yearly, annually, monthly, weekly, daily, hourly | A set of reoccurring times. |
| state | absent, present | If set to present, it will create the command. Absent will remove it. |
| cron_file | Null | If you have large banks of servers to maintain then sometimes it is better to have a pre-written crontab file. |
| backup | yes, no | Backs up the crontab file prior to being edited. |
For managing services or reloading daemons, Ansible has the systemd and the service modules. Service offers a basic set of options start, stop, restart, enable. The systemd module offers more configuration options. Systemd will allow you to do a daemon-reload where the service module will not.
- name: start nginx
service:
name: nginx
state: started"Note
The init daemon is being replaced by systemd. So in a lot of cases systemd will be the better option.
Another well used Ansible Systems Module is reboot. Considered safer than using the shell module to initiate shutdown. While running a play the reboot module will shut down the managed host, then wait until it is back up again prior to carrying on with the play.
Like the service and the systemd modules, the shell and the command can interchange some tasks. The command module is considered more secure but some environment variables are not available. Also, stream operators will not work. If you need to stream your commands then shell module will do.
- name: Run a templated variable (always use quote filter to avoid injection)
shell: cat {{ myfile|quote }}
| To sanitize any variables, It is suggested that you use |
- name: This command only command: /usr/bin/scrape_logs.py arg1 arg2 args:
| You can pass arguments into the form to provide the options. |
Note
The command module is considered more secure because it is not affected by the users environment.
Gathering facts on the managed host will allow you to access the environment variables. There is a sublist called ansible_env which has all the environment variables inside it.
---
- name:
hosts: webservers
vars:
local_shell: "{{ ansible_env }}"
tasks:
- name: Printing all the environment variables in Ansible
debug:
msg: "{{ local_shell }}"
| You can isolate the variable you want to return by using the lookup plugin. |
