Debian/Ubuntu: Why was the service renamed from bind9 to named?

Post by Klaus Darilion
Hello!
bind9 (1:9.13.6-1) experimental; urgency=medium
...
* Rename the init scripts to named to match the name of the daemon
Since years, Debian and Ubuntu User, and plenty of scripts and automation software (Puppet ...), know that the service is called "bind9". I think it is very confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 is released.
So I really do not understand this renaming.
The software is "Bind 9". The package is "bind9". The service for long time was "bind9". The config is in /etc/bind. Only the binary is named. So it would have made more sense to rename the binary. (actually the binary is not so important for end users: they install the package and manage the service and usually do not have to worry about the name of the binary).
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution

bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

Reindl Harald

2020-04-15 07:05:02 UTC

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all

[***@srv-rhsoft:~]$ systemctl status sddm
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/display-manager.service.d

[***@srv-rhsoft:~]$ systemctl status display-manager.service
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/display-manager.service.d
└─security.conf, start-before.conf

[***@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service
[Unit]
Description=Simple Desktop Display Manager
Conflicts=***@tty1.service
After=***@tty1.service systemd-logind.service

[Service]
ExecStart=/usr/bin/sddm
Restart=always
EnvironmentFile=-/etc/sysconfig/sddm

[Install]
Alias=display-manager.service

Klaus Darilion

2020-04-15 07:08:06 UTC

-----Ursprüngliche Nachricht-----
Harald
Gesendet: Mittwoch, 15. April 2020 09:05
Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
named?

automation software (Puppet ...), know that the service is called "bind9". I
think it is very confusing and will cause lots of headaches once Ubuntu 18.04
or Debian 11 is released.

Post by Klaus Darilion
So I really do not understand this renaming.
The software is "Bind 9". The package is "bind9". The service for long time

was "bind9". The config is in /etc/bind. Only the binary is named. So it would
have made more sense to rename the binary. (actually the binary is not so
important for end users: they install the package and manage the service and
usually do not have to worry about the name of the binary).

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/display-manager.service.d
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/display-manager.service.d
└─security.conf, start-before.conf
[Unit]
Description=Simple Desktop Display Manager
[Service]
ExecStart=/usr/bin/sddm
Restart=always
EnvironmentFile=-/etc/sysconfig/sddm
[Install]
Alias=display-manager.service

Can you please describe what you want to point out? I can not follow you.

Klaus

Klaus Darilion

2020-04-15 07:09:08 UTC

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

I do not complain about the version number, but of the name.

And in my opinion it is not sane to call a service/package httpd if the name of the software is Apache.

regards
Klaus

Reindl Harald

2020-04-15 07:13:57 UTC

Post by Klaus Darilion
The software is "Bind 9". The package is "bind9". The service for long time

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

Can you please describe what you want to point out? I can not follow you

that every other distibution calls it all the time "named" and "httpd"
and it's painful every time you toch a debian setup you have to remember
"apache" and "bind9"

what if bind10 wouldn't have failed and you get a software update after
some years?

what if httpd releases 3.0 ina few years besides that "apache" is
completly wrong to begin with becaus eit could be Apache Tomcat, Apache
Trafficserver, Apache Httpd

mainly that this is a distribution issue and when they are smart you can
type "systemctl reload named" and "systemctl reload bind9" without
confusing people which know it's named outside the debian world

Units can be aliased (have an alternative name), by creating a symlink
from the new name to the existing name in one of the unit search paths.
For example, systemd-networkd.service has the alias
dbus-org.freedesktop.network1.service, created during installation as a
symlink, so when systemd is asked through D-Bus to load
dbus-org.freedesktop.network1.service, it'll load
systemd-networkd.service. As another example, default.target — the
default system target started at boot — is commonly symlinked (aliased)
to either multi-user.target or graphical.target to select what is
started by default. Alias names may be used in commands like disable,
start, stop, status, and similar, and in all unit dependency directives,
including Wants=, Requires=, Before=, After=

Reindl Harald

2020-04-15 07:17:03 UTC

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

I do not complain about the version number, but of the name.
And in my opinion it is not sane to call a service/package httpd if the name of the software is Apache

seriously?

https://www.apache.org/

https://downloads.apache.org/httpd/
https://downloads.apache.org/tomcat/
https://downloads.apache.org/trafficserver/

and what do you do after httpd-3.0 is out?

you won't have httpd2 and httpd3 on the same system from your distribution

Erich Eckner

2020-04-15 07:17:57 UTC

-----UrsprÃŒngliche Nachricht-----
Harald
Gesendet: Mittwoch, 15. April 2020 09:05
Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
named?

automation software (Puppet ...), know that the service is called "bind9". I
think it is very confusing and will cause lots of headaches once Ubuntu 18.04
or Debian 11 is released.

Post by Klaus Darilion
So I really do not understand this renaming.
The software is "Bind 9". The package is "bind9". The service for long time

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all
â sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/display-manager.service.d
â sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/display-manager.service.d
ââsecurity.conf, start-before.conf
[Unit]
Description=Simple Desktop Display Manager
[Service]
ExecStart=/usr/bin/sddm
Restart=always
EnvironmentFile=-/etc/sysconfig/sddm
[Install]
Alias=display-manager.service

Can you please describe what you want to point out? I can not follow you.

You can set aliases in the service file and call the service whatever you
like (multiple names possible, too). I admit, this has nothing to do with
the package name.

Though: you should complain to debian/ubuntu/..., not upstream (=here)
about package name changes.

Regarding version numbers: In the world, where I come from (arch linux),
version numbers are only appended for *legacy* packages - e.g. "bind9"
would be valid, if there is a "bind" package, that has a higher version
than 9. Btw.: bind is packaged as "bind" for years on arch linux.

regards,
Erich

Post by Klaus Darilion
Klaus
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Kevin A. McGrail

2020-04-15 07:21:49 UTC

Post by Klaus Darilion
I do not complain about the version number, but of the name.
And in my opinion it is not sane to call a service/package httpd if the name of the software is Apache.

For me, adding the version number can make sense if there is an
intention to have both X and Y running on machines simultaneously. Or
if there is a need / ability to choose one version with more than one
being provided by the distro. Apache httpd 1 versus 2, was a real
choice not many years ago. MySQL 5 versus 8 has a similar situation
now. I'm sure I can point out others where the version number in the
service is a pathway to upgrades.

And with Apache HTTPD, you've picked a special naming case. It is the
granddaddy of the entire Apache Software Foundation and has morphed from
being called just "Apache" to "Apache httpd". Calling the service
apachehttpd might be good and differentiate it from the ~383 Apache
projects (https://projects.apache.org/) and other httpd daemons. But
it's been just httpd in a lot of distros for over 20 years so a LOT of
historical convention here.

Unfortunately, the exact name is up to the distribution, not really the
project. So this is really a discussion for an Ubuntu/Debian mailing
list, not this one.

Regards,

KAM

Reindl Harald

2020-04-15 07:26:46 UTC

Post by Kevin A. McGrail

Post by Klaus Darilion
I do not complain about the version number, but of the name.
And in my opinion it is not sane to call a service/package httpd if the name of the software is Apache.

in all that cases the default package of the distribution (at least
outside debian) is unversioned and you can optin to an older or newer
major version by explicit install "mysql8"

but the expected default in just do "dnf install mysqld" and if you can
install both at the same time (depends on packaging)
https://linux.die.net/man/8/alternatives is the way to go

Klaus Darilion

2020-04-15 07:42:46 UTC

-----Ursprüngliche Nachricht-----
Harald
Gesendet: Mittwoch, 15. April 2020 09:17
Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
named?

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

I do not complain about the version number, but of the name.
And in my opinion it is not sane to call a service/package httpd if the name

of the software is Apache
seriously?
https://www.apache.org/
https://downloads.apache.org/httpd/
https://downloads.apache.org/tomcat/
https://downloads.apache.org/trafficserver/
and what do you do after httpd-3.0 is out?
you won't have httpd2 and httpd3 on the same system from your
distribution

Why not? With postgresql it is very common. You have postgresql-X and a meta package pointing to the newest version. That's propapbly not what "every distribution" does, but how a good distribution like Debian and Ubuntu does it.

It is very very sane to have the version number in the package, and a package without version number pointing to the newest version. Eg. this is how the Linux kernel is handled in Debian/Ubuntu.

What about python? Only a single python interpreter is allowed with your good distros? In Debian you have all oft hem installed at the same time - this is a very very good approach!

But as you have missed again - I do not complain about the version number, but that a "winning team" was changed without seeing a problem.

regards
Klaus

Reindl Harald

2020-04-15 07:59:14 UTC

-----Ursprüngliche Nachricht-----
Harald
Gesendet: Mittwoch, 15. April 2020 09:17
Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
named?

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04

you confuse the upstream project with your distribution
bind9 was completly wrong in the debian world as well as apache2 for
httpd, on sane distributions it's "httpt" and "named" all the years
beause it's nonsense to throw vesions in service names

I do not complain about the version number, but of the name.
And in my opinion it is not sane to call a service/package httpd if the name

not over a long time outsuide the LTS world because nobody will maintain
it (besides that it's not the main point of my last message) and how
does that fix your wrong assumption "in my opinion it is not sane to
call a service/package httpd if the name of the software is Apache"

we are using httpd on backends and trafficserver as reverse proxy - who
of both apache projects is listening when i scream "apache" to my servers?

Post by Klaus Darilion
It is very very sane to have the version number in the package, and a package without version number pointing to the newest version. Eg. this is how the Linux kernel is handled in Debian/Ubuntu

well, than complain at your distribution

given that your mails are landing in the nic.at folder (we are a
registrar) and i know that nic.at normally has a very good technical
expertise i guess you are new there

may i ask you talk to your seniors how and where to complain about
distribution level changes and besides you are at the wrong list it's
nothing easier than make your owen overrides and aliases with
systemd-dropins so that you can call "systemctl
relaod/restart/start/stop" with whatever name you like no matter how the
distribution is calling the service

that's far quicker implemented and deployed even before you deploy the
update itself as it took to write your initial mail

Ondřej Surý

2020-04-15 08:04:39 UTC

Post by Reindl Harald
BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all

Is this the case of you being rude instead of getting the facts?

bind9 (1:9.15.3-2) unstable; urgency=medium

* Fix the section for bind9 alias in the systemd unit [GL #1193]

-- OndÅej SurÃœ <***@sury.org> Wed, 28 Aug 2019 21:35:44 +0200

$ cat named.service
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
Wants=nss-lookup.target
Before=nss-lookup.target

[Service]
EnvironmentFile=-/etc/default/named
ExecStart=/usr/sbin/named -f $OPTIONS
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target
Alias=bind9.service

--
OndÅej SurÃœ
***@isc.org

Reindl Harald

2020-04-15 08:14:30 UTC

your changelog snippet is handeled as signature seperator so a forward

when someone starts complaining "Since years, Debian and Ubuntu User,
and plenty of scripts and automation software (Puppet ...), know that
the service is called" i assume that he at least would have tried if
something is broken *before* complain and so it's a logicla assumption
the alias is missing

Debian/Ubuntu packages and what should be done there before the next
major release of the distribution don't belong here anyways

-------- Weitergeleitete Nachricht --------
Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Datum: Wed, 15 Apr 2020 10:04:39 +0200

Post by Reindl Harald
BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all

Is this the case of you being rude instead of getting the facts?

bind9 (1:9.15.3-2) unstable; urgency=medium

* Fix the section for bind9 alias in the systemd unit [GL #1193]

$ cat named.service
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target
Wants=nss-lookup.target
Before=nss-lookup.target

[Service]
EnvironmentFile=-/etc/default/named
ExecStart=/usr/sbin/named -f $OPTIONS
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target
Alias=bind9.service

Ondřej Surý

2020-04-15 08:15:09 UTC

Klaus,

the default and preferred init system on both Debian and Ubuntu is systemd,
and the unit has proper Alias, so it is recognized also under "bind9" name.

The sysv-rc script doesnât have the capability of aliases, so unfortunately, thereâs
a downfall from the renaming, but it would not make sense to have a different name
for different init systems. If you are using sysvinit, the choice and the suffering that
comes from that choice is all yours.

The renaming was done as it was a logical choice, the service is starting a daemon,
and not a package, and daemon name is `named`. Also it is the name used by RPM
based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 packages
in Debian/Ubuntu more unified with rest of the Linux world.

Ondrej
--
OndÅej SurÃœ

Reindl Harald

2020-04-15 08:21:07 UTC

you need to stop being rude to people on the bind-users mailing list,
personal attacks are not acceptable behaviour here. You should apologize
to Klaus.

it's not a personal attack to clearly point out that discussions of
distribution level changes don't belong to upstream lists and that one
within a company should at least consult someone internally with more
expierience and after "it is not sane to call a service/package httpd if
the name of the software is Apache" i simply had enough

it's also not a personal attack to point out that you could stop press
"reply-all" on a mailing list so that your off-list copy which is
quicker but has no list-headers don't break my reply-list button and
threading

Post by Reindl Harald
given that your mails are landing in the nic.at folder (we are a
registrar) and i know that nic.at normally has a very good technical
expertise i guess you are new there
may i ask you talk to your seniors how and where to complain about
distribution level changes and besides you are at the wrong list it's
nothing easier than make your owen overrides and aliases with
systemd-dropins so that you can call "systemctl
relaod/restart/start/stop" with whatever name you like no matter how the
distribution is calling the service

Klaus Darilion

2020-04-15 08:35:24 UTC

Thanks for answer!

So actually it is just a cosmetic change not addressing a real problem.

I will miss the bind9 service :-(

Klaus

-----Ursprüngliche Nachricht-----
Gesendet: Mittwoch, 15. April 2020 10:15
Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
named?
Klaus,
the default and preferred init system on both Debian and Ubuntu is systemd,
and the unit has proper Alias, so it is recognized also under "bind9" name.
The sysv-rc script doesn’t have the capability of aliases, so unfortunately,
there’s
a downfall from the renaming, but it would not make sense to have a
different name
for different init systems. If you are using sysvinit, the choice and the
suffering that
comes from that choice is all yours.
The renaming was done as it was a logical choice, the service is starting a
daemon,
and not a package, and daemon name is `named`. Also it is the name used by
RPM
based systems and Arch Linux and Gentoo, so it was also made to make BIND
9 packages
in Debian/Ubuntu more unified with rest of the Linux world.
Ondrej
--
Ondřej Surý

software (Puppet ...), know that the service is called "bind9". I think it is very
confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 is
released.

Post by Klaus Darilion
So I really do not understand this renaming.
The software is "Bind 9". The package is "bind9". The service for long time

Post by Klaus Darilion
It would be great if you undo this change before release of 18.04.
regards
Klaus
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe

from this list

Post by Klaus Darilion
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Klaus Darilion

2020-04-15 09:06:55 UTC

you need to stop being rude to people on the bind-users mailing list,
personal attacks are not acceptable behaviour here. You should apologize
to Klaus.

it's not a personal attack to clearly point out that discussions of
distribution level changes don't belong to upstream lists and that one

As it seems your are very smart you probably have noticed that Ondřej did the change in den Debian package and is also very active an this mailing list. Further I am not they only bind-user using Debian/Ubuntu so probably other bind-user are also interested in the reason for the renaming. Hence, I on purpose used this mailing list.

Post by Reindl Harald
within a company should at least consult someone internally with more
expierience and after "it is not sane to call a service/package httpd if
the name of the software is Apache" i simply had enough

Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.

Have a nice day
Klaus

FIN

Alessandro Vesely

2020-04-15 10:16:48 UTC

Post by OndÅej SurÃ½
The renaming was done as it was a logical choice, the service is starting a daemon,
and not a package, and daemon name is `named`. Also it is the name used by RPM
based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 packages
in Debian/Ubuntu more unified with rest of the Linux world.

Calling it /renamed/ would have been beyond criticism...

Best
Ale
--

Jim Popovitch

2020-04-15 12:17:42 UTC

Post by Klaus Darilion
Thanks for answer!
So actually it is just a cosmetic change not addressing a real problem.
I will miss the bind9 service :-(

Wait until you find out about Predicatable Network Interface Names and
iptables rules. :)

-Jim P.

Reindl Harald

2020-04-15 12:21:11 UTC

Post by Jim Popovitch

Post by Klaus Darilion
Thanks for answer!
So actually it is just a cosmetic change not addressing a real problem.
I will miss the bind9 service :-(

Wait until you find out about Predicatable Network Interface Names and
iptables rules. :)

"net.ifnames=0 biosdevname=0" is your friend :-)

Jim Popovitch

2020-04-15 12:31:52 UTC

Post by Jim Popovitch

Post by Klaus Darilion
Thanks for answer!
So actually it is just a cosmetic change not addressing a real problem.
I will miss the bind9 service :-(

Wait until you find out about Predicatable Network Interface Names and
iptables rules. :)

"net.ifnames=0 biosdevname=0" is your friend :-)

shhhh! Didn't you know that is suppose to be difficult for people to
figure out? :)

-Jim P.

Dennis Clarke

2020-04-15 23:10:58 UTC

Post by OndÅej SurÃ½
Klaus,
the default and preferred init system on both Debian and Ubuntu is systemd,
and the unit has proper Alias, so it is recognized also under "bind9" name.
The sysv-rc script doesn’t have the capability of aliases, so unfortunately, there’s
a downfall from the renaming, but it would not make sense to have a different name
for different init systems. If you are using sysvinit, the choice and the suffering that
comes from that choice is all yours.
The renaming was done as it was a logical choice, the service is starting a daemon,
and not a package, and daemon name is `named`. Also it is the name used by RPM
based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 packages
in Debian/Ubuntu more unified with rest of the Linux world.

An even more beautiful name would have been "iscbind" :

beta$ svcs -l iscbind
fmri svc:/network/dns/iscbind:default
name ISC BIND 9.11.16 SPARC V9 genunix
enabled true
state online
next_state none
state_time Thu Feb 20 04:35:15 2020
logfile /var/svc/log/network-dns-iscbind:default.log
restarter svc:/system/svc/restarter:default
contract_id 196663
dependency require_all/none svc:/system/filesystem/local (online)
dependency require_any/error svc:/network/loopback (online)
dependency optional_all/error svc:/milestone/network (online)
beta$

Sadly the newer releases will never be *easily* ported back to old
Solaris but we all need to move forwards.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Ted Mittelstaedt

2020-07-17 17:56:51 UTC

Post by Klaus Darilion
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.

John W. Blue

2020-07-17 18:35:29 UTC

Speaking about things to be annoyed over ..

I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.

John

-----Original Message-----
From: bind-users [mailto:bind-users-***@lists.isc.org] On Behalf Of Ted Mittelstaedt
Sent: Friday, July 17, 2020 12:57 PM
To: bind-***@lists.isc.org
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

Post by Klaus Darilion
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.

Hmm I'm a bit late to this discussion but I will chime in with the others. The service always was called "named" pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book on the subject, it was called this before you were born and it was kind of the height of hubris for it to ever be named
bind9 in a software distro.

In fact, the ONLY reason that the name "bind9" was ever even coined at all was because the changes from bind8 both in the syntax of the config file and how the program operated they wanted to boot admins in the behind to get them to change their config files. It should have been put to bed as a name a long time ago, or named "bind version 9" like every other software program does with their versions.

So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it originally was!

Ted
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Dennis Clarke

2020-07-18 13:29:35 UTC

Post by Ted Mittelstaedt
So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to
what it originally was!

Exactly ! Hear hear ! Well said.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

@lbutlr

2020-07-19 11:06:21 UTC

Post by Ted Mittelstaedt
In fact, the ONLY reason that the name "bind9" was ever even coined
at all was because the changes from bind8 both in the syntax of the
config file and how the program operated they wanted to boot admins
in the behind to get them to change their config files. It should
have been put to bed as a name a long time ago, or named "bind
version 9" like every other software program does with their versions.

This. Exactly this.

--
"Yessir, Captain Tight Pants."

tale

2020-07-20 16:09:30 UTC

This. Exactly this.

Well, one minor bit of clarification is important. While highlighting
the significant change in software might have been the motivation for
why some installers chose to go with the name bind9 in place of named
in some contexts, it was also a major design goal of BIND9 that it
could run as a drop-in replacement for BIND8 on most configurations.
It achieved this goal. The basic syntax was unchanged and
configuration behavior was largely the same but for a little bit
around the edges.

And for what it's worth, not all systems moved away from "named" to
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".

Dennis Clarke

2020-07-20 16:34:07 UTC

Post by tale
And for what it's worth, not all systems moved away from "named" to
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".

No one ever calls named anything other than named. In a sane world.

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Ted Mittelstaedt

2020-07-20 17:45:21 UTC

Post by John W. Blue
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.

I'm not happy that happened either but the simple fact is that if BIND
would quit dropping support so fast for it's older versions that never
would have happened. The fundamental problem was that BIND dropped
support for it's older versions before the distros dropped support for
their distros. This is happening with a lot of other software packages.

When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to
basically install it and forget about it, never run patches, never give
a fig about security. Simpler programs like Unbound have less code
and so less things to go wrong, need less patches, and are easier to
support for a longer period of time so they get supported for a longer
period of time. Also, Unbound's main purpose in life is as a caching
dns program. Nobody who runs a server on FreeBSD uses Unbound.

Ted

Post by John W. Blue
John
-----Original Message-----
Sent: Friday, July 17, 2020 12:57 PM
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

Post by Klaus Darilion
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.

Hmm I'm a bit late to this discussion but I will chime in with the others. The service always was called "named" pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book on the subject, it was called this before you were born and it was kind of the height of hubris for it to ever be named
bind9 in a software distro.
In fact, the ONLY reason that the name "bind9" was ever even coined at all was because the changes from bind8 both in the syntax of the config file and how the program operated they wanted to boot admins in the behind to get them to change their config files. It should have been put to bed as a name a long time ago, or named "bind version 9" like every other software program does with their versions.
So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it originally was!
Ted
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

Michael De Roover

2020-07-20 18:23:24 UTC

If that is true, I hereby lost all faith in humanity.. well whatever
faith I had left. This has been going on for like half a decade now.

A few weeks ago I saw here on the list someone suggesting that BIND is a
reference to bondage in BDSM, so perhaps it has to do with that... Lest
we forget that BIND is an abbreviation for Berkeley Internet Name
Domain. Software made at Berkeley, to serve domain names on the
internet. The name is pretty descriptive about its intended purpose I
would say. Perfectly fine! Just because an abbreviation coincidentally
becomes the same as a word in another context doesn't mean that it
suddenly /became/ that word. Western languages simply don't have enough
characters and words to make everything unique and special. And the best
part is.. banning certain words from general usage (for rather odd
reasons) only exacerbates that problem.

But with that said, if BSD thinks that BIND stands for bondage, I
suggest that BSD drops the D because it's clearly a reference to
criminally masculine dicks. Everything else is bullshit.

(My apologies if bad words are disallowed here, but I had to get this
off my chest)

Back to the thread's original topic, I happened to be configuring BIND
on Alpine yesterday. I was pleased to see that the package in Alpine is
simply called "bind". The service file in /etc/init.d is called "named".
While those decisions are entirely up to the distribution vendors, I
also think that version numbers don't really belong in the name of a
piece of software. However even upstream the repository is called
"bind9"... The branch name has already changed, so perhaps the same
could be done for the repository name?

Post by John W. Blue
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.
John

--
Met vriendelijke groet / Best regards,
Michael De Roover

Ted Mittelstaedt

2020-07-20 19:05:53 UTC

Post by Michael De Roover
If that is true, I hereby lost all faith in humanity.. well whatever
faith I had left. This has been going on for like half a decade now.

Nobody ever went broke catering to the human desire for ease....

Michael De Roover

2020-07-20 19:53:48 UTC

Sorry about that, the email might've been a bit too emotionally loaded.
The issues pile up.. and that's eventually the result.

I'm not using FreeBSD anywhere anymore but found some resources online
suggesting that the package name is bind916. The closest I could find to
unwinded is Unbound which apparently is what replaced BIND in FreeBSD
and OpenBSD. Is this the case?

Generally speaking all I'd ask for is consistency. Currently that does
not appear to be present anywhere. Everyone gives things their own (new)
names even if they're supposed to describe the same thing. It's
extremely confusing.

Post by Ted Mittelstaedt

Post by Michael De Roover
If that is true, I hereby lost all faith in humanity.. well whatever
faith I had left. This has been going on for like half a decade now.

Nobody ever went broke catering to the human desire for ease....
_______________________________________________

--
Met vriendelijke groet / Best regards,
Michael De Roover

Mark Andrews

2020-07-20 23:05:37 UTC

Post by John W. Blue
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.

There where lots of things happening at the time. There was misinformation propagated to *BSD that BIND 9 going away much faster that any plans we had. BIND 10 (now defunct) hadn’t even reached feature parity with BIND 9 which was still being developed because the DNS protocol is still be developed.

As for support life times. BIND 9.17 will load most BIND 8.0 configurations. Thats 20+ years of backwards compatibility.

Distributions also need to look at their own practices. They ask us to supply long term support but do not actually integrate the maintenance releases but instead cherry-pick just the security fixes. Maintenance is not just security fixes. That means that we keep seeing bug reports that need to be diagnosed about bugs we have fixed years ago. That really isn’t a good use of peoples time. Not ours, not the distributions maintainers nor the users time. Is there little wonder that we stop producing bug fixes releases for old version when the distributions don’t use them?

When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security. Simpler programs like Unbound have less code
and so less things to go wrong, need less patches, and are easier to
support for a longer period of time so they get supported for a longer
period of time. Also, Unbound's main purpose in life is as a caching
dns program. Nobody who runs a server on FreeBSD uses Unbound.
Ted

Post by John W. Blue
John
-----Original Message-----
Sent: Friday, July 17, 2020 12:57 PM
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

Post by Klaus Darilion
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.

Hmm I'm a bit late to this discussion but I will chime in with the others. The service always was called "named" pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book on the subject, it was called this before you were born and it was kind of the height of hubris for it to ever be named
bind9 in a software distro.
In fact, the ONLY reason that the name "bind9" was ever even coined at all was because the changes from bind8 both in the syntax of the config file and how the program operated they wanted to boot admins in the behind to get them to change their config files. It should have been put to bed as a name a long time ago, or named "bind version 9" like every other software program does with their versions.
So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it originally was!
Ted
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

Mark Andrews

2020-07-21 03:13:10 UTC

Just for the record here are the release dates for each maintenance series.

9.0.0 2000-09-16 (one off - marked not for production)
9.1.0 2001-01-18 - 9.1.3 2001-07-03 (6 months)
9.2.0 2001-11-25 - 9.2.9 2007-09-25 (5 years 10 months)
9.3.0 2004-09-22 - 9.3.6 2008-11-19 (4 years 2 months)
9.4.0 2007-02-23 - 9.4.3 2008-11-19 - 9.4-ESV-R5 2011-08-01 (4 years 6 months)
9.5.0 2008-05-29 - 9.5.2 2009-09-23 (1 year 3 months)
9.6.0 2008-12-23 - 9.6.3 2011-02-04 - 9.6-ESV-R11 2014-01-31 (5 years 2 months)
9.7.0 2010-02-16 - 9.7.7 2012-10-09 (2 years 8 months)
9.8.0 2011-03-01 - 9.8.8 2014-09-29 (3 years 6 months)
9.9.0 2012-02-29 - 9.9.13 2018-07-11 (6 years 4 months, ESV)
9.10.0 2014-04-30 - 9.10.8 2018-07-11 (4 years 3 months)
9.11.0 2016-10-04 - 9.11.21 2020-07-15 (Current Stable, ESV)
9.12.0 2018-01-23 - 9.12.4 2019-03-01 (1 year 2 months)
9.13.0 2018-05-25 - 9.13.7 2019-02-27 (development)
9.14.0 2019-03-22 - 9.14.12 2020-05-19 (1 year 2 months)
9.15.0 2020-03-06 - 9.15.8 2020-01-22 (development)
9.16.0 2020-03-06 - 9.16.5 2020-07-15 (Current Stable, (should be future ESV))
9.17.0 2020-03-18 - 9.17.3 2020-07-15 (current development)

ESV = Extended Support Version

Post by Mark Andrews

Post by John W. Blue
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for something called unwinding or whatever it is.

There where lots of things happening at the time. There was misinformation propagated to *BSD that BIND 9 going away much faster that any plans we had. BIND 10 (now defunct) hadn’t even reached feature parity with BIND 9 which was still being developed because the DNS protocol is still be developed.
As for support life times. BIND 9.17 will load most BIND 8.0 configurations. Thats 20+ years of backwards compatibility.
Distributions also need to look at their own practices. They ask us to supply long term support but do not actually integrate the maintenance releases but instead cherry-pick just the security fixes. Maintenance is not just security fixes. That means that we keep seeing bug reports that need to be diagnosed about bugs we have fixed years ago. That really isn’t a good use of peoples time. Not ours, not the distributions maintainers nor the users time. Is there little wonder that we stop producing bug fixes releases for old version when the distributions don’t use them?

Post by John W. Blue
John
-----Original Message-----
Sent: Friday, July 17, 2020 12:57 PM
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

Post by Klaus Darilion
Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you.

Hmm I'm a bit late to this discussion but I will chime in with the others. The service always was called "named" pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book on the subject, it was called this before you were born and it was kind of the height of hubris for it to ever be named
bind9 in a software distro.
In fact, the ONLY reason that the name "bind9" was ever even coined at all was because the changes from bind8 both in the syntax of the config file and how the program operated they wanted to boot admins in the behind to get them to change their config files. It should have been put to bed as a name a long time ago, or named "bind version 9" like every other software program does with their versions.
So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it originally was!
Ted
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

@lbutlr

2020-07-21 08:23:34 UTC

Post by tale
And for what it's worth, not all systems moved away from "named" to
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".

The service is always named, the package is bind. I stopped adding the 9 many years ago unless I need to specify a specific version like "bind nine dot eleven".

Post by tale
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to basically install it and forget about it, never run patches, never give
a fig about security.

Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.

I agree that anyone using a FreeBSD install as a server should be using bind, but I also agree it should not be the default install. You install bind when you figure out you need it, and not before.

--
Mickey and Mallory know the difference between right and wrong; the
just don't give a damn.

Reindl Harald

2020-07-20 17:53:14 UTC

Post by Ted Mittelstaedt

Post by John W. Blue
Speaking about things to be annoyed over ..
I am still ticked that FreeBSD dropped BIND from the distribution for
something called unwinding or whatever it is.

how has this anything to do with the fact that there is one named in
whatever version in your distribution?

it has also nothing to do with bind9 versus bind

it's a debian hobby to make such things like apache2 or bind9 where the
service is just httpd and named, no number and a completly different
name as debian is using

Post by Ted Mittelstaedt
When FreeBSD was used mostly for servers it wasn't a problem. But more
and more people are using it for desktop use where they want to
basically install it and forget about it, never run patches, never give
a fig about security. Simpler programs like Unbound have less code
and so less things to go wrong, need less patches, and are easier to
support for a longer period of time so they get supported for a longer
period of time. Also, Unbound's main purpose in life is as a caching
dns program. Nobody who runs a server on FreeBSD uses Unbound.

when i use a pure cache i run unbound and don't know why i wouldn't do
so on whatever OS which can run it

Mark Andrews

2020-07-21 12:37:53 UTC

Post by tale
And for what it's worth, not all systems moved away from "named" to
"bind9". I've been running FreeBSD for decades, and I can't remember
ever calling the service "bind9".

The service is always named, the package is bind. I stopped adding the 9 many years ago unless I need to specify a specific version like "bind nine dot eleven".

Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.

Anything that talks to the net is critical path from a security perspective.

Post by @lbutlr
I agree that anyone using a FreeBSD install as a server should be using bind, but I also agree it should not be the default install. You install bind when you figure out you need it, and not before.
--
Mickey and Mallory know the difference between right and wrong; the
just don't give a damn.
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

@lbutlr

2020-07-21 22:23:48 UTC

Post by Mark Andrews

Post by @lbutlr
Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.

Anything that talks to the net is critical path from a security perspective.

There are different levels of critical, and unbound is a lot further down that list that bind.

--
We are born naked, wet and hungry; then it's all downhill.

Mark Andrews

2020-07-21 23:28:37 UTC

Post by Mark Andrews

Post by @lbutlr
Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.

Anything that talks to the net is critical path from a security perspective.

There are different levels of critical, and unbound is a lot further down that list that bind.

I would beg to differ. From an exposure perspective they are identical. They both ask questions onto the network and both have to parse and process those answers. They both produce similar CVSS scores, which are a much more objective way of analysis the need to pay attention to a security issues. BIND and UNBOUND both have had CVSS scores of 7.5
for packets of death.

A packet of death that does nothing else has a CVS 3.0 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

CVSS, v3.0, a score of 0.0 receives a "None" rating; a 0.1-3.9 score gets a "Low" severity rating; a score of 4.0-6.9 is a "Medium" rating; score of 7.0-8.9 is a "High" rating; and a score of 9.0 - 10.0 is a "Critical" rating.

If it the fault leads to a potential remote compromise you get into the Critical range.

Post by @lbutlr
--
We are born naked, wet and hungry; then it's all downhill.
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

Ted Mittelstaedt

2020-07-23 04:28:17 UTC

Post by Mark Andrews
Distributions also need to look at their own practices. They ask us
to supply long term support but do not actually integrate the
maintenance releases but instead cherry-pick just the security fixes.
Maintenance is not just security fixes. That means that we keep
seeing bug reports that need to be diagnosed about bugs we have fixed
years ago. That really isn’t a good use of peoples time. Not ours,
not the distributions maintainers nor the users time. Is there
little wonder that we stop producing bug fixes releases for old
version when the distributions don’t use them?

Those kinds of bug reports need to be kicked back to the user with a
"refer to distro maintainer"

But truthfully you are proving my point. The simple fact is that bind
will compile WITHOUT using a FreeBSD port. Linux is 10 times worse
because they aren't even including the c compiler or development tools
anymore. But many "systemadmins" out there think they are Unix admins
yet are afraid to compile programs. They will go to the FreeBSD port or
the Linux precompiled apt-get stuff. The reason is more and more
non-technical people are getting their hands on this stuff.

This is a bit like the development of the automobile. When the Model T
came out it came with a toolbox and a big book that allowed the owner to
completely troubleshoot and fix anything that went wrong with the car.
But gradually as more and more people bought cars you had more people
who didn't know squat about cars buying them. So Ford stopped shipping
the manual and made it an extra cost item.

Nowadays Ford and Chevy don't even sell a manual at all anymore.
Instead you have to get an alldata subscription to get access to the
service manual. And if you stop paying the subscription you have no
more manual. But a running shop is always going to be paying a
subscription so it's not a problem for them. For the DIYers they
can get a 3 day alldatadiy subscription then spend 3 hours printing
every page of the manual but maybe 1 out of 10,000 car buyers ever
does this.

Microsoft ran into this problem and had to split windows into a server
and desktop version. Right after that happened "windows admins" who
knew the desktop only were fine. But today all the MS server
applications have to be controlled via the command line via powershell,
plus the server version of the OS is 4 times more expensive and both
these things tend to chase away the people who aren't system admin
types who are willing to get down and dirty and technical.

Linux did this as well although the "server versions" of the
distributions are horrendously lacking. FreeBSD really
should do this but they don't likely have enough people working on the
distro. So they make it so that the non-tech types can use it
and expect that the admin types know better.

None of these solutions are really solutions. The real solution would
be for the users to get more educated. But the majority of people don't
really care about an OS they just use it as a platform to run the
software that they do care about. Thus creating the means for gigantic
DDoS networks since none of them bother patching their OSes.

BIND chose the path of servicing the needs of the people who knew what
they were doing. Unbound went the other direction and chose the path
of servicing the non-technical users. There's more non-techs than
educated people so
sooner or later paths are going to diverge. It always makes me laugh to
read these flame wars from the non-techs who think that just because
their simple-and-not-configurable programs work for them on the
desktop that they should work on the server and the world should switch
to them. Whaah Whaah Whaah the real world is complicated, simplify it
for me or I'm gonna have a tantrum. We have one of those dunsels in the
White House in the USA right now.

The BIND developers should
forget about the non-techs and continue servicing the people who know
what they are doing and laugh also.

Ted

Michael De Roover

2020-07-23 04:59:31 UTC

Linux is 10 times worse because they aren't even including the c
compiler or development tools
anymore.

Every distribution I've laid my hands on so far has GCC packages and
most development packages affixed with either -dev or -devel (most of
the time).

But many "systemadmins" out there think they are Unix admins
yet are afraid to compile programs. They will go to the FreeBSD port or
the Linux precompiled apt-get stuff. The reason is more and more
non-technical people are getting their hands on this stuff.

I don't disagree with this but I also think there's more to it than
that. For me personally I avoid compiling from source when I can get
away with it - not because I can't run make - but simply because binary
packages are convenient. Having a package manager take care of updates
in the whole system is convenient. Having distribution maintainers that
say "okay we are going to go stable, bleeding edge or whatever with the
whole project" is useful when they can spend the time looking at the
upstream projects, and choose the most fitting software versions and
such to suit that goal. And when there's billions of machines running
very similar architectures, there is an argument to be made that making
every single one of them compile everything from source is rather
pointless. Why should every machine in existence be tasked with
CPU-intensive compilation workloads when a handful of dedicated
compilation servers can do exactly that, and a million times better?

--
Met vriendelijke groet / Best regards,
Michael De Roover

Ted Mittelstaedt

2020-07-23 05:19:18 UTC

Post by Michael De Roover

Linux is 10 times worse because they aren't even including the c
compiler or development tools
anymore.

Every distribution I've laid my hands on so far has GCC packages and
most development packages affixed with either -dev or -devel (most of
the time).

Well for starters there is no way for ME to validate that the compiled
software you built for me isn't busy running your Doom network server
behind my back. (do people still even run Doom servers?)

You are making an argument that is a desktop argument. That is, the
argument goes Those That Know Better Will Do It For You.

Also, I have had at least 5 Open Source programs over the years that
I found Really Useful to have that the authors decided they wanted to
"take commercial" or they had other religious conversions that made them
decide to go on a rampage and issue take down notices everywhere they
could find their source. One of those for example was when
Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start
charging
for software that created .gif files and the graphics community went
on a ballistic rampage jihad and destroyed every scrap of .gif code it
could find so as to force users to migrate to .png. I did not wish to
migrate to .png so I was very glad that I had saved all the old code,
safe from the fires of the religious zealots.

Lastly, the way I look at it is when I field a new server, if it cannot
recompile it's OS, kernel, make world, and all of it's applications from
source, then it's a piece of excrement that I do not want in service.

It is also a fact that I have had pre-production servers blow up on
"make worlds" In a few cases this was bad ram, in one case the server
was returned to the manufacturer under warranty. These are machines
that did not display any issues before the OS load. Do not ask me why
it was possible to install all the binaries for the OS and have it boot
with no problems yet blow chunks/blue screen/abend/take a dive into the
toilet/whatever your preferred term for crashing and burning is.

I don't generally run FreeBSD or Linux as a desktop OS, BTW so that
does affect my view of things.

So yes, there is definitely an argument in favor of compiling the
stuff at least on a server.

Ted

Michael De Roover

2020-07-23 06:12:32 UTC

Post by Ted Mittelstaedt
Well for starters there is no way for ME to validate that the compiled
software you built for me isn't busy running your Doom network server
behind my back. (do people still even run Doom servers?)

People would find out when an unnecessary service is started up though,
no? Especially with services, you can see those with netstat/ss right
away. Additionally, the distribution maintainers are (or at least should
be) the ones compiling it. It could be argued that by installing their
distribution, there is already a certain level of trust being given to
said maintainers.

For example I don't trust Manjaro's maintainers, since they screwed up
their TLS certificate renewal no less than 3 times. That's complete and
utter incompetence on their part. How they didn't already put certbot in
a cron job after the first time is beyond me. On the other hand, I have
started to get fond of Debian.. though also not entirely. But enough to
consider that their packages are probably just fine. I could also verify
this by compiling it myself and comparing the result. They publish their
downstream source code along with any modifications they made.

Post by Ted Mittelstaedt
You are making an argument that is a desktop argument. That is, the
argument goes Those That Know Better Will Do It For You.

Not quite, rather my goals for the system sufficiently align with those
of the distribution I end up going with on this or that system. And on a
server I don't like compiling from source for the same reason that I
wouldn't install and run a desktop environment on it. I consider it
unnecessary cruft. And keeping those packages up-to-date... I forgot to
manually update software I built from a git repository more often than
I'd like to admit. I also lost count.

With my internal BIND servers now running on Alpine (because super
lightweight), that blurs the lines a bit. With 9.14.12, they ship an EOL
version of BIND. And their stock configuration for it was pretty much
unusable anyway. Everything on that was replaced. Compiling from source
or sticking with what they provide, perhaps notifying Alpine's
maintainers that they should look into it? I don't know. But compiling
9.16 ESV there probably wouldn't be a bad idea. Certainly doable, but
not as convenient.

Post by Ted Mittelstaedt
Also, I have had at least 5 Open Source programs over the years that
I found Really Useful to have that the authors decided they wanted to
"take commercial" or they had other religious conversions that made them
decide to go on a rampage and issue take down notices everywhere they
could find their source. One of those for example was when
Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start
charging
for software that created .gif files and the graphics community went
on a ballistic rampage jihad and destroyed every scrap of .gif code it
could find so as to force users to migrate to .png. I did not wish to
migrate to .png so I was very glad that I had saved all the old code,
safe from the fires of the religious zealots.

That's an issue of licensing, it is super annoying, and having older
source code still available in those cases is indeed really useful. I
don't know how relevant this is to this discussion though (granted, can
we still pretend to be on-topic anyway?) given that this is more about
open source projects merely providing binary packages (with the source
available), rather than said project completely denying source code access.

Regarding the ballistic rampage... I can't help but think that this is
what's happening in BIND right now. Fortunately it was only a few days
worth of commits that dealt with.. that totally 100% necessary change of
nomenclature.

Post by Ted Mittelstaedt
Lastly, the way I look at it is when I field a new server, if it cannot
recompile it's OS, kernel, make world, and all of it's applications from
source, then it's a piece of excrement that I do not want in service.
It is also a fact that I have had pre-production servers blow up on
"make worlds" In a few cases this was bad ram, in one case the server
was returned to the manufacturer under warranty. These are machines
that did not display any issues before the OS load. Do not ask me why
it was possible to install all the binaries for the OS and have it boot
with no problems yet blow chunks/blue screen/abend/take a dive into the
toilet/whatever your preferred term for crashing and burning is.
I don't generally run FreeBSD or Linux as a desktop OS, BTW so that
does affect my view of things.
So yes, there is definitely an argument in favor of compiling the
stuff at least on a server.

Fair points. And I agree, having the option is absolutely something I
wouldn't want to give away for proprietary software either. But in all
the software I use (be it on workstations or servers, I run Linux on
both) I do have that option. It's just not as convenient and I certainly
wouldn't want every distro to turn into a Gentoo for increased merit or
reasons like that. If the distro makes compiling from source (be it
upstream or their downstream version) easy, either to compare or to
actually put it to use, all the better.

(My preferred term for for crashing and burning servers would probably
not be suitable for this list)

--
Met vriendelijke groet / Best regards,
Michael De Roover

Mauricio Tavares

2020-07-23 10:30:54 UTC

Bind is a poor choice for desktop use. Packages like unbound are much better for that sort of use, and it is fr less critical if those packages have security issues.

I was taught in kitty school "less critical if those packages
have security issues" is never a good argument. Just because
getting-into-a-desktop-and-then-using-it-as-launchpad-to-go-after-servers
is a traditional Windows attack vector does not mean Linux computers
are immune of that.

Fred Morris

2020-07-23 12:36:05 UTC

If you're running Alpine, you should know that it uses MUSL which has a
stub resolver which is/was lacking in some respects:
http://postfix.1071664.n5.nabble.com/Outgoing-DANE-not-working-tp105397p105420.html

Post by Michael De Roover
[...]
With my internal BIND servers now running on Alpine (because super
lightweight), that blurs the lines a bit.

--

Fred Morris

Fred Morris

2020-07-23 12:39:46 UTC

Perhaps slightly OT, but here's a company which has a whole business model
based on one nonobvious (?) reason to compile from source:
https://polyverse.com/

--

Fred Morris

Michael De Roover

2020-07-23 13:49:37 UTC

The idea is pretty interesting, seems like they provide a repository
with packages compiled with their own compiler that changes various
memory-related elements. It is true that memory is usually the culprit
behind security flaws.

According to their page at
https://polyverse.com/products/polymorphing-linux-security/ :

"Polymorphing takes source code and runs it through a polymorphic
compiler, changing register usage, function locations, import tables and
other targets. This produces individually unique binaries that are
semantically equivalent to the source. Polymorphing applies the compiler
to the totality of the Linux stack."

For this to work at all though, they'd have to provide all packages
simply as source code (why not use the distribution's own source
repositories?) and compile it on the target. But even then I think it's
more of a security by obscurity thing. Sure it makes it more difficult
to exploit a memory flaw by means of automated exploits and other such
scripts. But nothing stops you from taking the unmodified source code,
the binary and a disassembler to find out how exactly the resulting
binary has been changed / polymorphed. I'm not very familiar with
reverse engineering and disassemblers but I don't think there's much
more to it than that, at least to thwart this defense. All of it is
possible if an attacker can read, retrieve and execute a binary on the
affected server. The flaws are still there, only their memory locations
have changed. It would probably defend against script kiddies, but I
doubt it would keep out a determined attacker.

Personally I prefer Google's approach to this for Chromium. They
documented it at
https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
. Implementing programs in memory safe languages where possible is
something I believe to be a more solid long-term solution. Additionally
Google's Project Zero team is behind a lot of the security research and
disclosures. They audit the actual code instead, which I believe to be
far more suitable.

While the idea is valid to some extent (and could be worth it in highly
confidential environments), I wouldn't consider it worth compiling
everything from source for, with a nonstandard compiler no less. If
servers would just be updated more often and (security) bug fixes
actually make their way through to the distribution releases reliably,
we'd already go a long way I think. Of course there are also
configuration mistakes that could compromise a network component. From
what I've seen so far, this seems to be more often the case with those
leaked databases and whatnot.

Post by Fred Morris
Perhaps slightly OT, but here's a company which has a whole business
https://polyverse.com/
--
Fred Morris

--
Met vriendelijke groet / Best regards,
Michael De Roover

charlie derr

2020-07-23 14:44:43 UTC

Caveat: i'm far from an expert on compiling, linking, disassembling,
etc... (in fact i know *very* little about these domains), so it's
possible my comment/question below won't even really make sense.

Still, i'm not going to learn more without asking, so...

Post by Michael De Roover
The idea is pretty interesting, seems like they provide a repository
with packages compiled with their own compiler that changes various
memory-related elements. It is true that memory is usually the culprit
behind security flaws.
According to their page at
"Polymorphing takes source code and runs it through a polymorphic
compiler, changing register usage, function locations, import tables and
other targets. This produces individually unique binaries that are
semantically equivalent to the source. Polymorphing applies the compiler
to the totality of the Linux stack."
For this to work at all though, they'd have to provide all packages
simply as source code (why not use the distribution's own source
repositories?) and compile it on the target. But even then I think it's
more of a security by obscurity thing. Sure it makes it more difficult
to exploit a memory flaw by means of automated exploits and other such
scripts. But nothing stops you from taking the unmodified source code,
the binary and a disassembler to find out how exactly the resulting
binary has been changed / polymorphed.

While it would still *technically* be security by obscurity, it would
seem to me that there's some value to this approach because access to
the compiled binary wouldn't necessarily be easy to obtain (especially
if the sysadmin provisioning the system takes extra efforts to *not*
share it with anyone). Or am i missing something?

Post by Michael De Roover
I'm not very familiar with
reverse engineering and disassemblers but I don't think there's much
more to it than that, at least to thwart this defense. All of it is
possible if an attacker can read, retrieve and execute a binary on the
affected server. The flaws are still there, only their memory locations
have changed. It would probably defend against script kiddies, but I
doubt it would keep out a determined attacker.
Personally I prefer Google's approach to this for Chromium. They
documented it at
https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
. Implementing programs in memory safe languages where possible is
something I believe to be a more solid long-term solution. Additionally
Google's Project Zero team is behind a lot of the security research and
disclosures. They audit the actual code instead, which I believe to be
far more suitable.
While the idea is valid to some extent (and could be worth it in highly
confidential environments), I wouldn't consider it worth compiling
everything from source for, with a nonstandard compiler no less. If
servers would just be updated more often and (security) bug fixes
actually make their way through to the distribution releases reliably,
we'd already go a long way I think. Of course there are also
configuration mistakes that could compromise a network component. From
what I've seen so far, this seems to be more often the case with those
leaked databases and whatnot.

Thanks much for this fascinating discussion,
~c

Post by Michael De Roover

Post by Fred Morris
Perhaps slightly OT, but here's a company which has a whole business
https://polyverse.com/
--
Fred Morris

--
Charlie Derr Director, Instructional Technology 413-528-7344
https://www.simons-rock.edu Bard College at Simon's Rock
Encryption key: http://hope.simons-rock.edu/~cderr/
Personal writing: https://medium.com/@cderr Pronouns: he or they
Home landline: 860-435-1427

charlie derr

2020-07-23 14:56:02 UTC

Post by charlie derr
Caveat: i'm far from an expert on compiling, linking, disassembling,
etc... (in fact i know *very* little about these domains), so it's
possible my comment/question below won't even really make sense.
Still, i'm not going to learn more without asking, so...

Nevermind my previous question, obviously i didn't read carefully enough
(sonce their repo would expose the compiled binaries).

/back to lurk mode

~c

Fred Morris

2020-07-23 15:13:52 UTC

Post by charlie derr

Post by Michael De Roover
[...]
For this to work at all though, they'd have to provide all packages
simply as source code (why not use the distribution's own source
repositories?) and compile it on the target.

[...]
While it would still *technically* be security by obscurity, it would
seem to me that there's some value to this approach because access to
the compiled binary wouldn't necessarily be easy to obtain (especially
if the sysadmin provisioning the system takes extra efforts to *not*
share it with anyone). Or am i missing something?

They actually run a very large build farm in AWS, and they claim that all
binaries are made just for you. Basically you change your distro's package
repositories to theirs. Preventing people from examining the binaries in
order to craft working memory exploits which work across a large installed
base is exactly what they're aiming to prevent.

Disclosure: I've heckled their CTO in a friendly fashion for making better
idiots, but I paid for my own Old Fashioned.

--

Fred Morris

Ted Mittelstaedt

2020-07-23 18:22:50 UTC