Re: named out of swap on NetBSD/amd64

[Michal Nowak]

On 14/02/2023 16:09, Jan Schaumann via bind-users wrote:

I'm guessing that without a set 'max-cache-size', this
continues to grow until there is no more memory space
left, we start swapping, and eventually get OOM
killed.

https://bind9.readthedocs.io/en/v9_18_11/reference.html
claims that the default 'max-cache-size' is 90% of
physical memory, but it seems that didn't work out
here.  Might it be that on NetBSD, bind doesn't
correctly determine the physical memory amount?


In your named log you may see a "max-cache-size" calculation like the 
one below (I don't have "max-cache-size" set in the config explicitly, 
implicit value of "90%" is used):


'max-cache-size 90%' - setting to 1729MB (out of 1922MB)

It's from a 2 GB Linux cloud (KVM) instance and looking at the "free -m" 
command output, it makes sense.


Do you see a calculation for your system? Does it make sense?

Michal
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Move from Development to Production

[Michal Nowak]

On 26/08/2022 23:57, Benny Pedersen wrote:

David C. Templeton skrev den 2022-08-26 21:50:

Sorry for any confusion. I started with 9.18.4 because I also wanted
to test out upgrading. Install 9.18.4 first then make sure I could
upgrade to 9.18.6 without issue.

Am I following the correct link
(https://copr.fedorainfracloud.org/coprs/isc/bind-dev) ? The note at
the top of the page says, "Software published in this Copr should be
considered unstable." Is it recommended for a production environment?


so use the stable non dev version :)

https://copr.fedorainfracloud.org/coprs/isc/bind/


The catch is that only "isc-dev" (BIND 9.19) Copr repo has Enterprise 
Linux 9 packages. Enabling the "bind" (BIND 9.18) repo on Oracle Linux 9 
fails with:


Error: This repository does not have any builds yet so you cannot enable 
it now.


M.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND >= 9.18, jemalloc and EL7

[Michal Nowak]

On 25/08/2022 15:54, Ondřej Surý wrote:
I think there's only a risk that ISC doesn't regularly test with older 
jemalloc versions,

so you might get a hit by a bug we are not aware of.


Anand, we test regularly on Oracle Linux 7 with jemalloc 3.6.0 from 
Oracle's EPEL repository in the CI.


M.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: isc python module

[Michal Nowak]

On 16/08/2022 09:36, BÖSCH Christian wrote:

Hello,

I have FreeBSD and the bind-tools 9.16.X package installed and I am 
using the python module "isc" included in it with ansible.


Now when I tried to upgrade to bind-tools 9.18 package I see that the 
python module is no longer included.


I thought it might be the FreeBSD package, but I can't find the module 
in pypi etc. either.


So my question is whether the isc python module no longer exists, and 
whether there is an alternative?


Kind regards,

Christian




You can also find the module in 
https://gitlab.isc.org/isc-projects/dnssec-keymgr. I believe this 
project was "forked" from the main branch shortly before 9.16.0 and 
likely hasn't been touched since as it mostly serves archival purposes.


MN
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about linking jemalloc with Bind 9.18.x when doing the compile.

[Michal Nowak]

On 02/08/2022 18:46, Bhangui, Sandeep - BLS CTR via bind-users wrote:

Hello all

We are getting ready to test Bind 9.18.x. Currently we are running the 
latest version of 9.16.x branch.


We have downloaded and successfully installed the jemalloc module on the 
Server ( RHEL 7.9 OS) and getting ready to compile the latest version of 
Bind 9.18.x.


Can someone please point me to some documentation which tells as to what 
exact flags/parameters to use to properly link jemalloc when we compile 
latest version of Bind 9.18.x using “configure” so that we get the 
compile correctly done in the first run.


Thanks in advance.

Sandeep




Sandeep,

not much is needed as BIND 9's ./configure script handles it for you 
when jemalloc and jemalloc-devel packages are installed.


Just check that after ./configure is run, there are the following two lines:

Optional features enabled:
Memory allocator: jemalloc

Once BIND 9 is compiled, run "ldd /path/to/named" and look for the 
jemalloc line, it should look similar to this:


libjemalloc.so.2 => /lib64/libjemalloc.so.2 (0x7f895f20)

Michal
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Attempting to configure an ISC BIND repository on Red Hat Linux 7.9

[Michal Nowak]

On 28/04/2022 16:52, DeCaro, James John (Jim) CIV DISA FE (USA) via 
bind-users wrote:

Dnf is not available. Therefore using yum

Linux Red Hat 7.9 virtual machine on VMware, has internet connectivity

Set up local repository in 
/etc/yum.repos.d/download.copr.fedorainfracloud.org_results_isc_bind_epel-8-_.repo:


[copr:copr.fedorainfracloud.org:isc:bind]

name=Copr repo for bind owned by isc

baseurl=https://download.copr.fedorainfracloud.org/results/isc/bind/epel-8-$basearch/

type=rpm-md

skip_if_unavailable=False

enabled=1

enabled_metadata=1

gpgcheck=0

#gpgkey=https://download.copr.fedorainfracloud.org/results/isc/bind/pubkey.gpg

repo_gpgcheck=0

--changed gpgcheck and repo gpgcheck to ‘0’ and also commented out 
gpgkey=…..to try and get around the errors


# yum install isc-bind: rcd an error related to an ssl cert—therefore 
set sslverify=0 in /etc/yum.conf


now receiving error: 
“https://download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/repodata/repomd.xml: 
[Errno 14] HTTPS Error 503 - Service Unavailable” for each of the sites 
in isc: https:// 
download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/ (i.e. 
repeats 10 x)


curl -k 
https://download.copr.fedorainfracloud.org/results/isc/bind/epel-8-x86_64/ 
shows 
web page content so the connection is good


# sealert -a /var/log/audit/audit.log does not show any output

# firewall-cmd –list-all --list-ports does not show any blocks or 
filters


there are no entries in /var/log/yum.log (blank)

no references to the issue in /var/log/messages

internet search indicates a possible issue with the target site (which I 
doubt)


I am relatively new to repository configuration, so I am assuming I am 
missing something.


Thanks in advance for any input

V/R

Jim DeCaro




Can you start with the RHEL 7.9 system updated to the latest packages, 
remove the 
/etc/yum.repos.d/download.copr.fedorainfracloud.org_results_isc_bind_epel-8-_.repo 
file, put 
https://copr.fedorainfracloud.org/coprs/isc/bind/repo/epel-7/isc-bind-epel-7.repo 
to /etc/yum.repos.d/, and tell us what's the command's output when you 
try to install "isc-bind"?


It wasn't clear to me what was the error before you started disabling 
things in download.copr.fedorainfracloud.org_results_isc_bind_epel-8-_.repo.


Michal
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Building contrib modules for 9.18.2 fails

[Michal Nowak]

On 25/04/2022 12:20, Josef Moellers wrote:

Hi,

I'm trying to build bind 9.18.2 with the contrib modules, but this fails 
for contrib/dlz/modules/wildcard.


Without any modifications to the spec file used for 9.18.1, it fails 
because it does not have "FALLTHROUGH" and "UNREACHABLE()", whose use is 
new in 9.18.2, defined.


I tried to solve this by including  and adding 
"-I../../../../lib/isc/include" to the CFLAGS in the Makefile but
that then fails because the modules have a simpler definition of 
"isc_result_t"


My code to build the modules is:
# special build for the plugins
for d in contrib/dlz/modules/*; do
     [ -e $d/Makefile ] && make -C $d
done

Any tips/hints what I'm doing wrong?

Thanks in advance,

Josef


Looks like issue with commits 128c550a955635e4ff78f120eb6c94411a2f163d 
and c62a94363d7707f0354a2291de546d7f87ea58d9 we did not catch because we 
don't build contrib/ in the CI. The stuff in the directory in not 
supported, but will be fixed as time permits, if you file an issue to 
GitLab.


As a stopgap measure you can revert those two commits above just for the 
contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.c file. Then it builds 
for me.


Michal
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Michal Nowak]

On 02/09/2021 13:29, Mark Tinka wrote:

Hi all.

Ever since we moved from BIND-9.11 to BIND-9.16, we've been experiencing 
'named' crashing after 24hrs - 36hrs on high-load resolver-only servers, 
running on FreeBSD-13.0.


We found that the reason for this was due to BIND running out of swap space.

An increase in swap space by creating a 4GB swap file did not help.

So we are now playing with the 'max-cache-size' value in BIND. The 
system has 15GB of physical RAM. Limiting BIND to 13GB of memory does 
not work; 'named' still crashes due to a lack of swap space.


We have then switched to % values, and it's still crashing for the same 
reason at 90% and now 80%.


We are now testing 70%.

Anyone have some idea of how we can get this under control?

Is there a possibility that BIND is not properly understanding how much 
physical RAM is available to FreeBSD, and just burns through it anyway, 
tripping swap space in the process? I can't think of any reason why BIND 
would keep burning RAM if it has been told to limit its demand to a 
certain value or %.


All help appreciated. Thanks.

Mark.


Mark, what's the exact BIND 9.16 version which is crashing for you? Why 
do you say that the reason for crashing is BIND running out of swap? How 
did you found out?


Note that BIND 9.16.19 was tripping over a misplaced assert, see 
https://downloads.isc.org/isc/bind9/9.16.20/doc/arm/html/notes.html#notes-for-bind-9-16-20.


Michal
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [Non-DoD Source] Re: Upgrading from BIND 9.14.9 to 9.16.3

[Michal Nowak]

On 27/05/2020 20:22, DeCaro, James John (Jim) CIV DISA FE (USA) via 
bind-users wrote:

ld.so.1: gen: fatal: libuv.so.1: open failed: No such file or directory


...



$ find / -name libuv* -print
/usr/local/lib/libuv.so
/usr/local/lib/libuv.la
/usr/local/lib/libuv.so.1
/usr/local/lib/libuv.a
/usr/local/lib/libuv.so.1.0.0


Jim, I believe you installed 64-bit libuv to a 32-bit directory (i.e. 
/usr/local/lib/) and that's why linker can't find it. You should have 
installed libuv to the 64-bit directory (i.e. /usr/local/lib/amd64/), 
e.g. via


./configure ... --libdir=/usr/local/lib/amd64

PKG_CONFIG_PATH should have been set to 64-bit path too, i.e. 
/usr/local/lib/amd64/pkgconfig.


Michal
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users