ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-12-05T15:18:43Zhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/54Add setting of reservations inside of subnets2023-12-05T15:18:43ZDarren AnkneyAdd setting of reservations inside of subnetsHost reservations, as noted here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 are meant to only contain an IP address if they are specified at the subnet level. Re-use the host reservation mech...Host reservations, as noted here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 are meant to only contain an IP address if they are specified at the subnet level. Re-use the host reservation mechanism to add reservations in the subnet area. Allow IP address to be set here but only if it is part of the enclosing subnet.0.3https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/53Add selection of client classes to reservation2024-01-02T15:53:59ZDarren AnkneyAdd selection of client classes to reservationIt is possible to add hosts to a class inside a reservation as noted here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4 Make this a possibility in the reservation. If the reservation is g...It is possible to add hosts to a class inside a reservation as noted here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4 Make this a possibility in the reservation. If the reservation is global, check, but I think `early-global-reservations-lookup` is required, see note in this section: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#client-classification-in-dhcpv40.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/52Add selection of options to reservations2024-01-23T20:16:48ZDarren AnkneyAdd selection of options to reservationsReservations can contain options as described here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#including-specific-dhcpv4-options-in-reservations so re-use the options specification interface from global here to allow the ...Reservations can contain options as described here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#including-specific-dhcpv4-options-in-reservations so re-use the options specification interface from global here to allow the specification of options in host reservations.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/51Add selection of options to client-classes2024-01-23T20:16:48ZDarren AnkneyAdd selection of options to client-classesClient-classes can contain option-data as shown here: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#configuring-classes We now have an options addition interface. Re-use this interface in the client-classification to add opt...Client-classes can contain option-data as shown here: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#configuring-classes We now have an options addition interface. Re-use this interface in the client-classification to add option-data to the classification.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/50add client class selection to pool2024-01-02T22:05:13ZDarren Ankneyadd client class selection to poolAs described here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#pool-selection-with-client-class-reservations you can require a client-class membership in the `pool {}` statement inside a `pools []` block. Now that client-...As described here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#pool-selection-with-client-class-reservations you can require a client-class membership in the `pool {}` statement inside a `pools []` block. Now that client-classes exist, we should allow selection of a client class in each `pool {}` statement. This should probably include the special classes of `KNOWN` and `UNKNOWN`.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4470ns_interfacemgr_t listenon queue set incorrectly2024-03-28T08:28:47Zliu chaofengns_interfacemgr_t listenon queue set incorrectly<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential!
-->
### Summary
ns_interfacemgr_t listenon queue set incorrectly
### BIND version used
master branch
### Steps to reproduce
1. config named.conf like below
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
2. then start the named process
3. run "netstat -lpn|grep named" found the 53 and 10053 has already listened.
4. the ns_interfacemgr_t has a listenon queue
struct ns_interfacemgr {
...
ISC_LIST(isc_sockaddr_t) listenon;
....
}
5. I dump the listenon queue, found that there is only 127.0.0.1#53,
127.0.0.1#10053 is not in the listenon queue.
### What is the current *bug* behavior?
I think this behavior maybe a bug,
### What is the expected *correct* behavior?
the listenon should contain 127.0.0.1#53 and 127.0.0.1#10053
### Relevant configuration files
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/stork/-/issues/1240Sanity checks for Stork 1.14.0 rc12023-12-06T10:36:36ZMarcin GodzinaSanity checks for Stork 1.14.0 rc1We are now at step SANITY CHECKS of Stork 1.14.0 rc1.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the apk, deb & rp...We are now at step SANITY CHECKS of Stork 1.14.0 rc1.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the apk, deb & rpm packages, place them in the tarball location, run tests with `rake system_tests` and `rake system_tests_ui`.
3. Start demo locally with `rake demo:up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
4. Install server and agent locally e.g. in VMs from apk, deb & rpm packages
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.
* tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/3841692/artifacts/browse
* apk, deb & rpm packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/3841690/artifacts/browse
Hooks:
* tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/3841702/artifacts/browse
* apk, deb & rpm packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/3841709/artifacts/browse1.14https://gitlab.isc.org/isc-projects/bind9/-/issues/4465Release Checklist for BIND 9.18.21, 9.18.21-S1, 9.19.192024-01-10T07:23:06ZTom KrizekRelease Checklist for BIND 9.18.21, 9.18.21-S1, 9.19.19## Release Schedule
**Code Freeze:** Wednesday, 6 December 2023
**Tagging Deadline:** Monday, 11 December 2023
**Public Release:** Wednesday, 20 December 2023
## Documentation Review Links
**Closed issues assigned to the milestone ...## Release Schedule
**Code Freeze:** Wednesday, 6 December 2023
**Tagging Deadline:** Monday, 11 December 2023
**Public Release:** Wednesday, 20 December 2023
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.18.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.21-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.19](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
**Merge requests merged into the milestone without a release note:**
- [9.18.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.21-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.19](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.18.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.21-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.19](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Rebase -S editions on top of current open-source versions: `git checkout bind-9.18-sub && git rebase origin/bind-9.18`
- [x] ***(QA)*** [Inform](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_supp_marketing.py) Support and Marketing of [impending release](https://mattermost.isc.org/isc/pl/6oeity9pxf8fmbgx43t5ofsm6a) (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform. Check [public](https://gitlab.isc.org/isc-projects/bind9/-/pipelines?scope=all&source=schedule) and [private](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=all&source=schedule) scheduled pipelines.
- [x] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [x] ***(QA)*** Check [Perflab](https://perflab.isc.org/) 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](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/)[^1] (Subscription Edition only).
- [x] ***(QA)*** [Ensure](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/check_backports.py) all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** [Announce](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_code_freeze.py) ([on Mattermost](https://mattermost.isc.org/isc/pl/gdh1dzxaqbyq8dyic4gqbr5wcy)) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Inspect the current output of the `cross-version-config-tests` job to verify that no unexpected backward-incompatible change was introduced in the current release cycle.
- [x] ***(QA)*** Ensure release notes are correct, [ask Support and Marketing](https://mattermost.isc.org/isc/pl/epghkxueoiysibjjwgcya4fgey) to check them as well. [Example](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/510)
- [x] ***(QA)*** Add a release marker to `CHANGES`. Examples: [9.18](https://gitlab.isc.org/isc-projects/bind9/-/commit/f14d8ad78c0506fd4247187f2177f8eceeb6b3b9), [9.16](https://gitlab.isc.org/isc-projects/bind9/-/commit/1bcdf21874f99a00da389d723e0ad07dfd70f9f1)
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` ([9.18+](https://gitlab.isc.org/isc-projects/bind9/-/commit/3c85ab7f4c35e6d8acef1393606002a0a8730100)) or `version` ([9.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7692/diffs?commit_id=1bcdf21874f99a00da389d723e0ad07dfd70f9f1)).
- [x] ~~***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).~~
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)
- [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 the HTML version 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](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=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: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)
- [x] ***(QA)*** Prepare (using [`version_bump.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/version_bump.py)) and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [x] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums. Ask [signers on Mattermost](https://mattermost.isc.org/isc/channels/bind-9-qa).
- [x] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [x] ~~***(QA)*** Prepare the `patches/` subdirectory for each security release (if applicable).~~
- [x] ***(QA)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** [Build and test](https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/156507) ASN and/or Subscription Edition packages (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(QA)*** Use the [Printing Press project](https://gitlab.isc.org/isc-private/printing-press/-/wikis/home#adding-new-documents) to prepare a [release announcement email](https://gitlab.isc.org/isc-private/printing-press/-/merge_requests/83).
- [x] ~~***(Marketing)*** Update ASN documents in the SF portal.~~
- [x] ~~***(Marketing)*** Send out ASN emails (if applicable).~~
### On the Day of Public Release
- [x] ~~***(QA)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).~~
- [x] ***(QA)*** Place tarballs in public location on FTP site.
- [x] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [x] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [x] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [x] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [x] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [x] ***(Marketing)*** Announce release on social media sites.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [x] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [x] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [x] ***(QA)*** Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.
- [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](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) 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. Black, PyLint, Sphinx) by modifying the relevant [`Dockerfile`](https://gitlab.isc.org/isc-projects/images/-/merge_requests/228/diffs).
- [x] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
- [x] ***(QA)*** Update [`metadata.json`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/metadata.json) with the upcoming release information.
[^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.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Tom KrizekTom Krizek2023-12-20https://gitlab.isc.org/isc-projects/stork/-/issues/12391.14.0. release version bump2023-12-04T14:29:09ZMarcin Godzina1.14.0. release version bump1.14Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/stork/-/issues/1236stork-demo.sh is failing to build the web ui for stork2023-12-07T16:49:30Zvarsrajastork-demo.sh is failing to build the web ui for stork---
name: Bug report
about: store-demo.sh fails to build the web ui for stork
---
**Describe the bug**
Trying to build the stork server, web-ui web-apache docker containers . Checked out the latest code and tried to run the stork-dem...---
name: Bug report
about: store-demo.sh fails to build the web ui for stork
---
**Describe the bug**
Trying to build the stork server, web-ui web-apache docker containers . Checked out the latest code and tried to run the stork-demo.sh script that builds these images. it is exiting with error to build the web-ui image.
**Expected behavior**
Able to see the stork demo to start running.
[stork-demo-error.txt](/uploads/d0b03d0046b4202bd0a5c440896b549a/stork-demo-error.txt)
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.https://gitlab.isc.org/isc-projects/kea/-/issues/3179kea fails to log to syslog if run as non-root user2024-03-22T13:43:03ZLars Wendlerkea fails to log to syslog if run as non-root userWith the following config snippet
```
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "syslog" } ],
"severity": "INFO",
...With the following config snippet
```
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [ { "output": "syslog" } ],
"severity": "INFO",
"debuglevel": 0
}
]
```
kea won't log to syslog service once it's being started as non-root user. Simply starting kea as root makes it successfully log to syslog.
I am using the following syslogger: [sysklogd-2.4.4](https://github.com/troglobit/sysklogd)
I have found this problem being present in kea-2.4.1 and kea-2.5.4 and only tested the dhcp4 component of kea.kea2.5.8https://gitlab.isc.org/isc-projects/stork/-/issues/1235Improve documentation of Stork API (SwaggerUI)2023-12-05T14:55:44ZDarren AnkneyImprove documentation of Stork API (SwaggerUI)There is documentation of the Stork API in the Stork UI under "Help -> Stork API Docs (SwaggerUI)". This documentation is really good, especially the "try it out" functionality. Unfortunately, the "try it out" seems to always work no m...There is documentation of the Stork API in the Stork UI under "Help -> Stork API Docs (SwaggerUI)". This documentation is really good, especially the "try it out" functionality. Unfortunately, the "try it out" seems to always work no matter if you have set things properly by clicking the Lock icon, or made a mistake there. Therefore, it is somewhat difficult to figure out the actual process to come up with the session key to use during the API calls. I propose to resolve this by adding a simple example with accompanying short instruction so that it is more obvious how to use the API. It is really easy once you understand this step!
<details><summary>Example</summary>
```
$ curl -v -X 'POST' 'http://192.168.20.10:8080/api/sessions' -H 'accept: application/json' -H 'Content-Type: application/json' -d '{"authenticationMethodId": "internal", "identifier": "admin", "secret": "admin"}' | jq
Note: Unnecessary use of -X or --request, POST is already inferred.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.20.10:8080...
* Connected to 192.168.20.10 (192.168.20.10) port 8080 (#0)
> POST /api/sessions HTTP/1.1
> Host: 192.168.20.10:8080
> User-Agent: curl/7.88.1
> accept: application/json
> Content-Type: application/json
> Content-Length: 80
>
} [80 bytes data]
< HTTP/1.1 200 OK
< Cache-Control: no-cache="Set-Cookie"
< Content-Type: application/json
< Set-Cookie: session=L0cdSK9h6l_Cm4UY7D-Fsw_HWPmkYN0HwfnB5oNlI5U; Path=/; Expires=Thu, 30 Nov 2023 12:17:18 GMT; Max-Age=86400; HttpOnly; SameSite=Lax
< Vary: Cookie
< Date: Wed, 29 Nov 2023 12:17:17 GMT
< Content-Length: 108
<
{ [108 bytes data]
100 188 100 108 100 80 12253 9076 --:--:-- --:--:-- --:--:-- 23500
* Connection #0 to host 192.168.20.10 left intact
{
"authenticationMethodId": "internal",
"groups": [
1
],
"id": 1,
"lastname": "admin",
"login": "admin",
"name": "admin"
}
$ curl -v -X 'GET' 'http://192.168.20.10:8080/api/shared-networks' -H 'accept: application/json' -H 'Cookie: session=L0cdSK9h6l_Cm4UY7D-Fsw_HWPmkYN0HwfnB5oNlI5U' | jq
Note: Unnecessary use of -X or --request, GET is already inferred.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.20.10:8080...
* Connected to 192.168.20.10 (192.168.20.10) port 8080 (#0)
> GET /api/shared-networks HTTP/1.1
> Host: 192.168.20.10:8080
> User-Agent: curl/7.88.1
> accept: application/json
> Cookie: session=L0cdSK9h6l_Cm4UY7D-Fsw_HWPmkYN0HwfnB5oNlI5U
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Vary: Cookie
< Date: Wed, 29 Nov 2023 12:17:38 GMT
< Content-Length: 15
<
{ [15 bytes data]
100 15 100 15 0 0 6407 0 --:--:-- --:--:-- --:--:-- 7500
* Connection #0 to host 192.168.20.10 left intact
{
"items": null
}
```
</details>
<details><summary>Instructions based on the example</summary>
- First a login must be performed: `$ curl -v -X 'POST' 'http://192.168.20.10:8080/api/sessions' -H 'accept: application/json' -H 'Content-Type: application/json' -d '{"authenticationMethodId": "internal", "identifier": "admin", "secret": "admin"}'` The `"identifier": "admin"` and `"secret": "admin"` should match a username and password that can log into the Stork UI.
- The return, if authentication is successful, will contain (in the header) something like this: `< Set-Cookie: session=L0cdSK9h6l_Cm4UY7D-Fsw_HWPmkYN0HwfnB5oNlI5U; Path=/; Expires=Thu, 30 Nov 2023 12:17:18 GMT; Max-Age=86400; HttpOnly; SameSite=Lax`
- Subsequent calls, for the next 24 hours, must include: `session=L0cdSK9h6l_Cm4UY7D-Fsw_HWPmkYN0HwfnB5oNlI5U` as shown here: `$ curl -v -X 'GET' 'http://192.168.20.10:8080/api/shared-networks' -H 'accept: application/json' -H 'Cookie: session=L0cdSK9h6l_Cm4UY7D-Fsw_HWPmkYN0HwfnB5oNlI5U'`
</details>
Of course, the above is only a suggestion. There may be better examples and subsequent instructions, and/or a more dynamic way that could include data from the local StorkUI the user is actually using, which would be even easier to understand.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3176Kea disables logging if configured without an `output-options`2023-11-30T14:32:43ZAndrei Pavelandrei@isc.orgKea disables logging if configured without an `output-options`To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dh...To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
}
```
Or set the same configuration through unix socket or kea-ctrl-agent (maybe while still preserving the control-socket, that's why it's there):
```json
{
"arguments": {
"Dhcp6": {
"control-socket": {
"socket-name": "/tmp/kea-dhcp6-ctrl.sock",
"socket-type": "unix"
},
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
},
"command": "config-set",
"service": [
"dhcp6"
]
}
```
You get this and no more logging after that.
```
log4cplus:ERROR No appenders could be found for logger (kea-dhcp6.hosts).
log4cplus:ERROR Please initialize the log4cplus system properly.
```
This contradicts the ARM which says:
> Each logger can have zero or more `output-options`.
It replicates with subloggers too. Only the sublogger is affected in that case.
You can have `interfaces-config` and `subnet6` and anything else besides it.
DHCP traffic works. Commands work. Logging does not.
It also replicates on `kea-dhcp4`.
There is the workaround of reconfiguring with `output-options`. Logging recovers after that.
Also found a typo in the ARM: `output_commands` should be `output-options`.
Suggested actions:
* [ ] Make logging work when `output-options` is not configured with the documented default of `stdout` as output option.
* [ ] Fix the typo in the ARM: `output_commands` should be `output-options`.next-stable-2.6https://gitlab.isc.org/isc-projects/stork/-/issues/1234Update the build from sources guide for Ubuntu 20.04 LTS2024-02-06T14:42:33ZSlawek FigielUpdate the build from sources guide for Ubuntu 20.04 LTSSince the Stork build system requires Python 3.10 and Ruby 2.3, [the guide to build Stork from sources](https://gitlab.isc.org/isc-projects/stork/-/wikis/Install) is no longer applicable on Ubuntu 20.04 LTS.
The guide recommends install...Since the Stork build system requires Python 3.10 and Ruby 2.3, [the guide to build Stork from sources](https://gitlab.isc.org/isc-projects/stork/-/wikis/Install) is no longer applicable on Ubuntu 20.04 LTS.
The guide recommends installing Python and Ruby from the package repository, but the available versions of the above dependencies are outdated. Users need to install Python and Ruby from their maintainers' external, official packages. We should mention it in the guide.1.16https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/49Add favicon.ico2023-11-28T15:45:52ZDarren AnkneyAdd favicon.icoJust for fun. No reason this has to exist.Just for fun. No reason this has to exist.0.3Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4456license question: do bind9 based configs require Mozilla License?2023-11-27T20:54:47ZPJ Fanninglicense question: do bind9 based configs require Mozilla License?I'm a developer on the Apache Pekko project, an open source fork of Akka.
One of our mentors has queried if we have a licensing issue for the files in this directory.
https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/t...I'm a developer on the Apache Pekko project, an open source fork of Akka.
One of our mentors has queried if we have a licensing issue for the files in this directory.
https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/test/bind/etc
The configs there are Bind9 configs used in our tests.
Does the Mozilla Public License have to be applied to our config files?
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/LICENSE
The Mozilla Public License is regarded by the ASF as having copyleft implications.
Any advice on the licensing implications of having config files based on this repo would be appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/4455Please backport #3883 transfer statistics to 9.18-S if practical2024-01-03T18:07:30ZVicky Riskvicky@isc.orgPlease backport #3883 transfer statistics to 9.18-S if practicalThe transfer statistics have been requested by users for quite a while, and there is significant interest in them. If the feature doesn't rely on some refactoring in the 9.19 branch, or isn't significantly de-stabilizing for some other r...The transfer statistics have been requested by users for quite a while, and there is significant interest in them. If the feature doesn't rely on some refactoring in the 9.19 branch, or isn't significantly de-stabilizing for some other reason, could we request a backport to 9.18-S please?
https://gitlab.isc.org/isc-projects/bind9/-/issues/3883January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/kea/-/issues/3170Feature request: Add regex classification expression2023-11-30T14:29:47ZottoreiFeature request: Add regex classification expressionIt would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.It would be a huge improvement for client classification to have the possibility of using regular expressions. That way even more complex inputs could be handled with ease.next-stable-2.6https://gitlab.isc.org/isc-projects/stork/-/issues/1229Disable subnet edit and delete buttons when subnet_cmds unavailable2024-03-26T10:29:11ZMarcin SiodelskiDisable subnet edit and delete buttons when subnet_cmds unavailableAs suggested in https://gitlab.isc.org/isc-projects/stork/-/merge_requests/674#note_418902, we should consider hiding or disabling the button for editing and deleting a subnet when there are no machines with the subnet_cmds hook loaded. ...As suggested in https://gitlab.isc.org/isc-projects/stork/-/merge_requests/674#note_418902, we should consider hiding or disabling the button for editing and deleting a subnet when there are no machines with the subnet_cmds hook loaded. We should probably also disable it when any of the daemons associated with the subnet does not have this hook loaded. There are possibly other cases and similar issues exist for host management.
The issue was noticed by @marcin during 1.15 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1296#note_434197
An attempt to delete a subnet for which the servers have no subnet_cmds hook library loaded, disables the delete button and hangs for a while. Then, it displays a message in the top right corner saying that the `subnet4-del` command is not supported.1.16https://gitlab.isc.org/isc-projects/kea/-/issues/3167BLQ: query-by-link-address and shared networks2024-03-21T13:20:14ZTomek MrugalskiBLQ: query-by-link-address and shared networksThis is a continuation of #3149. It was brought to our attention that the `QUERY_BY_LINK_ADDRESS` does not return PD leases properly in some circumstances. The algorithm we came up with is as follows:
Proposed algorithm for QUERY_BY_LIN...This is a continuation of #3149. It was brought to our attention that the `QUERY_BY_LINK_ADDRESS` does not return PD leases properly in some circumstances. The algorithm we came up with is as follows:
Proposed algorithm for QUERY_BY_LINK_ADDRESS:
1. select subnet for specified address, pick its subnet-id
2. (if shared network is used, select all subnet-ids for all subnets in the shared network) - this behavior should be configurable (extra parameter that governs if this step should be done or not).
3. return all leases (NA, PD) with the matching subnet-id
Steps 1 and 3 are to be implemented in #3149. This ticket is about extending the code with shared network scenario. Once implemented, it should be configurable if the leases from shared network should be returned or not. The parameter could be global.next-stable-2.6