<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Oops, this should have gone to tech@ so everyone who is
interested can be aware.</p>
<p>Cheers,</p>
<p>James [MPT]<br>
</p>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>Gitlab CI for ucc-fw & introducing wheel-runner</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Wed, 30 Jun 2021 05:25:45 +0800</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>James Arcus <a class="moz-txt-link-rfc2396E" href="mailto:jimbo@ucc.asn.au"><jimbo@ucc.asn.au></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:wheel@ucc.asn.au">wheel@ucc.asn.au</a> <a class="moz-txt-link-rfc2396E" href="mailto:wheel@ucc.asn.au"><wheel@ucc.asn.au></a></td>
</tr>
</tbody>
</table>
<br>
<br>
Hi all,<br>
<br>
After being inspired by discussion on Monday night and being
cooped up awaiting my COVID test results, I decided to have a hack
at getting the firewall script to be deployed by Gitlab CI. I
appear to have succeeded!<br>
<br>
While ucc-fw has been in Gitlab for a while now, it was previously
just a mirror driven by changes made by root locally. It's now the
other way around, with murasoi being prompted to pull from Gitlab
whenever changes are made to master. The hope is that this way,
asking for a firewall change can become more of an active process
for any members who are interested but who aren't on wheel.<br>
<br>
To facilitate the CI/CD job, I've spun up a new Debian machine
named wheel-runner with the Gitlab Runner software installed.
Right now this is the only thing it handles, but I'm imagining in
future it will be able to handle more configuration deployments
for other parts of the network, like DHCP or DNS. It can also be
assigned to CI jobs for other UCC repos, but I believe it'd be
best to not use it to run untrusted code.<br>
<br>
The relevant moving parts of interest are the Gitlab CI config at
<a class="moz-txt-link-freetext" href="https://gitlab.ucc.asn.au/ucc-configuration/ucc-fw/-/blob/master/.gitlab-ci.yml">https://gitlab.ucc.asn.au/ucc-configuration/ucc-fw/-/blob/master/.gitlab-ci.yml</a>,
and the sudoers file along with /usr/local/bin/pull-fw.sh on
murasoi. Instead of having the runner drop the firewall script
(which is then executed by root) onto murasoi directly, it instead
prompts murasoi to pull an updated copy from the upstream repo
separately. That way, a compromise to the deploy@murasoi account
or the runner doesn't mean an automatic privilege escalation.<br>
<br>
I've never written a CI job before, so I'm sure there are neater
and better ways to do what I've done. Improvements are welcome!
Right now the next thing I want to do is remove the need for
StrictHostKeyChecking=no in the CI pipeline.<br>
<br>
Cheers,<br>
<br>
James [MPT]<br>
<br>
P.S. for those of you receiving them, sorry for all the "Failed
pipeline" emails that I generated trying to get things working.<br>
<br>
</div>
</body>
</html>