DBCONFIG(5)

NAME
dbconfig - RIPE database package general configuration file

DESCRIPTION
The dbconfig file (not necessarily a file with that name) is a configuration file for the RIPE database software. It contains among other things definitions of database objects, location of database files and location of various logfiles. It is used by various tools of the RIPE database software package like cleandb(8), netdbm(8), whoisd(8) and dbupdate(8). Not all tools need all options defined in dbconfig.

The general syntax is a set of keywords, followed by one or more values, where keywords and various values are seperated by one or more whitespace characters (tab, space).

The currently defined keywords are:

HELP
    takes one value which is a full pathname of a help file used by whoisd(8) when it received a "help" query. This keyword can only appear once in the configuration file.

DEFLOOK
    takes one value which is the source of the default database to be searched by whoisd(8). This keyword can only appear once in the configuration file. See also DBFILE below.

ALLLOOK
    takes mutliple values determining all sources whoisd(8) has to search when it receives a request to search all databases. This keyword can only appear once per configuration file. See also DBFILE below.

DBFILE
    takes 2 values, the first determining the source database, the second a full pathname specifying where a database with that source is kept. This keyword can appear multiple times with different values. An optional 3rd value can be "SPLIT" will tells all tools that this database is kept in a form where each object in this database has its own file. The filename for each of the objects is formed from the complete database name as specified here with the addition of the short form object type. Keeping objects in different files can make the individual files smaller for cleandb(8) or netdbm(8) and makes it possible to clean these files independently at different times and faster.

QRYLOG
    takes one value which is a full pathname of the file where whoisd(8) will log queries. This keyword can only appear once in the configuration file.

ERRLOG
    takes one value which is a full pathname of the file where various tools will log errors that occur. This keyword can only appear once in the configuration file.

AUTHLOG
    takes one value which is a full pathname of the file where updated(8) will log any authorization requests will be logged. See also dbauth(5) and updated(8). This keyword can only appear once in the configuration file.

UPDLOG
    takes one value which is an existing directory, in which all updates processed will be logged. The updates will be appended to a file with name YYMMDD (for year, month and day) in this directory.

ACKLOG
    takes one value which is an existing directory, in which all acknowledgements generated will be logged. The acknowledgements will be appended to a file with name YYMMDD (for year, month and day) in this directory.

NOMATCH
    takes multiple values, together making up the message that will be displayed by whoisd(8) if no match was found for a query. This keyword can appear mutiple times in a configuration file, the concatenation of all values makes up the complete message.

TOOMANY
    takes multiple arguments like NOMATCH, and will make up the message displayed by whoisd(8) if too many hits for a query were returned.

ATTR
    takes two values. The first value if the short two letter internal representation of attributes in the database, the second is the longer one word descriptive word for this attribute. Internally the database software only works with the short form, externally always the descriptive form. This keyword can appear multiple times with different values.

OBJ takes one value, then another keyword, and then a set of values. This keyword is used to describe a database object. The first value determines that name of the object (in two letter short format), then an additional keyword that determines the sort of definition this is. After this keyword a set of two letter short form attributes. Please see the example configuration file explanation of these second keywords, since they still change.

MAILCMD
    takes a value which is the command that will be used to send acknowledgement mails when an email update is processed. A complete mail with headers will be composed, and send as standard input to this command.

MAILTXT
    takes multiple lines as value and is used as a start in an acknowledgement mail. In this message one can use 4 variables which will be filled in when actually sending the mail. These are $FROM, $SUBJECT, $MDATE, $MSGID, which will be filled in with the "From:" field, the "Subject:" field, the "Date:" field and the "Msg-Id:" field of the mail that is being processed.

MHEADER
    takes mutliple lines as values, and is used to compose the mail header. Any mailheader line can be specified, except for the "To:" field which is inserted by the acknowledgement generation software. the 4 variables explained in MAILTXT can also be used here.

ACKERR
    takes multiple lines as value, and is printed at the end of an acknowledgement when errors or warnings are found in the processed updates.

ACKOK
    takes multiple lines as value, and is printed at the end of an acknowledgement when no errors or warnings are found in the processed updates.

ACKSIG
    takes multiple lines as value, and is printed at the end of an acknowledgement as a sort of signature by dbupdate(8).

RIGHTS
    takes multiple arguments like NOMATCH, and will make up a copyright message that will be added to any ASCII full dump of a database. Currently not yet used.

COUNTRY
    Takes 2 values, a 2 letter country code in capitals, and the same 2 letter country code in lowercase. All country codes defined here will be allowed by updated(8) as a legal value for the county attribute (RIPE specific) This keyword can appear multiple times with different values.

ENDCONF
    Denotes the end of the configuration file. ALWAYS end your configuration file with this keyword.

TESTMODE
    takes a 0 or 1 as value. If the value is 1, the database will run in test mode. This means that all mails that dbupdate(8) would send out are not send to the mailbox it would be send to, but to the mailbox mentioned in DEFMAIL.

HELP
    takes a full path filename as argument. This file will be displayed by whoisd(8) when help is queried.

CANUPD
    takes a list of sources. The sources mentioned in this list can be updated using dbupdate(8). Attempts to update objects with a source that is not in this list will return an error.

AUDITLOG
    takes a full path filename as argument. Special actions (such as deletes) performed by dbupdate are logged in this file.

PIDFILE
    take a full path filename as argument. This is where whoisd(8) will leave its process id.

CLEANLOCK
    takes a full path filename as argument. Whenever a database file is cleaned this file is used as a basename for a lockfile. The database filename will be appended to the file mentioned to create unique lock files for each database file.

TMPDIR
    takes a full path directory as argument. This is where dbupdate(8) and cleandb(8) will keep temporary files when doing updates to a database. You should pick a directory where you have enough space, because non of the tools know how to deal with "Out of disk space" errors.

DEFMAIL
    takes a mailbox as argument. This mailbox is used when running in test mode (see TESTMODE) and as sender address for ackowledgements sent out by dbupdate(8). NOTE This address should NOT be the mailbox dbupdate(8) listens to, because that could cause interesting mail bounces.

HUMAILBOX
    takes a mailbox as argument. This mailbox is used when forwarding special objects (like new "mntner:" objects) for inclusion. NOTE This address should NOT be the mailbox dbupdate(8) listens to, because that could cause interesting mail bounces.

ALIAS
    takes two arguments. First a two letter short form attribute, second an alias name for that attribute. These aliases are used for the template mode of whoisd(8). It will recognize the alias as a request for a template for the object referred to by the short form attribute.

NOTITEXT
    takes multiple lines as value and is used as the body of a mail generated by dbupdate(8) for notifications. You can use the same set of variables as in MAILTXT.

NHEADER
    takes multiple lines as value and is the header for notification mails generated by dbupdate(8). It needs a "From:" field. The variables mentioned in MAILTXT can be used. Do NOT specify a "To:" field, it will be added by dbupdate(8).

FWHEADER
    takes multiple lines as value and is the header for forwarding messages to a maintainer if objects fail authorization using the "mnt-by:" RIPE database function.The variables mentioned in MAILTXT can be used. Do NOT specify a "To:" field, it will be added by dbupdate(8).

FWTEXT
    takes multiple lines as value and is the body of the message when forwarding messages to a maintainer if objects fail authorization using the "mnt-by:" RIPE database function. The variables mentioned in MAILTXT can be used.

MTFWHEADER
    takes multiple lines as value and is the header of a message send to the database maintainer to request addition of new maintainer objects. It needs a "To:" field, which would usually be HUMAILBOX.

MTFWTEXT
    takes multiple lines as value and is the body of a message send to the database maintainer to request addition of new maintainer objects. The variables mentioned in MAILTXT can be used.

SEE ALSO

cleandb(8) dbupdate(8) whoisd(8) netdbm(8)

BUGS

Some parts of this configuration file are rather RIPE database specific. NO syntax checking is done by the module reading this config file. It will not complain when needed variables are not defined; it will simply go wrong. The module will however complain when it finds unknown configuration options, but will continue. The manual page is not very clear and needs to be alphabeticized.

AUTHOR

Marten Terpstra, RIPE Network Coordination Centre <marten@ripe.net>