Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Preparing Secrets for Clean-Host Installed-Package Conformance

This procedure prepares the external Secret inputs required before running the installed-package conformance harness on a clean MinisForum. It does not install the AHRI TRE server, PostgreSQL container, Secret projector, or site package. The conformance harness must remain the only package installer so that its evidence proves the behavior of the candidate archive.

The worked example uses:

  • Ubuntu MinisForum svrltreapcc02 at 192.168.31.75;
  • Datastore ahri-tre-test;
  • candidate kit 0.3.14;
  • fixed predecessor kit 0.3.12; and
  • the site identity and public material embedded in the candidate archive.

There are three command locations. The controller may be the original WSL2 shell or an explicitly authorized Apple Silicon Mac that completed the guarded controller migration in the failed-recovery reset:

  • Controller holds the candidate, predecessor, and protected authority or migrated candidate-bound leaf material.
  • MinisForum is an SSH session whose prompt starts with sysadmin@svrltreapcc02.
  • Browser is used only to retrieve the ORCID Sandbox application Secret.

Guided preparation wizard

The dedicated wizard performs Sections 1 through 12 in order, including the browser-assisted ORCID Secret step. Run it from the repository root on the recorded WSL2 controller or its authorized macOS replacement:

./scripts/minisforum-conformance-preparation-wizard.sh

The wizard is fixed to the candidate, predecessor, host, address, Deployment, Datastore, and public identities documented below. It verifies those values against the candidate rather than accepting overrides. It never writes a Secret to .env, the repository, a command-line argument, or the evidence directory. It stops after printing HOST READY; it does not create evidence or invoke the conformance harness. Continue with Section 13 only after that ready result.

If it is restarted after an interruption, the wizard validates and reuses a complete projection but refuses partial state. Reusing an already generated root identity also requires explicit confirmation that it came only from the interrupted preparation and has never been used by an installation; its separate backup must identify the same public recipient.

When the PostgreSQL CA signing key remains available, the wizard continues to issue a fresh PostgreSQL leaf certificate. When the unavailable controller was replaced by macOS, it instead accepts only the migrated PostgreSQL leaf key and certificate produced by the guarded reset. It verifies their key binding, hostname, and trust beneath the replacement candidate’s embedded PostgreSQL CA before reprojecting them. The Runtime migration follows the same public-key binding check.

The detailed procedure below remains the canonical explanation of every wizard action and can be used to inspect or recover an interrupted preparation.

Never paste a password, private key, client Secret, authorization code, or token into a command-line argument, terminal log, screenshot, evidence bundle, repository file, or release archive. Commands below inspect only public material or safe ownership and mode metadata.

What this preparation may create

Before the harness starts, this procedure creates only:

  • the ahri-tre-runtime and ahri-tre-web service identities and their declared groups;
  • temporary Secret projections beneath /run/secrets;
  • the public PostgreSQL leaf certificate under /etc/ahri-tre/postgresql/tls;
  • a new Deployment root identity under /root/ahri-tre-recovery; and
  • a separately protected root-identity backup in WSL2.

It must not create an AHRI TRE Managed-secret store, PostgreSQL data directory, PostgreSQL container, installed server manifest, or installed Runtime binary. Creating service identities alone does not install package files. The harness will run the predecessor installer later; systemd-sysusers safely confirms the already prepared identities at that point.

Required inputs

Obtain all four public files through the controlled candidate handoff:

ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz
ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256
ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz
ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256

If you are also the candidate composer, build the server, site, and WSL2 publications in one fresh component root, compose the macOS publication from the pinned Apple release and the extracted checksummed WSL2 generation client, then run:

candidate_output="$PWD/dist/conformance-candidate-postgresql-ownership-output-0.3.14"
component_root="$PWD/dist/conformance-candidate-postgresql-ownership-0.3.14"
install -d -m 0700 "$candidate_output"
./scripts/compose-installed-conformance-candidate.sh \
  --component-root "$component_root" \
  --output-directory "$candidate_output"

The component root must contain exactly server/, site/, and both client publications under clients/. The composer independently verifies their identities and checksums, embeds the committed harness, creates the complete candidate checksum inventory, and refuses to overwrite an earlier candidate. It never installs a package or invokes the harness. The macOS publication’s native install and launch remain part of later Apple Silicon conformance.

The candidate checksum must have been produced outside the candidate archive and must identify the exact candidate bytes used on every conformance host. The candidate digest for this qualification is:

bdd0fe785ed333caf1f9c7de8b70479d5c37b5526d7ace6e28de74105c2cab48

The fixed predecessor digest is:

6f5555c25d96274d7772d1b46d4409bd36a42205f21c4c715de8df5179ab18ed

The WSL2 operator must also possess:

  • the Runtime private key matching the Runtime certificate embedded in the candidate Application configuration;
  • the PostgreSQL CA private key matching the candidate’s PostgreSQL public CA; and
  • access to the ORCID Sandbox application whose public client ID is embedded in the candidate.

If either private key is unavailable or does not match the candidate, stop. Do not generate a replacement key and pair it with unrelated public material. A changed authority requires new public certificates and a newly built candidate archive. If only the Runtime leaf key is unavailable and no conformance phase has begun, follow Recovering a Conformance Candidate After Runtime Key Loss to issue a new leaf beneath the retained deployment CA, regenerate the site, and compose replacement candidate bytes before restarting this procedure.

1. MinisForum: reconfirm the clean host

Connect from WSL2:

ssh sysadmin@192.168.31.75

On the MinisForum, verify the retained host foundation:

hostname -s

Expected: svrltreapcc02.

ip -4 -o address show | grep -F ' 192.168.31.75/'

findmnt --mountpoint /data

sudo docker network inspect bridge --format '{{(index .IPAM.Config 0).Gateway}}'

The address must be assigned, /data must be the intended separate filesystem, and the Docker bridge gateway must be 172.17.0.1.

Verify the installation boundary is empty:

sudo test ! -e /usr/share/ahri-tre/server/component-versions.json
sudo test ! -e /usr/libexec/ahri-tre/ahri-tre-runtime
sudo test ! -e /var/lib/ahri-tre/secrets
sudo test ! -e /data/ahri-tre/postgresql
sudo docker inspect ahri-tre-postgresql >/dev/null 2>&1; test $? -ne 0

Every command must exit zero. Return to WSL2:

exit

2. WSL2: verify the private authority material

The example uses these protected paths outside the repository:

/home/kobus/ahri-tre-pki/private/runtime-private-key.pem
/home/kobus/ahri-tre-pki/private/postgresql-ca-private-key.pem
/home/kobus/ahri-tre-pki/public/postgresql-ca-chain.pem

Verify their presence without printing their contents:

sudo test -s /home/kobus/ahri-tre-pki/private/runtime-private-key.pem

sudo test -s /home/kobus/ahri-tre-pki/private/postgresql-ca-private-key.pem

test -s /home/kobus/ahri-tre-pki/public/postgresql-ca-chain.pem

Confirm that the PostgreSQL CA private key matches its public certificate:

sudo openssl pkey -in /home/kobus/ahri-tre-pki/private/postgresql-ca-private-key.pem -pubout -outform DER | sha256sum

openssl x509 -in /home/kobus/ahri-tre-pki/public/postgresql-ca-chain.pem -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum

The two SHA-256 values must be identical.

3. WSL2: verify and extract the candidate inputs

Place the four public input files in a protected directory:

install -d -m 0700 /home/kobus/ahri-tre-conformance/input

cd /home/kobus/ahri-tre-conformance/input

The candidate checksum declaration must contain the exact admitted digest, two spaces, and the candidate archive basename:

grep -qxF 'bdd0fe785ed333caf1f9c7de8b70479d5c37b5526d7ace6e28de74105c2cab48  ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz' ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256

sha256sum --check --strict ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256

Expected: the candidate archive reports OK.

Verify the predecessor declaration and bytes against the fixed digest:

grep -qxF '6f5555c25d96274d7772d1b46d4409bd36a42205f21c4c715de8df5179ab18ed  ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz' ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256

sha256sum --check --strict ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256

Expected: the predecessor archive reports OK.

Extract review copies without applying archive ownership or permissions:

test ! -e review
install -d -m 0700 review

tar --extract --gzip --file ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz --directory review --no-same-owner --no-same-permissions

tar --extract --gzip --file ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz --directory review --no-same-owner --no-same-permissions

Define the reviewed roots for this WSL2 shell:

CANDIDATE_ROOT=/home/kobus/ahri-tre-conformance/input/review/ahri-tre-test-datastore-deployment-kit-0.3.14
PREDECESSOR_ROOT=/home/kobus/ahri-tre-conformance/input/review/ahri-tre-test-datastore-deployment-kit-0.3.12

