CentOS 7.3

Option A: Azure Portal

• Go to the Azure Marketplace and search for "CentOS 7.3 SecureAnyCloud".
• Select the image and choose Create.
• On the Basics tab, set Subscription to your Azure subscription, Resource Group to a new or existing group, Virtual Machine Name to a name for your VM, Region to your preferred Azure region, and Size to Standard_B2s (recommended).
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• Choose Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:centos-7-3:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-centos-75-vm \
  --image sac1647283583153:centos-7-3:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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-centos-75-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

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

Check that the machine is the CentOS Linux 7.3.1611 release you expect. The centos-release package is the authoritative answer, because /etc/os-release carries only the major version on CentOS 7:

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

Expected output:

CentOS Linux release 7.3.1611 (Core) centos-release-7-3.1611.el7.centos.x86_64 NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" VERSION_ID="7" 3.10.0-514.26.2.el7.x86_64 x86_64

VERSION_ID="7" is expected. CentOS 7's /etc/os-release records only the major version, so /etc/centos-release and rpm -q centos-release are the checks that confirm the point release. Kernel 3.10.0-514.26.2.el7 is the newest kernel ever published for 7.3.

CentOS 7's /etc/os-release has no PLATFORM_ID field. That field was introduced in the el8 line.

rpm -q centos-release is the rpm-level proof of the point release, so a hand-edited /etc/centos-release cannot fake it. On 7.3, the updates repository ships no centos-release package at all. This NEVRA is therefore the one the install tree laid down, and yum update never touches it.

This is the defining feature of this image. CentOS 7 is end-of-life and its original mirrors are gone, so every repository is repointed to the CentOS 7.3.1611 vault. Pinning to that particular vault tree keeps the machine on 7.3:

yum repolist enabled grep '^baseurl' /etc/yum.repos.d/CentOS-Base.repo
sudo yum -q check-update; echo "check-update exit: $?"

Expected output: every repository resolves to vault.centos.org/7.3.1611. check-update exits 0, because the image is already patched to the last packages published for this point release:

repo id repo name status base/x86_64 CentOS-7.3.1611 - Base (vault) 9,363 extras/x86_64 CentOS-7.3.1611 - Extras (vault) 451 updates/x86_64 CentOS-7.3.1611 - Updates (vault) 2,146 repolist: 11,960 baseurl=https://vault.centos.org/7.3.1611/os/$basearch/ baseurl=https://vault.centos.org/7.3.1611/updates/$basearch/ baseurl=https://vault.centos.org/7.3.1611/extras/$basearch/ baseurl=https://vault.centos.org/7.3.1611/centosplus/$basearch/ check-update exit: 0

Why the pin holds. A vault tree for a point release is frozen and self-contained. The updates repository for 7.3.1611 carries the errata issued during 7.3's own lifetime, with the kernel running up to 3.10.0-514.26.2.el7. It contains no centos-release package, so nothing in this tree can rewrite the release string. yum update applies those errata and stops. No package here can move the machine to 7.4 or beyond.

CentOS also ships a CentOS-Vault.repo that lists every historical point release. On this image, every one of those sections is disabled, so nothing crosses point releases unless you deliberately enable it:

awk '/^enabled=1/{n++} END{print n+0}' /etc/yum.repos.d/CentOS-Vault.repo

Expected output:

0

check-update returning 0 means that no newer packages exist in the 7.3.1611 vault. The image is patched to the end of this point release's errata stream. No further security updates will ever be published upstream, for 7.3 or for CentOS 7 at all. For anything beyond legacy migration or version pinning, move to a supported distribution.

Confirm that SELinux is enforcing, root is locked, and SSH accepts keys only:

sudo getenforce
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) ' systemctl is-active rpcbind.socket || true

Expected output:

Enforcing root LK 2009-12-22 -1 -1 -1 -1 (Alternate authentication scheme in use.) permitrootlogin no pubkeyauthentication yes passwordauthentication no unknown

root LK means the root password is locked.

