Day 7 of 100 Days : Shell Scripting Essentials in DevOps

Why We Need Shell Scripting in DevOps

Think about a system administrator managing hundreds of servers. When changes are required—whether for updates, backups, or monitoring—manual effort on each server would be overwhelming and error-prone. Shell scripting allows us to write simple yet powerful scripts to automate these tasks across multiple servers with one command. This automation is crucial in DevOps because it ensures consistent and efficient operations, from deploying code to monitoring system health.

For instance, a shell script can pull new changes from Git, deploy them to the server, restart necessary services, and check for errors—all in one seamless operation. This kind of automation improves reliability, reduces downtime, and allows DevOps engineers to focus on strategic tasks rather than manual, repetitive work.

---

Shell Script Shebang (#!)

The shebang (#!) at the beginning of a shell script tells the system which interpreter to use for executing the script. By specifying the interpreter (usually /bin/bash or /usr/bin/env bash), you ensure that the script runs in a predictable environment, even if multiple shells are installed.

#!/bin/bash
echo "This script is executed with Bash!"

Using a shebang is especially important when scripts are shared across different environments, as it ensures the same shell is invoked on all systems.

---

Shell Commands

Shell commands form the basic operations in a script. Commands like ls, cd, cat, and echo are essential building blocks. DevOps scripts often combine several commands to check server statuses, manage files, or send logs.

For example, in a deployment script, you might use:

echo "Listing all the files..."
ls -l

---

Shell Variables

Variables store values to be reused, making scripts more flexible and easier to modify. In DevOps, variables often hold file paths, server names, and configuration details.

#!/bin/bash
server_name="ProdServer01"
echo "Deploying to $server_name..."

Using variables allows for quick adjustments. For instance, you could change server_name in one place to target a different server without modifying every line of your script.

---

Sourcing a File

Sourcing another file (source or .) loads its contents into the current script, which is especially useful for configurations. By storing reusable settings in a single file, you can update all dependent scripts by modifying that one file.

For example:

# config.sh
export DB_HOST="localhost"
export DB_PORT="3306"

# main_script.sh
source ./config.sh
echo "Connecting to database at $DB_HOST:$DB_PORT"

This setup is great for managing configurations across multiple scripts, as it centralizes and simplifies updates.

---

Preventing setuid Root Spoofing

Security is a key consideration in DevOps, and setuid root spoofing is a critical vulnerability to avoid. A script with setuid permissions (allowing root-level execution) could be maliciously edited to perform unintended actions.

To prevent this:

1. Use chmod 700 to restrict file permissions, allowing only the owner to execute the script.

2. Avoid setting setuid permissions on scripts that don’t require it.

chmod 700 deploy_script.sh
chown root deploy_script.sh

This approach minimizes the risk of unauthorized changes to scripts.

---

Executing a Shell Script

Running a shell script is straightforward and can be done in multiple ways:

• Using bash script.sh to run the script in a new shell instance.

• Making the script executable with chmod +x script.sh and then running it with ./script.sh.

Example:

chmod +x my_script.sh
./my_script.sh

In DevOps, making scripts executable and accessible to the right users ensures that automated tasks can be triggered reliably and securely.

---

Shell Script Parameters

Parameters enable dynamic inputs, allowing scripts to be used in various scenarios without modification. $1, $2, etc., represent positional parameters that can be passed into the script at runtime.

#!/bin/bash
echo "Deploying to server: $1"

Now, you can specify different server names each time you run the script, making it versatile across environments.

Commonly Used Parameter Symbols

• $0: Refers to the script's name itself.

• $1, $2, ..., $n: Refers to positional parameters. $1 is the first parameter, $2 is the second, and so on.

• $#: Represents the total number of arguments passed to the script.

• $@: Expands to all arguments passed to the script as separate quoted strings.

• $*: Expands to all arguments passed to the script as a single word.

• $?: Returns the exit status of the last executed command.

• $$: Shows the process ID of the current shell (useful for creating unique file names).

---

By mastering these foundational aspects of shell scripting, you're well on your way to creating robust and reusable scripts that streamline DevOps tasks, making infrastructure and deployment management smoother and more reliable.