about unbound and systemd units
ericluehrsen at gmail.com
Sat Nov 17 15:57:39 UTC 2018
On 11/16/18 2:44 PM, Frank Habicht via Unbound-users wrote:
> first post. please be gentle
> On 16/11/2018 19:36, Simon Deziel via Unbound-users wrote:
>> Hi Rubén,
>> On 2018-11-16 11:02 a.m., Rubén Torrero Marijnissen via Unbound-users
>>> I was getting suggestions to have unbound-anchor.timer enabled by
>>> default (even if unbound.service is not) but I'd say this way is
>>> better because it only runs unbound-anchor.servce if unbound.servce
>>> is running, but I might be completely wrong:
>> I think there is value in maintaining the root.key file even if unbound
>> isn't running. The rational is that other things (like unbound-host or
>> packages using libunbound2) might want a current one.
>> Not maintaining the root.key lead to at least one bug report in Ubuntu
>>  and for that reason, I believe that Ubuntu/Debian  should also
>> adopt a similar approach.
> if you can, and you know how to, please keep it (root key) updated. even
> if it's not used.
> tomorrow it might get used (the root key) [by the new dude, who enables
> validation] and you want it to be updated.
In OpenWrt, we run scripts around the root.key to prevent flash wear.
Unbound works and chroots in /var/lib/unbound, So after checking
root.key for cleanliness, it is copied back to /etc/unbound. Because
unbound-anchor is one shot anyway, you could make unbound-anchor.service
actually call a script instead. If Unbound is running and therefore
doing its RFC5011 work, then don't run unbound-anchor. This script would
check root.key for finger prints of success and no damage. If you
modularize it, then it can also be used by the Unbound.service start and
Just some thoughts
More information about the Unbound-users