Commits (2331)

Too many changes to show.

To preserve performance only 343 of 343+ files are displayed.
......@@ -44,4 +44,4 @@ config.h.in~
# Not normally needed, but may be if some script uses `apt-get install`.
DEBIAN_FRONTEND: noninteractive
# Locale settings do not affect the build, but might affect tests.
CI_REGISTRY_IMAGE: registry.gitlab.isc.org/isc-projects/images/bind9
# Disabled warnings:
# SC2039 - complains about local var: In POSIX sh, 'local' is undefined.
SHELLCHECK_OPTS: "--exclude=SC2039"
- test
stage: test
image: "$CI_REGISTRY_IMAGE:debian-stretch-amd64"
- sudo apt-get -y install shellcheck
- SCRIPTS="src/bin/keactrl/keactrl.in "
- SCRIPTS+="src/bin/admin/kea-admin.in "
- SCRIPTS+="src/bin/admin/admin-utils.sh "
- SCRIPTS+="tools/cql_config "
- SCRIPTS+="tools/sysrepo_config "
- shellcheck ${SCRIPTS} ${SHELLCHECK_OPTS}
......@@ -31,29 +31,5 @@ Add any other context about the problem here. In particular, feel free to share
Make sure you anonymize your config files (at the very lease make sure you obfuscate your database credentials, but you may also replace your actual IP addresses and host names with example.com and or 2001:db8::/32).
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version?
- Are you sure what you would like to do is not possible using some other mechanisms?
- Have you discussed your idea on kea-users or kea-dev mailing lists?
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
It is very important to describe what you would like to do and why?
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context about the feature request here.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs?
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code?
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
name: Release Checklist
about: Create a new issue using this checklist for each release
# Kea Release Process
## Introduction
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At the moment, Kea has only one supported release at a time, so the process tries to ensure that any modifications needed for a release take place on the master branch, rather than on a version-specific one. The basic steps for a release are:
1) Announce a code freeze for the master branch that will last until actual tarball release
2) Do all necessary changes to the master branch for the release
3) Create release tarball from master branch
4) After sanity checks made by the QA and development teams, either we continue or we accept changes on master to fix issues if needed and go back to the previous step.
5) Create a release branch (for beta) or merge master to existing release branch (for final) and tag release on it. (???)
6) Sign and upload tarballs
7) Announce that freeze time on master branch is over.
8) Release tarballs are prepared by Jenkins job: https://jenkins.isc.org/job/kea-master-tarball-internal/. When given tarball is accepted for releasing it is pushed to repo.isc.org using Jenkins job: https://jenkins.isc.org/job/kea-release-upload-internal/
## Pre-Release Preparation
Some of those checks and updates can be made before actual freeze, but it's reasonable to announce freeze now!
- [ ] 1. Check Jenkins results:
* Number of unit tests and system tests failing
* Is there a change in system tests pass rate? *Notify the development team of the overall Jenkins status
* Look into tarball check report " Kea Build Checks" on last tarball build and check if there is nothing suspicious (add/removed files, etc), verify that with developers:
* Compare current release package with code in repository
* Compare current release package with previous release package
- [ ] 2. Is the distcheck passing on kea and kea+premium (https://jenkins.isc.org/job/kea-master-distcheck/)?
* Highlight any issues that require fixing.
- [ ] 3. Check perflab if there is no critical errors there (https://perflab.isc.org/)
- [ ] 4. Make sure that there is no pending ticket to merge! (Use GitLab https://gitlab.isc.org/isc-projects/kea/merge_requests and https://gitlab.isc.org/isc-private/kea-premium/merge_requests or contact the development team).
- [ ] 5. Check the Known Issues list, is there something that suppose to be fixed before release and was omitted?
- [ ] 6. Check versioning:
* Ask the development team if the library versions are being updated (there is a step to check it later).
* Ask the development team if the HOOKS_VERSION is being updated.
- [ ] 7. Create Release Notes on Kea GitLab wiki using standard template, update all dates and versions. This wiki page should created under "release notes" folder, like this one: release-notes-1.5-final
- [ ] 8. Check if there is a Release Checklist ready. If not, create new one using this template (page could have been created, check Releases section at the bottom of this page)
The following steps may involve changing files in the repository. If any files will be updated, create a Kea ticket for them and make the changes on a separate branch.
- [ ] 1. Check User's Guide sections:
* Chapter 1. Introduction
- On what platforms we are running tests using Jenkins? Update Supported Platforms
- Did we add any additional 3rd party software? Update if needed
- Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
* Chapter 2. Quick Start
- Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
* Chapter 3. Installation
- Check installation hierarchy
- Check and update Building Requirements
- Check configure options against what ./configure -h says
- [ ] 2. Check !ChangeLog entries in Kea main and premium:
* Spelling, missing numbers, trailing whatspaces? (some of that is checked in every build of tarball-internal Jenkins job)
* Update Release Notes with !ChangeLog entries
- [ ] 3. Check AUTHORS, INSTALL, README files in Kea main and premium.
- [ ] 4. Update information in sources about copyright dates, new version, etc. This is done manually using script https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh
- [ ] 5. Regenerate parsers using docs.isc.org:
* download kea repo
cd kea; autoreconf -fi; ./configure --with-log4cplus=/home/wlodek/log4cplus --enable-generate-parser (log4cplus in /home/wlodek should be available for everyone, if not - download your own)
export PATH=/home/fdupont/bin:$PATH
cd ~/kea/src/bin/dhcp4; touch *.yy; make parser
cd ~/kea/src/bin/dhcp6; touch *.yy; make parser
cd ~/kea/src/bin/d2; touch *.yy; make parser
cd ~/kea/src/bin/agent; touch *.yy; make parser
cd ~/kea/src/bin/netconf/; touch *.yy; make parser
cd ~/kea/src/lib/eval; touch *.yy; make parser
TODO: we should regenerate all of them or just the one that been modified?
If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master.
## Build selection and upload package
That is the last moment to freeze code!
- [ ] 1. Update release version in configure.ac and remove -git suffix, and commit the change on master. From that moment all tarball builds can be officially released.
- [ ] 2. Go to tarball-internal Jenkins job and pick last tarball build - it will be a release candidate.
- [ ] 3. Tarball checks before requesting sanity checks from dev team
* Download tarballs from picked jenkins build
Untar packages:
* Check sizes - is new package reasonable?
* Check installation tree, compare it with previous release
* Check installed lib versions
* which were updated? (save results)
* any of the lib from current release has lower number then corresponding lib from previous release? (!)
* Uninstall Kea, check what left (there should be just configuration files)
* Check if all of installed binaries has man page
* if not, is it in the tarball?
* are man page up-to-date?
* Check if documentation is properly formatted, has correct versions and dates.
* it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
- [ ] 4. If all seems to be ok then upload tarballs to repo.isc.org
* Go to release-upload Jenkins job
* Click "Build with Parameters"
* In field "Tarball" select picked tarball build
* In field "Release_Candidate" pick:
* rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to folder suffixed with indicated rc#
* next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
* final if the last rc number was ok, this will push selected tarbal to repo.isc.org, to folder with no suffixes
- [ ] 5. If none of the results force you to fix and rebuild package, send sanity check request by an email to dhcp-team@isc.org and qa@isc.org with indicating paths with tarballs on repo.isc.org asking for sanity checks
## Sanity checks proposals:
- [ ] 1. Check documentation:
* users guide:
- dates, versions, installation instructions both for kea and premium, formatting
- if you have time - read as much as you can.
* man pages:
- dates, versions, is it up-to-date? or usage changed between releases?
- does every binary has it's own .8 page?
- [ ] 2. Check tarball content:
* compare tarball against repo (does some of the not included files should actually be included?)
* does premium tarballs include correct hooks? (any missing files?)
- [ ] 3. compile:
* configure warnings?
* build warnings?
- [ ] 4. run unit tests with various db backends, install (check tree), uninstall (check tree)
- [ ] 5. Check example configurations
- [ ] 6. Check release notes (not included in tarball)
- [ ] 8. Check db update scripts:
* tarball inlcude the last one? (compare with repo)
## Releasing tarballs:
- [ ] 1. Write an email to signers@isc.org requesting signatures of final tarballs on repo.isc.org indicating release folders. - Attach SHA256 checksums from tarball-internal logs.
- [ ] 2. Make release branch (e.g. v1_5_0 one branch for beta and final, with tags for both releases)
- [ ] 3. Upload Release Notes to repo.isc.org
- [ ] 4. When release packages are signed then upload them from repo.isc.org to ftp:
* make-available --public --symlink=cur /data/shared/sweng/kea/releases/1.4.0-beta
* make-available --private /data/shared/sweng/kea/releases/premium-1.4.0-beta/
* make-available --private /data/shared/sweng/kea/releases/subscription-1.4.0-beta/
- [ ] 5. Contact support or marketing to upload packages to www.isc.org/downloads
- [ ] 6. Contact marketing to upload premium packages to 'products' in web store
- [ ] 7. Contact support to deliver premium and subscriber-only hooks to Kea support subscribers
- [ ] 8. For final release - Release Notes should contain changlogs since previous stable release (beta +final)
- [ ] 9. Modify Release Notes to Announcement
- fold -sw 73 Kea140betaReleaseNotes.txt > Announcement
- change header
- change ftp links to ww.isc.org/downloads
- send it to yourself to check if it's ok
- [ ] 10. Prepare article on kb.isc.org
- change editing mode to HTML, copy release notes between <pre></pre>
- ask support to publish this document
- [ ] 11. Send announcements on:
* kea-users@lists.isc.org
* kea-announce@lists.isc.org
* dhcp-announce@lists.isc.org
- [ ] 12. Notify marketing to announce via social media, publish any blog post that is planned
* publish any blog post that is planned
* Update kea.isc.org
* Update Wikipedia page release info
* Add new hooks to downloadable products (if applies)
* Update subscription data sheet with any new hook (if applies)
* Inform sales about what the release may mean to them
- [ ] 13. Check KnownIssues list on kea.isc.org https://kea.isc.org/wiki/KeaKnownIssues
- ssh kea.isc.org /var/www/kea-docs
- [ ] 14. update page: https://wiki.isc.org/bin/view/Main/KeaReleaseDates
- [ ] 15. update page: https://wiki.isc.org/bin/view/Main/EngineeringReleaseSchedule
......@@ -5,16 +5,24 @@ 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)
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)
- Thomas Markwalder (DDNS, user_chk, global host reservations)
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, perfdhcp, control agent)
- 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.
......@@ -68,6 +76,8 @@ We have received the following contributions:
- 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
......@@ -180,17 +190,15 @@ We have received the following contributions:
- Vicky Risk
2018-08: Documentation clean up
2018-10: API documentation clean ups
- Franciszek Gorski
2018-10: Makefile bug fixed
2019-07: Statistics enhancements
2019-09: Statistics initialization enhancements
Kea uses log4cplus (http://sourceforge.net/projects/log4cplus/) for logging,
Boost (http://www.boost.org/) library for almost everything, and can use Botan
(http://botan.randombit.net/) or OpenSSL (https://www.openssl.org/) for
cryptographic operations. It can also optionally use PostgreSQL
(http://www.postgresql.org/) and/or MySQL (http://www.mysql.com/) and/or
Cassandra (http://cassandra.apache.org/) as a database.
- Suzanne Goldlust
2018-10: API documentation
Kea can use googletest for unit-tests (https://github.com/google/googletest).
Kea uses ISC Forge (https://github.com/isc-projects/forge/) for conformance testing.
- lpaserati, Thorsten Krohn
2018-11: Two bugfixes in kea-admin
# 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
- 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:
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:
./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
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
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
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.
#### Thank you for contributing your time and experience to the Kea project!
Copyright (C) 2009-2018 Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 2009-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
......@@ -600,3 +600,7 @@ Exhibit B - "Incompatible With Secondary Licenses" Notice
limitations under the License.
--- end of Apache 2.0 license -----------------------------------------------
The ext/coroutine code is externally maintained and distributed under
the Boost Software License, Version 1.0. (See its accompanying file
1669. [func] tmark
Rather than within the 'dhcp-ddns' section, DDNS behavioral
parameters may now be specifed at global, shared-network,
and subnet scopes. Implemented for both kea-dhcp4 and
kea-dhcp6. Not yet supported by Config Backend or Netconf.
(Gitlab #35,!517, git 49ce6286f5d00f99c1c890f12cbc0fd633c9dbf6)
1668. [build] fdupont
The Kea util thread library was removed.
(Gitlab #907,!519, git 1b27dc52aae23753643461086f0950b125bf9c93)
1667. [build] fdupont
The availability of C++11 thead, mutex, condition variable and
atomic librairies is now checked by ./configure.
(Gitlab #918,!520, git baf4097520c1cd38366ee4f33a95dde040906e9e)
1666. [doc] tmark
Added note in ARM about manually admining cb data being possible
but not supported.
(Gitlab #917,!518, git f242e5c2e0e14331172671477dce3a6597691b55)
Kea 1.7.0 released on Sep 25, 2019
1665. [build] tmark
Bumped up library version numbers for Kea 1.7.0 final release.
(Gitlab #924,!526, git c4061d0fdd660c8e375b4e1317603935ccc00b39)
1664. [build] razvan
Make sysrepo_config detect installed sysrepo version.
(Gitlab #766,!449, git e1a236fa4f4680d3eadade6b5f5a6a6065620a5b)
1663. [build] fdupont
Dropped support for Botan 1.x crypto library in Kea as these
versions are now end of life.
(Gitlab #345,!498, git ba028eee986c0da963754c6fcb74790081557bec)
1662. [bug] marcin
Prevent deadlock in the Kea DHCP servers caused by allocating
memory in the system signal handler. The issue was found on
CentOS 7.6, but could possibly affect Kea running on any other
(Gitlab #796,!504, git f858d9d0b63a18370ebb8bd7d1b8250d0c5a1cb5)
1661. [bug] tmark
kea-dhcp4 now rejects inbound client messages that have
neither a hardware address nor a client identifier.
(Gitlab #821,!501, git 60baf65d0c9de384b0da147b50b7fc3180fc54dd)
1660. [func] franek
Statistics of the DHCP packets are now initialized upon the
server startup. This makes the statistics available for fetching
via control channel immediately after the server is started.
(Gitlab #755,!503, git f0238d1b6e88dfedaa91029ec3b65e06c14cab34)
1659. [bug] razvan
Corrected an issue in the DHCPv4 server logic whereby the user-defined
option definitions were not committed which could result in
configuration failures when values for such options were specified.
(Gitlab #729, !434, git e5b68fb226161dcdef0e4d2d9d03d9bdb95af5e2)
Kea 1.6.0 released on Aug 28, 2019
1658. [bug] tmark
Renamed the column "array" in option definition tables
in MySQL schema to "is_array" to avoid a reserved word
conflict introduced by MySQL 8.0.17.
(Gitlab #853,!26-p, git 6665c3b6d0f9f2a45b7710e8e9a36fff8f99bf7f)
1657. [bug] marcin, tomek
Corrected multiple occurrences of out of bounds vector reads.
These could cause server to assert when GLIBCXX_ASSERTIONS
was enabled during compilation. Also, elminated overflows as
a result of strncpy.
(Gitlab #851,!24-p, git 4b1d6ffc5ae4f1e1fa5990a644c9786e7f6afea6)
1656. [bug] marcin
Corrected a bug in the Kea MySQL Configuration Backend which
caused the Kea DHCPv6 server to incorrectly require the server
tag to be provided with the remote-subnet6-option-set command.
In addition, corrected issues with setting and deleting
pool specific DHCP options via the Configuration Backend.
(Gitlab #847,!23-p, git 578bc6c997679c507c2f9e419783d34de77816cd)
1655. [bug] marcin
Corrected a bug in the Kea MySQL Configuration Backend which
prevented the DHCP servers from discovering and fetching the
changes applied with the new commands. The new commands set
and delete the options embedded within the subnets, shared
networks and pools.
(Gitlab #845,!22-p, git 7fb2255b212e4e98ff4dbf6d8e2e0ada78701110)
1654. [sec] tmark
kea-dhcp4 Memfile logic now ensures during reading and writing
that leases which are not in the declined state, have either
a hardware address, client id, or both. kea-dhcp6 Memfile logic
now ensures leases which are not declined have a non-empty DUID.
(Gitlab #805,!6-p, git 9705445210cf2a5c4bbe86fde4ce010c45b7aac1)
1653. [sec] tmark
Added a new parameter, "max-row-errors", to Memfile lease database
configuration for kea-dhcp4 and kea-dhcp6. This parameter can be
used to limit the number of rows discarded due to error during
lease file loading after which the server will abandon the effort
and exit. The default value of 0 disables the limit.
(Gitlab #805,!5-p git af7393c517cea37a7091075e5d0d24793bccf013)
1652. [sec] tmark
Prevent the DHCP servers from asserting when malformed
hostname or FQDN options are received. Now the servers will
drop the DHCP packets containing the malformed options.
(Gitlab #730,!2-p git a2a98c421bb400a81218bd28d6a6f62accd31b1f)
1651. [sec] tmark
Added logic to kea-dhcp6 to catch values for client or
server DUIDs that exceed 128 bytes to inbound packet
sanity checking.
(Gitlab #722,!1-p git bb1a64b8945950f4439121ce4fef566d37c8630c)
1650. [build] marcin
Bumped up library version numbers for Kea 1.6.0 final release.
(Gitlab #841,!490, git 2e88e2554905dd66b9974c9fc513ee7e7b825a46)
1649. [doc] sgoldlust
API documentation updated and cleaned up.
(Gitlab #810,!471, git f1ae84186beb54d45f8455236827108289b0b0d6)
1648. [func] fdupont,marcin
Client classification information (client-class,
require-client-classes) and excluded prefix (excluded-prefix,
excluded-prefix-len) may now be specified in the MySQL
Configuration Backend.
(Gitlab #659,!387, git 1f2cae397b48e2a28a7a7e61f6392691b9d32c13)
1647. [doc] marcin
Updated "Local and Relayed Traffic in Shared Networks" sections
of the Kea ARM. Explained that all subnets within a shared
network should have the same subnet selector, i.e. interface
name or relay IP address.
(Gitlab #496,!483, git 1335e5643cc142c65bfc49c13280e9aaf3eeec21)
1646. [func] fdupont
YANG models updated to cover the latest parameters:
pattern and max-row-errors.
(Gitlab #823,!477, git 79d0d45ec0c791560e297ca77fc88842b0a33868)
1645. [func] tmark
Binary option data may now be specified as a single-quoted
text string, within double quotes: "'some text'". This is
handy for binary options that convey text such as urls or
file names.
(Gitlab #761,!447, git 215d84f00208ac8a2710c28abc3386d6b765ede6)
1644. [doc] marcin, fdupont
Added a warning about class dependence on built-in classes.
(Gitlab #727,!466, git 9977d2927cf9b9cf1cd13de30aa5551ca900165b)
1643. [build] godfryd
Added an optional --with-site-packages switch to configure
script. It allows python package installation in a separate
directory (mostly useful on Debian systems when building native
(Gitlab #721,#480, git 66332000ff618fbb41656981c7bbf3bb940066fe)
1642. [doc] fdupont, marcin
User documentation for remote-option{4,6}-* commands.
(Gitlab #826,!479, git 9b469ab63a9627e377a219cf8f83033e4e613b11)
1641. [func] tmark
Added a new Logger output option, 'pattern', which can be
used to customize log message content and layout.
(Gitlab #665,!460, git 2add51ecf0d91d2a9ac797594c38472190c18460)
1640. [func] fdupont
Added sub-option expression for client classification and flex-id.
Users can access sub-option with option[12].option[34].hex or
(Gitlab #150,!385, git 70bb412f20b706484538680906d6fcfd7ee6da68)
1639. [func] fdupont
Updated YANG models with the latest changes in kea-dhcp4 and
(Gitlab #433,!473, git c46e8da1561e7d0c6c6f481d2e32cc9ae398324c)
1638. [bug] franek, razvan
Kea statistics improvements: Correct statistic-get{all} commands.
(Gitlab #756,!470, git 59fb24794af8a9ca8ee3621bc01dfd507350b2c1)
1637. [bug] tmark
Corrected an issue in kea-dhcp6 where the server would assign
a different lease each time a client with a dynamic host
reservation returned via a SOLICIT.
(Gitlab #754,!440, git c548d9330e6f626e538343c5e6361457057efdd7)
1636. [bug] razvan
Http request and response parser now accepts 0 for Content-Length.
(Gitlab #708,!423, git 09d75804e050083b502a96c8e77b0e98c735ae3d)
1635. [doc] godfryd, tomek
Converted API documentation to Sphinx format.
(Gitlab #777,!464, git 3ba1a265537330308c313a38b85e84cbe02704ae)
1634. [func] franek, razvan
Kea statistics improvements: Added commands for set sample age and
set sample count.
(Gitlab #731,!459, git dde1b96b33ed20dbe2c815f1168e62b66635e39f)
1633. [bug] fdupont
Added missing YANG Kea test module in distributions.
(Gitlab #747,!436, git a800e79c7917acc723cbc71b626adc360e15a8d7)
1632. [doc] razvan, tmark
Fixed doc examples.
(Gitlab #649,!381, git e14b90735ff57be0776270364064952d353d7e3a)
1631. [bug] marcin
Corrected the bug in mysql_cb hooks library which in some cases
caused the pools to be orphaned and left in the database after
the subnet has been updated.
(Gitlab #632,!438, git ea15b537d62c66e03923b5fdce91db8795f436b4)
1630. [build] fdupont
Added support for sysrepo 0.7.8 (and libyang 1.0-r3).
(Gitlab #742,!430, git 6776a829f90768225ea794145e522560d26fe959)
1629. [func] tmark
High Availaiblity logging now also emits server and partner system
times when reporting clock skew issues. Prior to this it reported
only the skew between the two servers.
(Gitlab #174,!414, git 9715ddecb0143d997a57edea564f5c180a7f8577)
1628. [bug] fdupont
Improved the error message from MySQL CB -set commands when
a specified server does not exist.
(Gitlab #732,!429, git 82f34e60363eec72a117939a5526bdb1ececb53c)
1627. [func] fdupont
Added new command server-tag-get to DHCPv4 and DHCPv6 servers.
(Gitlab #470,!386, git 3cb43f112662ba3f9d2fc7152dfa1639401b1491)
1626. [bug] marcin
Automatically delete embedded options as a result of deleting
a subnet, pool or shared network from the MySQL Configuration
Backend. Prior to this change, the options were unnecessarily
left in the database. The database schema version was affected
and its version bumped up to 8.2.
(Gitlab #680,!426, git 03f0af3900bdd9eaa951b23cc9508f0618d3f1bb)
Kea 1.6.0-beta2 released on July 24, 2019
1625. [build] tmark, marcin
Bumped up libraries version numbers for Kea 1.6.0 beta2 release.
(Gitlab #740,!427, git 359fe51531e802f052bd4172d4e295378155dbd5)
1624. [doc] marcin
Documented a usage of the server tags with the Kea Configuration
Backend in the Kea ARM.
(Gitlab #643,!421, git 4c60b02e619bce2c434bbf9ee0e775d8776b2d74)
1623. [bug] fdupont
Eliminated the issue whereby the DHCP server could terminate as a
result of the remote-network4-del and remote-network6-del commands.
(Gitlab #738,!425, git b34151b647aae8690fe0996090e13403a8e3ad55)
1622. [bug] fdupont
Corrected server tags returned with the metadata when fetching
option definitions from the MySQL configuration backend
(Gitlab #737,!424, git 1cc95ae2a66102427e583b4924383fd414e24f0f)
1621. [func] fdupont
Both kea-dhcp4 and kea-dhcp6 now support a special class, 'DROP'.
When the class is defined, inbound client packets that match the
class's match expression will be dropped without further processing.
Each such drop is logged at DEBUG level and accounted for in
drop statistics.
(Gitlab #606,!375, git bfa5b2c50324e9d2339daa8309774f49a5e7bf3c)
1620. [func] franek, razvan
Kea statistics improvements: Support for storing more than one
(Gitlab #696,!418, git c7b8c275758c96f56081e02da429f5dd9d653b87)
1619. [func] marcin
Add support for associating subnets with the server tags in the
mysql_cb hooks library.
(Gitlab #717,!417, git e121ec4e0a04bc5bebdbfecf9cc1606b50e71263)
1618. [func] marcin
Add support for associating the shared networks with the server
tags in the mysql_cb hooks library.
(Gitlab #716,!412, git 326fdbeb51dc1f6eebbdbbdcce78cfac87a61bd9)
1617. [bug] fdupont
During the application of the config backend the external config
is initialized to the default values so when a global parameter
is changed and deleted it gets back a sane value.
(Gitlab #630,!355, git 237afd3c512ed4d05ae76de76cce21dca643a889)
1616. [func] fdupont
Renamed kea-admin lease-init, lease-version and lease-upgrade
commands to db-init, db-version and db-upgrade. Only the lease-*
command is now lease-dump.
(Gitlab #466,!393, git cbd2ed23f2ea0649ccf608fe818197d2923108f0)
1615. [func] fdupont
Added check for keyword name and type in parsers of objects
managed by the config backend (options, option definitions,
subnets and shared networks).
(Gitlab #575,!358, git c9d87afad8db924da0aadc1b8ab40638bd0a6738)
1614. [func] marcin
Add support for associating the DHCP option definitions with
the server tags in the mysql_cb hooks library.
(Gitlab #715,!411, git 5511725555138213de4f48dc1091d65b5db47034)
1613. [func] marcin
Add support for associating the global DHCP options with the
server tags in the mysql_cb hooks library.
(Gitlab #714,!409, git 711c1dca9de388b786942fe5bedb8b8cf63b85ba)
1612. [bug] razvan
Fixed crash caused by unloading premium libraries which use
custom host cache containers.
(Gitlab #639,!410, git d3f7e9d9a18d93fb014c8e637e15c6ae9ca9269e)
1611. [doc] fdupont
Clarified how Kea handles subnet prefixes in server configuration.
(Gitlab #419,!333, git f260b51148b4f7584165e13fcf2320fdd5992a74)
1610. [build] fdupont
Removed the obsolete compatcheck top directory.
(Gitlab #667,!391, git 8cb113a52f0cf56fbdb5cb0e87464135234c2ac1)
1609. [bug] fdupont
Fixed the implementation of authentication keys in DHCPv6
host reservations. Please note this includes a PostgreSQL
schema update.
(Gitlab #550,!297, git f45511f0445cd4204671771175f7f0d34df54b0e)
1608. [bug] fdupont
Missing debug DHCP6_PACKET_SEND logging message was added.
(Gitlab #699,!401, git ac96edbe30be5c93f5e3d2512961f1bc99c3253a)
1607. [bug] tmark
Corrected an initialization issue which caused lease sanity
checking to be enabled inside the Lease File Cleanup (LFC)
process. The LFC cannot meaningfully perform sanity checking
as it does not have access to the full server configuration.
(Gitlab #686,!403 git 68b2cb0385779ef0c520164e418dee124d7cb364)
1606. [bug] tmark
Corrected an error with retrieving DHCPv6 leases, whose IAID
values are larger than int32_t max, from Postgresql lease
(Gitlab #651,!384, git 67e047df61d56558d474514a21ed0db96152557a)
1605. [func] marcin
Extended mysql_cb hooks library to support new API calls for
managing the DHCP servers in the database. In addition, added
support for associating the global parameters with the server
(Gitlab #642,!373, git 8ca1021809a6c44cf8a6589a959e94ca9ca76c29)
1604. [bug] fdupont
Improved configuration failure messages when the problem is
from the configuration backend and not the configuration file.
(Gitlab #616,!379, git 637e9f03cc502068822ab0310f2e070d4a4da339)
1603. [perf] tmark
High Availability now registers its HTTP sockets with Interface
Manager's main thread allowing the thread can monitor them for
IO readiness. This should improve the responsiveness of HA peers
to each other.
(Gitlab #691,!395, git 4a0b024bc6d83b26fe702d95ee7ce0c914b37d8e)
1602. [func] fdupont
Added more information to sanity-checker log messages.
(Gitlab #685,!392, git 5367cd1196662739bbff5e99072ab6a55cfb0489)
1601. [func] fdupont
Kea servers now add the lease validity lifetime to informational
lease allocation log messages.
(Gitlan #694,!399, git cb29b532cf1f8790f9752d7e8253b0aa31ce05e6)
1600. [bug] fdupont
Fixed prefixLengthFromRange() routine.
(Gitlab #583.!377, git 10bd31217d8a0a77345c4cba7a59314f70c1b509)
1599. [perf] marcin
Improved performance of the DHCPv6 server running with High
Availability by aggregating multiple lease updates in a single
lease6-bulk-apply command instead of generating multiple
lease6-update commands, one for each allocated lease.
(Gitlab #689,!394, git 65021b840b94da3d118e541fba5469c8ed15175b)
1598. [bug] razvan
Added unittests for long (> 65536 chars) tokens in parsed configs
so any crash related to parsers could be detected.
(Gitlab #604,!376, git 811735b67fcdb5592c3e020792c154f2f454259c)
1597. [func] fdupont
Added new configuration parameters for handling user lease
time hints to kea-dhcp4: min-valid-lifetime and max-valid-lifetime;
and to kea-dhcp6: min-preferred-lifetime, max-preferred-lifetime,
min-valid-lifetime, and max-valid-lifetime.
(Gitlab #295,!325, git 8641448c4106bf28ea32df72e5e0ad520d3946ae)
1596. [func] marcin
Implemented lease6-bulk-apply command in the lease_cmds hooks
(Gitlab #683,!390, git 122473c18b632ddfa22b8a48f6d9399bc18e2598)
1595. [func] fdupont
Removed unused t1_ and t2_ members from internal lease class.
(Gitlab #567,!357, git 6072db5f4ca6cfa9573152c255f97dd170acbd57)
1594. [bug] fdupont
Kea no longer uses the .../var/kea directory, for instance pid
files are now in .../var/run/kea.
BEWARE this applies to the kea-dhcp6-serverid file so if the
server will not find the file at its new location it will believe
it is the first time it is being started and will generate a new
server DUID. If that happens, clients will keep trying to get to
the old server and be confused.
(Gitlab #538,!334, git 928b9ae57452aae1dff92ad689ba180fa975381c)
1593. [bug] marcin
Fixed a bug in the Kea Control Agent which caused a sporadic crash
after a tiemout while sending the HTTP response to the controlling
(Gitlab #491,!363, git ff204dfe4dd80702f8bb2edf83f8486e019a7e04)
1592. [build] tmark
Files related to YANG and netconf are now only installed
when the build is configured with --with-syspro.
(Gitlab #584,!364, git 350ae513ed4e8e8e07b159658f88ec7d70b644d3)
1591. [doc] razvan
Fixed classify and pd-exclude documentation examples.
(Gitlab #590,!380, git 26b04d2d2d2a88be6abc5879a2fb48e05f0003fd)
1590. [func] fdupont
It is now possible to specify hostname-char-set and
hostname-char-replacement at the global scope allowing to sanitize
host names without requiring a dhcp-ddns entry.
(Gitlab #540,!374, git 0a5979369902070ee0c4faf3b713627455b99489)
1589. [bug] razvan
Fixed configuring kea with tools/cql_config when using --with-cql
from source.
(Gitlab #522,!261, git bf7debc182e094a8b34f1f2df99cf4e9f84c8906)
1588. [func] marcin
Extended APIs of the DHCPv4 and DHCPv6 configuration backends with
the management functions for the server tags.
(Gitlab #641,!352, git 022d2266e71ced7ec79e0717298ca8e88330a7e7)
1587. [bug] razvan
Fixed IPv6 prefix delegation pools retrieval from the MySQL
Configuration Backend.
(Gitlab #637,!349, git 483273734e8608ed68624d7a868f20672c859c95)
Kea 1.6.0-beta released on May 29, 2019
1586. [build] razvan, marcin
Bumped up libraries version numbers for Kea 1.6.0 beta release.
(Gitlab #617,!340, git c0434bf882b6ec483120e39f6b70b5a40fe7c711)
1585. [bug, func] marcin
MySQL Configuration Backend supports DHCPv6 interface-id parameter.
(Gitlab #628,!341, git 3a07c636ba4c7fceabe59ec597c44a9c8e3367eb)
1584. [doc] marcin
Documented Kea Configuration Backend in the Kea Administrator
Reference Manual.
(Gitlab #71,!314, git 3a65b7a9104f2a988dacf1acc26312b4259e958d)
1583. [bug] fdupont, marcin
Corrected a bug which caused failures to merge a subnet from the
Configuration Backend into the DHCP server's configuration
when subnet identifier was modified.
(Gitlab #492,!252, git c9aba2b5e915c27a8539e6b8f0498179ba896da4)
1582. [bug] tmark
Input values for DHCPv4 and DHCPv6 options of type 'string'
will now be trimmed of any trailing null bytes (0x0).
(Gitlab #539, !330, git b126558e9e39e9bff517dceac25a00e96d150085)
1581. [bug] marcin
Corrected a bug whereby the DHCPv6 server did not take into
account a relay address specified at the shared network level
during the subnet selection.
(Gitlab #620,!332, git c2383e404a5227f6b55655c09ccdc03930815500)
1580. [bug] jonatan.raudsepp
Compilation fix for Alpine linux in Perfdhcp code. Thanks to
Jonatan Raudsepp for sending a patch!
(Gitlab #624,!337, git 19321df9e4490b75ac7b322afec9d231bcb6ffe3)
1579. [bug] razvan
Fixed a bug which caused setting dhcp4o6-port to not function via
Kea configuration backend.
(Gitlab #577,!331, git 98c24fe1873795bbc94d426c54c588b05d79406f)
1578. [func] fdupont
The configuration syntax has changed. The Logging scope that used
to be shared between all servers has been deprecated. Each daemon
is supposed to define its own loggers using 'loggers' array. The
old configuration syntax is still accepted, but is considered
deprecated. Kea 1.6 will accept it, but that capability will be
removed in the future. Please migrate your configuration to new
(Gitlab #208,!196, git 37b8ec6c2c4b64681059f8fad26d112adbb7ee2b)
1577. [func] razvan
Implemented host reservations page retrieval for Cassandra.
(Gitlab #511,!278, git 152e82b49f5e5abd9d3a2a4825ed8620973f5ef1)
1576. [doc] fdupont
New commands cache-get-by-id and cache-size are now documented.
(Gitlab #594,!324, git 3753008cc77f71457b5d777560d8e36dc56e7acd)
1575. [bug] razvan
Fixed issue with keactrl logging error when trying to stop running
(Gitlab #534,!327, git 6ddee0a93ec4ad692cc385150c159d9e8da5232d)
1574. [bug] razvan
Add logging to the MySQL config backend.
(Gitlab #398,!315, git bc46fd3420afdf60ae8841866e8458f7f6e072e8)
1573. [bug] razvan
Fixed build sysrepo from sources using sysrepo_config.
(Gitlab #523,!262, git b86864a9b058a18eaaded2273dc5f40a9ec97c78)
1572. [bug] tmark
Corrected an issue where kea-dhcp6 was incorrectly scheduling DNS
entry removals when renewing leases with generated FQDNs.
(Gitlab #577,!310, git 362f40bebbdbe083ec6420a43ee1c050edf6bba6)
1571. [bug] marcin
The mysql_cb hooks library registers the MySQL backend for the
DHCPv6 server.
(Gitlab #603,!322, git 1ede298fcdc7a9b7018b6e300e2d759e33f73645)
1570. [bug] marcin
Corrected the bug in the Kea HTTP library which could cause a server
to assert when system clock was modified during the transaction.
(Gitlab #599,!320, git 958abe5063b6e602c0070e336524e313c3a87671)
1569. [perf] fdupont
Improved performance of the DHCPv4 server in cases when
match-client-id set disabled by removing unnecessary query to the
lease database."
(Gitlab 509,!272, git 2ad41651c1118fe6f7dfb918df0694dd254706f1)
1568. [bug] tmark
kea-dhcp6 now properly skips sanity checking prefix leases.
Prior to this it was incorrectly subjecting them to sanity
checks during memfile lease file reloads and then flagging
the leases as incorrect.
(Gitlab #591,!#313, git 12262c5df19673652be73cf1dd62d07527bee95d)
1567. [bug] marcin
Kea HTTP client now always includes Host header in all HTTP requests.
The Host header is required in all HTTP/1.1 requests. This corrects
the problem whereby HA peers were unable to communicate via reverse
HTTP proxy because the proxy was responding with Bad Request status
when no Host header was included.
(Gitlab #360,!305, git ddb6dbf4cf63e98d3954c5d46e0311abc4fd6cfc)
1566. [func] tmark
kea-dhcp6 can now be configured to calculate values to
send to clients for T1 and T2 times. Prior to this
it was only possibly to specify explicit values.
(Gitlab #365,!296, git 144b83a84c836d6ff17620b35cb74f830b13c2eb)
1565. [func] marcin
MySQL Config Backend returns server tags associated with the
configuration elements.
(Gitlab #579,!309, git 1e2648df047fe964e8ad3e9deb1c85eea32b1219)
1564. [func] fdupont
Implemented two new commands to manage subnets: subnet4-update and
subnet6-update. They allow an update of existing subnets
(Gitlab #465,!265, git 71eb9188033f81dab56fc5a847a39f5497398b62)
1563. [bug] razvan
Fixed compilation of google benchmarks.
(Gitlab #520,!260, git 11aa890d30ecce5518b9f0bad389feea6be78167)
1562. [bug] marcin
Corrected a bug whereby the DHCP server would trigger a segfault
upon termination when MySQL configuration backend was in use.
(Gitlab #571,!306, git 705e7bb6dd27ec90dd2807d4aac0905e3cb13de4)
1561. [func] tmark
kea-dhcp6 now automatically deletes configuration elements
that have been deleted from configuration backends.
(Gitlab #566,!304, git 2e85376f1b57187b822c662144380e04372cffff)
1560. [bug] fdupont
kea-dhcp4 now permits option code values of 0 and 255 for
options defined in option spaces other than the "dhcp4" space.
(Gitlab #564,!300, git 7a0a0b84d91893f08c0ee6f236daa05bede65166)
1559. [func] fdupont
Added DHCPv6 support to the MySQL Config Backend hook.
(Gitlab #397,!244, git 980091ecd717e41a61f0d7f6808213e450647d8e)
1558. [func] tmark
In addition to a continuous string of digits, hexadecimal
literals may now be a series of one or more octets separated
by either colons or spaces.
(Gitlab #484, git 251efcd5f518a215173845b22555276df0e0ffc6)
1557. [bug] marcin
Added support for "reservation-mode" parameter in the shared network
configuration parsers. It corrects a bug in Configuration Backend
whereby host reservation mode was not stored in the database when
specified via remote-network4-set command.
(Gitlab #517,!301, git e6533001e9d850432254d3cfe995a4f7abcee6e2)
1556. [bug] fdupont
Corrected parser for option definitions to refuse definitions with
duplicate code or name.
(Gitlab #503,!246, git 0befb653277463cd8f88740119fe90a93dbb1466)
1555. [bug] fdupont
Corrected parsers for option definitions to prevent setting out of
range option code values.
(Gitlab #500,!247, git 5c139602d7656df74060fee63461ffba4f290547)
1554. [func] tmark
kea-dhcp6 now uses globals, option definitions, options,
share-networks, and subnets from configuration back ends.
(Gitlab #413,!288, git ff367e273ed8763b354db272c5955a78203d865e)
1553. [func] marcin
DHCPv4 server automatically fetches incremental configuration updates
from the configuration backends.
(Gitlab #103,!277, git 319f7709edb40d6c01390a34942b9d4a200b333e)
(Gitlab #103,!289, git 80087e2d0f90f9ba6623860fed4f4d33ee935ad0)
1552. [bug] marcin
Corrected inheritance of the subnet and shared network specific
parameters in the MySQL Configuration Backend.
(Gitlab #552,!295, git 4812e4227a57b29bfa3995e71588233424a3abb1)
1551. [func] razvan
Added consistency and serial-consistency parameters to CQL
connection. Fixed all statements.
(Gitlab #16,!287, git 56a9b6a860899274f9cafe2366a6731a46490e92)
1550. [func] marcin
Implemented inheritance of the DHCPv4 global and shared network
specific configuration parameters when using configuration
(Gitlab #490,!284, git 2508f942e879ef74b20c07ffdba37d187d6ea932)
1549. [func] tmark
kea-dhcp6 can now be configured to fetch data from configuration
back ends. It does not yet utilize the data fetched.
(Gitlab #104,!290, git d8a25c1ecd17ad24bdce6af19e7a42ce66d4c4f2)
1548. [func] razvan
Added consistency and serial-consistency parameters to CQL
(Gitlab #16,!266, git 5771173d721464d879869fad6456211031858d6c)
1547. [bug, doc] fdupont
Option value for sip-ua-cs-domains has been corrected in the
Kea User's Guide. Thanks to Shawn Routhier from Infoblox for
reporting this issue.
(Gitlab #536,!281, git c128fd9a6b7bffc36ba4fe9a0badebe55441d673)
1546. [func] tmark
kea-dhcp4 now uses options fetched from configured backends.
(Gitlab #401,!254, git 6a33a6f1810f5899ff9c8bc79d0093eebad5c728)
1545. [func] fdupont
A new parameter "data-directory" has been added to DHCPv6.
If specified, it allows DHCPv6 server to store lease and
server-id files in non-standard locations.
(Gitlab #430,!263, git 1f094e18a21124abcaf846cab52c8cba65ca36bc)
1544. [build] fdupont
Message compiler is no longer needed during compilation and
generated message files are part of the distribution. They can be
regenerated using --enable-generate-messages switch passed to
configure script.
(Gitlab #441,!233, git 499b7c36454bcac2553f7bf304d48d7d80f4d4ca)
1543. [bug] fdupont
Corrected behavior of the remote-subnet4-set so as it is now
possible to set the subnet using both an ID or a subnet prefix.
(Gitlab #481,!251, git 9ef651950fde16e258e4b03dd21bbf6dd07d5231)
1542. [test] tmark
MySQL, PostgreSQL, and CQL unit tests will now attempt to wipe
the unit test data, rather than the (re)create the schema between
each test. This reduces test execution time appreciably. The
behavior may be overridden by defining environment variable:
KEA_TEST_DB_WIPE_DATA_ONLY="false". This will cause the schema
to be recreated before each test but may dramatically increase
test execution time.
(Gitlab #526,!269, git 7e81d7bea27e919b652351880872aae68ad1b209)
(Gitlab #531,!279, git 7f8c4fc535df3019789aea1881b7bb3bd539963a)
1541. [bug] fdupont
Empty Relay Agent Information option is no longer sent in server
responses. Thanks to Geoffrey Huang from Qingdao Agricultural
University, and Jiaqi Liu from Qingdao WuKeSong Company
Communication Limited, Shandong, PRC for reporting this issue.
(Gitlab #519,#510,!271, git f3563396d2227e48e96a5d65587406d8d1868db5)