CentOS 7.2 Minimal on Azure User Guide

Overview

This guide covers the deployment and configuration of CentOS 7.2 Minimal (CentOS Linux 7.2.1511, with a reduced package set) 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; 7.2.1511 is the point release published in December 2015, corresponding to RHEL 7.2. This image is provided deliberately for legacy-migration workloads: teams moving software that is certified against one specific CentOS 7 / RHEL 7 point release, and needing a clean, hardened, lean base pinned to exactly that release while they re-platform.

This image sits at the intersection of two properties, and you should pick it only if you want both:

• It is pinned to the 7.2.1511 minor release. It is not the terminal CentOS 7.9.2009. Every repository names the frozen 7.2.1511 vault literally, so yum update cannot walk the machine forward onto a later minor. If you want the last CentOS 7 release, use cloudimg's CentOS 7 Minimal image instead.
• It has a reduced package set. The packages an Azure guest cannot use have been removed. If you want the full package set at this same minor, use cloudimg's CentOS 7.2 image instead.

All of these are separate listings and you can run any combination of them.

End-of-life, minor-pin and out-of-pin notice — read this first

There are three disclosures here, and they are independent. All three matter.

1. CentOS Linux 7 reached end-of-life on 30 June 2024. The upstream CentOS Project no longer produces any updates for it, including security updates. Consequently:

• This image is patched only to its capture date, from the frozen CentOS 7.2.1511 vault (vault.centos.org). "Fully patched" therefore means patched to the last packages that will ever exist for this point release.
• After the end-of-life date, no further upstream security updates are published. Over time the 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 use. 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.

2. Pinning to 7.2.1511 also forgoes the packages published in later CentOS 7 minors. This is a deliberate trade of currency for reproducibility, and it is the reason this listing exists:

• CentOS 7.2.1511 was superseded upstream by 7.3.1611 and ultimately by 7.9.2009. A machine pinned here will never receive the packages that only ever shipped in those later minors, even though they exist and even though they predate end-of-life.
• Concretely, this image's enabled repositories offer 11,960 packages, against 16,771 in the terminal 7.9.2009 tree. That gap is real and you should size it against your requirement before choosing this image.
• What you get in exchange is a build target that does not move. If your certified software matrix names RHEL 7.2 specifically, this is the point release it names.

3. Exactly one installed package comes from outside that pin, and it is the Azure provisioning agent. This is unique to the pre-7.3 CentOS 7 point releases and is disclosed in full:

• CentOS 7.2.1511 never shipped a WALinuxAgent package at all — the Azure Linux Agent first appears in CentOS 7.3.1611. Without a provisioning agent an Azure virtual machine cannot receive your SSH key or report ready to the platform, so a strictly pure 7.2.1511 image could not be deployed on Azure at any price.
• This image therefore installs WALinuxAgent-2.2.0-4.el7.noarch from the CentOS 7.3.1611 snapshot, pinned by URL and SHA-256 rather than by a floating package name. It is a generic .el7 noarch build and every one of its dependencies resolves from 7.2.1511 itself.
• It is the only exception. Every other installed package on this image resolves from vault.centos.org/7.2.1511. The image documents this itself at /usr/share/doc/cloudimg/out-of-pin-packages.txt, including the source URL, the SHA-256 and the three commands that reproduce the comparison on your own running machine — see Step 7.

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, pinned package set — out of the box.

Removing packages changes none of the three disclosures. A smaller package set means fewer components that can carry a vulnerability, which is a genuine benefit on an end-of-life platform, but it is not a substitute for migrating.

What makes this the Minimal image

Every number below was measured during the build of this image, on the same kernel, against the same frozen vault snapshot and on the same day, against cloudimg's standard CentOS 7.2 image that this one is cut from. That matters: the comparison is against this image's own standard sibling at the same point release, not against a different CentOS 7 minor. The image ships the comparison itself at /usr/share/cloudimg/centos-7.2-minimal.manifest, so you can verify it on your own running machine rather than taking this page's word for it.

	Standard CentOS 7.2	CentOS 7.2 Minimal	Difference
Installed packages	306	274	32 fewer
Package payload on disk	754 MB	626 MB	128 MB smaller (17%)
Root filesystem used at build time	1,033 MB	~867 MB	~166 MB smaller
Externally reachable TCP listeners	22	22	unchanged
Loopback listeners	mail transport on 25, time on 323	time on 323	mail transport removed

Package payload — the total on-disk size owned by installed packages — is the exact and reproducible measure of the trim, and it is the figure the image's own manifest quotes. Root-filesystem used space also moves with logs, caches and journal state, so treat it as indicative and run df -h / on your own machine for its live value; a freshly deployed virtual machine reports less than the build-time figure above, because the build logs are cleared before capture.

The removals are chosen on one test: can an Azure virtual machine ever use this? Nothing was removed to hit a size target, and nothing the platform needs to boot, network, authenticate, patch or be managed by Azure was touched.

Removed	Why an Azure guest cannot use it
linux-firmware	69 MB of firmware for physical network cards, GPUs, wireless radios and storage controllers. An Azure virtual machine has none of that hardware: its disks and network are the in kernel Hyper V synthetic drivers, which load no firmware at all.
17 × iwl*-firmware	26 MB of Intel wireless network adapter firmware, iwl7265-firmware alone accounting for 8 MB. A Hyper V guest has one synthetic network interface and no wireless radio to load them into.
alsa-firmware, alsa-tools-firmware, alsa-lib	Sound card firmware and the loader tooling for it. There is no audio device on an Azure virtual machine.
ivtv-firmware, aic94xx-firmware	Firmware for a Hauppauge TV capture card and an Adaptec SAS controller respectively.
microcode_ctl	CPU microcode updates. A guest cannot apply microcode; the Azure host does it.
postfix, mariadb-libs	A local mail transport listening on 127.0.0.1:25 and ::1:25, and the MySQL client library it links against. A minimal base ships no mail server, and removing it closes both listeners.
btrfs-progs	btrfs is deprecated and unsupported on CentOS 7, and Azure images use xfs.
tuned	Tuning profile daemon. Azure guests use the platform defaults.
kexec-tools	Crash dump tooling. kdump reserves memory on a small virtual machine for a dump path a marketplace image never uses.
dracut-config-rescue	Rescue boot image generation, which produces a boot entry that cannot start on Azure.
NetworkManager-team, teamd	Network interface teaming. Azure networking is a single synthetic interface and is never a team.

Why the saving here is smaller than on cloudimg's CentOS 7.8 Minimal. The removal policy is identical, and so are the package classes — but linux-firmware was a 69 MB package in 2015 and had grown to 362 MB by the 7.8 release five years later. Same posture, roughly one fifth of the firmware bytes. Four packages the later Minimal images remove (lshw, hwdata, sg3_utils, qemu-guest-agent) are not installed on CentOS 7.2.1511 to begin with, and the image's manifest lists them as such so the two are comparable.

What was deliberately kept. binutils looks like an obvious 20 MB saving and is not removable on CentOS 7: /usr/bin/nm is required by kmod, and the dependency cascade from there reaches openssh and systemd. NetworkManager is retained for a reason specific to this point release — it is a hard dependency of the Azure provisioning agent described above — and ships installed but disabled, with the traditional network service owning eth0, so nothing double-manages the interface. The same applies to wpa_supplicant, cracklib-dicts and the grub2 and dracut tooling. Every candidate in the build was checked with rpm -e --test and against the full yum removal transaction before anything was erased, so this image contains no package removed by force and no broken dependency. The build also proves the check itself still works, by confirming it refuses to remove glibc, systemd and yum before any real removal is attempted.

NFS client support is retained in full. Only the rpcbind portmapper is switched off, and NFSv4 does not use it.

What's included

• CentOS Linux 7.2.1511 (Core), binary compatible with RHEL 7.2, with a reduced package set
• A standard (non-LVM) single-partition xfs root
• Every available 7.2.1511 vault package applied at build time (patched to capture date)
• Repositories repointed to vault.centos.org/7.2.1511 so yum keeps working post-EOL, pinned to this minor
• Exactly one kernel installed, 3.10.0-327.36.3.el7 — the last kernel the 7.2 vault published
• Azure Linux Agent (WALinuxAgent 2.2.0), the single disclosed out-of-pin package, for Azure provisioning
• Chronyd for NTP time synchronisation
• SELinux in enforcing mode
• firewalld enabled and active, allowing SSH
• A package set manifest at /usr/share/cloudimg/centos-7.2-minimal.manifest
• An out-of-pin package disclosure at /usr/share/doc/cloudimg/out-of-pin-packages.txt
• Gen1 Hyper V virtual machine support (BIOS boot)
• 24/7 cloudimg support

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

Security posture

• No baked-in credentials: the root password is locked, and there is no shipped SSH key
• SSH host keys are regenerated on first boot, so no two virtual machines share an identity
• SSH is key only: password authentication and root login are both disabled
• SELinux is enforcing, with the targeted policy
• Exactly one externally reachable TCP listener, sshd on port 22
• The rpcbind RPC listener on port 111 is disabled and masked
• No local mail transport, and therefore no listener on port 25
• Two firewalls are in force: the Azure Network Security Group and the guest's own firewalld
• No swap is baked into the image; Azure manages swap on the ephemeral resource disk

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 Minimal 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-minimal-vm \
  --image cloudimg:centos:centos72min: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-minimal-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.

A note on sudo in the commands below

Several of the tools used in this guide — ss, getenforce, sshd, firewall-cmd — live in /usr/sbin. On CentOS 7, /usr/sbin is added to a non-root user's PATH only by /etc/profile, which a login shell reads but a one-shot remote command such as ssh azureuser@host 'ss -tln' never does. Typed interactively they would work; pasted into a script they would fail with command not found. Every command below is therefore written with sudo, which both fixes the path and is required for the full output anyway. This is CentOS 7 behaviour, not something specific to this image.

Non-interactive sudo works normally on this image. Stock CentOS 7.2 sets Defaults requiretty in /etc/sudoers, which makes ssh azureuser@host 'sudo <command>' fail with "you must have a tty to run sudo"; Red Hat removed that default in CentOS 7.3. This image negates it in /etc/sudoers.d/90-cloudimg-cloud, so it behaves the same way every later CentOS 7 point release does and your remote automation works out of the box.

Step 3: Confirm the release and the minor pin

The pin is part of what you are buying, so check it explicitly. rpm writes the minor as 7-2.1511, so verify the package as well as the release string:

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

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
274

