Colocation Remote Hands Workflow for FreeBSD VPS Moves

What this colocation remote hands workflow solves

Use this colocation remote hands workflow when you own hardware in a rack, but you cannot be onsite for every cable move, disk swap, reboot, or console check. It is written for FreeBSD systems because that stack often sits behind a provider-controlled switch, PDU, or serial console, and the handoff has to be exact. If you run colocation at Hostperl, this is the kind of runbook that keeps a late-night request from turning into avoidable downtime. For operators still deciding whether owned hardware is the right fit, compare the operational model with dedicated server hosting before you commit to rack space.

The goal is straightforward: get a remote hands technician to make a change safely, then prove the server still boots, answers on the network, and keeps your data intact. You will prepare the request, confirm console access, inventory the machine, make a change in a controlled way, validate from both sides, and keep a rollback path ready.

Scenario and access model

This procedure assumes a FreeBSD host in colocation with physical access handled by remote hands, plus a management workstation outside the data center. It also assumes the server uses standard FreeBSD tools: pkg, service, rc.conf, pf, freebsd-update, and optionally ZFS.

You will use three checkpoints:

• Physical request: what the technician must touch.
• Console verification: what you see on the serial or IPMI console.
• Network verification: what the server and a client both confirm after the work.

For related planning around first-time rack ownership, Hostperl’s colocation rack planning guide for first-time hardware owners is a useful companion. If your change is part of a larger site move, review the colocation data center migration checklist for 2026 before you lift a finger.

1) Connect to the FreeBSD host and confirm the platform

On your local computer, start the SSH session to the server. The address 203.0.113.10 is a documentation example; replace it with the real public IP assigned to your colocated server.

ssh root@203.0.113.10

If your provider requires a non-root initial login, use the same IP with that account instead. Keep the root session open until every new login path works.

On the VPS as root, identify the OS before you do anything else:

freebsd-version

This prints the FreeBSD release, such as 14.2-RELEASE. If this does not return a valid version, stop and confirm the console is actually attached to the expected machine.

2) Create a safer administrative path before physical work

Even on colocated hardware, you should not depend on a single root SSH session. Create a non-root admin, add your key, and test the login before any lockout-prone change.

On the VPS as root, create the admin account and set a password:

adduser deploy

During the prompts, use a strong password, set the login shell to /bin/sh or /usr/local/bin/bash if installed, and add the user to the wheel group when asked. If you prefer a non-interactive approach, you can create the user and then set the password separately:

pw useradd deploy -m -G wheel -s /bin/sh

passwd deploy

Now create the SSH directory and copy your key safely:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

chown deploy:deploy /home/deploy/.ssh/authorized_keys

chmod 600 /home/deploy/.ssh/authorized_keys

If you do not already keep the key in /root/.ssh/authorized_keys, paste the public key into /home/deploy/.ssh/authorized_keys with vi or ee. The file must stay readable only by the account that owns it.

On your local computer, open a second terminal and test the new login:

ssh deploy@203.0.113.10

Replace 203.0.113.10 with your server IP. If the login succeeds, verify privilege escalation from the new account:

su -

or, if sudo is installed and configured on your host:

pkg install -y sudo

Then add a sudoers drop-in:

visudo -f /usr/local/etc/sudoers.d/deploy

Use this content:

deploy ALL=(ALL) ALL

Save and exit, then test:

su - deploy

sudo id

Keep the original root session open until this works. Only then should you consider disabling password login or tightening SSH rules.

3) Inventory the hardware before asking remote hands to touch it

Remote hands works best when the request includes exact identifiers. Capture the storage layout, interfaces, boot device, and service state so the technician does not have to guess.

On the VPS as root, record the visible hardware:

sysctl hw.model hw.ncpu hw.physmem

pciconf -lv | grep -A3 -B1 -i 'ethernet\|storage\|ahci\|nvme'

camcontrol devlist

gpart show

If you use ZFS, check pool status before a technician reboots or reseats anything:

zpool status

zfs list

For networking context, also note the active address and route table:

ifconfig

netstat -rn

This matters because many “remote hands failed” cases are really routing mistakes, wrong switch ports, or a console that was never attached to the right node. If you need a broader network-only workflow later, pair this article with Hostperl’s IPv4 and IPv6 troubleshooting guide.

4) Prepare a precise remote hands request

Your ticket should read like an instruction sheet, not a support chat. Include the machine name, rack row, unit position, exact action, and the validation step you want the technician to wait for.

Use this structure in the request:

Hostname: server.example.com
Location: Rack A, U12
Task: connect spare SATA SSD to bay 2 and confirm link lights
Console: leave system powered off until the console shows FreeBSD loader prompt
Validation: confirm /dev/ada1 appears after boot and report any disk fault LEDs
Rollback: if the new disk is not detected, remove it and return the server to its original state

That format cuts down on back-and-forth and gives support staff a clean checklist. It also helps when the work is part of a migration into Hostperl dedicated servers in London or another regional facility with scheduled access windows.

5) Make the FreeBSD-side change safely

This example uses a controlled disk addition. The same method applies to a RAM upgrade, NIC replacement, cable move, or KVM console check: one change, one request, one verification pass.

On the VPS as root, watch the logs while the technician works:

tail -f /var/log/messages

If the system uses ZFS and you expect a new disk, identify the device names after the technician confirms the cabled drive is present:

camcontrol devlist

sysctl kern.disks

