stevens-smartpark/smartpark-app
4
0
Fork 0
Code Issues 4 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Add Group 02 LaTeX manual source for peer review

Browse Source
This commit is contained in:
nica765
2026-10-07 19:54:11 -04:00
parent ba7eb30138
commit 2c9ddea66f
64 changed files with 5262 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
latex-manual/devopsGitea.tex
+561
View File
@@ -0,0 +1,561 @@
\chapter{Gitea}
\ChapterLabel{Gitea}
\index{Gitea}
% Chapter outline follows dosManual-V1.12.pdf, Section 2.6.
% Add the team's implementation and evidence beneath each heading.
% These comments are authoring notes, not claims of completed work.
The chapter follows the eight-part rubric in Section 2.6 of the assignment
manual~\cite{DosManual112}. Recorded deployment tests refer to September 29,
2026; times are UTC. The domain-benefit status reflects the team's later
update. Historical evidence is not a new live-service verification.
\section{Student Pack Domain and DNS}
\label{Section:GiteaDomainDNS}
% Identify offer, eligibility, first-year and renewal costs, expiration,
% hostname, DNS record, independent lookup, HTTPS link, and renewal tracking.
The team applied for access to the GitHub Student Developer Pack domain offer and was approved. However, access to the benefits of the developer pack will become available 3 days after the day of approval. Therefore, the team did not claim that the Student Pack domain
criterion was completed.
For the working Gitea deployment, the team used the temporary hostname
\url{https://git.137-184-97-250.nip.io/}. The hostname resolves to the DigitalOcean Droplet used for the Gitea service and allows the team to
verify HTTPS and the remaining deployment requirements while access to the approved Student Developer Pack benefits is pending.
The temporary \texttt{nip.io} hostname is not presented as a replacement for the required Student Pack domain. Once the approved Student Developer Pack benefits become available, the team will claim an eligible domain offer, record the offer and renewal terms, create a dedicated Gitea DNS record, and update the HTTPS configuration accordingly.
\section{Pinned Gitea Deployment}
\label{Section:GiteaDeployment}
% Record Droplet/image versions, official image source, deployment commands,
% restart policy, persistent mounts, proxy connection, redacted Compose,
% versioned non-secret file links, and repeatable installation instructions.
The SmartPark team deployed Gitea on a DigitalOcean Droplet using Docker Compose and the official version-pinned Gitea image \texttt{docker.gitea.com/gitea:1.27.3}. The deployment was checked on September 29, 2026, with Docker Compose version \texttt{v5.4.0}.
Gitea is attached to the private Docker network \texttt{color-net}, which is shared with the Caddy reverse proxy. Gitea does not publish its
application port directly to the host. Instead, Caddy forwards requests privately to \texttt{gitea:3000}. The public HTTPS endpoint therefore terminates at Caddy rather than at the Gitea container.
Persistent Gitea application data is stored in the named Docker volume \\
\texttt{gitea-foundation\_gitea\_data}, mounted at \texttt{/data}. This volume stores both the Git repositories and the SQLite database and remains in place when the disposable Gitea container is recreated.
The service is managed from \texttt{/root/gitea-foundation}. The deployment and basic verification commands are:
\begin{verbatim}
cd /root/gitea-foundation
docker compose config --quiet
docker compose up -d
docker compose ps
docker logs --tail 50 gitea-foundation-gitea-1
\end{verbatim}
The Gitea restart procedure is:
\begin{verbatim}
cd /root/gitea-foundation
docker compose restart gitea
docker compose ps
docker logs --tail 100 gitea-foundation-gitea-1
\end{verbatim}
Private proxy connectivity can be checked from the Caddy container with:
\begin{verbatim}
docker exec color-buttons-caddy wget -S -O /dev/null http://gitea:3000/
\end{verbatim}
The version-controlled deployment files include
\texttt{compose.yaml}, \texttt{.env.example}, \\
\texttt{Caddyfile.example}, and
\texttt{docs/gitea-operations.md}. The live \texttt{.env}, credentials,
SSH keys, database file, and backup archive are not stored in the repository
or included in this report.
\section{Database and Persistence}
\label{Section:GiteaPersistence}
% Document the chosen database, private connection/file path, volumes and
% secret handling. Include repository/issue IDs, container-replacement command,
% before/after evidence, and conclusion; PostgreSQL health check if applicable.
The team selected SQLite as the Gitea database because the deployment is intended for a small student team and does not require a separate database service. Gitea stores the SQLite database at \texttt{/data/gitea/gitea.db}. Git repositories are also stored under the persistent \texttt{/data} path. Because this data is stored in the named Docker volume rather than in the disposable container filesystem, it remains available when the Gitea container is replaced.
Before the persistence test on September 29, 2026, the operator verified that \\ \texttt{/data/gitea/gitea.db} existed inside the running Gitea container. At that time, the SQLite database file was 2,183,168 bytes.
The team used the existing SmartPark product repository and Issue~\#1 as the
persistence test records:
\begin{itemize}
\item Repository:
\url{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app}
\item Issue~\#1:
\url{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/1}
\end{itemize}
Before container replacement, both URLs returned HTTP 200 over HTTPS. The repository page displayed the SmartPark repository, and Issue~\#1 displayed the ``Document Gitea deployment and operations'' issue.
The Gitea container was then replaced without deleting its persistent volume. The exact command was run from \texttt{/root/gitea-foundation}:
\begin{verbatim}
docker compose up -d --force-recreate gitea
\end{verbatim}
Docker Compose recreated only the Gitea container. The service continued to use the pinned image \texttt{docker.gitea.com/gitea:1.27.3}. Gitea exposed only its internal container ports and did not publish the application backend directly to the host.
After the replacement, the same SmartPark repository and Issue~\#1 were checked again. Both returned HTTP 200 with normal TLS verification, and the same repository and issue content remained available. This verified that the repository data and issue metadata survived replacement of the disposable Gitea container because the SQLite database and Git repositories were stored in the persistent named volume.
SQLite requires no network database service or public database port. The database file is accessed locally by Gitea inside the persistent data volume, so there is no PostgreSQL-style port such as TCP 5432 to publish for this deployment.
This container-replacement test verifies \emph{persistence}; it is not a backup-and-restore test. Backup recoverability was tested separately using an isolated restored Gitea instance and is documented in the optional
recovery summary in Section~\ref{Section:GiteaOperation}. The separate optional extra-credit evidence subsection remains to be added.
\section{HTTPS and Certificate Renewal}
\label{Section:GiteaHTTPS}
% Compare two certificate options and justify the choice. Identify TLS
% termination, hostname certificate/issuer/expiry, redirect, renewal automation,
% successful renewal test or dry run, redacted proxy config, and test output.
Caddy is used as the public reverse proxy for the SmartPark Gitea deployment. TLS terminates at Caddy, and Caddy forwards traffic privately to
\texttt{gitea:3000} over the Docker network \texttt{color-net}. Gitea does not publish its web backend directly to the public Internet.
The team considered two certificate-management approaches: manually obtaining and installing a TLS certificate, or using Caddy's automatic HTTPS support with Let's Encrypt. Manual certificate management would require the team to track certificate installation, expiration, and renewal procedures directly. The team selected Caddy with Let's Encrypt because Caddy integrates certificate issuance, HTTP-to-HTTPS redirection, certificate storage, and automatic renewal with the reverse proxy.
The public Gitea service is available at:
\begin{center}
\url{https://git.137-184-97-250.nip.io/}
\end{center}
A verified TLS connection to this hostname presented a certificate whose subject and DNS Subject Alternative Name matched \texttt{git.137-184-97-250.nip.io}. The certificate was issued by Let's Encrypt using intermediate \texttt{YE2}. When checked on September 29, 2026, its expiration time was:
\begin{verbatim}
2026-12-28 19:17:55 UTC
\end{verbatim}
HTTP is used only for redirection to HTTPS. After TCP port 80 was moved to the Caddy reverse proxy and allowed through the DigitalOcean Cloud Firewall, an external HTTP request to the Gitea hostname returned HTTP 308 with the expected HTTPS Location header. Following the redirect reached the Gitea service with HTTP 200 and normal TLS certificate verification.
Caddy stores its ACME certificate state in persistent Docker storage. The named volumes \texttt{caddy\_data} and \texttt{caddy\_config} preserve Caddy's certificate and configuration state across container replacement. The live
Caddyfile is mounted read-only from the Droplet at \texttt{/root/color-buttons-app/Caddyfile}. This allows Caddy to manage future certificate renewal without relying on the disposable container filesystem.
A successful renewal of the live production certificate was not observed during this assignment. Instead, the team performed an ACME staging issuance dry run on September 29, 2026 at approximately 21:24 UTC to verify the configured certificate automation path.
The temporary staging hostname
\begin{verbatim}
renewal-check.git.137-184-97-250.nip.io
\end{verbatim}
was first verified to resolve to the Droplet IPv4 address. The operator backed up the live Caddyfile and added a separate temporary site using Let's Encrypt's staging ACME directory. The modified Caddy configuration was validated and reloaded successfully.
An external request to the staging hostname returned HTTP 200 when certificate trust verification was bypassed for that staging test host only. Certificate inspection showed a matching certificate with issuer:
\begin{verbatim}
CN=(STAGING) Artificial Amaranth YE1,
O=Let's Encrypt,
C=US
\end{verbatim}
The staging certificate had the expiration time:
\begin{verbatim}
2026-12-28 20:25:07 UTC
\end{verbatim}
Normal trust verification rejected the staging certificate, which was expected because Let's Encrypt's staging certificate authority is intentionally not publicly trusted.
During the staging test, external checks of the production Gitea site continued to return HTTP 200 with normal certificate verification. After the dry run, the operator restored the original Caddyfile, validated the restored configuration,
and reloaded Caddy. A local request to the Gitea HTTP hostname returned the expected HTTP 308 redirect, and follow-up external HTTPS checks again returned HTTP 200 with normal certificate verification. The temporary staging route was
removed from the restored Caddyfile.
This staging test demonstrates that the configured Caddy/ACME challenge and certificate-issuance path functions correctly with the Let's Encrypt staging service. It is a certificate issuance dry run and does not claim that a renewal of the live production certificate was directly observed.
A sanitized summary of the relevant reverse-proxy configuration is shown below:
\begin{verbatim}
git.137-184-97-250.nip.io {
reverse_proxy gitea:3000
}
\end{verbatim}
The production Caddy configuration and non-secret example configuration are maintained separately from credentials and private certificate material. Passwords, tokens, private keys, and live secret configuration are not included in this manual or committed to the product repository.
\section{Firewall and External Exposure}
\label{Section:GiteaFirewall}
\index{firewall}
\index{network exposure}
The DigitalOcean Cloud Firewall \texttt{ssw590-gitea} was attached to
\texttt{marketplace-s-1vcpu-1gb-nyc1}. The team's deployment records identify one
attached Droplet with IPv4 address \texttt{137.184.97.250}. The recorded
inbound rules are shown in Table~\ref{Table:GiteaFirewallRules}. These
configuration details describe the infrastructure managed by Jacob
(\texttt{jjradzz}); no Cloud Firewall screenshot or rule export is included
in the five images accompanying this chapter.
\begin{table}[htbp]
\centering
\caption{Recorded inbound Cloud Firewall rules, September 29, 2026.}
\label{Table:GiteaFirewallRules}
\begin{tabularx}{\linewidth}{L{1.7cm}L{3.5cm}Y}
\toprule
\textbf{TCP port} & \textbf{Allowed source} & \textbf{Purpose}\\
\midrule
443 & All IPv4 & Public HTTPS through Caddy.\\
80 & All IPv4 & HTTP redirect and certificate handling.\\
22 & \texttt{71.127.212.247/32} & Administrator SSH from the approved address.\\
\bottomrule
\end{tabularx}
\end{table}
Outbound ICMP, TCP, and UDP allow all IPv4 and IPv6 destinations. This permits
outbound access needed for image/package downloads, DNS, time, and
certificate services. No global IPv6 address was observed on the Droplet;
the recorded public ingress rules therefore cover its IPv4 interface.
An overlapping-firewall check and detailed host firewall inventory are not
present in the supplied evidence.
The operator initially found that the firewall had zero attached Droplets.
That configuration was corrected before the final tests. Earlier blocked-port
observations cannot be attributed to the unattached firewall. After attachment,
tests from the approved external Windows environment produced the results in
Table~\ref{Table:GiteaExternalTests}~\cite{SmartParkEvidence}.
\begin{table}[htbp]
\centering
\caption{Post-attachment external checks, September 29, 2026, about 21:51 UTC; source: approved Windows environment.}
\label{Table:GiteaExternalTests}
\begin{tabularx}{\linewidth}{L{2.3cm}L{3.3cm}Y}
\toprule
\textbf{Endpoint} & \textbf{Expected} & \textbf{Recorded actual result}\\
\midrule
Gitea TCP 443 & Working HTTPS & HTTP 200.\\
Gitea TCP 80 & HTTPS redirect & HTTP 308 to HTTPS.\\
Admin TCP 22 & Approved source allowed & Operator reported fresh login success; an external probe returned an SSH banner.\\
Backend TCP 3000 & Public access blocked & Connection timed out after about three seconds.\\
TCP 5432 & No public database service & Connection timed out; deployed database is SQLite, not PostgreSQL.\\
Admin TCP 22 from unapproved source & Access denied & Not retested after attachment; no pass is claimed.\\
\bottomrule
\end{tabularx}
\end{table}
The final Docker port summary records Caddy publishing TCP 80 and 443,
while Gitea and the Two Buttons application expose only internal application
ports. This supersedes the earlier Two Buttons deployment instructions that
published the application directly on host port 80. The first private probe
after replacing that application container returned connection refused during
startup; a later probe returned HTTP 200. HTTPS protects traffic, whereas
the firewall and container mappings restrict which network services can be
reached. Figure~\ref{Figure:GiteaArchitecture} shows these boundaries.
% Omitted: raw Docker port-map output, host firewall inventory, overlapping
% Cloud Firewall check, and a post-attachment unapproved-source SSH test.
\section{Startup Team Workflow}
\label{Section:GiteaWorkflow}
\index{peer review}
The team uses the
\href{https://git.137-184-97-250.nip.io/stevens-smartpark}{Stevens SmartPark organization}
and the public
\href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app}{smartpark-app repository}
for product and operations work. The team records identify
\texttt{nicasaoi} and \texttt{vincentpenalosa} as Developers team members
with configured Write access to Code, Issues, and Pull Requests.
The repository assignments were corrected to include \texttt{smartpark-app}
and \\ \texttt{backup-restore-proof}. The supplied
screenshots show actual contributions, review and merge activity, but do
not include the team permission settings page.
The five screenshots in this section were supplied for this report on
September 30, 2026. Their interfaces display relative times rather than
absolute timestamps, so exact capture and event times are not established.
The issue and PR list views show an earlier open state; the individual
merge and closure views show the later results.
\subsection{Group Member Contributions}
The group divided the work between infrastructure and operations,
product documentation, and peer review. The contributions below distinguish
authorship from review and merge activity.
\paragraph{Jacob Radzieta (\texttt{jjradzz}).}
Jacob managed the DigitalOcean/Gitea infrastructure and documented its
deployment and operations. His work covered the Docker deployment,
persistent SQLite storage, Caddy HTTPS route, firewall configuration,
and the recorded persistence and isolated recovery checks. In Gitea,
\texttt{jjradzz} created the five product and operations issues and authored
PR \#6 from \texttt{issue-1-gitea-operations}. That contribution added the
operations guide and non-secret deployment examples. The issue and PR list
screenshots identify his backlog and PR authorship.
\paragraph{Nica Saoi (\texttt{nicasaoi}).}
Nica expanded the product README through PR \#7 from
\texttt{issue-2-smartpark-readme}. Her recorded commits added the README
expansion, clarified the current project status, and corrected spacing
after review. This contribution connected Issue \#2 to a versioned change
and demonstrated responding to a teammate's feedback before merge.
\paragraph{Vincent Penalosa (\texttt{vincentpenalosa}).}
Vincent inspected Jacob's operations changes and recorded file-specific
review notes in the PR \#6 merge commit. He merged that contribution and
closed Issue \#1. For Nica's PR \#7, he submitted a review identifying a
spacing issue, approved the corrected changes, and merged the three commits
into \texttt{main}. These records show his contribution as a peer reviewer
and integrator of both teammates' changes; they do not establish that he
personally reran the infrastructure tests.
\subsection{Product and Operations Backlog}
The issue list shows five concrete work items created by \texttt{jjradzz}:
\begin{enumerate}
\item \href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/1}{Document Gitea deployment and operations}.
\item \href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/2}{Expand the SmartPark product README}.
\item \href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/3}{Add sample parking-location data}.
\item \href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/4}{Document the SmartPark architecture}.
\item \href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/5}{Add an operations verification checklist}.
\end{enumerate}
Figure~\ref{Figure:GiteaBacklog} shows all five titles. The supplied Issue
\#1 detail view also defines the requested operations document and its
completion condition: teammate review and merge. The other four issue
bodies are not visible in these images.
\begin{figure}[p]
\centering
\includegraphics[width=\linewidth,height=0.72\textheight,keepaspectratio]{png/actionable_items.png}
\caption{Five product and operations issues, shown in the earlier open state. Image supplied September 30, 2026; exact capture time is not displayed.}
\label{Figure:GiteaBacklog}
\end{figure}
\begin{figure}[p]
\centering
\includegraphics[width=\linewidth,height=0.72\textheight,keepaspectratio]{png/pull_requests.png}
\caption{Two issue-linked PRs before merging: PR \#6 by jjradzz from issue-1-gitea-operations, and PR \#7 by nicasaoi from issue-2-smartpark-readme, both targeting main. Image supplied September 30, 2026.}
\label{Figure:GiteaPullRequests}
\end{figure}
\subsection{Issue 1: Operations Documentation}
\href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/1}{Issue \#1}
requested \path{docs/gitea-operations.md}, including the HTTPS address,
architecture, image version, persistent storage, restart procedure,
verified HTTPS/firewall results and troubleshooting steps. The work was
proposed by \texttt{jjradzz} in
\href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/pulls/6}{PR \#6}
from \\ \texttt{issue-1-gitea-operations} into \texttt{main}.
Figure~\ref{Figure:GiteaOperationsMerge} shows merge commit
\texttt{9a5897e4a5} attributed to \texttt{vincentpenalosa}, with a link
back to PR \#6. Its message records file-by-file inspection notes about
secret exclusion, image/storage/network settings, the Caddy route, volume
persistence and the ACME dry run. This provides a written peer-inspection
record by a different account from the PR author. The image is a merge
commit view; it does not separately display a formal Gitea review event.
Review notes are not treated as additional executed infrastructure tests.
Figure~\ref{Figure:GiteaIssueClosure} shows Issue \#1 closed by
\texttt{vincentpenalosa}, with references to the operations branch and
PR \#6. The displayed closure action is recorded as such; automatic closure
by the merge is not inferred.
\begin{figure}[p]
\centering
\includegraphics[width=\linewidth,height=0.76\textheight,keepaspectratio]{png/PR_issue1.png}
\caption{PR \#6 merge commit and Vincent's file-inspection notes; commit 9a5897e4a5. Image supplied September 30, 2026. Statements in review notes do not establish an instructor waiver or independently verified test results.}
\label{Figure:GiteaOperationsMerge}
\end{figure}
\begin{figure}[p]
\centering
\includegraphics[width=\linewidth,height=0.76\textheight,keepaspectratio]{png/closure_issue1.png}
\caption{Issue \#1's requested work, branch/PR references, and Closed state attributed to vincentpenalosa. Image supplied September 30, 2026.}
\label{Figure:GiteaIssueClosure}
\end{figure}
\subsection{Issue 2: Product README}
\texttt{nicasaoi} proposed the README expansion in
\href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/pulls/7}{PR \#7},
using branch \\ \texttt{issue-2-smartpark-readme}. Its description contains
\texttt{Closes \#2}, linking it to
\href{https://git.137-184-97-250.nip.io/stevens-smartpark/smartpark-app/issues/2}{Issue \#2}.
The screenshot shows the following sequence:
\begin{enumerate}
\item \texttt{nicasaoi} added the README expansion (\texttt{b7aaebc7d6})
and a current-project-status update (\texttt{fa8fb79b63}).
\item \texttt{vincentpenalosa} reviewed the change and identified an extra
space before ``Planned Parking Information.''
\item \texttt{nicasaoi} committed the spacing correction
(\texttt{d601968d32}).
\item \texttt{vincentpenalosa} approved the changes and merged the three
commits into \texttt{main}.
\end{enumerate}
Figure~\ref{Figure:GiteaReadmeReview} therefore demonstrates review,
correction, approval and merge by separate contributor/reviewer accounts.
It does not show the final README text or Issue \#2's resulting Closed
state. The closing directive is visible, but the issue closure remains
unconfirmed by the supplied screenshots. Both PR merges are documented;
the complete second issue-closure trail still requires that final evidence.
\begin{figure}[p]
\centering
\includegraphics[width=\linewidth,height=0.76\textheight,keepaspectratio]{png/PR_issue2.png}
\caption{PR \#7: issue link, Nica's commits, Vincent's review, spacing correction, approval and Merged state. Image supplied September 30, 2026; Issue \#2's closed state is not shown.}
\label{Figure:GiteaReadmeReview}
\end{figure}
\section{Architecture and Operation}
\label{Section:GiteaOperation}
\index{Gitea!architecture}
\index{Gitea!restart procedure}
Figure~\ref{Figure:GiteaArchitecture} shows the recorded request and data
paths. Public browser traffic crosses the cloud firewall to Caddy. Caddy
terminates TLS and reaches Gitea over the private Docker network. Gitea
stores both SQLite and repository data in the named volume. Administrator
SSH is a separate path limited to the approved source. The Caddy volumes
\path{caddy_data} and \path{caddy_config} preserve certificate and
configuration state; its Caddyfile is mounted read-only from
\path{/root/color-buttons-app/Caddyfile}~\cite{SmartParkOperations}.
\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
every node/.style={font=\small},
box/.style={draw,rounded corners,align=center,text width=5.6cm,
minimum height=0.9cm,inner sep=6pt},
adminbox/.style={draw,align=center,text width=2.8cm,inner sep=6pt}
]
% Position each box from the previous box's edge so wrapped text cannot
% consume the gap between boxes.
\node[box] (browser) {Team browser};
\node[box,anchor=north,yshift=-10mm] (firewall) at (browser.south)
{DigitalOcean Cloud Firewall\\Public TCP 443 and TCP 80};
\node[box,anchor=north,yshift=-10mm] (proxy) at (firewall.south)
{Caddy: TLS termination\\HTTP redirect\\Persistent certificate and\\configuration volumes};
\node[box,anchor=north,yshift=-14mm] (gitea) at (proxy.south)
{Gitea: private TCP 3000\\Docker network: color-net};
\node[box,anchor=north,yshift=-10mm] (data) at (gitea.south)
{Persistent /data volume\\Git repositories and SQLite database};
\node[adminbox,anchor=west,xshift=20mm] (admin) at (firewall.east)
{Approved admin\\Source restricted to /32\\SSH TCP 22};
\node[adminbox,anchor=north,yshift=-16mm] (host) at (admin.south)
{Droplet SSH\\administration};
\draw[->] (browser.south) -- (firewall.north);
\draw[->] (firewall.south) -- (proxy.north);
\draw[->] (proxy.south) -- node[midway,right=3pt,fill=white,inner sep=2pt,font=\footnotesize]
{private HTTP} (gitea.north);
\draw[->] (gitea.south) -- (data.north);
\draw[->] (admin.west) -- (firewall.east);
\draw[->] (firewall.south east) -- (host.west);
\end{tikzpicture}
\caption{Recorded Gitea topology, September 29, 2026. The public hostname uses temporary nip.io DNS; the Student Pack domain requirement remains unmet. SSH is a separate administrative path.}
\label{Figure:GiteaArchitecture}
\end{figure}
\subsection{Restart and Troubleshooting}
Jacob (\texttt{jjradzz}) is responsible for the infrastructure. His operations
documentation provides this restart and diagnostic procedure for the administrator:
\begin{lstlisting}[caption={Gitea restart and diagnostic procedure; not a newly executed test.},label={Listing:GiteaRestart}]
cd /root/gitea-foundation
docker compose restart gitea
docker compose ps
docker logs --tail 100 gitea-foundation-gitea-1
docker exec color-buttons-caddy wget -S -O /dev/null http://gitea:3000/
docker exec color-buttons-caddy caddy validate --config /etc/caddy/Caddyfile
\end{lstlisting}
If the private request fails, inspect Gitea's logs, state, and network
membership. If private access succeeds but public HTTPS fails, inspect
Caddy's status and configuration, DNS, and firewall rules. Validate Caddy
configuration before reload. Preserve named volumes during routine restart
and container replacement; \texttt{docker compose down -v} is not a routine
restart command~\cite{SmartParkOperations}.
\subsection{Persistence and Recoverability}
Container replacement retains the existing data volume, while recovery
requires a usable copy of lost or damaged data. The separate September 29
restore test used an archive of the stopped Gitea volume, including SQLite,
configuration, and Git repositories. It restored into a separate volume and
instance bound to Droplet loopback, leaving the live service online.
The restored repository and issue returned HTTP 200, the issue retained
marker \texttt{SSW590-RESTORE-20260929}, and the restored Git endpoint
returned the expected commit. The temporary instance was stopped after
screenshots were saved~\cite{SmartParkEvidence}.
The backup remains root-only on the Droplet and contains secrets. The
stopped test container and separate test volume were retained. This summary
distinguishes recoverability from persistence; it does not replace the
separate logs and four screenshots required for the optional extra-credit
submission. A cost and final cleanup plan is omitted pending operator details.
\section{Manual Quality and Controls}
\label{Section:GiteaControls}
\index{Hosts register}
\index{Passwords register}
This draft is version \DocumentVersion{} of the team's existing manual. The history records
the Gitea outline and this evidence-based chapter update, and the AI Prompt
Log records the writing assistance. Historical observations, configured
permissions, and pending work are distinguished throughout the chapter.
Jacob's deployment and test records describe the infrastructure results.
Nica's commit history and Vincent's review and merge activity document the
product-documentation and peer-review contributions. Planned work is
distinguished from completed actions visible in those records.
\subsection{Hosts Register}
Table~\ref{Table:GiteaHosts} adds the known Gitea host and service facts.
The existing Two Buttons application shares the same Droplet and remains
a separate exercise.
\begin{table}[htbp]
\centering
\caption{Hosts register: Gitea deployment as recorded September 29, 2026.}
\label{Table:GiteaHosts}
\begin{tabularx}{\linewidth}{L{3.0cm}Y}
\toprule
\textbf{Field} & \textbf{Recorded value}\\
\midrule
Provider / environment & DigitalOcean; student team deployment.\\
Host / owner & \texttt{marketplace-s-1vcpu-1gb-nyc1}; Jacob, infrastructure owner.\\
Public address & \texttt{137.184.97.250}; no global IPv6 observed.\\
Service / HTTPS & Gitea source-control and issue hub; \url{https://git.137-184-97-250.nip.io/}.\\
Public exposure & Caddy TCP 80/443; admin SSH TCP 22 limited to approved IPv4 /32.\\
Private data path & \texttt{color-net} to Gitea TCP 3000; SQLite and repositories in persistent \path{/data}.\\
Backup / monitoring & Isolated backup/restore tested September 29; ongoing backup schedule and monitoring configuration not supplied.\\
\bottomrule
\end{tabularx}
\end{table}
\subsection{Passwords Register: Non-Secret Account Inventory}
Table~\ref{Table:GiteaPasswords} records only known account ownership and
privileges. Actual vault references, non-revealing recovery hints, and
MFA/rotation status have not been supplied, so those fields are left
unverified. This table is incomplete for final submission. No passwords,
tokens, recovery codes, or private keys should be added to it.
\begin{table}[htbp]
\centering
\caption{Passwords register: non-secret account inventory; management details pending confirmation.}
\label{Table:GiteaPasswords}
\begin{tabularx}{\linewidth}{L{3.2cm}L{2.0cm}Y}
\toprule
\textbf{Service/account} & \textbf{Owner} & \textbf{Recorded access / missing controls}\\
\midrule
Droplet administration & Jacob & SSH key authentication; key-storage hint and rotation status not supplied.\\
Gitea administration & Jacob & Repository owner account \texttt{jjradzz}; instance-level privilege confirmation, vault hint and MFA/rotation status not supplied.\\
Gitea \texttt{vincentpenalosa} & Vincent & Developers team Write access; personal storage hint and MFA/rotation status not supplied.\\
Gitea \texttt{nicasaoi} & Nica & Developers team Write access; personal storage hint and MFA/rotation status not supplied.\\
\bottomrule
\end{tabularx}
\end{table}
\subsection{Evidence and Submission Controls}
The five embedded screenshots show the backlog, issue-linked branches/PRs,
the operations merge and Issue \#1 closure, and the README review/merge.
Captions state the date the images were supplied; exact capture times are
not visible. Earlier open-list views are distinguished from later merge
and closure evidence. Infrastructure results remain attributed to the
team's September 29 deployment and test records; the provided screenshots do not independently
show firewall settings or the team permission configuration.
The test tables distinguish expected and observed outcomes, and missing
tests are not marked as passed. Remaining evidence includes Issue \#2's
closed state, the final README, a separate formal review event for PR \#6
if available, and the missing infrastructure/control records. The four
original/restored images required for optional backup/restore credit are
not included in the supplied image set.
The final delivery is the compiled PDF of this manual, with evidence
embedded, working repository links, and checked figures and citations.
LaTeX source, screenshots, database files, and backup archives are not
separate submission artifacts~\cite{DosManual112}. Full PDF compilation,
page-layout inspection, and final review remain pending; this chapter does
not claim submission readiness.