Colocation Remote Hands Handoff on openSUSE Leap

What this handoff covers

A colocation remote hands handoff is the process of preparing your server so a data-center technician can follow your instructions without guessing. In practice, that means clear asset labels, documented cabling, verified console access, a tested boot path, and a simple escalation plan for repairs or reboots.

This tutorial uses openSUSE Leap because it is a valid least-covered OS track for server handoff work. You will build a fresh non-root admin, document the machine for remote hands, confirm network and storage state, and leave behind a recovery path that a technician can follow under time pressure.

If you are placing hardware in a Hostperl colocation environment, this is the kind of preparation that keeps a support ticket from turning into a prolonged outage. For teams that need additional compute capacity or a migration path before moving into colo, dedicated server hosting and Hostperl VPS are useful staging options before the move.

Plan the handoff before anyone touches the rack

Remote hands works best when the technician only has to execute, not interpret. Your job is to remove ambiguity: what the server is, where it sits, what ports it uses, what should happen after a reboot, and who approves any risky action.

Before you start, gather these details in one document:

• Server name, asset tag, and serial number
• Rack unit position and whether the machine is front- or rear-cabled
• Primary and secondary NIC labels
• Expected boot mode: UEFI or legacy BIOS
• Expected storage layout: single disk, RAID, or ZFS
• Out-of-band access method: IPMI, iDRAC, iLO, or crash cart
• Approved actions: power cycle, reseat cable, swap drive, or only visual inspection

Keep that document with your operations notes, not in someone’s inbox. If the handoff is part of a broader migration, the same discipline used in colocation power, cooling, and cross-connect planning will help you avoid avoidable surprises.

Connect to the server and identify the operating system

On your local computer:

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation example. Replace it with the public IP assigned to your server by the colo provider. If your provider uses a non-root initial account, use that account name with the same IP and keep the root session open until the new login is verified.

Once you are on the server, check the OS release:

cat /etc/os-release

On the VPS as root: this confirms you are on openSUSE Leap and lets you use the correct package manager, firewall tools, and service names for the rest of the workflow.

Create a non-root admin for remote operations

Do not hand a colo server over with day-to-day work tied to root. Create a named admin account, give it sudo access, and verify SSH key login before you change anything that could lock you out.

On the VPS as root:

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

Replace deploy only if your team already uses a standard admin account name. The first command creates the user and adds it to the wheel group, which is the usual sudo path on openSUSE Leap. The second command sets a password in case you need a break-glass login during the transition.

Now create the SSH directory and authorized keys file with safe permissions:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /dev/null /home/deploy/.ssh/authorized_keys

Copy your public key into the file, then lock down ownership and test it. If you are pasting manually, use the next command carefully and replace the example key with your actual public key:

echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyValue deploy@example.com' > /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Open a second terminal from your local computer and test the new account before closing the root session:

ssh deploy@203.0.113.10

Then verify sudo works:

sudo -l

You should see that deploy can run privileged commands. If that check fails, do not continue until group membership and key permissions are corrected.

Set the machine identity and keep time in sync

Technicians working remote hands need a hostname that matches the asset record. You also want accurate time for logs, firmware notes, and incident sequencing.

On the VPS as root:

hostnamectl set-hostname server.example.com
timedatectl status

server.example.com is a documentation hostname. Replace it with the real asset name used in your rack and inventory records. The status output should show synchronized time or an active NTP source.

If time sync is not active, enable the default NTP client:

systemctl enable --now chronyd
chronyc tracking

This should report a live time source and bounded offset. If it does not, check upstream network access before blaming the clock.

Update openSUSE Leap and confirm the system is current

Colo handoffs often happen right before or right after a change window. Finish the base OS update before the machine goes into production support.

On the VPS as root:

zypper refresh
zypper update -y

These commands refresh repository metadata and install available security and bug-fix updates. If the kernel changes, plan a controlled reboot after you finish the rest of the preparation and after you have tested out-of-band access.

Confirm the running kernel and package state:

uname -r
zypper se -i kernel-default

If you manage a fleet, this is the right point to schedule the same maintenance pattern for all colo nodes. Hostperl customers who use remote or regional infrastructure often combine this with the practices described in dedicated server disaster recovery for bare metal buyers.

Document storage and network state for the technician

Remote hands needs a concise snapshot of the machine’s current state. Do not rely on memory. Capture the disk layout, mounted filesystems, and active interfaces now, while the machine is healthy.

On the VPS as root:

lsblk -f
findmnt
ip -br link
ip -br addr

Use this output to verify the boot disk, any RAID members, and the interface names. If the machine uses multiple NICs, label them in your operations note so a technician can identify the correct port without guessing.

For routing and connectivity, capture the current table:

ip route show
ping -c 3 203.0.113.1

