$Id: TODO 319 2007-03-01 10:30:01Z joostvb $
- reimplement bootstrap as something like
AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf --install \
- xsltproc 1.0.16-0.2 does not understand --path; xsltproc 1.1.8-5 does.
Document this. Furthermore, under some circumstances (on topaz, e.g.)
I/O error : Attempt to load network entity
_even_ with --nonet option.
- Split requirements in manual in cvs-build-time, build-time and run-time;
document all run-time dependencies, get configure.ac check for them.
- Don't use pod but docbook for st_snapshot manpage.
- Add links from systraq homepage to stuff build with "make html".
- Finish systraq manual: add diagram listing dependencies (see the FIXME)
- Don't install st_snapshot.hourly in bin/ , but in a location like libexec/ .
- Don't use md5sum, nor sha1sum as shipped with GNU coreutils
( ftp://ftp.gnu.org/gnu/coreutils/ ).
md5sum should be variable ST_SUM in /usr/sbin/systraq, it should be set
wait for coreutils or openssl to ship a commandline SHA2 tool or
use gpg --print-md RIPEMD160 (or gpg --print-md SHA256). The
first one seems to behave as a drop-in replacement, wrt output-format.
The SHA-2 standard is fine, it defines both SHA-224 and SHA-512.
RIPEMD-160 if fine too, as of april 2006.
See also shasum, shipped with libdigest-sha-perl and sleuthkit which ships
Rüdiger Weis and Stefan Lucks have described this in a paper presented at
http://www.sane.nl/sane2006/program/abstract.php?eventid=24 An article which
_is_ available online, describing the same issue, is at
Probably filetraq needs a fix too...
- The way all homedirectories are found is braindead. It fails in case
something like NIS is used. Document this.
- Systraq should silently ignore non-world-readable to-be-monitored files in
homedirectories. This is nice on systems where some users like to have e.g.
~/.bashrc monitored and others do not. Document this behaviour, and instruct
admins to check for readability when setting up list of to be monitored
files. Check what happens when permissions change: are we getting warned? I
guess we should be warned. Bug reported by Lionel Elie Mamane.
- Make this package usable on systems with a configured filetraq:
> What to do with filetraq.default
> What to do with filetraq cron job
- Guess systraq doesn't need it's own group, but is fine with being in
'nogroup'. systraq files can be group-owned root.