Bug 1142 - dnstap writes to unix domain socket give no error message with permissions failures
dnstap writes to unix domain socket give no error message with permissions fa...
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.5.10
x86_64 FreeBSD
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-26 11:29 CEST by Murray Stokely
Modified: 2016-10-26 15:12 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Murray Stokely 2016-10-26 11:29:23 CEST
I have been very happy with unbound 1.5.10 on FreeBSD 11-STABLE.

However, when I tried to enable dnstap, I was trusted when trying to understand the model for capturing the logs.  There are a couple of details that were not initially clear to me until I dug into the code and used Dtrace to see how unbound was interacting with the kernel.

The main issue is that unbound provides no useful error messages of any kind when it has trouble writing to the fstrm unix domain socket.  This is very frustrating and should be fixed.

Other less important things that were not clear to me initially are:

1) The socket must be created by the listening application, such as (1) dnstap or (2) fstrm_capture.

2) FreeBSD runs unbound as the 'unbound' user, so the capture application must also write to a directory owned by this user (not root) to ensure the unbound user can write to the unix domain socket.

3) The socket is created underneath the chroot environment.  This could be specified explicitly in some of the documentation.  I wasn't sure so setup listeners inside and outside the application as it was faster than reading through the code.
Comment 1 Wouter Wijngaards 2016-10-26 15:12:45 CEST
Hi Murray,

The issue is that fstrm_iothr_submit does not return any sort of diagnostic output.  Maybe in system from inside itself, but not to the caller.

Documentation sounds like a good idea.  Where did you look for documentation on what the username and chroot-position of the unix socket should be, and who creates it?  We can then add description there.

Best regards, Wouter