Improve infra-run portfolio credibility

.github/workflows/lint.yml

@@ -0,0 +1,36 @@
+---
+name: lint
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+
+jobs:
+  shell-yaml-ansible:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v4
+
+      - name: Install lint tools
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y shellcheck yamllint python3-pip
+          python3 -m pip install --user ansible-lint
+          echo "$HOME/.local/bin" >> "$GITHUB_PATH"
+
+      - name: ShellCheck Bash scripts
+        run: |
+          find infra-run/scripts/bash -name '*.sh' -print0 | xargs -0 shellcheck -x \
+            -P infra-run/scripts/bash/disk-full \
+            -P infra-run/scripts/bash/gpfs \
+            -P infra-run/scripts/bash/veritas
+
+      - name: yamllint
+        run: yamllint .
+
+      - name: ansible-lint
+        continue-on-error: true
+        run: cd infra-run/ansible && ansible-lint playbooks roles

.yamllint

@@ -0,0 +1,8 @@
+---
+extends: default
+
+rules:
+  line-length:
+    max: 140
+  truthy:
+    allowed-values: ["true", "false", "on"]

CHANGELOG.md

@@ -4,7 +4,7 @@
 
 ### Added
 
-- CIS-inspired Ansible hardening automation:
+- Selected baseline Ansible hardening automation:
   - RHEL 9 role and playbook.
   - Debian 13 / Ubuntu 26.04 role and playbook.
   - IBM AIX 7 role and playbook.
@@ -17,7 +17,7 @@
 
 ### Notes
 
-- Hardening content is CIS-inspired and intended for portfolio/lab use; production use requires environment-specific review and validation.
+- Hardening content covers selected baseline controls and intended for portfolio/lab use; live use requires environment-specific review and validation.
 
 ## [Initial Version]
 

README.md

@@ -1,92 +1,50 @@
 # Portfolio
 
-This repository demonstrates real-world Linux infrastructure and operations experience through sanitized scripts, runbooks, and project structure. It focuses on production operations, incident response, troubleshooting, automation, and enterprise infrastructure patterns.
+This repository contains sanitized infrastructure automation examples based on Linux operations and enterprise infrastructure workflows. The focus is on precheck, dry-run, controlled execution, postcheck, troubleshooting, and clear operational reporting.
 
-## Repository Diagram
+It is a technical portfolio, not a production toolkit. The examples are meant to show how I structure operational work: understand the current state, make changes only with explicit controls, verify the result, and leave readable evidence for review.
 
