[Unbound-users] unbound 1.4.16 release

W.C.A. Wijngaards wouter at nlnetlabs.nl
Fri Feb 3 15:00:45 UTC 2012

Hash: SHA1

Hi Mees,

Thanks for the error description, I have just found out that rename() is
not posix compliant on Windows.  It does not remove the destination file
(and thus there is a race condition).  Solved with an unlink() before
the rename, on windows.

The fix is in svn trunk.  I can send you a compile of that snapshot, if
you want?

The impact without the fix is that root.key remains the same, which is
harmless.  (Until the root key rolls over, then you must update to a
fixed unbound version).

Best regards,

On 02/03/2012 03:07 PM, Mees de Roo wrote:
> hi,
> This error seams to affect the Windows (7) version of unbound just as
> well. I get numerous messages (at boot):
> Log Name:      Application
> Source:        unbound
> Date:          3-2-2012 3:59:56
> Event ID:      4
> Task Category: None
> Level:         Error
> Keywords:      Classic
> User:          N/A
> Computer:      SuperLap
> Description:
> [unbound:0] error: rename(C:\Program Files
> (x86)\Unbound\root.key.13920-0 to C:\Program Files
> (x86)\Unbound\root.key): File exists
> Changing acces does not help; unbound resets them to the original
> failing values.
> The previous version showed no such messages.
> Mees de Roo
> -----Original Message----- From: W.C.A. Wijngaards
> Sent: Thursday, February 02, 2012 2:47 PM
> To: unbound-users at unbound.net
> Subject: Re: [Unbound-users] unbound 1.4.16 release
> Hi Juergen,
> On 02/02/2012 01:49 PM, Juergen Daubert wrote:
>>> Here is unbound 1.4.16, fixes bug in bugfix in 1.4.15:
>> thanks for the new release, however I think we have one regression
>> wrt ownership of the autotrust file, default
>> /etc/unbound/root.key.
>> This file must be owned by the user unbound is running as, e.g.
>> the user unbound. Starting with version 1.4.15 unbound-anchor
>> resets the ownership to the user running unbound-anchor, which is
>> normaly root.
> That is very inconvenient.  This is because it writes to a temp first,
> then moves it over the first.
>> Because of that the running unbound cannot longer update the key
>> file, which leasds to a error message:
>> Feb  2 12:33:43 tor unbound: [19568:0] error: could not open
>> autotrust file for writing, root.key.19568-0: Permission denied
> No, it is not allowed to create a new file in the directory.  It wants
> to create a tempfile to write to, when that has worked, it'll mv the
> new over the old.  So that failures during the write leave you with a
> bootable system.
> That part is working: this error may be inconvenient, but the system
> still boots.
> I guess you have to chown unbound /my/keydir
> or chgrp unbound /my/keydir
> This sort of solution becomes system specific.  What would work for you?
> Best regards,
>   Wouter
Unbound-users mailing list
Unbound-users at unbound.net

Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/


More information about the Unbound-users mailing list