Automation with Shell Scripts and Scheduling

Shell scripting is the art of writing a series of commands into a plain text file that the shell (the command-line interpreter) executes in order. Think of it as a recipe: you list all the steps, and when you run the file, the computer does them one after another without you typing each line. The shell you use in Red Hat Enterprise Linux is called Bash (Bourne Again SHell), which is the default. Every shell script begins with a special first line called the shebang: it looks like #!/bin/bash. This tells the system which interpreter to use. Without it, the system might try to run the script using the wrong program. The first step in making a script executable is to set the execute permission using the command chmod +x scriptname.sh. Then you can run it by typing ./scriptname.sh.

Why does this matter? Before shell scripts, if you needed to backup a directory every day, you would have to type the same commands manually: cd /var/log, tar -czf backup.tar.gz logs/, and so on. With a script, you write those commands once into a file, and then run the script whenever you need that backup. This saves time and drastically reduces the chance of a typo or missed step. A simple script might look like this:

#!/bin/bash # This script backs up the /var/log directory tar -czf /backup/logs-$(date +%Y%m%d).tar.gz /var/log echo "Backup complete"

In this script, $(date +%Y%m%d) inserts today's date into the filename, so each backup gets a unique name. The echo command prints a message to the terminal so you know it finished.

Now, even a script still requires a human to run it. Scheduling tools automate that. Two key tools are cron and at. cron is for recurring tasks that need to happen at set times: daily, weekly, on the 15th of every month, and so on. at is for one-off tasks that run at a specific future time (like next Tuesday at 3 PM).

To use cron, you edit your personal cron table (crontab) with the command crontab -e. Each line in the crontab has five time fields (minute, hour, day of month, month, day of week) followed by the command to run. For example, the line '0 2 * * * /home/user/backup.sh' means run the backup script at 2:00 AM every day. The asterisks mean 'every'—so every day, every month, every day of the week. There is also a system-wide cron directory /etc/cron.d/ where system administrators put scripts for all users. To view your current crontab, use crontab -l. To remove it, use crontab -r.

For one-off tasks, at is simpler. You run the command 'at 10:00 PM tomorrow', then type the command you want to run, and press Ctrl+D to finish. The at command uses the atd daemon (background service) to run the job at the specified time. You can see all pending at jobs with the atq command, and remove a job with atrm jobnumber.

Both cron and at rely on daemons — background programs that constantly run and check for scheduled jobs. cron checks every minute, at checks continuously. These daemons must be running for the schedules to work. On RHEL, you can verify they are active with 'systemctl status crond' and 'systemctl status atd'.

Why does this replace manual work? In a real IT environment, a sysadmin might need to:

Doing all of these by hand would require the administrator to be at work at those exact times, including weekends and holidays. With shell scripts and scheduling, the computer does the work. The admin simply writes the scripts and configures the schedule once.

A crucial point: when a cron job runs, it runs with a very limited environment. It does not source your .bash_profile or .bashrc, so it may not have access to your aliases or PATH variable. This is a common pitfall in the EX200 exam. Always use full paths in cron jobs (e.g., /usr/bin/tar instead of just tar) and redirect output if you want to see error messages. For example, '0 2 * * * /home/user/backup.sh > /tmp/backup.log 2>&1' sends both standard output and standard error to a log file.

Variables in scripts are like named containers for data. To set a variable, write VARIABLE_NAME=value (no spaces around the equals sign). To use it, prefix with a dollar sign: $VARIABLE_NAME. For example, BACKUP_DIR="/backup" and then tar -czf $BACKUP_DIR/logs.tar.gz /var/log. You can also capture the output of a command into a variable using backticks or the $() syntax, as shown earlier with $(date +%Y%m%d).

Conditional statements like if and loops like for allow your script to make decisions and repeat actions. A simple if checks whether a condition is true: if [ -f /etc/passwd ]; then echo "File exists"; fi. A for loop runs through a list: for user in alice bob charlie; do echo "Hello $user"; done. These make your scripts intelligent, handling different situations without manual intervention.

To summarise: shell scripts bundle commands into a reusable file. cron and at execute those scripts on a schedule. Together, they automate repetitive system administration tasks, which is exactly what the EX200 exam expects you to demonstrate.

In a real business, imagine you work as a junior system administrator for a small company with 100 employees. One of your daily chores is to check disk space on the main file server. If the disk fills up, employees cannot save files, causing lost work and angry calls. Doing this manually every hour is impractical. So you write a shell script called /usr/local/bin/check_disk.sh that checks the disk usage of the /data partition and sends an email alert if it goes above 90%.

You write the script using the df command (disk free) and awk to extract the usage percentage. Then you use the mail command (or a similar tool) to send an email to you. The script might look something like:

#!/bin/bash USAGE=$(df /data | awk 'NR==2 {print $5}' | sed 's/%//') if [ $USAGE -gt 90 ]; then echo "Warning: /data is $USAGE% full" | mail -s "Disk Alert" admin@company.com fi

Now, you cannot sit around waiting to run this script. So you add a cron job using crontab -e. You decide to run the script every hour between 9 AM and 6 PM on weekdays, because that is when employees are most active. The crontab entry looks like this:

0 9-18 * * 1-5 /usr/local/bin/check_disk.sh

This means the script runs at minute 0 of every hour from 9 AM to 6 PM, every day of the week from Monday (1) to Friday (5). Now the system checks automatically.

Next, you need to apply security patches to the server. The maintenance window is next Saturday at 2:00 AM. This is a one-time task, so cron is not the right tool — cron would run it every Saturday. Instead, you use at. You log in on Friday afternoon and type:

at 2:00 AM Saturday at> /usr/bin/yum update -y at> /sbin/shutdown -r now at> <Ctrl+D>

This queues the update and reboot to happen exactly once at the scheduled time. You can verify with atq and see job number 5. If you change your mind, you can remove it with atrm 5.

Another common scenario is rotating log files. Logs can grow huge and fill up a partition. Your company already uses logrotate, but you want to ensure custom logs (like from a web application) are also rotated. You write a script that compresses logs older than 7 days and deletes those older than 30 days, and schedule it with cron to run daily at midnight.

Finally, you need to generate a monthly usage report. You write a script that queries the system for CPU, memory, and disk usage, formats it into an email, and sends it to your manager. You schedule that with cron to run on the 1st day of each month at 8:00 AM:

0 8 1 * * /usr/local/bin/monthly_report.sh

These real-world tasks show that automation is not a luxury — it is a necessity to maintain a reliable system without being on call 24/7. The EX200 exam tests your ability to write the scripts and set the schedules, which directly maps to these everyday responsibilities.