β€œThis wasn't just a MediaWiki upgrade. It was the construction of an entire ecosystem to support it.”

🧱 Foundation: Virtualization Setup

  • Started on VMware ESXi
  • Initial challenge: VMs couldn’t communicate with one another
  • Troubleshot and confirmed virtual network misconfiguration
  • Introduced basic network segmentation by organizing containers into named networks (e.g. net1, step0, etc.), ensuring that services could communicate securely and without conflict

πŸ”§ Provisioning Automation: Kickstart

  • Set up a Kickstart server to provision RHEL VMs automatically
  • Encountered environment-specific blockers (no DHCP, limited repo access)
  • Configured a local web server (https://<kickstart_host>/kickstarts) to serve .ks files
  • Validated provisioning with test VMs and revised partitioning and post-install scripts

🐳 Containers and Services

  • Transitioned from monolithic setups to container-based infrastructure
  • Used Docker Compose initially, later adapted for Podman in RHEL8
  • Set up containers for:
    • mediawiki-mw1359 (MediaWiki 1.35.9)
    • mariadb-mw1359 (database backend)
    • phpmyadmin-mw1359 (for DB access)
  • Mapped volumes and configs to persist data and simplify rollback

πŸ” Networking, Proxy, and SSL

  • Built a reverse proxy on efs5 using Nginx
  • Configured port forwarding for rootless containers
  • Handled SSL certificates (and eventually removed SSL configs inside containers)
  • Ensured Apache could run cleanly with or without HTTPS inside the container

Local Repository for continuous development

πŸ§ͺ Staging and Debugging

  • Created isolated test networks (step0, step1, etc.) to avoid port conflicts
  • Exported/imported DB snapshots throughout each phase
  • Used curl and direct IPs to test routing when DNS was unreliable
  • Confirmed success (e.g., `/index.php/Main_Page` responding with 200 OK)

πŸ›‘οΈ Compliance and Controlled Connectivity

This environment is air-gapped by design, with strictly limited upstream access:

  • Nginx host handles reverse proxy duties and controlled web serving
  • Corporate-approved repositories are accessible to meet Puppet compliance standards

All content (Kickstarts, repos, container images, extensions) is hosted internally, and all environment customizations are version-controlled in:

/fred/IT (internal GitLab)

Though fully certified, the setup is often mischaracterized as β€œwild west.” This documentation helps clarify the structure, stability, and compliance built into the system from day one.

πŸ“Œ Key Lessons (So Far)

  • Environment setup can be more complex than the application itself
  • Kickstart and containerization paid off once stabilized
  • Every major step deserved its own project tracking
  • Naming and structure (like DocTrack) help connect the dots long-term