Overview
arch - This section describes the idea behind Vitalnix and the Unified Account Database. History
The nameless program was developed in 1997 at the Otto-Hahn-Gymnasium (high school) to help adding and deleting students' accounts as they came and went each year. (The first time, it was 1200 users, then about 200 every consecutive year.) It was widely used across the whole town (4 major colleges). It used direct file operations until 2003, when LDAP (or a hook for LDAP) was requested. So the design of it ought to change to support multiple back-ends. It turned out to be better to modularize and separate certain parts, so it was split up into libaccdb and the UIs. Default state
The following image shows what a default today's system would look like, including C-spark < v1.90.3.x (which did not have ACCDB), though, which is already capable of handling more than one backend.
Green and red arrows denote the flow of data (read and write). As you can see, the scene is really cramped. Every user database has its own, clearly separated region with its own access functions and programs. Other programs might even not use libc's password functions at all and directly access /etc/passwd. There are various reasons for that. (Spark actually used stdio (perlio at that time) since the very beginning...)
More features
Future Vitalnix/ACCDB state
The next image shows the state strived for.
The image shows programs which all use an abstraction layer which modules do provide. The modules then do the necessary database and I/O operations depending on what the database system is. One ACCDB back-end might use two others (Migration Service in the image), another might separate two groups across two servers/networks and writes an extra copy to a backup server.
|