Forem: Bonthu Durga Prasad

Oracle Linux 7 to 8 Upgrade Using Leapp: Architecture, Inhibitors, and Enterprise Troubleshooting

Bonthu Durga Prasad — Fri, 22 May 2026 09:12:00 +0000

Introduction

Enterprise Linux operating systems require periodic upgrades to maintain security, supportability, compliance, and operational stability.

As organizations modernize infrastructure platforms, migrating from Oracle Linux 7 to Oracle Linux 8 becomes important because Oracle Linux 8 introduces:

✔ Modern package management
✔ Improved security
✔ Better kernel support
✔ Enhanced automation compatibility
✔ AppStream modular repositories
✔ Long-term enterprise support

However, major Linux upgrades are not simple package updates.

They involve:

✔ Repository transitions
✔ Package dependency changes
✔ Kernel migration
✔ Bootloader modifications
✔ Service compatibility validation
✔ Third-party package handling

Oracle Linux provides the Leapp upgrade utility to automate and orchestrate Oracle Linux 7 to Oracle Linux 8 migrations safely.

In this blog, we will perform a complete deep dive into:

✔ Configuring Leapp repositories
✔ Installing Leapp utility
✔ Preupgrade analysis
✔ Understanding inhibitors
✔ Answer file handling
✔ Repository migration
✔ Upgrade execution
✔ Upgrade boot workflow
✔ Enterprise troubleshooting
✔ Real-world operational challenges

Understanding Leapp

Leapp is an in-place upgrade utility used to migrate Oracle Linux 7 systems to Oracle Linux 8.

Why Major OS Upgrades Are Complex

Upgrading from Oracle Linux 7 to Oracle Linux 8 involves platform-level architectural changes.

These include:

✔ Kernel transitions
✔ Package replacement
✔ Repository mapping
✔ Driver compatibility
✔ Service migration
✔ Security policy updates
✔ Boot environment changes

Note : Operating system upgrades are not only package upgrades — they are full platform transitions.

Oracle Linux Upgrade Architecture

The Leapp upgrade process follows multiple operational stages.

Upgrade Workflow

Oracle Linux 7
│
▼
Repository Validation
│
▼
Leapp Installation
│
▼
Preupgrade Analysis
│
▼
Inhibitor Detection
│
▼
Answer File Validation
│
▼
Upgrade Initramfs Creation
│
▼
System Reboot
│
▼
Upgrade Environment Boot
│
▼
Package Migration
│
▼
Oracle Linux 8

Step 1: Verify Current Oracle Linux Version

Before starting the migration, validate the current OS version.

Command:

cat /etc/os-release

Example output:

NAME="Oracle Linux Server"
VERSION="7.x"

Step 2: Verify Current Repositories

Repository consistency is critical before performing upgrades.

Check repositories:

yum repolist

Why Repository Validation Matters

Broken or duplicate repositories may cause:

✔ Dependency failures
✔ Package mapping errors
✔ Upgrade inhibitors
✔ Incomplete migrations
✔ Boot failures

Add Leapp Repository Configuration

Navigate to repository directory:

cd /etc/yum.repos.d/

Create or validate Oracle Linux repositories.

Example:

[ol7_leapp]
name=Oracle Linux 7 Leapp Repository
baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/leapp/x86_64/
enabled=1
gpgcheck=1

Refresh Repository Metadata
yum clean all
yum makecache

Step 4: Install Leapp Utility

Install required Leapp packages.

Command:

yum install -y leapp-upgrade leapp-data-oraclelinux

What Gets Installed?

Leapp installs:

✔ Upgrade actors
✔ Dependency analysis modules
✔ Migration logic
✔ Repository mapping data
✔ Upgrade workflows

Verify Leapp Installation

rpm -qa | grep leapp

Step 5: Understanding Leapp Preupgrade

Before performing the actual upgrade, Leapp performs extensive system analysis.

Command:
leapp preupgrade

What Happens During Preupgrade?

Leapp analyzes:

✔ Installed packages
✔ Drivers
✔ Repository configuration
✔ Bootloader state
✔ Kernel compatibility
✔ Unsupported packages
✔ Dependency conflicts
✔ Security policies

Operational Insight
The preupgrade phase prevents unsafe migrations before system modification begins.

Understanding Inhibitors

One of the most important Leapp concepts is inhibitors.

What Are Inhibitors?

Inhibitors are conditions that stop the upgrade from continuing safely.

If inhibitors exist, Leapp blocks the upgrade process.

Why Inhibitors Exist

Inhibitors protect systems from unsafe migration scenarios.

Examples:

✔ Unsupported repositories
✔ Duplicate repository entries
✔ Deprecated packages
✔ Missing answer files
✔ Third-party RPM conflicts
✔ Unsupported drivers
✔ Incorrect boot configuration

Real Repository Inhibitor Example

Example error:

Repository ol8_baseos_latest is listed more than once in the configuration.

Why This Happens

Possible causes:

✔ Duplicate .repo files
✔ Custom repositories
✔ Third-party repositories
✔ Incorrect migration preparation

Fixing Duplicate Repositories

Check repository directory:

ls -l /etc/yum.repos.d/

Review duplicate repository definitions:

grep -r "ol8_baseos_latest" /etc/yum.repos.d/

Remove duplicate entries carefully.

Understanding Leapp Answer Files

This is one of the most important upgrade concepts.

What Are Answer Files?

During upgrades, Leapp may require administrator confirmation for specific migration decisions.

Leapp stores these prompts inside answer files.

Location:

/var/log/leapp/answerfile

Why Answer Files Matter

Leapp blocks upgrades until required questions are answered.

Example:

Missing required answers in the answer file.

View Required Answers

Command:

leapp answer --section remove_pam_pkcs11_module_check.confirm=True

What Does This Do?

This command confirms specific upgrade actions required by Leapp.

Operational Insight

Answer files help administrators explicitly approve risky or environment-specific migration decisions.

Understanding Repository Migration

Oracle Linux 7 and Oracle Linux 8 use different repository structures.

Oracle Linux 7 Repositories

✔ ol7_latest
✔ ol7_UEKR6
✔ Optional repositories

Oracle Linux 8 Repositories

✔ BaseOS
✔ AppStream
✔ UEK repositories

Repository Mapping Workflow

OL7 Repositories
│
Repository Mapping
│
▼
OL8 BaseOS + AppStream

Understanding AppStream Repositories

Oracle Linux 8 introduces AppStream modular repositories.

Unlike Oracle Linux 7:

Packages are grouped into modules and streams.

Examples:

✔ Python streams
✔ NodeJS streams
✔ Database modules

This increases flexibility but also migration complexity.

Third-Party Repository Challenges

Enterprise systems commonly use third-party repositories.

Examples:

✔ EPEL
✔ Monitoring agents
✔ Security tools
✔ Vendor repositories
✔ Backup software

Example EPEL Problem

Example error:

No package epel-release available
Why This Happens

Possible causes:

✔ Repository incompatibility
✔ Incorrect release version
✔ Unsupported packages
✔ Missing metadata

Step 6: Execute Upgrade

Once inhibitors are resolved, begin the upgrade.

Command: leapp upgrade

What Happens Internally?

Leapp performs:

