vzstat

package: vzstat

title: vzstat(8)

text:
# vzstat(8)

## NAME
vzstat - top-like utility for gathering statistics

## SYNOPSIS
vzstat [-l] [-d X] [-p CTID] [-b|-v] [-t] [-m] [-a] [-o|-O|-i|-n] [-c<B|K|M|G>]

## DESCRIPTION
The vzstat utility is a top-like utility for real-time monitoring in OpenVZ. It displays the current system state and load, lists most resource - consuming Containers, and can provide an interactive interface for displaying parameters. It also can sort Containers by a number of parameters.

## COMMAND-LINE OPTIONS
-l

Batch mode. Prints the information once and exits immediately if no delay time (-d option) is specified. Otherwise, continues looping with the specified delay between the cycles.

-d delay

Specifies the delay time between screen updates. In the screen view mode, you can change this with the t interactive command. The default delay time is 1 sec.

-p CTID

Monitor only Containers with the specified IDs. This flag can be given up to twenty times, in form -p CTID1 -p CTID2 .... This option is not available interactively.

-b

"Brief" mode. Minimal detail level. Shows only one summary line about each monitoring subsystem. By default, the "standard" detail level is used. Valid levels are "brief", "standard" and "verbose". Can be set on the fly using the b interactive command. See also the -v command-line option and the s and v interactive commands.

-t

Text mode. Prints the information tersely, in a form suitable for parsing by other programs. The output data is neither aligned nor colored and numbers are not displayed in a human readable format. If no delay time (-d option) is specified, prints the information once and exits immediately. Otherwise, continues looping with the specified delay time between the cycles.

-v

"Verbose" mode. Provides maximum details about all monitored subsystems. Can be set on the fly using v interactive command. See also the -b command-line option and the b and s interactive commands.

-m

Display disc statistics for all fs types (by default only for ext2, ext3, ext4, reiserfs).

-o format

Set user-defined format. format is a single argument in the form of comma-separated list, which offers a way to specify individual output columns. The recognized keywords are described in the OUTPUT section below (see CODE in per Container info). Headers may be renamed (vzstat -o st,vm=VM) as desired or may be empty (vzstat -o st=,ior=). The column width can also be specified after the colon (-o name:12,host=HOST:20).

-O format

is like -o, but preloaded with some default columns. Identical to -o id,st,format,ip

-i

Show IO statistics. Identical to -o id,st,ior,iow,iort,iowt,ip IO statistics display may be toggled by the I interactive command.

-n

Show network statistics. Identical to -o id,st,rx,tx,rxt,txt,rxpt,txpt,ip Network statistics display may be toggled by the X interactive command.

-s key

Sort per-Container statistics by key. The recognized keywords are described in the OUTPUT section below (see CODE in per Container info). Sort keywords are identical to keywords for the -o option.

-a

Display disk input and output (I/O) statistics for Containers.

-c <B|K|M|G>

Scale output to the specified units.

## OUTPUT
vzstat displays a variety of information about the OpenVZ system state. The display is updated every 1 second by default, but you can change that with the -d command-line option or the t interactive command.

uptime

This line displays the time the system has been up, and the three load averages for the system. The load averages are the average number of process ready to run during the last 1, 5 and 15 minutes. This line is just like the output of uptime(1). For example: "1:22am, up 1:31, 2 users, load average: 0.00, 0.06, 0.33". The uptime display may be toggled by the interactive l command.

Containers and processes

The total number of Containers and processes running at the time of the last update. This is also broken down into the number of tasks which are running, sleeping, uninterruptible, zombie, stopped and dead. For example: "CTNum 102, procs 467: R 12, S 455, D 0, Z 0, T 0, X 1". The processes and states display may be toggled by the p interactive command.

CPU states

Shows the percentage of CPU time used by all Containers (except for CT0) and by CT0, CPU time usage in user mode, system mode, idle and max/avg scheduling latency in ms. Scheduling latency is time spent by the processes in the system awaiting for scheduling. For example: "CPU [ OK ]: CTs 43%, CT0 12%, user 41%, sys 13%, idle 45%, lat(ms) 3/2". The CPU usage display may be toggled by the c interactive command.

Mem

Statistics about memory usage, including the total available memory, free memory and max/avg memory allocation latency. Free memory is displayed both for low and high memory. Low memory is the sum of DMA and Normal zones memory and high memory is the High zone memory. Allocation latency is the time required to allocate memory inside the kernel in milliseconds. A long allocation latency can be a sign of node's overload. For example: "Mem [ OK ]: total 755MB, free 671MB/0MB (low/high), lat(ms) 10/7". That means that the maximum allocation latency is 10 and the average is 7. The display of memory information may be toggled by the m, M interactive commands.

Memory zones information

Information about memory zone state. This information includes: total memory zone size in MB, size of active and inactive lists, free memory and zone limits. For example: "ZONE1 (Normal): size 752MB, act 29MB, inact 31MB, free 658MB (0/1/2)". The display of memory information may be toggled by the m, M interactive commands.

Memory zones fragmentation

Information about memory zones fragmentation. This information describes how much system memory is fragmented and which is the biggest block size possible to allocate atomically. For example: "fragm 2*1 3*2 15*4 22*8 25*16 12*32 4*64 0*128 1*256 326*512". The first number before * is the number of blocks and the second one is the block size in pages. The display of memory information may be toggled by the m, M interactive commands.

Memory allocation latency

Memory allocation latency is an average time spent in kernel memory allocator for different memory type requests. Memory type is coded as XY, where X is A for GFP_ATOMIC, K for GFP_KERNEL and U for GFP_USER and Y denotes allocation request order, i.e. Y=0 for order=0 and 1 for order=1. For example: "Mem lat (ms): A0 0, K0 0, U0 1, K1 3, U1 2". The display of memory information may be toggled by the m, M interactive commands.

Slab cache information

Slab cache information includes the total slab cache size/real cache size, inode cache size, dentry cache size, buffer heads cache size, and page beancounters cache size. Real cache size is the size the cache can be shrunk to; it's always less than the total cache size. For example: "Slab pages: 13MB/13MB (ino 8MB, de 1MB, bh 1MB, pb 0MB)". The display of memory information may be toggled by the m, M interactive commands.

Swap

Statistics on swap space, including total swap space, available swap space and swap in/swap out in MB/s. For example: "Swap [ OK ]: tot 1004MB, free 1004MB, in 0.000MB/s, out 0.000MB/s". The display of swap information may be toggled by the w, W interactive commands.

Swap latency

Swap operations latency. This includes swap in count, swap in max/avg latency in ms, swap out count, swap out max/avg latency in ms and max/avg cpu time spent in swap out. For example: "Swap lat: si 0, 0/0 ms, so 0, 0/0 ms, 0/0 cpu ms". The display of swap information may be toggled by the w, W interactive commands.

Swap cache

Swap cache information includes: number of adds to swap cache, dels from swap cache and finds. For example: "Swap cache: add 0, del 0, find 0/0". The display of swap information may be toggled by the w, W interactive commands.

Network information

Network statistics summary. Total incoming traffic in MB/s and incoming packets/s, outcoming traffic in MB/s and packets/s. For example: "Net [ OK ]: tot in 1.020MB/s 267pkt/s, out 0.001MB/s 1pkt/s". The display of network information may be toggled by the n, N interactive commands.

Network interface information

Network interface statistics summary. Total incoming traffic in MB/s and incoming packets/s, outcoming traffic in MB/s and packets/s. For example: "eth0: in 0.000MB/s 3pkt/s, out 0.001MB/s 1pkt/s". The display of network information may be toggled by the n, N interactive commands. Note: veth interfaces statistics is shown only in text mode, i.e. when the -l or -t option is specified.

Disks statistics

Summary disks statistics. Reads in MB/s and writes in MB/s. For example: "Disks [ OK ]: in 0.000MB/s, out 0.000MB/s". The display of disk information may be toggled by the d, D interactive commands.

Mounted disks statistics

Information on mounted disks, such as mount points, free space, and the number of free inodes left on the device. For example: "root(/) free: 3489MB(46%), 511077ino(52%)". The display of disk information may be toggled by the d, D interactive commands.

Disk I/O statistics

Show disk input and output statistics for Containers. The following information is shown: * IOUSED%: the percentage of time the disks are used by the Container. * IOWAIT%: the percentage of time when at least one I/O transaction in the Container is waiting for being served. * IOSPEED: the current speed of disk I/O operations in the Container and the I/O limit set for this Container, if any. The value can be displayed in bytes, kilobytes, megabytes, or gigabytes per second, depending on the units you used to set the I/O limit. The display of disk information may be toggled by the A interactive command.

per-Container info

Per-Container info is a list of Containers with some information about them like IDs, memory usage, processes, CPU usage, socket usage, fail counters, IP addresses. The columns to be shown can be specified using the -o option (see above). The following columns can be displayed for Containers:

CODE

HEADER DESCRIPTION

id

CTID Container ID.

st

ST Container status. OK if Container latency and fail counters are good; otherwise, red "!!". Your can sort Containers by their statuses, displaying Containers with the "failed" status first.

vm

%VM Virtual memory usage, i.e. UBC privvmpages parameter (in percentage from total memory). The first number is how much privvmpages are being held (i.e. actual usage), the second is privvmpages barrier. For example: 5%/50% means that Container in question holds 5% of pages (of total memory) for privvmpages and can use even more, up to 50% of total memory pages. When a Container is running in SLM mode, privvmpages barrier has no fixed value, because it's calculated dynamically in the kernel, and this value depends on the current memory usage, Container activity, SLM settings and UBC limits for this Container. In SLM mode, privvmpages barrier for a Container is usually a little bit bigger than the usage, so this real value is not very useful and marked by '-'.

sw

%SW Virtual swap usage, i.e. UBC swappages parameter. The first parameter is percent of virtual swap usage, the second is the size of the virtual swap configured.

km

%KM Kernel memory usage, i.e. the UBC kmemsize parameter (in percentage from normal zone size). The first parameter is how much kmemsize is being used, the seconds is kmemsize barrier. For example: 3%/7% means that the Container in question holds 3% of the normal zone for kernel memory and can use even more, up to 7% of the normal zone. When SLM module is loaded, kmemsize barrier has no fixed value, and like privvmpages barrier it's marked by '-'.

proc

PROC Process information, in the format running tasks/total tasks/barrier. For example: 3/20/100 means that 3 processes are running, there are 20 processes in total, and at most 100 processes can be spawned in the Container in total. You can sort Containers by the number of total or running tasks.

cpu

CPU CPU usage. The actual CPU usage and the requested CPU usage are printed here. The first number is the actual CPU usage by a Container. When running on more than 1 CPU (i.e. on SMP host), all the processors are considered as 100%. The seconds number is the guaranteed CPU usage according to the assigned cpuunits weight. For example: 3%/5%, 99%/5%. Note that the actual CPU usage can be higher than the guaranteed one.

sock

SOCK Sockets usage, i.e. the sum of UBC numtcpsock and numothersock parameters. The first parameter is how much sockets are opened, the seconds is the sockets barrier. For example: 12/100 means that the Container in question holds 12 sockets and can open more sockets, but it is limited to 100 sockets.

fcnt

FCNT Fail counters, i.e. the sum of UBC fail counters for all resources. The FCNT parameter is printed differently in average and standart modes. In standart mode fail counters delta is printed, i.e. the increase of failcounter sum since the last screen update. If average mode is on, the absolute fail counters sum is printed.

mlat

MLAT Maximum scheduling latency for a Container, in ms. This parameter shows the maximum process scheduling latency inside the Container, i.e. how long (maximum) a process inside Container awaits for the CPU.

name

NAME Container name.

io

IO I/O rate and I/O limit in MBytes per second.

iops

IOPS The current rate of I/O operations in a Container and the limit set for the Container, calculated per second.

iow

IOW total number of bytes that were written to all block devices (IDE, SCSI, NFS ...) in MBytes per second.

ior

IOR total number of bytes that were read from all block devices (IDE, SCSI, NFS ...) in MBytes per second.

iowt

IOWT total number of bytes that were written to all block devices (IDE, SCSI, NFS ...) in MBytes.

iort

IORT total number of bytes that were read from all block devices (IDE, SCSI, NFS ...) in MBytes.

ios

IOS sync rate (MB/sec)

iod

IOD dirty pages rate (MB/sec). This value shows how many memory pages are dirty. Dirty pages are those pages that have data not yet flushed to the disk.

cpu_iowait

CPU IOWAIT current CPU IO wait in percent

cpu_iowait_acc

ACC IOWAIT accumulated CPU IO wait in percent

swapin

SWAPIN Number of I/O operations with swap in a Container, per second.

Per-Container network related codes.

Total network incoming/outgoing traffic statistics include information about all defined network classes. The network classes are described in the /etc/vz/conf/networks_classes file. See networks_classes (5) man page for more details. rx

RX received bytes rate (MB/sec).

tx

TX transmitted bytes rate (MB/sec).

rxt

RXT received bytes total (MB).

txt

TXT transmitted bytes total (MB).

rxp

RXP received packets rate (packets/sec).

txp

TXP transmitted packets rate (packets/sec).

rxpt

RXPT received packets total.

txpt

TXPT transmitted packets total.

## INTERACTIVE KEYS
Several single-keys commands are recognized while vzstat is running. Interactive commands are not available if vzstat is executed with the -t or -l command-line option.

h, ?

Print help usage.

space

Update the display immediately.

q

Quit.

t

Change the delay between screen updates. You will be prompted to enter a new delay time, in seconds. Entering 0 causes continuous updates. See also the -d command-line parameter.

r

Redraw full screen from scratch.

b

Set "brief" detail level. See also the -b command-line parameter.

s

Set"normal" detail level.

v

Set"verbose" detail level. See also the -v command-line parameter.

a

"Averaged" mode. The average (for a minute) for monitoring parameters is shown. This includes:

Number of uninterruptable processes

Scheduling max latency

Memory allocation max latency

Size of free/active/inactive memory

Swap-in latency

UBC fail counters absolute values

i

Toggle display of idle Containers.

l

Toggle display of load average.

p

Toggle display of processes statistics.

c

Toggle display of CPU usage statistics.

e

Toggle display of hostname/ip information.

m, M

Toggle/expand the display of memory information. Each subsystem, including memory, network, and disk, has a number of verbosity levels. On the minimal level, no information is displayed. Interactive lowercase keys decrease the verbosity level, the same keys in uppercase increase it.

n, N

Toggle/expand display of network statistics.

d, D

Toggle/expand display of disk usage and activity information.

w, W

Toggle/expand display of swap information.

I

Switch to IO accounting column set.

X

Switch to network statistics column set.

A

Switch to IO statistics column set.

0

Toggle display of CT0 statistics.

o

Sort key. One of the sort option keys should follow it:

n

Sort by CTID

t

Sort by Container status

v

Sort by virtual memory usage

k

Sort by kernel memory usage

r

Sort by the number of running processes

p

Sort by the total number of processes

c

Sort by CPU usage

s

Sort by number of open sockets

f

Sort by UBC failure counters

m

Sort by memory latency

## VZSTAT CONFIGURATION FILES
The vzstat configuration file is located in /etc/vz/vzstat.conf. The parameter values in this file are highlighting thresholds for the corresponding monitoring parameters. If the current value exceeds the warning level, the parameter is shown in yellow. If the value exceeds the error level, the parameter is shown in red. Some parameters, however, have one threshold only. All the parameters are numerical and specified in the form PARAMETER=NNN.

LOAD_AVG

Load average. Warning level. If exceeded, the parameter is shown is yellow.

PROC_RUN

Number of running processes. Warning level. If exceeded, the parameter is shown is yellow.

PROC_UNINT

Number of uninterruptable processes (in ´D´ state). Warning level. If exceeded, the parameter is shown is yellow.

CPU_IDLE

CPU idle time, in percent. Warning level. If exceeded, the parameter is shown is yellow.

CPU_SYS

CPU system time, in percent. Warning level. If exceeded, the parameter is shown is yellow.

CPU_LAT_MAX_WARN

Scheduling latency, in milliseconds (maximum over 5 sec period). Warning level. If exceeded, the parameter is shown is yellow.

CPU_LAT_AVG_ERR

Scheduling latency, in milliseconds (maximum over 5 sec period). Error level. If exceeded, the parameter is shown in red.

CPU_LAT_AVG_WARN

Scheduling latency, in milliseconds (5 sec average). Warning level. If exceeded, the parameter is shown is yellow.

CPU_LAT_MAX_ERR

Scheduling latency, in milliseconds (5 sec average). Error level. If exceeded, the parameter is shown in red.

MEM_LAT_MAX_WARN

Memory allocation latency, in milliseconds (maximum over 5 sec period). Warning level. If exceeded, the parameter is shown is yellow.

MEM_LAT_MAX_ERR

Memory allocation latency, in milliseconds (maximum over 5 sec period). Error level. If exceeded, the parameter is shown in red.

MEM_LAT_AVG_WARN

Memory allocation latency, in milliseconds (5 sec average). Warning level. If exceeded, the parameter is shown is yellow.

MEM_LAT_AVG_ERR

Memory allocation latency, in milliseconds (5 sec average). Error level. If exceeded, the parameter is shown in red.

MEM_ZONE_ACT_INACT_FREE_WARN

Size of available memory (free + active + inactive pages), in percent. Warning level. If the current value is below this level, the parameter is shown is yellow.

MEM_ZONE_ACT_INACT_FREE_ERR

Size of available memory (free + active + inactive pages), in percent. Error level. If the current value is below this level, the parameter is shown in red.

MEM_ZONE_ACT_INACT_FREE_ABS_WARN

Size of available memory (free + active + inactive pages), in MB. Warning level. If the current value is below this level, the parameter is shown is yellow.

MEM_ZONE_ACT_INACT_FREE_ABS_ERR

Size of available memory (free + active + inactive pages), in MB. Error level. If the current value is below this level, the parameter is shown in red.

MEM_ZONE_ORDER_GT_0

Number of pages which are gathered in blocks with order > 0. For example, if current memory distribution looks like: 3*1 1*2 3*4 5*8 .... Then number of pages with order>0 is 1*2 + 3*4 + 5*8 + ... This sum is printed yellow if it is too low.

SWAP_FREE_WARN

Free swap space, in percent. Warning level. If exceeded, the parameter is shown is yellow.

SWAP_FREE_ERR

Free swap space, in percent. Error level. If the current value is below this level, the parameter is shown in red.

SWAP_IN_WARN

Swap-in activity, in Mb/sec. Warning level. If exceeded, the parameter is shown is yellow.

SWAP_IN_ERR

Swap-in activity, in Mb/sec. Error level. If exceeded, the parameter is shown in red.

SWAP_OUT_WARN

Swap-out activity, in Mb/sec. Warning level. If exceeded, the parameter is shown is yellow.

SWAP_OUT_ERR

Swap-out activity, in Mb/sec. Error level. If exceeded, the parameter is shown in red.

SWAP_LAT_MAX_WARN

Swap-in latency, in milliseconds (maximum over 5 sec period). Warning level. If exceeded, the parameter is shown is yellow.

SWAP_LAT_MAX_ERR

Swap-in latency, in milliseconds (maximum over 5 sec period). Error level. If exceeded, the parameter is shown in red.

SWAP_LAT_AVG_WARN

Swap-in latency, in milliseconds (5 sec average). Warning level. If exceeded, the parameter is shown is yellow.

SWAP_LAT_AVG_ERR

Swap-in latency, in milliseconds (5 sec average). Error level. If exceeded, the parameter is shown in red.

DISK_FREE_INODES_WARN

Free inodes on disk, in percent. Warning level. If the current value is below this level, the parameter is shown is yellow.

DISK_FREE_INODES_ERR

Free inodes on disk, in percent. Error level. If the current value is below this level, the parameter is shown in red.

DISK_FREE_SPACE_WARN

Free disk space, in percent. Warning level. If the current value is below this level, the parameter is shown is yellow.

DISK_FREE_SPACE_ERR

Free disk space, in percent. Error level. If the current value is below this level, the parameter is shown in red.

DISK_IO_LOAD_WARN

Disk IO load, in percent. Warning level. If exceeded, the parameter is shown is yellow.

DISK_IO_LOAD_ERR

Disk IO load, in percent. Error level. If exceeded, the parameter is shown in red.

CT_FAILCNT_DELTA

Number of failed UBC resource allocations for a Container between vzstat screen updates (any resource type is taken into account). Error level. If exceeded, the parameter is shown in red.

## NOTES
vzstat requires superuser privileges to run.

## SEE ALSO
networks_classes(5).

## COPYRIGHT
Copyright (c) 2003-2017, Parallels International GmbH. All rights reserved. Copyright (c) 2017-2019 Virtuozzo International GmbH. All rights reserved.


vzstats

package: vzstats

title: vzstats(8)

summary: report OpenVZ usage statistics

text:
# vzstats(8)

## NAME
vzstats - report OpenVZ usage statistics

## SYNOPSIS
vzstats

vzstats --view|--status

vzstats --enable|--disable

vzstats --help

## DESCRIPTION
Utility vzstats, installed on an OpenVZ server, periodically collects some usage statistics and sends it to the OpenVZ stats server, http://stats.openvz.org, for processing and analysis. Aggregated statistics from all reports are available through the web interface.

Statistics reported include some basic hardware information (CPU, RAM, file system and disk space usage for /vz), software information (distribution version, kernel version, OpenVZ software versions), and some OpenVZ-specific information (number of containers running/total, number of containers using vswap and ploop, used OS templates etc.). Information submission is anonymous; information that can be used to directly identify a particular host (i.e. MAC or IP addresses, hostnames etc.) is not being reported.

For the server to anonymously identify reports from the same client, a unique random ID (UUID v4) is requested from the server during the first vzstats run. It is then saved locally and used when sending reports.

If run without any options and unless disabled, vzstats runs report scripts found in REPDIR (defined in vzstats.conf, default is /usr/libexec/vzstats), collects their output and sends it, as a tarball, to stats server.

## OPTIONS
In case any option is provided, no report is being send, instead an action denoted by the option is performed.

The following options are supported:

--view

Collect but do not send report, giving a user an ability to see what exact information would be send.

--config

Output current vzstats configuration, including:

• current version number;

• status (enabled or disabled);

• an URL used to submit reports to;

• vzstats UUID;

• report scripts directory.

--disable

Disable reporting. This is performed by creating a marker file, /etc/vz/vzstats-disable. vzstats checks this file upon start, and exits if it is present.

--enable

Re-enable reporting.

--help

Show usage.

## FILES

```
/etc/vz/vzstats.conf
/etc/vz/vzstats-disable
/usr/libexec/vzstats/*
```

## SEE ALSO
vzlist(8), http://stats.openvz.org/, http://openvz.org/vzstats.

## LICENSE
Copyright (C) 2013, Parallels, Inc. Licensed under GNU GPL.


vzpkg

package: vztt

title: vzpkg(8)

summary: tool for managing OpenVZ templates.

text:
# vzpkg(8)

## NAME
vzpkg - tool for managing OpenVZ templates.

## SYNOPSYS
vzpkg install [options] CT ID | CT NAME object [object ...]

vzpkg update [options] CT ID | CT NAME [object ...]

vzpkg remove [options] CT ID | CT NAME object [object ...]

vzpkg localinstall [options] CT ID | CT NAME rpmfile [rpmfile ...]

vzpkg localupdate [options] CT ID | CT NAME rpmfile [rpmfile ...]

vzpkg list [options] CT ID | CT NAME [CT ID | CT NAME ...] [--available]

vzpkg list [options] [ostemplate ...] [--available]

vzpkg create cache [options] [ostemplate ...]

vzpkg update cache [options] [ostemplate ...]

vzpkg remove cache [options] [ostemplate ...]

vzpkg create appcache [options]

vzpkg update appcache [options]

vzpkg remove appcache [options]

vzpkg list appcache

vzpkg create image <ostemplate> <path>

vzpkg info [options] [-F ostemplate | CT ID | CT NAME] object | CT ID | CT NAME [parameter ...]

vzpkg install template [options] [-F ostemplate] object ...

vzpkg update template [options] [-F ostemplate] object ...

vzpkg remove template [options] [-F ostemplate] object ...

vzpkg upgrade [options] CT ID | CT NAME

vzpkg fetch [options] ostemplate [ostemplate ...]

vzpkg update metadata [options] [ostemplate ...]

vzpkg link [options] CT ID | CT NAME

vzpkg clean [options] [ostemplate ...]

vzpkg status [options] ostemplate | CT ID | CT NAME

vzpkg upgrade area [options] ostemplate ...

vzpkg help

## DESCRIPTION
OpenVZ management tool for handling EZ templates and standalone RPM/DPKG packages and RPM packages groups.

### Commands
install

Install an object (application template or RPM package) into the Container CT ID|CT NAME. Multiple objects can be specified at once. If an application template is not installed on the Node, it will be downloaded from the vzup2date repository.

update

Update an object in the Container CT ID|CT NAME if a newer version is available. If an application template is not installed on the Node, it will be downloaded from the vzup2date repository. If no object is specified, update all installed packages. If the -t|--template option is specified, update all installed templates.

remove

Remove an object from the Container CT ID|CT NAME.

localinstall

Install a local RPM file into the Container CT ID|CT NAME.

localupdate

Update the Container CT ID|CT NAME from the specified local RPM file.

list

List the objects installed on the Node in the following format:

OS template [application template] [last update date and time]

If CT ID|CT NAME is specified, list the objects installed in the Container. If ostemplate is specified, list the objects available for this OS template. Otherwise, list the objects available for all OS templates. If --available is specified list templates available for installation.

create cache

Create a cache of the OS template ostemplate. The command returns an error if the cache already exists. If the specified OS template is not installed on the Node, it will be downloaded from the vzup2date repository. You can specify several OS templates at once. If no OS templates are specified, all uncached OS templates on the Node will be cached.

update cache

Update the cache of the OS template ostemplate if newer packages are available or create a cache if it does not exist. If the specified OS template is not installed on the Node, it will be downloaded from the vzup2date repository. You can specify multiple OS templates at once. If no OS templates are specified, all available OS templates will be updated/cached.

remove cache

Remove the cache of the OS template ostemplate. You can specify multiple OS templates at once. If no OS templates are specified, all OS template caches will be removed from the Node.

create appcache

Create the cache for OS template with application templates. Returns error if cache already exists. If the specified OS template is not installed on the Node, it will be downloaded from the vzup2date repository.

create image <ostemplate> <path>

Create a ploop image from the OS template ostemplate at path. If the specified OS template is not installed on the Node, it will be downloaded from the vzup2date repository.

update appcache

Update the cache for OS template with application templates. If the specified OS template is not installed on the Node, it will be downloaded from the vzup2date repository.

remove appcache

Remove the cache for OS template with application templates.

list appcache

List all caches for OS templates with application templates.

info

Show the information about the specified OS template, application template, package, or Container CT ID|CT NAME. To get the information about an application template or a package, specify the corresponding Container ID or OS template (using the -F|--for-os option).

install template

Install an application and/or OS template from the specified RPM package or from the vzup2date repository. To install from the repository, specify the template name instead of the name of the respective RPM package. To install an application template from the vzup2date repository, indicate the corresponding OS template using the -F|--for-os option. You can specify multiple objects (RPM packages or application templates) at once.

update template

Update an application and/or OS template from the specified RPM package or from the vzup2date repository. To update from the repository, specify the template name instead of the name of the respective RPM package. To update an application template from the vzup2date repository, indicate the corresponding OS template using the -F|--for-os option. You can specify multiple objects (RPM packages or application templates) at once.

remove template

Remove an application or OS template from the specified Container. To remove an application template, specify the corresponding OS template using the -F|--for-os option.

upgrade

Upgrade the Container CT ID|CT NAME to use another OS template. Upgrade is possible only within the same distribution and architecture. For example, you can upgrade the Container to use fedora-core-5-x86 instead of fedora-core-4-x86. All installed application templates are upgraded automatically.

fetch

Download and prepare packages of the specified OS and related application templates for installation on the Node.

update metadata

Update the metadata of the specified OS template. You should run this command with the -r|--remote option once you change the template's repositories/mirrorlist file.

link

Link the files installed inside a Container to the package set in the corresponding EZ OS template area. vzpkg searches the Container private area for the files similar to the ones from the template area. Once it finds one or more files, it replaces them with symlinks to the template area.

clean

Clean repository metadata for the specified OS and related application templates.

status

Report whether the Container is up to date or not. If any updates are available, the command exits with code 2; otherwise, it exits with code 0.

help

Display the usage information and exit.

## OPTIONS
-p, --packages

Interpret objects as package names instead of template names by default.

-g, --groups

Interpret objects as yum group names (instead of template names by default). This option is available only for RPM-based templates and Containers. You can use this option with install, update, remove, list, and info commands.

-d, --debug <num>

Set the debug level to <num> [0-5].

-C, --cache

Look for the packages in the local cache, do not try to get new packages over the network. If some packages are not available locally, vzpkg will fail.

-r, --remote

Force to look for the updated metadata in remote repositories.

-n, --check-only

Perform a test run.

-w, --with-depends

Remove the specified package and all dependent packages.

-O, --os

Execute the command for OS templates only.

-F, --for-os ostemplate|CT ID|CT NAME

Apply actions to the specified OS template only. When running the info command, you can also indicate a Container ID.

-A, --app

Execute the command for application templates only.

-c, --cached

Show cached OS templates only.

--config <config>

Use the specified sample configuration file for caching OS EZ templates with preinstalled applications.

--ostemplate <ostemplate>

Use the specified OS EZ template instead of that provided in the sample configuration file.

--apptemplate <apptemplate,apptemplate...>

Use the specified application EZ templates instead of those provided in the sample configuration file.

-i, --pkgid

Print a system-wide unique template ID instead of a template name.

-S, --with-summary

Show the list of objects with summary.

-f, --force

Force the operation on the specified template or package.

-e, --expanded

Use the 'upgrade' mode of the update command: upgrade for yum and dist-upgrade for apt-get. It may be useful when upgrading to a new major application version.

-s, --slow

Check all installed packages including those that are already virtualized (for the link command only).

-I, --interactive

Use the interactive mode of Debian package management.

-q, --quiet

Quiet mode.

-s, --force-shared

Force the operation for the template area on shared partitions.

-k, --clean-packages

Clean the local packages cache (for the clean command only).

-t, --template, --clean-template (deprecated)

Remove unused packages from the template area (for the clean command only). Update all templates installed in the Container (for the update command only).

-a, --clean-all

Clean the local packages cache and template area (for the clean command only).

-u, --custom-pkg

Report the list of packages that are installed in the Container but are not available in the template repositories (for the list command only).

-P, --separate

Execute the transaction separately for each template.

--update-cache

Update packages in the existing OS template cache instead of recreating the cache.

--vefstype <VEFSTYPE>

Redefine the VEFSTYPE parameter in the vz global configuration file.

## DIAGNOSTICS
vzpkg returns 0 upon successful execution. If something goes wrong, it returns an appropriate error code.

### System errors
1

System error

2

Internal error

3

Command execution error

4

Memory allocation error

5

vzctl binary was not found

6

File already exists

7

OpenVZ license is not loaded, or an invalid class ID is set.

8

Running command exits with non-null code

9

File or directory was not found

10

Program runs from a non-root user

11

Cannot calculate md5sum

12

Object exists, but it is not a directory

13

Broken magic symlink was found

14

Cannot parse string

52

Cannot fetch file

54

Cannot get OpenVZ service status

55

OpenVZ service is not running

56

Invalid URL

61

Cannot get list of existing Containers

62

vzctl library error

63

External program failed

64

External program was terminated by signal

67

Template metadata was not found. If you use the -C/--cache option with the status command, run the command without this option.

21

Cannot lock Container or OS template

69

Cannot unlock Container or OS template

70

Package manager failed

72

ploop library error

### Container errors
15

Container is not running

16

Container does not exist

17

Container is suspended

18

Container is not mounted

66

Container is not suspended

19

Container has invalid status

20

Cannot lock free temporary Container for caching

22

Container or OS template cache is not up to date

### Template errors
23

Template is not cached

24

Template was not found

25

Broken/invalid template

26

This template is not installed in the Container

27

This template is already installed in the Container

28

This template is not available on the Node

29

Template cache already exists

30

Configuration file for the template cache was not found

31

init executable for creating cache was not found

32

Base OS template has extra O templates

65

Base OS template has application templates

33

This RPM is not EZ template

34

This RPM is not standard template

57

Unknown OS template architecture

58

Unsupported OS template architecture

68

Template area resides on shared partition

73

Attempt to start an operation with packages on a template without package management support

### Argument errors
35

Bad argument

36

LOCKDIR variable is not defined in global configuration file

37

TEMPLATE variable is not defined in global configuration file

38

VE_ROOT variable is not defined in global and Container configuration files

39

VE_PRIVATE variable is not defined in global and Container configuration files

40

OSTEMPLATE variable is not defined in Container configuration file

41

Cannot change the value of $VEID variable to the value in VE_ROOT or VE_PRIVATE

42

Cannot get VEFORMAT from Container private area VERSION link

43

This VEFORMAT is not supported by kernel

44

Unknown VEFORMAT in VERSION link in Container private area

45

Unknown package management name

46

Bad Container name

47

Unknown technologies

48

Unsupported technologies

49

Cannot find environment directory

50

Broken environment directory

51

Cannot find temporary directory

59

Cannot get Container layout version

60

Unknown Container layout

## ENVIRONMENT VARIABLES
vzpkg uses http_proxy, ftp_proxy, or https_proxy environment variable.

## EXAMPLES
To install the OS template fedora-core-12-x86 from the vzup2date repository:

vzpkg install template fedora-core-12-x86

To create a cache of the OS template fedora-core-12-x86_64:

vzpkg create cache fedora-core-12-x86_64

To create a Container on the basis of the fedora-core-12-x86 OS template and start this Container:

vzctl create 1000 --ostemplate fedora-core-12-x86

vzctl start 1000

To install mysql and php application EZ templates into Container 1000:

vzpkg install 1000 mysql php

To update the OS template and all related application EZ templates in Container 1000 from the local yum cache:

vzpkg update -C 1000

To install emacs packages into Container 1000:

vzpkg install -p 1000 emacs

To show yum groups for centos-5-x86 OS template:

vzpkg list -g centos-5-x86

To install Administration Tools yum group into Container 1000:

vzpkg install -g 1000 "Administration Tools"

To get the list of packages for the fedora-core-12-x86 OS and mysql application EZ templates:

vzpkg info fedora-core-12-x86 packages

vzpkg info -F fedora-core-12-x86 mysql packages

To get the status of Container 1000:

vzpkg status -q 1000

To upgrade Container 1000 based on fedora-core-11-x86 to use fedora-core-12-x86:

vzpkg upgrade 1000

To download and prepare all packages for the fedora-core-12-x86 OS template and related application templates:

vzpkg fetch fedora-core-12-x86

To remove the OS template fedora-core-12-x86 from the Node:

vzpkg remove template fedora-core-12-x86

## FILES
/etc/vz/vz.conf,

/etc/vztt/vztt.conf,

/etc/vztt/url.map,

/var/log/vztt.log.

## SEE ALSO
vzctl(8), vzup2date(8), vzup2date.conf(5), vzmktmpl(8).

## COPYRIGHT
Copyright (c) 2001-2017, Parallels International GmbH. All rights reserved. Copyright (c) 2017-2019 Virtuozzo International GmbH. All rights reserved.


wakefix

package: wakefix

title: wakefix(8)

text:
# wakefix(8)

## NAME
wakefix - is a tool to read and modify (fix) the ACPI wakeup event table (/proc/acpi/wakeup). It is intended to be installed as a system startup service to make such modifications at boot.

## SYNOPSIS
wakefix [options]

## DESCRIPTION
wakefix is a tool to read and modify (fix) the ACPI wakeup event table (/proc/acpi/wakeup). It is intended to be installed as a system startup service to make such modifications at boot.

wakefix uses /etc/sysconfig/wakefix.conf configuration file.

## OPTIONS
-l, --list

print out the contents of the kernel ACPI wakeup table (the default action);

-e NAMEs, --enable=NAMEs

enable wakeup by events from devices which name contains one of the listed NAMEs;

-d NAMEs, --disable=NAMEs disable wakeup by events from devices

which name contains one of the listed NAMEs;

-f, --fix

make modifications in accordance with the configuration file /etc/sysconfig/wakefix.conf;

-n,--dry-run

just print out which devices would be enabled or disabled without actual state changes;

-v,--verbose

print information about the actual changes;

-V,--version

print program version and exit;

-h,--help

show this text and exit.

With no options given wakefix prints out the contents of the kernel ACPI wakeup table (as with -l).

## ENVIRONMENT
WAKEFIX_CONFIG

If the WAKEFIX_CONFIG environment variable is set then it specifies a path to the configuration file instead of the default /etc/sysconfig/wakefix.conf.

## AUTHOR
Written by Paul Wolneykien <manowar@altlinux.org>

## REPORTING BUGS
Report bugs to http://bugs.altlinux.ru/

## COPYRIGHT
Copyright © 2019 Paul Wolneykien <manowar@altlinux.org>

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

## SEE ALSO
acpi(1).


watchdog

package: watchdog

title: watchdog(8)

summary: a software watchdog daemon

text:
# watchdog(8)

## NAME
watchdog - a software watchdog daemon

## SYNOPSIS
watchdog [-F|--foreground] [-f|--force] [-c filename|--config-file filename] [-v|--verbose] [-s|--sync] [-b|--softboot] [-q|--no-action]

## DESCRIPTION
The Linux kernel can reset the system if serious problems are detected. This can be implemented via special watchdog hardware, or via a slightly less reliable software-only watchdog inside the kernel. Either way, there needs to be a daemon that tells the kernel the system is working fine. If the daemon stops doing that, the system is reset.

watchdog is such a daemon. It opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. Each write delays the reboot time another minute. After a minute of inactivity the watchdog hardware will cause the reset. In the case of the software watchdog the ability to reboot will depend on the state of the machines and interrupts.

The watchdog daemon can be stopped without causing a reboot if the device /dev/watchdog is closed correctly, unless your kernel is compiled with the CONFIG_WATCHDOG_NOWAYOUT option enabled.

## TESTS
The watchdog daemon does several tests to check the system status:

- Is the process table full?

- Is there enough free memory?

- Is there enough allocatable memory?

- Are some files accessible?

- Have some files changed within a given interval?

- Is the average work load too high?

- Has a file table overflow occurred?

- Is a process still running? The process is specified by a pid file.

- Do some IP addresses answer to ping?

- Do network interfaces receive traffic?

- Is the temperature too high? (Temperature data not always available.)

- Execute a user defined command to do arbitrary tests.

- Execute one or more test/repair commands found in /etc/watchdog.d. These commands are called with the argument test or repair.

If any of these checks fail watchdog will cause a shutdown. Should any of these tests except the user defined binary last longer than one minute the machine will be rebooted, too.

## OPTIONS
Available command line options are the following:

-v, --verbose

Set verbose mode. Only implemented if compiled with SYSLOG feature. This mode will log each several infos in LOG_DAEMON with priority LOG_DEBUG. This is useful if you want to see exactly what happened until the watchdog rebooted the system. Currently it logs the temperature (if available), the load average, the change date of the files it checks and how often it went to sleep. You can use this twice to enable some more verbose debug message for testing.

-s, --sync

Try to synchronize the filesystem every time the process is awake. Note that the system is rebooted if for any reason the synchronizing lasts longer than a minute.

-b, --softboot

Soft-boot the system if an error occurs during the main loop, e.g. if a given file is not accessible via the stat(2) call. Note that this does not apply to the opening of /dev/watchdog and /proc/loadavg, which are opened before the main loop starts. Now this is implemented by disabling the error re-try timer.

-F, --foreground

Run in foreground mode, useful for running under systemd (for example).

-f, --force

Force the usage of the interval given or the maximal load average given in the config file. Without this option these values are sanity checked.

-c config-file, --config-file config-file

Use config-file as the configuration file instead of the default /etc/watchdog.conf.

-q, --no-action

Do not reboot or halt the machine. This is for testing purposes. All checks are executed and the results are logged as usual, but no action is taken. Also your hardware card or the kernel software watchdog driver is not enabled. NOTE: This still allows 'repair' actions to run, but the daemon itself will not attempt a reboot.

-X num, --loop-exit num

Run for 'num' loops then exit as if SIGTERM was received. Intended for test/debug (e.g. using valgrind for checking memory access). If the daemon exits on a loop counter and you have the CONFIG_WATCHDOG_NOWAYOUT option compiled for the kernel or device-driver then an unplanned reboot will follow - be warned!

## FUNCTION
After watchdog starts, it puts itself into the background and then tries all checks specified in its configuration file in turn. Between each two tests it will write to the kernel device to prevent a reset. After finishing all tests watchdog goes to sleep for some time. The kernel drivers expects a write to the watchdog device every minute. Otherwise the system will be reset. watchdog will sleep for a configure interval that defaults to 1 second to make sure it triggers the device early enough.

Under high system load watchdog might be swapped out of memory and may fail to make it back in in time. Under these circumstances the Linux kernel will reset the machine. To make sure you won't get unnecessary reboots make sure you have the variable realtime set to yes in the configuration file watchdog.conf. This adds real time support to watchdog: it will lock itself into memory and there should be no problem even under the highest of loads.

On system running out of memory the kernel will try to free enough memory by killing process. The watchdog daemon itself is exempted from this so-called out-of-memory killer.

Also you can specify a maximal allowed load average. Once this load average is reached the system is rebooted. You may specify maximal load averages for 1 minute, 5 minutes or 15 minutes. The default values is to disable this test. Be careful not to set this parameter too low. To set a value less then the predefined minimal value of 2, you have to use the -f option.

You can also specify a minimal amount of virtual memory you want to have available as free. As soon as more virtual memory is used action is taken by watchdog. Note, however, that watchdog does not distinguish between different types of memory usage. It just checks for free virtual memory.

If you have a machine with temperature sensor(s) you can specify the maximal allowed temperature. Once this temperature is reached on any sensor the system is powered off. The default value is 90 C. Typically the temperature information is provided by the sensors package as files in the virtual filesystem /sys/device and can be found using, for example, the command

find /sys -name 'temp*input' -print

These files hold the temperature in milli-Celsius. You can have multiple sensors used in the config file. For example to change to 75C maximum and to check two virtual files for the system temperature you might have this:

max-temperature = 75

temperature-sensor = /sys/class/hwmon/hwmon0/device/temp1_input

temperature-sensor = /sys/class/hwmon/hwmon0/device/temp2_input

The watchdog will issue warnings once the temperature increases 90%, 95% and 98% of the configured maximum temperature.

When using file mode watchdog will try to stat(2) the given files. Errors returned by stat will not cause a reboot. For a reboot the stat call has to last at least the re-try time-out value (default 1 minute). This may happen if the file is located on an NFS mounted filesystem. If your system relies on an NFS mounted filesystem you might try this option. However, in such a case the sync option may not work if the NFS server is not answering.

watchdog can read the pid from a pid file and see whether the process still exists. If not, action is taken by watchdog. So you can for instance restart the server from your repair-binary.

watchdog will try periodically to fork itself to see whether the process table is full. This process will leave a zombie process until watchdog wakes up again and catches it; this is harmless, don't worry about it.

In ping mode watchdog tries to ping the given IPv4 addresses. These addresses do not have to be a single machine. It is possible to ping to a broadcast address instead to see if at least one machine in a subnet is still living.

Do not use this broadcast ping unless your MIS person a) knows about it and b) has given you explicit permission to use it!

watchdog will send out three ping packages and wait up to <interval> seconds for the reply with <interval> being the time it goes to sleep between two times triggering the watchdog device. Thus a unreachable network will not cause a hard reset but a soft reboot.

You can also test passively for an unreachable network by just monitoring a given interface for traffic. If no traffic arrives the network is considered unreachable causing a soft reboot or action from the repair binary.

watchdog can run an external command for user-defined tests. A return code not equal 0 means an error occurred and watchdog should react. If the external command is killed by an uncaught signal this is considered an error by watchdog too. The command may take longer than the time slice defined for the kernel device without a problem. However, error messages are generated into the syslog facility. If you have enabled softboot on error the machine will be rebooted if the binary doesn't exit in half the time watchdog sleeps between two tries triggering the kernel device.

If you specify a repair binary it will be started instead of shutting down the system. If this binary is not able to fix the problem watchdog will still cause a reboot afterwards.

If the machine is halted an email is sent to notify a human that the machine is going down. Starting with version 4.4 watchdog will also notify the human in charge if the machine is rebooted.

The re-try timer applies to most errors, except reset/reboot calls and too hot. It allows a given error source to recover, and treats most tests in this way. Exceptions are file handle test, load averages, and system memory. If set to the minimum time of 1 second it will still allow a single re-try at any polling interval of the system.

## SOFT REBOOT
A soft reboot (i.e. controlled shutdown and reboot) is initiated for every error that is found. Since there might be no more processes available, watchdog does it all by himself. That means:

1.

Kill all processes with SIGTERM.

2.

After a short pause kill all remaining processes with SIGKILL.

3.

Record a shutdown entry in wtmp.

4.

Save the random seed from /dev/urandom. If the device is non-existant or there is no filename for saving this step is skipped.

5.

Turn off accounting.

6.

Turn off quota and swap.

7.

Unmount all partitions

8.

Finally reboot.

## CHECK BINARY
If the return code of the check binary is not zero watchdog will assume an error and reboot the system. Be careful with this if you are using the real-time properties of watchdog since watchdog will wait for the return of this binary before proceeding. An exit code smaller than 245 is interpreted as an system error code (see errno.h for details). Values of 245 or larger than are special to watchdog:

255

(based on -1 as unsigned 8-bit number) Reboot the system. This is not exactly an error message but a command to watchdog. If the return code is this the watchdog will not try to run a shutdown script instead.

254

Reset the system. This is not exactly an error message but a command to watchdog. If the return code is this the watchdog will attempt to hard-reset the machine without attempting any sort of orderly stopping of process, unmounting of file systems, etc.

253

Maximum load average exceeded.

252

The temperature inside is too high.

251

/proc/loadavg contains no (or not enough) data.

250

The given file was not changed in the given interval.

249

/proc/meminfo contains invalid data.

248

Child process was killed by a signal.

247

Child process did not return in time.

246

Free for personal watchdog-specific use (was -10 as an unsigned 8-bit number).

245

Reserved for an unknown result, for example a slow background test that is still running so neither a success nor an error.

## REPAIR BINARY
The repair binary is started with one parameter: the error number that caused watchdog to initiate the boot process. After trying to repair the system the binary should exit with 0 if the system was successfully repaired and thus there is no need to boot anymore. A return value not equal 0 tells watchdog to reboot. The return code of the repair binary should be the error number of the error causing watchdog to reboot. Be careful with this if you are using the real-time properties since watchdog will wait for the return of this binary before proceeding.

The configuration file parameter repair-maximum controls the number of successive repair attempts that report 0 (i.e. success) but fail to clear the tested fault. If this is exceeded then a reboot takes place. If set to zero then a reboot can always be blocked by the repair program reporting success.

## TEST DIRECTORY
Executables placed in the test directory are discovered by watchdog on startup and are automatically executed. They are bounded time-wise by the test-timeout directive in watchdog.conf.

These executables are called with either "test" as the first argument (if a test is being performed) or "repair" as the first argument (if a repair for a previously-failed "test" operation on is being performed).

As with test binaries and repair binaries, expected exit codes for a successful test or repair operation is always zero.

If an executable's test operation fails, the same executable is automatically called with the "repair" argument as well as the return code of the previously-failed test operation.

For example, if the following execution returns 42:

/etc/watchdog.d/my-test test

The watchdog daemon will attempt to repair the problem by calling:

/etc/watchdog.d/my-test repair 42

This enables administrators and application developers to make intelligent test/repair commands. If the "repair" operation is not required (or is not likely to succeed), it is important that the author of the command return a non-zero value so the machine will still reboot as expected.

Note that the watchdog daemon may interpret and act upon any of the reserved return codes noted in the Check Binary section prior to calling a given command in "repair" mode.

As for the repair binary, the configuration parameter repair-maximum also controls the number of successive repair attempts that report success (return 0) but fail to clear the fault.

## BUGS
None known so far.

## AUTHORS
The original code is an example written by Alan Cox <alan@lxorguk.ukuu.org.uk>, the author of the kernel driver. All additions were written by Michael Meskes <meskes@debian.org>. Johnie Ingram <johnie@netgod.net> had the idea of testing the load average. He also took over the Debian specific work. Dave Cinege <dcinege@psychosis.com> brought up some hardware watchdog issues and helped testing this stuff.

## FILES
/dev/watchdog

The watchdog device.

/var/run/watchdog.pid

The pid file of the running watchdog.

## SEE ALSO
watchdog.conf(5)


title: wd_identify(8)

summary: get watchdog driver identity

text:
# wd_identify(8)

## NAME
wd_identify - get watchdog driver identity

## SYNOPSIS
wd_identify [-c filename|--config-file filename] [-v|--verbose]

## DESCRIPTION
This utility opens /dev/watchdog and gets the identification string from the watchdog which then is printed. The device is closed afterwards.

An exit code of zero indicates success in getting the driver identity, while a non-zero exit code indicates an error (not configured in the config file, no device driver loaded, or driver failed to respond to ioctl request).

The wd_identify tool can only be used without causing a reboot if your kernel is not compiled with the CONFIG_WATCHDOG_NOWAYOUT option enabled.

Note that the watchdog and/or wd_keepalive daemons may have to be stopped to make sure that wd_identify can access the watchdog device.

## OPTIONS
Available command line options are the following:

-c config-file, --config-file config-file

Use config-file as the configuration file instead of the default /etc/watchdog.conf.

-v, --verbose

Print more diagnostic messages. This covers parsing of the config file and also causes the program to read-back the current watchdog time-out value (if successful in opening the device).

## FILES
/dev/watchdog

The watchdog device.

## SEE ALSO
watchdog.conf(5)

watchdog(8)


title: wd_keepalive(8)

summary: a simplified software watchdog daemon

text:
# wd_keepalive(8)

## NAME
wd_keepalive - a simplified software watchdog daemon

## SYNOPSIS
wd_keepalive [-c filename|--config-file filename]

## DESCRIPTION
This is a simplified version of the watchdog daemon. Unlike the full watchdog, this daemon run no tests and only serves to keep the hardware timer refreshed. Typically this is used on system start-up to provide protection before the services that the full version tests are running, and on shutdown to continue the refresh while those services are stopped.

If configured so it only opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. Each write delays the reboot time another minute. After a minute of inactivity the watchdog hardware will cause a reset. In the case of the software watchdog the ability to reboot will depend on the state of the machines and interrupts.

The wd_keepalive daemon can be stopped without causing a reboot if the device /dev/watchdog is closed correctly, unless your kernel is compiled with the CONFIG_WATCHDOG_NOWAYOUT option enabled.

Under high system load wd_keepalive might be swapped out of memory and may fail to make it back in in time. Under these circumstances the Linux kernel will reset the machine. To make sure you won't get unnecessary reboots make sure you have the variable realtime set to yes in the configuration file watchdog.conf. This adds real time support to wd_keepalive: it will lock itself into memory and there should be no problem even under the highest of loads.

On system running out of memory the kernel will try to free enough memory by killing process. The wd_keepalive daemon itself is exempted from this so-called out-of-memory killer.

## OPTIONS
Available command line options are the following:

-c config-file, --config-file config-file

Use config-file as the configuration file instead of the default /etc/watchdog.conf.

-X num, --loop-exit num

Run for 'num' loops then exit as if SIG_TERM was received. Intended for test/debug (e.g. using valgrind for checking memory access). If the daemon exits on a loop counter and you have the CONFIG_WATCHDOG_NOWAYOUT option compiled for the kernel or device-driver then an unplanned reboot will follow - be warned!

## FILES
/dev/watchdog

The watchdog device.

/var/run/wd_keepalive.pid

The pid file of the running wd_keepalive.

## SEE ALSO
watchdog.conf(5)

watchdog(8)


whoson

package: whoson

title: whoson(8)

summary: whoson test client

text:
# whoson(8)

## NAME
whoson - whoson test client

## SYNOPSYS
whoson {login|logout|query} arguments...

## DESCRIPTION
The whoson command accesses the whoson(8) daemon by calling specfied whoson(3) API function.

## COPYRIGHT
Public domain

## SEE ALSO
whoson(3), whosond(8)


whosond

package: whoson-server

title: whosond(8)

summary: whoson database daemon

text:
# whosond(8)

## NAME
whosond - whoson database daemon

## SYNOPSYS
whosond [-V] [-v] [-h] [-d] [-I configfile]

## DESCRIPTION
whosond command starts the daemon that maintains the in-memory database accessible by the application programs via the whoson(3) API functions.

Command options are:

-V - print version information and exit

-v - verbose operation - print debugging output to stdout. Useful together with -d option.

-d - do not go to the background. By default, the program forks a child that closes stdin, stdout and stderr, detaches from the controlling terminal and continue in the background. The parent process finishes.

-I configfile Specify alternative location for the configuration file. Default is /etc/whoson.conf.

The daemon implements one extentions to the "whoson" protocol: if you send a command verb LIST, the daemon responds with a multiline display of some statistics information.

## COPYRIGHT
Public domain

## SEE ALSO
whoson(3), whoson.conf(5)


wicd

package: wicd-common

title: wicd(8)

text:
# wicd(8)

## NAME
Wicd - Wired and Wireless Network Connection Manager

## THEORY OF OPERATION
Wicd is designed to give the user as much control over behavior of network connections as possible. Every network, both wired and wireless, has its own profile with its own configuration options and connection behavior. Wicd will try to automatically connect only to networks the user specifies it should try, with a preference first to a wired network, then to wireless.

For wired connections, users have many options for determining what network settings to use. Wicd allows creation of an unlimited number of wired profiles, each of which has its own unique settings. The user can choose to automatically connect to a selected default profile, choose a profile from a pop-up window every time wicd connects, or have wicd automatically choose the last profile used to manually connect.

For wireless connections, users can select any number of wireless networks to automatically connect; wicd will choose the one with the highest signal strength to try to connect.

If the user chooses, wicd will try to automatically reconnect when it detects that a connection is lost. If the last known connection state is wired, wicd will first try to reconnect to the wired network, and if it is not available, wicd will try any available wireless networks which have automatic connection enabled. If the last known connection state is wireless, wicd will first try to reconnect to the previously connected network (even if that network does not have automatic connection enabled), and should that fail, it will try both a wired connection and any available wireless networks which have automatic connection enabled.

Wicd uses built-in linux wireless-tools, such as ifconfig and iwconfig, to get and configure network info. There is some flexibility in its use of DHCP, providing support for dhclient, dhcpcd, and pump. Wicd uses wpa_supplicant to handle all wireless encryption settings, and uses a template-based system to create the configuration files used by wpa_supplicant. These templates can be edited, and new templates can be created by the user and imported into wicd, allowing connection to networks with uncommon encryption settings.

## STRUCTURE
Wicd has two major parts: the daemon, which runs with root privileges; and the user interface, which runs with normal user privileges. The two parts run as separate processes and make use of D-Bus to communicate.

The daemon is responsible for making and configuring connections, reading and writing configuration files and logs, and monitoring the connection status. The daemon's job is split between two processes: wicd-daemon.py and monitor.py. All the connection status monitoring, as well as the auto-reconnection logic, takes place in monitor.py. Everything else is done by wicd-daemon.py.

The user interface (stored in wicd-gtk), which is made up of a tray icon, a main GUI window, and its child dialogs, gets configuration and network info from the daemon either by querying it using the methods in the daemon's dbus interface or by receiving signals emitted from the daemon over D-Bus. Any configuration changes made in the user interface are passed back to the daemon, which actually applies the changes and writes them to configuration files.

Since the user interface just queries for connection and configuration info from the daemon, it is possible to run wicd without the GUI at all. Also, the daemon is started by wicd's init script during system startup (before any user logs in), making it possible to use wicd with "headless" machines.

## USAGE HINTS
Choosing Alternate Tools

Wicd supports several alternatives regarding the networking tools on linux. In the "External Programs" tab of the Preferences menu, you can choose your preferred DHCP client, link detection tool, and routing tool if the defaults aren't suitable for your particular distribution or system.

Custom Scripts

If you need to run any custom commands before or after connecting to or disconnecting from a network, Wicd supports this; however, you will need to have a graphical sudo helper installed (currently supported are kdesu, pkexec, and ktsuss). Also see /etc/wicd/scripts/ in FILES.

If you do not have a graphical sudo helper installed, you still have the ability to use custom scripts, but you will have to set them up manually. See wicd-wired-settings.conf(5) and/or wicd-wireless-settings.conf(5) for more information on how to do so.

Automatically Connecting to Networks

Wicd uses the BSSID to recognize a particular network (and thus to decide whether it should automatically connect to it). If you are on a network that has many different access points which all have the same ESSID (many universities have such networks), there is an option in the "Advanced Settings" to "Use these settings for all networks sharing this essid." With this option enabled, Wicd will autoconnect to that network, regardless of which node it sees.

## FILES
/etc/wicd/manager-settings.conf

This file contains global settings for Wicd.

See this file's own man page for more information about it.

/etc/wicd/wired-settings.conf

This file contains settings related to the wired interface.

See this file's own man page for more information about it.

/etc/wicd/wireless-settings.conf

This file contains settings related to the wireless interface.

See this file's own man page for more information about it.

/etc/wicd/dhclient.conf.template

This is used to generate /var/lib/wicd/dhclient.conf during Wicd activity, if you're using dhclient(1) as DHCP client. See dhclient.conf(5) for more information.

/etc/wicd/encryption/templates/

This directory contains various templates for encrypted (WEP, WPA, etcetera) connections. If none of them fit your needs, you may create your own and add it to this directory. If you do this, please contact the authors (see below) of Wicd.

/etc/wicd/scripts/

Dropping a script in the relevant directory will cause it to be executed when the specified event is preformed upon connection or disconnect from or to any network. Please note that pre/post disconnect scripts may be executed multiple times on already-disconnected interfaces.

The scripts will be passed different parameters, depending if Wicd is acting on a wired or a wireless network. In the former case, "wired wired wired" will be passed (three times, just for compatibility with the wireless case). If Wicd is acting on a wireless network, it will pass "wireless ESSID BSSID" to the script.

Available directories are:

/etc/wicd/scripts/predisconnect

/etc/wicd/scripts/postdisconnect

/etc/wicd/scripts/preconnect

/etc/wicd/scripts/postconnect

/var/lib/wicd/configurations/

This directory contains individual configuration files for each encrypted network you set up in Wicd.

/var/log/

This directory contains logfiles of Wicd's activity. Please refer to the log if you are having connection or other problems.

## SEE ALSO
wicd-manager-settings.conf(5), wicd-wired-settings.conf(5), wicd-wireless-settings.conf(5), dhclient.conf(5), wicd-curses(8), ifconfig(8), iwconfig(8), wpa_supplicant(8), route(8), ip(8), mii-tool(8), ethtool(8), dhclient(8), dhcpcd(8), pump(8).

## WICD AUTHORS
Adam Blackburn <compwiz18@gmail.com>

Dan O'Reilly <oreilldf@gmail.com>

Andrew Psaltis <ampsaltis@gmail.com> (curses client)

David Paleino <d.paleino@gmail.com>

## MANPAGE AUTHOR
Robby Workman <rworkman@slackware.com>


wicd-cli

title: wicd-cli(8)

summary: commandline- only wicd(8) controller

text:
# wicd-cli(8)

## NAME
wicd-cli - commandline- only wicd(8) controller

## DESCRIPTION
TODO :-)


wicd-curses

package: wicd-curses

title: wicd-curses(8)

summary: curses-based wicd(8) controller

text:
# wicd-curses(8)

## NAME
wicd-curses - curses-based wicd(8) controller

## DESCRIPTION
wicd-curses is a curses-based network controller that uses the Wired/Wireless Internet Connection Daemon (wicd) to control your network connections. It is suitable to run in terminal multiplexers like screen(1).

It is designed to imitate the GTK-based wicd-client(1) as much as possible, and uses the Urwid (http://excess.org/urwid) console widget library to vastly simplify development.

This man page only documents the current status of wicd-curses. This may/may not be the most up-to-date document.

## CONTROLS
All of these are case sensitive.

C or enter

Connect to selected network

F8 or Q or q

Quit the client.

D

Disconnect all devices from network connections

ESC

If connecting to a network, stop doing so

F5 or R

Refresh the network list

P

Bring up the preferences controller

I

Bring up hidden network scanning dialog

H or h or ?

Bring up a rather simplistic help dialog. Of course, it mentions this man page first. :-)

A

Raise the "About wicd-curses" dialog

right-arrow

Bring up network configuration controller for the selected network

delete

Delete the selected wired network profile (from the wired network combo box at the top)

F2

Rename the selected wired network profile (from the wired network combo box at the top)

S

Bring up instructions on how to edit the scripts. I have implemented a way to do this in the interface itself, but making it function with all Linux distros would be difficult. Since you are reading this, you should know how to do what I suggest. ;-)

O

Raise the Ad-Hoc network creation dialog

X

Show the list of saved wireless networks, to be able to remove them

## SEE ALSO
wicd-client(1), wicd(8)

## BUGS
Probably lots. ;-)

If you happen to find one, ask about it on #wicd on freenode, or submit a bug report to http://launchpad.net/wicd.

## WICD-CURSES AUTHOR
Andrew Psaltis <ampsaltis@gmail.com>

## WICD AUTHORS
Adam Blackburn <compwiz18@gmail.com>

Dan O'Reilly <oreilldf@gmail.com>

David Paleino <d.paleino@gmail.com>


wg

package: wireguard-tools

title: wg(8)

text:
# wg(8)

## NAME
wg - set and retrieve configuration of WireGuard interfaces

## SYNOPSIS
wg [ COMMAND ] [ OPTIONS ]... [ ARGS ]...

## DESCRIPTION
wg is the configuration utility for getting and setting the configuration of WireGuard tunnel interfaces. The interfaces themselves can be added and removed using ip-link(8) and their IP addresses and routing tables can be set using ip-address(8) and ip-route(8). The wg utility provides a series of sub-commands for changing WireGuard-specific aspects of WireGuard interfaces.

If no COMMAND is specified, COMMAND defaults to show. Sub-commands that take an INTERFACE must be passed a WireGuard interface.

## COMMANDS
show { <interface> | all | interfaces } [public-key | private-key | listen-port | fwmark | peers | preshared-keys | endpoints | allowed-ips | latest-handshakes | persistent-keepalive | transfer | dump]

Shows current WireGuard configuration and runtime information of specified <interface>. If no <interface> is specified, <interface> defaults to all. If interfaces is specified, prints a list of all WireGuard interfaces, one per line, and quits. If no options are given after the interface specification, then prints a list of all attributes in a visually pleasing way meant for the terminal. Otherwise, prints specified information grouped by newlines and tabs, meant to be used in scripts. For this script-friendly display, if all is specified, then the first field for all categories of information is the interface name. If dump is specified, then several lines are printed; the first contains in order separated by tab: private-key, public-key, listen-port, fwmark. Subsequent lines are printed for each peer and contain in order separated by tab: public-key, preshared-key, endpoint, allowed-ips, latest-handshake, transfer-rx, transfer-tx, persistent-keepalive.

showconf <interface>

Shows the current configuration of <interface> in the format described by CONFIGURATION FILE FORMAT below.

set <interface> [listen-port <port>] [fwmark <fwmark>] [private-key <file-path>] [peer <base64-public-key> [remove] [preshared-key <file-path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...

Sets configuration values for the specified <interface>. Multiple peers may be specified, and if the remove argument is given for a peer, that peer is removed, not configured. If listen-port is not specified, or set to 0, the port will be chosen randomly when the interface comes up. Both private-key and preshared-key must be files, because command line arguments are not considered private on most systems but if you are using bash(1), you may safely pass in a string by specifying as private-key or preshared-key the expression: <(echo PRIVATEKEYSTRING). If /dev/null or another empty file is specified as the filename for either private-key or preshared-key, the key is removed from the device. The use of preshared-key is optional, and may be omitted; it adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance. If allowed-ips is specified, but the value is the empty string, all allowed ips are removed from the peer. The use of persistent-keepalive is optional and is by default off; setting it to 0 or "off" disables it. Otherwise it represents, in seconds, between 1 and 65535 inclusive, how often to send an authenticated empty packet to the peer, for the purpose of keeping a stateful firewall or NAT mapping valid persistently. For example, if the interface very rarely sends traffic, but it might at anytime receive traffic from a peer, and it is behind NAT, the interface might benefit from having a persistent keepalive interval of 25 seconds; however, most users will not need this. The use of fwmark is optional and is by default off; setting it to 0 or "off" disables it. Otherwise it is a 32-bit fwmark for outgoing packets and may be specified in hexadecimal by prepending "0x".

setconf <interface> <configuration-filename>

Sets the current configuration of <interface> to the contents of <configuration-filename>, which must be in the format described by CONFIGURATION FILE FORMAT below.

addconf <interface> <configuration-filename>

Appends the contents of <configuration-filename>, which must be in the format described by CONFIGURATION FILE FORMAT below, to the current configuration of <interface>.

syncconf <interface> <configuration-filename>

Like setconf, but reads back the existing configuration first and only makes changes that are explicitly different between the configuration file and the interface. This is much less efficient than setconf, but has the benefit of not disrupting current peer sessions. The contents of <configuration-filename> must be in the format described by CONFIGURATION FILE FORMAT below.

genkey

Generates a random private key in base64 and prints it to standard output.

genpsk

Generates a random preshared key in base64 and prints it to standard output.

pubkey

Calculates a public key and prints it in base64 to standard output from a corresponding private key (generated with genkey) given in base64 on standard input. A private key and a corresponding public key may be generated at once by calling:

$ umask 077

$ wg genkey | tee private.key | wg pubkey > public.key

help

Shows usage message.

## CONFIGURATION FILE FORMAT
The configuration file format is based on INI. There are two top level sections -- Interface and Peer. Multiple Peer sections may be specified, but only one Interface section may be specified.

The Interface section may contain the following fields:

- PrivateKey — a base64 private key generated by wg genkey. Required.

- ListenPort — a 16-bit port for listening. Optional; if not specified, chosen randomly.

- FwMark — a 32-bit fwmark for outgoing packets. If set to 0 or "off", this option is disabled. May be specified in hexadecimal by prepending "0x". Optional.

The Peer sections may contain the following fields:

- PublicKey — a base64 public key calculated by wg pubkey from a private key, and usually transmitted out of band to the author of the configuration file. Required.

- PresharedKey — a base64 preshared key generated by wg genpsk. Optional, and may be omitted. This option adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance.

- AllowedIPs — a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed. The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0 may be specified for matching all IPv6 addresses. May be specified multiple times.

- Endpoint — an endpoint IP or hostname, followed by a colon, and then a port number. This endpoint will be updated automatically to the most recent source IP address and port of correctly authenticated packets from the peer. Optional.

- PersistentKeepalive — a seconds interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently. For example, if the interface very rarely sends traffic, but it might at anytime receive traffic from a peer, and it is behind NAT, the interface might benefit from having a persistent keepalive interval of 25 seconds. If set to 0 or "off", this option is disabled. By default or when unspecified, this option is off. Most users will not need this. Optional.

## CONFIGURATION FILE FORMAT EXAMPLE
This example may be used as a model for writing configuration files, following an INI-like syntax. Characters after and including a '#' are considered comments and are thus ignored.

[Interface]

PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

Endpoint = 192.95.5.67:1234

AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]

PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=

Endpoint = [2607:5300:60:6b0::c05f:543]:2468

AllowedIPs = 10.192.122.4/32, 192.168.0.0/16

[Peer]

PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=

Endpoint = test.wireguard.com:18981

AllowedIPs = 10.10.10.230/32

## DEBUGGING INFORMATION
Sometimes it is useful to have information on the current runtime state of a tunnel. When using the Linux kernel module on a kernel that supports dynamic debugging, debugging information can be written into dmesg(1) by running as root:

\# modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

On OpenBSD and FreeBSD, debugging information can be written into dmesg(1) on a per-interface basis by using ifconfig(1):

\# ifconfig wg0 debug

On userspace implementations, it is customary to set the LOG_LEVEL environment variable to verbose.

## ENVIRONMENT VARIABLES
WG_COLOR_MODE

If set to always, always print ANSI colorized output. If set to never, never print ANSI colorized output. If set to auto, something invalid, or unset, then print ANSI colorized output only when writing to a TTY.

WG_HIDE_KEYS

If set to never, then the pretty-printing show sub-command will show private and preshared keys in the output. If set to always, something invalid, or unset, then private and preshared keys will be printed as "(hidden)".

WG_ENDPOINT_RESOLUTION_RETRIES

If set to an integer or to infinity, DNS resolution for each peer's endpoint will be retried that many times for non-permanent errors, with an increasing delay between retries. If unset, the default is 15 retries.

## SEE ALSO
wg-quick(8), ip(8), ip-link(8), ip-address(8), ip-route(8).

## AUTHOR
wg was written by Jason A. Donenfeld. For updates and more information, a project page is available on the World Wide Web.


wg-quick

package: wireguard-tools-wg-quick

title: wg-quick(8)

text:
# wg-quick(8)

## NAME
wg-quick - set up a WireGuard interface simply

## SYNOPSIS
wg-quick [ up | down | save | strip ] [ CONFIG_FILE | INTERFACE ]

## DESCRIPTION
This is an extremely simple script for easily bringing up a WireGuard interface, suitable for a few common use cases.

Use up to add and set up an interface, and use down to tear down and remove an interface. Running up adds a WireGuard interface, brings up the interface with the supplied IP addresses, sets up mtu and routes, and optionally runs pre/post up scripts. Running down optionally saves the current configuration, removes the WireGuard interface, and optionally runs pre/post down scripts. Running save saves the configuration of an existing interface without bringing the interface down. Use strip to output a configuration file with all wg-quick(8)-specific options removed, suitable for use with wg(8).

CONFIG_FILE is a configuration file, whose filename is the interface name followed by `.conf'. Otherwise, INTERFACE is an interface name, with configuration found at `/etc/wireguard/INTERFACE.conf', searched first, followed by distro-specific search paths.

Generally speaking, this utility is just a simple script that wraps invocations to wg(8) and ip(8) in order to set up a WireGuard interface. It is designed for users with simple needs, and users with more advanced needs are highly encouraged to use a more specific tool, a more complete network manager, or otherwise just use wg(8) and ip(8), as usual.

## CONFIGURATION
The configuration file adds a few extra configuration values to the format understood by wg(8) in order to configure additional attributes of an interface. It handles the values that it understands, and then it passes the remaining ones directly to wg(8) for further processing.

It infers all routes from the list of peers' allowed IPs, and automatically adds them to the system routing table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle overriding of the default gateway.

The configuration file will be passed directly to wg(8)'s `setconf' sub-command, with the exception of the following additions to the Interface section, which are handled by this tool:

- Address — a comma-separated list of IP (v4 or v6) addresses (optionally with CIDR masks) to be assigned to the interface. May be specified multiple times.

- DNS — a comma-separated list of IP (v4 or v6) addresses to be set as the interface's DNS servers, or non-IP hostnames to be set as the interface's DNS search domains. May be specified multiple times. Upon bringing the interface up, this runs `resolvconf -a tun.INTERFACE -m 0 -x` and upon bringing it down, this runs `resolvconf -d tun.INTERFACE`. If these particular invocations of resolvconf(8) are undesirable, the PostUp and PostDown keys below may be used instead.

- MTU — if not specified, the MTU is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice. However, to manually specify an MTU to override this automatic discovery, this value may be specified explicitly.

- Table — Controls the routing table to which routes are added. There are two special values: `off' disables the creation of routes altogether, and `auto' (the default) adds routes to the default table and enables special handling of default routes.

- PreUp, PostUp, PreDown, PostDown — script snippets which will be executed by bash(1) before/after setting up/tearing down the interface, most commonly used to configure custom DNS options or firewall rules. The special string `%i' is expanded to INTERFACE. Each one may be specified multiple times, in which case the commands are executed in order.

- SaveConfig — if set to `true', the configuration is saved from the current state of the interface upon shutdown. Any changes made to the configuration file before the interface is removed will therefore be overwritten.

Recommended INTERFACE names include `wg0' or `wgvpn0' or even `wgmgmtlan0'. However, the number at the end is in fact optional, and really any free-form string [a-zA-Z0-9_=+.-]{1,15} will work. So even interface names corresponding to geographic locations would suffice, such as `cincinnati', `nyc', or `paris', if that's somehow desirable.

## EXAMPLES
These examples draw on the same syntax found for wg(8), and a more complete description may be found there. Bold lines below are for options that extend wg(8).

The following might be used for connecting as a client to a VPN gateway for tunneling all traffic:

[Interface]

Address = 10.200.100.8/24

DNS = 10.200.100.1

PrivateKey = oK56DE9Ue9zK76rAc8pBl6opph+1v36lm7cXXsQKrQM=

[Peer]

PublicKey = GtL7fZc/bLnqZldpVofMCD6hDjrK28SsdLxevJ+qtKU=

PresharedKey = /UwcSPg38hW/D9Y3tcS1FOV0K1wuURMbS0sesJEP5ak=

AllowedIPs = 0.0.0.0/0

Endpoint = demo.wireguard.com:51820

The `Address` field is added here in order to set up the address for the interface. The `DNS` field indicates that a DNS server for the interface should be configured via resolvconf(8). The peer's allowed IPs entry implies that this interface should be configured as the default gateway, which this script does.

Building on the last example, one might attempt the so-called ``kill-switch'', in order to prevent the flow of unencrypted packets through the non-WireGuard interfaces, by adding the following two lines `PostUp` and `PreDown` lines to the `[Interface]` section:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

The `PostUp' and `PreDown' fields have been added to specify an iptables(8) command which, when used with interfaces that have a peer that specifies 0.0.0.0/0 as part of the `AllowedIPs', works together with wg-quick's fwmark usage in order to drop all packets that are either not coming out of the tunnel encrypted or not going through the tunnel itself. (Note that this continues to allow most DHCP traffic through, since most DHCP clients make use of PF_PACKET sockets, which bypass Netfilter.) When IPv6 is in use, additional similar lines could be added using ip6tables(8).

Or, perhaps it is desirable to store private keys in encrypted form, such as through use of pass(1):

PostUp = wg set %i private-key <(pass WireGuard/private-keys/%i)

For use on a server, the following is a more complicated example involving multiple peers:

[Interface]

Address = 10.192.122.1/24

Address = 10.10.0.1/16

SaveConfig = true

PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]

PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=

AllowedIPs = 10.192.122.4/32, 192.168.0.0/16

[Peer]

PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=

AllowedIPs = 10.10.10.230/32

Notice the two `Address' lines at the top, and that `SaveConfig' is set to `true', indicating that the configuration file should be saved on shutdown using the current status of the interface.

A combination of the `Table', `PostUp', and `PreDown' fields may be used for policy routing as well. For example, the following may be used to send SSH traffic (TCP port 22) traffic through the tunnel:

[Interface]

Address = 10.192.122.1/24

PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

Table = 1234

PostUp = ip rule add ipproto tcp dport 22 table 1234

PreDown = ip rule delete ipproto tcp dport 22 table 1234

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

AllowedIPs = 0.0.0.0/0

These configuration files may be placed in any directory, putting the desired interface name in the filename:

\# wg-quick up /path/to/wgnet0.conf

For convenience, if only an interface name is supplied, it automatically chooses a path in `/etc/wireguard/':

\# wg-quick up wgnet0

This will load the configuration file `/etc/wireguard/wgnet0.conf'.

The strip command is useful for reloading configuration files without disrupting active sessions:

\# wg syncconf wgnet0 <(wg-quick strip wgnet0)

## SEE ALSO
wg(8), ip(8), ip-link(8), ip-address(8), ip-route(8), ip-rule(8), resolvconf(8).

## AUTHOR
wg-quick was written by Jason A. Donenfeld. For updates and more information, a project page is available on the World Wide Web.