dictd

package: dictd

title: dictd(8)

text:
# dictd(8)

## NAME
dictd - a dictionary database server

## SYNOPSIS

```
dictd [options]
```

## DESCRIPTION
dictd is a server for the Dictionary Server Protocol (DICT), a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.

For security reasons, dictd drops root permissions after startup. If user dictd exists on the system, the daemon will run as that user, group dictd, otherwise it will run as user nobody, group nobody or nogroup (depending on the operating system distribution).

Since startup time is significant, the server is designed to run continuously, and should not be run from inetd(8). (However, with a fast processor, it is feasible to do so.)

Databases are distributed separately from the server.

By default, dictd assumes that the index files are sorted alphabetically, and only alphanumeric characters from the 7-bit ASCII character set are used for search. This default may be overridden by a header in the data file. The only such features implemented at this time are the headers "00-database-allchars" which tells dictd that non-alphanumeric characters may also be used for search, the header "00-database-utf8" which indicates that the database uses utf8 encoding, and the "00-database-8bit-new" which indicates that the database is encoded and sorted according to a locale that uses an 8-bit encoding.

## BACKGROUND
For many years, the Internet community has relied on the "webster" protocol for access to natural language definitions. The webster protocol supports access to a single dictionary and (optionally) to a single thesaurus. In recent years, the number of publicly available webster servers on the Internet has dramatically decreased.

Fortunately, several freely-distributable dictionaries and lexicons have recently become available on the Internet. However, these freely-distributable databases are not accessible via a uniform interface, and are not accessible from a single site. They are often small and incomplete individually, but would collectively provide an interesting and useful database of English words. Examples include the Jargon file, the WordNet database, MICRA's version of the 1913 Webster's Revised Unabridged Dictionary, and the Free Online Dictionary of Computing. (See the DICT protocol specification (RFC) for references.) Translating and non-English dictionaries are also becoming available (for example, the FOLDOC dictionary is being translated into Spanish).

The webster protocol is not suitable for providing access to a large number of separate dictionary databases, and extensions to the current webster protocol were not felt to be a clean solution to the dictionary database problem.

The DICT protocol is designed to provide access to multiple databases. Word definitions can be requested, the word index can be searched (using an easily extended set of algorithms), information about the server can be provided (e.g., which index search strategies are supported, or which databases are available), and information about a database can be provided (e.g., copyright, citation, or distribution information). Further, the DICT protocol has hooks that can be used to restrict access to some or all of the databases.

dictd(8) is a server that implements the DICT protocol. Bret Martin implemented another server, and several people (including Bret and myself) have implemented clients in a variety of languages.

## OPTIONS
-V or --version

Display version information.

--license

Display copyright and license information.

-h or --help

Display help information.

-v or --verbose or -dverbose

Be verbose.

-c file or --config file

Specify configuration file. The default is /etc/dictd.conf , but may be changed in the defs.h file at compile time (DICTD_CONFIG_FILE).

-p port or --port port

Overrides the keyword port in Global Settings Specification section of configuration file.

-i or --inetd

Communicate on standard input/output, suitable for use from inetd. Although, due to its rather large startup time, this daemon was not intended to run from inetd, with a fast processor it is feasible to do so. This option also implies --fast-start.

--pp prog

Sets a preprocessor for configuration file. like m4 or cpp . See examples/dictd_complex.conf file from distribution. By default configuration file is parsed without preprocessor.

--depth length

Overrides the keyword depth in Global Settings Specification section of configuration file.

--delay seconds

Overrides the keyword delay in Global Settings Specification section of configuration file.

--facility facility

The same as syslog_facility keyword in Global Settings Specification of configuration files.

-f or --force

Force the daemon to start even if an instance of the daemon is already running. (This is of little value unless a non-default port is specified with -p, since, if one instance is bound to a port, the second one fails when it can not bind to the port.)

--limit children

Overrides the keyword limit in Global Settings Specification section of configuration file.

--listen-to host

Overrides the keyword listen_to in Global Settings Specification section of configuration file.

--address-family family

Overrides the keyword address_family in Global Settings Specification section of configuration file.

--locale locale

Overrides the keyword locale in Global Settings Specification section of configuration file.

-s

The same as syslog keyword in Global Settings Specification of configuration files.

-L file or --logfile file

The same as log_file keyword in Global Settings Specification of configuration files.

--pid-file file

The same as pid_file keyword in Global Settings Specification of configuration files.

-m minutes or --mark minutes

Overrides the keyword timestamp in Global Settings Specification section of configuration file.

--default-strategy strategy

Overrides the keyword default_strategy in Global Settings Specification section of configuration file.

--without-strategy strat1,strat2,...

The same as without_strategy keyword in Global Settings Specification of configuration files.

--add-strategy strategy_name:description

The same as add_strategy keyword in Global Settings Specification of configuration files.

--fast-start

The same as fast_start keyword in Global Settings Specification of configuration files.

--without-mmap

The same as without_mmap keyword in Global Settings Specification of configuration files.

--stdin2stdout

When applied with --inetd, each command obtained from stdin is output to stdout. This option is useful for debugging.

-l option or --log option

The same as log_option keyword in Global Settings Specification of configuration files.

-d option

The same as debug_option keyword in Global Settings Specification of configuration files.

## CONFIGURATION FILE
Introduction

The configuration file defaults to /etc/dictd.conf but can be specified on the command line with the -c option (see above).

The configuration file is read into memory at startup, and is not referenced again by dictd unless a signal 1 (SIGHUP) is received, which will cause dictd to reread the configuration file.

The file is divided into sections. The Access Section should come first, followed by the Database Section, and the User Section. The Database Section is required; the others are optional, but they must be in the order listed here.

Syntax

The following keywords are valid in a configuration file: access, allow, deny, group, database, data, index, filter, prefilter, postfilter, name, include, user, authonly, site. Keywords are case sensitive. String arguments that contain spaces should be surrounded by double quotes. Without quoting, strings may contain alphanumeric characters and _, -, ., and *, but not spaces. Strings can be continued between lines. \", \\, \n, \<NL> are treated as double quote, backslash, new line and no symbol respectively. Comments start with # and extend to the end of the line.

Global Settings Section

global { global settings specification }

Used to set global dictd setting such as log file, syslog facility, locale and so on.

EXAMPLE:

See examples/dictd4.conf file from the distribution.

Access Section

access { access specification }

This section contains access restrictions for the server and all of the databases collectively. Per-database control is specified in the Database Section.

EXAMPLE:

See examples/dictd3.conf file from the distribution.

Database Section

database string { database specification }

The string specifies the name of the database (e.g., wn or web1913). (This is an arbitrary name selected by the administrator, and is not necessarily related to the file name or any name listed in the data file. A short, easy to type name is often selected for easy use with dict -d.)

EXAMPLE: See examples/dictd*.conf files from the distribution.

NOTE: If the files specified in the database specification do not exist on the system, dictd may silently fail.

database_virtual string { virtual database specification }

This section specifies the virtual database. The string specifies the name of the database (e.g., en-ru or fren).

EXAMPLE: See examples/dictd_virtual.conf or examples/dictd_complex.conf files from the distribution.

database_plugin string { plugin specification }

This section specifies the plugin. The string specifies the name of the database.

EXAMPLE: See examples/dictd_plugin_dbi.conf or examples/dictd_complex.conf files from the distribution.

database_mime string { mime specification }

Traditionally, databases created for dictd contained plain text only because dictd releases before 1.10.0 didn't have full support of OPTION MIME option (consult with RFC-2229). This section describes the special database which behaves differently depending on whether OPTION MIME command was received from client or was not, i.e. the database created by this section allows to return to the client either a plain text or specially formatted content depending on whether DICT client supports (or wants to receive) MIMEized content or doesn't. The string specifies the name of the database.

NOTE: All this is about DEFINE command only. MATCH, SHOW DB, SHOW STRAT, SHOW INFO, SHOW SERVER and HELP commands return texts prepended with empty line only.

EXAMPLE: See examples/dictd_mime.conf file from the distribution.

database_exit

Excludes following databases from the '*' database. By default '*' means all databases available. Look at 'examples/dictd_virtual.conf' file for example configuration.

NOTE: If you use 'virtual' dictionaries, you should use this directive, otherwise you will search the same dictionary twice.

User Section

user string string

The first string specifies the username, and the second string specifies the shared secret for this username. When the AUTH command is used, the client will provide the username and a hashed version of the shared secret. If the shared secret matches, the user is said to have authenticated, and will have access to databases whose access specifications allow that user (by name, or by wildcard). If present, this section must appear last in the configuration file. There may be many user entries. The shared secret should be kept secret, as anyone who has access to it can access the shared databases (assuming access is not denied by domain name).

Access Specification

Access specifications may occur in the Access Section or in the Database Section. The access specification will be described here. For allow, deny, and authonly, a star (*) may be used as a wild card that matches any number of characters. A question mark (?) may be used as a wildcard that matches a single character. For example, 10.0.0.* and *.edu are valid strings.

Further, a range of IP addresses and an IP address followed by a netmask may be specified. For example, 10.0.0.0:10.0.0.255, 10.0.0.0/24, and 10.0.0.* all specify the same range of IP numbers. Notation cannot be combined on the same line. If the notation does not make sense, access will be denied by default. Use the --debug auth option to debug related problems.

Note that these specifications take only one string per specification line. However, you can have multiple lines of each type.

The syntax is as follows:

allow string

The string specifies a domain name or IP address which is allowed access to the server (in the Access Section) or to a database (in the Database Section). Note that more than one string is not permitted for a single "allow" line, but more than one "allow" lines are permitted in the configuration file.

deny string

The string specifies a domain name or IP address which is denied access to the server (in the Access Section) or to a database (in the Database Section). Note that if reverse DNS is not working, then only the IP number will be checked. Therefore, it is essential to deny networks based on IP number, since a denial based on domain name may not always be checked.

authonly string

This form is only useful in the Access Section. The string specifies a domain name or IP address which is allowed access to the server but not to any of the databases. All commands are valid except DEFINE, MATCH, and SHOW DB. More specifically AUTH is a valid command, and commands which access the databases are not allowed.

user string

This form is only useful in the Database Section. The string specifies a username that is allowed to access this database after a successful AUTH command is executed.

Global Settings Specification

This section describes the following parameters: port string_or_number

Specifies the port or service name (e.g., 2628). The default is 2628, as specified in the DICT Protocol RFC, but may be changed in the defs.h file at compile time (DICT_DEFAULT_SERVICE).

site string

Used to specify the filename for the site information file, a flat text file which will be displayed in response to the SHOW SERVER command.

EXAMPLE: See examples/dictd4.conf file from the distribution.

site_no_banner boolean

By default SHOW SERVER command outputs information about dictd version and an operating system type. This option disables this.

site_no_uptime boolean

By default SHOW SERVER command outputs information about uptime of dictd , a number of forks since startup and forks per hour. This option disables this.

site_no_dblist boolean

By default SHOW SERVER command outputs internal information about databases, such as a number of headwords, index size and so on. This option disables this.

delay number

Specifies the number of seconds a client may be idle before the server will close the connection. Idle time is defined to be the time the server is waiting for input and does not include the time the server spends searching the database. The default is 0 seconds (no limit), but may be changed in the defs.h file at compile time (DICT_DEFAULT_DELAY).

NOTE: Setting delay option disables limit_time option. Only one of them (last specified in dictd.conf ) is in effect. NOTE: Connections are closed without warning since no provision for premature connection termination is specified in the DICT protocol RFC.

depth number

Specify the queue length for listen(2). Specifies the number of pending socket connections which are queued by the operating system. Some operating systems may silently limit this value to 5 (older BSD systems) or 128 (Linux). The default is 10 but may be changed in the defs.h file at compile time (DICT_QUEUE_DEPTH).

limit_childs number

Specifies the number of daemons that may be running simultaneously. Each daemon services a single connection. If the limit is exceeded, a (serialized) connection will be made by the server process, and a response code 420 (server temporarily unavailable) will be sent to the client. This parameter should be adjusted to prevent the server machine from being overloaded by dict clients, but should not be set so low that many clients are denied useful connections. The default is 100, but may be changed in the defs.h file at compile time (DICT_DAEMON_LIMIT_CHILDS).

limit number

Synonym for limit_childs. For backward compatibility only.

limit_matches number

Specifies the maximum number of matches that can be returned by MATCH query. Zero means no limit. The default is 2000.

limit_definitions number

Specifies the maximum number of definitions that can be returned by DEFINE query. Zero means no limit. The default is 200.

limit_time number

Specifies the number of seconds a client may talk to the server before the server will close the connection. The default is 600 seconds (10 minutes), but may be changed in the defs.h file at compile time (DICT_DEFAULT_LIMIT_TIME).

NOTE: Setting limit_time option disables delay option. Only one of them (last specified in dictd.conf ) is in effect.

NOTE: Connections are closed without warning since no provision for premature connection termination is specified in the DICT protocol RFC.

limit_queries number

Specifies the number of queries (MATCH, DEFINE, SHOW DB etc.) that client may send to the server before the server will close the connection. Zero means no limit. The default is 2000, but may be changed in the defs.h file at compile time (DICT_DEFAULT_LIMIT_QUERIES).

timestamp number

How often a timestamp should be logged (int minutes). (This is effective only if logging has been enabled with the -s or -L option, or with a debugging option.)

log_option option

