Hands-on Lab·CompTIA Linux+
Bash, Git, and rootless containers in one workflow
Domain 4 is 17% of XK0-006 and over half of it is shell scripting. This guide writes a script that reports success after failing, fixes it with three settings, gives it arguments and an exit code a scheduler can act on, puts it under git, and runs it inside a rootless container - which is the rest of the domain.
Automation and Scripting Guide 8 of 28 Intermediate
- OSUbuntu 26.04 LTS
- Kernel7.0.0-30-generic
- systemd259
- git2.53.0 (Ubuntu) / 2.52.0 (AlmaLinux)
- TimeAbout 26 min
- Containerspodman 5.7.0 (Ubuntu) / 5.8.2 (AlmaLinux) - rootless on both
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-A01 | 192.168.0.73 | Ubuntu 26.04 LTS | Debian-family host - apt, ufw, netplan, AppArmor | 2 Core | 4 GB | 50 GB |
This guide includes
Use this before you schedule anything you wrote. This matters because a script without set -euo pipefail carries on after a command fails and exits zero, so the thing that runs it every night will report success for as long as it keeps failing.
- watching a script fail and still report success, then fixing it with three settings
- measuring what
pipefailandset -ueach catch, on and off - giving a script an argument with a default and an exit code that means something
- committing it, changing it, and reading the diff and the status
- running it in a rootless container, and reading the uid map that makes root inside not root outside
Before you start
- five-faults-and-the-order-that-finds-them
-
A script that hides its own failure
-
The three settings that make it honest
-
Arguments, defaults, and an exit code that means something
-
Under version control, which is a Domain 4 objective
-
The same script inside a rootless container
-
Putting the machine back