✔ Upgrade initramfs creation
✔ Bootloader modification
✔ Package migration
✔ Repository transition
✔ Kernel migration
✔ Service migration
Understanding Upgrade Initramfs

This is one of the most advanced upgrade concepts.

What is Upgrade Initramfs?

Leapp temporarily boots into a dedicated upgrade initramfs environment outside the running Oracle Linux 7 userspace.

This isolated environment safely performs package replacement operations.

Upgrade Boot Workflow

Normal OL7 Boot
│
▼
Upgrade Initramfs
│
▼
Package Migration
│
▼
OL8 Boot

Why Upgrade Initramfs Is Required

Leapp performs the upgrade outside the running Oracle Linux 7 userspace to avoid active package conflicts and dependency corruption during migration.

The temporary upgrade initramfs environment provides an isolated userspace where package replacement, repository switching, kernel migration, and dependency updates can occur safely without interfering with the currently running operating system.

This isolation significantly reduces the risk of package inconsistency and upgrade instability during major platform transitions.

Step 7: Reboot the System

After upgrade preparation:

reboot

The system boots into the temporary upgrade environment.

Migration occurs automatically.

Step 8: Verify Oracle Linux 8 Upgrade

After reboot completes:

Verify OS Version
cat /etc/os-release

Common Real-World Upgrade Problems

Many upgrade failures occur because of environment inconsistencies rather than Leapp itself.

Common Operational Problems

✔ Repository duplication
✔ Dependency conflicts
✔ Unsupported packages
✔ Missing drivers
✔ Bootloader issues
✔ EPEL incompatibility
✔ Service startup failures
✔ Network configuration mismatches
✔ SELinux conflicts

Upgrade Failure Recovery

If the upgrade process fails during migration, administrators should analyze Leapp reports, validate repositories, review inhibitors, and restore systems using backups or boot volume snapshots when necessary.

/var/log/leapp/leapp-report.txt

/var/log/leapp/leapp-upgrade.log

/var/log/leapp/leapp-preupgrade.log

Leapp logs provide detailed visibility into dependency analysis, migration stages, repository transitions, and package failures.

Rollback and Recovery Planning

Enterprise upgrades should always include rollback preparation.

Before upgrades:

✔ Create backups
✔ Snapshot boot volumes
✔ Validate rollback workflows
✔ Test upgrades in staging
✔ Document recovery procedures

Why Rollback Planning Matters

If upgrades fail unexpectedly:

Rollback capability reduces downtime and operational risk.
Enterprise Upgrade Best Practices

✔ Validate backups before upgrade
✔ Remove unsupported repositories
✔ Review Leapp reports carefully
✔ Resolve inhibitors completely
✔ Test upgrades in staging first
✔ Validate applications after migration
✔ Monitor services post-upgrade
✔ Maintain rollback procedures

Conclusion

Leapp provides a powerful and automated framework for migrating Oracle Linux 7 systems to Oracle Linux 8 through dependency analysis, repository validation, package migration, and upgrade orchestration.

Although the migration process is heavily automated, successful enterprise upgrades still require careful planning, repository consistency, inhibitor analysis, answer file validation, operational testing, and rollback preparation to ensure production stability.

Modern Linux upgrades are no longer simple package updates — they are enterprise platform modernization workflows requiring operational engineering discipline.

OCI Web Application Firewall (WAF) Deep Dive: Architecture, Traffic Inspection, Threat Protection, and Enterprise Security Design

Bonthu Durga Prasad — Thu, 21 May 2026 10:53:56 +0000

Introduction

Modern applications exposed to the internet constantly face threats including SQL injection, bots, DDoS attacks, malicious traffic, and Layer 7 attacks.

OCI Web Application Firewall (WAF) helps protect internet-facing applications by inspecting and filtering HTTP/HTTPS traffic before it reaches backend applications.

What is OCI WAF?

OCI WAF performs Layer 7 traffic inspection, request filtering, threat detection, and policy enforcement before traffic reaches protected applications.

-> It acts like a security checkpoint for web traffic.

Why WAF Is Needed

✔ SQL Injection
✔ Cross-Site Scripting (XSS)
✔ Bot Traffic
✔ DDoS attacks
✔ Credential stuffing
✔ Malicious HTTP requests

Real-world Example

Attacker sends malicious SQL payload
→ Application vulnerable
→ Database compromise possible

WAF helps block malicious requests before they reach applications.

OCI WAF Architecture

Users
│
▼
OCI WAF
│
Traffic Inspection
│
▼
OCI Load Balancer
│
▼
Application Servers

Understanding Layer 7 Security

Traditional firewalls focus mainly on network traffic.
WAF focuses on HTTP/HTTPS application traffic.

-> OCI WAF operates at Layer 7 of the OSI model.

Layer 7 Examples

✔ URLs
✔ HTTP headers
✔ Cookies
✔ Request payloads
✔ API requests
✔ User agents

Request Inspection Workflow

Traffic Flow

User sends HTTPS request
Request reaches OCI WAF
WAF evaluates rules
Threat intelligence checks executed
Malicious payload detected
Request blocked or allowed
Safe traffic forwarded

OCI WAF Security Policies

WAF policies define how traffic should be inspected and filtered.

Examples
✔ Access rules
✔ IP blocking
✔ Country filtering
✔ Threat protection
✔ Rate limiting
✔ Bot management
✔ CAPTCHA challenges

Rate Limiting

Rate limiting controls excessive traffic requests.

Real-world example:

Bot sends 10,000 login attempts
→ WAF rate limiting blocks abuse

Bot Protection

Not all traffic comes from real users.

Bot Examples
✔ Credential stuffing bots
✔ Scraping bots
✔ Fake traffic generators
✔ Automated attack tools

-> OCI WAF helps differentiate legitimate traffic from automated malicious behavior.

OCI WAF Deployment Models

OCI WAF can be deployed in different architectures depending on traffic flow, security requirements, and application design.

Edge WAF

Traffic inspected closer to internet edge locations before reaching OCI infrastructure.

Regional WAF

Traffic inspection occurs within OCI regional deployment architecture.

Load Balancer Attached WAF

OCI WAF integrated directly with OCI Load Balancer for backend application protection.

WAF + Load Balancer Integration

Users
│
▼
OCI WAF
│
▼
OCI Load Balancer
│
▼
Backend Applications

WAF protects applications before traffic reaches backend infrastructure.

Real Enterprise Scenario

Example:

E-Commerce Platform

Users
→ WAF
→ Load Balancer
→ Web Servers
→ Payment Application
→ Database

Attack Example

Attacker sends malicious login traffic
→ WAF blocks suspicious requests
→ backend remains protected

Common WAF Challenges

✔ False positives
✔ Legitimate traffic blocked
✔ Poor rule tuning
✔ SSL misconfiguration
✔ Missing exclusions
✔ Excessively strict policies

Understanding False Positives

Sometimes legitimate application traffic may match security rules and become blocked accidentally.

Examples :

✔ Complex API payloads
✔ Encoded requests
✔ Search queries with special characters
✔ Custom application parameters

-> Effective WAF deployment requires balancing security and application usability.

WAF vs Traditional Firewall

Traditional Firewall	WAF
Network traffic	HTTP/HTTPS traffic
IP/Port filtering	Application inspection
Layer 3/4	Layer 7
Infrastructure protection	Application protection

