about unbound and systemd units

[Eric Luehrsen]

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 
>> wrote:
>>> 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
>> [1] and for that reason, I believe that Ubuntu/Debian [2] should also
>> adopt a similar approach.
> 
> +1
> 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.
> 
> Frank

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 
stop scripts.
Just some thoughts
Eric