Guided project: build your personal learning site

Choose a site you will keep improving

Build a personal blog, static profile, or small PHP website to showcase learning from this path and future courses. A plain static profile is the smallest starting point; a Markdown-based blog or PHP page is also valid. Choose one implementation, keep its source in Git, and record the runtime it actually needs.

This project uses one OrbStack Ubuntu machine. Docker, cloud accounts, LocalStack, databases, and Python are not prerequisites. Complete the module labs first, then apply the same habits to your own site.

Create a minimal static baseline

In the Linux home directory, choose a new learning-site directory; if it already exists, choose a different name before creating files. Put browser-visible files under public/ and keep Git metadata and private notes outside that served directory:

learning-site/
  public/index.html
  notes/permissions.md
  notes/patching.md
  notes/service-recovery.md
  README.md

Create those directories explicitly inside Linux. First check ls -ld ~/learning-site; if it exists, inspect it and choose a new course directory name consistently instead of overwriting it. For a new name:

mkdir -p ~/learning-site/public ~/learning-site/notes
cd ~/learning-site
printf '# My local learning site\n' > README.md

The served public directory is intentionally narrower than the repository. Serving the whole repository could expose private notes or .git metadata. The notes filenames in the diagram are planned entries, not evidence that you have already completed their labs.

Save this starter as public/index.html and replace its sample wording with your own observations:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="description" content="My engineering learning journal and lab evidence.">
  <title>My engineering learning journal</title>
</head>
<body>
  <header><h1>My engineering learning journal</h1></header>
  <main>
    <section>
      <h2>About my learning</h2>
      <p>I document the systems I build, investigate, and improve.</p>
    </section>
    <section>
      <h2>System engineer foundations</h2>
      <p>Current status: practising locally. Evidence will be added after each lab.</p>
    </section>
  </main>
</body>
</html>

Add links to sanitized Git evidence or generated public notes as you complete work. Raw Markdown is not automatically an HTML blog: if you select a static-site generator, document its build command and serve only its generated public output. A PHP alternative needs a PHP runtime and must not expose source or secrets through a static server.

Serve and inspect it locally

Use the BusyBox httpd applet prepared in the network lab. From the site's repository directory:

busybox httpd -f -p 127.0.0.1:8765 -h "$PWD/public"

In another Linux terminal, inspect the listener and request the page with curl --max-time 3 -i http://127.0.0.1:8765/. Try the URL from your Mac browser using OrbStack's documented forwarding; if it fails, trace the contexts and actual listener instead of exposing all interfaces.

For the PHP choice, stop BusyBox first, install a supported PHP CLI through the reviewed package workflow, and use php -S 127.0.0.1:8765 -t public for local development. A minimal public/index.php can render your own course list; validate it with php -l public/index.php. PHP's built-in server is for development, not a public production endpoint.

Make one visible change and one recovery record

After the baseline loads, add a link and a short public page about one lab you actually completed. State the environment, symptom, exact check/change, observed result, and limitation. For example, a permission entry should distinguish the file's 600 mode from the parent's missing search bit; use your actual observations instead of copying an expected-output paragraph.

Initialize Git here only after confirming this is the new site directory. Follow the earlier local-author setup, then inspect/stage the intended README.md and public files and make a baseline commit. Inspect git status before each commit; private notes may be kept outside Git or ignored if appropriate, but .gitignore does not remove already tracked secrets.

For a recoverable review exercise, make one harmless wording error in the site's disposable content, commit it, and reverse it with the taught git revert sequence. Re-request the page and check the corrected text. A successful Git revert establishes source history; the browser/curl check establishes what this local server currently returns. They are related but different checks.

If the page is missing, compare the server's -h directory with the actual file path. If the connection is refused, inspect the listener/process first. If the HTML loads but a link is broken, inspect that additional URL separately. These are the network lab's cases applied to your own small site.

Connect every module to the site

As an extension after the service lab, manage the static server through a dedicated user unit. With the site at ~/learning-site and /usr/bin/busybox confirmed by command -v busybox, its service section can use:

[Service]
Type=exec
ExecStart=/usr/bin/busybox httpd -f -p 127.0.0.1:8765 -h %h/learning-site/public
Restart=on-failure
RestartSec=5

This is a fragment for a new learnwithsk-site.service user unit; add a descriptive [Unit] section. Stop the manual server first, reload user units, start the named unit, and inspect its status and journal. Boot enablement is optional and depends on the user-session lifecycle.

Publish evidence, not claims

For each course entry include the task, environment/version, what you changed, what you observed, what failed, how you recovered, and one limitation. “Ran a local file-permission lab” is accurate evidence; “production Linux expert” does not follow from it. Keep tokens, private keys, account IDs, and unrelated logs out of public notes.

Public hosting is an optional separate step. A static host can serve generated HTML but will not execute PHP. Review the chosen host's current deployment and HTTPS instructions before publishing. This guide does not expose your lab machine to the internet.

Checkpoint and cleanup

Show your local site, at least three entries based on completed labs, a clean Git history, and a README with repeatable startup and recovery steps. Stop the manual server with Ctrl+C or the named user unit with systemctl --user stop learnwithsk-site.service. If you retire the unit, remove only its file and reload user units. Keep the website source as your portfolio; remove only disposable fixtures.

Continue into DevOps foundations when you can explain and operate this small site. MicroBank is introduced there as the more demanding application involving containers, cloud concepts, and local AWS emulation.

Sources

Primary references: BusyBox HTTP server↗; PHP development server↗; OrbStack networking↗; Git basics↗.