Specify a logging option. This is effective only if logging has been enabled with the -s or -L option or in configuration file, or logging to the console has been activated with a debugging option (e.g., --debug nodetach. Only one option may be set with each invocation of this option; however, multiple invocations of this option may be made in configuration file or dictd command line. For instance:

dictd -s --log stats --log found --log notfound

is a valid command line, and sets three logging options.

Some of the more verbose logging options are used primarily for debugging the server code, and are not practical for normal use.

server

Log server diagnostics. This is extremely verbose.

connect

Log all connections.

stats

Log all children terminations.

command

Log all commands. This is extremely verbose.

client

Log results of CLIENT command.

found

Log all words found in the databases.

notfound

Log all words not found in the databases.

timestamp

When logging to a file, use a full timestamp like that which syslog would produce. Otherwise, no timestamp is made, making the files shorter.

host

Log name of foreign host.

auth

Log authentication failures.

min

Set a minimal number of options. If logging is activated (to a file, or via syslog), and no options are set, then the minimal set of options will be used. If options are set, then only those options specified will be used.

all

Set all of the options.

none

Clear all of the options.

To facilitate location of interesting information in the log file, entries are marked with initial letters indicating the class of the line being logged:

I

Information about the server, connections, or termination statistics. These lines are generally not designed to be parsed automatically.

E

Error messages.

C

CLIENT command information.

D

Definitions found in the databases searched.

M

Matches found in the database searched.

N

Matches which were not found in the databases searched.

T

Trace of exact line sent by client.

A

Authentication information.

To preserve anonymity of the client, do not use the connect or host options. Clients may or may not send host information using the CLIENT command, but this should be an option that is selectable on the client side.

debug_option string

Activate a debugging option. There are several, all of which are only useful to developers. They are documented here for completeness. A list can be obtained interactively by using -d with an illegal option.

verbose

The same as -v or --verbose. Adds verbosity to other options.

scan

Debug the scanner for the configuration file.

parse

Debug the parser for the configuration file.

search

Debug the character folding and binary search routines.

init

Report database initialization.

port

Log client-side port number to the log file.

lev

Debug Levenshtein search algorithm.

auth

Debug the authorization routines.

nodetach

Do not detach as a background process. Implies that a copy of the log file will appear on the standard output.

nofork

Do not fork daemons to service requests. Be a single-threaded server. This option implies nodetach, and is most useful for using a debugger to find the point at which daemon processes are dumping core.

alt

Debugs altcompare in index.c.

locale string

Specifies the locale used for searching. If no locale is specified, the "C" locale is used. The locale used for the server should be the same as that used for dictfmt when the database was built (specifically, the locale under which the index was sorted). The locale should be specified for both 8-bit and UTF-8 formats. If locale contains utf8 or utf-8 substring, UTF-8 format is expected. Note that if your database is not in ASCII7 or UTF-8 format, then the dictd server will not be compliant to RFC 2229.

NOTE If utf-8 or 8-bit dictionaries are included in the configuration file, and the appropriate --locale has not been specified, dictd will fail to start. This implies that dictd will not run with both utf-8 and 8-bit dictionaries in the configuration file.

add_strategy strategy_name description

Adds strategy strategy_name with the description description. This new search strategy may be implemented with a help of plugins. Both strategy_name and description are strings.

default_strategy string

Set the server's default search strategy for MATCH search type. The compiled-in default is 'lev'. It is also possible to set default strategy per database. See default_strategy keyword in Database specification section.

disable_strategy string

Disable specified strategies. By default all implemented search strategies are enabled. It is also possible to disable strategies per database. See disable_strategy keyword in Database specification section.

listen_to host

Local host name or IP address for bind. If unspecified or *, dictd will bind to all interfaces. Otherwise, dictd will bind to this address only.

address_family family

If 4, address family is IPv4 (the default), if 6, address family is IPv6.

syslog string

Log using the syslog(3) facility.

syslog_facility string

Specifies the syslog facility to use. The use of this option implies the -s option to turn on logging via syslog. When the operating system libraries support SYSLOG_NAMES, the names used for this option should be those listed in syslog.conf(5). Otherwise, the following names are used (assuming the particular facility is defined in the header files): auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, and local7.

log_file string

Specify the file for logging. The filename specified is recomputed on each use using the strftime(3) call. For example, a filename ending in ".%Y%m%d" will write to log files ending in the year, month, and date that the log entry was written.

NOTE: If dictd does not have write permission for this file, it will silently fail.

pid_file string

The specified filename will be created to contain the process id of the main dictd process. The default is /var/run/dictd.pid

fast_start

By default, dictd creates (in memory) additional index to make the search faster. This option disables this behaviour and makes startup faster.

without_mmap

do not use the mmap(2) function and read entire files into memory instead. Use this option, if you know exactly what you are doing.

Database Specification

The database specification describes the database: data string

Specifies the filename for the flat text database. If the filename does not begin with '.' or '/', it is prepended with $datadir/. It is a compile time option. You can change this behaviour by editing Makefile or running ./configure --datadir=...

index string

Specifies the filename for the index file. Path matter is similar to that described above in "data" option .

index_suffix string

This is optional index file to make 'suffix' search strategy faster (binary search). It is generated by 'dictfmt_index2suffix'. Run "dictfmt_index2suffix --help" for more information. Path matter is similar to that described above in "data" option .

index_word string

This is optional index file to make 'word' search strategy faster (binary search). It is generated by 'dictfmt_index2word'. Run "dictfmt_index2word --help" for more information. Path matter is similar to that described above in "data" option .

prefilter string

Specifies the prefilter command. When a chunk of the compressed database is read, it will be filtered with this filter before being decompressed. This may be used to provide some additional compression that knows about the data and can provide better compression than the LZ77 algorithm used by zlib.

postfilter string

Specifies the postfilter command. When a chunk of the compressed database is read, it will be filtered with this filter before the offset and length for the entry are used to access data. This is provided for symmetry with the prefilter command, and may also be useful for providing additional database compression.

filter string

Specifies the filter command. After the entry is extracted from the database, it will be filtered with this filter. This may be used to provide formatting for the entry (e.g., for html).

name string

Specifies the short name of the database (e.g., "1913 Webster's"). If the string begins with @, then it specifies the headword to look up in the dictionary to find the short name of the database. The default is "@00-database-short", but this may be changed in the defs.h file at compile time (DICT_SHORT_ENTRY_NAME).

info string

Specifies the information about database. If the string begins with @, then it specifies the headword to look up in the dictionary to find information. The default is "@00-database-info", but this may be changed in the defs.h file at compile time (DICT_INFO_ENTRY_NAME).

invisible

Makes dictionary invisible to the clients i.e. this dictionary will not be recognized or shown by DEFINE, MATCH, SHOW INFO, SHOW SERVER and SHOW DB commands. If some definitions or matches are found in invisible dictionary, the name of the upper visible virtual dictionary is returned. Dictionaries '*' and '!' don't include invisible ones. NOTE: Invisible dictionaries are completely inaccessible (and invisible) to the client unless they are included to the virtual or MIME dictionary (See database_virtual or database_mime database sections).

disable_strategy string

Disables the specified strategy for database. This may be useful for slow dictionaries (plugins) or for dictionaries included to virtual ones. For an example see file examples/dictd_complex.conf.

default_strategy string

Specifies the strategy which will be used if the database is accessed using the strategy '.'. I.e. this directive is the way to set the preferred search strategy per database. For example, instead of strategy lev , the strategy word may be preferred for databases mainly containing the multiword phrases but the single words.

Virtual Database Specification

The virtual database specification describes the virtual database: database_list string

Specifies a list of databases which are included into the virtual database. Database names are in the string and are separated by comma.

name string

Specifies the short name of the database. See database specification

info string

Specifies the information about database. See database specification

invisible

Makes dictionary invisible to the clients. See database specification

disable_strategy string

Disables the specified strategy for database. See database specification

Plugin Specification

plugin string

Specifies a filename of the plugin.

data string

Specifies data for initializing plugin.

name string

Specifies the short name of the database. See Database Specification for more information.

info string

Specifies the information about database. See Database Specification for more information.

invisible

Makes dictionary invisible to the clients. See Database Specification for more information.

disable_strategy string

Disables the specified strategy for database. See Database Specification for more information.

default_strategy string

Sets the default search strategy for database. See Database Specification for more information.

Mime Specification

dbname_nomime string

Specifies the real database name which is used in case OPTION MIME command was NOT received from a client.

dbname_mime string

Specifies the real database name which is used in case OPTION MIME command WAS received from a client. A necessary MIME header is set while creating a database. See dictfmt(1) for option --mime-header.

name string

Specifies the short name of the database. See Database Specification for more information.

info string

Specifies the information about database. See Database Specification for more information.

invisible

Makes dictionary invisible to the clients. See Database Specification for more information.

disable_strategy string

Disables the specified strategy for database. See Database Specification for more information.

default_strategy string

Sets the default search strategy for database. See Database Specification for more information.

include string

The text of the file "string" (usually a database specification) will be read as if it appeared at this location in the configuration file. Nested includes are not permitted.

## DETERMINATION OF ACCESS LEVEL
When a client connects, the global access specification is scanned, in order, until a specification matches. If no access specification exists, all access is allowed (e.g., the action is the same as if "allow *" was the only item in the specification). For each item, both the hostname and IP are checked. For example, consider the following access specification:

allow 10.42.*

authonly *.edu

deny *

With this specification, all clients in the 10.42 network will be allowed access to unrestricted databases; all clients from *.edu sites will be allowed to authenticate, but will be denied access to all databases, even those which are otherwise unrestricted; and all other clients will have their connection terminated immediately. The 10.42 network clients can send an AUTH command and gain access to restricted databases. The *.edu clients must send an AUTH command to gain access to any databases, restricted or unrestricted. When the AUTH command is sent, the access list for each database is scanned, in order, just as the global access list is scanned. However, after authentication, the client has an associated username. For example, consider the following access specification:

user u1

deny *.com

user u2

allow *

If the client authenticated as u1, then the client will have access to this database, even if the client comes from a *.com site. In contrast, if the client authenticated as u2, the client will only have access if it does not come from a *.com site. In this case, the "user u2" is redundant, since that client would also match "allow *". Warning: Checks are performed for domain names and for IP addresses. However, if reverse DNS for a specific site is not working, it is possible that a domain name may not be available for checking. Make sure that all denials use IP addresses. (And consider a future enhancement: if a domain name is not available, should denials that depend on a domain name match anything? This is the more conservative viewpoint, but it is not currently implemented.)

## SEARCH ALGORITHMS
The DICT standard specifies a few search algorithms that must be implemented, and permits others to be supported on a server-dependent basis. The following search strategies are supported by this server. Note that all strategies are case insensitive. Most ignore non-alphanumeric, non-whitespace characters.

exact

An exact match. This algorithm uses a binary search and is one of the fastest search algorithms available.

lev

The Levenshtein algorithm (string edit distance of one). This algorithm searches for all words which are within an edit distance of one from the target word. An "edit" means an insertion, deletion, or transposition. This is a rapid algorithm for correcting spelling errors, since many spelling errors are within a Levenshtein distance of one from the original word.

prefix

Prefix match. This algorithm also uses a binary search and is very fast.

nprefix

Like prefix but returns the specified range of matches. For example, when prefix strategy returns 1000 matches, you can get only 100 ones skipping the first 800 matches. This is made by specified these limits in a query like this: 800#100#app, where 800 is skip count, 100 is a number of matches you want to get and "app" is your query. This strategy allows to implement DICT client with fast autocompletion (although it is not trivial) just like many standalone dictionary programs do.

NOTE: If you access the dictionary "*" (or virtual one) with nprefix strategy, the same range is set for each database in it, but globally for all matches found in all databases.

NOTE: In case you access non-english dictionary the returned matches may be (and mostly will be) NOT ordered in alphabetic order.

re

POSIX 1003.2 (modern) regular expression search. Modern regular expressions are the ones used by egrep(1). These regular expressions allow predefined character classes (e.g., [[:alnum:]], [[:alpha:]], [[:digit:]], and [[:xdigit:]] are useful for this application); uses * to match a sequence 0 or more matches of the previous atom; uses + to match a sequence of 1 or more matches of the previous atom; uses ? to match a sequence of 0 or 1 matches of the previous atom; used ^ to match the beginning of a word, uses $ to match the end of a word, and allows nested subexpression and alternation with () and |. For example, "(foo|bar)" matches all words that contain either "foo" or "bar". To match these special characters, they must be quoted with two backslashes (due to the quoting characteristics of the server). Warning: Regular expression matches can take 10 to 300 times longer than substring matches. On a busy server, with many databases, this can required more than 5 minutes of waiting time, depending on the complexity of the regular expression.

regexp

Old (basic) regular expressions. These regular expressions don't support |, +, or ?. Groups use escaped parentheses. While modern regular expressions are generally easier to use, basic regular expressions have a back reference feature. This can be used to match a second occurrence of something that was already matched. For example, the following expression finds all words that begin and end with the same three letters:

```
    ^\\(...\\).*\\1$
```

Note the use of the double backslashes to escape the special characters. This is required by the DICT protocol string specification (a single backslash quotes the next character -- we use two to get a single backslash through to the regular expression engine). Warning: Note that the use of backtracking is even slower than the use of general regular expressions.

soundex

The Soundex algorithm, a classic algorithm for finding words that sound similar to each other. The algorithm encodes each word using the first letter of the word and up to three digits. Since the first letter is known, this search is relatively fast, and it sometimes good for correcting spelling errors when the Levenshtein algorithm doesn't help.

substring

Match a substring anywhere in the headword. This search strategy uses a modified Boyer-Moore-Horspool algorithm. Since it must search the whole index file, it is not as fast as the exact and prefix matches.

suffix

Suffix match. This search strategy also uses a modified Boyer-Moore-Horspool algorithm, and is as fast as the substring search. If the optional index_suffix string file is listed in the configuration file this search is much faster.

word

Match any single word, even if part of a multi-word entry. If the optional index_word string file is listed in the configuration file this search strategy works much faster.

first

Match the first word that begins a multi-word entry.

last

Match the last word that ends a multi-word entry. If the optional index_suffix string file is listed in the configuration file this search strategy works much faster.

## DATABASE FORMAT
Databases for dictd are distributed separately. A database consists of two files. One is a flat text file, the other is the index.

The flat text file contains dictionary entries (or any other suitable data), and the index contains tab-delimited tuples consisting of the headword, the byte offset at which this entry begins in the flat text file, and the length of the entry in bytes. The offset and length are encoded using base 64 encoding using the 64-character subset of International Alphabet IA5 discussed in RFC 1421 (printable encoding) and RFC 1522 (base64 MIME). Encoding the offsets in base 64 saves considerable space when compared with the usual base 10 encoding, while still permitting tab characters (ASCII 9) to be used for delimiting fields in a record. Each record ends with a newline (ASCII 10), so the index file is human readable.

Some headwords are used by dictd especially

00-database-info Containts the information about database which is returned by SHOW INFO command, unless it is specified in the configuration file.

00-database-short Containts the short name of the database which is returned by SHOW DB command, unless it is specified in the configuration file. See dictfmt -s.

00-database-url URL where original dictionary sources were obtained from. See dictfmt -u. This headword is not used by dictd

00-database-utf8 Presents if dictionary is encoded using UTF-8. See dictfmt --utf8

00-database-8bit-new Presents if dictionary is encoded using 8-BIT character set (not ASCII and not UTF8). See dictfmt --locale.

The flat text file may be compressed using gzip(1) (not recommended) or dictzip(1) (highly recommended). Optimal speed will be obtained using an uncompressed file. However, the gzip compression algorithm works very well on plain text, and can result in space savings typically between 60 and 80%. Using a file compressed with gzip(1) is not recommended, however, because random access on the file can only be accomplished by serially decompressing the whole file, a process which is prohibitively slow. dictzip(1) uses the same compression algorithm and file format as does gzip(1), but provides a table that can be used to randomly access compressed blocks in the file. The use of 50-64kB blocks for compression typically degrades compression by less than 10%, while maintaining acceptable random access capabilities for all data in the file. As an added benefit, files compressed with dictzip(1) can be decompressed with gzip(1) or zcat(1). (Note: recompressing a dictzip'd file using, for example, znew(1) will destroy the random access characteristics of the file. Always compress data files using dictzip(1).)

## SIGNALS
SIGHUP causes dictd to reread configuration file and reinitialize databases.

SIGUSR1 causes dictd to unload databases. Then dictd returns 420 status (instead of 220). To load databases again, send SIGHUP signal. Because database files are mmap'ed(2) , it is impossible to update them while dictd is running. So, if you need to update database files and reread configuration file, first, send SIGUSR1 signal to dictd to unload databases, update files, and then send SUGHUP signal to load them again.

## COPYING
The main source files for the dictd server and the dictzip compression program were written by Rik Faith (faith@dict.org) and are distributed under the terms of the GNU General Public License. If you need to distribute under other terms, write to the author.

The main libraries used by these programs (zlib, regex, libmaa) are distributed under different terms, so you may be able to use the libraries for applications which are incompatible with the GPL -- please see the copyright notices and license information that come with the libraries for more information, and consult with your attorney to resolve these issues.

## BUGS
The regular expression searches do not ignore non-whitespace, non-alphanumeric characters as do the other searches. In practice, this isn't much of a problem.

## WARNINGS
Conformance of regular expressions (used by 're' and 'regexp' search strategies) to ERE and BRE depends on library you build dictd with. Whether 're' and 'regex' strategies support utf8 depends on library you build dictd with.

## FILES
/etc/dictd.conf

dictd configuration file

/usr/sbin/dictd

dictd daemon itself

/var/run/dictd.pid

File for storing pid of dictd daemon

/usr/share

The default directory for dictd databases (.index and .dict[.dz] files)

## SEE ALSO
examples/dictd*.conf, dictfmt(1), dict(1), dictzip(1), gunzip(1), zcat(1), webster(1), RFC 2229


diod

package: diod

title: diod(8)

summary: distributed I/O daemon

text:
# diod(8)

## NAME
diod - distributed I/O daemon

## SYNOPSIS
diod [OPTIONS]

## DESCRIPTION
diod is the distributed I/O daemon server, which implements I/O forwarding on Linux clusters.

Configuration is read from the diod.conf (5) config file. Some configuration can be overridden on the command line, as described below.

## OPTIONS
-f, --foreground

Do not change working directory to /var/lib/run, drop the controlling terminal, or run in the background. Send logs to stderr not syslog, unless sent somewhere else by -L.

-r, --rfdno INT

-w, --wfdno INT

Serve a connected client inherited on the specified read and write file descriptors. For file descriptors connected bidirectionally, the two options may be set to the same value.

-l, --listen address

Set the listen address. The address may be in the form of HOST:PORT, IP:PORT, or /path/to/unix_domain_socket form (default 0.0.0.0:564). This option may be specified more than once. It overrides the listen config file setting.

-t, --nwthreads INT

Set the number of worker threads to spawn to handle 9P operations for each unique aname. This option overrides the nwthreads setting in diod.conf (5). The default is 16.

-e, --export PATH

Set the file system to be exported. This option may be specified more than once. It overrides the exports setting in diod.conf (5).

-E, --export-all

Export everything in the server's /proc/mounts.

-o, --export-opts OPT[,OPT,...]

Set global export options. This option overrides the exportopts setting in diod.conf (5).

-n, --no-auth

This option allows users to attach without security credentials. It overrides the auth_required setting in diod.conf (5).

-N, --no-userdb

This option disables password/group lookups. It allows any uid to attach and assumes gid=uid, and supplementary groups contain only the primary gid. It overrides the userdb setting in diod.conf (5).

-S, --allsquash

Remap all users to the squash user. The attaching user need not be present in the server's password file. This option overrides the allsquash setting in diod.conf (5).

-U, --squashuser

Set the squash user. The default is nobody. This option overrides the squashuser setting in diod.conf (5). Note: if diod is not run as root, the effective uid overrides the squashuser.

-u, --runas-uid UID

Run the server as UID and only allow that user to attach. If invoked as root, diod sets real and effective uid, gid, and supplementary groups to those belonging to UID.

-L, --logdest DEST

Set the destination for logging. Possible destinations are syslog:facility:level, stderr, stdout, or a file name. This option overrides the logdest setting in diod.conf (5).

-d, --debug MASK

Set the debug mask. The bit values are:

0x01 - log decoded 9P protocol messages

-c, --config-file PATH

Set config file path.

## FILES
/usr/sbin/diod

/etc/diod.conf

## SEE ALSO
diod.conf (5), mount.diod (8), hosts_access (5)

branch: sisyphus


diodcat

title: diodcat(8)

text:
# diodcat(8)

## NAME
diodcat - cat files by attaching directly to diod server

## SYNOPSIS
diodcat [OPTIONS] [-s NAME] [-a aname] [file [file...]]

## DESCRIPTION
diodcat connects to a diod server, attaches to the mount point aname, and concatenates the contents of the specified files on stdout.

## OPTIONS
-a, --aname NAME

The file system name on the server (default "ctl"). Note that the "ctl" synthetic file system must be explicitly exported.

-s, --server NAME

The server in IP[:PORT], HOST[:PORT], or /path/to/socket form (default localhost:564).

-m, --msize SIZE

The maximum request size including 9P headers (default 65536).

-u, --uid UID

Try to attach to the server as the specified user (default your effective uid).

-t, --timeout SECS

Force timeout after specified number of seconds (default no timeout).

-p, --privport

Connect from a socket bound to a port in the range of 512-1023, available to root only. This can be used in conjunction with the privport export option.

## SEE ALSO
diod (8)


dioddate

title: dioddate(8)

summary: get server system time

text:
# dioddate(8)

## NAME
dioddate - get server system time

## SYNOPSIS
dioddate [OPTIONS] [-s NAME] [file [file...]]

## DESCRIPTION
dioddate obtains the current system time and zone information from a diod server by reading ctl:date. If the --set-time option is specified, sets the local system time on the client; otherwise prints the server time on stdout.

This is a simple way to obtain rough time synchronization before issuing a MUNGE-authenticated attach request, for example in a bootstrap environment where the "ctl" synthetic file system is exported with the "noauth" option.

## OPTIONS
-s, --server NAME

The server in IP[:PORT], HOST[:PORT], or /path/to/socket form (default localhost:564).

-m, --msize SIZE

The maximum request size including 9P headers (default 65536).

-u, --uid UID

Try to attach to the server as the specified user (default your effective uid).

-t, --timeout SECS

Force timeout after specified number of seconds (default no timeout).

-S, --set-time

Set the local system time to match the server's time.

## SEE ALSO
diod (8)


diodload

title: diodload(8)

summary: create artificial diod load

text:
# diodload(8)

## NAME
diodload - create artificial diod load

## SYNOPSIS
diodload [OPTIONS] [-s NAME]

## DESCRIPTION
diodload connects to a diod server and issues requests. Unless changed with -g, each thread copies from ctl:zero to ctl:null. Note that the "ctl" synthetic file system must be explicitly exported.

## OPTIONS
-s, --server NAME

The server in IP[:PORT], HOST[:PORT], or /path/to/socket form default localhost:564).

-m, --msize SIZE

Specifiy the maximum size of a protocol unit (default 65536).

-r, --runtime SECS

Specify the runtime in seconds (default 10).

-n, --numthreads NUM

Specify the number of concurrent threads making requests (default 16).

-g, --getattr

Issue a stream of getattrs on ctl:null instead of the default load.

## SEE ALSO
diod (8)


diodls

title: diodls(8)

text:
# diodls(8)

## NAME
diodls - list files by attaching directly to diod server

## SYNOPSIS
diodls [OPTIONS] [-s NAME] [-a aname] [file [file...]]

## DESCRIPTION
diodls connects to a diod server, attaches to the mount point aname, and lists the specified files or directories.

## OPTIONS
-a, --aname NAME

The file system name on the server (default ctl). Note that the "ctl" synthetic file system must be explicitly exported.

-s, --server NAME

The server in IP[:PORT], HOST[:PORT], or /path/to/socket form (default localhost:564).

-m, --msize SIZE

The maximum request size including 9P headers (default 65536).

-u, --uid UID

Try to attach to the server as the specified user (default your effective uid).

-t, --timeout SECS

Force timeout after specified number of seconds (default no timeout).

-l, --long

List stat information in addition to file names.

-p, --privport

Connect from a socket bound to a port in the range of 512-1023, available to root only. This can be used in conjunction with the privport export option.

## SEE ALSO
diod (8)


diodmount

title: diodmount(8)

summary: mount diod file systems

text:
# diodmount(8)

## NAME
mount.diod - mount diod file systems

## SYNOPSIS
mount.diod [OPTIONS] host[:aname] dir [-o options]

## DESCRIPTION
mount.diod is the mount utility for the distributed I/O daemon, which is an I/O forwarding service for Linux clusters built upon the Linux 9p file system.

mount.diod performs two main tasks: 1) connect and authenticate to the diod server, and 2) issue the mount(2) system call with appropriate mount options.