rpcbind.socket reporting unknown is intentional, and it is stronger than inactive. The rpcbind package is not installed on this image at all, so there is no RPC listener on port 111 to disable. If you need NFSv3 later, install nfs-utils first, then run sudo systemctl unmask rpcbind.socket && sudo systemctl enable --now rpcbind.socket.

getenforce, sshd and ss live in /usr/sbin. CentOS 7 adds that directory to a non-root PATH only from /etc/profile. An interactive login shell has them, but a one-shot ssh host 'getenforce' does not. Running them through sudo, as above, works in both cases.

Confirm that the Azure Linux Agent and time synchronisation are healthy, and check your resources:

systemctl is-active waagent
systemctl is-enabled waagent rpm -q WALinuxAgent grep -E '^Provisioning\.(Agent|Enabled|UseCloudInit)=' /etc/waagent.conf
systemctl is-active chronyd df -h / free -h

Expected output:

active enabled WALinuxAgent-2.2.14-1.el7.noarch Provisioning.Enabled=y Provisioning.UseCloudInit=n Provisioning.Agent=waagent active Filesystem Size Used Avail Use% Mounted on /dev/sda1 10G 1.2G 8.9G 12% / total used free shared buff/cache available Mem: 3.7G 171M 3.0G 16M 542M 3.3G Swap: 0B 0B 0B

waagent is what lets Azure provision your SSH key, resize the OS disk, run extensions and report VM health. It should always be active and enabled.

On this image, the Azure Linux Agent is the sole provisioning agent, and cloud-init is not installed. This is deliberate. The Azure Linux Agent that ships with CentOS 7.3 refuses to provision at all if it finds cloud-init running alongside it, so exactly one of the two has to own provisioning. On this image, that is the agent. It injects the SSH key you supply at create time, regenerates the SSH host keys, sets the hostname and reports VM health. Leaving cloud-init out is what makes the image provision reliably and receive your key on first boot.

If your workflow depends on cloud-init specifically, for example #cloud-config user data, this is not the image for it. Use a CentOS Stream, AlmaLinux or Rocky Linux image instead. Custom data supplied to the VM is still delivered to /var/lib/waagent/CustomData, so a first-boot script of your own can read it there.

Swap: 0B is deliberate. Azure manages swap on the temporary resource disk through waagent, and no swap file or swap partition ships inside the image.

This image runs a host firewall as well as the Azure Network Security Group, and you must open a new port in both. firewalld ships installed, enabled and active, exactly as it does on a stock CentOS 7 install:

sudo ss -tlnp sudo firewall-cmd --get-default-zone sudo firewall-cmd --list-all

Expected output: the only externally reachable listener is sshd on port 22. You also see postfix bound to 127.0.0.1:25 and ::1:25. That is the local mail transport, which is reachable only from the machine itself and not from the network. CentOS 7 prints the IPv4 wildcard as *:22 and the IPv6 wildcard as :::22:

State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=2523,fd=13)) LISTEN 0 128 *:22 *:* users:(("sshd",pid=4107,fd=3)) LISTEN 0 100 ::1:25 :::* users:(("master",pid=2523,fd=14)) LISTEN 0 128 :::22 :::* users:(("sshd",pid=4107,fd=4)) public public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:

Read the Local Address:Port column, not the peer column. It tells you what the machine is actually offering to the network.

This applies to every port you add afterwards. Opening 443 in the NSG alone is not enough. The traffic reaches the machine and firewalld drops it, which looks exactly like a broken application. Open the port in both places: in the Azure NSG as an inbound rule, and on the machine with sudo firewall-cmd --permanent --add-service=https followed by sudo firewall-cmd --reload.

For a port with no named service, use sudo firewall-cmd --permanent --add-port=8080/tcp and the same reload. Check the result with sudo firewall-cmd --list-all again, and always keep the ssh service in the zone so that you do not lock yourself out.

If you prefer to manage inbound access with the NSG alone, sudo systemctl disable --now firewalld removes the host layer. Do that deliberately, not by accident.