Everything bosun add creates on disk — ACLs, .env, deploy.conf, systemd units, RVM/gemsets — and why.
sudo bosun add myapp # one-time per app, run as root/sudoThis provisions /var/www/myapp with:
2775) on every directory, so new files/dirs are owned by the webapps group regardless of which developer created them.setfacl -d -m g:webapps:rwX) granting the group effective write access on anything created inside, independent of the umask 027 that argus-tty's profile.d/developer-restrictions.sh already applies to every developer/admin login — without that ACL, umask 027 would strip the group-write bit and one developer couldn't edit another's files./var/www/myapp/shared/.env — an empty, 600 root:root file for this app's env vars (DATABASE_URL, SECRET_KEY_BASE, etc.), plus a single named-user ACL read grant for webapp-svc. Deliberately not webapps-group readable — see permissions.md for why, and edit it with sudo vi /var/www/myapp/shared/.env./var/www/myapp/shared/deploy.conf — 660, holds RUBY_VERSION, RUBY_GEMSET, PROJECT_REPO_URL, KEEP_LATEST_RELEASE (deploy-pipeline metadata, not a secret — that's .env above). Read by every deploy subcommand. Also where you can optionally set RELEASE_VERSION_CMD to override how deploy names each release — unset, it's a plain timestamp (unchanged default); e.g. RELEASE_VERSION_CMD='echo "$(date +%Y%m%d%H%M%S)-$(git rev-parse --short HEAD)"' makes releases traceable to a commit instead. Runs with the freshly cloned repo as its working directory, so git commands resolve.shared/bin/{puma,sidekiq}-exec — small wrapper scripts that resolve RUBY_VERSION@RUBY_GEMSET from deploy.conf at run time via RVM's per-gemset wrapper scripts, so the systemd units below never need editing when a developer bumps the ruby version.shared/bin/run — the same env-loading, but forwards arbitrary args instead of a fixed command: shared/bin/run rails console, shared/bin/run rake db:migrate. Use this for anything run by hand instead of invoking bundle/rails directly — see "Why a per-app .env file" below for why it exists instead of a gem.shared/.ruby-version / shared/.ruby-gemset (symlinked into current/ by deploy) — RVM's cd-hook auto-loads RUBY_VERSION@RUBY_GEMSET the moment you cd into current/ interactively, with no trust prompt. Deliberately not a .rvmrc (RVM's older mechanism): .rvmrc is arbitrary shell code RVM has to ask you to trust the first time — real interactive-login friction — and this toolkit's own .rvmrc used to also source shared/.env as whoever cd'd in, which would silently reopen the exact access .env's permissions now deny developer/deployer accounts (see permissions.md). Not generated at all anymore.puma-myapp.service / sidekiq-myapp.service — installed under /etc/systemd/system/, enabled but not started (there's no release yet). Run as webapp-svc, an unprivileged, no-login system account — not root, not a developer's own account. Developers start/stop/restart these via argus-tty's already-whitelisted systemctl {start,stop,restart} * sudoers entry; they have no way to create or edit unit files themselves, by design — only add (run by an admin) does that.shared/deploy_key / shared/deploy_key.pub — a git deploy keypair generated once for this app and distributed to every current developer/admin account, so deploy can git clone without anyone using their own personal SSH key. See deploy-key.md.Existing accounts created before this feature: bosun add (first app on a box), bosun bootstrap, and argus-tty add/add-admin/add-deployer all retrofit every current developer/admin/deployer account onto webapps/rvm automatically now — no separate sudo argus-tty reconfigure step needed just for this. An account with an already-open session still needs a fresh login to pick up new group membership (a PAM limit, not something any script can work around).
Why a per-app .env file instead of the box-wide /etc/environment: /etc/environment is sourced into every login shell and PAM session on the host — including admins'. Any sudoers rule broad enough to let developers edit it (even a "restricted" wrapper) is a realistic path to tampering with root's environment (LD_PRELOAD, BASH_ENV, arbitrary vars) on next login — a bigger hole than argus-tty's whitelist model is designed to allow. shared/.env confines each app's secrets to that app's own directory permissions instead — and, on top of that, its own permissions are tighter than the rest of the app tree (root + a named-user ACL grant for webapp-svc only, not the webapps group — see permissions.md): even a compromised or malicious developer/deployer account has no standing read access to it at all.
add/do-release wire this up with no gem dependency (deliberately not dotenv-rails — a plain .env file does nothing on its own without something to read it, and we didn't want that something to be a Gemfile addition every app has to carry): the puma-<app>/sidekiq-<app> systemd units load it via EnvironmentFile=-shared/.env (read by root, so .env's tight permissions don't matter there), and, redundantly, the puma-exec/ sidekiq-exec wrapper scripts also source it before exec'ing — they run as webapp-svc, which has the ACL grant. For anything run by hand — rails console, rake, migrations — use bosun run (e.g. bosun run console myapp) instead of invoking bundle/rails directly; it elevates to webapp-svc to load the same deploy.conf/shared/.env before running whatever command you pass it, without requiring the calling developer/admin's own account to read .env directly.
RVM / gemsets: this toolkit does not install RVM as part of add — run sudo bosun bootstrap once per host instead (root, one-time; see walkthrough.md). It installs RVM in multi-user mode (a system-wide /usr/local/rvm and an rvm group). Once that group exists, every developer/admin/deployer account (new, or retrofitted automatically by bootstrap itself) is added to it automatically — as is the webapp-svc service account, which also needs rvm membership to actually load the gems it runs — so ruby/bundle/rails/gemset commands work with no sudo needed.
bootstrap also cleans up conflicting per-user RVM installs every time it runs (not just on first install) — e.g. ~ubuntu/.rvm from someone having run RVM's installer directly on some account before this toolkit's multi-user /usr/local/rvm existed. A per-user install auto-loads via a line in that account's .bashrc/.bash_profile, and RVM's own scripts aren't safe to load twice — the symptom is a login (or anything with a login-shell shebang) crashing with ... unbound variable (e.g. rvm_bash_nounset or _system_name), which has nothing to do with whatever command happened to trigger it. bootstrap finds every /home/*/.rvm and /root/.rvm, strips the auto-load line from that account's shell rc files, and leaves the actual .rvm directory in place (never auto-deletes gemset data) — remove it yourself once you've confirmed nothing still depends on it.