Authentication with the diod server takes place in user space. The connected (and authenticated) file descriptor is passed as a mount option to the kernel 9p file system

This command requires root to execute the mount(2) system call.

The 9p file system must support the 9P2000.L protocol variant, e.g. kernel 2.6.38 or above.

The host portion of the mount spec may optionally be supplied in hostlist format, e.g. host1,host2,host3:aname or host[1-3]:aname, in which case hosts are tried in order until a successful connection is obtained. Post-connect mount errors are immediately fatal.

If the host portion of the mount spec begins with a forward-slash (/), it refers to the path to a UNIX domain socket.

## COMMAND LINE OPTIONS
-f, --fake-mount

Do everything except the mount system call.

-n, --no-mtab

Do not update the system mtab.

-v, --verbose

Set verbose mode.

-o, --options opt[,opt,...]

Set mount options (see below).

## MOUNT OPTIONS
The following file system specific mount options are handled by mount.diod.

aname=name

The aname is the path of the exported file system on the server. It can be specified in the mount spec in host:aname format like NFS, or it can be specified with this option. diod will not allow an attach to an empty aname. diod has a built-in synthetic control file system that can be mounted with aname of ctl. Note that "ctl" must be explicitly exported.

uname=name

The user name to authenticate to the diod server. The default is uname=root.

access=mode

Select the access mode. access=user (default) causes the mount to support multiple users, and requires root authentication. access=<uid> restricts access at the client to only the specified user.

port=n

Connect to the diod server on the specified port. The default is the IANA-assigned 9pfs port 564.

trans=name

Select a transport. mount.diod only supports trans=fd because of its strategy for authentication.

rfdno=n,wfdno=n

The file descriptor for reading and writing with trans=fd. If set, mount.diod assumes this file descriptor is already connected to a diod server and ignores host in the device specification, and the port=n option.

msize=n

The msize is the max 9P packet payload size. The default is 65512 (65536-24)

version=name

Select 9P protocol version. diod only supports 9p2000.L.