-```mermaid
+## What Is Usable Now
-flowchart TD
+
-  A["portfolio"] --> B["infra-run"]
+- [infra-run](./infra-run/) - the main project in this repository.
-  A --> C["platform-projects"]
+- [Linux healthcheck scripts](./infra-run/scripts/bash/os-healthcheck/) - host, disk, service, network, and report helpers.
-  A --> D["labs"]
+- [Disk full workflow](./infra-run/scripts/bash/disk-full/) - triage scripts for usage, inode pressure, deleted open files, large files, log cleanup review, and postchecks.
-  B --> B1["ansible"]
+- [Veritas examples](./infra-run/scripts/bash/veritas/) - dry-run-first VxVM/VCS storage expansion workflow examples.
-  B --> B2["docs"]
+- [GPFS examples](./infra-run/scripts/bash/gpfs/) - dry-run-first IBM Spectrum Scale expansion workflow examples.
-  B --> B3["runbooks"]
+- [Ansible hardening examples](./infra-run/ansible/) - selected Linux and AIX baseline hardening tasks organized as lab-safe roles.
-  B --> B4["scripts"]
+
-  B1 --> B11["hardening roles"]
+## What Is Planned
-  B4 --> B41["bash"]
+
-  B4 --> B42["python"]
+The `labs` and `platform-projects` trees are intentionally thin. They are kept as planning areas for future lab notes and case studies, not as completed projects. Current planned topics are tracked in [ROADMAP.md](./ROADMAP.md).
-  C --> C1["storage"]
+
-  C --> C2["clustering"]
+## What This Repo Is Not
-  C --> C3["monitoring-zabbix"]
+
-  C --> C4["virtualization"]
+- It is not a compliance benchmark implementation.
-  C --> C5["elk-log-analysis"]
+- It is not a drop-in change automation framework.
-  D --> D1["docker"]
+- It is not proof that these exact scripts ran in any production environment.
-  D --> D2["kubernetes"]
+- It does not replace change review, peer review, backups, monitoring, or platform-specific runbooks.
-  D --> D3["terraform"]
+
-  D --> D4["networking"]
+## Validation
-  D --> D5["ci-cd"]
+
+Basic local validation:
+
+```bash
+find infra-run/scripts/bash -name '*.sh' -print0 | xargs -0 shellcheck -x -P infra-run/scripts/bash/disk-full -P infra-run/scripts/bash/gpfs -P infra-run/scripts/bash/veritas
+yamllint .
+cd infra-run/ansible && ansible-lint playbooks roles
 ```
 
-## Core Project
+Some scripts depend on platform tools such as `vxdisk`, `hagrp`, `mmcrnsd`, and `mmlscluster`. Those commands are not expected to exist on a normal workstation, so functional testing against Veritas or GPFS requires a real lab environment.
 
-### infra-run
+See [infra-run/TESTED.md](./infra-run/TESTED.md) and [infra-run/KNOWN_LIMITATIONS.md](./infra-run/KNOWN_LIMITATIONS.md) for the current validation status.
 
-`infra-run` is the core operational project in this repository. It contains Linux operations automation, incident response tooling, Bash-based operational scripts, and runbook-style workflows for pre-checks, controlled changes, troubleshooting, and post-change validation.
+## Skills Demonstrated
 
-## Toolkits
+- Linux operations triage and reporting.
-
+- Disk pressure and deleted-file incident analysis.
-### Linux Operations Toolkit
+- Dry-run-first Bash automation.
-
+- Controlled storage change workflow design.
-[infra-run/scripts/bash/os-healthcheck/](./infra-run/scripts/bash/os-healthcheck/)
+- Veritas VxVM/VCS operational awareness.
-
+- GPFS / IBM Spectrum Scale operational awareness.
-General Linux operations scripts for host health checks, disk usage checks, service validation, system reporting, and first-pass OS-level diagnostics. The toolkit is written for practical operations checks on RHEL, Oracle Linux, and Ubuntu-style systems.
+- Ansible role organization for selected hardening controls.
-
+- Clear documentation of what was tested and what still needs a real system.
-### Disk Full Incident Toolkit
-
-[infra-run/scripts/bash/disk-full/](./infra-run/scripts/bash/disk-full/)
-
-Production-style disk full incident workflow covering filesystem usage, inode pressure, large file discovery, deleted open files, top directory analysis, log cleanup review, and safe cleanup suggestions. The scenario reflects common incidents involving logs, temporary files, deleted files held open by processes, and inode exhaustion.
-
-### Network Troubleshooting
-
-[infra-run/scripts/bash/os-healthcheck/](./infra-run/scripts/bash/os-healthcheck/)
-
-OS-level network diagnostics for interfaces, routes, DNS resolution, gateway reachability, listening sockets, and optional remote connectivity checks. The script is designed for first-pass troubleshooting during Linux operations incidents.
-
-### Veritas Storage Toolkit
-
-[infra-run/scripts/bash/veritas/](./infra-run/scripts/bash/veritas/)
-
-Veritas VxVM and VCS storage expansion workflow covering new LUN detection, VxVM disk initialization, diskgroup extension, volume and filesystem resize, and VCS service group freeze/unfreeze handling. The approach is cluster-safe, dry-run by default, and organized around pre-check, change, and post-check steps.
-
-### GPFS Storage Toolkit
-
-[infra-run/scripts/bash/gpfs/](./infra-run/scripts/bash/gpfs/)
-
-GPFS / IBM Spectrum Scale filesystem expansion workflow covering cluster validation, candidate disk discovery, NSD stanza planning, NSD creation, filesystem expansion, optional rebalance, post-checks, and change reporting.
-
-### Ansible Hardening Toolkit
-
-[infra-run/ansible/](./infra-run/ansible/)
-
-CIS-inspired Ansible automation for repeatable operating system hardening across RHEL 9, Debian 13 / Ubuntu 26.04, and IBM AIX 7 targets. The roles are organized around pre-checks, configurable safeguards, SSH and sudo policy, auditing, logging, services, filesystem controls, platform-specific system settings, handlers, and post-change validation.
-
-## Repository Structure
-
-- `infra-run` - core operational automation, scripts, runbooks, and infrastructure operations examples.
-- `platform-projects` - larger infrastructure topics including storage, clustering, monitoring, virtualization, and log analysis.
-- `labs` - experimentation and lab work for Kubernetes, Terraform, Docker, networking, and CI/CD.
-
-## Design Principles
-
-- Safety first, with dry-run behavior by default.
-- Pre-check, change, and post-check workflow.
-- Real-world scenarios, not tutorials.
-- Minimal but practical tooling.
-- Configurable automation with sanitized defaults and explicit overrides.
-
-## Notes
-
-- Scripts are simplified and sanitized for portfolio use.
-- Examples are based on real production operations patterns.

ROADMAP.md

@@ -0,0 +1,21 @@
+# Roadmap
+
+This file keeps future portfolio ideas in one place so empty folders do not look like finished work.
+
+## Planned Lab Areas
+
+- Docker: image build notes, container troubleshooting, and small service examples.
+- Kubernetes: workload inspection, basic operations checks, and failure scenario notes.
+- Terraform: small infrastructure-as-code examples with clear plan/apply separation.
+- Networking: DNS, routing, firewall, and connectivity troubleshooting labs.
+- CI/CD: validation pipelines for shell, YAML, and Ansible examples.
+
+## Planned Platform Case Studies
+
+- Storage: expansion planning, filesystem checks, and SAN handoff documentation.
+- Clustering: service group checks, failover review, and operational checklists.
+- Monitoring: Zabbix-oriented alert review and host onboarding notes.
+- Virtualization: VM lifecycle and platform operations examples.
+- Log analysis: ELK-style search examples for incident review.
+
+Nothing in this roadmap should be read as completed implementation.

infra-run/KNOWN_LIMITATIONS.md

@@ -0,0 +1,9 @@
+# Known Limitations
+
+- Veritas scripts require manual review before real use. VxVM and VCS behavior varies by version, cluster design, naming convention, and operational policy.
+- GPFS commands require a real cluster and must be adapted to the site layout, NSD naming standard, failure groups, storage pools, and maintenance process.
+- The AIX Ansible role is a portfolio example unless tested on a real AIX LPAR with the target OpenSSH, sudo, audit, and OS levels.
+- SSH hardening must be validated against the full `sshd` configuration, not only a managed drop-in file.
+- The hardening examples cover selected controls only. They are not a full CIS benchmark implementation or compliance attestation.
+- Scripts do not replace formal change procedures, peer review, backups, monitoring checks, or rollback planning.
+- Sample outputs are fake and sanitized. They should be used for documentation review, not operational decisions.

infra-run/README.md

@@ -1,34 +1,70 @@
 # infra-run
 
-`infra-run` is the operational core of this repository. It groups automation, scripts, runbooks, and supporting documentation for Linux infrastructure work, incident response, and controlled change execution.
+`infra-run` is a sanitized infrastructure operations project. It contains Bash and Ansible examples based on Linux administration, incident response, storage operations, hardening, prechecks, postchecks, and controlled change workflows.
 
-## Diagram
+The goal is to show operational judgment, not to ship a universal automation product.
 
-```mermaid
+## Current Contents
-flowchart TD
+
-  A["infra-run"] --> B["ansible"]
+- [scripts/bash/os-healthcheck](./scripts/bash/os-healthcheck/) - general Linux health, service, disk, network, and report scripts.
-  A --> C["docs"]
+- [scripts/bash/disk-full](./scripts/bash/disk-full/) - disk-full triage and cleanup review workflow.
-  A --> D["runbooks"]
+- [scripts/bash/veritas](./scripts/bash/veritas/) - Veritas VxVM/VCS storage expansion workflow examples.
-  A --> E["scripts"]
+- [scripts/bash/gpfs](./scripts/bash/gpfs/) - GPFS / IBM Spectrum Scale expansion workflow examples.
-  E --> E1["bash"]
+- [ansible](./ansible/) - selected baseline hardening examples for RHEL-like Linux, Debian/Ubuntu, and AIX.
-  E --> E2["python"]
+- [examples](./examples/) - sanitized sample command outputs and incident notes.
+
+## What This Is
+
+- A portfolio project for Linux and infrastructure operations roles.
+- A set of readable examples showing precheck, dry-run, execution guardrails, postcheck, and reporting patterns.
+- A place to demonstrate Bash, Ansible, storage workflow, and troubleshooting habits with sanitized inputs.
+
+## What This Is Not
+
+- Not intended for direct live use.
+- Not a complete CIS benchmark implementation.
+- Not a replacement for site-specific change procedures.
+- Not tested against live Veritas, GPFS, or AIX systems in this repository.
+- Not safe to run blindly on servers without review.
+
+## Currently Usable
+
+- Bash syntax can be checked locally.
+- Shell scripts can be reviewed and partially exercised on a Linux workstation when platform commands are available or mocked.
+- Disk-full read-only scripts can be run against local paths for basic behavior checks.
+- Ansible YAML and role structure can be linted locally.
+
+## Lab-Safe Examples
+
+- Veritas and GPFS scripts default to dry-run behavior where they plan destructive or platform-changing operations.
+- Ansible hardening roles are examples of selected controls and need adaptation before use.
+- Sample outputs under [examples](./examples/) are fake and sanitized.
+
+## Tested
+
+See [TESTED.md](./TESTED.md) for current validation status.
+
+Short version:
+
+- Shell scripts were reviewed for dry-run behavior and obvious quoting issues.
+- YAML and Ansible files are intended for local linting.
+- Veritas, GPFS, and AIX behavior was not validated against real systems here.
+
+## Basic Validation
+
+From the repository root:
+
+```bash
+find infra-run/scripts/bash -name '*.sh' -print0 | xargs -0 shellcheck -x -P infra-run/scripts/bash/disk-full -P infra-run/scripts/bash/gpfs -P infra-run/scripts/bash/veritas
+yamllint .
+cd infra-run/ansible && ansible-lint playbooks roles
 ```
 
-## Scope
+If `ansible-lint` reports collection-related issues, install the collections listed in [ansible/collections/requirements.yml](./ansible/collections/requirements.yml) and rerun it. Treat lint as a starting point; platform testing still requires actual target systems.
 
-- `ansible` - infrastructure automation with CIS-inspired hardening roles and playbooks.
+## Supporting Notes
-- `docs` - supporting technical notes and written documentation.
-- `runbooks` - procedural operational guides.
-- `scripts` - executable tooling for operations and diagnostics.
 
