ARD07: Account Strategy
Status
Proposed (in progress — not yet decided or implemented)
Context
History
The tim user was created on RPi hosts to match the Mac username, so that ssh rpi
worked without specifying a user. This shortcut became unnecessary once ~/.ssh/config
gained explicit User directives for each host. The tim account on RPis is now
deprecated; ops is the standard RPi user for all provisioning and lab work.
Current state (Mac)
All lab work is done from the tim Mac account. This conflates personal and lab activity
in the same account, with the same environment, credentials, and shell history.
Motivation for change
Two related goals drive the desire for a separate lab account:
-
Separation of concerns. Lab-related SSH config,
opCLI sessions, shell history, and tooling should be isolated from everyday personal use. -
Handoff capability. The lab must be maintainable by a non-technical second person (partner/spouse) — now or in the event of incapacitation. That person needs a clear, documented entry point that does not depend on familiarity with Tim’s personal environment.
Decision
Not yet made. The following options and trade-offs are under consideration.
Option A: Separate macOS user account
Create a new local macOS account dedicated to lab work. Lab tooling, SSH config, 1Password setup, and shell environment live entirely in that account’s home directory.
Switch to it via su - <labuser> or by logging in directly.
Name candidates: ops (mirrors RPi convention), lab, homelab
Considerations:
- Clean separation — no cross-contamination with personal environment
- 1Password: the lab account would need its own 1Password app session, or would need to share Tim’s 1Password (family plan — both accounts can access the Lab vault)
- The SSH agent socket path is per-user; the lab account needs its own 1Password SSH agent configuration
sudoaccess from the lab account needs to be granted appropriately- A second person logging into this account needs the macOS login password and 1Password credentials — both must be documented and recoverable (e.g. stored in 1Password Emergency Kit or a shared vault)
Option B: Stay in one Mac account, add role-switching via shell aliases or scripts
Keep a single Mac user, but create a clearly scoped shell environment (e.g. a dedicated
~/.lab directory, a lab-shell alias that drops into an environment with the correct
PATH, SSH_AUTH_SOCK, and OP_* vars set).
Simpler to set up, but does not achieve true isolation and makes handoff harder — a second user still needs to understand Tim’s overall environment.
Option C: Dedicated lab workstation or VM
A separate machine (physical or VM) that is the designated lab workstation. Lab accounts exist only there. The second person uses that machine/VM for all lab work.
Higher overhead but strongest isolation and clearest handoff story.
Handoff Requirements
Whatever account strategy is chosen, the following must be true for the handoff goal to be met:
- The second person can log in without Tim present
- Credentials needed to log in are stored in a shared 1Password vault or Emergency Kit
- There is a documented “getting started” guide pitched at a non-developer audience covering: how to SSH into a Pi, how to restart a service, who to call for what
- The account has access to the Lab, devLab, and prodLab 1Password vaults (or a curated subset sufficient for day-to-day maintenance)
Open Questions
- What should the lab account username be? (
ops,lab,homelab) - Should the RPi
opsusername change to match the Mac lab account name, or stayops? - How does 1Password family sharing work for the lab account — separate 1Password account for the second person, or shared credentials?
- What is the minimum set of tasks the second person needs to be able to perform? (Restart a service? Reprovision a Pi? Just check if things are running?)
Consequences (anticipated)
- RPi
opsusername may be renamed to match the Mac lab account (requires reprovisioning) ~/.ssh/configand provisioning scripts updated to reference new username- A “lab workstation setup” runbook will be needed
- Handoff documentation becomes a first-class artifact alongside technical docs