kevinveenbirkenbachandClaude Opus 5.5
eb7056dafd
Main CI run 40976399687, socialhome#0 (swarm, tor, centos): the CLI tests
of svc-net-tor (onion:25 "socks CONNECT failed with reply 0x01") and
web-app-stalwart (probe_mail relay: ConnectionRefusedError on port 25)
failed. dockerd on the manager had aborted the whole ingress program of
the mail stack:
Failed to add ingress: failed to program ingress ports:
failed to bind host port 0.0.0.0:993/tcp: address already in use
/proc/net/tcp named the squatter: 192.168.244.10:993 -> :2049, the
node's own NFS client. The mount carries no noresvport, so the kernel
drew a source port from the 665-1023 reserved window and landed on
imaps. None of 25/465/993/995/4190/8095 got a DNAT rule or a
docker-proxy listener while every other published port did, and
stalwart still reported healthy because its healthcheck runs inside the
container. 993 and 995 are the only published ports inside that window,
so this is luck of the draw on any NFS-backed swarm host that runs the
mail role.
mount_opts now emits noresvport. insecure on the kernel-flavor export is
the other half: kernel nfsd defaults to secure and answers a mount from
an unprivileged source port with EACCES. It reaches the kernel flavor
only; ganesha already accepts unprivileged clients.
What it costs: the next deploy of every existing NFS client sees a
pending opts change and remounts the shared state; a host-side job
holding that path at that instant fails loudly. A plain remount may keep
a running mount on its old reserved port until the next real mount.
Port of f46c4d0bab from feature/store-i18n, applied identically so the
later store-i18n -> main merge stays conflict-free.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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-serveron Debian / Ubuntu,nfs-utilson Arch / RHEL / Fedora / Alpine. - Inventory-driven ACL: Allowed-IP list derives from the
svc-swarm-nodegroup; unrelated hosts cannot mount. - Reload-on-change: Re-running the role overwrites
/etc/exportswith the current allowed-IP set; the handler reloads viaexportfs -raonly 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).