Observability & Monitoring

WAF visibility is critical for security operations.

Monitoring Areas

✔ Blocked requests
✔ Attack patterns
✔ Bot traffic
✔ Request trends
✔ Security events
✔ Rate limit violations

Enterprise Best Practices

✔ Enable HTTPS inspection
✔ Continuously tune rules
✔ Monitor false positives
✔ Combine WAF with Load Balancer
✔ Enable logging
✔ Review attack trends
✔ Test security policies regularly

Understanding WAF Limitations

Although OCI WAF provides strong Layer 7 protection, it is not a complete replacement for secure application design.

✔ HTTP/HTTPS traffic only
✔ Requires rule tuning
✔ Cannot fully stop business logic abuse
✔ Secure coding still required
✔ Advanced attacks may bypass weak policies

Defense in Depth Security Architecture

Enterprise security should combine multiple security layers rather than relying on a single protection mechanism.

✔ OCI WAF
✔ OCI Network Firewall
✔ NSGs
✔ IAM Policies
✔ Secure Coding
✔ Vulnerability Scanning
✔ Logging & Monitoring
✔ Threat Detection

Conclusion

OCI WAF provides Layer 7 application protection by inspecting, filtering, and securing HTTP/HTTPS traffic before it reaches backend applications.

By combining threat protection, rate limiting, bot mitigation, and traffic inspection, OCI WAF helps organizations improve application security and operational resilience in modern cloud environments.

OCI Full Stack Disaster Recovery (FSDR) Deep Dive: Architecture, Switchover, Failover, and Recovery Workflows

Bonthu Durga Prasad — Wed, 20 May 2026 08:08:37 +0000

Introduction

Disaster recovery in cloud environments is no longer limited to restoring virtual machines or recovering storage volumes. Modern enterprise applications depend on tightly coupled compute, networking, databases, load balancers, DNS, and application dependencies.

OCI Full Stack Disaster Recovery (FSDR) introduces orchestration-driven recovery workflows that coordinate infrastructure and application recovery across regions while minimizing operational risk and downtime.

FSDR IS NOT BACKUP
Backup protects data.
Disaster recovery restores application continuity.

FSDR focuses on orchestrating complete application recovery, not only restoring individual resources.

This blog explains the deeper architecture and operational concepts behind OCI FSDR, including recovery orchestration, dependency sequencing, traffic redirection, resiliency engineering, and enterprise recovery design patterns.

Traditional backups help restore files or databases, but enterprise applications require coordinated recovery across multiple infrastructure layers.

Example:

Database restored successfully
→ application services unavailable
→ load balancer returns errors
→ business outage continues

Architecture Overview

FSDR setup follows a simple two-region design. The primary region hosts the live application stack, including compute, load balancer, database, and storage components. The secondary region keeps the standby resources ready for recovery.

All these resources are placed into Disaster Recovery Protection Groups, which help FSDR understand what belongs together. Once the groups are created, recovery plans can be built to define the exact order of actions during switchover or failover. This makes disaster recovery far more predictable and much easier to test.

Enterprise Multi-Region Disaster Recovery Architecture

Primary and DR Region Design

Users
│
▼
Primary OCI Region
│
├── Public Load Balancer
├── Web Tier
├── Application Tier
├── Database Tier
└── Storage Layer
│
Replication / Synchronization
│
▼
Disaster Recovery Region
│
├── Standby Infrastructure
├── Recovery Workflows
├── Replicated Data
└── Traffic Redirection

Understanding Recovery Orchestration

One of the most important concepts in FSDR is orchestration.

FSDR does not recover everything simultaneously.

Instead, recovery occurs in dependency-aware orchestration stages.

Example Recovery Workflow

Validate DR environment
Attach replicated storage
Recover database services
Validate database health
Start application services
Start web services
Update load balancer routing
Redirect traffic
Validate application response

This sequencing reduces operational failures during recovery events.

Why Dependency Order Matters

Application continuity depends heavily on startup sequencing.

Incorrect startup order is one of the most common disaster recovery failures.

Example:

Web tier starts before database recovery
→ application connection failures
→ unstable service state

OCI FSDR helps coordinate these dependencies through orchestrated recovery execution.

Traffic Flow During Disaster Recovery

Understanding traffic movement during failover is critical.

Normal Traffic Flow
Users
│
▼
Primary Load Balancer
│
▼
Application Stack

Disaster Event
Primary region unavailable
Recovery Flow
FSDR initiates recovery workflows
→ DR region activated
→ services validated
→ traffic redirected
→ application restored

Switchover vs Failover

Although these terms are often used interchangeably, operationally they are very different.

Switchover

Switchover is a controlled transition between regions.

Controlled migration with synchronized application state.

Typical use cases:

✔ Planned maintenance
✔ DR drills
✔ Infrastructure migration
✔ Region transition testing

Failover

Failover occurs during an actual disruption.

Emergency recovery during infrastructure failure.

Typical use cases:

✔ Region outage
✔ Critical disaster
✔ Connectivity failure
✔ Infrastructure incident

Key Operational Insight

Switchover focuses on continuity.
Failover focuses on survivability.

Recovery Objectives in Enterprise DR

Disaster recovery design is heavily influenced by two key metrics.

RTO (Recovery Time Objective)
Maximum acceptable downtime.

Example:

Application must recover within 15 minutes.
RPO (Recovery Point Objective)
Maximum acceptable data loss window.

Example:

5-minute replication lag accepted.

Important Design Insight

Lower RTO and RPO increase infrastructure complexity and operational cost.

This is one of the biggest design tradeoffs in enterprise disaster recovery.

Observability During Disaster Recovery

Recovery orchestration without observability creates blind operational recovery.

Monitoring and validation are essential during DR events.

Critical observability areas include:

✔ Replication health
✔ Recovery progress
✔ Application validation
✔ Service health
✔ Traffic routing
✔ Error monitoring

Without proper validation, infrastructure may recover while applications remain unavailable.

Real Enterprise Scenario

Consider a multi-tier banking application deployed across OCI regions.

Architecture:

Internet
│
▼
Public Load Balancer
│
▼
Web Tier
│
▼
Application Tier
│
▼
Database Tier

Disaster Recovery Deployment Models

One of the most important architectural decisions in disaster recovery design is selecting the appropriate DR deployment model.

The choice depends on:

✔ Recovery speed requirements
✔ Business criticality
✔ Infrastructure cost
✔ Operational complexity
✔ Acceptable downtime
✔ Recovery objectives (RTO/RPO)

Enterprise DR strategies are commonly divided into:

✔ Cold DR
✔ Warm DR
✔ Hot DR

old Disaster Recovery (Cold DR)
What is Cold DR?

Cold DR is the most cost-optimized disaster recovery model.

Simple explanation:

Infrastructure is created only during disaster recovery events.

In this model, the DR region does not continuously run the full application stack.

Instead:

✔ Backups are stored
✔ Configurations are maintained
✔ Infrastructure is provisioned during disaster
Cold DR Architecture
Primary Region
│
├── Running Production Environment
│
▼
DR Region
│
├── Backup Storage
├── Infrastructure Templates
└── Minimal Active Resources

**Cold DR Workflow

