v1.0.5.2

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.


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. (Spark actually used stdio (perlio at that time) since the very beginning...)

  • 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 man pages, 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 except hardcore POSIX-devel), see #4.
  • Libc goes a hell through a maze to do the I/O (i.e. nss)
  • First tests against Shadow (libc) and ACCDB have shown that the latter is 20x faster
  • High extendibility
  • The abstraction layer and user database modules are not specific and can thus be used by any application
  • (Every time you add a user database, you would not need to recompile libc-NSS)

More features

  • UID32/GID32 compliant
  • You can, for example, add users here and now, and they automatically pop up on the master server (which distributes users in an LDAP like way)
  • You can have back-end modules of different languages, as long they provide the needed base functions. That way, you can have a C++ or even C/Perl module (with C hooks).

Future Vitalnix/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.


May 11 2004 http://vitalnix.sf.net/