Chapter 6 — Operating systems and virtualization

Chapter 6 — Operating systems and virtualization

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Users and permissions"]
  N2["6.2 Isolation with virtualization"]
  N3["6.3 Maintaining hosts safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Users and permissions"]
  N2["6.2 Isolation with virtualization"]
  N3["6.3 Maintaining hosts safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 Users and permissions]
    |
    v
[6.2 Isolation with virtualization]
    |
    v
[6.3 Maintaining hosts safely]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) manage users and permissions; (2) run nodes in isolated environments; (3) maintain hosts safely.

6.1 Users and permissions

Operating systems control who can do what. Lucas creates a dedicated user for the node software on each server, gives it access only to its data and configuration folders, and removes shell access for that user. The node key file is readable only by that user. Administrators log in with their own accounts and elevate privileges only when needed, so actions are recorded per person. These steps follow the principle of least privilege. If the node software ever misbehaves or is misused, the damage it can do to the rest of the server is limited.

6.2 Isolation with virtualization

Virtual machines and containers isolate software. Lucas runs each node in its own container with limited memory and processor, a read-only base image and a mounted data folder. Isolation keeps a fault in one component from affecting others and makes environments reproducible. He also uses virtual machines in the college lab to rehearse upgrades without touching the makerspace's servers. Ms Adebayo warns that isolation is not perfect: containers share the host's kernel, so the host must still be hardened and patched carefully, and container images must come from trusted sources.

6.3 Maintaining hosts safely

Lucas sets a monthly maintenance routine: apply operating system updates to one server at a time, check that the node resynchronises, review disk usage and confirm backups. He keeps a maintenance log with dates, changes and results. Because the ledger needs two of three nodes, updating one at a time keeps it running. He tests every update in a lab virtual machine first. Careful, routine maintenance prevents many incidents, and the log helps diagnose problems later, because it shows exactly what changed and when it changed on each server.

Worked example

Lucas runs each node in a resource-limited container as a dedicated user and updates one server at a time after lab testing.

Synthetic case. The hosts and containers are synthetic.

Errors and limits

Assuming containers fully isolate software ignores that they share the host's kernel.

Exercises

• EX016 — Node user restriction. What access does the node user lack? Rubric: 3 = shell access;; 2 = no shell;; 1 = data folder;; 0 = none.
• EX017 — Isolation caveat. Why must hosts still be hardened? Rubric: 3 = containers share the host's kernel;; 2 = shared kernel;; 1 = they need not;; 0 = none.
• EX018 — Rehearsal place. Where are upgrades rehearsed? Rubric: 3 = lab virtual machines;; 2 = college lab;; 1 = production;; 0 = none.

Synthesis

Least privilege, isolation and routine maintenance keep node hosts dependable.

Continue studying — chapter 06 of 30

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →