2
0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-29 04:57:52 +00:00
kea/doc/examples/kea6/advanced.json
Thomas Markwalder 16acf248d0 [#3831] Initial impl of restricted ctl sockets
Working, have some UTs that still need to be fixed

/doc/examples/kea4/advanced.json
/doc/examples/kea4/all-keys-netconf.json
/doc/examples/kea4/all-keys-netconf.json
/doc/examples/kea4/all-keys.json
/doc/examples/kea4/comments.json
/doc/examples/kea4/config-backend.json
/doc/examples/kea4/ha-load-balancing-server1-mt-with-tls.json
/doc/examples/kea4/ha-load-balancing-server2-mt.json
/doc/examples/kea6/advanced.json
/doc/examples/kea6/all-keys-netconf.json
/doc/examples/kea6/all-keys.json
/doc/examples/kea6/comments.json
/doc/examples/kea6/config-backend.json
/doc/examples/kea6/ha-hot-standby-server1-with-tls.json
/doc/examples/kea6/ha-hot-standby-server2.json
    removed /tmp path from socket-name

/src/bin/dhcp4/tests/config_parser_unittest.cc
/src/bin/dhcp4/tests/ctrl_dhcp4_srv_unittest.cc
/src/bin/dhcp4/tests/dhcp4_srv_unittest.cc
/src/bin/dhcp4/tests/dhcp4_test_utils.cc
/src/bin/dhcp4/tests/dhcp4_test_utils.h
/src/bin/dhcp6/tests/config_parser_unittest.cc
/src/bin/dhcp6/tests/ctrl_dhcp6_srv_unittest.cc
/src/bin/dhcp6/tests/dhcp6_srv_unittest.cc
/src/bin/dhcp6/tests/dhcp6_test_utils.cc
/src/bin/dhcp6/tests/dhcp6_test_utils.h
    updated tests

/src/lib/config/Makefile.am
/src/lib/config/meson.build
    defined CONTROL_SOCKET_DIR

/src/lib/config/tests/unix_command_config_unittests.cc
/src/lib/config/tests/unix_command_mgr_unittests.cc
    updated tests

/src/lib/config/unix_command_config.*
    UnixCommandConfig - added PathChecker singleton and methods
    to set and validate socket path/permissions

/src/lib/util/filesystem.*
    Added getPermsissions() and hasPermsission()

/src/lib/util/tests/filesystem_unittests.cc
    new permissions tests
2025-05-19 12:12:55 +00:00

190 lines
8.2 KiB
JSON

// This is an example configuration file for DHCPv6 server in Kea.
// It attempts to showcase some of the more advanced features.
// Topology wise, it's a basic scenario with one IPv6 subnet configured.
// It is assumed that one subnet (2001:db8:1::/64) is available directly
// over eth0 interface.
//
// The following features are currently showcased here:
// 1. Configuration of MAC/hardware address sources in DHCPv6
// 2. RSOO (Relay supplied options) - Some relays may insert options with the
// intention for the server to insert them into client directed messages.
// 3. Control socket. Kea can open a socket and listen for incoming
// commands.
{ "Dhcp6":
{
// Kea is told to listen on eth0 network interface only.
"interfaces-config": {
"interfaces": [ "eth0" ],
// This makes interfaces to be re-detected at each (re-)configuration.
// By default it is true.
"re-detect": true
},
// We need to specify the database used to store leases. As of
// June 2022, three database backends are supported: MySQL,
// PostgreSQL and the in-memory database, Memfile.
// We will use memfile because it doesn't require any prior set up.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"sanity-checks": {
// This parameter determines what to do when a new lease appears in the
// system (i.e. either is read from disk during memfile startup or is
// added via lease commands). There are five modes supported:
// none - do nothing, accept them as is
// warn - if subnet-id problems are detected, print a warning, but
// otherwise load the lease as is. This is the default value.
// fix - attempt to fix the lease by finding appropriate subnet-id value.
// if there is no suitable subnet, the lease is loaded as is.
// fix-del - attempt to fix the lease by finding appropriate subnet-id
// value. If there is no suitable subnet, the lease is deleted.
// del - delete leases that have incorrect subnet-id values.
"lease-checks": "fix-del"
},
// Kea 0.9.1 introduced MAC/hardware addresses support in DHCPv6. There is
// no single reliable method of getting MAC address information in DHCPv6.
// Kea supports several methods. Depending on your network set up, some
// methods may be more preferable than others, hence the configuration
// parameter. 'mac-sources' is a list of methods. Allowed parameters are:
// any, raw, duid, ipv6-link-local, client-link-addr-option, rfc6939 (which
// is an alias for client-link-addr-option), remote-id, rfc4649 (which is an
// alias for remote-id, subscriber-id, rfc4580 (which is an alias for
// subscriber-id) and docsis.
// Note that the order matters. Methods are attempted one by one in the
// order specified until hardware address is obtained. If you don't care
// which method is used, using 'any' is marginally faster than enumerating
// them all.
// If mac-sources are not specified, a default value of 'any' is used.
"mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ],
// RFC6422 defines a mechanism called relay-supplied options option. The
// relay agent may insert certain options that the server will echo back to
// the client, if certain criteria are met. One condition is that the option
// must be RSOO-enabled (i.e. allowed to be echoed back). IANA maintains a
// list of those options here:
// http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied
// However, it is possible to allow the server to echo back additional
// options. This entry marks options 110, 120 and 130 as RSOO-enabled.
"relay-supplied-options": [ "110", "120", "130" ],
// This defines a control socket. If defined, Kea will open a UNIX socket
// and will listen for incoming commands. See section 15 of the Kea User's
// Guide for list of supported commands.
"control-socket": {
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket"
},
// Addresses will be assigned with preferred and valid lifetimes
// being 3000 and 4000, respectively. Client is told to start
// renewing after 1000 seconds. If the server does not respond
// after 2000 seconds since the lease was granted, client is supposed
// to start REBIND procedure (emergency renewal that allows switching
// to a different server).
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// The following list defines subnets. Each subnet consists of at
// least subnet and pool entries. Note the user-context being
// used throughout the definitions. This is something that is not
// being used by Kea, it's simply parsed and stored in appropriate
// structures. You can put anything you want in the user-context
// as long as it is a valid JSON and it starts with a map (i.e.
// is enclosed by curly brackets).
// A comment entry is translated into a user-context with a
// "comment" property so you can include comments inside the
// configuration itself.
"subnet6": [
{
"pools": [
{
"pool": "2001:db8:1::/80",
// This is user context specified for this particular
// pool. You can use it to describe the pool in some way.
// Just keep in mind that the structure will not be used
// by Kea itself. It will be made available to hooks if
// they want to use it.
"user-context": { "department": "engineering" }
}],
// Here's the user-context for the whole subnet.
"user-context": { "comment": "Floor one, west wing" },
// Equivalent using smart parser
// "comment": "Floor one, west wing",
// This defines PD (prefix delegation) pools. In this case
// we have only one pool. That consists of /64 prefixes
// being delegated out of large /48 pool. Each delegated
// prefix will contain an excluded-prefix option.
"pd-pools": [
{
"prefix": "2001:db8:abcd::",
"prefix-len": 48,
"delegated-len": 64,
"excluded-prefix": "2001:db8:abcd:0:1234::",
"excluded-prefix-len": 80,
// Another user-context for this PD pool. Again, you can put
// anything you want in there as long as it's valid JSON and
// starts with a map.
"user-context": {
"purpose": "For CPE devices"
}
}
], // end of pools
"id": 1,
"subnet": "2001:db8:1::/64",
"interface": "eth0",
// Sometimes the relay may use an odd IPv6 address that's not matching
// the subnet. This is discouraged, but there are valid cases when it
// makes sense. One case is when the relay has only link-local address
// and another is when there is a shared subnet scenario.
"relay": {
"ip-addresses": [ "3000::1" ]
}
}
],
// The following configures logging. It assumes that messages with at
// least informational level (info, warn, error and fatal) should be
// logged to stdout.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout",
// Several additional parameters are possible in addition
// to the typical output. Flush determines whether logger
// flushes output to a file. Maxsize determines maximum
// filesize before the file is rotated. maxver
// specifies the maximum number of rotated files being
// kept.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// We use pattern to specify custom log message layout
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}