Welcome back to our MAS 9 installation series!

If your experience is anything like ours you will make a ton of mistakes. You will also learn a lot. If you survive, by the end of this article, you will have a live, functioning OpenShift cluster ready to accept MAS 9 in Part 4.

We’ll cover two paths in this article:

• On-Premises: Installing OpenShift on physical or virtual hardware you control, including a real-world hardware bill of materials based on an actual SNO deployment.
• AWS Cloud: Installing Single Node OpenShift on Amazon Web Services, ideal for teams who want to skip the hardware altogether.

Both paths use Red Hat’s Assisted Installer or Agent-Based Installer, which dramatically simplify what used to be a complicated manual process. Let’s get into it.

What We’re Installing and Why It Matters

Single Node OpenShift (SNO) is a full OpenShift cluster compressed onto a single physical or virtual machine. The control plane and worker node are co-located on the same host. This makes it ideal for development environments, proof-of-concept deployments, and smaller production workloads like a dedicated MAS instance for a department or research group.

In a standard multi-node cluster, you would have separate master and worker nodes. SNO collapses all of that into one machine. The tradeoff is no high availability at the node level. If the machine goes down, so does your cluster. For dev and test, that is an acceptable tradeoff. For SNO with MAS 9 and Maximo Manage, it is a practical and economical choice that requires significantly less hardware and overhead than a full cluster.

Architecture Recap

Your SNO setup requires two machines: (1) SNO Server — the single OpenShift node that runs everything, and (2) Bastion Host — a separate Linux or Windows machine you use to issue commands and manage the cluster. The bastion host never joins the cluster

Option A: On-Premises Installation

Hardware Recommendations for the SNO Server

One of the most common questions we receive is: what hardware do I need? The IBM documentation gives minimum specs, but minimum specs and comfortable production operation are two different things. Below is our real-world recommendation based on an actual SNO deployment running MAS 9 with Maximo Manage.

The bill of materials below reflects what was purchased for a working SNO node. This is consumer-grade workstation hardware, not enterprise server hardware, making it accessible and cost-effective for teams evaluating MAS 9 or running smaller-scale deployments. After the initial build, an additional 32 GB of RAM was added, bringing the total to 96 GB.

Component	Part / Model	Price (approx.)
CPU	AMD Ryzen 9 9950X (16-core, 4.3 GHz, AM5, Zen 5)	$533.83 ea.
Motherboard	ASRock B850M PRO-A WIFI AM5 Micro ATX	$138.99 ea.
RAM	Corsair Vengeance 64 GB DDR5-5600 (2×32 GB) — upgraded to 96 GB	$164.99 ea.
Primary NVMe	Samsung 990 Pro 2 TB PCIe Gen4 M.2 (qty 2 per build)	$169.99 ea.
Storage HDD	Seagate BarraCuda 2 TB 7200 RPM (qty 2 per build)	$59.99 ea.
Power Supply	Corsair RM850e 850W Fully Modular, ATX 3.1 & PCIe 5.1	$129.99 ea.
Case	Fractal Design Meshify 2 Black ATX Mid Tower	$174.99 ea.
Total (one build)		~$1,500

Note on RAM

The initial build shipped with 64 GB (2×32 GB). Shortly after, an additional 32 GB kit was added to reach 96 GB. MAS 9 with Maximo Manage will use close to 64 GB under moderate load, so the extra headroom matters.

Why This Hardware Works Well for SNO + MAS 9

The AMD Ryzen 9 9950X is a 16-core workstation-class processor with excellent single-thread and multi-thread performance. OpenShift and MAS benefit from both: the high core count handles pod concurrency, while strong single-core performance keeps the OpenShift API server and scheduler responsive.

The 96 GB of RAM comfortably covers MAS 9 minimum of 64 GB with room to spare for Maximo Manage’s Java heap, persistent volume claims, and system overhead. Two Samsung 990 Pro NVMe drives provide high-speed storage for the OpenShift cluster and persistent volumes. The Seagate BarraCuda HDDs are suitable for archival storage, log offloading, or backups.

Budget-Friendly Alternatives

Not everyone wants to build from scratch with high-end components. Here are accessible alternatives widely available at major retailers (Newegg, Amazon, Micro Center) that meet the SNO requirements for MAS 9:

Component	Budget Option	Approx. Price	Notes
CPU	AMD Ryzen 9 7900X (12-core) or Intel Core i9-13900K	$300–$400	12+ cores minimum
Motherboard	MSI MAG B650 TOMAHAWK WIFI (AM5)	$180–$220	AM5 for DDR5 support
RAM	64 GB DDR5 kit (2×32 GB, any reputable brand)	$120–$160	64 GB is the floor
NVMe	Samsung 990 Pro 1 TB or WD Black SN850X 1 TB	$100–$130	1 TB per slot minimum
Power Supply	Seasonic Focus GX-750 (80+ Gold, 750W)	$100–$120	750W is sufficient
Case	Fractal Design Pop Air or Define 7	$90–$140	Good airflow matters
Estimated Total		~$900–$1,100	Per node

Pre-Built / Server Option

If building a machine isn’t your preference, a Dell PowerEdge T150 or T350 tower server with 64 GB RAM and a fast NVMe drive can serve as a capable SNO host. Look for refurbished enterprise tower servers on eBay or IT liquidation sites for significant savings.

Bastion Host Requirements

The bastion host is your command center. It never joins the OpenShift cluster, instead it is the machine from which you run the MAS CLI, the OpenShift CLI (oc), and installation scripts. It can be Linux or Windows (Windows 10/11 with WSL2 works well).

You can also perform all the functions simply using PowerShell if you prefer. There may be some instances where you must perform some translation(s) from Windows to Linux but we have installed complex OpenShift clusters using this method.

Component	Specification
CPU	4-core (any modern desktop or laptop CPU)
RAM	8 GB minimum, 16 GB preferred
Storage	100 GB free disk space
OS	RHEL 8/9, CentOS Stream, Ubuntu 22.04, or Windows 11 + WSL2
Network	Must reach the SNO node on ports 22, 443, and 6443

Preparing the Bastion Host

Before generating the OpenShift ISO, set up your bastion host with the tools and folder structure you need. This was covered in Part 2; here is a quick setup sequence to confirm your environment is ready to rock:

1. Create the recommended folder structure:

sudo mkdir -p /opt/ibm/mas9/oc sudo mkdir -p /opt/ibm/mas9/mas-cli sudo mkdir -p /opt/ibm/masconfig sudo chmod -R 755 /opt/ibm

