https://adminsforum.com/ Thu, 15 Oct 2026 05:18:14 +0000 MyBB https://adminsforum.com/Thread-news-ubuntu-26-10-security-changes-what-vps-and-hosting-admins-should-test Thu, 08 Oct 2026 03:20:04 +0800 DEV]]> https://adminsforum.com/Thread-news-ubuntu-26-10-security-changes-what-vps-and-hosting-admins-should-test Canonical published its Ubuntu 26.10 security overview on 6 October 2026. For hosting administrators, the useful question is which changes could affect boot recovery, automation and encrypted connections—not simply whether the release has newer packages.

Checked 7 October 2026. This is a pre-release planning article: the official roadmap schedules the final release for 15 October. It is an interim release, with support through July 2027. Check final release notes and your panel's supported OS list before planning a production move.

What matters to a server operator
Boot compatibility: Canonical describes a smaller signed GRUB build. Customized /boot layouts need review, particularly with Secure Boot. This does not mean those filesystems disappear from a running Linux system.

Automation compatibility: The remaining cp, mv and rm defaults move to Rust-based core utilities. Test scripts that depend on exact command behavior, especially backup, deployment and cleanup jobs.

TLS and SSH compatibility: The overview lists OpenSSL 4.0 and OpenSSH 10.5. Legacy OpenSSL ENGINE integrations need a provider migration path. curl gains revocation checking through upki. Applications using certificates or hardware-backed keys deserve specific tests.

Confinement: dbus-broker replaces dbus-daemon while retaining AppArmor mediation. Check application behavior rather than removing confinement when an unfamiliar error appears.

Read Canonical's full security overview for the exact scope and qualifications.

A practical staging checklist
These are suggested operational checks, not a claim that every panel supports 26.10.

1. Record your current OS, panel version, web server, PHP versions and database version. Get explicit compatibility guidance from the panel vendor. “Ubuntu supported” is not enough to establish support for this specific release.

2. Create an isolated test server with representative configuration and sanitized data. Stop it from sending real customer mail, running payment jobs or connecting to production services.

3. Capture a baseline. These read-only commands help on a typical Ubuntu server:

Code:Copy

cat /etc/os-release uname -r findmnt -T /boot openssl version ssh -V systemctl --failed

findmnt reports the filesystem containing /boot; it does not prove Secure Boot compatibility. Version commands describe the invoked tools, not every library used by every application. Avoid sharing configuration dumps containing secrets.

4. Test an ordinary website request, PHP execution, database access, outbound HTTPS calls, scheduled tasks and certificate renewal through the existing manager. Review failures individually. Do not work around certificate errors by disabling verification.

5. Keep provider-console access available. Prove a new SSH login, required sudo access and service recovery after a staging reboot. Run backup and restore tests against isolated destinations.

When should a production VPS move?
My operational recommendation is to keep a supported, working installation patched while you evaluate the new release. Move when a documented benefit outweighs the compatibility and maintenance cost, and the panel vendor supports the target.

Before any real migration, establish a verified recovery copy and maintenance window. Define success checks and how you will preserve new writes if a rollback becomes necessary. This article intentionally provides no production upgrade command: the correct path depends on the starting release, provider image and managed stack.

Discussion: Which hosting panel and OS do you run? If you test 26.10 in staging, share a reproducible compatibility result and sanitized error—not credentials or customer data.

Official sources: Canonical security report, 6 October 2026; official release roadmap and dates; Secure Boot design discussion.]]> Canonical published its Ubuntu 26.10 security overview on 6 October 2026. For hosting administrators, the useful question is which changes could affect boot recovery, automation and encrypted connections—not simply whether the release has newer packages.

Checked 7 October 2026. This is a pre-release planning article: the official roadmap schedules the final release for 15 October. It is an interim release, with support through July 2027. Check final release notes and your panel's supported OS list before planning a production move.

What matters to a server operator
Boot compatibility: Canonical describes a smaller signed GRUB build. Customized /boot layouts need review, particularly with Secure Boot. This does not mean those filesystems disappear from a running Linux system.

Automation compatibility: The remaining cp, mv and rm defaults move to Rust-based core utilities. Test scripts that depend on exact command behavior, especially backup, deployment and cleanup jobs.

TLS and SSH compatibility: The overview lists OpenSSL 4.0 and OpenSSH 10.5. Legacy OpenSSL ENGINE integrations need a provider migration path. curl gains revocation checking through upki. Applications using certificates or hardware-backed keys deserve specific tests.

Confinement: dbus-broker replaces dbus-daemon while retaining AppArmor mediation. Check application behavior rather than removing confinement when an unfamiliar error appears.

Read Canonical's full security overview for the exact scope and qualifications.

A practical staging checklist
These are suggested operational checks, not a claim that every panel supports 26.10.

1. Record your current OS, panel version, web server, PHP versions and database version. Get explicit compatibility guidance from the panel vendor. “Ubuntu supported” is not enough to establish support for this specific release.

2. Create an isolated test server with representative configuration and sanitized data. Stop it from sending real customer mail, running payment jobs or connecting to production services.