cache=mode

Specify a caching policy. By default, no caches are used. If cache=loose, no attempts are made at consistency. This mode is intended for exclusive, read-only mounts. If cache=fscache, use FS-Cache for a persistent, read-only cache backend.

cachetag

In the context of cache=fscache, select the cache tag to use for this session. Cache tags for existing cache sessions are listed in /sys/fs/9p/caches.

nodevmap

Do not map special files. Represent them as normal files. This can be used to share devices/named pipes/sockets between hosts.

debug=n

Specifies debug level for the kernel 9p module. The debug level is a bitmask.

0x01 = display verbose error messages

0x02 = developer debug (DEBUG_CURRENT)

0x04 = display 9p trace

0x08 = display VFS trace

0x10 = display Marshalling debug

0x20 = display RPC debug

0x40 = display transport debug

0x80 = display allocation debug

0x100 = display protocol message debug

0x200 = display Fid debug

0x400 = display packet debug

0x800 = display fscache tracing debug

The debug level is global, i.e. it applies to all 9P file systems and it remains set after the file system is unmounted. The default is debug=0.

## SEE ALSO
diod (8)


diodshowmount

title: diodshowmount(8)

summary: list diod server connections

text:
# diodshowmount(8)

## NAME
diodshowmount - list diod server connections

## SYNOPSIS
diodshowmount [OPTIONS] [-s NAME]

## DESCRIPTION
diodshowmount connects to a diod server and displays a list of clients connected to that server in hostlist format, with domain name suffixes stripped. With no options, it reads "ctl:version" from "localhost". Note that the "ctl" synthetic file system must be explicitly exported.

## OPTIONS
-s, --server NAME

The server in IP[:PORT], HOST[:PORT], or /path/to/socket form (default localhost:564).

-m, --msize SIZE

The maximum request size including 9P headers (default 65536).

-u, --uid UID

Try to attach to the server as the specified user (default your effective uid).

-t, --timeout SECS

Force timeout after specified number of seconds (default no timeout).

-l, --long

List clients one per line without removing domain name suffixes, if any.

## SEE ALSO
diod (8)


dtop

title: dtop(8)

summary: display diod performance

text:
# dtop(8)

## NAME
dtop - display diod performance

## SYNOPSIS
dtop [-h hostlist] [OPTIONS]

## DESCRIPTION
dtop connects to diod servers and displays performance information.

## OPTIONS
-h, --hostlist HOSTS

Specify the lists of diod servers that dtop monitors. Multiple hosts may be separated by commas, and host ranges may be included in the list, e.g. x[1-3,42] is equivalent to x1,x2,x3,x42. By default, dtop monitors localhost. Note that dtop uses the "ctl" synthetic file system. "ctl" must be explicitly exported.

-P, --poll-period SEC

Set the polling period. SEC may be a floating point number. The default is 1 second.

-p, --port PORT

Specify the server port number for all monitored servers (default 564).

## SEE ALSO
diod (8)


dkms

package: dkms

title: dkms(8)

summary: Dynamic Kernel Module Support

text:
# dkms(8)

## NAME
dkms - Dynamic Kernel Module Support

## SYNOPSIS
dkms

[action] [options] [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar] [/path/to/driver.rpm]

## DESCRIPTION
dkms is a framework which allows kernel modules to be dynamically built for each kernel on your system in a simplified and organized fashion.

## ACTIONS
add

[module/module-version | /path/to/source-tree | /path/to/tarball.tar]

Adds a module/module-version combination to the tree for builds and installs. If module/module-version, -m module/module-version, or -m module -v module-version are passed as options, this command requires source in /usr/src/<module>-<module-version>/ as well as a properly formatted dkms.conf file. If /path/to/source-tree is passed as an option, and source-tree contains a dkms.conf file, it will copy /path/to/source-tree to /usr/src/module-module-version. If /path/to/tarball.tar is passed, this command behaves like the ldtarball command.

remove

[module/module-version] [-k kernel/arch] [--all]

Removes a module/version or module/version/kernel/arch combination from the tree. If the module is currently installed, it first uninstalls it and if applicable, will replace it with its original_module. Use the --all option in order to remove all instances for every kernel at once.

build

[module/module-version] [-k kernel/arch] [--force]

Builds the specified module/version combo for the specified kernel/arch. If the -k option is not specified it builds for the currently running kernel and arch. All builds occur in the directory /var/lib/dkms/<module>/<module-version>/build/ . If the module/module-version combo has not been added, dkms will try to add it, and in that case build can take the same arguments that add can. If the module is already built, it will not be rebuilt again by default, and the --force option should be used to override this.

unbuild

[module/module-version] [-k kernel/arch] [--all]

Undoes the build for a module/version or module/version/kernel/arch combination from the tree. If the module is currently installed, it first uninstalls it and if applicable, will replace it with its original_module. Finally all binary kernel modules are removed. Use the --all option in order to remove all instances for every kernel at once.

install

[module/module-version] [-k kernel/arch] [--force] [/path/to/driver.rpm]

Installs a built module/version combo onto the kernel it was built for. If the kernel option is not specified it assumes the currently running kernel. If the module has not been built, dkms will try to build it. If the module has not been added, dkms will try to add it. In both cases, the install command can then take the same arguments as the build or add commands. If the module is already installed, it will not be reinstalled again by default, and the --force option should be used to override this. If you pass a .rpm file, dkms will try to install that file with rpm -Uvh, and it will perform an autoinstall action to be sure that everything is built for your kernel if the RPM installed successfully.

uninstall

[module/module-version] [-k kernel/arch] [--all]

Uninstalls an installed module/module-version combo from the kernel/arch passed in the -k option, or the current kernel if the -k option was not passed. Use the --all option in order to uninstall all instances for every kernel at once. After uninstall completion, the driver will be left in the built state. To completely remove a driver, the remove action should be utilized.

match

[--templatekernel kernel/arch] [-k kernel/arch]

Match installs modules onto the specified kernel by looking at the configuration of the specified templatekernel. Every module that is installed on the templatekernel within dkms is then installed on that specified kernel.

mktarball

[module/module-version] [-k kernel/arch] [--archive /path/to/tarball.tar] [--source-only] [--binaries-only]

Creates a tarball archive for the specified module/version of all files in the DKMS tree for that module/version combination. This includes the source and any built modules for kernels in the tree (as specified). Otherwise, you can specify a singular kernel to archive only, or multiple kernels to archive ( -k kernel1/arch1 -k kernel2/arch2 ). Optionally, you can use --archive to specify the file that you would like to save this tarball to. You can also specify --binaries-only if you want the resultant tarball not to include the module source. Likewise, --source-only can be used to specify that no prebuilt binaries should be included in the tarball. In general, mktarball is great for systems management purposes as you can build your driver on just one system and then use ldtarball on all of your other systems to get the same built modules loaded without having to wait for anything to compile.

ldtarball

[/path/to/tarball.tar] [--force]

This takes a tarball made from the mktarball command and loads it into your DKMS tree. This will leave any newly added modules in the built state and dkms install should then be called to install any of them. If files already exist where ldtarball is attempting to place them, it will warn and not copy over them. The --force option should be used to override this.

status

[module/module-version] [-k kernel/arch]

Returns the current status of modules, versions and kernels within the tree as well as whether they have been added, built or installed. Status can be shown for just a certain module, a certain kernel, a module/version combination or a module/version/kernel combination. If the source directory, or the symbolic link 'source' pointing to it is missing, the status of the module/version combination will be displayed as 'broken'. In that case dkms will not perform any other action on that particular module/version combination. Manual intervention is required. If only the symbolic link 'source' is missing, the add action may be used to re-add the module/version combination to dkms.

autoinstall

Attempt to install the latest revision of all modules that have been installed for other kernel revisions. The DKMS autoinstaller service is a stub that uses this action to perform its work.

generate_mok

Command to be issued standalone to generate Secure Boot keys. Required only if prior manipulation of the keys is needed, otherwise the keys are automatically generated on the first build attempt of a DKMS module. No additional arguments are parsed.

## OPTIONS
-m <module>/<module-version>

The name of the module and module version you want to operate on. The -m part of this option is optional, and can be omitted in virtually all circumstances.

-v <module-version>

The version of the module to execute the specified action upon. This option only has to be specified if you pass a -m option without a <module-version> component of its own.

-k <kernel-version>/<arch>

The kernel and arch to perform the action upon. You can specify multiple kernel version/arch pairs on the command line by repeating the -k argument with a different kernel version and arch. However, not all actions support multiple kernel versions (it will error out in this case). The arch part can be omitted, and DKMS will assume you want it to be the arch of the currently running system.

-a, --arch

The system architecture to perform the action upon. It is optional if you pass it as part of the -k option. If not specified, it assumes the arch of the currently running system ( uname -m ). You can specify multiple arch parameters on the same command line by repeating the -a argument with a different architecture name. When multiple architectures are specified, there must be a 1:1 relationship between -k arguments to -a arguments. DKMS will then assume the first -a argument aligns with the first -k and so on for the second, third, etc. For example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686 -a x86_64 , DKMS would process this as: kernel1-i386 , kernel2-i686 , kernel3-x86_64.

-q, --quiet

Quiet.

-V, --version

Prints the currently installed version of dkms and exits.

-h, --help

-c <dkms.conf-location>

The location of the dkms.conf file. This is needed for the add action and if not specified, it is assumed to be located in /usr/src/<module>-<module-version>/ . See below for more information on the format of dkms.conf.

--config <kernel-include/config/auto.conf-location>

During a build this option is used to specify an alternate location for the kernel include/config/auto.conf configuration file which contains that kernel configuration. Normally, dkms is able to derive the location of the configuration file from the filesystem, but if there is a problem in the detection, you will need to tell dkms where the necessary include/config/auto.conf file (or the legacy .config file) can be found so that your kernel can be properly prepared for the module build.

--archive <tarball-location>

This option is used during a ldtarball action to specify the location of the tarball you wish to load into your DKMS tree. You only have to specify the --archive part of this option if <tarball-location> does not already exist as a file.

--templatekernel <kernel-version>

This option is required for the action: match. Match will look at the templatekernel specified and install all of the same module/version combinations on the other kernel.

