RATS V2 Proposal and Requirements

It has become obvious that some of our larger systems can no longer perform at optimal levels while continuing to use some the classic account maintenance procedures that we are used to.  One of the primary problems is the size of password and group files on systems with over 10000 users.  To solve this problem, and to put down the foundation for other future projects we propose a  number of improvements to the current RATS system. Note that none of these changes imply that we will not continue to support the standard features now supported. Smaller systems will be able to continue to use the flat file model.
 

New Proposed Features:

1. A client database back end for the RATS clients. This will allow for fast updates and lookups, plus the ability to reform the data in any format that may be required by future projects and RUCS directions.
2. Better handling of special account types.  We seem to use a lot of account types which are not directly attached to real humans. Better handling is required.
3. Advanced account maintenance procedures. As anyone of person may have a multitude of changing roles and privileges on the same host, we need a better way to change and maintain data relating to these states. The ability to easily and automatically remove only some of a users privileges is needed.
4. Improved configuration. The current RATS configuration files are very powerful but also quite hard to manage for various system administrators. We intend to retain the flexibility but reduce the complexity.
5. Optimization. Due to the hurried nature of the initial RATS implementation a considerable amount of work should still go into cleanup and optimization of the current code base.
6. Increased automation. Many account related tasks are still performed by hand or by rules known to a select few. Some of these tasks should be automated, and consequently, the policy and procedure better defined.
7. Some new capabilities. A handful of capability enhancements have been requested during or after the development of RATS V1, and some of them should be incorporated in the new version
8. Continued support for current implementation.  Most of the new features will be relevant only to large (5000+ users) systems. We will make sure that the classic functionality and support for everyone else will be maintained and solidified.
9. Cleanup of existing username spaces. It is time to do the first cleanup of username spaces in PDB
10. Report tools for PDB. System administrators and staff have expressed interest in some tools that allow access to various PDB statistics and bulk data.

Non Goals:

1. Multi Cluster support. While we intend to allow for a multi cluster setup at some time in the future, no implementation is expected for V2
2. Determination and arbitration of RUCS wide computing policies. (at least not by the RATS core team)
3. Web interface for all system administration tasks. Out of scope for this project.
4. Automatic configuration.  This would be nice but time consuming.
5. Utilities not associated with creation or maintenance of accounts.
6. World Peace. Though it might help with RUCS Peace
7. Free Lunch. Though we will always accept one.

Consequences of Proposed Features:

1. The fallout of a database driven RATS client is that many of the classic account maintenance tools will need to be redesigned. For example vipw, chfn and so on would need replacements
2. While the time required to maintain large system may go down, the level of knowledge and experience required for the administrators of such systems may go up
3. Higher learning curve for system administrators.
4. A new suite of account info and consistency checking tools will need to be implemented.
5. Documentation must be greatly improved and the API clearly defined to allow for any other tools that the system administrators may wish to write.

Constrains:

1. Time.  For this RATS revision to be useful it must be delivered to the system administrators August 1 2000, giving them one month to experiment and configure their systems before the September student influx
2. A stringent design.  The design and implementation of the project should be well documented and reviewed by as many people as possible, to ensure that no essential features have been left out and that no major policy or implementation issues have been overlooked
3. Second System Syndrome. We must avoid adding every bell and whistle we can find to this project. Simplicity should be maintained as much as possible. This may mean that not all requested features may be included.

Requirements:

1. No new hardware resources need be allocated to this project. Current hardware will do just fine. (at this time)
2. People. We will need to be assisted by a few more people for various tasks. Bellow is a proposed list of required human resources, possible candidates, their original departments and approximate involvement.

Details

1. A breakdown of various tasks, interdependencies, and responsible people is available.
2. A  large gantt chart of the time table was can be found here.
3. A more detailed list of features and sub tasks.