Debian 9 Server Basics: From Install to WordPress

I still remember my first Debian 9 server setup.
I thought, “How hard can it be?” Installed it, rebooted… and then spent an hour wondering why I couldn’t even apt-get install anything because my repo wasn’t set, time was wrong, and SSH wasn’t installed.

If you’re in that boat right now, this guide is for you.

This is a practical, step-by-step walkthrough based on a Debian 9 server tutorial series: from install, network, and repos, all the way to Apache/Nginx, MariaDB, PHP, WordPress, SSL, and backups.
I’ll keep it focused, so you can get a working server without drama.

1. Decide Your Debian 9 Install Type

This affects anyone about to install Debian 9 for use as a server.
You basically have two main options mentioned in the series:

Install Debian 9 Desktop
Install Debian 9 Minimal Server

For a production server, minimal server is usually safer.
Less bloat, less attack surface, fewer updates to worry about.
Desktop install is fine if this is a lab box or you really want a GUI.

Use an official Debian mirror, verify the ISO, and keep a local copy so you don’t re-download for every reinstall.

Basic install flow:

Download the correct Debian 9 ISO.
Write it to USB (e.g. with Rufus/Etcher on your main machine).
Boot from USB and run through the installer.
For server use, choose minimal packages where possible.

Once you’re done, you should have a booting Debian 9 machine, either with a desktop or just a console.

2. Initial Checks: Version, Repos, and Network

After install, don’t rush into Apache or WordPress.
Get the basics solid first: version, repository, and networking.

Check Debian Version

Always confirm what you’re actually running before following any guide.
This helps you avoid copy-pasting wrong instructions later.

Set Debian 9 Repositories

If your repository is not configured correctly, apt will fail or be outdated.

For a safe workflow:

Backup the current sources list:
Make a copy of /etc/apt/sources.list before editing.
This lets you roll back if you break it.
Configure repositories for Debian 9.
Run an update to test:
If apt-get update runs cleanly, you’re good.

Configure Network

For most small servers:

Set a static IP on your server.
Dynamic IP for a server is asking for trouble when services suddenly move.
Make sure gateway and DNS are correct.
Test with ping (local network, then outside, like ping to a known host).

If you’re using virtual machines or complex network lab:

Configure virtual network interfaces as described in the series.
This is handy for hosting multiple networks on one NIC or for lab VLANs.

Only move on once:

You can resolve hostnames.
apt-get update works.
You can reach the server by IP from your local machine.

3. Basic Server Hardening: SSH, Users, Time

Next in the series: SSH, users, and time zone/NTP.
This is the boring part, but it saves you headaches later.

Install SSH Server

You want SSH so you don’t have to sit at the physical console all day.

Basic idea:

Install the SSH server package.
Confirm the service is running.
Test login from another machine using an SSH client.

Safety tips:

Don’t expose SSH to the internet without at least strong passwords.
For production, use key-based auth and non-default ports if needed.

Create a Non-Root User

Never live in root.

Steps you’ll generally follow:

Add a new user.
Set a strong password.
Add the user to appropriate groups (for sudo/admin work, if configured).
Log out of root and start using this normal user.

This reduces accidental rm -rf / type disasters.

Time Zone and NTP Client

Time matters for logs, SSL, cron, and debugging.

Basic flow:

Set the correct time zone for your region.
Enable and configure an NTP client so time syncs automatically.
Confirm that the system clock is correct.

Don’t skip this.
Wrong time can break SSL certificates and confuse log analysis.

4. File Sharing and Access: Samba, NFS, FTP

Samba Server

Use Samba if you have Windows clients.

Typical pattern:

Install Samba packages.
Configure shares in the Samba config file.
Set permissions on shared directories.
Add Samba users if needed.
Test access from Windows.

Be careful with permissions:

Don’t share system directories.
Use dedicated directories with controlled access.

NFS Server

Use NFS if you have Linux/Unix clients on a LAN.

Basic idea:

Install NFS server.
Define export paths and allowed clients.
Set directory ownership and permissions.
Reload/export configuration.
Mount from client and test.

Keep it on a trusted network.
NFS is usually for internal use, not over the public internet.

FTP Server with vsftpd

FTP is older but still used for some workflows.

Steps usually go like this:

Install vsftpd.
Configure authentication and access modes (anonymous vs local users).
Restrict access to home directories or specific folders.
Test using an FTP client.

Again: be strict with permissions.
For modern sites, SFTP (over SSH) is usually safer than plain FTP.

5. Web Stack: Apache, Nginx, MariaDB, PHP, DNS

You don’t have to install everything, but here’s how I’d approach it.

Choose a Web Server: Apache or Nginx

Apache and Nginx are both covered.
Many WordPress setups start with Apache because .htaccess is familiar.
Nginx is also great, especially as a reverse proxy.

Basic pattern for each:

Install the web server.
Confirm it’s running (check service status and open in a browser).
Set up your document root and a simple test page.
Configure virtual hosts / server blocks for your domain(s).

Test locally first (via IP or hosts file) before changing public DNS.

Install MariaDB (Database Server)

MariaDB is a drop-in replacement for MySQL in most use cases.

Flow usually looks like:

Install MariaDB server and client packages.
Secure the installation (set root password, remove test DB, etc.).
Create a database and user for your application (e.g. WordPress).
Test connection from the server.

Always use unique database users per app.
Don’t reuse the root DB user for your websites.

Install PHP

This is required for WordPress and many web apps.

Basic steps:

Install PHP and required extensions (e.g. for databases, image handling, etc.).
Ensure PHP is correctly connected to Apache or Nginx.
Apache: usually via mod_php.
Nginx: typically via PHP-FPM.
Create a small phpinfo test file in your web root.
Visit it in the browser to confirm PHP is executing.

Remove that phpinfo file once you’re done; it leaks environment info.

DNS Server

Running your own DNS is more advanced but useful for LAN labs or self-hosted zones.

Expected flow:

Install a DNS server package.
Configure zones and records for your domains.
Point your local machines’ DNS to this server.
Test with tools (dig, nslookup) from clients.

For public-facing DNS, you usually use a registrar/hosting DNS.
A local DNS server is great for internal development environments.

6. WordPress, SSL, Nextcloud, Remote Desktop, Backups

Once your base stack is ready, now we hit the real world apps.

Install WordPress on Debian 9

This guide builds on Apache/Nginx + PHP + MariaDB.
Typical sequence you’ll follow:

Create a database and user for WordPress in MariaDB.
Download WordPress and place it in your web root.
Set correct file permissions and ownership (web server user).
Configure your virtual host / server block for the domain.
Run the WordPress web installer and fill DB details.

Safety notes:

Don’t leave wp-config-sample.php or leftover install files.
Keep permissions as tight as possible while allowing updates.

Let’s Encrypt SSL Wildcard

Wildcard certificates cover *.domain.com under one cert.

General flow:

Use an ACME client (like Certbot) that supports wildcard.
Complete DNS-based validation (TXT records in your DNS).
Install the certificate on Apache/Nginx.
Update your virtual hosts/server blocks to use HTTPS.

Always make a backup of your web server config before editing.
One misplaced semicolon or directive can take all sites down.

Nextcloud Server

Nextcloud is your self-hosted file sync and share platform.

Combined stack usually requires:

Web server (Apache or Nginx) + PHP.
Database (MariaDB).
Nextcloud code in a dedicated directory.
Configured virtual host with proper PHP settings.

Useful as a private cloud for your team or family.
Keep storage and backup in mind from day one.

Remote Desktop Server

This is useful if you installed the desktop version or you need GUI access.

Flow usually is:

Install remote desktop server software.
Allow incoming connections (check firewall if in use).
Configure user access.
Connect from a client using an RDP/VNC-like tool.

Use strong passwords and consider VPN if exposed over the internet.
Remote desktop open to the world is a magnet for brute-force attempts.

Backups: Website and Database

This one is critical and too many people only learn it after losing data.

You should back up at least:

Website files (WordPress folder, uploads, etc.).
Databases (MariaDB dumps).

Safe habit:

Stop writing operations if possible (or schedule during low traffic).
Dump databases to files.
Archive website directories.
Copy backups off the server (remote storage, another VPS, NAS).
Test restore on a staging server occasionally.

A backup you never tested is just a hopeful zip file.

7. Putting It All Together Without Losing Your Mind

There’s a lot in that Debian 9 series, but you don’t need everything at once.
Here’s a simple order that works well for most small WordPress/Nextcloud setups:

Install Debian 9 (minimal server preferred).
Set repositories, network, SSH, users, and time/NTP.
Install and configure your web server (Apache or Nginx).
Install MariaDB and PHP.
Install WordPress and/or Nextcloud.
Add SSL (Let’s Encrypt wildcard if needed).
Add Samba/NFS/FTP only if you truly need them.
Set up regular website + database backups.

Whenever you’re changing configs:

Backup the file first.
Make small changes.
Reload/restart services and test immediately.

That approach has saved me from more than a few self-inflicted outages.

If this worked for you, keep CrushEdge handy for the next fix.