Moving to a DB based RATS implementation will require that most of the internal functions need to be able to operate on both flat files and a DB.

Currently each major internal function has a one to one pairing with an API call. Furthermore each of these functions is already split into two functional entities, one which decides on which host the operation should take place and dispatches it, and one which performs the operation on the local host.  The addition of the DB will fork the second entity further into two methods, one for flat files and one for DB access. Not all operations will require this. For example functions which create directories or copy files have no need to interact directly with the DB and as such would not be modified. The following are the currently existing calls which will need to be enhanced with DB manipulation abilities:

        30010:QSET will probably need to set quotas in a DB quota
        table. This is not directly related to the DB addition, but
        we are also going to try to streamline access to the UNIX quota
        management table.

        30040:ADDPWENT new password and shadow file entries will need
        to be made directly into the DB in addition to maintaining
        existing functionality

        30050:REMPWEN removal of password entries will also needs to
        support DB methods

        30060:ADDTOGRP will need to be able to add users the group
        tables in the DB

        30070:REMFRGRP will need to be able to remove users from group
        tables in the DB

        30140:RESERVE will need to be reimplimented to support DB based
        UID reservation as well as perhaps a better UID generation
        scheme

        30150:CHGSHELL will need to support changing a users shell in
        a DB table

        35010:GETUID will be able to retrieve an UID from a DB table

        35020:GETPWENT will also support retrieving getpwent() type
        info from the DB

        35040:GETGID will support lookups of GIDs in a DB

        35050:GETGROUP will be able to return a list of groups for
        an user according the DB

        35060:GETUSERS will be able return a lost of real and reserved
        users according to a DB

        35070:GETGRNAM will support retrieving getgrnam() type info
        from the DB

        35080:GETSHENT will support retrieval of shadow file info from
        the DB

        35090:EXUSER should be able to verify that a user exists on the
        system by checking password and reserve tables in the local DB
 
 

        In additions to the enhancements to these calls a new set of calls will be added to support other kinds of editing which were previously done with standard UNIX tools. Some of these are fallout of the switch to the DB system while others are new functionality that never made it into version one. These calls do not yet have numbers associated with them so we'll only list their proposed names. Note that we assume that all these new calls can be supported for both flat files and a DB modes of operations. There may be a few exceptions due to  implementation, and some new features may be for the DB only due to time constraints.

        ADDGROUP would create a new group entry, as a actual new group,
        not a new user in a group

        REMGROUP would completely remove a group, including its members,
        and extension groups if any are present. (we may also provide a REMGID func)

        RESERVEGID will allow for reservation of GID so GID spaces could
        also be synchronized between clusters

        CHGPASS needs to be supported for changes of encrypted passwords

        CHGGCOS will allow for new applications which can modify the
        GCOS field of an user. We are considering a hook here that will allow the
        sysadmin to constraint the content of this field.

        CHGHOME should allow for the home directory of an user to changed
        in their password entry

        MOVEDIR would facilitate moving home directories, perhaps in
        combination with CHGHOME

        COPYDIR would be used to copy a whole directory tree from one location
        to another in support of account creation and other operations.

        RESTOREARCH would allow for restoration of an archived home
        directory

        CHGUNAME should perform username changes on the client. It is
        not clear if this should imply CHGHOME or MOVEDIR. Further more
        some support for email address records in the PDB needs to be
        address

        CHGGRPPASS should allow for a group password to be changed
        CHGGNAME will allow for the name of group to be changed, together
        with all it's extension groups

        CHKLSTCHG should allow for checking when DB record was last changed,
        and this operation might have no meaning in a flat file context
 

        Please keep in mind that the above calls are only proposed and that some may not be implemented and others may be added as
needed. Also some remote user composed SQL support might be added.