pipewire.conf

title: pipewire.conf(5)

summary: pipewire.conf

text:
# pipewire.conf(5)

## NAME
pipewire.conf - pipewire.conf

## DESCRIPTION
The PipeWire server configuration file

## SYNOPSIS
$XDG_CONFIG_HOME/pipewire/pipewire.conf

/etc/pipewire/pipewire.conf

/usr/share/pipewire/pipewire.conf

/usr/share/pipewire/pipewire.conf.d/

/etc/pipewire/pipewire.conf.d/

$XDG_CONFIG_HOME/pipewire/pipewire.conf.d/

## DESCRIPTION
PipeWire is a service that facilitates sharing of multimedia content between devices and applications.

On startup, the daemon reads a main configuration file to configure itself. It executes a series of commands listed in the config file.

The config file is looked up in the order listed in the SYNOPSIS. The environment variables PIPEWIRE_CONFIG_DIR, PIPEWIRE_CONFIG_PREFIX and PIPEWIRE_CONFIG_NAME can be used to specify an alternative config directory, subdirectory and file respectively.

Other PipeWire configuration files generally follow the same lookup logic, replacing pipewire.conf with the name of the particular config file.

## DROP-IN CONFIGURATION FILES
All *.conf files in the pipewire.conf.d/ directories are loaded and merged into the configuration. Dictionary sections are merged, overriding properties if they already existed, and array sections are appended to. The drop-in files have same format as the main configuration file, but only contain the settings to be modified.

As the pipewire.conf configuration file contains various parts that must be present for correct functioning, using drop-in files for configuration is recommended.

### Example
A configuration file ~/.config/pipewire/pipewire.conf.d/custom.conf to change the value of the default.clock.min-quantum setting in pipewire.conf:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.properties = {

    default.clock.min-quantum = 128
}
```

## CONFIGURATION FILE FORMAT
The configuration file is in 'SPA' JSON format.

The configuration file contains top-level keys, which are the sections. The value of a section is either a dictionary, { }, or an array, [ ]. Section and dictionary item declarations have KEY = VALUE form, and are separated by whitespace. For example:

```
context.properties = {  # top-level dictionary section

    key1 = value  # a simple value

    key2 = { key1 = value1 key2 = value2 }  # a dictionary with two entries

    key3 = [ value1 value2 ]  # an array with two entries

    key4 = [ { k = v1 } { k = v2 } ]  # an array of dictionaries
}
context.modules = [  # top-level array section

    value1

    value2
]
```

The configuration files can also be written in standard JSON syntax, but for easier manual editing, the relaxed 'SPA' variant is allowed. In 'SPA' JSON:

- : to delimit keys and values can be substituted by = or a space.

- " around keys and string can be omitted as long as no special characters are used in the strings.

- , to separate objects can be replaced with a whitespace character.

- # can be used to start a comment until the line end

## CONFIGURATION FILE SECTIONS
context.properties

Dictionary. These properties configure the PipeWire instance.

context.spa-libs

Dictionary. Maps plugin features with globs to a spa library.

context.modules

Array of dictionaries. Each entry in the array is a dictionary with the name of the module to load, including optional args and flags. Most modules support being loaded multiple times.

context.objects

Array of dictionaries. Each entry in the array is a dictionary containing the factory to create an object from and optional extra arguments specific to that factory.

context.exec

Array of dictionaries. Each entry in the array is dictionary containing the path of a program to execute on startup and optional args. This array used to contain an entry to start the session manager but this mode of operation has since been demoted to development aid. Avoid starting a session manager in this way in production environment.

node.rules

Array of dictionaries. Match rules for modifying node properties on the server.

device.rules

Array of dictionaries. Match rules for modifying device properties on the server.

## CONTEXT PROPERTIES
Available PipeWire properties in context.properties and possible default values.

clock.power-of-two-quantum = true

The quantum requests from the clients and the final graph quantum are rounded down to a power of two. A power of two quantum can be more efficient for many processing tasks.

context.data-loop.library.name.system

The name of the shared library to use for the system functions for the data processing thread. This can typically be changed if the data thread is running on a realtime kernel such as EVL.

loop.rt-prio = -1

The priority of the data loops. The data loops are used to schedule the nodes in the graph. A value of -1 uses the default realtime priority from the module-rt. A value of 0 disables realtime scheduling for the data loops.

loop.class = [ data.rt .. ]

An array of classes of the data loops. Normally nodes are assigned to a loop by name or by class. Nodes are by default assigned to the data.rt class so it is good to have a data loop of this class as well.

context.num-data-loops = 1

The number of data loops to create. By default 1 data-loop is created and all nodes are scheduled in this thread. A value of 0 disables the real-time data loops and schedules all nodes in the main thread. A value of -1 spawns as many data threads as there are cpu cores.

context.data-loops = [ ... ]

This controls the data loops that will be created for the context. Is is an array of data loop specifications, one entry for each data loop to start:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.data-loops = [

    {

         #library.name.system = support/libspa-support

         loop.rt-prio = -1

         loop.class = [ data.rt .. ]

         thread.name = data-loop.0

         thread.affinity = [ 0 1 ]

    }

    ...
]
```

A specific priority, classes and name can be given with loop.rt-prio, loop.class and thread.name respectively. It is also possible to pin the data loop to specific CPU cores with the thread.affinity property.

core.daemon = false

Makes the PipeWire process, started with this config, a daemon process. This means that it will manage and schedule a graph for clients. You would also want to configure a core.name to give it a well known name.

core.name = pipewire-0

The name of the PipeWire context. This will also be the name of the PipeWire socket clients can connect to.

cpu.zero.denormals = false

Configures the CPU to zero denormals automatically. This will be enabled for the data processing thread only, when enabled.

cpu.vm.name = null

This will be set automatically when the context is created and will contain the name of the VM. It is typically used to write match rules to set extra properties.

default.clock.rate = 48000

The default clock rate determines the real time duration of the min/max/default quantums. You might want to change the quantums when you change the default clock rate to maintain the same duration for the quantums.

default.clock.allowed-rates = [ ]

It is possible to specify up to 32 alternative sample rates. The graph sample rate will be switched when devices are idle. Note that this is not enabled by default for now because of various kernel and Bluetooth issues. Note that the min/max/default quantum values are scaled when the samplerate changes.

default.clock.min-quantum = 32

Default minimum quantum.

default.clock.max-quantum = 8192

Default maximum quantum.

default.clock.quantum = 1024

Default quantum used when no client specifies one.

default.clock.quantum-limit = 8192

Maximum quantum to reserve space for. This is the maximum buffer size used in the graph, regardless of the samplerate.

default.clock.quantum-floor = 4

Minimum quantum to reserve space for. This is the minimum buffer size used in the graph, regardless of the samplerate.

default.video.width

Default video width

default.video.height

Default video height

default.video.rate.num

Default video rate numerator

default.video.rate.denom

Default video rate denominator

library.name.system = support/libspa-support

The name of the shared library to use for the system functions for the main thread.

link.max-buffers = 64

The maximum number of buffers to negotiate between nodes. Note that version < 3 clients can only support 16 buffers. More buffers is almost always worse than less, latency and memory wise.

log.level = 2

The default log level used by the process.

mem.allow-mlock = true

Try to mlock the memory for the realtime processes. Locked memory will not be swapped out by the kernel and avoid hickups in the processing threads.

mem.warn-mlock = false

Warn about failures to lock memory.

mem.mlock-all = false

Try to mlock all current and future memory by the process.

settings.check-quantum = false

Check if the quantum in the settings metadata update is compatible with the configured limits.

settings.check-rate = false

Check if the rate in the settings metadata update is compatible with the configured limits.

support.dbus = true

Enable DBus support. This will enable DBus support in the various modules that require it. Disable this if you want to globally disable DBus support in the process.

vm.overrides = { default.clock.min-quantum = 1024 }

Any property in the vm.overrides property object will override the property in the context.properties when PipeWire detects it is running in a VM. This is deprecated, use the context.properties.rules instead.

context.modules.allow-empty = false

By default, a warning is logged when there are no context.modules loaded because this likely indicates there is a problem. Some applications might load the modules themselves and when they set this property to true, no warning will be logged.

The context properties may also contain custom values. For example, the context.modules and context.objects sections can declare additional conditions that control whether a module or object is loaded depending on what properties are present.

## SPA LIBRARIES
SPA plugins are loaded based on their factory-name. This is a well known name that uniquely describes the features that the plugin should have. The context.spa-libs section provides a mapping between the factory-name and the plugin where the factory can be found.

Factory names can contain a wildcard to group several related factories into one plugin. The plugin is loaded from the first matching factory-name.

### Example

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.spa-libs = {

    audio.convert.* = audioconvert/libspa-audioconvert

    avb.*           = avb/libspa-avb

    api.alsa.*      = alsa/libspa-alsa

    api.v4l2.*      = v4l2/libspa-v4l2

    api.libcamera.* = libcamera/libspa-libcamera

    api.bluez5.*    = bluez5/libspa-bluez5

    api.vulkan.*    = vulkan/libspa-vulkan

    api.jack.*      = jack/libspa-jack

    support.*       = support/libspa-support

    video.convert.* = videoconvert/libspa-videoconvert
}
```

## MODULES
PipeWire modules to be loaded. See libpipewire-modules(7).

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.modules = [

    #{ name = MODULENAME

    #    ( args  = { KEY = VALUE ... } )

    #    ( flags = [ ( ifexists ) ( nofail ) ] )

    #    ( condition = [ { KEY = VALUE ... } ... ] )

    #}

    #
]
```

name

Name of module to be loaded

args = { }

Arguments passed to the module

flags = [ ]

Loading flags. ifexists to only load module if it exists, and nofail to not fail PipeWire startup if the module fails to load.

condition = [ ]

A match rule matches condition. The module is loaded only if one of the expressions in the array matches to a context property.

## CONTEXT OBJECTS
The context.objects section allows you to make some objects from factories (usually created by loading modules in context.modules).

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.objects = [

    #{ factory = <factory-name>

    #    ( args  = { <key> = <value> ... } )

    #    ( flags = [ ( nofail ) ] )

    #    ( condition = [ { <key> = <value> ... } ... ] )

    #}
]
```

This section can be used to make nodes or links between nodes.

factory

Name of the factory to create the object.

args = { }

Arguments passed to the factory.

flags = [ ]

Flag nofail to not fail PipeWire startup if the object fails to load.

condition = [ ]

A match rule matches condition. The object is created only if one of the expressions in the array matches to a context property.

### Example
This fragment creates a new dummy driver node, but only if core.daemon property is true:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.objects = [

    { factory = spa-node-factory

      args = {

          factory.name    = support.node.driver

          node.name       = Dummy-Driver

          node.group      = pipewire.dummy

          priority.driver = 20000

      },

      condition = [ { core.daemon = true } ]

    }
]
```

## COMMAND EXECUTION
The context.exec section can be used to start arbitrary commands as part of the initialization of the PipeWire program.

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.exec = [

    #{   path = <program-name>

    #    ( args = "<arguments>" | [ <arg1> <arg2> ... ] )

    #    ( condition = [ { <key> = <value> ... } ... ] )

    #}
]
```

path

Program to execute.

args

Arguments to the program.

condition

A match rule matches condition. The object is created only if one of the expressions in the array matches to a context property.

### Example
The following fragment executes a pactl command with the given arguments:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.exec = [

    { path = "pactl" args = "load-module module-always-sink" }
]
```

## MATCH RULES
Some configuration file sections contain match rules. This makes it possible to perform some action when an object (usually a node or stream) is created/updated that matches certain properties.

The general rules object follows the following pattern:

```
<rules> = [

    {

        matches = [

            # any of the following sets of properties are matched, if

            # any matches, the actions are executed

            {

                # <key> = <value>

                # all keys must match the value. ! negates. ~ starts regex.

                #application.process.binary = "teams"

                #application.name = "~speech-dispatcher.*"

                # Absence of property can be tested by comparing to null

                #pipewire.sec.flatpak = null

            }

            {

                # more matches here...

            }

            ...

        ]

        actions = {

            <action-name> = <action value>

            ...

        }

    }
]
```

Match rules are an array of rules.

A rule is always a JSON object with two keys: matches and actions. The matches key is used to define the conditions that need to be met for the rule to be evaluated as true, and the actions key is used to define the actions that are performed when the rule is evaluated as true.

The matches key is always a JSON array of objects, where each object defines a condition that needs to be met. Each condition is a list of key-value pairs, where the key is the name of the property that is being matched, and the value is the value that the property needs to have. Within a condition, all the key-value pairs are combined with a logical AND, and all the conditions in the matches array are combined with a logical OR.

The actions key is always a JSON object, where each key-value pair defines an action that is performed when the rule is evaluated as true. The action name is specific to the rule and is defined by the rule’s documentation, but most frequently you will see the update-props action, which is used to update the properties of the matched object.

In the matches array, it is also possible to use regular expressions to match property values. For example, to match all nodes with a name that starts with my_, you can use the following condition:

```
matches = [

  {

    node.name = "~my_.*"

  }
]
```

The ~ character signifies that the value is a regular expression. The exact syntax of the regular expressions is the POSIX extended regex syntax, as described in the regex (7) man page.

In addition to regular expressions, you may also use the ! character to negate a condition. For example, to match all nodes with a name that does not start with my_, you can use the following condition:

```
matches = [

  {

    node.name = "!~my_.*"

  }
]
```

The ! character can be used with or without a regular expression. For example, to match all nodes with a name that is not equal to my_node, you can use the following condition:

```
matches = [

  {

    node.name = "!my_node"

  }
]
```

The null value has a special meaning; it checks if the property is not available (or unset). To check if a property is not set:

```
matches = [

  {

    node.name = null

  }
]
```

To check the existence of a property, one can use the !null condition, for example:

```
matches = [

  {

    node.name = "!null"

  }

  {

    node.name = !null            # simplified syntax

  }
]
```

To handle the 'null' string, one needs to escape the string. For example, to check if a property has the string value 'null', use:

```
matches = [

  {

    node.name = "null"

  }
]
```

To handle anything but the 'null' string, use:

```
matches = [

  {

    node.name = "!\"null\""

  }

  {

    node.name = !"null"      # simplified syntax

  }
]
```

## CONTEXT PROPERTIES RULES
context.properties.rules can be used to dynamically update the properties based on other properties.

A typical case is to update custom settings when running inside a VM. The cpu.vm.name is automatically set when running in a VM with the name of the VM. A match rule can be written to set custom properties like this:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
context.properties.rules = [

    {   matches = [ { cpu.vm.name = !null } ]

        actions = {

            update-props = {

                # These overrides are only applied when running in a vm.

                default.clock.min-quantum = 1024

            }

        }

    }
}
```

## NODE RULES
The node.rules are evaluated every time the properties on a node are set or updated. This can be used on the server side to override client set properties on arbitrary nodes.

node.rules provides an update-props action that takes an object with properties that are updated on the node object.

Add a node.rules section in the config file like this:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
node.rules = [

    {

        matches = [

            {

                # all keys must match the value. ! negates. ~ starts regex.

                client.name = "jack_simple_client"

            }

        ]

        actions = {

            update-props = {

                node.force-quantum = 512

            }

        }

    }
]
```

Will set the node.force-quantum property of jack_simple_client to 512.

## DEVICE RULES
The device.rules are evaluated every time the properties on a device are set or updated. This can be used on the server side to override client set properties on arbitrary devices.

device.rules provides an update-props action that takes an object with properties that are updated on the device object.

Add a device.rules section in the config file like this:

```
# ~/.config/pipewire/pipewire.conf.d/custom.conf
device.rules = [

    {

        matches = [

            {

                # all keys must match the value. ! negates. ~ starts regex.

                device.name = ""v4l2_device.pci-0000_00_14.0-usb-0_1.2_1.0

            }

        ]

        actions = {

            update-props = {

                device.description = "My Webcam"

            }

        }

    }
]
```

Will set the device.description property of the device with the given device.name to 'My Webcam'.

## AUTHORS
The PipeWire Developers <https://gitlab.freedesktop.org/pipewire/pipewire/issues>; PipeWire is available from <https://pipewire.org>

## SEE ALSO
pipewire(1), pw-mon(1), libpipewire-modules(7) pipewire-pulse.conf(5) pipewire-client.conf(5)


pc

package: pkgconf

title: pc(5)

summary: pkg-config file format

text:
# pc(5)

## NAME
file.pc — pkg-config file format

## DESCRIPTION
pkg-config files provide a useful mechanism for storing various information about libraries and packages on a given system. Information stored by .pc files include compiler and linker flags necessary to use a given library, as well as any other relevant metadata.

These .pc files are processed by a utility called pkg-config, of which pkgconf is an implementation.

### FILE SYNTAX
The .pc file follows a format inspired by RFC822. Comments are prefixed by a pound sign, hash sign or octothorpe (#), and variable assignment is similar to POSIX shell. Properties are defined using RFC822-style stanzas.

### VARIABLES
Variable definitions start with an alphanumeric string, followed by an equal sign, and then the value the variable should contain.

Variable references are always written as "${variable}". It is possible to escape literal "${" as "$${".

### PROPERTIES
Properties are set using RFC822-style stanzas which consist of a keyword, followed by a colon (:) and then the value the property should be set to. Variable substitution is always performed regardless of property type.

There are three types of property:

Literal

The property will be set to the text of the value.

Dependency List

The property will be set to a list of dependencies parsed from the text. Dependency lists are defined by this ABNF syntax:

```
package-list = *WSP *( package-spec *( package-sep ) )
package-sep  = WSP / ","
package-spec = package-key [ ver-op package-version ]
ver-op       = "<" / "<=" / "=" / "!=" / ">=" / ">"
```

Fragment List

The property will be set to a list of fragments parsed from the text. The input text must be in a format that is suitable for passing to a POSIX shell without any shell expansions after variable substitution has been done.

### PROPERTY KEYWORDS
Name

The displayed name of the package. (mandatory; literal)

Version

The version of the package. (mandatory; literal)

Description

A description of the package. (mandatory; literal)

URL

A URL to a webpage for the package. This is used to recommend where newer versions of the package can be acquired. (mandatory; literal)

Cflags

Required compiler flags. These flags are always used, regardless of whether static compilation is requested. (optional; fragment list)

Cflags.private

Required compiler flags for static compilation. (optional; fragment list; pkgconf extension)

Copyright

A copyright attestation statement. (optional; literal; pkgconf extension)

Libs

Required linking flags for this package. Libraries this package depends on for linking against it, which are not described as dependencies should be specified here. (optional; fragment list)

Libs.private

Required linking flags for this package that are only required when linking statically. Libraries this package depends on for linking against it statically, which are not described as dependencies should be specified here. (optional; fragment list)

License

The asserted SPDX license tag that should be applied to the given package. (optional; literal; pkgconf extension)

Maintainer

The preferred contact for the maintainer. This should be in the format of a name followed by an e-mail address or website. (optional; literal; pkgconf extension)

Requires

Required dependencies that must be met for the package to be usable. All dependencies must be satisfied or the pkg-config implementation must not use the package. (optional; dependency list)

Requires.private

Required dependencies that must be met for the package to be usable for header inclusion and static linking. All dependencies must be satisfied or the pkg-config implementation must not use the package for header inclusion and static linking. (optional; dependency list)

Conflicts

Dependencies that must not be met for the package to be usable. If any package in the proposed dependency solution match any dependency in the Conflicts list, the package being considered is not usable. (optional; dependency list)

Provides

Dependencies that may be provided by an alternate package. If a package cannot be found, the entire package collection is scanned for providers which can match the requested dependency. (optional; dependency list; pkgconf extension)

### EXTENSIONS
Features that have been marked as a pkgconf extension are only guaranteed to work with the pkgconf implementation of pkg-config. Other implementations may or may not support the extensions.

Accordingly, it is suggested that .pc files which absolutely depend on these extensions declare a requirement on the pkgconf virtual.

## EXAMPLES
An example .pc file:

```
# This is a comment
prefix=/home/kaniini/pkg   # this defines a variable
exec_prefix=${prefix}      # defining another variable with a substitution
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libfoo                                  # human-readable name
Description: an example library called libfoo # human-readable description
Copyright: Copyright (c) 2022 pkgconf project authors
License: Apache-2.0
Maintainer: the pkgconf project <http://www.pkgconf.org>
Version: 1.0
URL: http://www.pkgconf.org
Requires: libbar > 2.0.0
Conflicts: libbaz <= 3.0.0
Libs: -L${libdir} -lfoo
Libs.private: -lm
Cflags: -I${includedir}/libfoo
```

## SEE ALSO
pkgconf(1), pkg.m4(7)


pkgconf-personality

title: pkgconf-personality(5)

text:
# pkgconf-personality(5)

## NAME
file.personality — pkgconf cross-compile personality file format

## DESCRIPTION
pkgconf cross-compile personality files provide a useful mechanism for storing various information about system toolchains. Information stored by .personality files include information about paths used by a cross-compile toolchain, such as the sysroot directory and default include and library paths. pkgconf uses this information to determine what information is necessary to use libraries.

### FILE SYNTAX
The .personality file follows a format inspired by RFC822. Comments are prefixed by a pound sign, hash sign or octothorpe (#), and variable assignment is similar to POSIX shell. Properties are defined using RFC822-style stanzas.

### PROPERTIES
Properties are set using RFC822-style stanzas which consist of a keyword, followed by a colon (:) and then the value the property should be set to. Variable substitution is always performed regardless of property type.

There are three types of property:

Literal

The property will be set to the text of the value.

Fragment List

The property will be set to a list of fragments parsed from the text. The input text must be in a format that is suitable for passing to a POSIX shell without any shell expansions after variable substitution has been done. Elements are delimited with a colon.

Boolean

The property will be set to true if the value is one of: true, yes or 1. Otherwise it will be set to false.

### PROPERTY KEYWORDS
Triplet

The triplet used by the cross-compile toolchain. (mandatory; literal)

SysrootDir

The directory used by the system root of the cross-compile toolchain. (mandatory; literal)

DefaultSearchPaths

A list of directories to look for pc(5) files in. (mandatory; fragment list)

SystemIncludePaths

A list of directories that are included by default in the search path for include files. (mandatory; fragment list)

SystemLibraryPaths

A list of directories that are included by default in the search path for libraries. (mandatory; fragment list)

WantDefaultPure

If true, pkgconf will default to preferring a pure dependency graph. (optional; boolean; default is false)

WantDefaultStatic

If true, pkgconf will default to operating in static linking mode. (optional; boolean; default is false)

## EXAMPLES
An example .personality file:

```
# This is a comment
Triplet: x86_64-pc-linux-gnu
SysrootDir: /home/kaniini/sysroot/x86_64-pc-linux-gnu
DefaultSearchPaths: /home/kaniini/sysroot/x86_64-pc-linux-gnu/lib/pkgconfig:/home/kaniini/sysroot/x86_64-pc-linux-gnu/share/pkgconfig
SystemIncludePaths: /home/kaniini/sysroot/x86_64-pc-linux-gnu/include
SystemLibraryPaths: /home/kaniini/sysroot/x86_64-pc-linux-gnu/lib
```

## SEE ALSO
pkgconf(1), pc(5), pkg.m4(7)


pksd.conf

package: pks

title: pksd.conf(5)

text:
# pksd.conf(5)

## NAME
pksd.conf - Public Key Server Daemon configuration file

## DESCRIPTION
The pksd.conf file contains all the configuration information for the programs which comprise the public key server system (pks-intro(8)). It contains a list of configuration variables of the form

word value

If the first character of a line is #, the line is a comment, and ignored. The variables are as follows:

pks_bin_dir

This defines the location of the executeables which form the public key server system. In particular, pksdctl(8) must be in this directory.

db_dir

This is the directory where the database files keydbXXX, worddb, and timedb , and the key database file counter num_keydb are stored.

www_port

This is the port number on which pksd(8) accepts HTTP connections. If it is 0, then HTTP connections are not accepted on any port.

www_readonly

This controls key updates/submissions via HTTP. If it is 0, then keys may be submitted via HTTP. The DEFAULT is 1, which DOES NOT allow key updates/submissions via HTTP.

max_reply_keys

This controls how many keys are returned at the most for keyserver queries. You'll want to set this. The default is 0, so the keyserver will not return any keys.

socket_name

This is the name of the unix domain socket on which pksd(8) will listen for control messages from pksdctl(8), including notification of new mail messages.

mail_delivery_client

This is a command which will be executed whenever mail needs to be delivered. This value is used as the command argument to the shell (/bin/sh -c value), so appropriate care should be taken to avoid security problems. The mail message to be delivered is passed to the standard input of this command, so options to the program should be used to parse the input for delivery addresses.

maintainer_email

This address is used as the From: address for all mail sent out.

mail_intro_file

This is the filename of a file which, if present, is inserted at the head of each mail message sent out by pksd(8). This file is used as a part of a MIME message. If MIME headers, such as content-type:, are required, they precede the body, separated by a blank line. If no headers are required, then the first line of the file must be blank.

help_dir

This is the name of a directory in which the key server help files should be found. The files in this directory should be named pks_help.LANG, where LANG is the language of the help file, in lower-case. These files are also used as MIME parts, so they are subject to the same formatting requirements as the mail_intro_file .

default_language

This is a string containing the default language for help responses from the server. The help file for this language, as described above, should exist.

this_site

This is the email address for this public key server. See the description of incremental messages in pksd(8) for more details.

syncsite

This command gives the email address of a peer public key server to this one. This is the only command which can be specified more than once. It should be specified once for each peer server.

## FILES
pksd.conf

## SEE ALSO
pks-intro(8), pksd(8)

## AUTHOR
Marc Horowitz, Massachusetts Institute of Technology