What does the CSE UDB (User DataBase) do?

In this document I'll be talking specifically about the New UDB. The Old UDB is similar (and deprecated, being used only on Old World hosts).

Server-wise, the UDB is implemented as a PostgreSQL database running on the server "bandleader".

One if its main functions is to answer Linux account (read: passwd) queries from CSE user login hosts (such as lab computers and VLAB/login servers) at login time via LDAP. Responses to these queries include UID, GID, home directory path and login shell. Thus, another component of the UDB is, effectively, the OpenLDAP server running on "bandleader" which answers these queries directly via LDAP (rather than being answered by the PostgreSQL server itself, see below).

Main roles

So, the main roles of the UDB are:

1. As mentioned above, answer Linux account/passwd queries via LDAP.
2. Loosely couple UNSW-maintained zID's to CSE accounts. I.e., zID-to-UID mapping, such as 'z9702847' is also known as 'plinich' (UID=4606) in CSE.
3. Maintain role and privilege history for users. E.g. "tutor/lecturer/student", "extra disk quota", "access to specific servers", when these roles/privileges were in effect, etc.
4. Maintain database tables supporting mlalias, including loosely coupling email identities to CSE user accounts.
5. Answer role/privilege queries via LDAP (specifically, netgroup membership queries, see below).
6. Answer queries from staff about users' roles and account details.

Changes come from

The main user(UID)/group(GID)/role/privilege tables of the UDB are maintained and updated by:

1. CSE Account creation and maintenance scripts. These scripts are run nightly on the host synth. They download enrolment, employment, and staff allocation data from SIMS, PIMS, HR and teachadmin, and transform this data into UDB account and class membership data which is used to update the UDB.
2. Manual operations by CSG staff, e.g., to temporarily increase a user's disk quote, or to extend their account life after their "official" end of association with UNSW due to, say, needing to complete work on a research paper with another academic, or because their role in a particular teaching class needs to be extended due to deferred exams, etc.
3. Other scripts which might patrol the contents of the UDB and clear up anomalies, or find very old accounts and archive them.

mlalias

The same PostgreSQL database also contains the tables used by the mlalias system and these are updated by:

1. Changes in the main UDB, such as a user account being deleted causing any associated mlaliases to be deleted.
2. Changes made manually by the owner of the mlaliases, including creation of new mlaliases.
3. Changes made by automated scripts, typically run the mlalias owners.

Main activity

By far the main activity of the UDB is answering LDAP queries from user login hosts. Principally, these queries are of three types:

1. As mentioned earlier, providing Linux account information necessary used when a user logs in.
2. UID- and GID-to-account-name mappings when a user runs a command like "ls -l" to show who owns a file or directory.
3. Looking up netgroup (i.e., class/role/privilege) information.

Speed and the need for flattening

Although the information delivered by LDAP derives directly from the PostgreSQL database, it is not served directly from the database due to speed considerations (i.e., the PostgreSQL queries necessary to resolve hierarchical/nested class membership lookups are too slow). Instead, at regular 15-minute intervals, the contents of the PostgreSQL database are resolved and flattened and synchronised with the OpenLDAP server's own fast BerkeleyDB database.

The resolving/flattening consists of expanding class memberships and creating records of "right now" and ignoring anything historical. Expanding class memberships means, for example, where a user is a current member of "COMP1511_STUDENT" their list of memberships will be expanded to also include "COMP1511", "STUDENT" and "COMP1" (this latter indicating they are enrolled in a first-year class).