During disaster:**

Disaster detected
Infrastructure provisioned in DR region
Storage restored
Database recovered
Application deployed
Traffic redirected

Warm Disaster Recovery (Warm DR)

What is Warm DR?

Warm DR provides a balance between recovery speed and infrastructure cost.

Simple explanation:

A partially running standby environment exists in the DR region.

Some infrastructure components remain active continuously.

Example:

✔ Database replication active
✔ Standby compute available
✔ Networking preconfigured
✔ Application services partially ready
Warm DR Architecture
Primary Region
│
├── Fully Active Environment
│
Replication
│
▼
DR Region
│
├── Standby Database
├── Preconfigured Networking
├── Minimal Compute
└── Recovery Automation

Warm DR Workflow

During disaster:

DR database promoted
Additional compute started
Application services activated
Load balancer updated
Traffic redirected

Hot Disaster Recovery (Hot DR)

What is Hot DR?

Hot DR is the most advanced disaster recovery model.

Simple explanation:

A fully active standby environment continuously runs in the DR region.

Both regions remain operational simultaneously.

The DR region is always ready for immediate failover.

Hot DR Architecture
Primary Region
│
├── Active Production Stack
│
Real-Time Replication
│
▼
DR Region
│
├── Fully Active Standby Stack
├── Running Applications
├── Active Networking
└── Immediate Traffic Readiness

**Hot DR Workflow

During disaster:**

Primary outage detected
Traffic immediately redirected
DR environment already operational
Minimal recovery delay

During disaster:

Primary region unavailable
→ FSDR executes recovery orchestration
→ DR database activated
→ application services recovered
→ traffic redirected
→ banking services restored

Common Disaster Recovery Failures

Many DR failures occur during orchestration and validation rather than infrastructure provisioning.

Common issues include:

✔ Missing dependency mapping
✔ DNS still pointing to failed region
✔ Replication lag ignored
✔ Application validation skipped
✔ Untested DR workflows
✔ Incorrect startup sequencing

Critical Operational Insight
Most DR failures occur during orchestration and validation, not infrastructure provisioning.
Why OCI FSDR Matters

Cloud resiliency is no longer only an infrastructure recovery problem.

Modern disaster recovery is an application orchestration challenge.

OCI FSDR helps organizations move from:

Manual recovery
→
Automated resiliency engineering

through coordinated recovery workflows across regions.

Production Best Practices
✔ Perform regular DR drills
✔ Validate application dependencies
✔ Continuously monitor replication
✔ Test traffic failover procedures
✔ Maintain updated recovery documentation
✔ Validate application health after recovery
✔ Separate production and DR environments

Oracle FSDR official Doc :

Conclusion

OCI Full Stack Disaster Recovery enables organizations to orchestrate application-aware disaster recovery workflows across OCI regions.

By coordinating dependency sequencing, traffic routing, recovery validation, and service orchestration, FSDR helps reduce downtime and operational complexity during disaster events.

Modern disaster recovery is no longer just about recovering infrastructure — it is about restoring complete business continuity through intelligent orchestration and resiliency engineering.

OCI Run Command Advanced Guide: Remote Execution, Object Storage Scripts, and Production Troubleshooting

Bonthu Durga Prasad — Thu, 23 Apr 2026 08:53:24 +0000

Introduction

Managing remote servers usually means logging in through SSH (Linux) or RDP (Windows). While that works, it also means managing ports, credentials, and access controls.

Oracle Cloud Infrastructure (OCI) offers a cleaner option called Run Command.

OCI Run Command allows you to remotely execute commands or scripts on OCI Compute instances directly from the OCI Console, OCI CLI, or API — without logging in to the server manually.

This blog explains what OCI Run Command is, how it works, what is required, common statuses, troubleshooting, and best practices.

What is OCI Run Command?

OCI Run Command is a feature that lets you run commands remotely on an OCI Compute instance using the Oracle Cloud Agent installed on that server.

Examples:

hostname
whoami
systemctl restart nginx
df -h

Instead of connecting to the server manually, OCI sends the command securely through the cloud control plane.

Why Use Run Command?

OCI Run Command is useful when you want to:

Run quick administrative commands
Restart services
Collect logs
Check disk space / memory
Update configuration
Run scripts remotely
Troubleshoot servers without SSH/RDP access

Architecture Overview

Administrator
│
▼
OCI Console / OCI CLI
│
▼
Run Command Service
│
▼
OCI Instance Agent
│
▼
Compute Instance
│
┌───┴──────────────┐
▼ ▼
Object Storage Log Files
(Scripts) (Output)

Inline Commands vs Large Scripts

Use Inline Commands For:
hostname
uptime
df -h
systemctl status httpd
Use Object Storage Scripts For:
Application deployment
Package installation
Multi-step patching
Configuration enforcement
Long shell logic

Main Components Required

1. OCI Compute Instance

Target server where command will run.

2. Oracle Cloud Agent

Installed on OCI instance. This agent communicates with OCI services.

3. Run Command Plugin

Must be enabled inside Oracle Cloud Agent settings.

4. IAM Policies

Permissions are needed for:

User who creates command
Instance that consumes command
5. Dynamic Group

Used to grant permissions to the OCI instance itself.

Step 1: Enable Run Command Plugin

Go to:

OCI Console → Compute Instance → Oracle Cloud Agent

Enable:

Step 2: Create Dynamic Group

Example rule:

ALL {instance.compartment.id = ''}

This means all servers in that compartment join the Dynamic Group.

Step 3: Dynamic Group Policies

Example:

Allow dynamic-group DeployDG to use instance-agent-command-execution-family in compartment id

Allow dynamic-group DeployDG to read instances in compartment id

Allow dynamic-group DeployDG to read buckets in compartment id

Allow dynamic-group DeployDG to read objects in compartment id where target.bucket.name=''

Allow dynamic-group DeployDG to manage objects in compartment id where target.bucket.name=''

This allows the server to receive and execute commands.

Step 4: User IAM Policies

Example:

Allow group Admins to manage instance-agent-command-family in compartment id

Allow group Admins to read instance-agent-command-execution-family in compartment id

Allow group Admins to inspect instances in compartment id

What is ocarun in OCI Run Command?

ocarun is the local execution user/context used by OCI Run Command plugin on the compute instance.

When you send a command through Oracle Cloud Infrastructure Run Command, the instance agent receives it and executes it using the Run Command plugin. On many OCI images/platform setups, that execution is associated with ocarun.

-> If you run commands that required sudo privilages then you should provide ocarun user to the admin privilage.

Example Run Command (OCI CLI)

oci instance-agent command create \
--compartment-id \
--target '{"instanceId":""}' \
--content '{
"source":{
"sourceType":"TEXT",
"text":"hostname"
}
}' \
--timeout-in-seconds 600 \
--display-name test-hostname

Common Status Values Explained

lifecycle-state

Shows execution status.

ACCEPTED
Command created and queued.
IN_PROGRESS
Command is currently running.
SUCCEEDED
Command completed successfully.
FAILED
Command ran but failed.
CANCELED
Execution canceled.

To check the delivery status

