ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-03-28T14:42:19Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3956mem.c:344: INSIST(ret != ((void *)0)) in mem_get()2023-03-28T14:42:19ZMichal Nowakmem.c:344: INSIST(ret != ((void *)0)) in mem_get()`tcp-ns1` hit `INSIST` on "long TCP messages" test (isc-projects/bind9#1996 / CVE-2020-8620).
Job [`system:gcc:bullseye:amd64cross32`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3256605) failed for `bind-9.18-sub`:
```
I:tcp:checki...`tcp-ns1` hit `INSIST` on "long TCP messages" test (isc-projects/bind9#1996 / CVE-2020-8620).
Job [`system:gcc:bullseye:amd64cross32`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3256605) failed for `bind-9.18-sub`:
```
I:tcp:checking that BIND 9 doesn't crash on long TCP messages (10)
I:tcp:sending 300000 time(s): 00010000000100000000000003697363036f72670000fc0001
I:tcp:............................................................................................................................................................................................................................................................................................................
I:tcp:sent 1621109 bytes to 10.53.0.1:14693
I:tcp:failed
I:tcp:exit status: 1
I:tcp:stopping servers
I:tcp:ns1 crashed on shutdown
...
I:tcp:ns1 crashed on shutdown
I:tcp:ns1 didn't die when sent a SIGTERM
I:tcp:ns1 died before a SIGABRT was sent
I:tcp:stopping servers failed
I:tcp:Core dump(s) found: /builds/isc-private/bind9/bin/tests/system/tcp/ns1/core.25933
D:tcp:backtrace from /builds/isc-private/bind9/bin/tests/system/tcp/ns1/core.25933:
D:tcp:--------------------------------------------------------------------------------
D:/builds/isc-private/bind9/bin/tests/system/tcp:Core was generated by `/builds/isc-private/bind9/bin/named/.libs/named -D tcp-ns1 -X named.lock -m rec'.
D:/builds/isc-private/bind9/bin/tests/system/tcp:Program terminated with signal SIGABRT, Aborted.
D:/builds/isc-private/bind9/bin/tests/system/tcp:#0 0xf7f0d069 in __kernel_vsyscall ()
D:/builds/isc-private/bind9/bin/tests/system/tcp:[Current thread is 1 (Thread 0xef47cb40 (LWP 25984))]
D:/builds/isc-private/bind9/bin/tests/system/tcp:#0 0xf7f0d069 in __kernel_vsyscall ()
D:/builds/isc-private/bind9/bin/tests/system/tcp:#1 0xf71fbe02 in raise () from /lib/i386-linux-gnu/libc.so.6
D:/builds/isc-private/bind9/bin/tests/system/tcp:#2 0xf71e4306 in abort () from /lib/i386-linux-gnu/libc.so.6
D:/builds/isc-private/bind9/bin/tests/system/tcp:#3 0x5659c792 in assertion_failed (file=0xf7c68be3 "mem.c", line=344, type=isc_assertiontype_insist, cond=0xf7c68c02 "ret != ((void *)0)") at main.c:238
D:/builds/isc-private/bind9/bin/tests/system/tcp:#4 0xf7c2baca in isc_assertion_failed (file=0xf7c68be3 "mem.c", line=344, type=isc_assertiontype_insist, cond=0xf7c68c02 "ret != ((void *)0)") at assertions.c:48
D:/builds/isc-private/bind9/bin/tests/system/tcp:#5 0xf7c3b814 in mem_get (ctx=ctx@entry=0xf2c6f000, size=size@entry=65535, flags=<optimized out>) at mem.c:344
D:/builds/isc-private/bind9/bin/tests/system/tcp:#6 0xf7c3bcbb in isc__mem_get (ctx=0xf2c6f000, size=65535, alignment=0, file=0xf79d9000 "client.c", line=349) at mem.c:761
D:/builds/isc-private/bind9/bin/tests/system/tcp:#7 0xf79a7560 in client_allocsendbuf (client=client@entry=0x102534, buffer=buffer@entry=0xef476664, datap=datap@entry=0xef47668c) at client.c:349
D:/builds/isc-private/bind9/bin/tests/system/tcp:#8 0xf79a8cae in ns_client_send (client=0x102534) at client.c:534
D:/builds/isc-private/bind9/bin/tests/system/tcp:#9 0xf79aa5d0 in ns_client_error (client=0x102534, result=<optimized out>) at client.c:952
D:/builds/isc-private/bind9/bin/tests/system/tcp:#10 0xf79d8260 in ns_xfr_start (client=0x102534, reqtype=252) at xfrout.c:1209
D:/builds/isc-private/bind9/bin/tests/system/tcp:#11 0xf79cafad in ns_query_start (client=0x102534, handle=0x102400) at query.c:12511
D:/builds/isc-private/bind9/bin/tests/system/tcp:#12 0xf79ad59b in ns__client_request (handle=<optimized out>, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2256
D:/builds/isc-private/bind9/bin/tests/system/tcp:#13 0xf7c186e0 in isc__nm_async_readcb (worker=0x0, ev0=0xef47841c) at netmgr/netmgr.c:2885
D:/builds/isc-private/bind9/bin/tests/system/tcp:#14 0xf7c187f5 in isc__nm_readcb (sock=0xf000fe00, uvreq=0xe72b4600, eresult=ISC_R_SUCCESS) at netmgr/netmgr.c:2858
D:/builds/isc-private/bind9/bin/tests/system/tcp:#15 0xf7c20cfc in isc__nm_tcpdns_processbuffer (sock=0xf000fe00) at netmgr/tcpdns.c:842
D:/builds/isc-private/bind9/bin/tests/system/tcp:#16 0xf7c14e3d in processbuffer (sock=0xf000fe00) at netmgr/netmgr.c:2308
D:/builds/isc-private/bind9/bin/tests/system/tcp:#17 isc__nm_process_sock_buffer (sock=0xf000fe00) at netmgr/netmgr.c:2330
D:/builds/isc-private/bind9/bin/tests/system/tcp:#18 0xf7c20ee1 in isc__nm_tcpdns_read_cb (stream=0xf0010254, nread=65537, buf=0xef47857c) at netmgr/tcpdns.c:905
D:/builds/isc-private/bind9/bin/tests/system/tcp:#19 0xf761fad1 in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
D:/builds/isc-private/bind9/bin/tests/system/tcp:#20 0xf76203df in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
D:/builds/isc-private/bind9/bin/tests/system/tcp:#21 0xf7627056 in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
D:/builds/isc-private/bind9/bin/tests/system/tcp:#22 0xf761496e in uv_run () from /usr/lib/i386-linux-gnu/libuv.so.1
D:/builds/isc-private/bind9/bin/tests/system/tcp:#23 0xf7c1a8de in nm_thread (worker0=0xf4e43bc0) at netmgr/netmgr.c:698
D:/builds/isc-private/bind9/bin/tests/system/tcp:#24 0xf7c545a6 in isc__trampoline_run (arg=0x57751e80) at trampoline.c:189
D:/builds/isc-private/bind9/bin/tests/system/tcp:#25 0xf73bb0b4 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
D:/builds/isc-private/bind9/bin/tests/system/tcp:#26 0xf72cb2c6 in clone () from /lib/i386-linux-gnu/libc.so.6
D:tcp:--------------------------------------------------------------------------------
D:tcp:full backtrace from /builds/isc-private/bind9/bin/tests/system/tcp/ns1/core.25933 saved in /builds/isc-private/bind9/bin/tests/system/tcp/ns1/core.25933-backtrace.txt
D:tcp:core dump /builds/isc-private/bind9/bin/tests/system/tcp/ns1/core.25933 archived as /builds/isc-private/bind9/bin/tests/system/tcp/ns1/core.25933.gz
```
[core.25933-backtrace.txt](/uploads/2d8cac4bc95c644562e5a0fefd486285/core.25933-backtrace.txt)
[named.run](/uploads/84f497eaa27f9ac10d267325a207149a/named.run)April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)https://gitlab.isc.org/isc-projects/stork/-/issues/936connection refused: stork machine registration2023-02-14T16:42:50ZAdam Chaitconnection refused: stork machine registrationWhen I run stork-agent register --server-url http://127.0.0.1 i get the following returned and I can't figure out how to resolve the "connection refused":
>>>> Server access token (optional):
>>>> IP address or FQDN of the host with Sto...When I run stork-agent register --server-url http://127.0.0.1 i get the following returned and I can't figure out how to resolve the "connection refused":
>>>> Server access token (optional):
>>>> IP address or FQDN of the host with Stork Agent (for the Stork Server connection) [kea]:
>>>> Port number that Stork Agent will listen on [8080]:
INFO[2023-01-12 16:58:44] register.go:160 Agent token stored in /var/lib/stork-agent/tokens/agent-token.txt
INFO[2023-01-12 16:58:44] register.go:161 Agent key, agent token, and CSR (re)generated
INFO[2023-01-12 16:58:44] register.go:449 =============================================================================
INFO[2023-01-12 16:58:44] register.go:450 AGENT TOKEN: 71DACCA3209973F663246FE581CBFCE9FC9F000B0EF19A6B50030CCE35B35F61
INFO[2023-01-12 16:58:44] register.go:451 =============================================================================
INFO[2023-01-12 16:58:44] register.go:454 Authorize the machine in the Stork web UI
INFO[2023-01-12 16:58:44] register.go:471 Try to register agent in Stork Server
ERRO[2023-01-12 16:58:44] register.go:474 problem registering machine: Post "http://127.0.0.1/api/machines": dial tcp 127.0.0.1:80: connect: connection refused
FATA[2023-01-12 16:58:44] main.go:134 Registration failed1.10Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea/-/issues/2840Changes for Kea 2.3.7 release2023-07-17T13:58:21ZWlodzimierz WencelChanges for Kea 2.3.7 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.3.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2837bump up lib versions for 2.3.72023-07-17T13:58:21ZWlodzimierz Wencelbump up lib versions for 2.3.7kea2.3.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2836update pgsql package in rhel 9 installation in hammer2023-07-17T13:58:22ZWlodzimierz Wencelupdate pgsql package in rhel 9 installation in hammerpackage name has changed, hammer needs to be updatedpackage name has changed, hammer needs to be updatedkea2.3.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2823Configure allocators in the config backend2023-07-31T09:43:16ZMarcin SiodelskiConfigure allocators in the config backendIt is now possible to select an allocator at the global, subnet and shared network levels. We must extend the config backend to be able to select the allocators from there. Right now, it is only possible to select them via the config fil...It is now possible to select an allocator at the global, subnet and shared network levels. We must extend the config backend to be able to select the allocators from there. Right now, it is only possible to select them via the config file or subnet_cmds.kea2.3.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2814hammer: Enable uploading of ddeb packages to repository.2023-07-17T13:58:22ZMarcin Godzinahammer: Enable uploading of ddeb packages to repository.Enable uploading of ddeb packages to repository by hammerEnable uploading of ddeb packages to repository by hammerkea2.3.7Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/2813Bump version in configure.ac to 2.3.7-git2023-07-17T13:58:22ZMarcin GodzinaBump version in configure.ac to 2.3.7-gitBump version in `configure.ac` to 2.3.7-gitBump version in `configure.ac` to 2.3.7-gitkea2.3.7Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/2794suboption 2 (remote id) of option 82 (agent information option) is incorrectl...2023-07-17T13:58:22ZWlodzimierz Wencelsuboption 2 (remote id) of option 82 (agent information option) is incorrectly parsed if it ends with 00During blq v4 testing I came across small corner case. If suboption 2 (remote id), of option 82 (agent information option) ends with 00 (or it's multiple) - Kea will trim zeros.
Example:
* client sends option 82 - 52 08 02 06 01 02 0c 0...During blq v4 testing I came across small corner case. If suboption 2 (remote id), of option 82 (agent information option) ends with 00 (or it's multiple) - Kea will trim zeros.
Example:
* client sends option 82 - 52 08 02 06 01 02 0c 03 0a 22
* 52 - code
* 08 - length of entire option 82
* 02 - code of suboption
* 06 - length of suboption
* 01 02 0c 03 0a 22 - content of suboption
Kea parse, and send back correct option (52 08 02 06 01 02 0c 03 0a 22) , but if:
* client sends option 82 - 52 08 02 06 01 02 0c 03 0a 00 Kea will send back:
* 52 - code
* 08 - length of entire option 82
* 02 - code of suboption
* 05 - length of suboption << reduced length
* 01 02 0c 03 0a - content of suboption << smaller value than client send
This will go further, Kea will trim not only last octet but all 00 from the back.
Please compare packets 5 and 6 from shows described scenario. 1 - 28 packets, Discovery<>Offer Request<>Reply exchanges use 00 more at the end. 29-60 packets show similar scenario but with suboption 12 (relay id) which is correct [capture.pcap](/uploads/6fdac068fae658d6e54a26b36c98fd4a/capture.pcap)
Saved leases during this test [leases.csv](/uploads/cbb90f0ad7ab20980bdb6087d4fb6d19/leases.csv)
Logs [kea.log](/uploads/36818b202478ffecd36db0bacfb52c41/kea.log)
This is not affecting BLQ work, this option is trimmed also in BLQ. The same error on saving leases and retrieving it leads to correctly returned leases. That is if we assume that client will accept different content of option 82 and not discard an offer.
If suboption 12 (relay id) is used there are NO similar problems.kea2.3.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2780Free lease queue allocator2023-07-17T13:58:22ZMarcin SiodelskiFree lease queue allocatorThe Free lease queue allocator populates leases at the startup or reconfiguration in the server's memory. It installs callbacks in LeaseMgr using #2764. When a DHCP request comes in, it picks the next free lease for a subnet and offers i...The Free lease queue allocator populates leases at the startup or reconfiguration in the server's memory. It installs callbacks in LeaseMgr using #2764. When a DHCP request comes in, it picks the next free lease for a subnet and offers it to the client. When the client requests the lease and the lease is allocated, the callbacks are invoked causing the lease removal from the populated list. Similarly, when the lease is deleted or reclaimed, the lease is put back into the queue.
This ticket doesn't necessarily contain optimizations to inherit populated leases across reconfigurations. It means that the leases will be populated every time, the server is reconfigured. But, that's fine for the first step. We will address it in another ticket.
Also see: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/free-lease-queues-designkea2.3.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2754Possible problem with clock skew in the HA Hook library2023-07-17T13:58:22ZDarren AnkneyPossible problem with clock skew in the HA Hook libraryA curious discrepancy was noticed during a HA failover event. Contact was lost with the Primary server. There seems to have been some severe clock skew on the Primary server. When the primary server returned to service, and the clock sk...A curious discrepancy was noticed during a HA failover event. Contact was lost with the Primary server. There seems to have been some severe clock skew on the Primary server. When the primary server returned to service, and the clock skew was noticed, both HA partners entered TERMINATED state. The discrepancy is that the log line on the secondary referencing the clock skew seems to give a time received from the primary which was from the last successful heartbeat before the outage began.
Last successful heartbeat logged on the primary prior to the outage:
```
2023-01-11 21:14:19.143 INFO [kea-dhcp4.commands/1727327.140540724561664] COMMAND_RECEIVED Received command 'ha-heartbeat'
```
Secondary's log of the clock skew (presumably post outage):
```
2023-01-11 21:17:47.784 ERROR [kea-dhcp4.ha-hooks/1724040.139887997884160] HA_HIGH_CLOCK_SKEW_CAUSES_TERMINATION my time: 2023-01-11 21:17:47, partner's time: 2023-01-11 21:14:19, partner's clock is 208s behind, causing HA service to terminate
```
Primary's log of the clock skew (assumedly at the same moment as the secondary's log about entering the TERMINATED state):
```
2023-01-11 21:24:05.763 ERROR [kea-dhcp4.ha-hooks/1727327.140540774917888] HA_TERMINATED HA service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
```
Assuming that the clock skews were logged at the same real time on both servers, then there is a discrepancy here. The Secondary claims that the primary's clock is 208s behind. However, the Primary's clock APPEARS to be 5 or 6 minutes ahead from the times logged.
[RT 21796](https://support.isc.org/Ticket/Display.html?id=21796)kea2.3.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2753Implement v4 BLQ methods for SQL2023-07-17T13:58:22ZFrancis DupontImplement v4 BLQ methods for SQLRequires #2752 and implements anything needed for BLQ v4 in the SQL implementation of the lease API at the exception of transition from a previous version of the database i.e. the core part of an upgrade command of the (B)LQ hook (this w...Requires #2752 and implements anything needed for BLQ v4 in the SQL implementation of the lease API at the exception of transition from a previous version of the database i.e. the core part of an upgrade command of the (B)LQ hook (this will be in #2623 and is useful only with long term leases).kea2.3.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2752Update SQL schemas for BLQ v4 new columns2023-07-17T13:58:22ZFrancis DupontUpdate SQL schemas for BLQ v4 new columnsFor BLQ v4 the SQL schemas must be updated to add two columns to DHCPv4 lease table for relay id and remote id, and of course the corresponding index.
This ticket is about the schema update and associated code (but not about lease API i...For BLQ v4 the SQL schemas must be updated to add two columns to DHCPv4 lease table for relay id and remote id, and of course the corresponding index.
This ticket is about the schema update and associated code (but not about lease API implementation).kea2.3.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2749Enable MT in the HA config by default2023-07-17T13:58:22ZFrancis DupontEnable MT in the HA config by default#2402 is only about the core.#2402 is only about the core.kea2.3.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1275V6 LeaseQuery by address will not return a delegated prefix which contains qu...2023-07-17T13:58:21ZThomas MarkwalderV6 LeaseQuery by address will not return a delegated prefix which contains query addressThe following discussion from https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/112
should be addressed:
* [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/112#note_140706...The following discussion from https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/112
should be addressed:
* [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-private/kea-premium/-/merge_requests/112#note_140706):
> The RFC is very loose about this (this explains why you skipped it) but the lease query works with prefix delegation too, for instance:
>
> ```
> Query by IPv6 address - This query allows a requestor to request
> from a server the bindings for a client that either is bound to
> the address or has been delegated the prefix that contains the
> address.
> ```
>
> Of course even logically you should not assign addresses in a prefix you delegates this raises the question to know if the query is for an address or a prefix. It should have been far clearer / simpler to use a dedicated query type or iaprefix sub option...
>
> I propose to postpone (i.e. another issue or MR) the prefix support. If you agree create a follower and resolve this thread.kea2.3.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/549Implement reservation-update command2023-07-17T13:58:21ZTomek MrugalskiImplement reservation-update commandWe currently have commands that add, retrieve and delete host reservations. We're missing a command to update existing reservations.We currently have commands that add, retrieve and delete host reservations. We're missing a command to update existing reservations.kea2.3.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2846update configure.ac for 2.3.82023-07-17T13:58:21ZWlodzimierz Wencelupdate configure.ac for 2.3.8kea2.3.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2842Sanity checks 2.3.7 rc32023-05-08T12:33:12ZWlodzimierz WencelSanity checks 2.3.7 rc3We are now at step SANITY CHECKS of Kea 2.3.7 rc3.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.3.7 rc3.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.3.7-rc3`
* `/data/shared/sweng/kea/releases/premium-2.3.7-rc3`
* `/data/shared/sweng/kea/releases/subscription-2.3.7-rc3`
* `/data/shared/sweng/kea/releases/enterprise-2.3.7-rc3`
```
SHA256 (2.3.7-rc3/kea-2.3.7.tar.gz) = 3aa58fd8042ce49a502ddaa5fa88f5700073ffe03ff967e9f9b7cc32f58cc65b
SHA256 (enterprise-2.3.7-rc3/kea-enterprise-2.3.7.tar.gz) = de7c3c15b8ad7b781c71488e09380af9076294daca56804b2804a3fba8872215
SHA256 (subscription-2.3.7-rc3/kea-subscription-2.3.7.tar.gz) = b472e00263c73f7095d619dd5c08ee76999c6e608498959f83bba81a8f661c16
SHA256 (premium-2.3.7-rc3/kea-premium-2.3.7.tar.gz) = a0156baccd01374c8b778b50e11609276eb71c459d3bcace8818133e68e3f18b
```
#### Packages on packages.aws.isc.org
* [APK: 2.3.7-r20230421110852](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20230421110852.apk)
* [deb: 2.3.7-isc20230421110852](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.3.7-isc20230421110852)
* [RPM: 2.3.7-isc20230421110852\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.3.7-isc20230421110852*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1105/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.3.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/28392.3.7 release checklist2023-05-08T12:16:50ZWlodzimierz Wencel2.3.7 release checklist# 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 fr...# 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.
For new stable releases or maintenance releases, please don't use `kea-dev` build farm. Use dedicated build farm for each release cycle.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/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. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
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-2.1.0
1. [x] Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
1. [ ] Run [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/) as running parameter `TarballOrPkg` select `packages` and [release-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 1.9.7 --repo-dir ~/isc/repos/kea/` Use `--upload` to commit changes. <br>
Help: `GITLAB_TOKEN="..." ./update-code-for-release.py --help`<br>
This script makes the following changes and actions:
1. run prepare_kea_release.sh that does:
1. add release entries in ChangeLogs
1. update Kea version in configure.ac
1. update copyright years in files that were changed in current year
1. sort message files
1. regenerate message files headers
2. regenerate parsers using Bison from Docker<br>
With `--upload`:
3. create an issue in GitLab for release changes in kea repo
4. create branches and merge requests for kea and kea-premium
5. commit the changes in both repos
6. checkout created branches in both repos
7. commit and push the changes to GitLab server
1. Check manually 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 (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
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] 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 MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) 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 hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages 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 and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) 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 the 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 an error)
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- 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 the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. Kea-2.2.2): <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description: <br>
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- if release engineer is holding personal signing key, please use [sign, verify, and upload script](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh)
- if release enginner do NOT have signing key, please contact team member.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build` button.
- this step is also veryfing sign files
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. 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.
1. [x] Create an issue and a merge request to 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`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [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*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** If it is a new `major.minor` 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.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(Support)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [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)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.3.7Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2804Editorial review of the ARM2023-07-17T13:58:22ZAndrei Pavelandrei@isc.orgEditorial review of the ARMIt's time for another review of the Kea ARM for content, typos, confusion, etc.It's time for another review of the Kea ARM for content, typos, confusion, etc.kea2.3.7Suzanne GoldlustSuzanne Goldlust