3. Capture a baseline. These read-only commands help on a typical Ubuntu server:

Code:Copy

cat /etc/os-release uname -r findmnt -T /boot openssl version ssh -V systemctl --failed

findmnt reports the filesystem containing /boot; it does not prove Secure Boot compatibility. Version commands describe the invoked tools, not every library used by every application. Avoid sharing configuration dumps containing secrets.

4. Test an ordinary website request, PHP execution, database access, outbound HTTPS calls, scheduled tasks and certificate renewal through the existing manager. Review failures individually. Do not work around certificate errors by disabling verification.

5. Keep provider-console access available. Prove a new SSH login, required sudo access and service recovery after a staging reboot. Run backup and restore tests against isolated destinations.

When should a production VPS move?
My operational recommendation is to keep a supported, working installation patched while you evaluate the new release. Move when a documented benefit outweighs the compatibility and maintenance cost, and the panel vendor supports the target.

Before any real migration, establish a verified recovery copy and maintenance window. Define success checks and how you will preserve new writes if a rollback becomes necessary. This article intentionally provides no production upgrade command: the correct path depends on the starting release, provider image and managed stack.

Discussion: Which hosting panel and OS do you run? If you test 26.10 in staging, share a reproducible compatibility result and sanitized error—not credentials or customer data.

Official sources: Canonical security report, 6 October 2026; official release roadmap and dates; Secure Boot design discussion.]]> https://adminsforum.com/Thread-guide-linux-disk-full-diagnose-space-and-inodes-before-deleting-files Thu, 08 Oct 2026 03:07:34 +0800 DEV]]> https://adminsforum.com/Thread-guide-linux-disk-full-diagnose-space-and-inodes-before-deleting-files “No space left on device” can mean exhausted bytes, inodes, quota or a different filesystem than the one you checked. Diagnose the constraint before deleting logs or backups.

1. Find the affected mount
These read-only commands target GNU/Linux:

Code:Copy

df -hT df -i findmnt -T /var/log

Replace /var/log with the directory where writes fail. A separate /var, container layer or network mount may be full while / has space. Check the application user's quota if the filesystem has room. Reserved blocks can make space unavailable to an ordinary service account.

2. Measure usage without crossing mounts

Code:Copy

sudo du -xhd1 /var sudo du -xhd1 /var/log sudo journalctl --disk-usage

The -x option keeps the walk on one filesystem; -d1 summarizes one directory level. On a busy host, scans can cause I/O, so inspect one plausible directory at a time. Check application uploads, backup retention, caches and database logs. Hidden directories count too; a shell wildcard can miss them.

3. Explain a df/du mismatch
A removed file can still occupy space while a process holds it open. If lsof is installed:

Code:Copy

sudo lsof +L1

Inspect the process and mount associated with large deleted files. Arrange a supported log reopen or targeted service restart after assessing impact. Do not kill processes blindly. Other differences include snapshots, filesystem metadata, sparse files, inaccessible directories and files hidden beneath mount points.

4. Reclaim the right data
Preserve incident evidence and verified backups first. Use the application's supported cache/log retention mechanism. Preview package or container cleanup and understand what it removes; Docker volumes can contain the only database copy. Never delete active database files or blindly run broad recursive removal commands.

If inodes are exhausted, investigate directories containing very many tiny files and fix their retention. If bytes are exhausted, identify the largest growing sources. Deleting one old archive without fixing an endless log loop buys only temporary relief. Avoid manually truncating a log when the application expects a different rotation process.

5. Validate recovery and prevent recurrence
Repeat df -h and df -i for the affected path, confirm the service can write, and check for database/application errors caused by the outage. Alert on both byte and inode availability with enough lead time. Budget local backup staging and update space. Track growth rather than relying on a single percentage threshold.

When asking for help: Share the failing path, filesystem type and sanitized df/du summaries. Avoid exposing customer filenames or secrets. If a filesystem turned read-only, inspect kernel/storage errors; deleting files is not the appropriate fix.

Reference: df manual and your installed man du/man lsof documentation.
aaPanel lab walkthrough: storage checks and a deleted-open-file demonstration
Verified 14 October 2026 on aaPanel Free 8.0.7 and Ubuntu 22.04.5. This extends the Linux procedure above with original lab measurements. The server had available space; we did not fill its disk or reproduce a disk-full outage.

A. Start from the path that could not be written
Check aaPanel Home's disk indicator as an initial clue, then use a private SSH or panel Terminal session to inspect the actual application, database, backup or temporary path. A headline root-disk percentage does not identify every separate filesystem.
For a website issue, match the failed operation with the access/error/application logs. Distinguish an exhausted resource from permission denial or a filesystem that became read-only before choosing a repair.

B. Check bytes and inodes for the relevant paths
Our read-only checks were:

Code:Copy

df -h / /www /tmp df -i / /www /tmp

All three paths belonged to /dev/vda2, mounted at /. They therefore shared capacity; their three available values must not be added together.
The rounded disk result was 39G total, 11G used, 26G available and 30% usage. The inode snapshot showed 2,555,904 total objects, 263,510 used and 2,292,394 available, or 11% usage. Neither resource was exhausted in this lab.
For a real error, substitute the exact paths used by the failed write. Many tiny files can exhaust inodes while bytes remain, whereas a separate temporary volume may run out without filling the website's volume.

