Operating Systems Azure

CentOS 7.2 on Azure User Guide

| Product: CentOS 7.2 on Azure

Overview

This guide covers the deployment and configuration of CentOS 7.2 (CentOS Linux 7.2.1511) on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

CentOS Linux is a community rebuild of Red Hat Enterprise Linux, binary compatible with RHEL 7. This image is deliberately pinned to the 7.2.1511 point release: its package repositories point at the frozen CentOS 7.2.1511 vault, so a routine yum update applies the errata issued for 7.2 and does not roll the machine forward to 7.3 or later.

That matters when an application, a kernel module, a driver or a vendor support statement is certified against one specific CentOS 7 point release rather than the CentOS 7 series as a whole. If you do not need a specific point release, use the CentOS 7 image instead — it ships 7.9.2009, the final CentOS 7 release.

End-of-life notice — read this first

CentOS Linux 7 reached end-of-life on 30 June 2024, and 7.2.1511 is a back-catalogue point release that was superseded upstream by 7.3 through 7.9. Both facts matter:

  • This image is patched to the last packages that exist for 7.2.1511, from the frozen CentOS 7.2.1511 vault (vault.centos.org). "Fully patched" here means patched to the end of that point release's own errata stream — the newest kernel it ever received is 3.10.0-327.36.3.el7.
  • Errata published after 7.3 shipped were released against later point releases, not against 7.2. Staying on 7.2 means deliberately forgoing them.
  • CentOS 7 as a whole receives no further upstream security updates of any kind after its end-of-life date. Over time this image will carry unpatched vulnerabilities that cannot be remediated by updating CentOS 7, because upstream ships nothing further.
  • This image is provided for legacy-migration and version-pinned use — running software certified only against CentOS 7.2, or reproducing an environment at the exact release it was signed off on. Plan a migration to a supported distribution such as AlmaLinux, Rocky Linux, CentOS Stream, or a current RHEL for any workload that must remain secure.

The stock CentOS 7 repositories point at mirror.centos.org, which was retired at end-of-life. This image has already repointed every repository to the CentOS 7.2.1511 vault, so yum keeps working — against the frozen 7.2 package set — out of the box.

One package on this image is not from 7.2 — the Azure provisioning agent

This is specific to CentOS 7.0, 7.1 and 7.2, and it is disclosed here because it is a real deviation from an otherwise exact point release pin.

CentOS 7.2.1511 never shipped a WALinuxAgent package. The Azure Linux Agent first appears in the CentOS 7.3.1611 repositories. The 7.2.1511 vault contains no copy of it in any repository — not in os, updates, extras, centosplus or cr. The cloud-init that 7.2 does ship (version 0.7.5, from 2014) cannot stand in for it: its Azure support delegates the agent step to a walinuxagent service that would not exist, and its parser reads only the older fingerprint form of the SSH key that Azure delivers, not the inline value form Azure sends today.

Without a provisioning agent an Azure virtual machine cannot receive the SSH key you supply at create time or report itself ready to the platform, so a strictly-7.2-only image could not be deployed at all.

So this image is CentOS Linux 7.2.1511 in full, with exactly one exception: WALinuxAgent-2.2.0-4.el7.noarch, taken from the CentOS 7.3.1611 snapshot and pinned by URL and SHA-256 checksum. That package is a noarch build tagged for the generic el7 platform rather than for 7.3 specifically, and every dependency it declares is satisfied from 7.2.1511 itself — so it is the only package on the system that does not come from the 7.2 vault. The build refuses to complete if a second one ever appears.

The image states this on disk so you can confirm it yourself rather than taking our word for it:

cat /usr/share/doc/cloudimg/out-of-pin-packages.txt

Expected output:

cloudimg — CentOS 7.2 (CentOS Linux 7.2.1511) Azure image

This image is CentOS Linux 7.2.1511 from the frozen vault.centos.org/7.2.1511
tree, with EXACTLY ONE exception: the Azure provisioning agent.

CentOS 7.2.1511 never shipped a WALinuxAgent package — it first appears in
CentOS 7.3.1611 — and without a provisioning agent an Azure VM cannot receive
your SSH key or report ready to the platform. The agent below is therefore
sourced from the CentOS 7.3.1611 snapshot, pinned by URL and sha256:

  package = WALinuxAgent-2.2.0-4.el7.noarch
  source  = https://vault.centos.org/7.3.1611/extras/x86_64/Packages/WALinuxAgent-2.2.0-4.el7.noarch.rpm
  sha256  = 91e1847c85fb2d06b2443bbea704f1deb9a6e639c7c9f3d1eefdb8d9aaf1f6cf

