\chapter{Hosts} \ChapterLabel{Hosts} \index{hosts} \index{hosts!inventory} \index{hosts!naming convention} \index{development environment} \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. \section{Naming Convention} \index{hosts!naming} Each \gls{host} that is provisioned for this course is named \texttt{ssw590-\textit{role}-\textit{nn}}, where \textit{role} identifies the function the machine serves and \textit{nn} is a two-digit ordinal within that role. Naming by role rather than by instance identifier keeps the name stable if the underlying machine is replaced, and keeps the inventory readable when more than one host serves the same purpose. Hosts that already exist independently of this course retain their existing names. \section{Host Inventory} \index{hosts!table} 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}}\\ \toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule \endfirsthead \multicolumn{4}{l}{\small\itshape Planned Host Inventory (continued)}\\ \toprule \textbf{Host name} & \textbf{Role} & \textbf{Platform} & \textbf{Status}\\ \midrule \endhead \bottomrule \endlastfoot \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. \begin{itemize}[leftmargin=*] \item Interactive access is by \gls{ssh} public key only. Password authentication is disabled in the server configuration. The local account password recorded in \ChapterRef{Passwords} authenticates \texttt{sudo} only. \item Inbound \gls{ssh} is restricted by source address to the workstation listed above rather than opened to the public Internet. \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 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. 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.