Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 832218 - net-dns/bind-9.18.x and net-dns/bin-tools-9.18.x bump request
Summary: net-dns/bind-9.18.x and net-dns/bin-tools-9.18.x bump request
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Patrick McLean
URL: https://github.com/gentoo/gentoo/pull...
Whiteboard:
Keywords: PullRequest
: 886325 908545 908716 (view as bug list)
Depends on:
Blocks: 923781
  Show dependency tree
 
Reported: 2022-01-28 15:05 UTC by Eray Aslan
Modified: 2024-02-14 13:18 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Draft patch for bind-9.18 to only build the tools (bind-tools-9.18-tools-only.patch,2.69 KB, patch)
2023-06-29 23:41 UTC, Joshua Kinard
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eray Aslan gentoo-dev 2022-01-28 15:05:31 UTC
https://lists.isc.org/pipermail/bind-announce/2022-January/001205.html

Today ISC is pleased to announce the release of BIND 9.18.0

This is the first stable release that contains support for DoT and DoH.

This new release of BIND is available for download from the Internet
Systems Consortium web site (https://www.isc.org/downloads)

Significant work covered in the 9.18.0 branch includes:

     - Support for securing DNS traffic using Transport Layer Security 
(TLS).
           TLS is used by both DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH).
     - Support for zone transfers over TLS (XFR-over-TLS, XoT) for both
           incoming and outgoing zone transfers.
     - The dig tool is now able to send DoT queries (+tls option).
     - Support for OpenSSL 3.0 APIs was added.


You can read more about this new edition of BIND in the release notes:

9.18.0: 
https://downloads.isc.org/isc/bind9/9.18.0/RELEASE-NOTES-bind-9.18.0.html

-- 
Peter Davies
Internet Systems Corporation
Comment 1 Eray Aslan gentoo-dev 2022-01-28 15:08:08 UTC
please see $URL for what I use locally

as this is a major release, made a lot of changes. review would be nice. my notes:

- punted CHROOT stuff to simplify the ebuild and scripts. I find containers easier to manage nowadays instead of chroot'ing but ymmv.
- bind-tools binaries (dig, delv etc) are not stand alone binaries anymore but link to bind libraries, i.e. net-dns/bind and net-dns/bind-tools by neccesity produce the same libraries resulting in file collisions. I soft blocked each other thinking it would result in the lowest maintanence burden but there are other options so your call
- net-dns/bind now produces everything, including binaries produced by net-dns/bind-tools
- old style dlz drivers have been removed upstream. prefer dumping from datastore (database, ldap etc) to a file on a regular basis/on demand instead anyway.
- licensing: I believe bind is mozilla-2.0. not sure why we had others. need to check
- dev-libs/jemalloc is the preferred allocator for bind-9.18. made it obligatory and dropped sparc keyword
- json and zlib USE flags dropped and made obligatory. zlib is more or less necessary because of doh stuff. json requirement is a small library. xml is still behind a USE flag as it has the potential to bring in big libraries (icu etc)
- python is optional and only used for testing
- upstream dropped berkdb support
- unified geoip and geoip2 USE flags
- build system now uses a more traditional autotools stack. punted old stuff from ebuild
- do not install a zone file for loopback addresses. they are already built in now I believe
- no need for named.cache as well
- install named.conf.auth as a sample for authoratative named server. recursive server do not need one to function
- openrc init script and confd revized, mostly because of punting chroot
Comment 2 Eray Aslan gentoo-dev 2022-04-26 13:39:25 UTC
latest versions are at:
https://github.com/erayaslan/eras-overlay

just fyi
Comment 3 Klemen Mihevc 2022-04-26 15:22:17 UTC
(In reply to Eray Aslan from comment #2)
> latest versions are at:
> https://github.com/erayaslan/eras-overlay
> 
> just fyi

Thanks, gonna try them in near future... DoT and DoH seems useful.
Comment 4 Klemen Mihevc 2022-05-19 13:06:52 UTC
I checked version from eras-overlay (its pretty much the same as pull request anyway) and it seems to work "fine". Obviously now with bind seperate bind-tools are not needed anymore. Also noticed it doesnt install localhost.zone and named.cache intentional or oversight?
Comment 5 Eray Aslan gentoo-dev 2022-05-19 15:42:24 UTC
1/
no need for named.cache file anymore. bind has built-in root server hints at lib/dns/rootns.c to figure out the root servers at first startup

2/
localhost choice is somewhat more controversial. I feel that:

- there should not be any localhost entry in any DNS zone and modern software should suppress localhost queries so they never reach the DNS servers
- end-user systems should handle queries for localhost using their hosts file, without making DNS queries, and without using their domain search list to construct additional queries
- built in empty zone should handle the reverse lookups (which is the default for bind): https://bind9.readthedocs.io/en/v9_18_2/reference.html?highlight=automatic%20empty%20zone#built-in-empty-zones
- bind is better suited for authoritative server use - use unbound for example for recursive caching name server. hence, the sample named.conf file I provide is for an auth server and not for a recursive server
- localhost in zone file has some security implications as well: https://seclists.org/bugtraq/2008/Jan/270
- also see https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

having said that, I can provide a localhost and 127.in-addr.arpa zone file with a default recursive named.conf if people keep asking for it. but I will hold out on that for now
Comment 6 Klemen Mihevc 2022-05-19 15:53:55 UTC
Im using bind as combination of authorative name server for my "home" domain + recursive for lan, so ye i have all those zones in like localhost and 127. For me its no problem to get zones from gentoo bind build, honestly not sure when i would notice, since it didnt eveb hard error about missing zone file, but i just noticed errors in log file, when trying to debug unrelated DoH issue...

Also not sure how good it is to not keep bind & bind-tools as seperate packages as it was until now, simply because some apps depend on bind-tools specifically (i have arno-iptables + testssl) and ebuilds will need to be fixed. I understand why it was done (saving space with librarys), just not sure if its worth the hassle...
Comment 7 Eray Aslan gentoo-dev 2022-05-19 16:46:42 UTC
bind and bind-tools produce the same library files leading to file collisions - that was the reason and not to save some space.

there are other ways to solve this - can make bind depend on bind-tools for example - but this is the least hassle free one I think and in any case that decision is up to the maintainer
Comment 8 Stephen Bosch 2022-10-29 23:27:57 UTC
Has there been any progress on this? It is getting increasingly important to have DoH and DoT support.

What still needs to be done to get this into main tree?

Should we think about splitting it up into net-dns/bind and net-dns/bind-tools to avoid having fix all the bind-tools dependencies?
Comment 9 Stephen Bosch 2022-10-29 23:34:29 UTC
It looks like Eray has already done the split:

https://gpo.zugaina.org/Overlays/eras-overlay
Comment 10 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-12-16 23:29:02 UTC
*** Bug 886325 has been marked as a duplicate of this bug. ***
Comment 11 Alexey Chernyak 2022-12-20 02:09:59 UTC
Eray, appreciate the recommendation to use containers, but removing CHROOT in newer ebuilds will break existing systems, and can catch people off guard during @world upgrade.

It seems there are 3 ebuilds in the portage tree that depend on bind-tools, this will cause blockage if we don't keep bind-tool separation, unless we remove dependencies from those ebuilds.

Overall I think the number of people that need bind-tools, but don't need bind is quite significant.

phoenix591 overlay seems to be maintaining updated ebuilds with preserved CHROOT functionality, but it has no bind-tools split.

http://gpo.zugaina.org/net-dns/bind

Despite a very strong desire to test this, I'm not game until we have an ebuild with CHROOT and bind-tools split issues addressed.
Comment 12 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-12-20 08:27:03 UTC
(In reply to Alexey Chernyak from comment #11)
> Eray, appreciate the recommendation to use containers, but removing CHROOT
> in newer ebuilds will break existing systems, and can catch people off guard
> during @world upgrade.
> 

Well, that's part of why it didn't get merged yet.

> It seems there are 3 ebuilds in the portage tree that depend on bind-tools,
> this will cause blockage if we don't keep bind-tool separation, unless we
> remove dependencies from those ebuilds.
> 

Obviously those would be updated.

> Overall I think the number of people that need bind-tools, but don't need
> bind is quite significant.
> 

eras is right though. I too tried to keep the bind-tools split going but it's pointless:
1. The build system will build all of BIND anyway, so it makes no difference wrt speed;
2. The split part is *extremely* fragile and relies on deleting the right files and keeping a list in sync across both the bind and bind-tools ebuilds. This is a recipe for disaster. It's not just ugly and unclean, it also makes it quite likely that a file might be missed on one side and a problem arises (possibly meaning the server can't start or functions improperly). 

I tried to make it work and gave up.

> phoenix591 overlay seems to be maintaining updated ebuilds with preserved
> CHROOT functionality, but it has no bind-tools split.
> 
> http://gpo.zugaina.org/net-dns/bind
> 
> Despite a very strong desire to test this, I'm not game until we have an
> ebuild with CHROOT and bind-tools split issues addressed.

See above. In any case, I recently rebased my PR based on eras' work at https://github.com/gentoo/gentoo/pull/25220 and a user is helping test it. I need to work on his comments next.
Comment 13 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-12-20 08:27:49 UTC
(In reply to Sam James from comment #12)
> eras is right though. I too tried to keep the bind-tools split going but
> it's pointless:
> 1. The build system will build all of BIND anyway, so it makes no difference
> wrt speed;
> 2. The split part is *extremely* fragile and relies on deleting the right
> files and keeping a list in sync across both the bind and bind-tools
> ebuilds. This is a recipe for disaster. It's not just ugly and unclean, it
> also makes it quite likely that a file might be missed on one side and a
> problem arises (possibly meaning the server can't start or functions
> improperly). 
> 

oh, and:
3. They both need libbind and so on, so you'd end up with either bind-tools depending on bind (which obviously nobody would like), or installing the libraries twice to a separate directory. Again, very brittle, and a waste of disk.
Comment 14 cyrillic 2022-12-31 00:16:53 UTC
One approach would be to make bind-tools a stub that depends on bind[tools].

This way, you do not need to fix any dependencies, and people who do not use bind would get it for free, and people who do use bind would not get any nasy surprises.
Comment 15 cyrillic 2022-12-31 00:18:22 UTC
s/nasy/nasty
Comment 16 Alexey Chernyak 2023-01-05 15:51:53 UTC
Or (In reply to Sam James from comment #13)
> oh, and:
> 3. They both need libbind and so on, so you'd end up with either bind-tools
> depending on bind (which obviously nobody would like), or installing the
> libraries twice to a separate directory. Again, very brittle, and a waste of
> disk.

Could do what Debian did and make libbind a separate package that both bind and bind-tools depend on?
Comment 17 Paul Osmialowski 2023-01-19 11:41:29 UTC
A side note here about some problem that could possibly be solved during the bump. Very recently bind has stopped being marked as stable on PPC. I'm still using Gentoo on PPC (although now I have only one such machine left), and it runs named on it. Are there any chances the new bumped version could be stabilized for 32-bit PPC too?
Comment 18 Alexey Chernyak 2023-01-31 14:19:56 UTC
(In reply to cyrillic from comment #14)
> One approach would be to make bind-tools a stub that depends on bind[tools].
> 
> This way, you do not need to fix any dependencies, and people who do not use
> bind would get it for free, and people who do use bind would not get any
> nasy surprises.
I think there are a lot more people that need the tools, but don't need the server, and some of them may not want it for free:
* Some may care about reducing footprint and squeezing out every last byte by not installing things they don't need.
* Some may care about reducing attack surface which they need to keep patched and not exploitable.

Perhaps we could improve your suggested approach a bit:
* Add "server" and "tools" USE flags to bind ebuild, both enabled by default.
* Allow users to disable either USE flag explicitly if they don't want either of them for free.
* Make bind-tools a stub that depends on bind[tools].
* Make existing bind-tools USE flags into corresponding bind USE flags dependencies.
* Make setting bind[-tools] force uninstallation of bind-tools.
* Make setting bind[-server] force uninstallation of acct-group/named and acct-user/named. (Assume there's no issues if someone wants server removed explicitly. Not sure what Gentoo's practice around this is.)
Comment 19 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-15 15:21:57 UTC
*** Bug 908545 has been marked as a duplicate of this bug. ***
Comment 20 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-17 20:53:24 UTC
*** Bug 908716 has been marked as a duplicate of this bug. ***
Comment 21 cyrillic 2023-06-19 00:54:23 UTC
(In reply to cyrillic from comment #14)
> One approach would be to make bind-tools a stub that depends on bind[tools].

FreeBSD appears to do the reverse of this :
Make bind a stub that depends on bind-tools[server]
Comment 22 Joshua Kinard gentoo-dev 2023-06-26 00:28:32 UTC
(In reply to cyrillic from comment #21)
> (In reply to cyrillic from comment #14)
> > One approach would be to make bind-tools a stub that depends on bind[tools].
> 
> FreeBSD appears to do the reverse of this :
> Make bind a stub that depends on bind-tools[server]

Other way around, actually.  In Ports, dns/bind-tools' Makefile has an include statement to pull in dns/bind918's Makefile, which has conditional clauses that check if the build is being invoked as the tools or the full server build, and adjusts the logic accordingly.
Comment 23 Joshua Kinard gentoo-dev 2023-06-26 00:48:17 UTC
(In reply to Joshua Kinard from comment #22)
> (In reply to cyrillic from comment #21)
> > (In reply to cyrillic from comment #14)
> > > One approach would be to make bind-tools a stub that depends on bind[tools].
> > 
> > FreeBSD appears to do the reverse of this :
> > Make bind a stub that depends on bind-tools[server]
> 
> Other way around, actually.  In Ports, dns/bind-tools' Makefile has an
> include statement to pull in dns/bind918's Makefile, which has conditional
> clauses that check if the build is being invoked as the tools or the full
> server build, and adjusts the logic accordingly.
Aaaaand I read that wrong initially.  Missed the "reverse" word.  You're right in that regard; FreeBSD has bind-tools acting as a stub of bind918, but disables building the server bits.
Comment 24 cyrillic 2023-06-27 00:49:14 UTC
Sorry, that was confusing the way I wrote it.

In any event, whether we take the Debian approach, the FreeBSD approach, or whatever, it would be nice to get bind-9.18.x in the tree before it goes EOL :)
Comment 25 Krzysztof Olędzki 2023-06-27 08:57:34 UTC
Regarding EOL, I would be more worried about the 9.16 branch (the only one available in portage), as https://kb.isc.org/docs/bind-9-end-of-life-dates suggests that we may only have about 9 months left before its EOL.
Comment 26 Joshua Kinard gentoo-dev 2023-06-27 22:28:34 UTC
(In reply to cyrillic from comment #24)
> Sorry, that was confusing the way I wrote it.
> 
> In any event, whether we take the Debian approach, the FreeBSD approach, or
> whatever, it would be nice to get bind-9.18.x in the tree before it goes EOL
> :)

FWIW, I stumbled on this issue when I wrote my own bind-tools-9.18 ebuild in #908716, not knowing there was already a discussion on-going (Bugzilla search really knows how to fail at the right moments, no?).  Talking to Sam early last week, I am going to look at taking his stab at bind-9.18.0 and try to harmonize the two, and make net-dns/bind install the server AND tools, while net-dns/bind-tools installs ONLY the tools.  Since both install shared libs, going to try using a 'virtual/bind-tools' to select between the two (you can have one or the other, but not both), and see how Portage likes it.  Packages that currently depend on net-dns/bind-tools would instead depend on "virtual/bind-tools" and I *think* that could actually work.  May need a bit of kludgery to deal with 9.16 still kicking around for a while, but eh.

My read of things indicates that it's the addition of the shared libs in bind-9.18 that throws the curveball here.  FreeBSD dodged this with a rather ugly kludge, in that dns/bind-tools in Ports installs a separate copy of the shared libs under /usr/local/lib/bind-tools, and dns/bind918 installs its own copy in the usual place.  It works, but I cringe now that I know why it works.

Probably a weekend project for this coming weekend, but we'll see...
Comment 27 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-28 05:42:34 UTC
(In reply to Joshua Kinard from comment #26)
> (In reply to cyrillic from comment #24)
> > Sorry, that was confusing the way I wrote it.
> > 
> > In any event, whether we take the Debian approach, the FreeBSD approach, or
> > whatever, it would be nice to get bind-9.18.x in the tree before it goes EOL
> > :)
> 
> FWIW, I stumbled on this issue when I wrote my own bind-tools-9.18 ebuild in
> #908716, not knowing there was already a discussion on-going (Bugzilla
> search really knows how to fail at the right moments, no?).  Talking to Sam
> early last week, I am going to look at taking his stab at bind-9.18.0 and
> try to harmonize the two, and make net-dns/bind install the server AND
> tools, while net-dns/bind-tools installs ONLY the tools.  Since both install
> shared libs, going to try using a 'virtual/bind-tools' to select between the
> two (you can have one or the other, but not both), and see how Portage likes
> it.  Packages that currently depend on net-dns/bind-tools would instead
> depend on "virtual/bind-tools" and I *think* that could actually work.  May
> need a bit of kludgery to deal with 9.16 still kicking around for a while,
> but eh.
> 

I really don't think this is a good idea unless:
1. you can patch it to conditionally build the tools vs server;
2. get the patch accepted upstream (or it's at least not huge);
3. it saves some significant amount of build time

The PR at https://github.com/gentoo/gentoo/pull/25220 is nearly ready, it really just needs a bit more polish and testing for the permissions issues raised in some comments there.
Comment 28 Joshua Kinard gentoo-dev 2023-06-28 22:00:29 UTC
(In reply to Sam James from comment #27)
> (In reply to Joshua Kinard from comment #26)
> > (In reply to cyrillic from comment #24)
> > > Sorry, that was confusing the way I wrote it.
> > > 
> > > In any event, whether we take the Debian approach, the FreeBSD approach, or
> > > whatever, it would be nice to get bind-9.18.x in the tree before it goes EOL
> > > :)
> > 
> > FWIW, I stumbled on this issue when I wrote my own bind-tools-9.18 ebuild in
> > #908716, not knowing there was already a discussion on-going (Bugzilla
> > search really knows how to fail at the right moments, no?).  Talking to Sam
> > early last week, I am going to look at taking his stab at bind-9.18.0 and
> > try to harmonize the two, and make net-dns/bind install the server AND
> > tools, while net-dns/bind-tools installs ONLY the tools.  Since both install
> > shared libs, going to try using a 'virtual/bind-tools' to select between the
> > two (you can have one or the other, but not both), and see how Portage likes
> > it.  Packages that currently depend on net-dns/bind-tools would instead
> > depend on "virtual/bind-tools" and I *think* that could actually work.  May
> > need a bit of kludgery to deal with 9.16 still kicking around for a while,
> > but eh.
> > 
> 
> I really don't think this is a good idea unless:
> 1. you can patch it to conditionally build the tools vs server;
> 2. get the patch accepted upstream (or it's at least not huge);
> 3. it saves some significant amount of build time
> 
> The PR at https://github.com/gentoo/gentoo/pull/25220 is nearly ready, it
> really just needs a bit more polish and testing for the permissions issues
> raised in some comments there.

Having played with 9.18's build system, I like the revamp that upstream did, and I *think* it will be possible to change it to have a configure switch control the generation of server+tools or tools-only.  Probably something to be done at the Makefile.am and configure.ac level, then let autoreconf do its thing.  Looking at it now, but I think I found a more nefarious bug that I need to figure out first (see my next comment after this one in a bit).

I am assuming that upstream would not be receptive to changes to the 9.18-series for this, even if they end up liking the general idea of it, as it constitutes a notable new feature versus a bugfix to a stable branch.  If we work up a patch to do this, we may end up carrying it ourselves throughout 9.18's lifetime, and possibly 9.20's as well, depending on where upstream is at in the 9.19 development cycle (I honestly have not yet looked for any kind of release calendar/timeline, so I have no idea when 9.20 is due out).  Are we sure we want to do that for a length of time that could be several years long?

That said, any attempt to mod the build system should be based on the 9.19 development series and submitted for acceptance in the eventual 9.20 release series.  Depending on how complicated that is, said patch may be simple to backport to 9.18 and maintain, but we should keep the door open to just continuing the existing approach of dual packages for at least 9.18's lifecycle, then merge everything when 9.20 is finally released.
Comment 29 Joshua Kinard gentoo-dev 2023-06-28 22:15:50 UTC
(In reply to Joshua Kinard from comment #28)
> 
> (see my next comment after this one in a bit).

So it looks like the bug here is that the build system is only installing fully-versioned libs.  E.g., /usr/lib64/libns-9.18.15.so.  bind-9.18.16 was just released, so when I went to copy my 9.18.15 ebuild and upgrade it, it ended up linking some of the 9.18.16.so libs against 9.18.15.so libs, and Portage couldn't remove the older ones.

I expected the build system to generate libxx-9.18.so and libxx-9.so symlinks as well that point to the fully-versioned name, but it looks like it isn't.  I think this is a bug?  Anyone recall other packages that had this issue and what the fix was?

Also, looking at 9.19.14's configure script, it's adding support for userspace-rcu, and there are several options that can be passed to a new configure switch, --with-librcu: membarrier, qsbr, mb, signal, & bp.  Can't recall a way to allow the user to select a specific options via USE flags without creating at least five new local flags.  What's been the approach in the past to handle this?
Comment 30 Joshua Kinard gentoo-dev 2023-06-29 01:18:07 UTC
(In reply to Joshua Kinard from comment #29)
> (In reply to Joshua Kinard from comment #28)
> > 
> > (see my next comment after this one in a bit).
> 
> So it looks like the bug here is that the build system is only installing
> fully-versioned libs.  E.g., /usr/lib64/libns-9.18.15.so.  bind-9.18.16 was
> just released, so when I went to copy my 9.18.15 ebuild and upgrade it, it
> ended up linking some of the 9.18.16.so libs against 9.18.15.so libs, and
> Portage couldn't remove the older ones.
> 
> I expected the build system to generate libxx-9.18.so and libxx-9.so
> symlinks as well that point to the fully-versioned name, but it looks like
> it isn't.  I think this is a bug?  Anyone recall other packages that had
> this issue and what the fix was?

n/m, my fault.  Try to short-circuit the build system, and you get surprises like this.
Comment 31 Joshua Kinard gentoo-dev 2023-06-29 23:41:21 UTC
Created attachment 864844 [details, diff]
Draft patch for bind-9.18 to only build the tools

Attaching a rough draft of a patch that mods the build system of bind-9.18 to add a new configure switch, --enable-tools-only, that only builds the following bind tools:
    delv, dig, dnssec-dsfromkey, dnssec-importkey,
    dnssec-keyfromlabel, dnssec-revoke, dnssec-keygen,
    dnssec-settime dnssec-signzone, dnssec-verify
    host, nslookup, & nsupdate

I am still looking at a way to also implement the additional tools requested in Bug #548124, but need to read autotools docs some more.  Still, if someone could test this against one of the net-dns/bind-9.18* examples and let me know the results, that'd be great.  I've only tested it as the actual bind-tools ebuild, not the full server ebuild.  I'd suggest using the latest version just released, which is 9.18.16.

Needs eautoreconf after applying the patch in src_prepare, and add --enable-tools-only to myeconfargs!
Comment 32 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-30 02:49:26 UTC
(In reply to Joshua Kinard from comment #31)
> Created attachment 864844 [details, diff] [details, diff]
> Draft patch for bind-9.18 to only build the tools
> 
> Attaching a rough draft of a patch that mods the build system of bind-9.18
> to add a new configure switch, --enable-tools-only, that only builds the
> following bind tools:
>     delv, dig, dnssec-dsfromkey, dnssec-importkey,
>     dnssec-keyfromlabel, dnssec-revoke, dnssec-keygen,
>     dnssec-settime dnssec-signzone, dnssec-verify
>     host, nslookup, & nsupdate
> 

We tend to not like "negative" use flags nowadays. I still think it'd be better to make the server part optional instead in net-dns/bind, or just not bother at all.

(In reply to Joshua Kinard from comment #28)
> I am assuming that upstream would not be receptive to changes to the
> 9.18-series for this, even if they end up liking the general idea of it, as
> it constitutes a notable new feature versus a bugfix to a stable branch.  If
> we work up a patch to do this, we may end up carrying it ourselves
> throughout 9.18's lifetime, and possibly 9.20's as well, depending on where
> upstream is at in the 9.19 development cycle (I honestly have not yet looked
> for any kind of release calendar/timeline, so I have no idea when 9.20 is
> due out).  Are we sure we want to do that for a length of time that could be
> several years long?

That's what I was saying - any decision to bother with a split or conditionally building stuff in bind itself (or bind-tools if we must) should be done on balance, not just because it's how we do it now.
Comment 33 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-30 02:50:42 UTC
(In reply to Joshua Kinard from comment #29)
> I expected the build system to generate libxx-9.18.so and libxx-9.so
> symlinks as well that point to the fully-versioned name, but it looks like
> it isn't.  I think this is a bug?  Anyone recall other packages that had
> this issue and what the fix was?

This is precisely why it feels like we shouldn't be doing this at all.

> 
> Also, looking at 9.19.14's configure script, it's adding support for
> userspace-rcu, and there are several options that can be passed to a new
> configure switch, --with-librcu: membarrier, qsbr, mb, signal, & bp.  Can't
> recall a way to allow the user to select a specific options via USE flags
> without creating at least five new local flags.  What's been the approach in
> the past to handle this?

You just roll with the defaults from upstream (and ideally explicitly state them in the ebuild), make your own decisions on them, roll them into a single flag (in several chunks perhaps), or you expose them as USE flags.
Comment 34 Joshua Kinard gentoo-dev 2023-06-30 04:02:28 UTC
(In reply to Sam James from comment #32)
> (In reply to Joshua Kinard from comment #31)
> > Created attachment 864844 [details, diff] [details, diff] [details, diff]
> > Draft patch for bind-9.18 to only build the tools
> > 
> > Attaching a rough draft of a patch that mods the build system of bind-9.18
> > to add a new configure switch, --enable-tools-only, that only builds the
> > following bind tools:
> >     delv, dig, dnssec-dsfromkey, dnssec-importkey,
> >     dnssec-keyfromlabel, dnssec-revoke, dnssec-keygen,
> >     dnssec-settime dnssec-signzone, dnssec-verify
> >     host, nslookup, & nsupdate
> > 
> 
> We tend to not like "negative" use flags nowadays. I still think it'd be
> better to make the server part optional instead in net-dns/bind, or just not
> bother at all.

I don't think making the server optional by default works.  When someone sees "bind", they are more likely to first think of the server, not the tools that come along with it.  If you want to go that route, then maintaining two separate ebuilds is better, because then you are implicit about what the purpose of each is.  One for the server+tools, and the other is tools-only (but then you need the virtual package, too, because those shared libs become a problem).

OTOH, if you do a single ebuild that can do either-or, you avoid the need to have a virtual.  But the default *should* follow upstream's original intent, and that is to build everything and install it.

There's a third option to make the server its own ebuild (net-dns/bind-server), and keep net-dns/bind-tools around for just the tooling, but again, the shared libs become a problem because named links against several of the same ones as the tools.  Only way around that is to break those libs out into their own package (net-libs/libbind?) that is a dependency used by both the server and tools packages, but now you're maintaining three ebuild sets.  Would also require significant modding to the build system, so I don't think this approach is feasible at all.

At least patching the build system gives me something to submit to ISC's gitlab and see what their reaction is.


> (In reply to Joshua Kinard from comment #28)
> > I am assuming that upstream would not be receptive to changes to the
> > 9.18-series for this, even if they end up liking the general idea of it, as
> > it constitutes a notable new feature versus a bugfix to a stable branch.  If
> > we work up a patch to do this, we may end up carrying it ourselves
> > throughout 9.18's lifetime, and possibly 9.20's as well, depending on where
> > upstream is at in the 9.19 development cycle (I honestly have not yet looked
> > for any kind of release calendar/timeline, so I have no idea when 9.20 is
> > due out).  Are we sure we want to do that for a length of time that could be
> > several years long?
> 
> That's what I was saying - any decision to bother with a split or
> conditionally building stuff in bind itself (or bind-tools if we must)
> should be done on balance, not just because it's how we do it now.

Now that I actually understand (somewhat) how to make this work, maintaining it won't be too much of a hassle.  The patch is pretty straight-forward.  So even if upstream likes the idea for future 9.20, it can be maintained for 9.18, too, if we want.


(In reply to Sam James from comment #33)
> (In reply to Joshua Kinard from comment #29)
> > I expected the build system to generate libxx-9.18.so and libxx-9.so
> > symlinks as well that point to the fully-versioned name, but it looks like
> > it isn't.  I think this is a bug?  Anyone recall other packages that had
> > this issue and what the fix was?
> 
> This is precisely why it feels like we shouldn't be doing this at all.

Well, it was my fault for trying to be clever.  The src_install I was using was trying to jump into the bin/ and lib/ subdirs and only compile stuff in those folders.  That worked, but it must be one of the higher Makefiles that does the soname symlinks during install, and you can't really work around it.  So I got rid of that and the standard 'make install' does what is expected.  You just have to rm -Rf some unneeded files that go into /usr/include, because of the shared libs (these headers aren't needed because these libs are intended for internal use only by the server and/or tools).  This is also what FreeBSD's dns/bind-tools port will do in its equivalent install phase.


> > Also, looking at 9.19.14's configure script, it's adding support for
> > userspace-rcu, and there are several options that can be passed to a new
> > configure switch, --with-librcu: membarrier, qsbr, mb, signal, & bp.  Can't
> > recall a way to allow the user to select a specific options via USE flags
> > without creating at least five new local flags.  What's been the approach in
> > the past to handle this?
> 
> You just roll with the defaults from upstream (and ideally explicitly state
> them in the ebuild), make your own decisions on them, roll them into a
> single flag (in several chunks perhaps), or you expose them as USE flags.

Default is to use membarrier, but they have those other four options.  Can do specific local USE flags for each, but USE flags were kinda always designed to be logical OR operators, and for this one configure switch, you really need a logical XOR operation instead.  I'll poke around the tree and see what other packages do and find something to emulate.  Just wanting to avoid a messy logical contraption to check for allowed USE combinations.
Comment 35 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-30 04:10:40 UTC
(In reply to Joshua Kinard from comment #34)
> I don't think making the server optional by default works.  When someone
> sees "bind", they are more likely to first think of the server, not the
> tools that come along with it.  If you want to go that route, then
> maintaining two separate ebuilds is better, because then you are implicit
> about what the purpose of each is.  One for the server+tools, and the other
> is tools-only (but then you need the virtual package, too, because those
> shared libs become a problem).

Add a USE=server, default it on, do a news item (can also then have USE=tools, and require at-least-one-of them be enabled).

> 
> OTOH, if you do a single ebuild that can do either-or, you avoid the need to
> have a virtual.  But the default *should* follow upstream's original intent,
> and that is to build everything and install it.

Right, all of this is swimming upstream (ha).

> At least patching the build system gives me something to submit to ISC's
> gitlab and see what their reaction is.

Sure. If they accept it, I'm willing to reconsider.
Comment 36 Joshua Kinard gentoo-dev 2023-06-30 04:59:42 UTC
(In reply to Sam James from comment #35)
> (In reply to Joshua Kinard from comment #34)
> > I don't think making the server optional by default works.  When someone
> > sees "bind", they are more likely to first think of the server, not the
> > tools that come along with it.  If you want to go that route, then
> > maintaining two separate ebuilds is better, because then you are implicit
> > about what the purpose of each is.  One for the server+tools, and the other
> > is tools-only (but then you need the virtual package, too, because those
> > shared libs become a problem).
> 
> Add a USE=server, default it on, do a news item (can also then have
> USE=tools, and require at-least-one-of them be enabled).

Eh, the issue with that is USE 'server' needs to build more than just named.  There's a couple of tools you need alongside it (like those for creating the DNSSEC records) for it to be useful.  But those tools can also be standalone....and that's what Bug #548124 was asking for, since they're not part of bind-tools.  Mix those in, and now you're carving up the package like a Thanksgiving turkey, and I feel confident that upstream won't accept that.  In the end, they would end up having to maintain it, if they even like the idea of making some bits optional in the first place.  If you make it too complicated, they may just take a hard pass and leave it as an exercise for the distros to figure out.
Comment 37 Eray Aslan gentoo-dev 2023-06-30 11:20:46 UTC
1/ I am more inclined to last rite bind-tools. Just have net-dns/bind and leave whether to start the server or not up to the admin

2/ Are you going to keep the CHROOT stuff?
Comment 38 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-30 11:21:42 UTC
(In reply to Eray Aslan from comment #37)
> 1/ I am more inclined to last rite bind-tools. Just have net-dns/bind and
> leave whether to start the server or not up to the admin

Right.

> 
> 2/ Are you going to keep the CHROOT stuff?

Yes, probably, as I know a few people using it. It's partly restored (at least) in my PR.
Comment 39 Guido Jäkel 2023-12-13 12:19:20 UTC
(In reply to Krzysztof Olędzki from comment #25)
> Regarding EOL, I would be more worried about the 9.16 branch (the only one
> available in portage), as https://kb.isc.org/docs/bind-9-end-of-life-dates
> suggests that we may only have about 9 months left before its EOL.

The EOL for 9.16 is very near. And to my understanding upgrading to 9.18 may require some attention and non-vanilla changes on existing installations.

Are the files at https://github.com/gentoo/gentoo/pull/25220 already usable as a template to ebuild a current release like 9.18.20 ?
Comment 40 Krzysztof Olędzki 2024-02-04 05:51:49 UTC
Happy New Year everyone! ;)

Yes, it is 2024 now. 

https://www.isc.org/download/ now shows "approaching EOL" for the 9.16.x branch, and https://kb.isc.org/docs/bind-9-end-of-life-dates states "Mar 2024 (upon release of 9.20)" so we have about one month left.
Comment 41 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-02-07 00:26:07 UTC
Thanks for the reminder. It's very near the top of the list.
Comment 42 Klemen Mihevc 2024-02-07 13:30:56 UTC
Honestly... maybe at this point we should just wait for 9.20 :) Because honestly this is biggest(?) DNS server tool right now and having it so much out of sync from official releases is just... what 9.20 will bring that im personally really interest it is ability to use DoT resolvers.
Comment 43 Eray Aslan gentoo-dev 2024-02-08 07:27:37 UTC
Sam, a final request to reconsider trying to keep the CHROOT stuff in. It results in just too much maintenance burden that we cannot afford - as can be seen in this 24 months old version bump request. The bump without CHROOT was ready 2 years ago but we do not have it in the tree because we try to keep CHROOT in. I do not think this beneficial for our users.

- get rid of CHROOT and all related cruft in the ebuild. simplify and make it maintanable
- (optional but recommended) get rid of bind-tools. we are not debian and do not start binaries on install
- bump net-dns/bind with something similar to https://github.com/erayaslan/eras-overlay/tree/main/net-dns/bind

if you agree, I can help/make the necessary changes. Thanks
Comment 44 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-02-08 07:30:59 UTC
(In reply to Eray Aslan from comment #43)
> Sam, a final request to reconsider trying to keep the CHROOT stuff in.

I'll think about it again. It just doesn't really help that people kept begging us to keep it :(

> It
> results in just too much maintenance burden that we cannot afford - as can
> be seen in this 24 months old version bump request. The bump without CHROOT
> was ready 2 years ago but we do not have it in the tree because we try to
> keep CHROOT in. I do not think this beneficial for our users.

A very fair point. Let me meditate on it more, I do very much get it, and I'd personally prefer it gone myself, but the outcry made me reconsider. Let me also see if we use the functionality at work... I thought we did, but maybe we don't..

> 
> - get rid of CHROOT and all related cruft in the ebuild. simplify and make
> it maintanable
> - (optional but recommended) get rid of bind-tools. we are not debian and do
> not start binaries on install

We tried that and it's not feasible -- ultimately, the same code is built, so we end up just maintaining a brittle set of `rm`s across the ebuilds to avoid collisions.

But the point about chroot is heard. It's precisely why I haven't just got this done already, because I don't have a setup to easily test it in, and I'm worried about getting it wrong. I really feel like if people want chroot functionality, it shouldn't need this much manual fiddling in the init script. bleh
Comment 45 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-02-08 07:33:24 UTC
Maybe we can just tell people who want the chroot functionality to maintain their own init scripts. If they were actually willing & maintained it, nothing would even prevent it being its own package in ::gentoo, as long as it installed under its own name.

I could remove it guilt-free then.
Comment 46 Hanno Böck gentoo-dev 2024-02-08 07:48:26 UTC
(In reply to Sam James from comment #44)
> (In reply to Eray Aslan from comment #43)
> > - get rid of CHROOT and all related cruft in the ebuild. simplify and make
> > it maintanable
> > - (optional but recommended) get rid of bind-tools. we are not debian and do
> > not start binaries on install
> 
> We tried that and it's not feasible -- ultimately, the same code is built,
> so we end up just maintaining a brittle set of `rm`s across the ebuilds to
> avoid collisions.

I'm confused here, and wondering if there's a misunderstanding. Eray Aslan suggested to get rid of bind-tools, i.e. having both in one package and simplify things.

What you write sounds like you're arguing for the same thing ("brittle set of `rm's`" sounds like what you have in a split bind/bind-tools situation), but disagreeing at the same time.

Is there some misunderstanding and you actually both argue for the same thing? (FWIW, I remember having looked at the bind/bind-tools split a while ago and wondered if it wouldn't be better to not split them, so I would also suggest having just one bind package.)
Comment 47 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-02-08 07:49:41 UTC
oops -- yes!
Comment 48 Joshua Kinard gentoo-dev 2024-02-08 08:43:07 UTC
I was mulling an idea about the chroot stuff.  I'm not the biggest fan of keeping that kind of logic in an actual package ebuild, but looking at how we now leverage ebuilds to do things like install users and groups, why not have an "app-chroot" category wherein are placed ebuilds that do any logic related to chroot functions, then a local (or global) USE that deps on it?  E.g., take the chroot logic for bind out and place it in app-chroot/bind, add USE 'chroot' to net-dns/bind so it gets pulled in, and make the bind-tools package not include it (since it won't be pulling in the server components)?  Those who want the chroot capability can simply add USE 'chroot' to their config and pull it in.  User choice is preserved, and the chroot logic is properly separated off into its own little ebuild.

I have not looked at if this is even technically feasible w/ how Portage currently works.  Just not had the time to dork around with the idea in a test ebuild or such.  But figured I'd throw it out there?
Comment 49 Alexey Chernyak 2024-02-08 12:39:00 UTC
I don't understand what the problem with CHROOT is?
It's already there.
It works.
People are using it.

Pulling it out would make life really difficult for everyone who is already using it next time they upgrade.

I've been using it with 9.16, I upgraded to 9.18 and have been using it without any drama for a year now.

I outlined all the issues I encountered and how I solved them in Sam's GitHub URL linked in this bug.

I'm happily using CHROOT and it hasn't been an issue at all.

The bind-tools on the other hand is indeed a dillema that needs to be addressed.
Comment 50 白川間瀬流 2024-02-14 13:18:43 UTC
I just wanted to notify that Debian's oldstable(!) bind is more recent than Gentoo's which is affected by several known (and already misused) security breaches.