-## Current Automation
+- [SOURCE.md](./SOURCE.md) explains why this project exists and what experience shaped it.
-
+- [TESTED.md](./TESTED.md) lists what was checked locally and what was not.
-- RHEL 9 CIS-inspired hardening role and playbook.
+- [KNOWN_LIMITATIONS.md](./KNOWN_LIMITATIONS.md) documents technical limits and operational cautions.
-- Debian 13 / Ubuntu 26.04 CIS-inspired hardening role and playbook.
+- [ROADMAP.md](./ROADMAP.md) tracks planned additions without presenting them as completed work.
-- IBM AIX 7 CIS-inspired hardening role and playbook.
-- Shared sanitized inventory defaults for Linux and AIX examples.
-
-## Notes
-
-- This folder reflects the structure of a production-oriented operations repository.
-- Current implementation includes Bash operational toolkits and Ansible hardening automation.

infra-run/ROADMAP.md

@@ -0,0 +1,16 @@
+# infra-run Roadmap
+
+This file tracks planned `infra-run` additions without presenting them as completed work.
+
+## Candidate Additions
+
+- More sample reports for disk pressure, service failures, and network incidents.
+- A small Python parser for converting script output into a markdown change note.
+- Additional Ansible molecule or container-based syntax checks where platform support is realistic.
+- Standalone runbooks that reference the existing Bash workflows.
+
+## Not Planned
+
+- A full compliance benchmark implementation.
+- Automated production changes without review gates.
+- Vendor-specific storage actions that cannot be tested in a lab.

infra-run/SOURCE.md

@@ -0,0 +1,37 @@
+# Source And Intent
+
+`infra-run` exists to present infrastructure operations work in a form that can be reviewed without exposing employer systems, hostnames, storage identifiers, tickets, or internal procedures.
+
+The project is inspired by professional Linux and infrastructure operations work: prechecks before changes, postchecks after changes, disk-pressure incidents, SSH and sudo hardening, storage expansion planning, cluster awareness, and the need to leave clear notes for other engineers.
+
+## What Is Realistic
+
+- The workflow shape: precheck, dry-run, execute only with explicit approval, postcheck, and report.
+- The operational topics: Linux health checks, disk-full triage, Veritas VxVM/VCS concepts, GPFS / IBM Spectrum Scale concepts, and selected OS hardening controls.
+- The caution around storage, clustering, SSH, sudo, audit, and filesystem changes.
+
+## What Is Simplified
+
+- Commands are written as examples and do not cover every vendor, OS release, package layout, or site standard.
+- The Veritas and GPFS scripts model common workflow steps but cannot validate a real cluster from this repository.
+- The Ansible roles apply selected baseline controls; they are not full compliance implementations.
+- Reporting examples use sanitized sample data.
+
+## What Was Sanitized
+
+- Hostnames, IP addresses, disk names, WWNs, ticket numbers, application names, company names, and environment-specific values.
+- Exact production procedures and internal approval paths.
+- Any data that could identify a real system or organization.
+
+## Production Caution
+
+Do not run these scripts blindly on production systems. Review every command, adapt variables and paths, test in a lab, confirm backups and rollback plans, and follow the local change process.
+
+This project does not claim that the exact scripts were used in production.
+
+## Roles This Supports
+
+- Linux System Administrator
+- Infrastructure Engineer
+- SRE / DevOps Operations Engineer
+- Linux Platform Engineer

infra-run/TESTED.md

@@ -0,0 +1,44 @@
+# Tested
+
+This file documents the validation status for `infra-run`.
+
+## Tested Locally
+
+- Repository structure and documentation links were reviewed.
+- Bash scripts were reviewed for dry-run defaults, quoting, and obvious unsafe cleanup behavior.
+- Disk-full examples use fake data and can be read without access to production systems.
+
+## Syntax Checked
+
+Recommended local checks:
+
+```bash
+find infra-run/scripts/bash -name '*.sh' -print0 | xargs -0 shellcheck -x -P infra-run/scripts/bash/disk-full -P infra-run/scripts/bash/gpfs -P infra-run/scripts/bash/veritas
+yamllint .
+cd infra-run/ansible && ansible-lint playbooks roles
+```
+
+The GitHub Actions workflow runs shell and YAML validation. `ansible-lint` is non-blocking because role behavior depends on platform facts, installed collections, and target OS support.
+
+## Not Tested Against Real Systems
+
+- Veritas VxVM/VCS commands were not tested against a live Veritas cluster here.
+- GPFS / IBM Spectrum Scale commands were not tested against a live GPFS cluster here.
+- AIX hardening tasks were not tested against a real AIX LPAR here.
+- SSH hardening was not validated across every possible `sshd_config` layout.
+
+## Known Limitations
+
+- Destructive storage operations are dry-run by default where applicable, but dry-run output is not a substitute for peer review.
+- Some scripts require vendor commands that are not available on a normal Linux workstation.
+- Ansible examples are selected baseline controls, not full hardening benchmarks.
+- Local linting does not prove production safety.
+
+## Suggested Validation Steps
+
+1. Run `shellcheck` against all Bash scripts.
+2. Run `yamllint` against repository YAML.
+3. Run `cd infra-run/ansible && ansible-lint playbooks roles` and review any non-blocking warnings.
+4. Run disk-full read-only scripts on disposable local paths.
+5. For Veritas or GPFS, test only in a lab with fake volumes/disks or a controlled training environment.
+6. Validate SSH changes on a disposable host using the full effective `sshd` configuration.

infra-run/ansible/README.md

@@ -19,7 +19,7 @@ flowchart TD
 
 - `collections` - collection requirements for supported automation targets.
 - `inventory` - sanitized Linux and AIX inventory examples with shared defaults.
-- `playbooks` - executable CIS-inspired hardening playbooks.
+- `playbooks` - executable selected baseline hardening playbooks.
 - `roles` - reusable hardening roles for supported operating systems.
 - `tests` - validation and test harnesses for Ansible content.
 
@@ -31,6 +31,6 @@ flowchart TD
 
 ## Notes
 
-- Roles are CIS-inspired examples intended for portfolio and lab use, not a drop-in compliance certification.
+- Roles are selected baseline examples intended for portfolio and lab use, not a drop-in compliance certification.
 - Defaults are sanitized and configurable through inventory or `--extra-vars`.
-- Run platform-specific playbooks against appropriate test hosts before adapting them to production environments.
+- Run platform-specific playbooks against appropriate test hosts before adapting them to managed environments.

infra-run/ansible/playbooks/README.md

@@ -14,7 +14,7 @@ flowchart TD
 
 ## Notes
 
-- `cis-rhel9-hardening.yml` applies the RHEL 9 CIS-inspired hardening role to Linux inventory targets.
+- `cis-rhel9-hardening.yml` applies the RHEL 9 selected baseline hardening role to Linux inventory targets.
-- `cis-debian-ubuntu-hardening.yml` applies the Debian 13 / Ubuntu 26.04 CIS-inspired hardening role to Linux inventory targets.
+- `cis-debian-ubuntu-hardening.yml` applies the Debian 13 / Ubuntu 26.04 selected baseline hardening role to Linux inventory targets.
-- `cis-aix7-hardening.yml` applies the IBM AIX 7 CIS-inspired hardening role to AIX inventory targets.
+- `cis-aix7-hardening.yml` applies the IBM AIX 7 selected baseline hardening role to AIX inventory targets.
 - Use the sanitized inventory under `../inventory/` as a starting point and override defaults per environment.

