feat: Add LaTeX Docker chapter; update metadata and previous chapters

chapters/devopsHosts.tex

@@ -7,11 +7,11 @@
 \index{Amazon EC2}
 
 \section{Purpose}
-This chapter names the hosts that will make up the development environment for
-\CourseNumber\ and records the role, platform, and ownership of each. It is an
-inventory of intent: no machine listed here has been provisioned, and the chapter therefore
-presents no execution \gls{evidence}. It is expected to grow as later
-assignments add services to the environment.
+This chapter names the hosts that make up the development environment for
+\CourseNumber\ and records the role, platform, owner, and status of each.
+Hosts in service are described here at inventory level; their configuration
+and execution \gls{evidence} are recorded in the chapter for the activity that
+uses them. The inventory may grow or change depending on assignment requirements.
 
 \section{Naming Convention}
 \index{hosts!naming}
@@ -29,22 +29,23 @@ The \textbf{Status} column distinguishes machines already in use from those that
 will be configured in a later assignment. A host is marked \emph{In service}
 only once it exists and is reachable.
 
-\begin{tabularx}{\linewidth}{L{3.0cm}YL{3.3cm}L{2.0cm}}
-\caption{Planned Host Inventory\label{Table:HostInventory}}\\
+\begin{tabularx}{\linewidth}{L{3.5cm}YL{3.0cm}L{2.2cm}}
+\caption{Host Inventory\label{Table:HostInventory}}\\
 \toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule
 \endfirsthead
-\multicolumn{4}{l}{\small\itshape Planned Host Inventory (continued)}\\
+\multicolumn{4}{l}{\small\itshape Host Inventory (continued)}\\
 \toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule
 \endhead \bottomrule \endlastfoot
+\texttt{ssw590-group-web} & Group deployment target. Runs the website in \ChapterRef{CloudDockerDeployment}. & Ubuntu 26.04 LTS on Amazon EC2, \texttt{t3.micro} & In service\\
 \texttt{ssw590-dev-01} & Primary Linux host for the course. Target for service configuration, deployment exercises, and command-line work. & Ubuntu Server LTS on Amazon EC2 & Planned\\
-\texttt{ssw590-build-01} & Build and integration host, kept separate from the deployment target so that a failed build cannot disturb a running service. To be provisioned only if a later assignment requires it. & Ubuntu Server LTS on Amazon EC2 & Conditional\\
 \end{tabularx}
 
 \section{Access and Ownership}
 \index{hosts!access model}
 \index{least privilege}
-All hosts listed above are owned and administered by the author. The following
-rules govern access to the Linux hosts once they are provisioned.
+\texttt{ssw590-group-web} is shared by both authors and runs under Victor's AWS account,
+where each author has a separate IAM identity. The following rules are the target access policy
+for course Linux hosts:
 
 \begin{itemize}[leftmargin=*]
 \item Interactive access is by \gls{ssh} public key only.
@@ -55,29 +56,24 @@ rules govern access to the Linux hosts once they are provisioned.
 \item Day-to-day work is performed by an unprivileged account. Administrative
       rights are granted per command rather than by general membership in the
       \texttt{sudo} group.
-\item Should a teammate require access after teams are formalized, that person
-      receives a separate named account rather than a shared login, so that
+\item Teammates who require access after teams are formalized
+      receive a separate named account rather than a shared login, so that
       access can be revoked individually and actions remain attributable.
 \end{itemize}
 
 \section{Cost and Cleanup}
 \index{hosts!cost}
 \index{hosts!teardown}
-The Linux hosts are expected to run on the smallest instance size that supports
-the coursework, under whatever free-tier or credit allowance the account
-provides, with a billing alarm configured before the first instance is
-launched. Compute is billed per instance-hour, and attached storage whether or
-not the instance is running, so each additional host adds cost independently of
-how heavily it is used: provisioning \texttt{ssw590-build-01} alongside
-\texttt{ssw590-dev-01} would approximately double the compute cost of the
-environment. It is therefore left unprovisioned until an assignment requires
-builds to be isolated from the deployment target, and would be stopped between
-uses rather than run continuously; only \texttt{ssw590-dev-01} needs to remain
-available at all times.
+\texttt{ssw590-group-web} runs on a \texttt{t3.micro} instance and is covered
+by a monthly AWS budget alert. Compute is billed per
+instance-hour, and attached storage and the public IPv4 address are billed as
+well, so each additional host adds cost independently of how heavily it is
+used: provisioning \texttt{ssw590-build-01} would approximately double the
+compute cost of the environment. It is therefore left unprovisioned unless
+required in the future, and would be stopped between uses rather than run continuously.
 
-Each planned host is disposable. Teardown consists of terminating the instance,
-deleting the attached storage volume, and releasing any static address reserved
-for it; a static address left reserved after the instance is gone continues to
-be billed. Because the \gls{ami} and the configuration steps are recorded, a
-terminated host can be rebuilt rather than preserved, which is why teardown is
-treated as routine rather than exceptional.
+Course hosts are disposable. Teardown consists of terminating the instance and
+deleting its storage volume. \texttt{ssw590-group-web} uses an automatically
+assigned public address rather than a reserved static address, so there is no
+address to release; its address changes if the instance is stopped and
+started.