ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-03-02T07:27:17Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/7Improve error message "mdb.c(319): non-null pointer"2021-03-02T07:27:17ZCathy AlmondImprove error message "mdb.c(319): non-null pointer"Per Support ticket [RT #14122](https://support.isc.org/Ticket/Display.html?id=14122)
In a dhcpd.conf that contains both client identifier AND uid in the
same host declaration, the following warning message is emitted as dhcpd starts:
`...Per Support ticket [RT #14122](https://support.isc.org/Ticket/Display.html?id=14122)
In a dhcpd.conf that contains both client identifier AND uid in the
same host declaration, the following warning message is emitted as dhcpd starts:
`mdb.c(319): non-null pointer`
Having both is ambiguous and not supported - but the error message is not in the least helpful or useful for diagnosing what is wrong.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/6DHCPv6 lease length logging2021-03-02T07:27:17ZGhost UserDHCPv6 lease length logging---
name: DHCPv6 - on commit {} - preferred lifetime / valid lifetime incorrect values available
---
**Describe the bug**
When logging preferred and valid lifetime using on commit {} client requested values are recorded instead of serve...---
name: DHCPv6 - on commit {} - preferred lifetime / valid lifetime incorrect values available
---
**Describe the bug**
When logging preferred and valid lifetime using on commit {} client requested values are recorded instead of server provided values.
**To Reproduce**
Use a MacOS DHCPv6 client.
Add this bit to the dhcp config:
```
on commit {
if exists dhcp6.ia-na {
log(debug,
concat( "PREFERREDLIFETIME: ",binary-to-ascii(10, 32, "", substring(option dhcp6.ia-na,32,4)),",",
"VALIDLIFETIME: ",binary-to-ascii(10, 32, "", substring(option dhcp6.ia-na,36,4))
)
);
}
}
```
which prints a log line like this:
`Sep 15 18:53:49 dhcp-server-1 dhcpd: PREFERREDLIFETIME: 0,VALIDLIFETIME: 0`
**Expected behavior**
Should print a log line with the server provided preferred and valid lifetimes (ie: the values being sent back to the client. In my test case was 375 and 600)
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Linux (custom)
- Which features were compiled in
```
./configure --prefix=/usr \
--sysconfdir=/etc \
--enable-secs-byteorder \
--localstatedir=/var/state/dhcp \
--with-srv-lease-file=/var/state/dhcp/dhcpd.leases \
--with-srv6-lease-file=/var/state/dhcp/dhcpd6.leases \
--with-srv-pid-file=/var/run/dhcpd.pid \
--with-srv6-pid-file=/var/run/dhcpd6.pid;
```
**Additional Information**
when committing a lease to an Apple Mac mini (el Capitan) which generates a conventional log line like this:
```
Sep 15 18:53:48 dhcp-server-1 dhcpd: Relay-forward message from 2001:DB8:2e50:e8::1 port 547, link address 2001:DB8:2e50:e8::1, peer address fe80::225:4bff:fea0:6fe8
Sep 15 18:53:48 dhcp-server-1 dhcpd: Advertise NA: address 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe to client with duid 00:01:00:01:20:e5:6e:2d:00:25:4b:a0:6f:e8 iaid = 0 valid for 600 seconds
Sep 15 18:53:48 dhcp-server-1 dhcpd: Sending Relay-reply to 2001:DB8:2e50:e8::1 port 547
Sep 15 18:53:49 dhcp-server-1 dhcpd: Relay-forward message from 2001:DB8:2e50:e8::1 port 547, link address 2001:DB8:2e50:e8::1, peer address fe80::225:4bff:fea0:6fe8
Sep 15 18:53:49 dhcp-server-1 dhcpd: Reply NA: address 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe to client with duid 00:01:00:01:20:e5:6e:2d:00:25:4b:a0:6f:e8 iaid = 0 valid for 600 seconds
Sep 15 18:53:49 dhcp-server-1 dhcpd: Sending Relay-reply to 2001:DB8:2e50:e8::1 port 547
```
Using tcpdump, I can see that the client request had preferred and valid lifetimes of 0 but the reply from the server had preferred lifetime of 375 and valid lifetime of 600.
```
1505501629.303271 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 197) 2001:DB8:2e50:e8::1.547 > 2001:DB8:2e50:e4::226.547: [udp sum ok] dhcp6 relay-fwd (linkaddr=2001:DB8:2e50:e8::1 peeraddr=fe80::225:4bff:fea0:6fe8 (relay-message (dhcp6 request (xid=450fb (client-ID hwaddr/time type 1 time 551906861 00254ba06fe8) (option-request DNS-server DNS-search-list) (elapsed-time 0) (server-ID hwaddr/time type 1 time 542736789 00259061f77a) (IA_NA IAID:0 T1:0 T2:0 (IA_ADDR 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe pltime:0 vltime:0)))) (opt_79) (interface-ID 4769302f302f312e3234...) (Remote-ID 9 0200010000f0000a0003...))
1505501629.303633 IP6 (hlim 64, next-header UDP (17) payload length: 181) 2001:DB8:2e50:e4::226.547 > 2001:DB8:2e50:e8::1.547: [udp sum ok] dhcp6 relay-reply (linkaddr=2001:DB8:2e50:e8::1 peeraddr=fe80::225:4bff:fea0:6fe8 (interface-ID 4769302f302f312e3234...) (relay-message (dhcp6 reply (xid=450fb (IA_NA IAID:0 T1:0 T2:0 (IA_ADDR 2001:DB8:2e50:e8:7fff:ffff:ffff:fffe pltime:375 vltime:600)) (client-ID hwaddr/time type 1 time 551906861 00254ba06fe8) (server-ID hwaddr/time type 1 time 542736789 00259061f77a) (DNS-server 2001:DB8:2e50:a::10 2001:DB8:2e50:a::74))))
```
It seems that option dhcp6.ia-na during the on commit {} may contain data from the client request packet instead of the server reply packet.
This seems to me like it should be considered a bug since it makes it impossible to get the lease time during on commit {}.
**Describe alternatives you've considered**
Presently I'm running tshark to extract the lease length and log it that way. This is not an ideal solution.
**Contacting you**
please contact me if you need to: perl-list at network1.netOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/5Delete build instructions for NextStep and other obsolete systems2021-03-02T07:27:17ZVicky Riskvicky@isc.orgDelete build instructions for NextStep and other obsolete systemsI know this is a nit, but it bugs me to see NextStep and Ultrix and so on in the readme. If it is ok with you Thomas, let me know and I will delete the offending bits.
(Ideally, we would also add a platforms.md and list the platforms we ...I know this is a nit, but it bugs me to see NextStep and Ultrix and so on in the readme. If it is ok with you Thomas, let me know and I will delete the offending bits.
(Ideally, we would also add a platforms.md and list the platforms we test on and know it works on there.)4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/4we need a contributing.md for ISC DHCP2021-03-02T07:27:17ZVicky Riskvicky@isc.orgwe need a contributing.md for ISC DHCPWe had some stuff about how to contribute on the web site, I think that content is mostly now here:
https://kb.isc.org/docs/contributing-to-iscs-open-source
it can be boilerplate. it should probably cover at least:
- how to submit a pat...We had some stuff about how to contribute on the web site, I think that content is mostly now here:
https://kb.isc.org/docs/contributing-to-iscs-open-source
it can be boilerplate. it should probably cover at least:
- how to submit a patch (presumably now via gitlab?)
- that your contribution will be covered by the current license for the project
- that you need to submit tests and doc for your contribution
- if there is still a contrib directory, what are the rules for what goes in there (e.g. ldap stuff?)https://gitlab.isc.org/isc-projects/dhcp/-/issues/3Migrate RT #48575: Avoid python dependency in bind9 build2021-03-02T07:27:16ZThomas MarkwalderMigrate RT #48575: Avoid python dependency in bind9 buildBIND9 changed the default configure behavior to require python. This issue was opened to turn switch this off. It was addressed and reviewed in RT but never merged.BIND9 changed the default configure behavior to require python. This issue was opened to turn switch this off. It was addressed and reviewed in RT but never merged.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/2AFTR-Name appears to be wrongly encoded2021-03-02T07:27:16ZThomas MarkwalderAFTR-Name appears to be wrongly encodedReported by Bluecat under support ticket:
https://support.isc.org/Ticket/Display.html?id=14126
We have a non-compliance issue with a little-used option. Gave them a patch which changed format type to 'D', which is compliant with RFC 10...Reported by Bluecat under support ticket:
https://support.isc.org/Ticket/Display.html?id=14126
We have a non-compliance issue with a little-used option. Gave them a patch which changed format type to 'D', which is compliant with RFC 1035 formating. They replied that this works fine for them. We need to open an RT ticket and change it formally, along with the others that are currently 'd', as they are also wrong.
Simply change 'd' to 'D' common/tables.c as shown the patch below:
[14126_v441.patch](/uploads/0b4d8dd045542e80832af2be669aea37/14126_v441.patch)4.1-ESV-R16Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/134A core dump occurs when the dhclient process runs(x86)2021-03-02T07:27:16ZyuanxinA core dump occurs when the dhclient process runs(x86)---
name: Bug report
about: A core dump occurs when the dhclient process runs a normal test case(x86).
---
**Describe the bug**
When the dhclient process is running, the client->active in the state_bound function (in the dhclinet.c fil...---
name: Bug report
about: A core dump occurs when the dhclient process runs a normal test case(x86).
---
**Describe the bug**
When the dhclient process is running, the client->active in the state_bound function (in the dhclinet.c file) accesses a null pointer.
![12](/uploads/d4c705bd7e091fb3476ea13cf6510a18/12.png)
**To Reproduce**
1.modify the dhclinet.c code.
![123](/uploads/262ce731af9ff9f15af699f2fe373b7a/123.png)
2.make: Compile the modified code.
3.run the following command:
gdb –args ./dhclient –d xxx
(xxx indicates the network adapter name.)
4.Delete the
/var/lib/dhclient/dhclient.leases
file when the gdb is suspended after running.
**Expected behavior**
A coredump occurs.
**Environment:**
- DHCP version 4.4.2
**Additional Information**
Analyze the code and construct a scenario where the white-box problem is the same as the error code. The black-box problem cannot be reproduced.
**Contacting you**
Email : 1041793952@qq.comhttps://gitlab.isc.org/isc-projects/stork/-/issues/458Replace 'appID' with server name or IP2021-03-01T20:15:48ZVicky Riskvicky@isc.orgReplace 'appID' with server name or IPthe appID is not useful to the humans (I realize it is useful to Stork). the human will be thinking of the Application by hostname or IP address. We need some naming scheme that is also implemented on the Kea server, so the same name can...the appID is not useful to the humans (I realize it is useful to Stork). the human will be thinking of the Application by hostname or IP address. We need some naming scheme that is also implemented on the Kea server, so the same name can be observed on Kea either directly or via Stork. One possibility is to have Stork get some sort of dhcp server 'name' from the Kea server. this could be a dns name but doesn't have to be.
Both users we tested with so far remarked that they didn't know what appID was or how to use it, and they were both searching for some key to associate a Kea server across multiple panels.0.15Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2539systemd unit file's PIDFile path not found for COPR package2021-03-01T12:08:01ZKenneth Portersystemd unit file's PIDFile path not found for COPR packageThe systemd unit file in the Red Hat COPR package has a PIDFile setting not found in the sample named.conf and apparently not compiled in. systemctl fails with a timeout waiting for the PIDFile to be created. It hangs for many seconds be...The systemd unit file in the Red Hat COPR package has a PIDFile setting not found in the sample named.conf and apparently not compiled in. systemctl fails with a timeout waiting for the PIDFile to be created. It hangs for many seconds before failing.
The value provided is:
PIDFile=/var/opt/isc/scls/isc-bind/run/named/named.pid
A better choice might be:
PIDFile=/run/named/named.pid
The example named.conf should include this setting.
BIND 9.16.12 (Stable Release) <id:aeb943d>
OS is CentOS 8.
Package from here:
https://copr.fedorainfracloud.org/coprs/isc/bind/
I edited the unit file's PIDFile setting (using a systemd drop-in file) and the service came up normally, using my configuration from named 9.10.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2541move expired/removed zone keys to a different directory2021-03-01T09:45:27ZMichel Lespinassemove expired/removed zone keys to a different directory### Description
Currently the configured key-directory holds both current and expired zone keys. With a dnssec-policy rotating keys on a regular basis, expired keys accumulate over time, and as they are placed in the same key-directory ...### Description
Currently the configured key-directory holds both current and expired zone keys. With a dnssec-policy rotating keys on a regular basis, expired keys accumulate over time, and as they are placed in the same key-directory as current keys, it would be easy for an administrator trying to archive/remove expired keys to get it wrong and mistakenly remove keys that are still in use.
Maybe moving expired keys to a different location would help reduce the risk of such mistakes ?
### Request
- Allow specifying a different directory for expired keys to be automatically moved to.
- By default, keys in that archive directory should not show in rndc dnssec -status output.
### Links / referenceshttps://gitlab.isc.org/isc-projects/stork/-/issues/495Prevent getting apps state for unauthorized machine2021-02-26T18:32:56ZMarcin SiodelskiPrevent getting apps state for unauthorized machineThis is a result of the following comment https://gitlab.isc.org/isc-projects/stork/-/merge_requests/272#note_196568.
As Tomek pointed out, if you click on the unauthorized machine you're taken to the same view as in case of authorized ...This is a result of the following comment https://gitlab.isc.org/isc-projects/stork/-/merge_requests/272#note_196568.
As Tomek pointed out, if you click on the unauthorized machine you're taken to the same view as in case of authorized machines. There used to be a button Get Latest State which, if clicked, would fetch apps information regardless if the machine is authorized or not. The button was removed for unauthorized machines in #485, but it is still possible to fetch the state via REST. I think it should be secured at the REST level, i.e. when the machine is unauthorized we should not fetch apps state.https://gitlab.isc.org/isc-projects/bind9/-/issues/2335TLSDNS refactoring2021-02-26T15:14:59ZOndřej SurýTLSDNS refactoringThe TLSDNS needs to be refactored to use libuv/OpenSSL directly, and not via netmgr layers.The TLSDNS needs to be refactored to use libuv/OpenSSL directly, and not via netmgr layers.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/162Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP se...2021-02-26T09:44:54ZTomasz Kazimierz MotylInconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up.**Describe the bug**
Whilst connecting a host running dhclient of version = 4.4.1 to a network with DHCP server temporarily disabled (a brief scheduled maintenance). The observed behaviour (please find the details below) hasn't been exa...**Describe the bug**
Whilst connecting a host running dhclient of version = 4.4.1 to a network with DHCP server temporarily disabled (a brief scheduled maintenance). The observed behaviour (please find the details below) hasn't been exactly anticipated and we haven't seen any corresponding entry in the 4.4.2 release notes.
**To Reproduce**
**Dhclient config:**
```
timeout 131;
retry 33;
reboot 9;
select-timeout 3;
initial-interval 2;
interface "eth1" {
request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, ntp-servers, vendor-encapsulated-options, dhcp-renewal-time, dhcp-rebinding-time;
require subnet-mask;
}
```
**Current time:** Wed 03 Feb 2021 12:33:20 PM PST
**Leases file - case 1 with the lease expiration set in half an hour time:**
```
lease {
interface "eth1";
fixed-address 10.1.1.92;
option subnet-mask 255.255.255.128;
option dhcp-lease-time 3600;
option routers 10.1.1.1;
option dhcp-message-type 5;
option dhcp-server-identifier ....;
option domain-name-servers ....
option domain-name "....";
renew 3 2021/02/03 13:02:23;
rebind 3 2021/02/03 13:03:23;
expire 3 2021/02/03 13:05:23;
}
```
**Observation:**
Starts with DHCP discover (why not with DHCP request whilst the lease is still valid?), and continues search for a DHCP Server. according to the timings set-up in the config.
Now let's set the expiries for renew, rebind and expire to tomorrow date so leases file would resemble as follows (**leases' database case 2**):
```
lease {
interface "eth1";
fixed-address 10.1.1.92;
option subnet-mask 255.255.255.128;
option routers 10.1.1.1;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option domain-name-servers ...;
option dhcp-server-identifier ...;
option domain-name "...";
renew 4 2021/02/04 13:10:16;
rebind 4 2021/02/04 13:11:16;
expire 4 2021/02/04 13:13:16;
}
```
It starts with 3 DHCP Requests (expected I daresay - we wonder why it hasn't started with DHCP requests with the sooner lease expiration date & time. It stops sending out the DHCP discover after the timeout to wake up and start sending them out around the midnight when the date will become 4th of February 2021 (unexpected).
Would there be something we do not fully realise? Is the afore an expected behaviour? If so would there be a way for a continuous DHCP discovery, whilst formerly leased IP would be in use after, timeout = 131 [s] passing and no response from a DHCP server?
**Expected behavior**
1. The behaviour ought to be consistent for both cases **1** & **2** :
- As in both cases: 1 &2 the lease is still valid dhclient should start with DHCP Request
- When the lease expiration date is set for some day in the future the DHCP Discover should not stop after timeout time
**Environment:**
- ISC DHCP version: v4.4.1
- OS: Ubuntu 20.04 x64
- Which features were compiled in
**Additional Information**
Please see **steps to reproduce**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
We haven't seen any corresponding entry in the 4.4.2 release notes.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time to consider migration?
N/A as kea is a server
- Are you sure what you would like to do is not possible using some other mechanisms?
If there is another mechanism, other than wiping out leases' DB at the boot time I would be extremely interested in getting know about it.
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
Not yet. I shall ask the question with the link to this particular issue. I deem having a record is mutually beneficial.
**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 fix in a subsequent maintenance release.
**Describe alternatives you've considered**
It is more of a sighting at this stage and perhaps originating in some deficiency in the existent documentation. We are uncertain at this stage where the problem lies. It looks like some flaw in the logic implementation.
**Additional context**
N/A
**Funding its development**
Yup, I would be happy to donate.
**Participating in development**
I would be willing to help with testing a WIP, patch or unreleased code.
**Contacting you**
e-mail: butterfly_tm666@yahoo.com; tomasz.motyl@se.com
With my best wishes
Tomasz Motylhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/157host declarations not synced to failover partner2021-02-25T19:14:03ZBalakumaranhost declarations not synced to failover partnerHost declarations added with omAPI to the primary failover peer is not syncing to secondary peer.Host declarations added with omAPI to the primary failover peer is not syncing to secondary peer.https://gitlab.isc.org/isc-projects/kea/-/issues/1704Release 1.9.5 checklist2021-02-25T08:27:15ZMichal NowikowskiRelease 1.9.5 checklist---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2
1. [x] Finish release notes and conduct its review
1. [ ] Run [release-pkgs-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
The following steps may involve changing files in the repository.
1. [x] Create a Kea issue for code changes that will be made due to the following checks:
1. Check User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] Update information in sources about copyright dates, new version, etc, script: [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh).
1. [x] Regenerate parsers using docs.isc.org, script: [regen-parsers.sh](https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/regen-parsers.sh).
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
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check sizes - is new package reasonable?
1. Check the installation tree, compare it with the previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from the current release has a lower number than the corresponding lib from the previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins
1. Go to [release-tarball-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. 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)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. [x] If none of the results force you to fix and rebuild the package, send sanity checks request if not already triggered automatically by `release-tarball-upload-internal`.
## Sanity Checks
1. [x] Create Sanity Checks announcement, put there:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to an issue created in next step
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
1. [x] Create a GitLab issue for sanity checks, put there the announcement
1. [x] Send the announcement to dhcp-team@isc.org
## Releasing Tarballs
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final
1. [x] When the upload is completed then copy SHA checksums from the log and write an email to signers@isc.org requesting signatures
of final tarballs on repo.isc.org indicating release directories. Attach SHA checksums to the request.
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Create git tags `Kea-a.b.c` in Kea main and premium repositories.
1. Update ReadTheDocs
1. [x] Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. [x] Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. [ ] For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major version, sweng will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [ ] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [x] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] Bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
- [ ] Bump up `REF_KEA_VERSION` in `qa-dhcp/kea/jenkins/tarball-internal.jenkinsfile` to `x.y.z` i.e. released versionkea1.9.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2526Example configuration for authoritative DNS server for docker container is mi...2021-02-24T20:45:03ZMalte BögershausenExample configuration for authoritative DNS server for docker container is misleadingThe example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```...The example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```
mean that the DNS server is not accessible from outside the container (and there is no reason to access it from inside the container).
Additionally there is no filename suggested for the config file. If `named.conf` is used the default structure for config files is overridden.https://gitlab.isc.org/isc-projects/kea/-/issues/1728bump up version in configure.ac2021-02-24T12:26:41ZWlodzimierz Wencelbump up version in configure.ackea1.9.6Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1698Fix broken MySQL schema when upgrading from 1.9.2, 1.9.3 to 1.9.42021-02-23T17:44:37ZTomek MrugalskiFix broken MySQL schema when upgrading from 1.9.2, 1.9.3 to 1.9.4As reported by a customer, see [support#17175](https://support.isc.org/Ticket/Display.html?id=17175), there is a problem with the MySQL schema upgrade. This has been traced to 9.5 schema version script being edited after it was released....As reported by a customer, see [support#17175](https://support.isc.org/Ticket/Display.html?id=17175), there is a problem with the MySQL schema upgrade. This has been traced to 9.5 schema version script being edited after it was released.
The following actions should be taken:
- [x] document the issue in known issues
- [x] provide a script that allows people who already tried to upgrade to fix their DB and continue
- [x] alter the 9.4_to_9.5 upgrade script to not introduce the changes
- [x] create 9.5_to_9.6 upgrade that introduces the changes properlykea1.9.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1681kea-admin db-upgrade reports permission denied2021-02-23T17:44:36ZAndrei Pavelandrei@isc.orgkea-admin db-upgrade reports permission denied`kea-admin db-upgrade` for all backends reports permission denied on the upgrade scripts. Affects tarball and pkgs. Does not affect `kea-admin db-init`.
Reported on [RT#17594](https://support.isc.org/Ticket/Display.html?id=17594).`kea-admin db-upgrade` for all backends reports permission denied on the upgrade scripts. Affects tarball and pkgs. Does not affect `kea-admin db-init`.
Reported on [RT#17594](https://support.isc.org/Ticket/Display.html?id=17594).kea1.9.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1672DHCPv4 fixed fields, such as boot-file-name, value precedence order is incons...2021-02-23T16:31:18ZThomas MarkwalderDHCPv4 fixed fields, such as boot-file-name, value precedence order is inconsistent with optionsThere are three "fixed" fields next-server, server-hostname, and boot-file-name sent in DHCPv4 ACKs.
They are not handled like configured options, rather they are handled in Dhcpv4Srv::setFixedFields(). This function cycles through all...There are three "fixed" fields next-server, server-hostname, and boot-file-name sent in DHCPv4 ACKs.
They are not handled like configured options, rather they are handled in Dhcpv4Srv::setFixedFields(). This function cycles through all classes associated with the client's packet, in the order they are associated, and uses the last value for a given option found. This is exactly the opposite of what we do for configured options. For those we evaluate the classes in the associated order BUT we use the first value for a given option. For example, using the following config:
```
"client-classes": [
{
"name":"one",
"boot-file-name":"one.boot",
"option-data": [
{
"name": "domain-name-servers",
"data": "1.1.1.1"
}]
},
{
"name":"two",
"boot-file-name":"two.boot",
"option-data": [
{
"name": "domain-name-servers",
"data": "2.2.2.2"
}]
}
],
"subnet4": [
{
"id": 1500,
"subnet": "178.0.0.0/8",
"pools": [ { "pool": "178.16.1.0 - 178.16.1.255" } ],
"reservations": [
{
"hw-address": "08:00:27:25:d3:f4",
"client-classes": [ "two", "one" ]
}]
}],
```
The value for boot-file-name will be "one.boot" and doman-name-servers will be "2.2.2.2". If we associate the classes in the reverse order, (i.e "one", "two") then I get "two.boot" and "1.1.1.1". This is inconsistent and in my opinion, broken. They should do it the same way. In this case, fixed fields should follow options behavior. The options ordering for classes is clearly documented in the ARM:
https://kea.readthedocs.io/en/latest/arm/classify.html#client-classification-overviewkea1.9.5Thomas MarkwalderThomas Markwalder