Bug 1183 - Path to root.key file ignored
Path to root.key file ignored
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.6.0
x86_64 Windows
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-12-13 23:08 CET by drahnier
Modified: 2016-12-15 20:21 CET (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 drahnier 2016-12-13 23:08:29 CET
In an attempt to segregate program code from program data, I moved certain Unbound configuration files to a folder named "C:\ProgramData\NLnet Labs\Unbound\", while the original Unbound installation directory remained "C:\Program Files\Unbound\".

I moved a "service.conf", a "root.hints", a "root.key", and a "filter.conf" file from their original location in the installation directory to the data directory and updated references to the latter three files in "service.conf" accordingly. I also updated the Unbound service configuration in the Windows Registry to cause Unbound to fetch its service configuration file from that data directory.

As it happens, Unbound appears to ignore (at least) the path definition to "root.key" and, at every start, places a new "root.key" file in it's installation directory while I would expect that file to be placed/updated in the data directory.

It is against all conventions and recommendations to mingle program code and program data on a Windows machine and I would kindly ask the Unbound team to look into this and ensure a "best practice" behavior for their code.
Comment 1 Wouter Wijngaards 2016-12-14 14:38:05 CET
Hi Drahnier,

Have you updated the registry string for Software\Unbound\RootAnchor it has the full pathname to the root.key and icannbundle.pem files.  You should adjust them too!  Then, unbound-anchor.exe should create the root.key file in the correct data directory.

This registry string is written by the installer (and it should have been written correctly for the failure report screenshot you sent earlier).  The installer makes it point to the install directory.

Best regards, Wouter
Comment 2 drahnier 2016-12-15 01:38:04 CET
No, I wasn't aware of that registry key. 

As it currently is, these dependencies are quite unfortunate. Shouldn't this - the placement of program data associated with unbound - handled consistently between all apps that come with the unbound package, shouldn't all these parameters/settings find it's way to a central place in the registry (and not being scattered around)? And shouldn't the build process enforce platform best practices for handling of code and data? - I think, something must be done here.

I will try/test once more as soon as you release a 2nd rc (or a final).
Comment 3 drahnier 2016-12-15 08:11:17 CET
(In reply to drahnier from comment #2)
> No, I wasn't aware of that registry key. 
> 
> As it currently is, these dependencies are quite unfortunate. Shouldn't this
> - the placement of program data associated with unbound - handled
> consistently between all apps that come with the unbound package, shouldn't
> all these parameters/settings find it's way to a central place in the
> registry (and not being scattered around)? And shouldn't the build process
> enforce platform best practices for handling of code and data? - I think,
> something must be done here.
> 
> I will try/test once more as soon as you release a 2nd rc (or a final).

More comments on this registry key:

What I see is a key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Unbound. This key - on ONE of my three systems running Unbound - has a REG_SZ with 'Name' RootAnchor' and a string 'Value' of '"C:\Program Files\Unbound\unbound-anchor.exe" -a "C:\Program Files\Unbound\icannbundle.pem"'. On the other two machines this name/key combo DOES NOT EXIST at all - although on all three machines Unbound 1.6rc1 had been installed running 'unbound_setup_1.6.0rc1.exe' (and the installer failing on ONE of those machines with the error previously reported, but completing without errors on the other two machines).
Comment 4 Wouter Wijngaards 2016-12-15 11:20:12 CET
Hi Drahnier,

Of course, thank you for the test results.

The installer writes WriteRegStr HKLM "Software\Unbound" "RootAnchor" "$\"$INSTDIR\unbound-anchor.exe$\" -a $\"$INSTDIR\root.key$\" -c $\"$INSTDIR\icannbundle.pem$\""

Note sure why that regsz string for you has a mangled value.

Unbound-anchor is designed to be independent.  This causes this configuration difference.  But it should be possible to configure the program to perform the operations as necessary for the platform (and layout) desired.  For that the executable has commandline options.  And these are stored in the registry string, that string is picked up by the unbound windows-service code.

Best regards, Wouter
Comment 5 drahnier 2016-12-15 11:37:59 CET
Whatever you say, but: On my three systems where I installed Unbound, this key - HKLM "Software\Unbound" - DOES NOT EXIST. 

Instead, what exists (and thus must have been created by Unbound's installer), is what I have written in my previous post: HKLM "SOFTWARE\WOW6432Node\Unbound" - and that makes perfectly sense, since the executable is a 32bit one in a64bit environment. - Maybe, things have changed with Windows 10 and you are testing with an older Windows version (that is, if you test the Windows version of Unbound at all)?
Comment 6 Wouter Wijngaards 2016-12-15 11:46:15 CET
Hi Drahnier,

Okay I don't know either.  It tries to write the value RootAnchor, and it apparantly read it too, otherwise it would not start unbound-anchor.exe.  But that does also have baked-in references to the programfiles place.  It is just that these baked-in references are overridden by the registry entry.  But that does not exist?

Best regards, Wouter
Comment 7 Wouter Wijngaards 2016-12-15 11:50:41 CET
Hi Drahnier,

And you are correct that we don't run unit tests on the windows version, assuming that unchanged code still works.  And that really is not helping at all, with what seems to be 'new' 64 to 32bit helper code in Windows 10.

I could attempt to compile 64bit binaries, perhaps that is better.  But the installer is a created executable with nsis, and could have its own 32/64 bit-ness which is different from unbound.exe (compiled with gcc)...

Best regards, Wouter
Comment 8 drahnier 2016-12-15 12:02:04 CET
I asked about a 64bit version for Unbound months ago (and you kindly provided one which worked flawlessly - on Windows 10). I really don't understand why 64bit is not the default here. If the tools don't do, then they are perhaps outdated and need to be reconsidered. I know from experience that that can be a VERY painful thing to do, but: We're living in the 21st century, don't we? So, yes, providing 64bit versions is the way to go, imho. And I promise to install each and any of these and report things broken ...
Comment 9 Wouter Wijngaards 2016-12-15 13:48:58 CET
Hi Drahnier,

I created a w64 compile (which you don't have to try), but I also set the default for new releases to 64bit.  I hope that will solve future problems, even if it doesn't impact this one.

( www.nlnetlabs.nl/~wouter/unbound_setup_1.6.1rc79.exe )

Best regards, Wouter
Comment 10 drahnier 2016-12-15 19:36:07 CET
Thanks for the 64bit 1.6.1rc version.

I've just installed that one on top of the existing 32bit 1.6.0 version. It still does not create any registry keys under HKLM "Software\Unbound", but seems to be content with (or has updated) what has been there under HKLM "SOFTWARE\WOW6432Node\Unbound". 

That does not look right, imho.

I'll do another install of this 64bit version on a second system later today (it's late here in Bangkok and I'm a little tired) and make sure to delete any registry entries under HKLM "SOFTWARE\WOW6432Node\Unbound" before doing so in the hope that that install will create new registry keys under HKLM "Software\Unbound".
Comment 11 drahnier 2016-12-15 20:21:51 CET
Another install of the 64bit version on a 2nd Windows 10 machine - this time after having removed any references to Unbound from the registry.

I'm puzzled:

- Why offers the installer to install the 64bit version to 'C:\Program Files (x86)\Unbound'? It clearly should offer 'C:\Program Files'.

- Why does the 64bit install still create registry entries under HKLM "SOFTWARE\WOW6432Node\Unbound", instead of HKLM "SOFTWARE\Unbound"?

This should be looked into and consequently cleaned up.