Vitalnix : User Management Suite
  manual v1.90.5.2

Description

This section describes the idea behind Vitalnix and the Unified Account Database.

Intention

Daxtraq was developed in 1997 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 used direct file operations until 2003, when LDAP (or a hook for LDAP) was requested. So the design of Daxtraq ought to change to support multiple backends. It turned out to be better to modularize and separate certain parts, so it was split up into libaccdb and Daxtraq.

Default state

The following image shows what a default today's system would look like, including Daxtraq < v1.90.3.x (which did not have ACCDB), though, which is already capable of handling more than one backend.


Colors: red = write :: yellow = programs :: green = write :: cyan = abstraction layer :: blue = abstraction code :: magenta = system libraries

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. (Daxtraq actually used perlio/stdio since the very beginning...)

Contra libc

  • Libc's password functions offer no flexibility, if you code it yourself, you can choose the filename and access methods.
  • They are not widely available, according to the manpages, SVID and BSD 4.3.
  • Re-entrancy issues. getpwent() returns its data in a static buffer, getpwent_r() is not an alternative (not even available at all expect hardcore POSIX-devel), see #4.
  • Libc goes a hell through a maze to do the I/O (i.e. nss)

Pro ACCDB

  • First tests against Shadow (libc) and ACCDB have shown that the latter is 20x faster
  • High extendability
  • Less applications are used: even though we are adding another bunch of applications to the scene (the ACCDB-capable ones), we therefore eliminate all others (as long as there are ACCDB backends)
  • The abstraction layer and user database modules are not specific and can thus be used by any application
  • (Everytime you add a user database, you would not need to recompile libc)

More features

  • UID32/GID32 compliant
  • You can, for example, add users here and now, and they automatically pop up on the NIS server
  • You can have back-end modules of different languages, as long they provide the needed base functions. That way, you can have a C++ oder even C/Perl module.

Future Daxtraq/ACCDB state

The next image shows the state strived for.


Colors: red = write :: yellow = programs :: green = write :: cyan = abstraction layer :: blue = abstraction code :: magenta = system libraries

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.


November 28 2003