If a new disk should become part of a mirror or backup target, partition it before use. For a GPT-labeled disk, replace ada1 with the actual device discovered above:

gpart create -s gpt ada1

gpart add -t freebsd-zfs ada1

Then confirm the partition exists:

gpart show ada1

If you are instead updating the machine before the technician leaves site, use the FreeBSD patch workflow, not a blind reboot. Fetch and apply system updates first:

freebsd-update fetch install

Then check whether a reboot is needed:

freebsd-version -kru

If kernel or userland versions differ in a way that requires a restart, coordinate that with the remote hands window rather than assuming local access later.

6) Harden the machine after the physical change

Once the hardware change is stable, tighten the server perimeter. FreeBSD commonly uses pf for packet filtering, and colocated hosts should only expose the ports you actually need.

On the VPS as root, create a minimal PF ruleset. Open the file:

ee /etc/pf.conf

Use this example content if you need SSH and a public web service on port 80 and 443. Adjust as needed for your own machine:

ext_if = "em0"
set skip on lo
block all
pass in on $ext_if proto tcp to port { 22, 80, 443 } keep state
pass out all keep state

Save and exit, then check syntax before enabling it:

pfctl -nf /etc/pf.conf

If the syntax check returns nothing, enable PF and start it at boot:

sysrc pf_enable="YES"

service pf start

Confirm the filter is active:

pfctl -sr

For SSH hardening, edit /etc/ssh/sshd_config and keep root access open until you verify the deploy account can still log in. A typical safe baseline is:

ee /etc/ssh/sshd_config

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Test the config before reloading:

sshd -t

If that returns no output, reload SSH:

service sshd reload

Do not remove your existing SSH session until you open a new one and prove the deploy user still works.

7) Make sure the host survives a reboot

Physical changes are only useful if the system comes back cleanly after power loss or maintenance. This is the checkpoint many colocated servers skip.

On the VPS as root, enable the services you touched:

sysrc pf_enable="YES"

sysrc sshd_enable="YES"

If you added custom services, confirm they are enabled with:

service -e

Then verify boot-time identity and network configuration after a controlled reboot:

reboot

After the machine returns, reconnect from your local computer:

ssh deploy@203.0.113.10

Check the system state:

freebsd-version

service sshd status

service pf status

zpool status

If the host uses a fixed address, confirm it still matches what the provider expects:

ifconfig em0

8) Validate from the client side

Server-side checks are not enough. You also need a client test that proves the service is reachable outside the rack.

On your local computer, run a port check and a simple SSH command:

nc -vz 203.0.113.10 22

ssh deploy@203.0.113.10 'hostname; uptime; freebsd-version'

If you exposed web service ports, test them too:

curl -I http://203.0.113.10

You should see a valid TCP connect on port 22 and a normal HTTP response if web traffic is part of the build. If the service fails only after reboot, check the boot logs on the server:

tail -n 100 /var/log/messages

9) Diagnose the most likely failures

SSH works from the console but not from your laptop. Run sockstat -4 -6 -l | grep sshd on the server. If nothing is listening on 22, reload sshd. If it listens only on localhost, fix ListenAddress in /etc/ssh/sshd_config and reload again after sshd -t.

The new disk does not appear. Check camcontrol devlist and gpart show. If the disk is missing entirely, ask remote hands to reseat the drive, confirm backplane LEDs, and verify the correct slot number in the ticket. If the disk appears but has no label, create the GPT and partition again.

PF blocks your SSH session. From the console, run pfctl -d to disable filtering temporarily, correct /etc/pf.conf, test with pfctl -nf /etc/pf.conf, then re-enable PF with service pf start. Never leave the machine unfiltered after the fix.

The machine reboots into a stale kernel or missing mount. Check freebsd-version -kru and mount. If the boot disk changed order, verify the loader configuration and ZFS pool import sequence before you call the change complete.

Rollback and recovery

Remote hands work should always have a clean way back. If a new disk caused problems, remove it physically and restore the original cabling. If a firewall rule blocks the host, disable PF from the console with pfctl -d, fix the ruleset, and only then re-enable it. If an update breaks booting, use the console to enter single-user mode and complete the recovery from there.

For ZFS-based servers, keep a current snapshot before any hardware swap. If the system is healthy enough to do so, create a pre-change snapshot:

zfs snapshot -r zroot@pre-remote-hands

That gives you a clean recovery point for configuration drift, not a substitute for backups. For backup and restore discipline on production hosting, Hostperl’s backup and restore tutorial is a good reminder that recovery testing matters more than storage optimism.

FAQ

When should I use remote hands instead of waiting for my next onsite visit?

Use remote hands when the change affects availability, cooling, power, or boot access, and the cost of delay is higher than the service fee. That usually includes failed disks, console recovery, cable corrections, and emergency power checks.

What should I include in every remote hands ticket?

Always include hostname, rack position, exact task, expected result, rollback instruction, and a contact method for approval. If the technician has to guess, the ticket is not ready.

Can I make firewall changes during a remote hands window?

Yes, but only after you have a second session open and the syntax passes. Keep console access available until you prove the new rules still allow SSH from your location.

What is the safest way to verify a colocated FreeBSD host after maintenance?

Check service status, boot logs, interface state, ZFS health, and a live SSH login from a separate client. Then confirm that the machine still responds after a reboot.

What if the technician finishes the job but the server still fails to boot?

Use the console to inspect the loader, disk order, and mount errors. If the issue is hardware-related, remove the last change first, then work back through the ticket in reverse order.