The Regis system is a system in place to distribute the /etc/passwd and the /etc/group files through the computer center. This system has shown not to meet the requirements that have evolved over the Years and needs reviewing.

This document describes all the requirements the Regis replacement System Zuul should have.

In this text I will always be talking in the masculine form. This is done out of ease, I apologize to anyone who feels disturbed through this

This is purely an requirements document. It should document what is done and not how.

Tasks

• Enable a user to logon to a machine (passwd and Kerberos)
• Enable local users to exist (like root, operator)
• Restrict cluster to user group
• Somehow synchronize uid and gid

Actors

• Manually, RPM-Scriptlets (adduser,addgroup)
• Sindes
• CRA

What is required (functional)

Here everything is listed and explained what the replacement system should have in functions. These are just bullet-points.

Respect accounts added locally

When useradd or groupadd are run the group or user should be added to the files \footnot meaning /etc/passwd and /etc/grou and stay on the system. So the rpm install scripts can work correctly.

A user must be able to belong to more than one group

It must be possible that a user can be added to secondary groups. Every user must have one primary group and can have n secondary groups

There must be a mechanism to select users or groups for specific clusters

It must be possible to alter the password file, in a automated way, so that only a special group of users can access a cluster.

UID and GID synchronized

User Ids and Group Ids should be synchronized through out the clusters. Duplicate entries should be avoided.

Root passwords based on passwd-database

The root or other passwords of the clusters or machines should be taken out of the already existing password-database. This is the system where the passwd.header file is now generated out of. This should still be used.

Root password change (Sindes)

It must be possible to remotely change the root, operator, etc passwords.

What is required (operational)

Here everything is listed and explained what the replacement system should have in an operational sense.

Backup strategy

There must be a clear Backup strategy especially if there is a single point of failure

Disaster Recovery

There must be a document describing all the steps to get \didiprojectname up and running again after an error.

System and application health

There must be a sytem in placete to monitor the overall health of the system (Error count,...) (ELFms)

System and application performance monitoring

There must be a system in place to monitor the overall load and performance of the system (ELFms)

Must scale appropriate

The system is not allowed to scale $x^2$ or worse. Scale linear would be the ideal case

Installation must be well documented

The installation of the system must be documented, so that someone who doesn't know the system, can install it.

RHEL4+ (SL4+)

As Red Hat Enterprise Linux is used at Cern \didiprojectname should work on the currently running version and on foreseeable version too.

Every step taken, must be logged

A logfile should be generated at all times wherever appropriate. How and where this is done (syslogd or other) is to be clarified

Security

Every computer must have a root user at all times

Root access must be able at all times. The case where no root user is in the files is not allowed.

Boundary for information security

The data that has to be protected in a special way is: any password in any form

What isn't required

Here everything is listed and explained what the replacement system shouldn't have.

Reinvent the Wheel

The system should use standardized techniques where possible.

Single point of failure

Because of the importance of the service a single point of failure should be avoided. If it is implemented security and uptime should be considered closely.

Soft Real Time

It is acceptable that an update can take up to one hour, to propagate through the system.

People to talk to

• VAN ELDIK Jan 71416 162739 IT FIO 31 1-010
• BAHYL Vlado 71884 IT FIO 31 1-002
• THE DB GUY

Typical Examples

• RPM install An RPM install script calls adduser to create a local user account
• A admin want's to add a user
• A root user leaves and the root password of all machines in a cluster has to be changed
• A AFS/Kerberos user logs on to a machine over ssh
• A root user whant's to restrict a cluster or machine to a special group of users (c3 for example)
• A user changes his default shell in CRA. This has to take affect on all machines he can logon.
• A user is created in CRA.

Explanations

• local user accounts Are accounts where the home directory is mounted locally or the password is stored locally. So not over AFS. There are 3 different possibilities here
  • Home dir mounted locally and the password still validates over Kerberos
  • Home dir over AFS but the password is stored locally
  • Home dir and password are stored on the machine

-- GeerdDietgerHoffmann - 20 Sep 2007