infra-run/ansible/playbooks/cis-aix7-hardening.yml

@@ -1,5 +1,5 @@
 ---
-- name: Apply CIS-inspired IBM AIX 7 hardening controls
+- name: Apply selected baseline IBM AIX 7 hardening controls
   hosts: aix
   become: true
   gather_facts: true

infra-run/ansible/playbooks/cis-debian-ubuntu-hardening.yml

@@ -1,5 +1,5 @@
 ---
-- name: Apply CIS-inspired Debian and Ubuntu hardening controls
+- name: Apply selected baseline Debian and Ubuntu hardening controls
   hosts: linux
   become: true
   gather_facts: true

infra-run/ansible/playbooks/cis-rhel9-hardening.yml

@@ -1,5 +1,5 @@
 ---
-- name: Apply CIS-inspired RHEL 9 hardening controls
+- name: Apply selected baseline RHEL 9 hardening controls
   hosts: linux
   become: true
   gather_facts: true

infra-run/ansible/roles/README.md

@@ -17,11 +17,11 @@ flowchart TD
 
 ## Current Roles
 
-- `cis-rhel9-hardening` - CIS-inspired RHEL 9 baseline with package, service, SSH, sudo, sysctl, audit, logging, filesystem, and validation tasks.
+- `cis-rhel9-hardening` - RHEL 9 baseline example with package, service, SSH, sudo, sysctl, audit, logging, filesystem, and validation tasks.
-- `cis-debian-ubuntu-hardening` - CIS-inspired Debian 13 and Ubuntu 26.04 baseline with apt, service, SSH, sudo, sysctl, audit, logging, filesystem, and validation tasks.
+- `cis-debian-ubuntu-hardening` - Debian 13 and Ubuntu 26.04 baseline example with apt, service, SSH, sudo, sysctl, audit, logging, filesystem, and validation tasks.
-- `cis-aix7-hardening` - CIS-inspired IBM AIX 7 baseline with SSH, sudo, audit, logging, cron, user, password, network, filesystem, service, and validation tasks.
+- `cis-aix7-hardening` - IBM AIX 7 baseline example with SSH, sudo, audit, logging, cron, user, password, network, filesystem, service, and validation tasks.
 
 ## Notes
 
 - Each role includes defaults, task includes, handlers where needed, and role-specific README guidance.
-- The hardening content is sanitized for portfolio use and should be reviewed against site policy before production use.
+- The hardening content is sanitized for portfolio use and should be reviewed against site policy before live use.

infra-run/ansible/roles/cis-aix7-hardening/README.md

@@ -1,10 +1,10 @@
 # cis-aix7-hardening
 
-Operational IBM AIX 7.x hardening role inspired by CIS Benchmark 1.2.0 and common enterprise Unix security practices.
+Operational IBM AIX 7.x hardening role inspired by CIS Benchmark 1.2.0 and common Unix security practices.
 
 Reference: https://www.cisecurity.org/benchmark/aix
 
-This role is intended for infrastructure and security operations teams that manage production AIX estates. It favors readable, conservative controls over broad benchmark coverage.
+This role is intended for infrastructure and security operations teams that manage AIX estates. It favors readable, conservative controls over broad benchmark coverage.
 
 ## Supported OS
 
@@ -27,7 +27,7 @@ This role is intended for infrastructure and security operations teams that mana
 
 AIX is not Linux. This role does not assume systemd, sysctl, Linux package managers, or Linux service paths. Service operations use SRC commands such as `lssrc`, `startsrc`, `stopsrc`, and `refresh`.
 
-AIX environments vary heavily between enterprises. Filesystem layout, OpenSSH source, sudo packaging, audit classes, NFS tuning, and security policy ownership should be validated before production rollout.
+AIX environments vary heavily between environments. Filesystem layout, OpenSSH source, sudo packaging, audit classes, NFS tuning, and security policy ownership should be validated before managed rollout.
 
 ## Safety Philosophy
 
@@ -64,4 +64,4 @@ ansible-playbook playbooks/cis-aix7-hardening.yml --tags audit -e cis_enable_aud
 
 ## Important Warning
 
-This is not a full CIS certification implementation and does not implement the entire CIS AIX benchmark. It is a practical CIS-inspired baseline that should be reviewed by infrastructure, security, and application owners before production enforcement.
+This is not a full compliance certification implementation and does not implement the entire CIS AIX benchmark. It is a practical baseline example that should be reviewed by infrastructure, security, and application owners before managed enforcement.

infra-run/ansible/roles/cis-aix7-hardening/tasks/filesystem.yml

@@ -18,7 +18,7 @@
   ansible.builtin.debug:
     msg: >-
       OK: Mount option management is disabled by default.
-      Review target {{ item.path }} for options {{ item.options | join(', ') }} before production rollout.
+      Review target {{ item.path }} for options {{ item.options | join(', ') }} before managed rollout.
   loop: "{{ cis_mount_option_targets }}"
   when: not cis_manage_mount_options | bool
 

infra-run/ansible/roles/cis-aix7-hardening/tasks/postcheck.yml

@@ -54,5 +54,5 @@
            if cis_aix_post_sshd.rc == 0 else 'CRITICAL: sshd validation failed; review SSH config before restarting sessions.' }}
       - "OK: Service states: {{ cis_aix_validation_summary.service_states }}"
       - "OK: Password policy summary: {{ cis_aix_validation_summary.password_policy }}"
-      - "WARNING: This role is CIS-inspired and does not represent a complete CIS certification implementation."
+      - "WARNING: This role is selected baseline and does not represent a complete compliance certification implementation."
       - "{{ cis_aix_validation_summary.recommendations }}"

infra-run/ansible/roles/cis-debian-ubuntu-hardening/README.md

@@ -1,6 +1,6 @@
-# CIS-Inspired Debian and Ubuntu Hardening
+# Debian And Ubuntu Baseline Hardening Role
 
-This role applies a small, practical set of CIS-inspired operational hardening controls for Debian and Ubuntu servers. It is intentionally readable, conservative, and suitable as a baseline for production environments that still need local review.
+This role applies a small, practical set of selected baseline operational hardening controls for Debian and Ubuntu servers. It is intentionally readable, conservative, and suitable as a baseline for managed environments that still need local review.
 
 ## Supported OS
 
@@ -11,7 +11,7 @@ Unsupported distributions and versions fail during precheck before hardening tas
 
 ## Implemented Areas
 
-- SSH daemon hardening with a validated drop-in configuration
+- SSH daemon hardening through a managed drop-in and final `sshd -t` validation
 - Legacy network package removal
 - Optional installation and enablement of `auditd`, `chrony`, `rsyslog`, and `sudo`
 - Kernel network sysctl hardening
@@ -31,7 +31,7 @@ The defaults are intended to be operationally safe:
 - Services are enabled only when the matching feature is enabled and the service exists.
 - Existing logging configuration is not replaced.
 
-This role does not implement the full CIS benchmark and is not a CIS certification implementation.
+This role does not implement the full CIS benchmark and is not a compliance certification implementation.
 
 ## Usage
 

infra-run/ansible/roles/cis-debian-ubuntu-hardening/tasks/postcheck.yml

@@ -37,12 +37,16 @@
   ansible.builtin.set_fact:
     cis_package_validation_summary:
       legacy_absent: "{{ cis_legacy_packages | difference(ansible_facts.packages.keys() | list) }}"
-      hardening_present: "{{ (cis_enabled_hardening_packages | default(cis_hardening_packages)) | intersect(ansible_facts.packages.keys() | list) }}"
+      hardening_present: >-
+        {{ (cis_enabled_hardening_packages | default(cis_hardening_packages))
+        | intersect(ansible_facts.packages.keys() | list) }}
       audit_present: "{{ cis_audit_packages | intersect(ansible_facts.packages.keys() | list) }}"
 
 - name: Build sysctl validation summary
   ansible.builtin.set_fact:
-    cis_sysctl_validation_summary: "{{ cis_sysctl_validation_summary | default({}) | combine({item.item.key: item.stdout | default('unreadable')}) }}"
+    cis_sysctl_validation_summary: >-
+      {{ cis_sysctl_validation_summary | default({})
+      | combine({item.item.key: item.stdout | default('unreadable')}) }}
   loop: "{{ cis_sysctl_validation.results | default([]) }}"
   loop_control:
     label: "{{ item.item.key }}"
@@ -65,7 +69,7 @@
 - name: Publish validation summary
   ansible.builtin.set_fact:
     cis_validation_summary:
-      benchmark: "CIS-inspired controls for Debian 13 Trixie and Ubuntu Server 26.04 LTS"
+      benchmark: "selected controls for Debian 13 Trixie and Ubuntu Server 26.04 LTS"
       sshd_config: "{{ 'OK' if cis_sshd_validate.rc == 0 else 'CRITICAL' }}"
       services: "{{ cis_service_state_summary }}"
       packages: "{{ cis_package_validation_summary }}"

infra-run/ansible/roles/cis-debian-ubuntu-hardening/tasks/ssh.yml

@@ -33,7 +33,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^PermitRootLogin\s+'
     line: "PermitRootLogin {{ 'no' if cis_disable_root_login | bool else 'prohibit-password' }}"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh
@@ -43,7 +42,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^PermitEmptyPasswords\s+'
     line: "PermitEmptyPasswords no"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh
@@ -53,7 +51,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^PasswordAuthentication\s+'
     line: "PasswordAuthentication {{ 'no' if cis_disable_password_auth | bool else 'yes' }}"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh
@@ -63,7 +60,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^MaxAuthTries\s+'
     line: "MaxAuthTries {{ cis_ssh_max_auth_tries }}"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh
@@ -73,7 +69,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^LoginGraceTime\s+'
     line: "LoginGraceTime {{ cis_ssh_login_grace_time }}"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh
@@ -83,7 +78,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^ClientAliveInterval\s+'
     line: "ClientAliveInterval {{ cis_ssh_client_alive_interval }}"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh
@@ -93,7 +87,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^ClientAliveCountMax\s+'
     line: "ClientAliveCountMax {{ cis_ssh_client_alive_count_max }}"
-    validate: sshd -t -f %s
   notify:
     - validate ssh
     - restart ssh

infra-run/ansible/roles/cis-debian-ubuntu-hardening/tasks/sysctl.yml

@@ -1,5 +1,5 @@
 ---
-- name: Apply CIS-inspired sysctl settings
+- name: Apply selected sysctl settings
   ansible.posix.sysctl:
     name: "{{ item.key }}"
     value: "{{ item.value }}"

infra-run/ansible/roles/cis-rhel9-hardening/README.md

@@ -1,8 +1,8 @@
-# CIS-Inspired RHEL 9 Hardening Role
+# RHEL 9 Baseline Hardening Role
 
-This role provides a practical, production-style hardening baseline for RHEL 9 and Oracle Linux 9 systems. It is inspired by CIS Benchmark controls for Red Hat Enterprise Linux 9 version 2.0.0, but it is intentionally scoped to common operational controls that infrastructure and security operations teams frequently automate.
+This role provides a practical, baseline hardening example for RHEL 9 and Oracle Linux 9 systems. It is inspired by hardening benchmark controls for Red Hat Enterprise Linux 9 version 2.0.0, but it is intentionally scoped to common operational controls that infrastructure and security operations teams frequently automate.
 
-This is not a full CIS certification implementation.
+This is not a full compliance certification implementation.
 
 ## Supported Platforms
 
@@ -16,7 +16,7 @@ The role fails safely on unsupported operating systems or unsupported major vers
 - SSH daemon hardening for root login, empty passwords, password authentication, retry limits, login grace time, and client keepalive behavior.
 - Removal of selected legacy network packages such as telnet, rsh-server, and ypbind.
 - Optional installation and enablement of chrony, auditd, and rsyslog.
-- CIS-inspired IPv4 network sysctl settings.
+- Selected IPv4 network sysctl settings.
 - Service enablement for chronyd, auditd, and rsyslog.
 - Safe disabling of known legacy services when they are present.
 - Basic audit backlog and audit rule examples.
@@ -26,9 +26,9 @@ The role fails safely on unsupported operating systems or unsupported major vers
 
 ## Safety Philosophy
 
-The defaults are conservative. The role supports Ansible check mode and avoids destructive production behavior by default. Filesystem mount option management is disabled unless `cis_manage_mount_options` is explicitly enabled, and even then the role persists configured options without remounting live filesystems.
+The defaults are conservative. The role supports Ansible check mode and avoids destructive live-system behavior by default. Filesystem mount option management is disabled unless `cis_manage_mount_options` is explicitly enabled, and even then the role persists configured options without remounting live filesystems.
 
-Review variables before using this role in production.
+Review variables before adapting this role to managed hosts.
 
 ## Common Variables
 