oci instance-agent command-execution list --compartment-id ocid1.compartment.oc1..aaaaaaaagz4mern4sk46kbebwqzl6czdowlud7rop7ornezr7axx6ja5jfla --instance-id ocid1.instance.oc1.ap-mumbai-1.anrg6ljr7gqo7aacuco546smbzylzekybcfbvp2vz2ygvwgu52vf62zk7cma --all

delivery-state

Shows whether command reached the server.

ACKED
Server received the command.
EXPIRED
Command was never picked up before timeout window expired.

Usually caused by:

Wrong Dynamic Group
Agent issue
Network issue
Permissions issue

-> If you get delivery status ACKED and exit code =0 then your command / script successfully executed over the remote server.

How to Troubleshoot

Check Agent Status

Linux:

systemctl status oracle-cloud-agent
Restart Agent
systemctl restart oracle-cloud-agent
View Logs
tail -100 /var/log/oracle-cloud-agent/agent.log

Upload Detailed Logs to Object Storage

For long executions, store logs locally:

/tmp/deploy_httpd.log

Then upload logs back to bucket using automation.

This enables:

✔ Retention
✔ Audit trail
✔ Team review
✔ Full debugging

Security Best Practices

✔ Use least privilege IAM policies
✔ Restrict bucket access
✔ Sign scripts / validate source
✔ Avoid plaintext secrets in scripts
✔ Rotate credentials

Run Command vs SSH

Feature	SSH	OCI Run Command
Needs inbound port	Yes	No
Manual session	Yes	No
API driven	Limited	Yes
Auditable	Moderate	Strong
Scalable fleet ops	Medium	Strong

Final Thoughts

OCI Run Command is a powerful feature for remote server administration. Once properly configured, it becomes one of the easiest and safest ways to execute commands on OCI instances without direct login access.

If you manage OCI servers regularly, it is worth enabling and learning.

OCI Monitoring & Alarms: Practical Guide with Real-Time Testing, Architecture, and Troubleshooting

Bonthu Durga Prasad — Tue, 07 Apr 2026 11:17:22 +0000

Introduction

Modern cloud environments require proactive monitoring to detect issues before they impact users.

In production environments, lack of proper monitoring leads to delayed incident response and downtime. OCI Monitoring solves this by providing real-time observability and alerting

Oracle Cloud Infrastructure Monitoring enables you to:

Collect real-time metrics
Define intelligent alarms
Trigger automated notifications

In this guide, we will:

Understand OCI Monitoring architecture
Configure alarms using Console
Validate alerts using real testing
Apply across multiple OCI services

Architecture Overview

Flow Explanation:

OCI Services emit metrics: Compute Load Balancer Autonomous DB
Metrics are collected by 👉 OCI Monitoring
Alarms evaluate conditions Notifications sent via 👉 OCI Notifications Understanding Metrics in OCI

Metrics are:

Time-series data
Automatically generated by OCI services

Examples:

CPU Utilization (Compute)
HTTP Errors (Load Balancer)
Storage Usage (DB)

**Understanding Alarms

Alarms:**

Continuously evaluate metrics
Trigger when thresholds are breached

Example:

CPU > 80%
Error rate > 5%

Step-by-Step: Creating Alarm (Console)

👉

Observability & Management → Monitoring → Alarms → Create Alarm

Key Configuration:

Metric Namespace (Oracle_Compute_Agent)
Interval (1m / 5m)
Threshold condition
Severity

Understanding Metric Namespaces in OCI

OCI metrics are organized into namespaces based on the source of data:

oci_compute → Provides default infrastructure-level metrics such as CPU utilization, network throughput, and disk I/O. These are available without any additional configuration.
oci_computeagent → Provides enhanced, guest OS-level metrics such as memory usage, filesystem utilization, and detailed performance insights. These require the Oracle Cloud Agent plugin to be enabled on the instance.

Notifications Setup

Using
👉 OCI Notifications

Steps:

Create Topic
Add Subscription (Email / HTTPS)
Confirm subscription

-> Define alarm notification with topic you have created so that the triggered alarms will notify you with that email.

-> You have created an alarm with the topic where you get notified when define threshold reaches.

Practical Validation

👉 This is where your test compute instance comes in (for screenshots)

Even though OCI Monitoring is service-agnostic, we validate using a compute instance.

Triggering a Real Alert

SSH into instance:

sudo yum install stress -y
stress --cpu 2 --timeout 120

Expected Outcome:
CPU spike
Alarm moves to FIRING state
Notification received

Metrics graph spike
Alarm state

Multi-Service Use Cases

This same setup works for:

🖥️ Compute
CPU, Memory
🌐 Load Balancer
HTTP 5xx errors
Latency
🗄️ Databases
Storage thresholds
Active sessions

👉 One monitoring system → multiple services

Troubleshooting

❌ Alarm not triggering
Wrong metric namespace
Incorrect interval
❌ No notifications
Subscription not confirmed
Topic mismatch
❌ Metrics missing
Service delay
Agent/plugin disabled (for compute)

⚡ Best Practices

Use different severities
Avoid alert noise (don’t set too low thresholds)
Always validate alarms manually

Validation Checklist

Metrics visible ✅
Alarm configured ✅
Notification received ✅
Real test performed ✅

🏁 Conclusion

OCI Monitoring and Alarms provide a powerful and unified observability solution across all OCI services. By combining real-time metrics, flexible alarm configurations, and integrated notifications, teams can proactively detect and respond to issues before they impact users.

This guide demonstrated not just configuration, but real-time validation using practical testing — a critical step for production readiness.

With these practices, organizations can significantly improve system reliability, reduce downtime, and enhance operational visibility across cloud environments.

OCI SMTP Email Delivery with Postfix on Linux: Secure Configuration, Testing, and Troubleshooting (Advanced Guide)

Bonthu Durga Prasad — Mon, 06 Apr 2026 10:20:16 +0000

Introduction

Email delivery is a critical component in cloud environments for alerts, notifications, and application workflows. In Oracle Cloud Infrastructure, the Email Delivery service provides a reliable SMTP-based solution.

This guide demonstrates how to configure a Linux server to send emails using OCI SMTP with a secure and production-ready setup

Architecture

Linux Server
↓
Postfix (SMTP client)
↓
OCI Email Delivery (SMTP)
↓
Recipient Email

Prerequisites

*OCI Setup
*
Go to:

👉 OCI Console → Email Delivery

*✔ Create Approved Sender
*

Generate SMTP Credentials

Copy:

SMTP Username
SMTP Password

Network Requirements

From Server:

Allow outbound port 587 or 25 (recommended)

Test connectivity:

telnet smtp.email.ap-mumbai-1.oci.oraclecloud.com 587

Install Required Packages

yum install postfix s-nail cyrus-sasl-plain -y

Verify mail command

which mail

Expected: /usr/bin/mail

Configure Postfix

Edit config file
vi /etc/postfix/main.cf

Add configuration

OCI SMTP relay (use port 587 )

relayhost = [smtp.email.ap-mumbai-1.oci.oraclecloud.com]:587

SMTP Authentication

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

TLS Configuration

smtp_use_tls = yes
smtp_tls_security_level = encrypt

Optional (avoid size issues)

mailbox_size_limit = 0
message_size_limit = 52428800

Configure SMTP Credentials

vi /etc/postfix/sasl_passwd

Add EXACT line
[smtp.email.ap-mumbai-1.oci.oraclecloud.com]:587 SMTP_USERNAME:SMTP_PASSWORD

🔴 Important rules

✔ Single line only
✔ Include [ ]
✔ Include :587
✔ No extra spaces

Secure and Apply Credentials

chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd

Verify mapping

postmap -q "[smtp.email.ap-mumbai-1.oci.oraclecloud.com]:587" hash:/etc/postfix/sasl_passwd

Expected : SMTP_USERNAME:SMTP_PASSWORD

Configure Approved Sender Mapping

Force all emails to use approved sender :

postconf -e "sender_canonical_maps = alerts@gmail.com"

Why this is required

OCI accepts only approved sender.

So:

root@hostname → alerts@gmail.com

Start and Enable Postfix

systemctl enable postfix
systemctl restart postfix

Test Email

echo "OCI SMTP TEST FROM AWS" | mail -s "TEST MAIL" your_email@example.com

Verify Logs

tail -f /var/log/maillog

expected output : status = 200(ok)

Automation Example

Simple test
echo "Alert test" | mail -s "Test Alert" your_email@example.com

Troubleshooting

Issue 1: Connection Timeout

Cause:

Port 25 blocked (OCI default)

Fix:

Use port 587 or 465
Issue 2: Authentication Failed

Cause:

Wrong SMTP credentials

Fix:

Verify username/password

Debug Logs (ADVANCED)

Check logs:

sudo tail -f /var/log/maillog

Example:

status=sent
status=bounced
authentication failed

Security Best Practices

✔ Use TLS encryption

✔ Restrict access to credential file

✔ Rotate SMTP credentials

✔ Avoid hardcoding credentials

Real Use Case
Use OCI SMTP to send:
✔ Monitoring alerts

✔ Application notifications

✔ we can setup password expiry notification for users in linux

Conclusion

OCI Email Delivery offers a secure and scalable way to send emails using authenticated SMTP with TLS. Combined with Postfix, a reliable and lightweight MTA, it becomes a simple yet powerful production-ready solution.

This setup also highlights cross-cloud flexibility—applications running on AWS can seamlessly use OCI for email delivery, enabling a cost-effective and hybrid architecture.

Overall, Postfix with OCI SMTP is a practical, secure, and efficient approach for real-world email delivery needs.

OCI CLI Configuration and Advanced Usage: Automating Tenancy Insights from Command Line

Bonthu Durga Prasad — Fri, 03 Apr 2026 10:04:54 +0000

Introduction

In cloud environments, automation and scripting are essential for efficient resource management. While the OCI Console provides a graphical interface, the OCI CLI enables engineers to interact with resources programmatically.

This guide demonstrates how to configure OCI CLI and extract tenancy-level data using real commands

Why OCI CLI

✔ Automation (scripts, pipelines)
✔ Bulk operations
✔ Faster troubleshooting
✔ Integration with DevOps workflows

Architecture

Local Machine
│
▼
OCI CLI
│
▼
API Request (Signed with Key)
│
▼
OCI Services (IAM, Compute, etc.)

Step 1: Install OCI CLI

bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

oci --version

Step 2: Generate API Keys

-> Create a directory .oci

mkidr .oci

-> Create a configuration file for the oci cli

mkdir config

-> Add the config details like below

[DEFAULT]
user=ocid1.user.oc1..aaaaaaaapjmafzjfgvdf7rohfvuwlwj6otxwxfqtazd6vvcwe24pfailx4cq
fingerprint=5e:b0:45:e2:07:3f:b8:fa:51:25:ee:4b:7b:d5:d6:e9
tenancy=ocid1.tenancy.oc1..aaaaaaaaf2yv5cljkqlepfllkxolhgvmq5tq7vgfu6tns3ajhnuqn4eikmja
region=ap-mumbai-1
key_file= # TODO

-> Create one file and add your private key details and change the permissions to read and write only.

chmod 600 ~/.oci/oci_api_key.pem

-> Now check with below command for the configuration setup

oci os ns get

Validate Configuration

oci iam region list

oci iam compartment list --compartment-id

You will get the list of compartments over the entire tenancy level

Get Instances

oci compute instance list --compartment-id

Real Use Case

oci iam user list --compartment-id \
--query "data[].{Name:name,ID:id}" --output table

You will get the user details in a table format

Best Practices

✔ Secure private keys

✔ Use profiles

✔ Avoid hardcoding OCIDs

✔ Use scripts for automation

✔ Rotate keys regularly

Conclusion

OCI CLI enables engineers to automate cloud operations and retrieve critical data efficiently. By combining CLI commands with scripting, organizations can improve operational efficiency and reduce manual effort.

OCI Bastion Service: Complete End-to-End Guide for Secure Access to Private Instances

Bonthu Durga Prasad — Fri, 27 Mar 2026 08:50:05 +0000

Introduction

Accessing private compute instances securely is a common challenge in cloud environments. Exposing SSH ports publicly increases the attack surface and violates security best practices.

In Oracle Cloud Infrastructure, Bastion Service provides a secure way to connect to private instances without assigning public IP addresses.

This guide provides a complete end-to-end implementation of OCI Bastion Service.

Architecture Overview

Your Laptop
│
▼
OCI Bastion Service
│
▼
Private Subnet
│
▼
Compute Instance (No Public IP)

Prerequisites

OCI account
VCN with:
- Public subnet
- Private subnet
Compute instance in private subnet
SSH key pair

Step 1: Create VCN (Quick Setup)

Go to Networking → VCN
Create VCN with:
CIDR: 10.0.0.0/16
Public subnet : 10.0.64.0/24
Private subnet : 10.0.128.0/17

Step 2: Create Private Compute Instance

Go to Compute → Instances
Launch instance
Instance_Name : Demo_Bastion_service
Private subnet
No public IP

You can get an instance with private IP

Step 3: Create Bastion

Navigate → Identity & Security → Bastion
Click Create Bastion

Configuration

Name: my-bastion
VCN: Demo_VCN
Subnet: public subnet
CIDR: 0.0.0.0/0 (for testing)

Step 4: Create Bastion Session

Click Bastion → Create Session

Select:
Session type: SSH_Port_Forwarding
Target instance: your private instance
Upload public key

Step 5: Connect to Instance

OCI gives command like: Copy the SSH command

ssh -i -N -L :10.0.171.0:22 -p 22 ocid1.bastionsession.oc1.ap-mumbai-1.amaaaaaa7gqo7aaalvsyyzpplvcrg5ixiyevbeuwfl2xycuchc3j5k6ughga@host.bastion.ap-mumbai-1.oci.oraclecloud.com

Change the permission of the .pem file in your computer location specific user who want to access.

-> Go to the file properties and go to the security and change the permissions over there.

Add your file location over there and local port change it to 22.

FYR

ssh -i C:\Test.key -N -L 22:10.0.171.0:22 -p 22 ocid1.bastionsession.oc1.ap-mumbai-1.amaaaaaa7gqo7aaalvsyyzpplvcrg5ixiyevbeuwfl2xycuchc3j5k6ughga@host.bastion.ap-mumbai-1.oci.oraclecloud.com

Tunneling will be established between your computer and the private server.

Open putty Go to auth and Go for tunneling and add the details as below.

