Oe
Operating Systems Azure

Oracle Enterprise Linux 7.8 on Azure User Guide

| Product: Oracle Enterprise Linux 7.8 on Azure

Overview

This guide covers the deployment and configuration of Oracle Enterprise Linux 7.8 on Microsoft Azure using cloudimg's virtual machine image from the Azure Marketplace (offer prod-m7gnf7nufz32a).

Oracle Linux is a free, enterprise grade Linux distribution built by Oracle to be binary compatible with Red Hat Enterprise Linux 7. Oracle provides the binaries at no cost and permits redistribution, so there is no subscription and no licence key needed to use or patch it.

This image is an established Oracle Linux 7 system that was built on Oracle Linux 7.8 and has since taken updates from the Oracle Linux 7 channels. Its release file still reads 7.8, while most of its packages are the newer 7.9 errata builds. Steps 5 and 6 show both and explain how to bring the whole machine to 7.9.

⚠️ End of life status — read before deploying

Oracle Linux 7 reached the end of Oracle Premier Support in December 2024. 7.8 was followed by 7.9 in October 2020, and 7.9 is the final Oracle Linux 7 release: there is no 7.10. Oracle's paid Extended Support for Oracle Linux 7 runs to July 2029; the free public channel no longer receives new Oracle Linux 7 errata. This image is a fixed baseline for legacy applications and compatibility testing that still need an Oracle Linux 7 or RHEL 7 base. It is not a system that keeps itself patched.

You own ongoing patching. For continued security updates, take an Oracle Linux Extended Support subscription, or plan a migration to a supported release such as Oracle Linux 8, 9 or 10.

What's included:

  • Oracle Linux 7 (release file 7.8, packages from the Oracle Linux 7.9 update channel), binary compatible with RHEL 7
  • The Unbreakable Enterprise Kernel Release 6 (5.4, booted by default) and the Red Hat Compatible Kernel (3.10)
  • A first boot script that applies the security errata available on the enabled channels, without kernel changes
  • ol7_latest, ol7_UEKR6, ol7_addons, EPEL and Azure CLI repositories enabled
  • Azure Linux Agent (waagent) and cloud-init 19.4 for Azure provisioning
  • Azure CLI 2.38 and Python 3.6
  • Chronyd for NTP time synchronisation
  • Generation 1 (BIOS) Hyper V virtual machine
  • 24/7 cloudimg support

Platform: Microsoft Azure (Generation 1 Hyper V) Default user: azureuser

Prerequisites

Before deploying this image, ensure you have:

  1. An active Microsoft Azure subscription
  2. The Azure CLI, installed locally or in Azure Cloud Shell
  3. An SSH key pair for Linux VM access
  4. Familiarity with Azure VM management

Step 1: Deploy the Virtual Machine

Deploy the image by its Marketplace URN. The image carries a purchase plan, so accept its terms once per subscription first:

az vm image terms accept --urn cloudimg1647283583153:prod-m7gnf7nufz32a:prod-m7gnf7nufz32a:latest

az vm create \
  --resource-group myResourceGroup \
  --name my-oel-7-8-vm \
  --image cloudimg1647283583153:prod-m7gnf7nufz32a:prod-m7gnf7nufz32a:latest \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Add --size with the size your workload needs. This is a Generation 1 image. The Azure CLI may print a warning that new virtual machines default to Trusted Launch; with this image the machine is still created as a standard Generation 1 virtual machine, and the warning needs no action.

Step 2: Connect via SSH

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-oel-7-8-vm --show-details --query publicIps -o tsv
ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.

Your first login prints a Last login line dated January 2024 from azure-bastion.internal.cloudapp.net. That line comes from the login history the image was built with, not from anyone using your machine.

Step 3: Give the machine its own SSH host keys and machine ID

Do this first, before you rely on the machine. The SSH host keys and the systemd machine ID in this image were created when the image was built, and they are not regenerated at first boot, so every virtual machine deployed from this image starts with the same host keys and the same machine ID. Replace them with ones unique to your machine:

sudo rm -f /etc/ssh/ssh_host_*
sudo /usr/sbin/sshd-keygen
sudo systemctl restart sshd
sudo rm -f /etc/machine-id
sudo systemd-machine-id-setup

Expected output:

Generating SSH2 RSA host key: [  OK  ]
Generating SSH2 ECDSA host key: [  OK  ]
Generating SSH2 ED25519 host key: [  OK  ]
Initializing machine ID from random generator.

Your current session stays open. The next time you connect, your SSH client warns that the remote host identification has changed, because the machine now presents its new keys. That warning is expected exactly once, after this step. Remove the old entry on your workstation, then connect again and accept the new key:

ssh-keygen -R <vm-ip>
ssh azureuser@<vm-ip>

Step 4: Remove the Azure Site Recovery agent

The image still carries the Azure Site Recovery mobility agent (InMageVx) and its boot hooks and configuration from the way it was migrated into Azure. Its vxagent service fails at every boot, and its configuration directories hold keys that belong to that migration. Your machine does not need any of it. Check the failed unit, then remove the package, its init scripts, units, udev rule, dracut module and directories:

systemctl --failed --no-legend
sudo yum -q -y remove InMageVx
for s in vxagent uarespawnd boottimemirroring_phase1 boottimemirroring_phase2 vConService_linux; do sudo chkconfig --del $s 2>/dev/null; sudo rm -f /etc/init.d/$s; done
sudo systemctl disable asr-installga.service involflt_start.service involflt_stop.service
sudo rm -f /etc/systemd/system/involflt_start.service /etc/systemd/system/involflt_stop.service /etc/udev/rules.d/09-inm_udev.rules
sudo rm -rf /usr/local/InMage /usr/local/asr-installga /etc/vxagent /usr/lib/dracut/modules.d/95involflt
sudo systemctl daemon-reload
sudo systemctl reset-failed
systemctl --failed --no-legend

The first command lists vxagent.service loaded failed failed. The last one prints nothing, meaning no unit has failed. While removing the package, yum prints warning: file /tmp/MobSvcInstaller/...: remove failed lines; they refer to installer files that are already gone and are harmless. Do this step before the full update in Step 6, so that the new kernel's initramfs is built without the agent's dracut module.

The image also creates the cloud-init default account cloud-user, which has no password, no SSH key and passwordless sudo. If you do not use it, remove it:

sudo userdel -r cloud-user

userdel reports /var/spool/mail/cloud-user not owned by cloud-user, not removing and exits with code 12; the account and its home directory are removed all the same, as getent passwd cloud-user (which then prints nothing) confirms.

Step 5: Confirm the release

cat /etc/oracle-release
grep -E '^(NAME|VERSION|ID|VERSION_ID)=' /etc/os-release
uname -rm
rpm -q oraclelinux-release redhat-release-server

Expected output:

Oracle Linux Server release 7.8
NAME="Oracle Linux Server"
VERSION="7.8"
ID="ol"
VERSION_ID="7.8"
5.4.17-2136.316.7.el7uek.x86_64 x86_64
oraclelinux-release-7.8-1.0.7.el7.x86_64
redhat-release-server-7.9-6.0.1.el7_9.x86_64

The release file and oraclelinux-release say 7.8. The el7_9 tag on most packages, such as redhat-release-server above, shows they are already 7.9 errata builds. The el7uek tag on the kernel shows the machine is running the Unbreakable Enterprise Kernel. The Red Hat Compatible Kernel (3.10 el7) is installed alongside it:

rpm -q kernel kernel-uek

Expected output:

kernel-3.10.0-1160.el7.x86_64
kernel-3.10.0-1160.66.1.el7.x86_64
kernel-3.10.0-1160.83.1.0.1.el7.x86_64
kernel-uek-5.4.17-2136.307.3.6.el7uek.x86_64
kernel-uek-5.4.17-2136.308.9.el7uek.x86_64
kernel-uek-5.4.17-2136.316.7.el7uek.x86_64

Step 6: Updates and the first boot script

At every boot, root's crontab runs /stage/scripts/initial_boot_update.sh, which applies the security errata available on the enabled channels, leaving out kernels and the release package:

sudo crontab -l
cat /stage/scripts/initial_boot_update.sh

Expected output:

@reboot /stage/scripts/initial_boot_update.sh
#!/bin/bash 
yum -y update --security --exclude=kernel* --exclude=oraclelinux-release >> /stage/scripts/initial_boot_update.log

On a fresh machine this run takes a few minutes after boot, and other yum commands wait for its lock until it finishes. It does not bring the machine fully up to date. Afterwards, yum check-update still lists pending updates (exit code 100), including the newer kernels and the 7.9 release package:

sudo yum -q check-update; echo "exit code: $?"

List the enabled repositories:

yum -q repolist enabled

Expected output:

repo id           repo name                                               status
azure-cli         Azure CLI                                                  123
epel/x86_64       Extra Packages for Enterprise Linux 7 - x86_64          13,791
ol7_UEKR6/x86_64  Latest Unbreakable Enterprise Kernel Release 6 for Orac  1,401
ol7_addons/x86_64 Oracle Linux 7Server Add ons (x86_64)                      981
ol7_latest/x86_64 Oracle Linux 7Server Latest (x86_64)                    27,429

To apply everything the channels carry, including the kernels and the 7.9 release package, run a full update and reboot:

sudo yum -y update
sudo systemctl reboot

After the reboot, the machine reports the final Oracle Linux 7 release and runs the newest Unbreakable Enterprise Kernel, and yum check-update returns exit code 0, meaning nothing further is available from the enabled channels:

cat /etc/oracle-release
uname -r
sudo yum -q check-update; echo "exit code: $?"

Expected output:

Oracle Linux Server release 7.9
5.4.17-2136.338.4.2.el7uek.x86_64
exit code: 0

Because Oracle Linux 7 is end of life, a machine with nothing left to apply is caught up only with the frozen free channel. It is not free of vulnerabilities found after that channel stopped receiving errata.

Step 7: Security posture

getenforce
sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|challengeresponseauthentication) '
systemctl is-active firewalld

