4. Interactive configuration of beltane

Your login name.

Your login password. If this is blank, the stored password will be kept (rather than set to blank). If exactly 32 chars, the input is assumed to be an MD5 hash already, otherwise the MD5 hash will be computed and stored.

(seconds) terminate session after this much seconds without user activity.

(TRUE/FALSE) yule is configured to strip the domain part from client names.

	NOTE
	Beltane will need the FQDN of clients in the client database (or the IP number, if clients are known to yule by IP number only). In particular, Beltane will not function properly if you have only the hostname in the client database, and yule is configured to strip the domain. See Section 3.2 for more information on the client database.

(TRUE/FALSE) If set to TRUE, beltane will request a comment for each baseline database update. The comment will be stored in the SQL database.

(TRUE/FALSE) If set to TRUE, and you are using browser-based http authentication over a SSL connection, and your http login name matches a username defined in the beltane configuration, you will automatically get logged in as this user.

(hostname) If this is not empty, and not set to "none", beltane will not use the userlist defined in the configuration, but will contact the LDAP server on that host to authenticate the user. See Section 5 for details.

(ldap dn) This is the base DN that beltane will use to authenticate users on the LDAP server. See Section 5 for details.

The path to yules data directory (e.g. /var/lib/yule). This is the directory where client file signature databases and client configuration files reside.

The path to yules pid file (e.g. /var/run/yule.pid).

The path to yules HTML status file (e.g. /var/lib/yule/yule.html). This is a file written by the server providing basic status information for the server itself and for the clients known to the server.

The path to the beltane_cp helper application.

The path to the beltane_update helper application.

The path to the beltane_log helper application.

The path to the beltane_sign helper application (used for signing file databases).

The path to the yulectl application. This is included in the samhain/yule distribution. It provides a command-line interface to connect to the Unix domain socket of yule and submit commands for clients. The server will pass such commands to a client when the client connects for the next time (e.g. for delivering a timestamp message).

The path to the file where the list of files is stored that were updated with the last non-bulk update. This can be used as file list for the bulk update, i.e. you can use one host as template and select updates manually, and then carry over this selection to other hosts.

The database type. Possible values are PostgreSQL, MySQL, Oracle, and ODBC (not tested). Oracle and ODBC are only supported with samhain version 1.8.0 and above.

The name of the table in the SQL database (default: log).

The host where the SQL server runs (for UNIX socket: localhost if MySQL, blank if PostgreSQL).

The name of the SQL database (default: samhain).

The name of the SQL user.

The password of the SQL user.

(integer) add this number of seconds to ctime, and mtime when showing details for modified files. Allows you to fix offsets between these items and log_time.

(integer) display at most this number of messages. The default value of '0' will display at most 1200 messages (but this is not a hardcoded maximum — you can set a higher limit).

(integer) time in seconds between window refresh for the message and client panel.

(TRUE/FALSE) also view messages from the server itself.

(TRUE/FALSE) sort clients alphanumerically in the 'Clients' panel.

(TRUE/FALSE) whether the message panel should be above (default), or to the right of the clients panel. If you change this option, it will only take effect after hitting Refresh, or the browsers reload button.

(TRUE/FALSE) whether the user that approved an update, and the comment for that update, should be displayed in the search results for a database search.

The height (in pixels) of the top panel containing menu and buttons. If you change this option, it will only take effect after hitting Refresh, or the browsers reload button.

The height (in pixels) of the message panel containing the list of messages. If you change this option, it will only take effect after hitting Refresh, or the browsers reload button.

The width (in pixels) of the client panel containing the list of clients. If you change this option, it will only take effect after hitting Refresh, or the browsers reload button.

The pattern to match. This may be a simple string or a Perl-style regular expression. Log records matching the pattern will get suppressed. Please note that PCRE regular expressions must be enclosed by matching delimiters (e.g. /pattern/ or #pattern#).

On Linux, see man perlre for details on Perl regular expressions. You may also have a look at the PHP manual for an overview of Perl-Compatible Regular Expressions (PCRE): http://php.net/manual/en/pcre.pattern.php

Whether the pattern should be interpreted as string (fast) or regular expression (slow).

(TRUE/FALSE) automatically confirm filtered messages, i.e. change their status from NEW to ACK_AUTO (acknowleged) in the database. If you don't use this option, the number of messages returned by a database query, but then filtered out, will increase with time, and eventually cause bad performance.

The field, to which the filter should be applied. If this field matches the pattern, the message will not be shown, and eventually automatically confirmed, depending on the 'ACK filtered'setting for this filter.

NOTE

The 'Log record tag' contains an MD5 checksum computed by yule over an arbitrary set of user-defined database fields. Basically, this should allow you to easily filter any rows in the database you like. E.g. on startup, clients will report the checksum of the configuration file, or the fingerprint of the PGP key used for signing. You could e.g. let yule include these fields in the 'Log record tag' ('log_hash' in the database), and filter ot all startup messages with 'good' config file checksums/PGP fingerprints.

The 'owner' of a filter is the login user for which this filter applies. If this field is empty, the filter is used for all users. Otherwise, the filter is only applied if the given name matches the login user.

	NOTE
	Users without administrative privilege may only see filters that apply to all users (no owner) and to themselves. They may only create and/or modify filters that are 'owned' by themselves (only).

The key ID for the signing key. Gpg understands the 8-digit hexadecimal ID as well as some other ways to specify the key.

The directory where the keyrings are located (usually /some/user/.gnupg).

Fill in to create a new user. Erase User name to remove a user. Leave Update privilege to FALSE, if you don't want the user to perform any database update actions. See also Section 4.8.

An optional comma-separated list of groups the user belongs to. If you leave this blank, the user belongs to no group, and can view all clients. If you enter a (list of) group(s), the user can view all clients pertaining to these groups. See also Section 6.

Fill in when you create a new user.

(ADMIN/USER/GUEST) Leave Privilege level to GUEST, if you don't want the user to perform any database update actions. See also Section 4.8.