0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-06 02:54:26 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 5 4986e80dd4 feat(readme): ask the reader for a domain the deployment can resolve

The Production block never set one. inventory provision writes only
ansible_connection for a local host, so DOMAIN_PRIMARY stayed at the
group_vars default of infinito.localhost and the deployment served a zone its
own resolver knows nothing about. CoreDNS templates answers for
INFINITO_DOMAIN_RE and nothing else, so every lookup of the deployment's own
name came back NXDOMAIN.

Mastodon is where that surfaced. tootctl accounts create validates the address
through EmailMxValidator, which resolves MX and then, for the domain itself,
A and AAAA. All six queries returned NXDOMAIN in run 33574056480, the
validator recorded email :unreachable, and the admin account was never created.
Only the guide rows were affected: the matrix rows write
DOMAIN_PRIMARY: "{{ lookup('env', 'INFINITO_DOMAIN') }}" into their host_vars
and resolve fine.

The template now carries DOMAIN=<your-domain> in both the host and the
container form and threads it into --vars, with the container form passing it
through the docker run boundary as well. The two guide runners substitute it
the way they already substitute the SSH key, so the replay deploys under
INFINITO_DOMAIN like every other CI deploy. compose_deploy.sh moves its env
load ahead of the substitutions to have the value; host_deploy.sh had no env
load at all.

A production reader is asked for a domain now instead of silently inheriting
infinito.localhost, which no real deployment wants either. The shipped default
keeps its value: sys-svc-nss documents that *.localhost resolves through the
myhostname NSS module without any zone, and host-side tasks lean on it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-02 18:30:25 +02:00

4.0 KiB

Raw Permalink Blame History

NFS Server

Description

NFS (Network File System) is a kernel-level protocol for sharing files over a network. The server exports a directory tree under defined access rules; clients mount it as if it were a local filesystem.

Overview

This role installs an NFS server in one of two flavors, the distro kernel server or userspace nfs-ganesha, selected per deployment. Both export the swarm state path to the resolved addresses of the svc-swarm-node group and to an additional CIDR allow-list; ganesha also exports the export base and squashes root there. Export options come from vars/main.yml for the kernel flavor and from the ganesha configuration template for ganesha. NFS server HA, Kerberos integration, and client-side mounting are out of scope; client mounts are handled by svc-storage-nfs-client.

Cosmos

The diagram places NFS Server in the Infinito.Nexus cosmos: the components it deploys (capabilities), the central services it consumes (dependencies), and its outward reach (federation and bridged external networks).

flowchart LR
    subgraph deps [Dependencies]
        dep_svc_bkp_nfs_2_local["svc-bkp-nfs-2-local 💻"]
    end
    subgraph role [svc-storage-nfs-server 💻]
        svc_nfs_server["nfs-server"]
        svc_nfs_backup["nfs_backup"]
    end
    subgraph dependents [Dependents]
        dpt_svc_bkp_nfs_2_local["svc-bkp-nfs-2-local 💻"]
        dpt_svc_storage_nfs_client["svc-storage-nfs-client 💻"]
    end
    dep_svc_bkp_nfs_2_local -. "0..1" .-> svc_nfs_backup
    svc_nfs_server -. "0..1" .-> dpt_svc_bkp_nfs_2_local
    svc_nfs_server -. "0..1" .-> dpt_svc_storage_nfs_client

Solid 1:1 edges are fixed relationships; dashed 0..1 edges are conditional (enabled only in matching deployments); red 0..0 edges are turned off in this role. Node markers show the role's deploy modes (💻 host, 🐳 compose, 🐝 swarm); ❌ marks a service that is explicitly turned off, and ⚙️ an Ansible role dependency declared in meta/main.yml.

Features

Distro-aware install: Installs nfs-kernel-server on Debian / Ubuntu, nfs-utils on Arch / RHEL / Fedora / Alpine.
Inventory-driven ACL: Allowed-IP list derives from the svc-swarm-node group; unrelated hosts cannot mount.
Reload-on-change: Re-running the role overwrites /etc/exports with the current allowed-IP set; the handler reloads via exportfs -ra only when the file changed.

Quick Setup

Development

Clone, set up the workstation, and deploy NFS Server onto the local stack:

git clone https://github.com/infinito-nexus/core.git
cd core
make onboard
make compose-deploy mode=reinstall apps=svc-storage-nfs-server full_cycle=false

Production

Install NFS Server directly onto the target machine: clone the repository, install the OS prerequisites and the repository toolchain, then deploy against localhost over a local connection (no SSH, no container):

git clone https://github.com/infinito-nexus/core.git
cd core
bash scripts/install/package.sh
make install
source scripts/meta/env/load.sh

APP=svc-storage-nfs-server
DOMAIN=<your-domain>
TLS_MODE=self_signed
SSH_PUBLIC_KEY="<your-ssh-public-key>"
INVENTORY=inventories/production
infinito administration inventory provision "$INVENTORY" \
  --inventory-file "$INVENTORY/devices.yml" \
  --host localhost \
  --include "$APP" \
  --vars "{\"TLS_MODE\": \"$TLS_MODE\", \"DOMAIN_PRIMARY\": \"$DOMAIN\", \"users\": {\"administrator\": {\"authorized_keys\": [\"$SSH_PUBLIC_KEY\"]}}}"
infinito administration deploy dedicated "$INVENTORY/devices.yml" \
  --password-file "$INVENTORY/.password" \
  --diff -vv

Credits

Implemented by Kevin Veen-Birkenbach. Part of the Infinito.Nexus Project and maintained by Kevin Veen-Birkenbach. Licensed under the Infinito.Nexus Community License (Non-Commercial).

4.0 KiB Raw Permalink Blame History