What looks like a straightforward Packer build — boot from ISO, run kickstart, SSH in, done — turned into a four-day deep-dive when every assumption about the Oracle Linux 9 installer, RHEL9’s SSH daemon configuration, and Ansible module resolution turned out to be wrong. This post documents every failure, the root cause, and the exact fix.

The goal was a fully automated VMware Workstation VM build on Windows using Packer, producing a hardened Oracle Linux 9 Ansible controller that can operate in an air-gapped environment.

The Stack

• Host: Windows 11, VMware Workstation 17.5
• Packer: v1.16.0 with github.com/hashicorp/vmware plugin ≥ 1.0.0
• Guest OS: Oracle Linux 9.8 (OracleLinux-R9-U8-x86_64-dvd.iso)
• Purpose: Ansible controller for STIG automation in air-gapped environments

Problem 1: Anaconda never saw the kickstart — boot_wait = "60s"

Symptom

The VM booted, Anaconda loaded the graphical installer, and showed the Installation Summary screen with red “Kickstart insufficient!” warnings for Root Password and Installation Destination. After 13+ minutes Packer gave up waiting for SSH.

Root Cause

The Oracle Linux 9 isolinux boot menu has a 60-second countdown before it automatically boots the top entry. The Packer config had boot_wait = "60s" — meaning Packer waited the full 60 seconds before sending the <tab> keystroke. The menu had already timed out and auto-booted into a standard graphical install without the kickstart URL.

Fix

boot_wait = "10s"   # catch the menu before it auto-boots
boot_command = [
  "<tab><wait>",
  " inst.ks=http://:/ks.cfg inst.text<enter><wait>"
]

Two changes:

1. boot_wait = "10s" — sends the keystroke while the isolinux menu is still visible
2. inst.text — uses text-mode Anaconda, which is faster and more reliable for unattended installs

Problem 2: BIOS vs. EFI — firmware = "bios" required

Symptom

Even after fixing boot_wait, the <tab> boot command was only working intermittently. On some runs the installer loaded correctly; on others it ignored the keystroke entirely.

Root Cause

VMware Workstation creates VMs in EFI mode by default for guest_os_type = "rhel9-64". EFI boots into GRUB2, which uses a completely different menu interaction model — pressing <tab> does nothing. The isolinux <tab> trick only works in BIOS/legacy mode.

Fix

firmware = "bios"

This forces the VM to boot in BIOS mode, which uses isolinux where <tab> edits the selected boot entry’s kernel command line.

Problem 3: Kickstart “insufficient” — missing explicit rootpw and partitioning

Symptom

Anaconda showed the installation summary screen with red icons on “Root Password” and “Installation Destination” even when the kickstart URL was correctly injected.

Root Cause

The early kickstart file used autopart --type=lvm, which Anaconda 34 (OL9) sometimes fails to parse correctly, and was missing an explicit rootpw directive entirely. Anaconda treats both as “not configured” and requires manual completion.

Fix

rootpw --plaintext CyberSecurity123!
zerombr
clearpart --all --initlabel --disklabel=msdos
part / --fstype=ext4 --size=1 --grow

Simple ext4 over a single MBR partition. No LVM, no complexity. Anaconda handles it without hesitation.

Problem 4: SSH authentication failure after successful install — OL9’s sshd_config.d override

Symptom

After a successful 13-minute installation and reboot, Packer connected to SSH and immediately got:

ssh: unable to authenticate, attempted methods [none publickey password],
no supported methods remain

Password auth was definitely enabled — it was in the kickstart %post. The root password was definitely set.

Root Cause

Oracle Linux 9 (and all RHEL 9 derivatives) ship a drop-in override file at /etc/ssh/sshd_config.d/50-redhat.conf that sets:

PermitRootLogin prohibit-password
PasswordAuthentication no

Files in sshd_config.d/ with a lower filename prefix take precedence over those with a higher one, and all drop-ins override the main sshd_config. Editing /etc/ssh/sshd_config with sed had no effect — the drop-in was winning.

