![]() |
Vitalnix | : User Management Suite |
manual | v1.90.8.1 |
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/ |
libaccdb Configuration files | /etc/libuudb/ |
Include files for libaccdb | /usr/include/ |
Administrative programs (login, useradd, etc.) | Various locations, /bin/, /usr/sbin/ |
Daxtraq binary | /usr/sbin/ |
Daxtraq configuration | /etc/ |
Daxtraq DS modules | /usr/lib/daxtraq/ |
Daxtraq runtime data (which is your SDF and XML files) | /var/lib/daxtraq/ |
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.
The Vitalnix package DOES conflicts with the Shadow RPM package, since it provides utilities like shadow's useradd in the same locations. Currently, the Vitalnix RPM package has no "Conflict" tag included, and files are called different. Once it becomes stable, you will need to remove the Shadow RPM package in order to use Vitalnix. There is also some "Obsoletes" tag, I might want to check that too. For now, do not worry.
You can pass DEBUG=1 to gmake (or edit the Makefile) to enable debugging support for GDB.
The following paragraph about the Segvtracer utility only
applies to Daxtraq.
In either case, a stub is included in Daxtraq which traces signals and segment
violations. It only becomes active if there are no open files on descriptors 3
to 255, to not interfere with GDB. If you encounter a segment violation (also
called a "bug" or "crash"), something like this will show up:
~/vitalnix > 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, over. (only ix86). Of course, submitting a GDB log is also accepted, as shown below:
~/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) |
November 14 2003