Files
portfolio/infra-run/README.md
T
Mateusz Suski 8a7b7c5abc
lint / shell-yaml-ansible (push) Failing after 20s
Clean up Python log analysis documentation
2026-05-11 17:10:10 +00:00

5.5 KiB

infra-run

infra-run is a sanitized infrastructure operations project. It contains Bash, Ansible, Python, and documentation examples based on Linux administration, incident response, storage operations, hardening, prechecks, postchecks, and controlled change workflows.

The goal is to show operational judgment, not to ship a universal automation product.

Current Contents

Bash Operational Scripts

Python Log And Reporting Tools

Ansible Automation

  • ansible - selected baseline hardening examples for RHEL-like Linux, Debian/Ubuntu, and AIX.

Runbooks And Documentation

  • examples - sanitized sample command outputs and incident notes.

Documentation

  • docs/operations-cheatsheet.md - production operations quick reference covering Linux/Unix triage, text processing, incident workflows, networking, storage, AIX, SSL/TLS, automation safety, Ansible execution, observability, and operational habits.

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.
  • Python log analysis examples can be run against sanitized sample logs under each tool directory.
  • Ansible YAML and role structure can be linted locally.

Running Safely

  • Start with the relevant README or runbook before executing a script.
  • Prefer read-only discovery scripts before remediation scripts.
  • Use dry-run mode unless a script explicitly documents safe local behavior.
  • Only use --execute after reviewing inputs, affected systems, rollback options, and post-checks.
  • For Ansible, start with --check --diff against a lab inventory.

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 are fake and sanitized.

Tested

See 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:

./scripts/validate-repo.sh

Focused checks are available in scripts/check-bash.sh, scripts/check-ansible.sh, scripts/check-python.sh, and scripts/check-docs.sh. If ansible-lint reports collection-related issues, install the collections listed in ansible/collections/requirements.yml and rerun it. Treat lint as a starting point; platform testing still requires actual target systems.

Supporting Notes

  • SOURCE.md explains why this project exists and what experience shaped it.
  • TESTED.md lists what was checked locally and what was not.
  • KNOWN_LIMITATIONS.md documents technical limits and operational cautions.
  • ROADMAP.md tracks planned additions without presenting them as completed work.
  • ../AGENTS.md and ../docs/codex document repository working rules and review expectations.