Results of BIND RFC

[Doug Barton]

Greetings,

SUMMARY

On February 21 I sent a message to freebsd-***@FreeBSD.org detailing
the current state of BIND on FreeBSD, and plans for the future. You can
see that message here:
http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html

In that message I asked for feedback on my plans for dealing with BIND
in the base. There wasn't much response on the lists, however I did
receive a great deal of response privately, all more or less to the
effect of, "Do we really need to continue having BIND in the base at
all?" After careful consideration and private discussion about this
issue the conclusion has been reached that the answer to this question
is, "No." Therefore we will be removing BIND from the FreeBSD base.

BACKGROUND

"Back in the day" when the FreeBSD project started there was really only
one show in the DNS town, BIND. In the last 10 years several truly
viable, first-class DNS options have been developed, in both the
authoritative and resolving server spaces. There are ports available for
each of these options, and many FreeBSD users take advantage of them.
There are of course also ports available for all supported BIND
versions, as well as dns/bind9 for BIND version 9.3 which has been
EOL'ed by ISC but is still in FreeBSD version 6.

This also leads to the issue mentioned in the post above, the
desynchronization between FreeBSD and ISC release schedules. While
FreeBSD 6 is scheduled to EOL in November of this year, it contains BIND
version 9.3.6-P1, which has long been EOL. There are a number of
problems related to upgrading the version of BIND in a release branch of
FreeBSD. Given the ease with which FreeBSD users can upgrade BIND with
the ports tree, and given the characteristics of the vulnerabilities
that have come to light with BIND 9.3.x to date, this hasn't been a
problem. There is no guarantee that this will continue to be the case.
This problem will reappear again in FreeBSD version 7 with BIND 9.4, and
FreeBSD version 8 with BIND 9.6.

PROS

This change will have several advantages.

1) Users of all FreeBSD versions will be able to have easy access to the
latest versions of BIND, and an easy upgrade path that does not involve
a full OS upgrade.
2) The release synchronization problem mentioned above will no longer be
a problem.
3) Users of other DNS solutions will no longer need to customize their
build using the various WITH/WITHOUT_BIND* knobs.

CONS

Of course this change will have some costs. Users of named who rely on
the current defaults will have some change management to deal with,
however the costs will be minimal. The one area that has come up
repeatedly in previous discussions about this topic is that users like
having access to the command line tools dig, host, and nslookup. To deal
with that issue I will be creating a bind-tools port so that those who
want just those tools can easily add them, without the overhead of the
rest of the BIND suite. If anyone has suggestions for other BIND tools
that should be included in the port, please let me know.

IMPLEMENTATION TIMELINE

I will be removing BIND from HEAD today. Removal from the other branches
will occur far enough in advance of their upcoming releases to ensure
that the users have a chance to shake things out first. I'll also be
committing the bind-tools and bind-config ports today so that users will
continue to have easy access to the work I've done on named.conf,
rc.d/named, etc.

I have been maintaining BIND in the base for almost 8 years now, and
while it's been challenging in a lot of ways, it's also been a great
privilege to be able to help the FreeBSD community in this way. I can't
say that I'll miss the drama of src updates though. :)


Many happy returns of the day,

Doug

- --

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

[Peter Thoenen]

May I only hope this is legit and not a April Fool's joke :)

[Randy Bush]

Post by Peter Thoenen
May I only hope this is legit and not a April Fool's joke :)

actually, as an unbound user, i would be quite happy to have bind
removed. bloated, ever-buggy, config religion, ...

randy

[jhell]

Post by Randy Bush

Post by Peter Thoenen
May I only hope this is legit and not a April Fool's joke :)

actually, as an unbound user, i would be quite happy to have bind
removed. bloated, ever-buggy, config religion, ...
randy

At least I hope that this will be removed and added to the distribution
as a package upon release time.

[Stanislav Sedov]

On Thu, 01 Apr 2010 15:16:59 -0700

Post by Doug Barton
Of course this change will have some costs. Users of named who rely on
the current defaults will have some change management to deal with,
however the costs will be minimal. The one area that has come up
repeatedly in previous discussions about this topic is that users like
having access to the command line tools dig, host, and nslookup. To deal
with that issue I will be creating a bind-tools port so that those who
want just those tools can easily add them, without the overhead of the
rest of the BIND suite. If anyone has suggestions for other BIND tools
that should be included in the port, please let me know.

Hey, Doug!

