Am 15.04.20 um 08:56 schrieb Reindl Harald:
>
>
> Am 15.04.20 um 08:51 schrieb Klaus Darilion:
>> Hello!
>>
>> What is the rationale of:
>>
>> bind9 (1:9.13.6-1) experimental; urgency=medium
>> ...
>> * Rename the init scripts to named to match the name of the daemon
>>
>>
>> Since years, Deb
> -Ursprüngliche Nachricht-
> Von: bind-users Im Auftrag von Reindl
> Harald
> Gesendet: Mittwoch, 15. April 2020 09:05
> An: bind-users@lists.isc.org
> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
> named?
>
>
>
> Am 15.04.20 um 08:56 schrieb Reindl Harald:
> >
> > 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 t
Am 15.04.20 um 09:08 schrieb Klaus Darilion:
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
>> impor
Am 15.04.20 um 09:09 schrieb 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"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 15 Apr 2020, Klaus Darilion wrote:
-Ursprüngliche Nachricht-
Von: bind-users Im Auftrag von Reindl
Harald
Gesendet: Mittwoch, 15. April 2020 09:05
An: bind-users@lists.isc.org
Betreff: Re: Debian/Ubuntu: Why was the service rename
On 4/15/2020 3:09 AM, Klaus Darilion wrote:
> 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 hav
Am 15.04.20 um 09:21 schrieb Kevin A. McGrail:
> On 4/15/2020 3:09 AM, Klaus Darilion wrote:
>> 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 ve
> -Ursprüngliche Nachricht-
> Von: bind-users Im Auftrag von Reindl
> Harald
> Gesendet: Mittwoch, 15. April 2020 09:17
> An: bind-users@lists.isc.org
> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
> named?
>
>
>
> Am 15.04.20 um 09:09 schrieb Klaus Darilion:
>
Am 15.04.20 um 09:42 schrieb Klaus Darilion:
>> -Ursprüngliche Nachricht-
>> Von: bind-users Im Auftrag von Reindl
>> Harald
>> Gesendet: Mittwoch, 15. April 2020 09:17
>> An: bind-users@lists.isc.org
>> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
>> named?
>>
>
> On 15 Apr 2020, at 09:05, Reindl Harald wrote:
>
> 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 [
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 brok
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
Am 15.04.20 um 10:08 schrieb Ondřej Surý:
> 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
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-
> Von: Ondřej Surý
> Gesendet: Mittwoch, 15. April 2020 10:15
> An: Klaus Darilion
> Cc: bind-users@lists.isc.org
> Betreff:
> Am 15.04.20 um 10:08 schrieb Ondřej Surý:
> > 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 le
On Wed 15/Apr/2020 10:15:09 +0200 Ondřej Surý wrote:
> 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
On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote:
> 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.
___
Am 15.04.20 um 14:17 schrieb Jim Popovitch via bind-users:
> On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote:
>> 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
On Wed, 2020-04-15 at 14:21 +0200, Reindl Harald wrote:
>
> Am 15.04.20 um 14:17 schrieb Jim Popovitch via bind-users:
> > On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote:
> > > Thanks for answer!
> > >
> > > So actually it is just a cosmetic change not addressing a real problem.
> > >
>
Hello All,
I'm currently working on DoH/DoT design - most specifically, the configuration
syntax that will be used to set up DoH/DoT. Since removing or modifying
options in named.conf is very hard I want it to be done properly - hence this
request for comments. The current design document is he
cosmetic config error
building 9.16.2, config options include
--disable-geoip support GeoIP2 geolocation ACLs if available
[default=yes]
(this^^ is confusing usage; do you DISABLE-geoip in order TO 'support GeoIP2
geolocation ACLs if available' ?
shouldn't t
Hi,
you are right this is a bit confusing, but you need to specify both:
--enable-geoip (as the feature independent of used libraries)
--with-maxmindsb (where to find the libraries)
Ondrej
--
Ondřej Surý — ISC
> On 15 Apr 2020, at 22:07, PGNet Dev wrote:
>
> cosmetic config error
>
> buildi
On 4/15/20 1:50 PM, Ondřej Surý wrote:
> you are right this is a bit confusing, but you need to specify both:
>
> --enable-geoip (as the feature independent of used libraries)
> --with-maxmindsb (where to find the libraries)
thx
i'd also suggest
- --with-maxmiddb
+ --with-libmaxmi
On 4/15/20 2:46 PM, PGNet Dev wrote:
> On 4/15/20 1:50 PM, Ondřej Surý wrote:
>> you are right this is a bit confusing, but you need to specify both:
>>
>> --enable-geoip (as the feature independent of used libraries)
>> --with-maxmindsb (where to find the libraries)
>
> thx
>
> i'd also suggest
On 4/15/20 8:15 AM, Ondřej Surý wrote:
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
Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to
dnssec-policy, and have couple questions, probably quite trivial...
We have signed zones with different key algorithms, now I want everything under
the same ecdsa256 policy. I guess when the key algorithm changes, example f
And yet, after updating Gemtrade.fi to dnssec-policy, ZSK and KSK both "13",
and updating the DS record at the .fi root, I still get:
(algorithm 13 not supportedsignature verification failed)
In Verisign DNSSEC verifier.
Lähettäjä: bind-users Puolesta Jukka Pakkanen
Lähetetty: 16. huhtikuuta
> On 16 Apr 2020, at 09:21, Jukka Pakkanen wrote:
>
> Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to
> dnssec-policy, and have couple questions, probably quite trivial…
>
> We have signed zones with different key algorithms, now I want everything
> under the same ecd
Well the tester doesn’t support algorithm 13. The red x’s should be cautions
as they aren’t failures (no working ds/dnskey pairs for supported algorithms
in use), but rather the zone should be treated as insecure by the tester.
Mark
> On 16 Apr 2020, at 09:28, Jukka Pakkanen wrote:
>
> And
30 matches
Mail list logo