Fix

Add a 01-packer.conf drop-in in the kickstart %post section. Files prefixed 01- load before 50-redhat.conf and override it:

mkdir -p /etc/ssh/sshd_config.d
cat > /etc/ssh/sshd_config.d/01-packer.conf << 'EOF'
PermitRootLogin yes
PasswordAuthentication yes
EOF
chmod 600 /etc/ssh/sshd_config.d/01-packer.conf

Problem 5: Packer provisioner calling yum -y update — network blocked

Symptom

After SSH finally connected, the Packer shell provisioner ran yum -y update and failed:

Curl error (7): Couldn't connect to server for
https://yum.oracle.com/repo/OracleLinux/OL9/appstream/x86_64/...
[Failed to connect to yum.oracle.com port 443: Connection refused]

Root Cause

This is an air-gapped build environment. The provisioner was trying to reach Oracle’s public yum servers which are blocked.

Fix

Remove the yum -y update provisioner entirely. The kickstart already installs everything needed from the local ISO during Anaconda installation (@core, @system-tools, @standard, python3, ansible-core via pip3). The Packer provisioner was redundant.

provisioner "shell" {
  inline = [
    "echo '=== Build verification ==='",
    "python3 --version",
    "ansible --version | head -1",
    "echo '=== Build complete ==='"
  ]
}

Problem 6: Ansible playbook — firewalld module not found

Symptom

ERROR! couldn't resolve module/action 'firewalld'.

Root Cause

ansible-core (installed via pip) does not include the firewalld module. It belongs to the ansible.posix collection which must be installed separately.

Fix

ansible-galaxy collection install ansible.posix

And in the playbook, use the fully-qualified collection name:

- name: Allow http/https through firewalld
  ansible.posix.firewalld:
    service: https
    permanent: yes
    state: enabled
  ignore_errors: yes

Problem 7: lookup(...) is not failed — invalid Jinja2 test

Symptom

The conditional check 'lookup('file', '/opt/offline-assets/assets.tar.gz',
errors='ignore') is not failed' failed.
The error was: The 'failed' test expects a dictionary

Root Cause

The is failed / is not failed Jinja2 tests are designed for task result dictionaries (objects with a failed key), not for strings. lookup('file', ...) returns a string (file contents) or empty string on error — applying is not failed to a string throws a type error.

Fix

Replace all lookup('file', PATH, errors='ignore') is not failed conditions with proper stat module pre-checks:

# Add before the block:
- name: Check for offline bundle
  stat:
    path: /opt/offline-assets/assets.tar.gz
  register: offline_bundle_stat

- name: Import offline asset bundle (if present)
  block:
    - name: Ensure offline folder exists
      file:
        path: /opt/offline-assets
        state: directory
    - name: Unpack offline bundle
      unarchive:
        src: /opt/offline-assets/assets.tar.gz
        dest: /opt/offline-assets/
        remote_src: yes
  when: offline_bundle_stat.stat.exists

Six occurrences of this pattern existed across controller.yml and securityonion.yml. All replaced.

Problem 8: import_role with when: — condition ignored at parse time

Symptom

ERROR! the role 'stig-manager' was not found in ...

Even though the task had when: have_stig_manager and have_stig_manager was false.

Root Cause

import_role is statically resolved at parse time, before any when: conditions are evaluated. Ansible tries to load the role into the play graph immediately — and fails if the role directory doesn’t exist, regardless of the condition.

Fix

Use include_role instead, which is dynamically resolved at runtime and correctly skips when the condition is false:

- name: Run stig-manager role if present
  include_role:
    name: "stig-manager"
  when: have_stig_manager

Manual Intervention Steps Required

Even with a fully automated Packer build, the following steps currently require manual action:

1. Re-attach the ISO after Packer completes

Packer detaches the ISO at the end of the build (Detaching ISO from CD-ROM device ide0:0). If you need to install additional packages from the DVD (e.g., nginx for air-gapped deployments), you must re-attach it in VMware Workstation settings and reboot the VM — the kernel requires a reboot to detect new optical media in VMware.