While it certainly might make sense to drop BIND out of the base, I'm not
sure dropping bind tools as well from it is the best decision. How hard
it will be to continue maintaining bind tools inside the base (so the
critical ones like dig and nslookup still will be available), while moving
the rest of it (the server itself and supporting tools) to the port?

[Andrey V. Elsukov]

Post by Stanislav Sedov
While it certainly might make sense to drop BIND out of the base, I'm not
sure dropping bind tools as well from it is the best decision. How hard
it will be to continue maintaining bind tools inside the base (so the
critical ones like dig and nslookup still will be available), while moving
the rest of it (the server itself and supporting tools) to the port?

Hi, All.

I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base,
It is very useful to still having them in base system.

[Denny Lin]

Post by Andrey V. Elsukov

Post by Stanislav Sedov
While it certainly might make sense to drop BIND out of the base, I'm not
sure dropping bind tools as well from it is the best decision. How hard
it will be to continue maintaining bind tools inside the base (so the
critical ones like dig and nslookup still will be available), while moving
the rest of it (the server itself and supporting tools) to the port?

Hi, All.
I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base,
It is very useful to still having them in base system.

+1 here. Dig and some of the other tools are extremely useful and
important, so it would be nice if they were in the base system instead
of a separate port.

[Doug Hardie]

Post by Denny Lin

Post by Andrey V. Elsukov

Post by Stanislav Sedov
While it certainly might make sense to drop BIND out of the base, I'm not
sure dropping bind tools as well from it is the best decision. How hard
it will be to continue maintaining bind tools inside the base (so the
critical ones like dig and nslookup still will be available), while moving
the rest of it (the server itself and supporting tools) to the port?

Hi, All.
I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base,
It is very useful to still having them in base system.

+1 here. Dig and some of the other tools are extremely useful and
important, so it would be nice if they were in the base system instead
of a separate port.

The reason dig and nslookup are used is because you have a problem with the internet connection. Thats a bit late to say "you need to install the DNS tools". If you could, you wouldn't need them. Not everyone will create a ports CD. _______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-***@freebsd.org"

[Randy Bush]

Post by Stanislav Sedov
While it certainly might make sense to drop BIND out of the base, I'm not
sure dropping bind tools as well from it is the best decision. How hard
it will be to continue maintaining bind tools inside the base (so the
critical ones like dig and nslookup still will be available), while moving
the rest of it (the server itself and supporting tools) to the port?

i don't mind if dig, doc, et alia are not in base, as long as they are a
separate port from the bind hippo.

randy

[Stanislav Sedov]

On Fri, 02 Apr 2010 17:26:13 +0900

Post by Randy Bush
i don't mind if dig, doc, et alia are not in base, as long as they are a
separate port from the bind hippo.

The major benefit of having them in the base
is the ability to cross-compile them when
building the distribution for another platform.
Ports doesn't support cross-compilation yet,
and it would be a pity to find yourself
bootstrapping another tiny arm platform and
having to use ports to have a usable system.

[Poul-Henning Kamp]

Post by Stanislav Sedov
On Fri, 02 Apr 2010 17:26:13 +0900
Ports doesn't support cross-compilation yet,
and it would be a pity to find yourself
bootstrapping another tiny arm platform and
having to use ports to have a usable system.

The result of the RFC was that bind is not a mandatory component
to make "a usable system", so you argument suffers from bad logic.

The fact that you want BIND on your arm, is no different from
somebody else wanting postfix on a MIPS.

[Stanislav Sedov]

On Fri, 02 Apr 2010 08:55:07 +0000

Post by Poul-Henning Kamp

Post by Stanislav Sedov
On Fri, 02 Apr 2010 17:26:13 +0900
Ports doesn't support cross-compilation yet,
and it would be a pity to find yourself
bootstrapping another tiny arm platform and
having to use ports to have a usable system.

The result of the RFC was that bind is not a mandatory component
to make "a usable system", so you argument suffers from bad logic.
The fact that you want BIND on your arm, is no different from
somebody else wanting postfix on a MIPS.

Sorry, I think I was not clear enough.
What I actually want is to have a couple
of the important tools in the base while
moving everything also in ports. By important
tools I mean nslookup (and maybe dig), and at
least the first one is cruicial for the system
bringup. That one is also nice to have on the
livecd, which currently includes (I believe)
only the base system.

[Robert Watson]

The result of the RFC was that bind is not a mandatory component to make "a
usable system", so you argument suffers from bad logic.

With an eye on the date of Doug's suggestive e-mail, I actually am concerned
that we maintain support for DNSSEC validation in the base system. If this
can be accomplished by keeping DNS debugging tools and the lightweight
resolver in the base, then I'm fine with that world view. However, if we
can't do DNSSEC record validation without installing the BIND package, then
that worries me.

