# LinkedIn Post Seeds Generated: 2026-06-26T01:11:10Z ## Your Site Is Not Down. DNS Might Be Lying. The browser said the site was gone. The server was answering fine. Command: `curl --resolve example.com:443:203.0.113.10 https://example.com/` A domain appears unreachable, but you need to separate a real server outage from stale or wrong DNS. Question: When a site disappears, do you check DNS first or the web server first? Full terminal demo and notes: https://linuxoneliners.com/lessons/curl-resolve-site-check/ --- ## Find the Files Eating Your Disk The disk was full, but guessing at folders was the slow part. Command: `find /var -type f -printf '%s %p\n' | sort -nr | head -20` A machine is low on disk space and you need to quickly find the largest files under a path. Question: What is the first disk-space command you usually run? Full command and safer cleanup notes: https://linuxoneliners.com/lessons/find-large-files/ --- ## Run Rsync Without Deleting Your Backup One rsync flag can save you. Another can erase the wrong side. Command: `rsync -avhn --delete ./source/ ./backup/` You need to preview an rsync operation before moving or deleting files. Question: Have you ever seen `rsync --delete` pointed the wrong way? Full demo and safer checklist: https://linuxoneliners.com/lessons/rsync-dry-run/ --- ## Watch Logs Without Opening the Whole File The app was failing now. Opening a giant log file was the wrong move. Command: `tail -n 80 -f /var/log/nginx/error.log` You need to watch recent log lines while a service or script is actively failing. Question: Do you inspect logs before or after reproducing a bug? Full log-watching demo: https://linuxoneliners.com/lessons/tail-live-logs/ --- ## Find Errors Before Reading Every Log Line The error was in the log. The problem was finding it without reading noise. Command: `grep -iE 'error|failed|denied|timeout' /var/log/nginx/error.log | tail -40` A log file has too much output and you need a quick first pass for failure words. Question: What failure words do you grep for first? Full grep pattern and caveats: https://linuxoneliners.com/lessons/grep-errors-in-logs/ --- ## Check What Is Actually Listening The app was running. The port was not listening. Command: `ss -tulpn | grep ':80\|:443'` A service appears started, but you need to confirm whether anything is listening on the expected port. Question: When a service is up but unreachable, do you check the port or the logs first? Full listener check demo: https://linuxoneliners.com/lessons/check-listening-ports/ --- ## Inspect Permissions Before Changing Them The permission fix was easy. Knowing what not to chmod was the hard part. Command: `namei -l /var/www/example/index.html` A file or directory has a permission issue, but recursive fixes could break more than they repair. Question: What permission command do you trust before reaching for `chmod -R`? Full permission inspection demo: https://linuxoneliners.com/lessons/inspect-permissions/ --- ## Find the Exact Log Line Before You Scroll The error was there. The useful part was knowing exactly where it was. Command: `grep -inE 'error|failed|denied|timeout' /var/log/nginx/error.log` A log file contains likely failures, but you need line numbers so you can inspect context around the match. Question: Do you jump straight into logs, or search for line numbers first? Full line-number grep demo: https://linuxoneliners.com/lessons/grep-line-numbers/ --- ## Find Which Folder Is Filling the Disk The disk was full. The fastest clue was the folder, not the file. Command: `du -sh /var/* 2>/dev/null | sort -h` A server is low on disk and you need a quick folder-level view before drilling into files. Question: Do you start disk cleanup with `du` or `find`? Full disk triage demo: https://linuxoneliners.com/lessons/disk-usage-by-folder/ --- ## Show Only Recent Errors The log had old failures too. I only cared about the newest ones. Command: `grep -iE 'error|failed|denied|timeout' /var/log/nginx/error.log | tail -10` A noisy log contains old and new errors, and you need the most recent likely failures. Question: When logs are noisy, do you filter first or tail first? Full recent-error demo: https://linuxoneliners.com/lessons/recent-log-errors/ --- ## Preview What Rsync Would Delete `rsync --delete` is useful. It is also how people erase the wrong side. Command: `rsync -avhn --delete ./source/ ./backup/ | grep '^deleting'` You need to know which files rsync would delete before running a real sync. Question: Would you run `rsync --delete` without checking the delete list first? Full dry-run delete demo: https://linuxoneliners.com/lessons/rsync-show-deletes/ --- ## Check Owner and Mode in One Line The file existed. The owner and mode explained why it still failed. Command: `stat -c '%A %U:%G %n' /var/www/example/index.html` A path exists but access fails, and you need owner, group, and mode quickly. Question: Do you use `stat` or `ls -l` first for permission issues? Full ownership check demo: https://linuxoneliners.com/lessons/file-owner-and-mode/ --- ## Find the Processes Using Memory The server felt slow. Memory pressure was the first thing to rule out. Command: `ps -eo pid,comm,%mem,%cpu --sort=-%mem | head` You need a quick process-level view of memory usage. Question: What do you check first when a VPS feels slow? Full memory triage demo: https://linuxoneliners.com/lessons/list-processes-by-memory/ --- ## Show Big Files in Human Units Byte counts are precise. Human units are faster under pressure. Command: `find /var -type f -printf '%s %p\n' | sort -nr | head -10 | awk '{printf "%.1f MB %s\n", $1/1024/1024, $2}'` You need to find large files and read their sizes without mentally converting bytes. Question: Do you prefer raw bytes or human units during disk cleanup? Full large-file demo: https://linuxoneliners.com/lessons/show-top-files-human/ --- ## Find What Is Using a Local Dev Port Your dev server says port 3000 is busy. Ask macOS who is holding it. Command: `lsof -nP -iTCP:3000 -sTCP:LISTEN` A local server will not start because another process is already listening on the same TCP port. Question: What is your fastest habit for debugging EADDRINUSE on macOS? Save this for the next time your local server refuses to start.: https://linuxoneliners.com/lessons/mac-find-what-is-using-port/ --- ## Stop the Process Blocking a Dev Port Free a stuck dev port without hunting through Activity Monitor. Command: `lsof -ti tcp:3000 | xargs kill` A stale local server keeps listening on a port after its terminal window was closed. Question: Do you prefer killing stale dev servers by PID, port, or process name? Use this carefully when a local server leaves a port behind.: https://linuxoneliners.com/lessons/mac-stop-process-on-port/ --- ## Show Your PATH One Entry Per Line Wrong Node, Python, or FFmpeg? Start by reading your PATH clearly. Command: `echo "$PATH" | tr ':' '\n' | nl -ba` A tool runs from an unexpected location because PATH order is unclear. Question: How often do your toolchain bugs turn out to be PATH order problems? Save this as the first check for weird CLI resolution issues.: https://linuxoneliners.com/lessons/mac-show-path-lines/ --- ## See Exactly Which Command macOS Will Run Before blaming npm, Python, or Git, check the binary your shell actually found. Command: `command -v node && node -v` Multiple versions of the same command are installed and the shell may be choosing the wrong one. Question: What command has bitten you most often because the wrong version was first in PATH? Run this before reinstalling a toolchain.: https://linuxoneliners.com/lessons/mac-which-command-will-run/ --- ## Find Large Files Inside a Project Before committing, check whether a huge video, build artifact, or export slipped into your repo. Command: `find . -type f -size +100M -print` A project folder contains unexpectedly large files that slow sync, backups, or Git operations. Question: What large file type most often sneaks into your projects: video, zip, database, or build output? Run this before pushing a repo that suddenly feels slow.: https://linuxoneliners.com/lessons/mac-find-large-project-files/ --- ## Find Which Folder Is Eating Disk Space When your Mac is full, start with the biggest folders in the current directory. Command: `du -sh ./* 2>/dev/null | sort -h` Disk space is low and the user needs to identify which project folder or cache is largest. Question: What is usually the biggest disk-space offender on your Mac? Use this from a specific folder when storage gets tight.: https://linuxoneliners.com/lessons/mac-sort-folder-size/ --- ## Flush macOS DNS Cache Changed DNS but your Mac still visits the old place? Flush the resolver cache. Command: `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` macOS may keep using cached DNS answers after a domain, hosts entry, or local network record changes. Question: When DNS debugging gets weird, do you check local cache before waiting on propagation? Keep this around for local domain and VPN troubleshooting.: https://linuxoneliners.com/lessons/mac-flush-dns-cache/ --- ## Watch a Log or Build File Update Need to see whether a file is still changing? Let tail follow it live. Command: `tail -f ./app.log` A developer or creator needs to monitor a changing log, export report, or build output file. Question: What local file do you tail most often while building? Use this for quick live feedback without opening another app.: https://linuxoneliners.com/lessons/mac-watch-file-changes/ --- ## Search a Log for Errors With Context A wall of logs is useless until you pull the error and the lines around it. Command: `grep -n -C 2 'ERROR' ./app.log` A local log contains too many lines to manually scan for the relevant failure. Question: Do you usually search logs directly, or save command output to a file first? Try context lines the next time a log is too noisy.: https://linuxoneliners.com/lessons/mac-search-logs-for-errors/ --- ## Check a URL Without Downloading the Page Before opening a broken page in five browsers, ask the server for headers. Command: `curl -I https://example.com` A developer needs to confirm whether a local or remote URL returns the expected status, redirect, or content type. Question: What header do you check first when a web page behaves strangely? Use this before opening another browser tab.: https://linuxoneliners.com/lessons/mac-test-url-headers/ --- ## List Newest Source Files Before Backup Before trusting a backup, know which files changed most recently. Command: `find source -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort` You need a timestamp-sorted view of source files before comparing backups. Question: Do you check recent source changes before validating a backup? Timestamp the source tree before comparing it.: https://linuxoneliners.com/lessons/backup-list-newest-source-files/ --- ## Create a SHA256 Checksum Manifest A file list says what exists; checksums say whether bytes match. Command: `sha256sum source/app/config.yml source/content/index.md source/content/about.md source/assets/logo.svg` You need checksums for key files before copying or archiving them. Question: Do you generate checksums before moving critical small files? Use checksums when exact bytes matter.: https://linuxoneliners.com/lessons/backup-create-checksum-manifest/ --- ## Verify a SHA256 Checksum Manifest A checksum file is only useful if you actually verify it. Command: `sha256sum -c checksums.sha256` You need to confirm files still match a saved SHA256 manifest. Question: Do you verify checksum manifests after restores, or just create them? Run the manifest check after copying data.: https://linuxoneliners.com/lessons/backup-verify-checksum-manifest/ --- ## Compare Source and Backup File Lists A backup can be missing files and still look plausible at a glance. Command: `comm -3 <(find source -type f | sed 's#^source/##' | sort) <(find backup -type f | sed 's#^backup/##' | sort)` You need to compare relative file paths in source and backup directories. Question: Do you compare backup file presence separately from file contents? Start with relative path lists, then verify bytes.: https://linuxoneliners.com/lessons/backup-compare-source-and-backup-file-lists/ --- ## Preview Backup Drift with rsync Rsync can tell you what would change before it changes anything. Command: `rsync -ain --delete source/ backup/` You need to see source-to-backup drift without modifying the backup. Question: Do you read rsync itemized output before removing --dry-run? Keep -n until the drift makes sense.: https://linuxoneliners.com/lessons/backup-rsync-dry-run-itemize/ --- ## Find Empty Files in a Backup Zero-byte files can be normal, or they can be failed writes. Command: `find backup -type f -size 0 -print` You need to spot empty files inside a backup tree. Question: Do you flag zero-byte files in backup reports? Treat empty files as a triage signal, not automatic failure.: https://linuxoneliners.com/lessons/backup-find-empty-files/ --- ## List Largest Files in a Backup Large backup files are where storage surprises usually start. Command: `find backup -type f -printf '%s %p\n' | sort -nr | head` You need to rank backup files by size. Question: When backup storage grows, do you rank files by size first? Use size ranking before cleanup decisions.: https://linuxoneliners.com/lessons/backup-list-largest-files/ --- ## List Contents of a Backup Tarball You can inspect an archive without extracting it. Command: `tar -tf archives/site-backup.tar | sort | head` You need to see what a backup tarball contains before restoring it. Question: Do you inspect tarball contents before extracting backups? List first, restore second.: https://linuxoneliners.com/lessons/backup-list-tar-contents/ --- ## Count Source Files by Extension A quick extension count can show whether expected content made it into the source tree. Command: `find source -type f -printf '%f\n' | sed -n 's/.*\.//p' | sort | uniq -c | sort -nr` You need a small inventory of source file types. Question: Do you inventory file types when validating backups? Use extension counts as a quick sanity check.: https://linuxoneliners.com/lessons/backup-count-source-file-types/ --- ## Find Files Newer Than a Backup Snapshot Files newer than the last snapshot are the ones most likely missing from it. Command: `find source -type f -newer backup/.snapshot -print | sort` You need to list source files changed after the backup snapshot marker. Question: Do you keep a snapshot marker for quick backup freshness checks? Use newer-than checks as one backup signal.: https://linuxoneliners.com/lessons/backup-find-files-newer-than-snapshot/ --- ## List Restore Points Before a Drill A restore drill starts by proving which backups actually exist. Command: `cd restore-dr && find backups -maxdepth 2 -type f -name MANIFEST.txt -printf '%TY-%Tm-%Td %TH:%TM %h\n' | sort -r` You need a quick, timestamped list of available backup restore points before choosing one to test. Question: Do your restore drills start with a real list of recovery points? Inventory the backups before choosing one.: https://linuxoneliners.com/lessons/backup-dr-list-restore-points/ --- ## Read the Backup Manifest The manifest should say what backup you are about to trust. Command: `cd restore-dr && cat backups/2026-06-25/MANIFEST.txt` You need to confirm the backup id, timestamp, archive name, and completion status before drilling a restore. Question: What fields do you require in a backup manifest? Make the restore point explicit before testing it.: https://linuxoneliners.com/lessons/backup-dr-read-backup-manifest/ --- ## List Archive Contents Before Extracting You can inspect a tar backup before it writes a single file. Command: `cd restore-dr && tar -tf backups/2026-06-25/site.tar | sed 's#^./##' | sort` You need to see what an archive contains before extracting it into a restore sandbox. Question: Do you list archive contents before restore tests? Inspect the tarball before extracting it.: https://linuxoneliners.com/lessons/backup-dr-list-archive-contents/ --- ## Find Missing Files in an Old Backup The fastest failed restore drill is the one that finds missing critical files early. Command: `cd restore-dr && tar -tf backups/2026-06-24/site.tar | sed 's#^./##' | sort | comm -23 required-files.txt -` You need to compare a backup archive against a required file list and print required files that are absent. Question: Which files are mandatory in your restore checklist? Compare backups against a required file list.: https://linuxoneliners.com/lessons/backup-dr-find-missing-required-files/ --- ## Extract a Backup Into a Restore Sandbox A restore drill should write to a sandbox, not production. Command: `cd restore-dr && rm -rf restore-sandbox/full && mkdir -p restore-sandbox/full && tar -xf backups/2026-06-25/site.tar -C restore-sandbox/full` You need to extract a backup into a dedicated restore-sandbox directory and list the restored files. Question: Do your restore drills ever write outside a sandbox? Keep restore tests isolated and reviewable.: https://linuxoneliners.com/lessons/backup-dr-extract-to-sandbox/ --- ## Verify Restored File Checksums A restore is not validated until the bytes match. Command: `cd restore-dr && rm -rf restore-sandbox/full && mkdir -p restore-sandbox/full && tar -xf backups/2026-06-25/site.tar -C restore-sandbox/full && (cd restore-sandbox/full && sha256sum -c CHECKSUMS.sha256)` You need to run the checksum manifest inside the restored sandbox and confirm each restored file is OK. Question: Do your restore drills verify bytes or only file names? Run checksum validation after extraction.: https://linuxoneliners.com/lessons/backup-dr-verify-restored-checksums/ --- ## Diff Restored Config Against Expected A restored config can exist and still be the wrong config. Command: `cd restore-dr && rm -rf restore-sandbox/full && mkdir -p restore-sandbox/full && tar -xf backups/2026-06-25/site.tar -C restore-sandbox/full && diff -u expected/app/config.yml restore-sandbox/full/app/config.yml` You need to compare a restored configuration file with the expected fixture copy. Question: Which restored config files do you diff during DR drills? Validate critical config, not just file presence.: https://linuxoneliners.com/lessons/backup-dr-diff-restored-config/ --- ## Check Required Files After Restore A successful extraction still needs a required-file check. Command: `cd restore-dr && rm -rf restore-sandbox/full && mkdir -p restore-sandbox/full && tar -xf backups/2026-06-25/site.tar -C restore-sandbox/full && find restore-sandbox/full -type f | sed 's#^restore-sandbox/full/##' | sort | comm -23 required-files.txt -` You need to confirm every required path exists in the restored sandbox. Question: Do you maintain a required-file list for restore drills? Use a checklist the shell can verify.: https://linuxoneliners.com/lessons/backup-dr-check-restored-required-list/ --- ## Review Critical File Modes in the Archive Permissions are part of the restore, not decoration. Command: `cd restore-dr && tar -tvf backups/2026-06-25/site.tar | awk '/secrets.env|deploy.sh/ {print $1, $6}'` You need to inspect critical file modes inside the backup archive before trusting a restore. Question: Do your backup checks include permissions? Review critical modes before the incident.: https://linuxoneliners.com/lessons/backup-dr-review-archive-permissions/ --- ## Read the Restore Drill Validation Report A restore drill that leaves no evidence is hard to trust later. Command: `cd restore-dr && grep -E 'status=|rpo_minutes=|rto_seconds=|checksum=|file_count=' reports/restore-dr-2026-06-25.txt` You need to pull the key pass, RPO, RTO, checksum, and file-count lines from a restore drill report. Question: What evidence do you keep from restore drills? Record the pass signals while the drill is fresh.: https://linuxoneliners.com/lessons/backup-dr-read-validation-report/ --- ## Find the Newest Build Logs First The failing file is usually one of the newest artifacts. Command: `find artifacts logs -type f \( -name '*.log' -o -name '*.txt' \) -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r | head` A CI job produced several logs and reports, and you need to quickly locate the most recent build output before reading everything. Question: When CI fails, do you inspect logs by timestamp or by guesswork? Build log triage demo: https://linuxoneliners.com/lessons/ci-find-newest-build-logs/ --- ## Scan Every CI Log for Error Lines One grep pass can turn a log pile into a failure list. Command: `grep -RInE 'error|failed|failure|exception|traceback' artifacts logs | head -50` Multiple CI logs may contain errors, warnings, stack traces, and test failures, but opening each file manually is slow. Question: What words do you search for first in a failed CI artifact bundle? CI log grep demo: https://linuxoneliners.com/lessons/ci-scan-errors-across-logs/ --- ## Show Context Around the First Error The line before the error often explains the error. Command: `grep -RInC 3 -m 1 'ERROR' artifacts logs` A log contains a clear error line, but the useful cause may be several lines above or below it. Question: Do you read only the error line, or the context around it? Error context demo: https://linuxoneliners.com/lessons/ci-show-context-around-first-error/ --- ## List Failed Tests from JUnit XML The XML report already knows which tests failed. Command: `grep -RIn ' 'Sleep' order by time desc limit 10;"` MySQL is slow and you need to identify queries that have been running the longest. Question: Do you sort MySQL sessions by runtime during slow incidents? Long MySQL query demo: https://linuxoneliners.com/lessons/mysql-find-long-running-queries/ --- ## Show MySQL Database Sizes The storage alert needed a database name. Command: `mysql -e "select table_schema, round(sum(data_length + index_length)/1024/1024, 1) as mb from information_schema.tables group by table_schema order by mb desc;"` Disk usage is rising and you need to know which MySQL schemas are largest. Question: When MySQL disk usage grows, do you check schema sizes first? MySQL size demo: https://linuxoneliners.com/lessons/mysql-check-database-sizes/ --- ## Check Whether Databases Listen Publicly The fastest database security check is the listening address. Command: `ss -ltnp | awk '$4 ~ /:(5432|3306)$/ {print}'` You need to know whether PostgreSQL or MySQL is exposed beyond localhost. Question: Do you check database bind addresses during VPS security reviews? Database exposure demo: https://linuxoneliners.com/lessons/database-check-public-listeners/ --- ## Fingerprint a Debian or Ubuntu Host Before package triage, prove what OS family and release you are actually on. Command: `. /etc/os-release && printf '%s %s %s\n' "$ID" "$VERSION_ID" "$VERSION_CODENAME"` A server is described as Debian or Ubuntu, but you need the exact release fields before interpreting package output. Question: Do you check the release codename before reading apt output? Use this as the first line in Debian and Ubuntu inventory notes.: https://linuxoneliners.com/lessons/debian-ubuntu-release-fingerprint/ --- ## Compare Kernel and Distro Versions The distro version and kernel version answer different questions. Command: `printf 'kernel=%s arch=%s distro=%s\n' "$(uname -r)" "$(uname -m)" "$(lsb_release -ds)"` You need to know whether a package issue is tied to the OS release, the running kernel, or the CPU architecture. Question: When debugging Linux packages, do you capture kernel and distro separately? Paste this into first-response inventory notes.: https://linuxoneliners.com/lessons/kernel-and-distro-side-by-side/ --- ## List Installed Package Versions A package inventory beats memory when a server is drifting. Command: `dpkg-query -W -f='${Package}\t${Version}\t${Architecture}\n' | sort` You need a deterministic list of installed Debian packages, versions, and architectures for comparison or incident notes. Question: Do you keep package inventories before risky maintenance windows? Use this for a clean Debian and Ubuntu package snapshot.: https://linuxoneliners.com/lessons/dpkg-installed-package-inventory/ --- ## See Which Packages Want Updates Before you upgrade anything, list what would move. Command: `apt list --upgradable` You need to see pending package updates without changing the system. Question: Do you review the upgradable list before running upgrades? Make this the first check in package maintenance notes.: https://linuxoneliners.com/lessons/apt-list-upgradable-packages/ --- ## Check the Installed and Candidate Package Version apt policy explains where the next version would come from. Command: `apt policy nginx` A package has an update available, and you need to see the installed version, candidate version, and repository source. Question: Do you check apt policy before blaming a repository or mirror? Use this to explain package version decisions.: https://linuxoneliners.com/lessons/apt-policy-package-candidate/ --- ## Check One Installed Package Cleanly For one package, dpkg-query gives a clean status line. Command: `dpkg-query -W -f='${Status} ${Version}\n' openssl` You need to confirm whether one package is installed and capture its exact installed version without noisy apt output. Question: For one package, do you reach for dpkg-query or apt first? Use this when exact installed state matters.: https://linuxoneliners.com/lessons/dpkg-check-one-package-status/ --- ## Find Which Package Owns a File That binary came from somewhere. dpkg can tell you where. Command: `dpkg-query -S /usr/sbin/nginx` You see a file or command on a Debian or Ubuntu host and need to identify the package that installed it. Question: Do you trace unfamiliar binaries back to package ownership? Use this before changing files you did not install manually.: https://linuxoneliners.com/lessons/dpkg-find-package-owning-file/ --- ## Find Broken or Leftover dpkg States Not every package row is cleanly installed. Command: `dpkg-query -W -f='${db:Status-Abbrev}\t${Package}\n' | awk '$1 !~ /^ii$/'` A host has package trouble and you need to spot half-configured packages or removed packages with leftover config. Question: Do you check dpkg status abbreviations after failed package installs? Use this before repair commands so you know what is actually broken.: https://linuxoneliners.com/lessons/dpkg-find-broken-package-states/ --- ## Find the Largest Installed Packages Disk cleanup starts with evidence, not random package removal. Command: `dpkg-query -W -f='${Installed-Size}\t${Package}\n' | sort -nr | head -20` A Debian or Ubuntu system is low on disk and you need to see which installed packages occupy the most space. Question: Do package sizes matter in your disk cleanup checklist? Use this read-only view before removal decisions.: https://linuxoneliners.com/lessons/dpkg-largest-installed-packages/ --- ## Spot Foreign-Architecture Packages One unexpected architecture can explain confusing dependency output. Command: `dpkg-query -W -f='${Architecture}\t${Package}\n' | awk '$1 != "amd64" && $1 != "all"'` Package dependency output is confusing and you need to see whether the host has non-native architecture packages installed. Question: Have foreign-architecture packages ever explained a dependency puzzle for you? Add this to Debian and Ubuntu package inventory checks.: https://linuxoneliners.com/lessons/dpkg-foreign-architecture-packages/ --- ## Simulate Security Package Upgrades Security patch triage starts by seeing what apt would change, without changing it. Command: `apt-get -s upgrade | awk '/^Inst/ && /security/ {print}'` You need to identify pending security updates on a Debian or Ubuntu host before a maintenance window. Question: Do you capture apt simulation output before approving security patch windows? Use this as the first read-only Debian and Ubuntu patch triage step.: https://linuxoneliners.com/lessons/apt-simulate-security-upgrades/ --- ## Prove a Package Candidate Is From Security The package name is not enough; the candidate repository tells the patch story. Command: `apt-cache policy openssl | sed -n '/Installed:/p;/Candidate:/p;/security/p'` A package is upgradable and you need to confirm whether the candidate version comes from the security pocket. Question: When reviewing a security patch, do you prove the candidate origin or just trust the package name? Use apt-cache policy for package-level patch evidence.: https://linuxoneliners.com/lessons/apt-cache-policy-security-candidate/ --- ## Find Held Packages Blocking Patches A held package can quietly keep a security update out of production. Command: `apt-mark showhold | sed 's/^/held: /'` Patch simulation shows kept-back packages and you need to see whether apt holds are part of the reason. Question: Do your patch reviews include a held-package check? Add apt-mark showhold to Debian and Ubuntu security triage.: https://linuxoneliners.com/lessons/apt-mark-held-security-blockers/ --- ## Review Kept-Back Packages Before Patching Kept-back packages are where simple upgrade plans stop being simple. Command: `apt-get -s upgrade | sed -n '/kept back:/,/^Inst/p'` A normal apt upgrade simulation reports packages kept back, and you need to capture them before choosing a broader upgrade path. Question: How do you handle kept-back packages during security maintenance? Record the kept-back section before changing upgrade strategy.: https://linuxoneliners.com/lessons/apt-kept-back-package-review/ --- ## Dry-Run Unattended Security Upgrades Unattended upgrades can explain what they would patch before they patch it. Command: `unattended-upgrade --dry-run --debug 2>&1 | sed -n '/Packages that will be upgraded:/,/^$/p'` You need to inspect what unattended-upgrades would select without installing packages. Question: Do you test unattended-upgrades with a dry run before relying on it? Use this to validate automatic Debian and Ubuntu security patch coverage.: https://linuxoneliners.com/lessons/unattended-upgrade-dry-run-security/ --- ## Find Services Needing Restart After Patches A patched library does not protect a process still using the old one. Command: `needrestart -b | sed -n 's/^NEEDRESTART-SVC: //p'` After security packages are applied, you need to see which services still need restarts. Question: Do your patch windows track service restarts separately from package installation? Use needrestart output to close the gap between installed and active fixes.: https://linuxoneliners.com/lessons/needrestart-services-after-security-updates/ --- ## Build a Recent Apt Patch Timeline Apt history turns patch claims into timestamps and package names. Command: `awk '/^(Start-Date|Commandline|Upgrade|End-Date)/ {print}' /var/log/apt/history.log` You need to prove what package changes happened recently and which command triggered them. Question: When validating patch work, do you check apt history or only current package versions? Use apt history for timestamped package-change evidence.: https://linuxoneliners.com/lessons/apt-history-security-patch-timeline/ --- ## Find Warnings in Apt Terminal Logs The package installed, but the terminal log may still contain the warning that matters. Command: `grep -Ei 'warning|error|failed|dpkg' /var/log/apt/term.log` A patch run completed and you need to spot warnings, errors, failed maintainer scripts, or restart clues. Question: Do your patch checks include apt term.log warnings? Search terminal logs before calling package maintenance clean.: https://linuxoneliners.com/lessons/apt-term-log-patch-warnings/ --- ## Preview Security Impact of dist-upgrade Kernel and dependency security fixes may only appear in the broader upgrade plan. Command: `apt-get -s dist-upgrade | awk '/^Inst/ {print}'` A regular upgrade leaves packages behind and you need to preview the broader resolver plan without installing it. Question: When do you escalate from apt upgrade to a broader dist-upgrade review? Use simulation output to size the patch window before changing the host.: https://linuxoneliners.com/lessons/apt-dist-upgrade-security-impact-preview/ --- ## Check Whether Patches Require Reboot Some security fixes are not complete until the host boots the new kernel or libraries. Command: `test -f /var/run/reboot-required && printf 'reboot-required\n' && cat /var/run/reboot-required.pkgs` After package updates, you need to know whether the system is signaling a required reboot and which packages triggered it. Question: Do your security patch runbooks separate package install, service restart, and reboot validation? Use reboot-required markers to make the final step explicit.: https://linuxoneliners.com/lessons/debian-reboot-required-after-patches/ --- ## Tail the Failing CI Lines Skip the full CI log and jump straight to lines that usually explain the failure. Command: `grep -RInE 'error|failed|exception|traceback|fatal' logs/ | tail -50` A build log is thousands of lines long and the useful error is buried near the end. Question: What is the first command you run when a CI log is too noisy? Share your fastest deployment triage one-liner.: https://linuxoneliners.com/lessons/tail-failing-ci-log-lines/ --- ## List Newest Build Artifacts Confirm what your pipeline actually produced before you deploy it. Command: `find artifacts/ -type f -printf '%TY-%Tm-%Td %TH:%TM %10s %p\n' | sort | tail -20` A deployment references an artifact, but you are not sure which files were built most recently. Question: Do you verify artifacts before deploy, or trust the pipeline name? Save this for your next release check.: https://linuxoneliners.com/lessons/list-newest-build-artifacts/ --- ## Check the Current Release Symlink One glance tells you which release directory production is pointing at. Command: `readlink -f releases/current && ls -ld releases/current` A deploy uses a current symlink and you need to verify the active release. Question: Does your deploy system make the active release obvious? Use this before blaming the app code.: https://linuxoneliners.com/lessons/check-current-release-symlink/ --- ## Find the Largest CI Logs Huge logs often point to loops, noisy tests, or runaway debug output. Command: `find logs/ -type f -printf '%s %p\n' | sort -nr | head -10` A CI job is slow or hard to inspect because some logs are unexpectedly large. Question: Have oversized logs ever hidden the real failure from your team? Try sorting logs by size during your next CI cleanup.: https://linuxoneliners.com/lessons/find-largest-ci-logs/ --- ## Show Release Directory Ages See your newest release directories without opening a dashboard. Command: `find releases/ -mindepth 1 -maxdepth 1 -type d -printf '%T@ %TY-%Tm-%Td %TH:%TM %p\n' | sort -nr | head -10 | cut -d' ' -f2-` You need to confirm recent releases exist and identify their order. Question: How do you confirm the release directory you expect is actually present? Add this to your deployment triage notes.: https://linuxoneliners.com/lessons/show-release-directory-ages/ --- ## Extract Environment Names Only Audit environment labels without printing secret values. Command: `grep -RhoE 'ENVIRONMENT|NODE_ENV|APP_ENV|RAILS_ENV' config deploy | sort -u` You need to see which environment names appear in config files, but must avoid exposing secrets. Question: Do your deployment checks avoid printing secret values by default? Use name-only checks when sharing terminal output.: https://linuxoneliners.com/lessons/extract-env-names-from-configs/ --- ## Smoke Check an HTTP Status A deploy is not done until the endpoint answers. Command: `curl -fsS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/health` You need a quick status-code check after a deployment. Question: What is your minimum smoke check after deployment? Post the one command your team trusts.: https://linuxoneliners.com/lessons/smoke-check-http-status/ --- ## Compare Artifact Checksums Verify two artifact copies match before blaming deployment code. Command: `sha256sum artifacts/app.tar.gz releases/current/app.tar.gz` You need to confirm whether a built artifact and deployed artifact are identical. Question: Do you verify artifact identity during deployment incidents? Keep checksum checks in your rollback playbook.: https://linuxoneliners.com/lessons/compare-artifact-checksums/ --- ## Count Failures by Test File Turn noisy test logs into a ranked failure list. Command: `grep -RhoE '[A-Za-z0-9_./-]+\.(test|spec)\.(js|ts|py|rb)' logs/ | sort | uniq -c | sort -nr | head` A CI log has repeated failures and you need to see which files appear most often. Question: When many tests fail, do you rank the failures or inspect them in log order? Try counting repeated test paths first.: https://linuxoneliners.com/lessons/count-failures-by-test-file/ --- ## Inspect Release Disk Usage Disk pressure during deploys often starts in old release directories. Command: `du -sh releases/* 2>/dev/null | sort -h | tail -10` A host is low on disk and release directories may be taking too much space. Question: What usually fills disk first on your deployment hosts? Measure before cleanup, especially during incidents.: https://linuxoneliners.com/lessons/inspect-release-disk-usage/ --- ## Check Image Tags in Manifests Find the image tags your deployment files reference without printing env values. Command: `grep -RhoE 'image:[[:space:]]*[^[:space:]]+' deploy/ | sort -u` You need to confirm which container image tags are present in deployment manifests. Question: Have you ever deployed the right code with the wrong image tag? Add a manifest tag check to your release routine.: https://linuxoneliners.com/lessons/check-container-image-tag-in-manifest/ --- ## Check Bytes and Inodes Before Cleanup No space left can mean full bytes, full inodes, or both. Command: `df -h /lab/disk-inode-cleanup && df -ih /lab/disk-inode-cleanup` A host is failing writes and you need to know whether byte usage or inode usage is the tighter limit before deleting anything. Question: During disk incidents, do you check inode pressure before cleanup? Start with byte and inode evidence.: https://linuxoneliners.com/lessons/disk-cleanup-confirm-space-and-inodes/ --- ## Keep du on One Filesystem A cleanup scan should not wander into mounted backups or network storage. Command: `du -xh --max-depth=1 /lab/disk-inode-cleanup/var 2>/dev/null | sort -h` You need a directory-level size view without crossing filesystem boundaries during disk triage. Question: Do your disk cleanup scans intentionally avoid mounted backup paths? Use scoped du output before drilling deeper.: https://linuxoneliners.com/lessons/disk-cleanup-scope-du-to-one-filesystem/ --- ## Preview Old Temp Files Before Deleting The safe version of cleanup is a candidate list first. Command: `find /lab/disk-inode-cleanup/var/tmp/uploads -xdev -type f -mtime +7 -printf '%TY-%Tm-%Td %10s %p\n' | sort` A temporary upload directory may contain stale files, but you need evidence before removing anything. Question: What proof do you require before deleting temp files on a production host? Print the candidate list before cleanup.: https://linuxoneliners.com/lessons/disk-cleanup-preview-old-temp-files/ --- ## Find Directories Burning Inodes Inode cleanup starts by finding the directory with too many files. Command: `find /lab/disk-inode-cleanup/var/cache/app -xdev -type f -printf '%h\n' | sort | uniq -c | sort -nr | head` Inode usage is high and you need to locate which directories contain the most regular files. Question: Have you seen a small cache directory exhaust inodes before it exhausted bytes? Count files by directory before deleting.: https://linuxoneliners.com/lessons/disk-cleanup-find-inode-hotspots/ --- ## List Empty Directories as Cleanup Candidates Empty directories are low-risk candidates, but they still deserve a preview. Command: `find /lab/disk-inode-cleanup/var/cache/app -xdev -depth -type d -empty -print` A cache tree may contain abandoned empty directories and you need to review them before cleanup. Question: Do you treat empty directories as safe to remove, or do you check app expectations first? Preview empty paths before pruning.: https://linuxoneliners.com/lessons/disk-cleanup-list-empty-directories/ --- ## Exclude the Current Release from Cleanup Release cleanup should prove what current points to before listing old directories. Command: `current=$(readlink -f /lab/disk-inode-cleanup/home/deploy/current); find /lab/disk-inode-cleanup/home/deploy/releases -mindepth 1 -maxdepth 1 -type d ! -samefile "$current" -printf '%TY-%Tm-%Td %p\n' | sort` Several release directories exist and you need to identify stale candidates without touching the active symlink target. Question: What is your guardrail before deleting old release directories? Resolve current first, then list candidates.: https://linuxoneliners.com/lessons/disk-cleanup-protect-current-release/ --- ## Rank Old Cleanup Candidates by Size The oldest file is not always the file that buys back meaningful space. Command: `find /lab/disk-inode-cleanup/var -xdev -type f -mtime +7 -printf '%s %TY-%Tm-%Td %p\n' | sort -nr | head` You have old files in a cleanup path and need to review the largest candidates first without deleting anything. Question: When disk cleanup is urgent, do you review oldest files first or largest old files first? Sort candidates by impact before deletion.: https://linuxoneliners.com/lessons/disk-cleanup-rank-old-files-by-size/ --- ## Review Log Files Before Cleanup Before truncating logs, prove which log files are large and how old they are. Command: `find /lab/disk-inode-cleanup/var/log -xdev -type f -printf '%10s %TY-%Tm-%Td %p\n' | sort -nr` Log files are suspected during disk pressure and you need a compact review list before changing retention or truncating anything. Question: Do you check log size and age before truncating during disk incidents? Make log cleanup evidence-based.: https://linuxoneliners.com/lessons/disk-cleanup-review-log-file-growth/ --- ## Summarize Cache File Ages Cache cleanup is safer when you know whether files are stale or still active. Command: `find /lab/disk-inode-cleanup/var/cache/app -xdev -type f -printf '%TY-%Tm-%Td\n' | sort | uniq -c` A cache tree is using many inodes and you need to see file age distribution before deciding on a retention threshold. Question: Do you choose cache cleanup thresholds from file age data or from habit? Summarize cache age before cleanup.: https://linuxoneliners.com/lessons/disk-cleanup-summarize-cache-file-ages/ --- ## Print a Dry-Run Removal Script The reviewable cleanup command is the one you print before you run. Command: `find /lab/disk-inode-cleanup/var/tmp/uploads -xdev -type f -mtime +7 -printf 'rm -i -- %p\n'` You have cleanup candidates and need a human-reviewable removal plan instead of executing deletion directly from find. Question: Do you review generated cleanup commands before executing them? Print the removal plan before running it.: https://linuxoneliners.com/lessons/disk-cleanup-print-dry-run-removal-script/ --- ## Compare DNS Answers Across Resolvers One resolver can still have the old edge IP while another has the new one. Command: `for r in 1.1.1.1 8.8.8.8 9.9.9.9; do printf '%s ' "$r"; dig @"$r" +short edge.test A; done` A site behaves differently for different users and you need to compare DNS answers from multiple public resolvers. Question: When users hit different edge IPs, which resolvers do you compare first? Compare resolver answers before changing the server.: https://linuxoneliners.com/lessons/dns-compare-public-resolvers/ --- ## Compare Authoritative Nameserver Answers The recursive resolver was not the problem. One nameserver disagreed. Command: `for ns in $(dig +short NS edge.test); do printf '%s ' "$ns"; dig @"$ns" +short edge.test A; done` A domain has multiple authoritative nameservers and you need to see whether they return the same edge IP. Question: Have you traced a DNS issue back to mismatched authoritative nameservers? Query each nameserver directly.: https://linuxoneliners.com/lessons/dns-compare-authoritative-nameservers/ --- ## Show the DNS Answer TTL The fix was correct. The TTL explained why users still saw the old edge. Command: `dig +noall +answer edge.test A` You need to see how long a DNS answer can remain cached. Question: Do you check TTL before calling a DNS cutover broken? Look at the answer section.: https://linuxoneliners.com/lessons/dns-show-answer-ttl/ --- ## Check the WWW CNAME Target The apex was right. The www name pointed through a different path. Command: `dig +short www.edge.test CNAME` You need to see whether www is an alias and where it ultimately resolves. Question: Do you test apex and www as separate DNS paths? Check the CNAME before editing redirects.: https://linuxoneliners.com/lessons/dns-check-www-cname-target/ --- ## Compare A and AAAA Records IPv4 worked. IPv6 sent users to a different edge. Command: `printf 'A '; dig +short edge.test A; printf 'AAAA '; dig +short edge.test AAAA` A site works for some users but fails for IPv6-capable clients, so you need to compare IPv4 and IPv6 DNS. Question: How often do you check AAAA records during edge incidents? Compare address families before changing services.: https://linuxoneliners.com/lessons/dns-compare-a-and-aaaa/ --- ## Check CAA Certificate Issuers The certificate request failed because DNS allowed the wrong issuer. Command: `dig +short edge.test CAA` You need to see which certificate authorities are allowed to issue for a domain. Question: Do you check CAA records before changing ACME tooling? Inspect issuer policy in DNS.: https://linuxoneliners.com/lessons/dns-check-caa-issuers/ --- ## Show TLS Certificate Dates The outage was not the web server. The edge certificate had expired. Command: `openssl s_client -connect edge.test:443 -servername edge.test /dev/null | openssl x509 -noout -dates` You need to read the served TLS certificate validity window. Question: Do you inspect the served certificate or the local cert file first? Read dates from the live TLS handshake.: https://linuxoneliners.com/lessons/tls-show-certificate-dates/ --- ## Show TLS Certificate Names The cert was valid, but not for this hostname. Command: `openssl s_client -connect edge.test:443 -servername edge.test /dev/null | openssl x509 -noout -subject -ext subjectAltName` You need to inspect the certificate subject and SAN names served for a hostname. Question: When TLS fails, do you check expiry or SAN coverage first? Inspect the served certificate names.: https://linuxoneliners.com/lessons/tls-show-certificate-names/ --- ## Check the Certificate Served for SNI The IP was right. The SNI name selected the wrong certificate. Command: `openssl s_client -connect 203.0.113.10:443 -servername wrong.edge.test /dev/null | openssl x509 -noout -subject -ext subjectAltName` You need to prove which certificate an edge returns for a specific SNI hostname. Question: Have you debugged a TLS issue that was really missing or wrong SNI? Test the exact server name.: https://linuxoneliners.com/lessons/tls-check-sni-certificate/ --- ## Show TLS Protocol and Cipher The certificate was fine. The TLS negotiation told the rest of the story. Command: `openssl s_client -connect edge.test:443 -servername edge.test /dev/null | awk '/Protocol|Cipher|Verify return code/ {print}'` You need to see which TLS protocol and cipher the edge negotiates. Question: What is your quickest TLS negotiation check during an incident? Print protocol, cipher, and verify result.: https://linuxoneliners.com/lessons/tls-show-protocol-and-cipher/ --- ## Show Containers in a Clean Triage Table Turn noisy docker ps output into the few fields operators scan first. Command: `docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}\t{{.Ports}}'` You need a fast view of container state, image, uptime, and published ports without wrapped columns hiding the important parts. Question: What fields do you always want in your first Docker triage view? Save this for the next time docker ps output is too noisy to scan.: https://linuxoneliners.com/lessons/docker-ps-human-table/ --- ## Find Restarting Containers Fast Restart loops hide in plain sight unless you filter for them. Command: `docker ps -a --filter status=restarting --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'` A service is unstable and you need to quickly identify containers stuck restarting. Question: Do you check restart loops before digging into app logs? Keep this one-liner handy for outage triage.: https://linuxoneliners.com/lessons/docker-restarting-containers/ --- ## Check Container Health Status Docker may say a container is running while its health check says otherwise. Command: `docker inspect --format '{{.Name}} health={{if .State.Health}}{{.State.Health.Status}}{{else}}none{{end}} status={{.State.Status}}' web` You need to see health-check state without opening a full inspect dump. Question: How often do you see running containers that are still unhealthy? Add this to your Docker incident checklist.: https://linuxoneliners.com/lessons/docker-container-health-status/ --- ## Read Recent Container Logs Skip the million-line log scroll and read only the recent failure window. Command: `docker logs --since 10m --tail 100 api` A container is failing and full logs are too large or too noisy. Question: What time window do you usually start with when reading container logs? Use this pattern before opening full logs.: https://linuxoneliners.com/lessons/docker-tail-recent-logs/ --- ## Snapshot Container CPU and Memory Get Docker resource usage once, without leaving a live dashboard running. Command: `docker stats --no-stream --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}'` You need a quick CPU and memory snapshot for running containers. Question: Do you prefer one-shot resource snapshots or live terminal dashboards during incidents? Save this for quick host pressure checks.: https://linuxoneliners.com/lessons/docker-stats-once/ --- ## Show Published Container Ports When a service is unreachable, confirm Docker is publishing the port you think it is. Command: `docker port web` You need to map container ports to host ports without scanning firewall rules. Question: What is your first check when a containerized web service is unreachable? Keep this command in your web service triage notes.: https://linuxoneliners.com/lessons/docker-port-map/ --- ## Summarize Docker Disk Usage See how Docker storage is split across images, containers, volumes, and cache. Command: `docker system df -v` The host disk is full and you need a safe storage summary before cleanup. Question: What Docker storage category has surprised you most during disk incidents? Run this before reaching for cleanup commands.: https://linuxoneliners.com/lessons/docker-system-df-verbose/ --- ## Inspect Container Environment Names Check what environment variables exist without printing their secret values. Command: `docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' api | sed 's/=.*$/=/'` You need to know whether expected env vars are present, but dumping values may expose credentials. Question: Have you seen secrets accidentally pasted from docker inspect output? Use redacted config checks when sharing triage output.: https://linuxoneliners.com/lessons/docker-container-env-redacted/ --- ## See Container Network Attachments A container can be healthy and still attached to the wrong network. Command: `docker inspect --format '{{.Name}} {{range $name, $net := .NetworkSettings.Networks}}{{$name}} {{$net.IPAddress}} {{end}}' api` Services cannot reach each other and you need to confirm container network membership. Question: How often are container networking bugs really attachment or naming issues? Add this to your container connectivity checklist.: https://linuxoneliners.com/lessons/docker-network-container-map/ --- ## Review Recent Docker Events Docker keeps a recent event trail for starts, stops, pulls, and health changes. Command: `docker events --since 30m --until 0s` Something changed on the host and you need a quick timeline of recent Docker activity. Question: Do you check Docker events during incident timelines? Try this before digging through every service log.: https://linuxoneliners.com/lessons/docker-events-recent/ --- ## Read UFW Policy Verbosely The firewall was active, but the defaults mattered more than the rule list. Command: `ufw status verbose` You need the UFW default policy, logging state, and allowed inbound rules in one readable snapshot. Question: Do you check firewall defaults before reading individual rules? Start exposure triage with the policy snapshot.: https://linuxoneliners.com/lessons/firewall-ufw-status-verbose/ --- ## List Numbered UFW Rules Numbered rules make firewall review less ambiguous. Command: `ufw status numbered` You need a compact, ordered UFW rule list that can be discussed or reviewed without editing anything. Question: Do you capture numbered firewall rules before changing UFW? Use numbered output for review, not guesswork.: https://linuxoneliners.com/lessons/firewall-ufw-numbered-rules/ --- ## Show the nftables Input Chain The packet path was hiding below UFW. Command: `nft list ruleset | sed -n '/chain input/,/}/p'` You need to inspect the nftables input chain policy and the key accept or drop rules. Question: When UFW output is not enough, do you inspect nftables directly? Read the input chain before changing policy.: https://linuxoneliners.com/lessons/firewall-nft-input-policy/ --- ## Show iptables INPUT Rules Legacy firewall state can still explain live exposure. Command: `iptables -S INPUT` You need a concise view of the iptables INPUT chain policy and rules. Question: Do you still check iptables on mixed firewall hosts? Capture the INPUT chain before editing rules.: https://linuxoneliners.com/lessons/firewall-iptables-input-rules/ --- ## List Listening TCP Sockets Firewall rules matter after you know what is listening. Command: `ss -ltnp` You need to see which TCP sockets are listening and which process owns each one. Question: Do you list listening sockets before changing firewall rules? Pair socket state with firewall policy.: https://linuxoneliners.com/lessons/exposure-list-listening-sockets/ --- ## Show Publicly Bound Listeners Localhost services are different from public listeners. Command: `ss -ltnp | awk 'NR==1 || $4 ~ /^(0[.]0[.]0[.]0|[[]::[]]|[*]):/'` You need to filter listening sockets down to services bound on all interfaces or IPv6 wildcard addresses. Question: Do you separate localhost listeners from public bind addresses during exposure checks? Build the public listener worklist first.: https://linuxoneliners.com/lessons/exposure-public-listeners-only/ --- ## Find Allowed Ports with No Listener An open firewall rule can outlive the service it was created for. Command: `comm -23 <(ufw status numbered | awk '/ALLOW/ {print}' | grep -Eo '[0-9]+/(tcp|udp)' | cut -d/ -f1 | sort -u) <(ss -ltnp | awk '/LISTEN/ {n=split($4,a,":"); print a[n]}' | sort -u)` You need to find UFW-allowed ports that do not currently have a listening TCP socket. Question: Do you look for firewall allow rules that no current listener uses? Compare firewall policy with socket state.: https://linuxoneliners.com/lessons/firewall-allowed-ports-without-listeners/ --- ## Find Public Listeners Not Allowed by UFW The process was public, but the firewall did not mention it. Command: `comm -13 <(ufw status numbered | awk '/ALLOW/ {print}' | grep -Eo '[0-9]+/(tcp|udp)' | cut -d/ -f1 | sort -u) <(ss -ltnp | awk '$4 ~ /^(0[.]0[.]0[.]0|[[]::[]]|[*]):/ {n=split($4,a,":"); print a[n]}' | sort -u)` You need to find publicly bound listening ports that are not listed as UFW allow rules. Question: Do you compare public listeners against firewall allow rules during hardening? Find services outside the declared policy.: https://linuxoneliners.com/lessons/exposure-public-listeners-not-in-ufw/ --- ## Check Whether SSH Is Publicly Bound SSH can be locked down by source and still bind publicly. Command: `ss -ltnp | awk '$4 ~ /:22$/ && $4 !~ /^127[.]/ {print}'` You need to see whether SSH is listening on a non-localhost address. Question: Do you check SSH bind address separately from firewall allow sources? Review SSH exposure with both views.: https://linuxoneliners.com/lessons/ssh-public-exposure-check/ --- ## Show Local-Only Database Listeners The database was listening, but only on localhost. Command: `ss -ltnp | awk '$4 ~ /^127[.]0[.]0[.]1:(5432|3306|6379)$/ {print}'` You need to confirm common database ports are bound only to 127.0.0.1. Question: Do you verify database bind addresses before touching firewall rules? Check local-only listeners first.: https://linuxoneliners.com/lessons/db-local-only-listeners/ --- ## Snapshot Git Status Before Recovery Before rollback commands, capture the branch and dirty files. Command: `cd /lab/git-recovery-rollback && git status --short --branch` An incident starts with an unknown working tree, and you need to see whether local edits could be overwritten by recovery work. Question: Do you snapshot git status before incident rollback work? Keep rollback commands reviewable.: https://linuxoneliners.com/lessons/git-incident-status-snapshot/ --- ## Map Recent Release Commits A rollback is easier when the last few release tags are visible. Command: `cd /lab/git-recovery-rollback && git log --oneline --decorate --graph --all -8` You need to see which tagged release commits exist before choosing a rollback target. Question: What command do you use to find the rollback target commit? Add tag visibility to incident triage.: https://linuxoneliners.com/lessons/git-map-recent-release-history/ --- ## Show Files Changed Since Last Good Release Compare the suspect release against the last known-good tag. Command: `cd /lab/git-recovery-rollback && git diff --name-status release-2026-06-25-1000..HEAD` A new release is suspect, and you need a quick list of files changed after the last stable release. Question: During rollback triage, do you inspect changed files before reverting? Make rollback scope explicit.: https://linuxoneliners.com/lessons/git-show-files-since-last-good-release/ --- ## Find a Discarded Commit in Reflog A reset does not mean the commit vanished. Command: `cd /lab/git-recovery-rollback && git reflog --date=iso --format='%h %gd %gs' -6` Someone ran reset during incident work and you need to locate the commit that disappeared from the branch tip. Question: Have you recovered a commit from reflog during an incident? Remember reflog before recreating work.: https://linuxoneliners.com/lessons/git-reflog-find-discarded-commit/ --- ## Branch a Recovered Commit Put a name on the reflog commit before it slips away. Command: `cd /lab/git-recovery-rollback && git branch recovered-incident-note HEAD@{1}` You found a useful discarded commit in reflog and need to preserve it with a branch name. Question: When you find lost work in reflog, do you branch it immediately? Turn temporary recovery into a named ref.: https://linuxoneliners.com/lessons/git-branch-recovered-commit/ --- ## Restore One File From Last Good Release Recover a config file without rolling back the whole branch. Command: `cd /lab/git-recovery-rollback && git restore --source=release-2026-06-25-1000 -- app/config.yml` One file is dirty or suspect, and you want to restore just that path from a known-good release tag. Question: Do you use targeted file restores during release incidents? Recover the smallest useful surface.: https://linuxoneliners.com/lessons/git-restore-file-from-last-good-release/ --- ## Check the Active Release Symlink Git may say one thing while the release pointer serves another. Command: `cd /lab/git-recovery-rollback && readlink releases/current && cat releases/current/VERSION` A deployment uses release directories and a current symlink, and you need to confirm which release is active. Question: Does your rollback checklist verify the active release pointer? Check deploy state outside Git too.: https://linuxoneliners.com/lessons/release-check-current-symlink-target/ --- ## Rollback a Release Symlink in a Sandbox Practice the pointer switch where the blast radius is zero. Command: `cd /lab/git-recovery-rollback && ln -sfn 2026-06-25-1000 releases/current` You need to rehearse a symlink-style rollback by pointing current at the previous stable release directory. Question: Have you rehearsed your symlink rollback command outside production? Practice rollback where mistakes are cheap.: https://linuxoneliners.com/lessons/release-rollback-current-symlink-in-sandbox/ --- ## Preview the Patch a Rollback Would Apply Show the exact file changes before moving the branch back. Command: `cd /lab/git-recovery-rollback && git diff --stat HEAD..release-2026-06-25-1000` You know the last good release tag, but you want to inspect what a rollback would remove before changing anything. Question: Do you preview rollback patches before changing refs? Make the rollback diff part of incident review.: https://linuxoneliners.com/lessons/git-preview-rollback-patch/ --- ## Revert the Suspect Release Commit Undo a bad release with a new commit instead of rewriting history. Command: `cd /lab/git-recovery-rollback && git restore -- app/config.yml && git revert --no-edit release-2026-06-25-1030` The suspect release has already been shared, and you need a rollback commit that preserves branch history. Question: When do you prefer git revert over resetting a release branch? Use forward-moving rollback commits for shared history.: https://linuxoneliners.com/lessons/git-revert-suspect-release-commit/ --- ## Test Nginx Before Reload The config looked fine. Nginx disagreed before reload broke anything. Command: `nginx -t` You changed an Nginx config and need to validate syntax before reloading the service. Question: Do you run `nginx -t` before every reload? Full Nginx syntax check demo: https://linuxoneliners.com/lessons/nginx-test-config/ --- ## Show Enabled Nginx Sites The config existed, but it was not enabled. Command: `ls -l /etc/nginx/sites-enabled/` You need to see which Nginx site configs are actually enabled. Question: Have you ever edited the available site instead of the enabled one? Full enabled-sites demo: https://linuxoneliners.com/lessons/nginx-show-enabled-sites/ --- ## Find Which Nginx Config Owns a Domain The wrong server block was answering the domain. Command: `grep -R "server_name" /etc/nginx/sites-enabled/` You need to find which Nginx config contains a domain's `server_name`. Question: What do you check first when Nginx serves the wrong site? Full server_name search demo: https://linuxoneliners.com/lessons/nginx-find-server-name/ --- ## Check HTTP to HTTPS Redirect HTTPS worked. The plain HTTP redirect still mattered. Command: `curl -I http://example.com` You need to confirm that plain HTTP redirects to HTTPS. Question: Do you test HTTP redirects after setting up SSL? Full redirect check demo: https://linuxoneliners.com/lessons/check-http-redirect/ --- ## Inspect Response Headers The page loaded, but the headers told the operational story. Command: `curl -sI https://example.com` You need to inspect server and security headers quickly. Question: Which header do you check first on a new site? Full response header demo: https://linuxoneliners.com/lessons/inspect-response-headers/ --- ## Check a Domain A Record The site was fine. The domain was pointed somewhere else. Command: `dig +short example.com A` You need to see the IPv4 address a domain currently resolves to. Question: When a site disappears, do you check DNS before Nginx? Full A-record demo: https://linuxoneliners.com/lessons/dig-a-record/ --- ## List Certbot Certificates The certificate existed. The question was which domains it covered. Command: `certbot certificates` You need to see Certbot-managed certificates and included domains. Question: Do you check Certbot inventory before changing SSL config? Full Certbot inventory demo: https://linuxoneliners.com/lessons/certbot-list-certs/ --- ## Check the Current Release Symlink The deploy finished. The symlink told me what was actually live. Command: `readlink -f /srv/www/example.com/current` You need to verify which release directory a site is serving. Question: Do your deploys expose a current symlink or release marker? Full release symlink demo: https://linuxoneliners.com/lessons/check-nginx-symlink-target/ --- ## Find Top 404 URLs The missing file was not random. The access log had a pattern. Command: `awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head` You need to see which URLs are producing 404 responses. Question: Do you check 404s after deploys? Full Nginx 404 demo: https://linuxoneliners.com/lessons/nginx-find-404s/ --- ## See Top Referrers LinkedIn traffic was not a guess. The referrer field showed it. Command: `awk -F'"' '{print $4}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head` You need a rough look at which referrers are sending requests. Question: Do you trust platform analytics, server logs, or both? Full referrer-count demo: https://linuxoneliners.com/lessons/watch-access-by-referrer/ --- ## Summarize Journal Severity During an Incident Start with severity counts before opening every log line. Command: `journalctl -p warning..alert --since "2 hours ago" --no-pager -o short-iso | awk '{count[$4]++} END {for (level in count) print count[level], level}' | sort -nr` An alert fired and you need to know whether the recent journal is mostly warnings, errors, or critical failures. Question: When an alert fires, do you start with individual log lines or a severity summary? Add this to your first-response checklist.: https://linuxoneliners.com/lessons/incident-journal-severity-summary/ --- ## Group Journal Errors by Unit A noisy incident usually has a noisy source. Command: `journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{split($3,a,"["); unit=a[1]; count[unit]++} END {for (u in count) print count[u], u}' | sort -nr` Recent journal errors mention several processes and you need to see which unit or source is producing most of them. Question: What is your quickest way to find the noisiest service during an incident? Use grouping before scrolling.: https://linuxoneliners.com/lessons/incident-journal-errors-by-unit/ --- ## Print a Critical Journal Timeline Timeline beats guesswork when several failures happen close together. Command: `journalctl -p err..alert --since "2 hours ago" --no-pager -o short-iso | awk '{print $1, $3, $4, substr($0,index($0,$5))}'` You need a compact timeline of severe journal lines with timestamp, source, priority, and message. Question: During incidents, what do you use to reconstruct the first failing event? Start with a compact journal timeline.: https://linuxoneliners.com/lessons/incident-journal-critical-timeline/ --- ## Show Context Around the First App Error The first error often explains more than the last one. Command: `awk '{buf[NR%5]=$0} tolower($0) ~ /(error|exception|fatal)/ {for (i=NR-4;i<=NR;i++) if (i>0) print buf[i%5]; exit}' fixtures/incidents/app.log` An application log has many lines, and you need the few lines leading into the first error. Question: Do you inspect the first failure or the loudest repeated failure first? Use this when repeated errors hide the original clue.: https://linuxoneliners.com/lessons/incident-first-error-context/ --- ## Count App Errors by Minute A minute-by-minute count shows whether an incident is a spike or a drip. Command: `awk 'tolower($0) ~ /(error|fatal|timeout|exception)/ {minute=substr($1,1,16); count[minute]++} END {for (m in count) print count[m], m}' fixtures/incidents/app.log | sort -nr` You need to see when severe application log lines clustered during an incident. Question: When logs show errors, do you bucket them by time before reading each line? Use minute buckets for quick incident shape.: https://linuxoneliners.com/lessons/incident-error-rate-by-minute/ --- ## Count Request IDs in Error Lines Repeated request IDs can connect separate error lines to one failing path. Command: `grep -Ei 'error|timeout|fatal|exception' fixtures/incidents/app.log | awk '{for (i=1;i<=NF;i++) if ($i ~ /^request_id=/) print $i}' | sort | uniq -c | sort -nr` An app log includes request IDs, and you need to see which failing request appears more than once. Question: Do your production logs include request IDs on every error path? Use IDs to connect the failure chain.: https://linuxoneliners.com/lessons/incident-request-ids-in-errors/ --- ## Build a Deploy and Restart Timeline Deploys and restarts are incident landmarks. Command: `grep -Eh 'deploy|release|restart|started|stopped|rolled back' fixtures/incidents/*.log | sort` You need to compare deploy activity, restarts, and rollbacks against application errors. Question: Do you put deploy and restart events next to errors during incident review? Build the timeline before deciding cause.: https://linuxoneliners.com/lessons/incident-deploy-restart-timeline/ --- ## Spot OOM Kills in the Kernel Journal Exit code 137 often means the kernel has something to say. Command: `journalctl -k --since "2 hours ago" --no-pager -o short-iso | grep -Ei 'out of memory|oom|killed process'` A worker exited during an incident and you need to check whether the kernel killed it for memory pressure. Question: When a worker exits with 137, do you check app logs or kernel logs first? Look for OOM evidence before guessing.: https://linuxoneliners.com/lessons/incident-oom-kills-from-journal/ --- ## Find the Noisiest Incident Log Files The biggest log is not always right, but it is worth knowing. Command: `wc -l fixtures/incidents/*.log | sort -nr` Several incident log files exist and you need to know which ones have the most lines before opening them. Question: Do you check log volume before opening multi-file incident logs? Use line counts as a quick noise map.: https://linuxoneliners.com/lessons/incident-noisy-log-files/ --- ## Redact Secret-Looking Log Lines Incident notes should not copy secrets forward. Command: `grep -RInE '(password=|token=|secret=|Authorization: Bearer)' fixtures/incidents | awk '{gsub(/password=[^ ]+/, "password=REDACTED"); gsub(/token=[^ ]+/, "token=REDACTED"); gsub(/secret=[^ ]+/, "secret=REDACTED"); gsub(/Authorization: Bearer [A-Za-z0-9._-]+/, "Authorization: Bearer REDACTED"); print}'` Logs may contain token, password, secret, or bearer values and you need a safer view before sharing snippets. Question: What redaction check do you run before sharing incident log snippets? Make redaction part of the triage habit.: https://linuxoneliners.com/lessons/incident-redact-secret-looking-log-lines/ --- ## Find Writable Directories Missing the Sticky Bit A writable log directory is not the same thing as a safe shared directory. Command: `find fixtures/perm-audit -type d -perm -0002 ! -perm -1000 -printf '%m %u:%g %p\n' | sort` You need to find directories that any user can write to, but where users can also rename or delete each other's files. Question: Do you check sticky-bit gaps separately from world-writable paths? Audit shared write paths before changing modes.: https://linuxoneliners.com/lessons/audit-world-writable-dirs-without-sticky-bit/ --- ## Find Release Files Writable Outside the Owner A release file that someone besides the owner can modify deserves a second look. Command: `find fixtures/perm-audit/releases/2026-06-25 -type f -perm /0022 -printf '%M %u:%g %p\n' | sort` You need to spot files under a release directory that are writable by group or other users. Question: Do you check release files for group or world write bits before chmod cleanup? Find broad write access before changing permissions.: https://linuxoneliners.com/lessons/audit-release-files-writable-outside-owner/ --- ## Find Runtime Directories Writable Outside the Owner Runtime directories often need writes, but the write boundary should be visible. Command: `find fixtures/perm-audit/releases/2026-06-25/storage fixtures/perm-audit/releases/2026-06-25/uploads -type d -perm /0022 -printf '%M %u:%g %p\n' | sort` You need to review storage, cache, log, and upload directories that are writable by group or other users. Question: Do you separate runtime write paths from static release files during permission audits? Review writable directories before broad chmod fixes.: https://linuxoneliners.com/lessons/audit-writable-runtime-directories/ --- ## Find SUID, SGID, and Sticky Bits in an App Tree Special bits are easy to miss in a long ls listing. Command: `find fixtures/perm-audit -perm /7000 -printf '%M %m %u:%g %p\n' | sort` You need a compact inventory of files and directories with SUID, SGID, or sticky bits set. Question: How often do you inventory SUID and SGID files outside system paths? List special bits before hardening.: https://linuxoneliners.com/lessons/audit-special-permission-bits/ --- ## Group Writable Files by Owning Group Group-writable files are not automatically wrong, but the owning group decides the risk. Command: `find fixtures/perm-audit -type f -perm -0020 -printf '%g %M %p\n' | sort` You need to see which groups can modify files under an application tree. Question: Do you review group-writable files by group name or just by mode? Start the audit with group context.: https://linuxoneliners.com/lessons/audit-group-writable-files-by-group/ --- ## Trace Every Parent Directory on a Permission Denial The file mode can look fine while a parent directory blocks the whole path. Command: `namei -l fixtures/perm-audit/current/app/config/prod.token` You need to inspect each directory component in a path to find where traversal permission fails. Question: When permission denied makes no sense, do you check parent directories first? Trace the path before changing modes.: https://linuxoneliners.com/lessons/trace-permission-denial-with-namei/ --- ## Find World-Readable Secret-Looking Files The fastest secret audit starts with readable files that look like secrets. Command: `find fixtures/perm-audit -type f -perm -0004 \( -iname '*secret*' -o -iname '*.env' -o -iname '*token*' -o -iname '*key*' \) -printf '%M %u:%g %p\n' | sort` You need to find files with sensitive names that are readable by everyone. Question: What filename patterns do you include in a fast secret-permission audit? Triage readable secrets before broader scanning.: https://linuxoneliners.com/lessons/audit-world-readable-secrets/ --- ## Find Config Files with Execute Bits Config files do not usually need to be executable. Command: `find fixtures/perm-audit -type f -perm /111 \( -path '*/config/*' -o -name '*.env' -o -name '*.conf' \) -printf '%M %u:%g %p\n' | sort` You need to find non-binary configuration files that accidentally have execute permissions. Question: Do you flag executable config files in release audits? List suspicious execute bits before cleanup.: https://linuxoneliners.com/lessons/audit-executable-config-files/ --- ## Audit a Symlink Permission Chain A symlink can make the path you audited different from the file the app opens. Command: `find fixtures/perm-audit -type l -printf '%p -> %l\n' -exec namei -l {} \;` You need to inspect symlink targets and every parent directory before deciding whether permissions are wrong. Question: Do release symlinks make your permission audits harder? Trace symlink targets before changing ownership.: https://linuxoneliners.com/lessons/audit-symlink-permission-chain/ --- ## Find Upload Files Writable Outside the Owner Uploads are supposed to be writable at the edge, not writable forever by everyone. Command: `find fixtures/perm-audit/releases/2026-06-25/uploads -type f -perm /0022 -printf '%M %u:%g %p\n' | sort` You need to find uploaded files that group or other users can still modify. Question: Do you audit upload files separately from the upload directory itself? Check writable uploads before broad chmod fixes.: https://linuxoneliners.com/lessons/audit-public-writeable-upload-files/ --- ## Find the Processes Burning CPU A server feels slow, but you need proof before restarting anything. Command: `ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pcpu | head -n 10` You need to identify which processes are using the most CPU without changing system state. Question: What is your first proof point before restarting a slow service? Start with a read-only CPU snapshot before changing state.: https://linuxoneliners.com/lessons/find-top-cpu-processes-with-ps/ --- ## Find the Processes Eating Memory Memory pressure can look like a slow app, a stuck deploy, or random crashes. Command: `ps -eo pid,ppid,stat,pcpu,pmem,rss,comm,args --sort=-pmem | head -n 10` You need to see which processes are using the most RAM. Question: When memory is tight, do you inspect total memory first or top processes first? Use both: free for pressure, ps for suspects.: https://linuxoneliners.com/lessons/find-top-memory-processes-with-ps/ --- ## Check Memory Pressure with free Linux memory numbers look scary until you know which column matters. Command: `free -h` You need to tell whether the system is actually low on available memory. Question: Which free column do you check first during memory triage? Treat available memory as the first quick read.: https://linuxoneliners.com/lessons/check-memory-pressure-with-free/ --- ## Read Load Average Before You React A high load number is a clue, not a diagnosis. Command: `uptime` You need a fast snapshot of system load and how long the machine has been running. Question: Do you read load average as a trend or a single number? Compare the 1, 5, and 15 minute values before reacting.: https://linuxoneliners.com/lessons/read-load-average-with-uptime/ --- ## Check Filesystem Space with df A full disk can break logins, uploads, databases, and deploys. Command: `df -h` You need to see which mounted filesystem is low on space. Question: What usually fills first on your VPS: logs, uploads, cache, or database files? Use df first, then narrow with du.: https://linuxoneliners.com/lessons/check-disk-space-with-df/ --- ## Check Inodes When Disk Space Looks Fine Sometimes the disk has free bytes but still cannot create files. Command: `df -ih` You need to check whether a filesystem has run out of inodes. Question: Have you hit inode exhaustion on a server that still had free GB? Add df -ih to your disk triage checklist.: https://linuxoneliners.com/lessons/check-inode-pressure-with-df-i/ --- ## Find Large Directories with du Once you know a filesystem is full, the next question is where. Command: `du -xh --max-depth=1 /var 2>/dev/null | sort -h` You need to identify which top-level directory is using the most space. Question: Do you start disk hunts at /, or narrow the path first? Keep recursive size scans scoped during incidents.: https://linuxoneliners.com/lessons/find-large-directories-with-du/ --- ## Find Listening Ports with ss Before blaming the firewall, check whether anything is actually listening. Command: `ss -ltnp` You need to list local TCP services that are accepting connections. Question: When a service is unreachable, do you check bind address before firewall rules? Use ss to prove what is listening locally.: https://linuxoneliners.com/lessons/find-listening-ports-with-ss/ --- ## Find Open Deleted Files with lsof A file can be deleted but still occupy disk while a process holds it open. Command: `lsof +L1` You need to spot deleted files still held by running processes after cleanup. Question: Have you ever deleted logs and wondered why disk space did not come back? Check for open deleted files before restarting services blindly.: https://linuxoneliners.com/lessons/find-open-deleted-files-with-lsof/ --- ## Inspect Established Network Connections Unexpected connections are easier to reason about when you can see them directly. Command: `ss -tan state established` You need to list established TCP connections without changing network state. Question: Do you inspect established sockets during incident timelines? Use ss as a quick snapshot, then move to logs for history.: https://linuxoneliners.com/lessons/inspect-established-connections-with-ss/ --- ## Show the Real User Cron Jobs Cron problems often hide behind comments, blank lines, and copied folklore. Command: `crontab -l | sed -n '/^[[:space:]]*#/d;/^[[:space:]]*$/d;p'` You need to inspect a user's scheduled cron commands without editing the crontab. Question: When a cron job misbehaves, do you check the user crontab or system cron first? Save this as the first cron triage step.: https://linuxoneliners.com/lessons/cron-list-active-user-crontab/ --- ## Find System Cron Files Fast A job can be nowhere in your crontab and still run every night. Command: `find /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly -maxdepth 1 -type f -print 2>/dev/null | sort` System cron jobs can live in /etc/cron.d and periodic directories, so checking only crontab -l misses them. Question: How often do you find production jobs hiding outside user crontabs? Add this to your scheduler audit checklist.: https://linuxoneliners.com/lessons/cron-find-system-job-files/ --- ## Turn Cron Into a Readable Table Cron is easier to debug when the schedule and command stop blending together. Command: `crontab -l | awk 'NF && $1 !~ /^#/ {printf "%-16s %s\n", $1" "$2" "$3" "$4" "$5, substr($0,index($0,$6))}'` Raw crontab lines are hard to scan during an incident, especially with long commands. Question: Do you mentally parse cron fields, or do you format them before reviewing? Use this for fast cron reviews.: https://linuxoneliners.com/lessons/cron-map-schedules-to-commands/ --- ## Find Cron Jobs With No Log Trail A silent cron job is a future incident with no witness. Command: `crontab -l | awk 'NF && $1 !~ /^#/ && $0 !~ /(>>|2>|logger|mail)/ {print}'` Cron jobs without redirects, mail, or logger calls can fail without leaving an obvious trail. Question: What is your minimum logging standard for cron jobs that touch production data? Use this as a cron observability audit.: https://linuxoneliners.com/lessons/cron-detect-silent-jobs-missing-logging/ --- ## Catch Cron Daily Files That Will Be Skipped A dot in a filename can keep a cron.daily script from running. Command: `run-parts --test /etc/cron.daily` run-parts only executes files matching its naming rules, so backup scripts with dots can be ignored. Question: Have you ever lost time to a cron.daily filename that run-parts ignored? Check periodic cron directories with --test.: https://linuxoneliners.com/lessons/cron-check-run-parts-names/ --- ## Map systemd Timers to Services A timer is only half the scheduled job. The service is the payload. Command: `systemctl list-timers --all --no-pager --plain | awk 'NR==1 || /\.timer/ {print $(NF-1), "->", $NF}'` systemctl list-timers shows timer units, but you need to see what service each timer activates. Question: When auditing scheduled work, do you map timers to services explicitly? Add timer activation mapping to your systemd checklist.: https://linuxoneliners.com/lessons/systemd-timer-map-activations/ --- ## Spot Stale systemd Timers The suspicious timer is the one with no next run. Command: `systemctl list-timers --all --no-pager --plain | awk 'NR==1 || $1=="n/a" || /backup\.timer|logrotate\.timer/'` A timer may exist but have no next scheduled run, which can hide disabled or stale automation. Question: Which timers on your servers would hurt if they silently stopped running? Use this for scheduled-job drift checks.: https://linuxoneliners.com/lessons/systemd-timer-find-stale-or-disabled/ --- ## Check the Last Timer Payload Logs When a timer fires, the useful logs are usually on the service. Command: `journalctl -u backup.service -n 20 --no-pager` A systemd timer appears scheduled, but you need the recent output from the service it activates. Question: Do you inspect timer units first or the activated service logs first? Use this pair for systemd timer incidents.: https://linuxoneliners.com/lessons/systemd-timer-check-last-service-logs/ --- ## Dry-Run Logrotate Before Touching Logs Logrotate can explain its plan without rotating anything. Command: `logrotate -d /etc/logrotate.conf 2>&1 | sed -n '/rotating pattern/p;/considering log/p;/error:/p'` You need to understand what logrotate would do without compressing, renaming, or truncating real logs. Question: Do you dry-run logrotate before changing rotation rules? Save this for disk and log-growth incidents.: https://linuxoneliners.com/lessons/logrotate-debug-without-rotating/ --- ## Find Logs Missing Logrotate Coverage The biggest log risk is often the file no policy mentions. Command: `find /var/log -type f -name '*.log' -printf '%p\n' | while read -r log; do grep -Rqs -- "$log" /etc/logrotate.conf /etc/logrotate.d || grep -Rqs -- "$(dirname "$log")/[*].log" /etc/logrotate.conf /etc/logrotate.d || printf '%s\n' "$log"; done` A log file can grow forever if no logrotate rule references it. Question: How do you check that every app log has a rotation policy? Use this as a first pass before manual policy review.: https://linuxoneliners.com/lessons/logrotate-find-unmanaged-logs/ --- ## List Tables in a SQLite Database Before querying a database file, see what tables are actually inside it. Command: `sqlite3 app.db ".tables"` You need a quick inventory of tables in a SQLite database. Question: What is your first command when someone hands you a SQLite file? Inventory tables before writing queries.: https://linuxoneliners.com/lessons/sqlite-list-tables/ --- ## Show One SQLite Table Schema A failed query is often just a wrong assumption about column names. Command: `sqlite3 app.db ".schema users"` You need to inspect the schema for one SQLite table. Question: Do you inspect table schema before writing incident queries? Let SQLite show the table shape first.: https://linuxoneliners.com/lessons/sqlite-show-users-schema/ --- ## Check SQLite Database Integrity When a SQLite-backed app behaves strangely, first rule out file corruption. Command: `sqlite3 app.db "PRAGMA integrity_check;"` You need a read-only integrity check for a SQLite database. Question: Do you run integrity checks after SQLite-backed apps crash? Rule out database damage early.: https://linuxoneliners.com/lessons/sqlite-check-integrity/ --- ## List SQLite User Tables Only System metadata tables can distract from the app tables you care about. Command: `sqlite3 app.db "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;"` You need to list normal tables from sqlite_master. Question: Do you prefer .tables or sqlite_master when scripting SQLite checks? Use sqlite_master when output shape matters.: https://linuxoneliners.com/lessons/sqlite-list-user-tables/ --- ## Count Rows in Key SQLite Tables A quick row count can reveal empty imports, runaway events, or missing data. Command: `sqlite3 app.db "SELECT 'users', count(*) FROM users UNION ALL SELECT 'orders', count(*) FROM orders UNION ALL SELECT 'events', count(*) FROM events;"` You need row counts for several important SQLite tables in one command. Question: Do you check row counts after restoring a SQLite backup? Use small count queries for a first sanity pass.: https://linuxoneliners.com/lessons/sqlite-count-key-tables/ --- ## Show Indexes on a SQLite Table Slow lookups often start with missing or misunderstood indexes. Command: `sqlite3 app.db "PRAGMA index_list('orders');"` You need to inspect indexes attached to one SQLite table. Question: Do you inspect existing indexes before adding a new one? Check table indexes before performance changes.: https://linuxoneliners.com/lessons/sqlite-show-order-indexes/ --- ## Show Recent SQLite Events For small apps, the quickest timeline may be inside the SQLite file. Command: `sqlite3 app.db "SELECT created_at, event_type FROM events ORDER BY created_at DESC LIMIT 5;"` You need the most recent event rows from a SQLite events table. Question: Do your small apps keep enough event data for local timeline checks? Use recent rows as one incident clue.: https://linuxoneliners.com/lessons/sqlite-show-recent-events/ --- ## Count SQLite Events by Type A noisy event type stands out faster when you group it. Command: `sqlite3 app.db "SELECT event_type, count(*) FROM events GROUP BY event_type ORDER BY count(*) DESC;"` You need to summarize event counts by event_type in SQLite. Question: When event volume changes, do you group by type before reading rows? Summarize first, then inspect examples.: https://linuxoneliners.com/lessons/sqlite-count-events-by-type/ --- ## Find Duplicate Emails in SQLite Duplicate account data is easier to spot with one grouped query. Command: `sqlite3 app.db "SELECT email, count(*) FROM users GROUP BY email HAVING count(*) > 1;"` You need to find duplicate email values in a SQLite users table. Question: Do you check duplicates after CSV imports into SQLite? Find duplicate keys before changing rows.: https://linuxoneliners.com/lessons/sqlite-find-duplicate-emails/ --- ## Back Up a SQLite Database File Copying a live SQLite file blindly can produce a bad backup. Command: `sqlite3 app.db ".backup backup/app.db"` You need to create a SQLite backup through sqlite3 instead of a raw file copy. Question: Do you use SQLite .backup before manual database fixes? Create and verify a backup before risky data work.: https://linuxoneliners.com/lessons/sqlite-backup-database-file/ --- ## Summarize SSH Auth Outcomes SSH logs get easier to read once accepted and failed methods are counted. Command: `awk '/sshd/ && /Accepted/ {print "accepted", $7} /sshd/ && /Failed password/ {print "failed", "password"} /sshd/ && /Failed publickey/ {print "failed", "publickey"}' logs/auth.log | sort | uniq -c | sort -nr` You need a quick count of successful and failed SSH authentication methods from an auth log. Question: Do you summarize SSH authentication outcomes before reading every auth log line? Turn noisy SSH logs into a small evidence table first.: https://linuxoneliners.com/lessons/ssh-auth-outcome-summary/ --- ## Find SSH Password Auth Exceptions A global password-auth setting can be changed later by a Match block. Command: `awk '/^Match /{ctx=$0} /^PasswordAuthentication|^AuthenticationMethods|^[[:space:]]+PasswordAuthentication|^[[:space:]]+AuthenticationMethods/ {print (ctx ? ctx : "global") ": " $0}' etc/ssh/sshd_config` You need to see whether sshd_config has password authentication exceptions under Match rules. Question: Do you check SSH Match blocks before assuming password auth is disabled everywhere? Read authentication directives with their context, not as isolated lines.: https://linuxoneliners.com/lessons/ssh-password-auth-exceptions/ --- ## List SSH Allow and Deny Rules SSH access can be shaped by users, groups, and Match blocks. Command: `grep -RhnE '^(AllowUsers|AllowGroups|DenyUsers|DenyGroups|Match )' etc/ssh` You need to find SSH allow-list and deny-list directives across the main config and include files. Question: Do you search sshd_config includes before changing SSH allow-list rules? Review all SSH access directives before editing one file.: https://linuxoneliners.com/lessons/ssh-access-allow-deny-rules/ --- ## Inventory SSH authorized_keys authorized_keys files are the practical list of who can use key-based SSH. Command: `find home -path '*/.ssh/authorized_keys' -exec awk '{print FILENAME, $1, $NF}' {} +` You need to list authorized key files and identify the key type plus comment for each entry. Question: Do you inventory authorized_keys comments before removing SSH access? Build the key inventory before changing account access.: https://linuxoneliners.com/lessons/ssh-authorized-keys-inventory/ --- ## List Accepted SSH Login Sources Successful SSH logins are the access events worth anchoring first. Command: `awk '/Accepted publickey/ {print $1, $2, $3, $9, $11}' logs/auth.log` You need to list accepted SSH public-key logins with user and source IP. Question: Do you anchor SSH triage on successful logins before reviewing failed attempts? List accepted SSH sources before changing access.: https://linuxoneliners.com/lessons/ssh-accepted-login-sources/ --- ## Show Failed SSH Public-Key Users A failed public-key attempt often points to stale keys or the wrong account. Command: `awk '/Failed publickey/ {print $9, $11}' logs/auth.log | sort | uniq -c | sort -nr` You need to extract users and source IPs from failed SSH public-key attempts. Question: Do you separate failed public-key SSH attempts from password guessing? Treat stale-key evidence differently from brute-force noise.: https://linuxoneliners.com/lessons/ssh-failed-publickey-users/ --- ## Summarize SSH Authorized Key Types Key inventory gets more useful when old key types stand out. Command: `find home -path '*/.ssh/authorized_keys' -exec awk '{print $1}' {} + | sort | uniq -c | sort -nr` You need to count SSH key algorithms used in authorized_keys files. Question: Do you summarize authorized SSH key types before planning key cleanup? Use key type counts as inventory, not as an automatic delete list.: https://linuxoneliners.com/lessons/ssh-authorized-key-type-summary/ --- ## Find Loose authorized_keys Modes SSH key access files should not be looser than intended. Command: `find home -path '*/.ssh/authorized_keys' -printf '%m %p\n' | awk '$1 > 600'` You need to find authorized_keys files with permissions broader than 600. Question: Do you check authorized_keys permissions during SSH access reviews? Find loose modes before editing keys or accounts.: https://linuxoneliners.com/lessons/ssh-authorized-keys-loose-modes/ --- ## Show SSH Auth Policy Order The order of Include, Match, and authentication directives changes how SSH policy reads. Command: `grep -nE '^(Include|Match |PubkeyAuthentication|PasswordAuthentication|AuthenticationMethods|[[:space:]]+(PasswordAuthentication|AuthenticationMethods))' etc/ssh/sshd_config` You need to see SSH authentication directives in file order, including Include and Match lines. Question: Do you read SSH authentication policy in file order when Match blocks are present? Check policy order before editing sshd_config.: https://linuxoneliners.com/lessons/ssh-auth-policy-order/ --- ## Extract SSH AllowUsers Accounts AllowUsers turns SSH access into an explicit account list. Command: `awk '/^AllowUsers/ {for (i = 2; i <= NF; i++) print $i}' etc/ssh/sshd_config` You need to extract each account named in an AllowUsers directive. Question: Do you extract SSH AllowUsers into a reviewable account list? Turn access directives into a simple checklist before editing.: https://linuxoneliners.com/lessons/ssh-allowusers-extract/ --- ## Find Duplicate Page Titles Duplicate titles make a static site harder to scan in search results and browser tabs. Command: `grep -Rho --include='*.html' '[^<]*' public | sed 's###;s###' | sort | uniq -c | sort -nr` You need to find repeated HTML title text across a built static site. Question: Do you catch duplicate titles from templates before deploy? Audit generated HTML, not just source templates.: https://linuxoneliners.com/lessons/find-duplicate-page-titles/ --- ## Find Pages Missing Canonical Links Canonical tags are easy to drop when templates branch. Command: `find public -name '*.html' -print | while read -r f; do grep -qi 'rel="canonical"' "$f" || echo "$f"; done` You need to list generated HTML pages that do not include a canonical link. Question: Have you had one template path silently drop canonical tags? Check the built files after template changes.: https://linuxoneliners.com/lessons/find-pages-missing-canonical/ --- ## Find Pages Marked noindex A leftover noindex can hide a page after launch. Command: `grep -Rni --include='*.html' 'noindex' public` You need to identify generated HTML pages that contain noindex directives. Question: Do you audit noindex before publishing a static site? Look for directives in the output directory.: https://linuxoneliners.com/lessons/find-noindex-pages/ --- ## Find Pages Missing Meta Descriptions Missing descriptions are usually a content template problem, not a mystery. Command: `find public -name '*.html' -print | while read -r f; do grep -qi 'name="description"' "$f" || echo "$f"; done` You need to list HTML pages without a meta description. Question: Do your generated posts all get descriptions, or only the main pages? Scan output HTML to catch template gaps.: https://linuxoneliners.com/lessons/find-pages-missing-meta-description/ --- ## List URLs from a Sitemap Before comparing sitemap coverage, print the URLs plainly. Command: `grep -o '[^<]*' public/sitemap.xml | sed 's###;s###'` You need to inspect the loc entries inside a sitemap without opening an XML viewer. Question: Do you inspect sitemap output after changing routes? Start with a plain URL list from sitemap.xml.: https://linuxoneliners.com/lessons/list-sitemap-urls/ --- ## Check robots.txt for a Sitemap Line A sitemap can exist and still be hard to discover. Command: `grep -n '^Sitemap:' public/robots.txt` You need to confirm robots.txt advertises the sitemap URL. Question: Do you check robots.txt after moving a static site between domains? Verify the Sitemap directive in the generated file.: https://linuxoneliners.com/lessons/check-robots-sitemap-line/ --- ## Find HTML Pages Missing from the Sitemap A page can exist in the build but never make it into the sitemap. Command: `find public -name '*.html' -print | sed 's#^public#https://example.com#' | while read -r url; do grep -q "$url" public/sitemap.xml || echo "$url"; done` You need to compare generated HTML files against sitemap URLs. Question: Do you compare generated pages against sitemap output? Catch pages that exist but are not advertised.: https://linuxoneliners.com/lessons/find-html-pages-missing-from-sitemap/ --- ## Find Broken Internal Links in Built HTML A broken internal link is easiest to catch before it becomes a 404. Command: `grep -Rho --include='*.html' 'href="/[^"]*"' public | sed 's#href="##;s#"##' | while read -r path; do test -e "public${path}" || echo "$path"; done | sort -u` You need to list internal href paths that do not exist in the static build. Question: Do you check broken internal links from the built output or source files? Audit the exact HTML you are about to serve.: https://linuxoneliners.com/lessons/find-broken-internal-links/ --- ## Find Pages Missing og:title Social previews often fail because one template missed Open Graph tags. Command: `find public -name '*.html' -print | while read -r f; do grep -qi 'property="og:title"' "$f" || echo "$f"; done` You need to list generated HTML pages without og:title metadata. Question: Do you audit Open Graph tags before sharing a new page? Check generated HTML, then preview the URL.: https://linuxoneliners.com/lessons/find-pages-missing-og-title/ --- ## Find Feed Links Missing from the Sitemap Your feed can advertise URLs that the sitemap never lists. Command: `grep -o 'https://example.com/[^<]*' public/feed.xml | sed 's###;s###' | while read -r url; do grep -q "$url" public/sitemap.xml || echo "$url"; done` You need to compare feed item links against sitemap entries. Question: Have you compared feed output against sitemap output after permalink changes? Cross-check generated discovery files together.: https://linuxoneliners.com/lessons/find-feed-links-missing-from-sitemap/ --- ## Show Failed systemd Units One command tells you which services systemd already knows are broken. Command: `systemctl --failed --no-pager` A VPS feels unhealthy, but checking services one by one wastes time and misses failed timers, mounts, and sockets. Question: What is the first command you run when a Linux server feels unhealthy? Save this for your next VPS incident checklist.: https://linuxoneliners.com/lessons/systemd-failed-units/ --- ## Inspect One Service Without Pager Traps Make systemctl status safe for scripts, screenshots, and quick incident notes. Command: `systemctl status nginx --no-pager --lines=30` systemctl status can open a pager, wrap awkwardly, or hide the prompt during a tense server check. Question: Do you prefer systemctl status or journalctl first when debugging one service? Keep this pattern handy for incident notes and clean screenshots.: https://linuxoneliners.com/lessons/service-status-no-pager/ --- ## Read Current-Boot Logs for One Service Ignore stale logs and inspect only what happened since this boot. Command: `journalctl -u nginx -b --no-pager -n 80` Old service logs can make a current incident look worse or point you at errors from last week. Question: How often have old logs sent you down the wrong debugging path? Add -b to your current-boot service checks.: https://linuxoneliners.com/lessons/journalctl-unit-since-boot/ --- ## Check systemd Journal Disk Usage Before deleting random logs, ask journald how much disk it owns. Command: `journalctl --disk-usage` Disk alerts often lead people to delete the wrong files without checking whether the systemd journal is the real consumer. Question: What is your safest first move during a Linux disk-space alert? Measure before cleanup. This one-liner is a good start.: https://linuxoneliners.com/lessons/journal-disk-usage/ --- ## Find Slow Services During Boot Find which units made your VPS boot slowly. Command: `systemd-analyze blame | head -20` A server comes back after reboot, but boot time feels long and there is no obvious culprit. Question: Which services usually dominate boot time on your servers? Use this as a lead list, not a final verdict.: https://linuxoneliners.com/lessons/slow-boot-services/ --- ## Check Whether a Service Starts at Boot Running now does not mean it will survive the next reboot. Command: `systemctl is-enabled nginx` A service is manually started during an incident, but nobody verifies whether systemd will start it after reboot. Question: Have you ever fixed a service only to lose it on reboot? Pair is-active with is-enabled when validating recovery.: https://linuxoneliners.com/lessons/service-enabled-at-boot/ --- ## Check If a Service Is Active Get a clean yes-or-no service state without the full status page. Command: `systemctl is-active nginx` Full status output is noisy when a script, checklist, or quick human check only needs the current active state. Question: What do you pair with systemctl is-active for a real production smoke check? Use this for service state, then verify the user-facing path.: https://linuxoneliners.com/lessons/service-active-check/ --- ## Show Recent Server Reboots Confirm whether the server actually rebooted and when. Command: `last -x reboot | head -5` After an outage, deploy, or provider event, you need evidence of reboot timing without guessing from logs. Question: Do you check reboot history during every unexplained outage? Add reboot history to your first five incident commands.: https://linuxoneliners.com/lessons/recent-reboots/ --- ## Check Memory Pressure Quickly See whether memory is actually tight before restarting services. Command: `free -h` A VPS feels slow, and people often restart daemons before checking whether memory pressure is the cause. Question: Which memory column do you trust first on Linux: free, used, or available? Teach newer operators to read available before reacting.: https://linuxoneliners.com/lessons/memory-pressure-summary/ --- ## List Upcoming systemd Timers Cron is not the only scheduler on modern Linux servers. Command: `systemctl list-timers --all --no-pager` Backups, renewals, and cleanup jobs may run as systemd timers, but they are easy to miss if you only inspect cron. Question: Which scheduled jobs on your servers moved from cron to systemd timers? Add systemd timers to your server audit checklist.: https://linuxoneliners.com/lessons/systemd-timers-due/ --- ## Read the Failure Cause in systemctl Status The status page often tells you the failed startup step before you open every log. Command: `systemctl status app-worker --no-pager --lines=50` A systemd service is failed and you need the active state, exit status, unit paths, and the most recent failure lines in one read-only check. Question: When a service fails, do you read systemctl status before opening the full journal? Use status as the first evidence snapshot.: https://linuxoneliners.com/lessons/systemd-status-failed-service-cause/ --- ## Print the Exact systemd Exit Fields Turn a noisy service failure into four fields you can paste into an incident note. Command: `systemctl show app-worker --property=Result,ExecMainCode,ExecMainStatus,NRestarts --no-pager` Full status output is useful for humans, but incident notes and scripts need compact fields like Result, ExecMainStatus, and restart count. Question: Which systemd fields do you capture in incident notes? Pair compact fields with the log line that explains them.: https://linuxoneliners.com/lessons/systemd-show-exit-result-fields/ --- ## Read Warning and Error Logs for One Failed Unit Filter a failed unit's journal to the lines most likely to explain the stop. Command: `journalctl -u app-worker -b -p warning..alert --no-pager -n 80` A unit journal contains startup chatter, retries, and supervisor messages, and you need the warning-or-worse lines first. Question: Do your services log real failures at warning or error level consistently? Use severity filtering as a fast first pass, then verify with full logs.: https://linuxoneliners.com/lessons/systemd-journal-warning-window/ --- ## Build a Restart Loop Timeline Restart loops make more sense when you line up starts, failures, and counters. Command: `journalctl -u app-worker -b --no-pager -o short-iso | grep -E 'Started|Failed|Scheduled restart|Main process exited'` A service keeps restarting and you need to separate the first application failure from later supervisor retries. Question: When a service is flapping, how do you find the first useful failure? Build the restart timeline before changing unit settings.: https://linuxoneliners.com/lessons/systemd-restart-loop-timeline/ --- ## Inspect the Unit File and Drop-ins Together The bug may be in an override file, not the main unit. Command: `systemctl cat app-worker` A service definition looks correct in the main unit, but a drop-in override may be changing the user, environment, or command. Question: How often do systemd drop-ins explain a service that suddenly changed behavior? Inspect the effective unit before editing.: https://linuxoneliners.com/lessons/systemd-cat-unit-and-dropins/ --- ## Print Runtime Paths and User From systemd Confirm the user, working directory, env file, and ExecStart systemd is actually using. Command: `systemctl show app-worker --property=FragmentPath,DropInPaths,EnvironmentFiles,ExecStart,User,WorkingDirectory --no-pager` A service failure points at credentials or paths, and you need systemd's resolved unit properties without reading multiple files manually. Question: When a service fails at USER, EXEC, or CHDIR, which property do you check first? Use systemctl show before chasing the wrong file.: https://linuxoneliners.com/lessons/systemd-show-runtime-paths/ --- ## Check Failed Dependencies for a Service Sometimes the service is only the messenger for a failed dependency. Command: `systemctl list-dependencies app-worker --failed --no-pager` A service fails after startup, but the real blocker may be a dependent unit such as Redis, networking, a mount, or a socket. Question: How often is a failed service actually a failed dependency? Check the dependency tree before restarting the app repeatedly.: https://linuxoneliners.com/lessons/systemd-check-failed-dependencies/ --- ## Reset Failed State After Capturing Evidence Clear the red failed state only after you have captured the evidence. Command: `systemctl reset-failed app-worker` systemctl --failed still shows an old service failure after the issue was fixed, and you need to clear the recorded failed state deliberately. Question: Do your runbooks capture evidence before clearing systemd failed state? Treat reset-failed as cleanup, not diagnosis.: https://linuxoneliners.com/lessons/systemd-reset-failed-after-capture/ --- ## Find the First Failure Line for One Unit The first failure line is often more useful than the last restart message. Command: `journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='` A failed service has repeated restart noise, and you need the earliest current-boot line that names an error or failed startup step. Question: When a service restarts repeatedly, do you inspect the first failure or the latest one first? Find the first failure line before tuning restart behavior.: https://linuxoneliners.com/lessons/systemd-find-first-failure-line/ --- ## Compare Failure Output With the Effective Unit Put the failed step next to the unit config that created it. Command: `systemctl status app-worker --no-pager --lines=50 && systemctl cat app-worker` systemctl status names a failed startup step, but you need to connect that symptom to the effective unit and drop-in configuration. Question: Do you compare systemd status output with the effective unit before editing overrides? Keep the symptom and loaded config in the same incident note.: https://linuxoneliners.com/lessons/systemd-compare-status-with-effective-unit/ --- ## List Accounts with Login Shells Login shells are the first account inventory to review. Command: `awk -F: '$7 ~ /(bash|sh|zsh)$/ {printf "%s %s\n", $1, $7}' fixtures/user-access-audit/etc/passwd` You need to separate human or interactive accounts from service accounts in a passwd-style file. Question: Do you inventory login-capable accounts before changing server access? Separate shell users from service accounts first.: https://linuxoneliners.com/lessons/access-list-login-shell-accounts/ --- ## Find Password-Enabled Accounts A shell account with an unlocked password hash deserves extra attention. Command: `awk -F: '$2 !~ /^(!|\*)/ {print $1}' fixtures/user-access-audit/etc/shadow` You need to identify accounts whose shadow field is not locked with ! or *. Question: Do you check locked versus password-enabled accounts during access reviews? Pair shadow review with SSH policy before changing anything.: https://linuxoneliners.com/lessons/access-find-password-enabled-accounts/ --- ## Review sudo Grants Privilege paths should be visible before you remove or approve access. Command: `awk -F: '$1=="sudo" {print "sudo group: " $4}' fixtures/user-access-audit/etc/group; grep -RhnE '^[^#].*ALL=' fixtures/user-access-audit/etc/sudoers fixtures/user-access-audit/etc/sudoers.d` You need a compact view of sudo group membership and sudoers rules from fixture-local stubs. Question: Do you review sudo group membership and direct sudoers rules together? Make every privilege path visible before editing.: https://linuxoneliners.com/lessons/access-review-sudo-grants/ --- ## Count authorized_keys by User authorized_keys is the practical SSH access list. Command: `find fixtures/user-access-audit/home -path '*/.ssh/authorized_keys' -exec sh -c 'for f do user=$(basename "$(dirname "$(dirname "$f")")"); keys=$(grep -vc "^[[:space:]]*#" "$f"); printf "%s %s %s\n" "$user" "$keys" "$f"; done' sh {} + | sort` You need to find which home directories have authorized_keys files and how many active key lines each contains. Question: Do you count authorized_keys entries by user during offboarding? Inventory SSH keys before removing access.: https://linuxoneliners.com/lessons/access-count-authorized-keys-by-user/ --- ## Find SSH Keys for nologin Users A nologin shell does not automatically mean SSH keys are irrelevant. Command: `comm -12 <(awk -F: '$7 !~ /(bash|sh|zsh)$/ {print $1}' fixtures/user-access-audit/etc/passwd | sort) <(find fixtures/user-access-audit/home -path '*/.ssh/authorized_keys' -printf '%h\n' | awk -F/ '{print $(NF-1)}' | sort)` You need to spot accounts that have authorized_keys files even though their passwd shell is nologin. Question: Do you check for authorized_keys files on service or nologin accounts? Compare account policy with the files that grant access.: https://linuxoneliners.com/lessons/access-find-keys-for-nologin-users/ --- ## Show Successful Logins and sudo Use Access reviews need both who logged in and who elevated privileges. Command: `grep -E 'Accepted publickey|sudo:' fixtures/user-access-audit/logs/auth.log` You need a compact access timeline from auth logs that includes successful SSH logins and sudo commands. Question: Do you combine successful SSH logins and sudo lines when reviewing access? Build the timeline before changing access.: https://linuxoneliners.com/lessons/access-show-successful-logins-and-sudo/ --- ## List Privileged Group Members Group membership can grant more access than the username suggests. Command: `awk -F: '$1 ~ /^(sudo|adm|docker)$/ && $4 != "" {print $1 ": " $4}' fixtures/user-access-audit/etc/group` You need to review accounts listed in privileged groups such as sudo, adm, or docker. Question: Do you review docker and adm membership alongside sudo during access audits? Check privileged groups before changing users.: https://linuxoneliners.com/lessons/access-list-privileged-group-members/ --- ## Summarize sudo Commands by User Privilege history is easier to review when users and commands are separated. Command: `sed -n 's/.*sudo: *\([^: ]*\).*COMMAND=\(.*\)$/\1 -> \2/p' fixtures/user-access-audit/logs/auth.log | sort` You need to extract sudo users and command paths from auth log lines. Question: Do you summarize sudo commands by user before reviewing the full auth log? Turn sudo logs into a readable access timeline.: https://linuxoneliners.com/lessons/access-summarize-sudo-commands-by-user/ --- ## Review a Breakglass Account Emergency accounts should be easy to find and hard to ignore. Command: `grep -Rhn 'breakglass' fixtures/user-access-audit/etc fixtures/user-access-audit/home fixtures/user-access-audit/logs` You need to collect account, group, SSH key, and log evidence for a breakglass user from fixture-local files. Question: Do you include recent log use when reviewing emergency accounts? Collect account, key, and log evidence together.: https://linuxoneliners.com/lessons/access-review-breakglass-account/ --- ## Find SSH Key Users with sudo The highest-priority access review starts where SSH keys and sudo overlap. Command: `comm -12 <(find fixtures/user-access-audit/home -path '*/.ssh/authorized_keys' -printf '%h\n' | awk -F/ '{print $(NF-1)}' | sort) <(awk -F: '$1=="sudo" {gsub(",","\n",$4); print $4}' fixtures/user-access-audit/etc/group | sort)` You need to identify users who both have authorized_keys files and appear in the sudo group. Question: Do you prioritize accounts that have both SSH keys and sudo access? Intersect key ownership with privileged groups.: https://linuxoneliners.com/lessons/access-find-ssh-key-users-with-sudo/ --- ## Count Failed SSH Login Users Failed SSH attempts are noisy; grouping users makes the pattern readable. Command: `sed -n 's/.*Failed password for \(invalid user \)\?\([^ ]*\) from .*/\2/p' logs/auth.log | sort | uniq -c | sort -nr` You need to count which usernames are being targeted in SSH failures. Question: Do you group failed SSH attempts by username during first response? Summarize the auth log before reading every line.: https://linuxoneliners.com/lessons/security-count-failed-ssh-users/ --- ## Count Failed SSH Login IPs The loudest SSH source is usually visible with one count. Command: `sed -n 's/.*Failed password .* from \([0-9.]*\) port.*/\1/p' logs/auth.log | sort | uniq -c | sort -nr` You need to rank source IPs from failed SSH login attempts. Question: Do you rank SSH failure sources before touching firewall rules? Use counts as evidence, then apply policy.: https://linuxoneliners.com/lessons/security-count-failed-ssh-ips/ --- ## Show Accepted SSH Logins During first response, successful logins matter more than background noise. Command: `grep 'Accepted publickey' logs/auth.log` You need to find successful SSH public-key logins in an auth log. Question: Do you separate successful SSH logins from failed noise first? Build access timelines from accepted login lines.: https://linuxoneliners.com/lessons/security-show-accepted-ssh-logins/ --- ## Show Recent sudo Commands Privilege use is one of the fastest first-response signals. Command: `grep 'sudo:' logs/auth.log | tail -n 10` You need to see recent sudo commands from auth logs. Question: Do you check sudo logs when a VPS changes unexpectedly? Privilege-use logs are fast timeline anchors.: https://linuxoneliners.com/lessons/security-show-recent-sudo-commands/ --- ## List Listening Ports on a VPS Unexpected network listeners are first-response evidence. Command: `ss -ltnp` You need a snapshot of TCP ports listening on the server. Question: Do you check bind addresses before assuming a port is exposed? Pair ss output with firewall checks.: https://linuxoneliners.com/lessons/security-list-listening-ports/ --- ## List Users with Login Shells Not every local account should be able to log in. Command: `awk -F: '$7 ~ /sh$/ {print $1, $7}' etc/passwd` You need to list accounts with shell-like login programs. Question: Do you inventory login-capable users during VPS handoff? Review shell accounts before changing access.: https://linuxoneliners.com/lessons/security-list-login-shell-users/ --- ## Check Key SSH Authentication Settings SSH policy should be visible before you change it. Command: `grep -nE '^(PasswordAuthentication|PermitRootLogin|PubkeyAuthentication|AllowUsers)' etc/ssh/sshd_config` You need to read important SSH daemon authentication settings. Question: Do you inspect SSH auth policy before changing sshd_config? Read the live policy lines before editing.: https://linuxoneliners.com/lessons/security-check-sshd-auth-settings/ --- ## Find World-Writable Web Directories World-writable web paths deserve immediate review. Command: `find srv/www -type d -perm -0002 -print` You need to find directories under a web root that anyone can write to. Question: Do you audit world-writable web directories after deploys? Find risky writable paths before changing modes.: https://linuxoneliners.com/lessons/security-find-world-writable-web-dirs/ --- ## Find Loose Private Key Permissions SSH private keys should not be readable like ordinary files. Command: `find home -type f -name 'id_*' -printf '%m %p\n' | awk '$1 > 600'` You need to find private-key-looking files with modes broader than 600. Question: Do you audit SSH key file modes during VPS access reviews? Find risky key permissions before changing access.: https://linuxoneliners.com/lessons/security-find-loose-private-key-modes/ --- ## List authorized_keys Files Authorized keys are the server's practical access list. Command: `find home -path '*/.ssh/authorized_keys' -printf '%m %p\n'` You need to find authorized_keys files and their modes. Question: Do you inventory authorized_keys files during server handoff? Review SSH access files before removing users.: https://linuxoneliners.com/lessons/security-list-authorized-keys-files/ --- ## List Nginx Listen Directives The site was configured, but the port was not. Command: `grep -RInE '^[[:space:]]*listen[[:space:]]' fixtures/nginx/conf.d fixtures/nginx/sites-enabled` You need to see which Nginx server blocks claim ports before chasing DNS or app errors. Question: When Nginx serves the wrong site, do you check listen lines or server names first? Map Nginx ports before editing configs.: https://linuxoneliners.com/lessons/web-config-list-nginx-listen-directives/ --- ## Find the Nginx Default Server The wrong site answered because it was the fallback. Command: `grep -RIn 'default_server' fixtures/nginx/conf.d fixtures/nginx/sites-enabled` You need to find which Nginx server block is marked as the default. Question: Have you debugged the wrong Nginx site because the fallback answered? Check default_server before changing host rules.: https://linuxoneliners.com/lessons/web-config-find-nginx-default-server/ --- ## Show Nginx Include Lines The config was valid; it just was not included. Command: `grep -RInE '^[[:space:]]*include[[:space:]]' fixtures/nginx/nginx.conf fixtures/nginx/conf.d fixtures/nginx/sites-enabled` You need to see which files the main Nginx config is expected to include. Question: What is your quickest way to prove a config file is in the include path? Trace Nginx include lines first.: https://linuxoneliners.com/lessons/web-config-show-nginx-include-chain/ --- ## Map Nginx Roots and Aliases The URL was right. The filesystem path was not. Command: `grep -RInE '^[[:space:]]*(root|alias)[[:space:]]' fixtures/nginx/conf.d fixtures/nginx/sites-enabled` You need to find which document roots and aliases Nginx config points at. Question: Do you check root and alias before debugging static-file 404s? Map Nginx file paths before changing permissions.: https://linuxoneliners.com/lessons/web-config-map-nginx-roots-aliases/ --- ## Map Nginx Proxy Targets Nginx was healthy. It was proxying to the wrong place. Command: `grep -RInE '^[[:space:]]*proxy_pass[[:space:]]' fixtures/nginx/conf.d fixtures/nginx/sites-enabled` You need to see where Nginx forwards proxied requests. Question: For a 502, do you inspect proxy_pass before checking the app process? Map proxy targets quickly.: https://linuxoneliners.com/lessons/web-config-map-nginx-proxy-targets/ --- ## Show Enabled Apache Sites The Apache config existed. The enabled symlink did not. Command: `find fixtures/apache/sites-enabled -maxdepth 1 -type l -printf '%f -> %l\n' | sort` You need to see which Apache virtual host files are enabled. Question: Have you ever edited an Apache site that was not enabled? Check enabled Apache symlinks first.: https://linuxoneliners.com/lessons/web-config-show-enabled-apache-sites/ --- ## Map Apache Virtual Hosts Apache chose a virtual host. You need to know which one. Command: `grep -RInE '= 3) print count[path], path}' ./fixtures/nginx/access.log | sort -nr | head` You need to identify missing paths that are being requested repeatedly. Question: Do you review repeated 404s as broken-link cleanup, security triage, or both? Prioritize repeated misses before one-off noise.: https://linuxoneliners.com/lessons/repeated-404-paths/ --- ## Spot Request Bursts by Minute Traffic spikes are easier to read when you bucket them by time. Command: `awk '{minute=substr($4,2,17); count[minute]++} END {for (m in count) print count[m], m}' ./fixtures/nginx/access.log | sort -nr | head` You need to find the busiest minute-level windows in an access log. Question: When traffic spikes, do you inspect raw lines first or bucket by time? Use buckets to find the hot window first.: https://linuxoneliners.com/lessons/request-bursts-by-minute/ --- ## Find Unusually Large Web Responses A few huge responses can explain bandwidth, latency, and suspicious download patterns. Command: `awk '$10 ~ /^[0-9]+$/ && $10 > 1000000 {print $10, $1, $7, $9}' ./fixtures/nginx/access.log | sort -nr | head` You need to list large responses from a web access log for operational and defensive review. Question: Do you check response size when investigating traffic spikes? Use byte counts to separate bandwidth from request-count problems.: https://linuxoneliners.com/lessons/large-web-responses/ --- ## Find Clients Repeating the Same Path The suspicious pattern is sometimes one client hammering one URL. Command: `awk '{key=$1 " " $7; count[key]++} END {for (k in count) if (count[k] >= 5) print count[k], k}' ./fixtures/nginx/access.log | sort -nr | head` You need to find IP and path pairs that appear repeatedly in a web access log. Question: Do you group web traffic by IP alone, or by IP plus path? Use this to separate broad activity from repeated loops.: https://linuxoneliners.com/lessons/ip-path-repeaters/