-> Now the tunneling will be created between your system and the private server.

-> You can able to connect the private server without public IP with the bastion service.

Verify Connection

-> You can verify the connection by using below command.

whoami
hostname -i

Security Best Practices

Do NOT allow 0.0.0.0/0 in production
Use restricted CIDR
Use short session duration
Use IAM policies

Conclusion

OCI Bastion Service enables secure and controlled access to private instances without exposing them to the internet. By using Bastion, organizations can implement a secure access architecture aligned with best practices.

Infrastructure as Code in OCI using Resource Manager (Terraform)

Bonthu Durga Prasad — Mon, 23 Mar 2026 09:23:46 +0000

Introduction

Infrastructure management in cloud environments has evolved significantly with the adoption of automation and DevOps practices. Manual provisioning is error-prone and difficult to scale.

In Oracle Cloud Infrastructure, Infrastructure as Code (IaC) is implemented using OCI Resource Manager, a managed Terraform-based service that enables automated, consistent, and repeatable deployments.

This article provides a deep dive into OCI Resource Manager, including architecture, execution flow, state management, drift detection, hands-on examples, and real-world DevOps practices.

What is Infrastructure as Code (IaC)

Infrastructure as Code (IaC) is the practice of defining and managing infrastructure using code.

Benefits

Automation
Consistency
Version control
Faster deployments

What is OCI Resource Manager

OCI Resource Manager is a managed service that uses Terraform to provision and manage cloud resources.

Key Features

Managed Terraform execution
No need for local setup
Secure state management
Easy rollback and updates

Architecture Overview

Developer
│
▼
Terraform Code (HCL)
│
▼
OCI Resource Manager
│
▼
OCI APIs
│
▼
Cloud Resources (VCN, Compute, Storage)

How Resource Manager Executes Terraform

Execution Flow

User submits job
│
▼
Configuration validated
│
▼
Terraform plan generated
│
▼
Terraform apply executed
│
▼
State file updated

Explanation

OCI Resource Manager internally performs Terraform operations such as plan and apply. It manages execution lifecycle and state securely without requiring local tools.

Key Components

Stack

A stack is a collection of Terraform configurations.

Job

Jobs execute operations such as:

Plan
Apply
Destroy

State

Tracks current infrastructure and dependencies.

Hands-on Example

Step 1: Terraform Configuration

resource "oci_core_vcn" "my_vcn" {
cidr_block = "10.0.0.0/16"
display_name = "my-vcn"
}

Step 2: Create Stack

Go to Resource Manager

Upload configuration
Create stack

Step 3: Run Apply Job

Click Apply
OCI provisions resources

CLI Commands

oci resource-manager stack list
oci resource-manager job list
oci resource-manager job get --job-id

Authentication and IAM Integration

OCI Resource Manager integrates with IAM for secure access.

Authentication is handled using IAM policies and instance principals.

ex : Allow group DevOps to manage all-resources in compartment Dev

Terraform State Management

Terraform state is automatically managed by OCI Resource Manager.

State includes:

Resource mappings
Infrastructure state
Dependency tracking

Why important:

Ensures Terraform knows existing resources and prevents duplication.

Drift Detection

Drift occurs when infrastructure is modified outside Terraform.

Ex : Manual change → Drift detected → Terraform shows mismatch

Resource Manager detects drift by comparing:

Current infrastructure
Stored state

Plan vs Apply

Plan → Shows changes

Apply → Executes changes

Example :

Plan: Create VCN
Apply: Resource created

Best Practices

Use version control (Git)
Separate dev and prod environments
Use variables instead of hardcoding
Always review Terraform plan
Store sensitive data securely

Conclusion

OCI Resource Manager simplifies infrastructure provisioning by enabling Infrastructure as Code using Terraform. It ensures consistency, scalability, and automation in cloud deployments.

Understanding execution flow, state management, and drift detection is essential for building reliable and production-ready cloud environments.

OCI Block Volume Deep Dive

Bonthu Durga Prasad — Thu, 19 Mar 2026 11:09:38 +0000

In modern cloud environments, storage plays a critical role in application performance and reliability. In Oracle Cloud Infrastructure (OCI), Block Volume provides scalable, high-performance storage that can be attached to compute instances.

This article provides a deep dive into OCI Block Volume, covering architecture, performance concepts such as VPUs and autotuning, attachment methods including iSCSI and paravirtualized, hands-on commands, monitoring, and real-world troubleshooting scenarios.

What is OCI Block Volume

OCI Block Volume is a network-based storage service that provides persistent storage for compute instances.

It is commonly used for:

Databases
Application storage
Boot volumes
High-performance workloads

Architecture Overview

Architecture Diagram

Compute Instance
│
▼
Attachment Layer (iSCSI / Paravirtualized)
│
▼
OCI Block Volume Service
│
▼
Distributed Storage Backend

OCI Block Volume is decoupled from compute, meaning storage persists even if the instance is terminated. Data is replicated across multiple storage servers to ensure high availability and durability.

Types of Volumes

OCI provides different types of volumes:

Boot Volume → Used for operating system
Block Volume → Used for application data
Volume Backups → Used for snapshots and recovery

Performance

Performance in OCI Block Volume is defined using VPUs (Volume Performance Units per GB).

Higher VPUs provide higher IOPS and throughput.

10 VPUs → Low cost workloads

20 VPUs → Balanced workloads

30+ VPUs → High-performance workloads

Autotuning (Dynamic Scaling)

Autotuning allows OCI to automatically adjust volume performance based on workload demand.

Workload increase → Performance increases

Workload decrease → Cost optimized

Attachment Types

iSCSI Attachment
Uses TCP/IP-based storage communication and requires manual setup.
Paravirtualized Attachment

Uses OCI optimized drivers and provides better performance with simpler setup.

When to Use What

Use Paravirtualized when:

Simplicity is required
Standard workloads

Use iSCSI when:

Maximum performance is required
Fine-grained control is needed

Best Practices

Use paravirtualized attachments when possible
Enable autotuning
Separate volumes for OS, logs, and database
Monitor performance regularly
Choose correct VPU levels

Conclusion

OCI Block Volume provides flexible and scalable storage for cloud workloads. By understanding architecture, performance tuning, and attachment methods, engineers can design efficient and reliable storage systems in OCI.

Proper monitoring and tuning help avoid performance bottlenecks and ensure optimal system behavior.

High Performance Computing Storage in OCI using Lustre File System

Bonthu Durga Prasad — Wed, 18 Mar 2026 10:22:34 +0000

High Performance Computing Storage in OCI using Lustre File System

As cloud workloads evolve, especially in areas like high-performance computing (HPC), machine learning, and big data analytics, traditional storage systems often become a bottleneck. These workloads require high throughput, low latency, and parallel file access.

In Oracle Cloud Infrastructure, high-performance storage requirements can be addressed using the Lustre File System, a distributed file system designed for large-scale workloads.

This article explores how Lustre works and how it can be used in OCI environments.

What is Lustre File System?

Lustre is a parallel distributed file system designed for environments that require high-speed access to large datasets.

It is commonly used in:

High Performance Computing (HPC)
Artificial Intelligence and Machine Learning
Scientific simulations
Big data processing

Unlike traditional file systems, Lustre distributes data across multiple storage nodes to achieve high performance.

Why Use Lustre in OCI?

Cloud-based HPC workloads demand:

High throughput
Scalable storage
Parallel access from multiple compute nodes

Lustre provides:

Parallel read/write operations
Horizontal scalability
High bandwidth performance

This makes it ideal for workloads where multiple compute instances process large datasets simultaneously.

Lustre Architecture Overview

Lustre is built using multiple components working together.

Key Components

Metadata Server (MDS) → Stores file metadata
Object Storage Servers (OSS) → Store actual data
Clients → Compute instances accessing the file system

Architecture Flow

Compute Nodes (Clients)
│
▼
Metadata Server (MDS)
│
▼
Object Storage Servers (OSS)
│
▼
Distributed Storage

In this architecture:

Clients request metadata from MDS
Data is read/written from OSS nodes
Operations happen in parallel for high performance

How Lustre Works

When a client accesses a file:

Metadata request is sent to MDS
MDS provides file location information
Client directly accesses data from OSS nodes
Data transfer happens in parallel

This parallel architecture significantly improves performance.

Real-World Use Cases

Lustre is widely used in scenarios such as:

Machine Learning Training

Training large models requires fast access to massive datasets.

2.Scientific Research

Simulations generate huge amounts of data that must be processed quickly.

3.Media Rendering

Video processing and rendering workflows benefit from high throughput.

Benefits of Lustre in OCI

High throughput storage
Scalable architecture
Parallel data access
Optimized for HPC workloads

Best Practices

When using Lustre in OCI:

Use multiple compute nodes for parallel processing
Design workloads for distributed execution
Monitor performance and I/O usage
Use high-performance networking for better throughput

Lustre File System Limits

Lustre limits are per availability domain:
Resource Limit
Max file systems 8 per tenant per availability domain
Max capacity per FS 200 TB
Aggregate throughput 200 Gbps per tenancy per availability domain

The Lustre client is mandatory for any VM or compute instance that wants to access a Lustre file system.
Lustre client works only with Red Hat Compatible Kernel (RHCK) on Oracle Linu

Syncing Lustre with Object Storage

OCI Lustre can sync data with Object Storage for cost-effective long-term storage:

Import
• Pull objects from Object Storage → Lustre
• Use case: AI training, data processing
- Export • Push files from Lustre → Object Storage Use case: Save processed results

OCI Lustre file systems require a Lustre client kernel module.
However:

Oracle Linux normally uses UEK kernel, not compatible with Lustre
So you must switch to RHCK kernel (Red Hat Compatible Kernel)
Then you must build the Lustre client from source code unless a prebuilt package exists

Understanding Identity and Access Management (IAM) Architecture in Oracle Cloud Infrastructure

Bonthu Durga Prasad — Sat, 14 Mar 2026 12:17:12 +0000

Understanding Identity and Access Management (IAM) Architecture in Oracle Cloud Infrastructure

Security is one of the most critical aspects when designing cloud infrastructure. In Oracle Cloud Infrastructure, Identity and Access Management (IAM) provides a centralized framework to control access to resources and services.

IAM allows administrators to define who can access cloud resources and what actions they are allowed to perform, ensuring a secure and well-managed cloud environment.

In this article, we will explore the core IAM architecture and understand how its components work together.

Why IAM is Important

In a cloud environment, multiple users, applications, and services interact with infrastructure resources. Without proper access control, organizations risk exposing sensitive data or critical infrastructure.

OCI IAM helps organizations:

Implement secure access control
Enforce the principle of least privilege
Organize resources effectively
Manage identities and permissions centrally

Core Components of OCI IAM

OCI IAM is built using several key components.

Compartments

Compartments are logical containers used to organize and isolate OCI resources.

They allow administrators to structure cloud environments and apply access control boundaries.

Example compartment hierarchy:

Root Tenancy
│
├── Development
│ ├── Compute
│ └── Storage
│
└── Production
├── Application Servers
└── Databases

This structure helps maintain clear separation between environments.

Users and Groups

Users represent identities that can access the OCI Console or APIs.

Groups are collections of users with similar responsibilities.

Instead of assigning permissions to individual users, administrators assign policies to groups.

Example:
Group: DevOps
Users:

Alice
Bob

This simplifies permission management across teams.

IAM Policies

Policies define what actions users or groups are allowed to perform on OCI resources.

Example policy:

Allow group DevOps to manage instance-family in compartment Production

Policies usually define:

Subject (group or dynamic group)
Action (inspect, read, use, manage)
Resource type
Compartment scope

Policies form the core of OCI authorization.

Dynamic Groups and Instance Principals

Modern cloud applications often run on compute instances and need access to OCI services.

Instead of storing API credentials on servers, OCI provides Instance Principals.

Instance principals allow compute instances to authenticate with OCI services using instance identity.

Example access flow:

Compute Instance
│
▼
Instance Principal
│
▼
Dynamic Group
│
▼
IAM Policy
│
▼
OCI Service Access

Dynamic groups automatically include instances based on matching rules.

Example dynamic group rule:

ALL {instance.compartment.id = ''}

Example policy:

Allow dynamic-group app-instances to read buckets in compartment Storage

This architecture eliminates the need to store credentials on servers.

*Real-World Example
*
Imagine an application running on an OCI compute instance that needs to upload files to Object Storage.

Instead of storing API keys on the instance:
The instance is added to a dynamic group
A policy grants access to Object Storage
The application authenticates using instance principals

This enables secure and automated access to OCI services.

Best Practices for OCI IAM

When designing IAM architecture in OCI, follow these best practices:

Use groups for permission management
Follow the principle of least privilege
Organize resources using compartments
Avoid storing API keys on compute instances
Use instance principals whenever possible

*Conclusion
*
Identity and Access Management is a foundational security service in Oracle Cloud Infrastructure. By combining compartments, users, groups, policies, and dynamic groups, organizations can build a secure access control framework for their cloud environments.

Understanding IAM architecture is essential for designing secure and scalable OCI workloads.

GitHub Repository

You can explore the complete IAM implementation and architecture documentation here:

Durgaprasad9346 / oci-iam-access-control-guide

OCI IAM deep dive covering users, groups, policies, dynamic groups, instance principals and advanced access patterns in Oracle Cloud Infrastructure.

oci-iam-access-control-guide

OCI IAM deep dive covering users, groups, policies, dynamic groups, instance principals and advanced access patterns in Oracle Cloud Infrastructure.

Overview

Identity and Access Management (IAM) is the security foundation of Oracle Cloud Infrastructure (OCI). It controls authentication and authorization for users, services, and applications interacting with cloud resources.

OCI IAM allows administrators to define who can access resources and what actions they can perform through policies, groups, and dynamic access mechanisms.

This repository provides an in-depth explanation of OCI IAM components and advanced access patterns used in enterprise cloud environments.

Core IAM Components

OCI IAM consists of several key components:

Compartments
Users
Groups
Policies
Dynamic Groups
Instance Principals
Resource Principals

These components work together to implement secure access control across OCI services.

IAM Access Flow

Typical access flow:

User │ ▼ OCI IAM │ ▼ Group Membership │ ▼ Policy Evaluation │ ▼ Access to OCI Resource

Repository

…

View on GitHub