Computing E-Groups Management

What's new?

Computing Groups

The Computing Groups are now normal E-Groups and are manageable through the standard E-Groups interface: http://e-groups.cern.ch.

By default, the newly created accounts are not member of any Computing Group. The account is fully functionnal and can be used for nearly all operations (read mail, access AIS, etc).
However, the Computing Group is needed to get access to AFS and LXPLUS services. The Computing Group Administrator should add the newcomer's account too the appropriate computing group if AFS and LXPLUS are needed.

Group Administrators

Each Computing E-Group have an associated administrators E-Group, named groupname-admins.
Example: Computing E-Group ZP has a corresponding administrators E-Group ZP-Admins (see them live here)

The groupname-admins E-Group is static, and is managed by the groupname-admins group members themselves.

Management Tips

Static E-Group: Manual editing

The Group Administrators can continue to edit the Computing E-Groups manually, as they were doing before with CRA at account creation.
Instead of creating a user account in a specific Computing Group, the Group Administrator can add the user to the Computing E-Group, by adding the user (name or personID based search) or a specific account (to add secondary accounts to the Computing E-Group for example).
Adding a user by name can be done as soon as the user is registered in the HR / AIS application.

Dynamic E-Group: Automate the Computing Group membership

The power of E-Groups can now be used to manage the Computing Groups. Using dynamic criteria to fill a Computing E-Group will fully automate the membership generation.
Example: the ZP E-Group belonging to ATLAS could be automated using some criterion like Experiment=ATLAS, along with some other criteria to ensure a proper membership.

Tip: As manually adding members will always be required, we strongly suggest to use sub E-Groups, dynamic and static.
Example: ZP E-Group could have 2 sub E-Groups, one ZP-Dynamic-members and one ZP-Static-members allowing both automation and exceptions.

Moving from one group to another

In case a user is changing experiment, the Group Administrators will remove the user from one Computing E-Group and add him/her to the other Computing E-Group.
Note that in case of dynamic Computing E-Groups the change will be automatic.
The LXPLUS primary group will change, the new Computing E-Group will be added to AFS.
However, if the user wants his AFS home directory and files group to be changed, he will have to run a specific set of commands as described here.

Multiple Computing E-Groups scenario

For some reasons a user could require to be a member of 2 or more Computing E-Groups. Typical examples would be where a user has to continue working on an old experiment while starting on a new one.
The recommended action is to have each account in a different computing group, i.e.:

• Ask the user to create a Secondary Account through this portal.
• Add this secondary account to the second Computing E-Group he needs to be member of.
• Repeat the 2 actions above for any additional Computing E-Group the user needs to be member of.

If for some reason the user account is added to several Computing E-Groups, only the first (and original) Computing E-Group will be used for LXPLUS primary group. The other Computing E-Groups will be added to AFS, giving the appropriate AFS rights but the login environment will be set by the primary LXPLUS group.

Computing E-Groups and AFS

The membership in a Computing E-Group is reflected on AFS in the following way:

• Members of Computing E-Group 'xx' are members of AFS group 'cern:xx'
• Admins of Computing E-Group 'xx' (i.e. members of E-Group 'xx-admins') are members of AFS group 'xx'

The membership in these AFS groups is assigned at account creation and removed at account deletion.

As an extension of the current functionality provided by CRA, the corresponding E-Groups will be synchronized with their AFS counterparts in order to also reflect group changes. This will, however, not be active when the new account management becomes active initially, but phased in in-coordination with the corresponding group admins.