Replace 203.0.113.1 with your gateway if your colo provider gave you a different one. If ping fails, check cabling and switch port status before touching the OS.

Open the right firewall access for support and management

Colo hardware usually needs SSH and, if available, an out-of-band management interface. openSUSE Leap commonly uses firewalld, so expose only the ports you actually need.

On the VPS as root:

systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
firewall-cmd --list-all

The last command should show SSH allowed. If you also need a management port, add it before you close any temporary access path:

firewall-cmd --permanent --add-port=623/tcp
firewall-cmd --reload

Adjust 623/tcp only if your out-of-band tool uses a different port. Test access from a second terminal before removing any older rule or maintenance exception.

Check AppArmor and boot behavior before a reboot

openSUSE Leap uses AppArmor, so you should confirm profiles are active and the system will come back cleanly after a restart. This matters when remote hands has to press power or verify a POST screen after maintenance.

On the VPS as root:

aa-status
systemctl list-unit-files --type=service | grep enabled

The AppArmor check should show loaded profiles. The service list helps you confirm that core services such as SSH, time sync, and firewall services start at boot.

If you need to inspect startup dependencies for a specific service, use:

systemctl cat sshd
systemctl status sshd --no-pager

This gives you a quick view of the service definition and current health. Keep the root terminal open until the reboot check is complete.

Prepare a clean remote-hands instruction set

Now turn the technical state into a technician-friendly action list. Keep each line short. Use verbs, not stories.

Your instruction sheet should look like this:

• Confirm server tag matches server.example.com
• Check both front power supplies for active LEDs
• Verify the boot disk is the leftmost NVMe drive
• Reseat the primary Ethernet cable if link is down
• Do not change BIOS settings unless support approves it
• After reboot, confirm SSH responds on the documented IP

For more complex recovery paths, especially on hardware you do not physically own, review the workflow in dedicated server IPMI setup for safe remote recovery. The same principle applies here: remote hands is only safe when the operator has a precise sequence to follow.

Test the recovery path before you need it

Do not assume a good SSH session means a good recovery plan. Simulate the most likely failure: a clean reboot, service restart, and login test after boot.

On the VPS as root:

systemctl reboot

After the server returns, reconnect from your local computer:

ssh deploy@203.0.113.10

Then verify the key operational checks:

sudo -l
systemctl status sshd --no-pager
firewall-cmd --list-services
journalctl -u sshd -b --no-pager | tail -n 20

You want a successful sudo listing, an active SSH service, the expected firewall services, and a clean log ending without authentication or binding errors.

Troubleshooting the most likely handoff failures

If the technician says the server is unreachable, start with the basics. Most colo issues are still cable, power, boot, or firewall problems.

No SSH after reboot:

journalctl -u sshd -b --no-pager | tail -n 50
ss -tulpn | grep :22

If sshd is not listening, fix the service first:

systemctl enable --now sshd
systemctl restart sshd

Firewall blocks access:

firewall-cmd --list-all
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

If the wrong source address was allowed earlier, remove it only after the correct rule is in place and tested from a second session.

Bad key permissions:

ls -ld /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

SSH will refuse unsafe ownership or permissions, so this is one of the first places to look.

Unexpected boot or disk issue:

lsblk -f
blkid
systemctl status local-fs.target --no-pager

If the machine boots but does not mount storage correctly, compare the current UUIDs to your handoff notes before asking remote hands to intervene.

Rollback and safe recovery

If anything in the handoff goes wrong, keep the original root session or out-of-band console open while you recover. Re-enable only the access you need, one change at a time.

A simple rollback sequence looks like this:

firewall-cmd --permanent --remove-port=623/tcp
firewall-cmd --reload
systemctl restart sshd

Use the port removal only if you opened it for a temporary support window and no longer need it. If the machine still needs remote recovery, leave approved access in place until the incident is closed.

If the hostname, account, or instructions were wrong, correct them and regenerate the handoff note rather than patching it informally. In colo operations, a clean note is part of the recovery toolset.

FAQ

What should a remote hands handoff include?

It should include the server identity, rack position, approved actions, console or IPMI access details, network labels, and a clear recovery contact. The technician should not need to infer anything.

Why use a non-root account for colo operations?

A named admin account gives you auditability and reduces the risk of accidental lockout. Root can stay available for break-glass recovery, but daily access should go through sudo.

Why is openSUSE Leap a good fit for this workflow?

It supports systemd, firewalld, and AppArmor, which makes the handoff process consistent on a production server. The commands in this guide match that stack.

Should I allow more firewall access for remote hands?

Only if the task requires it. Open the minimum port set first, test from a second terminal, and remove temporary access after the job is done.

What is the most common cause of colo handoff failure?

It is usually incomplete documentation. A mislabeled NIC, missing console detail, or unsafe SSH permission can waste more time than a hardware problem.