ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-08-22T10:04:56Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2683Increase the logging level of some IXFR messages2022-08-22T10:04:56ZMichal NowakIncrease the logging level of some IXFR messages(Originally reported as https://gitlab.isc.org/isc-projects/bind9/-/issues/2671#note_211777.)
I'd like to suggest that we increase the logging level of these messages:
```
xfrout_log1(client, question_name, ques...(Originally reported as https://gitlab.isc.org/isc-projects/bind9/-/issues/2671#note_211777.)
I'd like to suggest that we increase the logging level of these messages:
```
xfrout_log1(client, question_name, question_class,
ISC_LOG_DEBUG(4),
"IXFR version not in journal, "
"falling back to AXFR");
[...]
xfrout_log1(client, question_name,
question_class, ISC_LOG_DEBUG(4),
"IXFR delta size (%zu bytes) "
"exceeds the maximum ratio to "
"database size "
"(%" PRIu64 " bytes), "
"falling back to AXFR",
jsize, dbsize);
```
...perhaps all the way to `ISC_LOG_INFO`. It's not helpful for this to be a mysterious black box. Spurious AXFR fallbacks could be caused by a still-undetected corruption in the journal file, or a computational error counting the size of the database or the journal transactions, and without debug logging, or a full before-and-after copy of the database and journal, it's difficult to sort out which it is.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3440Use DEFAULT_ALGORITHM more often2022-10-03T11:31:41ZMark AndrewsUse DEFAULT_ALGORITHM more oftenUse DEFAULT_ALGORITHM etc. where the specific choice of algorithm is not required.Use DEFAULT_ALGORITHM etc. where the specific choice of algorithm is not required.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/3423When generating rdataset, owner name compression is being applied when it sho...2022-07-15T11:31:17ZGreg ChoulesWhen generating rdataset, owner name compression is being applied when it should not beThe `dns_name_towire2()` takes offset to previous (first) owner name as the last argument which can be use as fast-path for compression pointer. This is used as micro-optimization when generating the rdataset in the answer.
The code co...The `dns_name_towire2()` takes offset to previous (first) owner name as the last argument which can be use as fast-path for compression pointer. This is used as micro-optimization when generating the rdataset in the answer.
The code completely goes around standard DNS compression tables and it ignores the condition when the compressed path is longer (or equal) than uncompressed path.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/3406[PATCH] Clean up OpenSSL usage a bit2022-08-04T04:41:34ZDavid Benjamin[PATCH] Clean up OpenSSL usage a bitI tried to send this as a merge request per the instructions, but I couldn't figure out how to do that. (Trying to fork the repository on GitLab complained "You have reached your project limit" error, and trying to push to a random branc...I tried to send this as a merge request per the instructions, but I couldn't figure out how to do that. (Trying to fork the repository on GitLab complained "You have reached your project limit" error, and trying to push to a random branch on the main repo. Hopefully these diffs are okay.)
Here are a pair of patches to clean up OpenSSL usage a bit:
[0001-Simplify-BN_GENCB-handling.patch](/uploads/8451aa246934bc8c6ec0043f697f0bca/0001-Simplify-BN_GENCB-handling.patch)
> Simplify BN_GENCB handling.
>
> When callback was NULL, bind9 would use BN_GENCB_set_old to set a NULL
> callback because OpenSSL happened to allow a NULL "old" callback, but
> not a NULL "new" callback. Instead, the way top turn off the callback is
> to pass a NULL BN_GENCB itself.
>
> Switch to doing that. Along the way, add a missing NULL check in
> opensslrsa_link.c, in case BN_GENCB_new failed.
(I didn't do this in the patch, but this could probably be further simplified if the BN_GENCB_new wrapper returned a zeroed `malloc(sizeof(BN_GENCB))`, rather than rely on a special `_cb` variable.)
[0002-Remove-DH_clear_flags-call.patch](/uploads/7827844aef88c789734b09a293c7d6c7/0002-Remove-DH_clear_flags-call.patch)
This one took a bit of archaelogy:
> Remove DH_clear_flags call.
>
> These calls have not been needed since OpenSSL 0.9.7h.
>
> This dates to commit 704d6eeab1d8d6a2aeb99c37fa5a97322d9340fc, "Work
> around non-reentrancy in openssl by disabling precomputation in keys".
> This was in the bundled OpenSSL 0.9.3a era and made two changes. First,
> it registered a locking callback because, in those days, OpenSSL needed
> a callback to support locks. Second, it set flags to disable various
> bits of cached state on DH, DSA, and RSA objects.
>
> Looking back in OpenSSL 0.9.3a, that cached state was not protected by a
> lock:
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_3a/crypto/rsa/rsa_eay.c#L137-L142
>
> However, this was fixed in OpenSSL 0.9.7h:
> https://github.com/openssl/openssl/commit/6ec8e63af6c1835a8b222350dbabf7bb2ace094f
>
> The other flags (DSA and RSA) have since fallen away, DSA with the
> removal of DSA altogether (3994b1f9c2bd4438586523fb2e49b0fb847b487b) and
> RSA with 3a8d4a316eae09966c85e7e5befc682bd4744b34, "openssl 0.9.6a and
> higher don't have the RSA locking bug [...] other algorithms still don't
> do locking when performing precomputation [...]".
>
> That seems to be referring to this OpenSSL change, which indeed fixed it
> for RSA but not others:
> https://github.com/openssl/openssl/commit/bb617a9646d95d0454edda995518f370172390e9
>
> The 0.9.7h change above fixed it across the board, but there was never a
> similar update to the workaround for DSA and DH. With such OpenSSL
> versions long since out of support, the last remains of this workaround
> can finally be removed.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/3054"External" memory leaks are not detected by GitLab CI2022-10-05T07:14:03ZMichał Kępień"External" memory leaks are not detected by GitLab CIIf `named`'s memory use grows over time, but that growth is reflected in
the "in use" statistics of libisc memory contexts, tracking down the
source of such growth is a matter of time. However, not all memory that
`named` uses is contai...If `named`'s memory use grows over time, but that growth is reflected in
the "in use" statistics of libisc memory contexts, tracking down the
source of such growth is a matter of time. However, not all memory that
`named` uses is contained in libisc memory contexts: every linked shared
library might also perform its own memory allocations. If those are not
cleaned up properly, core dump examination is no good for tracking them
down unless the "needle" (i.e. what we are looking for) is known
beforehand, which is rarely the case.
The most notable example of this type of problem are memory leaks which
are specific to FreeBSD - these are usually caused by the fact that
libthr (the POSIX Threads implementation FreeBSD currently uses)
allocates memory on the heap for most of its objects upon their
creation. If such an object is a part of an often-recycled data
structure used by `named` (e.g. a socket), missing destructors can lead
to memory exhaustion issues over time, but only on specific operating
systems. This has already happened at least twice so far.
Finding a method of detecting "external" memory leaks in GitLab CI
should prevent such problems from reoccurring in the future.
See #3051August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3454CID 354665: Unchecked return value in bin/named/server.c2022-08-25T13:18:30ZMichal NowakCID 354665: Unchecked return value in bin/named/server.cIn isc-projects/bind9!6362 `putstr()` return values were not being checked (we do it 212 out of 221 times elsewhere in the code):
```
*** CID 354665: (CHECKED_RETURN)
/bin/named/server.c: 16646 in named_server_fetchlimit()
16640 ...In isc-projects/bind9!6362 `putstr()` return values were not being checked (we do it 212 out of 221 times elsewhere in the code):
```
*** CID 354665: (CHECKED_RETURN)
/bin/named/server.c: 16646 in named_server_fetchlimit()
16640 }
16641
16642 if (!first) {
16643 putstr(text, "\n");
16644 }
16645 putstr(text, "Rate limited servers, view ");
>>> CID 354665: (CHECKED_RETURN)
>>> Calling "putstr" without checking return value (as is done elsewhere 212 out of 221 times).
16646 putstr(text, view->name);
16647
16648 dns_adb_getquota(view->adb, &val, NULL, NULL, NULL, NULL);
16649 s = snprintf(tbuf, sizeof(tbuf),
16650 " (fetches-per-server %u):", val);
16651 if (s < 0 || (unsigned)s > sizeof(tbuf)) {
/bin/named/server.c: 16645 in named_server_fetchlimit()
16639 continue;
16640 }
16641
16642 if (!first) {
16643 putstr(text, "\n");
16644 }
>>> CID 354665: (CHECKED_RETURN)
>>> Calling "putstr" without checking return value (as is done elsewhere 212 out of 221 times).
16645 putstr(text, "Rate limited servers, view ");
16646 putstr(text, view->name);
16647
16648 dns_adb_getquota(view->adb, &val, NULL, NULL, NULL, NULL);
16649 s = snprintf(tbuf, sizeof(tbuf),
16650 " (fetches-per-server %u):", val);
```
@each If you think this does not need to be fixed, feel free to close this and mark appropriately in Coverity Scan dashboard's `bind-master` project.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3460BIND cache-cleaning bug in cleanup_dead_nodes()2022-11-02T15:14:40ZCathy AlmondBIND cache-cleaning bug in cleanup_dead_nodes()As reported in Support Ticket [#20948](https://support.isc.org/Ticket/Display.html?id=20948) against BIND 9.16.23-S1
The ISC BIND subscription edition modifies the rbtdb cache data
structure for EDNS CLIENT-SUBNET. It appears that the C...As reported in Support Ticket [#20948](https://support.isc.org/Ticket/Display.html?id=20948) against BIND 9.16.23-S1
The ISC BIND subscription edition modifies the rbtdb cache data
structure for EDNS CLIENT-SUBNET. It appears that the CLIENT-SUBNET
patch was ported to the 9.16 subscription version from a previous
branch.
There is a bug in cleanup_dead_nodes() which causes the cache to
overflow "max-cache-size" and keep growing. This normally may not happen
in the codepath via ISC BIND's overmem_purge(), or happen to a less
degree, but NIOS makes some changes that causes a far greater number of
nodes to enter the deadnodes lists. Nevertheless, the overflow occurs
eventually due to a bug in cleanup_dead_nodes(), and it might occur in
ISC BIND too.
The bug occurs due to the ECS cache changes, but it can occur even when
ECS is disabled as the modified cache is always used.
```diff
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index f553684..96d1d41 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -2204,20 +2204,36 @@ cleanup_dead_nodes(dns_rbtdb_t *rbtdb, int bucketnum) {
if (is_leaf(node) && rbtdb->task != NULL) {
send_to_prune_tree(rbtdb, node, isc_rwlocktype_write);
- } else if (node->down == NULL && node->data == NULL) {
+ } else if (node->down == NULL &&
+ (node->data == NULL ||
+ ((((rbtdb_data_t *) node->data)->nonecs_data == NULL) &&
+ (((rbtdb_data_t *) node->data)->ecs_root == NULL))))
+ {
/*
* Not a interior node and not needing to be
* reactivated.
*/
delete_node(rbtdb, node);
- } else if (node->data == NULL) {
+ } else if (node->data == NULL ||
+ ((((rbtdb_data_t *) node->data)->nonecs_data == NULL) &&
+ (((rbtdb_data_t *) node->data)->ecs_root == NULL)))
+ {
/*
* A interior node without data. Leave linked to
* to be cleaned up when node->down becomes NULL.
*/
ISC_LIST_APPEND(rbtdb->deadnodes[bucketnum], node,
deadlink);
+ } else {
+ /*
+ * XXXMUKS: Here, node has been removed from the
+ * deadnodes[bucketnum] list, and appears to
+ * fall off the list. It should be commented so
+ * here, as the implicit removal appears
+ * surprising.
+ */
}
+
node = ISC_LIST_HEAD(rbtdb->deadnodes[bucketnum]);
count--;
}
```
There also seems to be a minor bug in KEEP_NODE(). However the cache
cleans up properly nevertheless and this part of the sub-expression
which checks node->down may be unnecessary:
```diff
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index f553684..5e408bc 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -2309,7 +2309,7 @@ decrement_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
((n)->data != NULL && \
(((((rbtdb_data_t *)(n)->data)->nonecs_data) != NULL) || \
((((rbtdb_data_t *)(n)->data)->ecs_root) != NULL))) || \
- ((l) && (n)->down != NULL) || (n) == (r)->origin_node || \
+ (!(l) || (n)->down != NULL) || (n) == (r)->origin_node || \
(n) == (r)->nsec3_origin_node)
/* Handle easy and typical case first. */
```August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3477Release Checklist for BIND 9.16.32, 9.16.32-S1, 9.18.6, 9.19.42022-09-09T17:46:56ZMichał KępieńRelease Checklist for BIND 9.16.32, 9.16.32-S1, 9.18.6, 9.19.4## Release Schedule
**Code Freeze:** Wednesday, August 3rd, 2022
**Tagging Deadline:** Monday, August 8th, 2022
**Public Release:** Wednesday, August 17th, 2022
## Documentation Review Links
**Closed issues assigned to the milestone...## Release Schedule
**Code Freeze:** Wednesday, August 3rd, 2022
**Tagging Deadline:** Monday, August 8th, 2022
**Public Release:** Wednesday, August 17th, 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.19.4](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=August%202022%20%289.16.32,%209.16.32-S1,%209.18.6,%209.19.4%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
- [9.18.6](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=August%202022%20%289.16.32,%209.16.32-S1,%209.18.6,%209.19.4%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.16.32](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=August%202022%20%289.16.32,%209.16.32-S1,%209.18.6,%209.19.4%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.19.4](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=August%202022%20(9.16.32%2C%209.16.32-S1%2C%209.18.6%2C%209.19.4)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.18.6](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=August%202022%20(9.16.32%2C%209.16.32-S1%2C%209.18.6%2C%209.19.4)¬[label_name][]=Release%20Notes&target_branch=v9_18)
- [9.16.32](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=August%202022%20(9.16.32%2C%209.16.32-S1%2C%209.18.6%2C%209.19.4)¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.19.4](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=August%202022%20(9.16.32%2C%209.16.32-S1%2C%209.18.6%2C%209.19.4)&label_name[]=No%20CHANGES&target_branch=main)
- [9.18.6](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=August%202022%20(9.16.32%2C%209.16.32-S1%2C%209.18.6%2C%209.19.4)&label_name[]=No%20CHANGES&target_branch=v9_18)
- [9.16.32](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=August%202022%20(9.16.32%2C%209.16.32-S1%2C%209.18.6%2C%209.19.4)&label_name[]=No%20CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Add a release marker to `CHANGES`.
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` (9.18+) or `version` (9.16).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Check that the formatting is correct for HTML and PDF versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results for the tags created and sign off on the releases to be published.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to allow merging to them again.
- [x] ***(QA)*** Prepare and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(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 *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge published release tags (non-linearly) back into the their relevant development/maintenance branches.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Michal NowakMichal Nowak2022-08-17https://gitlab.isc.org/isc-projects/kea/-/issues/1000Author (in the Kea ARM or as a Wiki piece or KB article), better guidance on ...2022-08-31T09:25:33ZCathy AlmondAuthor (in the Kea ARM or as a Wiki piece or KB article), better guidance on HA and HA + backup configurationsThis is follow-on from customer questions and requests for advice on setting up and managing resilient Kea HA environments.
See discussions and material in [Support ticket #15378](https://support.isc.org/Ticket/Display.html?id=15378) an...This is follow-on from customer questions and requests for advice on setting up and managing resilient Kea HA environments.
See discussions and material in [Support ticket #15378](https://support.isc.org/Ticket/Display.html?id=15378) and [Support ticket #15334](https://support.isc.org/Ticket/Display.html?id=15334).
Although the concepts of how to configure HA as load-balancing or primary/standby as well as 'and you can add a backup server too) are covered in the Kea Administrator Reference Manual, there's no overall discussion about different strategies for deploying resilient server configurations, how to test, monitor, what to consider, and what to actually do, in case of a failure scenario.
It would be excellent to have a document (or paper, or series of KB articles) that cover things like:
- Different resilient configurations
- Pros and Cons of each
- Implications for routers/relays
- Disaster scenarios and recovery from them - including what to do with relays, routers, server addressing, route advertisements (for wheeling in a replacement server at another location)
- How to promote a backup server to primary/sole server if the HA pair 'vanish'
- How to change HA server states manually (in a controlled manner, with guaranteed state change) for maintenance/upgrades
- How to test your HA environment
- Where/how anycast might fit in
- Where/how load-balancers fit in - and specific considerations for those
- Server environment replication - entire VMs
- Lease file replication
- Multiple Kea servers sharing the same leases back-end
- Multiple Kea servers sharing the same reservations back-end
- All the 'what if?'s
And so on...kea2.3.0Peter DaviesPeter Davieshttps://gitlab.isc.org/isc-projects/kea/-/issues/2546bump up lib versions for 2.3.02023-07-17T13:58:25ZWlodzimierz Wencelbump up lib versions for 2.3.0it's new development, increase +11 for all libs (even those not modified)it's new development, increase +11 for all libs (even those not modified)kea2.3.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2541wipe_data.sh script is referring to non existing path2023-07-17T13:58:25ZWlodzimierz Wencelwipe_data.sh script is referring to non existing pathWhen Kea is installed from packages (rpm/deb) wipe script is trying to use `admin-utils.sh` from non existing path:
```
12:53:08 |forge-client-v4 10:53:06.783191| [172.28.0.31] run: bash /usr/share/kea/scripts/mysql/wipe_data.sh `mysq...When Kea is installed from packages (rpm/deb) wipe script is trying to use `admin-utils.sh` from non existing path:
```
12:53:08 |forge-client-v4 10:53:06.783191| [172.28.0.31] run: bash /usr/share/kea/scripts/mysql/wipe_data.sh `mysql -ukeauser -pkeapass keadb -N -B -e "SELECT CONCAT_WS('.', version, minor) FROM schema_version;" 2>/dev/null` -N -B -ukeauser -pkeapass keadb
12:53:08 |forge-client-v4 10:53:06.832385| [172.28.0.31] out: /usr/share/kea/scripts/mysql/wipe_data.sh: line 31: /home/fedora/rpm-root/BUILD/kea-2.3.0/src/bin/admin/admin-utils.sh: No such file or directory
```
In package we can't refer to `@abs_top_builddir@` at any point :(
```
# Include utilities. Use installed version if available and
# use build version if it isn't.
if [ -e "@abs_top_srcdir@/src/bin/admin/admin-utils.sh" ]; then
. "@abs_top_srcdir@/src/bin/admin/admin-utils.sh"
else
. "@abs_top_builddir@/src/bin/admin/admin-utils.sh"
fi
```
* this is completely trashing our pkg system test
* probably the same problem is with /usr/share/kea/scripts/pgsql/wipe_data.sh
* I would point isc-projects/kea#2071 as cause of this problemkea2.3.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2537Child loggers should inherit missing configuration from the root logger2023-07-17T13:58:25ZAndrei Pavelandrei@isc.orgChild loggers should inherit missing configuration from the root loggerThe Kea ARM has the following paragraph:
```
This relationship is important, as each child logger derives its default
configuration from its parent root logger. In the typical case, the root
logger configuration is the only logging conf...The Kea ARM has the following paragraph:
```
This relationship is important, as each child logger derives its default
configuration from its parent root logger. In the typical case, the root
logger configuration is the only logging configuration specified in the
configuration file and so applies to all loggers. If an entry is made
for a given logger, any attributes specified override those of the root
logger, whereas any not specified are inherited from it.
```
There are three possible entries:
* severity
* debuglevel
* output_options
In practice, none of them are inherited. We should either:
1. change the docs to explain the actual behavior, possibly removing that paragraph
2. OR implement logger configuration inheritance
The following unit tests pass succesfully, suggesting that part of the inheritance is already implemented:
* `LoggerTest.SeverityInheritance`
* `LoggerTest.EffectiveSeverityInheritance`
* `LoggerTest.DebugLevelInheritance`
I suspect the inheritance last worked prior to 2010 when Kea used logcxx.
[RT#20990](https://support.isc.org/Ticket/Display.html?id=20990)kea2.3.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2534hammer: FreeBSD 13.0 installation fails2023-07-17T13:58:25ZTomek Mrugalskihammer: FreeBSD 13.0 installation failsAn attempt to use hammer to install FreeBSD fails, because `py38-sphinx` and `py38-sphinx_rtd_theme` are no longer available. Need to migrate to 3.9.
Steps to reproduce:
```
./hammer.py prepare-system -p virtualbox -s freebsd -r 13.0 -l...An attempt to use hammer to install FreeBSD fails, because `py38-sphinx` and `py38-sphinx_rtd_theme` are no longer available. Need to migrate to 3.9.
Steps to reproduce:
```
./hammer.py prepare-system -p virtualbox -s freebsd -r 13.0 -l
```
Result:
```
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'py38-sphinx' have been found in the repositories
pkg: No packages available to install matching 'py38-sphinx_rtd_theme' have been found in the repositories
Traceback (most recent call last):
File "/home/vagrant/hammer.py", line 3058, in <module>
main()
File "/home/vagrant/hammer.py", line 3030, in main
prepare_system_cmd(args)
File "/home/vagrant/hammer.py", line 2860, in prepare_system_cmd
prepare_system_local(features, args.check_times)
File "/home/vagrant/hammer.py", line 1803, in prepare_system_local
install_pkgs(packages, env=env, timeout=6 * 60, check_times=check_times)
File "/home/vagrant/hammer.py", line 515, in install_pkgs
execute(cmd, timeout=timeout, env=env, check_times=check_times, attempts=3, sleep_time_after_attempt=10)
File "/home/vagrant/hammer.py", line 401, in execute
raise ExecutionError("The command return non-zero exitcode %s, cmd: '%s'" % (exitcode, cmd))
__main__.ExecutionError: The command return non-zero exitcode 1, cmd: 'sudo -E pkg install -y autoconf automake libtool openssl log4cplus boost-libs wget py38-sphinx py38-sphinx_rtd_theme'
```kea2.3.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2528fix bump_lib_versions to latest release requirements2023-07-17T13:58:25ZRazvan Becheriufix bump_lib_versions to latest release requirementsconsider bump from stable to stable
use 10+ for stable versions as well to support backport to multiple stable versionsconsider bump from stable to stable
use 10+ for stable versions as well to support backport to multiple stable versionskea2.3.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2527Support of new options required by RFC 69262023-07-17T13:58:25ZFrancis DupontSupport of new options required by RFC 6926The [RFC6926](https://www.rfc-editor.org/rfc/rfc6926) defines the following options:
- Status-code (151)
- Base-time (152)
- start-time-of-state (153)The [RFC6926](https://www.rfc-editor.org/rfc/rfc6926) defines the following options:
- Status-code (151)
- Base-time (152)
- start-time-of-state (153)kea2.3.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2517support multiple v6 vendor-opts code 17 options2023-07-17T13:58:25ZFrancis Dupontsupport multiple v6 vendor-opts code 17 optionsDHCPv6 version of #1518: far easier as there is one option per vendor ID.DHCPv6 version of #1518: far easier as there is one option per vendor ID.kea2.3.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2516add support for CentOS Stream 9 in hammer.py2023-07-17T13:58:25ZAndrei Pavelandrei@isc.orgadd support for CentOS Stream 9 in hammer.pyFor development and debugging purposes. CentOS Stream 9 is more easily available than RHEL 9.For development and debugging purposes. CentOS Stream 9 is more easily available than RHEL 9.kea2.3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2514Dependency issues with Kea 2.2 and RHEL 9.02022-07-29T13:05:06ZDavid YaffeDependency issues with Kea 2.2 and RHEL 9.0---
name: Bug report
about: Dependency issues with Kea 2.2 and RHEL 9.0
---
**Describe the bug**
Kea 2.2, specifically kea-hooks-2.20-isc20220726061131.el9.x86_64 depends on liblog4cplus-1.2.so.5()(64bit)
**To Reproduce**
Steps to repr...---
name: Bug report
about: Dependency issues with Kea 2.2 and RHEL 9.0
---
**Describe the bug**
Kea 2.2, specifically kea-hooks-2.20-isc20220726061131.el9.x86_64 depends on liblog4cplus-1.2.so.5()(64bit)
**To Reproduce**
Steps to reproduce the behavior:
1. Perform a clean install of RHEL 9
2. Enable EPEL, and Code Builder Repository
3. Enable the KEA repository using the script from cloudsmith.io
4. run `#sudo dnf install isc-kea isc-kea-hooks`
**Expected behavior**
Kea is installed
**Environment:**
- Kea version:
> # kea-dhcp4 -V
> 2.2.0
> tarball
> linked with:
> log4cplus 1.2.0
> OpenSSL 3.0.1 14 Dec 2021
> database:
> MySQL backend 14.0, library 3.2.6
> PostgreSQL backend 13.0, library 130005
> Memfile backend 2.1
- OS: [RHEL 9 - `Linux <REDACTED> 5.14.0-70.17.1.el9_0.x86_64 #1 SMP PREEMPT Tue Jun 14 11:32:10 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux]`
- Cloudsmith Packages, not from source.
**Additional Information**
I was able to install Kea 2.2 by using the log4cplus RPM from EPEL8. This is not ideal as it generates an error whenever I try to run `# dnf upgrade`:
```
[root@ipa-01 named]# dnf upgrade
Updating Subscription Management repositories.
Extra Packages for Enterprise Linux 9 - x86_64 5.4 MB/s | 8.7 MB 00:01
isc-kea-2-2 29 kB/s | 26 kB 00:00
isc-kea-2-2-noarch 338 B/s | 291 B 00:00
isc-kea-2-2-source 369 B/s | 291 B 00:00
isc-stork 24 kB/s | 22 kB 00:00
isc-stork-noarch 357 B/s | 291 B 00:00
isc-stork-source 344 B/s | 291 B 00:00
Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) 8.6 MB/s | 8.6 MB 00:01
Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) 5.1 MB/s | 2.9 MB 00:00
Red Hat CodeReady Linux Builder for RHEL 9 x86_64 (RPMs) 4.7 MB/s | 2.4 MB 00:00
Error:
Problem: cannot install both log4cplus-2.0.5-15.el9.x86_64 and log4cplus-1.2.0-11.el8.x86_64
- package isc-kea-hooks-2.2.0-isc20220726061131.el9.x86_64 requires liblog4cplus-1.2.so.5()(64bit), but none of the providers can be installed
- cannot install the best update candidate for package log4cplus-1.2.0-11.el8.x86_64
- cannot install the best update candidate for package isc-kea-hooks-2.2.0-isc20220726061131.el9.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
```
log4cplus 1.2 is over 4 years old. log4cplus 2.0.8 is the current version and was released on July 8th, 2022. EPEL9 includes version log4cplus 2.0.5 for RHEL (https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/Packages/l/log4cplus-2.0.5-15.el9.x86_64.rpm). Log4cplus 1.2.0 is available from EPEL8, https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/l/log4cplus-1.2.0-11.el8.x86_64.rpm
What is the best way to get this resolved? Can Kea for RHEL9 be built with a more modern log4cplus? or can an ISC specific version of log4cplus 1.2 be built and hosted in the cloudsmith repos?kea2.3.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2513Sphinx converts apostrophes to smart quotes2023-07-31T11:34:31ZAndrei Pavelandrei@isc.orgSphinx converts apostrophes to smart quotesAostrophes (U+0027) `'` in RST files are converted into left quotes and right quotes in the HTML and PDF created by sphinx.
| Unicode Codepoint | Visual Representation | Hexadecimal Byte Representation | Name |
| ...Aostrophes (U+0027) `'` in RST files are converted into left quotes and right quotes in the HTML and PDF created by sphinx.
| Unicode Codepoint | Visual Representation | Hexadecimal Byte Representation | Name |
| ----------------- | --------------------- | ------------------------------- | --------------------------- |
| U+2018 | ‘ | E2 80 98 | LEFT SINGLE QUOTATION MARK |
| U+2019 | ’ | E2 80 99 | RIGHT SINGLE QUOTATION MARK |
This prevents a user from copying and using any chunks of configuration or pieces of code that use apostrophes.
This issue does not affect preformatted code blocks or spans of code marked by backtick quotes.kea2.3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2512Bump version in configure.ac to 2.3.0-git2023-07-17T13:58:25ZAndrei Pavelandrei@isc.orgBump version in configure.ac to 2.3.0-gitkea2.3.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.org