ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-01-03T14:03:25Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/1260Long IPv6 address overlaps the reservation status2024-01-03T14:03:25ZSlawek FigielLong IPv6 address overlaps the reservation statusThe long IPv6 address overlaps the reservation status on the host reservation page.
![image](/uploads/53dfcad412a5fa954c4d5a851069c506/image.png)The long IPv6 address overlaps the reservation status on the host reservation page.
![image](/uploads/53dfcad412a5fa954c4d5a851069c506/image.png)1.15Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/bind9/-/issues/4483named logging for category rpz misses some rpz log messages2023-12-12T11:52:05ZEvan Harrisnamed logging for category rpz misses some rpz log messages<!--
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
When bind9/named is configured to log category rpz messages to a file, some
rpz log messages are not captured and end up being sent to an incorrect destination.
### BIND version used
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
### Steps to reproduce
Add the following stanza in named.conf.options:
```
logging {
channel rpzlog {
file "/var/log/named/rpz.log" versions unlimited size 100m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
category rpz { rpzlog; };
};
```
With this configuration for logging, most rpz log messages are properly
sent to the intended file (NXDOMAIN items), but some rpz messages are not.
So far, the ones that seem not to be properly captured by this log destination
are rpz "passthru" lookups.
Example log messages that end up in the default syslog/journald rather than
the configured log file:
```
Dec 10 01:29:41 somehostn named[327739]: client @0x7fee327a6568 127.0.0.1#35809 (some.domain.name): rpz QNAME PASSTHRU rewrite
some.domain.name/A/IN via some.domain.name.rpz.local
Dec 10 01:29:41 somehost named[327739]: client @0x7fee32785768 127.0.0.1#35809 (some.domain.name): rpz QNAME PASSTHRU rewrite
some.domain.name/AAAA/IN via some.domain.name.rpz.local
```
Example rpz entry that generates log entries that fail to go to the rpz category/destination:
```
some.domain.name CNAME rpz-passthru.
```
Example rpz entry that generates log entries that do go to the proper rpz category/destination:
```
other.domain.name CNAME .
```
### What is the current *bug* behavior?
rpz passthru entries generate log messages that do not go to the intended `category rpz` log destination.
### What is the expected *correct* behavior?
All rpz log messages should be caught by `category rpz`.
### Relevant configuration files
see abovehttps://gitlab.isc.org/isc-projects/stork/-/issues/1259Stork webinar preparation2024-01-02T12:31:56ZMarcin SiodelskiStork webinar preparationIn order to run the Stork webinar on Dec 13, 2023 we need need some small demo updates and fixes.In order to run the Stork webinar on Dec 13, 2023 we need need some small demo updates and fixes.1.15Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/1258Apps State Puller Interval is not preserved2024-03-05T12:38:29ZSlawek FigielApps State Puller Interval is not preservedIt is impossible to set the `Apps State Puller Interval` setting on UI. It always reverts to 30 seconds.
The API return HTTP 200 OK status:
```
stork-server-1 | time="2023-12-08 17:36:14" level="info" msg="HTTP request...It is impossible to set the `Apps State Puller Interval` setting on UI. It always reverts to 30 seconds.
The API return HTTP 200 OK status:
```
stork-server-1 | time="2023-12-08 17:36:14" level="info" msg="HTTP request incoming" file=" middleware.go:79 " method="PUT" path="/api/settings" remote="172.24.0.5:34192"
stork-server-1 | time="2023-12-08 17:36:14" level="info" msg="HTTP request served" file=" middleware.go:93 " method="PUT" path="/api/settings" remote="172.24.0.5:34192" size="0" status="200" text_status="OK" took="4.958374ms"
stork-webui-1 | 172.24.0.1 - - [08/Dec/2023:17:36:14 +0000] "PUT /api/settings HTTP/1.1" 200 0 "http://127.0.0.1:8080/settings" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 OPR/105.0.0.0" "-"
```1.16Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1257Simulator is not working due to incompatible dependency2023-12-08T16:31:05ZSlawek FigielSimulator is not working due to incompatible dependencyThe `isc-kea-common` package is not explicitly set in the `simulator.Dockerfile`.
It causes the incompatible version of this package to be installed after the recent Kea update.
```
root@simulator:/app# perfdhcp
perfdhcp: error while l...The `isc-kea-common` package is not explicitly set in the `simulator.Dockerfile`.
It causes the incompatible version of this package to be installed after the recent Kea update.
```
root@simulator:/app# perfdhcp
perfdhcp: error while loading shared libraries: libkea-dhcp++.so.73: cannot open shared object file: No such file or directory
```Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1256Stork addresses and prefixes usage aproximation2024-01-25T10:36:57ZVictor PetrescuStork addresses and prefixes usage aproximationHi everyone,
I've encounter an issue related to the aproximation of the assigned addresses, either is for Subents or Shared Networks. Do not know if this is the normal behavior or not but it's not accurate when showing the values.
For ...Hi everyone,
I've encounter an issue related to the aproximation of the assigned addresses, either is for Subents or Shared Networks. Do not know if this is the normal behavior or not but it's not accurate when showing the values.
For example, it shows utilization of 1k when in reality, hovering over, it shows 1771, which is a big difference.
![Screenshot_1306](/uploads/1d677d7fee16d9f49b3f2dbbfd267e60/Screenshot_1306.png)
Thank you !1.15Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4482Remove the "dnssec-must-be-secure" feature2023-12-07T10:23:58ZMichał KępieńRemove the "dnssec-must-be-secure" featureSee #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.See #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.BIND 9.21.x2024-12-01https://gitlab.isc.org/isc-projects/kea/-/issues/3188Support hot plugging network interfaces2024-02-01T10:52:48ZJakub OkońskiSupport hot plugging network interfaces---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` i...---
name: Feature request
about: Suggest an idea for this project
---
I'm migrating to kea from the previous ISC DHCP4 server and I noticed a difference in behavior. Kea refuses to start if an interface declared in `interfaces-config` is not present when Kea starts.
I want to be able to declare subnets & definitions for a USB adapter that I sometimes hotplug to the gateway. Without support from Kea, I'd need to keep two different configs and reload Kea at appropriate times. I assume it's also going to fail when a network interface it's listening on disappears.next-stable-2.6https://gitlab.isc.org/isc-projects/stork/-/issues/1254Ubuntu 20.04 LTS compatibility for LDAP hook2024-01-08T16:48:23ZSlawek FigielUbuntu 20.04 LTS compatibility for LDAP hookThe issue was reported on our mailing list: [Link](https://lists.isc.org/pipermail/stork-users/2023-December/000238.html).
We restored the Ubuntu 20.04 LTS support for main Stork binaries in the 1.14 release, but we forgot about the LDA...The issue was reported on our mailing list: [Link](https://lists.isc.org/pipermail/stork-users/2023-December/000238.html).
We restored the Ubuntu 20.04 LTS support for main Stork binaries in the 1.14 release, but we forgot about the LDAP hook.1.15Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1252Interrupt the system tests if the docker-compose build fails2023-12-19T14:46:52ZSlawek FigielInterrupt the system tests if the docker-compose build failsThe issue was created due to a post-sanity checks discussion with @andrei.
If your image build fails, it will be repeated for each test case if it isn't a temporary problem because the failed build is not stored in the cache. The build ...The issue was created due to a post-sanity checks discussion with @andrei.
If your image build fails, it will be repeated for each test case if it isn't a temporary problem because the failed build is not stored in the cache. The build problems are usually related to misconfiguration or bugs in Dockerfile or scripts. They are not temporary, so repeating the build on each test is unnecessary. We should interrupt the tests on the first build problem to save time.1.16https://gitlab.isc.org/isc-projects/kea/-/issues/3187ping-check hook should honor NetworkState2023-12-19T19:26:20ZThomas Markwalderping-check hook should honor NetworkStateThe last piece missing in ping check is coordinating with NetworkState. Currently, the hook library will continue to process existing ping checks even if NetworkState becomes disabled. Obviously no new checks would be created by core u...The last piece missing in ping check is coordinating with NetworkState. Currently, the hook library will continue to process existing ping checks even if NetworkState becomes disabled. Obviously no new checks would be created by core until the NetworkState is enabled again.
At first blush, this is matter of adding state checks in strategic places and acting accordingly. If disabled state is detected, existing checks would be flushed. If NetworkState were to be expanded to provide callbacks, similar to what is done with CriticalSections, this might have broader applications than just ping-check. Food for thought.kea2.5.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3186extend hammer to build aarch64 packages2024-01-03T10:49:15ZWlodzimierz Wencelextend hammer to build aarch64 packageskea2.5.5https://gitlab.isc.org/isc-projects/bind9/-/issues/4479SERVFAIL without any trace in logs2023-12-07T10:03:52ZrseffnerSERVFAIL without any trace in logs### Summary
rebooted Debian bookworm and can't use bind any more
### BIND version used
```
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.6.3-sus #6 SMP Wed Nov 29 09:06:16 CET 2023
built by mak...### Summary
rebooted Debian bookworm and can't use bind any more
### BIND version used
```
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.6.3-sus #6 SMP Wed Nov 29 09:06:16 CET 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
I don't know (on other same-configred Systems this bind-version is working)
### What is the current *bug* behavior?
an 'dig @127.0.0.1" results in SERVFAIL
```
SuS-GW:~# dig @127.0.0.1
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> @127.0.0.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48566
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
; COOKIE: fe27014ead9c76b10100000065706180e3a4d408ea8dc854 (good)
;; QUESTION SECTION:
;. IN NS
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Dec 06 12:56:48 CET 2023
;; MSG SIZE rcvd: 56
```
### What is the expected *correct* behavior?
Status: NOERROR and an valid ANSWER
### Relevant configuration files
Its not config-related. I tried to install an new bind into an chroot with same results.
### Relevant logs and/or screenshots
Here is the Problem: I can't find anything helpful in logs (also using 'rndc trace 9') except of:
```
06-Dec-2023 10:37:07.749 general: error: netmgr/uverr2result.c:98:isc___nm_uverr2result(): unexpected error:
06-Dec-2023 10:37:07.749 general: error: unable to convert libuv error code in udp_send_cb (netmgr/udp.c:802) to isc_result: -89: destination address required
```https://gitlab.isc.org/isc-projects/stork/-/issues/1251LDAP hook: Build fails on some Linux distributions2023-12-19T14:47:34ZSlawek FigielLDAP hook: Build fails on some Linux distributionsThe issue was found by @andrei during 1.14 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421471
```
Another one I had forgotten. I understand that this one as well is not a task that you usually run on a ta...The issue was found by @andrei during 1.14 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421471
```
Another one I had forgotten. I understand that this one as well is not a task that you usually run on a tarball.
rake hook:init MODULE=stork-server-ldap; rake hook:build results in error when run on a tarball. It seems like it is not picking up on DEFAULT_HOOK_DIRECTORY.
rm -f
Removing old compiled hooks...
cp go.mod go.sum /tmp/d20231205-1147463-kn7j49
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/tools/golang/go/bin/go mod edit -replace isc.org/stork=../../../../../Descărcări/sanity-checks/stork-1.14.0/backend
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/tools/golang/go/bin/go mod tidy
rake build
Building stork-server-ldap...
mkdir -p build
rm
rm: missing operand
Try 'rm --help' for more information.
rake aborted!
Command failed with status (1): [rm...]
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/hooks/stork-server-ldap/Rakefile:17:in `block in <top (required)>'
Tasks: TOP => build
(See full trace by running task with --trace)
rake aborted!
Command failed with status (1): [rake build...]
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:150:in `block (4 levels) in <top (required)>'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:141:in `block (3 levels) in <top (required)>'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:66:in `block (3 levels) in forEachHook'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:65:in `chdir'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:65:in `block (2 levels) in forEachHook'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:46:in `chdir'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:46:in `block in forEachHook'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:42:in `foreach'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:42:in `forEachHook'
/home/andrei/Descărcări/sanity-checks/stork-1.14.0/rakelib/90_hooks.rake:139:in `block (2 levels) in <top (required)>'
Tasks: TOP => hook:build
(See full trace by running task with --trace)
```1.16https://gitlab.isc.org/isc-projects/stork/-/issues/1250Syncing a new hook directory fails when running from tarball2023-12-19T14:43:29ZSlawek FigielSyncing a new hook directory fails when running from tarballThe issue was found by @andrei during 1.14 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421415
* If I do `rake hook:init MODULE=stork-server-ldap`, it initializes the git module correctly relative to the t...The issue was found by @andrei during 1.14 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421415
* If I do `rake hook:init MODULE=stork-server-ldap`, it initializes the git module correctly relative to the tarball content. However, if I do `rake hook:sync`, because the tarball is not a git repo, it goes all the way to the nearest parent git repository, and does some syncing there. I happen to have my home directory set up as a git repo, so I ended up with having some of my modules there modified. The task could instead check if there is a `.git` directory created at the same level as `Rakefile` first to determine if it is a tarball or a git repo. I also understand that this is not a task that you usually run on a tarball.
```
modified: .config/awesome/lain (new commits, modified content)
modified: .zprezto (modified content)
```backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4478Redefinition of 'hmac' as different kind of symbol on NetBSD2024-01-03T14:36:13ZMichal NowakRedefinition of 'hmac' as different kind of symbol on NetBSDSince renaming `hmacname` to `hmac` in ffacf0aec6ac265bba307f4ef5f4915406607b7a BIND 9.19 won't build on NetBSD as this platform already defines `hmac` in the `/usr/include/stdlib.h` header:
```
CC dig.o
In file included from dig....Since renaming `hmacname` to `hmac` in ffacf0aec6ac265bba307f4ef5f4915406607b7a BIND 9.19 won't build on NetBSD as this platform already defines `hmac` in the `/usr/include/stdlib.h` header:
```
CC dig.o
In file included from dig.c:45:
./dighost.h:262:24: error: redefinition of 'hmac' as different kind of symbol
extern dst_algorithm_t hmac;
^
/usr/include/stdlib.h:312:10: note: previous definition is here
ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *,
^
dig.c:2461:9: error: non-object type 'ssize_t (const char *, const void *, size_t, const void *, size_t, void *, size_t)' (aka 'long (const char *, const void *, unsigned long, const void *, unsigned long, void *, unsigned long)') is not assignable
hmac = DST_ALG_HMACMD5;
~~~~ ^
2 errors generated.
```
This erorr is on NetBSD 10.0 RC1 but `hmac(3)` suggests this will fail on every NetBSD since v8:
```
NAME
hmac – compute a key-Hash Message Authentication Code
...
HISTORY
The hmac() function appeared in NetBSD 8.
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/stork/-/issues/1249Problem installing danger on operating system with non-US locale2023-12-19T14:42:10ZSlawek FigielProblem installing danger on operating system with non-US localeThe issue was found by @andrei during 1.14 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421412
* I could not run system tests. I get this error on `rake systemtest`. Not sure what is wrong. Sounds like an ...The issue was found by @andrei during 1.14 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421412
* I could not run system tests. I get this error on `rake systemtest`. Not sure what is wrong. Sounds like an encoding could be enforced somewhere.
```
143.7 Bundler version 2.3.26
143.7 /app/tools/ruby/bin/bundle install --gemfile /app/rakelib/init_deps/danger/Gemfile --path /app/tools/ruby --binstubs /app/tools/ruby/bin_bundle
143.7 Preparing: /app/tools/ruby/bin_bundle/danger...
143.7 mkdir -p /app/tools/ruby/bin_bundle
143.9 /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/yaml_serializer.rb:54:in `split': invalid byte sequence in US-ASCII (ArgumentError)
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/yaml_serializer.rb:54:in `load'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/settings.rb:459:in `block in load_config'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/shared_helpers.rb:103:in `filesystem_access'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/settings.rb:455:in `load_config'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/settings.rb:91:in `initialize'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler.rb:342:in `new'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler.rb:342:in `settings'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/env.rb:20:in `report'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/friendly_errors.rb:74:in `request_issue_report_for'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/friendly_errors.rb:53:in `log_error'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/friendly_errors.rb:126:in `rescue in with_friendly_errors'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/friendly_errors.rb:118:in `with_friendly_errors'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/exe/bundle:36:in `<top (required)>'
143.9 from /app/tools/ruby/bin/bundle:25:in `load'
143.9 from /app/tools/ruby/bin/bundle:25:in `<main>'
143.9 /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/yaml_serializer.rb:54:in `split': invalid byte sequence in US-ASCII (ArgumentError)
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/yaml_serializer.rb:54:in `load'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/settings.rb:459:in `block in load_config'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/shared_helpers.rb:103:in `filesystem_access'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/settings.rb:455:in `load_config'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/settings.rb:91:in `initialize'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler.rb:342:in `new'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler.rb:342:in `settings'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/cli.rb:66:in `initialize'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor.rb:388:in `new'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor.rb:388:in `dispatch'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/cli.rb:31:in `dispatch'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/cli.rb:25:in `start'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/exe/bundle:48:in `block in <top (required)>'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/lib/bundler/friendly_errors.rb:120:in `with_friendly_errors'
143.9 from /app/tools/ruby/gems/bundler-2.3.26/exe/bundle:36:in `<top (required)>'
143.9 from /app/tools/ruby/bin/bundle:25:in `load'
143.9 from /app/tools/ruby/bin/bundle:25:in `<main>'
143.9 rake aborted!
143.9 Command failed with status (1): [/app/tools/ruby/bin/bundle install --gemfi...]
143.9 /app/rakelib/00_init.rake:795:in `block in <top (required)>'
143.9 /app/rakelib/00_init.rake:133:in `block in find_and_prepare_deps'
143.9 /app/rakelib/00_init.rake:115:in `each'
143.9 /app/rakelib/00_init.rake:115:in `find_and_prepare_deps'
143.9 /app/rakelib/00_init.rake:1113:in `block in <top (required)>'
143.9 Tasks: TOP => /app/tools/ruby/bin_bundle/danger
143.9 (See full trace by running task with --trace)
```backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4477statschannel test intermittently fails with incorrect zone loadtime2023-12-18T09:40:39ZTom Krizekstatschannel test intermittently fails with incorrect zone loadtimeAfter #3983 was fixed and the `loadtime` check was re-enabled, the following tests occasionally [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848463) because the `loadtime` retrieved over stats channel is 0.
- `statschannel/t...After #3983 was fixed and the `loadtime` check was re-enabled, the following tests occasionally [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848463) because the `loadtime` retrieved over stats channel is 0.
- `statschannel/tests_xml.py::test_zone_timers_secondary_xml`
- `statschannel/tests_json.py::test_zone_timers_secondary_json`
```
________________________ test_zone_timers_secondary_xml ________________________
[gw1] linux -- Python 3.11.2 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_xml.py:118: in test_zone_timers_secondary_xml
generic.test_zone_timers_secondary(
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:101: in test_zone_timers_secondary
check_zone_timers(loaded, expires, refresh, mtime)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:56: in check_zone_timers
check_loaded(loaded, loaded_exp, now)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:45: in check_loaded
assert loaded == expected
E assert datetime.datetime(2023, 12, 6, 0, 28, 43) == datetime.datetime(1970, 1, 1, 0, 0)
```January 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/stork/-/issues/1248Home breadcrumb has an undefined anchor2023-12-21T14:59:47ZSlawek FigielHome breadcrumb has an undefined anchorThe issue was found by @piotrek during [1.14 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421536).
I'm not sure if it is intended, but when breadcrumbs are displayed and you click on a Home breadcrumb, the...The issue was found by @piotrek during [1.14 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421536).
I'm not sure if it is intended, but when breadcrumbs are displayed and you click on a Home breadcrumb, then main dashboard opens in a new tab. Anchor `target` is `undefined`:
```html
<a class="p-menuitem-link ng-star-inserted" href="/" target="undefined" tabindex="0">
```
Usually breadcrumbs anchors work with `target="_self"`.1.15Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/stork/-/issues/1247DB password prompt hangs out on Ctrl-C2023-12-19T14:40:48ZSlawek FigielDB password prompt hangs out on Ctrl-CThe issue was found by @piotrek during [1.14 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421388).
Other thing observed is, interrupting `rake` task with `Ctrl+C` when it asks for some password, breaks the...The issue was found by @piotrek during [1.14 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1240#note_421388).
Other thing observed is, interrupting `rake` task with `Ctrl+C` when it asks for some password, breaks the terminal behavior afterwards. Terminal still waits for password and you can't type nor use the terminal in a normal way. This is not the case when you use e.g. `psql` and use `Ctrl+C` when it asks for password. You get back to normal operation of your terminal afterwards, which is expected.backlog