ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-11-26T17:01:53Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1577HA load balancing sometimes drop pkgs2020-11-26T17:01:53ZWlodzimierz WencelHA load balancing sometimes drop pkgsaffected: HA load-balancing in ST, MT mode, v4 and v6, with memfile, mysql, pgsql
configuration attached
[kea-dhcp6.conf1](/uploads/60c494b6270f7e1ffd52f3688776d617/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/c541b03ae04838db1faaed84d78...affected: HA load-balancing in ST, MT mode, v4 and v6, with memfile, mysql, pgsql
configuration attached
[kea-dhcp6.conf1](/uploads/60c494b6270f7e1ffd52f3688776d617/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/c541b03ae04838db1faaed84d789b41b/kea-dhcp6.conf)
logs:
[kea.log](/uploads/b57a83cc372c468a0f2d910651c032c1/kea.log)
[kea.log-CA](/uploads/8c97c1b65c2ba2cadb37a2c5912bb8aa/kea.log-CA)
[kea.log](/uploads/41b859db7e2c35236a9703f307940a38/kea.log)
[kea.log-CA](/uploads/4eb9f2c675a206e72614565e7b37c9d3/kea.log-CA)
What happens:
- client sends discover/solicit
- server gets discover/solicit and decide that this message is for him, and proceed with assigning lease
- server send offer/advertise
- client gets offer/advertise sends back request to the server
- server gets request and decide that this is not for him, drops request :(https://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/2306Compilation broken on systems without <sys/un.h>2020-11-26T15:52:36ZMichal NowakCompilation broken on systems without <sys/un.h>Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
s...Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
ssu_external.c:59:31: warning: unused parameter ‘path’ [-Wunused-parameter]
59 | ux_socket_connect(const char *path) {
| ~~~~~~~~~~~~^~~~
getaddrinfo.c: In function ‘get_local’:
getaddrinfo.c:1243:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr_un’
1243 | ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
| ^
getaddrinfo.c:1249:16: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
getaddrinfo.c:1249:47: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
```
I don't know what operating systems might be affected, probably none (even Solaris 10 has it), one can "emulate" it like this and rebuild with `autoreconf -fi`:
```patch
--- a/configure.ac
+++ b/configure.ac
@@ -1799,9 +1799,9 @@ AS_IF([test "$enable_linux_caps" = "yes"],
AC_SUBST([LIBCAP_LIBS])
AC_CHECK_HEADERS(sys/un.h,
-ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
-,
ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH"
+,
+ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
)
AC_SUBST(ISC_PLATFORM_HAVESYSUNH)
```
I tried for a short while and followed the compiler in fixing warnings and disabling code with `#ifdef ISC_PLATFORM_HAVESYSUNH` but I end up with either failing `tsiggss` system test or crashing `named`.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2309dig core dump on SIGINT2020-11-26T09:30:10ZPeter Daviesdig core dump on SIGINT
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# d...
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# dig @173.37.137.80 .
^Cdighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back trace
/usr/local/lib/libisc.so.1706(+0x3d3e9) [0x7f67f2fca3e9]
/usr/local/lib/libisc.so.1706(isc_assertion_failed+0x10) [0x7f67f2fca320]
dig(+0x1728a) [0x56374da2028a]
dig(+0xc5fd) [0x56374da155fd]
dig(+0x6bb0) [0x56374da0fbb0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f67f2afc1e3]
dig(+0x6bee) [0x56374da0fbee]
Aborted (core dumped)
```
### What is the current *bug* behavior?
Core dumps
### What is the expected *correct* behavior?
silent exit
### Relevant configuration files
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### 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.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/kea/-/issues/1565Sanity checks for Kea 1.9.2 rc12020-11-26T08:41:24ZjenkinsSanity checks for Kea 1.9.2 rc1```We are now at step SANITY CHECKS of Kea 1.9.2 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. ple...```We are now at step SANITY CHECKS of Kea 1.9.2 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.9.2-rc1
/data/shared/sweng/kea/releases/premium-1.9.2-rc1
/data/shared/sweng/kea/releases/subscription-1.9.2-rc1
SHA256 (kea-1.9.2.tar.gz) = da2585007783ed6cc904cd04a6817b040aedf7c5ecff66e3188db793a7939151
SHA256 (kea-premium-1.9.2.tar.gz) = 16f82cad89257cdf0914e6d2bfa8a502be776583e76d05684a6b581b5a754f3a
SHA256 (kea-subscription-1.9.2.tar.gz) = 14d90827cc08689df2f60526a3ef1cbf6045ab4adb41e3d28d33121598b59e23
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-dev/job/pkg/127/
Release version is 1.9.2-isc0009720201123144834 (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.9.2https://gitlab.isc.org/isc-projects/kea/-/issues/1304basic HTTP authentication2020-11-25T21:13:52ZFrancis Dupontbasic HTTP authenticationRelated to #1120 and #1263 but addressing only the access to the control agent by local unprivileged users.
The idea is to implement the basic HTTP authentication (https://tools.ietf.org/html/rfc7617):
- add user and optionally passwor...Related to #1120 and #1263 but addressing only the access to the control agent by local unprivileged users.
The idea is to implement the basic HTTP authentication (https://tools.ietf.org/html/rfc7617):
- add user and optionally password (for the user:password form) in HA config
- add user and optionally password to Kea shell
- add user and password list and realm to CA config
- add the capability to pass the basic credential (i.e. base64(user:password)) to HTTP client code
- add the basic authentication support (require header and check credential from a reversed map) to HTTP listener code
- add support from octet string to UTF-8 translation (JSON is Unicode32, we support its 8 bit subset)
- update the Kea secure shell and the RBAC reverse proxykea1.9.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/421pulling periodically information by server from kea with 4500 subnets consume...2020-11-24T11:56:13ZMichal Nowikowskipulling periodically information by server from kea with 4500 subnets consumes whole server's CPUAfter adding a machine with kea that is configured with 4500 subnets the servers starts to consume whole CPU.
The first observations indicate that processing large responses on the Stork server side takes much time.After adding a machine with kea that is configured with 4500 subnets the servers starts to consume whole CPU.
The first observations indicate that processing large responses on the Stork server side takes much time.0.14Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/374Notes from Second User test2020-11-23T17:36:51ZVicky Riskvicky@isc.orgNotes from Second User testThe recording of this session is stored in my home directory on our shared drive (only accessible to ISC staff, sorry). Note that the application refresh was particularly slow during this session so a few observations may be due to that...The recording of this session is stored in my home directory on our shared drive (only accessible to ISC staff, sorry). Note that the application refresh was particularly slow during this session so a few observations may be due to that (perhaps the screen would have updated if he had waited longer.)
- [x] As with the first user, this user wanted to add new machines under settings, or under hosts. However, when subsequently looking for machines, was perfectly able to find them under the services menu. Perhaps add a link on the Stork settings page to the Machines page? https://gitlab.isc.org/isc-projects/stork/-/issues/386
- [ ] Tracking from one screen to another is still confusing, even for a fairly experienced user. "I am not finding ID numbers useful." Initially thought the ID number was for the host, not the app.
- [ ] The AppID is one key that is available on multiple screens. Consider permitting the user to alias that to a term that is more meaningful to the user. If we do that, please reflect the alias everywhere we currently have AppID.
- [x] The user tried to look at the scopes held by each member of the HA pair. This information doesn't seem to be available. He also seemed to think that HA was not configured correctly because the standby machine reported it was not serving any scopes. I think that is as designed, but perhaps we could use a tip under HA/ scopes to say that if the server is not presently active, no scopes will be shown. https://gitlab.isc.org/isc-projects/stork/-/issues/387
- The user felt that a time-series graph of the # of addresses in each subnet is not useful. (Grafana) (no action)
- Grafana, # of leases assigned was not clear enough to the user. Are these active leases? User thought the # of leases assigned was not very useful. (we decided to leave this for now and see if any other users find this confusing)
- [x] The user was not satisfied with the CPU load factor shown. Look at around minute 35 of the recording. The user disagrees with the definition of CPU load displayed. (@Godfryd to view the tape to see if he can discover the issue. The display we are using is a standard OS function.)
- This user thought that the DHCP administrator would not be responsible for upgrading the OS on the hosts and thought that a DHCP dashboard is not the right place to monitor OS versions. (no action - this will vary by the organization size and complexity.)
- In the Kea detail app view, couldn't tell if the display was communicating which hooks are installed on disk or which hooks are actually loaded. Might be something to check in the documentation. (we decided to leave this for now and see if any other users find this confusing)
- The user was easily able to turn off monitoring for a specific daemon. The user was not confused about the ability to separately turn off monitoring for the daemon vs the CA. (no action required)
- [x] When clicking on the More button on the dashboard under the subnets display, it should display just the DHCPv4 or DHCPv6 subnets (depending on which More button is clicked). https://gitlab.isc.org/isc-projects/stork/-/issues/389
- [x] When the user disabled monitoring on the agent-kea6 application, the subnets on that application did not disappear from the subnets list. The same occurred with turning off monitoring for a DHCPv4 daemon. Utilization numbers on the subnets on this application that was not supposed to be monitored kept updating in Stork. This seems like a bug. https://gitlab.isc.org/isc-projects/stork/-/issues/390
- [x] The user suggested he would like to 'ignore' or stop monitoring a specific subnet. (I think that what he really wanted to do was to no longer see alerts on high utilization on that subnet.) (No action at this time.)
- [x] Some of the events are initiated by a User. Please provide a way to determine from the event which Stork user made the change (e.g. monitoring on/off, adding or removing a machine) https://gitlab.isc.org/isc-projects/stork/-/issues/388
- [x] The user was expecting when clicking on an event in the dashboard to drill down on the event, not to navigate to the app the event related to. (at the moment there IS no more detail, but if we add events with more detail, we will consider this) No action at this time.
- [x] The user is OK with not being able to see details on a machine that was removed, but the user wants to retain events associated with removed machine (what user removed the machine, when, etc). https://gitlab.isc.org/isc-projects/stork/-/issues/357
- [x] The user would like to see MORE on the events panel to see more event history. (https://gitlab.isc.org/isc-projects/stork/-/issues/357)
- The user had no difficulty finding and viewing the log tail. (no action)
- [x] On the Subnets list, the user thought it would be more helpful in the last column to show the hostname, instead of the IP address. [Not everyone will have defined hostnames and screen real estate is an issue. We discussed adding a hostname field, and having it hidden by default, with a configuration option to display it.] https://gitlab.isc.org/isc-projects/stork/-/issues/391
- [ ] The user observed that it would be helpful to have names for the subnets in some situations. If the subnets have names (perhaps use the comment field?) in the Kea configuration, it would be good to have an option here to display that comment/name rather than address/mask.
- [ ] When we have alerting, the user will require per-subnet alerting rules.
- [x] On the drill down for the machine, it would be helpful to display the IP address.
- [ ] On the summary list of machines, it the AppID@Address field is not really helpful The user would prefer to see the hostname, or at least, for whatever they DO see, they would like to see it reflected in the drill down they see when they click on the AppID@ link.
- [ ] On the drill down for an individual machine, the admin can rename the machine 'address.' This is reflected as 'Location' on the summary Machines panel. We should use the same term in both places.
- [ ] On the drill down for an individual machine, the admin can rename the machine 'address.' If what we are doing is permitting the admin to add an alias, we should be clearer about that (that this is a 'tag' or alias, not a new or different ip address necessarily). We also need to provide info about what sort of name is permitted (the user tried to add a name with spaces and that didn't work).
- [ ] On the drill down for an individual machine, the admin can rename the machine 'address', including the port. If the user changes both and there is a failure, there is no feedback about which change caused the failure. Perhaps these should be separate change dialogs, or we should not permit changing the port number, if this is intended to be an alias,
- In this instance, we changed the machine address to one that did not work, and the user did not notice/realize that the machine was no longer being monitored. Perhaps we should grey out the display of the cached information on a machine we can no longer reach so it is more obvious that this is old information. There is a message at the bottom of the machine detail panel saying that the machine was unreachable, but the user did not notice this.
- [ ] This user would like to be able to provide an alias for the APPID - some name that is more meaningful to the administrator
- The user commented that he liked the (?) info boxes.
- [ ] The user was surprised that the Grafana menu item under services went to an external application. This should probably open in a new window, rather than taking the user out of Stork.
- User wondered - "why are the DHCP services not under the DHCP menu? It is obviously DHCP...."
- [x] The user kept looking for machine information under Hosts. Consider renaming that 'Reservations' to avoid confusion with host machines.
- [ ] This user felt that the list of pools per subnet could be in a subnet drill down, rather than on the summary list of subnets. The user would also like to see a name for the subnet, if the subnet has a name in the Kea configuration (not sure if this is even supported)
- [ ] On the subnets list summary page, the far right column, the user requested that this be two links one to the machine and one to the app (clicking on either goes to the app).Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1555bump up libs and hooks versions for 1.9.2 release2020-11-23T11:06:45ZAndrei Pavelandrei@isc.orgbump up libs and hooks versions for 1.9.2 releasekea1.9.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1558EVP_MD_CTX_create issues2020-11-20T15:47:57ZFrancis DupontEVP_MD_CTX_create issuesAt least on Jenkins a virtual machine has a problem with EVP_MD_CTX_create:
```
[2020-11-18T19:14:11.131Z] [ RUN ] NSEC3HashTest.calculate
[2020-11-18T19:14:11.131Z] ld-elf.so.1: /usr/home/jenkins/workspace/kea-dev/ut-thread/src/lib...At least on Jenkins a virtual machine has a problem with EVP_MD_CTX_create:
```
[2020-11-18T19:14:11.131Z] [ RUN ] NSEC3HashTest.calculate
[2020-11-18T19:14:11.131Z] ld-elf.so.1: /usr/home/jenkins/workspace/kea-dev/ut-thread/src/lib/cryptolink/.libs/libkea-cryptolink.so.5: Undefined symbol "EVP_MD_CTX_create"
```
This shows a problem with the OpenSSL library which should have been detected in configure. As it can happen too in production I propose to address this. The first step should be to identify the virtual machine and its system.kea1.9.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1421Add authentication hook point2020-11-20T11:14:22ZTomek MrugalskiAdd authentication hook pointAs part of the #1304, @fdupont and I discussed the evolution of the basic http auth evolution. The code introduced in #1304 adds a basic credentials storage in the Kea config file. However, there are better alternatives envisaged in the ...As part of the #1304, @fdupont and I discussed the evolution of the basic http auth evolution. The code introduced in #1304 adds a basic credentials storage in the Kea config file. However, there are better alternatives envisaged in the future (keep them in a file, in a DB, perhaps in external system, like PAM, LDAP, RADIUS, etc.). Those could be implemented as hooks.
For this reason, we need a hook point that will:
- expose the credentials provided in a request to be authenticated
- let the hook decide whether the request should be authenticated or notkea1.9.2Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1536Diverse textual corrections to the ARM2020-11-20T11:09:22ZPeter DaviesDiverse textual corrections to the ARMThere are a couple of spelling mistakes in the KEA 1.8.0 arm:
8.4.1 Local and Relayed Traffic in Shared Networks
conifguration -> configuration
9.4.1 Local and Relayed Traffic in Shared Networks
conifguration -> config...There are a couple of spelling mistakes in the KEA 1.8.0 arm:
8.4.1 Local and Relayed Traffic in Shared Networks
conifguration -> configuration
9.4.1 Local and Relayed Traffic in Shared Networks
conifguration -> configuration
see[ RT 17284](https://support.isc.org/Ticket/Display.html?id=17284).
also:
3.4.3 Configure Before the Build
"neces sary" -> "necessary"
3.4.3 Configure Before the Build
"OpenSSL the cryptographic library" -> "OpenSSL cryptographic library".
3.4. Installation from Source 13
"pack ages -> packages"
"in specified directory" -> "in the specified directory"
"sys tems" -> "systems"
"Debian introduced separate directory" -> "Debian introduced a separate directory"
"specifies path" -> "specifies a path"
"requires subscription-only" -> "requires the subscription-only"
"That file contains list" -> "That file contains a list"
"requires subscription-only" -> "requires the subscription-only".kea1.9.2Peter DaviesPeter Davieshttps://gitlab.isc.org/isc-projects/kea/-/issues/1539Text corrections in the Kea ARM2020-11-20T10:36:01ZSuzanne GoldlustText corrections in the Kea ARMFixing various typos throughout the ARMFixing various typos throughout the ARMkea1.9.2Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2296Dns RRs size bigger than 64k , but bind is allowed only 64k , because of that...2020-11-20T10:20:02Zvenkappa eDns RRs size bigger than 64k , but bind is allowed only 64k , because of that lossing some RRs in the DNs responseMy DNS db file have 2048 answer RRs and 2048 Additional RRs, but DNS response includes only 475 Answers, that means not sending all the RRs and noticed ISC_R_NOSPACE ISSUE on bind side, I hope this is because of TCP_BUFFER_SIZE limit ...My DNS db file have 2048 answer RRs and 2048 Additional RRs, but DNS response includes only 475 Answers, that means not sending all the RRs and noticed ISC_R_NOSPACE ISSUE on bind side, I hope this is because of TCP_BUFFER_SIZE limit is 65535, so how to send all the RRs if more than 64k.https://gitlab.isc.org/isc-projects/kea/-/issues/1332extend perfdhcp to simulate ha failure2020-11-20T09:09:38ZWlodzimierz Wencelextend perfdhcp to simulate ha failureat this moment we can't simulate ha failure using perfdhcp. Extend perfdhcpat this moment we can't simulate ha failure using perfdhcp. Extend perfdhcpkea1.9.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1550dhcpv6 server assigns reservations from the pools even if out of pool flag is...2020-11-19T18:18:43ZRazvan Becheriudhcpv6 server assigns reservations from the pools even if out of pool flag is setthis was discovered while implementing #1405 and seeing the different behavior from v4 in previous written UT:
TEST_F(DORATest, reservationModeOutOfPool)
TEST_F(DORATest, reservationIgnoredInOutOfPoolMode)
in v4, before dynamic alloc...this was discovered while implementing #1405 and seeing the different behavior from v4 in previous written UT:
TEST_F(DORATest, reservationModeOutOfPool)
TEST_F(DORATest, reservationIgnoredInOutOfPoolMode)
in v4, before dynamic allocation (from pool), all reservations from the pools are removed.
in v6, because the retrieval of the reservations is done once for all IANAs, there is no filtering, and this must be done later, just before the dynamic allocation from the pools. at this stage, the lease type is also available, so proper filtering from the pool is optimal.kea1.9.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2294./server.c:3881: unexpected error: when issuing rndc reload or reconfig2020-11-19T14:51:45ZKarl Wieman./server.c:3881: unexpected error: when issuing rndc reload or reconfig<!--
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
When issuing an rndc reload or reconfig command to two of my BIND instances, I receive this error: "rndc: 'reload' failed: unexpected error" The syslog logs show this: "Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: ./server.c:3881: unexpected error:"
### BIND version used
cozbdns001# /opt/named/sbin/named -V
BIND 9.11.23 (Extended Support Version) <id:4f70056>
running on Linux x86_64 3.10.0-1160.2.1.el7.x86_64 #1 SMP Mon Sep 21 21:00:09 EDT 2020
built by make with '--prefix=/opt/bind-9.11.23'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /opt/bind-9.11.23/etc/named.conf
rndc configuration: /opt/bind-9.11.23/etc/rndc.conf
DNSSEC root key: /opt/bind-9.11.23/etc/bind.keys
nsupdate session key: /opt/bind-9.11.23/var/run/named/session.key
named PID file: /opt/bind-9.11.23/var/run/named/named.pid
named lock file: /opt/bind-9.11.23/var/run/named/named.lock
### Steps to reproduce
Any rndc reload or reconfig after a successful start up causes the issue. I copied the full BIND deployment and configuration to a lab server and the issue does not occur.
### What is the current *bug* behavior?
The server does not appear to actually reload its configuration. A full restart is required.
### What is the expected *correct* behavior?
rndc reconfig and reload should succeed. Also, "Unexpected error" is a useless message that does not help identify the cause of the issue.
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.603 general: info: received control channel command 'reload'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.603 general: info: loading configuration from '/etc/named.conf'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.610 general: info: reading built-in trust anchors from file '/opt/bind-9.11.23/etc/bind.keys'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 general: info: using default UDP/IPv4 port range: [1024, 65535]
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 general: info: using default UDP/IPv6 port range: [1024, 65535]
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 network: info: no IPv6 interfaces found
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.616 general: info: sizing zone task pool based on 462 zones
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.617 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.624 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.631 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.638 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.645 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.652 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.659 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.666 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.674 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.681 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.688 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.695 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.703 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.710 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.717 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.725 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.732 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.739 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.747 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.754 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.761 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.768 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.775 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.783 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.790 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.797 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.804 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.812 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.819 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.826 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.834 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.841 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.848 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.855 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.863 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.870 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.877 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.884 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.892 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.899 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.907 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.914 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.921 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.929 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.936 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.943 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.950 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.958 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.965 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.972 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.980 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.987 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.994 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.002 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.009 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.016 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.024 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.031 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: ./server.c:3881: unexpected error:
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: unable to obtain neither an IPv4 nor an IPv6 dispatch
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.042 general: error: reloading configuration failed: unexpected error
'
Note: Ommitted many "general: info: automatic empty zone: view <DOMAIN>: XXX" messages.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/22929.16.8 can't create PID file at Centos72020-11-19T09:03:05ZDen Ivanov9.16.8 can't create PID file at Centos7<!--
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
BIND could not open '/var/opt/isc/isc-bind/run/named/named.pid' and systemd service terminates after start
### BIND version used
```
BIND 9.16.8 (Stable Release) <id:539f9f0>
running on Linux x86_64 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:11 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.8/sphinx/bin/sphinx-build'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
```
### Steps to reproduce
systemctl start isc-bind-named.service
### What is the current *bug* behavior?
Service terminates
### What is the expected *correct* behavior?
Service must start and run
### Relevant configuration files
Doesn't matter for this case
### Relevant logs and/or screenshots
```
Nov 19 11:59:27 server named[893]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 19 11:59:27 server named[893]: Could not open '/var/opt/isc/isc-bind/run/named/named.pid'.
Nov 19 11:59:27 server named[893]: Please check file and directory permissions or reconfigure the filename.
Nov 19 11:59:27 server named[893]: could not open file '/var/opt/isc/isc-bind/run/named/named.pid': Permission denied
<...skip...>
Nov 19 12:00:57 server systemd[1]: isc-bind-named.service start operation timed out. Terminating.
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.102 network: no longer listening on 127.0.0.1#53
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.139 general: shutting down
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.139 general: stopping command channel on 127.0.0.1#953
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.156 general: exiting
Nov 19 12:00:57 server systemd[1]: Failed to start isc-bind-named.service.
Nov 19 12:00:57 server systemd[1]: Unit isc-bind-named.service entered failed state.
Nov 19 12:00:57 server systemd[1]: isc-bind-named.service failed.
```
### Possible fixes
```
semanage fcontext -a -t var_run_t "/var/opt/isc/isc-bind/run"
semanage fcontext -a -t named_var_run_t "/var/opt/isc/isc-bind/run(/.*)"
restorecon -vr /var/opt/isc/isc-bind/run
```Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/stork/-/issues/453stabilise selenium tests2020-11-18T13:33:01ZWlodzimierz Wencelstabilise selenium testsright now we have random result, figure out how to stabilise UI system testsright now we have random result, figure out how to stabilise UI system tests0.14Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1516Fix doxygen2020-11-18T12:49:14ZFrancis DupontFix doxygenA few doxygen trivial errors introduced recently should be fixed.A few doxygen trivial errors introduced recently should be fixed.kea1.9.2Francis DupontFrancis Dupont