Linux - Medium

Shell Scripting Basics

A shell script is just a sequence of the same commands you'd type interactively, saved to a file so they run reliably every time.

#!/bin/bash
# the "shebang" line above tells the OS which interpreter runs this file

NAME="world"                     # variable assignment - no spaces around =
echo "Hello, $NAME"

if [ -f /etc/nginx/nginx.conf ]; then   # -f tests "does this file exist"
  echo "config found"
else
  echo "config missing"
fi

for f in /var/log/*.log; do
  echo "Found log: $f"
done

chmod +x deploy.sh    # scripts need execute permission to run directly
./deploy.sh             # ./ tells the shell "run the one in this directory", not one from PATH

That ./ prefix trips up a lot of beginners - unlike other commands, scripts in your current directory usually aren't in PATH, so typing just deploy.sh gives "command not found" even though the file is right there.

---

Cron Jobs and Scheduling

cron is the standard Linux scheduler for recurring tasks - backups, cleanup scripts, periodic health checks.

crontab -e     # edit your personal crontab (opens in your default editor)

# minute  hour  day-of-month  month  day-of-week  command
0          3     *              *      *            /home/alice/backup.sh

That's "run backup.sh at 3:00 AM every day." The five fields go from most-specific (minute) to least-specific, and * means "any value." A frequent gotcha: cron runs with a much sparser environment than your interactive shell - no PATH full of your usual directories, no environment variables you've exported by hand. A script that runs fine when you test it manually can fail silently under cron because it can't find a program it assumed would be on PATH. Always use absolute paths in cron scripts, and redirect output somewhere you'll actually see it (>> /var/log/backup.log 2>&1).

---

SSH Deeper

Beyond ssh user@host, a few things make SSH genuinely production-usable.

ssh-keygen -t ed25519           # generate a new key pair
ssh-copy-id user@host            # copy your public key to a server's authorized_keys
ssh -i ~/.ssh/mykey user@host    # connect using a specific private key

Key-based auth is preferred over passwords for a real reason: passwords can be brute-forced or phished, and a private key never has to leave your machine to prove who you are. Most production servers disable password auth for SSH entirely.

An ~/.ssh/config file saves you from retyping the same flags constantly:

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/prod_key

Now ssh prod-web does exactly what the long version did. SSH can also tunnel other traffic through its encrypted connection - ssh -L 8080:localhost:80 user@host forwards your local port 8080 to port 80 on the remote machine, useful for reaching an internal dashboard that isn't exposed to the public internet.

---

Permissions Deeper

Beyond basic rwx, a few special permission bits matter for real server administration.

The sticky bit on a directory means users can only delete files they themselves own, even if they have write access to the directory - /tmp is the classic example, since everyone needs to write there but nobody wants to be able to delete each other's temp files.

setuid and setgid on an executable mean it runs with the permissions of the file's owner, not the user who launched it - this is how passwd, a program regular users can run, is able to modify /etc/shadow, a file regular users otherwise can't touch at all.

chmod +t /shared/tmp        # set the sticky bit
chmod u+s /usr/bin/somebin   # set setuid
umask                        # show the default permission mask for newly created files

umask matters more than it looks - it's why newly created files typically come out as 644 instead of the theoretical maximum 666; the umask value gets subtracted from the default to produce a safer starting permission automatically.