Oracle APPS DBA pieces

Wednesday, February 4, 2026

OCI Load Balancer Health Check Failing Despite Correct Security Rules? Here’s How to Fix It

If you’re managing Oracle Cloud Infrastructure (OCI), you might have encountered a frustrating issue: your OCI Load Balancer backend health check fails even though your security lists, route tables, and firewall settings are correct.

In this blog, we’ll break down why this happens and provide a step-by-step solution.

Understanding the OCI Load Balancer Health Check

OCI Load Balancers periodically check the health of backend servers by sending requests to a specific port and protocol (TCP or HTTP). If the response is not as expected, the backend is marked unhealthy, and traffic is not routed to it.

Common symptoms of failing health checks:

Status: Connection failed
Status: Status code mismatch
Backend remains Critical in the OCI console

Even if all your network rules are correct, the LB may still mark the backend as unhealthy due to application-level issues.

Case Study: Health Check Failing Despite Correct Security Settings

Here’s an example scenario:

Backend VM private IP: **.**.**.**
OCI Load Balancer health check node IP: **.**.**.**
Security lists and NSGs are correctly configured to allow traffic from the LB subnet
Firewall on the VM is disabled

Yet, the LB health check reports:


Critical – Connection failed

Step 1: Check if the backend application is listening

Run:


ss -lntp | grep :80

If nothing is listening on the configured port, the health check will fail
In our case, starting Apache (httpd) fixed the “Connection failed” issue:


sudo systemctl start httpd
sudo systemctl enable httpd

Step 2: Check the HTTP response code

After starting the web server, the health check may still fail with:


Status code mismatch

Run a test from the backend VM:


curl -i http://10.24.139.43/

In our example, the response was:


HTTP/1.1 403 Forbidden

OCI expects HTTP 200 OK by default. A 403 indicates Apache cannot serve the requested page, even if the server is running.

Step 3: Fix Apache configuration and permissions

Ensure Apache allows access to the DocumentRoot:


<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Create a simple index file to return HTTP 200:


sudo bash -c 'echo "<html><body><h1>OK</h1></body></html>" > /var/www/html/index.html'
sudo chmod 644 /var/www/html/index.html
sudo chown apache:apache /var/www/html/index.html
sudo systemctl restart httpd

Test again:


curl -i http://10.24.139.43/

Output should be:


HTTP/1.1 200 OK
<html><body><h1>OK</h1></body></html>

Step 4: Verify LB health check

OCI Load Balancer will now mark the backend Healthy within 30–60 seconds
Traffic through the LB will work correctly for end users

Key Takeaways

Security rules alone do not guarantee a healthy backend. Always check the application layer.
403 Forbidden or 404 Not Found responses will cause health check failures.
Ensure the backend serves HTTP 200 OK on the health check path.
Always test using curl or nc to simulate LB requests.

Conclusion

If your OCI Load Balancer health check is failing despite correct network settings, don’t panic. Most likely, the issue is at the application level — either the server is not listening, or the HTTP response is not 200 OK.

By ensuring your backend web server is running, the correct permissions are set, and a valid index page is served, your LB will pass the health checks, and traffic will flow smoothly.

Friday, January 23, 2026

Step-by-Step Guide: OCI DevOps & Resource Manager Terraform Infrastructure Provisioning

Introduction

Infrastructure provisioning on Oracle Cloud Infrastructure (OCI) can be automated with Infrastructure as Code (IaC) using OCI DevOps, OCI Resource Manager, and Terraform — enabling CI/CD-driven deployments across environments.

In this blog, we’ll walk through a real-world, high level plan of provisioning OCI infrastructure using OCI DevOps build pipelines integrated with OCI Resource Manager (Plan & Apply).

High-Level Architecture

The overall workflow looks like this:

OCI DevOps Code Repository stores Terraform and pipeline artifacts
OCI DevOps Build Pipeline is triggered on code changes
Build Pipeline invokes OCI Resource Manager
Resource Manager runs Terraform Plan and Apply
Infrastructure is provisioned automatically

Step 1: Create OCI DevOps Code Repository

Start by creating a Code Repository inside your OCI DevOps Project. This repository will store:

build_spec.yaml
Terraform configuration files

Once created, clone the repository using Cloud Shell:

Authenticate using your OCI username and Auth Token.

Initially the repository will be blank and terraform codes will pushed to the repository using cloud shell.

Step 2: Create OCI DevOps Build Pipeline

Next, create a Build Pipeline in OCI DevOps. This pipeline will:

Read Terraform artifacts
Trigger OCI Resource Manager operations

You don’t need to configure all stages immediately; the pipeline will be connected later using triggers.

Step 3: Prepare Repository Structure

Organize your repository with a clean structure:

devops-repository/

├── build_spec.yaml

└── terraform/

└── resource_manager.tf

At present, the files are present locally in cloud shell but not on OCI Devops

Step 4: Upload Artifacts and Push to Repository

Add the Terraform and build specification files, then push them to the repository:

git add .

git commit -m "updated artifacts first time"--this will prompt for the username and password

git push -u origin main

Note:The build file has to be present in the root folder of the devops repository so that build pipeline can read it.

This ensures the build pipeline always pulls the latest Terraform configuration.

Step 5: Upload Terraform Artifacts to Object Storage

In this case, OCI Resource Manager requires Terraform configuration to be sourced from OCI Object Storage. You can also call resource manager directly from build pipeline.

Create an Object Storage bucket
Upload the Terraform artifacts (resource_manager.tf files)

Step 6: Create OCI Resource Manager Stack (CLI)

In this scenario, the stack cannot be created from the OCI Console. In such cases, use OCI CLI:

export compartment_id=<compartment_ocid>

export config_source_bucket_name=ORM_STACK

export config_source_namespace=<namespace>

export config_source_region=us-ashburn-1

export stack_display_name=ORM-STACK

export terraform_version=1.1.x

oci resource-manager stack create-from-object-storage \

--display-name $stack_display_name \

--compartment-id $compartment_id \

--config-source-bucket-name $config_source_bucket_name \

--config-source-namespace $config_source_namespace \

--config-source-region $config_source_region \

--terraform-version $terraform_version

Successful output returns the Stack OCID.

Step 7: Update `build_spec.yaml`

Update the build_spec.yaml file to reference the Resource Manager Stack OCID. This file defines:

Build stages
Resource Manager Plan
Resource Manager Apply

This allows OCI DevOps to orchestrate Terraform execution automatically.

Step 8: Create Build Pipeline Trigger

Create a trigger that connects:

Code Repository (main branch)
Build Pipeline

Now, every git push automatically triggers infrastructure provisioning

Step 9: Commit and Trigger the Pipeline

Make final updates and push changes:

git add .

git commit -m "updated resource manager stack"

git push

Under the resource manager, we can see that both apply and plan jobs were triggered.

Note: In this case, the state file is internally being managed by Resource manager.

Thus every commit code pushed to devops will trigger the resource manager stack to create resources in OCI.

Benefits of This Approach

Fully automated infrastructure provisioning
Terraform state managed securely by OCI
CI/CD driven infrastructure changes
Repeatable, auditable deployments
Reduced manual errors

Conclusion

By integrating OCI DevOps, OCI Resource Manager, and Terraform, you can achieve a powerful Infrastructure as Code (IaC) pipeline on Oracle Cloud. This setup is ideal for enterprises looking to standardize cloud provisioning with governance, automation, and scalability

Saturday, January 10, 2026

Using Oracle SQLcl MCP Server with Oracle 19c: A Step-by-Step Guide for NLP-Based Database Queries

Introduction

With the rapid evolution of AI, databases are no longer limited to traditional SQL-only interactions. Oracle has taken a major step forward by introducing MCP (Model Context Protocol) support in SQLcl, allowing AI tools like Claude Desktop to interact directly with Oracle databases using natural language.

In this blog, I’ll walk you through a hands-on, end-to-end setup of Oracle SQLcl MCP Server with an on-prem / OCI-hosted Oracle 19c database, and show how conversational AI can query enterprise databases securely.

This guide is ideal for Oracle DBAs, Cloud Architects, and AI-curious professionals who want to explore NLP-driven database access.

Image source:-https://blogs.oracle.com/database/introducing-mcp-server-for-oracle-database

Architecture Overview

AI Client (Claude Desktop)
⬇️ MCP Protocol
SQLcl MCP Server (Local Machine)
⬇️ JDBC
Oracle Database 19c (OCI / On-Prem)

The AI never connects to the database directly. SQLcl acts as a secure MCP bridge, translating natural language into database operations.

Prerequisites

Before starting, ensure you have:

Oracle Database 19c (On-Prem or OCI Compute VM)
Windows laptop or desktop
Internet access to download tools
Basic Oracle SQL knowledge

Step 1: Install JDK 17 (Required for SQLcl)

Oracle SQLcl requires Java 17.

Download JDK 17 for Windows from Oracle
Install using the .exe
Set JAVA_HOME and update PATH

Verify:

java -version

Step 2: Install Oracle SQLcl

Download SQLcl from Oracle
Unzip it to a directory (example):
C:\AI\sqlcli

SQLcl is portable—no installer required.

Step 3: Install Claude Desktop

Claude Desktop will act as the AI MCP client.

Download Claude Desktop
Install and launch once
Close it before MCP configuration

Step 4: Prepare Oracle Database 19c

Verify PDBs

show pdbs;

Ensure your PDB (e.g., ORCLPDB) is in READ WRITE mode.

Listener and Network Setup

Ensure port 1521 is open
Disable firewall (lab use only):

systemctl stop firewalld

systemctl disable firewalld

Confirm connectivity from Windows:

Test-NetConnection <DB_PUBLIC_IP> -Port 1521

Step 5: Create SQLcl Connection

Launch SQLcl:

sql /nolog

Create and save a connection:

conn -save oracle19c_mcptest -savepwd system/password@<IP>:1521/ORCLPDB

Validate:

CONNMGR test oracle19c_mcptest

Step 6: Start SQLcl MCP Server

sql -mcp -name oracle19c_mcptest

You should see:

MCP Server started successfully

This process must remain running.

Step 7: Configure Claude Desktop for MCP

Edit Claude configuration file:

{

"mcpServers": {

"oracle19c": {

"command": "C:/AI/sqlcli/sqlcl/sqlcl/bin/sql.exe",

"args": ["-mcp", "-name", "oracle19c_mcptest"]

}

Restart Claude Desktop and allow MCP access when prompted.

Step 8: Follow Least Privilege (Best Practice)

Instead of SYSTEM, create an application user:

CREATE USER app_user IDENTIFIED BY password;

GRANT CREATE SESSION, CREATE TABLE TO app_user;

Create sample data:

CREATE TABLE sales_orders (...);

INSERT INTO sales_orders VALUES (...);

COMMIT;

Create a separate SQLcl MCP connection for this user.

This ensures:

AI only sees approved schemas
SYS/SYSTEM access is avoided

Step 9: Test NLP Queries via Claude

Now the magic ✨

Ask Claude:

Claude:

Understands intent
Calls SQLcl MCP
Executes SQL
Returns results

No SQL typing required.

Security Considerations

✔ SQLcl connections are local-only ✔ Credentials stored in user profile ✔ Secure with OS file permissions ✔ Use separate DB users ✔ Optional: Oracle Wallet for credentials

AI never gets raw database access.

Why This Matters

This setup demonstrates:

Conversational AI for ad-hoc querying
AI + Oracle DB without exposing credentials
Perfect for DBAs, Support, and Architects

Final Thoughts

Oracle SQLcl MCP Server bridges the gap between enterprise databases and modern AI—securely, locally, and powerfully.

If you’re running Oracle 19c today, you can already start experimenting with conversational data access.

Sunday, October 12, 2025

Oracle E-Business Suite Hit by New High-Severity Vulnerability — CVE-2025-61884

Overview

Oracle has disclosed a new high-severity vulnerability (CVE-2025-61884) impacting Oracle E-Business Suite (EBS) versions 12.2.3 through 12.2.14, as outlined in My Oracle Support (MOS) Note 3107176.1.
This vulnerability follows closely on the heels of another critical issue — CVE-2025-61882, announced on October 4, 2025, which has already been observed in active exploitation campaigns.

Both vulnerabilities underscore the growing importance of timely patching, network hardening, and proactive monitoring for organizations running Oracle EBS on-premises or in the cloud.

⚠️ CVE-2025-61884 — What We Know So Far

Component Affected: Oracle Configurator (Runtime UI)
Affected Versions: EBS 12.2.3 to 12.2.14
Severity: High (CVSS v3.1 Base Score 7.5)
Access Vector: Network — unauthenticated HTTP access
MOS Reference: Doc ID 3107176.1

This vulnerability allows unauthenticated network access to the Oracle Configurator component, potentially exposing sensitive configuration data or enabling unauthorized access to system resources.
Oracle has released a security patch to address the issue, available through the Patch Availability Document in MOS.

In addition to applying the patch, Oracle recommends specific post-patch verification steps and tightened access controls around Configurator-related URLs.

🧩 CVE-2025-61882 — The Earlier Critical CVE Still Demands Attention

Component Affected: Oracle Concurrent Processing / BI Publisher Integration
Severity: Critical — Remote Code Execution (RCE)
MOS Reference: Doc ID 3106344.1
Status: Actively exploited in the wild

This earlier CVE exposed an RCE vulnerability that could be triggered via HTTP, allowing attackers to execute arbitrary code on EBS application servers.
It has been actively exploited by threat actors (including ransomware groups), leading Oracle and cybersecurity agencies to issue urgent patching advisories.

Organizations should ensure that:

The CVE-2025-61882 patch has already been applied.
Prerequisite CPU/PSU patches are installed before applying the emergency fix.
Threat hunting and log analysis are performed for signs of compromise.

🔍 Key Differences Between CVE-2025-61882 and CVE-2025-61884

Aspect	CVE-2025-61882	CVE-2025-61884
Severity	Critical (RCE)	High (Unauthorized Access)
Attack Vector	HTTP, Remote Code Execution	HTTP, Configurator Runtime UI
Public Exploits	Actively exploited	No public exploit observed yet
MOS Note	3106344.1	3107176.1
Additional Mitigation	IOC scanning, log monitoring, CPU baseline patches	Restrict access to Configurator UI, apply post-patch hardening

🛠️ Recommended Actions for EBS Administrators

Immediately apply the patches for both CVEs as per Oracle’s MOS notes.
Validate patch prerequisites (previous CPUs or required patch baselines).
Restrict HTTP access to Configurator and BI Publisher components to trusted internal users only.
Enable web application firewall (WAF) filtering for known exploit patterns.
Perform threat hunting using HTTP access logs, BI Publisher logs, and concurrent manager trace files.
Regularly monitor Oracle’s Security Alert portal and subscribe to their Critical Patch Update (CPU) notifications.

💡 Why This Matters

Many enterprises still rely on Oracle E-Business Suite for core ERP functions such as finance, supply chain, HR, and manufacturing.
Given its business-critical nature, EBS environments remain a prime target for cyberattacks, especially when exposed to the internet.

Applying the latest patches promptly and reviewing access controls can dramatically reduce risk exposure.
Organizations running EBS on Oracle Cloud Infrastructure (OCI) or private cloud should also ensure that network security lists and WAF rules are up to date.

🧠 Final Thoughts

The appearance of two major vulnerabilities in quick succession highlights the need for a proactive security posture in Oracle ERP environments.
Stay current with patches, monitor advisories, and collaborate closely with your DBA, Sysadmin, and InfoSec teams.

For more technical guidance, refer to:

CVE-2025-61882 – MOS Note 3106344.1

CVE-2025-61884 – MOS Note 3107176.1

Friday, September 12, 2025

How to Make a Linux User Password Never Expire: Step-by-Step Guide

Introduction:

Password expiry policies are important for security, but sometimes you need to keep certain Linux user accounts active without enforcing password changes. For instance, in administrative or automation accounts like user1, frequent password expiration can disrupt services. In this guide, we’ll show you how to make a Linux user password never expire.

Step 1: Check the Current Password Expiry

Use the chage command to see when a user’s password will expire:


sudo chage -l user1

Example output:


Last password change                                    : Jul 03, 2025
Password expires                                        : Sep 01, 2025
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 1
Maximum number of days between password change          : 60
Number of days of warning before password expires       : 7


Here, the password is set to expire every 60 days.

Step 2: Make the Password Never Expire
Option 1: Using chage
sudo chage -M 99999 user1


-M 99999 sets the maximum days between password changes to effectively never expire.


Verify the change:
sudo chage -l user1

You should now see:
Password expires : never

Option 2: Using passwd
sudo passwd -x 99999 user1


Step 3: Verify the Configuration
Check again with:
sudo chage -l user1

Ensure:

Password expires: never

Account expires: never


This ensures the account will not require periodic password changes.

Step 4: Best Practices


Only disable password expiry for accounts that require uninterrupted access 
Keep strong passwords or use SSH keys where possible.

Monitor accounts regularly to maintain security.

Conclusion
Preventing password expiration in Linux is simple using chage or passwd. By setting 
odiuser or any critical account to never expire, you can avoid service disruptions 
while maintaining control over other security policies.

Wednesday, May 1, 2024

How to Install Oracle Database in Docker: Step-by-Step Guide for Seamless Deployment

In this post, we will go through the steps on how we can install and use Oracle Database 21c inside an Docker container. To access the database image on Docker, you start the container and then run the commands through docker to access the database

Steps:-

[opc@instance-20240128-1525 ~]$ sudo yum install docker-engine docker-cli

[opc@instance-20240128-1525 ~]$ sudo systemctl enable --now docker

[opc@instance-20240128-1525 ~]$ sudo docker info

Client:

Debug Mode: false

Server:

Containers: 0

Running: 0

Paused: 0

Stopped: 0

Images: 0

Server Version: 19.03.11-ol

Storage Driver: overlay2

Backing Filesystem: xfs

Supports d_type: true

Native Overlay Diff: false

Logging Driver: json-file

Cgroup Driver: cgroupfs

Plugins:

Volume: local

Network: bridge host ipvlan macvlan null overlay

Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog

Swarm: inactive

Runtimes: runc

Default Runtime: runc

Init Binary: docker-init

containerd version: 7eba5930496d9bbe375fdf71603e610ad737d2b2

runc version: 860f061

init version: fec3683

Security Options:

seccomp

Profile: default

Kernel Version: 5.4.17-2136.322.6.2.el7uek.x86_64

Operating System: Oracle Linux Server 7.9

OSType: linux

Architecture: x86_64

CPUs: 2

Total Memory: 6.487GiB

Name: instance-20240128-1525

ID: 6OVG:2ZU5:3GU5:AJKF:JAKN:FJSU:SJ2Q:D7ZM:ZNKN:EJKS:6T3M:3GJ6

Docker Root Dir: /var/lib/docker

Debug Mode: false

Registry: https://index.docker.io/v1/

Labels:

Experimental: false

Insecure Registries:

127.0.0.0/8

Live Restore Enabled: false

Registries:

[opc@instance-20240128-1525 ~]$ sudo su

[root@instance-20240128-1525 opc]# docker login container-registry.oracle.com

Username: *********

Password:

WARNING! Your password will be stored unencrypted in /root/.docker/config.json.

Configure a credential helper to remove this warning. See

https://docs.docker.com/engine/reference/commandline/login/#credentials-store

[root@instance-20240128-1525 opc]# docker pull container-registry.oracle.com/database/enterprise:latest

[root@instance-20240128-1525 opc]# docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

e556dbeb3c1d container-registry.oracle.com/database/enterprise:latest "/bin/sh -c 'exec $O…" 5 seconds ago Up 4 seconds (health: starting) 0.0.0.0:1521->1521/tcp oracle-db

Check the logs

[root@instance-20240128-1525 opc]# docker logs oracle-db

From the log, we can after few mins, we can see a message like below.

The Oracle base remains unchanged with value /opt/oracle

#########################

DATABASE IS READY TO USE!

#########################

Now, go inside the docker container.

[root@instance-20240128-1525 opc]# docker ps -a

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

e556dbeb3c1d container-registry.oracle.com/database/enterprise:latest "/bin/sh -c 'exec $O…" 2 hours ago Up About an hour (healthy) 0.0.0.0:1521->1521/tcp oracle-db

[root@instance-20240128-1525 opc]# docker exec -it oracle-db /bin/bash

bash-4.2$ whoami

oracle

bash-4.2$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on Sun Jan 28 12:27:14 2024

Version 21.3.0.0.0

Connected to:

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Version 21.3.0.0.0

SQL> show pdbs;

CON_ID CON_NAME OPEN MODE RESTRICTED

---------- ------------------------------ ---------- ----------

2 PDB$SEED READ ONLY NO

3 ORCLPDB1 READ WRITE NO

bash-4.2$ df -kh

Filesystem Size Used Avail Use% Mounted on

overlay 39G 19G 21G 48% /

tmpfs 64M 0 64M 0% /dev

tmpfs 3.3G 0 3.3G 0% /sys/fs/cgroup

shm 64M 0 64M 0% /dev/shm

/dev/sda3 39G 19G 21G 48% /etc/hosts

tmpfs 3.3G 0 3.3G 0% /proc/acpi

tmpfs 3.3G 0 3.3G 0% /proc/scsi

tmpfs 3.3G 0 3.3G 0% /sys/firmware

how to connect to the db using sqldeveloper

Hostname is the public IP of the VM where the container is running.

This completes the step by step instructions on how we can install Oracle DB inside a docker container and subsequently connect to the DB using sqldeveloper client. I hope, this post will help someone.

Till then, start learning cloud.

Thursday, April 25, 2024

Mastering Oracle Cloud: Step-by-Step Guide to Provision Your OIC Instance

Oracle Integration Cloud Service is a complete, secure, but lightweight integration solution that enables you to connect your applications in the cloud. It simplifies connectivity between your applications, and can connect both your applications that live in the cloud and your applications that still live on premises. It is a PaaS offering from Oracle and thus users who needs access to access to OIC must reside in IDCS(which is now the identity domain). In this post, we are going to explain, how we can provision an OIC instance from scratch when we have identity domain in place.

We will now provision an OIC instance in OCI console. Go to Developer Services

Click on Integration

We have successfully provisioned OIC instance. Now, in order to login, we need a user which has to be validated by IAM(Identity Domains) and it should have proper role assigned to it.

Go to Identity Domains, select the required domain and create a new user

Once the user is created, go to the Oracle Cloud Services under Identity domains and choose the OIC instance which was created earlier.

Click on the name and navigate to "Application roles".

Click on Assign.

That's it. Using this user, we should be able to login to the OIC Console.

I hope this post will help someone. Till, then keep learning cloud.

Pages

Wednesday, February 4, 2026

OCI Load Balancer Health Check Failing Despite Correct Security Rules? Here’s How to Fix It

Understanding the OCI Load Balancer Health Check

Case Study: Health Check Failing Despite Correct Security Settings

Step 1: Check if the backend application is listening

Step 2: Check the HTTP response code

Step 3: Fix Apache configuration and permissions

Step 4: Verify LB health check

Key Takeaways

Conclusion

Friday, January 23, 2026

Step-by-Step Guide: OCI DevOps & Resource Manager Terraform Infrastructure Provisioning

Introduction

High-Level Architecture

Step 1: Create OCI DevOps Code Repository

Step 2: Create OCI DevOps Build Pipeline

Step 3: Prepare Repository Structure

Step 4: Upload Artifacts and Push to Repository

Step 5: Upload Terraform Artifacts to Object Storage

Step 6: Create OCI Resource Manager Stack (CLI)

Step 7: Update build_spec.yaml

Step 8: Create Build Pipeline Trigger

Step 9: Commit and Trigger the Pipeline

Benefits of This Approach

Conclusion

Saturday, January 10, 2026

Using Oracle SQLcl MCP Server with Oracle 19c: A Step-by-Step Guide for NLP-Based Database Queries

Introduction

Architecture Overview

Prerequisites

Step 1: Install JDK 17 (Required for SQLcl)

Step 2: Install Oracle SQLcl

Step 3: Install Claude Desktop

Step 4: Prepare Oracle Database 19c

Verify PDBs

Listener and Network Setup

Step 5: Create SQLcl Connection

Step 6: Start SQLcl MCP Server

Step 7: Configure Claude Desktop for MCP

Step 8: Follow Least Privilege (Best Practice)

Step 9: Test NLP Queries via Claude

Security Considerations

Why This Matters

Final Thoughts

Sunday, October 12, 2025

Oracle E-Business Suite Hit by New High-Severity Vulnerability — CVE-2025-61884

Overview

⚠️ CVE-2025-61884 — What We Know So Far

🧩 CVE-2025-61882 — The Earlier Critical CVE Still Demands Attention

🔍 Key Differences Between CVE-2025-61882 and CVE-2025-61884

🛠️ Recommended Actions for EBS Administrators

💡 Why This Matters

🧠 Final Thoughts

Friday, September 12, 2025

How to Make a Linux User Password Never Expire: Step-by-Step Guide

Introduction:

Step 1: Check the Current Password Expiry

Step 2: Make the Password Never Expire

Option 1: Using chage

Option 2: Using passwd

Step 3: Verify the Configuration

Step 4: Best Practices

Conclusion

Wednesday, May 1, 2024

How to Install Oracle Database in Docker: Step-by-Step Guide for Seamless Deployment

Thursday, April 25, 2024

Mastering Oracle Cloud: Step-by-Step Guide to Provision Your OIC Instance

Step 7: Update `build_spec.yaml`

Option 1: Using `chage`

Option 2: Using `passwd`