/etc/os-release reports only VERSION_ID="7" — CentOS 7 does not record the minor there, which is exactly why /etc/centos-release and rpm -q centos-release are the authoritative checks. (CentOS 7's /etc/os-release also has no PLATFORM_ID field; that was introduced in the el8 line.)

Step 4: Confirm the minimal package set

This is the other half of what you are choosing, so verify it directly. The manifest is generated during the build and shipped in the image:

cat /usr/share/cloudimg/centos-7.2-minimal.manifest
rpm -q linux-firmware iwl7265-firmware alsa-firmware postfix microcode_ctl || echo "(absent by design in the Minimal image)"
df -h /

Expected output (the manifest is abridged here; the full list of 32 removals prints on your machine):

cloudimg CentOS 7.2 Minimal — package-set manifest
Generated at build time: 2026-09-10T21:13:08Z

Cut from the cloudimg standard 'CentOS 7.2' image (CentOS Linux release 7.2.1511 (Core), kernel 3.10.0-327.36.3.el7.x86_64),
measured on the same kernel and the same day, against the same frozen 7.2.1511 vault.

Standard CentOS 7.2 : 306 packages, 754 MB of package payload
CentOS 7.2 Minimal  : 274 packages, 626 MB of package payload
Delta               : -32 packages, -128 MB of package payload

Package payload is the total on-disk size owned by installed packages, which is the
exact and reproducible measure of the trim. Root-filesystem USED space additionally
moves with logs, caches and journal state, so it is not quoted here as a fixed
figure: it was 1033 MB on the standard image at the moment the baseline
was taken, and this image ships smaller still after its build logs are cleared.
Run 'df -h /' on your own machine for its live value.

Removed (not needed by an Azure guest):
  - linux-firmware
  - iwl7265-firmware
  ...
package linux-firmware is not installed
package iwl7265-firmware is not installed
package alsa-firmware is not installed
package postfix is not installed
package microcode_ctl is not installed
(absent by design in the Minimal image)
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        10G  867M  9.2G   9% /

Your df figures will differ: the root filesystem grows to fill whatever OS disk you asked for, and used space moves with logs and caches. The package counts and the payload figures in the manifest are the fixed, verifiable numbers.

The is not installed lines are the point of the image, not an error. The manifest lists every removal, why it was safe on Azure, which packages were deliberately kept because removing them would break CentOS 7, the four packages that were never present on 7.2.1511 in the first place, and the 7.2.1511 pin.

Step 5: Verify the security posture

Confirm SELinux is enforcing, root is locked, SSH is key only, and that exactly one port is reachable from the network:

sudo getenforce
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo ss -tln | awk '$1=="LISTEN"{print $1, $4}'
sudo ss -uln | awk '$1=="UNCONN"{print $1, $4}'

Expected output:

Enforcing
root LK 2009-12-22 -1 -1 -1 -1 (Alternate authentication scheme in use.)
permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
LISTEN *:22
LISTEN :::22
UNCONN *:68
UNCONN 127.0.0.1:323
UNCONN *:39344
UNCONN :::9891
UNCONN ::1:323

Read the second column, which is the local address the socket is bound to — not the peer address, which is the next column along and would make an outbound connection look like a listener. The only externally reachable TCP listener is sshd on port 22.

The UDP rows deserve a word, because two of them look alarming and are not. Every socket in that list belongs to just two processes, and sudo ss -ulnp will show you so on your own machine: 127.0.0.1:323 and ::1:323 are chrony's time synchronisation control socket, reachable only from the machine itself, and all three of *:68, *:39344 and :::9891 belong to the same dhclient process. CentOS 7.2's DHCP client binds the DHCP port 68 and additionally opens one randomly-chosen high port per address family to receive unicast replies. Those two port numbers are drawn afresh every time dhclient starts, so yours will be different numbers and they will change on every reboot — there is no service behind them. Neither is reachable in any case: firewalld admits only ssh and dhcpv6-client, and the Network Security Group only port 22.

root LK means the root password is locked: there is no password that logs in as root, and PermitRootLogin no refuses the connection before any password would be consulted.

Note what is not in that list: the standard CentOS 7.2 image also binds a local mail transport on 127.0.0.1:25 and ::1:25. This image removed it with the package. ss on CentOS 7.2 prints IPv6 addresses as :::22 and ::1:323 rather than the [::]:22 and [::1]:323 that newer iproute2 releases produce, which is worth knowing if you script against this output.

Step 6: Verify the vault update path and Azure integration

Because CentOS 7 is end-of-life, its original mirrors are gone. This image repoints every repository to the CentOS 7.2.1511 vault, so yum keeps working against the frozen package set for this minor. Confirm that, and that the Azure Linux Agent survived the package trim:

yum repolist enabled
grep '^baseurl' /etc/yum.repos.d/CentOS-Base.repo
sudo yum -q check-update; echo "check-update exit: $?"
systemctl is-active waagent
systemctl is-enabled waagent
rpm -q WALinuxAgent
systemctl is-active chronyd

Expected output:

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
active
enabled
WALinuxAgent-2.2.0-4.el7.noarch
active

Every one of those paths names 7.2.1511 literally rather than the $releasever variable the stock configuration uses. That literal path is the pin: it is what stops yum update from moving the machine to a later minor. Three of the four repositories are enabled; centosplus ships in the file but is disabled, as it is on a stock CentOS 7, which is why repolist totals the other three.

check-update returning 0 means no newer packages exist in this minor's vault: the image is patched to the end of what 7.2.1511 will ever contain. No further security updates will ever be published upstream, for this minor or for CentOS 7 at all. For anything beyond legacy migration, move to a supported distribution.

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. The package trim deliberately protects it: an image that saved space by dropping the Azure Linux Agent would not provision at all. Note there is no cloud-init on this image — the version CentOS shipped in 7.2 predates Azure's current SSH key format and cannot inject your key, so the Azure Linux Agent is the sole provisioning agent here. That is why root growth is a documented manual step rather than automatic; see Step 8.

Step 7: Verify the one out-of-pin package

Disclosure 3 above is the claim that exactly one installed package comes from outside the 7.2.1511 vault. You do not have to take that on trust — the image carries the statement and the method to check it:

cat /usr/share/doc/cloudimg/out-of-pin-packages.txt
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
echo "in-pin: $(wc -l < /tmp/inpin)  installed: $(wc -l < /tmp/inst)"

Expected output:

cloudimg — CentOS 7.2 Minimal (CentOS Linux 7.2.1511, reduced package set) Azure image

This image is CentOS Linux 7.2.1511 from the frozen vault.centos.org/7.2.1511
tree, with a reduced package set, and with EXACTLY ONE exception to the pin:
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

Every other package on this system resolves from vault.centos.org/7.2.1511.
...
WALinuxAgent-2.2.0-4.el7.noarch
in-pin: 9195  installed: 273

The comm -23 line is the whole proof, and it prints exactly one package name. It lists every installed package that yum could not obtain from this machine's own enabled repositories — that is, every package not in the frozen 7.2.1511 vault. One line means one out-of-pin package; the 272 others all resolve from the pin. The two counts on the last line are the size of the in-pin catalogue this machine can see (9,195 distinct package versions) and the number of installed packages compared against it (273; gpg-pubkey entries are excluded because they are RPM database bookkeeping, not real packages).

If you want to confirm the agent is genuinely the file that was pinned rather than some other build, download the URL above and check it: sha256sum of that RPM must equal the SHA-256 in the disclosure, and rpm -q WALinuxAgent must report WALinuxAgent-2.2.0-4.el7.noarch.

Nothing about this is required for the image to work — it is here so that a claim about what the image contains can be independently verified on the running machine rather than believed from a listing page. Note that this section is specific to the CentOS 7.0, 7.1 and 7.2 point releases; from 7.3 onwards the Azure Linux Agent is in the distribution itself, and cloudimg's images for those minors have no out-of-pin package at all.

Step 8: Growing the root filesystem

Because this image has no cloud-init, the root partition is not expanded automatically when you deploy onto an OS disk larger than the image. The tooling to do it is installed; the step is manual and takes a few seconds. If you accepted the default disk size you can skip this entirely.

Check the current size first, and only grow it if df shows the filesystem is smaller than the disk you asked for:

lsblk /dev/sda
df -h /

To grow it, run sudo growpart /dev/sda 1 to expand the partition, then sudo xfs_growfs / to expand the filesystem onto it. Both are online operations on a mounted xfs root, so no reboot and no downtime are involved, and df -h / afterwards should report the full disk. Running them when there is no free space to claim is harmless — growpart simply reports that it cannot be grown.

Step 9: Putting back anything you need

Nothing in this image is removed by force, so anything trimmed reinstalls normally from the vault. If you need a package that is not here, install it the usual way with sudo yum install -y <package>.

Three cases are worth calling out:

• Mail delivery. postfix is not installed, so there is no /usr/sbin/sendmail and cron cannot mail job output to MAILTO. If you need local mail, sudo yum install -y postfix followed by sudo systemctl enable --now postfix restores exactly the standard image's behaviour, including the loopback listener on port 25.
• NFSv3. The NFS client is fully installed, but the rpcbind portmapper is disabled and masked because NFSv4 does not need it. NFSv3 does. Restore it with sudo systemctl unmask rpcbind.socket followed by sudo systemctl enable --now rpcbind.socket.
• Firmware. The firmware packages are the bulk of the saving and are removed because Azure's synthetic devices load no firmware. If you are moving this image to physical hardware or to a hypervisor that passes through real devices, reinstall with sudo yum install -y linux-firmware before you do.

Reinstalling a trimmed package is supported and safe. It simply returns that part of the image to the standard CentOS 7.2 behaviour, and it comes from the same pinned vault, so it cannot break the minor pin — and because it comes from the pin, it cannot change the out-of-pin count either.

Step 10: Networking and the two firewalls

This image has two firewalls, and a new port has to be opened in both. This catches people out, because most cloud images ship with the guest firewall off.

1. The Azure Network Security Group is the outer control plane for inbound and outbound traffic, configured in the Azure Portal or with az network nsg rule create. The image advertises a single inbound port, SSH on 22.
2. firewalld runs inside the guest, enabled and active, in the public zone. It permits ssh and dhcpv6-client and nothing else.

Confirm both the listeners and the guest firewall's current state:

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

Expected output:

State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
LISTEN     0      128          *:22                       *:*                   users:(("sshd",pid=1161,fd=3))
LISTEN     0      128         :::22                      :::*                   users:(("sshd",pid=1161,fd=4))
enabled
active
public (default, active)
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

Your sshd process ID will differ. CentOS 7.2's firewall-cmd --list-all prints a shorter block than later CentOS 7 releases do — it has no target:, icmp-block-inversion:, protocols: or source-ports: lines — so do not be surprised if output you have seen elsewhere has more rows.

To open a service — HTTPS, say — add it in the Network Security Group and in firewalld. On the guest side that is sudo firewall-cmd --permanent --add-service=https followed by sudo firewall-cmd --reload; sudo firewall-cmd --list-all should then show https alongside ssh. Opening it in only one of the two is the usual reason a port appears unreachable when everything else looks correct: if the NSG rule is present but the connection still times out, check firewalld before you look anywhere else.

If your policy is to run without a guest firewall and rely on the NSG alone, sudo systemctl disable --now firewalld does that — but open the port in the NSG first, and be aware you are removing a layer the image ships with.

Common Use Cases

• Running legacy software whose support matrix names RHEL 7.2 or CentOS 7.2 specifically, while you re-platform
• A lean, immovable base for building and validating packages against a fixed point-release ABI, where a smaller image means faster provisioning and fewer components to review
• Reproducing a historical build or a customer-reported defect against exactly the package set that shipped in 7.2.1511, with the least possible surrounding software
• Lift-and-shift of an on-premises CentOS 7.2 estate into Azure as a migration staging step, on a reduced attack surface

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 at any minor.

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.

A command or tool is missing

This is the Minimal image, so some tooling present on the standard CentOS 7.2 image is not installed. Check the manifest to see whether a package was removed deliberately, then reinstall it from the vault if you need it:

awk '/^Removed/,/^$/' /usr/share/cloudimg/centos-7.2-minimal.manifest

Remember also that /usr/sbin is not on a non-root PATH on CentOS 7 in a non-interactive shell — if a command works when you type it but not from a script, try sudo or the full path before concluding it is missing.

Package manager cannot reach a mirror

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

grep -REl '^[[:space:]]*(baseurl|mirrorlist)[[:space:]]*=.*mirror(list)?\.centos\.org' /etc/yum.repos.d/ || echo "no ACTIVE repo line references a retired mirror"

Match active configuration lines only, as above. A plain grep -R mirror.centos.org /etc/yum.repos.d/ also matches the explanatory comment this image writes into CentOS-Base.repo and the commented-out #baseurl= lines that stock CentOS 7 ships in its disabled repository files, so it reports hits on a perfectly correct machine.

Checking the minor pin is still intact

If you suspect something has repointed a repository, list what yum actually resolves rather than reading the files:

yum repolist enabled
sudo yum -q repolist -v 2>/dev/null | awk '/^Repo-baseurl/{print $3}'

Every line must begin https://vault.centos.org/7.2.1511/. The most direct way to break the pin is to enable CentOS-CR.repo, which stock CentOS 7 ships disabled and which carries packages staged for the next point release. Leave it disabled unless you intend to leave 7.2.

Checking the out-of-pin count is still one

If you have installed packages from a third-party repository and want to know what is now outside the pin, re-run the comm -23 comparison from Step 7. Anything you install from the 7.2.1511 vault leaves the count at one; anything from an EPEL-style repository will appear in that list. That is not a fault — it is your machine and your choice — but it is worth knowing that the "one out-of-pin package" property describes the image as shipped, not the machine forever after.

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.

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. Neither pinning to a back-catalogue point release nor removing packages changes any licence term. The Azure Linux Agent is licensed under Apache 2.0 by Microsoft.

CentOS Linux 7 reached end-of-life on 30 June 2024 and receives no further upstream security updates. This image is patched only to its capture date, from the frozen CentOS 7.2.1511 vault, and is provided for legacy-migration use. It is also pinned to the 7.2.1511 minor release, so it forgoes the packages published in CentOS 7.3 through 7.9 — that is a deliberate trade of currency for reproducibility. One package is deliberately outside that pin and disclosed as such: the Azure Linux Agent, WALinuxAgent-2.2.0-4.el7.noarch, sourced from CentOS 7.3.1611 because 7.2.1511 shipped no provisioning agent at all; see /usr/share/doc/cloudimg/out-of-pin-packages.txt on the image. Plan a migration to a supported distribution (AlmaLinux, Rocky Linux, CentOS Stream, or a current RHEL) for any workload that must remain secure.

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:

• Website: www.cloudimg.co.uk
• Product Catalogue: www.cloudimg.co.uk/products
• User Guides: www.cloudimg.co.uk/guides
• SLA: 24 hour response guaranteed