ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-01-28T16:39:38Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2256Make the nmhandle attach/detach transparent2021-01-28T16:39:38ZOndřej SurýMake the nmhandle attach/detach transparentCurrently, the netmgr callbacks need to manually attach/detach to the `isc_nmhandle_t` which makes the usage very error prone (it's fairly easy to forgot some weird path).
The code needs to be refactored, so the attach/detach is interna...Currently, the netmgr callbacks need to manually attach/detach to the `isc_nmhandle_t` which makes the usage very error prone (it's fairly easy to forgot some weird path).
The code needs to be refactored, so the attach/detach is internal to the netmgr and not visible to the outside, e.g. instead of doing:
```
isc_nm_udpconnect(..., connect_cb, ...);
void
connect_cb(handle, ...) {
isc_nmhandle_attach(handle, &read_handle);
isc_nm_read(read_handle, read_cb, ...);
isc_nmhandle_attach(handle, &send_handle);
isc_nm_send(send_handle, send_cb, ...);
isc_nmhandle_detach(&handle);
}
void
read_cb(handle, ...) {
/* process data */
isc_nmhandle_detach(&handle);
}
void
send_cb(handle, ...) {
/* process */
isc_nmhandle_detach(&handle);
}
```
we should just do:
```
isc_nm_udpconnect(..., connect_cb, ...);
void
connect_cb(handle, ...) {
isc_nm_read(handle, read_cb, ...);
isc_nm_send(handle, send_cb, ...);
}
void
read_cb(handle, ...) {
/* process */
}
void
send_cb(handle, ...) {
/* process */
}
```
Basically, the `isc_nm_read()`, `isc_nm_send()` and others needs to attach to the handle itself, and detach after calling the use supplied callback. It's probably going to be a little bit more complicated than that, but it should be fairly straightforward to fix all the paths in the code.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2255dig crashed in tcp_connected() on OpenBSD2020-11-12T14:12:12ZMichal Nowakdig crashed in tcp_connected() on OpenBSD`dig` [crashed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1284077) on OpenBSD. We don't have the core because the CI job hung.
```
S:zero:2020-11-09T11:02:53+0000
T:zero:1:A
A:zero:System test zero
I:zero:PORTS:15033,15034,15035,1...`dig` [crashed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1284077) on OpenBSD. We don't have the core because the CI job hung.
```
S:zero:2020-11-09T11:02:53+0000
T:zero:1:A
A:zero:System test zero
I:zero:PORTS:15033,15034,15035,15036,15037,15038,15039,15040,15041,15042
I:zero:starting servers
I:zero:check lookups against TTL=0 records (1)
I:zero:successfully completed pass 1 of 10
I:zero:successfully completed pass 2 of 10
I:zero:successfully completed pass 3 of 10
I:zero:successfully completed pass 4 of 10
Abort trap (core dumped)
I:zero:failed
I:zero:check repeated recursive lookups of non recurring TTL=0 responses get new values (2)
I:zero:check lookups against TTL=1 records (3)
I:zero:successfully completed pass 1 of 10
I:zero:successfully completed pass 2 of 10
I:zero:successfully completed pass 3 of 10
I:zero:successfully completed pass 4 of 10
I:zero:successfully completed pass 5 of 10
I:zero:successfully completed pass 6 of 10
I:zero:successfully completed pass 7 of 10
I:zero:successfully completed pass 8 of 10
I:zero:successfully completed pass 9 of 10
I:zero:successfully completed pass 10 of 10
I:zero:exit status: 1
I:zero:stopping servers
I:zero:Core dump(s) found: zero/dig.core
D:zero:backtrace from zero/dig.core:
D:zero:--------------------------------------------------------------------------------
D:zero:Core was generated by `dig'.
D:zero:Program terminated with signal SIGABRT, Aborted.
D:zero:#0 thrkill () at /tmp/-:3
D:zero:[Current thread is 1 (process 175366)]
D:zero:#0 thrkill () at /tmp/-:3
D:zero:#1 0x00000bbe10cbb20e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
D:zero:#2 0x00000bbe10c9873c in _rthread_mutex_trylock (mutex=<optimized out>, trywait=<optimized out>, abs=0x0) at /usr/src/lib/libc/thread/rthread_mutex.c:117
D:zero:#3 _rthread_mutex_timedlock (mutexp=0xbbb1b07e920 <lookup_lock>, trywait=<optimized out>, abs=0x0, timed=<optimized out>) at /usr/src/lib/libc/thread/rthread_mutex.c:167
D:zero:#4 0x00000bbb1b075a1e in tcp_connected (handle=0x0, eresult=5, arg=0xbbde14c8220) at dighost.c:3217
D:zero:#5 0x00000bbd7ecd1547 in tcpdnsconnect_cb (handle=<optimized out>, result=5, arg=<optimized out>) at netmgr/tcpdns.c:746
D:zero:#6 0x00000bbd7eccffab in failed_connect_cb (sock=0xbbdd0a42800, req=0x0, eresult=5) at netmgr/tcp.c:136
D:zero:#7 0x00000bbd7eccd453 in tcp_connect_direct (sock=0xbbdd0a42800, req=<optimized out>) at netmgr/tcp.c:208
D:zero:#8 isc__nm_async_tcpconnect (worker=<optimized out>, ev0=<optimized out>) at netmgr/tcp.c:235
D:zero:#9 0x00000bbd7eccd786 in isc_nm_tcpconnect (mgr=0xbbde14a7000, local=0xbbb1b07e690 <localaddr>, peer=<optimized out>, cb=<optimized out>, cbarg=<optimized out>, timeout=<optimized out>, extrahandlesize=0) at netmgr/tcp.c:348
D:zero:#10 0x00000bbd7ecd14b7 in isc_nm_tcpdnsconnect (mgr=0xbbde14a7000, local=0x6, peer=0x0, cb=0xbbb1b075980 <tcp_connected>, cbarg=0xbbde14c8220, timeout=985019968, extrahandlesize=0) at netmgr/tcpdns.c:802
D:zero:#11 0x00000bbb1b073c5a in start_tcp (query=0xbbde14c8220) at dighost.c:2824
D:zero:#12 0x00000bbb1b0755bc in clear_current_lookup () at dighost.c:1817
D:zero:#13 0x00000bbb1b076211 in recv_done (handle=<optimized out>, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at dighost.c:4063
D:zero:#14 0x00000bbd7ecd2de3 in udp_recv_cb (handle=<optimized out>, nrecv=70, buf=0xbbe0731c140, addr=0xbbe0731c010, flags=<optimized out>) at netmgr/udp.c:405
D:zero:#15 0x00000bbd7ecd443b in udp_read_cb (handle=0xbbdbb6d5160, nrecv=6, buf=0x0, addr=0xbbe10cbd61a <thrkill+10>, flags=4014601344) at netmgr/udp.c:864
D:zero:#16 0x00000bbe05585104 in uv.udp_io () from /usr/local/lib/libuv.so.2.1
D:zero:#17 0x00000bbe055866d5 in uv.io_poll () from /usr/local/lib/libuv.so.2.1
D:zero:#18 0x00000bbe05575c31 in uv_run () from /usr/local/lib/libuv.so.2.1
D:zero:#19 0x00000bbd7ecc8fcb in nm_thread (worker0=0xbbde14a9000) at netmgr/netmgr.c:498
D:zero:#20 0x00000bbdaa877e21 in _rthread_start (v=<optimized out>) at /usr/src/lib/librthread/rthread.c:96
D:zero:#21 0x00000bbe10ca65b8 in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
D:zero:#22 0x0000000000000000 in ?? ()
D:zero:--------------------------------------------------------------------------------
D:zero:full backtrace from zero/dig.core saved in dig.core-backtrace.txt
D:zero:core dump zero/dig.core archived as zero/dig.core.gz
R:zero:FAIL
E:zero:2020-11-09T11:03:44+0000
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/kea/-/issues/1534Sanity checks for Kea 1.8.1 rc12020-12-09T12:19:03ZMichal NowikowskiSanity checks for Kea 1.8.1 rc1```
We are now at step SANITY CHECKS of Kea 1.8.1 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. pl...```
We are now at step SANITY CHECKS of Kea 1.8.1 rc1.
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
Before starting any checks. please, state in Sanity Checks issue in GitLab
what check you are doing in a thread/discussion (not as comment).
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.8.1-rc1
/data/shared/sweng/kea/releases/premium-1.8.1-rc1
/data/shared/sweng/kea/releases/subscription-1.8.1-rc1
SHA256 (kea-1.8.1.tar.gz) = 52020cb16889484b661746d7fc4c7cd88974b1af5b7fc436eb6e69c62eb83734
SHA256 (kea-subscription-1.8.1.tar.gz) = 4bc6e61cf4a4b00ca5dc51b24086ed76703daad4f7ad97c1c5ffaeca3e8c7002
SHA256 (kea-premium-1.8.1.tar.gz) = a95de737c0bf29bbc8b8d351420cd05322003a69e04a79d866cde8512f167f1f
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-1.8/job/pkg/13/
Release version is 1.8.1-isc0000920201106154401 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```kea1.8.1https://gitlab.isc.org/isc-projects/bind9/-/issues/2254named.conf man page formatting2023-11-01T07:33:03ZTom Marcoennamed.conf man page formattingThe ''named.conf'' man page displays the comment styles in the DESCRIPTION as:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
is this weird spacing intentional? I would expect it to be:
```
C style...The ''named.conf'' man page displays the comment styles in the DESCRIPTION as:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
is this weird spacing intentional? I would expect it to be:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
The code in the man page is:
```
.sp
C style: /* */
.INDENT 0.0
.INDENT 3.5
C++ style: // to end of line
.UNINDENT
.UNINDENT
.sp
Unix style: # to end of line
```
Perhaps it can be changed to:
```
.sp
C style: /* */
.INDENT 0.0
C++ style: // to end of line
.UNINDENT
.INDENT 0.0
Unix style: # to end of line
.UNINDENT
```
PS: This man page appears to be missing from the appendix of the ARM (v9.16.8).https://gitlab.isc.org/isc-projects/bind9/-/issues/2253dnssec-signzone dumped core in PKCS11 job2020-11-13T11:16:06ZMichal Nowakdnssec-signzone dumped core in PKCS11 jobOn `v9_11` `dnssec-signzone` dumped core in `dnssec` test of [PKCS11 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1281693):
```
I:dnssec:Core dump(s) found: dnssec/ns2/core.6516
R:dnssec:FAIL
D:dnssec:backtrace from dnssec/ns2/...On `v9_11` `dnssec-signzone` dumped core in `dnssec` test of [PKCS11 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1281693):
```
I:dnssec:Core dump(s) found: dnssec/ns2/core.6516
R:dnssec:FAIL
D:dnssec:backtrace from dnssec/ns2/core.6516:
D:dnssec:--------------------------------------------------------------------------------
D:dnssec:Core was generated by `/builds/isc-projects/bind9/bin/dnssec/.libs/dnssec-signzone -P -g -r /builds/is'.
D:dnssec:Program terminated with signal SIGSEGV, Segmentation fault.
D:dnssec:#0 0x00007fa35a5e1eec in ?? () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:[Current thread is 1 (Thread 0x7fa34e935700 (LWP 6553))]
D:dnssec:#0 0x00007fa35a5e1eec in ?? () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:#1 0x00007fa35a58936e in ?? () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:#2 0x00007fa35a56e18f in C_DestroyObject () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:#3 0x00007fa35d090cfc in pkcs_C_DestroyObject (hSession=24, hObject=49) at pk11_api.c:242
D:dnssec:#4 0x00007fa35d5f5881 in pkcs11rsa_destroyctx (dctx=0x7fa35a82c808) at pkcs11rsa_link.c:500
D:dnssec:#5 0x00007fa35d5fbcaa in dst_context_destroy (dctxp=dctxp@entry=0x7fa34e932a68) at dst_api.c:395
D:dnssec:#6 0x00007fa35d4a8095 in dns_dnssec_sign (name=<optimized out>, set=<optimized out>, key=<optimized out>, inception=<optimized out>, expire=<optimized out>, mctx=0x561d5c0efe70, buffer=0x7fa34e932c50, sigrdata=0x7fa34e933490) at dnssec.c:360
D:dnssec:#7 0x0000561d5bfbe509 in signwithkey (name=0x7fa35a844430, rdataset=0x7fa34e934d60, key=0x7fa35a82d0c8, ttl=3600, add=0x7fa34e934d10, logmsg=0x561d5bfcd6bb "signing with dnskey") at ./dnssec-signzone.c:298
D:dnssec:#8 0x0000561d5bfc46a6 in signset (set=0x7fa34e934d60, name=0x7fa35a844430, node=0x7fa35a827410, add=0x7fa34e934d10, del=0x7fa34e934d30) at ./dnssec-signzone.c:700
D:dnssec:#9 signname (node=0x7fa35a827410, name=0x7fa35a844430) at ./dnssec-signzone.c:1101
D:dnssec:#10 0x0000561d5bfc480a in sign (task=0x7fa35a839268, event=<optimized out>) at ./dnssec-signzone.c:1599
D:dnssec:#11 0x00007fa35d08940d in dispatch (manager=0x7fa35a810eb0) at task.c:1157
D:dnssec:#12 run (uap=0x7fa35a810eb0) at task.c:1331
D:dnssec:#13 0x00007fa35cddefa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:dnssec:#14 0x00007fa35cb664cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
D:dnssec:--------------------------------------------------------------------------------
D:dnssec:full backtrace from dnssec/ns2/core.6516 saved in core.6516-backtrace.txt
D:dnssec:core dump dnssec/ns2/core.6516 archived as dnssec/ns2/core.6516.gz
```
[core.6516.gz](/uploads/9660bac0f82322f21c8ebb31b715d1cd/core.6516.gz)
[core.6516-backtrace.txt](/uploads/819a6d5d2ae5ddbaf9e05aca486f76ca/core.6516-backtrace.txt)
[dnssec-signzone](/uploads/5ea5936415a18153b05f5391f0c552a7/dnssec-signzone)November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/2252ns_client_sendraw() is missing DNSTAP support.2020-11-13T11:04:35ZMark Andrewsns_client_sendraw() is missing DNSTAP support.Found in the course of discussing [Support RT#17273][1] (though not
directly related to the issue reported in that ticket).
[1]: https://support.isc.org/Ticket/Display.html?id=17273Found in the course of discussing [Support RT#17273][1] (though not
directly related to the issue reported in that ticket).
[1]: https://support.isc.org/Ticket/Display.html?id=17273November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/stork/-/issues/448HA state disappears on Kea app page2023-02-08T16:52:49ZMarcin SiodelskiHA state disappears on Kea app pageThis is a result of the Stork 0.13.0 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174642
@godfryd pointed out that "HA state disappears on Kea app page". Repro:
* add in the demo two kea instances (ha1 and...This is a result of the Stork 0.13.0 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174642
@godfryd pointed out that "HA state disappears on Kea app page". Repro:
* add in the demo two kea instances (ha1 and ha2)
* open kea apps page
* open both apps on separate tabs
* stop ha1/dhcp4 service in Stork Env Simulator
* on ha1 tab there should be presented info about connectivity issues
* on ha2 tab HA state may be presented by when tabs are switched between ha1 and ha2 then HA state disappears on ha2 tab (it may reappear after a while when new HA state is retrieved from the server)1.9Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/447Cannot fetch machine state when using IPv6 address2021-12-02T16:59:54ZMarcin SiodelskiCannot fetch machine state when using IPv6 addressThis is a result of Stork 0.13.0 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174641
@godfryd pointed out that: "Adding agent to server using IPv6 address does not work well. Server cannot fetch machine sta...This is a result of Stork 0.13.0 sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174641
@godfryd pointed out that: "Adding agent to server using IPv6 address does not work well. Server cannot fetch machine state."
Need to investigate it further.1.0Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/446Race and constraint errors when adding Kea with many subnets2020-11-30T07:31:17ZMarcin SiodelskiRace and constraint errors when adding Kea with many subnetsThis is a result of sanity checks for Stork 0.13.0 release. See https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174606
Copying over the errors and the debugging result below:
While testing the demo on Ubuntu 20.04 I apparen...This is a result of sanity checks for Stork 0.13.0 release. See https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174606
Copying over the errors and the debugging result below:
While testing the demo on Ubuntu 20.04 I apparently reproduced the issue earlier mentioned by @godfryd here: https://gitlab.isc.org/isc-projects/stork/-/merge_requests/230#note_173942
I've got the following error trace:
```
server_1 | ERRO[2020-11-05 10:03:47] statepuller.go:278 cannot store application state: ERROR #23505 duplicate key value violates unique constraint "access_point_unique_idx"
server_1 | problem with adding access point to app 11: &{11 control 8 127.0.0.1 8000 }
server_1 | isc.org/stork/server/database/model.updateAppAccessPoints
server_1 | /repo/build-root/backend/server/database/model/app.go:68
server_1 | isc.org/stork/server/database/model.AddApp
server_1 | /repo/build-root/backend/server/database/model/app.go:226
server_1 | isc.org/stork/server/apps/kea.CommitAppIntoDB
server_1 | /repo/build-root/backend/server/apps/kea/appkea.go:462
server_1 | isc.org/stork/server/apps.GetMachineAndAppsState
server_1 | /repo/build-root/backend/server/apps/statepuller.go:269
server_1 | isc.org/stork/server/apps.(*StatePuller).pullData
server_1 | /repo/build-root/backend/server/apps/statepuller.go:59
server_1 | isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
server_1 | /repo/build-root/backend/server/agentcomm/puller.go:93
server_1 | runtime.goexit
server_1 | /repo/build-root/tools/1.13.5/go/src/runtime/asm_amd64.s:1357
server_1 | problem with adding access points to app: &{ID:11 CreatedAt:2020-11-05 10:03:46.320564 +0000 UTC MachineID:8 Machine:0xc000e8e160 Type:kea Active:false Meta:{Version:1.7.3 ExtendedVersion:} AccessPoints:[0xc002c34820] Daemons:[0xc0007c00d0 0xc00023e8f0 0xc00037e0d0 0xc00037ef70]}
server_1 | isc.org/stork/server/database/model.AddApp
server_1 | /repo/build-root/backend/server/database/model/app.go:228
server_1 | isc.org/stork/server/apps/kea.CommitAppIntoDB
server_1 | /repo/build-root/backend/server/apps/kea/appkea.go:462
server_1 | isc.org/stork/server/apps.GetMachineAndAppsState
server_1 | /repo/build-root/backend/server/apps/statepuller.go:269
server_1 | isc.org/stork/server/apps.(*StatePuller).pullData
server_1 | /repo/build-root/backend/server/apps/statepuller.go:59
server_1 | isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
server_1 | /repo/build-root/backend/server/agentcomm/puller.go:93
server_1 | runtime.goexit
server_1 | /repo/build-root/tools/1.13.5/go/src/runtime/asm_amd64.s:1357
server_1 | ERRO[2020-11-05 10:03:47] statepuller.go:62 error occurred while getting info from machine 8: problem with storing application state in the database
server_1 | INFO[2020-11-05 10:03:47] statepuller.go:67 completed pulling information from machines: 0/1 succeeded
server_1 | ERRO[2020-11-05 10:03:47] puller.go:95 errors were encountered while pulling data from apps: problem with storing application state in the database
server_1 | isc.org/stork/server/apps.(*StatePuller).pullData
server_1 | /repo/build-root/backend/server/apps/statepuller.go:61
server_1 | isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
server_1 | /repo/build-root/backend/server/agentcomm/puller.go:93
server_1 | runtime.goexit
server_1 | /repo/build-root/tools/1.13.5/go/src/runtime/asm_amd64.s:1357
server_1 | INFO[2020-11-05 10:03:48] middleware.go:42 served request
```
Looking further into the code I think that this is what happens:
* User adds new machine via UI. The machine runs Kea with many subnets.
* The machine entry is fairly quickly added to the database and then apps state is being fetched.
* Before the app is added to the db its configuration is being fetched so it takes a while before we create app entry in the db.
* The state puller monitors this machine already so it tries to get its updated state.
* The state puller checks if the app is already in the db, but it is not because the first operation of machine creation is still in progress.
* The state puller assumes it found a new Kea app because there is no such app in the db yet. The state puller will proceed as it was to add a new app.
* The initial create machine operation finally completes.
* The state pulling also completes and the state puller attempts to add the "new app" into db.
* This operation causes no conflict with (app_id, type) because the puller assigned new app_id, treating it as a new machine.
* This causes an attempt to insert the new app which fails because of the (machine_id, port) constraint.
Overall, the database state should remain consistent because the second instance of the app is not added. But, it produces a lot of work for the server to do parallel updates and also causes a lot of traffic.
The solution in #409 apparently worked because it fetched existing app by (type) rather than (type, app_id). Overall, the right approach would rather be to not do state pulling before the previous pull has completed. We'd need to implement some signaling for it.0.14Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/445Crashes observed in traffic simulator in 0.132022-02-04T09:06:46ZMarcin SiodelskiCrashes observed in traffic simulator in 0.13This is a result of sanity checks for 0.13.0. See the following comment: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174569
It was pointed out that:
"After using Stork Demo for a while I wanted to try Stork Environment ...This is a result of sanity checks for 0.13.0. See the following comment: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174569
It was pointed out that:
"After using Stork Demo for a while I wanted to try Stork Environment Simulator. I noticed that it crashes on http://localhost:5000/services URL."
With the following stack trace:
```
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 2464, in __call__
return self.wsgi_app(environ, start_response)
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 2450, in wsgi_app
response = self.handle_exception(e)
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1867, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/dist-packages/flask/_compat.py", line 39, in reraise
raise value
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 2447, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1952, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1821, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/dist-packages/flask/_compat.py", line 39, in reraise
raise value
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1950, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1936, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/sim/sim.py", line 309, in get_services
data = _get_services()
File "/sim/sim.py", line 284, in _get_services
machines = r.json()['items']
KeyError: 'items'
```1.0-backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/444Fix typos and line lengths in ChangeLog2020-11-26T15:57:16ZMarcin SiodelskiFix typos and line lengths in ChangeLogThis is a result of sanity checks for Stork 0.13.0: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174495
There are typos in the ChangeLog: "develope" instead of "develop" in the entry 106. "eg." instead of "e.g." in entry 1...This is a result of sanity checks for Stork 0.13.0: https://gitlab.isc.org/isc-projects/stork/-/issues/441#note_174495
There are typos in the ChangeLog: "develope" instead of "develop" in the entry 106. "eg." instead of "e.g." in entry 113. "adjuste" instead of "adjusted" in entry 114.
Also, some ChangeLog lines are too long (>73) and wrap in the release notes.0.14Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2251bin/rndc/rndc.conf is of questionable use2023-11-01T07:31:53ZMichal Nowakbin/rndc/rndc.conf is of questionable useSome files tracked by Git are of questionable use, e.g. `bin/rndc/rndc.conf`.
(Branched off from https://gitlab.isc.org/isc-projects/bind9/-/issues/1913.)Some files tracked by Git are of questionable use, e.g. `bin/rndc/rndc.conf`.
(Branched off from https://gitlab.isc.org/isc-projects/bind9/-/issues/1913.)BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2250DNS Flag Day 2020 - EDNS buffer size configuring does not work anymore2020-12-02T22:34:28ZArsen StasicDNS Flag Day 2020 - EDNS buffer size configuring does not work anymore<!--
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 do *NOT* report it here, but send an
email to [...<!--
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 do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
I think !4179 introduced a bug, that any config option of max-udp-size or edns-udp-size are not working anymore.
### BIND version used
9.16.8
9.11.24
old versions ( 9.16.7 , 9.11.23 ) don't show this behavior
### Steps to reproduce
Install new bind and following config:
```
edns-udp-size 2000;
max-udp-size 2000;
```
But you will still get a TC-bit for queries bigger than 1232 byte.
### What is the current *bug* behavior?
You get the TC-bit even if the answer is lower than 2000 byte long.
### What is the expected *correct* behavior?
Not getting the TC-bit.
### Relevant configuration files
```
edns-udp-size 2000;
max-udp-size 2000;
```
### Relevant logs and/or screenshots
With the new version installed on 28th October 2020 the TCP queries for DNSKEY quadrupled:
![Screenshot_2020-11-06_DSC-Grafana](/uploads/c633160feb899346b14ced8c47403ff0/Screenshot_2020-11-06_DSC-Grafana.png)
### Possible fixes
I think !4179 introduced this bug.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1533Changes for Kea 1.8.1 release2020-11-27T06:38:00ZMichal NowikowskiChanges for Kea 1.8.1 releasekea1.8.1Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1532rawip interface support2020-11-26T16:59:22ZFrancis Dupontrawip interface supportA patch (https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/66) was proposed for ISC DHCP to add support for interfaces using the rawip ARP hardware type. I propose when the ISC DHCP part will be ready to do the same for Kea.
(tr...A patch (https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/66) was proposed for ISC DHCP to add support for interfaces using the rawip ARP hardware type. I propose when the ISC DHCP part will be ready to do the same for Kea.
(triage proposal: put it in 1.x and re-triage it when the ISC DHCP part will be ready)outstandinghttps://gitlab.isc.org/isc-projects/keama/-/issues/6Keama doesn't build on Free BSD 12.12024-02-08T13:50:37ZPeter DaviesKeama doesn't build on Free BSD 12.1Keama doesn't build on Free BSD 12.1
./configure
make
...
cd keama
make
cc -DHAVE_CONFIG_H -I. -I../includes -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/tmp/dhcp-4.4.2/bind/include -MT keama.o -MD -MP -MF .deps/k...Keama doesn't build on Free BSD 12.1
./configure
make
...
cd keama
make
cc -DHAVE_CONFIG_H -I. -I../includes -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/tmp/dhcp-4.4.2/bind/include -MT keama.o -MD -MP -MF .deps/keama.Tpo -c -o keama.o keama.c
keama.c:75:19: error: use of undeclared identifier 'AF_INET'
local_family = AF_INET;
^
keama.c:77:19: error: use of undeclared identifier 'AF_INET6'
local_family = AF_INET6;
^
See [RT #17269](https://support.isc.org/Ticket/Display.html?id=17269)4.5.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/147Keama doesn't build on Free BSD 12.12023-05-17T11:22:24ZPeter DaviesKeama doesn't build on Free BSD 12.1Keama doesn't build on Free BSD 12.1
./configure
make
...
cd keama
make
cc -DHAVE_CONFIG_H -I. -I../includes -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/tmp/dhcp-4.4.2/bind/include -MT keama.o -MD -MP -MF .deps/k...Keama doesn't build on Free BSD 12.1
./configure
make
...
cd keama
make
cc -DHAVE_CONFIG_H -I. -I../includes -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/tmp/dhcp-4.4.2/bind/include -MT keama.o -MD -MP -MF .deps/keama.Tpo -c -o keama.o keama.c
keama.c:75:19: error: use of undeclared identifier 'AF_INET'
local_family = AF_INET;
^
keama.c:77:19: error: use of undeclared identifier 'AF_INET6'
local_family = AF_INET6;
^
See [RT #17269](https://support.isc.org/Ticket/Display.html?id=17269)4.5.0-betahttps://gitlab.isc.org/isc-projects/kea/-/issues/1530bump lib versions for 1.8.12020-11-27T06:38:00ZRazvan Becheriubump lib versions for 1.8.1bump lib versions for 1.8.1bump lib versions for 1.8.1kea1.8.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/146Add support for raw IP interface type2020-12-03T10:15:34ZFrancis DupontAdd support for raw IP interface typeSee !66 (issue created to host it).See !66 (issue created to host it).4.5.0-betaFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2249Stop falling back to plain DNS on FORMERR+OPT2023-05-08T12:37:02ZMark AndrewsStop falling back to plain DNS on FORMERR+OPTThe number of servers on the Internet that have this mis-behaviour have fallen to negligible levels. FORMERR+OPT should now be treated as not meaning EDNS is not supported. Any remaining servers with this behaviour can be handled by ser...The number of servers on the Internet that have this mis-behaviour have fallen to negligible levels. FORMERR+OPT should now be treated as not meaning EDNS is not supported. Any remaining servers with this behaviour can be handled by server clauses.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)