Colocation Turnup Checklist for First Rack Power-Up

Start with the first power-on, not the first surprise

A colocation turnup checklist gives you a clear sequence for bringing a new server online in a data center without guessing about power, network, or remote-hands handoffs. Use this guide if you are receiving your own hardware in a colo rack, taking delivery of a new bare metal server, or validating a migration after shipping equipment to the facility. The goal is straightforward: confirm power, reach the console, verify the network path, and leave with a documented rollback plan.

If you are planning the hardware side of a colo build, Hostperl’s dedicated server hosting options are a useful baseline for comparing owned-hardware operations with managed delivery. For teams that want a lower-touch path, self-managed dedicated server service is often a better operational fit than trying to improvise everything on day one.

This tutorial is written for a fresh turnup on openSUSE Leap where the stack is supported, because openSUSE Leap gives you a clean systemd, zypper, firewalld, and AppArmor workflow for a cautious first bring-up. The same operational logic applies to other Linux builds, but the commands below are specific to openSUSE Leap.

What you should have before the rack goes live

Before you touch the server, collect the items below. Missing one of these usually costs time later, often while the facility waits on a remote-hands response.

• Server serial number, asset tag, and rack position
• Management IP or out-of-band console access details
• Public IP, gateway, and DNS records from the provider
• Expected power draw and any PDU port assignment
• Switch port number, VLAN, and any MAC registration requirements
• Support contact for the facility and remote hands

If your migration also involves firmware hygiene or hardware refresh work, Hostperl’s dedicated server firmware lifecycle guide is a useful companion read. It helps you separate a clean hardware lifecycle from a rushed production cutover.

Turn up the server from the console, then confirm the OS

Start from your local computer. Connect with SSH only if the machine already has a reachable management path; otherwise use the facility console, iDRAC, IPMI, Redfish, or similar out-of-band access first.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation example. Replace it with the real public IP assigned to your server or management endpoint.

Once you have a shell on the server, detect the operating system before changing anything.

cat /etc/os-release

Run that on the VPS or server as root. On openSUSE Leap, you should see NAME="openSUSE Leap" and a matching version line. If you do not, stop and confirm you are on the correct machine before continuing.

Bring the machine online safely on openSUSE Leap

On the server as root, update the package metadata and install the tools needed for basic turnup checks. This keeps the first session focused on diagnostics instead of package surprises.

zypper refresh

This refreshes repository metadata. A successful run finishes without repository errors.

zypper install -y sudo vim curl wget firewalld AppArmor-utils iproute2 ethtool lsof chrony

These packages give you an editor, time sync, firewall control, network inspection, and port checks. On a colo server, that is enough to validate most first-day issues.

Check that time is synchronized before you validate logs or certificates.

systemctl enable --now chronyd

This starts the time service and makes it persistent across reboots. You should see an active state.

timedatectl

Look for System clock synchronized: yes. If it says no, wait a few minutes and check NTP reachability with the facility network team.

Create a non-root admin before you lock anything down

Keep your original root session open until the new login works. That avoids a lockout during the first production turnup.

Create a non-root administrator account named deploy on the server as root.

useradd -m -G wheel -s /bin/bash deploy

Set a password only if you need console fallback. For SSH-key-only access, you can lock the password after you confirm the key is working.

passwd deploy

Now prepare SSH access on the server as root.

mkdir -p /home/deploy/.ssh

chmod 700 /home/deploy/.ssh

Copy your public key into place. Replace the key text with your real public key.

cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEexampleKeyHere user@example.com
EOF

chmod 600 /home/deploy/.ssh/authorized_keys

chown -R deploy:deploy /home/deploy/.ssh

Check the account from a second terminal on your local computer.

ssh deploy@203.0.113.10

After login, confirm sudo access.

sudo -v

If that works, you have a safe admin path. Only then should you consider disabling root password login later.

Verify power, storage, and NIC identity before traffic

Colocation problems are often physical, not software-related. Check the hardware identity first so you know what the rack is actually delivering.

hostnamectl

This confirms the machine name and platform details.

lsblk

Look for the expected boot disk, any mirror layout, and the correct capacity. If the disk count does not match your build sheet, stop and request a remote-hands inspection.

lspci | grep -i ethernet

Confirm the NIC model and count. Then check link state.

ip link show

ethtool enp1s0

Replace enp1s0 with your actual interface name. You want Link detected: yes and the negotiated speed that matches the switch port.

Set the firewall before exposing services

Enable the firewall first, then open only what you need. For a fresh colo server, that usually means SSH and a small set of management services.

systemctl enable --now firewalld

Check the active zone.

