Once you’ve got comfortable with basic Linux commands, the next natural step is putting that knowledge to work by actually serving something to the outside world — a website, a file share, an email system, whatever it might be. I want to walk through the most common network applications you’ll run into as a Linux server administrator, how to install and configure each one, and how they all fit together into a coherent server setup.
Understanding Network Services on Linux
Before installing anything, it’s worth understanding what a “network service” actually is at the OS level. A network service (or daemon) is a background process that listens on a specific network port, waiting for incoming connections. When a client connects, the daemon handles the request according to whatever protocol it implements — HTTP for web servers, SMTP for mail, SSH for remote shells, and so on.
Linux daemons are almost universally managed through systemd on modern distributions. You can check which services are active with:
systemctl list-units --type=service --state=running
And check the status of any specific service with:
systemctl status servicename
Every service covered in this guide follows the same general lifecycle: install the package via apt, edit its configuration file (usually somewhere under /etc/), enable and start it via systemctl, and open the relevant firewall port.
Web Servers: Nginx and Apache
Web servers are the most common network application anyone sets up, serving HTTP/HTTPS content to browsers.
Nginx installation:
sudo apt update
sudo apt install nginx
Once installed, systemd starts it automatically on most distributions. Verify with:
systemctl status nginx
Nginx’s main configuration lives at /etc/nginx/nginx.conf, with individual site configurations typically under /etc/nginx/sites-available/ and symlinked into /etc/nginx/sites-enabled/ when active. A minimal site block looks like:
server {
listen 80;
server_name example.com;
root /var/www/example.com;
index index.html;
}
After editing configuration, always test syntax before reloading, since a broken config file will otherwise take your live server down:
sudo nginx -t
sudo systemctl reload nginx
Apache is the alternative, installed with:
sudo apt install apache2
Apache’s configuration structure is similar in spirit but organized under /etc/apache2/, with sites-available and sites-enabled directories following the same pattern as Nginx. Apache uses .htaccess files for per-directory configuration overrides, a feature Nginx deliberately doesn’t support (by design, for performance reasons — Nginx checks configuration once at startup rather than on every request).
The practical difference: Nginx tends to handle high concurrent connection loads more efficiently due to its event-driven architecture, while Apache’s module ecosystem (particularly mod_php for direct PHP execution) is often considered simpler to configure for certain legacy applications. Many production setups actually run both together — Nginx as a reverse proxy in front of Apache or an application server, handling static files and SSL termination while passing dynamic requests backward.
SSH: Secure Remote Access
SSH (Secure Shell) is arguably the single most important network service on any Linux server, since it’s how you’ll manage the machine remotely for everything else.
sudo apt install openssh-server
The main configuration file is /etc/ssh/sshd_config. A few settings worth knowing and hardening on any internet-facing server:
PermitRootLogin no
PasswordAuthentication no
Port 22
Disabling direct root login and password authentication (in favor of SSH key-based authentication) are two of the most impactful security hardening steps you can take, since brute-force SSH attacks against password-based root logins are extremely common against any server exposed to the internet.
After editing, restart the service:
sudo systemctl restart ssh
Generating and copying an SSH key pair for passwordless, more secure login:
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id user@server-ip
ed25519 is the modern recommended key type — faster and more secure than the older RSA default, though RSA remains widely supported for compatibility with older systems.
FTP and SFTP: File Transfer
Traditional FTP (File Transfer Protocol) transmits credentials and data in plaintext, which makes it a poor choice for anything internet-facing today. If you genuinely need standalone FTP for legacy compatibility reasons, vsftpd (very secure FTP daemon) is the standard choice:
sudo apt install vsftpd
Configuration lives at /etc/vsftpd.conf. For any modern deployment though, SFTP (SSH File Transfer Protocol) is almost always the better choice, since it rides on top of your existing SSH service, is encrypted by default, and requires no separate daemon or port. You can even restrict specific users to SFTP-only access with no shell privileges by editing sshd_config:
Match User sftpuser
ForceCommand internal-sftp
ChrootDirectory /home/sftpuser
PasswordAuthentication yes
AllowTcpForwarding no
This is genuinely the recommended modern approach — one less daemon to secure and patch, reusing infrastructure you already have running.
DNS: BIND9
If you’re managing your own domain infrastructure or running an internal network that needs custom name resolution, BIND9 is the traditional, most widely deployed DNS server on Linux:
sudo apt install bind9 bind9utils
Its configuration is split across several files under /etc/bind/, with named.conf.options controlling global server behavior and named.conf.local defining the specific zones (domains) it’s authoritative for. A basic zone declaration looks like:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
The actual zone file (/etc/bind/db.example.com) contains the DNS records themselves — A records, MX records, CNAME records, and so on. After any change, validate the configuration before reloading:
sudo named-checkconf
sudo named-checkzone example.com /etc/bind/db.example.com
sudo systemctl reload bind9
For most small setups, running your own authoritative DNS server is overkill — using your domain registrar’s built-in DNS management or a managed DNS provider is simpler and more reliable. BIND9 becomes genuinely worthwhile when you need advanced internal DNS logic, split-horizon DNS, or you’re managing DNS for a large number of domains at scale.
Mail Servers: Postfix and Dovecot
Email is one of the more involved services to self-host correctly, mainly because of the anti-spam infrastructure (SPF, DKIM, DMARC, reverse DNS, IP reputation) that mail providers expect before they’ll even accept your mail without flagging it.
Postfix handles outgoing/incoming mail transfer (SMTP):
sudo apt install postfix
During installation, you’ll be prompted for a mail server configuration type — “Internet Site” is the standard choice for a server that sends and receives mail directly. Main configuration is at /etc/postfix/main.cf.
Dovecot handles the IMAP/POP3 side — actually letting mail clients like Thunderbird or Outlook connect and retrieve mail:
sudo apt install dovecot-imapd dovecot-pop3d
Configuration lives under /etc/dovecot/, primarily dovecot.conf and the modular files under conf.d/.
Given the complexity of getting a self-hosted mail server correctly configured, authenticated, and trusted by major providers (Gmail, Outlook, etc. will silently reject or spam-folder mail from misconfigured servers), many administrators reasonably choose managed email services instead and reserve self-hosting for internal-only mail or specific compliance requirements.
Database Servers: MySQL/MariaDB and PostgreSQL
While not strictly a “network application” in the web-facing sense, database servers are network services too, typically used to back other applications rather than being exposed directly to the internet.
sudo apt install mariadb-server
or
sudo apt install postgresql
Both bind to localhost by default (127.0.0.1), which is exactly what you want unless you have a specific need for remote database access — and if you do, that access should be locked down tightly with firewall rules and strong authentication, since an exposed database is one of the most common causes of serious data breaches.
Run the included security setup script after installing MariaDB:
sudo mysql_secure_installation
This walks you through setting a root password, removing anonymous users, disabling remote root login, and removing the test database — all sensible defaults for any production install.
Managing the Firewall: UFW
None of these services matter if your firewall isn’t configured to allow the right traffic through (or worse, if it’s wide open to everything). On Ubuntu, UFW (Uncomplicated Firewall) is the standard front-end for iptables/nftables:
sudo apt install ufw
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Always allow SSH access before enabling UFW if you’re managing the server remotely — enabling the firewall without first permitting SSH will lock you out of a remote server instantly, which is a genuinely common and painful mistake.
Check firewall status and active rules at any time:
sudo ufw status verbose
Checking What’s Actually Listening
A crucial habit for any server admin is regularly auditing which ports are actually open and which processes own them:
sudo ss -tulpn
This shows TCP (-t) and UDP (-u) listening (-l) sockets, with process names (-p) and numeric port numbers (-n) rather than resolved service names. Any port you don’t recognize or didn’t intentionally open deserves investigation — it could be a service you forgot about, or in the worst case, something malicious.
Reverse Proxies and Load Balancing
On any server running more than one web application, a reverse proxy pattern is standard practice: Nginx (or Apache, or dedicated tools like HAProxy or Traefik) sits in front, listening on ports 80/443, and forwards requests to backend applications running on internal ports based on the requested domain or path.
A simple Nginx reverse proxy block:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
This lets you run multiple applications, each bound only to localhost on different ports, while Nginx handles all external-facing traffic, SSL termination, and routing — a pattern that scales cleanly as you add more services to a single server.
Securing Services with TLS/SSL
Any service handling sensitive data (which, realistically, is most of them) should be encrypted in transit. For web servers, Let’s Encrypt via Certbot is the standard free option:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
Certbot automatically obtains a certificate, configures Nginx to use it, and sets up automatic renewal via a systemd timer or cron job, since Let’s Encrypt certificates are valid for 90 days and need periodic renewal.
Troubleshooting Network Service Issues
Service won’t start — Check logs immediately with journalctl -u servicename -xe, which shows recent log entries and often points directly at the configuration error causing the failure.
Port already in use — Another process is already bound to the port you need. Identify it with sudo ss -tulpn | grep :80 and decide whether to stop that process or reconfigure your new service to use a different port.
Can’t connect from outside despite service running locally — Almost always a firewall issue. Check ufw status and confirm the relevant port is actually allowed, and also check any cloud provider security groups if you’re running on AWS, GCP, Azure, etc., since those add an additional firewall layer outside the OS itself.
Service works over HTTP but not HTTPS — Usually a certificate issue; check certificate validity and paths with sudo certbot certificates and confirm your web server’s config actually points at the right certificate files.
Best Practices for Production Network Services
Run every service with the least privilege it needs — most modern daemons drop root privileges after binding to their port and run as a dedicated unprivileged user (www-data for Nginx/Apache, for example). Keep services patched via regular apt update && apt upgrade. Disable and remove any service you’re not actually using — every running daemon is additional attack surface. Log centrally where possible, since correlating logs across multiple services during an incident is far easier with centralized logging (via rsyslog, journald forwarding, or a dedicated log aggregator) than SSHing into individual boxes.
Summary
Setting up network services on Linux follows a consistent pattern regardless of which specific application you’re deploying: install via your package manager, configure through well-documented text files under /etc/, manage the running process through systemd, and secure it with a properly configured firewall and, where applicable, TLS encryption. Once that pattern clicks, adding a new service to your server — whether it’s a web server, mail system, database, or file share — becomes a familiar, repeatable process rather than something new to figure out each time.
References
- Nginx official documentation: https://nginx.org/en/docs/
- Apache HTTP Server documentation: https://httpd.apache.org/docs/
- OpenSSH manual: https://www.openssh.com/manual.html
- BIND9 Administrator Reference Manual: https://bind9.readthedocs.io/
- Postfix documentation: https://www.postfix.org/documentation.html
- Ubuntu Server Guide: https://ubuntu.com/server/docs