Stop roles overwriting each other's directory ownership #12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/foundry-k3s-cluster-4057a8"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two roles were managing the same directory with different intentions, so every converge applied both and reported a change. There were two instances of it, at different paths.
/mnt/storestoragesetroot:root 0755;sambathen setjosh:foundry 2775. Beyond the noise, it left the share root owned by root for the part of every run between the two roles.They were each right about a different thing, which is why neither looked wrong on its own:
storagecares about the mount point — a bare directory that should be root-owned so a failed or missing mount cannot silently accept writes onto the root filesystem with group-writable permissions.sambacares about the share root — which, once the G-DRIVE is mounted, is the same path but a different inode entirely: the mounted filesystem's root, which has to be group-writable and setgid for the share to work.storagenow enforces ownership only while the path is not a mount point, and otherwise leaves the attributes alone. Both properties hold and neither role overwrites the other./var/log/foundryThe same conflict at a second path, found while checking the remaining churn. Both roles wanted
foundry_owner:foundry_group, so they agreed on everything except the mode:rcloneasked for0750,self_pullfor2775.2775wins. The directory is shared rather than either role's own, so setgid keeps new files in thefoundrygroup whichever identity writes them — a root-run process cannot leave a file the group is unable to manage. The log files themselves are0640, so widening the directory does not widen access to their contents.0750is tighter and correct while the rclone timer is the only writer, but it breaks silently the moment anything else writes there.rclone's hardcoded mode becomes
rclone_backup_log_dir_modeso the value sits next to the path it applies to, and both roles' defaults now carry a comment naming the other — nothing in the repo previously recorded that these two share a directory.Verification
Full
foundry.ymlconverge:failed=0on all three nodes. Foundry's churn drops from 10 changed tasks to 6, and the four that disappear are exactly the conflicting ones:storage : Ensure G-DRIVE mount point existssamba : Ensure Samba share directories existrclone : Ensure rclone backup log directory existsself_pull : Ensure foundry state directories existFinal state on the host is stable and correct —
/mnt/store,/var/log/foundryand/var/lib/foundryat2775 josh:foundry,/etc/foundryat750 root:foundry. Cluster healthy, ServiceLB label still onfoundry-blackalone,git.emkaytec.comreturning 200.Not addressed
The remaining 6 changed tasks are pre-existing in
developer_clisand are not conflicts — the AWS CLI re-downloading and reinstalling itself on every run (5 tasks), andnpm -g @latest(1). They are tasks that cannot report accurately rather than roles fighting each other.One related fragility surfaced while verifying, worth recording even though it is out of scope here:
developer_clismakes unauthenticated GitHub API calls on every converge to check for new releases, against a 60-requests-per-hour limit shared across the whole source IP. Repeated converges exhausted it and failed a run with403 rate limit exceededonapi.github.com/repos/sst/opencode/releases. The hourlyansible-pullspends from the same budget, so a converge can fail for reasons unrelated to the infrastructure. Authenticating those calls or caching the version check would fix it.