homelab/SKILL.md at 7eb7072ec59ad11095f02cc3933a275d7d26c70e

validate / lint (push) Failing after 1s

Details

Not used enough to justify chasing the stale-NFS-handle issue on its
photos-art mount. Removes manifests/media/immich.yaml (Namespace, PVCs,
Deployments, Service, Certificate, IngressRoute), its secret script and
sealed secret, immich.home.arpa from both Pi-hole values files, its Dashy
dashboard tile, and all other repo references (READMEs, secrets-leak-scanner
scope, regen-sealed-secret example, .env.example).

Per explicit confirmation: this also means the live namespace's PVCs
(immich-library 50Gi, immich-postgres-data 20Gi, immich-ml-cache 10Gi, all
local-path with Delete reclaim policy) are intended to be deleted along with
it -- any photos actually uploaded to Immich's own library are gone once the
namespace is deleted, separately from the read-only NFS folders it browsed
(untouched either way, those live independently on nik-debian).

Git removal alone does not delete the live cluster resources -- the media
Application has prune: false. Manual `kubectl delete namespace immich` still
needed to actually free the namespace/PVCs/data.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-23 20:21:05 +09:00

2.4 KiB

Raw Blame History

name, description, disable-model-invocation

name	description	disable-model-invocation
regen-sealed-secret	Regenerate a committed -sealed.yaml SealedSecret from .env values. Use when rotating a secret or when a -secret.sh script needs to be run to refresh sealed output.	true

Regenerate the sealed secret for: $ARGUMENTS

This repo keeps sealed secrets and their source script side by side (e.g. manifests/home-services/discord-bot-secret.sh → manifests/home-services/discord-bot-sealed.yaml, manifests/home-services/ha-gateway-secret.sh → manifests/home-services/ha-gateway-sealed.yaml). The script is the source of truth; the *-sealed.yaml file is generated output.

Steps

Find the matching *-secret.sh script for the target secret (search manifests/**/*-secret.sh). If none exists yet, model the new one on manifests/home-services/discord-bot-secret.sh:

source "$(dirname "$0")/../../.env"
kubectl create secret generic <name> \
  --namespace=<namespace> \
  --from-literal=<KEY>="${ENV_VAR}" \
  --dry-run=client -o yaml \
  | kubeseal --controller-namespace=kube-system \
           --controller-name=sealed-secrets-controller \
           --format=yaml \
  > "$(dirname "$0")/<name>-sealed.yaml"

Confirm the source value is up to date in .env (copy from .env.example if the key is missing, then ask the user to fill it in — never invent a secret value).
Confirm kubeseal can reach the cluster's controller: kubeseal --controller-namespace=kube-system --controller-name=sealed-secrets-controller --fetch-cert should succeed against the live cluster (minisforum, context default).
Run the script: bash manifests/<area>/<name>-secret.sh.
Diff the resulting *-sealed.yaml — it should be the only file that changed, and it should NOT contain plaintext (sealed secrets are ciphertext under spec.encryptedData, unlike the raw kubectl create secret ... -o yaml output piped into it).
Commit only the regenerated *-sealed.yaml. Never commit the raw kubectl create secret --dry-run=client -o yaml output or .env itself.

If the secret should instead be created directly in-cluster without being committed (the runtime-script pattern, e.g. authentik-secret.sh), skip kubeseal entirely and pipe straight to kubectl apply -f - — don't sealed-secret something that was never meant to be committed.

2.4 KiB Raw Blame History

Steps

2.4 KiB

Raw Blame History