• Place your credentials in /opt/ibm/masconfig:
  • pull-secret (your Red Hat OpenShift pull secret JSON from https://console.redhat.com)
  • license.dat (your IBM MAS AppPoints license file from the IBM License Key Center)

• Install Docker on the bastion host (required to download the ISO)

sudo yum install -y docker sudo systemctl start docker sudo systemctl enable docker

Docker Install Troubleshooting

If the Docker install fails with a permission error on /var/log/, you may need to free up disk space. Run ‘du -sh *’ in /var/log to identify large files, then remove them with rm [filename]. Return to the install after clearing space.

Step 1: Generate the OpenShift ISO with the Assisted Installer

Red Hat’s Assisted Installer is a web-based tool that generates a customized bootable ISO image for your specific cluster configuration. You will tell OpenShift exactly how your network is set up, what your node’s IP address is, and what your cluster name and domain will be. The ISO embeds all of this so that when your server boots from it, the cluster practically configures itself.

Log in to the Red Hat Hybrid Cloud Console at https://console.redhat.com

1. Search for “Assisted Installer” and click “Create new cluster.”
2. Fill in the cluster details:
   • Cluster Name: sno (or a descriptive name such as masdev)
   • Base Domain: mas.yourdomain.com (your organization’s DNS subdomain)
   • OpenShift Version: 4.16.x (use the latest stable 4.16 release)
   • Number of Control Plane Nodes: 1 (this is what makes it SNO)
   • Host network configuration: Static (strongly recommended)
3. Enter your static network configuration
   • IPv4 Address: [your SNO node’s IP] / [subnet prefix, e.g., /24]
   • Default Gateway: [your network gateway IP]
   • DNS: [your DNS server IP

---

Example from a Real Deployment

For the our SNO deployment the network was configured as: IPv4 10.0.0.92/24, Gateway 10.0.0.1, DNS x.x.x.x. Your values will differ but this illustrates the format the Assisted Installer expects.

4. Click Next, then select “Install Logical Volume Manager (LVM) Storage.” Click Next.
5. Generate your SSH key on the bastion host:

cd /opt ssh-keygen -t rsa -b 4096 # Accept defaults or specify a custom file name cat /opt/id_rsa.pub # Copy the full output — this is your public SSH key

6. In the Assisted Installer, paste your SSH public key into the “SSH public key” field.
7. Click “Generate Discovery ISO” and wait for the file to be prepared.
8. Click the link to copy the download command. It will look similar to:

curl -L ‘https://api.openshift.com/api/assisted-install/v2/clusters/[cluster-id]/downloads/image’   -o discovery_image_sno.iso

9. On the bastion host, paste and run the download command to retrieve the ISO file.

Step 2: Boot the SNO Server from the ISO

With the ISO downloaded, you now need to boot your SNO server from it. The method depends on your environment:

Physical Hardware (USB boot): Write the ISO to a USB drive using Rufus (Windows) or dd (Linux/Mac). Boot the SNO server from USB by entering the BIOS/UEFI boot menu (usually F12 or Del at POST) and selecting the USB device.

Physical Hardware via IPMI / iDRAC / iLO: If your server has a remote management interface, mount the ISO as virtual media and boot from it without needing a physical USB drive. This is the preferred approach for headless servers.

Virtual Machine (VMware / KVM / Hyper-V): Attach the ISO as a virtual CD/DVD drive, set it as the primary boot device, and start the VM. Installation begins automatically.

If you are using GRUB on a physical machine, you can manually configure it to boot from an ISO image.

Steps:

1. Mount the ISO:
2. Copy the ISO contents to a suitable directory (optional):
3. Add the boot entry to /etc/grub.d/40_custom:
4. Update the GRUB configuration:
5. Reboot and choose the new entry from the GRUB menu.

Summary:

• VM Software: Set the ISO as the boot device and reboot the VM.
• GRUB (Linux): Add an entry to boot from the ISO and reboot.
• Bootable USB: Mount the ISO to a USB stick and boot from it via BIOS/UEFI.

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
menuentry "Boot ISO" {
    set root=(hd0,1)
    loopback loop (hd0,1)/path/to/your.iso
    linux (loop)/path/to/kernel
    initrd (loop)/path/to/initrd
}
sudo cp -r /mnt/* /boot/iso/
sudo mount -o loop /path/to/your.iso /mnt
sudo update-grub
menuentry "Boot from ISO" {
    set isofile="/path/to/your.iso"
    loopback loop (hd0,1)$isofile
    linux (loop)/path/to/your/boot/kernel
    initrd (loop)/path/to/your/initrd
}
sudo nano /etc/grub.d/40_custom
sudo mount -o loop /path/to/your.iso /mnt/iso


Once the SNO server boots from the ISO, it will connect back to the Red Hat Assisted Installer console and register itself as a discovered host. No direct interaction with the server is needed from this point forward.

Step 3: Install the OpenShift Cluster

1. Return to the Red Hat Hybrid Cloud Console (https://console.redhat.com).
2. Navigate to Clusters and click your cluster name (e.g., sno.mas.yourdomain.com).
3. Confirm your SNO server appears as a discovered host. Verify the hostname and IP address.
4. Click “Install Cluster.” The installation process will begin. Expect 30–40 minutes.
5. Monitor progress by clicking “View cluster events.” Events are listed newest-first.

What to Watch For

You will see events such as ‘Host installed’, ‘Waiting for control plane’, and eventually ‘Cluster installed’. Occasional short timeouts on early steps are normal. If the installer appears stuck for more than 15 minutes with no new events, check for errors before intervening.

6. When installation is complete, the console displays:
7. Kubeadmin password — copy this immediately and store it securely
8. Kubeconfig file — download or copy this; you will need it on the bastion host

Important

The Kubeadmin password is displayed only once after installation. If you miss it, it can be recovered later, but it is far simpler to copy it now.

Step 4: Configure the Bastion Host to Manage the Cluster

All cluster management is performed from the bastion host using the oc CLI tool. Here is how to get that configured.

1. Download the OpenShift CLI (oc) on the bastion host:

export VERSION=4.16.37   # Use your installed OCP version curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz   | tar zxvf – oc sudo cp oc /usr/sbin oc version

2. Create the credentials directory and kubeconfig file:

mkdir -p ~/cluster-install/auth cd ~/cluster-install/auth nano kubeconfig # Paste the full kubeconfig content from the Red Hat console # Save and exit

3. Export the KUBECONFIG environment variable:

export KUBECONFIG=~/cluster-install/auth/kubeconfig

4. Test the connection to the cluster:

oc get nodes

You should see your SNO node listed with STATUS Ready. If nothing appears, confirm the kubeconfig file path is correct and the KUBECONFIG variable is properly exported.

5. Make the export permanent by adding it to your bash profile:

vi ~/.bash_profile # Add this line at the end: export KUBECONFIG=~/cluster-install/auth/kubeconfig # Save and exit, then reload: source ~/.bash_profile

Step 5: Post-Installation Verification

Before proceeding to MAS installation, confirm your cluster is fully healthy.

1. Check node status:

oc get nodes

2. Verify all cluster operators are available:

oc get clusteroperators

All operators should show AVAILABLE: True and DEGRADED: False.

3. Quick health check — returns nothing if the cluster is fully healthy:

oc get co | grep -v “True.*False.*False”

4. Confirm LVM Storage class is present:

oc get storageclass

You should see lvms-vg1 listed as the default storage class, configured automatically when you selected LVM Storage during ISO generation.

Option B: AWS Cloud Installation

If you prefer to avoid hardware procurement entirely, AWS is an excellent option for running SNO + MAS 9. You get the same OpenShift cluster on EC2 infrastructure that you can provision and decommission on demand. This is particularly useful for development, testing, or proof-of-concept work where standing up physical hardware is not practical.

Cost Consideration

Running SNO on AWS is not free. Expect $400–$800/month for a suitably sized EC2 instance running continuously. For intermittent use, stopping the instance when not needed reduces costs significantly. AWS Spot Instances are generally not recommended for SNO due to the risk of interruption.

AWS Prerequisites

• An active AWS account with EC2 and Route 53 permissions (or equivalent DNS access)
• An Elastic IP address reserved for the SNO instance
• A security group configured to allow inbound TCP on ports 22, 80, 443, and 6443
• Same Red Hat and IBM credentials as the on-premises path (pull secret, entitlement key, license.dat)
• A bastion host (a separate EC2 instance in the same VPC, or your local machine with VPN access)

Recommended EC2 Instance Configuration

Specification	Recommendation
Instance Type	m5.4xlarge (16 vCPU, 64 GB) minimum; m5.8xlarge (32 vCPU, 128 GB) preferred
Root Volume	300 GB gp3 SSD (encrypted recommended)
Data Volume	500 GB gp3 SSD (attach as a secondary EBS volume)
AMI	Red Hat CoreOS (RHCOS), see documentation for AMI IDs by region/version
Network	Elastic IP attached; public subnet; VPC with internet gateway

RHCOS AMI IDs

Red Hat CoreOS AMI IDs are specific to your AWS region and OpenShift version. Find the correct AMI at: https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/ . Select your OCP version and look for the AWS AMI list.

DNS Configuration for AWS

Create the following DNS entries in Route 53 (or your DNS provider), all pointing to your Elastic IP:

DNS Entry	Points To	Purpose
api.[cluster].[domain]	Elastic IP	Kubernetes API server
api-int.[cluster].[domain]	Elastic IP	Internal API access
*.apps.[cluster].[domain]	Elastic IP	Wildcard for all application routes

The wildcard record (*.apps…) is critical. All application routes, including the MAS console, Maximo Manage, OpenShift built-in services, and the OAuth endpoint all depend on it. Without it, MAS will install but nothing will be reachable.

Installing OpenShift on AWS: Agent-Based Installer

For AWS, the recommended approach is the OpenShift Agent-Based Installer, which generates an ignition configuration that boots and configures your EC2 instance without needing to manually handle an ISO file.

1. Install the OpenShift Installer on your bastion host:

export VERSION=4.16.37 curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-install-linux.tar.gz   | tar xvz openshift-install sudo mv openshift-install /usr/local/bin/

• Create your install-config.yaml for the SNO cluster:

apiVersion: v1 baseDomain: yourdomain.com metadata:   name: sno controlPlane:   hyperthreading: Enabled   name: master   replicas: 1 compute:   – hyperthreading: Enabled     name: worker     replicas: 0 platform:   aws:     region: us-east-1     type: m5.4xlarge pullSecret: ‘[paste your full pull secret JSON here]’ sshKey: ‘[paste your SSH public key here]’

• Generate the ignition configuration:

openshift-install create single-node-ignition-config –dir=./sno-install

• Launch your EC2 instance using the RHCOS AMI for your region and OCP version, with the generated bootstrap.ign as EC2 user data. The instance configures itself automatically during first boot.

• Monitor installation progress via the installer:

openshift-install –dir=./sno-install wait-for install-complete –log-level=info

AWS Full Documentation

For the complete AWS SNO installation procedure including IAM role requirements, VPC configuration, security group rules, and the RHCOS AMI list by region, refer to: https://docs.openshift.com/container-platform/4.16/installing/installing_sno/install-sno-installing-sno.html

• Once installation completes, configure your bastion host using the same Steps 4–5 from the on-premises section above. The kubeconfig setup, oc CLI installation, and verification steps are identical.

Required Network Ports

Whether deploying on-premises or on AWS, the following ports must be open between your bastion host, end-user workstations, and the SNO node:

Port	Protocol	Purpose
22	TCP (SSH)	Bastion host access to SNO node for management (can be restricted after install)
80	TCP (HTTP)	HTTP traffic; redirects to HTTPS. Required for certificate challenges if applicable.
443	TCP (HTTPS)	Web console, all application access, MAS UI, OAuth endpoints
6443	TCP	Kubernetes API server. Required by oc CLI, kubectl, and CI/CD pipelines.

Post-Installation Checklist

Before moving on to Part 4 (MAS Core Installation), verify the following are in place:

• OpenShift cluster is installed and the node shows STATUS: Ready in oc get nodes
• All cluster operators show AVAILABLE: True, DEGRADED: False in oc get clusteroperators
• LVM Storage class (lvms-vg1) is present and set as default
• Kubeconfig is in place on the bastion host at ~/cluster-install/auth/kubeconfig
• KUBECONFIG is exported in .bash_profile and persists across login sessions
• oc version confirms CLI version is compatible with the cluster version
• Kubeadmin password is saved securely (password manager, vault, or equivalent)
• All three DNS entries (api, api-int, *.apps) resolve correctly to the node IP
• Port 6443 is reachable from the bastion host: nc -zv [node-ip] 6443
• IBM pull secret and license.dat are in /opt/ibm/masconfig/ on the bastion host

Conclusion: You Have a Cluster

Getting OpenShift installed is arguably the most technically demanding step in the entire MAS 9 journey. Once you have a live, healthy SNO cluster, the MAS installation process is substantially more guided as the MAS CLI does most of the heavy lifting, provided your prerequisites are in order.

At this point you should have a functioning OpenShift cluster, a configured bastion host with working oc access, and your kubeconfig securely in place. You’re ready for Part 4, where we’ll install MAS Core, configure your IBM Entitlement Key, and lay the foundation for Maximo Manage.

If you find your cluster is showing degraded operators or strange errors, don’t panic. Check the cluster events, look at the pod logs in the openshift-* namespaces, and consult the IBM and Red Hat documentation. OpenShift is very good at telling you what is wrong, but it is occasionally cryptic about it. You will learn to speak the language.

Keep that stress ball handy. You’re doing great.

Resources

• Red Hat Hybrid Cloud Console (Assisted Installer): https://console.redhat.com
• OpenShift SNO Documentation: https://docs.openshift.com/container-platform/4.16/installing/installing_sno/
• RHCOS AMI List for AWS: https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/
• OpenShift Client Downloads: https://mirror.openshift.com/pub/openshift-v4/clients/ocp/
• IBM MAS Documentation: https://www.ibm.com/docs/en/mas
• IBM Container Library (Entitlement Key): https://myibm.ibm.com/products-services/containerlibrary

Stay tuned for Part 4: Installing MAS Core!

Need More Than Just This Article?

If you’re knee-deep in your MAS 9 migration and need more than a stress ball, check out our MAS 9 Resource Center. It’s the central hub for this entire installation series, plus other guides, tools, and resources to help you get from WebSphere to a fully running MAS 9 environment without losing your sanity along the way.

About

A3J Group is a leading solutions and consulting firm based in Tampa, Florida, specializing in Enterprise Asset Management (EAM) with a focus on fully developed Computerized Maintenance Management System (CMMS) solutions like IBM Maximo.

In addition to our suite of proprietary products—including MxMobile, our powerful mobile solution for Maximo—we provide traditional consulting services that help organizations plan, implement, optimize, and support their EAM strategies. Whether clients need hands-on configuration, strategic guidance, or ongoing system support, our team delivers the expertise to drive long-term success.

With over 50 years of combined experience, our specialized team is dedicated to our core mission: to serve as excellent stewards of our clients’ trust and investments, while driving measurable results through tailored, high-impact solutions and intelligent consulting.

Visit us at www.a3jgroup.com. Or drop us a line at info@a3jgroup.com.