--force

This option can be used in conjunction with build, install and ldtarball to force copying over existing files.

--force-version-override

This option skips the checks whether the version of the module, which is going to be installed, is newer than the already installed version.

--binaries-only

This option can be used in conjunction with mktarball in order to create a DKMS tarball which does not contain the source for the module within it. This can be helpful in reducing the size of the tarball if you know that the system which this tarball will be loaded upon already has the source installed. In order to load a tarball made as binaries-only you must have the module source in that systems DKMS tree. If you do not, DKMS will refuse to load a binaries-only tarball.

--source-only

This option can be used in conjunction with mktarball but do not want the tarball you create to have any prebuilt modules within it, passing this option will keep its internal DKMS tarball from containing any prebuilt modules.

--all

This option can be used to automatically specify all relevant kernels/arches for a module/module-version. This can be used for things like remove, unbuild and uninstall. This saves the trouble of having to actually specify -k kernel1 -a arch1 -k kernel2 -a arch2 for every kernel you have built your module for.

--no-depmod

This option prevents DKMS from running the depmod command during install and uninstall which will avoid (re)calculating module dependencies and thereby save time.

--modprobe-on-install

This option executes modprobe on the modules upon successful installation.

--kernelsourcedir <kernel-source-directory-location>

Using this option you can specify the location of your kernel source directory. Most likely you will not need to set this if your kernel source is accessible via /lib/modules/$kernel_version/build.

--directive <"cli-directive=cli-value">

Using this option, you can specify additional directives from the command line. The --directive option can be used multiple times on the same command-line to specify multiple additional command line directives.

--rpm_safe_upgrade

This flag should be used when packaging DKMS enabled modules in RPMs. It should be specified during both the add and remove actions in the RPM spec to ensure that DKMS and RPM behave correctly in all scenarios when upgrading between various versions of a dkms enabled module RPM package.

--dkmstree path/to/place

Provides a destination tree for building and installing modules to. Useful in cases that you don't want to contaminate a system when using solely for building.

--sourcetree path/to/place

Provides a location to build a DKMS package from. Useful for systems that you may not have root access, but would still like to be able to build DKMS packages.

--installtree path/to/place

Provides a location to place modules when a dkms install command is issued.

-j number

Run no more than number jobs in parallel; see the -j option of make(1). Defaults to the number of CPUs in the system, detected by nproc(1). Specify 0 to impose no limit on the number of parallel jobs.

--verbose

Enable verbose output of external commands executed in DKMS.

## ORIGINAL MODULES
During the first install of a module for a <kernelversion>, dkms will search /lib/modules/<kernelversion> for a pre-existing module of the same name. If one is found, it will automatically be saved as an "original_module" so that if the newer module is later removed, dkms will put the original module back in its place. Currently, DKMS searches for these original modules with first preference going to modules located in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODULE_LOCATION (as specified in dkms.conf ). If one cannot be found in either location, a find will be used to locate one for that kernel. If none are found, then during a later uninstall, your kernel will not have that module replaced.

If more than one is found, then the first one located (by preference indicated above) will be considered the "original_module". As well, all copies of the same-named module will be removed from your kernel tree and placed into /var/lib/dkms/<module>/original_module/$kernelver/collisions so that they can be *manually* accessible later. DKMS will never actually do anything with the modules found underneath the /collisions directory, and they will be stored there until you manually delete them.

## DKMS.CONF
When performing an add, a proper dkms.conf file must be found. A properly formatted configuration file is essential for communicating to DKMS how and where the module should be installed. While not all the directives are required, providing as many as possible helps to limit any ambiguity. Note that dkms.conf is really only a shell-script of variable definitions which are then sourced in by the dkms executable (of the format, DIRECTIVE="directive text goes here" ). As well, the directives are case-sensitive and should be given in ALL CAPS.

