Vitalnix : User Management Suite
  manual v1.90.8.21

Installing (RPM)

There are two ways of getting Vitalnix installed. One is to install the RPM package, the other is to compile the source tree itself. I suggest using the former, since it is way easier to upgrade it later.

rpm -Uhv vitalnix-%version.%arch.rpm

(replace %version and %arch appropriately)... installs the RPM package. That is all there is, it is that easy. Program files will be installed in these paths:

libaccdb and ACCDB modules /usr/lib/
Configuration files for libaccdb /etc/libuudb/
Include files for libaccdb /usr/include/
Administrative programs (login, useradd, etc.) Various locations, /bin/, /usr/sbin/
Configuration files for administrative programs /etc
Vitalnix supply programs /usr/lib/vitalnix
Daxtraq binary /usr/sbin/
Configuration file for Daxtraq /etc/daxtraq.conf
Daxtraq DS (Data Source) modules /usr/lib/daxtraq/
Daxtraq runtime data (which is your SDF and XML files) /var/lib/daxtraq/

Conflicting files

The Vitalnix package actually does "conflict" with other installed packages, as it provides some tools itself, which may already be installed by other -- possibly base system -- packages. This currently includes shadow.rpm, and in near future coreutils, and possible util-linux. The Vitalnix RPM has no "Conflict" tag included, as these issues are not resolved yet. Files installed in system directories are called different, i.e. vgroupadd instead of just groupadd.

Installing (Source tree)

The other way is to compile the sources: Extract the source tree and run `gmake`. If everything went well, ACCDB, its back-ends, system programs and Daxtraq will be compiled, lying in the current directory (the root of the source tree). Note that "." is added to the library search paths for all of Vitalnix, so if you happen to run any of the utilities from a directory which has a different libaccdb.so, that one will be used instead.

If you only wish to make certain parts of the source tree, the Makefile provides the following targets: all, accdb, backends, sysprog and daxtraq. "all" is assumed when no target is given to gmake.

To install the compiled binaries to system folders, run gmake install. The default paths to which the binaries and modules will be installed are the ones listed above. To change this behavior, you can pass some variables to gmake (or edit the Makefile): If, for example, you want to compile on one machine and then copy it over to another using mounted directories (NFS, CIFS, SMBFS), you can use the PREFIX variable:

gmake install PREFIX=/nfspath

So that Daxtraq gets stored in i.e. /nfspath/usr/sbin/daxtraq. But we allow more fine control about what is placed where, since the PREFIX variable is prepended to all the variables BINDIR (default /bin), ETCDIR (/etc), USRINC (/usr/include), USRBIN (/usr/bin), USRSBIN (/usr/sbin) and VARLIB (/var/lib). Any of these variables overrides PREFIX, so this does something completely different:

gmake install PREFIX=/mnt ETCDIR=/etc

since that will install everything into /mnt/... but configuration files, which come into /etc/. You usually do not need this, not even PREFIX, but it is here for completeness.

Debugging

You can pass DEBUG=1 to gmake (or edit the Makefile) to enable debugging support for GDB.

If you happen to run into a Segmentation fault (also called Segment violation, a bug or a crash), you can use GDB or the provided segvtracer utility (to be found in devutil/). Run it, with the original program's name and arguments as its arguments, i.e. segvtracer vgroupadd -g 666 satan. Something like the following might show up (Daxtraq used in this case):

~/vitalnix > segvtracer daxtraq
SEGV> Current thread: PID=31513, TID=16384, PGID=31512, PGRP=31512, STR=app
SEGV> Launching application
SEGV> Current thread: PID=31512, TID=16384, PGID=31512, PGRP=31512, STR=main
SEGV> Current thread: PID=31515, TID=16386, PGID=31512, PGRP=31512, STR=xlog
*****[ Daxtraq v1.90.6.27 <devel> (Oct 26 2003 12:15:36) ]*****

...
... (anything)
...
SEGV> Application received signal 11 (Segmentation fault)
SEGV> Register dump =>
SEGV>         EAX = 0x00000000  ESI = 0x00000000     EIP = 0x400242BB
SEGV>         EBX = 0x400277E0  EDI = 0xBFFFEF94  EFLAGS = 0x00010296
SEGV>         ECX = 0x403B4E0C  EBP = 0xBFFFECD8       `-> ......i.s..x.p..
SEGV>         EDX = 0xFFFFFFFF  ESP = 0xBFFFECB4    EEAX = 0xFFFFFFFF
SEGV>          CS = 0x00000023   DS = 0x0000002B   SS = 0x0000002B
SEGV>         _CS = 0x00000000  _DS = 0x00000000  _SS = 0x00000000
SEGV>          ES = 0x0000002B   FS = 0x00000000   GS = 0x00000007
SEGV>         _ES = 0x00000000  _FS = 0x00000000  _GS = 0x00000000
SEGV> Stack backtrace dump =>
SEGV>         (#0) EBP=0xBFFFECD8, RET=0x0804A933
SEGV>         (#1) EBP=0xBFFFEF28, RET=0x0804ABD3
SEGV>         (#2) EBP=0xBFFFEF38, RET=0x08049AED
SEGV>         (#3) EBP=0xBFFFEF48, RET=0x4029A857
SEGV>         (#4) EBP=0xBFFFEF68, RET=0x080499F1
SEGV> Tracing completed, log stored in segvtracer.log.

You can either debug the problem yourself, correct it and submit a patch, or on purpose submit the source tree, complete with compiled files (thus, only ix86), over. Of course, submitting a GDB log is also accepted, as shown below. Please note that the SIGSEGV might only happen at your machine, because of the conditions there. In that case, other arrangements need to be made.

~/vitalnix > gdb daxtraq
(gdb) r
Starting program: /root/f/daxtraq/daxtraq
[New Thread 16384 (LWP 18557)]
*****[ Daxtraq v1.90.6.27 <devel> (Oct 26 2003 12:15:36) ]*****

...
...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 18557)]
0x400242bb in HXdir_read (d=0x0) at dir.c:63
63     if((d->wdata = readdir(d->dentry)) == NULL) { return NULL; }
Current language: auto; currently c
(gdb) bt
#0 0x400242bb in HXdir_read (d=0x0) at dir.c:63
#1 0x0804a973 in mm_register_ds () at dx_mm.c:30
#2 0x0804ac13 in Mainmenu_TX () at dx_ptui.c:28
#3 0x08049b2d in main (argc=1, argv=0xbfffeec4) at dx_main.cpp:46
#4 0x4029a857 in __libc_start_main () from /lib/libc.so.6
(gdb)

SegvTracer will NOT be installed to any system folders, either by the RPM or by `gmake install`. (In the example above, the error was that mm_register_ds() did not check for d == NULL, not a libHX fault.)


November 26 2003