Now that we have _democratic-csi_ for storage management, the old manual
iSCSI volumes are being replaced with dynamically provisioned volumes.
ThiThe new _buildroot-airplaypi_ volume is completely blank, so _root_
owns everything. The old volume had the correct ownership because it
was originally mounted in a pod that had the default `securityContext`,
before we changed the merge strategy. We now need to explicitly set the
UIDs and GIDs, since we're not inheriting the default `securityContext`
anymore.
By default, CRI-O assigns a random SELinux category to every pod, and
then must adjust the label of every file and directory in the persistent
volume to match. For very large volumes like a Buildroot output
directory, this can take quite some time. Fortunately, if we assign a
static category, we can tell CRI-O to skip the relabel step.
Unfortunately, Jenkins does not merge the `securityContext` field of the
pod spec when the `yamlMergeStrategy` is set to `merge`. For our custom
settings to apply, we have to leave the merge strategy at the default,
`override`.
Until I implement some kind of self-provisioning process for these
machines (supposing I ever do), I need a way to log in and
configure/troubleshoot. I don't think there's any particular security
concern by having an auto-logged-in root shell on the UART console, as
accessing it needs physical access to the machine.
Dustin