Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/wikioasis/salt/llms.txt

Use this file to discover all available pages before exploring further.

The users state implements a role-based access control system for all WikiOasis servers. Rather than managing individual users per host, administrators are assigned to groups (such as ops or mediawiki-admins). Each server’s pillar declares which groups are active on that host via server_groups. Salt then resolves the full list of users who should exist, creates their accounts and home directories, installs their SSH public keys on both their own account and on root, and writes fine-grained sudoers entries — all driven entirely from pillar data with no per-server templating needed.

​
Pillar structure

The users pillar is split across two files: a global users/init.sls that defines all known users and groups, and per-server overlays (e.g. users/servers/mediawiki.sls) that declare which groups are active on a given host.

​
server_groups

Declares which access groups are active on a server. Only users who belong to at least one listed group will have accounts created. 
server_groups:
  - ops
  - mediawiki-admins

​
users

A map of username → user definition. UIDs and GIDs start at 3000 to avoid conflicts with system accounts. 
users:
  thomas:
    fullname: Thomas
    ssh-keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBBENCQ1Vgjdl8ux9snbGF4s1SRbcU0EvaYlj7I51LWG zippybonzo@wikioasis.org
    uid: 3000
    gid: 3000
  unai:
    fullname: Unai
    ssh-keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICvwM20uHONQHh289mWK8VnvAod4FbuwML2gtyy8uBwj
    uid: 3001
    gid: 3001
  tali64:
    fullname: Tali64
    ssh-keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIq5RurEGzZPA38t64iDxOYwL/AT2JTLcwcIqHefM8VW user@user-HP-Laptop-15-fd0xxx
    uid: 3002
    gid: 3002

​
groups

Defines access groups, their GIDs, membership lists, and the exact sudoers privilege lines granted to members. 
groups:
  ops:
    gid: 7000
    description: root, on all servers
    members: [thomas, unai]
    privileges: ['ALL = (ALL) NOPASSWD: ALL']
  mediawiki-admins:
    gid: 7001
    description: elevated permissions on webservers
    members: [tali64]
    privileges:
      - 'ALL = (www-data) NOPASSWD: ALL'
      - 'ALL = (www-data) NOPASSWD: /usr/local/bin/mwdeploy *'
      - 'ALL = (ALL) NOPASSWD: /usr/sbin/service nginx *'
      - 'ALL = (ALL) NOPASSWD: /usr/sbin/service php8.4-fpm *'
      - 'ALL = (ALL) NOPASSWD: /bin/journalctl *'

​
revokedusers

Users listed under revokedusers are removed from the system. Salt calls user.absent with purge: True and force: True, removes any root SSH authorized keys, and cleans up their sudoers files. 
revokedusers:
  olduser:
    ssh-keys:
      - ssh-ed25519 AAAA... olduser@example.com

​
Group privilege system

ops

Full passwordless sudo on all servers. Members: thomas, unai. Assigned via server_groups: [ops].

mediawiki-admins

Scoped sudo for wiki operations: run commands as www-data, restart nginx and PHP-FPM, and read journals. Members: tali64.
For each group member, Salt writes a file at /etc/sudoers.d/<username>_<group> (mode 0440, owned by root) containing exactly the privilege lines defined in the group’s privileges list. This gives precise, auditable control without a shared sudoers file.

​
Passwordless sudo

All sudoers on WikiOasis servers use key-based SSH authentication only; no passwords are managed by Salt. The file /etc/sudoers.d/sudonopasswd (sourced from salt://users/files/sudoers.d/sudonopasswd) contains: 
%sudo	ALL = (ALL) NOPASSWD: ALL
This ensures members of the sudo group (populated automatically on Ubuntu minions) can escalate without a password prompt.

​
SSH key deployment

For each user resolved by server_groups, the state installs their SSH public keys in two locations:
  • /home/<username>/.ssh/authorized_keys — for direct user login
  • /root/.ssh/authorized_keys — for direct root access
This means an operator can SSH directly as root using their personal key, without requiring su or sudo for emergency access.

​
Revoking a user

1

Move user to revokedusers

Move the user’s entry from users: to revokedusers: in the pillar, keeping their SSH keys listed so they can be explicitly removed from authorized_keys.
2

Apply the users state

salt '*' state.apply users
3

Verify removal

Salt will call user.absent with purge: True (deletes home directory) and force: True (kills running processes), remove their SSH keys from root, and delete all /etc/sudoers.d/<user>_* files.
purge: True permanently deletes the user’s home directory. Ensure any important data (e.g. SSH known_hosts, local configs) is backed up before revoking.

​
Applying the state

salt '*' state.apply users
To target only a specific host: 
salt 'mw-us-east-011.ovvin.wonet' state.apply users

Build docs developers (and LLMs) love

Get started for freeTalk to us