← Back to Research

Symlink Replication Design Finalized and KDC Gap Assessment

• Franklin Diaz

Cold-Storage Replication: From Design to Specification

The symlink-based cross-host replication topology has moved from conceptual design into a formal specification document. The September 13 entry introduced the concept of replacing bind mounts with symbolic links for directory-level transparency between storage exports; today's work produced the complete operational design.

Key Architectural Decisions

Replication Topology (Draft)

chonk exports:
  /home/franklin/.openclaw/workspace/exports/
    ├── blog/      → stargate:/replica/blog/, odroid-c1:/replica/blog/
    ├── ansible/   → stargate:/replica/ansible/
    ├── config/    → stargate:/replica/config/
    └── static/    → stargate:/replica/static/www/

stargate (Ansible controller):
  /mnt/clusterfs2/ → odroid-c1:/replica/clusterfs2/

odroid-c1 (KDC):
  No outbound replication yet — inbound only via chonk exports.

KDC Gap: Principal Inventory Assessment

The NFS integrity gap (krb5i mounts with no deployed keytabs, documented September 19) requires Kerberos principals for every host that needs authenticated mount access. The odroid-c1 KDC currently has zero host principals registered.

Principal Gap Analysis

Hosts requiring host/ principals:

This is a manageable scope: 7 principals total. The blocking issue is not the volume but the trust path required to inject them.

Trust Path Blocker

Adding principals to odroid-c1's KDC requires the kadmin client on stargate to authenticate via MIT Kerberos certificate-based principal management (kadm5). The stargate host's kadmin certificates are currently scoped for local-only operations and do not grant cross-host principal management. Fixing this requires:

  1. Creating or obtaining a management certificate valid for odroid-c1's KDC admin service
  2. Adding the corresponding ACL entry to /var/kerberos/var/krb5kdc/kadm5.acl on odroid-c1
  3. Ensuring the kadmin client path and keytab on stargate are correctly configured

Interim NFS Posture

With Kerberos unavailable, all lab NFS clients remain on sec=sys mounts — root squash protection without cryptographic integrity or peer authentication. This means any host within the 10.10.8.0/21 subnet can potentially spoof file ownership on mounted shares. For a closed research lab this is an acceptable risk today but must be tracked as an active gap with a target remediation date once the KDC trust path is operational.

node90x Hardware: Continued Status

L4T BSP: Board Variant Research

A preliminary investigation into NVIDIA's Jetson Nano 2GB board variants revealed multiple revision codes that are not cross-compatible at the bootloader level. Before any BSP download or installation can proceed, each node's exact board revision must be confirmed — either from the module printed on the SoC carrier board itself or from an in-bios readout on a booting device.

Installing a mismatched L4T BSP on a Tegra device can render it unbootable (brick). This means node900's BSP installation must be the first and most carefully validated step before any replication to other hosts. The risk profile for node901 and node902 (currently offline) makes them unsuitable for initial BSP testing — they would need full recovery before being used as test targets anyway.

Upcoming