And you can reproduce the whole comparison. This lists every installed package that is not available from the repositories this image is pinned to:

repoquery -a --qf '%{name}-%{version}-%{release}.%{arch}' 2>/dev/null | sort -u > /tmp/inpin
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | grep -v '^gpg-pubkey-' | sort -u > /tmp/inst
comm -23 /tmp/inst /tmp/inpin

Expected output — one line, the agent, and nothing else:

WALinuxAgent-2.2.0-4.el7.noarch

Terminal showing the cloudimg out of pin packages disclosure file naming WALinuxAgent 2.2.0-4.el7.noarch, its CentOS 7.3.1611 source URL and its sha256 checksum, followed by a comparison of installed packages against the pinned 7.2.1511 repositories that returns that single package and nothing else

If an exact, unmodified 7.2.1511 package set matters more to you than deployability on Azure, the CentOS 7 image (7.9.2009) or the CentOS 7.6 image are pinned point releases whose own vault trees do include the Azure agent, so they carry no out of pin package at all.

What's included

  • CentOS Linux 7.2.1511 (Core), binary compatible with RHEL 7
  • Repositories pinned to vault.centos.org/7.2.1511, so yum keeps working post-EOL and stays on 7.2
  • Every package that exists for 7.2.1511 applied at build time, including kernel 3.10.0-327.36.3.el7
  • A standard (non-LVM) single-partition xfs root
  • Azure Linux Agent (WALinuxAgent), handling provisioning, SSH key injection and host key regeneration — sourced from CentOS 7.3.1611 as described above
  • Chronyd for NTP time synchronisation
  • SELinux in enforcing mode
  • Gen1 Hyper V virtual machine support (BIOS boot)
  • 24/7 cloudimg support

Platform: Microsoft Azure (Gen1 Hyper V) Default user: azureuser

Security posture

This image ships with no known credential. There is no default password and no baked in SSH key:

  • The root account password is locked, so no one can log in as root with a password.
  • PasswordAuthentication is disabled in the SSH daemon, so every login is by key.
  • PermitRootLogin is set to no in the main /etc/ssh/sshd_config. CentOS 7's sshd has no sshd_config.d include directory, so the setting is applied in the main file, not a drop-in.
  • The only key that works is the public key you supply when you create the virtual machine. Azure injects it into azureuser at first boot, so no two machines you launch ever share a secret.
  • The machine identity and the SSH host keys are regenerated uniquely on every instance.
  • SELinux is left in enforcing mode, the CentOS default.
  • The only externally reachable listener is SSH on port 22. rpcbind is not installed at all, and its socket unit is masked so a later package install cannot silently reopen port 111.

Prerequisites

Before deploying this image, ensure you have:

  1. An active Microsoft Azure subscription
  2. Access to the Azure Portal or Azure CLI
  3. An SSH key pair for Linux VM access
  4. Familiarity with Azure VM management

Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

  1. Navigate to the Azure Marketplace and search for "CentOS 7.2 cloudimg"
  2. Select the image and click Create
  3. Configure the basics:
  4. Subscription: Select your Azure subscription
  5. Resource Group: Create new or select existing
  6. Virtual Machine Name: Enter a name for your VM
  7. Region: Select your preferred Azure region
  8. Size: Standard_B2s recommended
  9. Under Administrator Account, select SSH public key and enter your key
  10. Under Inbound Port Rules, allow SSH (port 22)
  11. Click Review + Create, then Create

Option B: Azure CLI

az vm create \
  --resource-group myResourceGroup \
  --name my-centos-72-vm \
  --image cloudimg:centos:centos72:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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-centos-72-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.

Step 3: Confirm the point release

Check that the machine is the CentOS Linux 7.2.1511 release you expect. The centos-release package is the authoritative answer — /etc/os-release only carries 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.2.1511 (Core)
centos-release-7-2.1511.el7.centos.2.10.x86_64
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
VERSION_ID="7"
3.10.0-327.36.3.el7.x86_64 x86_64

VERSION_ID="7" is expected: CentOS 7's /etc/os-release records only the major version, which is why /etc/centos-release and rpm -q centos-release are the checks that actually confirm the point release. Kernel 3.10.0-327.36.3.el7 is the newest kernel ever published for 7.2. (CentOS 7's /etc/os-release has no PLATFORM_ID field — that was introduced in the el8 line.)

Terminal showing cat of etc centos-release reporting CentOS Linux release 7.2.1511 Core, rpm -q centos-release reporting centos-release-7-2.1511.el7.centos.2.10, os-release fields ID centos and VERSION_ID 7, and uname reporting the 3.10.0-327.36.3.el7 kernel on x86_64

