Oel 7.8

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 sac1647283583153:prod-m7gnf7nufz32a:prod-m7gnf7nufz32a:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-oel-7-8-vm \
  --image sac1647283583153: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.

Run these commands 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. It does not mean anyone else used your machine.

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. Every virtual machine deployed from this image therefore 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. This 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>

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.

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 that they are already 7.9 errata builds. The el7uek tag on the kernel shows that 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

At every boot, root's crontab runs /stage/scripts/initial_boot_update.sh. The script 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, then 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.

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, 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 the firewall on.

To turn on the host firewall, run:

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, to open HTTPS:

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

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

The disks and partitions are laid out as follows:

• /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: size 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.

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.

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> and 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 on the file and mode 700 on the .ssh directory, both owned by that user.