@@ -78,6 +78,6 @@ Example:
 ansible-playbook playbooks/cis-rhel9-hardening.yml --tags precheck,ssh,postcheck
 ```
 
-## Production Rollout Notes
+## Rollout Notes
 
 This role is a hardening starting point for internal infrastructure teams. It should be reviewed against local access patterns, break-glass procedures, compliance requirements, monitoring expectations, and host build standards before rollout.

infra-run/ansible/roles/cis-rhel9-hardening/tasks/postcheck.yml

@@ -28,7 +28,9 @@
 
 - name: Build sysctl validation summary
   ansible.builtin.set_fact:
-    cis_sysctl_validation_summary: "{{ cis_sysctl_validation_summary | default({}) | combine({item.item.key: item.stdout | default('unreadable')}) }}"
+    cis_sysctl_validation_summary: >-
+      {{ cis_sysctl_validation_summary | default({})
+      | combine({item.item.key: item.stdout | default('unreadable')}) }}
   loop: "{{ cis_sysctl_validation.results | default([]) }}"
   loop_control:
     label: "{{ item.item.key }}"

infra-run/ansible/roles/cis-rhel9-hardening/tasks/ssh.yml

@@ -22,7 +22,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^PermitRootLogin\s+'
     line: "PermitRootLogin {{ 'no' if cis_disable_root_login | bool else 'prohibit-password' }}"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd
@@ -32,7 +31,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^PermitEmptyPasswords\s+'
     line: "PermitEmptyPasswords no"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd
@@ -42,7 +40,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^PasswordAuthentication\s+'
     line: "PasswordAuthentication {{ 'no' if cis_disable_password_auth | bool else 'yes' }}"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd
@@ -52,7 +49,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^MaxAuthTries\s+'
     line: "MaxAuthTries {{ cis_ssh_max_auth_tries }}"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd
@@ -62,7 +58,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^LoginGraceTime\s+'
     line: "LoginGraceTime {{ cis_ssh_login_grace_time }}"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd
@@ -72,7 +67,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^ClientAliveInterval\s+'
     line: "ClientAliveInterval {{ cis_ssh_client_alive_interval }}"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd
@@ -82,7 +76,6 @@
     path: "{{ cis_ssh_dropin_path }}"
     regexp: '^ClientAliveCountMax\s+'
     line: "ClientAliveCountMax {{ cis_ssh_client_alive_count_max }}"
-    validate: sshd -t -f %s
   notify:
     - validate sshd
     - reload sshd

infra-run/ansible/roles/cis-rhel9-hardening/tasks/sysctl.yml

@@ -1,5 +1,5 @@
 ---
-- name: Apply CIS-inspired sysctl settings
+- name: Apply selected sysctl settings
   ansible.posix.sysctl:
     name: "{{ item.key }}"
     value: "{{ item.value }}"

infra-run/docs/README.md

@@ -1,17 +1,10 @@
-# infra-run/docs
+# docs
 
-This directory is intended for supporting technical documentation tied to the operational tooling in `infra-run`. It is the natural home for implementation notes, architecture writeups, and operational reference material.
+Planned area for longer technical notes.
 
-## Diagram
+Current documentation lives in the project README files plus:
 
-```mermaid
+- [SOURCE.md](../SOURCE.md)
-flowchart TD
+- [TESTED.md](../TESTED.md)
-  A["docs"] --> B["Architecture notes"]
+- [KNOWN_LIMITATIONS.md](../KNOWN_LIMITATIONS.md)
-  A --> C["Operational references"]
+- [ROADMAP.md](../ROADMAP.md)
-  A --> D["Change preparation notes"]
-```
-
-## Notes
-
-- The folder currently contains only a placeholder file.
-- It complements `runbooks` by focusing on reference material rather than step-by-step execution flows.

infra-run/examples/README.md

@@ -0,0 +1,11 @@
+# examples
+
+Sanitized sample outputs for documentation and review.
+
+These files use fake hostnames, reserved example domains, reserved IP address ranges, and invented storage names. They are useful for reading the workflow without exposing real system details.
+
+## Included
+
+- `disk-full/` - sample filesystem usage, deleted open files, and a short after-action report.
+- `veritas/` - sample VxVM disk and VCS service group output.
+- `gpfs/` - sample GPFS cluster and NSD output.

infra-run/examples/disk-full/sample-df-before.txt

@@ -0,0 +1,4 @@
+Filesystem              Size  Used Avail Use% Mounted on
+/dev/mapper/vgapp-lvlog  80G   76G  4.0G  95% /var/log/app
+/dev/mapper/vgapp-lvdata 200G  121G   79G  61% /srv/app
+/dev/sda2                40G   19G   21G  48% /

infra-run/examples/disk-full/sample-lsof-deleted.txt

@@ -0,0 +1,4 @@
+COMMAND     PID   USER   FD   TYPE DEVICE   SIZE/OFF NLINK NODE NAME
+appworker  1842 appsvc   12w   REG  253,7 8589934592     0 9911 /var/log/app/app.log.1 (deleted)
+java       2210 appsvc   45w   REG  253,7 2147483648     0 9919 /var/log/app/gc.log.2 (deleted)
+rsyslogd    712   root    7w   REG  253,7  524288000     0 9924 /var/log/app/messages.old (deleted)

infra-run/examples/disk-full/sample-report-after.txt

@@ -0,0 +1,13 @@
+Disk Full Review - Sanitized Example
+
+Host: host-app-01.example.invalid
+Filesystem: /var/log/app
+Before: 95% used
+After: 72% used
+Actions reviewed:
+- Confirmed largest files under /var/log/app.
+- Identified deleted files still held by appworker and java processes.
+- Confirmed no symlinks were removed during rotated log cleanup.
+- Recommended application owner restart during approved window to release deleted files.
+
+No real hostnames, tickets, or application names are included in this sample.

infra-run/examples/gpfs/sample-mmlscluster.txt

@@ -0,0 +1,11 @@
+GPFS cluster information
+========================
+  GPFS cluster name:         gpfs-lab.example.invalid
+  GPFS cluster id:           1234567890123456789
+  GPFS UID domain:           gpfs-lab.example.invalid
+  Remote shell command:      /usr/bin/ssh
+  Remote file copy command:  /usr/bin/scp
+
+Node  Daemon node name              IP address     Admin node name              Designation
+1     gpfs-node-a.example.invalid   192.0.2.11     gpfs-node-a.example.invalid  quorum-manager
+2     gpfs-node-b.example.invalid   192.0.2.12     gpfs-node-b.example.invalid  quorum-manager

infra-run/examples/gpfs/sample-mmlsnsd.txt

@@ -0,0 +1,5 @@
+ File system   Disk name    NSD servers
+-------------------------------------------------------------------
+ fs_data       nsd_data_01  gpfs-node-a.example.invalid,gpfs-node-b.example.invalid
+ fs_data       nsd_data_02  gpfs-node-a.example.invalid,gpfs-node-b.example.invalid
+ fs_data       nsd_data_03  gpfs-node-a.example.invalid,gpfs-node-b.example.invalid

infra-run/examples/veritas/sample-hagrp-state.txt

@@ -0,0 +1,3 @@
+#Group       Attribute             System               Value
+app_sg01     State                 node-a.example.invalid |ONLINE|
+app_sg01     State                 node-b.example.invalid |OFFLINE|

infra-run/examples/veritas/sample-vxdisk-list.txt

@@ -0,0 +1,5 @@
+DEVICE       TYPE            DISK         GROUP        STATUS
+san_lun_001  auto:none       -            -            online invalid
+san_lun_002  auto:none       -            -            online invalid
+san_lun_010  auto:cdsdisk    dgapp01_01   dgapp01      online
+san_lun_011  auto:cdsdisk    dgapp01_02   dgapp01      online

infra-run/runbooks/README.md

@@ -1,18 +1,5 @@
-# infra-run/runbooks
+# runbooks
 
-This directory is reserved for runbook-style procedures that describe how to perform controlled operational work. It sits alongside the executable scripts and captures the human workflow around them.
+Planned area for standalone runbooks.
 
-## Diagram
+Current runnable workflow notes live with the Bash toolkits under [scripts/bash](../scripts/bash/).
-
-```mermaid
-flowchart TD
-  A["runbooks"] --> B["Pre-check"]
-  A --> C["Change execution"]
-  A --> D["Post-check"]
-  A --> E["Rollback or escalation"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- It is intended to hold narrative procedures that complement the script-based toolkits.

infra-run/scripts/README.md

@@ -14,7 +14,7 @@ flowchart TD
 
 ## Scope
 
-- `bash` - current implementation area with production-style operations toolkits.
+- `bash` - current implementation area with operations toolkits.
 - `python` - reserved space for future supporting utilities.
 
 ## Notes

infra-run/scripts/bash/disk-full/00_env.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 TIMESTAMP="${TIMESTAMP:-$(date +%Y%m%d_%H%M%S)}"
 DRY_RUN="${DRY_RUN:-true}"

infra-run/scripts/bash/disk-full/01_disk_overview.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/02_find_big_files.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/03_deleted_open_files.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/04_top_dirs.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/05_log_cleanup.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/06_quick_fix.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/07_postcheck.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/disk-full/disk_full_runbook.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/00_env.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 TIMESTAMP="${TIMESTAMP:-$(date +%Y%m%d_%H%M%S)}"
 DRY_RUN="${DRY_RUN:-true}"

infra-run/scripts/bash/gpfs/01_cluster_overview.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/02_precheck_gpfs.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/03_detect_new_disks.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/04_create_nsd_stanza.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/05_add_nsd_to_filesystem.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh
@@ -43,8 +41,13 @@ fi
 
 warning "Adding NSDs must be coordinated with storage, GPFS, application, and change-management teams."
 section "Planned GPFS changes"
-ok "DRY-RUN: mmcrnsd -F $NSD_STANZA"
+if [[ "$DRY_RUN" == "true" ]]; then
-ok "DRY-RUN: mmadddisk $FILESYSTEM -F $NSD_STANZA"
+  ok "DRY-RUN: mmcrnsd -F $NSD_STANZA"
+  ok "DRY-RUN: mmadddisk $FILESYSTEM -F $NSD_STANZA"
+else
+  warning "EXECUTE: mmcrnsd -F $NSD_STANZA"
+  warning "EXECUTE: mmadddisk $FILESYSTEM -F $NSD_STANZA"
+fi
 
 confirm_execute "create NSDs and add disks to $FILESYSTEM"
 

infra-run/scripts/bash/gpfs/06_rebalance_filesystem.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh
@@ -48,7 +46,11 @@ if [[ "$BACKGROUND" == "true" ]]; then
     mmrestripefs "$FILESYSTEM" -b 2>&1 | tee -a "$LOG_FILE" &
   fi
 else
-  ok "DRY-RUN: mmrestripefs $FILESYSTEM -b"
+  if [[ "$DRY_RUN" == "true" ]]; then
+    ok "DRY-RUN: mmrestripefs $FILESYSTEM -b"
+  else
+    warning "EXECUTE: mmrestripefs $FILESYSTEM -b"
+  fi
   confirm_execute "restripe for $FILESYSTEM"
   if [[ "$DRY_RUN" == "false" ]]; then
     run_cmd mmrestripefs "$FILESYSTEM" -b

infra-run/scripts/bash/gpfs/07_postcheck_gpfs.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/08_generate_report.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/gpfs/README.md

@@ -1,6 +1,6 @@
 # GPFS / IBM Spectrum Scale Filesystem Expansion Toolkit
 
-Safe, sanitized Bash examples for planning and executing a GPFS / IBM Spectrum Scale filesystem expansion. The scripts are written as portfolio-grade operational tooling for a Linux Infrastructure Engineer: conservative defaults, clear validation, dry-run behavior, and explicit operator confirmation before changes.
+Safe, sanitized Bash examples for planning and executing a GPFS / IBM Spectrum Scale filesystem expansion. The scripts are written as readable operational examples for a Linux Infrastructure Engineer: conservative defaults, clear validation, dry-run behavior, and explicit operator confirmation before changes.
 
 These scripts are examples. Exact GPFS commands, flags, quorum practices, failure-group design, and storage naming standards vary by Spectrum Scale version and site policy.
 

infra-run/scripts/bash/gpfs/gpfs_extend_runbook.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/os-healthcheck/disk_check.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 threshold="${1:-80}"
 
@@ -13,7 +11,7 @@ fi
 status=0
 warning_threshold=$(( threshold > 5 ? threshold - 5 : threshold ))
 
-while read -r filesystem size used avail use_percent mountpoint; do
+while read -r filesystem _size _used avail use_percent mountpoint; do
   usage="${use_percent%\%}"
 
   if (( usage >= threshold )); then

infra-run/scripts/bash/os-healthcheck/healthcheck.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 section() {
   printf '\n== %s ==\n' "$1"

infra-run/scripts/bash/os-healthcheck/network_troubleshoot.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 target="${1:-}"
 status=0

infra-run/scripts/bash/os-healthcheck/service_check.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 services=("$@")
 

infra-run/scripts/bash/os-healthcheck/system_report.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 host="$(hostname)"
 timestamp="$(date '+%Y-%m-%d_%H%M%S')"

infra-run/scripts/bash/veritas/00_env.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 DRY_RUN=true
 TIMESTAMP="$(date +%Y%m%d_%H%M%S)"
@@ -14,7 +12,6 @@ MOUNTPOINT=""
 SIZE=""
 DISKS=""
 
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 
 log() {
   local level="${1:-INFO}"

infra-run/scripts/bash/veritas/01_detect_new_luns.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/02_precheck_vcs_vxvm.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/03_freeze_vcs_group.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/04_init_vxvm_disks.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/05_extend_diskgroup.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/06_extend_volume_fs.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/07_postcheck_vcs_vxvm.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/08_unfreeze_vcs_group.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/bash/veritas/README.md

@@ -1,6 +1,6 @@
 # Veritas VxVM/VCS Storage Expansion Toolkit
 
-Production-style Bash examples for expanding storage in a Veritas environment. These scripts are sanitized operational tooling for a Linux Infrastructure Engineer portfolio: they show the flow, guardrails, logging, and validation patterns used in enterprise change work.
+Bash examples for expanding storage in a Veritas environment. These scripts are sanitized operational tooling for a Linux Infrastructure Engineer portfolio: they show the flow, guardrails, logging, and validation patterns used in controlled infrastructure change work.
 
 ## Diagram
 
@@ -118,4 +118,4 @@ Run individual steps:
 
 ## Operational Reminder
 
-Use these scripts as examples and adapt them to local runbooks, naming standards, multipath stack, Veritas release, filesystem type, and change-control policy before production use.
+Use these scripts as examples and adapt them to local runbooks, naming standards, multipath stack, Veritas release, filesystem type, and change-control policy before live use.

infra-run/scripts/bash/veritas/veritas_extend_runbook.sh

@@ -1,7 +1,5 @@
 #!/usr/bin/env bash
-set -o errexit
+set -euo pipefail
-set -o nounset
-set -o pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=00_env.sh

infra-run/scripts/python/README.md

@@ -1,17 +1,5 @@
-# infra-run/scripts/python
+# python
 
-This directory is reserved for Python helpers that may later complement the Bash-first operations tooling. It provides a separate place for richer parsing, reporting, or integration logic without mixing languages in the same toolkit directory.
+Planned area for small Python helpers.
 
-## Diagram
+No Python tooling is implemented in `infra-run` yet.
-
-```mermaid
-flowchart LR
-  A["python"] --> B["Future reporting utilities"]
-  A --> C["Parsers"]
-  A --> D["Automation helpers"]
-```
-
-## Notes
-
-- The folder currently contains only a placeholder file.
-- Keeping it explicit now makes future multi-language tooling easier to organize.

labs/README.md

@@ -1,26 +1,5 @@
 # labs
 
-This directory collects hands-on lab areas used for experimentation and skill development. It complements the production-style tooling elsewhere in the repository by separating exploratory work from operational examples.
+This directory is reserved for future lab work. The current focus of the repository is [infra-run](../infra-run/).
 
-## Diagram
+Planned lab topics are tracked in [ROADMAP.md](../ROADMAP.md). Subdirectories are placeholders only and should not be treated as completed projects.
-
-```mermaid
-flowchart TD
-  A["labs"] --> B["docker"]
-  A --> C["kubernetes"]
-  A --> D["terraform"]
-  A --> E["networking"]
-  A --> F["ci-cd"]
-```
-
-## Scope
-
-- `docker` - container runtime and image workflow practice.
-- `kubernetes` - orchestration and workload experiments.
-- `terraform` - infrastructure-as-code exercises.
-- `networking` - connectivity and protocol-focused labs.
-- `ci-cd` - pipeline and delivery automation practice.
-
-## Notes
-
-- These folders are intentionally separate from `infra-run` to keep experiments isolated from the operational core.

labs/ci-cd/README.md

@@ -1,18 +1,3 @@
-# labs/ci-cd
+# ci-cd
 
-This folder is intended for CI/CD experiments such as pipeline layouts, validation jobs, artifact flows, and deployment automation patterns.
+CI/CD lab notes are planned. The active validation example is the GitHub Actions workflow at ../../.github/workflows/lint.yml.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["ci-cd"] --> B["Build"]
-  A --> C["Test"]
-  A --> D["Package"]
-  A --> E["Deploy"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- It provides a dedicated area for delivery automation concepts outside the main operations toolkits.

labs/docker/README.md

@@ -1,17 +1,3 @@
-# labs/docker
+# docker
 
-This folder is reserved for Docker-focused lab work. It is intended for image builds, container runtime testing, compose workflows, and lightweight environment simulations.
+Docker lab notes are planned. No implemented Docker example is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["docker"] --> B["Dockerfiles"]
-  A --> C["Compose stacks"]
-  A --> D["Container debugging"]
-```
-
-## Notes
-
-- The directory currently contains only a placeholder file.
-- It represents a sandbox for container workflows rather than finalized portfolio tooling.

labs/kubernetes/README.md

@@ -1,18 +1,3 @@
-# labs/kubernetes
+# kubernetes
 
-This folder is intended for Kubernetes lab work such as manifests, troubleshooting exercises, and orchestration experiments.
+Kubernetes lab notes are planned. No implemented Kubernetes example is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["kubernetes"] --> B["Workloads"]
-  A --> C["Services"]
-  A --> D["Ingress and networking"]
-  A --> E["Cluster troubleshooting"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- It keeps orchestration experiments separate from the production-style script content.

labs/networking/README.md

@@ -1,18 +1,3 @@
-# labs/networking
+# networking
 
-This folder is reserved for networking-focused exercises. It can hold examples around routing, DNS, ports, packet flow, and host-to-host diagnostics.
+Networking lab notes are planned. No implemented networking lab is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["networking"] --> B["Routing"]
-  A --> C["DNS"]
-  A --> D["Firewall and ports"]
-  A --> E["Connectivity tests"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- It complements the operational network diagnostics already present in `infra-run/scripts/bash/os-healthcheck`.

labs/terraform/README.md

@@ -1,17 +1,3 @@
-# labs/terraform
+# terraform
 
-This folder is intended for Terraform experiments and infrastructure-as-code practice. It is the natural place for module trials, state-handling examples, and environment provisioning exercises.
+Terraform lab notes are planned. No implemented Terraform example is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["terraform"] --> B["Modules"]
-  A --> C["Environment configs"]
-  A --> D["Plan and apply workflows"]
-```
-
-## Notes
-
-- The directory currently contains only a placeholder file.
-- It is positioned as a lab space rather than a production-ready IaC stack.

platform-projects/README.md

@@ -1,26 +1,5 @@
 # platform-projects
 
-This directory groups broader infrastructure themes that sit above individual scripts. It highlights larger platform domains such as storage, clustering, monitoring, virtualization, and log analysis.
+This directory is reserved for future platform case studies. The current implemented project is [infra-run](../infra-run/).
 
-## Diagram
+Planned platform topics are tracked in [ROADMAP.md](../ROADMAP.md). Subdirectories are placeholders only and should not be treated as completed work.
-
-```mermaid
-flowchart TD
-  A["platform-projects"] --> B["storage"]
-  A --> C["clustering"]
-  A --> D["monitoring-zabbix"]
-  A --> E["virtualization"]
-  A --> F["elk-log-analysis"]
-```
-
-## Scope
-
-- `storage` - storage engineering themes and patterns.
-- `clustering` - high availability and cluster operations topics.
-- `monitoring-zabbix` - observability and alerting direction.
-- `virtualization` - compute platform and hypervisor-related topics.
-- `elk-log-analysis` - log ingestion, search, and analysis concepts.
-
-## Notes
-
-- These folders are currently high-level placeholders for future platform case studies.

platform-projects/clustering/README.md

@@ -1,18 +1,3 @@
-# platform-projects/clustering
+# clustering
 
-This folder is reserved for clustering-focused platform work. It is meant for high-availability concepts, quorum behavior, failover patterns, and multi-node operational design.
+Clustering case study notes are planned. Current VCS-related examples live under ../../infra-run/scripts/bash/veritas/.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["clustering"] --> B["Quorum"]
-  A --> C["Failover"]
-  A --> D["Service groups"]
-  A --> E["Operational validation"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- Its theme aligns naturally with the Veritas and GPFS toolkits elsewhere in the repository.

platform-projects/elk-log-analysis/README.md

@@ -1,18 +1,3 @@
-# platform-projects/elk-log-analysis
+# elk-log-analysis
 
-This folder is intended for Elastic Stack style log-analysis work. It can hold examples around log pipelines, parsing, dashboards, and troubleshooting based on operational telemetry.
+ELK log-analysis notes are planned. No implemented ELK example is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["elk-log-analysis"] --> B["Ingest"]
-  A --> C["Parse"]
-  A --> D["Search"]
-  A --> E["Visualize"]
-```
-
-## Notes
-
-- The directory currently contains only a placeholder file.
-- It represents a future case-study area for observability and incident analysis patterns.

platform-projects/monitoring-zabbix/README.md

@@ -1,18 +1,3 @@
-# platform-projects/monitoring-zabbix
+# monitoring-zabbix
 
-This folder is reserved for monitoring and alerting work centered on Zabbix-style platform operations. It is a suitable place for host templates, dashboards, trigger design, and operational alert tuning examples.
+Zabbix monitoring notes are planned. No implemented Zabbix example is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["monitoring-zabbix"] --> B["Hosts"]
-  A --> C["Templates"]
-  A --> D["Triggers"]
-  A --> E["Dashboards"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- It complements the healthcheck scripts by representing the monitoring side of infrastructure operations.

platform-projects/storage/README.md

@@ -1,18 +1,3 @@
-# platform-projects/storage
+# storage
 
-This folder is intended for storage-oriented platform topics. It can hold higher-level notes and case studies related to filesystem growth, block storage operations, multipath design, and capacity planning.
+Storage platform case study notes are planned. Current storage workflow examples live under ../../infra-run/scripts/bash/.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["storage"] --> B["Capacity planning"]
-  A --> C["Filesystem expansion"]
-  A --> D["Block device management"]
-  A --> E["Operational safety"]
-```
-
-## Notes
-
-- The directory currently contains only a placeholder file.
-- It is closely related to the GPFS and Veritas operational toolkits under `infra-run/scripts/bash`.

platform-projects/virtualization/README.md

@@ -1,18 +1,3 @@
-# platform-projects/virtualization
+# virtualization
 
-This folder is reserved for virtualization platform topics. It is intended for work around hypervisors, guest lifecycle operations, capacity considerations, and infrastructure hosting patterns.
+Virtualization notes are planned. No implemented virtualization example is present yet. See ../../ROADMAP.md.
-
-## Diagram
-
-```mermaid
-flowchart LR
-  A["virtualization"] --> B["Hypervisors"]
-  A --> C["Guests"]
-  A --> D["Resource planning"]
-  A --> E["Operational maintenance"]
-```
-
-## Notes
-
-- The directory is currently a placeholder.
-- It represents a future area for platform-level case studies beyond the current script collection.