Module 65: Server Management

Why each option is right or wrong

• “The private key, so the server can recognise you when you connect” (Incorrect): The private key should stay on your computer; the server only needs the public one.
• “Both keys, so either side can sign in” (Incorrect): The private key should stay with you; sharing it defeats the purpose.
• “Neither; SSH works with passwords only” (Incorrect): SSH keys are the safer, preferred way to sign in.
• “The public key; the private key stays on your computer” is correct.

  SSH keys come in pairs. The public key, in ~/.ssh/authorized_keys on the server, can only check signatures. The private key proves who you are and should stay on your computer, protected by a passphrase.

  • Create: ssh-keygen -t ed25519.
  • Copy: ssh-copy-id user@server.

📖 Revise: Lesson 1: SSH and keys

Why each option is right or wrong

• “SSH settings apply only to sessions that are already open” (Incorrect): They apply to new connections, which is why a mistake can lock you out.
• “Closing the session deletes the configuration file” (Incorrect): Closing doesn't touch the file.
• “Servers reboot when the last session closes” (Incorrect): Servers keep running when you disconnect.
• “If the change is wrong, you can fix it instead of being locked out” is correct.

  A mistake in sshd_config, like disabling password login before your key works, can stop new connections. An existing session stays connected, so you can undo the change. Test with a second, new connection first.

  • Check syntax: sudo sshd -t before restarting.
  • Cloud providers: often offer a console as a last resort.

📖 Revise: Lesson 1: SSH and keys

Why each option is right or wrong

• “Updates make the server run noticeably faster every time they install” (Incorrect): Speed isn't the aim; closing known holes is.
• “Servers stop working unless they're updated daily” (Incorrect): They keep running, but stay vulnerable.
• “Updates delete old log files automatically” (Incorrect): Log clean-up is handled by rotation, not security updates.
• “Most attacks use known weaknesses that updates already fix” is correct.

  Attackers scan the internet for servers missing published fixes, often within days of a fix appearing. Automatic security updates close those gaps without waiting for you to remember.

  • Ubuntu: unattended-upgrades.
  • Still check: some updates need a restart.

📖 Revise: Lesson 2: Packages and updates

Why each option is right or wrong

• “Minimal servers have no need for security updates” (Incorrect): Every server needs updates; fewer programs just means fewer to patch.
• “Hosting providers charge per installed program” (Incorrect): Pricing isn't per program; security and simplicity are the reasons.
• “Linux can run only five programs at once” (Incorrect): Linux can run many; minimal is about fewer weaknesses.
• “Fewer programs and ports mean fewer ways in” is correct.

  Every installed service, open port and extra package is something that may have a flaw or need updating. Removing what you don't use shrinks the attack surface and the maintenance.

  • Check open ports: ss -tlnp.
  • Firewall: allow only the ports you need, like 22, 80 and 443.

📖 Revise: Lesson 2: Packages and updates

Why each option is right or wrong

• “Root can't run Node.js applications” (Incorrect): Root can run anything, which is exactly the danger.
• “The deploy user makes the app run faster” (Incorrect): Speed is the same; the benefit is limited damage.
• “Apps running as root crash more often than apps run by other users” (Incorrect): Stability is the same; the risk is how much an attacker gets.
• “A compromised app then only gets limited access” is correct.

  If an attacker finds a flaw in your app, they get the permissions of the user it runs as. As root, that's the whole server. As a limited deploy user, they're confined to what that user can touch.

  • Give it: only its own folder and the ports it needs.
  • Ports below 1024: use a reverse proxy instead of root.

📖 Revise: Lesson 3: Running your app with systemd

Why each option is right or wrong

• “Restarts the server whenever the app fails” (Incorrect): It restarts the app, not the whole server.
• “Stops the app permanently after its first failure” (Incorrect): It does the opposite: it starts it again.
• “Sends an email to the administrator” (Incorrect): Notifications need separate monitoring.
• “Restarts the app automatically if it crashes” is correct.

  If the process exits with an error, systemd starts it again, after a short delay if configured. Brief crashes recover without anyone waking up, though you should still find the cause.

  • Pair with: RestartSec=5 and alerts on repeated restarts.
  • Enable at boot: systemctl enable servicename.

📖 Revise: Lesson 3: Running your app with systemd

Why each option is right or wrong

• “systemctl start servicename -f” (Incorrect): That starts the service; it doesn't show logs.
• “cat /var/log/all” (Incorrect): There's no such standard file, and cat doesn't follow.
• “ls -f servicename” (Incorrect): ls lists files; it doesn't read logs.
• “journalctl -u servicename -f” is correct.

  journalctl reads systemd's journal. -u picks one unit (service) and -f follows new lines as they arrive, like tail -f.

  • Recent only: --since "10 min ago".
  • Errors only: -p err.

📖 Revise: Lesson 4: Logs

Why each option is right or wrong

• “Rotated logs are encrypted automatically for extra security” (Incorrect): Rotation manages size; encryption is separate.
• “Log files can't be opened or read until they've been rotated” (Incorrect): Current logs can be read anytime.
• “Rotation makes the app run faster” (Incorrect): It protects disk space, not speed.
• “Without rotation, logs grow until they fill the disk” is correct.

  A busy app can write gigabytes of logs. Rotation regularly starts a new file, compresses old ones and deletes the oldest, keeping history without running out of space.

  • Tool: logrotate, or journald's size limits.
  • Keep: as long as you need for investigations.

📖 Revise: Lesson 4: Logs

Why each option is right or wrong

• “Full disks make the server's CPU overheat” (Incorrect): Disk space doesn't affect CPU temperature.
• “Disk space is the only thing worth monitoring” (Incorrect): Memory, CPU and errors matter too; disk failures are just very disruptive.
• “Hosting providers delete servers with full disks” (Incorrect): They don't delete them, but your app may stop working.
• “A full disk stops databases and logging, often taking the app down” is correct.

  When the disk fills, databases refuse writes, logs stop, and uploads fail, often all at once. It creeps up slowly, so an alert at, say, 80% gives time to act before it becomes an outage.

  • Common culprits: logs, backups, uploads, old releases.
  • Check: df -h and du -sh *.

📖 Revise: Lesson 5: Monitoring a server

Why each option is right or wrong

• “Each alert costs the server money to send by email or text” (Incorrect): Cost isn't the main issue; attention is.
• “Most monitoring tools allow only three alerts per server” (Incorrect): Tools allow many; the limit should be human attention.
• “Alerts slow down the app while they're sent” (Incorrect): Sending alerts has a negligible effect on the app.
• “Too many alerts get ignored, so real problems are missed” is correct.

  If alerts fire for every small blip, people learn to dismiss them, and the one that matters gets lost. Alert only on things that need action, such as the site being down, errors rising, or disk filling.

  • Alert fatigue: the name for this problem.
  • Each alert should say: what's wrong and what to do.

📖 Revise: Lesson 5: Monitoring a server