mateusz/portfolio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Improve infra-run portfolio credibility
lint / shell-yaml-ansible (push) Failing after 21s
Details

Browse Source
This commit is contained in:
Mateusz Suski
2026-05-08 21:18:22 +00:00
parent deb12a0b4f
commit ca5a876d03
87 changed files with 462 additions and 531 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/lint.yml
+36
View File
@@ -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
+8
View File
@@ -0,0 +1,8 @@
---
extends: default
rules:
line-length:
max: 140
truthy:
allowed-values: ["true", "false", "on"]
CHANGELOG.md
+2 -2
View File
@@ -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
+41 -83
View File
@@ -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
flowchart TD
A["portfolio"] --> B["infra-run"]
A --> C["platform-projects"]
A --> D["labs"]
B --> B1["ansible"]
B --> B2["docs"]
B --> B3["runbooks"]
B --> B4["scripts"]
B1 --> B11["hardening roles"]
B4 --> B41["bash"]
B4 --> B42["python"]
C --> C1["storage"]
C --> C2["clustering"]
C --> C3["monitoring-zabbix"]
C --> C4["virtualization"]
C --> C5["elk-log-analysis"]
D --> D1["docker"]
D --> D2["kubernetes"]
D --> D3["terraform"]
D --> D4["networking"]
D --> D5["ci-cd"]
## What Is Usable Now
- [infra-run](./infra-run/) - the main project in this repository.
- [Linux healthcheck scripts](./infra-run/scripts/bash/os-healthcheck/) - host, disk, service, network, and report helpers.
- [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.
- [Veritas examples](./infra-run/scripts/bash/veritas/) - dry-run-first VxVM/VCS storage expansion workflow examples.
- [GPFS examples](./infra-run/scripts/bash/gpfs/) - dry-run-first IBM Spectrum Scale expansion workflow examples.
- [Ansible hardening examples](./infra-run/ansible/) - selected Linux and AIX baseline hardening tasks organized as lab-safe roles.
## What Is Planned
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).
## What This Repo Is Not
- It is not a compliance benchmark implementation.
- It is not a drop-in change automation framework.
- It is not proof that these exact scripts ran in any production environment.
- It does not replace change review, peer review, backups, monitoring, or platform-specific runbooks.
## Validation
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 Toolkit
[infra-run/scripts/bash/os-healthcheck/](./infra-run/scripts/bash/os-healthcheck/)
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.
### 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.
- Linux operations triage and reporting.
- Disk pressure and deleted-file incident analysis.
- Dry-run-first Bash automation.
- Controlled storage change workflow design.
- Veritas VxVM/VCS operational awareness.
- GPFS / IBM Spectrum Scale operational awareness.
- Ansible role organization for selected hardening controls.
- Clear documentation of what was tested and what still needs a real system.
ROADMAP.md
+21
View File
@@ -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
+9
View File
@@ -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
+62 -26
View File
@@ -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
flowchart TD
A["infra-run"] --> B["ansible"]
A --> C["docs"]
A --> D["runbooks"]
A --> E["scripts"]
E --> E1["bash"]
E --> E2["python"]
## Current Contents
- [scripts/bash/os-healthcheck](./scripts/bash/os-healthcheck/) - general Linux health, service, disk, network, and report scripts.
- [scripts/bash/disk-full](./scripts/bash/disk-full/) - disk-full triage and cleanup review workflow.
- [scripts/bash/veritas](./scripts/bash/veritas/) - Veritas VxVM/VCS storage expansion workflow examples.
- [scripts/bash/gpfs](./scripts/bash/gpfs/) - GPFS / IBM Spectrum Scale expansion workflow examples.
- [ansible](./ansible/) - selected baseline hardening examples for RHEL-like Linux, Debian/Ubuntu, and AIX.
- [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.
- `docs` - supporting technical notes and written documentation.
- `runbooks` - procedural operational guides.
- `scripts` - executable tooling for operations and diagnostics.
## Supporting Notes
## Current Automation
- RHEL 9 CIS-inspired hardening role and playbook.
- Debian 13 / Ubuntu 26.04 CIS-inspired hardening role and playbook.
- 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.
- [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.
- [KNOWN_LIMITATIONS.md](./KNOWN_LIMITATIONS.md) documents technical limits and operational cautions.
- [ROADMAP.md](./ROADMAP.md) tracks planned additions without presenting them as completed work.
infra-run/ROADMAP.md
+16
View File
@@ -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
+37
View File
@@ -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
+44
View File
@@ -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
+3 -3
View File
@@ -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
+3 -3
View File
@@ -14,7 +14,7 @@ flowchart TD
## Notes
- `cis-rhel9-hardening.yml` applies the RHEL 9 CIS-inspired 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-aix7-hardening.yml` applies the IBM AIX 7 CIS-inspired hardening role to AIX 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 selected baseline hardening role to Linux 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 -1
View File
@@ -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 -1
View File
@@ -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 -1
View File
@@ -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
+4 -4
View File
@@ -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-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-aix7-hardening` - CIS-inspired IBM AIX 7 baseline with SSH, sudo, audit, logging, cron, user, password, network, filesystem, service, 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` - Debian 13 and Ubuntu 26.04 baseline example with apt, service, SSH, sudo, sysctl, audit, logging, filesystem, 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
+4 -4
View File
@@ -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
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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
+4 -4
View File
@@ -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
+7 -3
View File
@@ -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
-7
View File
@@ -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 -1
View File
@@ -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
+7 -7
View File
@@ -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
+3 -1
View File
@@ -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
-7
View File
@@ -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 -1
View File
@@ -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
+7 -14
View File
@@ -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
flowchart TD
A["docs"] --> B["Architecture notes"]
A --> C["Operational references"]
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.
- [SOURCE.md](../SOURCE.md)
- [TESTED.md](../TESTED.md)
- [KNOWN_LIMITATIONS.md](../KNOWN_LIMITATIONS.md)
- [ROADMAP.md](../ROADMAP.md)
infra-run/examples/README.md
+11
View File
@@ -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
+4
View File
@@ -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
+4
View File
@@ -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
+13
View File
@@ -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
+11
View File
@@ -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
+5
View File
@@ -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
+3
View File
@@ -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
+5
View File
@@ -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
+3 -16
View File
@@ -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
```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.
Current runnable workflow notes live with the Bash toolkits under [scripts/bash](../scripts/bash/).
infra-run/scripts/README.md
+1 -1
View File
@@ -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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/disk-full/07_postcheck.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/gpfs/00_env.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/gpfs/02_precheck_gpfs.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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
+6 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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"
if [[ "$DRY_RUN" == "true" ]]; then
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
+5 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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
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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/gpfs/08_generate_report.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/gpfs/README.md
+1 -1
View File
@@ -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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/os-healthcheck/disk_check.sh
+2 -4
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
section() {
printf '\n== %s ==\n' "$1"
infra-run/scripts/bash/os-healthcheck/network_troubleshoot.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
target="${1:-}"
status=0
infra-run/scripts/bash/os-healthcheck/service_check.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
services=("$@")
infra-run/scripts/bash/os-healthcheck/system_report.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
host="$(hostname)"
timestamp="$(date '+%Y-%m-%d_%H%M%S')"
infra-run/scripts/bash/veritas/00_env.sh
+1 -4
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/veritas/05_extend_diskgroup.sh
+1 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo 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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/bash/veritas/README.md
+2 -2
View File
@@ -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 -3
View File
@@ -1,7 +1,5 @@
#!/usr/bin/env bash
set -o errexit
set -o nounset
set -o pipefail
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=00_env.sh
infra-run/scripts/python/README.md
+3 -15
View File
@@ -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
```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.
No Python tooling is implemented in `infra-run` yet.
labs/README.md
+2 -23
View File
@@ -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
```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.
Planned lab topics are tracked in [ROADMAP.md](../ROADMAP.md). Subdirectories are placeholders only and should not be treated as completed projects.
labs/ci-cd/README.md
+2 -17
View File
@@ -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.
## 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.
CI/CD lab notes are planned. The active validation example is the GitHub Actions workflow at ../../.github/workflows/lint.yml.
labs/docker/README.md
+2 -16
View File
@@ -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.
## 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.
Docker lab notes are planned. No implemented Docker example is present yet. See ../../ROADMAP.md.
labs/kubernetes/README.md
+2 -17
View File
@@ -1,18 +1,3 @@
# labs/kubernetes
# kubernetes
This folder is intended for Kubernetes lab work such as manifests, troubleshooting exercises, and orchestration experiments.
## 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.
Kubernetes lab notes are planned. No implemented Kubernetes example is present yet. See ../../ROADMAP.md.
labs/networking/README.md
+2 -17
View File
@@ -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.
## 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`.
Networking lab notes are planned. No implemented networking lab is present yet. See ../../ROADMAP.md.
labs/terraform/README.md
+2 -16
View File
@@ -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.
## 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.
Terraform lab notes are planned. No implemented Terraform example is present yet. See ../../ROADMAP.md.
platform-projects/README.md
+2 -23
View File
@@ -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
```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.
Planned platform topics are tracked in [ROADMAP.md](../ROADMAP.md). Subdirectories are placeholders only and should not be treated as completed work.
platform-projects/clustering/README.md
+2 -17
View File
@@ -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.
## 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.
Clustering case study notes are planned. Current VCS-related examples live under ../../infra-run/scripts/bash/veritas/.
platform-projects/elk-log-analysis/README.md
+2 -17
View File
@@ -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.
## 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.
ELK log-analysis notes are planned. No implemented ELK example is present yet. See ../../ROADMAP.md.
platform-projects/monitoring-zabbix/README.md
+2 -17
View File
@@ -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.
## 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.
Zabbix monitoring notes are planned. No implemented Zabbix example is present yet. See ../../ROADMAP.md.
platform-projects/storage/README.md
+2 -17
View File
@@ -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.
## 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`.
Storage platform case study notes are planned. Current storage workflow examples live under ../../infra-run/scripts/bash/.
platform-projects/virtualization/README.md
+2 -17
View File
@@ -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.
## 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.
Virtualization notes are planned. No implemented virtualization example is present yet. See ../../ROADMAP.md.