Expected output:

Disabled
pubkeyauthentication yes
passwordauthentication no
challengeresponseauthentication no
unknown
  • SSH is key only. Password and challenge response logins are disabled. The root, azureuser and cloud-user passwords are locked, and no account has a password hash.
  • SELinux is disabled on this image (SELINUX=disabled in /etc/selinux/config). If your policy needs SELinux, plan to enable it yourself, which needs a full filesystem relabel and a reboot.
  • The host firewall is off. firewalld is installed but disabled and has never been started, which is why systemctl is-active reports unknown. The Azure Network Security Group is the only network control until you turn it on.

To turn on the host firewall:

sudo systemctl enable --now firewalld
sudo firewall-cmd --list-all

The default public zone lists dhcpv6-client ssh under services, so your SSH session keeps working. To expose another service, open it in both the Azure NSG and firewalld, for example HTTPS:

sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

Step 8: Verify Azure integration

systemctl is-active waagent
systemctl is-enabled waagent
cloud-init --version
sudo cloud-init status
systemctl is-active chronyd
df -h /

Expected output on a fresh machine:

active
enabled
/usr/bin/cloud-init 19.4
status: done
active
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        38G  6.4G   29G  18% /

The used and available figures on / change as you install and update packages.

waagent lets Azure run extensions and report VM health. cloud-init handles provisioning: it creates azureuser, installs your SSH key and runs any custom data you supply.

Run cloud-init status with sudo, as above. Without sudo, the cloud-init 19.4 build on Oracle Linux 7 (Python 2.7) stops with NameError: global name 'PermissionError' is not defined when it cannot read its root only status file. Provisioning itself completes, and sudo cloud-init status reports status: done.

Disk layout

Device Size Use
/dev/sda1 2 GB /boot (ext4)
/dev/sda2 38 GB / root filesystem (ext4)
/dev/sda3 10 GB swap partition, not enabled (free -h shows 0B swap)
/dev/sdb1 varies /mnt, the Azure temporary resource disk

The OS disk is 50 GB. The root partition is followed by the swap partition, so making the OS disk larger in Azure does not grow / on its own.

Step 9: Networking

sudo ss -tlnp

On a fresh machine the only external listener is sshd on port 22. Postfix listens for local mail on the loopback address only ([::1]:25), and chronyd uses local port 323.

Step 10: Install software and add a user

Install packages from the enabled repositories in the usual way, for example:

sudo yum -y install git

To add another administrator, create the account with sudo adduser <name>, add it to the wheel group with sudo usermod -aG wheel <name>, then copy your public key into /home/<name>/.ssh/authorized_keys with mode 600 and the .ssh directory mode 700, owned by that user.

Common Use Cases

  • Hosting legacy applications that require an Oracle Linux 7 or RHEL 7 base
  • Compatibility and regression testing against Oracle Linux 7
  • Lift and shift of existing Oracle Linux 7 workloads to Azure

Troubleshooting

Cannot connect via SSH

  1. Verify the VM is in Running state in the Azure Portal
  2. Check that port 22 is allowed in the Network Security Group
  3. Ensure you are using the correct username: azureuser
  4. Verify your SSH key matches the one you supplied at create time. Password login is disabled, so a wrong key cannot fall back to a password prompt.
  5. If SSH reports that the remote host identification has changed right after Step 3, run ssh-keygen -R <vm-ip> on your workstation and connect again. At any other time, treat that warning seriously and find out why the key changed.

A yum command waits for a lock after boot

The first boot script holds the yum lock for a few minutes after each boot. Wait for it to finish:

sudo tail -3 /stage/scripts/initial_boot_update.log

Azure agent not running

sudo systemctl status waagent

If it is not running, start it with sudo systemctl enable --now waagent.

Package manager issues

Refresh the metadata cache first:

sudo yum clean all
sudo yum makecache

If repositories are unreachable, check DNS resolution with getent hosts yum.oracle.com.

Important Notes

End of life. Oracle's Lifetime Support Policy lists Oracle Linux 7 with Premier Support ending in December 2024 and Extended Support ending in July 2029 (Oracle Lifetime Support Policy: Oracle Open Source Service Offerings). Oracle Linux 7.9, released in October 2020, is the last Oracle Linux 7 update (endoflife.date: Oracle Linux). This image is not kept patched by the free channel; you own ongoing patching. For continued security updates, take an Oracle Linux Extended Support subscription, or migrate to a supported release such as Oracle Linux 8, 9 or 10.

Oracle Linux is free and open source, and Oracle permits its redistribution. It is a distribution assembled from thousands of independently packaged components, each carrying its own terms, including the GPL, LGPL, MIT, BSD, Apache 2.0 and MPL; every package's terms are readable with rpm -qi <package>. No subscription, licence key or Red Hat entitlement is required.

Oracle and Oracle Linux are trademarks of Oracle Corporation. The names are used here only to identify the distribution this image contains. cloudimg is not affiliated with, endorsed by or sponsored by Oracle Corporation.

Support

For assistance with this image, contact cloudimg support: