What is the status of external config script/executable support on Windows?

[BlackHoleFox]

Hiyo there. While trying to put together a dnscontrol deployment, I ran into this line in the documentation around using an external app to create dynamic creds.json contents:

Windows: Executing an external script isn't supported. There's no code that prevents it from trying, but it isn't supported.

For someone new its not really clear what "external script" is referring to. Is that just a shell file (.sh. .cmd, .ps1) marked as executable in its filesystem properties or does it also include native binaries too? The question pops up since running an actual binary with arguments works just fine on Windows (a pleasant surprise, honestly :D) and neither the impl PR or the Go documentation for the functions used mention missing functionality.

if the answer is "none of that is supported, its just working by chance", what can be done to make sure at least the executable part continues to work into the future (or ideally becomes supported)? Adding CI tests? I'd feel better leaving this for a long time knowing a future update isn't going to break my workflow.

[tlimoncelli]

Hi there!

Excellent question!

When that was written the concern was, as you guessed, that we don't have CI tests running on Windows. Thus, we can't be sure we don't break anything by mistake.

That said, the code is written in a way that if it works at all, it should work for both Unix and Windows. The only way I can imagine it stop working would be a violation of Go's compatibility guarantee. The warning should probably be removed.

Considering the code mentions Windows, if someone did change it, we'd at least do some ad hoc testing on Windows.

If I may editorialize a bit.... I still don't understand why dnscontrol push --config !foo is better than foo >dnsconfig.js && dnscontrol preview. The latter leaves behind the file for inspection; very useful when debugging! Also, if you run preview then push, you're running foo twice which is inefficient and also runs the risk of having different output the second time. I almost rejected the PR because of these concerns but accepted the feature after so many people asked for it.

Bottom line: Go ahead and use this feature on Windows.

Hope that helps! Tom

[tlimoncelli]

I've updated the docs. Thanks for raising this issue!

[BlackHoleFox]

Much appreciation for the fast updates :)

I still don't understand why dnscontrol push --config !foo is better than foo >dnsconfig.js && dnscontrol preview. The latter leaves behind the file for inspection; very useful when debugging!

In my use case the structure of the creds.json "template" file remains the same but my invocation fills in sensitive field values from my password/secret manager using template strings. For me its an anti-feature if those credentials ended up on-disk in plaintext (this person is doing the same thing). If I want to initially configure it/debug I'll swap out the references with dummy values that aren't sensitive.

Also, if you run preview then push, you're running foo twice which is inefficient and also runs the risk of having different output the second time.

Inefficiency is a good callout, but if you used something like https://github.com/ryantm/agenix then you never risk having different outputs on each run because your encrypted/masked secret is committed as well for reproducibility. An invalid secret would just fail to decrypt outright.

[tlimoncelli]

Ah yes! Good points all around.

Thanks for the clarification.