Step 4: The point release pin and the vault update path

This is the defining feature of this image. Because CentOS 7 is end-of-life its original mirrors are gone, so every repository is repointed to the CentOS 7.2.1511 vault — and pinning to that particular vault tree is what keeps the machine on 7.2:

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.2.1511, and 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.2.1511 - Base (vault)                  9,007
extras/x86_64              CentOS-7.2.1511 - Extras (vault)                  393
updates/x86_64             CentOS-7.2.1511 - Updates (vault)               2,560
repolist: 11,960
baseurl=https://vault.centos.org/7.2.1511/os/$basearch/
baseurl=https://vault.centos.org/7.2.1511/updates/$basearch/
baseurl=https://vault.centos.org/7.2.1511/extras/$basearch/
baseurl=https://vault.centos.org/7.2.1511/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.2.1511 carries the errata issued during 7.2's own lifetime, and it contains no centos-release package — so yum update applies those errata and stops. It cannot pull in the centos-release package from a later tree, which is what would otherwise move the machine to 7.3 or beyond.

CentOS also ships a CentOS-Vault.repo listing every historical point release. On this image every one of those sections is left 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 no newer packages exist in the 7.2.1511 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.2 or for CentOS 7 at all. For anything beyond legacy migration or version pinning, move to a supported distribution.

Terminal showing yum repolist with the base updates and extras repositories repointed to the CentOS 7.2.1511 vault, the CentOS-Base.repo baseurls at vault.centos.org 7.2.1511, and yum check-update exiting 0 meaning patched to the last packages published for this point release

Step 5: Verify the security posture and Azure integration

Confirm SELinux is enforcing, root is locked, SSH is key only, and the Azure Linux Agent is healthy:

getenforce
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
systemctl is-active rpcbind.socket || true
systemctl is-active waagent
rpm -q WALinuxAgent
grep -E '^Provisioning\.(Agent|Enabled|UseCloudInit)=' /etc/waagent.conf
systemctl is-active chronyd

Expected output:

Enforcing
root LK 2009-12-22 -1 -1 -1 -1 (Alternate authentication scheme in use.)
permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
unknown
active
WALinuxAgent-2.2.0-4.el7.noarch
Provisioning.Enabled=y
Provisioning.Agent=waagent
Provisioning.UseCloudInit=n
active

root LK means the root password is locked. rpcbind.socket reporting unknown is intentional and 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 sudo systemctl unmask rpcbind.socket && sudo systemctl enable --now rpcbind.socket.

waagent is what lets Azure provision your SSH key, resize the OS disk, run extensions and report VM health, so 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 — see the out of pin section above for why that combination is the only one that works on this point release.

Terminal showing SELinux enforcing, the root account reported as LK meaning locked, the effective sshd policy with permitrootlogin no and passwordauthentication no, rpcbind reporting unknown because the package is not installed, and the Azure Linux Agent active with waagent pinned as the provisioning agent

Step 6: Check disk, memory and the listening ports

df -h /
free -h
sudo ss -tlnp

Expected output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        10G  1.1G  9.0G  11% /
              total        used        free      shared  buff/cache   available
Mem:           3.9G        169M        3.4G         16M        346M        3.5G
Swap:            0B          0B          0B
State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
LISTEN     0      128          *:22                       *:*                   users:(("sshd",pid=1171,fd=3))
LISTEN     0      100    127.0.0.1:25                       *:*                   users:(("master",pid=1275,fd=13))
LISTEN     0      128         :::22                      :::*                   users:(("sshd",pid=1171,fd=4))
LISTEN     0      100        ::1:25                      :::*                   users:(("master",pid=1275,fd=14))

The root filesystem is a single xfs partition on /dev/sda1, with no LVM. The only externally reachable listener is sshd on port 22. postfix appears bound to 127.0.0.1:25 and ::1:25 — that is the local mail transport, reachable only from the machine itself, not from the network. On CentOS 7 an IPv6 loopback address is printed as ::1:25 rather than [::1]:25, which is easy to mistake for a wildcard bind; it is not one.

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.

Note that ss lives in /usr/sbin, which is on your PATH in an interactive login shell but not in a non-interactive one — so in a script, call it as sudo ss or /usr/sbin/ss.

Step 7: Networking — there are TWO firewalls

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

systemctl is-enabled firewalld
systemctl is-active firewalld
sudo firewall-cmd --list-all

Expected output:

enabled
active
public (default, active)
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

The two layers agree out of the box — the NSG advertises SSH on 22 and the public zone permits the ssh service — which is why port 22 works with no further configuration.

The practical consequence is for 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 it 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. Check the result with sudo firewall-cmd --list-all again. If you would rather manage inbound access solely with the NSG, sudo systemctl disable --now firewalld removes the host layer, but do that deliberately rather than by accident.

Growing the root filesystem

The root filesystem is a single xfs partition on /dev/sda, and growpart and xfs_growfs are preinstalled. If you give the VM a larger OS disk than the image ships with, stop the VM, raise the OS disk size in the Azure Portal (or with az disk update --size-gb), start it again, then grow the partition with sudo growpart /dev/sda 1 followed by sudo xfs_growfs /. Both operate on the mounted filesystem, so no reboot is needed after the resize. If the partition already fills the disk, growpart reports NOCHANGE and exits non zero — that is the expected answer and means there is no unallocated space to claim.

Common Use Cases

  • Running software certified specifically against CentOS 7.2, rather than against the CentOS 7 series
  • Reproducing a legacy environment at the exact point release it was built and signed off on
  • Lift-and-shift of a version pinned on-premises CentOS 7.2 estate into Azure as a migration staging step
  • Compatibility and RPM validation work against the RHEL 7.2 ABI

For any workload that must stay secure long term, migrate to AlmaLinux, Rocky Linux, CentOS Stream, or a current RHEL — CentOS 7 receives no further upstream security updates.

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 by design, so a wrong key cannot fall back to a password prompt.

Package manager cannot reach a mirror

CentOS 7's original mirrors were retired at end-of-life. This image already points at the 7.2.1511 vault, but if you add a third-party .repo that still references mirror.centos.org or mirrorlist.centos.org you will see 404s. Repoint it to https://vault.centos.org/7.2.1511/... or remove it. Confirm no active repository line still points at the retired mirrors:

grep -RE '^[[:space:]]*(baseurl|mirrorlist)[[:space:]]*=.*mirror(list)?\.centos\.org' /etc/yum.repos.d/ \
  || echo "no active repository references the retired mirrors"

Expected output:

no active repository references the retired mirrors

Match only uncommented baseurl= / mirrorlist= lines, as above. A plain grep -R mirror.centos.org also matches commented-out stock lines and the explanatory comment cloudimg writes into CentOS-Base.repo, so it reports hits on a perfectly correct image.

A package I need is not in the repositories

The 7.2.1511 vault is frozen, and it is considerably smaller than the final 7.9 tree — anything added to CentOS 7 after 7.2 shipped is not in it. EPEL-only packages (for example nginx) are not present in base, updates or extras at all. Either install from an external repository you control, or use the CentOS 7 image, which ships the final 7.9.2009 package set.

Note that enabling one of the other point release sections in /etc/yum.repos.d/CentOS-Vault.repo will pull packages from a different release and defeat the point release pin this image exists to provide.

Azure agent not running

Check the agent's status:

systemctl status waagent --no-pager

If it is not running, start and enable it with sudo systemctl enable --now waagent. Do not reinstall it with yum install WALinuxAgent — as described in the out of pin section, no WALinuxAgent package exists in the 7.2.1511 repositories, so that command cannot succeed on this image.

Important Notes

CentOS Linux is free and open source. It is not covered by a single licence: 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> and under /usr/share/licenses/. No subscription, licence key or Red Hat entitlement is required.

CentOS Linux 7 reached end-of-life on 30 June 2024 and receives no further upstream security updates, and 7.2.1511 was superseded upstream by 7.3 through 7.9. This image is patched to the last packages that exist for 7.2.1511, from the frozen CentOS 7.2.1511 vault, and is provided for legacy-migration and version-pinned use. Plan a migration to a supported distribution (AlmaLinux, Rocky Linux, CentOS Stream, or a current RHEL) for any workload that must remain secure.

Every package on this image comes from the frozen CentOS 7.2.1511 vault except one: the Azure Linux Agent, WALinuxAgent-2.2.0-4.el7.noarch, which that point release never shipped and which is therefore sourced from CentOS 7.3.1611 and pinned by checksum. Without it the image could not be deployed on Azure at all. See the out of pin section above, and /usr/share/doc/cloudimg/out-of-pin-packages.txt on the machine itself.

CentOS is a trademark of Red Hat, Inc. The name is used here nominatively, only to identify the distribution this image contains. cloudimg is not affiliated with, endorsed by or sponsored by Red Hat.

Support

For assistance with this image, contact cloudimg support: