Colocation Power and Cooling Audit on Ubuntu Server 24.04

Why this audit matters before you move hardware

A colocation power and cooling audit shows whether your server can stay within rack limits without tripping a breaker, overheating, or burning through power headroom. For a Hostperl customer moving owned hardware into colo, that usually means checking PSU draw, fan response, ambient temperature, and the data center’s power allocation before the truck leaves the warehouse. If you are still comparing server placement options, Hostperl dedicated server hosting can be the simpler path when you do not want to manage physical hardware yourself.

This tutorial uses Ubuntu Server 24.04 on the monitoring host and assumes the machine you are auditing is already in the rack or in a pre-rack burn-in room. You will log in, verify the OS, create a non-root administrator, collect power and thermal data, test log visibility, and define a rollback path if the system runs hotter or draws more current than the colo contract allows.

What you need before the first terminal session

• A colo server with IPMI, iDRAC, iLO, or equivalent out-of-band management.
• An Ubuntu Server 24.04 admin VM or jump host on the same management network.
• SSH access from your local computer.
• The colo power allocation from your contract, expressed in amps or watts.
• A remote hands contact, in case you must reseat hardware or reduce load.

Keep your original root session open until the new admin login is confirmed. If you are planning a migration rather than a greenfield rack-in, Hostperl customers often pair this kind of checklist with their migration runbook and, for web workloads, the blue-green release process so the hardware change does not become an application outage.

Connect safely and confirm the platform

On your local computer, open your first SSH session to the Ubuntu admin host.

ssh root@203.0.113.10

Use 203.0.113.10 only as documentation. Replace it with the public IP assigned to your server.

If your provider gave you a default non-root account, use that instead:

ssh deploy@203.0.113.10

After you log in, confirm the platform before making any OS-specific changes.

On the VPS as root, run:

cat /etc/os-release

You should see Ubuntu 24.04 information. That matters because the package names, firewall steps, and systemd service handling below are written for Ubuntu Server.

Create a non-root admin and keep the root session open

The monitoring host should not stay on root SSH permanently. Create a sudo user, load your SSH key, and test the new login from a second terminal before you lock anything down.

On the VPS as root, create the account and add it to the sudo group:

adduser deploy
usermod -aG sudo deploy

This creates the deploy administrator. If you choose another name, use it consistently in the rest of the commands.

Now prepare SSH access:

sudo -iu deploy
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat > ~/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyForDocumentationOnlyReplaceIt
EOF
chmod 600 ~/.ssh/authorized_keys
exit

Replace the sample public key with your real key. The permissions must stay tight, or SSH will ignore the file.

Test the new login in a second terminal before you disable root SSH.

On your local computer, open another terminal and run:

ssh deploy@203.0.113.10

Then confirm sudo works:

sudo -v

If this succeeds, keep both sessions open. Only after the new login works should you consider SSH hardening.

Install the tools for thermal and power visibility

Ubuntu Server does not ship with the hardware reporting tools you need for a serious colo audit. Install the monitoring utilities and confirm they are present.

On the VPS as the non-root sudo user, run:

sudo apt update
sudo apt install -y lm-sensors ipmitool htop smartmontools pciutils ethtool

lm-sensors reads CPU and board temperatures, ipmitool pulls out-of-band power and sensor data, and smartmontools checks drive health.

Detect sensors and verify the toolchain:

sudo sensors-detect --auto
sensors
ipmitool sensor

If sensors shows temperatures and fan readings, you are ready to collect baseline data. If ipmitool cannot connect, the BMC may need network access or credentials corrected.

Measure current draw and thermal headroom

This is the core of the colocation power and cooling audit. You are not trying to guess capacity from spec sheets. You are measuring what the machine actually does under load.

On the VPS as the non-root sudo user, capture the idle state first:

date
uptime
sensors
sudo ipmitool dcmi power reading

Record the wattage and fan speeds in your change log. A healthy colocated server usually shows stable fan values at idle and a power reading well below the contracted ceiling.

Now create a controlled load for a short burn-in window:

sudo apt install -y stress-ng
stress-ng --cpu 4 --vm 2 --vm-bytes 512M --timeout 10m --metrics-brief

While the test runs, watch temperatures and power:

watch -n 10 'sensors; echo; sudo ipmitool dcmi power reading'

On a properly cooled rack, temperatures should rise and then stabilize. If CPU or board sensors keep climbing without leveling off, your airflow path is poor or the data center room is too warm for this hardware profile.

Check NIC health, link speed, and port stability

Colocation problems often look like power issues but start with network instability. A loose cable or negotiated half-duplex link can make a healthy server look unreliable.

On the VPS as the non-root sudo user, inspect the interface:

ip addr show
sudo ethtool enp1s0

Replace enp1s0 with your actual interface name from ip addr. You want to see the expected speed and Link detected: yes. If the speed is lower than the switch port should support, ask remote hands to check the cable and transceiver.

For latency and loss checks across the colo handoff, run a short ping test to your upstream gateway or management host:

ping -c 20 203.0.113.1

Swap in your real gateway or router address. Packet loss or large jitter during this test can indicate physical layer trouble, not application trouble.

Harden access without locking yourself out

