Home

Welcome to the salt wiki!

Google User/Groups to Linux User/Groups mapping

Google users and google groups share the same name space. blah@pennbrain.upenn.edu may be either a user or a group, but not both.

Therefore you can not have a docker@pennbrain.upenn.edu user (which you need to ensure the images are consistent across the cluster) and a docker@pennbrain.upenn.edu group with a list of users allowed to use the docker service.

Other oddities:

• google groups do not have a natural way to store the group id
• google groups allow members to be both users and groups, while linux groups membership is only effective for users. You may list a linux group as a member of another group, but the membership is not recursive.

Design Compromises: The user/group id range will be mirrored so any user id above 1000 will be used as a group id for a group of the same name.
Every group id specified above 1000, will be the uid for the group of the same name. The id ranges are divided into three ranges:

• 1100 - 1999 and increasing service accounts for installed software which have to be available across the cluster, such as munge, slurm, and docker.
• 2000 - 3000 and decreasing collective groups for user memberships for who has login, who gets to use special queues
• 3001 - inf and increasing normal users

In order to ensure users have a group when they login, their user group will be copied from their posix account information into the cloud-config metadata.

Cloud-config only provides the name and membership of the group. This will mean the base images will have to be updated frequently with the new group info to keep them in sync We should only need to worry about groups that have to maintain their gids across NFS mounts. Membership within a single node is not a problem.

Service account users need a way to specify the user and group ids and the membership lists. The membership could be specified at the organization level, but may make more sense to maintain at the cluster level and copy the service account memberships out of the controller's group files. It will be important to maintain the same gid for all service accounts and it doesn't seem obvious how to ensure this.

Collective groups do not need a presents in the linux user space.