What this prompt does
This prompt builds a user management automation suite for [server_count] [distro] servers handling [user_count] users across [group_structure] groups. It reads a CSV roster (name, email, department, role, ssh_public_key, start_date, end_date) to create or update accounts with [default_shell] and group memberships, places authorized_keys with correct permissions, configures per-role sudoers via [role_permissions] using validated drop-in files, offboards by disabling rather than deleting accounts, generates a quarterly access audit flagging accounts inactive over [inactive_days] days, and syncs state across servers via [sync_method] with a dry-run.
The variables define your access model. [group_structure] and [role_permissions] map roles to groups and sudo rights, [inactive_days] sets the audit's staleness flag, and [sync_method] propagates changes across the fleet. The disable-not-delete offboarding and visudo syntax checking are deliberate safeguards: the former preserves home directories as archives, the latter prevents a broken sudoers file.
When to use it
- Onboarding and offboarding access is rotting because it is done manually
- Driving user lifecycle from a CSV roster instead of ad-hoc commands
- You insist on disable-not-delete for offboarding to preserve home directories
- Configuring per-role sudoers safely with visudo syntax checking
- Producing a quarterly audit that flags accounts inactive over a threshold
- Synchronizing user state across many servers with a dry-run preview
Example output
You get scripts that parse the CSV roster and create or update accounts, write authorized_keys with 700/600 permissions, generate /etc/sudoers.d drop-in files validated with visudo per [role_permissions], an offboarding routine that locks, expires, kills sessions, and archives the home directory, a quarterly audit report of users, groups, sudo privileges, last login, and inactive accounts, and a [sync_method]-based sync with dry-run.
Pro tips
- Always run the dry-run before applying; seeing planned account and permission changes across
[server_count]servers prevents a surprise mass change - Keep offboarding as disable-not-delete so a departed user's home directory survives as an archive for audit or handover
- Validate every sudoers change with visudo via the drop-in approach; a syntax error in sudoers can break sudo for everyone
- Make
[role_permissions]least-privilege — readonly-ops viewing logs should not inherit broader rights by accident - Treat the
[inactive_days]audit flag as actionable; stale accounts are exactly the ones that quietly become a risk - Ensure authorized_keys permissions land at 700 for .ssh and 600 for the file, or SSH will silently refuse the key
- Drive everything from the CSV roster as the single source of truth, including start_date and end_date, so onboarding and offboarding are a data change rather than a manual ssh-into-each-box chore
- Keep
[group_structure]and[role_permissions]aligned; if a role's group membership and its sudoers entry drift apart across[server_count]servers, you get users who can do more or less than the roster intends