C. Measure relevant directory growth

Code:Copy

du -x -h --max-depth=1 /www/backup /www/wwwlogs

The scoped lab results were approximately 287M for backups and 9.8M for logs. They do not explain every byte on /. We removed nothing from these directories because available capacity did not justify speculative cleanup.
Display depth limits the detail shown, not all traversal work. Large scans can cause I/O, so narrow the scope and compare growth over time. Determine which application owns the data and what its retention policy permits before removing it.


AdminsForum formatted transcript of the original checks, not a panel screenshot.

D. Why deleting a filename may not reclaim storage
Our isolated test wrote and flushed a 1MiB disposable file, unlinked its path while holding the descriptor open, and inspected only the test process. The path no longer existed, the link count was zero, and the descriptor still showed 1,048,576 allocated bytes. lsof reported the held object as (deleted).
The test process then closed the descriptor and exited, leaving no temporary data file. This demonstrates open-file behavior; it does not claim a large measured df/du discrepancy or a specific amount recoverable from a real service.
For a real investigation:

Code:Copy

lsof -nP +L1

Inspect the relevant process and filesystem privately. The -nP options avoid resolving names/port names; +L1 selects unlinked open files. Permissions and namespaces affect visibility. Use the owning service's supported rotation/reopen or carefully planned graceful restart process rather than blindly killing it or truncating a live descriptor through /proc.

E. Recover with a deliberate retention plan
Preserve verified independent backups and useful incident evidence. Use supported log rotation, cache expiry and application maintenance tools. Identify the job creating excessive data and address it so a cleanup does not immediately get undone.
Never manually remove live database tablespaces or transaction/replication files. Avoid deleting all session files or Docker volumes as a generic cleanup. A quota, read-only filesystem or application storage limit can need a different solution even when df shows room.
After an authorized cleanup or supported expansion, repeat the checks on the same affected path, confirm a small legitimate application write and inspect fresh errors. Capacity/inode trends and growth alerts provide more useful warning than a single percentage snapshot.

Additional references: GNU df, GNU du and lsof manual.

  storage-diagnostics-20261014.jpg (Size: 135.33 KB / Downloads: 4) ]]> “No space left on device” can mean exhausted bytes, inodes, quota or a different filesystem than the one you checked. Diagnose the constraint before deleting logs or backups.

1. Find the affected mount
These read-only commands target GNU/Linux:

Code:Copy

df -hT df -i findmnt -T /var/log

Replace /var/log with the directory where writes fail. A separate /var, container layer or network mount may be full while / has space. Check the application user's quota if the filesystem has room. Reserved blocks can make space unavailable to an ordinary service account.

2. Measure usage without crossing mounts

Code:Copy

sudo du -xhd1 /var sudo du -xhd1 /var/log sudo journalctl --disk-usage

The -x option keeps the walk on one filesystem; -d1 summarizes one directory level. On a busy host, scans can cause I/O, so inspect one plausible directory at a time. Check application uploads, backup retention, caches and database logs. Hidden directories count too; a shell wildcard can miss them.

3. Explain a df/du mismatch
A removed file can still occupy space while a process holds it open. If lsof is installed:

Code:Copy

sudo lsof +L1

Inspect the process and mount associated with large deleted files. Arrange a supported log reopen or targeted service restart after assessing impact. Do not kill processes blindly. Other differences include snapshots, filesystem metadata, sparse files, inaccessible directories and files hidden beneath mount points.

4. Reclaim the right data
Preserve incident evidence and verified backups first. Use the application's supported cache/log retention mechanism. Preview package or container cleanup and understand what it removes; Docker volumes can contain the only database copy. Never delete active database files or blindly run broad recursive removal commands.

If inodes are exhausted, investigate directories containing very many tiny files and fix their retention. If bytes are exhausted, identify the largest growing sources. Deleting one old archive without fixing an endless log loop buys only temporary relief. Avoid manually truncating a log when the application expects a different rotation process.

5. Validate recovery and prevent recurrence
Repeat df -h and df -i for the affected path, confirm the service can write, and check for database/application errors caused by the outage. Alert on both byte and inode availability with enough lead time. Budget local backup staging and update space. Track growth rather than relying on a single percentage threshold.

When asking for help: Share the failing path, filesystem type and sanitized df/du summaries. Avoid exposing customer filenames or secrets. If a filesystem turned read-only, inspect kernel/storage errors; deleting files is not the appropriate fix.

Reference: df manual and your installed man du/man lsof documentation.
aaPanel lab walkthrough: storage checks and a deleted-open-file demonstration
Verified 14 October 2026 on aaPanel Free 8.0.7 and Ubuntu 22.04.5. This extends the Linux procedure above with original lab measurements. The server had available space; we did not fill its disk or reproduce a disk-full outage.

