Knot - enable HTTP

[manison]

Hello.
I’m trying to enable the HTTP module in Knot resolver but with no luck so far. I wanted to trace some DNS issues I’m facing with the tracking service.

I loaded the module in my /etc/kresd/custom.conf

module.load('http')

and reloaded the kresd:

/etc/init.d/kresd reload

However it was complaining about missing cqueues Lua module:

error: /usr/lib/kres_modules/http.lua:6: module ‘cqueues’ not found:

So I installed the missing module:

opkg install lua-cqueues

and reloaded kresd again. But got the same error. I noticed that the cqueues module has been installed on path /usr/lib/lua, however this path is not on the kresd search path:

error: /usr/lib/kres_modules/http.lua:6: module ‘cqueues’ not found:
no field package.preload[‘cqueues’]
no file ‘/usr/lib/cqueues.lua’
no file ‘/usr/lib/cqueues/init.lua’
no file ‘./cqueues.lua’
no file ‘/usr/share/luajit-2.0.5/cqueues.lua’
no file ‘/usr/local/share/lua/5.1/cqueues.lua’
no file ‘/usr/local/share/lua/5.1/cqueues/init.lua’
no file ‘/usr/share/lua/5.1/cqueues.lua’
no file ‘/usr/share/lua/5.1/cqueues/init.lua’
no file ‘/usr/lib/cqueues.so’
no file ‘./cqueues.so’
no file ‘/usr/local/lib/lua/5.1/cqueues.so’
no file ‘/usr/lib/lua/5.1/cqueues.so’
no file ‘/usr/local/lib/lua/5.1/loadall.so’

I made a symlink from /usr/lib/lua to one of the listed paths and now I’m stuck with this error:

error: /usr/lib/kres_modules/http.lua:6: loop or previous error loading module ‘cqueues’

It’s this line.

I’m on Turris OS 3.11.6.

Questions:

• Shouldn’t the knot-resolver package have dependency to lua-cqueues module?
• Shouldn’t the lua-cqueues package install on Lua package search path?
• And most importantly – how to enable the HTTP module?

Thanks.

[vcunat]

@manison

I’m on Turris OS 3.11.6.

3.11.16, I assume.

The biggest problem I see is that the module absolutely can’t work without the lua-http package, and that’s not packaged for Turris yet (not even 5.0.0 HBT).

@manison

Shouldn’t the knot-resolver package have dependency to lua-cqueues module?

cqueues is only needed for some quite specific functions; almost no Turris users will benefit from it, I believe. Therefore it seems OK to me not to pull that dependency by default, even though on Turris devices we surely don’t need to be as minimalist as openwrt defaults.

[vcunat]

@manison

I wanted to trace some DNS issues I’m facing with the tracking service.

It most likely won’t help your case, but there’s a public instance of the service here: https://debug.knot-resolver.cz/query.py?qtype=A&qname=turris.cz Well, if you discover some reproducible bugs in Knot Resolver through the service, we’ll certainly be interested.

[manison]

@vcunat

3.11.16, I assume.

Sure, it was typo.

@vcunat

The biggest problem I see is that the module absolutely can’t work without the lua-http package, and that’s not packaged for Turris yet (not even 5.0.0 HBT).

Ok, I tried to install it with luarocks, but it tries to pull in a buch of other dependencies, some of them trying to compile from sources. I’m giving up…

@vcunat

cqueues is only needed for some quite specific functions; almost no Turris users will benefit from it, I believe. Therefore it seems OK to me not to pull that dependency by default, even though on Turris devices we surely don’t need to be as minimalist as openwrt defaults.

Then maybe the HTTP module could be packaged separately as knot-resolver-module-http with this package having the required dependencies, couldn’t it?

@vcunat

It most likely won’t help your case , but there’s a public instance of the service here: https://debug.knot-resolver.cz/query.py?qtype=A&qname=turris.cz Well, if you discover some reproducible bugs in Knot Resolver through the service, we’ll certainly be interested.

Great, good to know, thanks.

Anyway, does the HTTP tracking service provide any additional information or benefit over the resolver-debug package? It seems to me that the output from from the public service you mentioned is the same as the debug logs I can already retrieve.

[vcunat]

@manison

Then maybe the HTTP module could be packaged separately as knot-resolver-module-http with this package having the required dependencies, couldn’t it?

Yes, that’s how we typically package it for Linux distributions, so I assume we would aim for the same here as well.

@manison

Anyway, does the HTTP tracking service provide any additional information or benefit over the resolver-debug package? It seems to me that the output from from the public service you mentioned is the same as the debug logs I can already retrieve.

Yes, the tracing in http displays the verbose log; the main advantage is that you see a separate log just for one particular request. The http module also has some other features (e.g. DNS-over-HTTPS), but you don’t seem interested in those.

[manison]

@vcunat

Yes, the tracing in http displays the verbose log; the main advantage is that you see a separate log just for one particular request.

That can be of great help though.

@vcunat

The http module also has some other features (e.g. DNS-over-HTTPS), but you don’t seem interested in those.

I’m aware of DoH, I don’t need it at the moment.

Thank you.

[vcunat]

@vcunat

@vcunat

Yes, the tracing in http displays the verbose log; the main advantage is that you see a separate log just for one particular request.

That can be of great help though.

In verbose logs we try to attribute every line to a client’s request and mark it [NNNNN. by the ID sent from the client, so that can be also used for separating them afterwards.