FAQ — Frequently Asked Questions

General

TipTIP
 

The most frequent problems are:

  1. Untrusted paths for config/log/pid/database files. See the Section called Trusted users and trusted paths in the chapter called Installation> for details.

  2. Failure of self-address resolving on the client due to mistakes in the /etc/hosts file. See the Section called Client or Standalone> for details.

Owner not trustworthy / Group writeable and member not trustworthy

An untrusted user (might be an untrusted group member for group writeable files/directories) owns or can write to an element in the path listed in the error message. This concerns the configuration file, the log file, and the database file.

The offending element in the path is identified as obj=/xxx in the error message.

To fix the problem, determine relevant users and/or group members, and use the configure option --with-trusted=LIST_OF_TRUSTED_UIDS (not GIDS !)

./configure [more options] --with-trusted=0,...

Untrusted path

See above

PANIC — File not accessible

Most likely permission denied because of unsufficient privileges.

The executable is corrupted after installation

The executable will get stripped during the installation. On suitable systems (i386 Linux/FreeBSD currently), additionally the sstrip utility (copyright 1999 by Brian Raiter, under the GNU GPL) will be used to strip the executable even more, to prevent debugging with the GNU gdb debugger. The strip utility cannot handle the resulting executable, therefore trying to strip manually after installation will corrupt the executable.

--enable-xml-log has no effect

If you have compiled for stealth, you won't see much, because if obfuscated, then both a 'normal' and an XML logfile look, well ... obfuscated. Use 'samhain -jL /path/to/logfile' to view the logfile.

E-mail: Reverse lookup failed

Fix your DNS (reverse lookup: numerical IP address to FQDN, to verify FQDN to numerical IP address). If this problem happens for client/server connections: also see the Section called Server>.

But nslookup tells me my DNS works

First, nslookup does not use the system resolver library — it has its own resolving routines, and does things differently than the resolver library (see the book DNS and bind). Therefore, it is not exactly the best tool for debugging name resolving problems. Second, did you check reverse lookup as well as forward lookup ?

Device not available path=/dev/random

Because /dev/random can block for a long time if there is no entropy, samhain will fall back on /dev/urandom after some timeout, and issue this message (it will try /dev/random again next time).

How can I avoid error messages for invalid UIDs (no such user) ?

Set SeverityNames to a low value (see the Section called Severity levels in the chapter called Configuration — Basic>).

[Redhat] The /etc/init.d/xyz init script hangs

Redhat uses initlog (see man initlog) in initscripts. If it hangs, most probably samhain/yule runs in the foreground rather than as daemon. Use Daemon=yes in the configuration file.

The /etc/init.d/xyz init script exits with: execvp: No such file or directory

Either the program is not installed, or it is not in the PATH (the one used by the init script, which may be different from your PATH).