1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
// This is a simple example of a configuration for Netconf that handles
// DHCPv6 configuration. This example provides YANG interface for
// DHCPv6 server only.
{
"Netconf":
{
// Three flags control netconf (default values are true):
// - "boot-update" about the YANG configuration load when
// netconf boots.
// - "subscribe-changes" about the subscription to notifications
// when the running YANG module is changed.
// - "validate-changes" allows to validate changes or not.
"boot-update": true,
"subscribe-changes": true,
"validate-changes": true,
// This map specifies how each server is managed:
// the YANG model to use and the control channel.
"managed-servers":
{
// This is how Netconf can communicate with the DHCPv6 server.
"dhcp6":
{
// Eventually, the kea-netconf will be able to handle multiple
// models. However, for the time being the choices for
// DHCPv6 server are kea-dhcp6-server and
/// ietf-dhcpv6-server models but only the first is usable.
"model": "kea-dhcp6-server",
// The three control flags can be defined in this scope too
// and takes precedence over global and default values.
// boot-update determines whether the initial configuration
// should be retrieved from netconf during kea-netconf startup.
// You almost always want to set this to yes.
"boot-update": true,
// This flag control whether the kea-netconf daemon should
// subscribe to any changes. If set to true, kea-netconf will
// monitor sysrepo and will pick up any changes that may be
// introduced, either using netconf clients or sysrepocfg.
"subscribe-changes": true,
// This parameters specifies whether kea-netconf will attempt
// to verify if the upcoming NETCONF configuration is sane. The
// verification is done by calling config-test. Depending on
// Kea response, the new configuration is accepted or rejected.
"validate-changes": false,
// Currently three control channel types are supported:
// - "stdout" which output the configuration on the standard
// output (this is mainly for testing purposes, but you can
// use simple script (such as curl or socat) to pass that
// information to the server.
// - "unix" which uses the local control channel supported by
// "dhcp4" and "dhcp6" servers ("d2" support is coming in Kea 1.5)
// - "http" which uses the Control Agent (CA) to manage itself or
// to forward commands to "dhcp4" or "dhcp6" (not yest supported).
"control-socket":
{
"socket-type": "unix",
"socket-name": "/tmp/kea6-ctrl-socket"
},
// Comment is optional. You can put some notes here.
"comment": "Kea DHCP6 server serving network on floor 13"
}
},
// Netconf is able to load hook libraries that augment its operation.
// The primary functionality is the ability to add new commands.
//
// Uncomment this section to load a hook library.
//
// "hooks-libraries": [
// // Hook libraries list may contain more than one library.
// {
// // The only necessary parameter is the library filename.
// "library": "/opt/local/netconf-commands.so",
//
// // Some libraries may support parameters. Make sure you
// // type this section carefully, as the CA does not validate
// // it (because the format is library specific).
// "parameters": {
// "param1": "foo"
// }
// }
//]
// Similar to other Kea components, Netconf also uses logging.
"loggers": [
{
"name": "kea-netconf",
"output_options": [
{
//"output": "/var/log/kea-netconf.log",
"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 being 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"
}
],
// You can change the severity to DEBUG, INFO, WARN, ERROR or
// CRIT. For DEBUG level, you can also additionally specify
// debuglevel (0-99, higher = more verbose). All configurations
// are logged on DEBUG/55.
"severity": "INFO",
"debuglevel": 0
}
]
}
}
|
