Name
C-spark -- User Management UI Description
C-Spark is a tool for the mass registration of users within the system user database. It finds the differences between a given list and the user database, adds and deletes users. It thus removes the need for adding each user manually. It also supports operations on/with single users. This application may come handy in companies, schools/colleges and/or similar where there is a large amount of people to manage and adding them would otherwise take long. Finding differences is group-based: select a group to match the list against. This allows for multiple groups and lists. Currently, C-Spark has the "autorun" (non-interactive) and CLI (simplistic interactive) interfaces. In future I hope to add a CUI (graphical interactive). Program calling syntax
Due to its so-called "autorun" mode, there are a lot of options. They will be explained below, but in the green overview box, only the most important are shown.
Here are a few examples for the Autorun mode usage. If that's too complex for you, better use the Interactive mode by providing no Autorun arguments and/or parameters.
Configuration file
Configuration files are done in textual key=value-pair style. (Described in ACCDB API.) There are a lot of configurations available. All configuration options are discussed in the following. The spark.cfg from CVS contains what I experimented with, so if it says "default" somewhere, the hardcoded value and/or spark.cfg from official file package releases are meant. AUTOFLUSH optionThis is a special option for the backend module usage. If AUTOFLUSH is on for a backend module, it flushes dirty data to disk (or instructs its parent to do so). This flushing only becomes necessary, if other applications read the user database behind Vitalnix ACCDB, because a newly created user might only exist within memory and the scope of ACCDB until the DB is flushed to disk. (SLANED solves all this...) Possible values are:
User management helper programsMASTER_{PRE,POST}{ADD,DEL} specify scripts that are to be executed { before, after } the { addition, deletion } process. The available positional parameters are concluded below. USER_{PRE,POST}{ADD,DEL} specify scripts that are to be executed { before, after } a user is { added, deleted }. Some of these might not be called if there are no users to { add, delete }. The available positional parameters are concluded below.
ProgramsSHELL points to the default command interpreter for the user when s/he logs in. Default is /bin/bash. Password related optionsThree options related to password creation and storage are available: PSWD_LEN, PSWD_PHON and PSWD_METH. PSWD_LEN controls the length of newly generated passwords. Use -1 to disable newly generated accounts using a password that never matches. Use 0 to start with no password. The latter may not always work as remote services may disallow empty passwords. See their source or their respective PAM configuration file. If PSWD_PHON is set to yes (or on), special subroutines to generate pronouncible, easy-rememberable (and on top, secure) passwords are used. If this is no, the standard total-random-chars-and-numbers-algorithm is taken. PSWD_METH specifies the encryption method to use. This can be des, md5 or blowfish. (The last is the most secure.) If you use "samba encrypted passwords" you will need to use ntlm (absolutely weak and currently not implemented). Directory optionsHOME points to the path where new directories shall be added. In most cases, this will be /home. SPLIT_LVL enables how to arrange home directories. If you have a large amount of users, it may become advisable to split them up, since listing such a big directory (/home) containing some thousand entries takes some time. The solution to this is to move them to sub directories, i.e. to create /home/j/jengelh. This speeds up single lookups, and searching all /home using find utilities does not get any slower. The maximum value SPLIT_LVL is 2 (which would create /home/j/je/jengelh). The default is 0, meaning not to use this feature. SKEL points to the skeleton directory. All files from the skeleton directory are copied to the user's directory upon user creation. The default is /var/lib/empty. (If you want to have all the dot.crap files change to /etc/skel.) Finding differences
Involving the diff utility could be quite an idea, but it is a general differencer, comparing line-by-line. Since we just need to compare fields, and that conditionally on their content, the use of diff would make the whole program a lot more complicated. The first step is to take an input file, and compare it against the current user database. Users which are found in both repositories are kept, those who are only in the Data Source have to be added and the rest is deleted. (Can be archived if demanded for.) Input data format
Data fed to C-spark is in XML format. See the tags specification for details. Or check out some data source examples from the doc/examples folder.
|