2. SSH keyboard input from VS Code terminal

VS Code integrated terminals cannot forward keystrokes to interactive SSH password prompts. Solutions:

• SSH key auth — generate a key pair, paste the public key into the VM console, then use -i keyfile with scp/ssh
• sshpass via WSL — sshpass -p 'password' scp ... works reliably
• External terminal (Windows Terminal, cmd.exe) — handles interactive prompts fine

3. Install ansible.posix collection before running the playbook

ansible-galaxy collection install ansible.posix

The collection is not included with ansible-core and there is no offline-first fallback in the current playbook.

Final Build Outcome

After all fixes, the Packer build completes in ~20 minutes:

==> Connected to SSH!
==> === Build verification ===
==> Python 3.9.25
==> ansible [core 2.15.13]
==> === Build complete ===
Build finished after 20 minutes 7 seconds.
Artifacts: VM files in directory: output-oracle_linux

The controller playbook runs to:

PLAY RECAP
localhost: ok=25  changed=8  failed=0  skipped=12  ignored=1

nginx is running as the HTTPS offline asset server, the ansible user is configured with passwordless sudo, and SELinux context is applied to /opt/offline-assets.

Key Takeaways

The full project is on GitHub: KimcheeGI/oracle-stig-so-platform

Security and compliance leadership increasingly depends on the ability to operationalize control frameworks at scale while maintaining governance, auditability, and resilience. In environments where internet access is restricted or deliberately disconnected, this challenge becomes even more significant.

This is precisely where a portable Oracle Linux control appliance can provide strategic value. Designed to support STIG automation, Ansible-driven remediation, and offline Security Onion deployment workflows, it offers an enterprise-ready foundation for hardening and compliance operations in sensitive environments.

Executive Summary

For organizations operating in regulated, classified, or highly constrained networks, maintaining a defensible security posture requires more than manual configuration and periodic audits. It requires a repeatable operating model that can enforce baseline controls, produce evidence, and support continuous oversight without relying on external connectivity.

A purpose-built Oracle Linux VM addresses this need by serving as a centralized control plane for:

• STIG assessment and reporting
• Ansible-based hardening and remediation
• Offline package and repository management
• Security Onion deployment preparation in air-gapped environments

The result is a practical and scalable platform for enterprise security operations that improves compliance readiness while reducing operational risk.

Why This Matters for CISOs and Compliance Teams

For security leaders, the challenge is not only implementing controls, but demonstrating that those controls are effective, consistent, and auditable. This architecture supports that objective by providing a repeatable foundation for hardening, remediation, and evidence collection in environments where manual processes are often too slow or too fragile.

It enables compliance teams to move from periodic reporting toward a more defensible, evidence-based model of continuous assurance, with stronger alignment to regulatory, contractual, and internal governance expectations.

CISM Mapping for the Project

This architecture aligns with the CISM framework by delivering capabilities across mission-critical domains:

• Governance: Structured compliance workflows, centralized evidence collection, and policy-aligned reporting support board- and executive-level oversight.
• Risk Management: Automated STIG evaluation and Ansible-driven remediation reduce exposure and enable more timely risk decisions.
• Program Development: Repeatable deployment workflows, baseline hardening, and offline readiness help institutionalize security controls in constrained environments.
• Incident Management: Offline Security Onion preparation and audit-grade reporting improve the speed and quality of investigation and response planning.

Why This Matters for Executive Leadership

Air-gapped environments are common in government, defense, critical infrastructure, and regulated industry settings. In these contexts, leaders must balance three priorities:

• maintaining mission readiness
• reducing cyber risk
• demonstrating control effectiveness to auditors and stakeholders

A VMware-based Oracle Linux appliance supports these goals by enabling organizations to standardize security operations, improve consistency across systems, and preserve the evidence needed for oversight and reporting.

Core Components

1. Oracle Linux Control Appliance

The base platform provides a secure, stable, and enterprise-supported foundation for hosting automation tools and compliance workflows.