As we go forward, DNSSEC is going to become increasingly important, and being
unable to bootstrap a system will be a problem, and it will become an
increasingly critical part of the security bootstrap process for networked
systems. While some DNSSEC folk consider it anathema ("DNS is not a directory
service!"), the ability to securely distribute keying material via an existing
network service has enourmous value: for example, early DNSSEC prototypes in
the late 1990's/early 2000's included SSH key distribution via cert records in
DNSSEC. Similarly, as proposals to tie DHCP security and mobility security to
DNSSEC expand, any decision to require a package to do DNSSEC would mean any
component depending on that also has to be outside our base.

If all requirements along these lines are met by the lightweight resolver,
then this is less of a concern.

Robert

[Doug Barton]

So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false sense of
joy, my apologies. :) And for the record, everything from here on is
"just the facts."

I have always said that I will remove BIND from the base when there is
clear community consensus to do so, and I stand by that. However the
discussion always seems to go along the lines that this thread did. A
vocal group who say, "YES!" and then a lot of people who want the
resolution tools (dig, host, nslookup) to stay, and the other end of the
bell-shaped curve with those who like having the whole thing in the
base. Toss in a few choruses of "The whole base should be more modular,"
(a viewpoint with which I have a great deal of sympathy btw) and the
soup is pretty well complete.

In regard to the tools issue, the problem is that you need a pretty good
majority of the code in order to build them. They require the libraries
to be built, and once you've done that, you might as well do the rest. :)

Total size of code in:
contrib/bind9: 14.0M
contrib/bind9/lib: 7.6M
contrib/bind9/bin: 2.5M
contrib/bind9/bin/dig: 0.4M

The last is the directory that has the code for all 3 resolution tools,
FYI.

Therefore I think that the status quo of having it all in there, and
knobs to turn off the bits you don't want is a good one since it seems
to please the majority of our users. I will continue to maintain the
bind-tools port though, that's something that's been requested often,
and I think it's a good thing to have for those who want a different DNS
solution but still want access to those tools in a fairly painless
manner. And of course the ability to easily change/upgrade/manage what
version of BIND you use via the ports will continue to be a key
component of how we deal with this going forward.

Of course, the release synchronization problems I described in both the
original post and the AFD post are real, so stay tuned. :)

Answers to DNSSEC concerns below.

Post by Robert Watson
With an eye on the date of Doug's suggestive e-mail, I actually am concerned
that we maintain support for DNSSEC validation in the base system. If this
can be accomplished by keeping DNS debugging tools and the lightweight
resolver in the base, then I'm fine with that world view. However, if we
can't do DNSSEC record validation without installing the BIND package, then
that worries me.

Unfortunately this answer is more complicated than I'd like it to be. In
general, DNS resolution requires 4 components (and yes, this is pretty
well simplified, but I think the illustration serves to clarify my point):
1. An end-user application that makes a request
2. A stub resolver located on the local system
3. A resolving name server
4. An authoritative name server

At this time the DNSSEC protocol only clearly addresses the behavior of
4, and partially addresses the behavior of 3. There is no protocol
specification for 1 or 2. So in general if you want to be able to
validate DNSSEC signatures on the local system the only option available
to you is to run a local validating resolver. It doesn't have to be
BIND, unbound is also a good candidate, but you have to run something
locally to be sure that the response(s) you've received are valid.

Now that said, if you have a special purpose in mind to validate records
in a specific domain (or specific few domains) for which you are
prepared to individually manage trust anchors (the generic term of art
for DNSSEC keys) then you could do that using dig alone. However that
solution would not scale well, and I wouldn't recommend it for a
critical piece of the base or ports.

Post by Robert Watson
As we go forward, DNSSEC is going to become increasingly important, and being
unable to bootstrap a system will be a problem, and it will become an
increasingly critical part of the security bootstrap process for networked
systems.

Since your description above is generic, I will generically agree with
you. :) I think as time goes on and more intelligence about DNSSEC is
pushed to the edges I think it will be possible to have a validating
stub resolver, and on a trusted network reasonable to rely on an
external validating resolving name server. However there's an awful lot
of supposition there, and as I said above, the spec doesn't even exist
yet, never mind the code.

Post by Robert Watson
While some DNSSEC folk consider it anathema ("DNS is not a directory
service!"), the ability to securely distribute keying material via an existing
network service has enourmous value: for example, early DNSSEC prototypes in
the late 1990's/early 2000's included SSH key distribution via cert records in
DNSSEC.

The CERT record still exists, although not for ssh. See
http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the
SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always
TXT records. :)

Now all THAT said, there is an element of DNSSEC that I am rather
strongly leaning toward putting in the ports, trust anchor
configuration. Currently you have essentially 2 choices for DNSSEC
validation, manually configure trust anchors, or use a DNS Lookaside
Validation (DLV) service, of which the most popular is ISC's. Both
options have their benefits and their drawbacks, which are outside the
scope of this post. OTOH, if things continue going according to plan the
root zone will be signed with real DNSSEC keys in July. That will make
it possible to do "regular" DNSSEC validation for those zones that are
signed from the root down by only configuring one trust anchor, the root
zone key. (If you need to validate something on a "secure island," i.e.,
one or more parent zones is not signed, you are back to the first 2
choices, but once again, out of scope.)

In the ideal world the root zone trust anchor would function like the
root.hints file does now. It is stable (not updated often) and failure
to update it in a timely manner would not be catastrophic.
Unfortunately, the first is not guaranteed, and the latter is the
opposite of the truth. There has already been on incident where an OS
distribution had shipped with trust anchors manually configured and when
they became outdated hilarity ensued. I would like to avoid that for our
users.

At this time my plan is to add hooks for "easy" incorporation of DNSSEC
validation into the base named.conf, with instructions for how to
install the port/package, the importance of keeping it up to date, etc.
Before I make any changes I'll be seeking input from experts in the
DNSSEC community and posting something a little more focused on -arch at
least. If the release engineer or security officer teams have
"something" in mind for FreeBSD that will require DNSSEC, we'll have to
coordinate efforts on this, but I don't imagine it will be too difficult
even with a bind-dnssec-config port.


hth,

Doug

- --

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

[Ian Smith]

Post by Doug Barton
So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false sense of
joy, my apologies. :) And for the record, everything from here on is
"just the facts."

You're a proper bastard, Doug - in the strictly affectionate Aussie
sense of the term. Talk about stirring the possum!

Had me fired up to figure out how to add a choice menu to sysinstall ..

Good to hear the DNSSEC stuff is coming along, however ponderously.

KUTGW, Ian

[Arseny Nasokin]

Post by Doug Barton
Therefore I think that the status quo of having it all in there, and
knobs to turn off the bits you don't want is a good one since it seems
to please the majority of our users. I will continue to maintain the
bind-tools port though, that's something that's been requested often,
and I think it's a good thing to have for those who want a different DNS
solution but still want access to those tools in a fairly painless
manner. And of course the ability to easily change/upgrade/manage what
version of BIND you use via the ports will continue to be a key
component of how we deal with this going forward.
Of course, the release synchronization problems I described in both the
original post and the AFD post are real, so stay tuned. :)

Some about BIND and XML support via port. As I know, world is enough
to build everything in it, but support build something in world, which
depends on some port is not good idea. Yes, it useful option, but I
think it should be in port(which has much more flexibility), not in
world.

Post by Doug Barton
hth,
Doug
- --
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3
788AoPf53oxsgutXPriuLOszcp2DBKc1
=hUnq
-----END PGP SIGNATURE-----
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-current
"

[Arseny Nasokin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false sense of
joy, my apologies. :) And for the record, everything from here on is
"just the facts."
I have always said that I will remove BIND from the base when there is
clear community consensus to do so, and I stand by that. However the
discussion always seems to go along the lines that this thread did. A
vocal group who say, "YES!" and then a lot of people who want the
resolution tools (dig, host, nslookup) to stay, and the other end of the
bell-shaped curve with those who like having the whole thing in the
base. Toss in a few choruses of "The whole base should be more
modular,"
(a viewpoint with which I have a great deal of sympathy btw) and the
soup is pretty well complete.
In regard to the tools issue, the problem is that you need a pretty good
majority of the code in order to build them. They require the
libraries
to be built, and once you've done that, you might as well do the rest. :)
contrib/bind9: 14.0M
contrib/bind9/lib: 7.6M
contrib/bind9/bin: 2.5M
contrib/bind9/bin/dig: 0.4M
The last is the directory that has the code for all 3 resolution tools,
FYI.
Therefore I think that the status quo of having it all in there, and
knobs to turn off the bits you don't want is a good one since it seems
to please the majority of our users. I will continue to maintain the
bind-tools port though, that's something that's been requested often,
and I think it's a good thing to have for those who want a different DNS
solution but still want access to those tools in a fairly painless
manner. And of course the ability to easily change/upgrade/manage what
version of BIND you use via the ports will continue to be a key
component of how we deal with this going forward.
Of course, the release synchronization problems I described in both the
original post and the AFD post are real, so stay tuned. :)
Answers to DNSSEC concerns below.

