Hi Michael Michael Tremer schreef op wo 17-06-2026 om 14:11 [+0100]: > Hello Robin, > > I totally agree that the overhead of kresctl is way too high, > especially on some of the weaker hardware that we are using. The HTTP > responses are available instantaneously which is much nicer as it > almost uses zero resources. > > It seems that kresctl is only returning the plain output of the HTTP > API anyways. > > However, I am not sure if we should make this available over the > network because of the following problems: > > * Port Number Congestion - Port 5000 is a very round number and might > already be used by other services like OpenVPN or even the proxy > where people can choose a port number freely. As the number is easy > to remember chances are high.
I just took 5000 as that was used in the example provided by the knot documentation. I noticed older versions of knot had a HTTP plugin serving more or less the same purpose, and that operated on port 8043 (http) or 8443 (https). It seems they downscaled that (only http now) and built it into the core.. > > * Security - Securing access to localhost is hard. True.. any process running on IPFire could easily query/use the knot API. > > So I have a counter-proposal which does not require any configuration > changes on behalf of the Knot Resolver configuration. Kresctl already > as a socket to communicate with the daemon using a Unix domain socket > using the HTTP API - although it feels a bit weird sending HTTP over > the socket. But it does work: > > [root@fw01 ~]# curl --unix-socket > /var/run/knot-resolver/kres-api.sock http://localhost/metrics/json > {"kresd:kresd0": {"answer": {"total": 0, "noerror": 0, "nxdomain": 0, > "nodata": 0, "1ms": 0, "10ms": 0, "50ms": 0, "100ms": 0, "250ms": 0, > "500ms": 0, "1000ms": 0,… > > Is this an option for Zabbix? I suppose you are using curl as a > replacement to kresctl as it is much more lightweight. Or are you > using an internal HTTP client of the zabbix agent? And if so, does it > support the Unix socket? Zabbix agent natively supports querying http(s) over tcp/udp sockets using a builtin client, but does not support unix sockets out of the box. So using this method will need a different approach on the Zabbix agent if we want to support it "out-of-the-box". I've been looking around for existing Knot templates, but the only ones I found use the http(s) plugin for knot and even query the interface straight from the Zabbix server instead of through the agent, so the http(s) interface has to be accessible from the Zabbix server for them to work. Anyway, the unix socket won't work natively, so I will have to add a new UserParameter to the Zabbix agent IPFire specific config, calling curl to retrieve the metrics from the unix socket, like I already do with ping, arping, getipstat, openvpnctrl, wireguardctl etc.. I've tested this and this seems to work nearly as good as natively calling http. There will always be a little performance loss due to the fact that a separate process is forked to execute an additional binary. But as it seems minimal, this should not pose a problem. Regards Robin -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