It is important to understand that many of the DKMS directives are arrays whose index values are tied together. These array associations can be considered families, and there are currently three such families of directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family. PATCH[#] and PATCH_MATCH[#] make up the second family. The third and largest family consists of BUILT_MODULE_NAME[#] , BUILT_MODULE_LOCATION[#] , DEST_MODULE_NAME[#] , DEST_MODULE_LOCATION[#] and STRIP[#] . When indexing these arrays when creating your dkms.conf , each family should start at index value 0.

PACKAGE_NAME=

This directive is used to give the name associated with the entire package of modules. This is the same name that is used with the -m option when building, adding, etc. and may not necessarily be the same as the MODULE_NAME. This directive must be present in every DKMS configuration file.

PACKAGE_VERSION=

This directive is used to give the version associated with the entire package of modules being installed within that dkms package. This directive must be present in every DKMS configuration file.

BUILT_MODULE_NAME[#]=

This directive gives the name of the module just after it is built. If your DKMS module package contains more than one module to install, this is a required directive for all of the modules. This directive should explicitly not contain any trailing ".o" or ".ko". Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME , BUILT_MODULE_LOCATION , DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300" ).

BUILT_MODULE_LOCATION[#]=

This directive tells DKMS where to find your built module after it has been built. This pathname should be given relative to the root directory of your source files (where your dkms.conf file can be found). If unset, DKMS expects to find your BUILT_MODULE_NAME[#] in the root directory of your source files. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME , BUILT_MODULE_LOCATION , DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. BUILT_MODULE_LOCATION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/" ).

DEST_MODULE_NAME[#]=

This directive can be used to specify the name of the module as it should be installed. This will rename the module from BUILT_MODULE_NAME[#] to DEST_MODULE_NAME[#]. This directive should explicitly not contain any trailing ".o" or ".ko". If unset, it is assumed to be the same value as BUILT_MODULE_NAME[#]. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME , BUILT_MODULE_LOCATION , DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x" ).

DEST_MODULE_LOCATION[#]=

This directive specifies the destination where a module should be installed to, once compiled. It also is used for finding original_modules. This is a required directive, except as noted below. This directive must start with the text "/kernel" which is in reference to /lib/modules/<kernelversion>/kernel. Note that for each module within a dkms package, the numeric value of # must be the same for each of BUILT_MODULE_NAME , BUILT_MODULE_LOCATION , DEST_MODULE_NAME and DEST_MODULE_LOCATION and that the numbering should start at 0 (eg. DEST_MODULE_LOCATION[0]="/kernel/drivers/something/" DEST_MODULE_LOCATION[1]="/kernel/drivers/other/" ). DEST_MODULE_LOCATION is ignored on Fedora, Red Hat Enterprise Linux, SuSE Linux Enterprise Server, openSUSE and Ubuntu. Instead, the proper distribution-specific directory is used.

STRIP[#]=

By default strip is considered to be "yes". If set to "no", DKMS will not run strip -g against your built module to remove debug symbols from it. STRIP[0] is used as the default for any unset entries in the STRIP array.

MAKE[#]=

The MAKE directive array tells DKMS which make command should be used for building your module. The default make command should be put into MAKE[0]. Other entries in the MAKE array will only be used if their corresponding entry in MAKE_MATCH[#] matches, as a regular expression (using grep -E), the kernel that the module is being built for. Note that if no value is placed in MAKE_MATCH[#] for any MAKE[#] where # > 0, then that MAKE directive is ignored. MAKE_MATCH[0] is optional and if it is populated, it will be used to determine if MAKE[0] should be used to build the module for that kernel. If multiple MAKE_MATCH directives match against the kernel being built for, the last matching MAKE[#] will be used to build your module. If no MAKE directive is specified or if no MAKE_MATCH matches the kernel being built for, DKMS will attempt to use a generic make command to build your module. KERNELRELEASE=$kernelver -j$parallel_jobs will be automatically appended to MAKE[#]. If you want to suppress this behavior, you can quote the make command: 'make'.

MAKE_MATCH[#]=

See the above entry on MAKE[#] directives. This array should be populated with regular expressions which, when matched against the kernel being built for, will tell DKMS to use the corresponding make command in the MAKE[#] directive array to build your module.

NO_WEAK_MODULES=

The NO_WEAK_MODULES directive, when set to "yes", prevents dkms from creating a symlink into the weak-updates directory. The weak modules facility was designed to eliminate the need to rebuild kernel modules when kernel upgrades occur and relies on the symbols within the kABI. Valid values are "yes" or "no". The kABI kernel module interface is currently supported on Red Hat Enterprise Linux (and derivatives), SUSE Linux Enterprise Server and openSUSE Leap; on other distributions this directive is ignored.

OBSOLETE_BY=

This directive is deprecated and will be removed in a future version. Consider using BUILD_EXCLUSIVE_KERNEL_MAX instead of OBSOLETE_BY as the former is a more general approach to solve the same problem. It allows you to specify a kernel version that obsoletes the necessity for this particular DKMS module. This can be specified as a particular upstream kernel or an ABI bump of a kernel. For example, "2.6.24" would be an upstream kernel and "2.6.24-16" would represent an ABI bump for a kernel. Both are valid in this area.

Its use indicates a lack of proper module versioning using MODULE_VERSION() tags in the module source itself. It is better to fix the MODULE_VERSION() tags than use OBSOLETE_BY. This also introduces a implicit distribution/version dependency on the package, as the value of OBSOLETE_BY is meaningful only in the context of a single distribution/version.

PATCH[#]=

Use the PATCH directive array to specify patches which should be applied to your source before a build occurs. All patches are expected to be in -p1 format and are applied with the patch -p1 command. Each directive should specify the filename of the patch to apply, and all patches must be located in the patches subdirectory of your source directory ( /usr/src/<module>-<module-version>/patches/ ) or in /etc/dkms/<module>/patches/ (which takes precedence over the source directory). If any patch fails to apply, the build will be halted and the rejections can be inspected in /var/lib/dkms/<module>/<module-version>/build/. If a patch should only be applied conditionally, the PATCH_MATCH[#] array should be used, and a corresponding regular expression should be placed in PATCH_MATCH[#] which will alert dkms to only use that PATCH[#] if the regular expression matches the kernel which the module is currently being built for.

PATCH_MATCH[#]=

See the above description for PATCH[#] directives. If you only want a patch applied in certain scenarios, the PATCH_MATCH array should be utilized by giving a regular expression which matches the kernels you intend the corresponding PATCH[#] to be applied to before building that module.

AUTOINSTALL=

If this directive is set to "yes" then the DKMS autoinstaller service will automatically try to install this module on any kernel you boot into. See the section on DKMS AUTOINSTALLER for more information. Valid values are "yes" or "no".

BUILD_DEPENDS[#]=

This optional directive is an array that allows you to specify other modules as dependencies for your module. Each array element should be the PACKAGE_NAME of another module that is managed by dkms. Do not specify a version or architecture in the dependency. A missing dependency requires the parameter [--force] to still attempt the build of the module. When invoked through autoinstall , unresolved dependencies are handled differently depending on whether they are known to dkms. A dependency that is itself a dkms-managed module but failed to install (for example because of a circular dependency or a build error) is treated as a hard failure and causes autoinstall to exit non-zero. A dependency that is not registered with dkms at the time autoinstall runs is treated as deferred: a warning is emitted and the dependent module is left in the added state, but autoinstall exits successfully. This avoids spurious failures during multi-package installs where the dependency's source package has not yet had its postinst run, or where the dependency is supplied by something outside dkms. The dependent module will be picked up by the next autoinstall trigger once the dependency becomes available.

Example: Ubuntu system with module A and module B depending on A. During an update, both the kernel and module A get updated, so autoinstall runs as a kernel post hook. This means the whole dependency logic fails because module A is not yet installed to satisfy module B.

BUILD_DEPENDS_REBUILD=

If this directive is set to yes then the module which has BUILD_DEPENDS being set, will get rebuilt every time a dependency changes version. This is usually provided in a specific /etc/dkms/<module>.conf on a per installation basis. To keep track of the dependency change, the version of the module that was used at build time is recorded in the file /var/lib/dkms/<module>/<kernel_version>-<arch>/.dep_<dependency>. As soon as the module version changes, this is compared and the dependent module is rebuilt. With the parameter --force the dependency is not tracked.

BUILD_EXCLUSIVE_KERNEL=

This optional directive allows you to specify a regular expression which defines the subset of kernels which DKMS is allowed to build your module for. If the kernel being built for does not match against this regular expression (or does not the satisfy the constraints of any other BUILD_EXCLUSIVE_* directive), the build will error out with exit code 77. Note that dkms autoinstall will ignore this type of error condition and simply skip the respective modules. For example, if you set it as ="^2.4.*", your module would not be built for 2.6 or later kernels.

BUILD_EXCLUSIVE_KERNEL_MIN=

and BUILD_EXCLUSIVE_KERNEL_MAX= These optional directives allow one to specify the minimal and maximal kernel versions supported by the module. If one (or both) of these are defined, the module will not be built for kernels outside the specified version limits. For example, if you set BUILD_EXCLUSIVE_KERNEL_MIN as "=3.5", your module would be built for e.g. "3.5-rc2", "3.6.18" or other later versions but not for "3.4.999" or earlier kernels. Similarly, if you set BUILD_EXCLUSIVE_KERNEL_MAX as ="4.12", your module would be built for e.g. "4.11.999", "3.9-rc5" or other earlier versions, but not for "4.12-rc1" or later kernels.

BUILD_EXCLUSIVE_ARCH=

This optional directive functions very similarly to BUILD_EXCLUSIVE_KERNEL except that it matches against the kernel architecture. For example, if you set it to ="i.86", your module would not be built for ia32e, x86_64, amd64, s390, etc.

BUILD_EXCLUSIVE_CONFIG=

This optional directive allows you to specify a space separated list of kernel configuration options ("CONFIG_FOO") that must be enabled in the targeted kernels ".config" file (either to be compiled in or to be built as a module) or absent (if prefixed with an exclamation mark, e.g. "!CONFIG_BAR") in order to build the module. For example, if you set it as ="CONFIG_PCI !CONFIG_PREEMPT_RT", your module would only be built for kernels that have PCI enabled, but the RT patchset disabled.

BUILD_EXCLUSIVE_KERNEL[#]=, BUILD_EXCLUSIVE_KERNEL_MIN[#]=, BUILD_EXCLUSIVE_KERNEL_MAX[#]=, BUILD_EXCLUSIVE_ARCH[#]=, BUILD_EXCLUSIVE_CONFIG[#]=

These optional per-module directives function identically to their global counterparts but apply only to the specific module at the given index. They allow you to specify different BUILD_EXCLUSIVE constraints for each module in a multi-module package. The global BUILD_EXCLUSIVE directives are still checked for backward compatibility, and if any module fails either the global or its specific per-module constraints, the build will be excluded. For example, if you have two modules in your package: BUILD_EXCLUSIVE_KERNEL[0]="^5..*" BUILD_EXCLUSIVE_KERNEL[1]="^6..*" Module 0 would only be built for kernel 5.x, while module 1 would only be built for kernel 6.x.

POST_ADD=

The name of the script to be run after an add is performed. The path should be given relative to the root directory of your source.

POST_BUILD=

The name of the script to be run after a build is performed. The path should be given relative to the root directory of your source.

POST_INSTALL=

The name of the script to be run after an install is performed. The path should be given relative to the root directory of your source.

POST_REMOVE=

The name of the script to be run after a remove is performed. The path should be given relative to the root directory of your source.

PRE_BUILD=

The name of the script to be run before a build is performed. The path should be given relative to the root directory of your source.

PRE_INSTALL=

The name of the script to be run before an install is performed. The path should be given relative to the root directory of your source. If the script exits with a non-zero value, the install will be aborted. This is typically used to perform a custom version comparison.

All scripts (POST_ADD, PRE_BUILD, POST_BUILD, PRE_INSTALL, POST_INSTALL, POST_REMOVE) can also be placed in /etc/dkms/<module>/ instead of the module source directory. Scripts in /etc/dkms/<module>/ take precedence over scripts in the source directory.

## DKMS.CONF VARIABLES
Within your DKMS configuration file, you can use certain variables which will be replaced at run-time with their values.

$kernelver

This variable can be used within a directive definition and during use, the actual kernel version in question will be substituted in its place. This is especially useful in MAKE commands when specifying which INCLUDE statements should be used when compiling your module (eg. MAKE="make all INCLUDEDIR=/lib/modules/${kernelver}/build/include").

$kernel_source_dir

This variable holds the value of the location of your kernel source directory. Usually, this will be /lib/modules/$kernelver/build, unless otherwise specified with the --kernelsourcedir option.

## DKMS.CONF OVERRIDES
You can override directives provided in the module-provided dkms.conf files. Every time after a dkms.conf file is read, dkms will look for and read the following files in order:

/etc/dkms/<module>.conf

/etc/dkms/<module>-<module-version>.conf

/etc/dkms/<module>-<module-version>-<kernel>.conf

/etc/dkms/<module>-<module-version>-<kernel>-<arch>.conf

You can use these files to override settings in the module-provided dkms.conf file.

Additionally, patches and scripts can be placed in /etc/dkms/<module>/ to override those provided by the module source tree:

/etc/dkms/<module>/patches/ — patch files (override same-named patches from the source directory; the directory structure is preserved, so patches in subdirectories such as /etc/dkms/<module>/patches/subdir/patch.patch will override the corresponding subdir/patch.patch from the source tree)

/etc/dkms/<module>/ — scripts referenced by PRE_BUILD, POST_BUILD, etc. (override same-named scripts from the source directory)

## FRAMEWORK.CONF MAIN CONFIGURATION
The /etc/dkms/framework.conf configuration file controls how the overall DKMS framework handles. It is sourced in every time the dkms command is run. Mainly it can currently be used to set different default values for the variables.

The file contains descriptions for each directive it supports.

Additionally to /etc/dkms/framework.conf , any file matching the glob /etc/dkms/framework.conf.d/*.conf will be loaded as well.

dkms_tree, source_tree, install_tree, tmp_location

Control which folders DKMS uses for components and artifacts.

verbose

Can be set to anything but a null value to enable verbose output of external commands executed in DKMS.

symlink_modules

Controls whether binary modules are copied to /lib/modules or if only symlinks are created there. Note that these variables can also be manipulated on the command line with --dkmstree , --sourcetree , --installtree and --symlink-modules options.

autoinstall_all_kernels

Used by the common postinst for DKMS modules. It controls if the build should be done for all installed kernels or only for the current and latest installed kernel. It has no command line equivalent.

sign_file

This is the path of the sign-file kernel binary that is used to sign the kernel modules. The variable $kernelver can be used in path to represent the target kernel version. The path for the binary depends on the distribution.

mok_signing_key, mok_certificate

Location of the key and certificate files used for Secure boot. The variable $kernelver can be used in path to represent the target kernel version. NOTE: If any of the files specified by mok_signing_key and mok_certificate are non-existent, dkms will re-create both files.

mok_signing_key can also be a "pkcs11:..." string for PKCS#11 engine, as long as the sign-file program supports it.

modprobe_on_install

Automatically load the built modules upon successful installation.

parallel_jobs

Run no more than this number of jobs in parallel.

compress_gzip_opts, compress_xz_opts, compress_zstd_opts

Control how modules are compressed. By default, the highest available level of compression is used.

build_environment

If the directive is set to any non null-value, when building modules, the exported variables that are in the file will be imported into the DKMS shell with the source command. Can be used to specify a custom gcc installed in a custom path; and the variable $kernelver can be used inside the environment file to represent the target kernel version. Some examples:

Define a custom script to point to a specific GCC ( export CC=/opt/gcc12/bin/gcc ): build_environment="/opt/gcc12/env"

Enable the software collection gcc-toolset-11 and use it for building an UEK kernel on Oracle Linux: build_environment="/opt/rh/gcc-toolset-11/enable"

post_transaction

If the directive is set to any non null-value, the content of the directive will be executed with any command that change the content of the kernel modules folder, that is dkms autoinstall, dkms install and dkms remove/unbuild/uninstall. Can be used to trigger a global initrd rebuild or to call a script that performs some other tasks (calling kexec, triggering the restart of services not contained in a DKMS package, etc.). The command is constructed with the shell built-in eval and the variable $kernelver can be used to represent the target kernel version. Some examples: Regenerate the ram disk for the target kernel: post_transaction="dracut --force --kver $kernelver" (Red Hat style) or post_transaction="update-initramfs -k $kernelver" (Debian style).

Launch an arbitrary script: post_transaction="/path/to/script.sh"

Restart a service: post_transaction="systemctl restart something.service"

Regenerate the ram disk for all installed kernels, ignoring the kernel version passed as the parameter: post_transaction="dracut --force --regenerate-all" (Red Hat style) or post_transaction="update-initramfs -k all" (Debian style).

## DKMS AUTOINSTALLER
The DKMS autoinstaller service (which can be dkms_autoinstaller or dkms.service depending on your distribution) is a boot-time service automatically installs any module which has AUTOINSTALL="yes" set in its dkms.conf file. The service works quite simply and if multiple versions of a module are in your system's DKMS tree, it will not do anything and instead explain that manual intervention is required.

## AUTHOR
Gary Lerhaupt, Emil Velikov, Simone Caronni, Xu Zhen

## WEBPAGE
https://github.com/dkms-project/dkms


package: dlm

title: dlm_controld(8)

summary: dlm cluster control daemon

text:
# dlm_controld(8)

## NAME
dlm_controld - dlm cluster control daemon

## SYNOPSIS
dlm_controld [OPTIONS]

## DESCRIPTION
The kernel dlm requires a user daemon to manage lockspace membership. dlm_controld manages lockspace membership using corosync cpg groups, and translates membership changes into dlm kernel recovery events. dlm_controld also manages posix locks for cluster file systems using the dlm.

## OPTIONS
Command line options override a corresponding setting in dlm.conf(5).

For default settings, see dlm_controld -h.

--daemon_debug | -D

enable debugging to stderr and don't fork

--foreground

don't fork

--log_debug | -K

enable kernel dlm debugging messages

--protocol | -r str

dlm kernel lowcomms protocol: tcp, sctp, detect

--debug_logfile | -L

write debugging to log file

--enable_plock | -p 0|1

enable/disable posix lock support for cluster fs

--plock_debug | -P

enable plock debugging

--plock_rate_limit | -l int

limit rate of plock operations (0 for none)

--plock_ownership | -o 0|1

enable/disable plock ownership

--drop_resources_time | -t int

plock ownership drop resources time (milliseconds)

--drop_resources_count | -c int

plock ownership drop resources count

--drop_resources_age | -a int

plock ownership drop resources age (milliseconds)

--post_join_delay | -j int

seconds to delay fencing after cluster join

--enable_fencing | -f 0|1

enable/disable fencing

--enable_concurrent_fencing 0|1

enable/disable concurrent fencing

--enable_startup_fencing | -s 0|1

enable/disable startup fencing

--enable_quorum_fencing | -q 0|1

enable/disable quorum requirement for fencing

--enable_quorum_lockspace 0|1

enable/disable quorum requirement for lockspace operations

--enable_helper 0|1

enable/disable helper process for running commands

--repeat_failed_fencing 0|1

enable/disable retrying after fencing fails

--fence_all str

fence all nodes with this agent

--unfence_all

enable unfencing self with fence_all agent

--help | -h

print this help, then exit

--version | -V

Print program version information, then exit

## SEE ALSO
dlm_tool(8), dlm.conf(5)


title: dlm_stonith(8)

text:
# dlm_stonith(8)

## NAME
dlm_stonith - a proxy for fencing via stonith/pacemaker

## SYNOPSIS
dlm_stonith

## DESCRIPTION
dlm_controld can use dlm_stonith as a proxy fence agent when the stonith/pacemaker system performs actual fencing.

dlm_stonith is run by dlm_controld, and is not meant to be run manually. dlm_controld provides the options on stdin as key=val; command line options are for testing.

If fencing was successful, this program has a zero exit code. If fencing failed, this program has a non-zero exit code.

## OPTIONS
-n nodeid

The nodeid of the target node. (stdin key is "node")

-t fail_time

The time(2) at which the target node failed. If this option is provided, and the last fencing time is later, then a new fencing request is not made.

## SEE ALSO
dlm_controld(8), dlm.conf(5)


title: dlm_tool(8)

text:
# dlm_tool(8)

## NAME
dlm_tool - a utility for the dlm and dlm_controld daemon

## SYNOPSIS
dlm_tool [COMMAND] [OPTIONS] [ name ]

## COMMANDS
ls

Display dlm_controld internal lockspace state.

status

Dump dlm_controld daemon state.

dump

Dump dlm_controld debug buffer.

dump_config

Dump dlm_controld config settings.

reload_config

Reload dlm_controld config settings from dlm.conf.

set_config setting=value

Set dlm_controld config settings in the currently running daemon.

fence_ack nodeid

Cancel a waiting fencing operation and consider it successful.

log_plock

Dump dlm_controld plock debug buffer.

plocks lockspace_name

Dump posix locks from dlm_controld for the lockspace.

join lockspace_name

Join a lockspace.

leave lockspace_name

Leave a lockspace.

joinleave lockspace_name

Join then immediately leave a lockspace (for testing only.)

lockdebug lockspace_name

Complete display of locks from the lockspace.

lockdump lockspace_name

Minimal display of locks from the lockspace (deprecated).

run command

Run command and check for result (for lvmlockd only.)

run_start command

Run command and don't check for result.

run_check uuid

Check status of a command that was run.

run_cancel uuid

Cancel a command that was run and is not yet done.

run_list

Dump a list of running commands.

## OPTIONS
-n Show all node information from dlm_tool ls.

-d 0|1 Resource directory off/on in join, default 0

-e 0|1 Exclusive create off/on in join, default 0

-f 0|1 FS (filesystem) flag off/on in join, default 0

-i sec Seconds to wait in run_check.

-m mode Permission mode for lockspace device (octal), default 0600

-s Summary following lockdebug output (experiemental)

-v Verbose lockdebug or status output

-w Wide lockdebug output

-M Include MSTCPY locks in lockdump output

-h Print help, then exit

-V Print program version information, then exit

## USAGE

### fence_ack
See dlm_tool status for information about waiting fencing operations for specific nodeid's.

### set_config
dlm_tool set_config can change certain config settings in the currently running dlm_controld. Supported options:

```
daemon_debug
log_debug
debug_logfile
plock_debug
plock_rate_limit
drop_resources_time
drop_resources_count
drop_resources_age
post_join_delay
enable_quorum_fencing
enable_quorum_lockspace
repeat_failed_fencing
```

Special cases to revert a previous set_config and restore the previous value (from default or dlm.conf):

dlm_tool set_config setting=restore

restores a single setting.

dlm_tool set_config restore_all

restores all settings.

### dump_config
A config setting may have been set from: the default, the dlm_controld command line, dlm.conf at startup, dlm.conf from reload_config, dlm_tool set_config. The dump_config output indicates how values were set:

setting=value

default value.

setting=value (cli option)

Set from a dlm_controld command line option.

setting=value (dlm.conf)

Set from dlm.conf (at startup or reload.)

setting=value (set_config)

Set from dlm_tool set_config.

## EXAMPLES

### dump_config

```
$ dlm_tool dump_config | head -n 5
daemon_debug=1 (set_config)
foreground=0
log_debug=1 (dlm.conf)
protocol=detect
```

In this case, daemon_debug is set by set_config, log_debug is set from dlm.conf, foreground and protocol are using default values.

### set_config

```
$ dlm_tool dump_config | grep log_debug
log_debug=1 (dlm.conf)
$ dlm_tool set_config "log_debug=0"
set_config done
$ dlm_tool dump_config | grep log_debug
log_debug=0 (set_config)
$ dlm_tool set_config "log_debug=restore"
set_config done
$ dlm_tool dump_config | grep log_debug
log_debug=1 (dlm.conf)
```

log_debug is set by dlm.conf (value is 1), then run set_config to change to 0, then use restore to restore to dlm.conf setting.

### set_config

```
$ dlm_tool dump_config | grep _debug
daemon_debug=0
log_debug=1 (dlm.conf)
plock_debug=0
$ dlm_tool set_config "daemon_debug=1 log_debug=1 plock_debug=1"
set_config done
$ dlm_tool dump_config | grep _debug
daemon_debug=1 (set_config)
log_debug=1 (set_config)
plock_debug=1 (set_config)
$ dlm_tool set_config "restore_all"
set_config done
$ dlm_tool dump_config | grep _debug
daemon_debug=0
log_debug=1 (dlm.conf)
plock_debug=0
```

## SEE ALSO
dlm_controld(8), dlm.conf(5)


biosdecode

package: dmidecode

title: biosdecode(8)

summary: \s-1BIOS\s0 information decoder

text:
# biosdecode(8)

## NAME
biosdecode - BIOS information decoder

## SYNOPSIS
biosdecode [OPTIONS]

## DESCRIPTION
biosdecode parses the BIOS memory and prints information about all structures (or entry points) it knows of. Currently known entry point types are:

- SMBIOS (System Management BIOS)

Use dmidecode for a more detailed output.

- DMI (Desktop Management Interface, a legacy version of SMBIOS)

Use dmidecode for a more detailed output.

- SYSID

- PNP (Plug and Play)

- ACPI (Advanced Configuration and Power Interface)

- BIOS32 (BIOS32 Service Directory)

- PIR (PCI IRQ Routing)

- 32OS (BIOS32 Extension, Compaq-specific)

See ownership for a Compaq ownership tag retrieval tool.

- SNY (Sony-specific, not decoded)

- VPD (Vital Product Data, IBM-specific)

Use vpddecode for a more detailed output.

- FJKEYINF (Application Panel, Fujitsu-specific)

biosdecode started its life as a part of dmidecode but as more entry point types were added, it was moved to a different program.

## OPTIONS
-d, --dev-mem FILE

Read memory from device FILE (default: /dev/mem)

--pir full

Decode the details of the PCI IRQ routing table. Only full mode is supported.

-h, --help

Display usage information and exit

-V, --version

Display the version and exit

## FILES
/dev/mem

## BUGS
Most of the time, biosdecode prints too much information (you don't really care about addresses) or not enough (because it doesn't follow pointers and has no lookup tables).

## AUTHORS
Alan Cox, Jean Delvare

## SEE ALSO
dmidecode(8), mem(4), ownership(8), vpddecode(8)