write Coder binary to a fixed (not-user-specific) path

[spikecurtis]

In order to get direct network connections working, a customer needs to add a firewall exception for coder.exe on Windows. They manage their firewall rules centrally, and the problem is that the IDE plugin writes to the directory

c:\Users\%USERNAME%\AppData\Roaming\Code\User\globalStorage\coder.coder-remote

Since the directory is different for every person, they can't push out a central firewall rule.

It would be better if we could write to somewhere that doesn't depend on the username, and/or write somewhere centrally configurable.

[code-asher]

If they can control the settings they can configure coder.binaryDestination to a static location.

Not sure how easy it is to manage VS Code settings as policy, though, so maybe we need a different way to configure this.

[code-asher]

Oh yeah actually VS Code does have policy-level settings, maybe this will work: https://code.visualstudio.com/docs/setup/enterprise

[EhabY]

It seems the that policy-level settings are a bit broad and generic. Here's the full list:

I see a few solutions here for this to work with the firewall:

• As @code-asher suggested, users have to set their coder.binaryDestination (which they can share by sharing a settings.json if the path is the same)
• We can provide an environment variable for that so "it just works"
• By default the binary is installed in <global storage path>/coder.coder-remote/<coder url> , where the executable lives in the bin directory. Potentially the firewall can allow such a path but it'll be different on all systems because of the username and the OS

[spikecurtis]

By default the binary is installed in /coder.coder-remote/ , where the executable lives in the bin directory. Potentially the firewall can allow such a path but it'll be different on all systems because of the username and the OS

The whole point of this issue is for it to be the same on all systems so that the firewall rule can be managed centrally.

[EhabY]

I am not very familiar with Windows firewall rules but I mentioned this as a possibility if they can have wildcards in there.

It would be better if we could write to somewhere that doesn't depend on the username, and/or write somewhere centrally configurable.

What Asher mentioned should be that exactly then. Though sadly it cannot be centrally managed unless they write to the settings.json for each user. (Even then it would still be configurable by the user though it would just be blocked by the firewall).

[code-asher]

Environment variable sounds reasonable to me, I know one team for example sets CODER_URL for their users so it automatically populates with the right deployment URL, so it could be sufficient to support a CODER_BINARY_DESTINATION env var.

As far as policy goes, I did see there is a policy object that can be added to settings to make a setting controllable by policy, but I saw this in the VS Code source and am not sure if it can be applied to settings added by an extension. But this makes it sound like it is not currently possible: microsoft/vscode#151948

[EhabY]

@spikecurtis Do you know if an environment variable would resolve this issue for now? Or do we want to wait for MS to implement group policy for settings?

[spikecurtis]

The high level objective is that sysadmins can get this working using Group Policy---it can't depend on individual users taking action. I have no specific objection to an environment variable as long as it can be set via Group Policy (I'm not an expert). We might just need to try it out.

[EhabY]

Not an expert on Group Policy as well but it seems that environment variables set on the SYSTEM level cannot be modified by users (I am guessing their IT knows how to do that). In this case, adding an environment variable could be the way to go.

One last thing, in all other settings, environment variables take lower priority than actual settings in VS Code (or CLI), should it be the same here? If it is then it would just mean that users can change the binary location but the firewall rules would just kick in and block it in that case.

[spikecurtis]

One last thing, in all other settings, environment variables take lower priority than actual settings in VS Code (or CLI), should it be the same here? If it is then it would just mean that users can change the binary location but the firewall rules would just kick in and block it in that case.

Yeah, that's fine. If the user screws it up it fails secure (deny).