Package: kea-dhcp4-server
Version: 2.2.0-6
Followup-For: Bug #1055438
Dear Maintainer,
I updated to Debian 12.4 and rebooted all my hosts. Kea didn't came up
so my notebook (and all other devices) didn't get IP addresses. I
configured network manually, connected to the server host and ran
sudo /etc/init.d/kea-dhcp4-server start
No errors but Kea didn't came up.
sudo /bin/sh -x /etc/init.d/kea-dhcp4-server start
No errors, nothing suspicious in the output, but Kea didn't came up.
sudo kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
Boom -- there is no /run/kea/ directory so Kea doesn't start and doesn't
report problems via logs as it cannot create log files. I added the
directory creation in /etc/init.d/kea-dhcp4-server; not sure if it's the
most correct resolution but it works for me:
--- kea-dhcp4-server.orig 2023-12-11 10:40:30.160620819 +0300
+++ kea-dhcp4-server 2023-12-11 09:47:25.925425273 +0300
@@ -24,6 +24,7 @@
KEA_PIDFILE_DIR=/run/
KEA_LOCKFILE_DIR=/run/lock/kea/
KEA_LOGGER_DESTINATION=/var/log/kea/
+KEA_RUN_DIR=/run/kea/
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
@@ -44,6 +45,9 @@
if [ ! -d "$KEA_LOCKFILE_DIR" ]; then
mkdir -m 0750 -p "$KEA_LOCKFILE_DIR"
fi
+ if [ ! -d "$KEA_RUN_DIR" ]; then
+ mkdir -m 0750 -p "$KEA_RUN_DIR"
+ fi
}
#
-- System Information:
Debian Release: 12.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 6.1.0-14-686 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages kea-dhcp4-server depends on:
ii init-system-helpers 1.65.2
ii kea-common 2.2.0-6
ii libc6 2.36-9+deb12u3
ii libgcc-s1 12.2.0-14
ii libstdc++6 12.2.0-14
kea-dhcp4-server recommends no packages.
Versions of packages kea-dhcp4-server suggests:
pn kea-doc <none>
-- Configuration Files:
/etc/init.d/kea-dhcp4-server changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="kea-dhcp4"
NAME=kea-dhcp4-server
DAEMON=/usr/sbin/kea-dhcp4
DAEMON_ARGS="-c /etc/kea/kea-dhcp4.conf"
PIDFILE=/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
KEA_PIDFILE_DIR=/run/
KEA_LOCKFILE_DIR=/run/lock/kea/
KEA_LOGGER_DESTINATION=/var/log/kea/
KEA_RUN_DIR=/run/kea/
[ -x "$DAEMON" ] || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
. /lib/init/vars.sh
. /lib/lsb/init-functions
create_lockfile_dir()
{
if [ ! -d "$KEA_LOCKFILE_DIR" ]; then
mkdir -m 0750 -p "$KEA_LOCKFILE_DIR"
fi
if [ ! -d "$KEA_RUN_DIR" ]; then
mkdir -m 0750 -p "$KEA_RUN_DIR"
fi
}
do_start()
{
create_lockfile_dir
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
--test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -b
-- \
$DAEMON_ARGS \
|| return 2
}
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec
$DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name
$NAME
return 0
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave 'force-reload' as an alias for 'restart'.
#
#log_daemon_msg "Reloading $DESC" "$NAME"
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
/etc/kea/kea-dhcp4.conf changed:
// This is a basic configuration for the Kea DHCPv4 server. Subnet declarations
// are mostly commented out and no interfaces are listed. Therefore, the servers
// will not listen or respond to any queries.
// The basic configuration must be extended to specify interfaces on which
// the servers should listen. There are a number of example options defined.
// These probably don't make any sense in your network. Make sure you at least
// update the following, before running this example in your network:
// - change the network interface names
// - change the subnets to match your actual network
// - change the option values to match your network
//
// This is just a very basic configuration. Kea comes with large suite (over 30)
// of configuration examples and extensive Kea User's Guide. Please refer to
// those materials to get better understanding of what this software is able to
// do. Comments in this configuration file sometimes refer to sections for more
// details. These are section numbers in Kea User's Guide. The version matching
// your software should come with your Kea package, but it is also available
// in ISC's Knowledgebase (https://kea.readthedocs.io; the direct link for
// the stable version is https://kea.readthedocs.io/).
//
// This configuration file contains only DHCPv4 server's configuration.
// If configurations for other Kea services are also included in this file they
// are ignored by the DHCPv4 server.
{
// DHCPv4 configuration starts here. This section will be read by DHCPv4 server
// and will be ignored by other components.
"Dhcp4": {
"dhcp-ddns": {
"enable-updates": false
},
// "valid-lifetime": 3600,
"max-valid-lifetime": 86400,
"option-def": [
{
"space": "dhcp4",
"name": "rfc3442-classless-static-routes",
"code": 121,
"array": true,
"type": "uint8"
},
{
"space": "dhcp4",
"name": "ms-classless-static-routes",
"code": 249,
"array": true,
"type": "uint8"
},
{
"space": "dhcp4",
"name": "wpad",
"code": 252,
"type": "string"
}
],
// Add names of your network interfaces to listen on.
"interfaces-config": {
// See section 8.2.4 for more details. You probably want to add just
// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": ["enp7s0"]
// Kea DHCPv4 server by default listens using raw sockets. This ensures
// all packets, including those sent by directly connected clients
// that don't have IPv4 address yet, are received. However, if your
// traffic is always relayed, it is often better to use regular
// UDP sockets. If you want to do that, uncomment this line:
// "dhcp-socket-type": "udp"
},
// Kea supports control channel, which is a way to receive management
// commands while the server is running. This is a Unix domain socket that
// receives commands formatted in JSON, e.g. config-set (which sets new
// configuration), config-reload (which tells Kea to reload its
// configuration from file), statistic-get (to retrieve statistics) and many
// more. For detailed description, see Sections 8.8, 16 and 15.
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea4-ctrl-socket"
},
// Use Memfile lease database backend to store leases in a CSV file.
// Depending on how Kea was compiled, it may also support SQL databases
// (MySQL and/or PostgreSQL). Those database backends require more
// parameters, like name, host and possibly user and password.
// There are dedicated examples for each backend. See Section 7.2.2 "Lease
// Storage" for details.
"lease-database": {
// Memfile is the simplest and easiest backend to use. It's an in-memory
// C++ database that stores its state in CSV file.
"type": "memfile",
"lfc-interval": 3600
},
// Kea allows storing host reservations in a database. If your network is
// small or you have few reservations, it's probably easier to keep them
// in the configuration file. If your network is large, it's usually better
// to use database for it. To enable it, uncomment the following:
// "hosts-database": {
// "type": "mysql",
// "name": "kea",
// "user": "kea",
// "password": "kea",
// "host": "localhost",
// "port": 3306
// },
// See Section 7.2.3 "Hosts storage" for details.
// Setup reclamation of the expired leases and leases affinity.
// Expired leases will be reclaimed every 10 seconds. Every 25
// seconds reclaimed leases, which have expired more than 3600
// seconds ago, will be removed. The limits for leases reclamation
// are 100 leases or 250 ms for a single cycle. A warning message
// will be logged if there are still expired leases in the
// database after 5 consecutive reclamation cycles.
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
// Global timers specified here apply to all subnets, unless there are
// subnet specific values defined in particular subnets.
"renew-timer": 900,
"rebind-timer": 1800,
"valid-lifetime": 3600,
// Many additional parameters can be specified here:
// - option definitions (if you want to define vendor options, your own
// custom options or perhaps handle standard options
// that Kea does not support out of the box yet)
// - client classes
// - hooks
// - ddns information (how the DHCPv4 component can reach a DDNS daemon)
//
// Some of them have examples below, but there are other parameters.
// Consult Kea User's Guide to find out about them.
// These are global options. They are going to be sent when a client
// requests them, unless overwritten with values in more specific scopes.
// The scope hierarchy is:
// - global (most generic, can be overwritten by class, subnet or host)
// - class (can be overwritten by subnet or host)
// - subnet (can be overwritten by host)
// - host (most specific, overwrites any other scopes)
//
// Not all of those options make sense. Please configure only those that
// are actually useful in your network.
//
// For a complete list of options currently supported by Kea, see
// Section 7.2.8 "Standard DHCPv4 Options". Kea also supports
// vendor options (see Section 7.2.10) and allows users to define their
// own custom options (see Section 7.2.9).
"option-data": [
// When specifying options, you typically need to specify
// one of (name or code) and data. The full option specification
// covers name, code, space, csv-format and data.
// space defaults to "dhcp4" which is usually correct, unless you
// use encapsulate options. csv-format defaults to "true", so
// this is also correct, unless you want to specify the whole
// option value as long hex string. For example, to specify
// domain-name-servers you could do this:
// {
// "name": "domain-name-servers",
// "code": 6,
// "csv-format": "true",
// "space": "dhcp4",
// "data": "192.0.2.1, 192.0.2.2"
// }
// but it's a lot of writing, so it's easier to do this instead:
{
"name": "domain-name-servers",
"data": "192.168.3.8, 10.110.0.3, 10.110.0.5"
},
// Typically people prefer to refer to options by their names, so they
// don't need to remember the code names. However, some people like
// to use numerical values. For example, option "domain-name" uses
// option code 15, so you can reference to it either by
// "name": "domain-name" or "code": 15.
{
"code": 15,
"name": "domain-name",
"data": "aviel.ru"
},
// Domain search is also a popular option. It tells the client to
// attempt to resolve names within those specified domains. For
// example, name "foo" would be attempted to be resolved as
// foo.mydomain.example.com and if it fails, then as foo.example.com
{
"name": "domain-search",
"data": "aviel.ru"
},
// String options that have a comma in their values need to have
// it escaped (i.e. each comma is preceded by two backslashes).
// That's because commas are reserved for separating fields in
// compound options. At the same time, we need to be conformant
// with JSON spec, that does not allow "\,". Therefore the
// slightly uncommon double backslashes notation is needed.
// Legal JSON escapes are \ followed by "\/bfnrt character
// or \u followed by 4 hexadecimal numbers (currently Kea
// supports only \u0000 to \u00ff code points).
// CSV processing translates '\\' into '\' and '\,' into ','
// only so for instance '\x' is translated into '\x'. But
// as it works on a JSON string value each of these '\'
// characters must be doubled on JSON input.
// {
// "name": "boot-file-name",
// "data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"
// },
// Options that take integer values can either be specified in
// dec or hex format. Hex format could be either plain (e.g. abcd)
// or prefixed with 0x (e.g. 0xabcd).
{
"name": "default-ip-ttl",
"data": "0xf0"
}
// Note that Kea provides some of the options on its own. In particular,
// it sends IP Address lease type (code 51, based on valid-lifetime
// parameter, Subnet mask (code 1, based on subnet definition), Renewal
// time (code 58, based on renew-timer parameter), Rebind time (code 59,
// based on rebind-timer parameter).
// {
// "space": "dhcp4",
// "name": "wpad",
// "code": 252,
// "data": "http://wpad.url";
// }
],
// Other global parameters that can be defined here are option definitions
// (this is useful if you want to use vendor options, your own custom
// options or perhaps handle options that Kea does not handle out of the box
// yet).
// You can also define classes. If classes are defined, incoming packets
// may be assigned to specific classes. A client class can represent any
// group of devices that share some common characteristic, e.g. Windows
// devices, iphones, broken printers that require special options, etc.
// Based on the class information, you can then allow or reject clients
// to use certain subnets, add special options for them or change values
// of some fixed fields.
// "client-classes": [
// {
// // This specifies a name of this class. It's useful if you need
to
// // reference this class.
// "name": "voip",
// // This is a test. It is an expression that is being evaluated on
// // each incoming packet. It is supposed to evaluate to either
// // true or false. If it's true, the packet is added to specified
// // class. See Section 12 for a list of available expressions.
There
// // are several dozens. Section 8.2.14 for more details for DHCPv4
// // classification and Section 9.2.19 for DHCPv6.
// "test": "substring(option[60].hex,0,6) == 'Aastra'",
// // If a client belongs to this class, you can define extra
behavior.
// // For example, certain fields in DHCPv4 packet will be set to
// // certain values.
// "next-server": "192.0.2.254",
// "server-hostname": "hal9000",
// "boot-file-name": "/dev/null"
// // You can also define option values here if you want devices
from
// // this class to receive special options.
// }
// ],
// Another thing possible here are hooks. Kea supports a powerful mechanism
// that allows loading external libraries that can extract information and
// even influence how the server processes packets. Those libraries include
// additional forensic logging capabilities, ability to reserve hosts in
// more flexible ways, and even add extra commands. For a list of available
// hook libraries, see
https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available.
// "hooks-libraries": [
// {
// // Forensic Logging library generates forensic type of audit trail
// // of all devices serviced by Kea, including their identifiers
// // (like MAC address), their location in the network, times
// // when they were active etc.
// "library":
"/usr/lib/i386-linux-gnu/kea/hooks/libdhcp_legal_log.so",
// "parameters": {
// "path": "/var/lib/kea",
// "base-name": "kea-forensic4"
// }
// },
// {
// // Flexible identifier (flex-id). Kea software provides a way to
// // handle host reservations that include addresses, prefixes,
// // options, client classes and other features. The reservation can
// // be based on hardware address, DUID, circuit-id or client-id in
// // DHCPv4 and using hardware address or DUID in DHCPv6. However,
// // there are sometimes scenario where the reservation is more
// // complex, e.g. uses other options that mentioned above, uses part
// // of specific options or perhaps even a combination of several
// // options and fields to uniquely identify a client. Those
scenarios
// // are addressed by the Flexible Identifiers hook application.
// "library": "/usr/lib/i386-linux-gnu/kea/hooks/libdhcp_flex_id.so",
// "parameters": {
// "identifier-expression": "relay4[2].hex"
// }
// }
// ],
"host-reservation-identifiers": [
"hw-address"
],
"reservation-mode": "out-of-pool",
// Below an example of a simple IPv4 subnet declaration. Uncomment to enable
// it. This is a list, denoted with [ ], of structures, each denoted with
// { }. Each structure describes a single subnet and may have several
// parameters. One of those parameters is "pools" that is also a list of
// structures.
"subnet4": [
{
// This defines the whole subnet. Kea will use this information to
// determine where the clients are connected. This is the whole
// subnet in your network. This is mandatory parameter for each
// subnet.
"subnet": "192.168.3.0/24",
// Pools define the actual part of your subnet that is governed
// by Kea. Technically this is optional parameter, but it's
// almost always needed for DHCP to do its job. If you omit it,
// clients won't be able to get addresses, unless there are
// host reservations defined for them.
// "pools": [ { "pool": "192.168.3.128 - 192.168.3.255" } ],
"id": 1,
"authoritative": true,
"interface": "enp7s0",
// These are options that are subnet specific. In most cases,
// you need to define at least routers option, as without this
// option your clients will not be able to reach their default
// gateway and will not have Internet connectivity.
"option-data": [
{
"space": "dhcp4",
"name": "broadcast-address",
"code": 28,
"data": "192.168.3.255"
},
{
"space": "dhcp4",
"name": "domain-name",
"code": 15,
"data": "aviel.ru"
},
{
"space": "dhcp4",
"name": "domain-name-servers",
"code": 6,
"data": "192.168.3.8, 10.110.0.3, 10.110.0.5"
},
{
"space": "dhcp4",
"name": "domain-search",
"code": 119,
"data": "aviel.ru"
},
{
"space": "dhcp4",
"name": "ip-forwarding",
"code": 19,
"data": "false"
},
{
// For each IPv4 subnet you most likely need to specify at
// least one router.
"name": "routers",
"data": "192.168.3.8"
},
{
"space": "dhcp4",
"name": "subnet-mask",
"code": 1,
"data": "255.255.255.0"
},
{
"space": "dhcp4",
"name": "rfc3442-classless-static-routes",
"code": 121,
"data": "0, 192, 168, 3, 8, 16, 10, 90, 192, 168, 3, 8, 16,
10, 100, 192, 168, 3, 8, 16, 10, 110, 192, 168, 3, 8, 12, 172, 16, 192, 168, 3,
8, 21, 93, 185, 192, 192, 168, 3, 8, 24, 62, 117, 85, 192, 168, 3, 8, 24, 83,
234, 164, 192, 168, 3, 8, 29, 62, 117, 80, 120, 192, 168, 3, 8, 30, 80, 252,
152, 0, 192, 168, 3, 8"
},
{
"space": "dhcp4",
"name": "ms-classless-static-routes",
"code": 249,
"data": "0, 192, 168, 3, 8, 16, 10, 90, 192, 168, 3, 8, 16,
10, 100, 192, 168, 3, 8, 16, 10, 110, 192, 168, 3, 8, 12, 172, 16, 192, 168, 3,
8, 21, 93, 185, 192, 192, 168, 3, 8, 24, 62, 117, 85, 192, 168, 3, 8, 24, 83,
234, 164, 192, 168, 3, 8, 29, 62, 117, 80, 120, 192, 168, 3, 8, 30, 80, 252,
152, 0, 192, 168, 3, 8"
}
],
// Kea offers host reservations mechanism. Kea supports reservations
// by several different types of identifiers: hw-address
// (hardware/MAC address of the client), duid (DUID inserted by the
// client), client-id (client identifier inserted by the client) and
// circuit-id (circuit identifier inserted by the relay agent).
//
// Kea also support flexible identifier (flex-id), which lets you
// specify an expression that is evaluated for each incoming packet.
// Resulting value is then used for as an identifier.
//
// Note that reservations are subnet-specific in Kea. This is
// different than ISC DHCP. Keep that in mind when migrating
// your configurations.
"reservations": [
// This is a reservation for a specific hardware/MAC address.
// It's a rather simple reservation: just an address and nothing
// else.
// {
// "hw-address": "1a:1b:1c:1d:1e:1f",
// "ip-address": "192.0.2.201"
// },
// This is a reservation for a specific client-id. It also shows
// the this client will get a reserved hostname. A hostname can
// be defined for any identifier type, not just client-id.
// {
// "client-id": "01:11:22:33:44:55:66",
// "ip-address": "192.0.2.202",
// "hostname": "special-snowflake"
// },
// The third reservation is based on DUID. This reservation
defines
// a special option values for this particular client. If the
// domain-name-servers option would have been defined on a
global,
// subnet or class level, the host specific values take
preference.
// {
// "duid": "01:02:03:04:05",
// "ip-address": "192.0.2.203",
// "option-data": [ {
// "name": "domain-name-servers",
// "data": "10.1.1.202, 10.1.1.203"
// } ]
// },
// The fourth reservation is based on circuit-id. This is an
option
// inserted by the relay agent that forwards the packet from
client
// to the server. In this example the host is also assigned
vendor
// specific options.
//
// When using reservations, it is useful to configure
// reservations-global, reservations-in-subnet,
// reservations-out-of-pool (subnet specific parameters)
// and host-reservation-identifiers (global parameter).
// {
// "client-id": "01:12:23:34:45:56:67",
// "ip-address": "192.0.2.204",
// "option-data": [
// {
// "name": "vivso-suboptions",
// "data": "4491"
// },
// {
// "name": "tftp-servers",
// "space": "vendor-4491",
// "data": "10.1.1.202, 10.1.1.203"
// }
// ]
// },
// This reservation is for a client that needs specific DHCPv4
// fields to be set. Three supported fields are next-server,
// server-hostname and boot-file-name
// {
// "client-id": "01:0a:0b:0c:0d:0e:0f",
// "ip-address": "192.0.2.205",
// "next-server": "192.0.2.1",
// "server-hostname": "hal9000",
// "boot-file-name": "/dev/null"
// },
// This reservation is using flexible identifier. Instead of
// relying on specific field, sysadmin can define an expression
// similar to what is used for client classification,
// e.g. substring(relay[0].option[17],0,6). Then, based on the
// value of that expression for incoming packet, the reservation
// is matched. Expression can be specified either as hex or
// plain text using single quotes.
//
// Note: flexible identifier requires flex_id hook library to be
// loaded to work.
// {
// "flex-id": "'s0mEVaLue'",
// "ip-address": "192.0.2.206"
// }
// You can add more reservations here.
{
"hostname": "oleg-nb4-eth",
"hw-address": "e8:d8:d1:8a:2c:2f",
"ip-address": "192.168.3.47",
"option-data": [
{
"space": "dhcp4",
"name": "host-name",
"code": 12,
"data": "oleg-nb4-eth"
}
]
},
{
"hostname": "oleg-nb4-wifi",
"hw-address": "98:af:65:39:d1:5e",
"ip-address": "192.168.3.48",
"option-data": [
{
"space": "dhcp4",
"name": "host-name",
"code": 12,
"data": "oleg-nb4-wifi"
}
]
}
]
// You can add more subnets there.
}
],
// There are many, many more parameters that DHCPv4 server is able to use.
// They were not added here to not overwhelm people with too much
// information at once.
// Logging configuration starts here. Kea uses different loggers to log
various
// activities. For details (e.g. names of loggers), see Chapter 18.
"loggers": [
{
// This section affects kea-dhcp4, which is the base logger for DHCPv4
// component. It tells DHCPv4 server to write all log messages (on
// severity INFO or more) to a file.
"name": "kea-dhcp4",
"output_options": [
{
// Specifies the output file. There are several special values
// supported:
// - stdout (prints on standard output)
// - stderr (prints on standard error)
// - syslog (logs to syslog)
// - syslog:name (logs to syslog using specified name)
// Any other value is considered a name of the file
"output": "syslog",
// Shorter log pattern suitable for use with systemd,
// avoids redundant information
"pattern": "%-5p %m\n"
// This governs whether the log output is flushed to disk after
// every write.
// "flush": false,
// This specifies the maximum size of the file before it is
// rotated.
// "maxsize": 1048576,
// This specifies the maximum number of rotated files to keep.
// "maxver": 8
}
],
// This specifies the severity of log messages to keep. Supported values
// are: FATAL, ERROR, WARN, INFO, DEBUG
"severity": "INFO",
// If DEBUG level is specified, this value is used. 0 is least verbose,
// 99 is most verbose. Be cautious, Kea can generate lots and lots
// of logs if told to do so.
"debuglevel": 0
}
]
}
}
-- no debconf information
