keepalived

package: keepalived

title: keepalived(8)

summary: load\-balancing and high\-availability service

text:
# keepalived(8)

## NAME
keepalived - load-balancing and high-availability service

## SYNOPSIS
keepalived [-f|--use-file=FILE] [-P|--vrrp] [-C|--check] [-B|--no_bfd] [--all] [-l|--log-console] [-D|--log-detail] [-S|--log-facility={0-7|local{0-7}|user|daemon}] [-g|--log-file=FILE] [--flush-log-file] [-G|--no-syslog] [-X|--release-vips] [-V|--dont-release-vrrp] [-I|--dont-release-ipvs] [-R|--dont-respawn] [-n|--dont-fork] [-d|--dump-conf] [-p|--pid=FILE] [-r|--vrrp_pid=FILE] [-T|--genhash] [-c|--checkers_pid=FILE] [-a|--address-monitoring] [-b|--bfd_pid=FILE] [-s|--namespace=NAME] [-e|--all-config] [-i|--config-id id] [-x|--snmp] [-A|--snmp-agent-socket=FILE] [-u|--umask=NUMBER] [-m|--core-dump] [-M|--core-dump-pattern[=PATTERN]] [--signum=SIGFUNC] [-t|--config-test[=FILE]] [--perf[={all|run|end}]] [--debug[=debug-options]] [--no-mem-check] [--ignore-sigint] [-v|--version] [-h|--help]

## DESCRIPTION
Keepalived provides simple and robust facilities for load-balancing and high-availability. The load-balancing framework relies on the well-known and widely used Linux Virtual Server (IPVS) kernel module providing Layer4 load-balancing. Keepalived implements a set of checkers to dynamically and adaptively maintain and manage a load-balanced server pool according to their health. Keepalived also implements the VRRPv2 and VRRPv3 protocols to achieve high-availability with director failover.

## OPTIONS
-f, --use-file=FILE

Use the specified configuration file. The default configuration file is "/etc/keepalived/keepalived.conf".

-P, --vrrp

Only run the VRRP subsystem. This is useful for configurations that do not use the IPVS load balancer.

-C, --check

Only run the healthcheck subsystem. This is useful for configurations that use the IPVS load balancer with a single director with no failover.

-B, --no_bfd

Don't run the BFD subsystem.

--all

Run all subsystems, even if they have no configuration.

-l, --log-console

Log messages to the local console. The default behavior is to log messages to syslog.

-D, --log-detail

Detailed log messages.

-S, --log-facility={0-7|local{0-7}|user|daemon}

Set syslog facility to LOG_LOCAL[0-7], LOG_USER or LOG_DAEMON. The default syslog facility is LOG_DAEMON.

-g, --log-file=FILE

Write log entries to FILE. FILE will have _vrrp, _healthcheckers, and _bfd inserted before the last '.' in FILE for the log output for those processes.

--flush-log-file

If using the -g option, the log file stream will be flushed after each write.

-G, --no-syslog

Do not write log entries to syslog. This can be useful if the rate of writing log entries is sufficiently high that syslog will rate limit them, and the -g option is used instead.

-X, --release-vips

Drop VIP on transition from signal.

-V, --dont-release-vrrp

Don't remove VRRP VIPs and VROUTEs on daemon stop. The default behavior is to remove all VIPs and VROUTEs when keepalived exits.

-I, --dont-release-ipvs

Don't remove IPVS topology on daemon stop. The default behavior it to remove all entries from the IPVS virtual server table when keepalived exits.

-R, --dont-respawn

Don't respawn child processes. The default behavior is to restart the VRRP and checker processes if either process exits.

-n, --dont-fork

Don't fork the daemon process. This option will cause keepalived to run in the foreground.

-d, --dump-conf

Dump the configuration data.

-p, --pid=FILE

Use the specified pidfile for the parent keepalived process. The default pidfile for keepalived is "/run/keepalived.pid", unless a network namespace is being used. See NAMESPACES below for more details.

-r, --vrrp_pid=FILE

Use the specified pidfile for the VRRP child process. The default pidfile for the VRRP child process is "/run/keepalived_vrrp.pid", unless a network namespace is being used.

-T, --genhash

Enter genhash utility mode. Previous versions of keepalived were shipped with a dedicated genhash utility. genhash is now part of the mainline code. We keep compatibility with previous genhash utility command line option. For more information please refer to the genhash(1) manpage.

-c, --checkers_pid=FILE

Use the specified pidfile for checkers child process. The default pidfile for the checker child process is "/run/keepalived_checkers.pid" unless a network namespace is being used.

-a, --address-monitoring

Log all address additions/deletions reported by netlink.

-b, --bfd_pid=FILE

Use the specified pidfile for the BFD child process. The default pidfile for the BFD child process is "/run/keepalived_bfd.pid" unless a network namespace is being used.

-s, --namespace=NAME

Run keepalived in network namespace NAME. See NAMESPACES below for more details.

-e, --all-config

Don't load if any configuration file is missing or cannot be read.

-i, --config-id ID

Use configuration id ID, for conditional configuration (defaults to hostname without the domain name).

-x, --snmp

Enable the SNMP subsystem.

-A, --snmp-agent-socket=FILE

Use the specified socket for connection to SNMP master agent.

-u, --umask=NUMBER

The umask specified in the usual numeric way - see man umask(2)

-m, --core-dump

Override the RLIMIT_CORE hard and soft limits to enable keepalived to produce a coredump in the event of a segfault or other failure. This is most useful if keepalived has been built with 'make debug'. Core dumps will be created in /, unless keepalived is run with the --dont-fork option, in which case they will be created in the directory from which keepalived was run, or they will be created in the directory of a configuraton file if the fault occurs while reading the file.

-M, --core-dump-pattern[=PATTERN]

Sets option --core-dump, and also updates /proc/sys/kernel/core_pattern to the pattern specified, or 'core' if none specified. Provided the parent process doesn't terminate abnormally, it will restore /proc/sys/kernel/core_pattern to its original value on exit. Note: This will also affect any other process producing a core dump while keepalived is running.

--signum=PATTERN

Returns the signal number to use for STOP, RELOAD, DATA, STATS, STATS_CLEAR, JSON and TDATA. For example, to stop keepalived running, execute:

```
kill -s $(keepalived --signum=STOP) $(cat /run/keepalived.pid)
```

-t, --config-test[=FILE]

Keepalived will check the configuration file and exit with non-zero exit status if there are errors in the configuration, otherwise it exits with exit status 0 (see Exit status below for details). Rather that writing to syslog, it will write diagnostic messages to stderr unless file is specified, in which case it will write to the file.

--perf[={all|run|end}]

Record perf data for vrrp process. Data will be written to /perf_vrrp.data. The data recorded is for use with the perf tool.

--no-mem-check

Disable malloc() etc mem-checks if they have been compiled into keepalived.

--ignore-sigint

Disable SIGINT handling (defaults to terminating keepalived). This is needed for running keepalived under GDB.

--debug[=debug-options]]

Enables debug options if they have been compiled into keepalived. debug-options is made up of a sequence of strings of the form Ulll.

The upper case letter specifies the debug option, and the lower case letters specify for which processes the option is to be enabled.

If a debug option is not followed by any lower case letters, the debug option is enabled for all processes.

The characters to identify the processes are: Chr

Process

p

Parent process

b

BFD process

c

Checker process

v

VRRP process

The characters used to identify the debug options are:

Chr

Debug option

D

Epoll thread dump

E

Epoll debug

F

VRRP fd debug

N

Netlink timers

P

Network timestamp

X

Regex timers

M

Email alert debug

T

Timer debug

S

TSM debug

R

Regex debug

B

Smtp connect debug

U

Checksum diagnostics

O

Track process debug

A

Track process debug with extra detail

C

Parser (config) debug

H

Checker debug

Z

Memory alloc/free error debug

G

VRRP recvmsg() debug

J

VRRP recvmsg() log rx data

V

Script debugging

K

Dump keywords

Example: --debug=DvEcvNR

-v, --version

Display the version and exit.

-h, --help

Display this help message and exit.

### Exit status:
0

if OK

1

if unable to malloc memory

2

if cannot initialise subsystems

3

if running with --config-test and configuration cannot be run

4

if running with --config-test and there are configuration errors but keepalived will run after modifying the configuration

5

if running with --config-test and script security hasn't been enabled but scripts are configured.

## NAMESPACES
keepalived can be run in a network namespace (see keepalived.conf(5) for configuration details). When run in a network namespace, a local mount namespace is also created, and /run/keepalived/keepalived_NamespaceName is mounted on /run/keepalived. By default, pid files with the usual default names are then created in /run/keepalived from the perspective of a process in the mount namespace, and they will be visible in /run/keepalived/keepalived_NamespaceName for a process running in the default mount namespace.

## SIGNALS
keepalived reacts to a set of signals. You can send a signal to the parent keepalived process using the following:

```
kill -SIGNAL $(cat /run/keepalived.pid)
```

or better:

```
kill -s $(keepalived --signum=SIGFUNC) $(cat /run/keepalived.pid)
```

Note that if the first option is used, -SIGNAL must be replaced with the actual signal you are trying to send, e.g. with HUP. So it then becomes:

```
kill -HUP $(cat /run/keepalived.pid)
```

Signals other than for STOP, RELOAD, DATA and STATS may change depending on the kernel, and also what functionality is included in the version of the keepalived depending on the build options used.

HUP or SIGFUNC=RELOAD

This causes keepalived to close down all interfaces, reload its configuration, and start up with the new configuration.

Note: If a virtual_ipaddress, virtual_route or virtual_rule is being moved from one VRRP instance to another one, two reloads will be necessary, the first to remove the virtual ipaddress/route/rule, and the second reload to add it to the VRRP instance it is now to be configured on. Failing to do this can result in the ipaddress/route/rule not being configured on the new instance if both the old and new instances are in master state. It will usually work with a single reload, however, if either of the VRRP instances is not in MASTER state or if the VRRP instance the ipaddress/route/rule the VRRP instance is being added to is later in the original configuration file than the instance it is being removed from. Note2: If a configuration is running with SNMP enable, and then a reload is done with a configuration that does not enable SNMP, it is not possible to subsequently re-enable SNMP. The reason for this is not currently understood.

TERM, INT or SIGFUNC=STOP

keepalived will shut down.

USR1 or SIGFUNC=DATA

Write configuration data to /tmp/keepalived.data or file configured by state_dump_file

USR2 or SIGFUNC=STATS

Write statistics info to /tmp/keepalived.stats or file configured by stats_dump_file

SIGFUNC=STATS_CLEAR

Write statistics info to /tmp/keepalived.stats or file configured by stats_dump_file and clear the statistics counters

SIGFUNC=JSON

Write configuration data in JSON format to /tmp/keepalived.json or file configured by json_dump_file

SIGFUNC=TDATA

This causes keepalived to write the current state of its internal threads to the log

## USING KEEPALIVED WITH FIREWALLD
If you are running a firewall (see firewalld(8)) you must allow VRRP protocol traffic through the firewall. For example if this instance of keepalived(8) has a peer node on IPv4 address 192.168.0.1:

```
# firewall-cmd \

    --add-rich-rule="rule family='ipv4' \

                     source address='192.168.0.1' \

                     protocol value='vrrp' accept" --permanent
# firewall-cmd --reload
```

## SEE ALSO
keepalived.conf(5), ipvsadm(8)

## AUTHOR
This man page was written by Ryan O'Hara <rohara@redhat.com>


package: kernel-headers-common

title: adjust_kernel_headers(8)

summary: select version of kernel headers

text:
# adjust_kernel_headers(8)

## NAME
adjust_kernel_headers - select version of kernel headers

## SYNOPSIS
adjust_kernel_headers [--list | --auto | --first | kernel-version]

## DESCRIPTION
adjust_kernel_headers maintains symbolic links which are used to select one of the available versions of kernel headers as the default kernel headers for the system.

Initially kernel headers selection is performed in the automatic mode. In this mode, when adjust_kernel_headers is called without parameters, it selects headers which match the running kernel; if such headers are not available, headers from the glibc-kernheaders package will be selected. This adjustment is performed by the kheaders service at every system startup, and also by installation scripts of packages with kernel headers.

If such automatic adjustment is not desired, the system administrator may switch kernel headers selection to the manual mode. In this mode adjust_kernel_headers called without parameters will not select a different version of headers, unless the manually selected version is no longer available (in which case it will switch to the automatic mode).

## OPTIONS
--list

Show all available versions of kernel headers.

--auto

Switch kernel headers selection to the automatic mode and select the appropriate headers.

--first

Switch kernel headers selection to the manual mode and choose the first kernel version in the alphabetic order from the installed kernel headers.

--help

Display help screen.

--version

Display version information.

kernel-version

Switch kernel headers selection to the manual mode and select the specified version.

## FILES
/etc/sysconfig/kernel/include

Symbolic link to the real location of kernel headers which is updated by adjust_kernel_headers.

/etc/sysconfig/kernel/include_manual_mode

The existence of this file indicates the manual mode.

## AUTHOR

```
Dmitry V. Levin <ldv@altlinux.org>
Sergey Vlasov <vsu@altlinux.org>
```

branch: sisyphus


kexec

package: kexec-tools

title: kexec(8)

summary: directly boot into a new kernel

text:
# kexec(8)

## NAME
kexec - directly boot into a new kernel

## SYNOPSIS
/sbin/kexec [-v (--version)] [-f (--force)] [-x (--no-ifdown)] [-y (--no-sync)] [-l (--load)] [-p (--load-panic)] [-u (--unload)] [-e (--exec)] [-t (--type)] [--mem-min=addr] [--mem-max=addr]

## DESCRIPTION
kexec is a system call that enables you to load and boot into another kernel from the currently running kernel. kexec performs the function of the boot loader from within the kernel. The primary difference between a standard system boot and a kexec boot is that the hardware initialization normally performed by the BIOS or firmware (depending on architecture) is not performed during a kexec boot. This has the effect of reducing the time required for a reboot.

Make sure you have selected CONFIG_KEXEC=y when configuring the kernel. The CONFIG_KEXEC option enables the kexec system call.

## USAGE
Using kexec consists of

(1) loading the kernel to be rebooted to into memory, and

(2) actually rebooting to the pre-loaded kernel.

To load a kernel, the syntax is as follows:

kexec -l kernel-image --append=command-line-options --initrd=initrd-image

where kernel-image is the kernel file that you intend to reboot to.

Insert the command-line parameters that must be passed to the new kernel into command-line-options. Passing the exact contents of /proc/cmdline into command-line-options is the safest way to ensure that correct values are passed to the rebooting kernel.

The optional initrd-image is the initrd image to be used during boot.

It's also possible to invoke kexec without an option parameter. In that case, kexec loads the specified kernel and then invokes shutdown(8). If the shutdown scripts of your Linux distribution support kexec-based rebooting, they then call kexec -e just before actually rebooting the machine. That way, the machine does a clean shutdown including all shutdown scripts.

## EXAMPLE
For example, if the kernel image you want to reboot to is /boot/vmlinux, the contents of /proc/cmdline is root=/dev/hda1, and the path to the initrd is /boot/initrd, then you would use the following command to load the kernel:

kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd

After this kernel is loaded, assuming the user-space supports kexec-based rebooting, it can be booted to, with a clean shutdown, using the command:

reboot

Alternatively, it can also be booted to, without calling shutdown(8), with the command:

kexec -e

## OPTIONS
-d (--debug)

Enable debugging messages.

-S (--status)

Return 1 if the type (by default crash) is loaded, 0 if not. Can be used in conjuction with -l or -p to toggle the type. Note this option supersedes other options and it will not load or unload the kernel.

-e (--exec)

Run the currently loaded kernel. Note that it will reboot into the loaded kernel without calling shutdown(8).

-f (--force)

Force an immediate kexec call, do not call shutdown(8) (contrary to the default action without any option parameter). This option performs the same actions like executing -l and -e in one call.

-h (--help)

Open a help file for kexec.

--hotplug

Setup kexec segments such that kernel can safely update them on CPU/Memory hot add/remove events. If this option is enabled, kernel does in-kernel update of kexec segments on CPU/Memory hot add/remove events, thus avoiding the need to reload kdump kernel.

-i (--no-checks)

Fast reboot, no memory integrity checks.

-l (--load) kernel

Load the specified kernel into the current kernel.

-p (--load-panic)

Load the new kernel for use on panic.

-t (--type=type)

Specify that the new kernel is of this type.

-s (--kexec-file-syscall)

Specify that the new KEXEC_FILE_LOAD syscall should be used exclusively. Ignored on XEN.

-c (--kexec-syscall)

Specify that the old KEXEC_LOAD syscall should be used exclusively.

-a (--kexec-syscall-auto)

Try the new KEXEC_FILE_LOAD syscall first and when it is not supported or the kernel does not understand the supplied image fall back to the old KEXEC_LOAD interface. There is no one single interface that always works, so this is the default.

KEXEC_FILE_LOAD is required on systems that use locked-down secure boot to verify the kernel signature. KEXEC_LOAD may be also disabled in the kernel configuration.

KEXEC_LOAD is required for some kernel image formats and on architectures that do not implement KEXEC_FILE_LOAD.

-u (--unload)

Unload the current kexec target kernel. If a capture kernel is being unloaded then specify -p with -u.

-v (--version)

Return the version number of the installed utility.

-x (--no-ifdown)

Shut down the running kernel, but restore the interface on reload.

-y (--no-sync)

Shut down the running kernel, but skip syncing the filesystems.

--mem-min=addr

Specify the lowest memory address addr to load code into.

--mem-max=addr

Specify the highest memory address addr to load code into.

--entry=addr

Specify the jump back address. (0 means it's not jump back or preserve context)

--load-preserve-context

Load the new kernel and preserve context of current kernel during kexec.

--load-jump-back-helper

Load a helper image to jump back to original kernel.

--reuseinitrd

Reuse initrd from first boot.

--print-ckr-size

Print crash kernel region size, if available.

## SUPPORTED KERNEL FILE TYPES AND OPTIONS
Beoboot-x86

--args-elf

Pass ELF boot notes.

--args-linux

Pass Linux kernel style options.

--real-mode

Use the kernel's real mode entry point.

elf-x86

--append=string

Append string to the kernel command line.

--command-line=string

Set the kernel command line to string.

--reuse-cmdline

Use the command line from the running system. When a panic kernel is loaded, it strips the crashkernel parameter automatically. The BOOT_IMAGE parameter is also stripped.

--initrd=file

Use file as the kernel's initial ramdisk.

--ramdisk=file

Use file as the kernel's initial ramdisk.

bzImage-x86

--append=string

Append string to the kernel command line.

--command-line=string

Set the kernel command line to string.

--reuse-cmdline

Use the command line from the running system. When a panic kernel is loaded, it strips the crashkernel parameter automatically. The BOOT_IMAGE parameter is also stripped.

--initrd=file

Use file as the kernel's initial ramdisk.

--ramdisk=file

Use file as the kernel's initial ramdisk.

--real-mode

Use real-mode entry point.

multiboot-x86

--command-line=string

Set the kernel command line to string.

--reuse-cmdline

Use the command line from the running system. When a panic kernel is loaded, it strips the crashkernel parameter automatically. The BOOT_IMAGE parameter is also stripped.

--module=mod arg1 arg2 ...

Load module mod with command-line arguments arg1 arg2 ... This parameter can be specified multiple times.

multiboot2-x86

--command-line=string

Set the kernel command line to string.

--reuse-cmdline

Use the command line from the running system. When a panic kernel is loaded, it strips the crashkernel parameter automatically. The BOOT_IMAGE parameter is also stripped.

--module=mod arg1 arg2 ...

Load module mod with command-line arguments arg1 arg2 ... This parameter can be specified multiple times.

elf-ppc64

--reuse-cmdline

Use the kernel command line from the running system.

--command-line=string

Set the kernel command line to string.

--append=string

Set the kernel command line to string.

--ramdisk=file

Use file as the initial RAM disk.

--initrd=file

Use file as the initial RAM disk.

--devicetreeblob=file

Specify device tree blob file. Not applicable while using --kexec-file-syscall.

--dtb=file

Specify device tree blob file. Not applicable while using --kexec-file-syscall.

## ARCHITECTURE OPTIONS
--console-serial

Enable the serial console.

--console-vga

Enable the VGA console.

--elf32-core-headers

Prepare core headers in ELF32 format.

--elf64-core-headers

Prepare core headers in ELF64 format.

--reset-vga

Attempt to reset a standard VGA device.

--serial=port

Specify the serial port for debug output.

--serial-baud=baud_rate

Specify the baud rate of the serial port.

--dt-no-old-root

Do not reuse old kernel root=<device> param while creating flatten device tree.


vmcore-dmesg

title: vmcore-dmesg(8)

text:
# vmcore-dmesg(8)

## NAME
vmcore-dmesg

## SYNOPSIS
vmcore-dmesg vmcore

## DESCRIPTION
vmcore-dmesg extracts the dmesg from a vmcore and write it to standard out. vmcore-dmesg works against either /proc/vmcore in a crash dump capture context or a copy of /proc/vmcore that has been saved for later analysis. A single build of vmcore-dmesg should work against any linux vmcore written created on any architecture.

## SEE ALSO
kexec(8)

## AUTHOR
vmcore-dmesg was written by Eric Biederman.


keyfuzz

package: keyfuzz

title: keyfuzz(8)

text:
# keyfuzz(8)

## NAME
keyfuzz - Modify keyboard scancode tables of the Linux input layer

## SYNOPSIS
keyfuzz [options]

## DESCRIPTION
You may use keyfuzz to manipulate the scancode/keycode translation tables of keyboard drivers supporting the Linux input layer API. ("evdev API")

## OPTIONS
-g | --get

Dump the current scancode translation table of the device to STDOUT.

-s | --set

Merge the translation table passed through STDIN into the current translation table of the device.

-i | --info

Show some information about the specified device.

-d | --device=DEVICE

Use the specified event device. The virtual file /proc/bus/input/devices lists all input devices available on the local system. (Default: /dev/input/event0)

-v | --verbose

Enable verbose mode. If used together with --set all translation tables changes are printed to STDERR.

-h | --help

Show help

-v | --version

Show version

## TRANSLATION TABLES
The scancode/keycode translation tables as read from STDIN or written to STDOUT are formatted as follows: lines beginning with a hashmark and empty lines are ignored. All other lines have to contain a scancode and a keycode number separated by white space. The numbers may be specified either in decimal or in hexadecimal notation. In the latter case, a 0x as to be prepended. You may save the current table by passing --get to keyfuzz and storing its output in a file. Then, you may restore the table by passing the contents of that file back to keyfuzz with --set.

## AUTHOR
keyfuzz was written by Lennart Poettering <mzxrlshmm (at) 0pointer (dot) de>. keyfuzz is available at http://0pointer.de/lennart/projects/keyfuzz/

## COMMENTS
This man page was written using xmltoman(1) by Oliver Kurth.


package: keyutils

title: key.dns_resolver(8)

summary: upcall for request\-key to handle dns_resolver keys

text:
# key.dns_resolver(8)

## NAME
key.dns_resolver - upcall for request-key to handle dns_resolver keys

## SYNOPSIS
/sbin/key.dns_resolver <key>

/sbin/key.dns_resolver --dump-config [-c <configfile>]

/sbin/key.dns_resolver -D [-v] [-v] [-c <configfile>] <desc>

<calloutinfo>

## DESCRIPTION
This program is invoked by request-key on behalf of the kernel when kernel services (such as NFS, CIFS and AFS) want to perform a hostname lookup and the kernel does not have the key cached. It is not ordinarily intended to be called directly.

There program has internal parameters that can be changed with a configuration file (see key.dns_resolver.conf(5) for more information). The default configuration file is in /etc, but this can be overridden with the -c flag.

The program can be called in debugging mode to test its functionality by passing a -D or --debug flag on the command line. For this to work, the key description and the callout information must be supplied. Verbosity can be increased by supplying one or more -v flags.

The program may also be called with --dump-config to show the values that configurable parameters will have after parsing the config file.

## ERRORS
All errors will be logged to the syslog.

## SEE ALSO
key.dns_resolver.conf(5), request-key.conf(5), keyrings(7), request-key(8)


request-key

title: request-key(8)

text:
# request-key(8)

## NAME
request-key - handle key instantiation callback requests from the kernel

## SYNOPSIS
/sbin/request-key <op> <key> <uid> <gid> <threadring> <processring> <sessionring> [<info>]

## DESCRIPTION
This program is invoked by the kernel when the kernel is asked for a key that it doesn't have immediately available. The kernel creates a partially set up key and then calls out to this program to instantiate it. It is not intended to be called directly.

However, for debugging purposes, it can be given some options on the command line:

-d

Turn on debugging mode. In this mode, no attempts are made to access any keys and, if a handler program is selected, it won't be executed; instead, this program will print a message and exit 0.

-D

In debugging mode, use the proposed key description specified with this rather than the sample ("user;0;0;1f0000;debug:1234") built into the program.

-l

Use configuration from the current directory. The program will use request-key.d/* and request-key.conf from the current directory rather than from /etc.

-n

Don't log to the system log. Ordinarily, error messages and debugging messages will be copied to the system log - this will prevent that.

-v

Turn on debugging output. This may be specified multiple times to produce increasing levels of verbosity.

--version

Print the program version and exit.

## ERRORS
All errors will be logged to the syslog.

## FILES
/etc/request-key.d/*.conf Individual configuration files.

/etc/request-key.conf Fallback configuration file.

## SEE ALSO
keyctl(1), request-key.conf(5), keyrings(7)


klogd

package: klogd

title: klogd(8)

summary: Kernel Log Daemon

text:
# klogd(8)

## NAME
klogd - Kernel Log Daemon

## SYNOPSIS
klogd [ -c n ] [ -d ] [ -f fname ] [ -u username ] [ -j chroot_dir ] [ -iI ] [ -n ] [ -o ] [ -s ] [ -v ]

## DESCRIPTION
klogd is a system daemon which intercepts and logs Linux kernel messages.

## OPTIONS
-c n

Sets the default log level of console messages to n.

-d

Enable debugging mode. This will generate LOTS of output to stderr.

-f file

Log messages to the specified filename rather than to the syslog facility.

-u username

Tells klogd to become the specified user and drop root privileges before starting logging.

-j chroot_dir

Tells klogd to chroot(2) into this directory after initializing. This option is only valid if the -u option is also used to run klogd without root privileges. Note that the use of this option will prevent -i and -I from working unless you set up the chroot directory in such a way that klogd can still read the kernel module symbols.

-i -I

Signal the currently executing klogd daemon. Both of these switches control the loading/reloading of symbol information. The -i switch signals the daemon to reload the kernel module symbols. The -I switch signals for a reload of both the static kernel symbols and the kernel module symbols.

-n

Avoid auto-backgrounding. This is needed especially if the klogd is started and controlled by init(8).

-o

Execute in 'one-shot' mode. This causes klogd to read and log all the messages that are found in the kernel message buffers. After a single read and log cycle the daemon exits.

-s

Force klogd to use the system call interface to the kernel message buffers.

-v

Print version and exit.

-k file

Does nothing, retained for compatibility.

-p

Does nothing, retained for compatibility.

-x

Does nothing, retained for compatibility.

-2

Does nothing, retained for compatibility.

## OVERVIEW
The functionality of klogd has been typically incorporated into other versions of syslogd but this seems to be a poor place for it. In the modern Linux kernel a number of kernel messaging issues such as sourcing, prioritization and resolution of kernel addresses must be addressed. Incorporating kernel logging into a separate process offers a cleaner separation of services.

In Linux there are two potential sources of kernel log information: the /proc file system and the syscall (sys_syslog) interface, although ultimately they are one and the same. Klogd is designed to choose whichever source of information is the most appropriate. It does this by first checking for the presence of a mounted /proc file system. If this is found the /proc/kmsg file is used as the source of kernel log information. If the proc file system is not mounted klogd uses a system call to obtain kernel messages. The command line switch (-s) can be used to force klogd to use the system call interface as its messaging source.

If kernel messages are directed through the syslogd daemon the klogd daemon, as of version 1.1, has the ability to properly prioritize kernel messages. Prioritization of the kernel messages was added to it at approximately version 0.99pl13 of the kernel. The raw kernel messages are of the form:

<[0-7]>Something said by the kernel.

The priority of the kernel message is encoded as a single numeric digit enclosed inside the <> pair. The definitions of these values is given in the kernel include file kernel.h. When a message is received from the kernel the klogd daemon reads this priority level and assigns the appropriate priority level to the syslog message. If file output (-f) is used the prioritization sequence is left pre-pended to the kernel message.

The klogd daemon can also be used in a 'one-shot' mode for reading the kernel message buffers. One shot mode is selected by specifying the -o switch on the command line. Output will be directed to either the syslogd daemon or to an alternate file specified by the -f switch.

For example, to read all the kernel messages after a system boot and record them in a file called krnl.msg the following command would be given.

```
	klogd -o -f ./krnl.msg
```

## CONSOLE LOG LEVEL
The klogd daemon allows the ability to alter the presentation of kernel messages to the system console. Consequent with the prioritization of kernel messages was the inclusion of default messaging levels for the kernel. In a stock kernel the the default console log level is set to 7. Any messages with a priority level numerically lower than 7 (higher priority) appear on the console.

Messages of priority level 7 are considered to be 'debug' messages and will thus not appear on the console. Many administrators, particularly in a multi-user environment, prefer that all kernel messages be handled by klogd and either directed to a file or to the syslogd daemon. This prevents 'nuisance' messages such as line printer out of paper or disk change detected from cluttering the console.

When -c is given on the commandline the klogd daemon will execute a system call to inhibit all kernel messages from being displayed on the console. Former versions always issued this system call and defaulted to all kernel messages except for panics. This is handled differently currently so klogd doesn't need to set this value anymore. The argument given to the -c switch specifies the priority level of messages which will be directed to the console. Note that messages of a priority value LOWER than the indicated number will be directed to the console.

For example, to have the kernel display all messages with a priority level of 3 (KERN_ERR) or more severe the following command would be executed:

```
	klogd -c 4
```

The definitions of the numeric values for kernel messages are given in the file kernel.h which can be found in the /usr/include/linux directory if the kernel sources are installed. These values parallel the syslog priority values which are defined in the file syslog.h found in the /usr/include/sys sub-directory.

The console log level is usually configured with the sysctl(8) program, directly or via its configuration file /etc/sysctl.conf. In this file the following line

```
kernel.printk = 4 4 1 7
```

corresponds to the sampe setting above.

## SIGNAL HANDLING
The klogd will respond to eight signals: SIGHUP, SIGINT, SIGKILL, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2 and SIGCONT. The SIGINT, SIGKILL, SIGTERM and SIGHUP signals will cause the daemon to close its kernel log sources and terminate gracefully.

The SIGTSTP and SIGCONT signals are used to start and stop kernel logging. Upon receipt of a SIGTSTP signal the daemon will close its log sources and spin in an idle loop. Subsequent receipt of a SIGCONT signal will cause the daemon to go through its initialization sequence and re-choose an input source. Using SIGSTOP and SIGCONT in combination the kernel log input can be re-chosen without stopping and restarting the daemon. For example if the /proc file system is to be un-mounted the following command sequence should be used:

\# kill -TSTP pid

\# umount /proc

\# kill -CONT pid

Notations will be made in the system logs with LOG_INFO priority documenting the start/stop of logging.

The SIGUSR1 and SIGUSR2 signals are used to initiate loading/reloading of kernel symbol information. Receipt of the SIGUSR1 signal will cause the kernel module symbols to be reloaded. Signaling the daemon with SIGUSR2 will cause both the static kernel symbols and the kernel module symbols to be reloaded.

Provided that the System.map file is placed in an appropriate location the signal of generally greatest usefulness is the SIGUSR1 signal. This signal is designed to be used to signal the daemon when kernel modules are loaded/unloaded. Sending this signal to the daemon after a kernel module state change will insure that proper resolution of symbols will occur if a protection fault occurs in the address space occupied by a kernel module.

## FILES
/proc/kmsg

One Source for kernel messages klogd

/var/run/klogd.pid

The file containing the process id of klogd

/boot/System.map, /System.map, /usr/src/linux/System.map

Default locations for kernel system maps.

## BUGS
Probably numerous. Well formed context diffs appreciated.

## AUTHORS
The kernel log daemon klogd was originally written by Steve Lord <lord@cray.com>, Greg Wettstein made major improvements. Martin Schulze <joey@infodrom.org> fixed some bugs and took over maintenance.


depmod

package: kmod

title: depmod(8)

text:
# depmod(8)

## NAME
depmod - Generate modules.dep and map files.

## SYNOPSIS
depmod [-b basedir] [-m moduledir] [-o outdir] [-e] [-E Module.symvers]

[-F System.map] [-n] [-v] [-A] [-P prefix] [-w] [version]

depmod [-e] [-E Module.symvers] [-F System.map] [-n] [-v] [-P prefix]

[-w] [version] [filename...]

## DESCRIPTION
Linux kernel modules can provide services (called "symbols") for other modules to use (using one of the EXPORT_SYMBOL variants in the code). If a second module uses this symbol, that second module clearly depends on the first module. These dependencies can get quite complex.

depmod creates a list of module dependencies by reading each module under <BASEDIR>/<MODULEDIR>/version. By default <MODULEDIR> is /lib/modules and <BASEDIR> is empty. See options below to override when needed. It determines what symbols each module exports and needs. This list is written to modules.dep, and a binary hashed version named modules.dep.bin, in the same directory. If filenames are given on the command line, only those modules are examined (which is rarely useful unless all modules are listed). depmod also creates a list of symbols provided by modules in the file named modules.symbols and its binary hashed version, modules.symbols.bin. Finally, depmod will output a file named modules.devname if modules supply special device names (devname) that should be populated in /dev on boot (by a utility such as systemd-tmpfiles).

If a version is provided, then that kernel version's module directory is used rather than the current kernel version (as returned by uname -r).

## OPTIONS
-a, --all

Probe all modules. This option is enabled by default if no file names are given in the command-line.

-A, --quick

This option scans to see if any modules are newer than the modules.dep file before any work is done: if not, it silently exits rather than regenerating the files.

-b basedir, --basedir=basedir

Override the base directory <BASEDIR> where modules are located. If your modules are not currently in the (normal) directory /lib/modules/version, but in a staging area, you can specify a basedir which is prepended to the directory name. This basedir is stripped from the resulting modules.dep file, so it is ready to be moved into the normal location. Use this option if you are a distribution vendor who needs to pre-generate the meta-data files rather than running depmod again later. If a relative path is given, it's relative to the current working directory.

Example:

depmod -b /my/build/staging/dir/

This expects all input files under /my/build/staging/dir/lib/modules/$(uname -r) and generates index files under that same directory.

-m moduledir, --moduledir=moduledir

Override the module directory <MODULEDIR>, which defaults to /lib/modules prefix set at build time. This is useful when building modules.dep file in basedir for a system that uses a different prefix, e.g. /usr/lib/modules vs /lib/modules. Relative and absolute paths are accepted, but they are always relative to the basedir.

Examples:

depmod -b /tmp/build -m /kernel-modules

depmod -b /tmp/build -m kernel-modules

This expects all input files under /tmp/build/kernel-modules/$(uname -r) and generates index files under that same directory.

Without an accompanying -b argument, the moduledir is relative to /. Example:

depmod -m foo/bar

This expects all input files under /foo/bar/$(uname -r) and generates index files under the same directory. Unless libkmod is prepared to handle that arbitrary location, it won't work in runtime.

-o outdir, --outdir=outdir

Set the output directory where depmod will store any generated file. outdir serves as a root to that location, similar to how basedir is used. Also this setting takes precedence and if used together with basedir it will result in the input being that directory, but the output being the one set by outdir. If a relative path is given, it's relative to the current working directory.

Example:

depmod -o /my/build/staging/dir/

This expects all input files under /lib/modules/$(uname -r) and generates index files under /my/build/staging/dir/lib/modules/$(uname -r).

-C file or directory, --config=file or directory

This option overrides the default configuration files. See depmod.d(5).

-e, --errsyms

When combined with the -F option, this reports any symbols which a module needs which are not supplied by other modules or the kernel. Normally, any symbols not provided by modules are assumed to be provided by the kernel (which should be true in a perfect world), but this assumption can break especially when additionally updated third party drivers are not correctly installed or were built incorrectly.

-E Module.symvers, --symvers=Module.symvers

When combined with the -e option, this reports any symbol versions supplied by modules that do not match with the symbol versions provided by the kernel in its Module.symvers. This option is mutually incompatible with -F.

-F System.map, --filesyms=System.map

Supplied with the System.map produced when the kernel was built, this allows the -e option to report unresolved symbols. This option is mutually incompatible with -E.

-h, --help

Print the help message and exit.

-n, --show, --dry-run

This sends the resulting modules.dep and the various map files to standard output rather than writing them into the module directory.

-P

Some architectures prefix symbols with an extraneous character. This specifies a prefix character (for example '_') to ignore.

-v, --verbose

In verbose mode, depmod will print (to stdout) all the symbols each module depends on and the module's file name which provides that symbol.

-V, --version

Show version of program and exit. See below for caveats when run on older kernels.

-w

Warn on duplicate dependencies, aliases, symbol versions, etc.

## COPYRIGHT
This manual page originally Copyright 2002, Rusty Russell, IBM Corporation. Portions Copyright Jon Masters, and others.

## SEE ALSO
depmod.d(5), modprobe(8), modules.dep(5)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHORS
Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


insmod

title: insmod(8)

text:
# insmod(8)

## NAME
insmod - Simple program to insert a module into the Linux Kernel

## SYNOPSIS
insmod [OPTIONS] [filename] [module options]

## DESCRIPTION
insmod is a trivial program to insert a module into the kernel. Most users will want to use modprobe(8) instead, which is more clever and can handle module dependencies.

Only the most general of error messages are reported: as the work of trying to link the module is now done inside the kernel, the dmesg(1) usually gives more information about errors.

## OPTIONS
-f, --force

This option can be extremely dangerous: it tells the kernel to ignore the module version and vermagic fields when loading. With this option, you can load modules build locally or by third parties, although this can lead to memory corruption, system crashes and data loss.

-s, --syslog

Send errors to syslog instead of standard error.

-v, --verbose

Print messages about what the program is doing. Usually insmod prints messages only if something goes wrong.

-V, --version

Show version of program and exit.

-h, --help

Print the help message and exit.

## COPYRIGHT
This manual page originally Copyright 2002, Rusty Russell, IBM Corporation.

## SEE ALSO
modprobe(8), rmmod(8), lsmod(8), modinfo(8), depmod(8)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHORS
Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


kmod

title: kmod(8)

text:
# kmod(8)

## NAME
kmod - Program to manage Linux Kernel modules

## SYNOPSIS
kmod [OPTIONS...] [COMMAND] [COMMAND_OPTIONS...]

## DESCRIPTION
kmod is a multi-call binary which implements the programs used to control Linux Kernel modules. Most users will only run it using its other names.

## OPTIONS
-V, --version

Show the program version and exit.

-h, --help

Show the help message.

## COMMANDS
help

Show the help message.

list

List the currently loaded modules.

static-nodes

Output the static device nodes information provided by the modules of the currently running kernel version.

## COPYRIGHT
This manual page originally Copyright 2014, Marco d'Itri.

## SEE ALSO
lsmod(8), rmmod(8), insmod(8), modinfo(8), modprobe(8), depmod(8)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHOR
kmod project was started by Lucas De Marchi as a drop-in replacement to module-init-tools that was maintained by Jon Masters, adding a library (libkmod) and additional features.

Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


lsmod

title: lsmod(8)

text:
# lsmod(8)

## NAME
lsmod - Show the status of modules in the Linux Kernel

## SYNOPSIS
lsmod [OPTIONS]

## DESCRIPTION
lsmod is a trivial program which nicely formats the contents of the /proc/modules, showing what kernel modules are currently loaded.

## OPTIONS
-s, --syslog

Send errors to syslog instead of standard error.

-v, --verbose

Print messages about what the program is doing. Usually lsmod prints messages only if something goes wrong.

-V, --version

Show version of program and exit.

-h, --help

Print the help message and exit.

## COPYRIGHT
This manual page originally Copyright 2002, Rusty Russell, IBM Corporation.

## SEE ALSO
insmod(8), modprobe(8), modinfo(8), depmod(8)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHORS
Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


modinfo

title: modinfo(8)

text:
# modinfo(8)

## NAME
modinfo - Show information about a Linux Kernel module

## SYNOPSIS
modinfo [-0] [-F field] [-k kernel] [modulename|filename...]

modinfo -V

modinfo -h

## DESCRIPTION
modinfo extracts information from the Linux Kernel modules given on the command line. If the module name is not a filename, then the /lib/modules/ version directory is searched, as is also done by modprobe(8) when loading kernel modules.

modinfo by default lists each attribute of the module in form fieldname : value, for easy reading. The filename is listed the same way (although it's not really an attribute).

This version of modinfo can understand modules of any Linux Kernel architecture.

## OPTIONS
-V, --version

Print the modinfo version.

-F field, --field=field

Only print this field value, one per line. This is most useful for scripts. Field names are case-insensitive. Common fields (which may not be in every module) include author, description, license, parm, depends, and alias. There are often multiple parm, alias and depends fields. The special field filename lists the filename of the module.

-b basedir, --basedir=basedir

Root directory for modules, / by default.

-k kernel

Provide information about a kernel other than the running one. This is particularly useful for distributions needing to extract information from a newly installed (but not yet running) set of kernel modules. For example, you wish to find which firmware files are needed by various modules in a new kernel for which you must make an initrd/initramfs image prior to booting.

-0, --null

Use the ASCII zero character to separate field values, instead of a new line. This is useful for scripts, since a new line can theoretically appear inside a field.

-a --author, -d --description, -l --license, -p --parameters, -n --filename

These are shortcuts for the --field flag's author, description, license, parm and filename arguments, to ease the transition from the old modutils modinfo.

-h, --help

Print the help message and exit.

## COPYRIGHT
This manual page originally Copyright 2003, Rusty Russell, IBM Corporation.

## SEE ALSO
modprobe(8)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHORS
Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


modprobe

title: modprobe(8)

text:
# modprobe(8)

## NAME
modprobe - Add and remove modules from the Linux Kernel

## SYNOPSIS
modprobe [-v] [-V] [-C config-file] [-n] [-i] [-q] [-b] [modulename]

[module parameters...]

modprobe [-r] [-v] [-n] [-i] [modulename...]

modprobe [-c]

modprobe [--dump-modversions] [filename]

## DESCRIPTION
modprobe intelligently adds or removes a module from the Linux kernel: note that for convenience, there is no difference between _ and - in module names (automatic underscore conversion is performed). modprobe looks in the module directory /usr/lib/`uname -r` for all the modules and other files, except for the optional configuration files (see modprobe.d(5)). modprobe will also use module options specified on the kernel command line in the form of <module>.<option> and blacklists in the form of modprobe.blacklist=<module>.

Note that unlike in 2.4 series Linux kernels (which are not supported by this tool) this version of modprobe does not do anything to the module itself: the work of resolving symbols and understanding parameters is done inside the kernel. So module failure is sometimes accompanied by a kernel message: see dmesg(8).

modprobe expects an up-to-date modules.dep.bin file as generated by the corresponding depmod utility shipped along with modprobe (see depmod(8)). This file lists what other modules each module needs (if any), and modprobe uses this to add or remove these dependencies automatically.

If any arguments are given after the modulename, they are passed to the kernel (in addition to any options listed in the configuration file).

When loading modules, modulename can also be a path to the module. If the path is relative, it must explicitly start with "./". Note that this may fail when using a path to a module with dependencies not matching the installed depmod database.

## OPTIONS
-a, --all

Insert all module names on the command line.

-b, --use-blacklist

This option causes modprobe to apply the blacklist commands in the configuration files (if any) to module names as well. It is usually used by udev(7).

-C directory, --config=directory

This option overrides the default configuration directory. See modprobe.d(5). This option is passed through install or remove commands to other modprobe commands in the MODPROBE_OPTIONS environment variable.

-c, --showconfig

Dump out the effective configuration from the config directory and exit.

--dump-modversions

Print out a list of module versioning information required by a module. This option is commonly used by distributions in order to package up a Linux kernel module using module versioning deps.

-d, --dirname

Root directory for modules, / by default.

--first-time

Normally, modprobe will succeed (and do nothing) if told to insert a module which is already present or to remove a module which isn't present. This is ideal for simple scripts; however, more complicated scripts often want to know whether modprobe really did something: this option makes modprobe fail in the case that it actually didn't do anything.

--force-vermagic

Every module contains a small string containing important information, such as the kernel and compiler versions. If a module fails to load and the kernel complains that the "version magic" doesn't match, you can use this option to remove it. Naturally, this check is there for your protection, so using this option is dangerous unless you know what you're doing. This applies to any modules inserted: both the module (or alias) on the command line and any modules on which it depends.

--force-modversion

When modules are compiled with CONFIG_MODVERSIONS set, a section detailing the versions of every interfaced used by (or supplied by) the module is created. If a module fails to load and the kernel complains that the module disagrees about a version of some interface, you can use --force-modversion to remove the version information altogether. Naturally, this check is there for your protection, so using this option is dangerous unless you know what you're doing. This applies to any modules inserted: both the module (or alias) on the command line and any modules on which it depends.

-f, --force

Try to strip any versioning information from the module which might otherwise stop it from loading: this is the same as using both --force-vermagic and --force-modversion. Naturally, these checks are there for your protection, so using this option is dangerous unless you know what you are doing. This applies to any modules inserted: both the module (or alias) on the command line and any modules on which it depends.

-i, --ignore-install, --ignore-remove

This option causes modprobe to ignore install and remove commands in the configuration file (if any) for the module specified on the command line (any dependent modules are still subject to commands set for them in the configuration file). Both install and remove commands will currently be ignored when this option is used regardless of whether the request was more specifically made with only one or other (and not both) of --ignore-install or --ignore-remove. See modprobe.d(5).

-n, --dry-run, --show

This option does everything but actually insert or delete the modules (or run the install or remove commands). Combined with -v, it is useful for debugging problems. For historical reasons both --dry-run and --show actually mean the same thing and are interchangeable.

-q, --quiet

With this flag, modprobe won't print an error message if you try to remove or insert a module it can't find (and isn't an alias or install/remove command). However, it will still return with a non-zero exit status. The kernel uses this to opportunistically probe for modules which might exist using request_module.

-R, --resolve-alias

Print all module names matching an alias. This can be useful for debugging module alias problems.

-r, --remove

This option causes modprobe to remove rather than insert a module. If the modules it depends on are also unused, modprobe will try to remove them too. Unlike insertion, more than one module can be specified on the command line (it does not make sense to specify module parameters when removing modules). There is usually no reason to remove modules, but some buggy modules require it. Your distribution kernel may not have been built to support removal of modules at all.

-w TIMEOUT_MSEC, --wait=TIMEOUT_MSEC

This option causes modprobe -r to continue trying to remove a module if it fails due to the module being busy, i.e. its refcount is not 0 at the time the call is made. Modprobe tries to remove the module with an incremental sleep time between each tentative up until the maximum wait time in milliseconds passed in this option.

-S version, --set-version=version

Set the kernel version, rather than using uname(2) to decide on the kernel version (which dictates where to find the modules).

--show-depends

List the dependencies of a module (or alias), including the module itself. This produces a (possibly empty) set of module filenames, one per line, each starting with "insmod" and is typically used by distributions to determine which modules to include when generating initrd/initramfs images. Install commands which apply are shown prefixed by "install". It does not run any of the install commands. Note that modinfo(8) can be used to extract dependencies of a module from the module itself, but knows nothing of aliases or install commands.

-s, --syslog

This option causes any error messages to go through the syslog mechanism (as LOG_DAEMON with level LOG_NOTICE) rather than to standard error. This is also automatically enabled when stderr is unavailable. This option is passed through install or remove commands to other modprobe commands in the MODPROBE_OPTIONS environment variable.

-V, --version

Show version of program and exit.

-v, --verbose

Print messages about what the program is doing. Usually modprobe only prints messages if something goes wrong. This option is passed through install or remove commands to other modprobe commands in the MODPROBE_OPTIONS environment variable.

## ENVIRONMENT
The MODPROBE_OPTIONS environment variable can also be used to pass command line arguments to modprobe. The format is intentionally left undocumented, since the use by third-party tools and scripts is discouraged.

The environment variable originates with the implementation of the install rules.

## COPYRIGHT
This manual page originally Copyright 2002, Rusty Russell, IBM Corporation.

## SEE ALSO
modprobe.d(5), insmod(8), rmmod(8), lsmod(8), modinfo(8), depmod(8)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHORS
Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


rmmod

title: rmmod(8)

text:
# rmmod(8)

## NAME
rmmod - Simple program to remove a module from the Linux Kernel

## SYNOPSIS
rmmod [OPTIONS] [list of modulenames]

## DESCRIPTION
rmmod is a trivial program to remove a module or a list of modules from the kernel (when module unloading support is provided). Most users will want to use modprobe(8) with the -r option instead since it removes unused dependent modules as well.

When a list of modules is provided, the program will process them one at a time. If a module is not found, rmmod will immediately exit with an error code. Should the module removal fail, the program will log an error AND continue with the next module. This behaviour is NOT controlled by the --force option.

## OPTIONS
-f, --force

This option can be extremely dangerous: it has no effect unless CONFIG_MODULE_FORCE_UNLOAD was set when the kernel was compiled. With this option, you can remove modules which are being used, or which are not designed to be removed, or have been marked as unsafe (see lsmod(8)).

-s, --syslog

Send errors to syslog instead of standard error.

-v, --verbose

Print messages about what the program is doing. Usually rmmod prints messages only if something goes wrong.

-V, --version

Show version of program and exit.

-h, --help

Print the help message and exit.

## COPYRIGHT
This manual page originally Copyright 2002, Rusty Russell, IBM Corporation.

## SEE ALSO
modprobe(8), insmod(8), lsmod(8), modinfo(8), depmod(8)

## BUGS
Please direct any bug reports to kmod's issue tracker at https://github.com/kmod-project/kmod/issues/ alongside with version used, steps to reproduce the problem and the expected outcome.

## AUTHORS
Numerous contributions have come from the linux-modules mailing list <linux-modules@vger.kernel.org> and Github. If you have a clone of kmod.git itself, the output of git-shortlog(1) and git-blame(1) can show you the authors for specific parts of the project.

Lucas De Marchi <lucas.de.marchi@gmail.com> is the current maintainer of the project.


kcatalogprint

package: knot

title: kcatalogprint(8)

summary: Knot DNS catalog print utility

text:
# kcatalogprint(8)

## NAME
kcatalogprint - Knot DNS catalog print utility

## SYNOPSIS
kcatalogprint [config_option] [options]

## DESCRIPTION
The program prints zone catalog stored in a catalog database.

### Config options
-c, --config file

Use a textual configuration file (default is /etc/knot/knot.conf).

-C, --confdb directory

Use a binary configuration database directory (default is /var/lib/knot/confdb). The default configuration database, if exists, has a preference to the default configuration file.

-D, --dir path

Use specified catalog database path and default configuration.

### Options
-a, --catalog

Filter the output by catalog zone name.

-m, --member

Filter the output by member zone name.

-h, --help

Print the program help.

-V, --version

Print the program version. The option -VV makes the program print the compile time configuration summary.

## EXIT VALUES
Exit status of 0 means successful operation. Any other exit status indicates an error.

## SEE ALSO
knotd(8), knot.conf(5).

## Author
CZ.NIC, z.s.p.o. and contributors <https://www.knot-dns.cz/>

## Copyright
Copyright (C) CZ.NIC, z.s.p.o. and contributors


keymgr

title: keymgr(8)

summary: Knot DNS key management utility

text:
# keymgr(8)

## NAME
keymgr - Knot DNS key management utility

## SYNOPSIS
keymgr [config_option] [options] zone_name command

keymgr [config_option] [options] keystore_id command

keymgr [config_option] [-j] -l

keymgr -t parameter...

## DESCRIPTION
The keymgr utility serves for manual key management in Knot DNS server.

Functions for DNSSEC keys and KASP (Key And Signature Policy) management are provided.

The DNSSEC and KASP configuration is stored in a so called KASP database. The database is backed by LMDB.

### Parameters
zone_name

Name of the zone the command is executed for.

### Config options
-c, --config file

Use a textual configuration file (default is /etc/knot/knot.conf).

-C, --confdb directory

Use a binary configuration database directory (default is /var/lib/knot/confdb). The default configuration database, if exists, has a preference to the default configuration file.

-D, --dir path

Use specified KASP database path and default configuration.

### Options
-t, --tsig tsig_name [tsig_algorithm [tsig_bits]]

Generates a TSIG key for the given name. Optionally the key algorithm can be specified by its name <#key-algorithm> (default: hmac-sha256) and a bit length of the key (default: optimal length given by algorithm). The generated TSIG key is only displayed on stdout: the command does not create a file, nor include the key in a keystore.

-e, --extended

Extended output (listing of keys with full description).

-j, --json

Print the zones or keys (not TSIG keys) in JSON format.

-l, --list

Print the list of zones that have at least one key stored in the configured KASP database.

-x, --mono

Don't generate colorized output.

-X, --color

Force colorized output in the normal mode.

-h, --help

Print the program help.

-V, --version

Print the program version. The option -VV makes the program print the compile time configuration summary.

Note:

Keymgr runs with the same user privileges as configured for knotd <>. For example, if keymgr is run as root, but the configured user <#server-user> is knot, it won't be able to read files (PEM files, KASP database, ...) readable only by root.

### Commands
list [timestamp_format]

Prints the list of key IDs and parameters of keys belonging to the zone.

generate [arguments...]

Generates new DNSSEC key and stores it in KASP database. Prints the key ID. This action takes some number of arguments (see below). Values for unspecified arguments are taken from corresponding policy (if -c or -C options used) or from Knot policy defaults.

import-bind BIND_key_file

Imports a BIND-style key into KASP database (converting it to PEM format). Takes one argument: path to BIND key file (private or public, but both MUST exist).

import-pub BIND_pubkey_file

Imports a public key into KASP database. This key won't be rolled over nor used for signing. Takes one argument: path to BIND public key file.

import-pem PEM_file [arguments...]

Imports a DNSSEC key from PEM file. The key parameters (same as for the generate action) need to be specified (mainly algorithm, timers...) because they are not contained in the PEM format.

import-pkcs11 key_id [arguments...]

Imports a DNSSEC key from PKCS #11 storage. The key parameters (same as for the generate action) need to be specified (mainly algorithm, timers...) because they are not available. In fact, no key data is imported, only KASP database metadata is created.

nsec3-salt [new_salt]

Prints the current NSEC3 salt used for signing. If new_salt is specified, the salt is overwritten. The salt is printed and expected in hexadecimal, or dash if empty.

master-serial [new_serial]

Print SOA serial of the remote master stored in KASP database when using on-secondary DNSSEC signing. If new_serial is specified, the serial is overwritten (not recommended).

set key_spec [arguments...]

Changes a timing argument (or ksk/zsk) of an existing key to a new value. Key_spec is either the key tag or a prefix of the key ID, with an optional [id=|keytag=] prefix; arguments are like for generate, but just the related ones.

ds [key_spec]

Generate DS record (all digest algorithms together) for specified key. Key_spec is like for set, if unspecified, all KSKs are used.

dnskey [key_spec]

Generate DNSKEY record for specified key. Key_spec is like for ds, if unspecified, all KSKs are used.

delete key_spec

Remove the specified key from zone. If the key was not shared, it is also deleted from keystore.

share key_ID zone_from

Import a key (specified by full key ID) from another zone as shared. After this, the key is owned by both zones equally.

### Keystore commands
keystore-test

Conduct some tests on the specified keystore. For each algorithm, key generation, import, removal, and use (signing and verification) are tested. Use a configured keystore_id or - for the default.

keystore-bench [num_threads]

Conduct a signing benchmark on the specified keystore. Random blocks of data are signed by the selected number of threads (default is 1) in a loop, and the average number of signing operations per second for each algorithm is returned. Use a configured keystore_id or - for the default.

### Commands related to Offline KSK feature
pregenerate [timestamp-from] timestamp-to

Pre-generate ZSKs for use with offline KSK, for the specified period starting from now or specified time. This function also applies to non-offline KSK keys.

show-offline [timestamp-from] [timestamp-to]

Print pre-generated offline key-related records for specified time interval. If timestamp_to is omitted, it will be to infinity. If timestamp-from is omitted, it will start from the beginning.

del-offline timestamp-from timestamp-to

Delete pre-generated offline key-related records in specified time interval.

del-all-old

Delete old keys that are in state 'removed'. This function also applies to non-offline KSK keys.

generate-ksr [timestamp-from] timestamp-to

Print to stdout KeySigningRequest based on pre-generated ZSKs for specified time period. If timestamp-from is omitted, timestamp of the last offline records set is used or now if no records available.

sign-ksr ksr_file

Read KeySigningRequest from a text file, sign it using local keyset and print SignedKeyResponse to stdout.

validate-skr skr_file

Read SignedKeyResponse from a text file and validate the RRSIGs in it if not corrupt.

import-skr skr_file

Read SignedKeyResponse from a text file and import the signatures for later use in zone. If some signatures have already been imported, they will be deleted for the period from beginning of the SKR to infinity.

### Generate arguments
Arguments are separated by space, each of them is in format 'name=value'. A (bool) argument accepts values yes or no. If the value is omitted, it's interpreted as yes.

algorithm

Either an algorithm number (e.g. 14) or algorithm name <#policy-algorithm> (e.g. ecdsap256sha256).

size

Key length in bits.

ksk

(bool) The key will be used for signing DNSKEY rrset. The generated key will also have the Secure Entry Point flag set to 1.

zsk

(bool) The key will be used for signing zone (except DNSKEY rrset). This flag can be set concurrently with the ksk flag (for a CSK key).

sep

(bool) Overrides the standard setting of the Secure Entry Point flag.

for-later

(bool) The key will be determined for later use. It means once a new key ought to be generated, this one will be used instead if the key type and algorithm match.

The following arguments are timestamps of key lifetime (see DNSSEC key states <#dnssec-key-states>):

pre_active

Key started to be used for signing, not published (only for algorithm rollover).

publish

Key published.

ready

Key is waiting for submission (only for KSK).

active

Key used for signing.

retire_active

Key still used for signing, but another key is active (only for KSK or algorithm rollover).

retire

Key still published (only if ZSK), but no longer used for signing.

post_active

Key no longer published, but still used for signing (only for algorithm rollover).

revoke

Key revoked according to RFC 5011 <https://datatracker.ietf.org/doc/html/rfc5011.html> trust anchor roll-over.

remove

Key deleted.

### Timestamps
0

Zero timestamp means infinite future.

UNIX_time

Positive number of seconds since 1970 UTC.

YYYYMMDDHHMMSS

Date and time in this format without any punctuation.

relative_timestamp

A sign character (+, -), a number, and an optional time unit (y, mo, d, h, mi, s). The default unit is one second. E.g. +1mi, -2mo.

### Output timestamp formats
(none)

The timestamps are printed as UNIX timestamp.

human

The timestamps are printed relatively to now using time units (e.g. -2y5mo, +1h13s).

iso

The timestamps are printed in the ISO8601 format (e.g. 2016-12-31T23:59:00).

## EXIT VALUES
Exit status of 0 means successful operation. Any other exit status indicates an error.

## EXAMPLES
1.

Generate new TSIG key:

```
$ keymgr -t my_name hmac-sha384
```

2.

Generate new DNSSEC key:

```
$ keymgr example.com. generate algorithm=ECDSAP256SHA256 size=256 \

  ksk=true created=1488034625 publish=20170223205611 retire=+10mo remove=+1y
```

3.

Import a DNSSEC key from BIND:

```
$ keymgr example.com. import-bind ~/bind/Kharbinge4d5.+007+63089.key
```

4.

Import a CSK DNSSEC key from a PEM file:

```
$ keymgr example.com. import-pem 085d3890e8c22d854586678d9263933f2d02d795.pem ksk=yes zsk=yes
```

5.

Configure key timing:

```
$ keymgr example.com. set 4208 active=+2mi retire=+4mi remove=+5mi
```

6.

Share a KSK from another zone:

```
$ keymgr example.com. share e687cf927029e9db7184d2ece6d663f5d1e5b0e9 another-zone.com.
```

## SEE ALSO
RFC 6781 <https://datatracker.ietf.org/doc/html/rfc6781.html> - DNSSEC Operational Practices. RFC 7583 <https://datatracker.ietf.org/doc/html/rfc7583.html> - DNSSEC Key Rollover Timing Considerations.

knot.conf(5), knotc(8), knotd(8).

## Author
CZ.NIC, z.s.p.o. and contributors <https://www.knot-dns.cz/>

## Copyright
Copyright (C) CZ.NIC, z.s.p.o. and contributors


kjournalprint

title: kjournalprint(8)

summary: Knot DNS journal print utility

text:
# kjournalprint(8)

## NAME
kjournalprint - Knot DNS journal print utility

## SYNOPSIS
kjournalprint [config_option] [options] zone_name

kjournalprint [config_option] -z

## DESCRIPTION
The program prints zone history stored in a journal database. As default, changes are colored for terminal.

### Parameters
zone_name

A name of the zone to print the history for.

### Config options
-c, --config file

Use a textual configuration file (default is /etc/knot/knot.conf).

-C, --confdb directory

Use a binary configuration database directory (default is /var/lib/knot/confdb). The default configuration database, if exists, has a preference to the default configuration file.

-D, --dir path

Use specified journal database path and default configuration.

### Options
-z, --zone-list

Instead of reading the journal, display the list of zones in the DB.

-l, --limit limit

Limits the number of displayed changes.

-s, --serial soa

Start at a specific SOA serial.

-M, --merge

Print the changesets merged into one changeset. If zone-in-journal is present, the stored contents with all the changesets applied will be printed.

-H, --check

Enable additional journal semantic checks during printing.

-d, --debug

Debug mode brief output.

-x, --mono

Don't generate colorized output.

-X, --color

Force colorized output.

-h, --help

Print the program help.

-V, --version

Print the program version. The option -VV makes the program print the compile time configuration summary.

## EXIT VALUES
Exit status of 0 means successful operation. Any other exit status indicates an error.

## EXAMPLES
Last (most recent) 5 changes without colors:

```
$ kjournalprint -xl 5 /var/lib/knot/journal example.com.
```

## SEE ALSO
knotd(8), knot.conf(5).

## Author
CZ.NIC, z.s.p.o. and contributors <https://www.knot-dns.cz/>

## Copyright
Copyright (C) CZ.NIC, z.s.p.o. and contributors


knotc

title: knotc(8)

summary: Knot DNS control utility

text:
# knotc(8)

## NAME
knotc - Knot DNS control utility

## SYNOPSIS
knotc [config_option] [options] [action]

## DESCRIPTION
This program controls a running knotd process using a socket.

If an action is specified, it is performed and knotc exits, otherwise the program is executed in the interactive mode.

### Config options
-c, --config file

Use a textual configuration file (default is /etc/knot/knot.conf).

-C, --confdb directory

Use a binary configuration database directory (default is /var/lib/knot/confdb). The default configuration database, if exists, has a preference to the default configuration file.

### Options
-m, --max-conf-size MiB

Set maximum size of the configuration database (default is 500 MiB, maximum 10000 MiB).

-s, --socket path

Use a control UNIX socket path (default is /run/knot/knot.sock).

-t, --timeout seconds

Use a control timeout in seconds. Set to 0 for infinity (default is 60). The control socket operations are also subject to the timeout <#control-timeout> parameter set on the server side in server's Control configuration section.

-b, --blocking

Zone event trigger commands wait until the event is finished. Control timeout is set to infinity if not forced by explicit timeout specification.

-e, --extended

Show extended output (even empty items in zone status).

-f, --force

Forced operation. Overrides some checks.

-x, --mono

Don't generate colorized output.

-X, --color

Force colorized output in extended output or to a pipe.

-v, --verbose

Enable debug output.

-h, --help

Print the program help.

-V, --version

Print the program version. The option -VV makes the program print the compile time configuration summary.

### Actions
status [detail]

Check if the server is running. Details are version for the running server version, workers for the numbers of worker threads, configure for the configure summary, or cert-key for the public key pin of the currently used certificate.

stop

Stop the server if running.

reload

Reload the server configuration and modified zone files, and reopen the log files if they are configured. All open zone transactions will be aborted!

stats [module[.counter]]

Show global statistics counter(s). To print also counters with value 0, use force option.

zone-check [zone...]

Test if the server can load the zone. Semantic checks are executed if enabled in the configuration. If invoked with the force option, an error is returned when semantic check warning appears. (*)

zone-status [zone...] [filter]

Show the zone status. Filters are +role, +serial, +transaction, +events, +freeze, and +catalog. Empty zone parameters are omitted, unless the --extended option is used. A single dash in the output represents an unset value. Automatic colorization can be overruled using the --mono and --color options. The color code is: green - zone acts as a master / red - zone acts as a slave, bold font (highlited) - zone is active / normal - zone is empty, underscored - zone is an interpreted catalog member.

zone-reload [zone...]

Trigger a zone reload from a disk without checking its modification time. For secondary zone, the refresh event from primary server(s) is scheduled; for primary zone, the notify event to secondary server(s) is scheduled. An open zone transaction will be aborted! If invoked with the force option, also zone modules will be re-loaded, but blocking mode might not work reliably. (#)

zone-refresh [zone...]

Trigger a check for the zone serial on the zone's primary server. If the primary server has a newer zone, a transfer is scheduled. This command is valid for secondary zones. (#)

zone-retransfer [zone...]

Trigger a zone transfer from the zone's primary server. The server doesn't check the serial of the primary server's zone. This command is valid for secondary zones. (#)

zone-notify [zone...]

Trigger a NOTIFY message to all configured remotes. This can help in cases when previous NOTIFY had been lost or the secondary servers have been offline. (#)

zone-flush [zone...] [+outdir directory]

Trigger a zone journal flush to the configured zone file. If zonefile synchronization is disabled, the force option must be used. If an output directory is specified, the current zone is immediately dumped (in the blocking mode) to a zone file in the specified directory. See Notes below about the directory permissions. (#)

zone-backup [zone...] +backupdir directory [filter...]

Trigger a zone data and metadata backup to a specified directory. Available filters are +zonefile, +journal, +timers, +kaspdb, +keysonly, +catalog, +quic, and their negative counterparts +nozonefile, +nojournal, +notimers, +nokaspdb, +nokeysonly, +nocatalog, and +noquic. With these filters set, zone contents, zone's journal, zone-related timers, zone-related data in the KASP database together with keys (or keys without the KASP database), zone's catalog, and the server QUIC key and certificate, respectively, are backed up, or omitted from the backup. By default, filters +zonefile, +timers, +kaspdb, +catalog, +quic, +nojournal, and +nokeysonly are set for backup. The same defaults are set for restore, with the only difference being +noquic. Setting a filter for an item doesn't change the default settings for other items. The only exception is +keysonly, which disables all other filters by default, but they can still be turned on explicitly. If zone flushing is disabled, the original zone file is backed up instead of writing out zone contents to a file. When backing-up a catalog zone, it is recommended to prevent ongoing changes to it by use of zone-freeze. The force option allows an already existing backupdir to be overwritten. See Notes below about the directory permissions. (#)

zone-restore [zone...] +backupdir directory [filter...]

Trigger a zone data and metadata restore from a specified backup directory. Optional filters are equivalent to the same filters of zone-backup. Restore from backups created by Knot DNS releases prior to 3.1 is possible with the force option. See Notes below about the directory permissions. (#)

zone-sign [zone...]

Trigger a DNSSEC re-sign of the zone. Existing signatures will be dropped. This command is valid for zones with DNSSEC signing enabled. (#)

zone-validate [zone...]

Trigger a DNSSEC validation of the zone. If the validation fails and the zone is secondary, the zone expires immediately! (#)

zone-keys-load [zone...]

Trigger a load of DNSSEC keys and other signing material from KASP database (which might have been altered manually). If suitable, re-sign the zone afterwards (keeping valid signatures intact). (#)

zone-key-rollover zone key_type

Trigger immediate key rollover. Publish new key and start a key rollover, even when the key has a lifetime to go. Key type can be ksk (also for CSK) or zsk. This command is valid for zones with DNSSEC signing and automatic key management enabled. Note that complete key rollover consists of several steps and the blocking mode relates to the initial one only! (#)

zone-ksk-submitted zone... [+ttl seconds]

Use when the zone's KSK rollover is in submission phase. By calling this command the user confirms manually that the parent zone contains DS record for the new KSK in submission phase and the old KSK can be retired. The optional +ttl parameter specifies the parent DS's TTL and possibly other delays, with the effect that the removal of old KSK is postponed by this number of seconds. (#)

zone-freeze [zone...]

Trigger a zone freeze. All running events will be finished and all new and pending (planned) zone-changing events (load, refresh, update, flush, and DNSSEC signing) will be held up until the zone is thawed. Up to 8 (this limit is hardcoded) DDNS updates per zone will be queued, subsequent updates will be refused. (#)

zone-thaw [zone...]

Trigger dismissal of zone freeze. (#)

zone-xfr-freeze [zone...]

Temporarily disable outgoing AXFR/IXFR for the zone(s). (#)

zone-xfr-thaw [zone...]

Dismiss outgoing XFR freeze. (#)

zone-read zone [owner [type]]

Get zone data that are currently being presented.

zone-begin zone... [+benevolent]

Begin a zone transaction. If +benevolent is used, the transaction will be committed even if it contains removals of non-existent records or additions of existing records.

zone-commit zone...

Commit the zone transaction. All changes are applied to the zone.

zone-abort zone...

Abort the zone transaction. All changes are discarded.

zone-diff zone

Get zone changes within the transaction.

zone-get zone [owner [type]]

Get zone data within the transaction.

zone-set zone owner [ttl] type rdata

Add zone record within the transaction. The first record in a rrset requires a ttl value specified.

zone-unset zone owner [type [rdata]]

Remove zone data within the transaction.

zone-purge zone... [+orphan] [filter...]

Purge zone data, zone file, journal, timers, and/or KASP data of specified zones. Available filters are +expire, +zonefile, +journal, +timers, +kaspdb, and +catalog. If no filter is specified, all filters are enabled. If the zone is no longer configured, add +orphan parameter (zone file cannot be purged in this case). When purging orphans, always check the server log for possible errors. For proper operation, it's necessary to prevent ongoing changes to the zone and triggering of zone related events during purge; use of zone-freeze is advisable. This command always requires the force option. (#)

zone-stats zone [module[.counter]]

Show zone statistics counter(s). To print also counters with value 0, use force option.

zone-serial-set zone [[+]serial]

Set the zone SOA serial to the specified value. If the argument is prefixed with +, the serial is incremented by that value (the special constant MAX can be used to increment by the maximum allowed value 2147483647). If the zone transaction is open, both reading and writing of the SOA serial occur within that transaction. Otherwise, a short-lived transaction is created and committed solely for setting the new SOA serial. If no argument is specified, the current zone SOA serial is returned.

conf-init

Initialize the configuration database. If the database doesn't exist yet, execute this command as an intended user to ensure the server is permitted to access the database (e.g. sudo -u knot knotc conf-init). (*)

conf-check

Check the server configuration. (*)

conf-import filename [+nopurge]

Import a configuration file into the configuration database. If the database doesn't exist yet, execute this command as an intended user to ensure the server is permitted to access the database (e.g. sudo -u knot knotc conf-import ...). An optional filter +nopurge prevents possibly existing configuration database from purging before the import itself. Also ensure the server is not using the configuration database at the same time! (*)

conf-export [filename] [+schema]

Export the configuration database (or JSON schema) into a file or stdout. (*)

conf-list [item]

List the configuration database sections or section items.

conf-read [item]

Read the item from the active configuration database.

conf-begin

Begin a writing configuration database transaction. Only one transaction can be opened at a time.

conf-commit

Commit the configuration database transaction.

conf-abort

Rollback the configuration database transaction.

conf-diff [item]

Get the item difference in the transaction.

conf-get [item]

Get the item data from the transaction.

conf-set item [data...]

Set the item data in the transaction.

conf-unset [item] [data...]

Unset the item data in the transaction.

### Notes
Empty or -- zone parameter means all zones or all zones with a transaction.

Use @ owner to denote the zone name.

Type item parameter in the form of section[[id]][.name].

(*) indicates a local operation which requires a configuration.

(#) indicates an optionally blocking operation.

The -b and -f options can be placed right after the command name.

Responses returned by knotc commands depend on the mode:

- In the blocking mode, knotc reports if an error occurred during processing of the command by the server. If an error is reported, a more detailed information about the failure can usually be found in the server log.

- In the non-blocking (default) mode, knotc doesn't report processing errors. The OK response to triggering commands means that the command has been successfully sent to the server. To verify if the operation succeeded, it's necessary to check the server log.

Actions zone-flush, zone-backup, and zone-restore are carried out by the knotd process. The directory specified must be accessible to the user account that knotd runs under and if the directory already exists, its permissions must be appropriate for that user account.

### Interactive mode
The utility provides interactive mode with basic line editing functionality, command completion, and command history.

Interactive mode behavior can be customized in ~/.editrc. Refer to editrc(5) for details.

Command history is saved in ~/.knotc_history.

## EXIT VALUES
Exit status of 0 means successful operation. Any other exit status indicates an error.

## EXAMPLES

### Reload the whole server configuration

```
$ knotc reload
```

### Flush the example.com and example.org zones

```
$ knotc zone-flush example.com example.org
```

### Get the current server configuration

```
$ knotc conf-read server
```

### Get the list of the current zones

```
$ knotc conf-read zone.domain
```

### Get the primary servers for the example.com zone

```
$ knotc conf-read 'zone[example.com].master'
```

### Add example.org zone with a zonefile location

```
$ knotc conf-begin
$ knotc conf-set 'zone[example.org]'
$ knotc conf-set 'zone[example.org].file' '/var/zones/example.org.zone'
$ knotc conf-commit
```

### Get the SOA record for each configured zone

```
$ knotc zone-read -- @ SOA
```

## SEE ALSO
knotd(8), knot.conf(5), editrc(5).

## Author
CZ.NIC, z.s.p.o. and contributors <https://www.knot-dns.cz/>

## Copyright
Copyright (C) CZ.NIC, z.s.p.o. and contributors


knotd

title: knotd(8)

summary: Knot DNS server daemon

text:
# knotd(8)

## NAME
knotd - Knot DNS server daemon

## SYNOPSIS
knotd [config_option] [options]

## DESCRIPTION
Knot DNS is a high-performance authoritative DNS server. The knotd program is the DNS server daemon.

### Config options
-c, --config file

Use a textual configuration file (default is /etc/knot/knot.conf).

-C, --confdb directory

Use a binary configuration database directory (default is /var/lib/knot/confdb). The default configuration database, if exists, has a preference to the default configuration file.

### Options
-m, --max-conf-size MiB

Set maximum size of the configuration database (default is 500 MiB, maximum 10000 MiB).

-s, --socket path

Use a remote control UNIX socket path (default is /run/knot/knot.sock).

-d, --daemonize [directory]

Run the server as a daemon. New root directory may be specified (default is /).

-v, --verbose

Enable debug output.

-h, --help

Print the program help.

-V, --version

Print the program version. The option -VV makes the program print the compile time configuration summary.

### Signals
The knotd process handles the following signals:

- SIGINT – Stop the process.

- SIGHUP – Reload the server configuration and reopen configured log files.

- SIGUSR1 – Reload all configured zones (not recommended with catalog zones).

## EXIT VALUES
Exit status of 0 means successful operation. Any other exit status indicates an error.

## SEE ALSO
knot.conf(5), knotc(8), keymgr(8), kjournalprint(8).

## Author
CZ.NIC, z.s.p.o. and contributors <https://www.knot-dns.cz/>

## Copyright
Copyright (C) CZ.NIC, z.s.p.o. and contributors


kresctl

package: knot-resolver

title: kresctl(8)

text:
# kresctl(8)

## NAME
kresctl - Control Knot Resolver 6.2.0, the full caching DNSSEC-enabled resolver

## SYNOPSIS
kresctl [-s|--socket API_SOCKET] <command> <args>

## DESCRIPTION
kresctl is a control tool for Knot Resolver, a DNSSEC-enabled full caching resolver.

kresctl may be used to control and inspect the configuration of running Knot Resolver via its HTTP API.

Full documentation is available at https://www.knot-resolver.cz/documentation/latest/ or in package documentation (available as knot-resolver-doc package in most distributions.

## OPTIONS
The available options are:

-s <api_socket>, --socket <api_socket>

Specify how to connect to a running Knot Resolver. Accepts path to Unix-domain socket or host:port. Defaults to /var/run/knot-resolver/kres-api.sock

Some commands do not require communication with the running resolver. In such cases, the value of this option is ignored and the command may succeed even if the socket is invalid. -h, --help Print help message and exit.

## COMMANDS
config [-d|--delete] [--stdin] json_ptr [new_value]

Get or modify resolver's runtime configuration. json_ptr follows RFC 6901 and specifies, which part of the configuration will the tool operate on. This argument is required. When not given any additional options or arguments, prints the current configured value. Equivalent to GET method in the underlying HTTP API.

When -d or --delete is provided, kresctl tries to remove the runtime configuration subtree. The operation fails if it renders the configuration invalid. Equivalent to the DELETE method in the HTTP API.

When --stdin or new_value are provided, the new value (from the argument or from reading stdin) is put into the configuration at the given json_ptr. The operation fails if it renders the configuration invalid. Equivalent to PUT method in the underlying HTTP API.

stop

Gracefully stops the running resolver.

## SEE ALSO
kresd(8), https://www.knot-resolver.cz/documentation/latest/

## AUTHORS
kresd developers are mentioned in the AUTHORS file in the distribution.


kresd

title: kresd(8)

text:
# kresd(8)

## NAME
kresd - full caching DNSSEC-enabled Knot Resolver 6.2.0.

## SYNOPSIS
kresd [-a|--addr addr[@port]] [-t|--tls addr[@port]] [-S|--fd fd] [-T|--tlsfd fd] [-c|--config config] [-n|--noninteractive] [-q|--quiet] [-v|--verbose] [-V|--version] [-h|--help] [rundir]

## DESCRIPTION
Beware: you most likely don't want to use the kresd process directly. Instead the knot-resolver command will manage the processes for you.

Knot Resolver is a DNSSEC-enabled full caching resolver.

Default mode of operation: when it receives a DNS query it iteratively asks authoritative nameservers starting from root zone (.) and ending with a nameservers authoritative for queried name. Automatic DNSSEC means verification of integrity of authoritative responses by following keys and signatures starting from root. Root trust anchor is automatically bootstrapped from IANA, or you can provide a file with root trust anchors (same format as Unbound or BIND9 root keys file).

The daemon also caches intermediate answers into cache, which by default uses LMDB memory-mapped database. This has a significant advantage over in-memory caches as the process may be stopped and restarted without loss of cache entries. In multi-user scenario a shared cache is potential privacy/security issue, with kresd each user can have resolver cache in their private directory and use it in similar fashion to keychain.

To use a locally running kresd for resolving put

nameserver 127.0.0.1

into resolv.conf(5) and start kresd

The daemon may be configured also as a plain forwarder using query policies. This requires using a config file. Please refer to documentation for configuration file options. It is available at https://www.knot-resolver.cz/documentation/latest/ or in package documentation (available as knot-resolver-doc package in most distributions).

The available CLI options are:

-a addr[@port], --addr=<addr[@port]>

Listen on given address (and port) pair. If no port is given, 53 is used as a default. Option may be passed multiple times to listen on more addresses.

-t addr[@port], --tls=<addr[@port]>

Listen using TLS on given address (and port) pair. If no port is given, 853 is used as a default. Option may be passed multiple times to listen on more addresses.

-S fd, --fd=<fd>

Listen on given file descriptor(s), passed by supervisor. Option may be passed multiple times to listen on more file descriptors.

-T fd, --tlsfd=<fd>

Listen using TLS on given file descriptor(s), passed by supervisor. Option may be passed multiple times to listen on more file descriptors.

-c config, --config=<config>

Set the config file with settings for kresd to read instead of reading the file at the default location (config).

-n, --noninteractive

Daemon will refrain from entering into read-eval-print loop for stdin+stdout.

-q, --quiet

Daemon will refrain from printing the command prompt.

-v, --verbose

Increase logging to debug level.

-h

Show short command-line option help.

-V

Show the version.

## SEE ALSO
https://www.knot-resolver.cz/documentation/latest/

## AUTHORS
kresd developers are mentioned in the AUTHORS file in the distribution.