26 Čen
2015
26 Čen
'15
15:25
Hello everyone!
CZ.NIC Labs just released a final version of Knot DNS 2.0.
There are only a few changes since the release candidate. The synchronization
of zone file can be now disabled; knsupdate was improved to accept TSIG
algorithm in interactive mode; and some small bugs have been resolved.
I believe you are tuned to this channel and it makes a little sense to repeat
all the new features we put into 2.0 in details. Just to sum up the most
important things:
- Knot DNS 2.0 uses new configuration format based on YAML. The new format
adds zone templates, improves remotes and ACLs specification, and in general
makes the configuration more readable. You can convert your existing 1.6
configuration using the knot1to2 utility.
- We have a new DNSSEC backend. It is based on GnuTLS instead of OpenSSL. And
it contains basic support for KASP (Key And Signature Policy). At the
moment, it can generate initial zone signing keys and perform automatic ZSK
rollover.
For more details, please, take a look at the full change log, previous
release e-mails, documentation, or just ask.
We are looking forward to your feedback, feature requests, and even bug
reports. And thank you for using Knot DNS.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.0.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.0.0.tar.xz.asc
Best Regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.cz https://www.nic.cz
27 Čen
27 Čen
22:57
Hi Jan,
can you tell when Ubuntu (14.04 LTS) packages will be available?
Did anyone migrated from 1.6.3 to 2.0 yet? Any problems?
Regards
Volker
30 Čen
30 Čen
13:36
Hello Volker,
can you tell when Ubuntu (14.04 LTS) packages will be
available?
I guess it will take a a few days this time. Both for .deb and .rpm packages.
We are currently discussing how to maintain both the LTS version and 2.0 in
the repositories. And whether (and how) to handle migration of configuration
file.
Did anyone migrated from 1.6.3 to 2.0 yet? Any
problems?
I'm running nightly builds of pre-2.0 since December. It just works. What
about the others? :-)
Cheers,
Jan
13:38
Hi Volker,
you can try these:
https://launchpad.net/~cz.nic-labs/+archive/ubuntu/knot-dns-experimental
I will move those packages to main Knot DNS Ubuntu repository soon(ish). I have just
finished preparing new repository for Knot DNS LTS, so it might happen this week.
Cheers,
--
Ondřej Surý -- Chief Science Officer
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
From: "Jan Včelák"
<jan.vcelak(a)nic.cz>
To: knot-dns-users(a)lists.nic.cz
Sent: Tuesday, June 30, 2015 1:36:11 PM
Subject: Re: [knot-dns-users] Knot DNS 2.0.0 (final release)
Hello Volker,
can you tell when Ubuntu (14.04 LTS) packages
will be available?
I guess it will take a a few days this time. Both for .deb and .rpm packages.
We are currently discussing how to maintain both the LTS version and 2.0 in
the repositories. And whether (and how) to handle migration of configuration
file.
Did anyone migrated from 1.6.3 to 2.0 yet? Any
problems?
I'm running nightly builds of pre-2.0 since December. It just works. What
about the others? :-)
Cheers,
Jan
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
1 Čec
1 Čec
13:39
Hi Ondřej,
I was able to install the package. I just need to repair the knot.conf,
the automated conversion to the new format did not work. I found this
error:
remotes {
master0 {
address 178.63.159.122@53;
address 2a01:4f8:120:73aa::affe@53;
key TRANSFER;
}
}
got
remote:
- id: "master0"
address: "2a01:4f8:120:73aa::affe@53"
key: "transfer."
As you can see the IPv4 is no longer listed as master.
BTW: why has the new keyname a dot suffix? Does this mean something?
Regards,
Volker
Am 30.06.2015 13:38, schrieb Ondřej Surý:
Hi Volker,
you can try these:
https://launchpad.net/~cz.nic-labs/+archive/ubuntu/knot-dns-experimental
I will move those packages to main Knot DNS Ubuntu repository
soon(ish). I have just finished preparing new repository for Knot DNS
LTS, so it might happen this week.
Cheers,
--
Ondřej Surý -- Chief Science Officer
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
From: "Jan Včelák"
<jan.vcelak(a)nic.cz>
To: knot-dns-users(a)lists.nic.cz
Sent: Tuesday, June 30, 2015 1:36:11 PM
Subject: Re: [knot-dns-users] Knot DNS 2.0.0 (final release)
> Hello Volker,
>
>> can you tell when Ubuntu (14.04 LTS) packages will be available?
>
> I guess it will take a a few days this time. Both for .deb and .rpm
> packages.
> We are currently discussing how to maintain both the LTS version and
> 2.0 in
> the repositories. And whether (and how) to handle migration of
> configuration
> file.
>
>> Did anyone migrated from 1.6.3 to 2.0 yet? Any problems?
>
> I'm running nightly builds of pre-2.0 since December. It just works.
> What
> about the others? :-)
>
> Cheers,
>
> Jan
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
13:45
Hi Volker,
could you please fill that as an issue to our gitlab (gitlab.labs.nic.cz/labs/knot), so
it's not forgotten? Also could you attach scrubbed configuration files (we really
don't want your TSIG keys :)) before and after conversion??
Cheers,
Ondrej
--
Ondřej Surý -- Chief Science Officer
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
From: "Volker Janzen" <voja(a)voja.de>
To: knot-dns-users(a)lists.nic.cz
Cc: "Ondřej Surý" <ondrej.sury(a)nic.cz>
Sent: Wednesday, July 1, 2015 1:39:54 PM
Subject: Re: [knot-dns-users] Knot DNS 2.0.0 (final release)
Hi Ondřej,
I was able to install the package. I just need to repair the knot.conf,
the automated conversion to the new format did not work. I found this
error:
remotes {
master0 {
address 178.63.159.122@53;
address 2a01:4f8:120:73aa::affe@53;
key TRANSFER;
}
}
got
remote:
- id: "master0"
address: "2a01:4f8:120:73aa::affe@53"
key: "transfer."
As you can see the IPv4 is no longer listed as master.
BTW: why has the new keyname a dot suffix? Does this mean something?
Regards,
Volker
Am 30.06.2015 13:38, schrieb Ondřej Surý:
> Hi Volker,
>
> you can try these:
>
> https://launchpad.net/~cz.nic-labs/+archive/ubuntu/knot-dns-experimental
>
> I will move those packages to main Knot DNS Ubuntu repository
> soon(ish). I have just finished preparing new repository for Knot DNS
> LTS, so it might happen this week.
>
> Cheers,
> --
> Ondřej Surý -- Chief Science Officer
> --------------------------------------------
> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury@nic.cz https://nic.cz/
> --------------------------------------------
>
> ----- Original Message -----
>> From: "Jan Včelák" <jan.vcelak(a)nic.cz>
>> To: knot-dns-users(a)lists.nic.cz
>> Sent: Tuesday, June 30, 2015 1:36:11 PM
>> Subject: Re: [knot-dns-users] Knot DNS 2.0.0 (final release)
>
>> Hello Volker,
>>
>>> can you tell when Ubuntu (14.04 LTS) packages will be available?
>>
>> I guess it will take a a few days this time. Both for .deb and .rpm
>> packages.
>> We are currently discussing how to maintain both the LTS version and
>> 2.0 in
>> the repositories. And whether (and how) to handle migration of
>> configuration
>> file.
>>
>>> Did anyone migrated from 1.6.3 to 2.0 yet? Any problems?
>>
>> I'm running nightly builds of pre-2.0 since December. It just works.
>> What
>> about the others? :-)
>>
>> Cheers,
>>
>> Jan
>> _______________________________________________
>> knot-dns-users mailing list
>> knot-dns-users(a)lists.nic.cz
>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
13:59
On 01/07/15 13:39, Volker Janzen wrote:
Hi Volker,
I was able to install the package. I just need to
repair the knot.conf,
the automated conversion to the new format did not work. I found this
error:
remotes {
master0 {
address 178.63.159.122@53;
address 2a01:4f8:120:73aa::affe@53;
key TRANSFER;
}
}
got
remote:
- id: "master0"
address: "2a01:4f8:120:73aa::affe@53"
key: "transfer."
I was always under the impression that the Knot 1.x config format only
allowed one IP address per remote definition. In fact, this is the
reason I have remotes defined thus:
remotes {
master0-v4 {
address IPv4;
key KEY;
}
master0-v6 {
address IPv6;
key KEY;
}
}
And then I use the "groups" directive to group these related masters
together:
groups {
master0 { master0-v4, master0-v6 }
}
Finally, I can use the "master0" name in the zone config to tell Knot
which masters to transfer from.
This is a rather cumbersome and convoluted way to define remotes in Knot
1.x, but it works for us. I am glad that the version 2 config format has
made this easy.
BTW: why has the new keyname a dot suffix? Does this
mean something?
A key name is just a DNS label. So it works the same with or without the
final dot. The case of the key name also does not matter. The knot1to2
utility is just lowercasing the name and canonicalising it with a final
dot. It will just continue to work.
Regards,
Anand Buddhdev
RIPE NCC
14:39
Hi Anand,
I was always under the impression that the Knot 1.x
config format only
allowed one IP address per remote definition. In fact, this is the
reason I have remotes defined thus:
it is possible that my configuration was not correct. I started using
knot a few weeks ago. As of using dualstack and having already updated
the server I'm not able to see, if knot would have listened to the IPv4
notifies. Seeing only IPv6 log entries.
@Ondrej: do you know if there was only one adress intended? There was no
warning about a configuration error, but this might explain why only one
IP made it to the v2 config format.
A key name is just a DNS label. So it works the same
with or without
the
final dot. The case of the key name also does not matter. The knot1to2
utility is just lowercasing the name and canonicalising it with a final
dot. It will just continue to work.
Okay I see. I just noticed this as one of the changes to the config
file.
Regards,
Volker
2 Čec
2 Čec
10:01
Hello Volker,
On Wednesday, July 01, 2015 02:39:24 PM Volker Janzen wrote:
Hi Anand,
Yes, this is really true. Knot 1.x supports only one address per remote.
And looking into the source code... the last address specified takes all. And
there is no warning. :-/
Jan
I was always under the impression that the Knot
1.x config format only
allowed one IP address per remote definition. In fact, this is the
reason I have remotes defined thus:
it is
possible that my configuration was not correct. I started using
knot a few weeks ago. As of using dualstack and having already updated
the server I'm not able to see, if knot would have listened to the IPv4
notifies. Seeing only IPv6 log entries.
@Ondrej: do you know if there was only one adress intended? There was no
warning about a configuration error, but this might explain why only one
IP made it to the v2 config format.
28 Čen
28 Čen
1:04
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 26/06/15 15:25, Jan Včelák wrote:
Hello everyone!
Hi Jan!
CZ.NIC Labs just released a final version of Knot DNS
2.0.
Yay!! Thank you very much for this release. My experiences with it so fa
r:
1. It builds properly under CentOS 6, with the caveat that one has to
find "gnutls3" and "nettle" packages from somewhere, because
they're
not in EPEL 6. For the time being, I'm using packages from:
https://copr.fedoraproject.org/coprs/jvcelak/gnutls3/
It would be good if gnutls were officially added to EPEL 6.
2. I like the new YAML config file format. My one slight complaint is
that you've chosen to implement a subset of YAML, so it has taken away
some of the usefulness of this format. For example, I can do:
listen: [ addr1, addr2 ]
but not:
listen:
- addr1
- addr2
In YAML those two are equivalent, but Knot's parser only accepts the
first form. Is there any reason for not just reading the full YAML forma
t?
3. I really, really like the template concept :)
4. In the template definition, %s translates to the zone name, with
the exception of the root zone. If I use the default for the "file"
parameter, then I get file names like:
zone1.zone
zone2.zone
but:
..zone
It tickles the purist in me, but it's not really a problem.
5. I haven't loaded all our zones in it yet, but it appears to be
running just fine on our test server with a subset of zones.
6. I'm trying to figure out whether RPM can tell me it's upgrading
from 1.x to 2.x, so that I can trigger the knot1to2 utility on 1.x
config files. But I don't yet know how to get this info from RPM.
7. Talking about the knot1to2 utility, I have a suggestion. The
current way it works, by taking an input file and an output file, it's
not idempotent. Let's say I write a post-install script to invoke
knot1to2 during a package upgrade, then when upgrading the first time
from 1.x to 2.0.0, it will work. Of course, I would probably want to
keep the post-install script in the 2.x series package. But now,
upgrading from 2.0.0, to say 2.0.1, would probably make it throw
errors if the config file is already in the v2 format.
It might be better if knot1to2 works like this:
knot1to2 <config>
Now, if config is v1, then it should rename it to config.v1, and then
create config in v2 format. However, if it is already v2 format, then
it should do nothing and just exit silently. This way, I can keep
knot1to2 in the post-install script of the package, and it would not
throw errors. Is it too late to change this behaviour?
Regards,
Anand
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVjyvuAAoJEBXgoyUMySoFYPYP/jbnf7bBTUDy+Zow6vuwYgjB
aUz9GCGHx8M7JkVsEuoVKY8Ab4tTiNzRwLcaP94ObgbamuyKdMC3DNbBxBYq8CB2
THiazD8Xp+KH3F6vxU5JenJWC6XHZ6kyloYstk48TfoSN5gwPKMfg8PoyrB915MD
aezvQ5mInNcEEjcBehxcFUoIlOFcNhrGG/xuVPNBKYDF7Oh8Z2q/afWQE0FlzbGa
xWIun1vzWyzNlE8FyK79hOvjG0Xda5aFO2rbxr/oXwiuyrRA5keXiSI+/pFrsB9X
5HJQ8j+L8uhQEQK2MmeGkTHDuDCQBvWmiluqYlT5AzmhQNVclsLoIxys8jvZaP87
6AKpZMXiZS9HKMM0LGsWc7VzKjxpn5s1yhtusmM6B5Ek2qNHP0K/EmVQGaBV9ZZ0
ruOFwBkbVJZOjk4O6rnc9oiD3tH3caECINUxT/GnDiR35Bojkcwdq9lY2TXxhalg
35lejP33wR3le5NoIUSatmRJhk8RcCJU8r5ieGDZrIAtqk07QpXQlK0fOvxFs3q4
4uqCEWAotIBDYJQ0brdcGvqGfJhyvpbYuDX6XicsZ/eS05Dww0sKJnrM74syaG4U
xO70KudB1Cp1WPFc7ud7vM1evzlXJz+P5SkKvt+eCnApEfKIgkiQLdgkxRhhuTVM
tvF7UVOmYzRRLiErSSTb
=thMp
-----END PGP SIGNATURE-----
11:38
Hi Anand,
On 2015-06-28 01:04, Anand Buddhdev wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 26/06/15 15:25, Jan Včelák wrote:
The reason is the YAML format is quite complex so I didn't manage to
implement
some features yet.
On the other hand, you can use nonYAML variant:
listen: addr1
listen: addr2
This works for all multivalued items.
Hello everyone!
Hi Jan!
CZ.NIC Labs just released a final version of Knot
DNS 2.0.
Yay!! Thank you very much for this release. My experiences with it so
fa
r:
1. It builds properly under CentOS 6, with the caveat that one has to
find "gnutls3" and "nettle" packages from somewhere, because
they're
not in EPEL 6. For the time being, I'm using packages from:
https://copr.fedoraproject.org/coprs/jvcelak/gnutls3/
It would be good if gnutls were officially added to EPEL 6.
2. I like the new YAML config file format. My one slight complaint is
that you've chosen to implement a subset of YAML, so it has taken away
some of the usefulness of this format. For example, I can do:
listen: [ addr1, addr2 ]
but not:
listen:
- addr1
- addr2
In YAML those two are equivalent, but Knot's parser only accepts the
first form. Is there any reason for not just reading the full YAML
forma
t?
3. I really, really like the template concept :)
+1
4. In the template definition, %s translates to the
zone name, with
the exception of the root zone. If I use the default for the "file"
parameter, then I get file names like:
zone1.zone
zone2.zone
but:
..zone
It tickles the purist in me, but it's not really a problem.
Yes, we already discussed this case but without a better solution.
I think, the root zone use case requires special care (explicit
zonefile specification).
5. I haven't loaded all our zones in it yet, but
it appears to be
running just fine on our test server with a subset of zones.
6. I'm trying to figure out whether RPM can tell me it's upgrading
from 1.x to 2.x, so that I can trigger the knot1to2 utility on 1.x
config files. But I don't yet know how to get this info from RPM.
7. Talking about the knot1to2 utility, I have a suggestion. The
current way it works, by taking an input file and an output file, it's
not idempotent. Let's say I write a post-install script to invoke
knot1to2 during a package upgrade, then when upgrading the first time
from 1.x to 2.0.0, it will work. Of course, I would probably want to
keep the post-install script in the 2.x series package. But now,
upgrading from 2.0.0, to say 2.0.1, would probably make it throw
errors if the config file is already in the v2 format.
It might be better if knot1to2 works like this:
knot1to2 <config>
Now, if config is v1, then it should rename it to config.v1, and then
create config in v2 format. However, if it is already v2 format, then
it should do nothing and just exit silently. This way, I can keep
knot1to2 in the post-install script of the package, and it would not
throw errors. Is it too late to change this behaviour?
Ok, we will think it over.
Thanks,
Dan
Regards,
Anand
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVjyvuAAoJEBXgoyUMySoFYPYP/jbnf7bBTUDy+Zow6vuwYgjB
aUz9GCGHx8M7JkVsEuoVKY8Ab4tTiNzRwLcaP94ObgbamuyKdMC3DNbBxBYq8CB2
THiazD8Xp+KH3F6vxU5JenJWC6XHZ6kyloYstk48TfoSN5gwPKMfg8PoyrB915MD
aezvQ5mInNcEEjcBehxcFUoIlOFcNhrGG/xuVPNBKYDF7Oh8Z2q/afWQE0FlzbGa
xWIun1vzWyzNlE8FyK79hOvjG0Xda5aFO2rbxr/oXwiuyrRA5keXiSI+/pFrsB9X
5HJQ8j+L8uhQEQK2MmeGkTHDuDCQBvWmiluqYlT5AzmhQNVclsLoIxys8jvZaP87
6AKpZMXiZS9HKMM0LGsWc7VzKjxpn5s1yhtusmM6B5Ek2qNHP0K/EmVQGaBV9ZZ0
ruOFwBkbVJZOjk4O6rnc9oiD3tH3caECINUxT/GnDiR35Bojkcwdq9lY2TXxhalg
35lejP33wR3le5NoIUSatmRJhk8RcCJU8r5ieGDZrIAtqk07QpXQlK0fOvxFs3q4
4uqCEWAotIBDYJQ0brdcGvqGfJhyvpbYuDX6XicsZ/eS05Dww0sKJnrM74syaG4U
xO70KudB1Cp1WPFc7ud7vM1evzlXJz+P5SkKvt+eCnApEfKIgkiQLdgkxRhhuTVM
tvF7UVOmYzRRLiErSSTb
=thMp
-----END PGP SIGNATURE-----
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users 
30 Čen
30 Čen
13:06
Dne 28.6.2015 v 01:04 Anand Buddhdev napsal(a):
4. In the template definition, %s translates to the
zone name, with
the exception of the root zone.
Hi all,
I have not yet tried the templates but I'm concerned about handling of
BCP 20 classless reverse zones like 192/26.2.0.192.in-addr.arpa
What happens if the zone name like this translates to an invalid file
name? Our current practice substitutes the slash with dash in file
names, but a proper solution inside the DNS server would be highly
appreciated :)
--
Ondřej Caletka
13:59
Hello Ondřej,
On Tuesday, June 30, 2015 01:06:19 PM Ondřej Caletka wrote:
I have not yet tried the templates but I'm
concerned about handling of
BCP 20 classless reverse zones like 192/26.2.0.192.in-addr.arpa
What happens if the zone name like this translates to an invalid file
name? Our current practice substitutes the slash with dash in file
names, but a proper solution inside the DNS server would be highly
appreciated :)
The slashes will be replaced by underscores. This was happening in 1.6 as well
if you haven't specified the zone path.
And any other characters should not be a problem on a modern file system. The
only problem could be the root zone which is translated to '.'. So if you are
hosting the root zone, don't rely on automatics. :-)
Cheers,
Jan
16:05
Dne 30.6.2015 v 13:59 Jan Včelák napsal(a):
The slashes will be replaced by underscores. This was
happening in 1.6 as well
if you haven't specified the zone path.
Thank you, Jan, I haven't noticed that yet. It's always good to know
that the feature you just invented is actually already implemented :D
--
Ondra
19:22
Ondřej Caletka wrote:
Dne 28.6.2015 v 01:04 Anand Buddhdev napsal(a):
You mean BCP 20 §4, right? :-)
The second scheme described in BCP 20 §5.2 is quite a bit nicer IMO if
you have a large number of small classless blocks to maintain -- on the
receiving side, you can maintain PTRs from many separate blocks in a
single zone. (And because there are no delegations from the provider to
the customer, there's no NS RRset to be synchronized.)
Unfortunately quite a few providers have reverse DNS provisioning
systems that can only do the §4 scheme.
--
Robert Edmonds
edmonds(a)debian.org
4. In the template definition, %s translates to
the zone name, with
the exception of the root zone.
Hi all,
I have not yet tried the templates but I'm concerned about handling of
BCP 20 classless reverse zones like 192/26.2.0.192.in-addr.arpa
13:49
Hi Anand!
Yay!! Thank you very much for this release. My
experiences with it so
You are very welcome. :-) We are also glad that the release is finally out.
1. It builds properly under CentOS 6, with the caveat
that one has to
find "gnutls3" and "nettle" packages from somewhere, because
they're
not in EPEL 6. For the time being, I'm using packages from:
https://copr.fedoraproject.org/coprs/jvcelak/gnutls3/
It would be good if gnutls were officially added to EPEL 6.
I need to say that the gnutls3 package in COPR is a based on some at that time
up-to-date Fedora 21 package. But it is not maintained. It might contain some
bugs (security?). I really don't know.
I'm working on getting the gnutls3 package in official EPEL repositories.
Please, give me a few days (weeks?).
3. I really, really like the template concept :)
I really love to hear that. So simple and so powerful! :-) I like it as well.
6. I'm trying to figure out whether RPM can tell
me it's upgrading
from 1.x to 2.x, so that I can trigger the knot1to2 utility on 1.x
config files. But I don't yet know how to get this info from RPM.
I was also wondering about this. It's probably not possible because the RPM
allows installation of multiple packages with the same name (e.g., kernel and
multilib packages). It won't tell you which package is being replaced.
The only sane way which comes to my mind is to call "knotc checkconf".
7. Talking about the knot1to2 utility, I have a
suggestion. ...
... Is it too late to change this behaviour?
It's never late!
Regards,
Jan
3229
days inactive
3235
days old
15 comments
7 participants
participants (7)
-
Anand Buddhdev -
daniel.salzman＠nic.cz -
Jan Včelák -
Ondřej Caletka -
Ondřej Surý -
Robert Edmonds -
Volker Janzen