firewall-cmd --get-active-zones

Allow SSH before you test any rule changes, otherwise you risk locking yourself out on the next reconnect.

firewall-cmd --permanent --add-service=ssh

firewall-cmd --reload

Confirm the rule.

firewall-cmd --list-services

If you plan to publish a service later, add that port before removing any temporary access rule. Safe sequencing matters on remote hardware because there is no local keyboard in most colo racks.

Use the network tools that catch colo mistakes fast

Now validate addressing, routing, and name resolution. These checks catch the most common first-day problems: wrong gateway, bad VLAN handoff, and incomplete provisioning.

ip addr show

Confirm the assigned IP is on the correct interface.

ip route show

You should see the expected default route. If the gateway is missing, the facility handoff is incomplete.

ping -c 4 203.0.113.1

Replace 203.0.113.1 with your real gateway. Successful replies show the layer-3 path is working.

curl -4 ifconfig.me

This confirms outward IPv4 reachability from the server if outbound policy allows it.

For a deeper look at colo network planning, Hostperl’s dedicated server networking checklist explains the upstream details to validate with the carrier before you rack equipment. If you are preparing a full first-day install, the colocation turnup checklist for a clean first day pairs well with this hands-on guide.

Harden SSH after the new login is proven

Only after the deploy login works should you tighten SSH. On openSUSE Leap, edit the OpenSSH server file.

vim /etc/ssh/sshd_config

Add or confirm these lines inside the file:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Save and exit Vim with :wq. Test the config syntax before reloading.

sshd -t

If there is no output, the syntax is valid.

systemctl reload sshd

Open a new local terminal and confirm that key-based login still works for deploy. Keep the original root session open until that check passes.

Document the facility handoff and the rollback path

A turnup is not finished until you know how to reverse it. Record the state below before you close the ticket with the data center team.

• Server hostname and interface names
• Assigned IP, gateway, and DNS servers
• Firewall rules currently in place
• SSH policy and admin account used for login
• Storage layout and any RAID or mirror status
• Remote-hands contact and rack location

If the network becomes unstable, your rollback is simple: keep the working root session open, revert the SSH config from backup if needed, and use the facility console while you investigate the switch port or gateway. On colo hardware, preserving access is more valuable than forcing a failed hardening change through.

Final checks from server and client

Run these checks on the server as the non-root sudo user after you finish the initial hardening.

sudo systemctl status firewalld --no-pager

sudo systemctl status sshd --no-pager

ss -tulpn

Look for SSH listening on port 22 and only the services you meant to publish.

journalctl -u sshd -n 50 --no-pager

This gives you a quick view of login failures or key problems.

From your local computer, test the actual login path again.

ssh deploy@203.0.113.10

You should enter without a password prompt if your key is in place. Then test a basic command.

ssh deploy@203.0.113.10 'hostnamectl; ip route show'

If you are preparing this server for public service, recheck the published port from outside the rack network as well. That catches firewall or carrier filtering that the local console cannot see.

Troubleshooting the most likely first-day failures

1. SSH works on console but not from your laptop.
Diagnostic: journalctl -u sshd -n 50 --no-pager
Expected clue: authentication failures, denied user, or key mismatch.
Fix: confirm ~deploy/.ssh/authorized_keys permissions, then run sshd -t and reload SSH.

2. Link is up, but there is no routed traffic.
Diagnostic: ip route show
Expected clue: missing default route or wrong gateway.
Fix: ask the facility to confirm the handoff, switch port, and VLAN assignment before changing anything else.

3. Firewall rules are correct, but the service is unreachable.
Diagnostic: ss -tulpn
Expected clue: the service is not listening on the expected address or port.
Fix: update the service bind address, then add the port to firewalld and retest.

4. Disk layout does not match the build sheet.
Diagnostic: lsblk
Expected clue: missing mirror disk, wrong device size, or boot order surprise.
Fix: stop the turnup and request a remote-hands check before proceeding to production.

Frequently asked questions

Do I need out-of-band access for every colo turnup?
Yes. If the server is remote, console access is your safety net when network settings are wrong or SSH is not yet trusted.

Should I disable root login on the first day?
Only after you verify a working non-root login and sudo access. Keep the original root session open until then.

Why open SSH before other services?
Because SSH is your recovery path. Open it first, confirm it works, then add application ports later.

What if the IP pings locally but not from outside?
Check the upstream firewall, switch port policy, and carrier handoff with the facility. The problem is often outside the server.

Is openSUSE Leap a good choice for colo hardware?
Yes, if your operations team is comfortable with zypper, systemd, firewalld, and AppArmor. It is a clean fit for careful hardware turnups.