test -x "$CANDIDATE_ROOT/conformance/run.sh"
test -f "$CANDIDATE_ROOT/site/site-inputs.json"
test -f "$PREDECESSOR_ROOT/server/sysusers/ahri-tre.conf"

4. WSL2: bind the private material to the candidate

Review the candidate’s non-secret site identity:

jq '{kit_version, hostname, ipv4_address, deployment_id, datastore_id, runtime_dns_name, runtime_https_port, postgresql: {logical_host: .postgresql.logical_host, routing_address: .postgresql.routing_address}, oidc_client_id: .oidc.client_id}' "$CANDIDATE_ROOT/site/site-inputs.json"

Stop unless it names the intended MinisForum, address, Deployment, Datastore, Runtime origin, PostgreSQL route, and ORCID public client ID. Record the Deployment UUID; it is public confirmation input for every later conformance phase.

Confirm that the candidate contains only the declared site-v3 Injected version:

jq -e '[.requirements[].expected_version] | unique == ["site-v3"]' "$CANDIDATE_ROOT/site/injected-secrets.json"

Confirm that the retained PostgreSQL CA is byte-for-byte identical to the candidate public CA:

cmp --silent /home/kobus/ahri-tre-pki/public/postgresql-ca-chain.pem "$CANDIDATE_ROOT/site/postgresql/public-ca-chain.pem" && echo 'PostgreSQL CA matches candidate'

Extract the public Runtime leaf certificate from the candidate Application configuration:

python3 -c 'import sys,tomllib; document=tomllib.load(open(sys.argv[1], "rb")); print(document["services"]["trusted_runtime"]["certificate_chain"][0], end="")' "$CANDIDATE_ROOT/site/application.toml" > /tmp/ahri-tre-candidate-runtime-certificate.pem

Verify its chain and DNS identity:

openssl verify -CAfile "$CANDIDATE_ROOT/site/public-ca-chain.pem" /tmp/ahri-tre-candidate-runtime-certificate.pem

openssl x509 -in /tmp/ahri-tre-candidate-runtime-certificate.pem -noout -checkhost runtime.svrltreapcc02.home.arpa

Compare the public key from that certificate with the retained Runtime private key:

openssl x509 -in /tmp/ahri-tre-candidate-runtime-certificate.pem -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum

sudo openssl pkey -in /home/kobus/ahri-tre-pki/private/runtime-private-key.pem -pubout -outform DER | sha256sum

The two SHA-256 values must be identical. Remove the temporary public leaf certificate:

rm -- /tmp/ahri-tre-candidate-runtime-certificate.pem

5. WSL2 and MinisForum: transfer and verify the public inputs

Create a protected input directory on the MinisForum:

ssh sysadmin@192.168.31.75 'umask 077; mkdir -p ~/ahri-tre-conformance/input'

Transfer the same four verified files:

scp /home/kobus/ahri-tre-conformance/input/ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz /home/kobus/ahri-tre-conformance/input/ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256 /home/kobus/ahri-tre-conformance/input/ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz /home/kobus/ahri-tre-conformance/input/ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256 sysadmin@192.168.31.75:ahri-tre-conformance/input/

Connect and verify the transferred bytes again:

ssh sysadmin@192.168.31.75

cd ~/ahri-tre-conformance/input

grep -qxF 'bdd0fe785ed333caf1f9c7de8b70479d5c37b5526d7ace6e28de74105c2cab48  ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz' ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256
sha256sum --check --strict ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256

grep -qxF '6f5555c25d96274d7772d1b46d4409bd36a42205f21c4c715de8df5179ab18ed  ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz' ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256
sha256sum --check --strict ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256

Extract both public archives without installing them:

test ! -e extracted
install -d -m 0700 extracted

tar --extract --gzip --file ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz --directory extracted --no-same-owner --no-same-permissions
tar --extract --gzip --file ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz --directory extracted --no-same-owner --no-same-permissions

Define the MinisForum roots for the current SSH shell:

INPUT_ROOT=/home/sysadmin/ahri-tre-conformance/input
CANDIDATE_ROOT="$INPUT_ROOT/extracted/ahri-tre-test-datastore-deployment-kit-0.3.14"
PREDECESSOR_ROOT="$INPUT_ROOT/extracted/ahri-tre-test-datastore-deployment-kit-0.3.12"

6. MinisForum: create only the service identities

Use the fixed predecessor’s declared system identities. Do not run server/install.sh or systemd-tmpfiles:

sudo systemd-sysusers "$PREDECESSOR_ROOT/server/sysusers/ahri-tre.conf"

Verify the required identities:

id ahri-tre-runtime
id ahri-tre-web
getent group ahri-tre
getent group ahri-tre-oidc

Create the root-owned projection root and shared traversal namespaces. Mode 0711 permits traversal to the separately restricted leaf directories; it does not make any Secret value readable:

sudo install -d -o root -g root -m 0755 /run/secrets
sudo install -d -o root -g root -m 0711 \
  /run/secrets/ahri-tre \
  /run/secrets/oidc \
  /run/secrets/postgres \
  /run/secrets/postgres/tls \
  /run/secrets/runtime

Verify this boundary before creating any leaf:

test "$(sudo stat -c '%U:%G:%a' /run/secrets)" = root:root:755
for namespace in ahri-tre oidc postgres postgres/tls runtime; do
  test "$(sudo stat -c '%U:%G:%a' "/run/secrets/$namespace")" = root:root:711
done

Recheck that no package or Managed-store boundary was installed:

sudo test ! -e /usr/share/ahri-tre/server/component-versions.json
sudo test ! -e /usr/libexec/ahri-tre/ahri-tre-runtime
sudo test ! -e /var/lib/ahri-tre/secrets

7. MinisForum and WSL2: issue the PostgreSQL leaf certificate

On the MinisForum, create a new PostgreSQL private key and public CSR. UID and GID 999 are the declared container identity; no host account named 999 is required.

sudo install -d -m 0700 /run/secrets/postgres/tls/private-key
sudo chown 999:999 /run/secrets/postgres/tls/private-key

sudo env OPENSSL_CONF=/dev/null openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out /run/secrets/postgres/tls/private-key/value
sudo chown 999:999 /run/secrets/postgres/tls/private-key/value
sudo chmod 0400 /run/secrets/postgres/tls/private-key/value

sudo env OPENSSL_CONF=/dev/null openssl req -new -key /run/secrets/postgres/tls/private-key/value -subj '/CN=postgres.svrltreapcc02.home.arpa' -addext 'subjectAltName=DNS:postgres.svrltreapcc02.home.arpa' -out /tmp/postgres.svrltreapcc02.home.arpa.csr
sudo chown sysadmin:sysadmin /tmp/postgres.svrltreapcc02.home.arpa.csr

In WSL2, copy and verify only the public CSR:

install -d -m 0700 /home/kobus/ahri-tre-pki/requests
scp sysadmin@192.168.31.75:/tmp/postgres.svrltreapcc02.home.arpa.csr /home/kobus/ahri-tre-pki/requests/
openssl req -in /home/kobus/ahri-tre-pki/requests/postgres.svrltreapcc02.home.arpa.csr -verify -noout

Create the public leaf-certificate extensions:

printf '%s\n' 'basicConstraints=critical,CA:FALSE' 'keyUsage=critical,digitalSignature,keyEncipherment' 'extendedKeyUsage=serverAuth' 'subjectAltName=DNS:postgres.svrltreapcc02.home.arpa' > /tmp/postgresql-server-certificate.ext

Sign the CSR with the candidate-matching PostgreSQL CA:

sudo openssl x509 -req -sha256 -days 825 -in /home/kobus/ahri-tre-pki/requests/postgres.svrltreapcc02.home.arpa.csr -CA /home/kobus/ahri-tre-pki/public/postgresql-ca-chain.pem -CAkey /home/kobus/ahri-tre-pki/private/postgresql-ca-private-key.pem -CAcreateserial -extfile /tmp/postgresql-server-certificate.ext -out /home/kobus/ahri-tre-pki/public/postgres.svrltreapcc02.home.arpa.pem

Copy only the public leaf certificate to the MinisForum:

scp /home/kobus/ahri-tre-pki/public/postgres.svrltreapcc02.home.arpa.pem sysadmin@192.168.31.75:ahri-tre-conformance/input/

On the MinisForum, install and verify the public certificate:

sudo install -D -m 0444 /home/sysadmin/ahri-tre-conformance/input/postgres.svrltreapcc02.home.arpa.pem /etc/ahri-tre/postgresql/tls/certificate.pem
sudo chown 999:999 /etc/ahri-tre/postgresql/tls/certificate.pem

sudo env OPENSSL_CONF=/dev/null openssl verify -CAfile "$CANDIDATE_ROOT/site/postgresql/public-ca-chain.pem" /etc/ahri-tre/postgresql/tls/certificate.pem
sudo env OPENSSL_CONF=/dev/null openssl x509 -in /etc/ahri-tre/postgresql/tls/certificate.pem -noout -checkhost postgres.svrltreapcc02.home.arpa

sudo stat -c '%u:%g:%a %n' /etc/ahri-tre/postgresql/tls/certificate.pem /run/secrets/postgres/tls/private-key/value

Expected modes are 999:999:444 for the public certificate and 999:999:400 for the private key. Remove the public CSR from the MinisForum:

rm -- /tmp/postgres.svrltreapcc02.home.arpa.csr

8. MinisForum: create fresh PostgreSQL password projections

Create the protected directories:

sudo install -d -o root -g root -m 0700 /run/secrets/postgres/bootstrap-password /run/secrets/postgres/administrator-passfile
sudo install -d -o ahri-tre-runtime -g ahri-tre-runtime -m 0700 /run/secrets/postgres/administrator-password

Start a temporary root shell:

sudo bash

At the # prompt, paste this complete block:

set -eu
umask 077
postgres_password="$(env OPENSSL_CONF=/dev/null openssl rand -hex 32)"
printf '%s' "$postgres_password" > /run/secrets/postgres/bootstrap-password/value
printf '%s' "$postgres_password" > /run/secrets/postgres/administrator-password/value
printf '%s\n' "postgres.svrltreapcc02.home.arpa:5432:*:ahri_tre_administrator:${postgres_password}" > /run/secrets/postgres/administrator-passfile/value
unset postgres_password
printf '%s' 'site-v3' > /run/secrets/postgres/administrator-password/version
chown root:root /run/secrets/postgres/bootstrap-password/value /run/secrets/postgres/administrator-passfile/value
chmod 0400 /run/secrets/postgres/bootstrap-password/value
chmod 0600 /run/secrets/postgres/administrator-passfile/value
chown ahri-tre-runtime:ahri-tre-runtime /run/secrets/postgres/administrator-password/value /run/secrets/postgres/administrator-password/version
chmod 0400 /run/secrets/postgres/administrator-password/value /run/secrets/postgres/administrator-password/version
exit

Verify equality without displaying the password:

sudo cmp --silent /run/secrets/postgres/bootstrap-password/value /run/secrets/postgres/administrator-password/value && echo 'PostgreSQL password projections match'

9. Browser and MinisForum: project the ORCID client Secret

Read the public client ID and callback from the candidate:

jq -r '.oidc.client_id, ("https://" + .runtime_dns_name + "/v1/runtime-login/callback")' "$CANDIDATE_ROOT/site/site-inputs.json"

In a browser, sign in to ORCID Sandbox Developer Tools. Open the application with that exact public client ID, confirm that the displayed callback URI is identical, and copy its client Secret.

On the MinisForum, create the protected directory:

sudo install -d -o root -g ahri-tre-oidc -m 0750 /run/secrets/oidc/client-secret

Start a temporary root shell:

sudo bash

Read the Secret without terminal echo:

IFS= read -r -s -p 'Paste the ORCID Sandbox client secret, then press Enter: ' orcid_client_secret

Then run:

printf '\n'
test -n "$orcid_client_secret"
umask 027
printf '%s' "$orcid_client_secret" > /run/secrets/oidc/client-secret/value
unset orcid_client_secret
printf '%s' 'site-v3' > /run/secrets/oidc/client-secret/version
chown root:ahri-tre-oidc /run/secrets/oidc/client-secret/value /run/secrets/oidc/client-secret/version
chmod 0440 /run/secrets/oidc/client-secret/value /run/secrets/oidc/client-secret/version
exit

Verify only ownership and modes:

sudo stat -c '%U:%G %a %n' /run/secrets/oidc/client-secret/value /run/secrets/oidc/client-secret/version

Both lines must begin root:ahri-tre-oidc 440.

10. WSL2 and MinisForum: project the Runtime private key

In WSL2, make a temporary protected transfer copy:

sudo install -o kobus -g kobus -m 0400 /home/kobus/ahri-tre-pki/private/runtime-private-key.pem /tmp/runtime-private-key.transfer
scp /tmp/runtime-private-key.transfer sysadmin@192.168.31.75:runtime-private-key.transfer
rm -- /tmp/runtime-private-key.transfer

On the MinisForum, project it and remove the transfer copy:

sudo install -d -o ahri-tre-runtime -g ahri-tre-runtime -m 0700 /run/secrets/runtime/private-key
sudo install -o ahri-tre-runtime -g ahri-tre-runtime -m 0400 /home/sysadmin/runtime-private-key.transfer /run/secrets/runtime/private-key/value
printf '%s' 'site-v3' | sudo tee /run/secrets/runtime/private-key/version >/dev/null
sudo chown ahri-tre-runtime:ahri-tre-runtime /run/secrets/runtime/private-key/version
sudo chmod 0400 /run/secrets/runtime/private-key/version
rm -- /home/sysadmin/runtime-private-key.transfer

Validate the projected key without printing it:

sudo -u ahri-tre-runtime env OPENSSL_CONF=/dev/null openssl pkey -in /run/secrets/runtime/private-key/value -check -noout

11. MinisForum and WSL2: create a new Deployment root identity

Never restore or reuse the identity from a deleted installation. On the MinisForum, generate a new X25519 identity:

sudo install -d -o root -g root -m 0700 /root/ahri-tre-recovery
sudo test ! -e /root/ahri-tre-recovery/conformance-root-identity.txt

sudo bash -c 'set -eu; umask 077; age-keygen | sed -n "/^AGE-SECRET-KEY-1/p" > /root/ahri-tre-recovery/conformance-root-identity.txt; test -s /root/ahri-tre-recovery/conformance-root-identity.txt'

Project it for the Runtime:

sudo install -d -o ahri-tre-runtime -g ahri-tre-runtime -m 0700 /run/secrets/ahri-tre/root-identity
sudo install -o ahri-tre-runtime -g ahri-tre-runtime -m 0400 /root/ahri-tre-recovery/conformance-root-identity.txt /run/secrets/ahri-tre/root-identity/value
printf '%s' 'site-v3' | sudo tee /run/secrets/ahri-tre/root-identity/version >/dev/null
sudo chown ahri-tre-runtime:ahri-tre-runtime /run/secrets/ahri-tre/root-identity/version
sudo chmod 0400 /run/secrets/ahri-tre/root-identity/version

Read the public Deployment UUID and create a temporary transfer copy:

DEPLOYMENT_ID="$(jq -r '.deployment_id' "$CANDIDATE_ROOT/site/site-inputs.json")"
sudo install -o sysadmin -g sysadmin -m 0400 /root/ahri-tre-recovery/conformance-root-identity.txt /home/sysadmin/conformance-root-identity.transfer
printf 'Deployment identity: %s\n' "$DEPLOYMENT_ID"

In WSL2, set the same public Deployment UUID from the reviewed candidate:

DEPLOYMENT_ID="$(jq -r '.deployment_id' /home/kobus/ahri-tre-conformance/input/review/ahri-tre-test-datastore-deployment-kit-0.3.14/site/site-inputs.json)"
RECOVERY_ROOT="/home/kobus/ahri-tre-recovery/conformance-${DEPLOYMENT_ID}"
install -d -m 0700 "$RECOVERY_ROOT"
test ! -e "$RECOVERY_ROOT/root-identity.txt"

If the last command fails, stop. Resolve the previous backup explicitly; do not overwrite it or silently reuse it. Retrieve and verify the new identity:

scp sysadmin@192.168.31.75:/home/sysadmin/conformance-root-identity.transfer "$RECOVERY_ROOT/root-identity.txt"
chmod 0400 "$RECOVERY_ROOT/root-identity.txt"
grep -q '^AGE-SECRET-KEY-1' "$RECOVERY_ROOT/root-identity.txt" && echo 'Separate root-identity backup is valid'

Back on the MinisForum, remove the temporary transfer copy:

rm -- /home/sysadmin/conformance-root-identity.transfer

Keep this identity separate from the encrypted Datastore backup and from the conformance evidence bundle.

12. MinisForum: verify the prepared boundary

Display only ownership and modes:

sudo stat -c '%U(%u):%G(%g) %a %n' /run/secrets /run/secrets/ahri-tre /run/secrets/oidc /run/secrets/postgres /run/secrets/postgres/tls /run/secrets/runtime /run/secrets/postgres/bootstrap-password/value /run/secrets/postgres/administrator-password/value /run/secrets/postgres/administrator-password/version /run/secrets/postgres/administrator-passfile/value /run/secrets/postgres/tls/private-key/value /run/secrets/oidc/client-secret/value /run/secrets/oidc/client-secret/version /run/secrets/runtime/private-key/value /run/secrets/runtime/private-key/version /run/secrets/ahri-tre/root-identity/value /run/secrets/ahri-tre/root-identity/version

Required results are:

  • bootstrap password: root:root 400;
  • administrator password and version: ahri-tre-runtime:ahri-tre-runtime 400;
  • administrator passfile: root:root 600;
  • PostgreSQL private key: numeric 999:999 400;
  • ORCID client Secret and version: root:ahri-tre-oidc 440;
  • Runtime private key and version: ahri-tre-runtime:ahri-tre-runtime 400; and
  • root identity and version: ahri-tre-runtime:ahri-tre-runtime 400.

The host may display unrelated names for UID or GID 999; the numeric values are authoritative. Never use cat, less, head, or an editor on a Secret value file.

Verify every declared candidate projection exists, is a regular file rather than a symbolic link, and has the declared numeric owner, group, and mode:

while IFS=$'\t' read -r path owner group mode; do
  sudo test -f "$path" || exit 1
  sudo test ! -L "$path" || exit 1
  test "$(sudo stat -c '%U' "$path")" = "$owner" ||
    test "$(sudo stat -c '%u' "$path")" = "$owner" || exit 1
  test "$(sudo stat -c '%G' "$path")" = "$group" ||
    test "$(sudo stat -c '%g' "$path")" = "$group" || exit 1
  test "$(sudo stat -c '%a' "$path")" = "${mode#0}" || exit 1
done < <(sudo jq -r '.projections[] | [.projection_path, .owner, .group, .mode] | @tsv' "$CANDIDATE_ROOT/site/secret-projection-plan.json")

Reconfirm the clean-host installation boundary:

sudo test ! -e /usr/share/ahri-tre/server/component-versions.json
sudo test ! -e /usr/libexec/ahri-tre/ahri-tre-runtime
sudo test ! -e /var/lib/ahri-tre/secrets
sudo test ! -e /data/ahri-tre/postgresql
sudo docker inspect ahri-tre-postgresql >/dev/null 2>&1; test $? -ne 0

Preparation is complete only when every check exits zero. Do not reboot: the temporary inputs beneath /run/secrets are intentionally ephemeral.

13. MinisForum: hand off to the conformance harness

Create an evidence directory that contains no other files:

sudo install -d -o root -g root -m 0700 /var/backups/ahri-tre/conformance-evidence
sudo test -z "$(sudo find /var/backups/ahri-tre/conformance-evidence -mindepth 1 -maxdepth 1 -print -quit)"

Set the public Deployment confirmation and replace the safe identity placeholder with the canonical admitted ORCID Sandbox iD that will be used throughout the qualification:

DEPLOYMENT_ID="$(jq -r '.deployment_id' "$CANDIDATE_ROOT/site/site-inputs.json")"
SAFE_IDENTITY=REPLACE_WITH_ADMITTED_ORCID_ID

Invoke the harness from the extracted candidate while passing the original archives and their exact checksum declarations:

sudo "$CANDIDATE_ROOT/conformance/run.sh" server \
  --kit-archive "$INPUT_ROOT/ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz" \
  --kit-sha256 "$INPUT_ROOT/ahri-tre-test-datastore-deployment-kit-0.3.14.tar.gz.sha256" \
  --predecessor-archive "$INPUT_ROOT/ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz" \
  --predecessor-sha256 "$INPUT_ROOT/ahri-tre-test-datastore-deployment-kit-0.3.12.tar.gz.sha256" \
  --evidence-dir /var/backups/ahri-tre/conformance-evidence \
  --confirm-clean-host svrltreapcc02 \
  --confirm-host svrltreapcc02 \
  --confirm-address 192.168.31.75 \
  --confirm-deployment "$DEPLOYMENT_ID" \
  --confirm-datastore ahri-tre-test \
  --safe-identity "$SAFE_IDENTITY" \
  --backup-name conformance-0.3.14

The command must print Linux server installed-package evidence outcome=go. From this point onward, use the same candidate archive bytes and checksum for every workstation, recovery, cleanup, and finalization phase. Never copy a Secret projection or root identity into conformance evidence.

Continue with Running Installed-Package Conformance, which gives the complete backup, restore, WSL2 recovery, rollback, macOS, cleanup, and finalization sequence without requiring an issue or ticket.