kea-1.6.2/0000755000175000017500000000000013623761246007273 500000000000000kea-1.6.2/AUTHORS0000644000175000017500000001530513623761160010262 00000000000000 Kea authors and contributors ------------------------------ Primary developers: - Tomek Mrugalski (lead developer: DHCPv4, DHCPv6 components, prefix delegation, memfile, database interface, core libdhcp++, host reservation, MAC extraction in DHCPv6, statistics manager, kea-shell, netconf, flex/bison parsers, flex-id, documentation) - Stephen Morris (Hooks, MySQL) - Marcin Siodelski (DHCPv4, DHCPv6 components, options handling, perfdhcp, host reservation, lease file cleanup, lease expiration, control agent, shared networks, high availability, config backend) - Thomas Markwalder (DDNS, user_chk, global host reservations, stat commands, congestion handling, config backend) - Jeremy C. Reed (documentation, build system, testing, release engineering) - Wlodek Wencel (testing, release engineering) - Francis Dupont (crypto, flex/bison parsers, perfdhcp, control agent, radius, netconf, config backend) - Brian Reid (logo design) - Shawn Routhier (lease file cleanup) - Michal Nowikowski (testing, hammer, release engineering) - Razvan Becheriu (cassandra, sysrepo) - Suzanne Goldlust (documentation) Primary area of work mentioned in parentheses. The list is in a roughly chronological order. Kea is using parts of the code of now defunct BIND 10 project. The following people contributed to BIND 10 code: Chen Zhengzhang Dmitriy Volodin Evan Hunt Francis Dupont Haidong Wang Haikuo Zhang Han Feng Jelte Jansen Jeremy C. Reed Xie Jiagui Jin Jian JINMEI Tatuya John DuBois Kazunori Fujiwara Marcin Siodelski Michael Graff Michal Vaner Mukund Sivaraman Naoki Kambe Paul Selkirk Shane Kerr Shen Tingting Stephen Morris Thomas Markwalder Tomek Mrugalski Yoshitaka Aharen Zhang Likun We have received the following contributions: - David Carlier 2013-11: memfile fixes 2013-12: better error handling when port is in use 2013-12: interface detection for BSD systems 2014-04: PostgreSQL support - Jiri Popelka, Red Hat 2014-08: config files examples permission fix 2014-08: compilation fix for armv7 2014-08: configure.ac update: AC_PROG_LIBTOOL => LT_INIT 2014-08: PostgreSQL compilation fix on i686 2015-12: compilation fix in MySQL host data source 2016-02: Fixed missing slashes in path_replacer.sh - Adam Osuchowski, Silesian University of Technology 2014-09: Examples corrected in Kea ARM 2019-02: Hooks installation directory fixed. 2019-02: Possible syntax error in keactrl fixed. - Nicolas Chaigneau, Capgemini 2014-09: Fix for interfaces with multiple addresses in perfdhcp 2015-11: query4 parameter added to pkt4_send hook point - Marcin Wyszynki, Facebook 2014-11: Export CalloutManager headers for testing statically linked libraries. - David Gutierrez Rueda, CERN 2014-12: Support for client link-address option in DHCPv6 (RFC6939) - Adam Kalmus, Gdansk University of Technology 2014-12: Extract MAC address from DUID-LL and DUID-LLT types 2015-01: Extract MAC address from remote-id 2015-05: MySQL schema extended to cover host reservation 2015-10: Common MySQL Connector Pool 2015-12: MySQL host data source implemented 2016-02: IPv6 reservations implemented - Jinmei Tatuya 2015-10: Pkt4o6 class improvements 2015-11: split Dhcpv4Srv::run() into run() and processPacket() - Sebastien Couture, Ubity Inc 2015-12: Fixes to MySQL schema creation - Angelo Failla, Facebook 2016-04: Fixes for transaction id generation in perfdhcp 2016-08: Using a file as a source of MAC addresses to be used in new transactions. 2016-08: Support for generating relayed DHCPv6 traffic. - Razvan Becheriu, Qualitance 2016-05: Added support for Cassandra 2017-12: Significant update for Cassandra backend 2018-01: Host reservations for Cassandra 2018-01: Various changes (github 54) 2018-02: Support for Google benchmark added (github 36) 2018-02: exit-wait-time param added to perfdhcp (github 55) 2018-03: Cassandra: host delete, fixed DHCPv4 fields, user contexts, Postgres: hwaddress source, type storage (github 70) 2018-07: Sysrepo detection improvements - Patrik Lundin 2016-07: Replace test by expr for < in configure.ac 2016-11: Fixes in Lease File Cleanup unit test - Michal Humpula (mihu) 2016-07: Response to DHCPINFORM is sent to port 68 - Andreas Rammhold (andir) 2016-09: Compilation fixes for GCC 6, using C++14. - Yusef Shaban (xxwolfsrainxx) 2016-09: MySQL database creation scripts use single quotes for strings to avoid issues with creation of the database when MySQL server operates in ANSI_QUOTES mode. - Cristian Secareanu, Qualitance 2016-10: Support for IPv6 prefix and PDEXCLUDE option - Andrei Pavel, Qualitance 2016-10: Support for DHCPv6 options defined in RFC6603 and RFC7598 2017-02: Doxygen support updated to 1.8.11 2017-02: Improved PgSQL backend version handling 2017-02: Numerous spelling mistakes 2017-12: Significant update for Cassandra backend 2018-01: Host reservations for Cassandra 2018-01: Uniform compilation 2018-01: Various changes (github 54,43) 2018-02: Documentation upgraded to DocBook 5.0 2018-02: --with-dhcp-XXX renamed to --with-XXX 2018-02: Support for Google benchmark added (github 36) 2018-02: exit-wait-time param added to perfdhcp (github 55) 2018-07: Sysrepo detection improvements - Vincent Legout 2016-11: Fixed serveral spelling mistakes - Sebasian Schrader 2017-01: Fix build dir in doc/guide/Makefile.am - Marvin Frick (MrMarvin) 2017-04: -h and --host parameters added to kea-admin - Olivier Clavel (zeitounator) 2017-04: Improvements in valgrind test script - Josh Soref (jsoref) 2017-07: Many spelling corrections. - Walt Steverson (waltsteverson) 2017-07: Compilation fixed for Alpine Linux 2017-07: option6_pdexclude.h now installed properly - Ebben Aries 2017-10: Option length checks improvements for the V-I Vendor Class option - Ryan Goodfellow (rcgoodfellow) 2018-01: Fix kea-admin typo breaking lease-dump - Sunil Mayya 2018-07: support for Authentication option in DHCPv6 2018-07: support storage of Authentication keys in host structure 2018-08: Optimized query for host reservation from the backends - Piotr Strzyżewski 2018-07: YANG model for DHCPv4 Kea - Vicky Risk 2018-08: Documentation clean up 2018-10: API documentation clean ups - Franciszek Gorski 2018-10: Makefile bug fixed 2019-07: Statistics enhancements - Suzanne Goldlust 2018-10: API documentation - lpaserati, Thorsten Krohn 2018-11: Two bugfixes in kea-admin kea-1.6.2/Makefile.am0000644000175000017500000001312613623761160011245 00000000000000ACLOCAL_AMFLAGS = -I m4macros ${ACLOCAL_FLAGS} # ^^^^^^^^ This has to be the first line and cannot come later in this # Makefile.am due to some bork in some versions of autotools. # We now build doc after src/, because docgen, a tool to generate API # documentation requires libkea-exceptions and libkea-cc. SUBDIRS = tools . ext src doc m4macros @PREMIUM_DIR@ @CONTRIB_DIR@ USE_LCOV=@USE_LCOV@ LCOV=@LCOV@ GENHTML=@GENHTML@ DISTCHECK_GTEST_CONFIGURE_FLAG=@DISTCHECK_GTEST_CONFIGURE_FLAG@ DISTCHECK_CRYPTO_CONFIGURE_FLAG=@DISTCHECK_CRYPTO_CONFIGURE_FLAG@ DISTCHECK_BOOST_CONFIGURE_FLAG=@DISTCHECK_BOOST_CONFIGURE_FLAG@ DISTCHECK_LOG4CPLUS_CONFIGURE_FLAG=@DISTCHECK_LOG4CPLUS_CONFIGURE_FLAG@ DISTCHECK_PERFDHCP_CONFIGURE_FLAG=@DISTCHECK_PERFDHCP_CONFIGURE_FLAG@ DISTCHECK_KEA_SHELL_CONFIGURE_FLAG=@DISTCHECK_KEA_SHELL_CONFIGURE_FLAG@ DISTCHECK_PREMIUM_CONFIGURE_FLAG=@DISTCHECK_PREMIUM_CONFIGURE_FLAG@ DISTCHECK_CONTRIB_CONFIGURE_FLAG=@DISTCHECK_CONTRIB_CONFIGURE_FLAG@ DISTCHECK_SYSREPO_CONFIGURE_FLAG=@DISTCHECK_SYSREPO_CONFIGURE_FLAG@ OVERALL_COVERAGE_DIR=$(abs_top_builddir)/coverage-cpp-html DISTCLEANFILES = config.report # When running distcheck target, do not install the configurations DISTCHECK_CONFIGURE_FLAGS = --disable-install-configurations # Use same --with-gtest flag if set DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_GTEST_CONFIGURE_FLAG) # Keep the crypto backend config DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_CRYPTO_CONFIGURE_FLAG) # Keep the Boost configuration which becomes sensible DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_BOOST_CONFIGURE_FLAG) # Keep the log4cplus path too DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_LOG4CPLUS_CONFIGURE_FLAG) # Keep perfdhcp if enabled DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_PERFDHCP_CONFIGURE_FLAG) # Keep kea-shell if enabled DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_KEA_SHELL_CONFIGURE_FLAG) # Keep the premium config DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_PREMIUM_CONFIGURE_FLAG) # Keep the contrib config DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_CONTRIB_CONFIGURE_FLAG) # keerp the sysrepo config DISTCHECK_CONFIGURE_FLAGS += $(DISTCHECK_SYSREPO_CONFIGURE_FLAG) dist_doc_DATA = AUTHORS COPYING ChangeLog README CONTRIBUTING.md .PHONY: check-valgrind check-valgrind-suppress check-valgrind: if HAVE_VALGRIND @VALGRIND_COMMAND="$(VALGRIND) -q --gen-suppressions=all --track-origins=yes --num-callers=48 --leak-check=full --fullpath-after=" \ make -C $(abs_top_builddir) check else @echo "*** Valgrind is required for check-valgrind ***"; exit 1; endif check-valgrind-suppress: if HAVE_VALGRIND @VALGRIND_COMMAND="$(VALGRIND) -q --gen-suppressions=all --track-origins=yes --error-exitcode=1 --suppressions=$(abs_top_srcdir)/src/valgrind-suppressions --suppressions=$(abs_top_srcdir)/src/valgrind-suppressions.revisit --num-callers=48 --leak-check=full --fullpath-after=" \ make -C $(abs_top_builddir) check else @echo "*** Valgrind is required for check-valgrind-suppress ***"; exit 1; endif clean-cpp-coverage: @if [ $(USE_LCOV) = yes ] ; then \ $(LCOV) --directory . --zerocounters; \ rm -rf $(OVERALL_COVERAGE_DIR); \ else \ echo "C++ code coverage not enabled at configuration time." ; \ echo "Use: ./configure --with-lcov" ; \ fi perform-coverage: find src -mindepth 2 -maxdepth 2 -type d | xargs -I{} bash -c "cd {}; make check || true" report-cpp-coverage: if HAVE_BOTAN BOTAN_PATH=botan/\* else BOTAN_PATH= endif if HAVE_OPENSSL OPENSSL_PATH=openssl/\* else OPENSSL_PATH= endif @if [ $(USE_LCOV) = yes ] ; then \ $(LCOV) --capture --directory . \ --ignore-errors gcov,source,graph \ --output-file all.info; \ $(LCOV) --remove all.info \ c++/* \ boost/\* \ if HAVE_BOTAN botan/\* \ endif ext/coroutine/\* \ gtest/\* \ include/\* \ lib/\eval/\* \ log4cplus/\* \ unittests/\* \ tests/\* \ testutils/\* \ valgrind/\* \ $(BOTAN_PATH) \ $(OPENSSL_PATH) \ --ignore-errors gcov,source,graph \ --output report.info; \ sed --in-place --expression "s|$(abs_top_srcdir)|$(abs_top_builddir)|g" report.info; \ "$(GENHTML)" --frames --show-details --title 'Kea code coverage report' --legend \ --function-coverage --ignore-errors source --demangle-cpp \ --output "$(OVERALL_COVERAGE_DIR)" report.info; \ printf "Generated C++ code coverage report in HTML at %s.\n" "$(OVERALL_COVERAGE_DIR)"; \ else \ echo "C++ code coverage not enabled at configuration time." ; \ echo "Use: ./configure --with-lcov" ; \ fi # for c++ test coverage .NOTPARALLEL: coverage coverage: clean-coverage perform-coverage report-coverage clean-coverage: clean-cpp-coverage report-coverage: report-cpp-coverage # for static C++ check using cppcheck (when available) cppcheck: cppcheck -I./src/lib -I./src/bin --enable=all \ --suppressions-list=src/cppcheck-suppress.lst --inline-suppr \ --quiet --error-exitcode=1 \ --template '{file}:{line}: check_fail: {message} ({severity},{id})' \ src # this is a shortcut that builds only documentation dependecies and documentation itself docs: $(MAKE) -C doc/sphinx # These steps are necessary during installation install-exec-hook: mkdir -p $(DESTDIR)${localstatedir}/log/ mkdir -p $(DESTDIR)${localstatedir}/lib/${PACKAGE_NAME} mkdir -p $(DESTDIR)${runstatedir}/${PACKAGE_NAME} EXTRA_DIST = tools/path_replacer.sh EXTRA_DIST += tools/mk_cfgrpt.sh #### include external sources in the distributed tarball: EXTRA_DIST += ext/coroutine/coroutine.hpp CLEANFILES = $(abs_top_builddir)/logger_lockfile # config.h may be included by headers supplied for building user-written # hooks libraries, so we need to include it in the distribution. pkginclude_HEADERS = config.h kea_version.h kea-1.6.2/config.sub0000755000175000017500000010676313623761177011216 00000000000000#! /bin/sh # Configuration validation subroutine script. # Copyright 1992-2016 Free Software Foundation, Inc. timestamp='2016-11-04' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, see . # # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that # program. This Exception is an additional permission under section 7 # of the GNU General Public License, version 3 ("GPLv3"). # Please send patches to . # # Configuration subroutine to validate and canonicalize a configuration type. # Supply the specified configuration type as an argument. # If it is invalid, we print an error message on stderr and exit with code 1. # Otherwise, we print the canonical config type on stdout and succeed. # You can get the latest version of this script from: # http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub # This file is supposed to be the same for all GNU packages # and recognize all the CPU types, system types and aliases # that are meaningful with *any* GNU software. # Each package is responsible for reporting which valid configurations # it does not support. The user should be able to distinguish # a failure to support a valid configuration from a meaningless # configuration. # The goal of this file is to map all the various variations of a given # machine specification into a single specification in the form: # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM # or in some cases, the newer four-part form: # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM # It is wrong to echo any other type of specification. me=`echo "$0" | sed -e 's,.*/,,'` usage="\ Usage: $0 [OPTION] CPU-MFR-OPSYS or ALIAS Canonicalize a configuration name. Operation modes: -h, --help print this help, then exit -t, --time-stamp print date of last modification, then exit -v, --version print version number, then exit Report bugs and patches to ." version="\ GNU config.sub ($timestamp) Copyright 1992-2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." help=" Try \`$me --help' for more information." # Parse command line while test $# -gt 0 ; do case $1 in --time-stamp | --time* | -t ) echo "$timestamp" ; exit ;; --version | -v ) echo "$version" ; exit ;; --help | --h* | -h ) echo "$usage"; exit ;; -- ) # Stop option processing shift; break ;; - ) # Use stdin as input. break ;; -* ) echo "$me: invalid option $1$help" exit 1 ;; *local*) # First pass through any local machine types. echo $1 exit ;; * ) break ;; esac done case $# in 0) echo "$me: missing argument$help" >&2 exit 1;; 1) ;; *) echo "$me: too many arguments$help" >&2 exit 1;; esac # Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any). # Here we must recognize all the valid KERNEL-OS combinations. maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'` case $maybe_os in nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc | linux-newlib* | \ linux-musl* | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | \ knetbsd*-gnu* | netbsd*-gnu* | netbsd*-eabi* | \ kopensolaris*-gnu* | cloudabi*-eabi* | \ storm-chaos* | os2-emx* | rtmk-nova*) os=-$maybe_os basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'` ;; android-linux) os=-linux-android basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown ;; *) basic_machine=`echo $1 | sed 's/-[^-]*$//'` if [ $basic_machine != $1 ] then os=`echo $1 | sed 's/.*-/-/'` else os=; fi ;; esac ### Let's recognize common machines as not being operating systems so ### that things like config.sub decstation-3100 work. We also ### recognize some manufacturers as not being operating systems, so we ### can provide default operating systems below. case $os in -sun*os*) # Prevent following clause from handling this invalid input. ;; -dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \ -att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \ -unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \ -convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\ -c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \ -harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \ -apple | -axis | -knuth | -cray | -microblaze*) os= basic_machine=$1 ;; -bluegene*) os=-cnk ;; -sim | -cisco | -oki | -wec | -winbond) os= basic_machine=$1 ;; -scout) ;; -wrs) os=-vxworks basic_machine=$1 ;; -chorusos*) os=-chorusos basic_machine=$1 ;; -chorusrdb) os=-chorusrdb basic_machine=$1 ;; -hiux*) os=-hiuxwe2 ;; -sco6) os=-sco5v6 basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -sco5) os=-sco3.2v5 basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -sco4) os=-sco3.2v4 basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -sco3.2.[4-9]*) os=`echo $os | sed -e 's/sco3.2./sco3.2v/'` basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -sco3.2v[4-9]*) # Don't forget version if it is 3.2v4 or newer. basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -sco5v6*) # Don't forget version if it is 3.2v4 or newer. basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -sco*) os=-sco3.2v2 basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -udk*) basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -isc) os=-isc2.2 basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -clix*) basic_machine=clipper-intergraph ;; -isc*) basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; -lynx*178) os=-lynxos178 ;; -lynx*5) os=-lynxos5 ;; -lynx*) os=-lynxos ;; -ptx*) basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'` ;; -windowsnt*) os=`echo $os | sed -e 's/windowsnt/winnt/'` ;; -psos*) os=-psos ;; -mint | -mint[0-9]*) basic_machine=m68k-atari os=-mint ;; esac # Decode aliases for certain CPU-COMPANY combinations. case $basic_machine in # Recognize the basic CPU types without company name. # Some are omitted here because they have special meanings below. 1750a | 580 \ | a29k \ | aarch64 | aarch64_be \ | alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \ | alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \ | am33_2.0 \ | arc | arceb \ | arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv7[arm] \ | avr | avr32 \ | ba \ | be32 | be64 \ | bfin \ | c4x | c8051 | clipper \ | d10v | d30v | dlx | dsp16xx \ | e2k | epiphany \ | fido | fr30 | frv | ft32 \ | h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \ | hexagon \ | i370 | i860 | i960 | ia64 \ | ip2k | iq2000 \ | k1om \ | le32 | le64 \ | lm32 \ | m32c | m32r | m32rle | m68000 | m68k | m88k \ | maxq | mb | microblaze | microblazeel | mcore | mep | metag \ | mips | mipsbe | mipseb | mipsel | mipsle \ | mips16 \ | mips64 | mips64el \ | mips64octeon | mips64octeonel \ | mips64orion | mips64orionel \ | mips64r5900 | mips64r5900el \ | mips64vr | mips64vrel \ | mips64vr4100 | mips64vr4100el \ | mips64vr4300 | mips64vr4300el \ | mips64vr5000 | mips64vr5000el \ | mips64vr5900 | mips64vr5900el \ | mipsisa32 | mipsisa32el \ | mipsisa32r2 | mipsisa32r2el \ | mipsisa32r6 | mipsisa32r6el \ | mipsisa64 | mipsisa64el \ | mipsisa64r2 | mipsisa64r2el \ | mipsisa64r6 | mipsisa64r6el \ | mipsisa64sb1 | mipsisa64sb1el \ | mipsisa64sr71k | mipsisa64sr71kel \ | mipsr5900 | mipsr5900el \ | mipstx39 | mipstx39el \ | mn10200 | mn10300 \ | moxie \ | mt \ | msp430 \ | nds32 | nds32le | nds32be \ | nios | nios2 | nios2eb | nios2el \ | ns16k | ns32k \ | open8 | or1k | or1knd | or32 \ | pdp10 | pdp11 | pj | pjl \ | powerpc | powerpc64 | powerpc64le | powerpcle \ | pru \ | pyramid \ | riscv32 | riscv64 \ | rl78 | rx \ | score \ | sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[234]eb | sheb | shbe | shle | sh[1234]le | sh3ele \ | sh64 | sh64le \ | sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | sparclite \ | sparcv8 | sparcv9 | sparcv9b | sparcv9v \ | spu \ | tahoe | tic4x | tic54x | tic55x | tic6x | tic80 | tron \ | ubicom32 \ | v850 | v850e | v850e1 | v850e2 | v850es | v850e2v3 \ | visium \ | we32k \ | x86 | xc16x | xstormy16 | xtensa \ | z8k | z80) basic_machine=$basic_machine-unknown ;; c54x) basic_machine=tic54x-unknown ;; c55x) basic_machine=tic55x-unknown ;; c6x) basic_machine=tic6x-unknown ;; leon|leon[3-9]) basic_machine=sparc-$basic_machine ;; m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | nvptx | picochip) basic_machine=$basic_machine-unknown os=-none ;; m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65 | z8k) ;; ms1) basic_machine=mt-unknown ;; strongarm | thumb | xscale) basic_machine=arm-unknown ;; xgate) basic_machine=$basic_machine-unknown os=-none ;; xscaleeb) basic_machine=armeb-unknown ;; xscaleel) basic_machine=armel-unknown ;; # We use `pc' rather than `unknown' # because (1) that's what they normally are, and # (2) the word "unknown" tends to confuse beginning users. i*86 | x86_64) basic_machine=$basic_machine-pc ;; # Object if more than one company name word. *-*-*) echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 exit 1 ;; # Recognize the basic CPU types with company name. 580-* \ | a29k-* \ | aarch64-* | aarch64_be-* \ | alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \ | alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \ | alphapca5[67]-* | alpha64pca5[67]-* | arc-* | arceb-* \ | arm-* | armbe-* | armle-* | armeb-* | armv*-* \ | avr-* | avr32-* \ | ba-* \ | be32-* | be64-* \ | bfin-* | bs2000-* \ | c[123]* | c30-* | [cjt]90-* | c4x-* \ | c8051-* | clipper-* | craynv-* | cydra-* \ | d10v-* | d30v-* | dlx-* \ | e2k-* | elxsi-* \ | f30[01]-* | f700-* | fido-* | fr30-* | frv-* | fx80-* \ | h8300-* | h8500-* \ | hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \ | hexagon-* \ | i*86-* | i860-* | i960-* | ia64-* \ | ip2k-* | iq2000-* \ | k1om-* \ | le32-* | le64-* \ | lm32-* \ | m32c-* | m32r-* | m32rle-* \ | m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \ | m88110-* | m88k-* | maxq-* | mcore-* | metag-* \ | microblaze-* | microblazeel-* \ | mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \ | mips16-* \ | mips64-* | mips64el-* \ | mips64octeon-* | mips64octeonel-* \ | mips64orion-* | mips64orionel-* \ | mips64r5900-* | mips64r5900el-* \ | mips64vr-* | mips64vrel-* \ | mips64vr4100-* | mips64vr4100el-* \ | mips64vr4300-* | mips64vr4300el-* \ | mips64vr5000-* | mips64vr5000el-* \ | mips64vr5900-* | mips64vr5900el-* \ | mipsisa32-* | mipsisa32el-* \ | mipsisa32r2-* | mipsisa32r2el-* \ | mipsisa32r6-* | mipsisa32r6el-* \ | mipsisa64-* | mipsisa64el-* \ | mipsisa64r2-* | mipsisa64r2el-* \ | mipsisa64r6-* | mipsisa64r6el-* \ | mipsisa64sb1-* | mipsisa64sb1el-* \ | mipsisa64sr71k-* | mipsisa64sr71kel-* \ | mipsr5900-* | mipsr5900el-* \ | mipstx39-* | mipstx39el-* \ | mmix-* \ | mt-* \ | msp430-* \ | nds32-* | nds32le-* | nds32be-* \ | nios-* | nios2-* | nios2eb-* | nios2el-* \ | none-* | np1-* | ns16k-* | ns32k-* \ | open8-* \ | or1k*-* \ | orion-* \ | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* \ | pru-* \ | pyramid-* \ | riscv32-* | riscv64-* \ | rl78-* | romp-* | rs6000-* | rx-* \ | sh-* | sh[1234]-* | sh[24]a-* | sh[24]aeb-* | sh[23]e-* | sh[34]eb-* | sheb-* | shbe-* \ | shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \ | sparc-* | sparc64-* | sparc64b-* | sparc64v-* | sparc86x-* | sparclet-* \ | sparclite-* \ | sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | sv1-* | sx*-* \ | tahoe-* \ | tic30-* | tic4x-* | tic54x-* | tic55x-* | tic6x-* | tic80-* \ | tile*-* \ | tron-* \ | ubicom32-* \ | v850-* | v850e-* | v850e1-* | v850es-* | v850e2-* | v850e2v3-* \ | vax-* \ | visium-* \ | we32k-* \ | x86-* | x86_64-* | xc16x-* | xps100-* \ | xstormy16-* | xtensa*-* \ | ymp-* \ | z8k-* | z80-*) ;; # Recognize the basic CPU types without company name, with glob match. xtensa*) basic_machine=$basic_machine-unknown ;; # Recognize the various machine names and aliases which stand # for a CPU type and a company and sometimes even an OS. 386bsd) basic_machine=i386-unknown os=-bsd ;; 3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc) basic_machine=m68000-att ;; 3b*) basic_machine=we32k-att ;; a29khif) basic_machine=a29k-amd os=-udi ;; abacus) basic_machine=abacus-unknown ;; adobe68k) basic_machine=m68010-adobe os=-scout ;; alliant | fx80) basic_machine=fx80-alliant ;; altos | altos3068) basic_machine=m68k-altos ;; am29k) basic_machine=a29k-none os=-bsd ;; amd64) basic_machine=x86_64-pc ;; amd64-*) basic_machine=x86_64-`echo $basic_machine | sed 's/^[^-]*-//'` ;; amdahl) basic_machine=580-amdahl os=-sysv ;; amiga | amiga-*) basic_machine=m68k-unknown ;; amigaos | amigados) basic_machine=m68k-unknown os=-amigaos ;; amigaunix | amix) basic_machine=m68k-unknown os=-sysv4 ;; apollo68) basic_machine=m68k-apollo os=-sysv ;; apollo68bsd) basic_machine=m68k-apollo os=-bsd ;; aros) basic_machine=i386-pc os=-aros ;; asmjs) basic_machine=asmjs-unknown ;; aux) basic_machine=m68k-apple os=-aux ;; balance) basic_machine=ns32k-sequent os=-dynix ;; blackfin) basic_machine=bfin-unknown os=-linux ;; blackfin-*) basic_machine=bfin-`echo $basic_machine | sed 's/^[^-]*-//'` os=-linux ;; bluegene*) basic_machine=powerpc-ibm os=-cnk ;; c54x-*) basic_machine=tic54x-`echo $basic_machine | sed 's/^[^-]*-//'` ;; c55x-*) basic_machine=tic55x-`echo $basic_machine | sed 's/^[^-]*-//'` ;; c6x-*) basic_machine=tic6x-`echo $basic_machine | sed 's/^[^-]*-//'` ;; c90) basic_machine=c90-cray os=-unicos ;; cegcc) basic_machine=arm-unknown os=-cegcc ;; convex-c1) basic_machine=c1-convex os=-bsd ;; convex-c2) basic_machine=c2-convex os=-bsd ;; convex-c32) basic_machine=c32-convex os=-bsd ;; convex-c34) basic_machine=c34-convex os=-bsd ;; convex-c38) basic_machine=c38-convex os=-bsd ;; cray | j90) basic_machine=j90-cray os=-unicos ;; craynv) basic_machine=craynv-cray os=-unicosmp ;; cr16 | cr16-*) basic_machine=cr16-unknown os=-elf ;; crds | unos) basic_machine=m68k-crds ;; crisv32 | crisv32-* | etraxfs*) basic_machine=crisv32-axis ;; cris | cris-* | etrax*) basic_machine=cris-axis ;; crx) basic_machine=crx-unknown os=-elf ;; da30 | da30-*) basic_machine=m68k-da30 ;; decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn) basic_machine=mips-dec ;; decsystem10* | dec10*) basic_machine=pdp10-dec os=-tops10 ;; decsystem20* | dec20*) basic_machine=pdp10-dec os=-tops20 ;; delta | 3300 | motorola-3300 | motorola-delta \ | 3300-motorola | delta-motorola) basic_machine=m68k-motorola ;; delta88) basic_machine=m88k-motorola os=-sysv3 ;; dicos) basic_machine=i686-pc os=-dicos ;; djgpp) basic_machine=i586-pc os=-msdosdjgpp ;; dpx20 | dpx20-*) basic_machine=rs6000-bull os=-bosx ;; dpx2* | dpx2*-bull) basic_machine=m68k-bull os=-sysv3 ;; e500v[12]) basic_machine=powerpc-unknown os=$os"spe" ;; e500v[12]-*) basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'` os=$os"spe" ;; ebmon29k) basic_machine=a29k-amd os=-ebmon ;; elxsi) basic_machine=elxsi-elxsi os=-bsd ;; encore | umax | mmax) basic_machine=ns32k-encore ;; es1800 | OSE68k | ose68k | ose | OSE) basic_machine=m68k-ericsson os=-ose ;; fx2800) basic_machine=i860-alliant ;; genix) basic_machine=ns32k-ns ;; gmicro) basic_machine=tron-gmicro os=-sysv ;; go32) basic_machine=i386-pc os=-go32 ;; h3050r* | hiux*) basic_machine=hppa1.1-hitachi os=-hiuxwe2 ;; h8300hms) basic_machine=h8300-hitachi os=-hms ;; h8300xray) basic_machine=h8300-hitachi os=-xray ;; h8500hms) basic_machine=h8500-hitachi os=-hms ;; harris) basic_machine=m88k-harris os=-sysv3 ;; hp300-*) basic_machine=m68k-hp ;; hp300bsd) basic_machine=m68k-hp os=-bsd ;; hp300hpux) basic_machine=m68k-hp os=-hpux ;; hp3k9[0-9][0-9] | hp9[0-9][0-9]) basic_machine=hppa1.0-hp ;; hp9k2[0-9][0-9] | hp9k31[0-9]) basic_machine=m68000-hp ;; hp9k3[2-9][0-9]) basic_machine=m68k-hp ;; hp9k6[0-9][0-9] | hp6[0-9][0-9]) basic_machine=hppa1.0-hp ;; hp9k7[0-79][0-9] | hp7[0-79][0-9]) basic_machine=hppa1.1-hp ;; hp9k78[0-9] | hp78[0-9]) # FIXME: really hppa2.0-hp basic_machine=hppa1.1-hp ;; hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893) # FIXME: really hppa2.0-hp basic_machine=hppa1.1-hp ;; hp9k8[0-9][13679] | hp8[0-9][13679]) basic_machine=hppa1.1-hp ;; hp9k8[0-9][0-9] | hp8[0-9][0-9]) basic_machine=hppa1.0-hp ;; hppa-next) os=-nextstep3 ;; hppaosf) basic_machine=hppa1.1-hp os=-osf ;; hppro) basic_machine=hppa1.1-hp os=-proelf ;; i370-ibm* | ibm*) basic_machine=i370-ibm ;; i*86v32) basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` os=-sysv32 ;; i*86v4*) basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` os=-sysv4 ;; i*86v) basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` os=-sysv ;; i*86sol2) basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'` os=-solaris2 ;; i386mach) basic_machine=i386-mach os=-mach ;; i386-vsta | vsta) basic_machine=i386-unknown os=-vsta ;; iris | iris4d) basic_machine=mips-sgi case $os in -irix*) ;; *) os=-irix4 ;; esac ;; isi68 | isi) basic_machine=m68k-isi os=-sysv ;; leon-*|leon[3-9]-*) basic_machine=sparc-`echo $basic_machine | sed 's/-.*//'` ;; m68knommu) basic_machine=m68k-unknown os=-linux ;; m68knommu-*) basic_machine=m68k-`echo $basic_machine | sed 's/^[^-]*-//'` os=-linux ;; m88k-omron*) basic_machine=m88k-omron ;; magnum | m3230) basic_machine=mips-mips os=-sysv ;; merlin) basic_machine=ns32k-utek os=-sysv ;; microblaze*) basic_machine=microblaze-xilinx ;; mingw64) basic_machine=x86_64-pc os=-mingw64 ;; mingw32) basic_machine=i686-pc os=-mingw32 ;; mingw32ce) basic_machine=arm-unknown os=-mingw32ce ;; miniframe) basic_machine=m68000-convergent ;; *mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*) basic_machine=m68k-atari os=-mint ;; mips3*-*) basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'` ;; mips3*) basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown ;; monitor) basic_machine=m68k-rom68k os=-coff ;; morphos) basic_machine=powerpc-unknown os=-morphos ;; moxiebox) basic_machine=moxie-unknown os=-moxiebox ;; msdos) basic_machine=i386-pc os=-msdos ;; ms1-*) basic_machine=`echo $basic_machine | sed -e 's/ms1-/mt-/'` ;; msys) basic_machine=i686-pc os=-msys ;; mvs) basic_machine=i370-ibm os=-mvs ;; nacl) basic_machine=le32-unknown os=-nacl ;; ncr3000) basic_machine=i486-ncr os=-sysv4 ;; netbsd386) basic_machine=i386-unknown os=-netbsd ;; netwinder) basic_machine=armv4l-rebel os=-linux ;; news | news700 | news800 | news900) basic_machine=m68k-sony os=-newsos ;; news1000) basic_machine=m68030-sony os=-newsos ;; news-3600 | risc-news) basic_machine=mips-sony os=-newsos ;; necv70) basic_machine=v70-nec os=-sysv ;; next | m*-next ) basic_machine=m68k-next case $os in -nextstep* ) ;; -ns2*) os=-nextstep2 ;; *) os=-nextstep3 ;; esac ;; nh3000) basic_machine=m68k-harris os=-cxux ;; nh[45]000) basic_machine=m88k-harris os=-cxux ;; nindy960) basic_machine=i960-intel os=-nindy ;; mon960) basic_machine=i960-intel os=-mon960 ;; nonstopux) basic_machine=mips-compaq os=-nonstopux ;; np1) basic_machine=np1-gould ;; neo-tandem) basic_machine=neo-tandem ;; nse-tandem) basic_machine=nse-tandem ;; nsr-tandem) basic_machine=nsr-tandem ;; op50n-* | op60c-*) basic_machine=hppa1.1-oki os=-proelf ;; openrisc | openrisc-*) basic_machine=or32-unknown ;; os400) basic_machine=powerpc-ibm os=-os400 ;; OSE68000 | ose68000) basic_machine=m68000-ericsson os=-ose ;; os68k) basic_machine=m68k-none os=-os68k ;; pa-hitachi) basic_machine=hppa1.1-hitachi os=-hiuxwe2 ;; paragon) basic_machine=i860-intel os=-osf ;; parisc) basic_machine=hppa-unknown os=-linux ;; parisc-*) basic_machine=hppa-`echo $basic_machine | sed 's/^[^-]*-//'` os=-linux ;; pbd) basic_machine=sparc-tti ;; pbb) basic_machine=m68k-tti ;; pc532 | pc532-*) basic_machine=ns32k-pc532 ;; pc98) basic_machine=i386-pc ;; pc98-*) basic_machine=i386-`echo $basic_machine | sed 's/^[^-]*-//'` ;; pentium | p5 | k5 | k6 | nexgen | viac3) basic_machine=i586-pc ;; pentiumpro | p6 | 6x86 | athlon | athlon_*) basic_machine=i686-pc ;; pentiumii | pentium2 | pentiumiii | pentium3) basic_machine=i686-pc ;; pentium4) basic_machine=i786-pc ;; pentium-* | p5-* | k5-* | k6-* | nexgen-* | viac3-*) basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'` ;; pentiumpro-* | p6-* | 6x86-* | athlon-*) basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'` ;; pentiumii-* | pentium2-* | pentiumiii-* | pentium3-*) basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'` ;; pentium4-*) basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'` ;; pn) basic_machine=pn-gould ;; power) basic_machine=power-ibm ;; ppc | ppcbe) basic_machine=powerpc-unknown ;; ppc-* | ppcbe-*) basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'` ;; ppcle | powerpclittle) basic_machine=powerpcle-unknown ;; ppcle-* | powerpclittle-*) basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'` ;; ppc64) basic_machine=powerpc64-unknown ;; ppc64-*) basic_machine=powerpc64-`echo $basic_machine | sed 's/^[^-]*-//'` ;; ppc64le | powerpc64little) basic_machine=powerpc64le-unknown ;; ppc64le-* | powerpc64little-*) basic_machine=powerpc64le-`echo $basic_machine | sed 's/^[^-]*-//'` ;; ps2) basic_machine=i386-ibm ;; pw32) basic_machine=i586-unknown os=-pw32 ;; rdos | rdos64) basic_machine=x86_64-pc os=-rdos ;; rdos32) basic_machine=i386-pc os=-rdos ;; rom68k) basic_machine=m68k-rom68k os=-coff ;; rm[46]00) basic_machine=mips-siemens ;; rtpc | rtpc-*) basic_machine=romp-ibm ;; s390 | s390-*) basic_machine=s390-ibm ;; s390x | s390x-*) basic_machine=s390x-ibm ;; sa29200) basic_machine=a29k-amd os=-udi ;; sb1) basic_machine=mipsisa64sb1-unknown ;; sb1el) basic_machine=mipsisa64sb1el-unknown ;; sde) basic_machine=mipsisa32-sde os=-elf ;; sei) basic_machine=mips-sei os=-seiux ;; sequent) basic_machine=i386-sequent ;; sh) basic_machine=sh-hitachi os=-hms ;; sh5el) basic_machine=sh5le-unknown ;; sh64) basic_machine=sh64-unknown ;; sparclite-wrs | simso-wrs) basic_machine=sparclite-wrs os=-vxworks ;; sps7) basic_machine=m68k-bull os=-sysv2 ;; spur) basic_machine=spur-unknown ;; st2000) basic_machine=m68k-tandem ;; stratus) basic_machine=i860-stratus os=-sysv4 ;; strongarm-* | thumb-*) basic_machine=arm-`echo $basic_machine | sed 's/^[^-]*-//'` ;; sun2) basic_machine=m68000-sun ;; sun2os3) basic_machine=m68000-sun os=-sunos3 ;; sun2os4) basic_machine=m68000-sun os=-sunos4 ;; sun3os3) basic_machine=m68k-sun os=-sunos3 ;; sun3os4) basic_machine=m68k-sun os=-sunos4 ;; sun4os3) basic_machine=sparc-sun os=-sunos3 ;; sun4os4) basic_machine=sparc-sun os=-sunos4 ;; sun4sol2) basic_machine=sparc-sun os=-solaris2 ;; sun3 | sun3-*) basic_machine=m68k-sun ;; sun4) basic_machine=sparc-sun ;; sun386 | sun386i | roadrunner) basic_machine=i386-sun ;; sv1) basic_machine=sv1-cray os=-unicos ;; symmetry) basic_machine=i386-sequent os=-dynix ;; t3e) basic_machine=alphaev5-cray os=-unicos ;; t90) basic_machine=t90-cray os=-unicos ;; tile*) basic_machine=$basic_machine-unknown os=-linux-gnu ;; tx39) basic_machine=mipstx39-unknown ;; tx39el) basic_machine=mipstx39el-unknown ;; toad1) basic_machine=pdp10-xkl os=-tops20 ;; tower | tower-32) basic_machine=m68k-ncr ;; tpf) basic_machine=s390x-ibm os=-tpf ;; udi29k) basic_machine=a29k-amd os=-udi ;; ultra3) basic_machine=a29k-nyu os=-sym1 ;; v810 | necv810) basic_machine=v810-nec os=-none ;; vaxv) basic_machine=vax-dec os=-sysv ;; vms) basic_machine=vax-dec os=-vms ;; vpp*|vx|vx-*) basic_machine=f301-fujitsu ;; vxworks960) basic_machine=i960-wrs os=-vxworks ;; vxworks68) basic_machine=m68k-wrs os=-vxworks ;; vxworks29k) basic_machine=a29k-wrs os=-vxworks ;; w65*) basic_machine=w65-wdc os=-none ;; w89k-*) basic_machine=hppa1.1-winbond os=-proelf ;; xbox) basic_machine=i686-pc os=-mingw32 ;; xps | xps100) basic_machine=xps100-honeywell ;; xscale-* | xscalee[bl]-*) basic_machine=`echo $basic_machine | sed 's/^xscale/arm/'` ;; ymp) basic_machine=ymp-cray os=-unicos ;; z8k-*-coff) basic_machine=z8k-unknown os=-sim ;; z80-*-coff) basic_machine=z80-unknown os=-sim ;; none) basic_machine=none-none os=-none ;; # Here we handle the default manufacturer of certain CPU types. It is in # some cases the only manufacturer, in others, it is the most popular. w89k) basic_machine=hppa1.1-winbond ;; op50n) basic_machine=hppa1.1-oki ;; op60c) basic_machine=hppa1.1-oki ;; romp) basic_machine=romp-ibm ;; mmix) basic_machine=mmix-knuth ;; rs6000) basic_machine=rs6000-ibm ;; vax) basic_machine=vax-dec ;; pdp10) # there are many clones, so DEC is not a safe bet basic_machine=pdp10-unknown ;; pdp11) basic_machine=pdp11-dec ;; we32k) basic_machine=we32k-att ;; sh[1234] | sh[24]a | sh[24]aeb | sh[34]eb | sh[1234]le | sh[23]ele) basic_machine=sh-unknown ;; sparc | sparcv8 | sparcv9 | sparcv9b | sparcv9v) basic_machine=sparc-sun ;; cydra) basic_machine=cydra-cydrome ;; orion) basic_machine=orion-highlevel ;; orion105) basic_machine=clipper-highlevel ;; mac | mpw | mac-mpw) basic_machine=m68k-apple ;; pmac | pmac-mpw) basic_machine=powerpc-apple ;; *-unknown) # Make sure to match an already-canonicalized machine name. ;; *) echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 exit 1 ;; esac # Here we canonicalize certain aliases for manufacturers. case $basic_machine in *-digital*) basic_machine=`echo $basic_machine | sed 's/digital.*/dec/'` ;; *-commodore*) basic_machine=`echo $basic_machine | sed 's/commodore.*/cbm/'` ;; *) ;; esac # Decode manufacturer-specific aliases for certain operating systems. if [ x"$os" != x"" ] then case $os in # First match some system type aliases # that might get confused with valid system types. # -solaris* is a basic system type, with this one exception. -auroraux) os=-auroraux ;; -solaris1 | -solaris1.*) os=`echo $os | sed -e 's|solaris1|sunos4|'` ;; -solaris) os=-solaris2 ;; -svr4*) os=-sysv4 ;; -unixware*) os=-sysv4.2uw ;; -gnu/linux*) os=`echo $os | sed -e 's|gnu/linux|linux-gnu|'` ;; # First accept the basic system types. # The portable systems comes first. # Each alternative MUST END IN A *, to match a version number. # -sysv* is not here because it comes later, after sysvr4. -gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \ | -*vms* | -sco* | -esix* | -isc* | -aix* | -cnk* | -sunos | -sunos[34]*\ | -hpux* | -unos* | -osf* | -luna* | -dgux* | -auroraux* | -solaris* \ | -sym* | -kopensolaris* | -plan9* \ | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \ | -aos* | -aros* | -cloudabi* | -sortix* \ | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \ | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \ | -hiux* | -386bsd* | -knetbsd* | -mirbsd* | -netbsd* \ | -bitrig* | -openbsd* | -solidbsd* | -libertybsd* \ | -ekkobsd* | -kfreebsd* | -freebsd* | -riscix* | -lynxos* \ | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \ | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ | -chorusos* | -chorusrdb* | -cegcc* \ | -cygwin* | -msys* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ | -midipix* | -mingw32* | -mingw64* | -linux-gnu* | -linux-android* \ | -linux-newlib* | -linux-musl* | -linux-uclibc* \ | -uxpv* | -beos* | -mpeix* | -udk* | -moxiebox* \ | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \ | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \ | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \ | -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \ | -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* \ | -powermax* | -dnix* | -nx6 | -nx7 | -sei* | -dragonfly* \ | -skyos* | -haiku* | -rdos* | -toppers* | -drops* | -es* \ | -onefs* | -tirtos* | -phoenix* | -fuchsia*) # Remember, each alternative MUST END IN *, to match a version number. ;; -qnx*) case $basic_machine in x86-* | i*86-*) ;; *) os=-nto$os ;; esac ;; -nto-qnx*) ;; -nto*) os=`echo $os | sed -e 's|nto|nto-qnx|'` ;; -sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \ | -windows* | -osx | -abug | -netware* | -os9* | -beos* | -haiku* \ | -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*) ;; -mac*) os=`echo $os | sed -e 's|mac|macos|'` ;; -linux-dietlibc) os=-linux-dietlibc ;; -linux*) os=`echo $os | sed -e 's|linux|linux-gnu|'` ;; -sunos5*) os=`echo $os | sed -e 's|sunos5|solaris2|'` ;; -sunos6*) os=`echo $os | sed -e 's|sunos6|solaris3|'` ;; -opened*) os=-openedition ;; -os400*) os=-os400 ;; -wince*) os=-wince ;; -osfrose*) os=-osfrose ;; -osf*) os=-osf ;; -utek*) os=-bsd ;; -dynix*) os=-bsd ;; -acis*) os=-aos ;; -atheos*) os=-atheos ;; -syllable*) os=-syllable ;; -386bsd) os=-bsd ;; -ctix* | -uts*) os=-sysv ;; -nova*) os=-rtmk-nova ;; -ns2 ) os=-nextstep2 ;; -nsk*) os=-nsk ;; # Preserve the version number of sinix5. -sinix5.*) os=`echo $os | sed -e 's|sinix|sysv|'` ;; -sinix*) os=-sysv4 ;; -tpf*) os=-tpf ;; -triton*) os=-sysv3 ;; -oss*) os=-sysv3 ;; -svr4) os=-sysv4 ;; -svr3) os=-sysv3 ;; -sysvr4) os=-sysv4 ;; # This must come after -sysvr4. -sysv*) ;; -ose*) os=-ose ;; -es1800*) os=-ose ;; -xenix) os=-xenix ;; -*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*) os=-mint ;; -aros*) os=-aros ;; -zvmoe) os=-zvmoe ;; -dicos*) os=-dicos ;; -nacl*) ;; -ios) ;; -none) ;; *) # Get rid of the `-' at the beginning of $os. os=`echo $os | sed 's/[^-]*-//'` echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2 exit 1 ;; esac else # Here we handle the default operating systems that come with various machines. # The value should be what the vendor currently ships out the door with their # machine or put another way, the most popular os provided with the machine. # Note that if you're going to try to match "-MANUFACTURER" here (say, # "-sun"), then you have to tell the case statement up towards the top # that MANUFACTURER isn't an operating system. Otherwise, code above # will signal an error saying that MANUFACTURER isn't an operating # system, and we'll never get to this point. case $basic_machine in score-*) os=-elf ;; spu-*) os=-elf ;; *-acorn) os=-riscix1.2 ;; arm*-rebel) os=-linux ;; arm*-semi) os=-aout ;; c4x-* | tic4x-*) os=-coff ;; c8051-*) os=-elf ;; hexagon-*) os=-elf ;; tic54x-*) os=-coff ;; tic55x-*) os=-coff ;; tic6x-*) os=-coff ;; # This must come before the *-dec entry. pdp10-*) os=-tops20 ;; pdp11-*) os=-none ;; *-dec | vax-*) os=-ultrix4.2 ;; m68*-apollo) os=-domain ;; i386-sun) os=-sunos4.0.2 ;; m68000-sun) os=-sunos3 ;; m68*-cisco) os=-aout ;; mep-*) os=-elf ;; mips*-cisco) os=-elf ;; mips*-*) os=-elf ;; or32-*) os=-coff ;; *-tti) # must be before sparc entry or we get the wrong os. os=-sysv3 ;; sparc-* | *-sun) os=-sunos4.1.1 ;; *-be) os=-beos ;; *-haiku) os=-haiku ;; *-ibm) os=-aix ;; *-knuth) os=-mmixware ;; *-wec) os=-proelf ;; *-winbond) os=-proelf ;; *-oki) os=-proelf ;; *-hp) os=-hpux ;; *-hitachi) os=-hiux ;; i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent) os=-sysv ;; *-cbm) os=-amigaos ;; *-dg) os=-dgux ;; *-dolphin) os=-sysv3 ;; m68k-ccur) os=-rtu ;; m88k-omron*) os=-luna ;; *-next ) os=-nextstep ;; *-sequent) os=-ptx ;; *-crds) os=-unos ;; *-ns) os=-genix ;; i370-*) os=-mvs ;; *-next) os=-nextstep3 ;; *-gould) os=-sysv ;; *-highlevel) os=-bsd ;; *-encore) os=-bsd ;; *-sgi) os=-irix ;; *-siemens) os=-sysv4 ;; *-masscomp) os=-rtu ;; f30[01]-fujitsu | f700-fujitsu) os=-uxpv ;; *-rom68k) os=-coff ;; *-*bug) os=-coff ;; *-apple) os=-macos ;; *-atari*) os=-mint ;; *) os=-none ;; esac fi # Here we handle the case where we know the os, and the CPU type, but not the # manufacturer. We pick the logical manufacturer. vendor=unknown case $basic_machine in *-unknown) case $os in -riscix*) vendor=acorn ;; -sunos*) vendor=sun ;; -cnk*|-aix*) vendor=ibm ;; -beos*) vendor=be ;; -hpux*) vendor=hp ;; -mpeix*) vendor=hp ;; -hiux*) vendor=hitachi ;; -unos*) vendor=crds ;; -dgux*) vendor=dg ;; -luna*) vendor=omron ;; -genix*) vendor=ns ;; -mvs* | -opened*) vendor=ibm ;; -os400*) vendor=ibm ;; -ptx*) vendor=sequent ;; -tpf*) vendor=ibm ;; -vxsim* | -vxworks* | -windiss*) vendor=wrs ;; -aux*) vendor=apple ;; -hms*) vendor=hitachi ;; -mpw* | -macos*) vendor=apple ;; -*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*) vendor=atari ;; -vos*) vendor=stratus ;; esac basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"` ;; esac echo $basic_machine$os exit # Local variables: # eval: (add-hook 'write-file-hooks 'time-stamp) # time-stamp-start: "timestamp='" # time-stamp-format: "%:y-%02m-%02d" # time-stamp-end: "'" # End: kea-1.6.2/CONTRIBUTING.md0000644000175000017500000004214713623761160011447 00000000000000# Kea Contributor's Guide So you found a bug in Kea or plan to develop an extension and want to send us a patch? Great! This page will explain how to contribute your changes smoothly. Here's a quick list of how to contribute a patch: 1. **create account** on [gitlab](https://gitlab.isc.org) 2. **open an issue** in [Kea project](https://gitlab.isc.org/isc-projects/kea/issues/new), make sure it describes what you want to fix and **why** 3. **ask someone from the ISC team to give you permission to fork Kea** (ask @tomek, @vicky, @ondrej or @godfryd or basically anyone from the Kea dev team) 4. **fork Kea code**: go to Kea project page, click [Fork button](https://gitlab.isc.org/isc-projects/kea/forks/new). If you can't, you didn't complete step 3. 5. **Implement your fix or feature, push code** to your repo. Make sure it compiles, has unit-tests, is documented and does what it's supposed to do. 6. **Open Merge Request**: go to Kea project [merge requests page](https://gitlab.isc.org/isc-projects/kea/merge_requests), click [New merge request](https://gitlab.isc.org/isc-projects/kea/merge_requests/new). If you don't see the button, you didn't complete step 3. 7. **Participate in the code review**: Once you submit the MR, someone from ISC will eventually get to the issue and will review your code. Please make sure you respond to comments. It's likely you'll be asked to update the code. For a much more detailed description with details, see the text below. ## Writing a patch Before you start working on a patch or a new feature, it is a good idea to discuss it first with Kea developers. You can post your questions to the [kea-dev](https://lists.isc.org/mailman/listinfo/kea-dev) or [kea-users](https://lists.isc.org/mailman/listinfo/kea-users) mailing lists. The kea-users is intended for users who are not interested in the internal workings or development details of Kea: it is OK to ask for feedback regarding new design or the best proposed solution to a certain problem. This is the best place to get user's feedback. The internal details, questions about the code and its internals are better asked on kea-dev. OK, so you have written a patch? Great! Before you submit it, make sure that your code compiles. This may seem obvious, but there's more to it. You have surely checked that it compiles on your system, but Kea is a portable software. Besides Linux, it is compiled and used on relatively uncommon systems like OpenBSD. Will your code compile and work there? What about endianness? It is likely that you used a regular x86 architecture machine to write your patch, but the software is expected to run on many other architectures. You may take a look at [system specific build notes](https://kb.isc.org/docs/installing-kea). For a complete list of systems we build on, you may take a look at the [Jenkins build farm](https://jenkins.isc.org/). Does your patch conform to [Kea coding guidelines](https://gitlab.isc.org/isc-projects/kea/wikis/coding-guidelines)? You can submit a patch that does not adhere to them, but that will reduce its chances of being accepted. If the deviations are minor, one of the Kea engineers who does the review will likely fix the issues. However, if there are lots of issues, the reviewer may simply reject the patch and ask you to fix it before re-submitting. ## Running unit-tests One of the ground rules in Kea development is that every piece of code has to be tested. We now have an extensive set of unit-tests for almost every line of code. Even if you are fixing something small, like a single line fix, you are encouraged to write unit-tests for that change. That is even more true for new code: if you write a new function, method or a class, you definitely should write unit-tests for it. To ensure that everything is tested, ISC uses a development method called [Test Driven Development (TDD)](https://en.wikipedia.org/wiki/Test-driven_development). In TDD, a feature is developed alongside the tests, preferably with the tests being written first. In detail, a test is written for a small piece of functionality and run against the existing code. (In the case where the test is a unit test for a function, it would be run against an empty (unimplemented) function.) The test should fail. A minimal amount of code is then written, just enough to get the test to pass. Then the process is repeated for the next small piece of functionality. This continues until all the functionality has been implemented. This approach has two advantages: - By writing a test first and then only enough code to pass the test, that code is fully tested. By repeating this process until the feature is fully implemented, all the code gets test coverage. You avoid the situation where not enough tests have been written to check all the code. - By running the test before the code implementing the function is written and observing the test fail, you can detect the situation where a bug in the test code will cause it to pass regardless of the code being tested. Initially, some people unfamiliar with that approach react with "but my change is simple and I tested that it works". That approach is both insufficient and short-sighted. It is insufficient, because manual testing is by definition laborious and can't really be done on the multitude of systems we run Kea on. It is short-sighted, because even with your best intentions you will not be able to dedicate any significant amount of time for repeated testing of your improved code. The old ISC DHCP has two decades of history behind it and we hope to make Kea last similar time span. Over such long periods, code tends to be refactored several times. The change you made may be affected by some other change or by the code that hasn't been written yet. See Building Kea with Unit Tests for instructions on how to run unit-tests. If you happen to touch any database related code, make sure you compile your code with –with-mysql, –with-pgsql and/or –with-cql as needed. For example, if you change something substantial, make sure the other compilation options still work. If you happen to add new files or have modified any Makefile.am files, it is also a good idea to check if you haven't broken the distribution process: ```bash make distcheck ``` There are other useful switches which can be passed to configure. It is always a good idea to use `–enable-logger-checks`, which does sanity checks on logger parameters. Use `–-enable-debug` to enable various additional consistency checks that reduce performance but help during development. If you happen to modify anything in the documentation, use `–-enable-generate-docs`. If you are modifying DHCP code, you are likely to be interested in enabling a non-default database backends for DHCP. Note that if the backend is not enabled, the database-specific unit-tests are skipped. To enable the MySQL backend, use the switch `–with-mysql`; for PostgreSQL, use `–with-pgsql` and for Cassandra use `--with-cql`. A complete list of all switches can be obtained with the command: ```bash ./configure --help ``` ## Submitting Merge Request (also known as sending your patch the right way) The first step in writing the patch or new feature should be to get the source code from our Git repository. The procedure is very easy and is [explained here](https://gitlab.isc.org/isc-projects/kea/wikis/processes/gitlab-howto). While it is possible to provide a patch against the latest stable release, it makes the review process much easier if it is for latest code from the Git master branch. ISC uses [gitlab](https://gitlab.isc.org) to manage its source code. While we also maintain presence on [github](https://github.com/isc-projects/kea), the process of syncing gitlab to github is mostly automated and Kea devs rarely look at github. ISC's gitlab has been a target for spammers in the past, so it is now set up defensively. In particular, new users can't fork the code on their own and it requires someone from ISC to manually grant the ability to fork projects. Fortunately, this is easy to do and we glady do this for anyone who asks and provides a good reason. "I'd like to fix bug X or develop feature Y" is an excellent reason. The best place for asking is either kea-dev or asking in a comment in your issue. Make sure you put a name tag (@tomek, @godfryd, @vicky or @ondrej). When you write a comment in an issue or merge request and add a name tag on it, the user is automatically notified. Once you fork the Kea code in gitlab, you have your own copy and you can commit your changes there and push them to your copy of Kea repo. Once you feel that your patch is ready, go to Kea project and [submit a Merge Request](https://gitlab.isc.org/isc-projects/kea/merge_requests/new). If you can't access this link or don't see New Merge Request button on the [merge requests page](https://gitlab.isc.org/isc-projects/kea/merge_requests), please ask on kea-dev and someone will help you out. ## Send Pull Request on github If you can't send the patch on gitlab, the next best preferred way is to send pull request (PR) on [github](https://github.com/isc-projects/kea). This is almost as good as sending MR on gitlab. The downside is that Kea devs don't look at github too frequently, so it may be a while before we notice it. And when we do, the chances are we will be busy with other things. With gitlab, your MR will stare at us the whole time, so we'll get round to it much quicker. But we understand that there are some cases where people may prefer github over gitlab. See the excellent documentation on github: https://help.github.com/articles/creating-a-pull-request/ for details. In essence, you need github account (spam/hassle free, takes one minute to set up). Then you can fork the Kea repository, commit changes to your repo and ask us to pull your changes into official Kea repository. This has a number of advantages. First, it is made against a specific code version, which can be easily checked with git log command. Second, this request pops up instantly on our list of open pull requests and will stay there. The third benefit is that the pull request mechanism is very flexible. Kea engineers (and other users, too) can comment on it, attach links, mention other users etc. You as a submitter can augment the patch by committing extra changes to your repository. Those extra commits will appear instantly in the pull request. This is really useful during the review. Finally, Kea developers can better assess all open pull requests and add labels to them, such as "enhancement", "bug", or "unit-tests missing". This makes our life easier. Oh, and your commits will later be shown as yours in github history. If you care for that kind of things, once the patch is merged, you'll be automatically listed as contributor and Kea will be listed as project you have contributed to. ## If you really can't do MR on gitlab or PR on github... Well, you are out of luck. There are other ways, but those are really awkward and the chances of your patch being ignored are really high. Anyway, here they are: - [create an issue in the Kea Gitlab](https://gitlab.isc.org/isc-projects/kea/issues/new) and attach your patch to it. Sending a patch has a number of disadvantages. First, if you don't specify the base version against which it was created, one of Kea developers will have to guess that or go through a series of trials and errors to find that out. If the code doesn't compile, the reviewer will not know if the patch is broken or maybe it was applied to incorrect base code. Another frequent problem is that it may be possible that the patch didn't include any new files you have added. If we happen to have any comments that you as submitter are expected to address (and in the overwhelming majority of cases, we have), you will be asked to send an updated patch. It is not uncommon to see several rounds of such reviews, so this can get very complicated very quickly. Please don't add your issue to any milestone. Kea team has a process of going through issues unassigned to any milestone. Kea developers review new issues once a week and assign them to specific milestones. Please do not add issues to working milestones directly. Having an issue in gitlab ensures that the patch will never be forgotten and it will show up on our gitlab reports. It's not required, but much appreciated if you send a short note to the kea-dev mailing list explaining what you did with the code and announce the issue number. - Send a patch to the kea-dev list. This is the third preferred method, if you can't or don't want to use gitlab and github. If you send a patch to a mailing list in a wrong time, e.g. shortly before a release, Kea developers may miss it or perhaps they will see it and then forget about it. Nevertheless, it is still doable and we successfully accepted patches that way. It just takes more time from everyone involved, so it's a slower process in general. - Send a tarball with your modified code. This is really the worst way one can contribute a patch. It has a number of disadvantages. In particular, someone will need to find out which version the code was based on and generate the patch. It's not rocket science, but it may be a very mundane thing to do if the Kea developer does not know the version in advance. The mailing list has a limit on the message size (for good reasons), so you'll likely need to upload it somewhere first. Kea developers often don't pick up new issues instantly, so it may have to wait weeks before the tarball is looked at. The tarball does not benefit from most of the advantages mentioned for github, like the ability to easily update the code, have a meaningful discussion or see what the exact scope of changes are. Nevertheless, if we given a choice of getting a tarball or not getting a patch at all, we prefer tarballs. Just keep in mind that processing a tarball is really cumbersome for Kea developers, so it may take significantly longer than other ways. ## Going through a review Once you make your patch available using one of the ways above, the action is on one of the Kea developers. We need an issue. While we can create it on our own, we prefer the original submitter fill them in as he or she has the best understanding of the purpose of the change and may have any extra information about OS, version, why it was done this specific way etc. If there is no MR and no gitlab issue, you risk the issue not showing up on ISC radars. Depending on the subjective importance and urgency as perceived by the ISC engineer, the issue or PR will be assigned to one of the milestones. Sooner or later, one of Kea developers will do the review. Here's the tricky part. One of Kea developers will review your patch, but it may not happen immediately. Unfortunately, developers are usually working under a tight schedule, so any extra unplanned review work may take a while. Having said that, we value external contributions very much and will do whatever we can to review patches in a timely manner. Don't get discouraged if your patch is not accepted after first review. To keep the code quality high, we use the same review processes for external patches as we do for internal code. It may take some cycles of review/updated patch submissions before the code is finally accepted. The nature of the review process is that it emphasizes areas that need improvement. If you are not used to the review process, you may get the impression that the feedback is negative. It is not: even the Kea developers seldom see reviews that say "All OK please merge". Once the process is almost complete, the developer will likely ask you how you would like to be credited. The typical answers are by first and last name, by nickname, by company name or anonymously. Typically we will add a note to the ChangeLog and also set you as the author of the commit applying the patch and update the contributors section in the AUTHORS file. If the contributed feature is big or critical for whatever reason, it may also be mentioned in release notes. Sadly, we sometimes see patches that are submitted and then the submitter never responds to our comments or requests for an updated patch. Depending on the nature of the patch, we may either fix the outstanding issues on our own and get another Kea developer to review them or the issue may end up in our Outstanding milestone. When a new release is started, we go through the issues in Outstanding, select a small number of them and move them to whatever the current milestone is. Keep that in mind if you plan to submit a patch and forget about it. We may accept it eventually, but it's much, much faster process if you participate in it. ## Extra steps If you are interested in knowing the results of more in-depth testing, you are welcome to visit the ISC Jenkins page: https://jenkins.isc.org This is a live result page with all tests being run on various systems. Besides basic unit-tests, we also have reports from valgrind (memory debugger), cppcheck and clang-analyzer (static code analyzers), Lettuce system tests and more. Although it is not possible for non ISC employees to run tests on that farm, it is possible that your contributed patch will end up there sooner or later. We also have ISC Forge tests running, but currently the test results are not publicly available. kea-1.6.2/INSTALL0000644000175000017500000000356513623761160010250 00000000000000INSTALLATION INSTRUCTIONS 1. Generate the configure script. If you downloaded the source from git or are compiling with premium hook packages, you will need to run autoreconf to generate the configure script as shown below. If you are building from a tarball you may skip this step. $ autoreconf --install 2. Run the configure script. If you want to alter Kea's installation path, or need to include capabilities (e.g. enabling MySQL or PostgreSQL) you will need to specify these as options to the configure script (run ./configure -h for list of options). $ ./configure If your environment is missing dependencies, the configure script will exit with error and should emit sufficient information to guide you on how to proceed. A detailed account of the configure process is captured in ./config.log. 3. Build it. Once you've successfully configured the source tree, run "make" to build it. You may wish to include the -j command line option to specify parallel execution to speed things along: $ make 4. Install it. Depending on your target directory, this step will likely require a root privileges. You can install the software by running: $ sudo make install Kea depends on C++ compiler, make, libtool, boost (at least includes, but many OSes require boost-system library), log4cplus and one crypto library (either OpenSSL or Botan) for compilation. Optional backends (MySQL, PostgreSQL and Cassandra) have additional dependencies. For detailed installation directions, see the documentation in doc/sphinx/arm/install.rst text file or on the Kea online docs: https://kea.readthedocs.io/. Other optional dependencies are FreeRADIUS client (this requires a subscriber only RADIUS hook) and Sysrepo, a system for providing YANG/NETCONF interface. You can find current OS-specific build/installation instructions in our knowledge base at https://kb.isc.org/docs/installing-kea kea-1.6.2/compile0000755000175000017500000001624513623761177010604 00000000000000#! /bin/sh # Wrapper for compilers which do not understand '-c -o'. scriptversion=2012-10-14.11; # UTC # Copyright (C) 1999-2014 Free Software Foundation, Inc. # Written by Tom Tromey . # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see . # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. # This file is maintained in Automake, please report # bugs to or send patches to # . nl=' ' # We need space, tab and new line, in precisely that order. Quoting is # there to prevent tools from complaining about whitespace usage. IFS=" "" $nl" file_conv= # func_file_conv build_file lazy # Convert a $build file to $host form and store it in $file # Currently only supports Windows hosts. If the determined conversion # type is listed in (the comma separated) LAZY, no conversion will # take place. func_file_conv () { file=$1 case $file in / | /[!/]*) # absolute file, and not a UNC file if test -z "$file_conv"; then # lazily determine how to convert abs files case `uname -s` in MINGW*) file_conv=mingw ;; CYGWIN*) file_conv=cygwin ;; *) file_conv=wine ;; esac fi case $file_conv/,$2, in *,$file_conv,*) ;; mingw/*) file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'` ;; cygwin/*) file=`cygpath -m "$file" || echo "$file"` ;; wine/*) file=`winepath -w "$file" || echo "$file"` ;; esac ;; esac } # func_cl_dashL linkdir # Make cl look for libraries in LINKDIR func_cl_dashL () { func_file_conv "$1" if test -z "$lib_path"; then lib_path=$file else lib_path="$lib_path;$file" fi linker_opts="$linker_opts -LIBPATH:$file" } # func_cl_dashl library # Do a library search-path lookup for cl func_cl_dashl () { lib=$1 found=no save_IFS=$IFS IFS=';' for dir in $lib_path $LIB do IFS=$save_IFS if $shared && test -f "$dir/$lib.dll.lib"; then found=yes lib=$dir/$lib.dll.lib break fi if test -f "$dir/$lib.lib"; then found=yes lib=$dir/$lib.lib break fi if test -f "$dir/lib$lib.a"; then found=yes lib=$dir/lib$lib.a break fi done IFS=$save_IFS if test "$found" != yes; then lib=$lib.lib fi } # func_cl_wrapper cl arg... # Adjust compile command to suit cl func_cl_wrapper () { # Assume a capable shell lib_path= shared=: linker_opts= for arg do if test -n "$eat"; then eat= else case $1 in -o) # configure might choose to run compile as 'compile cc -o foo foo.c'. eat=1 case $2 in *.o | *.[oO][bB][jJ]) func_file_conv "$2" set x "$@" -Fo"$file" shift ;; *) func_file_conv "$2" set x "$@" -Fe"$file" shift ;; esac ;; -I) eat=1 func_file_conv "$2" mingw set x "$@" -I"$file" shift ;; -I*) func_file_conv "${1#-I}" mingw set x "$@" -I"$file" shift ;; -l) eat=1 func_cl_dashl "$2" set x "$@" "$lib" shift ;; -l*) func_cl_dashl "${1#-l}" set x "$@" "$lib" shift ;; -L) eat=1 func_cl_dashL "$2" ;; -L*) func_cl_dashL "${1#-L}" ;; -static) shared=false ;; -Wl,*) arg=${1#-Wl,} save_ifs="$IFS"; IFS=',' for flag in $arg; do IFS="$save_ifs" linker_opts="$linker_opts $flag" done IFS="$save_ifs" ;; -Xlinker) eat=1 linker_opts="$linker_opts $2" ;; -*) set x "$@" "$1" shift ;; *.cc | *.CC | *.cxx | *.CXX | *.[cC]++) func_file_conv "$1" set x "$@" -Tp"$file" shift ;; *.c | *.cpp | *.CPP | *.lib | *.LIB | *.Lib | *.OBJ | *.obj | *.[oO]) func_file_conv "$1" mingw set x "$@" "$file" shift ;; *) set x "$@" "$1" shift ;; esac fi shift done if test -n "$linker_opts"; then linker_opts="-link$linker_opts" fi exec "$@" $linker_opts exit 1 } eat= case $1 in '') echo "$0: No command. Try '$0 --help' for more information." 1>&2 exit 1; ;; -h | --h*) cat <<\EOF Usage: compile [--help] [--version] PROGRAM [ARGS] Wrapper for compilers which do not understand '-c -o'. Remove '-o dest.o' from ARGS, run PROGRAM with the remaining arguments, and rename the output as expected. If you are trying to build a whole package this is not the right script to run: please start by reading the file 'INSTALL'. Report bugs to . EOF exit $? ;; -v | --v*) echo "compile $scriptversion" exit $? ;; cl | *[/\\]cl | cl.exe | *[/\\]cl.exe ) func_cl_wrapper "$@" # Doesn't return... ;; esac ofile= cfile= for arg do if test -n "$eat"; then eat= else case $1 in -o) # configure might choose to run compile as 'compile cc -o foo foo.c'. # So we strip '-o arg' only if arg is an object. eat=1 case $2 in *.o | *.obj) ofile=$2 ;; *) set x "$@" -o "$2" shift ;; esac ;; *.c) cfile=$1 set x "$@" "$1" shift ;; *) set x "$@" "$1" shift ;; esac fi shift done if test -z "$ofile" || test -z "$cfile"; then # If no '-o' option was seen then we might have been invoked from a # pattern rule where we don't need one. That is ok -- this is a # normal compilation that the losing compiler can handle. If no # '.c' file was seen then we are probably linking. That is also # ok. exec "$@" fi # Name of file we expect compiler to create. cofile=`echo "$cfile" | sed 's|^.*[\\/]||; s|^[a-zA-Z]:||; s/\.c$/.o/'` # Create the lock directory. # Note: use '[/\\:.-]' here to ensure that we don't use the same name # that we are using for the .o file. Also, base the name on the expected # object file name, since that is what matters with a parallel build. lockdir=`echo "$cofile" | sed -e 's|[/\\:.-]|_|g'`.d while true; do if mkdir "$lockdir" >/dev/null 2>&1; then break fi sleep 1 done # FIXME: race condition here if user kills between mkdir and trap. trap "rmdir '$lockdir'; exit 1" 1 2 15 # Run the compile. "$@" ret=$? if test -f "$cofile"; then test "$cofile" = "$ofile" || mv "$cofile" "$ofile" elif test -f "${cofile}bj"; then test "${cofile}bj" = "$ofile" || mv "${cofile}bj" "$ofile" fi rmdir "$lockdir" exit $ret # Local Variables: # mode: shell-script # sh-indentation: 2 # eval: (add-hook 'write-file-hooks 'time-stamp) # time-stamp-start: "scriptversion=" # time-stamp-format: "%:y-%02m-%02d.%02H" # time-stamp-time-zone: "UTC" # time-stamp-end: "; # UTC" # End: kea-1.6.2/doc/0000755000175000017500000000000013623761246010040 500000000000000kea-1.6.2/doc/examples/0000755000175000017500000000000013623761246011656 500000000000000kea-1.6.2/doc/examples/https/0000755000175000017500000000000013623761246013020 500000000000000kea-1.6.2/doc/examples/https/httpd2/0000755000175000017500000000000013623761246014225 500000000000000kea-1.6.2/doc/examples/https/httpd2/kea-httpd2.conf0000644000175000017500000001200413623761160016747 00000000000000# This file contains a partial Apache2 server configuration which # enables reverse proxy service for Kea RESTful API. An access to # the service is protected by client's certificate verification # mechanism. Before using this configuration a server administrator # must generate server certificate and private key as well as # the certificate authority (CA). The clients' certificates must # be signed by the CA. # # Note that the steps provided below to generate and setup certificates # are provided as an example for testing purposes only. Always # consider best known security measures to protect your production # environment. # # The server certificate and key can be generated as follows: # # openssl genrsa -des3 -out kea-proxy.key 4096 # openssl req -new -x509 -days 365 -key kea-proxy.key -out kea-proxy.crt # # The CA certificate and key can be generated as follows: # # openssl genrsa -des3 -out ca.key 4096 # openssl req -new -x509 -days 365 -key ca.key -out ca.crt # # # The client certificate needs to be generated and signed: # # openssl genrsa -des3 -out kea-client.key 4096 # openssl req -new -key kea-client.key -out kea-client.csr # openssl x509 -req -days 365 -in kea-client.csr -CA ca.crt \ # -CAkey ca.key -set_serial 10 -out kea-client.crt # # Note that the 'common name' value used when generating the client # and the server certificates must differ from the value used # for the CA certificate. # # The client certificate must be deployed on the client system. # In order to test the proxy configuration with 'curl' run # command similar to the following: # # curl -k --key kea-client.key --cert kea-client.crt -X POST \ # -H Content-Type:application/json -d '{ "command": "list-commands" }' \ # https://kea.example.org/kea # # On some curl running on macOS the crypto library requires a PKCS#12 # bundle with the private key and the certificate as the cert argument. # The PKCS#12 file can be generated by: # # openssl pkcs12 -export -in kea-client.crt -inkey kea-client.key \ # -out kea-client.p12 # # If the password is kea, curl command becomes: # # curl -k --cert kea-client.p12:kea -X POST \ # -H Content-Type:application/json -d '{ "command": "list-commands" }' \ # https://kea.example.org/kea # # # In order to use this configuration within your Apache2 configuration # put the following line in the main Apache 2 configuration file: # # Include /path/to/kea-httpd2.conf # # and specify a path appropriate for your system. # # # Apache2 server configuration starts here. # # Address and port that the server should bind to. # Usually an explicit address is specified to avoid binding to # many addresses. For testing https connection on the localhost # use: # Listen [::1]:443 or # Listen 127.0.0.1:443 Listen *:443 # List the ciphers that the client is permitted to negotiate, # and that httpd will negotiate as the client of a proxied server. # See the OpenSSL documentation for a complete list of ciphers, and # ensure these follow appropriate best practices for this deployment. # httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers, # while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 # User agents such as web browsers are not configured for the user's # own preference of either security or performance, therefore this # must be the prerogative of the web server administrator who manages # cpu load versus confidentiality, so enforce the server's cipher order. SSLHonorCipherOrder on # List the protocol versions which clients are allowed to connect with. # Disable SSLv2 and SSLv3 by default (cf. RFC 7525 3.1.1). TLSv1 (1.0) # should be disabled as quickly as practical. By the end of 2016, only # the TLSv1.2 protocol or later should remain in use. SSLProtocol all -SSLv2 -SSLv3 SSLProxyProtocol all -SSLv2 -SSLv3 # Semaphore: # Configure the path to the mutual exclusion semaphore the # SSL engine uses internally for inter-process synchronization. SSLMutex "file:/usr/local/var/run/apache2/ssl_mutex" # For URLs such as https://kea.example.org/kea, forward the requests # to http://127.0.0.1:8080 ProxyPass /kea http://127.0.0.1:8080/ ProxyPassReverse /kea http://127.0.0.1:8080/ # Disable connection keep alive between the proxy and Kea because # Kea doesn't support this mechanism. SetEnv proxy-nokeepalive 1 # Set server name. ServerName kea.example.org # Enable SSL for this virtual host. SSLEngine on # Server certificate and private key. SSLCertificateFile "/path/to/kea-proxy.crt" SSLCertificateKeyFile "/path/to/kea-proxy.key" # Enable verification of the client certificate. SSLVerifyClient require # Certificate Authority. Client certificate must be signed by the CA. SSLCACertificateFile "/path/to/ca.crt" kea-1.6.2/doc/examples/https/shell/0000755000175000017500000000000013623761246014127 500000000000000kea-1.6.2/doc/examples/https/shell/kea-stunnel.conf0000644000175000017500000000245713623761160017147 00000000000000; This file contains an example stunnel TLS client configuration which ; enables secure transport for Kea RESTful API. An access to ; the service is protected by client's and server's certificate ; verification mechanism (as known as mutual authentication). ; ; Note that the setup below (and reused nginx or httpd2 setups) ; are provided as an example for testing purposes only. Always ; consider best known security measures to protect your production ; environment. ; ; Transport marked with ==> (vs -->) is secured against passive ; (i.e. eavesdropping) and active (i.e. man-in-the-middle) attacks ; ; kea-shell -- 127.0.0.1 port 8080 --> ; stunnel == 127.0.0.1 port 443 ==> ; nginx -- 127.0.0.1 port 8000 --> ; kea-agent ; ; stunnel configuration starts here. ; in the case you would like to follow what happens ;; foreground = yes ;; debug = 7 ; kea service [kea] ; client (vs server) mode client = yes ; accept requests from the kea-shell tool accept = 127.0.0.1:8080 ; forward requests to the https peer connect = 127.0.0.1:443 ; client certificate cert = kea-client.crt ; client private key key = kea-client.key ; check server certificate verifyPeer = yes ; server certificate CAfile = kea-proxy.crt kea-1.6.2/doc/examples/https/nginx/0000755000175000017500000000000013623761246014143 500000000000000kea-1.6.2/doc/examples/https/nginx/kea-nginx.conf0000644000175000017500000000630413623761160016611 00000000000000# This file contains an example nginx HTTP server configuration which # enables reverse proxy service for Kea RESTful API. An access to # the service is protected by client's certificate verification # mechanism. Before using this configuration a server administrator # must generate server certificate and private key as well as # the certificate authority (CA). The clients' certificates must # be signed by the CA. # # Note that the steps provided below to generate and setup certificates # are provided as an example for testing purposes only. Always # consider best known security measures to protect your production # environment. # # The server certificate and key can be generated as follows: # # openssl genrsa -des3 -out kea-proxy.key 4096 # openssl req -new -x509 -days 365 -key kea-proxy.key -out kea-proxy.crt # # The CA certificate and key can be generated as follows: # # openssl genrsa -des3 -out ca.key 4096 # openssl req -new -x509 -days 365 -key ca.key -out ca.crt # # # The client certificate needs to be generated and signed: # # openssl genrsa -des3 -out kea-client.key 4096 # openssl req -new -key kea-client.key -out kea-client.csr # openssl x509 -req -days 365 -in kea-client.csr -CA ca.crt \ # -CAkey ca.key -set_serial 10 -out kea-client.crt # # Note that the 'common name' value used when generating the client # and the server certificates must differ from the value used # for the CA certificate. # # The client certificate must be deployed on the client system. # In order to test the proxy configuration with 'curl' run # command similar to the following: # # curl -k --key kea-client.key --cert kea-client.crt -X POST \ # -H Content-Type:application/json -d '{ "command": "list-commands" }' \ # https://kea.example.org # # On some curl running on macOS the crypto library requires a PKCS#12 # bundle with the private key and the certificate as the cert argument. # The PKCS#12 file can be generated by: # # openssl pkcs12 -export -in kea-client.crt -inkey kea-client.key \ # -out kea-client.p12 # # If the password is kea, curl command becomes: # # curl -k --cert kea-client.p12:kea -X POST \ # -H Content-Type:application/json -d '{ "command": "list-commands" }' \ # https://kea.example.org # # nginx configuration starts here. events { } http { # HTTPS server server { # Use default HTTPS port. listen 443 ssl; # Set server name. server_name kea.example.org; # Server certificate and key. ssl_certificate /path/to/kea-proxy.crt; ssl_certificate_key /path/to/kea-proxy.key; # Certificate Authority. Client certificate must be signed by the CA. ssl_client_certificate /path/to/ca.crt; # Enable verification of the client certificate. ssl_verify_client on; # For the URL https://kea.example.org forward the # requests to http://127.0.0.1:8000. # kea-shell defaults to / but --path can be used to set another value # for instance kea-shell --path kea which will matches location /kea location / { proxy_pass http://127.0.0.1:8000; } } } kea-1.6.2/doc/examples/kea4/0000755000175000017500000000000013623761246012502 500000000000000kea-1.6.2/doc/examples/kea4/hooks-radius.json0000644000175000017500000001577613623761160015740 00000000000000// This is an example configuration file for the DHCPv4 server in Kea // illustrating the configuration of the RADIUS and Host Cache hooks libraries. // // It is not intended to be used as is. It tries to showcase some of the // parameters available. // // To use this configuration file, you need to have both RADIUS and // Host Cache hooks. These are currently available to support customers only. // // clients get a wine name (option AOP code 250) divided into red and white. // Expensive brands have a host entry, i.e. a reserved address. // // Names // // brouilly (red) // chablis (white) // chambertin (red, expensive) // chinon (red) // chiroubles (red) // condrieu (white) // cornas (red) // corton (red) // fleurie (red) // givry (red) // margaux (red, expensive) // meursault (white) // montrachet (white, expensive) // morgon (red) // muscadet (white) // petrus (red, expensive) // riesling (white) // romanee (red, expensive) // sylvaner (white) // yquem (white, expensive) // // Address space is 192.0.2.0/24 with 10-99 for reds and 110-199 for whites. // // Reservations are given here in Kea/JSON style but they must be // in the RADIUS server configuration: // // { // "flex-id": "'chambertin'", // "ip-address": "192.0.2.10" // }, // { // "flex-id": "'margaux'", // "ip-address": "192.0.2.11" // }, // { // "flex-id": "'petrus'", // "ip-address": "192.0.2.12" // }, // { // "flex-id": "'romanee'", // "ip-address": "192.0.2.13" // }, // { // "flex-id": "'montrachet'", // "ip-address": "192.0.2.110" // }, // { // "flex-id": "'yquem'", // "ip-address": "192.0.2.111" // } // {"Dhcp4": { // Kea is told to listen on specfic interfaces only. "interfaces-config": { // You should probably list your network interfaces here (e.g. "en0") "interfaces": [ "en0" ] }, // Set up the storage for leases. "lease-database": { "type": "memfile" }, // Note there is hosts-database defined. RADIUS and Host Cache libraries // will create them dynamically. // RADIUS uses flex-id reservations, so restrict Kea to use flex-id only. "host-reservation-identifiers": [ "flex-id" ], // Define the AOP option. "option-def": [ { "name": "AOP", "code": 250, "type": "string" } ], // Define red and white client classes. // If they are not defined we can get spurious warnings. "client-classes": [ { "name": "red" }, { "name": "white" } ], // Define a subnet. "subnet4": [ { // Set the subnet ID (aka RADIUS NAS port). "id": 14, "subnet": "192.0.2.0/24", "interface": "en0", "pools": [ { // Red pool (10-19 are for reservations) "pool": "192.0.2.20-192.0.2.99", "client-class": "red" }, { // White pool (110-119 are for reservations) "pool": "192.0.2.120-192.0.2.199", "client-class": "white" } // Note there are not pools available to anyone. This is // important to note. This means that to get an address, the // client needs to belong to red class, to white class or // have an address reserved. ] } ], // Set up the hooks libraries. "hooks-libraries": [ { // Load the flex-id hook library. "library": "/usr/local/lib/kea/hooks/libdhcp_flex_id.so", "parameters": { // Take the ID from the AOP option. "identifier-expression": "option[250].text", // Replace the client ID in queries by the flex-id. // Currently required by access code. // Required for accounting as it will become the lease ID too. "replace-client-id": true } }, { // Load the host cache hook library. It is needed by the RADIUS // library to keep the attributes from authorization to later user // for accounting. "library": "/usr/local/lib/kea/hooks/libdhcp_host_cache.so" }, { // Load the RADIUS hook library. "library": "/usr/local/lib/kea/hooks/libdhcp_radius.so", "parameters": { // If do not use RFC 4361 // "extract-duid": false, // If have conflicting subnets // "reselect-subnet-pool": true, // Strip the 0 type added by flex-id "client-id-pop0": true, // flex Id is printable (far easier for the RADIUS server config) // Without this it will be in hexadecimal... "client-id-printable": true, // Use the flex-id. "identifier-type4": "flex-id", // Configure an access (aka authentication/authorization) server. "access": { // This starts the list of access servers "servers": [ { // These are parameters for the first (and only) access server "name": "127.0.0.1", "port": 1812, "secret": "secret" } // Additional access servers could be specified here ], // This define a list of additional attributes Kea will send to each // access server in Access-Request. "attributes": [ { // This attribute is identified by name (must be present in the // dictionary) and has static value (i.e. the same value will be // sent to every server for every packet) "name": "Password", "data": "mysecretpassword" }, { // It's also possible to specify an attribute using its type, // rather than a name. 77 is Connect-Info. The value is specified // using hex. Again, this is a static value. It will be sent the // same for every packet and to every server. "type": 77, "raw": "65666a6a71" }, { // This example shows how an expression can be used to send dynamic // value. The expression (see Section 13) may take any value from // the incoming packet or even its metadata (e.g. the interface // it was received over from) "name": "Configuration-Token", "expr": "pkt.iface" } ] // End of attributes }, // Configure an accouting server. "accounting": { "servers": [ { "name": "127.0.0.1", "port": 1813, "secret": "secret" } ] } } } ] } } kea-1.6.2/doc/examples/kea4/cassandra.json0000644000175000017500000000775013623761160015260 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It is a basic scenario with one IPv4 subnet configured. It demonstrates // how to configure Kea to use CQL (Cassandra) backend { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // 4. CQL (Cassandra) backend. Leases will be stored in Cassandra // database. Make sure it is up, running and properly initialized. See // kea-admin documentation for details on how to initialize the // database. The only strictly required parameters are type, keyspace // and contact-points. At least one contact point must be specified, but // more than one is required for redundancy. Make sure you specify the // contact points without spaces. Kea must be compiled with --with-cql // option to use this backend. "lease-database": { "type": "cql", "keyspace": "keatest", "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", "port": 9042, // Cassandra supports many additonal parameters that are typically // not needed, but may be used to tweak your deployment. // This parameter governs how long Kea waits before attempting // to reconnect. Expressed in milliseconds. The default is 2000 [ms]. "reconnect-wait-time": 2000, // This parameter sets the timeout for connecting to a node. Expressed // in milliseconds. The default is 5000 [ms]. "connect-timeout": 5000, // This parameter sets the timeout for waiting for a response // from a node. Expressed in milliseconds. The default is 12000 [ms]. "request-timeout": 12000, // This parameter governs the TCP keep-alive mechanism. Expressed // in seconds of delay. The default is disabled. In this example // it is set to 20 minutes. "tcp-keepalive": 1200, // This parameter enables/disables Nagle's algorithm on connections. // The default is true. "tcp-nodelay": true, // This parameter configures consistency level. The default is "quorum". // Supported values: // - any // - one // - two // - three // - quorum // - all // - local-quorum // - each-quorum // - serial // - local-serial // - local-one // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigConsistency.html for more details. "consistency": "quorum", // This parameter configures serial consistency level which manages // lightweight transaction isolation. The default is "serial". // Supported values: // - any // - one // - two // - three // - quorum // - all // - local-quorum // - each-quorum // - serial // - local-serial // - local-one // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigSerialConsistency.html for more details. "serial-consistency": "serial" }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // The following list defines subnets. We have only one subnet // here. We tell Kea that it is directly available over local interface. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX" } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/ha-load-balancing-primary.json0000644000175000017500000002247313623761160020222 00000000000000// This is an example configuration of the Kea DHCPv4 server. It uses High // Availability hooks library and Lease Commands hooks library to enable // High Availibility function for the DHCP server. Note that almost exactly // the same configuration must be used on the second server (partner). // The only difference is that "this-server-name" must be set to "server2" // on this other server. Also, the interface configuration depends on the // network settings of the particular machine. // // The servers using this configuration work in load balancing mode. { // DHCPv4 configuration starts here. "Dhcp4": { // Add names of your network interfaces to listen on. "interfaces-config": { // The DHCPv4 server listens on this interface. "interfaces": [ "ethX" ] }, // Control socket is required for communication between the Control // Agent and the DHCP server. High Availability requires Control Agent // to be running because lease updates are sent over the RESTful // API between the HA peers. "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea-dhcp4-ctrl.sock" }, // 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) and even Cassandra. 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 a in-memory "type": "memfile" }, // Client classes will associate address pools with certain servers taking // part in providing High Availability. "client-classes": [ // phones class { "name": "phones", "test": "substring(option[60].hex,0,6) == 'Aastra'" }, // laptops are everything but phones. { "name": "laptops", "test": "not member('phones')" }, // Some phones will be handled by server1. Whether the HA_server1 // or HA_server2 is assigned for the client is a matter of load // balancing performed by the HA hooks library. { "name": "phones_server1", "test": "member('phones') and member('HA_server1')" }, // Some phones will be handled by server2. { "name": "phones_server2", "test": "member('phones') and member('HA_server2')" }, // Some laptops will be handled by server1. { "name": "laptops_server1", "test": "member('laptops') and member('HA_server1')" }, // Some laptops will be handled by server2. { "name": "laptops_server2", "test": "member('laptops') and member('HA_server2')" } ], // HA requires two hooks libraries to be loaded: libdhcp_lease_cmds.so and // libdhcp_ha.so. The former handles incoming lease updates from the HA peers. // The latter implements high availability feature for Kea. "hooks-libraries": [ // The lease_cmds library must be loaded because HA makes use of it to // deliver lease updates to the server as well as synchronize the // lease database after failure. { "library": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so", "parameters": { } }, { // The HA hooks library should be loaded. "library": "/opt/lib/kea/hooks/libdhcp_ha.so", "parameters": { // High Availability configuration is specified for the HA hook library. // Each server should have the same HA configuration, except for the // "this-server-name" parameter. "high-availability": [ { // This parameter points to this server instance. The respective // HA peers must have this parameter set to their own names. "this-server-name": "server1", // The HA mode is set to load-balancing. In this mode, the active // servers share the traffic (50/50). "mode": "load-balancing", // Heartbeat is to be sent every 10 seconds if no other control // commands are transmitted. "heartbeat-delay": 10000, // Maximum time for partner's response to a heartbeat, after which // failure detection is started. This is specified in milliseconds. "max-response-delay": 10000, // The following parameters control how the server detects the // partner's failure. The ACK delay sets the threshold for the // 'secs' field of the received discovers. This is specified in // milliseconds. "max-ack-delay": 5000, // This specifies the number of clients which send messages to // the partner but appear to not receive any response. "max-unacked-clients": 5, // This specifies the maximum timeout (in milliseconds) for the server // to complete sync. If you have a large deployment (high tens or // hundreds of thausands of clients), you may need to increase it // further. The default value is 60000ms (60 seconds). "sync-timeout": 60000, "peers": [ // This is the configuration of this server instance. { "name": "server1", // This specifies the URL of our server instance. The // Control Agent must run along with our DHCPv4 server // instance and the "http-host" and "http-port" must be // set to the corresponding values. "url": "http://192.168.56.33:8080/", // This server is primary. The other one must be // secondary. "role": "primary" }, // This is the configuration of our HA peer. { "name": "server2", // Specifies the URL on which the partner's control // channel can be reached. The Control Agent is required // to run on the partner's machine with "http-host" and // "http-port" values set to the corresponding values. "url": "http://192.168.56.66:8080/", // The partner is a secondary. Our is primary. "role": "secondary" } ] } ] } } ], // This example contains a single subnet declaration. "subnet4": [ { // Subnet prefix. "subnet": "192.0.3.0/24", // Specify four address pools. "pools": [ { "pool": "192.0.3.100 - 192.0.3.125", "client-class": "phones_server1" }, { "pool": "192.0.3.126 - 192.0.3.150", "client-class": "laptops_server1" }, { "pool": "192.0.3.200 - 192.0.3.225", "client-class": "phones_server2" }, { "pool": "192.0.3.226 - 192.0.3.250", "client-class": "laptops_server2" } ], // 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": [ { // For each IPv4 subnet you most likely need to specify at // least one router. "name": "routers", "data": "192.0.3.1" } ], // This subnet will be selected for queries coming from the following // IP address. "relay": { "ip-address": "192.168.56.1" } } ], // Logging configuration starts here. "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": [ { "output": "stdout" } ], "severity": "INFO" }, { // This section specifies configuration of the HA hooks library specific // logger. "name": "kea-dhcp4.ha-hooks", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/several-subnets.json0000644000175000017500000000554213623761160016440 00000000000000// This is an example configuration file for DHCPv4 server in Kea. // It's a basic scenario with three IPv4 subnets configured. In each // subnet, there's a smaller pool of dynamic addresses. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // Addresses will be assigned with a lifetime of 4000 seconds. // The client is told to start renewing after 1000 seconds. If the server // does not respond within 2000 seconds of the lease being granted, client // is supposed to start REBIND procedure (emergency renewal that allows // switching to a different server). "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // RFC6842 says that the server is supposed to echo back client-id option. // However, some older clients do not support this and are getting confused // when they get their own client-id. Kea can disable RFC6842 support. "echo-client-id": false, // Some clients don't use stable client identifier, but rather generate them // during each boot. This may cause a client that reboots frequently to get // multiple leases, which may not be desirable. As such, sometimes admins // prefer to tell their DHCPv4 server to ignore client-id value altogether // and rely exclusively on MAC address. This is a parameter that is defined // globally, but can be overridden on a subnet level. "match-client-id": true, // By default, Kea ignores requests by clients for unknown IP addresses, // because other non-cooperating DHCP servers could reside on the same // network (RFC 2131). This parameter is defined globally, but can be // overriden on a subnet level "authoritative": false, // The following list defines subnets. Each subnet consists of at // least subnet and pool entries. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24" }, { // This particular subnet has match-client-id value changed. "pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ], "subnet": "192.0.3.0/24", "match-client-id": false }, { "pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ], "subnet": "192.0.4.0/24" } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/mysql-reservations.json0000644000175000017500000000703113623761160017200 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It contains configuration of the MySQL host database backend, used // to retrieve reserved addresses, host names, DHCPv4 message fields // and DHCP options from MySQL database. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // 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). When told to do so, Kea can check for all of those // identifier types, but it takes a costly database lookup to do so. It // is therefore useful from a performance perspective to use only the // reservation types that are actually used in a given network. // The example below is not optimal from a performance perspective, but it // nicely showcases the host reservation capabilities. Please use the minimum // set of identifier types used in your network. "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ], // Specify connection to the database holding host reservations. The type // specifies that the MySQL database is used. user and password are the // credentials used to connect to the database. host and name specify // location of the host where the database instance is running, and the // name of the database to use. The server processing a packet will first // check if there are any reservations specified for this client in the // reservations list, within the subnet (configuration file). If there are // no reservations there, the server will try to retrieve reservations // from this database. "hosts-database": { "type": "mysql", "name": "kea", "user": "kea", "password": "kea", "host": "localhost", "port": 3306 }, // Define a subnet with a single pool of dynamic addresses. Addresses from // this pool will be assigned to clients which don't have reservations in the // database. Subnet identifier is equal to 1. If this subnet is selected for // the client, this subnet id will be used to search for the reservations // within the database. "subnet4": [ { "pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX", "id": 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/config-backend.json0000644000175000017500000000611613623761160016146 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It demonstrates how to enable Kea Configuration Backend using MySQL. // It requires that libdhcp_mysql_cb.so library is available and // optionally libdhcp_cb_cmds.so hooks library. { "Dhcp4": { // Set the server tag for the configuration backend. This instance will // be named server1. Every configuration element that is applicable to // either "all" or "server1" will be used by this instance. "server-tag": "server1", // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Use memfile lease database backend. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // This parameter controls how the server accesses the configuration // database. Currently only one database type is available - "mysql". // It requires that libdhcp_mysql_cb.so hooks library is loaded. "config-control": { // A list of database backends to connect to. Currently, it is limited // to a single backend. "config-databases": [ { "type": "mysql", "name": "kea", "user": "kea", "password": "kea", "host": "localhost", "port": 3306 } ], // Controls how often the server polls the database for the // configuration updates. The setting below implies that it // will take up to approx. 20 seconds for the server to // discover and fetch configuration changes. "config-fetch-wait-time": 20 }, // This defines a control socket. If defined, Kea will open a UNIX socket // and will listen for incoming commands. See section 17 of the Kea ARM for // details. "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea-dhcp4.sock" }, // Hooks libraries that enable configuration backend are loaded. "hooks-libraries": [ // The libdhcp_mysql_cb.so is required to use MySQL Configuration // Backend. { "library": "/usr/local/lib/kea/hooks/libdhcp_mysql_cb.so" } // The libdhcp_cb_cmds.so is optional. It allows for managing the // configuration in the database. If this library is not loaded, // the configuration can be managed directly using available // tools that work directly with the MySQL database. //,{ // "library": "/usr/local/lib/kea/hooks/libdhcp_cb_cmds.so" //} ], // The following configures logging. It assumes that messages with at // least informational level (info, warn, error and fatal) should be // logged to stdout. Alternatively, you can specify stderr here, a filename // or 'syslog', which will store output messages via syslog. "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/classify.json0000644000175000017500000001107513623761160015131 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // The purpose of this example is to showcase how clients can be classified. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Let's use the simplest backend: memfile and use some reasonable values // for timers. They are of no concern for the classification demonstration. "lease-database": { "type": "memfile" }, "renew-timer": 1000, "rebind-timer": 2000, "valid-lifetime": 4000, // This list defines several classes that incoming packets can be assigned to. // One packet can belong to zero or more classes. "client-classes": [ // The first class attempts to match the whole hardware address to a specific // value. All incoming packets with that MAC address will get a special // value of the option. If there are many hosts that require special // treatment, it is much better to use host reservations. However, doing // tricks with MAC addresses may prove useful in some cases, e.g. // by matching OUI to known values we can detect certain vendors. { "name": "special_snowflake", "test": "pkt4.mac == 0x010203040506", "option-data": [{ "name": "domain-name-servers", "data": "127.0.0.1" }] }, // Let's classify all incoming DISCOVER (message type 1) to a separate // class. { "name": "discovers", "test": "pkt4.msgtype == 1" }, // Clients are supposed to set the transaction-id field to a random value. // Clients that send it with 0 are most likely broken. Let's mark them // as such. { "name": "broken", "test": "pkt4.transid == 0" }, // Let's pick VoIP phones. Those that send their class identifiers // as Aastra, should belong to VoIP class. For a list of all options, // see www.iana.org/assignments/bootp-dhcp-parameters/. // In this particular class, we want to set specific values // of certain DHCPv4 fields. If the incoming packet matches the // test, those fields will be set in outgoing responses. // The option 43 is defined to encapsulate suboption in the aastra space. { "name": "VoIP", "test": "substring(option[60].hex,0,6) == 'Aastra'", "next-server": "192.0.2.254", "server-hostname": "hal9000", "boot-file-name": "/dev/null", "option-def": [ { "name": "vendor-encapsulated-options", "code": 43, "type": "empty", "encapsulate": "aastra" } ] } ], // The following list defines subnets. For some subnets we defined // a class that is allowed in that subnet. If not specified, // everyone is allowed. When a class is specified, only packets belonging // to that class are allowed for that subnet. "subnet4": [ // This one is for VoIP devices only. { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "client-class": "VoIP", "interface": "ethX" }, // This one doesn't have any client-class specified, so everyone // is allowed in. The normal subnet selection rules still apply, // though. There is also a static class reservation for a client // using MAC address 1a:1b:1c:1d:1e:1f. This client will always // be assigned to this class. { "pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ], "subnet": "192.0.3.0/24", "reservations": [ { "hw-address": "1a:1b:1c:1d:1e:1f", "client-classes": [ "VoIP" ] } ], "interface": "ethX" }, // The following list defines a subnet with pools. For some pools // we defined a class that is allowed in that pool. If not specified // everyone is allowed. When a class is specified, only packets belonging // to that class are allowed for that pool. { "pools": [ // This one is for VoIP devices only. { "pool": "192.0.4.1 - 192.0.4.200", "client-class": "VoIP" }, // This one doesn't have any client-class specified, // so everyone is allowed in. { "pool": "192.0.5.1 - 192.0.5.200" } ], "subnet": "192.0.4.0/23", "interface": "ethY" } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/multiple-options.json0000644000175000017500000001641513623761160016643 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It demonstrates simple configuration of the options for a subnet. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // Defining a subnet. There are some DHCP options returned to the // clients connected to this subnet. The first and third options are // clients connected to this subnet. The first two options are // identified by the name. The third option is identified by the // option code. // There is an address pool defined within this subnet. Pool // specific value for option domain-name-servers is defined // for the pool. "subnet4": [ { "subnet": "192.0.2.0/24", "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.0.2.1, 192.0.2.2" }, // Note the Kea provides some of the options on its own. In // particular: // - IP address lease time (option 51) is governed by // valid-lifetime parameter, so you don't need to specify // it as option. // - Subnet mask (option 1) is calculated automatically from the // subnet parameter specified for each "subnet4" entry. // - renewal-timer (option 58) is calculated from renew-timer // parameter // - rebind timer (option 59) is calculated from rebind-timer // parameter // For each IPv4 subnet you most likely need to specify at least // one router. { "name": "routers", "data": "192.0.2.1" }, // 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, "data": "example.org" }, // Domain search is also a popular option. It tells the client to // attempt to resolve names within those specificed 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": "mydomain.example.com, example.com" }, // Options can also be specified using hexadecimal format. // This should be avoided if possible, because Kea ability to // validate correctness is limited when using hex values. { "name": "broadcast-address", "csv-format": false, "data": "ffff8000" }, // 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 hexa-decimal 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" }, // At a few exceptions options are added to response only when // the client requests them. The always-send flag should be used // to enforce a particular option. { "name": "vendor-class-identifier", "data": "isc", "always-send": true } ], // Now we define pools. There are two pools here. "pools": [ { // This is the first pool. Nothing spectacular here, just a range // of addresses. "pool": "192.0.2.10 - 192.0.2.100" }, { // This second pool is more interesting. Anyone who gets an // address from this pool will also get this specific option // value if asks for DNS servers configuration. This value, // being more specific, overrides any values that were specified // on either global or subnet scope. "pool": "192.0.2.101 - 192.0.2.200", "option-data": [ { "name": "domain-name-servers", "data": "192.0.2.3, 192.0.2.4" } ] } ] } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/all-keys.json0000644000175000017500000010547413623761160015044 00000000000000// WARNING: This example configuration is not meant for production use. // The Kea DHCPv4 server will refuse this configuration because it contains // mutually exclusive configuration parameters. // // The primary purpose of the example file is to provide a comprehensive // list of parameters supported by Kea DHCPv4 server along with the brief // description of each parameter. // // This current version should be up to date, i.e. new keywords should be // added in this file at the same time than in the syntax. { // Kea DHCPv4 server configuration begins here. "Dhcp4": { // Global bootfile name to be set in the 'file' field. "boot-file-name": "/dev/null", // Ordered list of client classes used by the DHCPv4 server. "client-classes": [ { // Class specific bootfile name to be set in the 'file' field. "boot-file-name": "/tmp/bootfile.efi", // Class name. "name": "phones_server1", // Class specific next server address to use in bootstrap, which // is set in 'siaddr' field. "next-server": "10.2.3.4", // Class specific DHCPv4 options list. "option-data": [], // Class specific DHCPv4 option definitions, i.e. custom formats // specified for non-standard options. "option-def": [], // Class specific optional server hostname, which is set in // 'sname' field. "server-hostname": "", // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server1')" }, { // Default value of the class specific bootfile name. Empty name // means that the bootfile name is unspecified. "boot-file-name": "", // Second class name. "name": "phones_server2", // Default value of the class specific next server address. The // zero IPv4 address means that it is unspecified. "next-server": "0.0.0.0", // Class specific DHCPv4 options list. "option-data": [], // Class specific DHCPv4 option definitions, i.e. custom formats // specified for non-standard options. "option-def": [], // Class specific optional server hostname, which is set in // 'sname' field. "server-hostname": "", // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server2')" }, { // Third class name. "name": "late", // Boolean flag indicating that the class expression is only evaluated // when the class is required, e.g. selected address pool configuration // includes this class name in its "require-client-classes" list. The // default value false means that the class test expression must // always be evaluated. "only-if-required": true, // Class selection expression. "test": "member('ALL')" } ], // Command control socket configuration parameters for Kea DHCPv4 server. "control-socket": { // Location of the unix domain socket file the DHCPv4 server uses // to receive control commands from the Kea Control Agent or the // local server administrator. "socket-name": "/tmp/kea-dhcp4-ctrl.sock", // Control socket type used by the Kea DHCPv4 server. The 'unix' // socket is currently the only supported type. "socket-type": "unix" }, // Time in seconds specifying how long a declined lease should be // excluded from DHCP assignments. The default value is 24 hours. "decline-probation-period": 86400, // Name Change Requests forwarding configuration for Kea DHCPv4 server. // NCRs are sent to Kea D2 module to update DNS upon allocation of the // DHCP leases. "dhcp-ddns": { // Boolean flag indicating if Kea DHCPv4 server must generate NCRs. // By default NCRs are not generated. "enable-updates": false, // Specifies a prefix to be prepended to the generated Client FQDN. "generated-prefix": "myhost", // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // Specifies maximum number of NCRs to queue waiting to be sent // to Kea D2 server. "max-queue-size": 1024, // Packet format to use when sending NCRs to Kea D2 server. // Currently, only JSON format is supported. "ncr-format": "JSON", // Socket protocol to use when sending NCRs to D2. Currently, // only UDP is supported. "ncr-protocol": "UDP", // Boolean flag indicating that server should ignore DHCP client // wishes to update DNS on its own. With that flag set to true // the server will send DNS updates for both forward and // reverse DNS data. The default value is false, which indicates // that the server will delegate DNS update to the client when // requested. "override-client-update": false, // Boolean flag indicating that the server should override DHCP // client's wish to not update the DNS. With this parameter // set to true the server will send DNS update even when // the client requested no update. "override-no-update": false, // Suffix appended to the partial name sent to the DNS. The // default value is an empty string which indicates that no // suffix is appended. "qualifying-suffix": "", // Enumeration specifying whether the server should honor // hostname or Client FQDN sent by the client or replace // this name. The acceptable values are: "never" (use the // name the client sent), "always" (replace the name the // client sent), "when-present" (replace the name the client // sent, but do not generate one when the client didn't sent // the name), "when-not-present" (generate the name when // client didn't send one, otherwise leave the name the // client sent). The default value is "never". "replace-client-name": "never", // IP address that Kea DHCPv4 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable address. "sender-ip": "0.0.0.0", // Port number that Kea DHCPv4 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable port. "sender-port": 0, // IP address on which D2 listens for NCRs. "server-ip": "127.0.0.1", // Port number on which D2 listens for NCRs. "server-port": 53001 }, // Specifies the first of the two consecutive ports of the UDP // sockets used for communication between DHCPv6 and DHCPv4 // servers. See RFC 7341. "dhcp4o6-port": 6767, // Boolean flag indicating whether or not the Kea DHCPv4 server // should send back Client Identifier option in its responses. // The default value is true which indicates that the option // must be sent back if the client included it. The false // value instructs the server to not send this option for // backward compatibility with older DHCP specifications which // stated that Client Identifier must not be sent back. "echo-client-id": true, // Collection of Kea DHCPv4 server parameters configuring how // the server should process expired DHCP leases. "expired-leases-processing": { // Specifies the number of seconds since last removal of // the expired leases when next removal should occur. "flush-reclaimed-timer-wait-time": 25, // Specifies the time period in seconds to keep expired // leases in the lease database (lease affinity). "hold-reclaimed-time": 3600, // Specifies the maximum number of expired leases that can be // processed in a single attempt to clean up the lease // database from the expired leases. If there are more // expired leases, they will be processed during the next // cleanup attempt. "max-reclaim-leases": 100, // Specifies the maximum time in milliseconds that the single // attempt to cleanup the lease database from the expired // leases may take. "max-reclaim-time": 250, // Specifies the time period in seconds since last attempt // to process expired leases to initiate the next attempt. "reclaim-timer-wait-time": 10, // Specifies the maximum number of expired leases processing // cycles which didn't result in full cleanup of the lease // database from the expired leases, after which a // warning message is issued. "unwarned-reclaim-cycles": 5 }, // List of hooks libraries and their specific configuration parameters // to be loaded by Kea DHCPv4 server. "hooks-libraries": [ { // Location of the hooks library to be loaded. "library": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so", // Hook library specific configuration parameters. "parameters": { } } ], // List of access credentials to external sources of IPv4 reservations, "hosts-databases": [ { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 3306, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 5432, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "postgresql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "keyspace": "kea", // Host on which the database resides. "contact-points": "127.0.0.1", // Database password. "password": "kea", // Port on which the database is available. "port": 9042, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "cql", // User name to be used to access the database. "user": "kea", // Consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "consistency": "quorum", // Serial consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "serial-consistency": "serial", // Connection reconnect wait time. "reconnect-wait-time": 100, // Connection connect timeout. "connect-timeout": 100, // Connection request timeout. "request-timeout": 100, // Connection tcp keepalive. "tcp-keepalive": 100, // Connection tcp nodelay. "tcp-nodelay": true } ], // List of host reservation identifier types to be used by the // Kea DHCPv4 server to fetch static reservations for the // DHCP clients. All identifiers are used by default, which // means that the server will issue multiple queries to the // database to find if there is a reservation for the particular // client. If the particular deployment uses only subset, e.g. // one, identifier type, this identifier should be only listed // here to prevent unnecessary queries to the database. "host-reservation-identifiers": [ "hw-address", "duid", "circuit-id", "client-id", "flex-id" ], // Specifies configuration of interfaces on which the Kea DHCPv4 // server is listening to the DHCP queries. "interfaces-config": { // Specifies whether the server should use "udp" socket or // "raw" sockets to listen to the DHCP traffic. The "raw" // sockets are useful when direct DHCP traffic is being // received. "dhcp-socket-type": "udp", // Specifies a list of interfaces on which the Kea DHCPv4 // server should listen to the DHCP requests. "interfaces": [ "ethX" ], // Enumeration which indicates what interface should be used // to send DHCP response to the client. The default value is // "same-as-inbound" which indicates that the response should // be sent via the interface on which the client's query // was received. The "use-routing" value indicates that the // Kea server should use kernel's routing table to find the // suitable interface. "outbound-interface": "same-as-inbound", // Boolean flag indicating if the available interfaces should // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. "re-detect": true }, // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval // in seconds at which lease file should be cleaned up (outdated // lease entries are removed to prevent lease file from growing // infinitely). "lfc-interval": 3600, // Maximum number of lease file read errors allowed before // loading the file is abandoned. Defaults to 0 (no limit). "max-row-errors": 100, // Name of the lease file. In case of database it specifies the // database name. "name": "/tmp/kea-dhcp4.csv", // memfile specific parameter indicating whether leases should // be saved on persistent storage (disk) or not. The true value // is the default and it indicates that leases are stored in the // persistent storage. This setting must be used in production. // The false value should only be used for testing purposes // because non stored leases will be lost upon Kea server restart. "persist": true, // Lease database backend type, i.e. "memfile", "mysql", // "postgresql" or "cql". "type": "memfile" }, // Boolean value indicating if the Kea DHCPv4 server should use client // identifier value sent by the client or ignore it. The default value // is true which indicate that the server should use client identifier // and that it takes precedence over client's MAC address. In deployments // where MAC address should take precedence this value can be set to // false, in which case the clients will be identified by MAC address. // This is specifically useful when clients don't generate unique // identifiers or these identifiers are not stable etc. "match-client-id": false, // Global value of the next server address set in 'siaddr' field. // The global value may be overriden in lower level configuration // scopes. "next-server": "192.0.2.123", // List of global DHCP options that Kea DHCPv4 server assigns to the // clients. "option-data": [ { // Boolean flag indicating if the given option is always // send in response or only when requested. The default // value of false indicates that it is only sent when // requested. "always-send": false, // Option code. It is not required if the option name is // provided. "code": 6, // Boolean value indicating whether the option data specified // in the "data" field is specified as a string of hexadecimal // digits or in human readable CSV format. "csv-format": true, // Option data to be stored in the option payload. "data": "192.0.3.1, 192.0.3.2", // Option name. It is not required of the option code is // provided. "name": "domain-name-servers", // Option space. The default is the "dhcp4" option space which // groups top level DHCPv4 options. "space": "dhcp4" } ], // List of global option definitions, i.e. option formats, that the // Kea DHCPv4 server is using. "option-def": [ { // Boolean flag indicating if the option definition comprises // an array of values of some type, e.g. array of IPv4 addresses. // The default value of false means that the option does not // comprise an array of values. "array": false, // Option code. "code": 6, // Holds a name of the option space encapsulated by this option. // All options that belong to this option space will be sent // as sub-options of this option. Empty string means that this // option doesn't encapsulate any option. "encapsulate": "", // Option name. "name": "my-option", // Specifies the types of fields within the option if the option // is said to be a "record" (see "type"). in this particular example // this option comprises two fields, 1 byte and 2 bytes long. "record-types": "uint8, uint16", // Name of the option space to which this option belongs. "space": "my-space", // Option type. All possible types are listed in the Kea // Administrator Reference Manual. "type": "record" } ], // Global value for the rebind timer, i.e. the time after which the // DHCP client enters rebind state if it fails to renew the lease. "rebind-timer": 40, // Global value for the renew timer, i.e. the timer after which the // DHCP client renews the lease. "renew-timer": 30, // Governs how the Kea DHCPv4 server should deal with the invalid // data received from the client. "sanity-checks": { // Specifies how the Kea DHCPv4 server should behave when invalid // data is read for a lease from the lease file. The following // values are supported "none" (don't attempt to correct the // lease information), "warn" (print a warning for subnet-id // related inconsistencies), "fix" (correct the subnet id by // trying to find the suitable subnet), "fix-del" (similar // to "fix" but delete the lease if no suitable subnet found), // "del" (delete the lease if the lease has invalid subnet // identifier value). "lease-checks": "warn" }, // List of shared networks used by Kea DHCPv4 server. The shared // networks group subnets together. "shared-networks": [ { // Shared network level bootfile name. "boot-file-name": "/dev/null", // Restricts this shared network to allow only clients // that belong to the particular client class. If an // empty string is provided, no restriction is applied. "client-class": "", // Specifies that this shared network is selected for the // requests received on the particular interface. "interface": "ethX", // Shared network level flag specifying whether the client // identifier should be used for identifying clients. "match-client-id": true, // Shared network name. "name": "my-secret-network", // Shared network level specification of the next server // to be sent in 'siaddr'. "next-server": "192.0.2.123", // List of shared network specific DHCP options. "option-data": [], // List of IPv4 relay addresses for which this shared // network is selected. "relay": { "ip-addresses": [] }, // Shared network level rebind timer. "rebind-timer": 41, // Shared network level renew timer. "renew-timer": 31, // Shared network level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // List of client classes which must be evaluated when this shared // network is selected for client assignments. "require-client-classes": [ "late" ], // Shared network level server hostname set in 'sname' field. "server-hostname": "", // List of IPv4 subnets belonging to this shared network. "subnet4": [ { // Interface name matched against inbound interface name. // Used in DHCPv4o6. See RFC 7341. "4o6-interface": "", // Interface ID option value. See RFC 7341. "4o6-interface-id": "", // Prefix matched against source address. See RFC7341. "4o6-subnet": "2001:db8:1:1::/64", // Subnet level bootfile name, set in 'file' field. "boot-file-name": "", // Restricts this subnet to allow only clients that belong // to the particular client class. If an empty string is // provided, no restriction is applied. "client-class": "", // Subnet unique identifier. "id": 1, // Specifies that this subnet is selected for the requests // received on the particular interface. "interface": "ethX", // Subnet level flag specifying whether the client identifier // should be used for identifying clients. "match-client-id": true, // Subnet level specification of the next server to be sent // in 'siaddr'. "next-server": "0.0.0.0", // Subnet level list of DHCP options. "option-data": [ { // Boolean flag indicating if the particular option // should be always sent or sent only when requested. "always-send": false, // Option code. "code": 3, // Boolean flag indicating if the option value specified // in "data" is a string of hexadecimal values or human // readable CSV value. "csv-format": true, // Option data to be included in the option payload. "data": "192.0.3.1", // Option name. "name": "routers", // Option space. The default value "dhcp4" designates the // top level option space. "space": "dhcp4" } ], // List of IP address pools belonging to the subnet. "pools": [ { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server1", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "192.1.0.1 - 192.1.0.200", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [ "late" ] }, { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server2", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "192.3.0.1 - 192.3.0.200", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [] } ], // Subnet level value of the rebind timer. "rebind-timer": 40, // List of IPv4 relay addresses for which this subnet is // selected. "relay": { "ip-addresses": [ "192.168.56.1" ] }, // Subnet level value of the renew timer. "renew-timer": 30, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // Subnet-level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // List of static IPv4 reservations assigned to the clients belonging // to this subnet. For detailed example see reservations.json. "reservations": [ { // Identifier used for client matching. Supported values are // "hw-address", "client-id", "duid", "circuit-id", "flex-id". "circuit-id": "01:11:22:33:44:55:66", // Reserved IP address. "ip-address": "192.0.2.204", // Reservation specific option data. "option-data": [ { // Option name. "name": "vivso-suboptions", // Option data. "data": "4491" } ] } ], // List of client classes which must be evaluated when this subnet // is selected for client assignments. "require-client-classes": [ "late" ], // Subnet level server hostname set in 'sname' field. "server-hostname": "", // Subnet prefix. "subnet": "192.0.0.0/8", // Subnet level (default) valid lifetime. "valid-lifetime": 6000, // Subnet level min valid lifetime. "min-valid-lifetime": 4000, // Subnet level max valid lifetime. "max-valid-lifetime": 8000 } ], // Shared network level (default) valid lifetime. "valid-lifetime": 6001, // Subnet level min valid lifetime. "min-valid-lifetime": 4001, // Subnet level max valid lifetime. "max-valid-lifetime": 8001 } ], // Global server hostname set in the 'sname' field. "server-hostname": "", // List of IPv4 subnets which don't belong to any shared network. "subnet4": [], // Global valid (default) lifetime value. "valid-lifetime": 6000, // Global min valid lifetime value. "min-valid-lifetime": 4000, // Global max valid lifetime value. "max-valid-lifetime": 8000, // Reservations (examples are in other files). "reservations": [], // Configuration control (currently not used, i.e. this syntax // is already defined but corresponding feature is not implemented). "config-control": { // Only configuration databases entry is defined. "config-databases": [ { // Name of the database to connect to. "name": "config", // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql" } ], // Intervals between attempts to fetch configuration updates // via the configuration backends used. "config-fetch-wait-time": 30 }, // Server tag. "server-tag": "my DHCPv4 server", // DHCP queue control parameters. "dhcp-queue-control": { // Enable queue is mandatory. "enable-queue": true, // Queue type was mandatory. "queue-type": "kea-ring4" }, // Fetches host reservations. "reservation-mode": "all", // Global compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // List of loggers used by the servers using this configuration file. "loggers": [ { // Debug level, a value between 0..99. The greater the value // the more detailed debug log. "debuglevel": 99, // Name of the logger. "name": "kea-dhcp4", // Configures how the log should be output. "output_options": [ { // Determines whether the log should flushed to a file. "flush": true, // Specifies maximum filesize before the file is being rotated. "maxsize": 10240000, // Specifies the maximum number of rotated files being kept. "maxver": 1, // Specifies logging destination. "output": "stdout", // Specifies log entry content "pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" } ], // Specifies logging severity, i.e. "ERROR", "WARN", "INFO", "DEBUG". "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/comments.json0000644000175000017500000000504313623761160015137 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It uses embedded (i.e., which will be included in configuration objects // and not stripped by at lexical analysis) comments. { "Dhcp4": { // Global scope "comment": "A DHCPv4 server", // In interface config "interfaces-config": { "comment": "Use wildcard", "interfaces": [ "*" ] }, // In option definitions "option-def": [ { "comment": "An option definition", "name": "foo", "code": 100, "type": "ipv4-address", "space": "isc" } ], // In option data "option-data": [ { "comment": "Set option value", "name": "dhcp-message", "data": "ABCDEF0105", "csv-format": false } ], // In client classes "client-classes": [ { "comment": "match all", "name": "all", "test": "'' == ''" }, // Of course comments are optional { "name": "none" }, // A comment and a user-context can be specified { "comment": "a comment", "name": "both", "user-context": { "version": 1 } } ], // In control socket (more for the agent) "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea4-ctrl-socket", "user-context": { "comment": "Indirect comment" } }, // In shared networks "shared-networks": [ { "comment": "A shared network", "name": "foo", // In subnets "subnet4": [ { "comment": "A subnet", "subnet": "192.0.1.0/24", "id": 100, // In pools "pools": [ { "comment": "A pool", "pool": "192.0.1.1-192.0.1.10" } ], // In host reservations "reservations": [ { "comment": "A host reservation", "hw-address": "AA:BB:CC:DD:EE:FF", "hostname": "foo.example.com", // Again in an option data "option-data": [ { "comment": "An option in a reservation", "name": "domain-name", "data": "example.com" } ] } ] } ] } ], // In dhcp ddns "dhcp-ddns": { "comment": "No dynamic DNS", "enable-updates": false }, // In loggers "loggers": [ { "comment": "A logger", "name": "kea-dhcp4" } ] } } kea-1.6.2/doc/examples/kea4/reservations.json0000644000175000017500000001467713623761160016053 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It contains one subnet in which there are two static address reservations // for the clients identified by the MAC addresses. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of September // 2016, four database backends are supported: MySQL, PostgreSQL, Cassandra, and // the in-memory database, Memfile. We'll use memfile because it doesn't // require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // 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), circuit-id // (circuit identifier inserted by the relay agent) and flex-id (flexible // identifier available when flex_id hook library is loaded). When told to do // so, Kea can check for all of those identifier types, but it takes a costly // database lookup to do so. It is therefore useful from a performance // perspective to use only the reservation types that are actually used in a // given network. // The example below is not optimal from a performance perspective, but it // nicely showcases the host reservation capabilities. Please use the minimum // set of identifier types used in your network. "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id", "flex-id" ], // Define a subnet with four reservations. Some of the reservations belong // to the dynamic pool. Kea is able to handle this case, but it is not // recommended from a performance perspective, as Kea would not only need to // check if a given address is free, but also whether it is reserved. // To avoid this check, one can change reservation-mode to out-of-pool, rather // than 'all'. If a subnet does not have reservations at all, the reservation // lookup can be skipped altogether (reservation-mode is set to 'disabled'). // Note that the second reservation is for an address which is within the // range of the pool of the dynamically allocated address. The server will // exclude this address from this pool and only assign it to the client which // has a reservation for it. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "eth0", // This directive tells Kea that reservations may be made both in-pool // and out-of-pool. For improved performance, you may move all reservations // out of the dynamic pool and change reservation-mode to "out-of-pool". // Kea will then be able to skip querying for host reservations when // assigning leases from dynamic pool. "reservation-mode": "all", "reservations": [ // This is a reservation for a specific hardware/MAC address. It's a very // 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 also // defines 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. { "circuit-id": "01:11:22:33:44:55:66", "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" } ] } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/backends.json0000644000175000017500000000775513623761160015100 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It is a basic scenario with one IPv4 subnet configured. It demonstrates // how to configure Kea to use various backends to store leases: // - memfile // - MySQL // - PostgreSQL // - CQL (Cassandra) backend { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify lease type. Exactly one lease-database section // should be present. Make sure you uncomment only one. // 1. memfile backend. Leases information will be stored in flat CSV file. // This is the easiest backend to use as it does not require any extra // dependencies or services running. // "lease-database": { // "type": "memfile", // "persist": true, // "lfc-interval": 3600 // }, // 2. MySQL backend. Leases will be stored in MySQL database. Make sure it // is up, running and properly initialized. See kea-admin documentation // for details on how to initialize the database. The only strictly required // parameters are type and name. If other parameters are not specified, // Kea will assume the database is available on localhost, that user and // password is not necessary to connect and that timeout is 5 seconds. // Kea must be compiled with --with-mysql option to use this backend. // "lease-database": { // "type": "mysql", // "name": "keatest", // "host": "localhost", // "port": 3306, // "user": "keatest", // "password": "secret1", // "connect-timeout": 3 // }, // 3. PostgreSQL backend. Leases will be stored in PostgreSQL database. Make // sure it is up, running and properly initialized. See kea-admin documentation // for details on how to initialize the database. The only strictly required // parameters are type and name. If other parameters are not specified, // Kea will assume the database is available on localhost, that user and // password is not necessary to connect and that timeout is 5 seconds. // Kea must be compiled with --with-pgsql option to use this backend. // "lease-database": { // "type": "postgresql", // "name": "keatest", // "host": "localhost", // "port": 5432, // "user": "keatest", // "password": "secret1", // "connect-timeout": 3 // }, // 4. CQL (Cassandra) backend. Leases will be stored in Cassandra // database. Make sure it is up, running and properly initialized. See // kea-admin documentation for details on how to initialize the // database. The only strictly required parameters are type, keyspace // and contact-points. At least one contact point must be specified, but // more than one is required for redundancy. Make sure you specify the // contact points without spaces. Kea must be compiled with --with-cql // option to use this backend. // "lease-database": { // "type": "cql", // "keyspace": "keatest", // "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", // "port": 9042 // }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // The following list defines subnets. We have only one subnet // here. We tell Kea that it is directly available over local interface. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX" } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/dhcpv4-over-dhcpv6.json0000644000175000017500000000154513623761160016646 00000000000000// This is an example configuration file for the DHCPv4 server of // DHCPv4-over-DHCPv6 tests in Kea. { // DHCPv4 conf "Dhcp4": { "interfaces-config": { "interfaces": [ "eno33554984" ] }, "lease-database": { "type": "memfile", "name": "leases4", "lfc-interval": 3600 }, "valid-lifetime": 4000, "subnet4": [ { "subnet": "10.10.10.0/24", // Don't forget the "4o6-" before "interface" here! "4o6-interface": "eno33554984", "4o6-subnet": "2001:db8:1:1::/64", "pools": [ { "pool": "10.10.10.100 - 10.10.10.199" } ] } ], // This enables DHCPv4-over-DHCPv6 support "dhcp4o6-port": 6767, "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "/tmp/kea-dhcp4.log" } ], "severity": "DEBUG", "debuglevel": 0 } ] } } kea-1.6.2/doc/examples/kea4/shared-network.json0000644000175000017500000001242113623761160016245 00000000000000// This is an example configuration file for DHCPv4 server in Kea. // It demonstrates an advanced feature called shared network. Typically, for // each physical link there is one IPv4 subnet that the server is expected // to manage. However, in some cases there is a need to configure more subnets // in the same physical location. The most common use case is an existing // subnet that grew past its original assumptions and ran out of addresses, // so the sysadmin needs to add another subnet on top of existing one. { "Dhcp4": { // As with any other configuration, you need to tell Kea the interface // names, so it would listen to incoming traffic. "interfaces-config": { "interfaces": [ "ethX" ] }, // You also need to tell where to store lease information. // memfile is the backend that is easiest to set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // The shared networks definition starts here. shared-networks can // contain a list of shared networks. There are many parameters // that can be specified here, so this example may be overwhelming // at first, but the only mandatory parameter for each shared // network is name. It must be unique. Typically, each shared // network also needs to have at least two subnets to be functional, // but if you really want to, you can define a degraded shared // network that has 1 or even 0 subnets. This may come in handy // when migrating between regular subnets and shared networks // or when debugging a problem. It is not recommended to use // 1 subnet per shared network, as there is extra processing // overhead for shared networks. "shared-networks": [ { // Name of the shared network. It may be an arbitrary string // and it must be unique among all shared networks. "name": "frog", // You may specify interface name if the shared network is // reachable directly from the server. "interface": "eth1", // You can specify many parameters that are allowed in subnet scope // here. It's useful to put them here if they apply to all subnets // in this shared network. It's likely that the most common // parameter here will be option values defined with option-data. "match-client-id": false, "option-data": [ ], "rebind-timer": 150, "authoritative": true, // If all the traffic coming from that shared network is reachable // via relay and that relay always use the same IP address, you // can specify that relay address here. Since this example shows // a shared network reachable directly, we put 0.0.0.0 here. // It would be better to skip the relay scope altogether, but // it was left here for demonstration purposes. "relay": { "ip-address": "0.0.0.0" }, // Timer values can be overridden here. "renew-timer": 100, "reservation-mode": "all", // This starts a list of subnets allowed in this shared network. // In our example, there are two subnets. "subnet4": [ { "id": 1, "match-client-id": true, "next-server": "0.0.0.0", "server-hostname": "", "boot-file-name": "", "option-data": [ ], "pools": [ ], "rebind-timer": 20, // You can override the value inherited from shared-network // here if your relay uses different IP addresses for // each subnet. "relay": { "ip-address": "0.0.0.0" }, "renew-timer": 10, "reservation-mode": "all", "subnet": "10.0.0.0/8", "valid-lifetime": 30 }, { "id": 2, "match-client-id": true, "next-server": "0.0.0.0", "server-hostname": "", "boot-file-name": "", "option-data": [ ], "pools": [ ], "rebind-timer": 20, "renew-timer": 10, "reservation-mode": "all", "subnet": "192.0.2.0/24", "valid-lifetime": 30 } ], "valid-lifetime": 200 } ], // end of shared-networks // It is likely that in your network you'll have a mix of regular, // "plain" subnets and shared networks. It is perfectly valid to mix // them in the same config file. // // This is regular subnet. It's not part of any shared-network. "subnet4": [ { "pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ], "subnet": "192.0.3.0/24", "interface": "eth0", "id": 3 } ] } // end of Dhcp4 } kea-1.6.2/doc/examples/kea4/single-subnet.json0000644000175000017500000000352113623761160016070 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It is a basic scenario with one IPv4 subnet configured. The subnet // contains a single pool of dynamically allocated addresses. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // The following list defines subnets. We have only one subnet // here. We tell Kea that it is directly available over local interface. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX" } ], // The following configures logging. It assumes that messages with at // least informational level (info, warn, error and fatal) should be // logged to stdout. Alternatively, you can specify stderr here, a filename // or 'syslog', which will store output messages via syslog. "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/with-ddns.json0000644000175000017500000000443013623761160015212 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It is a basic scenario with one IPv4 subnet configured but with DDNS // enabled. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // The following list defines subnets. We have only one subnet // here. We tell Kea that it is directly available over local interface. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX" } ], // Enable dynamic DNS updates "dhcp-ddns" : { "enable-updates" : true, "server-ip" : "192.0.2.0", "server-port" : 3432, "sender-ip" : "192.0.2.1", "sender-port" : 3433, "max-queue-size" : 2048, "ncr-protocol" : "UDP", "ncr-format" : "JSON", "override-no-update" : true, "override-client-update" : true, "replace-client-name" : "when-present", "generated-prefix" : "test.prefix", "qualifying-suffix" : "test.suffix.", "hostname-char-set": "[^A-Za-z0-9.-]", "hostname-char-replacement": "x" }, // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/all-keys-netconf.json0000644000175000017500000010525213623761160016470 00000000000000// WARNING: This example configuration is not meant for production use. // The Kea DHCPv4 server will refuse this configuration because it contains // mutually exclusive configuration parameters. // // The primary purpose of the example file is to provide a comprehensive // list of parameters supported by Kea DHCPv4 server along with the brief // description of each parameter. // // This stable version is used for YANG as we do not want to update code // and models each time a keyword is added to the syntax. { // Kea DHCPv4 server configuration begins here. "Dhcp4": { // Global bootfile name to be set in the 'file' field. "boot-file-name": "/dev/null", // Ordered list of client classes used by the DHCPv4 server. "client-classes": [ { // Class specific bootfile name to be set in the 'file' field. "boot-file-name": "/tmp/bootfile.efi", // Class name. "name": "phones_server1", // Class specific next server address to use in bootstrap, which // is set in 'siaddr' field. "next-server": "10.2.3.4", // Class specific DHCPv4 options list. "option-data": [], // Class specific DHCPv4 option definitions, i.e. custom formats // specified for non-standard options. "option-def": [], // Class specific optional server hostname, which is set in // 'sname' field. "server-hostname": "", // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server1')" }, { // Default value of the class specific bootfile name. Empty name // means that the bootfile name is unspecified. "boot-file-name": "", // Second class name. "name": "phones_server2", // Default value of the class specific next server address. The // zero IPv4 address means that it is unspecified. "next-server": "0.0.0.0", // Class specific DHCPv4 options list. "option-data": [], // Class specific DHCPv4 option definitions, i.e. custom formats // specified for non-standard options. "option-def": [], // Class specific optional server hostname, which is set in // 'sname' field. "server-hostname": "", // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server2')" }, { // Third class name. "name": "late", // Boolean flag indicating that the class expression is only evaluated // when the class is required, e.g. selected address pool configuration // includes this class name in its "require-client-classes" list. The // default value false means that the class test expression must // always be evaluated. "only-if-required": true, // Class selection expression. "test": "member('ALL')" } ], // Command control socket configuration parameters for Kea DHCPv4 server. "control-socket": { // Location of the unix domain socket file the DHCPv4 server uses // to receive control commands from the Kea Control Agent or the // local server administrator. "socket-name": "/tmp/kea-dhcp4-ctrl.sock", // Control socket type used by the Kea DHCPv4 server. The 'unix' // socket is currently the only supported type. "socket-type": "unix" }, // Time in seconds specifying how long a declined lease should be // excluded from DHCP assignments. The default value is 24 hours. "decline-probation-period": 86400, // Name Change Requests forwarding configuration for Kea DHCPv4 server. // NCRs are sent to Kea D2 module to update DNS upon allocation of the // DHCP leases. "dhcp-ddns": { // Boolean flag indicating if Kea DHCPv4 server must generate NCRs. // By default NCRs are not generated. "enable-updates": false, // Specifies a prefix to be prepended to the generated Client FQDN. "generated-prefix": "myhost", // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // Specifies maximum number of NCRs to queue waiting to be sent // to Kea D2 server. "max-queue-size": 1024, // Packet format to use when sending NCRs to Kea D2 server. // Currently, only JSON format is supported. "ncr-format": "JSON", // Socket protocol to use when sending NCRs to D2. Currently, // only UDP is supported. "ncr-protocol": "UDP", // Boolean flag indicating that server should ignore DHCP client // wishes to update DNS on its own. With that flag set to true // the server will send DNS updates for both forward and // reverse DNS data. The default value is false, which indicates // that the server will delegate DNS update to the client when // requested. "override-client-update": false, // Boolean flag indicating that the server should override DHCP // client's wish to not update the DNS. With this parameter // set to true the server will send DNS update even when // the client requested no update. "override-no-update": false, // Suffix appended to the partial name sent to the DNS. The // default value is an empty string which indicates that no // suffix is appended. "qualifying-suffix": "", // Enumeration specifying whether the server should honor // hostname or Client FQDN sent by the client or replace // this name. The acceptable values are: "never" (use the // name the client sent), "always" (replace the name the // client sent), "when-present" (replace the name the client // sent, but do not generate one when the client didn't sent // the name), "when-not-present" (generate the name when // client didn't send one, otherwise leave the name the // client sent). The default value is "never". "replace-client-name": "never", // IP address that Kea DHCPv4 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable address. "sender-ip": "0.0.0.0", // Port number that Kea DHCPv4 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable port. "sender-port": 0, // IP address on which D2 listens for NCRs. "server-ip": "127.0.0.1", // Port number on which D2 listens for NCRs. "server-port": 53001 }, // Specifies the first of the two consecutive ports of the UDP // sockets used for communication between DHCPv6 and DHCPv4 // servers. See RFC 7341. "dhcp4o6-port": 6767, // Boolean flag indicating whether or not the Kea DHCPv4 server // should send back Client Identifier option in its responses. // The default value is true which indicates that the option // must be sent back if the client included it. The false // value instructs the server to not send this option for // backward compatibility with older DHCP specifications which // stated that Client Identifier must not be sent back. "echo-client-id": true, // Collection of Kea DHCPv4 server parameters configuring how // the server should process expired DHCP leases. "expired-leases-processing": { // Specifies the number of seconds since last removal of // the expired leases when next removal should occur. "flush-reclaimed-timer-wait-time": 25, // Specifies the time period in seconds to keep expired // leases in the lease database (lease affinity). "hold-reclaimed-time": 3600, // Specifies the maximum number of expired leases that can be // processed in a single attempt to clean up the lease // database from the expired leases. If there are more // expired leases, they will be processed during the next // cleanup attempt. "max-reclaim-leases": 100, // Specifies the maximum time in milliseconds that the single // attempt to cleanup the lease database from the expired // leases may take. "max-reclaim-time": 250, // Specifies the time period in seconds since last attempt // to process expired leases to initiate the next attempt. "reclaim-timer-wait-time": 10, // Specifies the maximum number of expired leases processing // cycles which didn't result in full cleanup of the lease // database from the expired leases, after which a // warning message is issued. "unwarned-reclaim-cycles": 5 }, // List of hooks libraries and their specific configuration parameters // to be loaded by Kea DHCPv4 server. "hooks-libraries": [ { // Location of the hooks library to be loaded. "library": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so", // Hook library specific configuration parameters. "parameters": { } } ], // List of access credentials to external sources of IPv4 reservations, "hosts-databases": [ { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 3306, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 5432, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "postgresql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "keyspace": "kea", // Host on which the database resides. "contact-points": "127.0.0.1", // Database password. "password": "kea", // Port on which the database is available. "port": 9042, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "cql", // User name to be used to access the database. "user": "kea", // Consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "consistency": "quorum", // Serial consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "serial-consistency": "serial", // Connection reconnect wait time. "reconnect-wait-time": 100, // Connection connect timeout. "connect-timeout": 100, // Connection request timeout. "request-timeout": 100, // Connection tcp keepalive. "tcp-keepalive": 100, // Connection tcp nodelay. "tcp-nodelay": true } ], // List of host reservation identifier types to be used by the // Kea DHCPv4 server to fetch static reservations for the // DHCP clients. All identifiers are used by default, which // means that the server will issue multiple queries to the // database to find if there is a reservation for the particular // client. If the particular deployment uses only subset, e.g. // one, identifier type, this identifier should be only listed // here to prevent unnecessary queries to the database. "host-reservation-identifiers": [ "hw-address", "duid", "circuit-id", "client-id", "flex-id" ], // Specifies configuration of interfaces on which the Kea DHCPv4 // server is listening to the DHCP queries. "interfaces-config": { // Specifies whether the server should use "udp" socket or // "raw" sockets to listen to the DHCP traffic. The "raw" // sockets are useful when direct DHCP traffic is being // received. "dhcp-socket-type": "udp", // Specifies a list of interfaces on which the Kea DHCPv4 // server should listen to the DHCP requests. "interfaces": [ "ethX" ], // Enumeration which indicates what interface should be used // to send DHCP response to the client. The default value is // "same-as-inbound" which indicates that the response should // be sent via the interface on which the client's query // was received. The "use-routing" value indicates that the // Kea server should use kernel's routing table to find the // suitable interface. "outbound-interface": "same-as-inbound", // Boolean flag indicating if the available interfaces should // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. "re-detect": true }, // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval // in seconds at which lease file should be cleaned up (outdated // lease entries are removed to prevent lease file from growing // infinitely). "lfc-interval": 3600, // Maximum number of lease file read errors allowed before // loading the file is abandoned. Defaults to 0 (no limit). "max-row-errors": 100, // Name of the lease file. In case of database it specifies the // database name. "name": "/tmp/kea-dhcp4.csv", // memfile specific parameter indicating whether leases should // be saved on persistent storage (disk) or not. The true value // is the default and it indicates that leases are stored in the // persistent storage. This setting must be used in production. // The false value should only be used for testing purposes // because non stored leases will be lost upon Kea server restart. "persist": true, // Lease database backend type, i.e. "memfile", "mysql", // "postgresql" or "cql". "type": "memfile" }, // Boolean value indicating if the Kea DHCPv4 server should use client // identifier value sent by the client or ignore it. The default value // is true which indicate that the server should use client identifier // and that it takes precedence over client's MAC address. In deployments // where MAC address should take precedence this value can be set to // false, in which case the clients will be identified by MAC address. // This is specifically useful when clients don't generate unique // identifiers or these identifiers are not stable etc. "match-client-id": false, // Global value of the next server address set in 'siaddr' field. // The global value may be overriden in lower level configuration // scopes. "next-server": "192.0.2.123", // List of global DHCP options that Kea DHCPv4 server assigns to the // clients. "option-data": [ { // Boolean flag indicating if the given option is always // send in response or only when requested. The default // value of false indicates that it is only sent when // requested. "always-send": false, // Option code. It is not required if the option name is // provided. "code": 6, // Boolean value indicating whether the option data specified // in the "data" field is specified as a string of hexadecimal // digits or in human readable CSV format. "csv-format": true, // Option data to be stored in the option payload. "data": "192.0.3.1, 192.0.3.2", // Option name. It is not required of the option code is // provided. "name": "domain-name-servers", // Option space. The default is the "dhcp4" option space which // groups top level DHCPv4 options. "space": "dhcp4" } ], // List of global option definitions, i.e. option formats, that the // Kea DHCPv4 server is using. "option-def": [ { // Boolean flag indicating if the option definition comprises // an array of values of some type, e.g. array of IPv4 addresses. // The default value of false means that the option does not // comprise an array of values. "array": false, // Option code. "code": 6, // Holds a name of the option space encapsulated by this option. // All options that belong to this option space will be sent // as sub-options of this option. Empty string means that this // option doesn't encapsulate any option. "encapsulate": "", // Option name. "name": "my-option", // Specifies the types of fields within the option if the option // is said to be a "record" (see "type"). in this particular example // this option comprises two fields, 1 byte and 2 bytes long. "record-types": "uint8, uint16", // Name of the option space to which this option belongs. "space": "my-space", // Option type. All possible types are listed in the Kea // Administrator Reference Manual. "type": "record" } ], // Global value for the rebind timer, i.e. the time after which the // DHCP client enters rebind state if it fails to renew the lease. "rebind-timer": 40, // Global value for the renew timer, i.e. the timer after which the // DHCP client renews the lease. "renew-timer": 30, // Governs how the Kea DHCPv4 server should deal with the invalid // data received from the client. "sanity-checks": { // Specifies how the Kea DHCPv4 server should behave when invalid // data is read for a lease from the lease file. The following // values are supported "none" (don't attempt to correct the // lease information), "warn" (print a warning for subnet-id // related inconsistencies), "fix" (correct the subnet id by // trying to find the suitable subnet), "fix-del" (similar // to "fix" but delete the lease if no suitable subnet found), // "del" (delete the lease if the lease has invalid subnet // identifier value). "lease-checks": "warn" }, // List of shared networks used by Kea DHCPv4 server. The shared // networks group subnets together. "shared-networks": [ { // Shared network level bootfile name. "boot-file-name": "/dev/null", // Restricts this shared network to allow only clients // that belong to the particular client class. If an // empty string is provided, no restriction is applied. "client-class": "", // Specifies that this shared network is selected for the // requests received on the particular interface. "interface": "ethX", // Shared network level flag specifying whether the client // identifier should be used for identifying clients. "match-client-id": true, // Shared network name. "name": "my-secret-network", // Shared network level specification of the next server // to be sent in 'siaddr'. "next-server": "192.0.2.123", // List of shared network specific DHCP options. "option-data": [], // List of IPv4 relay addresses for which this shared // network is selected. "relay": { "ip-addresses": [] }, // Shared network level rebind timer. "rebind-timer": 41, // Shared network level renew timer. "renew-timer": 31, // Shared network level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // List of client classes which must be evaluated when this shared // network is selected for client assignments. "require-client-classes": [ "late" ], // Shared network level server hostname set in 'sname' field. "server-hostname": "", // List of IPv4 subnets belonging to this shared network. "subnet4": [ { // Interface name matched against inbound interface name. // Used in DHCPv4o6. See RFC 7341. "4o6-interface": "", // Interface ID option value. See RFC 7341. "4o6-interface-id": "", // Prefix matched against source address. See RFC7341. "4o6-subnet": "2001:db8:1:1::/64", // Subnet level bootfile name, set in 'file' field. "boot-file-name": "", // Restricts this subnet to allow only clients that belong // to the particular client class. If an empty string is // provided, no restriction is applied. "client-class": "", // Subnet unique identifier. "id": 1, // Specifies that this subnet is selected for the requests // received on the particular interface. "interface": "ethX", // Subnet level flag specifying whether the client identifier // should be used for identifying clients. "match-client-id": true, // Subnet level specification of the next server to be sent // in 'siaddr'. "next-server": "0.0.0.0", // Subnet level list of DHCP options. "option-data": [ { // Boolean flag indicating if the particular option // should be always sent or sent only when requested. "always-send": false, // Option code. "code": 3, // Boolean flag indicating if the option value specified // in "data" is a string of hexadecimal values or human // readable CSV value. "csv-format": true, // Option data to be included in the option payload. "data": "192.0.3.1", // Option name. "name": "routers", // Option space. The default value "dhcp4" designates the // top level option space. "space": "dhcp4" } ], // List of IP address pools belonging to the subnet. "pools": [ { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server1", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "192.1.0.1 - 192.1.0.200", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [ "late" ] }, { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server2", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "192.3.0.1 - 192.3.0.200", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [] } ], // Subnet level value of the rebind timer. "rebind-timer": 40, // List of IPv4 relay addresses for which this subnet is // selected. "relay": { "ip-addresses": [ "192.168.56.1" ] }, // Subnet level value of the renew timer. "renew-timer": 30, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // Subnet-level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // List of static IPv4 reservations assigned to the clients belonging // to this subnet. For detailed example see reservations.json. "reservations": [ { // Identifier used for client matching. Supported values are // "hw-address", "client-id", "duid", "circuit-id", "flex-id". "circuit-id": "01:11:22:33:44:55:66", // Reserved IP address. "ip-address": "192.0.2.204", // Reservation specific option data. "option-data": [ { // Option name. "name": "vivso-suboptions", // Option data. "data": "4491" } ] } ], // List of client classes which must be evaluated when this subnet // is selected for client assignments. "require-client-classes": [ "late" ], // Subnet level server hostname set in 'sname' field. "server-hostname": "", // Subnet prefix. "subnet": "192.0.0.0/8", // Subnet level (default) valid lifetime. "valid-lifetime": 6000, // Subnet level min valid lifetime. "min-valid-lifetime": 4000, // Subnet level max valid lifetime. "max-valid-lifetime": 8000 } ], // Shared network level (default) valid lifetime. "valid-lifetime": 6001, // Subnet level min valid lifetime. "min-valid-lifetime": 4001, // Subnet level max valid lifetime. "max-valid-lifetime": 8001 } ], // Global server hostname set in the 'sname' field. "server-hostname": "", // List of IPv4 subnets which don't belong to any shared network. "subnet4": [], // Global valid (default) lifetime value. "valid-lifetime": 6000, // Global min valid lifetime value. "min-valid-lifetime": 4000, // Global max valid lifetime value. "max-valid-lifetime": 8000, // Reservations (examples are in other files). "reservations": [], // Configuration control (currently not used, i.e. this syntax // is already defined but corresponding feature is not implemented). "config-control": { // Only configuration databases entry is defined. "config-databases": [ { // Name of the database to connect to. "name": "config", // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql" } ], // Intervals between attempts to fetch configuration updates // via the configuration backends used. "config-fetch-wait-time": 30 }, // Server tag. "server-tag": "my DHCPv4 server", // DHCP queue control parameters. "dhcp-queue-control": { // Enable queue is mandatory. "enable-queue": true, // Queue type was mandatory. "queue-type": "kea-ring4" }, // Fetches host reservations. "reservation-mode": "all", // Global compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // List of loggers used by the servers using this configuration file. "loggers": [ { // Debug level, a value between 0..99. The greater the value // the more detailed debug log. "debuglevel": 99, // Name of the logger. "name": "kea-dhcp4", // Configures how the log should be output. "output_options": [ { // Determines whether the log should flushed to a file. "flush": true, // Specifies maximum filesize before the file is being rotated. "maxsize": 10240000, // Specifies the maximum number of rotated files being kept. "maxver": 1, // Specifies logging destination. "output": "stdout" } ], // Specifies logging severity, i.e. "ERROR", "WARN", "INFO", "DEBUG". "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/classify2.json0000644000175000017500000001324613623761160015215 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // The purpose of this example is to showcase how clients can be classified // with advanced features. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Let's use the simplest backend: memfile and use some reasonable values // for timers. They are of no concern for the classification demonstration. "lease-database": { "type": "memfile" }, "renew-timer": 1000, "rebind-timer": 2000, "valid-lifetime": 4000, // This list defines several classes that incoming packets can be assigned to. // One packet can belong to zero or more classes. "client-classes": [ // This class is required by the second subnet and is evaluated only // if it is required. The test expression returns true. // Note it is not possible to depend on VoIP class because it is not yet // defined. { "name": "second_subnet", "only-if-required": true, "test": "member('ALL')", "option-data": [{ "name": "domain-name-servers", "data": "127.0.0.1" }] }, // Let's classify all incoming DISCOVER (message type 1) to a separate // class. { "name": "discovers", "test": "pkt4.msgtype == 1" }, // Clients are supposed to set the transaction-id field to a random value. // Clients that send it with 0 are most likely broken. Let's mark them // as such. { "name": "broken", "test": "pkt4.transid == 0" }, // Let's pick VoIP phones. Those that send their class identifiers // as Aastra, should belong to VoIP class. For a list of all options, // see www.iana.org/assignments/bootp-dhcp-parameters/. // In this particular class, we want to set specific values // of certain DHCPv4 fields. If the incoming packet matches the // test, those fields will be set in outgoing responses. // The option 43 is defined to encapsulate suboption in the aastra space. { "name": "VoIP", "test": "substring(option[60].hex,0,6) == 'Aastra'", "next-server": "192.0.2.254", "server-hostname": "hal9000", "boot-file-name": "/dev/null", "option-def": [ { "name": "vendor-encapsulated-options", "code": 43, "type": "empty", "encapsulate": "aastra" } ] }, // Both a VoIP phone (by evaluation or host reservation) and has a host // reservation. { "name": "VoIP_host", "test": "member('VoIP') and member('KNOWN')", "server-hostname": "hal9001" } ], // The following list defines subnets. For some subnets we defined // a class that is allowed in that subnet. If not specified, // everyone is allowed. When a class is specified, only packets belonging // to that class are allowed for that subnet. "subnet4": [ { // This one is for VoIP devices only. "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "client-class": "VoIP", "interface": "ethX" }, // This one doesn't have any client-class specified, so everyone // is allowed in. The normal subnet selection rules still apply, // though. There is also a static class reservation for a client // using MAC address 1a:1b:1c:1d:1e:1f. This client will always // be assigned to this class. { "pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ], "subnet": "192.0.3.0/24", "reservations": [ { "hw-address": "1a:1b:1c:1d:1e:1f", "client-classes": [ "VoIP" ] } ], "interface": "ethX", "require-client-classes": [ "second_subnet" ] }, // The following list defines a subnet with pools. For some pools // we defined a class that is allowed in that pool. If not specified // everyone is allowed. When a class is specified, only packets belonging // to that class are allowed for that pool. { "pools": [ { // This one is for VoIP devices only. "pool": "192.0.4.1 - 192.0.4.200", "client-class": "VoIP" }, // This one doesn't have any client-class specified, so everyone // is allowed in. { "pool": "192.0.5.1 - 192.0.5.200" } ], "subnet": "192.0.4.0/23", "interface": "ethY" }, // This subnet is divided in two pools for unknown and known // (i.e. which have a reservation) clients. The built-in KNOWN and // UNKNOWN classes are set or not at host reservation lookup (KNOWN if // this returns something, UNKNOWN if this finds nothing) and client //classes depending on it are evaluated. // This happens after subnet selection and before address allocation //from pools. { "pools": [ { "pool": "192.0.8.100 - 192.0.8.200", "client-class": "UNKNOWN" }, { "pool": "192.0.9.100 - 192.0.9.200", "client-class": "KNOWN" } ], "subnet": "192.0.8.0/23", "reservations": [ { "hw-address": "00:00:00:11:22:33", "hostname": "h1" }, { "hw-address": "00:00:00:44:55:66", "hostname": "h4" }, { "hw-address": "00:00:00:77:88:99", "hostname": "h7" }, { "hw-address": "00:00:00:aa:bb:cc", "hostname": "ha" } ] } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/global-reservations.json0000644000175000017500000001364613623761160017304 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It demonstrates how global host reservations can be configured. // The global reservations are not associated with any subnet. They // are assigned regardless of the subnet to which the DHCP client belongs. // Global reservations are assigned to the DHCP clients using the // same host identifier types as subnet specific reservations. This file // contains multiple examples of host reservations using different // identifier types, e.g. MAC address, client identifier etc. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the database used to store leases. As of September // 2016, four database backends are supported: MySQL, PostgreSQL, Cassandra, and // the in-memory database, Memfile. We'll use memfile because it doesn't // require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // 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), circuit-id // (circuit identifier inserted by the relay agent) and flex-id (flexible // identifier available when flex_id hook library is loaded). When told to do // so, Kea can check for all of those identifier types, but it takes a costly // database lookup to do so. It is therefore useful from a performance // perspective to use only the reservation types that are actually used in a // given network. // The example below is not optimal from a performance perspective, but it // nicely showcases the host reservation capabilities. Please use the minimum // set of identifier types used in your network. "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id", "flex-id" ], // This directive tells Kea that reservations are global. Note that this // can also be specified at shared network and/or subnet level. "reservation-mode": "global", // Define several global host reservations. "reservations": [ // This is a reservation for a specific hardware/MAC address. It's a very // simple reservation: just an address and nothing else. // Note it is not recommended but still allowed to reverse addresses at // the global scope: as it breaks the link between the reservation and // the subnet it can lead to a client localized in another subnet than // its address belongs to. { "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. Either a hostname or // an address is required. { "client-id": "01:11:22:33:44:55:66", "hostname": "special-snowflake" }, // The third reservation is based on DUID. This reservation also // defines 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 precedence for // this particular DHCP client. { "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. { "circuit-id": "01:11:22:33:44:55:66", "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" } ], // Define a subnet. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "eth0" } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/advanced.json0000644000175000017500000002126013623761160015056 00000000000000// This is an example configuration file for DHCPv4 server in Kea. // It covers some of the more advanced features. This file may not be coherent // as its main purpose is to demonstrate the features. They don't necessarily // have to make sense used together. // The new parser supports 3 comment styles: // This is C++ style. # This is a bash style. /* This is a C style comment. */ /* C style comment can span multiple lines */ { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ], // This specifies what type of socket Kea uses. Currently supported // are 'raw' (which is the default) and 'udp'. Raw has the benefit // of receiving all traffic every time and a downside of bypassing // all firewall rules and having marginally bigger performance impact. // 'udp' is generally better if you have only relayed traffic. Kea // than opens up normal UDP socket and the kernel does all the // Ethernet/IP stack processing. "dhcp-socket-type": "udp", // Typically the DHCP server will send its response back on the same // interface the query came in. This is the default ("same-as-inbound"). // However, sometimes it is useful to have the ability to send the // packet as plain UDP packet and let the kernel and the routing tables // determine the right interface ("use-routing"). This option only works // for "dhcp-socket-type" set to "udp" and is ignored otherwise. "outbound-interface": "use-routing", // This makes interfaces to be re-detected at each (re-)configuration. // By default it is true. "re-detect": true }, "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 findind 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" }, // Option 43 last resort definition can make well-formed messages // to be rejected because they use not compatible "raw" value, // and different vendors may define different sub-options. // The option definition should be applied to avoid these problems, // for instance by defining at the global scope the option as binary. // In client-classes the option may be redefined as carrying vendor // dependent sub-options. "option-def": [ { "name": "vendor-encapsulated-options", "code": 43, "type": "binary" } ], // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. // For memfile, it's important to always specify lfc-interval, so // the lease file would not grow without bounds and be sanitized // once per hour. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // 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": "/tmp/kea4-ctrl-socket" }, // Addresses will be assigned with a lifetime of 4000 seconds. // The client is told to start renewing after 1000 seconds. If the server // does not respond within 2000 seconds of the lease being granted, client // is supposed to start REBIND procedure (emergency renewal that allows // switching to a different server). "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // RFC6842 says that the server is supposed to echo back client-id option. // However, some older clients do not support this and are getting confused // when they get their own client-id. Kea can disable RFC6842 support. "echo-client-id": false, // Some clients don't use stable client identifier, but rather // generate them during each boot. This may cause a client that // reboots frequently to get multiple leases, which may not be // desirable. As such, sometimes admins prefer to tell their DHCPv4 // server to ignore client-id value altogether and rely exclusively // on MAC address. This is a parameter that is defined globally, but // can be overridden on a subnet level. "match-client-id": true, // By default, Kea ignores requests by clients for unknown IP addresses, // because other non-cooperating DHCP servers could reside on the same // network (RFC 2131). This parameter is defined globally, but can be // overriden on a subnet level "authoritative": false, // The following list defines subnets. Each subnet consists of at // least subnet and pool entries. One extra feature that requires // some explanation is user-context. This is a structure that you can // define in subnets, pools and others. It is parsed by Kea, but not // used directly. It is intended to keep anything you may want to // put there - comments, extra designations, floor or department // names etc. These structures will be made available to Kea hooks. // A comment entry is translated into a user-context with a // "comment" property so you can include comments inside the // configuration itself. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200", "user-context": { "info": "what a large pool" } } ], "subnet": "192.0.2.0/24", "user-context": { "comment": "Our first subnet!" } // Equivalent using smart parser // "comment": "Our first subnet!" }, { // This particular subnet has match-client-id value changed. // This causes Kea to ignore client-id values in this subnet // and rely exclusively on MAC addresses. "pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ], "subnet": "192.0.3.0/24", "match-client-id": false }, { "pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ], "subnet": "192.0.4.0/24", // Sometimes the relay may use an IPv4 address that does // not match the subnet. This is discouraged, but there are // valid cases when it makes sense. One case is when there // is a shared subnet. "relay": { "ip-address": "192.168.1.1" } }, { // This particular subnet has the authoritative value changed. // This causes Kea to reply to requests for unknown IP addresses // with a DHCPNAK message. "pools": [ { "pool": "192.0.5.100 - 192.0.5.200" } ], "subnet": "192.0.5.0/24", "authoritative": true } ], // 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-dhcp4", "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 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" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/pgsql-reservations.json0000644000175000017500000000724013623761160017163 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It contains configuration of the PostgreSQL host database backend, used // to retrieve reserved addresses, host names, DHCPv4 message fields // and DHCP options from PostgreSQL database. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // Renew and rebind timers are commented out. This implies that options // 58 and 59 will not be sent to the client. In this case it is up to // the client to pick the timer values according to RFC2131. Uncomment the // timers to send these options to the client. // "renew-timer": 1000, // "rebind-timer": 2000, // 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). When told to do so, Kea can check for all of those // identifier types, but it takes a costly database lookup to do so. It // is therefore useful from a performance perspective to use only the // reservation types that are actually used in a given network. // The example below is not optimal from a performance perspective, but it // nicely showcases the host reservation capabilities. Please use the minimum // set of identifier types used in your network. "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ], // Specify connection to the database holding host reservations. The type // specifies that the PostgreSQL database is used. user and password are the // credentials used to connect to the database. host and name specify // location of the host where the database instance is running, and the // name of the database to use. The server processing a packet will first // check if there are any reservations specified for this client in the // reservations list, within the subnet (configuration file). If there are // no reservations there, the server will try to retrieve reservations // from this database. // The database specification can go into one hosts-database entry for // backward compatibility or be listed in hosts-databases list. "hosts-databases": [ { "type": "postgresql", "name": "kea", "user": "kea", "password": "kea", "host": "localhost" } ], // Define a subnet with a single pool of dynamic addresses. Addresses from // this pool will be assigned to clients which don't have reservations in the // database. Subnet identifier is equal to 1. If this subnet is selected for // the client, this subnet id will be used to search for the reservations // within the database. "subnet4": [ { "pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX", "id": 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea4/hooks.json0000644000175000017500000000232113623761160014431 00000000000000// This is an example configuration file for the DHCPv4 server in Kea // illustrating the configuration of hooks libraries. It uses a basic scenario // of one IPv4 subnet configured with the default values for all parameters. {"Dhcp4": { // Kea is told to listen on the ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Set up the storage for leases. "lease-database": { "type": "memfile" }, "valid-lifetime": 1800, // Define a single subnet. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX" } ], // Set up the hooks libraries. For this example, we assume that two libraries // are loaded, called "security" and "charging". Note that order is important: // "security" is specified first so if both libraries supply a hook function // for a given hook, the function in "security" will be called before that in // "charging". "hooks-libraries": [ { "library": "/opt/lib/security.so" }, { "library": "/opt/lib/charging.so", "parameters": { "path": "/var/lib/kea", "base-name": "kea-forensic6" } } ] } } kea-1.6.2/doc/examples/kea4/leases-expiration.json0000644000175000017500000000454413623761160016753 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It provides parameters controlling processing of expired leases, // a.k.a. leases reclamation. { "Dhcp4": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. // Note, we're setting the maximum number of row read errors to 100, // (defaults to 0, meaning unlimited). "lease-database": { "type": "memfile", "lfc-interval": 3600, "max-row-errors": 100 }, // The following parameters control processing expired leases. Expired // leases will be reclaimed periodically according to the // "reclaim-timer-wait-time" parameter. Reclaimed leases will be held in // the database for 1800s to facilitate lease affinity. After this // period the leases will be removed. The frequency of removal is // controlled by the "flush-reclaimed-timer-wait-time" parameter. The // lease reclamation routine will process at most 500 leases or will // last for at most 100ms, during a single run. If there are still some // unreclaimed leases after 10 attempts, a warning message is issued. "expired-leases-processing": { "reclaim-timer-wait-time": 5, "hold-reclaimed-time": 1800, "flush-reclaimed-timer-wait-time": 10, "max-reclaim-leases": 500, "max-reclaim-time": 100, "unwarned-reclaim-cycles": 10 }, // Addresses will be assigned with a lifetime of 4000 seconds. "valid-lifetime": 4000, // The following list defines subnets. We have only one subnet // here. We tell Kea that it is directly available over local interface. "subnet4": [ { "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ], "subnet": "192.0.2.0/24", "interface": "ethX" } ], // 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-dhcp4", "output_options": [ { "output": "stdout" } ], "severity": "INFO" } ] } } kea-1.6.2/doc/examples/ddns/0000755000175000017500000000000013623761246012606 500000000000000kea-1.6.2/doc/examples/ddns/template.json0000644000175000017500000000571413623761160015236 00000000000000// This file may be used a template for constructing DHCP-DDNS JSON // configuration. // // It must start with a left-curly-bracket. { "DhcpDdns" : { // // -------------- Global Parameters ---------------- // // All of the global parameters have default values as shown. If these // are satisfactory you may omit them. // // "ip-address" : "127.0.0.1", // "port" : 53001, // "dns-server-timeout" : 100, // "ncr-protocol" : "UDP" // "ncr-format" : "JSON" // // ----------------- Control Socket ----------------- // // "control-socket": // { // "socket-type": "unix", // "socket-name": "/tmp/d2-ctrl-socket" // }, // // ----------------- Forward DDNS ------------------ // "forward-ddns" : { "ddns-domains" : [ // { // "name" : "", // "key-name" : "", // "dns-servers" : // [ // { // "ip-address" : "" // ,"port" : 53 // } // , // { // next DNS server for this DdnsDomain // } // : // ] // } // , // { // next Forward DdnsDomain // } // : ] }, // // ----------------- Reverse DDNS ------------------ // "reverse-ddns" : { "ddns-domains" : [ // { // "name" : "", // "key-name" : "", // "dns-servers" : // [ // { // "ip-address" : "" // ,"port" : 53 // } // , // { // next DNS server for this DdnsDomain // } // : // ] // } // , // { // next Reverse DdnsDomain // } // : ] }, // // ------------------ TSIG keys --------------------- // "tsig-keys" : [ // { // "name" : "", // "algorithm" : "", // Valid values for algorithm are: HMAC-MD5, HMAC-SHA1, // HMAC-SHA224, HMAC-SHA256, // HMAC-SHA384, HMAC-SHA512 // "digest-bits" : 256, // Minimum truncated length in bits. // Default 0 (means truncation is forbidden). // "secret" : "" // } // , // { // next TSIG Key // } ] // Logging // ,"loggers": // [ // { // "name": "kea-dhcp-ddns", // "severity": "info" // } // ] } // It must end with an right-curly-bracket. } kea-1.6.2/doc/examples/ddns/sample1.json0000644000175000017500000001171413623761160014762 00000000000000// This is an example configuration file for D2, Kea's DHCP-DDNS processor. // It supports updating two Forward DNS zones "four.example.com" and // "six.example.com"; and one Reverse DNS zone, "2.0.192.in-addr.arpa." { // ------------------ DHCP-DDNS --------------------- // "DhcpDdns": { // -------------- Global Parameters ---------------- // // D2 will listen for update requests for Kea DHCP servers at 127.0.0.1 // on port 53001. Maximum time to we will wait for a DNS server to // respond to us is 1000 ms. "ip-address": "127.0.0.1", "port": 53001, "dns-server-timeout" : 1000, // One extra feature that requires some explanation is // user-context. This is a structure that you can define at global scope, // in ddns domain, dns server, tsig key and others. It is parsed by // Kea, but not used directly. It is intended to keep anything you // may want to put there - comments, extra designations, floor or // department names etc. // A comment entry is translated into a user-context with a "comment" // property so you can include comments inside the configuration itself. "user-context": { "version": 1 }, // // ----------------- Control Socket ----------------- // "control-socket": { "socket-type": "unix", "socket-name": "/tmp/d2-ctrl-socket" }, // // ----------------- Forward DDNS ------------------ // // 1. Zone - "four.example.com. // It uses TSIG, key name is "d2.md5.key" // It is served by one DNS server which listens for DDNS requests at // 172.16.1.1 on the default port 53 (standard DNS port) // // 2. Zone - "six.example.com." // It does not use TSIG. // It is server by one DNS server at "2001:db8:1::10" on port 7802 "forward-ddns": { "ddns-domains": [ // DdnsDomain for zone "four.example.com." { "comment": "DdnsDomain example", "name": "four.example.com.", "key-name": "d2.md5.key", "dns-servers": [ { "ip-address": "172.16.1.1" } ] }, // DdnsDomain for zone "six.example.com." { "name": "six.example.com.", "dns-servers": [ { "ip-address": "2001:db8:1::10", "port": 7802 } ] } ] }, // ----------------- Reverse DDNS ------------------ // // We will update Reverse DNS for one zone "2.0.192.in-addr-arpa". It // uses TSIG with key "d2.sha1.key" and is served by two DNS servers: // one listening at "172.16.1.1" on 53001 and the other at "192.168.2.10". // "reverse-ddns": { "ddns-domains": [ { "name": "2.0.192.in-addr.arpa.", "key-name": "d2.sha1.key", "dns-servers": [ { "ip-address": "172.16.1.1", "port": 53001 }, { "ip-address": "192.168.2.10" } ] } ] }, // ------------------ TSIG keys --------------------- // // Each key has a name, an algorithm (HMAC-MD5, HMAC-SHA1, HMAC-SHA224...) // and a base-64 encoded shared secret. // "tsig-keys": [ { "name": "d2.md5.key", "algorithm": "HMAC-MD5", "secret": "LSWXnfkKZjdPJI5QxlpnfQ==" }, { "name": "d2.sha1.key", "algorithm": "HMAC-SHA1", "secret": "hRrp29wzUv3uzSNRLlY68w==" }, { "name": "d2.sha512.key", "algorithm": "HMAC-SHA512", "digest-bits": 256, "secret": "/4wklkm04jeH4anx2MKGJLcya+ZLHldL5d6mK+4q6UXQP7KJ9mS2QG29hh0SJR4LA0ikxNJTUMvir42gLx6fGQ==" } ], // The following configures logging. It assumes that messages with at least // informational level (info, warn, error and fatal) should be logged to stdout. // It also specifies a custom log pattern. "loggers": [ { "name": "kea-dhcp-ddns", "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 being rotated. maxver // specifies the maximum number of rotated files being // kept. "flush": true, "maxsize": 204800, "maxver": 4, "pattern": "%d [%c/%i] %m\n" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/ddns/comments.json0000644000175000017500000000272613623761160015250 00000000000000// This is an example configuration file for D2, Kea's DHCP-DDNS processor. // It uses embedded comments which will be included in configuration objects // within user-contexts rather than stripped away by at lexical analysis. { "DhcpDdns": { // Global scope "comment": "A DHCP-DDNS server", "ip-address": "127.0.0.1", "port": 53001, "dns-server-timeout" : 1000, "control-socket": { "comment": "Control channel", "socket-type": "unix", "socket-name": "/tmp/d2-ctrl-socket" }, "forward-ddns": { "ddns-domains": [ // In DDNS domain { "comment": "DdnsDomain for zone 'four.example.com.'", "name": "four.example.com.", "key-name": "d2.md5.key", // In DNS server "dns-servers": [ { "comment": "four.example.com. server", "ip-address": "172.16.1.1" } ] } ] }, // In TSIG key "tsig-keys": [ { "comment": "four.example.com. key", "name": "d2.md5.key", "algorithm": "HMAC-MD5", "secret": "LSWXnfkKZjdPJI5QxlpnfQ==" } ], // In loggers "loggers": [ { "comment": "A logger", "name": "kea-dhcp-ddns", "severity": "info" } ] } } kea-1.6.2/doc/examples/netconf/0000755000175000017500000000000013623761246013312 500000000000000kea-1.6.2/doc/examples/netconf/simple-dhcp6.json0000644000175000017500000001301713623761160016415 00000000000000// 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" alloes to validate or not changes. "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 } ] } } kea-1.6.2/doc/examples/netconf/simple-dhcp4.json0000644000175000017500000001266313623761160016421 00000000000000// This is a simple example of a configuration for Netconf that handles // DHCPv4 configuration. This example provides YANG interface for // DHCPv4 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" alloes to validate or not changes. "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 DHCPv4 server. "dhcp4": { // Eventually, the kea-netconf will be able to handle multiple // models. However, for the time being the only choice for // DHCPv4 server is kea-dhcp4-server model. "model": "kea-dhcp4-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". "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea4-ctrl-socket" }, // Comment is optional. You can put some notes here. "comment": "Kea DHCP4 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 } ] } } kea-1.6.2/doc/examples/netconf/comments.json0000644000175000017500000000164413623761160015752 00000000000000// This is a example of a configuration for Netconf. // It uses embedded (i.e., which will be included in configuration objects // and not stripped by at lexical analysis) comments. { "Netconf": { // Global scope "comment": "The Netconf Agent", // In servers "managed-servers": { "dhcp4": { "comment": "the model is mandatory", "model": "kea-dhcp4-server", // In control socket. "control-socket": { "comment": "using unix/local socket", "socket-type": "unix", "socket-name": "/path/to/the/unix/socket-v4" } } }, // In loggers "loggers": [ { "comment": "A logger", "name": "kea-ctrl-agent" } ] } } kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/0000755000175000017500000000000013623761246017235 500000000000000kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/twosubnets.xml0000644000175000017500000000136013623761160022107 00000000000000 1 2001:db8:1:: 2001:db8:1::ffff 2001:db8:1::/112 2001:db8:1::/64 2 2001:db8:2:: 2001:db8:2::ffff 2001:db8:2::/112 2001:db8:2::/64 eth1 /tmp/kea6-sock unix kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/twopools.xml0000644000175000017500000000124513623761160021562 00000000000000 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::2:0 2001:db8::2:ffff 2001:db8::2:0/112 2001:db8::/64 eth1 /tmp/kea6-sock unix kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/netconf.json0000644000175000017500000000116413623761160021501 00000000000000{ "Netconf": { "managed-servers": { "dhcp6": { "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea6-sock" } } }, "loggers": [ { "name": "kea-netconf", "output_options": [ { "output": "stderr" } ], "severity": "DEBUG", "debuglevel": 99 } ] } } kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/startup.xml0000644000175000017500000000100013623761160021363 00000000000000 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::/64 eth1 /tmp/kea6-sock unix kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/logging.xml0000644000175000017500000000127013623761160021320 00000000000000 eth1 1 2001:db8::1:0 2001:db8::1:ffff 2001:db8::1:0/112 2001:db8::/64 /tmp/kea6-sock unix kea-dhcp6 stderr 99 DEBUG kea-1.6.2/doc/examples/netconf/kea-dhcp6-operations/boot.json0000644000175000017500000000021613623761160021005 00000000000000{ "Dhcp6": { "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea6-sock" } } } kea-1.6.2/doc/examples/kea6/0000755000175000017500000000000013623761246012504 500000000000000kea-1.6.2/doc/examples/kea6/cassandra.json0000644000175000017500000001001213623761160015243 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // It is a basic scenario with one IPv6 subnet configured. It demonstrates // how to configure Kea to use CQL (Cassandra) backend. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make // sure it is up, running and properly initialized. See kea-admin documentation // for details on how to initialize the database. The only strictly required // parameters are type, keyspace and contact-points. At least one contact point // must be specified, but more than one is required for redundancy. Make sure // you specify the contact points without spaces. Kea must be compiled with // --with-cql option to use this backend. "lease-database": { "type": "cql", "keyspace": "keatest", "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", "port": 9042, // Cassandra supports many additonal parameters that are typically // not needed, but may be used to tweak your deployment. // This parameter governs how long Kea waits before attempting // to reconnect. Expressed in milliseconds. The default is 2000 [ms]. "reconnect-wait-time": 2000, // This parameter sets the timeout for connecting to a node. Expressed // in milliseconds. The default is 5000 [ms]. "connect-timeout": 5000, // This parameter sets the timeout for waiting for a response // from a node. Expressed in milliseconds. The default is 12000 [ms]. "request-timeout": 12000, // This parameter governs the TCP keep-alive mechanism. Expressed // in seconds of delay. The default is disabled. In this example it is // set to 20 minutes. "tcp-keepalive": 1200, // This parameter enables/disables Nagle's algorithm on connections. // The default is true. "tcp-nodelay": true, // This parameter configures consistency level. The default is "quorum". // Supported values: // - any // - one // - two // - three // - quorum // - all // - local-quorum // - each-quorum // - serial // - local-serial // - local-one // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigConsistency.html for more details. "consistency": "quorum", // This parameter configures serial consistency level which manages // lightweight transaction isolation. The default is "serial". // Supported values: // - any // - one // - two // - three // - quorum // - all // - local-quorum // - each-quorum // - serial // - local-serial // - local-one // See https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigSerialConsistency.html for more details. "serial-consistency": "serial" }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/several-subnets.json0000644000175000017500000000370213623761160016436 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It's a basic scenario with four IPv6 subnets configured. In each // subnet, there's a smaller pool of dynamic addresses. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64" }, { "pools": [ { "pool": "2001:db8:2::/80" } ], "subnet": "2001:db8:2::/64" }, { "pools": [ { "pool": "2001:db8:3::/80" } ], "subnet": "2001:db8:3::/64" }, { "pools": [ { "pool": "2001:db8:4::/80" } ], "subnet": "2001:db8:4::/64" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/mysql-reservations.json0000644000175000017500000000626113623761160017206 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // It contains configuration of the MySQL host database backend, used // to retrieve reserved addresses, host names, DHCPv4 message fields // and DHCP options from MySQL database. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // This is pretty basic stuff, it has nothing to do with reservations. "preferred-lifetime": 3000, "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // Kea supports two types of identifiers in DHCPv6: hw-address // (hardware/MAC address of the client) and duid (DUID inserted by the // client). When told to do so, Kea can check for each of these // identifier types, but it takes a costly database lookup to do so. It // is therefore useful from a performance perspective to use only the // reservation types that are actually used in a given network. "host-reservation-identifiers": [ "duid", "hw-address" ], // Specify connection to the database holding host reservations. The type // specifies that the MySQL database is used. user and password are the // credentials used to connect to the database. host and name specify // location of the host where the database instance is running, and the // name of the database to use. The server processing a packet will first // check if there are any reservations specified for this client in the // reservations list, within the subnet (configuration file). If there are // no reservations there, the server will try to retrieve reservations // from this database. "hosts-database": { "type": "mysql", "name": "kea", "user": "kea", "password": "kea", "host": "localhost", "port": 3306, "readonly": true }, // Define a subnet with a pool of dynamic addresses and a pool of dynamic // prefixes. Addresses and prefixes from those pools will be assigned to // clients which don't have reservations in the database. Subnet identifier // is equal to 1. If this subnet is selected for the client, this subnet // id will be used to search for the reservations within the database. "subnet6": [ { "subnet": "2001:db8:1::/48", "pools": [ { "pool": "2001:db8:1::/80" } ], "pd-pools": [ { "prefix": "2001:db8:1:8000::", "prefix-len": 56, "delegated-len": 64 } ], "interface": "ethX", "id": 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/config-backend.json0000644000175000017500000000615313623761160016151 00000000000000// This is an example configuration file for the DHCPv4 server in Kea. // It demonstrates how to enable Kea Configuration Backend using MySQL. // It requires that libdhcp_mysql_cb.so library is available and // optionally libdhcp_cb_cmds.so hooks library. { "Dhcp6": { // Set the server tag for the configuration backend. This instance will // be named server2. Every configuration element that is applicable to // either "all" or "server2" will be used by this instance. "server-tag": "server2", // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Use memfile lease database backend. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // This parameter controls how the server accesses the configuration // database. Currently only one database type is available - "mysql". // It requires that libdhcp_mysql_cb.so hooks library is loaded. "config-control": { // A list of database backends to connect to. Currently, it is limited // to a single backend. "config-databases": [ { "type": "mysql", "name": "kea", "user": "kea", "password": "kea", "host": "localhost", "port": 3306 } ], // Controls how often the server polls the database for the // configuration updates. The setting below implies that it // will take up to approx. 20 seconds for the server to // discover and fetch configuration changes. "config-fetch-wait-time": 20 }, // This defines a control socket. If defined, Kea will open a UNIX socket // and will listen for incoming commands. See section 17 of the Kea ARM for // details. "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea-dhcp6.sock" }, // Hooks libraries that enable configuration backend are loaded. "hooks-libraries": [ // The libdhcp_mysql_cb.so is required to use MySQL Configuration // Backend. { "library": "/usr/local/lib/kea/hooks/libdhcp_mysql_cb.so" } // The libdhcp_cb_cmds.so is optional. It allows for managing the // configuration in the database. If this library is not loaded, // the configuration can be managed directly using available // tools that work directly with the MySQL database. //,{ // "library": "/usr/local/lib/kea/hooks/libdhcp_cb_cmds.so" //} ], // The following configures logging. It assumes that messages with at // least informational level (info, warn, error and fatal) should be // logged to stdout. Alternatively, you can specify stderr here, a filename // or 'syslog', which will store output messages via syslog. "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "stdout" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/classify.json0000644000175000017500000000556213623761160015137 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // The purpose of this example is to showcase how clients can be classified. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Let's use the simplest backend: memfile and use some reasonable values // for timers. They are of no concern for the classification demonstration. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, "renew-timer": 1000, "rebind-timer": 2000, "preferred-lifetime": 3000, "valid-lifetime": 4000, // This list defines several classes that incoming packets can be assigned to. // One packet can belong to zero or more classes. "client-classes": [ // The first class attempts to match all packets coming in on ethX interface. { "name": "lab", "test": "pkt.iface == 'ethX'", "option-data": [{ "name": "dns-servers", "data": "2001:db8::1" }] }, // Let's classify all incoming RENEW (message type 5) to a separate // class. { "name": "renews", "test": "pkt6.msgtype == 5" }, // Let's pick cable modems. In this simple example we'll assume the device // is a cable modem if it sends a vendor option with enterprise-id equal // to 4491. { "name": "cable-modems", "test": "vendor.enterprise == 4491" } ], // The following list defines subnets. Each subnet consists of at // least subnet and pool entries. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "client-class": "cable-modems", "interface": "ethX" }, // The following subnet contains a class reservation for a client using // DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned // to this class. { "pools": [ { "pool": "2001:db8:2::/80" } ], "subnet": "2001:db8:2::/64", "reservations": [ { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "client-classes": [ "cable-modems" ] } ], "interface": "ethX" }, // The following subnet contains a pool with a class constraint: only // clients which belong to the class are allowed to use this pool. { "pools": [ { "pool": "2001:db8:3::/80", "client-class": "cable-modems" } ], "subnet": "2001:db8:4::/64", "interface": "ethY" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/tee-times.json0000644000175000017500000000413713623761160015213 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It's a basic scenario with three IPv6 subnets use different // methods for determining T1 and T2 values. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // Addresses will be assigned with preferred and valid lifetimes // being 3000 and 4000, respectively. By default calculate-tee-times // is true with values of .5 and .8 for t1-percent and t2-percent // respectively. Since some of our subnets will use calculated values and // we must NOT specify global values for renew-timer and rebind-timer. "preferred-lifetime": 3000, "valid-lifetime": 4000, // The following list defines subnets. Each subnet consists of at // least subnet and pool entries. "subnet6": [ { // This subnet use default calculation "subnet": "2001:db8:1::/64", "pools": [ { "pool": "2001:db8:1::/80" } ] }, { // This subnet will use explicit values. Explict // values override calculation. "subnet": "2001:db8:2::/64", "pools": [ { "pool": "2001:db8:2::/80" } ], "renew-timer": 1000, "rebind-timer": 2000 }, { // This subnet will use custom percents "subnet": "2001:db8:3::/64", "pools": [ { "pool": "2001:db8:3::/80" } ], "t1-percent": .45, "t2-percent": .7 }], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/multiple-options.json0000644000175000017500000001562213623761160016644 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It demonstrates simple configuration of the options for a subnet. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // 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, // Defining a subnet. There are some DHCP options returned to the // clients connected to this subnet. The first option is identified // by the name. The second option is identified by the code. // There are two address pools defined within this subnet. Pool // specific value for option 12 is defined for the pool: // 2001:db8:1::1 - 2001:db8:1::100. Clients obtaining an address // from this pool will be assigned option 12 with a value of // 3001:cafe::21. Clients belonging to this subnet but obtaining // addresses from the other pool, or the clients obtaining // stateless configuration will be assigned subnet specific value // of option 12, i.e. 2001:db8:1:0:ff00::1. // For DHCPv6 subnets can have prefix delegation pools too so // a pd-pools with an option-data is defined too. "subnet6": [ { // This is how option values are defined for this particular subnet. "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 "dhcp6" 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": "dns-servers", // "code": 23, // "csv-format": true, // "space": "dhcp6", // "data": "2001:db8:2::45, 2001:db8:2::100" // } // but it's a lot of writing, so it's easier to do this instead: { "name": "dns-servers", "data": "2001:db8:2::45, 2001:db8:2::100" }, // 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, DHCPv6 can optionally use server // unicast communication, if extra option is present. Option // "unicast" uses option code 12, so you can reference to it // either by "name": "unicast" or "code": 12. { "code": 12, "data": "2001:db8:1:0:ff00::1" }, // Options can also be specified using hexadecimal format. // This should be avoided if possible, because Kea ability to // validate correctness is limited when using hex values. { "name": "sntp-servers", "csv-format": false, "data": "20010db8000000000000000000000001" }, // 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 hexa-decimal 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": "new-posix-timezone", "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": "preference", "data": "0xf0" }, // A few options are encoded in (length, string) tuples // which can be defined using only strings as the CSV // processing computes lengths. { "name": "bootfile-param", "data": "root=/dev/sda2, quiet, splash" }, // At a few exceptions options are added to response only when // the client requests them. The always-send flag should be used // to enforce a particular option. { "name": "pana-agent", "data": "2001:db8:2::123", "always-send": true } ], "pools": [ { "pool": "2001:db8:1::1 - 2001:db8:1::100", "option-data": [ { "code": 12, "data": "3001:cafe::21" } ] }, { "pool": "2001:db8:1::500 - 2001:db8:1::1000" } ], "pd-pools": [ { "prefix": "2001:2b8:2::", "prefix-len": 56, "delegated-len": 64, "option-data": [ { "code": 12, "data": "3001:cafe::12" } ] } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/all-keys.json0000644000175000017500000010415213623761160015036 00000000000000// WARNING: This example configuration is not meant for production use. // The Kea DHCPv6 server will refuse this configuration because it contains // mutually exclusive configuration parameters. // // The primary purpose of the example file is to provide a comprehensive // list of parameters supported by Kea DHCPv6 server along with the brief // description of each parameter. // // This current version should be up to date, i.e. new keywords should be // added in this file at the same time than in the syntax. { // Kea DHCPv6 server configuration begins here. "Dhcp6": { // Ordered list of client classes used by the DHCPv6 server. "client-classes": [ { // Class name. "name": "phones_server1", // Class specific DHCPv6 options list. "option-data": [], // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server1')" }, { // Second class name. "name": "phones_server2", // Class specific DHCPv6 options list. "option-data": [], // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server2')" }, { // Third class name. "name": "late", // Boolean flag indicating that the class expression is only evaluated // when the class is required, e.g. selected address pool configuration // includes this class name in its "require-client-classes" list. The // default value false means that the class test expression must // always be evaluated. "only-if-required": true, // Class selection expression. "test": "member('ALL')" } ], // Command control socket configuration parameters for Kea DHCPv6 server. "control-socket": { // Location of the unix domain socket file the DHCPv6 server uses // to receive control commands from the Kea Control Agent or the // local server administrator. "socket-name": "/tmp/kea-dhcp6-ctrl.sock", // Control socket type used by the Kea DHCPv6 server. The 'unix' // socket is currently the only supported type. "socket-type": "unix" }, // Time in seconds specifying how long a declined lease should be // excluded from DHCP assignments. The default value is 24 hours. "decline-probation-period": 86400, // Name Change Requests forwarding configuration for Kea DHCPv6 server. // NCRs are sent to Kea D2 module to update DNS upon allocation of the // DHCP leases. "dhcp-ddns": { // Boolean flag indicating if Kea DHCPv6 server must generate NCRs. // By default NCRs are not generated. "enable-updates": false, // Specifies a prefix to be prepended to the generated Client FQDN. "generated-prefix": "myhost", // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // Specifies maximum number of NCRs to queue waiting to be sent // to Kea D2 server. "max-queue-size": 1024, // Packet format to use when sending NCRs to Kea D2 server. // Currently, only JSON format is supported. "ncr-format": "JSON", // Socket protocol to use when sending NCRs to D2. Currently, // only UDP is supported. "ncr-protocol": "UDP", // Boolean flag indicating that server should ignore DHCP client // wishes to update DNS on its own. With that flag set to true // the server will send DNS updates for both forward and // reverse DNS data. The default value is false, which indicates // that the server will delegate DNS update to the client when // requested. "override-client-update": false, // Boolean flag indicating that the server should override DHCP // client's wish to not update the DNS. With this parameter // set to true the server will send DNS update even when // the client requested no update. "override-no-update": false, // Suffix appended to the partial name sent to the DNS. The // default value is an empty string which indicates that no // suffix is appended. "qualifying-suffix": "", // Enumeration specifying whether the server should honor // hostname or Client FQDN sent by the client or replace // this name. The acceptable values are: "never" (use the // name the client sent), "always" (replace the name the // client sent), "when-present" (replace the name the client // sent, but do not generate one when the client didn't sent // the name), "when-not-present" (generate the name when // client didn't send one, otherwise leave the name the // client sent). The default value is "never". "replace-client-name": "never", // IP address that Kea DHCPv6 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable address. "sender-ip": "::1", // Port number that Kea DHCPv6 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable port. "sender-port": 0, // IP address on which D2 listens for NCRs. "server-ip": "::1", // Port number on which D2 listens for NCRs. "server-port": 53001 }, // Specifies the first of the two consecutive ports of the UDP // sockets used for communication between DHCPv6 and DHCPv4 // servers. See RFC 7341. "dhcp4o6-port": 0, // Collection of Kea DHCPv6 server parameters configuring how // the server should process expired DHCP leases. "expired-leases-processing": { // Specifies the number of seconds since last removal of // the expired leases when next removal should occur. "flush-reclaimed-timer-wait-time": 25, // Specifies the time period in seconds to keep expired // leases in the lease database (lease affinity). "hold-reclaimed-time": 3600, // Specifies the maximum number of expired leases that can be // processed in a single attempt to clean up the lease // database from the expired leases. If there are more // expired leases, they will be processed during the next // cleanup attempt. "max-reclaim-leases": 100, // Specifies the maximum time in milliseconds that the single // attempt to cleanup the lease database from the expired // leases may take. "max-reclaim-time": 250, // Specifies the time period in seconds since last attempt // to process expired leases to initiate the next attempt. "reclaim-timer-wait-time": 10, // Specifies the maximum number of expired leases processing // cycles which didn't result in full cleanup of the lease // database from the expired leases, after which a // warning message is issued. "unwarned-reclaim-cycles": 5 }, // List of hooks libraries and their specific configuration parameters // to be loaded by Kea DHCPv4 server. "hooks-libraries": [ { // Location of the hooks library to be loaded. "library": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so", // Hook library specific configuration parameters. "parameters": { } } ], // List of access credentials to external sources of IPv6 reservations, "hosts-databases": [ { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 3306, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 5432, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "postgresql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "keyspace": "kea", // Host on which the database resides. "contact-points": "127.0.0.1", // Database password. "password": "kea", // Port on which the database is available. "port": 9042, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "cql", // User name to be used to access the database. "user": "kea", // Consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "consistency": "quorum", // Serial consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "serial-consistency": "serial", // Connection reconnect wait time. "reconnect-wait-time": 100, // Connection connect timeout. "connect-timeout": 100, // Connection request timeout. "request-timeout": 100, // Connection tcp keepalive. "tcp-keepalive": 100, // Connection tcp nodelay. "tcp-nodelay": true } ], // List of host reservation identifier types to be used by the // Kea DHCPv6 server to fetch static reservations for the // DHCP clients. All identifiers are used by default, which // means that the server will issue multiple queries to the // database to find if there is a reservation for the particular // client. If the particular deployment uses only subset, e.g. // one, identifier type, this identifier should be only listed // here to prevent unnecessary queries to the database. "host-reservation-identifiers": [ "hw-address", "duid", "flex-id" ], // Specifies configuration of interfaces on which the Kea DHCPv6 // server is listening to the DHCP queries. "interfaces-config": { // Specifies a list of interfaces on which the Kea DHCPv6 // server should listen to the DHCP requests. "interfaces": [ "ethX" ], // Boolean flag indicating if the available interfaces should // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. "re-detect": true }, // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval // in seconds at which lease file should be cleaned up (outdated // lease entries are removed to prevent lease file from growing // infinitely). "lfc-interval": 3600, // Maximum number of lease file read errors allowed before // loading the file is abandoned. Defaults to 0 (no limit). "max-row-errors": 100, // Name of the lease file. In case of database it specifies the // database name. "name": "/tmp/kea-dhcp6.csv", // memfile specific parameter indicating whether leases should // be saved on persistent storage (disk) or not. The true value // is the default and it indicates that leases are stored in the // persistent storage. This setting must be used in production. // The false value should only be used for testing purposes // because non stored leases will be lost upon Kea server restart. "persist": true, // Lease database backend type, i.e. "memfile", "mysql", // "postgresql" or "cql". "type": "memfile" }, // List of parameters indicating how the client's MAC address can be // inferred from the DHCP query. Supported values are listed in the // Kea Administrator Reference Manual. "mac-sources": [ "duid" ], // List of global DHCP options that Kea DHCPv6 server assigns to the // clients. "option-data": [ { // Boolean flag indicating if the given option is always // send in response or only when requested. The default // value of false indicates that it is only sent when // requested. "always-send": false, // Option code. It is not required if the option name is // provided. "code": 23, // Boolean value indicating whether the option data specified // in the "data" field is specified as a string of hexadecimal // digits or in human readable CSV format. "csv-format": true, // Option data to be stored in the option payload. "data": "2001:db8:2::45, 2001:db8:2::100", // Option name. It is not required of the option code is // provided. "name": "dns-servers", // Option space. The default is the "dhcp6" option space which // groups top level DHCPv6 options. "space": "dhcp6" } ], // List of global option definitions, i.e. option formats, that the // Kea DHCPv6 server is using. "option-def": [ { // Boolean flag indicating if the option definition comprises // an array of values of some type, e.g. array of IPv6 addresses. // The default value of false means that the option does not // comprise an array of values. "array": false, // Option code. "code": 6, // Holds a name of the option space encapsulated by this option. // All options that belong to this option space will be sent // as sub-options of this option. Empty string means that this // option doesn't encapsulate any option. "encapsulate": "", // Option name. "name": "my-option", // Specifies the types of fields within the option if the option // is said to be a "record" (see "type"). in this particular example // this option comprises two fields, 1 byte and 2 bytes long. "record-types": "uint8, uint16", // Name of the option space to which this option belongs. "space": "my-space", // Option type. All possible types are listed in the Kea // Administrator Reference Manual. "type": "record" } ], // Global (default) value of the preferred lifetime. "preferred-lifetime": 50, // Global min value of the preferred lifetime. "min-preferred-lifetime": 40, // Global max value of the preferred lifetime. "max-preferred-lifetime": 60, // Global value for the rebind timer, i.e. the time after which the // DHCP client enters rebind state if it fails to renew the lease. "rebind-timer": 40, // List of relay supplied option codes. See RFC 6422. "relay-supplied-options": [ "110", "120", "130" ], // Global value for the renew timer, i.e. the timer after which the // DHCP client renews the lease. "renew-timer": 30, // Governs how the Kea DHCPv6 server should deal with the invalid // data received from the client. "sanity-checks": { // Specifies how the Kea DHCPv6 server should behave when invalid // data is read for a lease from the lease file. The following // values are supported "none" (don't attempt to correct the // lease information), "warn" (print a warning for subnet-id // related inconsistencies), "fix" (correct the subnet id by // trying to find the suitable subnet), "fix-del" (similar // to "fix" but delete the lease if no suitable subnet found), // "del" (delete the lease if the lease has invalid subnet // identifier value). "lease-checks": "warn" }, // Custom DUID used by the DHCPv6 server. "server-id": { // Type of the DUID. Possible values are "LLT", "EN", and "LL". "type": "EN", // Enterprise id used for "EN" duid. "enterprise-id": 2495, // Identifier part of the DUID. "identifier": "0123456789", // Boolean flag indicating if the DUID should be persisted on // disk. "persist": false }, // List of shared networks used by Kea DHCPv6 server. The shared // networks group subnets together. "shared-networks": [ { // Restricts this shared network to allow only clients // that belong to the particular client class. If an // empty string is provided, no restriction is applied. "client-class": "", // Specifies that this shared network is selected for the // requests received on the particular interface. "interface": "ethX", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to // which the response is sent. "interface-id": "", // Shared network name. "name": "my-secret-network", // List of shared network specific DHCP options. "option-data": [], // Shared network specific (default) preferred lifetime. "preferred-lifetime": 2000, // Shared network specific min preferred lifetime. "min-preferred-lifetime": 1500, // Shared network specific ma xpreferred lifetime. "max-preferred-lifetime": 2500, // Boolen flag indicating if the server can respond to // a Solicit message including a Rapid Commit option with // the Reply message (See DHCPv6 rapid commit). "rapid-commit": false, // List of IPv6 relay addresses for which this shared // network is selected. "relay": { "ip-addresses": [] }, // Shared network level rebind timer. "rebind-timer": 41, // Shared network level renew timer. "renew-timer": 31, // Shared network level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // List of client classes which must be evaluated when this shared // network is selected for client assignments. "require-client-classes": [ "late" ], // List of IPv6 subnets belonging to this shared network. "subnet6": [ { // Restricts this subnet to allow only clients that belong // to the particular client class. If an empty string is // provided, no restriction is applied. "client-class": "", // Subnet unique identifier. "id": 1, // Specifies that this subnet is selected for the requests // received on the particular interface. "interface": "ethX", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to // which the response is sent. "interface-id": "", // Subnet level list of DHCP options. "option-data": [ { // Boolean flag indicating if the particular option // should be always sent or sent only when requested. "always-send": false, // Option code. "code": 7, // Boolean flag indicating if the option value specified // in "data" is a string of hexadecimal values or human // readable CSV value. "csv-format": false, // Option data to be included in the option payload. "data": "0xf0", // Option name. "name": "preference", // Option space. The default value "dhcp6" designates the // top level option space. "space": "dhcp6" } ], // List of pools from which delegated prefixes are assigned to the // clients. "pd-pools": [ { // Restricts this prefix pool to be used only for the client // requests belonging to a particular client class. "client-class": "phones_server1", // Length of prefixes delegated to clients. "delegated-len": 64, // Excluded prefix (address) from client assignments. "excluded-prefix": "2001:db8::", // Excluded prefix (length) from client assignments. "excluded-prefix-len": 48, // Prefix pool level list of DHCP options. "option-data": [], // Prefix range (address) used for client assignments. "prefix": "2001:db8::", // Prefix range (length) used for client assignments. "prefix-len": 40, // List of client classes which must be evaluated // when this prefix pool is selected for client assignments. "require-client-classes": [] } ], "pools": [ { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server1", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "2001:db8:0:1::/64", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [ "late" ] }, { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server2", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "2001:db8:0:3::/64", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [] } ], // Subnet specific (default) preferred lifetime. "preferred-lifetime": 2000, // Subnet specific min preferred lifetime. "min-preferred-lifetime": 1500, // Subnet specific max referred lifetime. "max-preferred-lifetime": 2500, // Boolen flag indicating if the server can respond to // a Solicit message including a Rapid Commit option with // the Reply message (See DHCPv6 rapid commit). "rapid-commit": false, // Subnet level rebind timer. "rebind-timer": 40, // List of IPv4 relay addresses for which this subnet // is selected. "relay": { "ip-addresses": [ "2001:db8:0:f::1" ] }, // Subnet level renew timer. "renew-timer": 30, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // Subnet level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // List of static IPv6 reservations assigned to the clients belonging // to this subnet. For detailed example see reservations.json. "reservations": [ { // Identifier used for client matching. Supported values are // "duid", "hw-address" and "flex-id". "duid": "01:02:03:04:05:06:07:08:09:0A", // List of reserved IPv6 addresses. "ip-addresses": [ "2001:db8:1:cafe::1" ], // List of reserved IPv6 prefixes. "prefixes": [ "2001:db8:2:abcd::/64" ], // Reserved hostname. "hostname": "foo.example.com", // Reservation specific option data. "option-data": [ { // Option name. "name": "vendor-opts", // Option value. "data": "4491" } ] } ], // List of client classes which must be evaluated when this subnet // is selected for client assignments. "require-client-classes": [ "late" ], // Subnet prefix. "subnet": "2001:db8::/32", // Subnet level (default) valid lifetime. "valid-lifetime": 6000, // Subnet level min valid lifetime. "min-valid-lifetime": 4000, // Subnet level max valid lifetime. "max-valid-lifetime": 8000 } ], // Shared network level (default) valid lifetime. "valid-lifetime": 6001, // Shared network level min valid lifetime. "min-valid-lifetime": 4001, // Shared network level max valid lifetime. "max-valid-lifetime": 8001 } ], // List of IPv6 subnets which don't belong to any shared network. "subnet6": [], // Global (default) valid lifetime value. "valid-lifetime": 6000, // Global min valid lifetime value. "min-valid-lifetime": 4000, // Global max valid lifetime value. "max-valid-lifetime": 8000, // Reservations (examples are in other files). "reservations": [], // Configuration control (currently not used, i.e. this syntax // is already defined but corresponding feature is not implemented). "config-control": { // Only configuration databases entry is defined. "config-databases": [ { // Name of the database to connect to. "name": "config", // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql" } ], // Intervals between attempts to fetch configuration updates // via the configuration backends used. "config-fetch-wait-time": 30 }, // Server tag. "server-tag": "my DHCPv6 server", // DHCP queue control parameters. "dhcp-queue-control": { // Enable queue is mandatory. "enable-queue": true, // Queue type was mandatory. "queue-type": "kea-ring6" }, // Fetches host reservations. "reservation-mode": "all", // Data directory. "data-directory": "/tmp", // Global compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // List of loggers used by the servers using this configuration file. "loggers": [ { // Debug level, a value between 0..99. The greater the value // the more detailed debug log. "debuglevel": 99, // Name of the logger. "name": "kea-dhcp6", // Configures how the log should be output. "output_options": [ { // Determines whether the log should flushed to a file. "flush": true, // Specifies maximum filesize before the file is being rotated. "maxsize": 10240000, // Specifies the maximum number of rotated files being kept. "maxver": 1, // Specifies logging destination. "output": "stdout", // Specifies log entry content "pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" } ], // Specifies logging severity, i.e. "ERROR", "WARN", "INFO", "DEBUG". "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/stateless.json0000644000175000017500000000152113623761160015320 00000000000000// A very simply stateless configuration that provides information about DNS // servers to all clients, regardless of their point of attachment. // // It is also possible to specify options on a per subnet basis // in the same way as in stateful mode. // { "Dhcp6": { "interfaces-config": { "interfaces": [ "ethX" ] }, // This is the list of options that will be granted to all clients that ask. "option-data": [ { "name": "dns-servers", "data": "2001:db8::1, 2001:db8::2" } ], // Kea 0.9.1 requires lease-database to be specified, even it is not used. // In stateless mode, only options are granted, not addresses or // prefixes, so there will be no leases (unless stateless and stateful // mode is used together). "lease-database": { "type": "memfile", "lfc-interval": 3600 } } } kea-1.6.2/doc/examples/kea6/ha-hot-standby.json0000644000175000017500000001462313623761160016142 00000000000000// This is an example configuration of the Kea DHCPv6 server. It uses High // Availability hooks library and Lease Commands hooks library to enable // High Availibility function for the DHCP server. Note that almost exactly // the same configuration must be used on the second server (partner). // The only difference is that "this-server-name" must be set to "server1" // on this other server. Also, the interface configuration depends on the // network settings of the particular machine. // // The servers using this configuration work in hot standby mode.. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Control socket is required for communication between the Control // Agent and the DHCP server. High Availability requires Control Agent // to be running because lease updates are sent over the RESTful // API between the HA peers. "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea-dhcp6-ctrl.sock" }, // 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) and even Cassandra. 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 a in-memory "type": "memfile" }, // HA requires two hooks libraries to be loaded: libdhcp_lease_cmds.so and // libdhcp_ha.so. The former handles incoming lease updates from the HA peers. // The latter implements high availability feature for Kea. "hooks-libraries": [ { "library": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so", "parameters": { } }, { // The HA hooks library should be loaded. "library": "/opt/lib/kea/hooks/libdhcp_ha.so", "parameters": { // High Availability configuration is specified for the HA hook library. // Each server should have the same HA configuration, except for the // "this-server-name" parameter. "high-availability": [ { // This parameter points to this server instance. The respective // HA peers must have this parameter set to their own names. "this-server-name": "server2", // The HA mode is set to hot-standby. This server will receive lease // updates from the primary. The primary will be responding to all // DHCP queries. "mode": "hot-standby", // Heartbeat is to be sent every 10 seconds if no other control // commands are transmitted. "heartbeat-delay": 10000, // Maximum time for partner's response to a heartbeat, after which // failure detection is started. This is specified in milliseconds. "max-response-delay": 10000, // The following parameters control how the server detects the // partner's failure. The ACK delay sets the threshold for the // 'secs' field of the received discovers. This is specified in // milliseconds. "max-ack-delay": 5000, // This specifies the number of clients which send messages to // the partner but appear to not receive any response. "max-unacked-clients": 5, "peers": [ // This is the configuration of our HA peer. { "name": "server1", // Specifies the URL on which the partner's control // channel can be reached. The Control Agent is required // to run on the partner's machine with "http-host" and // "http-port" values set to the corresponding values. "url": "http://192.168.56.33:8080/", // Th partner is primary. Our is standby. "role": "primary" }, // This is the configuration of this server instance. { "name": "server2", // This specifies the URL of our server instance. The // Control Agent must run along with our DHCPv6 server // instance and the "http-host" and "http-port" must be // set to the corresponding values. "url": "http://192.168.56.66:8080/", // Out server is standby. The partner is primary. "role": "standby" } ] } ] } } ], // The following list defines subnets. Each subnet consists of at // least subnet and pool entries. "subnet6": [ { "subnet": "2001:db8:1::/64", "pools": [ { "pool": "2001:db8:1::100 - 2001:db8:1::250" } ], "interface": "ethX" } ], // The following configures logging. It assumes that messages with at // least informational level (info, warn, error and fatal) should be // logged to stdout. Alternatively, you can specify stderr here, a filename // or 'syslog', which will store output messages via syslog. "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "stdout" } ], "debuglevel": 0, "severity": "INFO" }, { // This section specifies configuration of the HA hooks library specific // logger. "name": "kea-dhcp4.ha-hooks", "output_options": [ { "output": "stdout" } ], "severity": "INFO", "debuglevel": 99 } ] } } kea-1.6.2/doc/examples/kea6/comments.json0000644000175000017500000000543613623761160015147 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // It uses embedded (i.e., which will be included in configuration objects // and not stripped by at lexical analysis) comments. { "Dhcp6": { // Global scope "comment": "A DHCPv6 server", // In interface config "interfaces-config": { "comment": "Use wildcard", "interfaces": [ "*" ] }, // In option definitions "option-def": [ { "comment": "An option definition", "name": "foo", "code": 100, "type": "ipv6-address", "space": "isc" } ], // In option data "option-data": [ { "comment": "Set option value", "name": "subscriber-id", "data": "ABCDEF0105", "csv-format": false } ], // In client classes "client-classes": [ { "comment": "match all", "name": "all", "test": "'' == ''" }, // Of course comments are optional { "name": "none" }, // A comment and a user-context can be specified { "comment": "a comment", "name": "both", "user-context": { "version": 1 } } ], // In control socket (more for the agent) "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea6-ctrl-socket", "user-context": { "comment": "Indirect comment" } }, // In shared networks "shared-networks": [ { "comment": "A shared network", "name": "foo", // In subnets "subnet6": [ { "comment": "A subnet", "subnet": "2001:db1::/64", "id": 100, // In pools "pools": [ { "comment": "A pool", "pool": "2001:db1::/64" } ], // In prefix pools "pd-pools": [ { "comment": "A prefix pool", "prefix": "2001:db2::", "prefix-len": 48, "delegated-len": 64 } ], // In host reservations "reservations": [ { "comment": "A host reservation", "hw-address": "AA:BB:CC:DD:EE:FF", "hostname": "foo.example.com", // Again in an option data "option-data": [ { "comment": "An option in a reservation", "name": "domain-search", "data": "example.com" } ] } ] } ] } ], // In dhcp ddns "dhcp-ddns": { "comment": "No dynamic DNS", "enable-updates": false }, // In loggers "loggers": [ { "comment": "A logger", "name": "kea-dhcp6" } ] } } kea-1.6.2/doc/examples/kea6/reservations.json0000644000175000017500000001337513623761160016047 00000000000000// This is an example configuration file for DHCPv6 server in Kea // that showcases how to do host reservations. It is // assumed that one subnet (2001:db8:1::/64) is available directly // over ethX interface. A number of hosts have various combinations // of addresses and prefixes reserved for them. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // This is pretty basic stuff, it has nothing to do with reservations. "preferred-lifetime": 3000, "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // Kea supports three types of identifiers in DHCPv6: hw-address (hardware/MAC // address of the client), duid (DUID inserted by the client) and flex-id // (flexible identifier available when flex_id hook library is loaded) When told // to do so, Kea can check for each of these identifier types, but it takes a // costly database lookup to do so. It is therefore useful from a performance // perspective to use only the reservation types that are actually used in a // given network. "host-reservation-identifiers": [ "duid", "hw-address", "flex-id" ], // The following list defines subnets. Subnet, pools and interface definitions // are the same as in the regular scenario, without host reservations. // least subnet and pool entries. "subnet6": [ { "subnet": "2001:db8:1::/48", // This directive tells Kea that reservations may be made both in-pool // and out-of-pool. For improved performance, you may move all reservations // out of the dynamic pool and change reservation-mode to "out-of-pool". // Kea will then be able to skip querying for host reservations when // assigning leases from dynamic pool. "reservation-mode": "all", "pools": [ { "pool": "2001:db8:1::/120" } ], "pd-pools": [ { "prefix": "2001:db8:1:8000::", "prefix-len": 56, "delegated-len": 64 } ], "interface": "ethX", // Host reservations. Define several reservations, note that // they are all within the range of the pool of the dynamically // allocated address. The server will exclude the addresses from this // pool and only assign them to the client which has a reservation for // them. "reservations": [ // This is a simple host reservation. The host with DUID matching // the specified value will get an address of 2001:db8:1::100. { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "ip-addresses": [ "2001:db8:1::100" ] }, // This is similar to the previous one, but this time the reservation // is done based on hardware/MAC address. The server will do its best to // extract the hardware/MAC address from received packets (see // 'mac-sources' directive for details). This particular reservation // also specifies two extra options to be available for this client. If // there are options with the same code specified in a global, subnet or // class scope, the values defined at host level take precedence. { "hw-address": "00:01:02:03:04:05", "ip-addresses": [ "2001:db8:1::101" ], "option-data": [ { "name": "dns-servers", "data": "3000:1::234" }, { "name": "nis-servers", "data": "3000:1::234" }], "client-classes": [ "special_snowflake", "office" ] }, // This is a bit more advanced reservation. The client with the specified // DUID will get a reserved address, a reserved prefix and a hostname. // This reservation is for an address that it not within the dynamic pool. // Finally, this reservation features vendor specific options for CableLabs, // which happen to use enterprise-id 4491. Those particular values will // be returned only to the client that has a DUID matching this reservation. { "duid": "01:02:03:04:05:06:07:08:09:0A", "ip-addresses": [ "2001:db8:1:cafe::1" ], "prefixes": [ "2001:db8:2:abcd::/64" ], "hostname": "foo.example.com", "option-data": [ { "name": "vendor-opts", "data": "4491" }, { "name": "tftp-servers", "space": "vendor-4491", "data": "3000:1::234" } ] }, // 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": "'somevalue'", "ip-addresses": [ "2001:db8:1:cafe::2" ] } ] } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/simple.json0000644000175000017500000000361313623761160014606 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It's a basic scenario with one IPv6 subnet configured. It is // assumed that one subnet (2001:db8:1::/64 is available directly // over ethX interface. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // The following configures logging. It assumes that messages with at // least informational level (info, warn, error and fatal) should be // logged to stdout. Alternatively, you can specify stderr here, a filename // or 'syslog', which will store output messages via syslog. "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "stdout" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/backends.json0000644000175000017500000001001213623761160015056 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // It is a basic scenario with one IPv6 subnet configured. It demonstrates // how to configure Kea to use various backends to store leases: // - memfile // - MySQL // - PostgreSQL // - CQL (Cassandra) backend { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify lease type. Exactly one lease-database section // should be present. Make sure you uncomment only one. // 1. memfile backend. Leases information will be stored in flat CSV file. // This is the easiest backend to use as it does not require any extra // dependencies or services running. "lease-database": { "type": "memfile", "persist": true, "lfc-interval": 3600 }, // 2. MySQL backend. Leases will be stored in MySQL database. Make sure it // is up, running and properly initialized. See kea-admin documentation // for details on how to initialize the database. The only strictly required // parameters are type and name. If other parameters are not specified, // Kea will assume the database is available on localhost, that user and // password is not necessary to connect and that timeout is 5 seconds. // Kea must be compiled with --with-mysql option to use this backend. // "lease-database": { // "type": "mysql", // "name": "keatest", // "host": "localhost", // "port": 3306, // "user": "keatest", // "password": "secret1", // "connect-timeout": 3 // }, // 3. PostgreSQL backend. Leases will be stored in PostgreSQL database. Make // sure it is up, running and properly initialized. See kea-admin documentation // for details on how to initialize the database. The only strictly required // parameters are type and name. If other parameters are not specified, // Kea will assume the database is available on localhost, that user and // password is not necessary to connect and that timeout is 5 seconds. // Kea must be compiled with --with-pgsql option to use this backend. // "lease-database": { // "type": "postgresql", // "name": "keatest", // "host": "localhost", // "port": 5432, // "user": "keatest", // "password": "secret1", // "connect-timeout": 3 // }, // 4. CQL (Cassandra) backend. Leases will be stored in Cassandra // database. Make sure it is up, running and properly initialized. See // kea-admin documentation for details on how to initialize the // database. The only strictly required parameters are type, keyspace // and contact-points. At least one contact point must be specified, but // more than one is required for redundancy. Make sure you specify the // contact points without spaces. Kea must be compiled with --with-cql // option to use this backend. // "lease-database": { // "type": "cql", // "keyspace": "keatest", // "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3", // "port": 9042 // }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/dhcpv4-over-dhcpv6.json0000644000175000017500000000207413623761160016646 00000000000000// This is an example configuration file for the DHCPv6 server of // DHCPv4-over-DHCPv6 tests in Kea. { // DHCPv6 conf "Dhcp6": { "interfaces-config": { // Enable unicast "interfaces": [ "eno33554984/2001:db8:1:1::1" ] }, "lease-database": { "type": "memfile", "name": "leases6" }, "preferred-lifetime": 3000, "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, "subnet6": [ { "subnet": "2001:db8:1:1::/64", "interface": "eno33554984", "pools": [ { "pool": "2001:db8:1:1::1:0/112" } ] } ], // This enables DHCPv4-over-DHCPv6 support "dhcp4o6-port": 6767, // Required by DHCPv4-over-DHCPv6 clients "option-data": [ { "name": "dhcp4o6-server-addr", "code": 88, "space": "dhcp6", "csv-format": true, // Put the server address here "data": "2001:db8:1:1::1" } ], "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "/tmp/kea-dhcp6.log" } ], "severity": "DEBUG", "debuglevel": 0 } ] } } kea-1.6.2/doc/examples/kea6/shared-network.json0000644000175000017500000001110013623761160016240 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It demonstrates an advanced feature called shared network. Typically, for // each physical link there is one IPv6 subnet that the server is expected // to manage. However, in some cases there is a need to configure more subnets // in the same physical location. This may sound odd, as IPv6 is not expected // to run out of addresses. However, due to vast address space some deployments // experiment with various addressing schemes and later find out that the // initial proposal was not best and way to migrate to something else. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // You also need to tell where to store lease information. // memfile is the backend that is easiest to set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // It is likely that in your network you'll have a mix of regular, // "plain" subnets and shared networks. It is perfectly valid to mix // them in the same config file. // // This is regular subnet. It's not part of any shared-network. "subnet6": [ { "pools": [ { "pool": "2001:db8:2::/80" } ], "subnet": "2001:db8:2::/64", "interface": "ethX" } ], // Hhe shared networks definition starts here. shared-networks can // contain a list of shared networks. There are many parameters // that can be specified here, so this example may be overwhelming // at first, but the only mandatory parameter for each shared // network is name. It must be unique. Typically, each shared // network also needs to have at least two subnets to be functional, // but if you really want to, you can define a degraded shared // network that has 1 or even 0 subnets. This may come in handy // when migrating between regular subnets and shared networks // or when debugging a problem. It is not recommended to use // 1 subnet per shared network, as there is extra processing // overhead for shared networks. "shared-networks": [ { "interface": "eth1", // Similar to regular subnets, it is forbidden to define both // interface and interface-id at the same time. That's because // interface parameter expresses physical network interface // for links available locally and interface-id identifies // values inserted by relays, which are only used for // remote traffic. A shared network cannot be both direct // and relayed. //"interface-id": "content of the option", // Other parameters defined here will be inherited by the // subnets. "name": "frog", "option-data": [ ], "preferred-lifetime": 200, "rapid-commit": true, "rebind-timer": 150, "relay": { "ip-address": "2001:db8::1" }, "renew-timer": 100, "reservation-mode": "all", // List of subnets belonging to this particular shared-network // start here. "subnet6": [ // This is the first subnet. { "preferred-lifetime": 30, "rapid-commit": false, "rebind-timer": 20, // It is possible to override some values here. "relay": { "ip-address": "2001:db8:1::123" }, "renew-timer": 10, "reservation-mode": "all", "subnet": "2001:db8:1::/64", "pools": [ { "pool": "2001:db8:1:abcd::/64" } ], "valid-lifetime": 40 }, // This is the second subnet. { "preferred-lifetime": 30, "pools": [ { "pool": "3000:db8::/64" } ], "rapid-commit": false, "rebind-timer": 20, "relay": { "ip-address": "3000::1" }, "renew-timer": 10, "reservation-mode": "all", "subnet": "3000::/16", "valid-lifetime": 40 } ], "valid-lifetime": 300 } ] } } kea-1.6.2/doc/examples/kea6/softwire46.json0000644000175000017500000000516413623761160015334 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It demonstrates how user can specify values for Softwire options // defined in RFC 7598 for Lightweight 4over6 architecture. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Let's use a Memfile backend to store leases. "lease-database": { "type": "memfile" }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX", // Include MAP-E Container option for hosts connected to this subnet. "option-data": [ { "name": "s46-cont-mape" } ], // Send host specific softwire options. "reservations": [ { "duid": "01:02:03:04:05:06:07:08:09:0A", "option-data": [ // These two options will be included in the MAP-E Container { "space": "s46-cont-mape-options", "name": "s46-rule", "data": "1, 0, 24, 192.0.2.0, 2001:db8:1::/64" }, { "space": "s46-cont-mape-options", "name": "s46-br", "data": "2001:db8:cafe::1" }, // This option will be included in the S46 Rule option. It includes // PSID/PSID length value in a user friendly form. The PSID length // specifies the number of bits on which PSID is coded. The PSID // value 3 is a 4th value that is coded on these 4 bits: "0011b". { "space": "s46-rule-options", "name": "s46-portparams", "data": "0, 3/4" } ] } ] } ], // The following configures logging. Kea will log all debug messages // to /var/log/kea-debug.log file. "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "/var/log/kea-debug.log" } ], "debuglevel": 99, "severity": "DEBUG" } ] } } kea-1.6.2/doc/examples/kea6/iPXE.json0000644000175000017500000000452313623761160014123 00000000000000// This is an example configuration for iPXE boot in Kea6. { "Dhcp6": { // Mandatory part of the config that list interfaces on which // Kea will listen for incoming traffic. "interfaces-config": { "interfaces": [ "ethX" ] }, // Two classes are migrated form ISC-DHCP example: // if exists dhcp6.client-arch-type and // option dhcp6.client-arch-type = 00:07 { // option dhcp6.bootfile-url "http://[2001:db8::1]/ipxe.efi"; // } else if exists dhcp6.user-class and // substring(option dhcp6.user-class, 2, 4) = "iPXE" { // option dhcp6.bootfile-url "http://[2001:db8::1]/ubuntu.cfg"; // } // // In example shown below incoming packet will receive value // http://[2001:db8::1]/ubuntu.cfg if incoming packet will include user // class option with "iPXE" in it and value http://[2001:db8::1]/ipxe.efi // if option client architecture type will be 7. // If incoming packet will include both of those options with matching // values it will be assigned to class "a-ipxe" because it was first // matching class. If you want to change that order names of the classes // have to have different alphabetical order. In Kea 1.3.0 (and previous // versions) alphabetical order is used in classification. Note this // should change in next versions, for instance to keep the definition // order. "client-classes": [ { "name": "a-ipxe", // user-class option (code 15) is a tuple array // so we need to skip the length (tuple first element) "test": "substring(option[15].hex, 2, 4) == 'iPXE'", "option-data": [ { "space": "dhcp6", "name": "bootfile-url", "code": 59, "data": "http://[2001:db8::1]/ubuntu.cfg" } ] }, { "name": "b-efi", // please consider to add a not a-ipxe here to enforce // the "else"? "test": "option[61].hex == 0x0007", "option-data": [ { "space": "dhcp6", "name": "bootfile-url", "code": 59, "data": "http://[2001:db8::1]/ipxe.efi" } ] } ], "subnet6": [ { "subnet": "2001:db8::/64" } ] } } kea-1.6.2/doc/examples/kea6/with-ddns.json0000644000175000017500000000457513623761160015226 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It's a basic scenario with one IPv6 subnet configured. It is // assumed that one subnet (2001:db8:1::/64 is available directly // over ethX interface. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // Enable dynamic DNS updates "dhcp-ddns" : { "enable-updates" : true, "server-ip" : "3001::1", "server-port" : 3432, "sender-ip" : "3001::2", "sender-port" : 3433, "max-queue-size" : 2048, "ncr-protocol" : "UDP", "ncr-format" : "JSON", "override-no-update" : true, "override-client-update" : true, "replace-client-name" : "when-present", "generated-prefix" : "test.prefix", "qualifying-suffix" : "test.suffix.", "hostname-char-set": "[^A-Za-z0-9.-]", "hostname-char-replacement": "x" }, // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/all-keys-netconf.json0000644000175000017500000010373713623761160016500 00000000000000// WARNING: This example configuration is not meant for production use. // The Kea DHCPv6 server will refuse this configuration because it contains // mutually exclusive configuration parameters. // // The primary purpose of the example file is to provide a comprehensive // list of parameters supported by Kea DHCPv6 server along with the brief // description of each parameter. // // This stable version is used for YANG as we do not want to update code // and models each time a keyword is added to the syntax. { // Kea DHCPv6 server configuration begins here. "Dhcp6": { // Ordered list of client classes used by the DHCPv6 server. "client-classes": [ { // Class name. "name": "phones_server1", // Class specific DHCPv6 options list. "option-data": [], // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server1')" }, { // Second class name. "name": "phones_server2", // Class specific DHCPv6 options list. "option-data": [], // Class selection expression. The DHCP packet is assigned to this // class when the given expression evaluates to true. "test": "member('HA_server2')" }, { // Third class name. "name": "late", // Boolean flag indicating that the class expression is only evaluated // when the class is required, e.g. selected address pool configuration // includes this class name in its "require-client-classes" list. The // default value false means that the class test expression must // always be evaluated. "only-if-required": true, // Class selection expression. "test": "member('ALL')" } ], // Command control socket configuration parameters for Kea DHCPv6 server. "control-socket": { // Location of the unix domain socket file the DHCPv6 server uses // to receive control commands from the Kea Control Agent or the // local server administrator. "socket-name": "/tmp/kea-dhcp6-ctrl.sock", // Control socket type used by the Kea DHCPv6 server. The 'unix' // socket is currently the only supported type. "socket-type": "unix" }, // Time in seconds specifying how long a declined lease should be // excluded from DHCP assignments. The default value is 24 hours. "decline-probation-period": 86400, // Name Change Requests forwarding configuration for Kea DHCPv6 server. // NCRs are sent to Kea D2 module to update DNS upon allocation of the // DHCP leases. "dhcp-ddns": { // Boolean flag indicating if Kea DHCPv6 server must generate NCRs. // By default NCRs are not generated. "enable-updates": false, // Specifies a prefix to be prepended to the generated Client FQDN. "generated-prefix": "myhost", // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // Specifies maximum number of NCRs to queue waiting to be sent // to Kea D2 server. "max-queue-size": 1024, // Packet format to use when sending NCRs to Kea D2 server. // Currently, only JSON format is supported. "ncr-format": "JSON", // Socket protocol to use when sending NCRs to D2. Currently, // only UDP is supported. "ncr-protocol": "UDP", // Boolean flag indicating that server should ignore DHCP client // wishes to update DNS on its own. With that flag set to true // the server will send DNS updates for both forward and // reverse DNS data. The default value is false, which indicates // that the server will delegate DNS update to the client when // requested. "override-client-update": false, // Boolean flag indicating that the server should override DHCP // client's wish to not update the DNS. With this parameter // set to true the server will send DNS update even when // the client requested no update. "override-no-update": false, // Suffix appended to the partial name sent to the DNS. The // default value is an empty string which indicates that no // suffix is appended. "qualifying-suffix": "", // Enumeration specifying whether the server should honor // hostname or Client FQDN sent by the client or replace // this name. The acceptable values are: "never" (use the // name the client sent), "always" (replace the name the // client sent), "when-present" (replace the name the client // sent, but do not generate one when the client didn't sent // the name), "when-not-present" (generate the name when // client didn't send one, otherwise leave the name the // client sent). The default value is "never". "replace-client-name": "never", // IP address that Kea DHCPv6 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable address. "sender-ip": "::1", // Port number that Kea DHCPv6 server should use to send // NCRs to D2. Default value of zero indicates that Kea // should pick suitable port. "sender-port": 0, // IP address on which D2 listens for NCRs. "server-ip": "::1", // Port number on which D2 listens for NCRs. "server-port": 53001 }, // Specifies the first of the two consecutive ports of the UDP // sockets used for communication between DHCPv6 and DHCPv4 // servers. See RFC 7341. "dhcp4o6-port": 0, // Collection of Kea DHCPv6 server parameters configuring how // the server should process expired DHCP leases. "expired-leases-processing": { // Specifies the number of seconds since last removal of // the expired leases when next removal should occur. "flush-reclaimed-timer-wait-time": 25, // Specifies the time period in seconds to keep expired // leases in the lease database (lease affinity). "hold-reclaimed-time": 3600, // Specifies the maximum number of expired leases that can be // processed in a single attempt to clean up the lease // database from the expired leases. If there are more // expired leases, they will be processed during the next // cleanup attempt. "max-reclaim-leases": 100, // Specifies the maximum time in milliseconds that the single // attempt to cleanup the lease database from the expired // leases may take. "max-reclaim-time": 250, // Specifies the time period in seconds since last attempt // to process expired leases to initiate the next attempt. "reclaim-timer-wait-time": 10, // Specifies the maximum number of expired leases processing // cycles which didn't result in full cleanup of the lease // database from the expired leases, after which a // warning message is issued. "unwarned-reclaim-cycles": 5 }, // List of hooks libraries and their specific configuration parameters // to be loaded by Kea DHCPv4 server. "hooks-libraries": [ { // Location of the hooks library to be loaded. "library": "/opt/lib/kea/hooks/libdhcp_lease_cmds.so", // Hook library specific configuration parameters. "parameters": { } } ], // List of access credentials to external sources of IPv6 reservations, "hosts-databases": [ { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 3306, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "name": "kea", // Host on which the database resides. "host": "localhost", // Database password. "password": "kea", // Port on which the database is available. "port": 5432, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "postgresql", // User name to be used to access the database. "user": "kea" }, { // Name of the database to connect to. "keyspace": "kea", // Host on which the database resides. "contact-points": "127.0.0.1", // Database password. "password": "kea", // Port on which the database is available. "port": 9042, // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "cql", // User name to be used to access the database. "user": "kea", // Consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "consistency": "quorum", // Serial consistency level for all queries. // Supported values: any, one, two, three, quorum, all, // local-quorum, each-quorum, serial, local-serial, local-one. "serial-consistency": "serial", // Connection reconnect wait time. "reconnect-wait-time": 100, // Connection connect timeout. "connect-timeout": 100, // Connection request timeout. "request-timeout": 100, // Connection tcp keepalive. "tcp-keepalive": 100, // Connection tcp nodelay. "tcp-nodelay": true } ], // List of host reservation identifier types to be used by the // Kea DHCPv6 server to fetch static reservations for the // DHCP clients. All identifiers are used by default, which // means that the server will issue multiple queries to the // database to find if there is a reservation for the particular // client. If the particular deployment uses only subset, e.g. // one, identifier type, this identifier should be only listed // here to prevent unnecessary queries to the database. "host-reservation-identifiers": [ "hw-address", "duid", "flex-id" ], // Specifies configuration of interfaces on which the Kea DHCPv6 // server is listening to the DHCP queries. "interfaces-config": { // Specifies a list of interfaces on which the Kea DHCPv6 // server should listen to the DHCP requests. "interfaces": [ "ethX" ], // Boolean flag indicating if the available interfaces should // be re-detected upon server reconfiguration. The default value // is true which means that the interfaces are always // re-detected. "re-detect": true }, // Specifies credentials to access lease database. "lease-database": { // memfile backend specific parameter specifying the interval // in seconds at which lease file should be cleaned up (outdated // lease entries are removed to prevent lease file from growing // infinitely). "lfc-interval": 3600, // Maximum number of lease file read errors allowed before // loading the file is abandoned. Defaults to 0 (no limit). "max-row-errors": 100, // Name of the lease file. In case of database it specifies the // database name. "name": "/tmp/kea-dhcp6.csv", // memfile specific parameter indicating whether leases should // be saved on persistent storage (disk) or not. The true value // is the default and it indicates that leases are stored in the // persistent storage. This setting must be used in production. // The false value should only be used for testing purposes // because non stored leases will be lost upon Kea server restart. "persist": true, // Lease database backend type, i.e. "memfile", "mysql", // "postgresql" or "cql". "type": "memfile" }, // List of parameters indicating how the client's MAC address can be // inferred from the DHCP query. Supported values are listed in the // Kea Administrator Reference Manual. "mac-sources": [ "duid" ], // List of global DHCP options that Kea DHCPv6 server assigns to the // clients. "option-data": [ { // Boolean flag indicating if the given option is always // send in response or only when requested. The default // value of false indicates that it is only sent when // requested. "always-send": false, // Option code. It is not required if the option name is // provided. "code": 23, // Boolean value indicating whether the option data specified // in the "data" field is specified as a string of hexadecimal // digits or in human readable CSV format. "csv-format": true, // Option data to be stored in the option payload. "data": "2001:db8:2::45, 2001:db8:2::100", // Option name. It is not required of the option code is // provided. "name": "dns-servers", // Option space. The default is the "dhcp6" option space which // groups top level DHCPv6 options. "space": "dhcp6" } ], // List of global option definitions, i.e. option formats, that the // Kea DHCPv6 server is using. "option-def": [ { // Boolean flag indicating if the option definition comprises // an array of values of some type, e.g. array of IPv6 addresses. // The default value of false means that the option does not // comprise an array of values. "array": false, // Option code. "code": 6, // Holds a name of the option space encapsulated by this option. // All options that belong to this option space will be sent // as sub-options of this option. Empty string means that this // option doesn't encapsulate any option. "encapsulate": "", // Option name. "name": "my-option", // Specifies the types of fields within the option if the option // is said to be a "record" (see "type"). in this particular example // this option comprises two fields, 1 byte and 2 bytes long. "record-types": "uint8, uint16", // Name of the option space to which this option belongs. "space": "my-space", // Option type. All possible types are listed in the Kea // Administrator Reference Manual. "type": "record" } ], // Global (default) value of the preferred lifetime. "preferred-lifetime": 50, // Global min value of the preferred lifetime. "min-preferred-lifetime": 40, // Global max value of the preferred lifetime. "max-preferred-lifetime": 60, // Global value for the rebind timer, i.e. the time after which the // DHCP client enters rebind state if it fails to renew the lease. "rebind-timer": 40, // List of relay supplied option codes. See RFC 6422. "relay-supplied-options": [ "110", "120", "130" ], // Global value for the renew timer, i.e. the timer after which the // DHCP client renews the lease. "renew-timer": 30, // Governs how the Kea DHCPv6 server should deal with the invalid // data received from the client. "sanity-checks": { // Specifies how the Kea DHCPv6 server should behave when invalid // data is read for a lease from the lease file. The following // values are supported "none" (don't attempt to correct the // lease information), "warn" (print a warning for subnet-id // related inconsistencies), "fix" (correct the subnet id by // trying to find the suitable subnet), "fix-del" (similar // to "fix" but delete the lease if no suitable subnet found), // "del" (delete the lease if the lease has invalid subnet // identifier value). "lease-checks": "warn" }, // Custom DUID used by the DHCPv6 server. "server-id": { // Type of the DUID. Possible values are "LLT", "EN", and "LL". "type": "EN", // Enterprise id used for "EN" duid. "enterprise-id": 2495, // Identifier part of the DUID. "identifier": "0123456789", // Boolean flag indicating if the DUID should be persisted on // disk. "persist": false }, // List of shared networks used by Kea DHCPv6 server. The shared // networks group subnets together. "shared-networks": [ { // Restricts this shared network to allow only clients // that belong to the particular client class. If an // empty string is provided, no restriction is applied. "client-class": "", // Specifies that this shared network is selected for the // requests received on the particular interface. "interface": "ethX", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to // which the response is sent. "interface-id": "", // Shared network name. "name": "my-secret-network", // List of shared network specific DHCP options. "option-data": [], // Shared network specific (default) preferred lifetime. "preferred-lifetime": 2000, // Shared network specific min preferred lifetime. "min-preferred-lifetime": 1500, // Shared network specific ma xpreferred lifetime. "max-preferred-lifetime": 2500, // Boolen flag indicating if the server can respond to // a Solicit message including a Rapid Commit option with // the Reply message (See DHCPv6 rapid commit). "rapid-commit": false, // List of IPv6 relay addresses for which this shared // network is selected. "relay": { "ip-addresses": [] }, // Shared network level rebind timer. "rebind-timer": 41, // Shared network level renew timer. "renew-timer": 31, // Shared network level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // List of client classes which must be evaluated when this shared // network is selected for client assignments. "require-client-classes": [ "late" ], // List of IPv6 subnets belonging to this shared network. "subnet6": [ { // Restricts this subnet to allow only clients that belong // to the particular client class. If an empty string is // provided, no restriction is applied. "client-class": "", // Subnet unique identifier. "id": 1, // Specifies that this subnet is selected for the requests // received on the particular interface. "interface": "ethX", // Specifies the content of the interface-id option used // by relays to identify the interface on the relay to // which the response is sent. "interface-id": "", // Subnet level list of DHCP options. "option-data": [ { // Boolean flag indicating if the particular option // should be always sent or sent only when requested. "always-send": false, // Option code. "code": 7, // Boolean flag indicating if the option value specified // in "data" is a string of hexadecimal values or human // readable CSV value. "csv-format": false, // Option data to be included in the option payload. "data": "0xf0", // Option name. "name": "preference", // Option space. The default value "dhcp6" designates the // top level option space. "space": "dhcp6" } ], // List of pools from which delegated prefixes are assigned to the // clients. "pd-pools": [ { // Restricts this prefix pool to be used only for the client // requests belonging to a particular client class. "client-class": "phones_server1", // Length of prefixes delegated to clients. "delegated-len": 64, // Excluded prefix (address) from client assignments. "excluded-prefix": "2001:db8::", // Excluded prefix (length) from client assignments. "excluded-prefix-len": 48, // Prefix pool level list of DHCP options. "option-data": [], // Prefix range (address) used for client assignments. "prefix": "2001:db8::", // Prefix range (length) used for client assignments. "prefix-len": 40, // List of client classes which must be evaluated // when this prefix pool is selected for client assignments. "require-client-classes": [] } ], "pools": [ { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server1", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "2001:db8:0:1::/64", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [ "late" ] }, { // Restricts this pool to be only used for the client // requests belonging to a particular client class. "client-class": "phones_server2", // Pool level list of DHCP options. "option-data": [], // Address range used for client assignments. "pool": "2001:db8:0:3::/64", // List of client classes which must be evaluated when this pool // is selected for client assignments. "require-client-classes": [] } ], // Subnet specific (default) preferred lifetime. "preferred-lifetime": 2000, // Subnet specific min preferred lifetime. "min-preferred-lifetime": 1500, // Subnet specific max referred lifetime. "max-preferred-lifetime": 2500, // Boolen flag indicating if the server can respond to // a Solicit message including a Rapid Commit option with // the Reply message (See DHCPv6 rapid commit). "rapid-commit": false, // Subnet level rebind timer. "rebind-timer": 40, // List of IPv4 relay addresses for which this subnet // is selected. "relay": { "ip-addresses": [ "2001:db8:0:f::1" ] }, // Subnet level renew timer. "renew-timer": 30, // Enumeration specifying server's mode of operation when it // fetches host reservations. "reservation-mode": "all", // Subnet level compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // List of static IPv6 reservations assigned to the clients belonging // to this subnet. For detailed example see reservations.json. "reservations": [ { // Identifier used for client matching. Supported values are // "duid", "hw-address" and "flex-id". "duid": "01:02:03:04:05:06:07:08:09:0A", // List of reserved IPv6 addresses. "ip-addresses": [ "2001:db8:1:cafe::1" ], // List of reserved IPv6 prefixes. "prefixes": [ "2001:db8:2:abcd::/64" ], // Reserved hostname. "hostname": "foo.example.com", // Reservation specific option data. "option-data": [ { // Option name. "name": "vendor-opts", // Option value. "data": "4491" } ] } ], // List of client classes which must be evaluated when this subnet // is selected for client assignments. "require-client-classes": [ "late" ], // Subnet prefix. "subnet": "2001:db8::/32", // Subnet level (default) valid lifetime. "valid-lifetime": 6000, // Subnet level min valid lifetime. "min-valid-lifetime": 4000, // Subnet level max valid lifetime. "max-valid-lifetime": 8000 } ], // Shared network level (default) valid lifetime. "valid-lifetime": 6001, // Shared network level min valid lifetime. "min-valid-lifetime": 4001, // Shared network level max valid lifetime. "max-valid-lifetime": 8001 } ], // List of IPv6 subnets which don't belong to any shared network. "subnet6": [], // Global (default) valid lifetime value. "valid-lifetime": 6000, // Global min valid lifetime value. "min-valid-lifetime": 4000, // Global max valid lifetime value. "max-valid-lifetime": 8000, // Reservations (examples are in other files). "reservations": [], // Configuration control (currently not used, i.e. this syntax // is already defined but corresponding feature is not implemented). "config-control": { // Only configuration databases entry is defined. "config-databases": [ { // Name of the database to connect to. "name": "config", // Type of the database, e.g. "mysql", "postgresql", "cql". "type": "mysql" } ], // Intervals between attempts to fetch configuration updates // via the configuration backends used. "config-fetch-wait-time": 30 }, // Server tag. "server-tag": "my DHCPv6 server", // DHCP queue control parameters. "dhcp-queue-control": { // Enable queue is mandatory. "enable-queue": true, // Queue type was mandatory. "queue-type": "kea-ring6" }, // Fetches host reservations. "reservation-mode": "all", // Data directory. "data-directory": "/tmp", // Global compute T1 and T2 timers. "calculate-tee-times": true, // T1 = valid lifetime * .5. "t1-percent": .5, // T2 = valid lifetime * .75. "t2-percent": .75, // String of zero or more characters with which to replace each // invalid character in the hostname or Client FQDN. The default // value is an empty string which will cause invalid characters // to be omitted rather than replaced. "hostname-char-replacement": "x", // Regular expression describing the invalid character set in // the hostname or Client FQDN. "hostname-char-set": "[^A-Za-z0-9.-]", // List of loggers used by the servers using this configuration file. "loggers": [ { // Debug level, a value between 0..99. The greater the value // the more detailed debug log. "debuglevel": 99, // Name of the logger. "name": "kea-dhcp6", // Configures how the log should be output. "output_options": [ { // Determines whether the log should flushed to a file. "flush": true, // Specifies maximum filesize before the file is being rotated. "maxsize": 10240000, // Specifies the maximum number of rotated files being kept. "maxver": 1, // Specifies logging destination. "output": "stdout" } ], // Specifies logging severity, i.e. "ERROR", "WARN", "INFO", "DEBUG". "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/duid.json0000644000175000017500000000517413623761160014246 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It demonstrates how to configure Kea to use DUID-LLT with some // values specified explicitly. { "Dhcp6": { // Configure server identifier (DUID-LLT). The hexadecimal value of the // identifier will be used as link layer address component of the DUID. // The link layer type will be ethernet. The value of time is set to 0 // which indicates that the server must generate this value, i.e. use // current time. Note that it is easy to move from this configuration // to DUID-EN or DUID-LL. It would require changing the "type" value // to "EN" or "LL" respectively. The "identifier" would hold a // DUID-EN variable length identifier or DUID-LL link layer address. // The values of "time" and "htype" would be ignored for DUID-EN. // If one wanted to use a non-default enterprise-id for DUID-EN, the // "enterprise-id" parameter would need to be added. Note that only // a "type" parameter is mandatory while specifying "server-id" map. "server-id": { "type": "LLT", "identifier": "12C4D5AF870C", "time": 0, "htype": 1 }, // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // The following configures logging. It assumes that messages with at least // informational level (info, warn, error) will will be logged to stdout. "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "stdout" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/classify2.json0000644000175000017500000001036313623761160015214 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // The purpose of this example is to showcase how clients can be classified. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Let's use the simplest backend: memfile and use some reasonable values // for timers. They are of no concern for the classification demonstration. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, "renew-timer": 1000, "rebind-timer": 2000, "preferred-lifetime": 3000, "valid-lifetime": 4000, // This list defines several classes that incoming packets can be assigned to. // One packet can belong to zero or more classes. "client-classes": [ // This class is required by the second subnet and is evaluated only // if it is required. The test expression returns true. // Note it is not possible to depend on cable-modems class because it // is not yet defined. { "name": "second_subnet", "only-if-required": true, "test": "member('ALL')", "option-data": [{ "name": "dns-servers", "data": "2001:db8::1" }] }, // Let's classify all incoming RENEW (message type 5) to a separate // class. { "name": "renews", "test": "pkt6.msgtype == 5" }, // Let's pick cable modems. In this simple example we'll assume the device // is a cable modem if it sends a vendor option with enterprise-id equal // to 4491. { "name": "cable-modems", "test": "vendor.enterprise == 4491" }, // Both a cable modem (by evaluation or host reservation) and has a host // reservation. { "name": "cable-modem-hosts", "test": "member('cable-modems') and member('KNOWN')" } ], // The following list defines subnets. Each subnet consists of at // least subnet and pool entries. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "client-class": "cable-modems", "interface": "ethX" }, // The following subnet contains a class reservation for a client using // DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned // to this class. { "pools": [ { "pool": "2001:db8:2::/80" } ], "subnet": "2001:db8:2::/64", "reservations": [ { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "client-classes": [ "cable-modems" ] } ], "interface": "ethX", "require-client-classes": [ "second_subnet" ] }, // The following subnet contains a pool with a class constraint: only // clients which belong to the class are allowed to use this pool. { "pools": [ { "pool": "2001:db8:3::/80", "client-class": "cable-modems" } ], "subnet": "2001:db8:4::/64", "interface": "ethY" }, // This subnet is divided in two pools for unknown and known // (i.e. which have a reservation) clients. The built-in KNOWN and // UNKNOWN classes are set or not at host reservation lookup (KNOWN if // this returns something, UNKNOWN if this finds nothing) and client //classes depending on it are evaluated. // This happens after subnet selection and before address allocation //from pools. { "pools": [ { "pool": "2001:db8:8::/64", "client-class": "UNKNOWN" }, { "pool": "2001:db8:9::/64", "client-class": "KNOWN" } ], "subnet": "2001:db8:8::/46", "reservations": [ { "hw-address": "00:00:00:11:22:33", "hostname": "h1" }, { "hw-address": "00:00:00:44:55:66", "hostname": "h4" }, { "hw-address": "00:00:00:77:88:99", "hostname": "h7" }, { "hw-address": "00:00:00:aa:bb:cc", "hostname": "ha" } ] } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/global-reservations.json0000644000175000017500000001341113623761160017274 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // It demonstrates how global host reservations can be configured. // The global reservations are not associated with any subnet. They // are assigned regardless of the subnet to which the DHCP client belongs. // Global reservations are assigned to the DHCP clients using the // same host identifier types as subnet specific reservations. This file // contains multiple examples of host reservations using different // identifier types, e.g. DUID, MAC address etc. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile", "lfc-interval": 3600 }, // This is pretty basic stuff, it has nothing to do with reservations. "preferred-lifetime": 3000, "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // Kea supports three types of identifiers in DHCPv6: hw-address (hardware/MAC // address of the client), duid (DUID inserted by the client) and flex-id // (flexible identifier available when flex_id hook library is loaded) When told // to do so, Kea can check for each of these identifier types, but it takes a // costly database lookup to do so. It is therefore useful from a performance // perspective to use only the reservation types that are actually used in a // given network. "host-reservation-identifiers": [ "duid", "hw-address", "flex-id" ], // This directive tells Kea that reservations are global. Note that this // can also be specified at shared network and/or subnet level. "reservation-mode": "global", // Define several global host reservations. "reservations": [ // This is a simple host reservation. The host with DUID matching // the specified value will get an address of 2001:db8:1::100. // Note it is not recommended but still allowed to reverse addresses at // the global scope: as it breaks the link between the reservation and // the subnet it can lead to a client localized in another subnet than // its address belongs to. { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "ip-addresses": [ "2001:db8:1::100" ] }, // This is similar to the previous one, but this time the reservation // is done based on hardware/MAC address. The server will do its best to // extract the hardware/MAC address from received packets (see // 'mac-sources' directive for details). This particular reservation // also specifies two extra options to be available for this client. If // there are options with the same code specified in a global, subnet or // class scope, the values defined at host level take precedence for // this particular DHCP client. { "hw-address": "00:01:02:03:04:05", "ip-addresses": [ "2001:db8:1::101" ], "option-data": [ { "name": "dns-servers", "data": "3000:1::234" }, { "name": "nis-servers", "data": "3000:1::234" } ], "client-classes": [ "special_snowflake", "office" ] }, // This is a bit more advanced reservation. The client with the specified // DUID will get a reserved address, a reserved prefix and a hostname. // At least one of the three must be specified in a reservation. // Finally, this reservation features vendor specific options for CableLabs, // which happen to use enterprise-id 4491. Those particular values will // be returned only to the client that has a DUID matching this reservation. { "duid": "01:02:03:04:05:06:07:08:09:0A", "ip-addresses": [ "2001:db8:1:cafe::1" ], "prefixes": [ "2001:db8:2:abcd::/64" ], "hostname": "foo.example.com", "option-data": [ { "name": "vendor-opts", "data": "4491" }, { "name": "tftp-servers", "space": "vendor-4491", "data": "3000:1::234" } ] }, // 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": "'somevalue'", "ip-addresses": [ "2001:db8:1:cafe::2" ] } ], // The following list defines subnets. Subnet, pools and interface definitions // are the same as in the regular scenario. "subnet6": [ { "subnet": "2001:db8::/47", "pools": [ { "pool": "2001:db8::/64" } ], "pd-pools": [ { "prefix": "2001:db8:1:8000::", "prefix-len": 56, "delegated-len": 64 } ], "interface": "ethX" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/advanced.json0000644000175000017500000002031213623761160015055 00000000000000// 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 ethX 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 ethX network interface only. "interfaces-config": { "interfaces": [ "ethX" ], // This makes interfaces to be re-detected at each (re-)configuration. // By default it is true. "re-detect": true }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, 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 findind 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": "/tmp/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:1234::", "excluded-prefix-len": 62, // 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 "subnet": "2001:db8:1::/64", "interface": "ethX", // 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-address": "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 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/pgsql-reservations.json0000644000175000017500000000644213623761160017170 00000000000000// This is an example configuration file for the DHCPv6 server in Kea. // It contains configuration of the PostgreSQL host database backend, used // to retrieve reserved addresses, host names, DHCPv4 message fields // and DHCP options from PostgreSQL database. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // This is pretty basic stuff, it has nothing to do with reservations. "preferred-lifetime": 3000, "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // Kea supports two types of identifiers in DHCPv6: hw-address // (hardware/MAC address of the client) and duid (DUID inserted by the // client). When told to do so, Kea can check for each of these // identifier types, but it takes a costly database lookup to do so. It // is therefore useful from a performance perspective to use only the // reservation types that are actually used in a given network. "host-reservation-identifiers": [ "duid", "hw-address" ], // Specify connection to the database holding host reservations. The type // specifies that the PostgreSQL database is used. user and password are the // credentials used to connect to the database. host and name specify // location of the host where the database instance is running, and the // name of the database to use. The server processing a packet will first // check if there are any reservations specified for this client in the // reservations list, within the subnet (configuration file). If there are // no reservations there, the server will try to retrieve reservations // from this database. // The database specification can go into one hosts-database entry for // backward compatibility or be listed in hosts-databases list. "hosts-databases": [ { "type": "postgresql", "name": "kea", "user": "kea", "password": "kea", "host": "localhost" } ], // Define a subnet with a pool of dynamic addresses and a pool of dynamic // prefixes. Addresses and prefixes from those pools will be assigned to // clients which don't have reservations in the database. Subnet identifier // is equal to 1. If this subnet is selected for the client, this subnet // id will be used to search for the reservations within the database. "subnet6": [ { "subnet": "2001:db8:1::/48", "pools": [ { "pool": "2001:db8:1::/80" } ], "pd-pools": [ { "prefix": "2001:db8:1:8000::", "prefix-len": 56, "delegated-len": 64 } ], "interface": "ethX", "id": 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/kea6/hooks.json0000644000175000017500000000260113623761160014434 00000000000000// This is an example configuration file for the DHCPv6 server in Kea // illustrating the configuration of hooks libraries. It uses a basic scenario // of one IPv6 subnet configured with the default values for all parameters. {"Dhcp6": { // Kea is told to listen on the ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // Set up the storage for leases. "lease-database": { "type": "memfile" }, // Set values to mandatory timers "renew-timer": 900, "rebind-timer": 1200, "preferred-lifetime": 1800, "valid-lifetime": 2700, // Define a single subnet. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80", "user-context": { "charging": true } } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // Set up the hooks libraries. For this example, we assume that two libraries // are loaded, called "security" and "charging". Note that order is important: // "security" is specified first so if both libraries supply a hook function // for a given hook, the function in "security" will be called before that in // "charging". "hooks-libraries": [ { "library": "/opt/lib/security.so" }, { "library": "/opt/lib/charging.so", "parameters": { "path": "/var/lib/kea", "base-name": "kea-forensic6" } } ] } } kea-1.6.2/doc/examples/kea6/leases-expiration.json0000644000175000017500000000530313623761160016747 00000000000000// This is an example configuration file for DHCPv6 server in Kea. // It provides parameters controlling processing of expired leases, // a.k.a. leases reclamation. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. // Note, we're setting the maximum number of row read errors to 100, // (defaults to 0, meaning unlimited). "lease-database": { "type": "memfile", "lfc-interval": 3600, "max-row-errors": 100 }, // The following parameters control processing expired leases. Expired leases // will be reclaimed periodically according to the "reclaim-timer-wait-time" // parameter. Reclaimed leases will be held in the database for 1800s to // facilitate lease affinity. After this period the leases will be removed. // The frequency of removal is controlled by the // "flush-reclaimed-timer-wait-time" parameter. The lease reclamation // routine will process at most 500 leases or will last for at most // 100ms, during a single run. If there are still some unreclaimed // leases after 10 attempts, a warning message is issued. "expired-leases-processing": { "reclaim-timer-wait-time": 5, "hold-reclaimed-time": 1800, "flush-reclaimed-timer-wait-time": 10, "max-reclaim-leases": 500, "max-reclaim-time": 100, "unwarned-reclaim-cycles": 10 }, // 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. "subnet6": [ { "pools": [ { "pool": "2001:db8:1::/80" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ], // 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" } ], "debuglevel": 0, "severity": "INFO" } ] } } kea-1.6.2/doc/examples/agent/0000755000175000017500000000000013623761246012754 500000000000000kea-1.6.2/doc/examples/agent/comments.json0000644000175000017500000000146613623761160015416 00000000000000// This is a example of a configuration for Control-Agent (CA) or simply Agent. // It uses embedded (i.e., which will be included in configuration objects // and not stripped by at lexical analysis) comments. { "Control-agent": { // Global scope "comment": "A Control Agent", "http-host": "127.0.0.1", "http-port": 8000, // In control socket "control-sockets": { "dhcp4": { "comment": "control socket for DHCP4 server", "socket-type": "unix", "socket-name": "/path/to/the/unix/socket-v4" } }, // In loggers "loggers": [ { "comment": "A logger", "name": "kea-ctrl-agent" } ] } } kea-1.6.2/doc/examples/agent/simple.json0000644000175000017500000001007013623761160015051 00000000000000// This is a simple example of a configuration for Control-Agent (CA) or simply // Agent. This server provides RESTful interface for all Kea servers. { "Control-agent": { // We need to specify where the agent should listen to incoming HTTP // queries. Note that agent does not provide SSL or TLS protection // on its own, so limiting the traffic to localhost is a good idea. "http-host": "127.0.0.1", // Another mandatory parameter is the HTTP port. "http-port": 8000, // This map specifies where control channel of each server is configured // to listen on. See 'control-socket' object in the respective // servers. At this time the only supported socket type is "unix". // Make sure that the Agent and respective servers configuration // matches exactly, otherwise they won't be able to communicate. // One extra feature that requires some explanation is // user-context. This is a structure that you can define at // global scope, in control sockets and others. It is parsed by // Kea, but not used directly. It is intended to keep anything // you may want to put there - comments, extra designations, // floor or department names etc. These structures will be made // available to Kea hooks. A comment entry is translated into a // user-context with a "comment" property so you can include // comments inside the configuration itself. "control-sockets": { // This is how the Agent can communicate with the DHCPv4 server. "dhcp4": { "comment": "socket to DHCP4 server", "socket-type": "unix", "socket-name": "/path/to/the/unix/socket-v4" }, // Location of the DHCPv6 command channel socket. "dhcp6": { "socket-type": "unix", "socket-name": "/path/to/the/unix/socket-v6" }, // Location of the D2 command channel socket. "d2": { "socket-type": "unix", "socket-name": "/path/to/the/unix/socket-d2", "user-context": { "in-use": false } } }, // CA is able to load hook libraries that augment its operation. // The primary functionality is the ability to add new commands. "hooks-libraries": [ // Hook libraries list may contain more than one library. { // The only necessary parameter is the library filename. "library": "/opt/local/control-agent-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, CA also uses logging. "loggers": [ { "name": "kea-ctrl-agent", "output_options": [ { "output": "/var/log/kea-ctrl-agent.log", // 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" } ], "severity": "INFO", "debuglevel": 0 } ] } } kea-1.6.2/doc/devel/0000755000175000017500000000000013623761246011137 500000000000000kea-1.6.2/doc/devel/Makefile.am0000644000175000017500000000120213623761160013101 00000000000000EXTRA_DIST = EXTRA_DIST += Doxyfile Doxyfile-xml EXTRA_DIST += bison.dox EXTRA_DIST += config-backend.dox EXTRA_DIST += contribute.dox EXTRA_DIST += mainpage.dox EXTRA_DIST += terminology.dox EXTRA_DIST += unit-tests.dox EXTRA_DIST += doc.dox EXTRA_DIST += congestion-handling.dox all: # do nothing, used only by developers manually devel: mkdir -p $(builddir)/html (cat $(srcdir)/Doxyfile; echo PROJECT_NUMBER=$(PACKAGE_VERSION)) | doxygen - > $(builddir)/html/doxygen.log 2> $(builddir)/html/doxygen-error.log echo `grep -i ": warning:" $(builddir)/html/doxygen-error.log | wc -l` warnings/errors detected. clean-local: rm -rf html kea-1.6.2/doc/devel/Doxyfile-xml0000644000175000017500000000034213623761160013355 00000000000000# This is a doxygen configuration for generating XML output as well as HTML. # # Inherit everything from our default Doxyfile except GENERATE_XML, which # will be reset to YES @INCLUDE = Doxyfile GENERATE_XML = YES kea-1.6.2/doc/devel/unit-tests.dox0000644000175000017500000002704413623761160013714 00000000000000// Copyright (C) 2015-2019 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. /** @page unitTests Building Kea with Unit Tests Depending on how you compiled or installed \c gtest (e.g. from sources or using some package management system) one of those two switches will find \c gtest. After that you make and run the unit-tests with: @code make check @endcode @section unitTestsEnvironmentVariables Environment Variables The following environment variable can affect the unit tests: - KEA_LOCKFILE_DIR - Specifies a directory where the logging system should create its lock file. If not specified, it is prefix/var/run/kea, where prefix defaults to /usr/local. This variable must not end with a slash. There is one special value, "none", which instructs Kea to not create a lock file at all. This may cause issues if several processes log to the same file. (Also see the Kea User's Guide, section 15.3.) - KEA_LOGGER_DESTINATION - Specifies the logging destination. If not set, logged messages will not be recorded anywhere. There are three special values: stdout, stderr and syslog. Any other value is interpreted as a filename. (Also see Kea User's Guide, section 15.3.) - KEA_PIDFILE_DIR - Specifies the directory which should be used for PID files as used by dhcp::Daemon or its derivatives. If not specified, the default is prefix/var/run/kea, where prefix defaults to /usr/local. This variable must not end with a slash. - KEA_SOCKET_TEST_DIR - if set, it specifies the directory where Unix sockets are created. There is an operating system limitation on how long a Unix socket path can be, typically slightly over 100 characters. By default unit-tests create sockets in temporary folder under /tmp folder. KEA_SOCKET_TEST_DIR can be specified to instruct unit-tests to use a different directory. It must not end with slash. - KEA_TEST_DB_WIPE_DATA_ONLY - Unit tests which use a Kea unit test database take steps to ensure they are starting with an empty database of the correct schema version. The first step taken is to simply delete the transient data (such as leases, reservations, etc..), provided the schema exists and is the expected version. If the schema does not exist, is not the expected version, or for some reason the data wipe fails, the schema will be dropped and recreated. Setting this value to "false" will cause the test setup logic to always drop and create the database schema. The default value is "true". @note Setting KEA_TEST_DB_WIPE_DATA_ONLY to false may dramatically increase the time it takes each unit test to execute. @section unitTestsDatabaseConfig Databases Configuration for Unit Tests With the use of databases requiring separate authorisation, there are certain database-specific pre-requisites for successfully running the unit tests. These are listed in the following sections. @subsection unitTestsDatabaseUsers Database Users Required for Unit Tests Unit tests validating database backends require that the keatest database is created. This database should be empty. The unit tests also require that the keatest user is created and that this user is configured to access the database with a password of keatest. Unit tests use these credentials to create database schema, run test cases and drop the schema. Thus, the keatest user must have sufficiently high privileges to create and drop tables, as well as insert and modify the data within those tables. The database backends which support read only access to the host reservations databases (currently MySQL and PostgreSQL) include unit tests verifying that a database user with read-only privileges can be used to retrieve host reservations. Those tests require another user, keatest_readonly, with SQL SELECT privilege to the keatest database (i.e. without INSERT, UPDATE etc.), is also created. keatest_readonly should also have the password keatest. The following sections provide step-by-step guidelines how to setup the databases for running unit tests. @subsection mysqlUnitTestsPrerequisites MySQL Database The steps to create the database and users are: -# Log into MySQL as root: @verbatim % mysql -u root -p Enter password: : mysql>@endverbatim\n -# Create the test database. This must be called "keatest": @verbatim mysql> CREATE DATABASE keatest; mysql>@endverbatim\n -# Create the users under which the test client will connect to the database (the apostrophes around the words keatest, keatest_readonly, and localhost are required): @verbatim mysql> CREATE USER 'keatest'@'localhost' IDENTIFIED BY 'keatest'; mysql> CREATE USER 'keatest_readonly'@'localhost' IDENTIFIED BY 'keatest'; mysql>@endverbatim\n -# Grant the created users permissions to access the keatest database (again, the apostrophes around the user names and localhost are required): @verbatim mysql> GRANT ALL ON keatest.* TO 'keatest'@'localhost'; mysql> GRANT SELECT ON keatest.* TO 'keatest_readonly'@'localhost'; mysql>@endverbatim\n -# If you get You do not have the SUPER privilege and binary logging is enabled error message, you need to add: @verbatim mysql> SET GLOBAL LOG_BIN_TRUST_FUNCTION_CREATORS = 1; mysql>@endverbatim\n -# Exit MySQL: @verbatim mysql> quit Bye %@endverbatim The unit tests are run automatically when "make check" is executed (providing that Kea has been build with the \c --with-mysql switch (see the installation section in the Kea Administrator Reference Manual). @subsection pgsqlUnitTestsPrerequisites PostgreSQL Database PostgreSQL set up differs from system to system. Please consult your operating system-specific PostgreSQL documentation. The remainder of that section uses Ubuntu 13.10 x64 (with PostgreSQL 9.0+) as an example. On Ubuntu, PostgreSQL is installed (with sudo apt-get install postgresql) under user postgres. To create new databases or add new users, initial commands must be issued under this username: @verbatim $ sudo -u postgres psql postgres [sudo] password for thomson: psql (9.1.12) Type "help" for help. postgres=# CREATE USER keatest WITH PASSWORD 'keatest'; CREATE ROLE postgres=# CREATE DATABASE keatest; CREATE DATABASE postgres=# GRANT ALL PRIVILEGES ON DATABASE keatest TO keatest; GRANT postgres=# \q @endverbatim PostgreSQL versions earlier than 9.0 don't provide an SQL statement for granting privileges on all tables in a database. In newer PostgreSQL versions, it is possible to grant specific privileges on all tables within a schema. However, this only affects tables which exist when the privileges are granted. To ensure that the user has specific privileges to tables dynamically created by the unit tests, the default schema privileges must be altered. The following example demonstrates how to create the user keatest_readonly, which has SELECT privilege to the tables within the keatest database, in Postgres 9.0+. For earlier versions of Postgres, it is recommended to simply grant full privileges to keatest_readonly, using the same steps as for the keatest user. @verbatim $ psql -U postgres Password for user postgres: psql (9.1.12) Type "help" for help. postgres=# CREATE USER keatest_readonly WITH PASSWORD 'keatest'; CREATE ROLE postgres=# \q $ psql -U keatest Password for user keatest: psql (9.1.12) Type "help" for help. keatest=> ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES to keatest_readonly; ALTER DEFAULT PRIVILEGES keatest=> \q @endverbatim Note that the keatest user (rather than postgres) is used to grant privileges to the keatest_readonly user. This ensures that the SELECT privilege is granted only on the tables that the keatest user can access within the public schema. It seems this no longer works on recent versions of PostgreSQL: if you get a permission problem on SELECT on the schema_version table for eatest_readonly, please try with the schema loaded: @verbatim $ psql -h localhost -U keatest -d keatest Password for user keatest: psql (11.3 (Debian 11.3-1)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) Type "help" for help. keatest=> GRANT SELECT ON ALL TABLES IN SCHEMA public TO keatest_readonly; GRANT keatest=> \q @endverbatim Now we should be able to log into the newly created database using both user names: @verbatim $ psql -d keatest -U keatest Password for user keatest: psql (9.1.12) Type "help" for help. keatest=> \q $ psql -d keatest -U keatest_readonly Password for user keatest_readonly: psql (9.1.12) Type "help" for help. keatest=> @endverbatim If instead of seeing keatest=> prompt, your login is refused with an error code about failed peer or indent authentication, it means that PostgreSQL is configured to check unix username and reject login attempts if PostgreSQL names are different. To alter that, the PostgreSQL configuration must be changed - the /etc/postgresql/9.1/main/pg_hba.conf config file has to be altered. (It may be in a different location in your system.) The following lines: @verbatim local all all peer host all all 127.0.0.1/32 md5 host all all ::1/128 md5 @endverbatim need to be replaced with: @verbatim local all all password host all all 127.0.0.1/32 password host all all ::1/128 password @endverbatim Another possible problem is that you get no password prompt. This is most probably because you have no pg_hba.conf config file and everybody is by default trusted. As it has a very bad effect on the security you should have been warned this is a highly unsafe configuration. The solution is the same, i.e., require password or md5 authentication method. If you lose the postgres user access you can first add: @verbatim local all postgres trust @endverbatim to trust only the local postgres user. Note the postgres user can be pgsql on some systems. Please consult your PostgreSQL user manual before applying those changes as those changes may expose your other databases that you run on the same system. In general case, it is a poor idea to run anything of value on a system that runs tests. Use caution! The unit tests are run automatically when "make check" is executed (providing that Kea has been build with the \c --with-pgsql switch (see the installation section in the Kea Administrator Reference Manual). @subsection cqlUnitTestsPrerequisites Cassandra database @todo: Describe steps necessary to set up Cassandra database suitable for running unittests. It seems this was enough: -# Launch cassandra if not running (-f for foreground) @verbatim % cassandra -f @endverbatim The tool is cqlsh: -# Run the tool @verbatim % cqlsh Connected to Test Cluster at 127.0.0.1:9042. [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4] Use HELP for help. cqlsh> @endverbatim\n */ kea-1.6.2/doc/devel/doc.dox0000644000175000017500000000601113623761160012331 00000000000000// Copyright (C) 2018-2019 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. /** @page docs Building Kea Documentation There are several types of documentation for Kea. The primary one, intended to be read by users, is User's Guide. It comes in HTML, PDF and txt format. All of them generated from the same sources. To generate this doc, you need to run configure script with --enable-generate-docs option. Several tools have to be present in the system: docbook environment, links and several others. You can generate this by doing: @code $ ./configure --enable-generate-docs $ cd doc/ $ make guide @endcode The output files will be generated in doc/guide/ directory. Since Kea 1.5, this doc has appendix A that lists all Kea commands. That appendix is generated using a small tool called docgen. The basic principle is that for every command there is a JSON file that briefly describes the major aspects of the new command, such as name, short description, expected syntax, expected response, a hook that needs to be loaded, first Kea version where it appeared, etc. Those JSON files are loaded by docgen tool that will generate api.xml that will be used by make guide. There is no need to generate this, unless you alter description of existing commands or add a new one. @section docsNewCommand Documenting new command There are several steps needed to document a new API command: 1. Configure sources with ./configure --enable-generate-docs 1. Copy doc/sphinx/api/_template.json to appropriate name. 2. Remove comments from it and fill in the actual content. 3. Update api_files variable in doc/sphinx/Makefile.am 4. make html will generate multi-page html. 5. make singlehtml will generate a single page html. A word of caution regaring editing JSON files. The files themselves need to be valid JSON files. They also often contain fields, such as command syntax or command response, there are themselves a JSON or JSON like structures. That means that some trickery with escaping double quotes will be involved. Note there is no need to escape any other character, unless you want to specify non-printable characters. Also, while Kea's JSON parser supports comments and multi-line string, they are not part of JSON standard. That means that external tools, such as python or Sphinx parsers are not able to deal with them. Therefore comments must be removed and long strings (such as command descriptions or example invocations) are to be presented as a list of strings ( e.g. [ "line1", "line2, "line3" ]). @section docsDevelGuide Generating Developer's Guide Generating Developer's Guide is very simple, although you need to have doxygen installed in your system. If you also have graphviz installed, it will generate nice diagrams. To generate developer's guide, do the following commands: @code $ ./configure $ cd doc/devel $ make devel @endcode */kea-1.6.2/doc/devel/terminology.dox0000644000175000017500000000242013623761160014134 00000000000000// Copyright (C) 2017 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. /** @page terminology Terminology This page explains some common abbreviations and terms: - CA - Control Agent. That's a separate module that talks with Kea DHCPv4, DHCPv6 (and soon also D2) over control channel and exposes their internal commands using RESTful interface. - D2 - This is a nickname of DHCP-Dynamic DNS server module. Since using the full name is awkward, we often use shortened version of it: D2. - DHCP - Dynamic Host Configuration Protocol. There are two similar, but operationally different protocols: DHCPv4 and DHCPv6. When v4 or v6 is not specified, the DHCP expression applies to both. - DHCPv4 - Dynamic Host Configuration Protocol for IPv4, a protocol that defines how IPv4 hosts can obtain IPv4 addresses and other configuration from the servers. Defined in RFC2131. - DHCPv6 - Dynamic Host Configuration Protocol for IPv6, a protocol that defines how IPv6 hosts and router can obtain IPv6 addresses, IPv6 prefixes and other configuration from the servers. Defined in RFC3315. */ kea-1.6.2/doc/devel/Makefile.in0000644000175000017500000003573713623761177013146 00000000000000# Makefile.in generated by automake 1.15 from Makefile.am. # @configure_input@ # Copyright (C) 1994-2014 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. @SET_MAKE@ VPATH = @srcdir@ am__is_gnu_make = { \ if test -z '$(MAKELEVEL)'; then \ false; \ elif test -n '$(MAKE_HOST)'; then \ true; \ elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \ true; \ else \ false; \ fi; \ } am__make_running_with_option = \ case $${target_option-} in \ ?) ;; \ *) echo "am__make_running_with_option: internal error: invalid" \ "target option '$${target_option-}' specified" >&2; \ exit 1;; \ esac; \ has_opt=no; \ sane_makeflags=$$MAKEFLAGS; \ if $(am__is_gnu_make); then \ sane_makeflags=$$MFLAGS; \ else \ case $$MAKEFLAGS in \ *\\[\ \ ]*) \ bs=\\; \ sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \ | sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \ esac; \ fi; \ skip_next=no; \ strip_trailopt () \ { \ flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \ }; \ for flg in $$sane_makeflags; do \ test $$skip_next = yes && { skip_next=no; continue; }; \ case $$flg in \ *=*|--*) continue;; \ -*I) strip_trailopt 'I'; skip_next=yes;; \ -*I?*) strip_trailopt 'I';; \ -*O) strip_trailopt 'O'; skip_next=yes;; \ -*O?*) strip_trailopt 'O';; \ -*l) strip_trailopt 'l'; skip_next=yes;; \ -*l?*) strip_trailopt 'l';; \ -[dEDm]) skip_next=yes;; \ -[JT]) skip_next=yes;; \ esac; \ case $$flg in \ *$$target_option*) has_opt=yes; break;; \ esac; \ done; \ test $$has_opt = yes am__make_dryrun = (target_option=n; $(am__make_running_with_option)) am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) pkgdatadir = $(datadir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ pkglibdir = $(libdir)/@PACKAGE@ pkglibexecdir = $(libexecdir)/@PACKAGE@ am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd install_sh_DATA = $(install_sh) -c -m 644 install_sh_PROGRAM = $(install_sh) -c install_sh_SCRIPT = $(install_sh) -c INSTALL_HEADER = $(INSTALL_DATA) transform = $(program_transform_name) NORMAL_INSTALL = : PRE_INSTALL = : POST_INSTALL = : NORMAL_UNINSTALL = : PRE_UNINSTALL = : POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ subdir = doc/devel ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/m4macros/ax_boost_for_kea.m4 \ $(top_srcdir)/m4macros/ax_cpp11.m4 \ $(top_srcdir)/m4macros/ax_crypto.m4 \ $(top_srcdir)/m4macros/ax_isc_rpath.m4 \ $(top_srcdir)/m4macros/libtool.m4 \ $(top_srcdir)/m4macros/ltoptions.m4 \ $(top_srcdir)/m4macros/ltsugar.m4 \ $(top_srcdir)/m4macros/ltversion.m4 \ $(top_srcdir)/m4macros/lt~obsolete.m4 \ $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/config.h CONFIG_CLEAN_FILES = CONFIG_CLEAN_VPATH_FILES = AM_V_P = $(am__v_P_@AM_V@) am__v_P_ = $(am__v_P_@AM_DEFAULT_V@) am__v_P_0 = false am__v_P_1 = : AM_V_GEN = $(am__v_GEN_@AM_V@) am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) am__v_GEN_0 = @echo " GEN " $@; am__v_GEN_1 = AM_V_at = $(am__v_at_@AM_V@) am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) am__v_at_0 = @ am__v_at_1 = SOURCES = DIST_SOURCES = am__can_run_installinfo = \ case $$AM_UPDATE_INFO_DIR in \ n|no|NO) false;; \ *) (install-info --version) >/dev/null 2>&1;; \ esac am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) am__DIST_COMMON = $(srcdir)/Makefile.in README DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) ACLOCAL = @ACLOCAL@ AMTAR = @AMTAR@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ AR = @AR@ ASCIIDOC = @ASCIIDOC@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ AWK = @AWK@ BENCHMARK_CPPFLAGS = @BENCHMARK_CPPFLAGS@ BENCHMARK_INCLUDES = @BENCHMARK_INCLUDES@ BENCHMARK_LDADD = @BENCHMARK_LDADD@ BENCHMARK_LDFLAGS = @BENCHMARK_LDFLAGS@ BENCHMARK_SOURCE = @BENCHMARK_SOURCE@ BOOST_INCLUDES = @BOOST_INCLUDES@ BOOST_LIBS = @BOOST_LIBS@ BOTAN1_TOOL = @BOTAN1_TOOL@ BOTAN_TOOL = @BOTAN_TOOL@ CC = @CC@ CCDEPMODE = @CCDEPMODE@ CFLAGS = @CFLAGS@ CONTRIB_DIR = @CONTRIB_DIR@ CPP = @CPP@ CPPFLAGS = @CPPFLAGS@ CQL_CPPFLAGS = @CQL_CPPFLAGS@ CQL_LIBS = @CQL_LIBS@ CRYPTO_CFLAGS = @CRYPTO_CFLAGS@ CRYPTO_INCLUDES = @CRYPTO_INCLUDES@ CRYPTO_LDFLAGS = @CRYPTO_LDFLAGS@ CRYPTO_LIBS = @CRYPTO_LIBS@ CRYPTO_PACKAGE = @CRYPTO_PACKAGE@ CRYPTO_RPATH = @CRYPTO_RPATH@ CXX = @CXX@ CXXCPP = @CXXCPP@ CXXDEPMODE = @CXXDEPMODE@ CXXFLAGS = @CXXFLAGS@ CYGPATH_W = @CYGPATH_W@ DEFS = @DEFS@ DEPDIR = @DEPDIR@ DISTCHECK_BENCHMARK_CONFIGURE_FLAG = @DISTCHECK_BENCHMARK_CONFIGURE_FLAG@ DISTCHECK_BOOST_CONFIGURE_FLAG = @DISTCHECK_BOOST_CONFIGURE_FLAG@ DISTCHECK_CONTRIB_CONFIGURE_FLAG = @DISTCHECK_CONTRIB_CONFIGURE_FLAG@ DISTCHECK_CRYPTO_CONFIGURE_FLAG = @DISTCHECK_CRYPTO_CONFIGURE_FLAG@ DISTCHECK_GTEST_CONFIGURE_FLAG = @DISTCHECK_GTEST_CONFIGURE_FLAG@ DISTCHECK_KEA_SHELL_CONFIGURE_FLAG = @DISTCHECK_KEA_SHELL_CONFIGURE_FLAG@ DISTCHECK_LOG4CPLUS_CONFIGURE_FLAG = @DISTCHECK_LOG4CPLUS_CONFIGURE_FLAG@ DISTCHECK_PERFDHCP_CONFIGURE_FLAG = @DISTCHECK_PERFDHCP_CONFIGURE_FLAG@ DISTCHECK_PREMIUM_CONFIGURE_FLAG = @DISTCHECK_PREMIUM_CONFIGURE_FLAG@ DISTCHECK_SYSREPO_CONFIGURE_FLAG = @DISTCHECK_SYSREPO_CONFIGURE_FLAG@ DLLTOOL = @DLLTOOL@ DSYMUTIL = @DSYMUTIL@ DUMPBIN = @DUMPBIN@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ EGREP = @EGREP@ EXEEXT = @EXEEXT@ FGREP = @FGREP@ GENHTML = @GENHTML@ GREP = @GREP@ GTEST_CONFIG = @GTEST_CONFIG@ GTEST_INCLUDES = @GTEST_INCLUDES@ GTEST_LDADD = @GTEST_LDADD@ GTEST_LDFLAGS = @GTEST_LDFLAGS@ GTEST_SOURCE = @GTEST_SOURCE@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ KEA_CXXFLAGS = @KEA_CXXFLAGS@ KEA_SRCID = @KEA_SRCID@ LCOV = @LCOV@ LD = @LD@ LDFLAGS = @LDFLAGS@ LEX = @LEX@ LEXLIB = @LEXLIB@ LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIPO = @LIPO@ LN_S = @LN_S@ LOG4CPLUS_INCLUDES = @LOG4CPLUS_INCLUDES@ LOG4CPLUS_LIBS = @LOG4CPLUS_LIBS@ LTLIBOBJS = @LTLIBOBJS@ LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@ MAKEINFO = @MAKEINFO@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ MYSQL_CPPFLAGS = @MYSQL_CPPFLAGS@ MYSQL_LIBS = @MYSQL_LIBS@ NM = @NM@ NMEDIT = @NMEDIT@ OBJDUMP = @OBJDUMP@ OBJEXT = @OBJEXT@ OTOOL = @OTOOL@ OTOOL64 = @OTOOL64@ PACKAGE = @PACKAGE@ PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ PACKAGE_NAME = @PACKAGE_NAME@ PACKAGE_STRING = @PACKAGE_STRING@ PACKAGE_TARNAME = @PACKAGE_TARNAME@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ PDFLATEX = @PDFLATEX@ PERL = @PERL@ PGSQL_CPPFLAGS = @PGSQL_CPPFLAGS@ PGSQL_LIBS = @PGSQL_LIBS@ PKGPYTHONDIR = @PKGPYTHONDIR@ PKG_CONFIG = @PKG_CONFIG@ PLANTUML = @PLANTUML@ PREMIUM_DIR = @PREMIUM_DIR@ PYTHON = @PYTHON@ PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@ PYTHON_PLATFORM = @PYTHON_PLATFORM@ PYTHON_PREFIX = @PYTHON_PREFIX@ PYTHON_VERSION = @PYTHON_VERSION@ RANLIB = @RANLIB@ SED = @SED@ SEP = @SEP@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ SPHINXBUILD = @SPHINXBUILD@ STRIP = @STRIP@ SYSREPO_CPPFLAGS = @SYSREPO_CPPFLAGS@ SYSREPO_INCLUDEDIR = @SYSREPO_INCLUDEDIR@ SYSREPO_LIBS = @SYSREPO_LIBS@ SYSREPO_REPO = @SYSREPO_REPO@ USE_LCOV = @USE_LCOV@ VALGRIND = @VALGRIND@ VERSION = @VERSION@ WARNING_GCC_44_STRICT_ALIASING_CFLAG = @WARNING_GCC_44_STRICT_ALIASING_CFLAG@ YACC = @YACC@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ abs_top_builddir = @abs_top_builddir@ abs_top_srcdir = @abs_top_srcdir@ ac_ct_AR = @ac_ct_AR@ ac_ct_CC = @ac_ct_CC@ ac_ct_CXX = @ac_ct_CXX@ ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ am__include = @am__include@ am__leading_dot = @am__leading_dot@ am__quote = @am__quote@ am__tar = @am__tar@ am__untar = @am__untar@ bindir = @bindir@ build = @build@ build_alias = @build_alias@ build_cpu = @build_cpu@ build_os = @build_os@ build_vendor = @build_vendor@ builddir = @builddir@ datadir = @datadir@ datarootdir = @datarootdir@ docdir = @docdir@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ host = @host@ host_alias = @host_alias@ host_cpu = @host_cpu@ host_os = @host_os@ host_vendor = @host_vendor@ htmldir = @htmldir@ includedir = @includedir@ infodir = @infodir@ install_sh = @install_sh@ libdir = @libdir@ libexecdir = @libexecdir@ localedir = @localedir@ localstatedir = @localstatedir@ mandir = @mandir@ mkdir_p = @mkdir_p@ oldincludedir = @oldincludedir@ pdfdir = @pdfdir@ pkgpyexecdir = @pkgpyexecdir@ pkgpythondir = @pkgpythondir@ prefix = @prefix@ program_transform_name = @program_transform_name@ psdir = @psdir@ pyexecdir = @pyexecdir@ pythondir = @pythondir@ runstatedir = @runstatedir@ sbindir = @sbindir@ sharedstatedir = @sharedstatedir@ srcdir = @srcdir@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ EXTRA_DIST = Doxyfile Doxyfile-xml bison.dox config-backend.dox \ contribute.dox mainpage.dox terminology.dox unit-tests.dox \ doc.dox congestion-handling.dox all: all-am .SUFFIXES: $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) @for dep in $?; do \ case '$(am__configure_deps)' in \ *$$dep*) \ ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \ && { if test -f $@; then exit 0; else break; fi; }; \ exit 1;; \ esac; \ done; \ echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign doc/devel/Makefile'; \ $(am__cd) $(top_srcdir) && \ $(AUTOMAKE) --foreign doc/devel/Makefile Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status @case '$?' in \ *config.status*) \ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ *) \ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \ esac; $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(top_srcdir)/configure: $(am__configure_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(ACLOCAL_M4): $(am__aclocal_m4_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(am__aclocal_m4_deps): mostlyclean-libtool: -rm -f *.lo clean-libtool: -rm -rf .libs _libs tags TAGS: ctags CTAGS: cscope cscopelist: distdir: $(DISTFILES) @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ list='$(DISTFILES)'; \ dist_files=`for file in $$list; do echo $$file; done | \ sed -e "s|^$$srcdirstrip/||;t" \ -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \ case $$dist_files in \ */*) $(MKDIR_P) `echo "$$dist_files" | \ sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \ sort -u` ;; \ esac; \ for file in $$dist_files; do \ if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ if test -d $$d/$$file; then \ dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \ if test -d "$(distdir)/$$file"; then \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \ find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \ fi; \ cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \ else \ test -f "$(distdir)/$$file" \ || cp -p $$d/$$file "$(distdir)/$$file" \ || exit 1; \ fi; \ done check-am: all-am check: check-am all-am: Makefile installdirs: install: install-am install-exec: install-exec-am install-data: install-data-am uninstall: uninstall-am install-am: all-am @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am installcheck: installcheck-am install-strip: if test -z '$(STRIP)'; then \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ install; \ else \ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \ fi mostlyclean-generic: clean-generic: distclean-generic: -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) -test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES) maintainer-clean-generic: @echo "This command is intended for maintainers to use" @echo "it deletes files that may require special tools to rebuild." clean: clean-am clean-am: clean-generic clean-libtool clean-local mostlyclean-am distclean: distclean-am -rm -f Makefile distclean-am: clean-am distclean-generic dvi: dvi-am dvi-am: html: html-am html-am: info: info-am info-am: install-data-am: install-dvi: install-dvi-am install-dvi-am: install-exec-am: install-html: install-html-am install-html-am: install-info: install-info-am install-info-am: install-man: install-pdf: install-pdf-am install-pdf-am: install-ps: install-ps-am install-ps-am: installcheck-am: maintainer-clean: maintainer-clean-am -rm -f Makefile maintainer-clean-am: distclean-am maintainer-clean-generic mostlyclean: mostlyclean-am mostlyclean-am: mostlyclean-generic mostlyclean-libtool pdf: pdf-am pdf-am: ps: ps-am ps-am: uninstall-am: .MAKE: install-am install-strip .PHONY: all all-am check check-am clean clean-generic clean-libtool \ clean-local cscopelist-am ctags-am distclean distclean-generic \ distclean-libtool distdir dvi dvi-am html html-am info info-am \ install install-am install-data install-data-am install-dvi \ install-dvi-am install-exec install-exec-am install-html \ install-html-am install-info install-info-am install-man \ install-pdf install-pdf-am install-ps install-ps-am \ install-strip installcheck installcheck-am installdirs \ maintainer-clean maintainer-clean-generic mostlyclean \ mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \ tags-am uninstall uninstall-am .PRECIOUS: Makefile all: # do nothing, used only by developers manually devel: mkdir -p $(builddir)/html (cat $(srcdir)/Doxyfile; echo PROJECT_NUMBER=$(PACKAGE_VERSION)) | doxygen - > $(builddir)/html/doxygen.log 2> $(builddir)/html/doxygen-error.log echo `grep -i ": warning:" $(builddir)/html/doxygen-error.log | wc -l` warnings/errors detected. clean-local: rm -rf html # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: kea-1.6.2/doc/devel/congestion-handling.dox0000644000175000017500000004075613623761160015534 00000000000000// Copyright (C) 2018 Internet Systems Consortium, Inc. ("ISC") // // This Source Code Form is subject to the terms of the Mozilla Public // License, v. 2.0. If a copy of the MPL was not distributed with this // file, You can obtain one at http://mozilla.org/MPL/2.0/. /** @page congestionHandling Congestion Handling in Kea DHCP Servers @section background What is Congestion? Congestion occurs when servers are subjected to client queries faster than they can be fulfilled. Subsequently, the servers begin accumulating a backlog of pending queries. The longer the high rate of traffic continues the farther behind the servers fall. Depending on the client implementations, those that fail to get leases either give up or simply continue to retry forever. In the former case, the server may eventually recover. The latter case is vicious cycle from which the server is unable to escape. In a well-planned deployment, the number and capacity of servers is matched to the maximum client loads expected. As long as capacity is matched to load, congestion does not occur. If the load is routinely too heavy, then the deployment needs to be re-evaluated. Congestion typically occurs when there is a network event that causes overly large numbers of clients to simultaneously need leases such as recovery after a network outage. @section introduction Congestion Handling Overview Kea 1.5.0 introduces a new feature referred to as Congestion Handling. The goal of Congestion Handling is to help the servers mitigate the peak in traffic by fulfilling as many of the most relevant requests as possible until it subsides. Prior to Kea 1.5.0, Kea DHCP servers read inbound packets directly from the interface sockets in the main application thread. This meant that packets waiting to be processed were held in socket buffers themselves. Once these buffers fill any new packets are discarded. Under swamped conditions the servers can end up processing client packets that may no longer be relevant, or worse are redundant. In other words, the packets waiting in the FIFO socket buffers become increasingly stale. Congestion Handling offers the ability to configure the server to use a separate thread to read packets from the interface socket buffers. As the thread reads packets from the buffers they are added to an internal "packet queue". The server's main application thread processes packets from this queue rather than the socket buffers. By structuring it this way, we've introduced a configurable layer which can make decisions on which packets to process, how to store them, and the order in which they are processed by the server. The default packet queue implementation for both Kea DHCPv4 and DHCPv6 servers is a simple ring buffer. Once it reaches capacity, new packets get added to the back of queue by discarding packets from the front of queue. Rather than always discarding the newest packets, we now always discard the oldest packets. The capacity of the buffer, (i.e the maximum number of packets the buffer can contain) is configurable. @section custom-implementations Custom Packet Queues It is possible to replace the default packet queue implementation with a custom implementation by registering it with your Kea server via a hook library. The steps for doing this are listed below: -# Develop a derivation of the interface isc::dhcp::PacketQueue -# Registering and un-registering your implementation via Hook library -# Configure your Kea server to use your derivation (If you are not familiar with writing Kea hook libraries, you may wish to read @ref hooksdgDevelopersGuide before continuing). @subsection packet-queue-derivation Developing isc::dhcp::PacketQueue Derivations @subsection packet-queue-derivation-basics The Basics Your custom packet queue must derive from the class template, isc::dhcp::PacketQueue. The class is almost entirely abstract and deliberately brief to provide developers wide latitude in the internals of their solutions. The template argument, @c PacketTypePtr, is expected to be either isc::dhcp::Pkt4Ptr or isc::dhcp::Pkt6Ptr, depending upon which protocol the implementation will handle. Please note that the while following text and examples largely focus on DHCPv4 out of convenience as the concepts are identical for DHCPv6. For completeness there are code snippets at the end of this chapter for DHCPv6. The two primary functions of interest are: -# isc::dhcp::PacketQueue::enqueuePacket() - This function is invoked by the receiver thread each time a packet has been read from an interface socket buffer and should be added to the queue. It is passed a pointer to the unpacked client packet (isc::dhcp::Pkt4Ptr or isc::dhcp::Pkt6Ptr), and a reference to the isc::dhcp::SocketInfo describing the interface socket from which the packet was read. Your derivation is free to use whatever logic you deem appropriate to decide if a given packet should be added to the queue or dropped. The socket information is passed along to be used (or not) in your decision making. The simplest derivation would add every packet, every time. -# isc::dhcp::PacketQueue::dequeuePacket() - This function is invoked by the server's main thread whenever the receiver thread indicates that packets are ready. Which packet is dequeued and returned is entirely up to your derivation. The remaining functions that you'll need to implement are self-explanatory. How your actual "queue" is implemented is entirely up to you. Kea's default implementation using a ring buffer based on Boost's boost::circular_buffer (please refer to isc::dhcp::PacketQueueRing, isc::dhcp::PacketQueueRing4 and isc::dhcp::PacketQueueRing6). The most critical aspects to remember when developing your implementation are: -# It MUST be thread safe since queuing and dequeing packets are done by separate threads. (You might considering using isc::util::thread::Mutex and isc::util::thread::Mutex::Locker). -# Its efficiency (or lack thereof) will have a direct impact on server performance. You will have to consider the dynamics of your deployment to determine where the trade-off lies between the volume of packets responded to and preferring to respond to some subset of those packets. @subsection packet-queue-derivation-factory Defining a Factory isc::dhcp::IfaceMgr using two derivations of isc::dhcp::PacketQueueMgr (one for DHCPv4 and one for DHCPv6), to register queue implementations and instantiate the appropriate queue type based the current configuration. In order to register your queue implementation your hook library must provide a factory function that will be used to create packet queues. This function will be invoked by the server during the configuration process to instantiate the appropriate queue type. For DHCPv4, the factory should be as follows: @code PackQueue4Ptr factory(isc::data::ConstElementPtr parameters) @endcode and for DHCPv6: @code PackQueue6Ptr factory(isc::data::ConstElementPtr parameters) @endcode The factory's only argument is an isc::data::ConstElementPtr. This is will be an isc::data::MapElement instance containing the contents of the configuration element "dhcp-queue-control" from the Kea server's configuration. It will always have the following two values: -# "enable-queue" - used by isc::dhcp::IfaceMgr to know whether or not congestion handling is enabled. Your implementation need not do anything with this value. -# "queue-type" - name of the registered queue implementation to use. It is used by isc::dhcp::IfaceMgr to invoke the appropriate queue factory. Your implementation must pass this value through to the isc::dhcp::PacketQueue constructor. Beyond that you may add whatever additional values you may require. In other words, the content is arbitrary so long as it is valid JSON. It is up to your factory implementation to examine the contents and use them to construct a queue instance. @subsection packet-queue-derivation-example An Example Let's suppose you wish to develop a queue for DHCPv4 and your implementation requires two configurable parameters: capacity and threshold. Your class declaration might look something like this: @code class YourPacketQueue4 : public isc::dhcp::PacketQueue { public: // Logical name you will register your factory under. static const std::string QUEUE_TYPE; // Factory for instantiating queue instances. static isc::dhcp::PacketQueue4Ptr factory(isc::data::ConstElementPtr params); // Constructor YourPacketQueue4(const std::string& queue_type, size_t capacity, size_t threshold) : isc::dhcp::PacketQueue(queue_type) { // your constructor steps here } // Adds a packet to your queue using your secret formula based on threshold. virtual void enqueuePacket(isc::dhcp::Pkt4Ptr packet, const dhcp::SocketInfo& source); // Fetches the next packet to process from your queue using your other secret formula. virtual isc::dhcp::Pkt4Ptr dequeuePacket(); : // Imagine you prototyped the rest of the functions }; @endcode Your factory implementation would then look something like this: @code const std::string QUEUE_TYPE = "Your-Q4"; isc::dhcp::PacketQueue4Ptr YourPacketQueue4::factory(isc::data::ConstElementPtr parameters) { // You need queue-type to pass into the base class. // It's guaranteed to be here. std::string queue_type = isc::data::SimpleParser::getString(parameters, "queue-type"); // Now you need to fetch your required parameters. size_t capacity; try { capacity = isc::data::SimpleParser::getInteger(parameters, "capacity"); } catch (const std::exception& ex) { isc_throw(isc::dhcp::InvalidQueueParameter, "YourPacketQueue4:factory:" " 'capacity' parameter is missing/invalid: " << ex.what()); } size_t threshold; try { threshold = isc::data::SimpleParser::getInteger(parameters, "threshold"); } catch (const std::exception& ex) { isc_throw(isc::dhcp::InvalidQueueParameter, "YourPacketQueue4:factory:" " 'threshold' parameter is missing/invalid: " << ex.what()); } // You should be all set to create your queue instance! isc::dhcp::PacketQueue4Ptr queue(new YourPacketQueue4(queue_type, capacity, threshold)); return (queue); } @endcode Kea's configuration parser cannot know your parameter requirements and thus can only flag JSON syntax errors. Thus it is important for your factory to validate your parameters according to your requirements and throw meaningful exceptions when they are not met. This allows users to know what to correct. @subsection packet-queue-registration Registering Your Implementation All hook libraries must provide a load() and unload() function. Your hook library should register you queue factory during load() and un-register it during unload(). Picking up with the our example, those functions might look something like this: @code // This function is called when the library is loaded. // // param - handle library handle (we aren't using it) // return - 0 when initialization is successful, 1 otherwise int load(LibraryHandle& /* handle */) { try { // Here you register your DHCPv4 queue factory isc::dhcp::IfaceMgr::instance().getPacketQueueMgr4()-> registerPacketQueueFactory(YourPacketQueue4::QUEUE_TYPE, YourPacketQueue::factory); } catch (const std::exception& ex) { LOG_ERROR(your_logger, YOUR_LOAD_FAILED) .arg(ex.what()); return (1); } LOG_INFO(your_logger, YOUR_LOAD_OK); return (0); } // This function is called when the library is unloaded. // // return - 0 if deregistration was successful, 1 otherwise int unload() { // You need to remove your queue factory. This must be done to make sure // your queue instance is destroyed before your library is unloaded. isc::dhcp::IfaceMgr::instance().getPacketQueueMgr4()-> unregisterPacketQueueFactory(YourPacketQueue4::QUEUE_TYPE); LOG_INFO(your_logger, YOUR_UNLOAD_OK); return (0); } @endcode @subsection packet-queue-factory Configuring Kea to use YourPacketQueue4 You're almost there. You developed your implementation, you've unit tested it (You did unit test it right?). Now you just have to tell Kea to load it and use it. Continuing with the example, your kea-dhcp4 configuration would need to look something like this: @code { "Dhcp4": { ... "hooks-libraries": [ { # Loading your hook library! "library": "/somepath/lib/libyour_packet_queue.so" } # any other hook libs ], ... "dhcp-queue-control": { "enable-queue": true, "queue-type": "Your-Q4", "capacity" : 100, "threshold" : 75 }, ... } @endcode @subsection packet-queue-example-dhcpv6 DHCPv6 Example Snippets For completeness, this section includes the example from above implemented for DHCPv6. DHCPv6 Class declaration: @code class YourPacketQueue6 : public isc::dhcp::PacketQueue { public: // Logical name you will register your factory under. static const std::string QUEUE_TYPE; // Factory for instantiating queue instances. static isc::dhcp::PacketQueue6Ptr factory(isc::data::ConstElementPtr params); // Constructor YourPacketQueue6(const std::string& queue_type, size_t capacity, size_t threshold) : isc::dhcp::PacketQueue(queue_type) { // your constructor steps here } // Adds a packet to your queue using your secret formula based on threshold. virtual void enqueuePacket(isc::dhcp::Pkt6Ptr packet, const dhcp::SocketInfo& source); // Fetches the next packet to process from your queue using your other secret formula. virtual isc::dhcp::Pkt6Ptr dequeuePacket(); : // Imagine you prototyped the rest of the functions }; @endcode DHCPv6 Factory implemenation: @code const std::string QUEUE_TYPE = "Your-Q6"; isc::dhcp::PacketQueue6Ptr YourPacketQueue6::factory(isc::data::ConstElementPtr parameters) { // You need queue-type to pass into the base class. // It's guaranteed to be here. std::string queue_type = isc::data::SimpleParser::getString(parameters, "queue-type"); // Now you need to fetch your required parameters. size_t capacity; try { capacity = isc::data::SimpleParser::getInteger(parameters, "capacity"); } catch (const std::exception& ex) { isc_throw(isc::dhcp::InvalidQueueParameter, "YourPacketQueue6:factory:" " 'capacity' parameter is missing/invalid: " << ex.what()); } size_t threshold; try { threshold = isc::data::SimpleParser::getInteger(parameters, "threshold"); } catch (const std::exception& ex) { isc_throw(isc::dhcp::InvalidQueueParameter, "YourPacketQueue6:factory:" " 'threshold' parameter is missing/invalid: " << ex.what()); } // You should be all set to create your queue instance! isc::dhcp::PacketQueue6Ptr queue(new YourPacketQueue6(queue_type, capacity, threshold)); return (queue); } @endcode DHCPv6 Hook load/unload functions @code // This function is called when the library is loaded. // // param - handle library handle (we aren't using it) // return - 0 when initialization is successful, 1 otherwise int load(LibraryHandle& /* handle */) { try { // Here you register your DHCPv6 queue factory isc::dhcp::IfaceMgr::instance().getPacketQueueMgr6()-> registerPacketQueueFactory(YourPacketQueue6::QUEUE_TYPE, YourPacketQueue::factory); } catch (const std::exception& ex) { LOG_ERROR(your_logger, YOUR_LOAD_FAILED) .arg(ex.what()); return (1); } LOG_INFO(your_logger, YOUR_LOAD_OK); return (0); } // This function is called when the library is unloaded. // // return - 0 if deregistration was successful, 1 otherwise int unload() { // You need to remove your queue factory. This must be done to make sure // your queue instance is destroyed before your library is unloaded. isc::dhcp::IfaceMgr::instance().getPacketQueueMgr6()-> unregisterPacketQueueFactory(YourPacketQueue6::QUEUE_TYPE); LOG_INFO(your_logger, YOUR_UNLOAD_OK); return (0); } @endcode Server configuration for kea-dhcp6: @code { "Dhcp6": { ... "hooks-libraries": [ { # Loading your hook library! "library": "/somepath/lib/libyour_packet_queue.so" } # any other hook libs ], ... "dhcp-queue-control": { "enable-queue": true, "queue-type": "Your-Q6", "capacity" : 100, "threshold" : 75 }, ... } @endcode */ kea-1.6.2/doc/devel/Doxyfile0000644000175000017500000032524613623761160012574 00000000000000# Doxyfile 1.8.11 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # # All text after a double hash (##) is considered a comment and is placed in # front of the TAG it is preceding. # # All text after a single hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists, items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (\" \"). #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # This tag specifies the encoding used for all characters in the config file # that follow. The default is UTF-8 which is also the encoding used for all text # before the first occurrence of this tag. Doxygen uses libiconv (or the iconv # built into libc) for the transcoding. See http://www.gnu.org/software/libiconv # for the list of possible encodings. # The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by # double-quotes, unless you are using Doxywizard) that should identify the # project for which the documentation is generated. This name is used in the # title of most generated pages and in a few other places. # The default value is: My Project. PROJECT_NAME = Kea # The PROJECT_NUMBER tag can be used to enter a project or revision number. This # could be handy for archiving the generated documentation or if some version # control system is used. PROJECT_NUMBER = # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = # With the PROJECT_LOGO tag one can specify a logo or an icon that is included # in the documentation. The maximum height of the logo should not exceed 55 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy # the logo to the output directory. PROJECT_LOGO = ../images/kea-logo-100x70.png # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is # entered, it will be relative to the location where doxygen was started. If # left blank the current directory will be used. OUTPUT_DIRECTORY = html # If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub- # directories (in 2 levels) under the output directory of each output format and # will distribute the generated files over these directories. Enabling this # option can be useful when feeding doxygen a huge amount of source files, where # putting all generated files in the same directory would otherwise causes # performance problems for the file system. # The default value is: NO. CREATE_SUBDIRS = YES # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII # characters to appear in the names of generated files. If set to NO, non-ASCII # characters will be escaped, for example _xE3_x81_x84 will be used for Unicode # U+3044. # The default value is: NO. ALLOW_UNICODE_NAMES = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, # Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), # Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, # Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), # Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, # Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, # Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, # Ukrainian and Vietnamese. # The default value is: English. OUTPUT_LANGUAGE = English # If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member # descriptions after the members that are listed in the file and class # documentation (similar to Javadoc). Set to NO to disable this. # The default value is: YES. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief # description of a member or function before the detailed description # # Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. # The default value is: YES. REPEAT_BRIEF = YES # This tag implements a quasi-intelligent brief description abbreviator that is # used to form the text in various listings. Each string in this list, if found # as the leading text of the brief description, will be stripped from the text # and the result, after processing the whole list, is used as the annotated # text. Otherwise, the brief description is used as-is. If left blank, the # following values are used ($name is automatically replaced with the name of # the entity):The $name class, The $name widget, The $name file, is, provides, # specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # doxygen will generate a detailed section even if there is only a brief # description. # The default value is: NO. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. # The default value is: NO. INLINE_INHERITED_MEMB = NO # If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path # before files name in the file list and in the header files. If set to NO the # shortest path that makes the file name unique will be used # The default value is: YES. FULL_PATH_NAMES = NO # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. # Stripping is only done if one of the specified strings matches the left-hand # part of the path. The tag can be used to show relative paths in the file list. # If left blank the directory from which doxygen is run is used as the path to # strip. # # Note that you can specify absolute paths here, but also relative paths, which # will be relative from the directory where doxygen is started. # This tag requires that the tag FULL_PATH_NAMES is set to YES. STRIP_FROM_PATH = # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the # path mentioned in the documentation of a class, which tells the reader which # header file to include in order to use a class. If left blank only the name of # the header file containing the class definition is used. Otherwise one should # specify the list of include paths that are normally passed to the compiler # using the -I flag. STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but # less readable) file names. This can be useful is your file systems doesn't # support long names like on DOS, Mac, or CD-ROM. # The default value is: NO. SHORT_NAMES = NO # If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the # first line (until the first dot) of a Javadoc-style comment as the brief # description. If set to NO, the Javadoc-style will behave just like regular Qt- # style comments (thus requiring an explicit @brief command for a brief # description.) # The default value is: NO. JAVADOC_AUTOBRIEF = YES # If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first # line (until the first dot) of a Qt-style comment as the brief description. If # set to NO, the Qt-style will behave just like regular Qt-style comments (thus # requiring an explicit \brief command for a brief description.) # The default value is: NO. QT_AUTOBRIEF = NO # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a # multi-line C++ special comment block (i.e. a block of //! or /// comments) as # a brief description. This used to be the default behavior. The new default is # to treat a multi-line C++ comment block as a detailed description. Set this # tag to YES if you prefer the old behavior instead. # # Note that setting this tag to YES also means that rational rose comments are # not recognized any more. # The default value is: NO. MULTILINE_CPP_IS_BRIEF = NO # If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the # documentation from any documented member that it re-implements. # The default value is: YES. INHERIT_DOCS = YES # If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new # page for each member. If set to NO, the documentation of a member will be part # of the file/class/namespace that contains it. # The default value is: NO. SEPARATE_MEMBER_PAGES = NO # The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen # uses this value to replace tabs by spaces in code fragments. # Minimum value: 1, maximum value: 16, default value: 4. TAB_SIZE = 4 # This tag can be used to specify a number of aliases that act as commands in # the documentation. An alias has the form: # name=value # For example adding # "sideeffect=@par Side Effects:\n" # will allow you to put the command \sideeffect (or @sideeffect) in the # documentation, which will result in a user-defined paragraph with heading # "Side Effects:". You can put \n's in the value part of an alias to insert # newlines. ALIASES = # This tag can be used to specify a number of word-keyword mappings (TCL only). # A mapping has the form "name=value". For example adding "class=itcl::class" # will allow you to use the command class in the itcl::class meaning. TCL_SUBST = # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources # only. Doxygen will then generate output that is more tailored for C. For # instance, some of the names that are used will be different. The list of all # members will be omitted, etc. # The default value is: NO. OPTIMIZE_OUTPUT_FOR_C = NO # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or # Python sources only. Doxygen will then generate output that is more tailored # for that language. For instance, namespaces will be presented as packages, # qualified scopes will look different, etc. # The default value is: NO. OPTIMIZE_OUTPUT_JAVA = NO # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran # sources. Doxygen will then generate output that is tailored for Fortran. # The default value is: NO. OPTIMIZE_FOR_FORTRAN = NO # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL # sources. Doxygen will then generate output that is tailored for VHDL. # The default value is: NO. OPTIMIZE_OUTPUT_VHDL = NO # Doxygen selects the parser to use depending on the extension of the files it # parses. With this tag you can assign which parser to use for a given # extension. Doxygen has a built-in mapping, but you can override or extend it # using this tag. The format is ext=language, where ext is a file extension, and # language is one of the parsers supported by doxygen: IDL, Java, Javascript, # C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran: # FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran: # Fortran. In the later case the parser tries to guess whether the code is fixed # or free formatted code, this is the default for Fortran type files), VHDL. For # instance to make doxygen treat .inc files as Fortran files (default is PHP), # and .f files as C (default is Fortran), use: inc=Fortran f=C. # # Note: For files without extension you can use no_extension as a placeholder. # # Note that for custom extensions you also need to set FILE_PATTERNS otherwise # the files are not read by doxygen. EXTENSION_MAPPING = # If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments # according to the Markdown format, which allows for more readable # documentation. See http://daringfireball.net/projects/markdown/ for details. # The output of markdown processing is further processed by doxygen, so you can # mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in # case of backward compatibilities issues. # The default value is: YES. MARKDOWN_SUPPORT = YES # When enabled doxygen tries to link words that correspond to documented # classes, or namespaces to their corresponding documentation. Such a link can # be prevented in individual cases by putting a % sign in front of the word or # globally by setting AUTOLINK_SUPPORT to NO. # The default value is: YES. AUTOLINK_SUPPORT = YES # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want # to include (a tag file for) the STL sources as input, then you should set this # tag to YES in order to let doxygen match functions declarations and # definitions whose arguments contain STL classes (e.g. func(std::string); # versus func(std::string) {}). This also make the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. # The default value is: NO. BUILTIN_STL_SUPPORT = YES # If you use Microsoft's C++/CLI language, you should set this option to YES to # enable parsing support. # The default value is: NO. CPP_CLI_SUPPORT = NO # Set the SIP_SUPPORT tag to YES if your project consists of sip (see: # http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen # will parse them like normal C++ but will assume all classes use public instead # of private inheritance when no explicit protection keyword is present. # The default value is: NO. SIP_SUPPORT = NO # For Microsoft's IDL there are propget and propput attributes to indicate # getter and setter methods for a property. Setting this option to YES will make # doxygen to replace the get and set methods by a property in the documentation. # This will only work if the methods are indeed getting or setting a simple # type. If this is not the case, or you want to show the methods anyway, you # should set this option to NO. # The default value is: YES. IDL_PROPERTY_SUPPORT = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC # tag is set to YES then doxygen will reuse the documentation of the first # member in the group (if any) for the other members of the group. By default # all members of a group must be documented explicitly. # The default value is: NO. DISTRIBUTE_GROUP_DOC = NO # If one adds a struct or class to a group and this option is enabled, then also # any nested class or struct is added to the same group. By default this option # is disabled and one has to add nested compounds explicitly via \ingroup. # The default value is: NO. GROUP_NESTED_COMPOUNDS = NO # Set the SUBGROUPING tag to YES to allow class member groups of the same type # (for instance a group of public functions) to be put as a subgroup of that # type (e.g. under the Public Functions section). Set it to NO to prevent # subgrouping. Alternatively, this can be done per class using the # \nosubgrouping command. # The default value is: YES. SUBGROUPING = YES # When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions # are shown inside the group in which they are included (e.g. using \ingroup) # instead of on a separate page (for HTML and Man pages) or section (for LaTeX # and RTF). # # Note that this feature does not work in combination with # SEPARATE_MEMBER_PAGES. # The default value is: NO. INLINE_GROUPED_CLASSES = NO # When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions # with only public data fields or simple typedef fields will be shown inline in # the documentation of the scope in which they are defined (i.e. file, # namespace, or group documentation), provided this scope is documented. If set # to NO, structs, classes, and unions are shown on a separate page (for HTML and # Man pages) or section (for LaTeX and RTF). # The default value is: NO. INLINE_SIMPLE_STRUCTS = NO # When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or # enum is documented as struct, union, or enum with the name of the typedef. So # typedef struct TypeS {} TypeT, will appear in the documentation as a struct # with name TypeT. When disabled the typedef will appear as a member of a file, # namespace, or class. And the struct will be named TypeS. This can typically be # useful for C code in case the coding convention dictates that all compound # types are typedef'ed and only the typedef is referenced, never the tag name. # The default value is: NO. TYPEDEF_HIDES_STRUCT = NO # The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This # cache is used to resolve symbols given their name and scope. Since this can be # an expensive process and often the same symbol appears multiple times in the # code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small # doxygen will become slower. If the cache is too large, memory is wasted. The # cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range # is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 # symbols. At the end of a run doxygen will report the cache usage and suggest # the optimal cache size from a speed point of view. # Minimum value: 0, maximum value: 9, default value: 0. LOOKUP_CACHE_SIZE = 0 #--------------------------------------------------------------------------- # Build related configuration options #--------------------------------------------------------------------------- # If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in # documentation are documented, even if no documentation was available. Private # class members and static file members will be hidden unless the # EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. # Note: This will also disable the warnings about undocumented members that are # normally produced when WARNINGS is set to YES. # The default value is: NO. EXTRACT_ALL = YES # If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will # be included in the documentation. # The default value is: NO. EXTRACT_PRIVATE = NO # If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal # scope will be included in the documentation. # The default value is: NO. EXTRACT_PACKAGE = NO # If the EXTRACT_STATIC tag is set to YES, all static members of a file will be # included in the documentation. # The default value is: NO. EXTRACT_STATIC = NO # If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined # locally in source files will be included in the documentation. If set to NO, # only classes defined in header files are included. Does not have any effect # for Java sources. # The default value is: YES. EXTRACT_LOCAL_CLASSES = YES # This flag is only useful for Objective-C code. If set to YES, local methods, # which are defined in the implementation section but not in the interface are # included in the documentation. If set to NO, only methods in the interface are # included. # The default value is: NO. EXTRACT_LOCAL_METHODS = NO # If this flag is set to YES, the members of anonymous namespaces will be # extracted and appear in the documentation as a namespace called # 'anonymous_namespace{file}', where file will be replaced with the base name of # the file that contains the anonymous namespace. By default anonymous namespace # are hidden. # The default value is: NO. EXTRACT_ANON_NSPACES = NO # If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all # undocumented members inside documented classes or files. If set to NO these # members will be included in the various overviews, but no documentation # section is generated. This option has no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_MEMBERS = NO # If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all # undocumented classes that are normally visible in the class hierarchy. If set # to NO, these classes will be included in the various overviews. This option # has no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_CLASSES = NO # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend # (class|struct|union) declarations. If set to NO, these declarations will be # included in the documentation. # The default value is: NO. HIDE_FRIEND_COMPOUNDS = NO # If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any # documentation blocks found inside the body of a function. If set to NO, these # blocks will be appended to the function's detailed documentation block. # The default value is: NO. HIDE_IN_BODY_DOCS = NO # The INTERNAL_DOCS tag determines if documentation that is typed after a # \internal command is included. If the tag is set to NO then the documentation # will be excluded. Set it to YES to include the internal documentation. # The default value is: NO. INTERNAL_DOCS = NO # If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file # names in lower-case letters. If set to YES, upper-case letters are also # allowed. This is useful if you have classes or files whose names only differ # in case and if your file system supports case sensitive file names. Windows # and Mac users are advised to set this option to NO. # The default value is: system dependent. CASE_SENSE_NAMES = YES # If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with # their full class and namespace scopes in the documentation. If set to YES, the # scope will be hidden. # The default value is: NO. HIDE_SCOPE_NAMES = NO # If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will # append additional text to a page's title, such as Class Reference. If set to # YES the compound reference will be hidden. # The default value is: NO. HIDE_COMPOUND_REFERENCE= NO # If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of # the files that are included by a file in the documentation of that file. # The default value is: YES. SHOW_INCLUDE_FILES = YES # If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each # grouped member an include statement to the documentation, telling the reader # which file to include in order to use the member. # The default value is: NO. SHOW_GROUPED_MEMB_INC = NO # If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include # files with double quotes in the documentation rather than with sharp brackets. # The default value is: NO. FORCE_LOCAL_INCLUDES = NO # If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the # documentation for inline members. # The default value is: YES. INLINE_INFO = YES # If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the # (detailed) documentation of file and class members alphabetically by member # name. If set to NO, the members will appear in declaration order. # The default value is: YES. SORT_MEMBER_DOCS = YES # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief # descriptions of file, namespace and class members alphabetically by member # name. If set to NO, the members will appear in declaration order. Note that # this will also influence the order of the classes in the class list. # The default value is: NO. SORT_BRIEF_DOCS = YES # If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the # (brief and detailed) documentation of class members so that constructors and # destructors are listed first. If set to NO the constructors will appear in the # respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. # Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief # member documentation. # Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting # detailed member documentation. # The default value is: NO. SORT_MEMBERS_CTORS_1ST = YES # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy # of group names into alphabetical order. If set to NO the group names will # appear in their defined order. # The default value is: NO. SORT_GROUP_NAMES = YES # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by # fully-qualified names, including namespaces. If set to NO, the class list will # be sorted only by class name, not including the namespace part. # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. # Note: This option applies only to the class list, not to the alphabetical # list. # The default value is: NO. SORT_BY_SCOPE_NAME = NO # If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper # type resolution of all parameters of a function it will reject a match between # the prototype and the implementation of a member function even if there is # only one candidate or it is obvious which candidate to choose by doing a # simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still # accept a match between prototype and implementation in such cases. # The default value is: NO. STRICT_PROTO_MATCHING = NO # The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo # list. This list is created by putting \todo commands in the documentation. # The default value is: YES. GENERATE_TODOLIST = YES # The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test # list. This list is created by putting \test commands in the documentation. # The default value is: YES. GENERATE_TESTLIST = YES # The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug # list. This list is created by putting \bug commands in the documentation. # The default value is: YES. GENERATE_BUGLIST = YES # The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) # the deprecated list. This list is created by putting \deprecated commands in # the documentation. # The default value is: YES. GENERATE_DEPRECATEDLIST= YES # The ENABLED_SECTIONS tag can be used to enable conditional documentation # sections, marked by \if ... \endif and \cond # ... \endcond blocks. ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the # initial value of a variable or macro / define can have for it to appear in the # documentation. If the initializer consists of more lines than specified here # it will be hidden. Use a value of 0 to hide initializers completely. The # appearance of the value of individual variables and macros / defines can be # controlled using \showinitializer or \hideinitializer command in the # documentation regardless of this setting. # Minimum value: 0, maximum value: 10000, default value: 30. MAX_INITIALIZER_LINES = 30 # Set the SHOW_USED_FILES tag to NO to disable the list of files generated at # the bottom of the documentation of classes and structs. If set to YES, the # list will mention the files that were used to generate the documentation. # The default value is: YES. SHOW_USED_FILES = YES # Set the SHOW_FILES tag to NO to disable the generation of the Files page. This # will remove the Files entry from the Quick Index and from the Folder Tree View # (if specified). # The default value is: YES. SHOW_FILES = YES # Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces # page. This will remove the Namespaces entry from the Quick Index and from the # Folder Tree View (if specified). # The default value is: YES. SHOW_NAMESPACES = YES # The FILE_VERSION_FILTER tag can be used to specify a program or script that # doxygen should invoke to get the current version for each file (typically from # the version control system). Doxygen will invoke the program by executing (via # popen()) the command command input-file, where command is the value of the # FILE_VERSION_FILTER tag, and input-file is the name of an input file provided # by doxygen. Whatever the program writes to standard output is used as the file # version. For an example see the documentation. FILE_VERSION_FILTER = # The LAYOUT_FILE tag can be used to specify a layout file which will be parsed # by doxygen. The layout file controls the global structure of the generated # output files in an output format independent way. To create the layout file # that represents doxygen's defaults, run doxygen with the -l option. You can # optionally specify a file name after the option, if omitted DoxygenLayout.xml # will be used as the name of the layout file. # # Note that if you run doxygen from a directory containing a file called # DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE # tag is left empty. LAYOUT_FILE = # The CITE_BIB_FILES tag can be used to specify one or more bib files containing # the reference definitions. This must be a list of .bib files. The .bib # extension is automatically appended if omitted. This requires the bibtex tool # to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info. # For LaTeX the style of the bibliography can be controlled using # LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the # search path. See also \cite for info how to create references. CITE_BIB_FILES = #--------------------------------------------------------------------------- # Configuration options related to warning and progress messages #--------------------------------------------------------------------------- # The QUIET tag can be used to turn on/off the messages that are generated to # standard output by doxygen. If QUIET is set to YES this implies that the # messages are off. # The default value is: NO. QUIET = YES # The WARNINGS tag can be used to turn on/off the warning messages that are # generated to standard error (stderr) by doxygen. If WARNINGS is set to YES # this implies that the warnings are on. # # Tip: Turn warnings on while writing the documentation. # The default value is: YES. WARNINGS = YES # If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate # warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag # will automatically be disabled. # The default value is: YES. WARN_IF_UNDOCUMENTED = YES # If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for # potential errors in the documentation, such as not documenting some parameters # in a documented function, or documenting parameters that don't exist or using # markup commands wrongly. # The default value is: YES. WARN_IF_DOC_ERROR = YES # This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that # are documented, but have no documentation for their parameters or return # value. If set to NO, doxygen will only warn about wrong or incomplete # parameter documentation, but not about the absence of documentation. # The default value is: NO. WARN_NO_PARAMDOC = NO # If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when # a warning is encountered. # The default value is: NO. WARN_AS_ERROR = NO # The WARN_FORMAT tag determines the format of the warning messages that doxygen # can produce. The string should contain the $file, $line, and $text tags, which # will be replaced by the file and line number from which the warning originated # and the warning text. Optionally the format may contain $version, which will # be replaced by the version of the file (if it could be obtained via # FILE_VERSION_FILTER) # The default value is: $file:$line: $text. WARN_FORMAT = "$file:$line: $text" # The WARN_LOGFILE tag can be used to specify a file to which warning and error # messages should be written. If left blank the output is written to standard # error (stderr). WARN_LOGFILE = #--------------------------------------------------------------------------- # Configuration options related to the input files #--------------------------------------------------------------------------- # The INPUT tag is used to specify the files and/or directories that contain # documented source files. You may enter file names like myfile.cpp or # directories like /usr/src/myproject. Separate the files or directories with # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING # Note: If this tag is empty the current directory is searched. INPUT = ../../src/bin/agent \ ../../src/bin/d2 \ ../../src/bin/dhcp4 \ ../../src/bin/dhcp6 \ ../../src/bin/lfc \ ../../src/bin/netconf \ ../../src/bin/perfdhcp \ ../../src/bin/sockcreator \ ../../src/hooks/dhcp/high_availability \ ../../src/hooks/dhcp/lease_cmds \ ../../src/hooks/dhcp/stat_cmds \ ../../src/hooks/dhcp/user_chk \ ../../src/lib/asiodns \ ../../src/lib/asiolink \ ../../src/lib/cc \ ../../src/lib/cfgrpt \ ../../src/lib/config \ ../../src/lib/config_backend \ ../../src/lib/cql \ ../../src/lib/cryptolink \ ../../src/lib/database \ ../../src/lib/dhcp \ ../../src/lib/dhcp_ddns \ ../../src/lib/dhcpsrv \ ../../src/lib/dhcpsrv/parsers \ ../../src/lib/dhcpsrv/benchmarks \ ../../src/lib/dns \ ../../src/lib/eval \ ../../src/lib/exceptions \ ../../src/lib/hooks \ ../../src/lib/http \ ../../src/lib/log \ ../../src/lib/log/compiler \ ../../src/lib/log/interprocess \ ../../src/lib/mysql \ ../../src/lib/pgsql \ ../../src/lib/process \ ../../src/lib/stats \ ../../src/lib/testutils \ ../../src/lib/util \ ../../src/lib/util/encode \ ../../src/lib/util/io \ ../../src/lib/util/random \ ../../src/lib/util/threads \ ../../src/lib/util/unittests \ ../../src/lib/yang \ . # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses # libiconv (or the iconv built into libc) for the transcoding. See the libiconv # documentation (see: http://www.gnu.org/software/libiconv) for the list of # possible encodings. # The default value is: UTF-8. INPUT_ENCODING = UTF-8 # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and # *.h) to filter out the source-files in the directories. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # read by doxygen. # # If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp, # *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, # *.hh, *.hxx, *.hpp, *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, # *.m, *.markdown, *.md, *.mm, *.dox, *.py, *.pyw, *.f90, *.f, *.for, *.tcl, # *.vhd, *.vhdl, *.ucf, *.qsf, *.as and *.js. FILE_PATTERNS = *.c \ *.cc \ *.h \ *.hpp \ *.dox # The RECURSIVE tag can be used to specify whether or not subdirectories should # be searched for input files as well. # The default value is: NO. RECURSIVE = NO # The EXCLUDE tag can be used to specify files and/or directories that should be # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. # # Note that relative paths are relative to the directory from which doxygen is # run. EXCLUDE = ../../src/lib/dns/master_lexer.cc \ ../../src/lib/dns/rdataclass.cc \ ../../src/lib/eval/lexer.cc # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or # directories that are symbolic links (a Unix file system feature) are excluded # from the input. # The default value is: NO. EXCLUDE_SYMLINKS = NO # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories for example use the pattern */test/* EXCLUDE_PATTERNS = */*-placeholder.* \ */cpp/*.py # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names # (namespaces, classes, functions, etc.) that should be excluded from the # output. The symbol name can be a fully qualified name, a word, or if the # wildcard * is used, a substring. Examples: ANamespace, AClass, # AClass::ANamespace, ANamespace::*Test # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories use the pattern */test/* EXCLUDE_SYMBOLS = # The EXAMPLE_PATH tag can be used to specify one or more files or directories # that contain example code fragments that are included (see the \include # command). EXAMPLE_PATH = # If the value of the EXAMPLE_PATH tag contains directories, you can use the # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and # *.h) to filter out the source-files in the directories. If left blank all # files are included. EXAMPLE_PATTERNS = # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be # searched for input files to be used with the \include or \dontinclude commands # irrespective of the value of the RECURSIVE tag. # The default value is: NO. EXAMPLE_RECURSIVE = NO # The IMAGE_PATH tag can be used to specify one or more files or directories # that contain images that are to be included in the documentation (see the # \image command). IMAGE_PATH = ../images \ ../../src/lib/hooks/images \ ../../src/bin/d2/images \ ../../src/lib/dhcpsrv/images # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program # by executing (via popen()) the command: # # # # where is the value of the INPUT_FILTER tag, and is the # name of an input file. Doxygen will then use the output that the filter # program writes to standard output. If FILTER_PATTERNS is specified, this tag # will be ignored. # # Note that the filter must not add or remove lines; it is applied before the # code is scanned, but not when the output code is generated. If lines are added # or removed, the anchors will not be placed correctly. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # properly processed by doxygen. INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern # basis. Doxygen will compare the file name with each pattern and apply the # filter if there is a match. The filters are a list of the form: pattern=filter # (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how # filters are used. If the FILTER_PATTERNS tag is empty or if none of the # patterns match the file name, INPUT_FILTER is applied. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # properly processed by doxygen. FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER) will also be used to filter the input files that are used for # producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). # The default value is: NO. FILTER_SOURCE_FILES = NO # The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file # pattern. A pattern will override the setting for FILTER_PATTERN (if any) and # it is also possible to disable source filtering for a specific pattern using # *.ext= (so without naming a filter). # This tag requires that the tag FILTER_SOURCE_FILES is set to YES. FILTER_SOURCE_PATTERNS = # If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that # is part of the input, its contents will be placed on the main page # (index.html). This can be useful if you have a project on for instance GitHub # and want to reuse the introduction page also for the doxygen output. USE_MDFILE_AS_MAINPAGE = #--------------------------------------------------------------------------- # Configuration options related to source browsing #--------------------------------------------------------------------------- # If the SOURCE_BROWSER tag is set to YES then a list of source files will be # generated. Documented entities will be cross-referenced with these sources. # # Note: To get rid of all source code in the generated output, make sure that # also VERBATIM_HEADERS is set to NO. # The default value is: NO. SOURCE_BROWSER = YES # Setting the INLINE_SOURCES tag to YES will include the body of functions, # classes and enums directly into the documentation. # The default value is: NO. INLINE_SOURCES = NO # Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any # special comment blocks from generated source code fragments. Normal C, C++ and # Fortran comments will always remain visible. # The default value is: YES. STRIP_CODE_COMMENTS = YES # If the REFERENCED_BY_RELATION tag is set to YES then for each documented # function all documented functions referencing it will be listed. # The default value is: NO. REFERENCED_BY_RELATION = YES # If the REFERENCES_RELATION tag is set to YES then for each documented function # all documented entities called/used by that function will be listed. # The default value is: NO. REFERENCES_RELATION = YES # If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set # to YES then the hyperlinks from functions in REFERENCES_RELATION and # REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will # link to the documentation. # The default value is: YES. REFERENCES_LINK_SOURCE = YES # If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the # source code will show a tooltip with additional information such as prototype, # brief description and links to the definition and documentation. Since this # will make the HTML file larger and loading of large files a bit slower, you # can opt to disable this feature. # The default value is: YES. # This tag requires that the tag SOURCE_BROWSER is set to YES. SOURCE_TOOLTIPS = YES # If the USE_HTAGS tag is set to YES then the references to source code will # point to the HTML generated by the htags(1) tool instead of doxygen built-in # source browser. The htags tool is part of GNU's global source tagging system # (see http://www.gnu.org/software/global/global.html). You will need version # 4.8.6 or higher. # # To use it do the following: # - Install the latest version of global # - Enable SOURCE_BROWSER and USE_HTAGS in the config file # - Make sure the INPUT points to the root of the source tree # - Run doxygen as normal # # Doxygen will invoke htags (and that will in turn invoke gtags), so these # tools must be available from the command line (i.e. in the search path). # # The result: instead of the source browser generated by doxygen, the links to # source code will now point to the output of htags. # The default value is: NO. # This tag requires that the tag SOURCE_BROWSER is set to YES. USE_HTAGS = NO # If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a # verbatim copy of the header file for each class for which an include is # specified. Set to NO to disable this. # See also: Section \class. # The default value is: YES. VERBATIM_HEADERS = YES # If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the # clang parser (see: http://clang.llvm.org/) for more accurate parsing at the # cost of reduced performance. This can be particularly helpful with template # rich C++ code for which doxygen's built-in parser lacks the necessary type # information. # Note: The availability of this option depends on whether or not doxygen was # generated with the -Duse-libclang=ON option for CMake. # The default value is: NO. CLANG_ASSISTED_PARSING = NO # If clang assisted parsing is enabled you can provide the compiler with command # line options that you would normally use when invoking the compiler. Note that # the include paths will already be set by doxygen for the files and directories # specified with INPUT and INCLUDE_PATH. # This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. CLANG_OPTIONS = #--------------------------------------------------------------------------- # Configuration options related to the alphabetical class index #--------------------------------------------------------------------------- # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all # compounds will be generated. Enable this if the project contains a lot of # classes, structs, unions or interfaces. # The default value is: YES. ALPHABETICAL_INDEX = YES # The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in # which the alphabetical index list will be split. # Minimum value: 1, maximum value: 20, default value: 5. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. COLS_IN_ALPHA_INDEX = 2 # In case all classes in a project start with a common prefix, all classes will # be put under the same header in the alphabetical index. The IGNORE_PREFIX tag # can be used to specify a prefix (or a list of prefixes) that should be ignored # while generating the index headers. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. IGNORE_PREFIX = #--------------------------------------------------------------------------- # Configuration options related to the HTML output #--------------------------------------------------------------------------- # If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output # The default value is: YES. GENERATE_HTML = YES # The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a # relative path is entered the value of OUTPUT_DIRECTORY will be put in front of # it. # The default directory is: html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_OUTPUT = ../html # The HTML_FILE_EXTENSION tag can be used to specify the file extension for each # generated HTML page (for example: .htm, .php, .asp). # The default value is: .html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FILE_EXTENSION = .html # The HTML_HEADER tag can be used to specify a user-defined HTML header file for # each generated HTML page. If the tag is left blank doxygen will generate a # standard header. # # To get valid HTML the header file that includes any scripts and style sheets # that doxygen needs, which is dependent on the configuration options used (e.g. # the setting GENERATE_TREEVIEW). It is highly recommended to start with a # default header using # doxygen -w html new_header.html new_footer.html new_stylesheet.css # YourConfigFile # and then modify the file new_header.html. See also section "Doxygen usage" # for information on how to generate the default header that doxygen normally # uses. # Note: The header is subject to change so you typically have to regenerate the # default header when upgrading to a newer version of doxygen. For a description # of the possible markers and block names see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_HEADER = # The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each # generated HTML page. If the tag is left blank doxygen will generate a standard # footer. See HTML_HEADER for more information on how to generate a default # footer and what special commands can be used inside the footer. See also # section "Doxygen usage" for information on how to generate the default footer # that doxygen normally uses. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading style # sheet that is used by each HTML page. It can be used to fine-tune the look of # the HTML output. If left blank doxygen will generate a default style sheet. # See also section "Doxygen usage" for information on how to generate the style # sheet that doxygen normally uses. # Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as # it is more robust and this tag (HTML_STYLESHEET) will in the future become # obsolete. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_STYLESHEET = # The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined # cascading style sheets that are included after the standard style sheets # created by doxygen. Using this option one can overrule certain style aspects. # This is preferred over using HTML_STYLESHEET since it does not replace the # standard style sheet and is therefore more robust against future updates. # Doxygen will copy the style sheet files to the output directory. # Note: The order of the extra style sheet files is of importance (e.g. the last # style sheet in the list overrules the setting of the previous ones in the # list). For an example see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_STYLESHEET = # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the HTML output directory. Note # that these files will be copied to the base HTML output directory. Use the # $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these # files. In the HTML_STYLESHEET file, use the file name only. Also note that the # files will be copied as-is; there are no commands or markers available. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_FILES = # The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen # will adjust the colors in the style sheet and background images according to # this color. Hue is specified as an angle on a colorwheel, see # http://en.wikipedia.org/wiki/Hue for more information. For instance the value # 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 # purple, and 360 is red again. # Minimum value: 0, maximum value: 359, default value: 220. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_HUE = 220 # The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors # in the HTML output. For a value of 0 the output will use grayscales only. A # value of 255 will produce the most vivid colors. # Minimum value: 0, maximum value: 255, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_SAT = 100 # The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the # luminance component of the colors in the HTML output. Values below 100 # gradually make the output lighter, whereas values above 100 make the output # darker. The value divided by 100 is the actual gamma applied, so 80 represents # a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not # change the gamma. # Minimum value: 40, maximum value: 240, default value: 80. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_GAMMA = 80 # If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML # page will contain the date and time when the page was generated. Setting this # to YES can help to show when doxygen was last run and thus if the # documentation is up to date. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_TIMESTAMP = YES # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the # page has loaded. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_DYNAMIC_SECTIONS = YES # With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries # shown in the various tree structured indices initially; the user can expand # and collapse entries dynamically later on. Doxygen will expand the tree to # such a level that at most the specified number of entries are visible (unless # a fully collapsed tree already exceeds this amount). So setting the number of # entries 1 will produce a full collapsed tree by default. 0 is a special value # representing an infinite number of entries and will result in a full expanded # tree by default. # Minimum value: 0, maximum value: 9999, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_INDEX_NUM_ENTRIES = 100 # If the GENERATE_DOCSET tag is set to YES, additional index files will be # generated that can be used as input for Apple's Xcode 3 integrated development # environment (see: http://developer.apple.com/tools/xcode/), introduced with # OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a # Makefile in the HTML output directory. Running make will produce the docset in # that directory and running make install will install the docset in # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at # startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html # for more information. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_DOCSET = NO # This tag determines the name of the docset feed. A documentation feed provides # an umbrella under which multiple documentation sets from a single provider # (such as a company or product suite) can be grouped. # The default value is: Doxygen generated docs. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_FEEDNAME = "Doxygen generated docs" # This tag specifies a string that should uniquely identify the documentation # set bundle. This should be a reverse domain-name style string, e.g. # com.mycompany.MyDocSet. Doxygen will append .docset to the name. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_BUNDLE_ID = org.doxygen.Project # The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify # the documentation publisher. This should be a reverse domain-name style # string, e.g. com.mycompany.MyDocSet.documentation. # The default value is: org.doxygen.Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_ID = org.doxygen.Publisher # The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. # The default value is: Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_NAME = Publisher # If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three # additional HTML index files: index.hhp, index.hhc, and index.hhk. The # index.hhp is a project file that can be read by Microsoft's HTML Help Workshop # (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on # Windows. # # The HTML Help Workshop contains a compiler that can convert all HTML output # generated by doxygen into a single compiled HTML file (.chm). Compiled HTML # files are now used as the Windows 98 help format, and will replace the old # Windows help format (.hlp) on all Windows platforms in the future. Compressed # HTML files also contain an index, a table of contents, and you can search for # words in the documentation. The HTML workshop also contains a viewer for # compressed HTML files. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_HTMLHELP = NO # The CHM_FILE tag can be used to specify the file name of the resulting .chm # file. You can add a path in front of the file if the result should not be # written to the html output directory. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_FILE = # The HHC_LOCATION tag can be used to specify the location (absolute path # including file name) of the HTML help compiler (hhc.exe). If non-empty, # doxygen will try to run the HTML help compiler on the generated index.hhp. # The file has to be specified with full path. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. HHC_LOCATION = # The GENERATE_CHI flag controls if a separate .chi index file is generated # (YES) or that it should be included in the master .chm file (NO). # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. GENERATE_CHI = NO # The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) # and project file content. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_INDEX_ENCODING = # The BINARY_TOC flag controls whether a binary table of contents is generated # (YES) or a normal table of contents (NO) in the .chm file. Furthermore it # enables the Previous and Next buttons. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. BINARY_TOC = NO # The TOC_EXPAND flag can be set to YES to add extra items for group members to # the table of contents of the HTML help documentation and to the tree view. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. TOC_EXPAND = NO # If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and # QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that # can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help # (.qch) of the generated HTML documentation. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_QHP = NO # If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify # the file name of the resulting .qch file. The path specified is relative to # the HTML output folder. # This tag requires that the tag GENERATE_QHP is set to YES. QCH_FILE = # The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help # Project output. For more information please see Qt Help Project / Namespace # (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace). # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_NAMESPACE = # The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt # Help Project output. For more information please see Qt Help Project / Virtual # Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual- # folders). # The default value is: doc. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_VIRTUAL_FOLDER = doc # If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom # filter to add. For more information please see Qt Help Project / Custom # Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- # filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_NAME = # The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the # custom filter to add. For more information please see Qt Help Project / Custom # Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- # filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_ATTRS = # The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this # project's filter section matches. Qt Help Project / Filter Attributes (see: # http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_SECT_FILTER_ATTRS = # The QHG_LOCATION tag can be used to specify the location of Qt's # qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the # generated .qhp file. # This tag requires that the tag GENERATE_QHP is set to YES. QHG_LOCATION = # If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be # generated, together with the HTML files, they form an Eclipse help plugin. To # install this plugin and make it available under the help contents menu in # Eclipse, the contents of the directory containing the HTML and XML files needs # to be copied into the plugins directory of eclipse. The name of the directory # within the plugins directory should be the same as the ECLIPSE_DOC_ID value. # After copying Eclipse needs to be restarted before the help appears. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_ECLIPSEHELP = NO # A unique identifier for the Eclipse help plugin. When installing the plugin # the directory name containing the HTML and XML files should also have this # name. Each documentation set should have its own identifier. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. ECLIPSE_DOC_ID = org.doxygen.Project # If you want full control over the layout of the generated HTML pages it might # be necessary to disable the index and replace it with your own. The # DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top # of each HTML page. A value of NO enables the index and the value YES disables # it. Since the tabs in the index contain the same information as the navigation # tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. DISABLE_INDEX = NO # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index # structure should be generated to display hierarchical information. If the tag # value is set to YES, a side panel will be generated containing a tree-like # index structure (just like the one that is generated for HTML Help). For this # to work a browser that supports JavaScript, DHTML, CSS and frames is required # (i.e. any modern browser). Windows users are probably better off using the # HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can # further fine-tune the look of the index. As an example, the default style # sheet generated by doxygen has an example that shows how to put an image at # the root of the tree instead of the PROJECT_NAME. Since the tree basically has # the same information as the tab index, you could consider setting # DISABLE_INDEX to YES when enabling this option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_TREEVIEW = YES # The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that # doxygen will group on one line in the generated HTML documentation. # # Note that a value of 0 will completely suppress the enum values from appearing # in the overview section. # Minimum value: 0, maximum value: 20, default value: 4. # This tag requires that the tag GENERATE_HTML is set to YES. ENUM_VALUES_PER_LINE = 4 # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used # to set the initial width (in pixels) of the frame in which the tree is shown. # Minimum value: 0, maximum value: 1500, default value: 250. # This tag requires that the tag GENERATE_HTML is set to YES. TREEVIEW_WIDTH = 180 # If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to # external symbols imported via tag files in a separate window. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. EXT_LINKS_IN_WINDOW = NO # Use this tag to change the font size of LaTeX formulas included as images in # the HTML documentation. When you change the font size after a successful # doxygen run you need to manually remove any form_*.png images from the HTML # output directory to force them to be regenerated. # Minimum value: 8, maximum value: 50, default value: 10. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_FONTSIZE = 10 # Use the FORMULA_TRANSPARENT tag to determine whether or not the images # generated for formulas are transparent PNGs. Transparent PNGs are # not supported properly for IE 6.0, but are supported on all modern browsers. # Note that when changing this option you need to delete any form_*.png files # in the HTML output before the changes have effect. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_TRANSPARENT = YES # Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see # http://www.mathjax.org) which uses client side Javascript for the rendering # instead of using pre-rendered bitmaps. Use this if you do not have LaTeX # installed or if you want to formulas look prettier in the HTML output. When # enabled you may also need to install MathJax separately and configure the path # to it using the MATHJAX_RELPATH option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. USE_MATHJAX = NO # When MathJax is enabled you can set the default output format to be used for # the MathJax output. See the MathJax site (see: # http://docs.mathjax.org/en/latest/output.html) for more details. # Possible values are: HTML-CSS (which is slower, but has the best # compatibility), NativeMML (i.e. MathML) and SVG. # The default value is: HTML-CSS. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_FORMAT = HTML-CSS # When MathJax is enabled you need to specify the location relative to the HTML # output directory using the MATHJAX_RELPATH option. The destination directory # should contain the MathJax.js script. For instance, if the mathjax directory # is located at the same level as the HTML output directory, then # MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax # Content Delivery Network so you can quickly see the result without installing # MathJax. However, it is strongly recommended to install a local copy of # MathJax from http://www.mathjax.org before deployment. # The default value is: http://cdn.mathjax.org/mathjax/latest. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest # The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax # extension names that should be enabled during MathJax rendering. For example # MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_EXTENSIONS = # The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces # of code that will be used on startup of the MathJax code. See the MathJax site # (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an # example see the documentation. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_CODEFILE = # When the SEARCHENGINE tag is enabled doxygen will generate a search box for # the HTML output. The underlying search engine uses javascript and DHTML and # should work on any modern browser. Note that when using HTML help # (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) # there is already a search function so this one should typically be disabled. # For large projects the javascript based search engine can be slow, then # enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to # search using the keyboard; to jump to the search box use + S # (what the is depends on the OS and browser, but it is typically # , /