These are chat archives for CZ-NIC/knot-resolver

21st
Feb 2018
jrun
@257
Feb 21 2018 16:47
Feb 21 11:39:50 asusp7p55lx kresd[27678]: /usr/lib/kdns_modules/hints.so: undefined symbol: engine_hint_root_file
i see that there was a discussion about this on the gitter when building and running on fedora but not sure if it's related here.
dunno if it's related but there is something unusual about building knot-resolver; PREFIX passed in compile phase is not honnered in install phase.
Vladimír Čunát
@vcunat
Feb 21 2018 16:49
You need to pass the same PREFIX to both phases.
It's just makefiles, it doesn't save settings somewhere :-)
jrun
@257
Feb 21 2018 16:51
as a work around i'm passing PREFIX twice although that doesn't solve the prblem with LIBDIR which unlike ETCDIR and MODULEDIR is not put to gether in the initial Makefile.
Vladimír Čunát
@vcunat
Feb 21 2018 16:52
Assuming you have exactly same kresd and libkres version, what version gives this problem?
(the missing symbol)
jrun
@257
Feb 21 2018 16:54
2.1.0
vcunat: not sure about the libkres actually. is that from knot?
let me check
Vladimír Čunát
@vcunat
Feb 21 2018 16:54
No, from knot-resolver itself.
jrun
@257
Feb 21 2018 16:54
2.6.4
2.6.4 is the knot version, nvm.
Vladimír Čunát
@vcunat
Feb 21 2018 16:55
But this is actually about hints.so and kresd. These problems should be gone on 2.1.0, if both are from this version.
jrun
@257
Feb 21 2018 16:57
vcunat: they are from the same version. would building off the git help? i guess i have to anyway for any possible fix, i'm assuming it's a bug...
Vladimír Čunát
@vcunat
Feb 21 2018 17:02
We had this exact bug in 1.5.2 and 2.0.0, but resolved it in 1.5.3 and 2.1.0 (couldn't reproduce it anymore).
What's your system? Do you pass any CFLAGS, LDFLAGS, etc?
jrun
@257
Feb 21 2018 17:04
gentoo, wait for the ebuild post which should be easy to read (shell like) and i will be here to explain if there is any need for it.
i'm just rewritten to build off the tags on github.
Vladimír Čunát
@vcunat
Feb 21 2018 17:05
OK, I think I can still read ebuilds.
You can test the presence of the symbol even without running, via
$ nm -D path/to/kresd | grep engine_hint_root_file
000000000000a980 T engine_hint_root_file
nm finds not hint_root actually
or wait...
sorry wait.
yeah, that symbol is not there
this is the correct ebuild, it builds off v2.1.0 or whatever the actuall ebuild is called:
jrun
@257
Feb 21 2018 17:12
here is the list of files installed:
and libkres.pc:
Vladimír Čunát
@vcunat
Feb 21 2018 17:15
I would certainly feel safer if the same set of variables was passed to both build an installation. It's enough to have them as environment variables, as make picks them automatically.
jrun
@257
Feb 21 2018 17:17
vcunat: i'm trying without ${EPREFIX} at the build phase, is that what you mean?
vcunat: and still the same problem.
hmm, wait. i forgot about LDFLAGS at install phase.
Vladimír Čunát
@vcunat
Feb 21 2018 17:19
Well, that point was unrelated to the missing symbol, really.
The toolchain is recent gcc, gnu ld, and some unusual system-wide CFLAGS/LDFLAGS?
jrun
@257
Feb 21 2018 17:22
gcc: [1] x86_64-pc-linux-gnu-6.4.0 *
binutils: [1] x86_64-pc-linux-gnu-2.29.1 *
CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"
Vladimír Čunát
@vcunat
Feb 21 2018 17:23
And some hardening flags, as I read.
But that's all fairly standard.
jrun
@257
Feb 21 2018 17:23
not sure, i don't think so in fact.
where did you see them?
Vladimír Čunát
@vcunat
Feb 21 2018 17:24
It's written in the ebuild :-)
What's the output of cc --version ?
jrun
@257
Feb 21 2018 17:25
oh, that can be set via USE flags. it's not set on my system.
Vladimír Čunát
@vcunat
Feb 21 2018 17:26
Ah, right got it :-D
You may apply something like
--- a/platform.mk
+++ b/platform.mk
@@ -55,7 +55,7 @@ else
                ifeq ($(UNAME),Linux)
                        LDFLAGS += -ldl
                endif
-               ifeq (GCC,$(shell $(CC) --version | grep -q '\<GCC\>' && echo GCC))
+               ifeq (GCC,$(shell $(CC) --version | grep -q '\<gcc\>' && echo GCC))
                        # Otherwise Fedora is making kresd symbols inaccessible for modules.
                        # Clang doesn't support this flag, so we hackily detect gcc.
                        BUILD_CFLAGS += -rdynamic
Or just add -rdynamic to CFLAGS.
I was being obtuse this evening.
I suppose case-insensitive match for "gcc" word will do it. Each platform has this string different, apparently, and so far I haven't found a better way of recognizing gcc from e.g. clang.
jrun
@257
Feb 21 2018 17:39
hmm, not getting this:
not sure if it's related.
i didn't use your patch, yet. i'm appending cflags conditionally, i.e. if cc supports it.
Vladimír Čunát
@vcunat
Feb 21 2018 17:40
And the file is missing?
jrun
@257
Feb 21 2018 17:40
nope
Vladimír Čunát
@vcunat
Feb 21 2018 17:40
Is it accessible by the user+group running kresd?
jrun
@257
Feb 21 2018 17:41
hmm, permission problem i think
-rw-r----- 1 root root 3.3K Feb 21 12:37 /etc/knot-resolver/root.hints
-rw-r--r-- 1 root root 563 Feb 21 12:43 /etc/knot-resolver/root.keys
still not go
Vladimír Čunát
@vcunat
Feb 21 2018 17:44
Hmm, our makefile is installing etc files with 0640. I have no clue why.
jrun
@257
Feb 21 2018 17:45
i actully cp'ed it from /var/lib/knot-resolver/root.keys into /etc/knot-resolver
it's installing 0644, i don't know about the first case.
Vladimír Čunát
@vcunat
Feb 21 2018 17:46
root.keys would better be writable by kresd
That's important for rfc5011 updates, unless you update the file by package manager for example.
jrun
@257
Feb 21 2018 17:47
still no go:
-rw-r--r-- 1 kresd kresd 563 Feb 21 12:43 /etc/knot-resolver/root.keys
Vladimír Čunát
@vcunat
Feb 21 2018 17:49
and ls -ld /etc/knot-resolver ?
jrun
@257
Feb 21 2018 17:52
drwxr-xr-x 1 kresd kresd 244 Feb 21 12:48 /etc/knot-resolver
drwxr-xr-x 1 root root 2752 Feb 21 12:42 /etc
Vladimír Čunát
@vcunat
Feb 21 2018 17:53
That seems OK. It still can't read the file?
BTW, the original message is about root.hints, not root.keys.
jrun
@257
Feb 21 2018 17:55
vcunat: good catch.
thanks.
now, i have couple of questions. first, is there a way to warm-up the cache for prefetch? this is for both personal and isp usage.
Vladimír Čunát
@vcunat
Feb 21 2018 18:00
The cache is persistent across restarts.
You may simply send particular queries to it to warm it up :-)
We're currently working on a way to keep the whole root zone warm all the time, but that's probably not what you have in mind.
jrun
@257
Feb 21 2018 18:02
we would like to keep the cache warm until say 02:00 AM. i.e. any record already looked up, since say 9:00 AM, should be prefetched at %1 percent of it's ttl expiring. is that possible?
Though for now implementation of this is fairly simple.
BTW, I see some issues in the ebuild, in case you e.g. intend to put it into the portage or something.
jrun
@257
Feb 21 2018 18:04
vcunat: that kinda looks like what bind's named does, it seems to me. in the sense that it won't prefetch the record if there is no query and it will let it die. is that correct?
Vladimír Čunát
@vcunat
Feb 21 2018 18:04
There are two parts.
First is what you just wrote.
And second is learning patterns and trying to predict what might be asked.
These two corresponds to the first two paragraphs in the docs.
oops!
i wanted to highlight the when is that sentence.
Vladimír Čunát
@vcunat
Feb 21 2018 18:09
The prediction parts refreshes records by itself - if you regularly need some record a lot, it will find this pattern and refresh the record by itself just before the predicted period.
jrun
@257
Feb 21 2018 18:09
what if they're not used? i want them to be prefetched if they were queried the same day after 9:00 AM. is that possible?
Vladimír Čunát
@vcunat
Feb 21 2018 18:09
Yes, that's what it does.
It should spot the pattern by itself.
But you can also put a timer into your config that does it explicitly.
jrun
@257
Feb 21 2018 18:11
is that what period is for?
or is that window?
Vladimír Čunát
@vcunat
Feb 21 2018 18:13
The time is sliced into "window"-minute segments.
And it tracks the last "period" segments.
So you probably want the product to give exactly 24h.
jrun
@257
Feb 21 2018 18:19
vcunat: what's predict.layer? i'm not well-versed in lua, sorry.
perdict.layer seems to update the qyr's in qyrs if that they have EXPIRING flag.
Vladimír Čunát
@vcunat
Feb 21 2018 18:23
These aren't about lua but about this particular project.
The part you read is about the first paragraph from docs.
Then there's timer harvesting what stats module gathered as frequent queries, and the prediction is done on that (second paragraph of docs).
jrun
@257
Feb 21 2018 18:39
vcunat: what are the problems with the ebuild?
vcunat: and is it possible to do rpz for personal use?
Vladimír Čunát
@vcunat
Feb 21 2018 18:40
There is some basic rpz format support.
jrun
@257
Feb 21 2018 18:40
never mind the rpz, i found it under policy actually
Vladimír Čunát
@vcunat
Feb 21 2018 18:40
Yes, that's it. But it's very limited.
  • use flags: memcached and redis support is dropped for now, and go doesn't really do anything
(dropped since 2.0.0, but weren't really performant anyway)
  • rdepend nitpicks: luasocket and luasec are optional and not needed for basic usage, but they're relatively small anyway
Vladimír Čunát
@vcunat
Feb 21 2018 18:46
You might want to optionally support e.g. systemd, allowing to run completely without privileges.
And 2.1.0 needs knot >= 2.6.4
(not strictly, but the Makefile checks that and won't compile otherwise)
Dependencies like lmdb and gnutls are pulled by knot, so you might be OK not specifying them explicitly. I'm not sure what's the ebuild policy about that.
That's all I can immediately see about it.
jrun
@257
Feb 21 2018 18:53
vcunat: am not doing the optional systemd? that's actually important to me.
btw, it would be nice if makefile also installed systemd units and man pages.
Vladimír Čunát
@vcunat
Feb 21 2018 18:54
It needs libsystemd.
That's detected by pkg-config. I can't see it in explicit dependencies, but perhaps it's OK that you get the support iff you have systemd...
kresd.8 should be installed by default.
jrun
@257
Feb 21 2018 18:55
i think systemd on gentoo installs the libsystemd by default. or at least it does it on systmed profile.
Vladimír Čunát
@vcunat
Feb 21 2018 18:56
Yes, surely it does. You'd lose the support if you switched init systems and didn't recompile kresd afterwards, but IIRC fixing by rebuilding is standard thing on Gentoo.
Systemd units aren't installed by default, because each distribution wants this a different way, so they better explicitly copy them (and adapt them if need be).
Consequently, kresd.systemd.7 suffers the same fate.
jrun
@257
Feb 21 2018 18:58
i had kresd.systemd.7 in mind actually.
vcunat: what's the reason for 2 different users, kresd and knot-resolver?
Vladimír Čunát
@vcunat
Feb 21 2018 19:00
We don't want two users.
jrun
@257
Feb 21 2018 19:01
in systemd units i think knot-resolver is used.
Vladimír Čunát
@vcunat
Feb 21 2018 19:01
Since 2.0.0 we should be consistently using knot-resolver user.
But before 2.0.0 it was often kresd, depending on distribution.
There also used to be /etc/kresd
jrun
@257
Feb 21 2018 19:03
kresd[17752]: [system] bind to '127.0.0.1@53' Permission denied
Vladimír Čunát
@vcunat
Feb 21 2018 19:04
Are you sure it was compiled with systemd support? It's shown in the log as [yes] systemd (daemon).
(pkgconfig file might be missing)
jrun
@257
Feb 21 2018 19:06
no it wasn't, you're right.
i just added systemd hooks.
vcunat: what's the release worflow in regards to git repo's tags?
jrun
@257
Feb 21 2018 19:11
i want my ebuild to just clone a shallow copy of the release tag, if possible.
Vladimír Čunát
@vcunat
Feb 21 2018 19:12
We tag on release. Yes, that's sufficient, though you will need a submodule.
jrun
@257
Feb 21 2018 19:29
vcunat: would it be possible for you to tag the last couple commits, like permission correction and so on?
jrun
@257
Feb 21 2018 19:37
and is there a way to hook up to a running instance?
jrun
@257
Feb 21 2018 20:01
hmm, i'm getting this:
cache.get("google.com")
error: Function not implementedcache.get("google.com")
error: Function not implemented
cache.get("google.com"); that is.
jrun
@257
Feb 21 2018 20:20
so running this:
watch --interval 32 'dig +noall +answer +ttlid akamai.com'
i see [resl] => querying: '95.100.173.66' score: 85 zone cut: 'akamai.com.' m12n: 'AkAmaI.coM.' type: 'A' proto: 'udp'
on each query
does that mean that cache of the record was purged since ttl is 20 for akamai.com?
Vladimír Čunát
@vcunat
Feb 21 2018 20:41
A couple lua cache functions is unimplemented ATM.
The systemd setup should expose a unix socket - you should be able to sudo nc -U /run/knot-resolver/control? to access the command interface.
The querying line does mean it's sending a query.
Vladimír Čunát
@vcunat
Feb 21 2018 20:50
Timed-out records will show in --verbose log like this:
[cach]   => skipping exact RR: rank 030 (min. 030), new TTL -72
(skipping due to negative TTL)