Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2022-09-03T18:37:20+02:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/747Expired gpg key in OBS2022-09-03T18:37:20+02:00Vladimír Čunátvladimir.cunat@nic.czExpired gpg key in OBS.deb users of our [upstream repo](https://www.knot-resolver.cz/download/) can't update anymore (Debian, Ubuntu).
Message examples:
```
# apt update
[...]
W: GPG error: http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolve....deb users of our [upstream repo](https://www.knot-resolver.cz/download/) can't update anymore (Debian, Ubuntu).
Message examples:
```
# apt update
[...]
W: GPG error: http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_11 InRelease: The following signatures were invalid: EXPKEYSIG 74062DB36A1F4009 home:CZ-NIC OBS Project <home:CZ-NIC@build.opensuse.org>
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
```
The key:
```
pub rsa2048 2018-02-15 [SC] [expired: 2022-06-21]
45737F9C8BC3F3ED2791818274062DB36A1F4009
uid [ expired] home:CZ-NIC OBS Project <home:CZ-NIC@build.opensuse.org>
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/610migrate upstream repositories from OBS2024-01-19T17:08:29+01:00Tomas Krizekmigrate upstream repositories from OBSThe OBS infrastructure has some serious issues, some of which are security related.
The mirrors can get weirdly out of sync, which can cause a different file size / checksums in downloaded repository metadata (`Packages` file for debian...The OBS infrastructure has some serious issues, some of which are security related.
The mirrors can get weirdly out of sync, which can cause a different file size / checksums in downloaded repository metadata (`Packages` file for debian) and the downloaded package. This issue has been observed by our users.
The packages are also downloaded over http, because not all the mirrors support https. Users have complained about this on the [mailing list](https://lists.nic.cz/pipermail/knot-resolver-users/2019/000193.html).
Overall, OBS may be suitable for testing and automation, but the official upstream packages should be somewhere more reliable. I propose to use the same approach as [Knot DNS](https://www.knot-dns.cz/download/) to be more consistent.
Features we want:
- supported distributions
- Debian (9), 10+
- Ubuntu (16.04), 18.04, 20.04, latest rolling?
- Fedora - all supported
- CentOS 7, 8
- openSUSE - Leap 15.x
- Arch is a bonus
- supported architectures
- x86_64
- aarch64 ?
- armv7 ?
- control over build root dependencies (e.g. using a newer/older Knot DNS)
- possibility to use multiple repositories (latest, testing, ...)
- re-builds if distribution packages/dependencies change?
- non-public repositories for security releases for customers?Jakub RužičkaJakub Ružičkahttps://gitlab.nic.cz/knot/knot-resolver/-/issues/655create package for dnstap module2021-01-15T14:51:35+01:00Tomas Krizekcreate package for dnstap moduleSupport for `dnstap` module should be packaged. Using a separate package, such as `knot-resolver-module-dnstap` probably makes the most sense. It also needs to be mentioned in dnstap documentation that an extra package is needed.
Report...Support for `dnstap` module should be packaged. Using a separate package, such as `knot-resolver-module-dnstap` probably makes the most sense. It also needs to be mentioned in dnstap documentation that an extra package is needed.
Reported from: https://github.com/CZ-NIC/knot-resolver/issues/71Jakub RužičkaJakub Ružičkahttps://gitlab.nic.cz/knot/knot-resolver/-/issues/613packaging: sync with debian2020-09-24T15:25:29+02:00Jakub Ružičkapackaging: sync with debian[Debian packaging](https://salsa.debian.org/dns-team/knot-resolver/-/tree/debian/master/debian) has diverged greatly from [upstream packaging](distro/deb) to a point where the diff is scary big.
We need to sync packaging in both directi...[Debian packaging](https://salsa.debian.org/dns-team/knot-resolver/-/tree/debian/master/debian) has diverged greatly from [upstream packaging](distro/deb) to a point where the diff is scary big.
We need to sync packaging in both directions:
- [ ] merge useful debian changes into upstream
- [ ] merge useful upstream changes into debian
I'm able to submit debian salsa MRs but a debian developer still needs to review and merge all the changes - I haven't had much luck with that so far, so that's more of a social/political task and one more reason to start with `debian -> upstream` sync ¯\\\_(ツ)\_/¯Jakub RužičkaJakub Ružičkahttps://gitlab.nic.cz/knot/knot-resolver/-/issues/612unify packaging tests2022-10-03T16:48:49+02:00Tomas Krizekunify packaging testsCurrently, there are two different implementations of packaging tests:
- [distro/tests](https://gitlab.nic.cz/knot/knot-resolver/-/tree/master/distro/tests/ansible-roles/knot_resolver/tasks)
- depend on external repos (currently OBS)
...Currently, there are two different implementations of packaging tests:
- [distro/tests](https://gitlab.nic.cz/knot/knot-resolver/-/tree/master/distro/tests/ansible-roles/knot_resolver/tasks)
- depend on external repos (currently OBS)
- use VMs, because we need to test systemd integration
- are pretty much exactly what the user would use
- primarily test default config
- [tests/packaging](https://gitlab.nic.cz/knot/knot-resolver/-/tree/master/tests/packaging)
- use docker containers
- added in !892 and !947
- test if resolver starts up with given config
- can't detect certain type of failures (crash shortly after startup, e.g. due to TA update)
- test loading of optional modules
I think tests/packaging are redundant and they add additional maintenance burden (see my opinion in https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/947#note_154887). However, they do test that all supported modules can be loaded in config. This functionality should be moved and unified with distro/tests as additional test, so we don't have to maintain two separate implementations of these tests.Jakub RužičkaJakub Ružičkahttps://gitlab.nic.cz/knot/knot-resolver/-/issues/59464-bit ARM: our OBS packages2023-10-16T12:00:21+02:00Vladimír Čunátvladimir.cunat@nic.cz64-bit ARM: our OBS packagesAs uncovered in #593, there are still some issues. We'll most likely first fix them in our OBS packages and then try to fix in official Debian. This ticket shall track the progress.As uncovered in #593, there are still some issues. We'll most likely first fix them in our OBS packages and then try to fix in official Debian. This ticket shall track the progress.