DevOps & Deployment Engineering

Learn delivery engineering from one explicit service contract through containers, request routing, immutable releases, infrastructure change, observation, policy, capacity, cost, rollback, recovery, and an honestly bounded handoff.

Course details and reading size
Tutorial
Reading comfortAdjust lesson text without changing code or interface size.

Linux services and least privilege

Objective Define and validate a least-privilege service contract before asking an operating-system supervisor to enforce it.

Core explanation

A service is a long-running program that provides a named capability, while a process is one running instance of a program. A supervisor starts, stops, observes, and may restart a process according to declared policy; systemd is one Linux supervisor, not the definition of a service. Identity names the operating-system user and groups whose authority the kernel evaluates, and least privilege means granting only the operations required for ordinary work. Code is the executable release, configuration selects behavior, mutable state must survive the process when the product requires it, logs record bounded operational evidence, readiness states whether new work can safely arrive, and a restart policy states which failures may be retried and how often. The Node.js program validates a plain teaching contract before any privileged setup. It accepts a dedicated non-login uid, read-only release directory, separate writable state path, loopback listener, no-new-privileges declaration, bounded restart attempts, and twenty-second stop grace. A controlled contract running as root, writing into the release, permitting privilege gain, and retrying without a positive bound is rejected with four exact reasons. This proves deterministic checks over supplied values only; it does not create a Linux user, apply permissions, start a supervisor, bind a socket, enforce a sandbox, deliver a signal, or verify service readiness. The later disposable-Linux lab must supply those environment-specific observations under an account and machine the learner owns.

Write the service identity, paths, listener, readiness, restart, and shutdown contract first; then use an owned supervisor lab to prove which parts the operating system actually enforced.

Read a service contract before choosing a supervisor

A service is a long-running program that provides a named capability, a process is one running instance, and a supervisor manages process lifecycle according to declared policy. systemd is one Linux supervisor; the portable contract comes first and names identity, executable release, configuration, writable state, listener, readiness, restart, shutdown, logs, and resource boundaries.

Predict and run the five-line Node.js validator before touching a privileged tool. The safe fixture separates non-login uid 10001, read-only release, writable state, loopback listener, privilege boundary, three-attempt restart, and twenty-second stop grace; the unsafe fixture reports four ordered reasons without creating an account or changing the host.

Translate the contract into an owned systemd lab

In a disposable Linux machine or virtual machine you own, record operating-system and systemd versions before creating the dedicated service identity through the approved lab procedure. Install a versioned release that the runtime identity can read but not modify, create only the named writable state directory, and keep configuration and any teaching secret outside the release and repository.

The unit supplies absolute ExecStart and WorkingDirectory values, the dedicated User and Group, explicit configuration, NoNewPrivileges, restricted writable paths, a bounded restart rule, and the documented stop timeout. Validate the unit and inspect its effective merged form because defaults and drop-ins can change what the supervisor will actually enforce.

Make readiness, restart, shutdown, and evidence distinct

Readiness states whether new work may safely arrive, while a restart rule states when supervisor-created replacement is likely to help. A permanent configuration error should stop with an operator-readable reason rather than loop forever; a temporary process failure may be retried only under the declared attempt and time bounds.

On termination, stop admission, finish or checkpoint bounded accepted work, close resources, and exit before the grace period ends. Correlate supervisor state, release identity, operation identity, logs, memory, CPU, tasks, files, listener, readiness, signal time, and exit time without recording tokens or private payloads.

Prove the real boundary and state what remains modeled

Start the unit, capture effective uid and groups, executable and configuration paths, listener, writable directories, readiness, ordinary loopback request, one denied read of an unrelated lab file, delivered termination signal, exit time, bounded restart, and retained logs. Restart the disposable machine once so boot ordering and mounted state are tested rather than inferred from a manual start.

A green active state proves only that systemd observes a process, and the Node.js validator proves only its own object rules. Diagnose unit loading, process creation, configuration, filesystem, socket, dependency, readiness, and user result in order; preserve exact host-specific evidence without claiming container, cloud, public network, production, or incident behavior.

CURRICULUM CONTEXTRelated courses and the course concept model