Web Server Deployment And Disaster Recovery

Operating a web server involves more than serving a page: you must control how it listens, secure administrative access, investigate traffic, and prove that important data can be restored. This challenge-based project connects those responsibilities in four state-verified Linux scenarios.

You will provision Nginx on a custom port, install an SSH public key, audit listening sockets, reduce an access log to its busiest client, and perform a destructive restore test from a compressed archive. The tasks provide requirements and hints, while leaving the command choices and verification workflow to you.

What You Will Learn

• Install Nginx, change its default listener to port 8080, deploy specified page content, and restart the service
• Generate an RSA SSH key pair, authorize its public key, and enforce 700 and 600 SSH path permissions
• List listening TCP sockets numerically and confirm that SSH port 22 is exposed
• Build a shell text-processing pipeline that counts requests by source IP and extracts the top talker
• Archive both /var/www/html and /var/log/nginx into a gzip-compressed tar file and inspect its contents
• Simulate loss of the web root, extract the archive at /, and verify that the critical page content returns

Who This Course Is For

This project is for Linux and DevOps learners ready to apply web-service, SSH, log-processing, and backup skills without step-by-step commands.

Prerequisites: Familiarity with package and service management, text editing, shell pipelines, SSH files, permissions, network-socket inspection, and tar; this is an assessment-style project.

Learning environment: A browser-accessible Ubuntu host with sudo access, APT, Nginx, OpenSSH tools, Zsh, standard GNU/Linux utilities, and prepared log and web data; no cloud account or remote server is required.

Frequently Asked Questions

Does the SSH challenge fully disable password authentication?

No. It generates /home/labex/.ssh/id_rsa, appends the public key to authorized_keys, and fixes permissions. It does not modify sshd_config, disable passwords, or test a remote login.

Will I close unexpected network ports?

No. You use ss or netstat to list listening TCP ports numerically and confirm port 22; firewall changes and service shutdowns are outside the task.

How is the busiest client identified?

You analyze the first field of /var/log/nginx/access.log, group and count identical IP addresses, sort by frequency, and save only the top IP—203.0.113.42—to /home/labex/attacker_ip.txt.

What is actually deleted and restored in the disaster-recovery test?

The archive includes the web root and Nginx logs, but the simulated loss removes /var/www/html. You extract the archive at the filesystem root and verify that index.html containing Critical Web Content exists again.