2. Ansible Automation Engine

Ansible enables organizations to implement repeatable hardening and remediation workflows across distributed systems with greater consistency and less manual effort.

3. STIG Manager and Evaluation Workflow

STIG Manager provides the governance layer for tracking compliance outcomes, compiling assessment evidence, and aligning operational activity with recognized security baselines.

4. Offline Security Onion Workflow

In isolated environments, Security Onion deployment can be prepared and staged offline using curated repositories, templates, and configuration artifacts, enabling monitoring capabilities without external connectivity.

Reference Architecture

+---------------------------------------------------------------+
|              Oracle Linux Control Appliance                  |
|                                                               |
|  +----------------------+   +------------------------------+ |
|  |   STIG Manager       |   |   Ansible Automation Engine | |
|  | - Reporting          |   | - Playbooks & Roles        | |
|  | - Compliance Data   |   | - Remediation Workflow     | |
|  +----------+-----------+   | - Offline Repository Prep  | |
|             |               +--------------+---------------+ |
|             |                              |                 |
|             +----------- STIG / CKL / JSON Reports ---------+ |
|                                                              |
+---------------------------+----------------------------------+
                            |
                            v
+---------------------------------------------------------------+
|                 Air-Gapped Target Environment                |
|  - Oracle Linux / RHEL systems                               |
|  - Security Onion deployment workflow                        |
|  - STIG assessment and compliance reporting                 |
+---------------------------------------------------------------+

Operational Benefits

This approach offers several strategic advantages for enterprise security programs:

• standardized deployment of security controls
• faster remediation of configuration drift
• stronger audit readiness through structured reporting
• improved support for disconnected operations
• a reusable foundation for future compliance automation initiatives

A Strategic Fit for Modern Security Programs

The value of this architecture extends beyond technical automation. It supports a broader governance mindset by aligning infrastructure configuration, security controls, and compliance evidence within a disciplined operating model. For CISOs and compliance leaders, that means stronger oversight, better defensibility, and more reliable reporting in environments where manual assurance is insufficient.

Conclusion

CISM Alignment: This platform supports governance, risk management, program development, and incident management by providing a repeatable, audit-ready automation foundation for air-gapped operations.

For organizations operating in high-security, disconnected, or regulated environments, a portable Oracle Linux appliance for Ansible and STIG automation provides a compelling foundation. It enables teams to strengthen hardening practices, improve compliance reporting, and support secure monitoring in air-gapped networks without compromising control, traceability, or operational resilience.

As enterprise security programs continue to mature, architectures like this will play a growing role in connecting automation with assurance.

For organizations operating in air-gapped or restricted networks, security automation must be both practical and resilient. The most effective solutions are not only capable of applying controls, but also of preserving evidence, reducing drift, and supporting repeatable deployment across distributed systems.

This post outlines a technical approach for building an Oracle Linux-based compliance automation workflow using Ansible, STIG-aligned content, and offline repository strategies.

Architectural Approach

The workflow can be organized into four layers:

1. Infrastructure layer
   • Oracle Linux or RHEL-compatible hosts
   • VMware-based deployment model for portability
   • local or mirrored package repositories
2. Automation layer
   • Ansible playbooks and roles
   • inventory-driven execution
   • role-based hardening logic
3. Compliance layer
   • STIG evaluation and reporting
   • evidence collection in JSON, CKL, or similar formats
   • centralized tracking of results
4. Operations layer
   • offline package staging
   • deployment preparation for Security Onion or related monitoring services
   • audit-ready reporting and change tracking

Why Ansible Fits This Model

Ansible is well suited to this environment because it provides a simple, agentless model for enforcing configuration baselines across many systems. In practice, that means teams can:

• define a standard hardening baseline once
• reuse playbooks across multiple systems
• apply changes consistently with version control
• integrate with existing operational and governance processes

For disconnected networks, this becomes especially valuable because the automation logic can be staged locally and executed without relying on external services.

Recommended Workflow