Post by Robert Watson
With an eye on the date of Doug's suggestive e-mail, I actually am concerned
that we maintain support for DNSSEC validation in the base system.
If this
can be accomplished by keeping DNS debugging tools and the
lightweight
resolver in the base, then I'm fine with that world view. However, if we
can't do DNSSEC record validation without installing the BIND
package, then
that worries me.

Unfortunately this answer is more complicated than I'd like it to be. In
general, DNS resolution requires 4 components (and yes, this is pretty
1. An end-user application that makes a request
2. A stub resolver located on the local system
3. A resolving name server
4. An authoritative name server
At this time the DNSSEC protocol only clearly addresses the behavior of
4, and partially addresses the behavior of 3. There is no protocol
specification for 1 or 2. So in general if you want to be able to
validate DNSSEC signatures on the local system the only option
available
to you is to run a local validating resolver. It doesn't have to be
BIND, unbound is also a good candidate, but you have to run something
locally to be sure that the response(s) you've received are valid.
Now that said, if you have a special purpose in mind to validate records
in a specific domain (or specific few domains) for which you are
prepared to individually manage trust anchors (the generic term of art
for DNSSEC keys) then you could do that using dig alone. However that
solution would not scale well, and I wouldn't recommend it for a
critical piece of the base or ports.

Post by Robert Watson
As we go forward, DNSSEC is going to become increasingly important, and being
unable to bootstrap a system will be a problem, and it will become an
increasingly critical part of the security bootstrap process for networked
systems.

Since your description above is generic, I will generically agree with
you. :) I think as time goes on and more intelligence about DNSSEC is
pushed to the edges I think it will be possible to have a validating
stub resolver, and on a trusted network reasonable to rely on an
external validating resolving name server. However there's an awful lot
of supposition there, and as I said above, the spec doesn't even exist
yet, never mind the code.

Post by Robert Watson
While some DNSSEC folk consider it anathema ("DNS is not a directory
service!"), the ability to securely distribute keying material via an existing
network service has enourmous value: for example, early DNSSEC prototypes in
the late 1990's/early 2000's included SSH key distribution via cert records in
DNSSEC.

The CERT record still exists, although not for ssh. See
http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the
SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always
TXT records. :)
Now all THAT said, there is an element of DNSSEC that I am rather
strongly leaning toward putting in the ports, trust anchor
configuration. Currently you have essentially 2 choices for DNSSEC
validation, manually configure trust anchors, or use a DNS Lookaside
Validation (DLV) service, of which the most popular is ISC's. Both
options have their benefits and their drawbacks, which are outside the
scope of this post. OTOH, if things continue going according to plan the
root zone will be signed with real DNSSEC keys in July. That will make
it possible to do "regular" DNSSEC validation for those zones that are
signed from the root down by only configuring one trust anchor, the root
zone key. (If you need to validate something on a "secure island," i.e.,
one or more parent zones is not signed, you are back to the first 2
choices, but once again, out of scope.)
In the ideal world the root zone trust anchor would function like the
root.hints file does now. It is stable (not updated often) and failure
to update it in a timely manner would not be catastrophic.
Unfortunately, the first is not guaranteed, and the latter is the
opposite of the truth. There has already been on incident where an OS
distribution had shipped with trust anchors manually configured and when
they became outdated hilarity ensued. I would like to avoid that for our
users.
At this time my plan is to add hooks for "easy" incorporation of DNSSEC
validation into the base named.conf, with instructions for how to
install the port/package, the importance of keeping it up to date, etc.
Before I make any changes I'll be seeking input from experts in the
DNSSEC community and posting something a little more focused on -
arch at
least. If the release engineer or security officer teams have
"something" in mind for FreeBSD that will require DNSSEC, we'll have to
coordinate efforts on this, but I don't imagine it will be too
difficult
even with a bind-dnssec-config port.
hth,
Doug
- --
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3
788AoPf53oxsgutXPriuLOszcp2DBKc1
=hUnq
-----END PGP SIGNATURE-----
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-current
"

[Poul-Henning Kamp]

Post by Stanislav Sedov
On Fri, 02 Apr 2010 08:55:07 +0000
Sorry, I think I was not clear enough.

Sorry for misunderstanding.

Yes, the case can certainly be made that DNS query tool belongs in the
base system.

[s***@nethelp.no]

[1]: FreeBSD really needs to move away from the "base system" as a
concept, as I've ranted about in the past.

Strongly disagree.

Or if it cannot, the "base
system" needs to start using pkg_* (somehow) for use, and src.conf
WITHOUT_xxx (where xxx = some software) removed. Concept being: "I
don't need Kerberos; pkg_delete base-krb5. I also don't need lib32;
pkg_delete base-lib32". Beautiful concept, hard to implement due to
libraries being yanked out from underneathe binaries that are linked to
them. But you get the idea.

This *might* be workable. However, in general - a large part of the
reason why I use FreeBSD is that the FreeBSD base system gives me
most of what I want, in *one* well defined chunk, *without* having
to install a zillion extra packages, and without umpteen different
versions of config files and locations for the important information.

So please don't destroy this.

Steinar Haug, Nethelp consulting, ***@nethelp.no

[Reko Turja]

+AD4- Strongly disagree.
+AD4-
+AD4APg- Or if it cannot, the +ACI-base
+AD4APg- system+ACI- needs to start using pkg+AF8AKg- (somehow) for use, and src.conf
+AD4APg- WITHOUT+AF8-xxx (where xxx +AD0- some software) removed. Concept being: +ACI-I
+AD4APg- don't need Kerberos+ADs- pkg+AF8-delete base-krb5. I also don't need
+AD4APg- lib32+ADs-
+AD4APg- pkg+AF8-delete base-lib32+ACI-. Beautiful concept, hard to implement due
+AD4APg- to
+AD4APg- libraries being yanked out from underneathe binaries that are
+AD4APg- linked to
+AD4APg- them. But you get the idea.
+AD4-
+AD4- This +ACo-might+ACo- be workable. However, in general - a large part of the
+AD4- reason why I use FreeBSD is that the FreeBSD base system gives me
+AD4- most of what I want, in +ACo-one+ACo- well defined chunk, +ACo-without+ACo- having
+AD4- to install a zillion extra packages, and without umpteen different
+AD4- versions of config files and locations for the important
+AD4- information.

me +-1

If I wanted to go Gnu/BSD (or Loonix) route, I'd already installed
either thank you. Funny though that BIND which is pretty
straightforward as configuration goes and as much essential system
component as Sendmail is getting the axe. I thought one of the main
philosophies in FreeBSD always was being a system in itself, rather
than kernel with some haphazardly thrown in components added.

-Reko

[Guido Falsi]

Post by s***@nethelp.no

[1]: FreeBSD really needs to move away from the "base system" as a
concept, as I've ranted about in the past.

Strongly disagree.

I'm with you!

Post by s***@nethelp.no

Or if it cannot, the "base
system" needs to start using pkg_* (somehow) for use, and src.conf
WITHOUT_xxx (where xxx = some software) removed. Concept being: "I
don't need Kerberos; pkg_delete base-krb5. I also don't need lib32;
pkg_delete base-lib32". Beautiful concept, hard to implement due to
libraries being yanked out from underneathe binaries that are linked to
them. But you get the idea.

This *might* be workable. However, in general - a large part of the
reason why I use FreeBSD is that the FreeBSD base system gives me
most of what I want, in *one* well defined chunk, *without* having
to install a zillion extra packages, and without umpteen different
versions of config files and locations for the important information.

Also, more than that, won't splitting the "base system" in many smaller
pieces moving around by themselves make every single part of freeBSD a
moving target?

What I mean is that what may look like a way to simplify things could
make matters worse with incompatibilities in between the base packages.
having everythign in the base system guarantees much more control. I'm
also thinking about the nightmares this kind of splitting could cause to
release engineering.

This is not pure speculation. Such problems do appear in many other
known open source OSes with such a split base system.

In fact, if I wanted such a thing I'd install that other open source OS.
I did in fact, and observed many annoying things about not having a rich
base system like ours(like wasting time figuring which packet contained
commands I'm used to see in the base system on any unix.

Post by s***@nethelp.no
So please don't destroy this.

I hope not. Another good reason not to destroy this is again that there
are already many alternative OSes doing it, and I think FreebSD has a
strong point in being different, not a weak spot.

[Erik Trulsson]

[1]: FreeBSD really needs to move away from the "base system" as a
concept, as I've ranted about in the past. Or if it cannot, the "base
system" needs to start using pkg_* (somehow)

No, it does not need to do that. It might be a good idea (but I am far
from convinced of it), but there most certainly is no *need* to move in
that direction.

[Jeremy Chadwick]

Post by Poul-Henning Kamp

Post by Stanislav Sedov
On Fri, 02 Apr 2010 08:55:07 +0000
Sorry, I think I was not clear enough.

Sorry for misunderstanding.
Yes, the case can certainly be made that DNS query tool belongs in the
base system.

I disagree (so what else is new?) It should be kept out of the base
system. KISS:

Doug pulling BIND out of the base system / going ports-only = excellent.

Doug making a separate port for BIND-esque DNS query/maintenance tools =
excellent.

Both of the above can be made into packages. Vendors who use FreeBSD
can incorporate said package(s) into their build infrastructure. Folks
who do not have Internet connections (yet for some reason want said DNS
tools) can install the package(s) from CD/DVD/USB.

I want the bikeshed to be black. :-)


[1]: FreeBSD really needs to move away from the "base system" as a
concept, as I've ranted about in the past. Or if it cannot, the "base
system" needs to start using pkg_* (somehow) for use, and src.conf
WITHOUT_xxx (where xxx = some software) removed. Concept being: "I
don't need Kerberos; pkg_delete base-krb5. I also don't need lib32;
pkg_delete base-lib32". Beautiful concept, hard to implement due to
libraries being yanked out from underneathe binaries that are linked to
them. But you get the idea.

[Freddie Cash]

[1]: FreeBSD really needs to move away from the "base system" as a
concept, as I've ranted about in the past. Or if it cannot, the "base
system" needs to start using pkg_* (somehow) for use, and src.conf
WITHOUT_xxx (where xxx = some software) removed. Concept being: "I
don't need Kerberos; pkg_delete base-krb5. I also don't need lib32;
pkg_delete base-lib32". Beautiful concept, hard to implement due to
libraries being yanked out from underneathe binaries that are linked to
them. But you get the idea.

Maybe I'm just a lowly sysadmin and ex-port maintainer, but ...

No, no, no, definitely no, no, and no!!

The greatest thing about FreeBSD is that there is a clear separation between
the "base OS" and everything else (ports, local installs, etc). You get a
nice, clearly defined, base to build on. You get a stable base that changes
infrequently, that you can add software to on whatever schedule you want.

The worst thing about Linux distros is the lack of this clear separation
between the base and third-party apps. If you want to install an updated
version of Apache, you either have to update the whole damned distro, go
searching for some unsupported backports repos, or compile everything by
hand defeating the whole point of binary packages.

Making the tools do deal with the base could be interesting, but please,
please, please don't shove everything into the pkg_tools and turning FreeBSD
into "just a random collection of packages that kind of work together".
IOW, don't go down the distro path.

Keep the base OS separate from third-party apps. Keep the tools to deal
with them separate.

[Adam Vande More]

Post by Freddie Cash
Maybe I'm just a lowly sysadmin and ex-port maintainer, but ...
No, no, no, definitely no, no, and no!!
The greatest thing about FreeBSD is that there is a clear separation between
the "base OS" and everything else (ports, local installs, etc). You get a
nice, clearly defined, base to build on. You get a stable base that changes
infrequently, that you can add software to on whatever schedule you want.
The worst thing about Linux distros is the lack of this clear separation
between the base and third-party apps. If you want to install an updated
version of Apache, you either have to update the whole damned distro, go
searching for some unsupported backports repos, or compile everything by
hand defeating the whole point of binary packages.
Making the tools do deal with the base could be interesting, but please,
please, please don't shove everything into the pkg_tools and turning FreeBSD
into "just a random collection of packages that kind of work together".
IOW, don't go down the distro path.
Keep the base OS separate from third-party apps. Keep the tools to deal
with them separate.

True word, brother! If we wanted to run linux there are options for it.
debs suck, rpms really suck. Those types of systems are sometimes faster to
get up and rolling as long as you want vanilla apps, but they are a major
PITA for many types of customizations which are a breeze with the ports
tree. You'd be killing of one of the more elegant approaches in FreeBSD.
Sure there are problem with it, but IMO adopting more severe problems isn't
a good answer.

Maybe that was a 4/1 too though. If so, good work.

[Kevin Oberman]

Date: Fri, 2 Apr 2010 03:14:54 -0700

Post by Poul-Henning Kamp

Post by Stanislav Sedov
On Fri, 02 Apr 2010 08:55:07 +0000
Sorry, I think I was not clear enough.

Sorry for misunderstanding.
Yes, the case can certainly be made that DNS query tool belongs in the
base system.

I disagree (so what else is new?) It should be kept out of the base
Doug pulling BIND out of the base system / going ports-only = excellent.
Doug making a separate port for BIND-esque DNS query/maintenance tools =
excellent.
Both of the above can be made into packages. Vendors who use FreeBSD
can incorporate said package(s) into their build infrastructure. Folks
who do not have Internet connections (yet for some reason want said DNS
tools) can install the package(s) from CD/DVD/USB.
I want the bikeshed to be black. :-)

I have very mixed feelings on this. I agree with arguments I have seen
on both sides. I like being able to install FreeBSD and have a well
integrated system with all of the basic tools installed for basic
use. Things play together well.

I don't use many of the base system tools. I use cups, postfix,
customized ssh, and the ports version of BIND. I don't build the stuff I
don't need (src.conf) and I don't mind them being there.

On the other hand, for complex, heavy duty ports, keeping up to date
with externally maintains tools (contrib) is a pain and the base system
can get stuck with rather out of date tools as a result. (Remember
perl?) Unless there is very strong support for a contributed tools, it's
hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC,
it's still hopeless.

I have seen suggestions that some tools be kept in the base
system. nslookup (an evil tool that I think should be put out of its
misery) and dig (a good tool that not enough people understand how to
use) have been explicitly mentioned. The problem is that dig needs to
be in reasonable feature sync with the resolver or it can have
problems.

Finally, what about a stub resolver? This really MUST be in the base
system and, it should understand DNSSEC soon, which just complicates
things.

I prefer my bikeshed in green. Black is too goth and too hot for my
tastes.

[Reko Turja]

Based on the inspection of the source tree, I want my bikeshed mauve.
I've not been had by AFD jokes in a while but Doug pulled this one
off...

-Reko

[Charles Sprickman]

Can we do sendmail next April 1?

Sent from a device with a tiny keyboard

Post by Reko Turja
Based on the inspection of the source tree, I want my bikeshed
mauve. I've not been had by AFD jokes in a while but Doug pulled
this one off...
-Reko
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
"

[Ruben de Groot]

Post by Charles Sprickman
Can we do sendmail next April 1?

Better yet, defer all questions about moving <X> out of the base system by
referring to the Grand Discussion that'll take place *next year* on the
first of april.

[p***@pluto.rain.com]

defer all questions about moving <X> out of the base system ...

Last I knew, X was not _in_ the base system :)

[Peter Jeremy]

Post by p***@pluto.rain.com

defer all questions about moving <X> out of the base system ...

Last I knew, X was not _in_ the base system :)

Well, that's an excellent topic for another bikeshed - Should X be
made part of the base system? I know it is on OpenBSD.

:-) :-)

[Daniel Eischen]

Post by Kevin Oberman

Date: Fri, 2 Apr 2010 03:14:54 -0700
I disagree (so what else is new?) It should be kept out of the base
Doug pulling BIND out of the base system / going ports-only = excellent.
Doug making a separate port for BIND-esque DNS query/maintenance tools =
excellent.
Both of the above can be made into packages. Vendors who use FreeBSD
can incorporate said package(s) into their build infrastructure. Folks
who do not have Internet connections (yet for some reason want said DNS
tools) can install the package(s) from CD/DVD/USB.
I want the bikeshed to be black. :-)

I have very mixed feelings on this. I agree with arguments I have seen
on both sides. I like being able to install FreeBSD and have a well
integrated system with all of the basic tools installed for basic
use. Things play together well.
I don't use many of the base system tools. I use cups, postfix,
customized ssh, and the ports version of BIND. I don't build the stuff I
don't need (src.conf) and I don't mind them being there.
On the other hand, for complex, heavy duty ports, keeping up to date
with externally maintains tools (contrib) is a pain and the base system
can get stuck with rather out of date tools as a result. (Remember
perl?) Unless there is very strong support for a contributed tools, it's
hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC,
it's still hopeless.

I really dread having to update my ports. I hate all the bloated
dependencies that a lot of ports have. It's sometimes a hit or miss
situtation; you never know whether your ports are going to build
(update) fully or not. And it takes forever. Our ports team
does a fantastic job, so no diss intended. But I am concerned
about moving BIND into ports, even if there is a tools-only port.

With BIND in base, I don't have to worry about updating or when
to update - someone else decides when to update/patch the base
BIND and I am happy with that. All I have to do is buildworld,
which I do much more often than update ports.

If there is already a WITHOUT_BIND knob, then I really don't
see what advantage there is in moving BIND out of base. Anyone
that wants to use a different resolver can already do that,
with the only limitation that they have to buildworld to
remove the base bind.