// 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 } ] } }