A typical deployment pattern would include:

• preparing offline repositories and dependency bundles
• staging Ansible roles and collections locally
• defining host groups and inventory variables
• applying STIG-aligned playbooks to target systems
• collecting compliance results for reporting and review

This approach allows security teams to build a compliance workflow that is both repeatable and operationally manageable.

Operational Considerations

Successful implementation depends on several practical controls:

• versioned playbooks and role definitions
• clear inventory segmentation by environment or mission scope
• documented rollback procedures
• evidence retention for audit and reporting purposes
• controlled package mirror strategies for disconnected use cases

Conclusion

An Oracle Linux STIG automation workflow built around Ansible is a strong fit for organizations that need to balance security, compliance, and operational efficiency in restricted environments. The combination of automation, evidence collection, and offline readiness creates a foundation that is both practical and defensible.

A practical, governance‑aligned approach for CISOs and security engineers

Executive Summary

Modern cyber threats increasingly rely on browser‑based attack vectors—phishing kits, malicious JavaScript, dynamic redirects, and client‑side payload delivery. Traditional scanners often miss these behaviors because they lack real execution context.

To address this gap, the combination of Model Context Protocol (MCP) and Playwright provides a scalable, repeatable, and evidence‑driven automation stack for cybersecurity teams. This article explores how MCP + Playwright enables dynamic analysis, strengthens governance, and supports CISM‑aligned security operations.

Why Browser Automation Matters Now

Attackers have shifted toward client‑side logic, making the browser itself a critical point of analysis. Examples include:

• MFA‑aware phishing kits
• Obfuscated JavaScript loaders
• Conditional redirects based on geolocation or user agent
• Credential harvesting portals
• Malicious third‑party integrations

Static scanners cannot reliably detect these behaviors.
Browser automation executes the page exactly as a user would, revealing the real threat surface.

Introducing MCP + Playwright

What is MCP?

Model Context Protocol (MCP) is an emerging standard that allows tools and automation engines to communicate through a structured, secure interface. It provides:

• Controlled execution
• Auditability
• Extensibility
• Governance alignment

What is Playwright?

Playwright is a browser automation framework capable of:

• Launching Chromium, Firefox, WebKit
• Capturing screenshots
• Monitoring network traffic
• Extracting scripts
• Dumping DOM content
• Executing JavaScript in context

Together, MCP orchestrates workflows while Playwright performs real browser execution.

Architecture Overview

+—————————+ | VS Code / Agent | | (MCP Client Interface) | +————-+————-+ | | MCP Requests v +—————————+ | MCP Playwright Server | | - Screenshot Tool | | - Script Extractor | | - Network Monitor | | - DOM Dump | +————-+————-+ | | Browser Automation v +—————————+ | Playwright | | Headless Browser Engine | +—————————+ —

Key Cybersecurity Workflows

1. Phishing Analysis

Run phishing-analysis on https://suspicious-domain.com

Outputs:

• Screenshot of the page
• External script inventory
• Network request log
• Indicators of compromise (IOCs)

2. Reconnaissance

Run recon on https://target-site.com

Outputs:

• C2 callbacks
• Suspicious third‑party domains
• Payload delivery attempts

Governance & CISO Alignment

This automation stack supports CISM domains:

Domain 1 — Governance

• Structured, auditable workflows
• Clear separation of duties
• Policy‑aligned automation boundaries

Domain 2 — Risk Management

• Evidence‑based threat validation
• Attack surface mapping
• Real‑context analysis for risk scoring

Domain 3 — Security Program Development

• Repeatable workflows
• Continuous validation of controls
• Integration with SIEM/TI platforms

Domain 4 — Incident Management

• Faster triage
• Automated phishing investigation
• IOC extraction and enrichment

Example Output (Network Monitor)

```json { “url”: “https://suspicious-domain.com/login”, “requests”: [ { “method”: “GET”, “url”: “https://cdn.badjs.io/loader.js” }, { “method”: “POST”, “url”: “https://exfil.attacker.net/collect” } ] }