Once the audit host is stable, reduce the attack surface. Do this only after the new sudo login is verified.

On the VPS as the non-root sudo user, enable UFW and allow SSH before any restrictive rule changes:

sudo ufw allow OpenSSH
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Adjust the management subnet to match your real admin network. Keep the temporary broad SSH allowance until you confirm the narrow rule works from your office or jump host.

If you want to reduce password risk, edit SSH carefully:

sudo nano /etc/ssh/sshd_config

Set these lines:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Save and exit, then test syntax before restart:

sudo sshd -t
sudo systemctl restart ssh
sudo systemctl status ssh --no-pager

If sshd -t returns nothing, the config is valid. If it reports an error, fix the file before restarting or you may lock yourself out.

Keep the audit visible after reboot

Some teams do one power test, then forget to make it repeatable. That is how colo surprises show up during the next maintenance window. Create a small log capture so you can review temperatures after boot and after load spikes.

On the VPS as the non-root sudo user, create a systemd timer-friendly log file target:

sudo install -d -m 0755 /opt/myapp
sudo tee /usr/local/bin/colo-audit-snapshot.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
{
  echo "=== $(date -Is) ==="
  sensors || true
  ipmitool dcmi power reading || true
  uptime
} >> /var/log/colo-audit.log
EOF
sudo chmod 0755 /usr/local/bin/colo-audit-snapshot.sh

Now create a timer:

sudo tee /etc/systemd/system/colo-audit.service > /dev/null <<'EOF'
[Unit]
Description=Colocation audit snapshot

[Service]
Type=oneshot
ExecStart=/usr/local/bin/colo-audit-snapshot.sh
EOF
sudo tee /etc/systemd/system/colo-audit.timer > /dev/null <<'EOF'
[Unit]
Description=Run colocation audit snapshot hourly

[Timer]
OnBootSec=5m
OnUnitActiveSec=1h
Persistent=true

[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now colo-audit.timer
systemctl list-timers --all | grep colo-audit

You should see the timer scheduled and active. This gives you a lightweight record of temperatures and power after reboots, which is useful when a colo ticket starts with “the server feels hot.”

Rollback and recovery if the machine runs hot

If the audit shows unsafe temperatures, do not keep pushing load. Roll back the test state first, then decide whether the issue is cooling, mounting, or power allocation.

On the VPS as the non-root sudo user, stop the stress test if it is still running:

sudo pkill stress-ng || true
sudo systemctl stop colo-audit.timer
sudo ufw delete allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw status numbered

Now collect evidence for remote hands or your colo provider: screenshot the sensor output, note the rack unit, and record the exact power reading. If fans are at maximum and the intake remains hot, request airflow inspection, blanking panels, cable cleanup, or a higher power envelope.

Verification from the server and your client laptop

Do not close the ticket until you can prove the audit completed and the system stayed reachable.

On the VPS as the non-root sudo user, run:

systemctl status colo-audit.timer --no-pager
journalctl -u colo-audit.service -n 20 --no-pager
sudo ipmitool dcmi power reading
sensors

The timer should be active, the journal should show a recent snapshot, and the power reading should be within contract. Reboot once if you need persistence proof:

sudo reboot

After the server comes back, reconnect and confirm the timer and SSH still work. From your local computer, run:

ssh deploy@203.0.113.10
sudo systemctl is-active ssh
sudo systemctl is-active colo-audit.timer

If both services are active, the audit survived reboot and your access model is still intact.

Troubleshooting the most likely failures

1. ipmitool reports a connection or auth error.
Diagnostic command:

ipmitool -I lanplus -H 203.0.113.10 -U admin sensor

Expected clue: a timeout or authentication failure. Next action: verify the BMC IP, credentials, and management VLAN with your colo or remote hands team.

2. Temperatures climb past safe limits during the load test.
Diagnostic command:

watch -n 5 'sensors; echo; sudo ipmitool dcmi power reading'

Expected clue: rising temperatures that do not stabilize. Next action: stop the load, request airflow checks, and compare intake versus exhaust temperatures. If needed, move the server to a lower-density cabinet or reduce component count.

3. SSH hardening breaks login.
Diagnostic command:

sudo sshd -t

Expected clue: syntax output with a file and line number. Next action: fix /etc/ssh/sshd_config, then run sudo systemctl restart ssh again only after syntax is clean.

FAQ

How much headroom should I leave in colocation power planning?

Leave practical headroom above your measured peak, not just the CPU TDP on paper. Fan spikes, drive spin-up, and PSU efficiency losses all affect real draw.

Can I audit cooling without IPMI?

Yes, but you lose the cleanest power reading. You can still use sensors, SMART data, and rack temperature measurements, though you may need remote hands for cross-checks.

What if my server passes idle checks but fails under load?

That usually points to airflow, insufficient power margin, or a failing component. Keep the stress test short, capture the readings, and stop before the machine overheats.

Should I keep SSH root login enabled in colo?

No. Use a non-root sudo account and key-based access, then disable root SSH only after you have verified the new login path.

When should I ask for remote hands?

Ask as soon as you suspect a physical issue you cannot prove from the management shell: loose cabling, bad airflow, damaged rails, missing blanking panels, or a BMC that will not answer.