A. Start from the path that could not be written
Check aaPanel Home's disk indicator as an initial clue, then use a private SSH or panel Terminal session to inspect the actual application, database, backup or temporary path. A headline root-disk percentage does not identify every separate filesystem.
For a website issue, match the failed operation with the access/error/application logs. Distinguish an exhausted resource from permission denial or a filesystem that became read-only before choosing a repair.

B. Check bytes and inodes for the relevant paths
Our read-only checks were:

Code:Copy

df -h / /www /tmp df -i / /www /tmp

All three paths belonged to /dev/vda2, mounted at /. They therefore shared capacity; their three available values must not be added together.
The rounded disk result was 39G total, 11G used, 26G available and 30% usage. The inode snapshot showed 2,555,904 total objects, 263,510 used and 2,292,394 available, or 11% usage. Neither resource was exhausted in this lab.
For a real error, substitute the exact paths used by the failed write. Many tiny files can exhaust inodes while bytes remain, whereas a separate temporary volume may run out without filling the website's volume.

C. Measure relevant directory growth

Code:Copy

du -x -h --max-depth=1 /www/backup /www/wwwlogs

The scoped lab results were approximately 287M for backups and 9.8M for logs. They do not explain every byte on /. We removed nothing from these directories because available capacity did not justify speculative cleanup.
Display depth limits the detail shown, not all traversal work. Large scans can cause I/O, so narrow the scope and compare growth over time. Determine which application owns the data and what its retention policy permits before removing it.


AdminsForum formatted transcript of the original checks, not a panel screenshot.

D. Why deleting a filename may not reclaim storage
Our isolated test wrote and flushed a 1MiB disposable file, unlinked its path while holding the descriptor open, and inspected only the test process. The path no longer existed, the link count was zero, and the descriptor still showed 1,048,576 allocated bytes. lsof reported the held object as (deleted).
The test process then closed the descriptor and exited, leaving no temporary data file. This demonstrates open-file behavior; it does not claim a large measured df/du discrepancy or a specific amount recoverable from a real service.
For a real investigation:

Code:Copy

lsof -nP +L1

Inspect the relevant process and filesystem privately. The -nP options avoid resolving names/port names; +L1 selects unlinked open files. Permissions and namespaces affect visibility. Use the owning service's supported rotation/reopen or carefully planned graceful restart process rather than blindly killing it or truncating a live descriptor through /proc.

E. Recover with a deliberate retention plan
Preserve verified independent backups and useful incident evidence. Use supported log rotation, cache expiry and application maintenance tools. Identify the job creating excessive data and address it so a cleanup does not immediately get undone.
Never manually remove live database tablespaces or transaction/replication files. Avoid deleting all session files or Docker volumes as a generic cleanup. A quota, read-only filesystem or application storage limit can need a different solution even when df shows room.
After an authorized cleanup or supported expansion, repeat the checks on the same affected path, confirm a small legitimate application write and inspect fresh errors. Capacity/inode trends and growth alerts provide more useful warning than a single percentage snapshot.

Additional references: GNU df, GNU du and lsof manual.

  storage-diagnostics-20261014.jpg (Size: 135.33 KB / Downloads: 4) ]]> https://adminsforum.com/Thread-guide-15-things-to-do-after-buying-a-new-vps Thu, 08 Oct 2026 01:42:35 +0800 DEV]]> https://adminsforum.com/Thread-guide-15-things-to-do-after-buying-a-new-vps What should you do first after buying a VPS?
Confirm recovery-console access, update the OS, create a named administrator with SSH keys, allow only the required ports, and set up off-site backups. Verify a fresh login and a restore before installing a hosting panel or moving a live website.

Review status: Documentation reviewed on 9 October 2026. Fresh-VPS walkthrough testing and original screenshots are pending; no OS or panel version is claimed as hands-on tested. Record your exact release with cat /etc/os-release before using these examples.

Scope: Commands below target a fresh, systemd-based Ubuntu/Debian VPS. AlmaLinux/Rocky use different package and firewall tools; do not paste these commands there. Use a supported OS release. If a control panel is already installed, follow its supported update, firewall and backup procedures.

Before you start: Keep your current SSH session open and confirm the provider's web/serial console works. Replace YOUR_SERVER_IP and adminuser with your own values. Run sudo commands as a sudo-capable user; on an initial root session, omit sudo. Never paste passwords, private SSH keys or access tokens into a forum post.

1. Check what you actually bought
Verify the IP addresses, RAM, storage, bandwidth allowance, virtualization type, renewal cost and backup options in the provider dashboard. Check that the guest matches the plan:

Code:Copy

cat /etc/os-release uname -r nproc free -h lsblk df -hT

A disk advertised by the provider and the usable filesystem size can differ. Investigate an unexpectedly small filesystem before storing data; do not resize partitions blindly.

2. Establish a recovery path
Open the provider console before changing SSH or firewall settings. Know how rescue mode works and record the server ID and support contact in a private runbook. Take a baseline snapshot if available. Snapshots on the same provider are convenient rollback points, but they are not an independent backup.

3. Verify the SSH host key
On first connection, compare the host-key fingerprint with one obtained through the provider console or another trusted provider channel. In the server console:

Code:Copy

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

From your own computer:

Code:Copy

ssh root@YOUR_SERVER_IP

Use the initial username specified by your provider if it is not root. A changed host-key warning may follow a reinstall, but can also indicate an attack. Investigate it before accepting a replacement key; do not simply erase the warning.

4. Patch the fresh operating system

Code:Copy

sudo apt update apt list --upgradable sudo apt upgrade

Read the proposed changes and configuration-file prompts. Do not force an unattended upgrade on a server you have not inspected. If the system reports a required reboot, schedule one while the console is available, then reconnect and check services. Do not treat a routine package upgrade as a distribution upgrade.

5. Create a named administrator
Use a personal account for daily work and sudo for privileged tasks:

Code:Copy

sudo adduser adminuser sudo usermod -aG sudo adminuser

Set a strong, unique local password when prompted. Log in as that user in a second session and verify:

Code:Copy

whoami sudo -v sudo id

Do not remove the original access method until the new account and sudo both work.

6. Set up an SSH key from your own computer
On a computer with OpenSSH installed, generate a key only if you do not already have a suitable one. Choose a new filename if prompted about overwriting an existing key, and protect it with a passphrase:

Code:Copy

ssh-keygen -t ed25519 -C "vps-admin"

On Linux/macOS, if ssh-copy-id is available:

Code:Copy

ssh-copy-id adminuser@YOUR_SERVER_IP ssh adminuser@YOUR_SERVER_IP

Use -p with the actual SSH port if it differs from 22. If ssh-copy-id is unavailable, install only the public .pub key in the user's ~/.ssh/authorized_keys through your trusted console/login. The .ssh directory should be owned by that user with mode 700, and authorized_keys with mode 600. The private key stays on your computer.

7. Harden SSH without locking yourself out
Do this only after a fresh key-based login and sudo have succeeded. Back up the SSH configuration, including any snippets, and inspect /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/. Provider/cloud-init snippets and Match blocks can affect the result.

Use sudoedit to update the configuration file that actually controls these settings:

Code:Copy

PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no KbdInteractiveAuthentication no

The last setting disables keyboard-interactive authentication; do not disable it if your planned MFA uses that method. Validate syntax and inspect effective settings before reloading:

Code:Copy

sudo /usr/sbin/sshd -t sudo /usr/sbin/sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|port) ' sudo systemctl reload ssh

If syntax validation fails, correct it before reloading. sshd generally uses the first obtained value for a setting, so adding a later snippet may not override an earlier one. For Match rules, also check the intended user/client context with sshd -T -C (see man sshd). Open another fresh connection to confirm the intended authentication policy. Keep the original session until that works. A custom port reduces log noise; it is not a substitute for keys and access controls.

8. Configure both firewall layers
Check the provider/cloud firewall as well as the guest firewall. Allow your actual SSH port before enabling either. The following UFW example assumes SSH really listens on TCP 22 and a fresh server without Docker or a panel-managed firewall:

Code:Copy

sudo apt install ufw sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp sudo ufw enable sudo ufw status verbose

For a web server, add TCP 80 and 443 only when required. Avoid exposing database, Redis or panel ports to the whole Internet; prefer loopback, a VPN or restricted source addresses. Apply and test IPv6 rules too if IPv6 is enabled. Docker-published ports need separate attention because their traffic may bypass normal UFW expectations. After every change, test a new SSH connection. If locked out, use the provider console to repair the relevant rule; repeatedly reconnecting will not fix a blocked port.

9. Set a useful hostname and verify time
Pick a hostname you control, such as vps1.example.com:

Code:Copy

sudo hostnamectl set-hostname vps1.example.com hostnamectl timedatectl status

Check /etc/hosts and provider/cloud-init behavior if the name reverts after reboot. A hostname change does not create a DNS record. UTC is convenient for servers; use sudo timedatectl set-timezone UTC if that suits your operations. Verify an NTP service is actually synchronizing rather than assuming the displayed time is correct. Bad time can break TLS checks, authentication and useful log correlation.

10. Plan DNS before moving traffic
Create an A record for the public IPv4 address. Add AAAA only after IPv6 routing, firewall rules and the service have been tested. Check resolution from your workstation and an external network:

Code:Copy

dig +short A vps1.example.com dig +short AAAA vps1.example.com

If dig is missing on Ubuntu/Debian, it is supplied by dnsutils. Allow for DNS caching. Reverse DNS (PTR) is usually set in the provider dashboard and matters especially for mail. Do not deploy a mail server before checking outbound port restrictions and SPF/DKIM/DMARC requirements.

11. Inspect listening services before adding more

Code:Copy

sudo ss -lntup systemctl --failed systemctl list-unit-files --state=enabled

Understand every public listener. Bind internal services to loopback/private networks and remove unneeded software only after checking dependencies. Install a control panel only on an OS and clean-server setup supported by its vendor. Verify installers against the vendor's official instructions; do not run a random downloaded script as root. Keep SELinux/AppArmor enabled and troubleshoot policy denials instead of disabling protection as a shortcut.

12. Configure automatic security updates deliberately
Ubuntu commonly includes unattended-upgrades, but provider images vary. Check your own configuration:

Code:Copy

sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades sudo unattended-upgrade --dry-run --debug

Review /etc/apt/apt.conf.d/50unattended-upgrades and the periodic-update configuration. Confirm which repositories are covered, how failures are reported and whether automatic reboot is enabled. Third-party repositories are not automatically covered just because they were added. For panel-managed systems, check vendor compatibility first and schedule required reboots.

13. Add monitoring and actionable alerts
Monitor external availability, disk space and inodes, memory pressure, CPU, failed services, certificate expiry and backup failures. Start with a baseline:

Code:Copy

uptime free -h df -h df -i systemctl --failed sudo journalctl -p err -b --no-pager

Test the alert delivery path. An alert stored only on the failed VPS is not useful. Low "free" RAM alone is not a problem: Linux uses memory for cache, so examine available memory, swap activity and application symptoms. Sustained resource pressure needs investigation, not an automatic reboot or blind tuning.

14. Build off-site backups and prove a restore
Back up application data, database dumps, configuration and the information needed to rebuild. Store an encrypted copy outside this VPS/provider account, protect backup credentials and define retention. Database backups need application-consistent dumps or a supported snapshot/quiescing process; copying live database files can produce an unusable backup.

Restore into an isolated temporary environment. Verify files, ownership, database contents and that the application starts. Record the recovery point objective (how much data you can lose) and recovery time objective (how long recovery may take). A successful upload or a provider snapshot alone does not prove recoverability.

15. Reboot, retest and write a private runbook
Once access and backups are ready, do a planned reboot from the console or with sudo reboot. Confirm SSH, firewall policy, DNS, expected services, monitoring and backup schedules survive it. Record the OS version, purpose, ports, update schedule, backup location and recovery steps. Store secrets in a password manager, not in the runbook or forum.

Useful troubleshooting shortcuts

• SSH times out: Check the correct IP/port, provider firewall, UFW, routing and service listener through the console. Test IPv4 and IPv6 separately.
  
• Connection refused: Check sudo systemctl status ssh and sudo ss -lntp. The host may be reachable but nothing is listening on that port.
  
• Permission denied (publickey): Check the username, chosen key, ownership/modes and server logs. Use ssh -v from your computer; redact identifying details before sharing output.
  
• Updates fail: Check disk/inodes, DNS, clock and repository errors. Wait for legitimate package jobs to finish; do not delete package-manager lock files to force access.
  
• Website fails only on some networks: Check stale DNS and a broken AAAA record before changing the web server.
  

Done means verified: a fresh key-based administrator login works, only intended ports are reachable, updates are covered, alerts arrive, and an off-site backup has been restored successfully.

Official references

• Ubuntu: OpenSSH server configuration
  
• Ubuntu: UFW firewall
  
• Ubuntu: automatic updates
  
• OpenSSH: sshd_config reference (check your installed man pages for version-specific behavior)
  

What OS and workload are you setting up? Share the non-sensitive details if you need help adapting this checklist.

Final verification checklist

• Provider recovery console opens and the server identity is verified.
  
• A fresh SSH-key login as your named administrator works, with sudo access.
  
• Only intended services are reachable through both firewall layers.
  
• OS update policy, DNS and time synchronization are checked.
  
• Monitoring alerts reach you outside the VPS.
  
• An off-site backup has been restored in an isolated environment.
  
• The access, services and scheduled jobs still work after a planned reboot.
  

Common questions
Should I install aaPanel before doing this checklist?
Prepare and verify the fresh VPS first. Then check aaPanel's current OS requirements and use its supported installation and firewall procedures.

Is a provider snapshot enough as my only backup?
No. Keep an independent copy outside the VPS and test a restore. A snapshot is useful for rollback but can share the same account or provider failure.

Do I need to change SSH port 22?
Changing the port can reduce log noise, but keys, tested access controls and a recovery path matter more. Allow and verify the actual port before changing firewall rules.

Continue with aaPanel

• aaPanel setup guide for a new VPS
  
• Create your first website, connect a domain and enable SSL
  
• Ask for help with a VPS problem — include the OS version, exact error and redacted logs.
  

]]> What should you do first after buying a VPS?
Confirm recovery-console access, update the OS, create a named administrator with SSH keys, allow only the required ports, and set up off-site backups. Verify a fresh login and a restore before installing a hosting panel or moving a live website.

Review status: Documentation reviewed on 9 October 2026. Fresh-VPS walkthrough testing and original screenshots are pending; no OS or panel version is claimed as hands-on tested. Record your exact release with cat /etc/os-release before using these examples.

Scope: Commands below target a fresh, systemd-based Ubuntu/Debian VPS. AlmaLinux/Rocky use different package and firewall tools; do not paste these commands there. Use a supported OS release. If a control panel is already installed, follow its supported update, firewall and backup procedures.

Before you start: Keep your current SSH session open and confirm the provider's web/serial console works. Replace YOUR_SERVER_IP and adminuser with your own values. Run sudo commands as a sudo-capable user; on an initial root session, omit sudo. Never paste passwords, private SSH keys or access tokens into a forum post.

1. Check what you actually bought
Verify the IP addresses, RAM, storage, bandwidth allowance, virtualization type, renewal cost and backup options in the provider dashboard. Check that the guest matches the plan:

Code:Copy

cat /etc/os-release uname -r nproc free -h lsblk df -hT

A disk advertised by the provider and the usable filesystem size can differ. Investigate an unexpectedly small filesystem before storing data; do not resize partitions blindly.

2. Establish a recovery path
Open the provider console before changing SSH or firewall settings. Know how rescue mode works and record the server ID and support contact in a private runbook. Take a baseline snapshot if available. Snapshots on the same provider are convenient rollback points, but they are not an independent backup.

3. Verify the SSH host key
On first connection, compare the host-key fingerprint with one obtained through the provider console or another trusted provider channel. In the server console:

Code:Copy

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

From your own computer:

Code:Copy

ssh root@YOUR_SERVER_IP

Use the initial username specified by your provider if it is not root. A changed host-key warning may follow a reinstall, but can also indicate an attack. Investigate it before accepting a replacement key; do not simply erase the warning.

4. Patch the fresh operating system

Code:Copy

sudo apt update apt list --upgradable sudo apt upgrade

Read the proposed changes and configuration-file prompts. Do not force an unattended upgrade on a server you have not inspected. If the system reports a required reboot, schedule one while the console is available, then reconnect and check services. Do not treat a routine package upgrade as a distribution upgrade.

5. Create a named administrator
Use a personal account for daily work and sudo for privileged tasks:

Code:Copy

sudo adduser adminuser sudo usermod -aG sudo adminuser

Set a strong, unique local password when prompted. Log in as that user in a second session and verify:

Code:Copy

whoami sudo -v sudo id

Do not remove the original access method until the new account and sudo both work.

6. Set up an SSH key from your own computer
On a computer with OpenSSH installed, generate a key only if you do not already have a suitable one. Choose a new filename if prompted about overwriting an existing key, and protect it with a passphrase:

Code:Copy

ssh-keygen -t ed25519 -C "vps-admin"

On Linux/macOS, if ssh-copy-id is available:

Code:Copy

ssh-copy-id adminuser@YOUR_SERVER_IP ssh adminuser@YOUR_SERVER_IP

Use -p with the actual SSH port if it differs from 22. If ssh-copy-id is unavailable, install only the public .pub key in the user's ~/.ssh/authorized_keys through your trusted console/login. The .ssh directory should be owned by that user with mode 700, and authorized_keys with mode 600. The private key stays on your computer.

7. Harden SSH without locking yourself out
Do this only after a fresh key-based login and sudo have succeeded. Back up the SSH configuration, including any snippets, and inspect /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/. Provider/cloud-init snippets and Match blocks can affect the result.

Use sudoedit to update the configuration file that actually controls these settings:

Code:Copy

PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no KbdInteractiveAuthentication no

The last setting disables keyboard-interactive authentication; do not disable it if your planned MFA uses that method. Validate syntax and inspect effective settings before reloading:

Code:Copy

sudo /usr/sbin/sshd -t sudo /usr/sbin/sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|port) ' sudo systemctl reload ssh

If syntax validation fails, correct it before reloading. sshd generally uses the first obtained value for a setting, so adding a later snippet may not override an earlier one. For Match rules, also check the intended user/client context with sshd -T -C (see man sshd). Open another fresh connection to confirm the intended authentication policy. Keep the original session until that works. A custom port reduces log noise; it is not a substitute for keys and access controls.

8. Configure both firewall layers
Check the provider/cloud firewall as well as the guest firewall. Allow your actual SSH port before enabling either. The following UFW example assumes SSH really listens on TCP 22 and a fresh server without Docker or a panel-managed firewall:

Code:Copy

sudo apt install ufw sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp sudo ufw enable sudo ufw status verbose

For a web server, add TCP 80 and 443 only when required. Avoid exposing database, Redis or panel ports to the whole Internet; prefer loopback, a VPN or restricted source addresses. Apply and test IPv6 rules too if IPv6 is enabled. Docker-published ports need separate attention because their traffic may bypass normal UFW expectations. After every change, test a new SSH connection. If locked out, use the provider console to repair the relevant rule; repeatedly reconnecting will not fix a blocked port.

9. Set a useful hostname and verify time
Pick a hostname you control, such as vps1.example.com:

Code:Copy

sudo hostnamectl set-hostname vps1.example.com hostnamectl timedatectl status

Check /etc/hosts and provider/cloud-init behavior if the name reverts after reboot. A hostname change does not create a DNS record. UTC is convenient for servers; use sudo timedatectl set-timezone UTC if that suits your operations. Verify an NTP service is actually synchronizing rather than assuming the displayed time is correct. Bad time can break TLS checks, authentication and useful log correlation.

10. Plan DNS before moving traffic
Create an A record for the public IPv4 address. Add AAAA only after IPv6 routing, firewall rules and the service have been tested. Check resolution from your workstation and an external network:

Code:Copy

dig +short A vps1.example.com dig +short AAAA vps1.example.com

If dig is missing on Ubuntu/Debian, it is supplied by dnsutils. Allow for DNS caching. Reverse DNS (PTR) is usually set in the provider dashboard and matters especially for mail. Do not deploy a mail server before checking outbound port restrictions and SPF/DKIM/DMARC requirements.

11. Inspect listening services before adding more

Code:Copy

sudo ss -lntup systemctl --failed systemctl list-unit-files --state=enabled

Understand every public listener. Bind internal services to loopback/private networks and remove unneeded software only after checking dependencies. Install a control panel only on an OS and clean-server setup supported by its vendor. Verify installers against the vendor's official instructions; do not run a random downloaded script as root. Keep SELinux/AppArmor enabled and troubleshoot policy denials instead of disabling protection as a shortcut.

12. Configure automatic security updates deliberately
Ubuntu commonly includes unattended-upgrades, but provider images vary. Check your own configuration:

Code:Copy

sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades sudo unattended-upgrade --dry-run --debug

Review /etc/apt/apt.conf.d/50unattended-upgrades and the periodic-update configuration. Confirm which repositories are covered, how failures are reported and whether automatic reboot is enabled. Third-party repositories are not automatically covered just because they were added. For panel-managed systems, check vendor compatibility first and schedule required reboots.

13. Add monitoring and actionable alerts
Monitor external availability, disk space and inodes, memory pressure, CPU, failed services, certificate expiry and backup failures. Start with a baseline:

Code:Copy

uptime free -h df -h df -i systemctl --failed sudo journalctl -p err -b --no-pager

Test the alert delivery path. An alert stored only on the failed VPS is not useful. Low "free" RAM alone is not a problem: Linux uses memory for cache, so examine available memory, swap activity and application symptoms. Sustained resource pressure needs investigation, not an automatic reboot or blind tuning.

14. Build off-site backups and prove a restore
Back up application data, database dumps, configuration and the information needed to rebuild. Store an encrypted copy outside this VPS/provider account, protect backup credentials and define retention. Database backups need application-consistent dumps or a supported snapshot/quiescing process; copying live database files can produce an unusable backup.

Restore into an isolated temporary environment. Verify files, ownership, database contents and that the application starts. Record the recovery point objective (how much data you can lose) and recovery time objective (how long recovery may take). A successful upload or a provider snapshot alone does not prove recoverability.

15. Reboot, retest and write a private runbook
Once access and backups are ready, do a planned reboot from the console or with sudo reboot. Confirm SSH, firewall policy, DNS, expected services, monitoring and backup schedules survive it. Record the OS version, purpose, ports, update schedule, backup location and recovery steps. Store secrets in a password manager, not in the runbook or forum.

Useful troubleshooting shortcuts

• SSH times out: Check the correct IP/port, provider firewall, UFW, routing and service listener through the console. Test IPv4 and IPv6 separately.
  
• Connection refused: Check sudo systemctl status ssh and sudo ss -lntp. The host may be reachable but nothing is listening on that port.
  
• Permission denied (publickey): Check the username, chosen key, ownership/modes and server logs. Use ssh -v from your computer; redact identifying details before sharing output.
  
• Updates fail: Check disk/inodes, DNS, clock and repository errors. Wait for legitimate package jobs to finish; do not delete package-manager lock files to force access.
  
• Website fails only on some networks: Check stale DNS and a broken AAAA record before changing the web server.
  

Done means verified: a fresh key-based administrator login works, only intended ports are reachable, updates are covered, alerts arrive, and an off-site backup has been restored successfully.

Official references

• Ubuntu: OpenSSH server configuration
  
• Ubuntu: UFW firewall
  
• Ubuntu: automatic updates
  
• OpenSSH: sshd_config reference (check your installed man pages for version-specific behavior)
  

What OS and workload are you setting up? Share the non-sensitive details if you need help adapting this checklist.

Final verification checklist

• Provider recovery console opens and the server identity is verified.
  
• A fresh SSH-key login as your named administrator works, with sudo access.
  
• Only intended services are reachable through both firewall layers.
  
• OS update policy, DNS and time synchronization are checked.
  
• Monitoring alerts reach you outside the VPS.
  
• An off-site backup has been restored in an isolated environment.
  
• The access, services and scheduled jobs still work after a planned reboot.
  

Common questions
Should I install aaPanel before doing this checklist?
Prepare and verify the fresh VPS first. Then check aaPanel's current OS requirements and use its supported installation and firewall procedures.

Is a provider snapshot enough as my only backup?
No. Keep an independent copy outside the VPS and test a restore. A snapshot is useful for rollback but can share the same account or provider failure.

Do I need to change SSH port 22?
Changing the port can reduce log noise, but keys, tested access controls and a recovery path matter more. Allow and verify the actual port before changing firewall rules.

Continue with aaPanel

• aaPanel setup guide for a new VPS
  
• Create your first website, connect a domain and enable SSL
  
• Ask for help with a VPS problem — include the OS version, exact error and redacted logs.
  

]]>