Managed Reseller Hosting Client Handover on AlmaLinux

What this handover solves

Managed reseller hosting client handover is the point where a move stops being a support ticket and starts behaving like a live service. On AlmaLinux, that usually means setting up a new account for an agency or small hosting business, moving client data cleanly, setting access correctly, and proving the server is ready before traffic changes over.

This tutorial is for a fresh AlmaLinux server and a real operations handover. You will create a non-root administrator, harden SSH access, prepare a reseller-style web and account workflow, move the client site data, and verify that the service survives a reboot. If you are choosing a platform for this kind of work, Hostperl VPS hosting is a practical starting point for agencies that need predictable admin access and room to grow.

If the migration needs more headroom, the same workflow also fits a small managed server build. The main differences are support scope, storage, and how much responsibility your team wants to keep in-house.

Before you start: what you need

• An AlmaLinux 9 server with root SSH access.
• A DNS name such as server.example.com pointed at the server later in the process.
• One public IP for examples: 203.0.113.10. Replace it with the real IP from your provider.
• A local SSH client and a second terminal window for testing the new login.
• A site or client account to migrate, plus its files, database, and application credentials.

We will use standard AlmaLinux tools: dnf, systemd, firewalld, and SELinux. That keeps the process aligned with RHEL-compatible hosting builds and avoids brittle one-off changes.

Connect and confirm the operating system

On your local computer, connect to the server with the documentation IP below. Replace 203.0.113.10 with your real server address.

ssh root@203.0.113.10

If your provider gives you a default non-root account instead, use that account for the first login and keep the same IP format. Once you are on the server, confirm the OS before you touch packages or firewall rules.

On the VPS as root, run:

cat /etc/os-release

You should see AlmaLinux 9 or another RHEL-compatible release. If you do not, stop here and adjust the commands for the actual platform.

Create the admin account and keep root open

Do not disable root access yet. Create the new administrative user first, test it in a second terminal, and only then move to lock-down steps. That order prevents lockouts during a live handover.

On the VPS as root, create the user, set its password, and grant wheel access:

useradd -m -G wheel deploy
passwd deploy

Replace deploy only if you already use a different internal admin name. On AlmaLinux, wheel membership is the standard sudo path. Confirm it worked:

id deploy
grep '^%wheel' /etc/sudoers

Now create SSH access for the new user. On your local computer, copy your key, or add it manually if you prefer a controlled migration path.

ssh-copy-id deploy@203.0.113.10

If you are moving keys by hand, create the directory and set permissions on the server:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Open a second terminal now and test the new login before changing any SSH settings.

On your local computer, connect as the non-root admin:

ssh deploy@203.0.113.10

Then verify sudo:

sudo -l
sudo dnf repolist

You should be prompted for your password if sudo requires it, and the package list should display. Keep the original root session open until this works.

Update the server and install the management tools

Managed reseller handovers usually go wrong when the base layer is rushed. Update first, then install the tools you need for account work, web service control, and basic diagnostics.

On the VPS as root, update the system and install the core utilities:

dnf -y update
dnf -y install firewalld policycoreutils-python-utils curl wget unzip tar rsync vim-enhanced chrony

Check that time sync is active, since mail, TLS, logs, and some panel workflows depend on correct time.

systemctl enable --now chronyd
chronyc tracking

A healthy server should report synced time and a stable reference source. If time is wrong, fix that before you migrate anything.

Prepare network access for the handover

Open the firewall before you change SSH policy. That prevents a lockout if you need a new session after hardening.

On the VPS as root, enable firewalld and allow SSH plus web traffic:

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

For a handover that includes DNS cutover or a temporary site preview, allowing HTTP and HTTPS now avoids a second maintenance window later.

Harden SSH after the new login is proven

Only after the deploy account works should you reduce SSH exposure. Back up the current config, then change one setting at a time.

On the VPS as root, back up and edit the SSH daemon config:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
vi /etc/ssh/sshd_config

Add or change these lines:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Save and exit the editor. Then test the configuration before reloading:

sshd -t
systemctl reload sshd

Open a new terminal and confirm that root password login no longer works, while the deploy key still does. If the syntax test fails, restore the backup before reloading:

cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sshd -t
systemctl reload sshd

Move the client site and account data

For a reseller handover, the practical task is usually one site or one account at a time. Move the web root, database dump, and application files together so you can test the full stack, not just the home page.

In this example, the client site lives under /opt/myapp. Create the directory structure and a place for backups:

mkdir -p /opt/myapp/{current,backups,logs}
chown -R deploy:deploy /opt/myapp
chmod 750 /opt/myapp

Copy the site files into place. If you are migrating from another server, use rsync over SSH from the old host or from your workstation.

rsync -aHAX --delete /path/to/client-site/ deploy@203.0.113.10:/opt/myapp/current/

If the site uses MariaDB or MySQL, export the database on the source server and import it on the new one. A simple dump and restore path looks like this:

mysqldump -u root -p clientdb > clientdb.sql
mysql -u root -p clientdb < clientdb.sql

Adjust the database name to your client’s actual application. If the migration includes PostgreSQL instead, use the PostgreSQL-specific restore workflow from PostgreSQL PITR on RHEL 9 for Real Recovery for the recovery side of the process.

Set ownership, permissions, and SELinux context

AlmaLinux often trips people up at the SELinux layer. If you copy files and the site still returns permission errors, check contexts before you chase the application.

On the VPS as root, set ownership and label the content for web access if you are serving it with Apache or Nginx later:

chown -R deploy:deploy /opt/myapp
restorecon -Rv /opt/myapp || true

Use tighter permissions on secrets and environment files:

chmod 640 /opt/myapp/current/.env
chmod 750 /opt/myapp/current

If you need a quick SELinux check, run:

getenforce
ausearch -m avc -ts recent

An enforcing system is normal. AVC denials point to a context problem, a missing boolean, or an app trying to write outside its allowed path.

Bring the service online and test it

Most handovers need a reverse proxy or web server in front of the app. If you already run Nginx or Apache on this server, point it at the new document root or upstream before you switch DNS. For a general migration workflow, keep the application service isolated and test it locally first.

From the server, validate that the app responds on its local port. If the service listens on 8000, test it like this:

curl -I http://127.0.0.1:8000

You should see an HTTP status line, usually 200 OK or a redirect if the app forces HTTPS. If the app is a PHP site, you can also confirm the web root and file ownership with:

ls -lah /opt/myapp/current
find /opt/myapp/current -maxdepth 2 -type f | head

For a deeper web-server clean-up after migration, Hostperl’s Nginx access logs for supportable app hosting guide is useful when you need to separate application bugs from proxy issues.

Add a simple systemd service for persistence

A handover is not finished until the service comes back after reboot. If the client application is custom, create or update a systemd unit so the process starts reliably.

On the VPS as root, create a unit file:

vi /etc/systemd/system/client-app.service

Use this example unit:

[Unit]
Description=Client App
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/opt/myapp/current
ExecStart=/usr/bin/python3 /opt/myapp/current/app.py
Restart=always
RestartSec=3
EnvironmentFile=/opt/myapp/current/.env

[Install]
WantedBy=multi-user.target

Save and exit, then test and enable it:

systemctl daemon-reload
systemctl start client-app
systemctl enable client-app
systemctl status client-app --no-pager

If the unit fails, check logs immediately:

journalctl -u client-app -xe --no-pager

Fix the process command, file path, or permissions before you continue. Do not hide a failed start with a manual process launch.

Validate DNS, external access, and rollback readiness

When the server is ready, point the client domain to the new IP and wait for propagation. If the domain already has a low TTL, this step is usually fast; if not, plan a longer overlap window.

On your local computer, check DNS resolution:

dig +short example.com
curl -I https://example.com

Replace example.com with the client’s real domain. You want the public resolver to return the new address, and the HTTPS request to reach the migrated service.

Keep a rollback plan ready: the old server stays online until the new site passes smoke tests, and the previous DNS target remains available in case the database import or application config needs correction. If the new host fails, switch DNS back, restore the previous dump, and re-test before making another cutover attempt.

Common failure points and fixes

1. SSH lockout after hardening
Diagnostic:

sshd -t
ss -tlnp | grep sshd

If the syntax test fails or SSH is not listening, restore /etc/ssh/sshd_config.bak, then reload sshd.

2. Site loads locally but not from the internet
Diagnostic:

firewall-cmd --list-all
ss -tlnp

If the port is missing from the firewall or the process is not listening, open the needed service and restart the application or reverse proxy.

3. SELinux blocks writes or uploads
Diagnostic:

ausearch -m avc -ts recent
getenforce

If AVC denials appear, fix the file context with restorecon -Rv /opt/myapp or adjust the application path so it writes inside a labeled directory.

4. Database content is missing after migration
Diagnostic:

mysql -u root -p -e 'SHOW DATABASES;'
mysql -u root -p clientdb -e 'SHOW TABLES;'

If the tables are absent, repeat the import from the correct dump file and verify the application’s database credentials in its environment file.

Final verification checklist

Before you mark the handover complete, confirm all of these from both the server and a client machine:

• SSH works with the non-root admin account.
• Root login is disabled if that is part of your policy.
• Firewall rules include SSH, HTTP, and HTTPS.
• The application service is enabled and starts after reboot.
• The site responds over the public domain name.
• Logs are clean enough to support the first 24 hours of traffic.

On the VPS as root, do one last service and reboot test:

systemctl is-enabled client-app
systemctl is-active client-app
reboot

After the server returns, log back in and confirm the service is still active. That final reboot check is what separates a working handover from a temporary demo.

FAQ

Can I use this process for cPanel-based reseller handovers?
Yes, but you should swap the custom systemd and file-placement steps for the account-transfer workflow used by the panel. The SSH hardening, firewall, verification, and rollback sequence still apply.

Why use AlmaLinux for this tutorial?
AlmaLinux matches the RHEL-compatible admin model many hosting teams use for production. It also gives you predictable behavior for dnf, firewalld, and SELinux.

What is the safest order for a live client move?
Create the admin user, verify SSH, update the system, open the firewall, migrate files and data, test locally, then switch DNS. Do not change root access before the new login is proven.

What if the site uses Nginx or Apache already?
Keep the application and OS steps the same, then point the existing web server at the new content and test its config syntax before reload. If you need help with proxy logs, use the Nginx log guide linked above.