Hi,
ist it possible to switch on logging for unbound? I would like to log all DNS requests from internal (green) IP addresses.
Michael
Hello Michael,
you might want to use the following server options in /etc/unbound/unbound.conf (excerpt from the unbound.conf documentation):
log-queries: <yes or no>
Prints one line per query to the log, with the log timestamp and
IP address, name, type and class. Default is no. Note that it
takes time to print these lines which makes the server (signifi-
cantly) slower. Odd (nonprintable) characters in names are
printed as '?'.
log-replies: <yes or no>
Prints one line per reply to the log, with the log timestamp and
IP address, name, type, class, return code, time to resolve,
from cache and response size. Default is no. Note that it
takes time to print these lines which makes the server (signifi-
cantly) slower. Odd (nonprintable) characters in names are
printed as '?'.
log-tag-queryreply: <yes or no>
Prints the word 'query' and 'reply' with log-queries and
log-replies. This makes filtering logs easier. The default is
off (for backwards compatibility).
Jesko
1 Like
If you have any custom settings for unbound, please put them into /etc/unbound/local.d.
They won’t be overwritten in an update then.
1 Like
FYI: /etc/unbound/unbound.conf will include any file with extension .conf in the local.d/ dir
example: /etc/unbound/local.d/pavlos.conf is as follows …
server:
log-queries: yes
log-replies: yes
log-tag-queryreply: yes
1 Like
Hey
i wasn’t here for while. Greetings @ all
does it make a sense to put those logs into a seperate log file?
Greetings Daniel,
Yes it would make sense,
I think this should work to put your logs in /var/log/unbound
# the log file, "" means log to stderr.
# Use of this option sets use-syslog to "no".
logfile: "/var/log/unbound/unbound.log"
The WUI System Logs page already gives you just the unbound logs, together with each of the other system logs, all in one place.
That is done by using the messages logfile and an appropriate grep process.
So I believe that the current process works fine and meets the needs of the majority of users.
If a user really needs to access the logs from the command line then they will likely know how to carry out a grep search on it.
Be aware making changes to config files will likely be overwritten when a Core Update is carried out.
1 Like
Okay - Thank you
I think logrotate needs also to be adjusted?
In what way?
Hey Jon,
sorry for being so late.
cause we will do make changes to the System.
Each Addon, if it is logging, does place a custom rotate file into logrotate.d subdir.
Right now we do tell unbound to log somewhere else. We do need to take care about the logfile rotation.
Hope that answers your Question.
Thank you.
Hey bonńitwin,
you are absolutely right.
If we do change that, the GUI needs also to be adjusted - just another cgi diff file to be added. 
Don’t you agree?
If you want to make those changes on your system and also still be able to use the WUI system logs, then yes you will also need to change the cgi page for that as it will need to get the log info from multiple log files instead of generally only from the messages log series.
1 Like
Generally spoken, if you have new ideas about logging ( not yet implemented since the start of this thread ), feel free to join the development community. How this can be done is documented in the wiki.
Just my 2cts:
Almost each core update I’ve to adopt /srv/web/ipfire/cgi-bin/logs.cgi/log.dat to get the logs entries, that NUT, precisely upsmon, writes into messages. Maybe worth to change the coding?
Additionally, I want to see logs that HAProxy and Deyhdrated create, unfortunately both do not write into /var/log/messages though. They use their own files, perhaps one time those packages get their own menu item below Log?
1 Like
Raise a bug for that, then the issue is recorded and can be worked on when resources are available.
Raise a separate bug for each add-on that is doing it differently.
1 Like
I certainly would like to do, if not Bugzilla has that ugly and unfortunately not user friendly interface and missing data to file a detailed and appropriate ticket. 
As my post above, is not really a bug, but a feature request, I would like to file as such in Bugzilla. But, I’m completely lost while searching for the correct component as nut nor upsmon are both not listed there. So I’ve searched the list for words log and messages to no avail either.
So please advice on how to file such a request and on how to choose the correct component. 
1 Like
Components are only selected if you are entering a bug for IPFire 3.x
Select the entry at the top of the drop down list which is three dashes and the wording in the box indicates that is the entry to use for all IPFire2.x entries.
If you are unsure about an entry then just leave it at unknown or the default setting. We can modify it afterwards if it should be different.
For NUT I would classify that as a bug as the log data is put into /var/log/messages but there is no filter in the system logs.
HAProxy and Dehydrated might be more feature related than bug but the standard approach for IPFire is to use the system logs entry so I would also consider them as bugs as they are not following the standard approach for the logs.
Either way, just put the entries into bugzilla and we will manage to work with them. I will have a look through afterwards and see if anything needs to be tuned in the entries.
2 Likes
Just a further comment about working with bugs / feature requests.
To follow such things you need to be informed about every change. If you do this with the community board, you will be flooded with announcements. So the real information is lost .
Chosing bugzilla or the development mail list narrows this amount massively.
Bugzilla has the advantage, that the devs can easily search for unsolved tickets.
I don’t think the structure of bugzilla is too complicated. Classifying a request helps the requestor also to clarify his problem.
Because there is no automatism in working with bugzilla, each ticket is read and probably corrected as @bonnietwin stated. The ticket opener is informed about these modificatios.
1 Like
Done for the bug of package NUT.
And a second one as a feature request for HAProxy and Dehydrated.
Nevertheless, since HAProxy and Dehydrated use their own or no standard logging at all, I doubt to see the logs in the WebIf anytime soon 
1 Like
NUT should be no problem.
Looking at HAProxy then it looks like you can set it up to feed all output into a syslog system so it should be feasible to make work but it can also be changed in the conf file to go to quite different log files. Will need to try it out to see if it is possible but I am hopeful.
Having looked at Dehydrated I am less hopeful. It is not a running daemon but a script that is run when you need it, or it can be run periodically via cron. There is no logging setup at all. To get all the output going to a log system would require a modification of the script and the challenge would be to have the output going to a log file and at the same time to the screen because usually you will be interested in seeing the result when you run the script.
Not sure now that this will be feasible.
Will work on NUT first and then have a look at HAProxy and then based on how those went will decide about trying Dehydrated or not.
3 Likes