On Tue, Sep 13, 2022 at 12:24:15PM +0200, Petr Špaček wrote: ! On 12. 09. 22 15:49, Peter wrote: ! > On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote: ! > ! My testing did not uncover anything problematic. ! > ! ! > ! Versions: ! > ! fstrm 0.6.1-1 ! > ! protobuf 21.5-1 ! > ! protobuf-c 1.4.1-1 ! > ! ! > ! ! > ! A procedure which works: ! > ! - start BIND configured with ! > ! options { ! > ! dnstap { all; }; ! > ! dnstap-output unix "/tmp/unix"; ! > ! }; ! > ! ! > ! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix ! > ! -w /tmp/capture ! > ! ! > ! - fire couple queries: sleep 6 && dig bla example ! > ! ! > ! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature ! > ! > Negative. Does not work here: ! > ! > /tmp # ls -la capture ! > -rw-r--r-- 1 root wheel 42 Sep 12 15:42 capture ! > /tmp # dnstap-read -y /tmp/capture ! > /tmp # named -V ! > BIND 9.16.30 (Extended Support Version) <id:61fdb40> ! > running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1 ! ! Unfortunately neither me on Linux or my colleague who testing on FreeBSD are ! able to reproduce the problem you describe.
Okay, thank You for checking. I didn't look into the matter since I got my things working nevertheless. It looks a bit different now as not only me is experiencing the behaviour. ! There is a caveat, though: Without the --split interval option one has to ! terminate fstrm_capture to get data for dnstap-read to consume. That's ! probably by design and outside of our control (in libfstrm). This would then happen no matter if fstrm_capture is started before or after named. Let's have a short look. truss tells me that named is trying to open the socket, and receives ECONNREFUSED. Then, after every 5 seconds (just as the docs say) it tries again, but now it receives EPERM ! Apparently, the first connect() happens (after chroot but) before droppings priviledges. (The FreeBSD integration script does set -u to UID "bind", by default.) So, apparently, fstrm_capture should also run as UID "bind" (and would then need a proper filespace where it is allowed to create that socket). Or something else along that line. The OP should check if their problem suddenly resolves when doing a "chmod 777" on that socket (and then devise a suitable design according to their security policy). It's a joy to work with you folks, as always. :) -- PMc -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users