Execution fails after Windows installation

[Tzrlk]

After manually installing the SOPS binary from their project, running helm secrets help throws the following error:

Error: fork/exec C:\Users\tzrlk\.helm\plugins\helm-secrets/secrets.sh: %1 is not a valid Win32 application.

I do have sh and bash on my path, so the scripts in this project should be runnable, but even following the helpful stackoverflow answer to make shell scripts runnable, it keeps giving me the same error.

Related to #56

[polerin]

I am also experiencing this.

[smeierhofer]

I found this too. This plugin only works on Linux as it is a bash shell script. Check it out at $HELM_HOME/plugins/helm-secrets.

I installed this plugin manually by cloning the git repo into this location (make sure git is using LF line endings). I then edited the file $HELM_HOME/plugins/helm-secrets/plugin.yaml so that it invoked the secrets.sh bash script using the WSL. Here's the line I changed:

command: "wsl --exec /mnt/c/Users/smeierhofer/.helm/plugins/helm-secrets/secrets.sh"

You'll also need to set the WSLENV Windows environment variable to list all the Helm variables that are passed from helm.exe to the secrets.sh bash script. Here's what I have:

HELM_BIN/p:HELM_HOME/p:HELM_PATH_CACHE/p:HELM_PATH_LOCAL_REPOSITORY/p:HELM_PATH_REPOSITORY_FILE/p:HELM_PATH_REPOSITORY/p:HELM_PATH_STARTER/p:HELM_PLUGIN_DIR/p:HELM_PLUGIN/p:HELM_PLUGIN_NAME:TILLER_HOST:TILLER_NAMESPACE:HELM_HOST:HELM_TILLER_SILENT:HELM_TILLER_PORT:HELM_TILLER_PROBE_PORT:PROBE_LISTEN_FLAG:HELM_TILLER_STORAGE:HELM_TILLER_LOGS:HELM_TILLER_LOGS_DIR/p:HELM_TILLER_HISTORY_MAX:CREATE_NAMESPACE_IF_MISSING

But probably you are better off working entirely in the WSL and use Helm for Linux. I am about go this route myself.

[jribmartins]

Hello all,

I solved this installing helm secrets in a docker image, and creating an alias like this:
alias helm=docker run -ti --rm -v %cd%:/apps -v ~/.kube:/root/.kube my-helm:latest $*
It works very well.

[BowlingX]

In case someone stumbles across here and wonders how this works with powershell

Create a custom helm image:

 FROM alpine/helm:3.0.3

RUN apk update && apk upgrade && \
    apk add --no-cache bash curl git openssh
 RUN helm plugin install https://github.com/futuresimple/helm-secrets 
 RUN helm plugin install https://github.com/chartmuseum/helm-push

Build and push:

docker build -t helm:3.0.3 .

Create a function:

Function helm3 { $location=$(Get-Location); Invoke-Expression -Command "docker run -ti --rm -v $($location -replace '\\','/'):/apps -v ~/.kube:/root/.kube helm:3.0.3 $args" }

[smeierhofer]

Are you suggesting that Windows users run Helm and the Helm secrets plugin in a docker image running in Docker Desktop for Windows? I don't see that as a workable solution for the full stack of Helm, Helm secrets plugin, Kubernetes, Kubectl, etc. To make the approach of running Helm inside a docker image work, you would need to run the entire stack of tools inside the docker image. The tools have configuration files. And the tools operate on files such as the Helm Chart and the values files, secrets files, etc. That's going to get painful to do inside a Docker container.

I have personally found that using WSL on Windows works best. I have installed Linux versions of tools in WSL (Helm, Helmfile, helm plugins, sops, OpenGPG, Kubectl CLI, Docker CLI) and I have these configured to work with the single-node Kubernetes cluster provided by Docker Desktop for Windows. I run all the tools from the WSL bash shell which has seemless access to my Windows file system where the secrets files and Helm Chart files and all the other files live.

Summary is that the Helm secrets plugin doesn't work on Windows. Work-around is to use the Linux version of Helm and plugins inside the WSL.

[BowlingX]

@smeierhofer that's a viable solution :). I like to stay in the same shell. I use sops, kubectl etc. on windows, and it works for the most tooling. I just wanted to give an alternative. The docker command mounts the folder where you run the command, it's not perfect and yes you have to install the tools you require.

[JoshuaCWebDeveloper]

Working in WSL is probably the best option, especially if you are only working with k8s clusters in the cloud. However, in my case, I am also deploying to a local Minikube cluster that is running on my Windows environment, and I did not want to muck with trying to get tools running in WSL to communicate with my Minikube running in Windows.

In order to be able to run helm-secrets in Windows, I took @smeierhofer's above instructions, but instead modified the plugin command to use Git Bash (if you have installed Git on Windows, you likely already have Git Bash installed even if you don't know about it). I am running all of my tools in Git Bash, so I'm not sure if the below will work if you are running helm from Windows Command Prompt or similar.

If you can't or don't want to use WSL, you can try using Git Bash instead by making the following change to the plugin.yaml file:

#command: "$HELM_PLUGIN_DIR/secrets.sh"
command: "sh --login -i $HELM_PLUGIN_DIR/secrets.sh"

The usage of sh assumes that the Git Bash bin/ directory is on your Windows PATH. If you aren't sure if this is the case, try running the command sh from Windows Command Prompt.

Also, I was able to install this plugin from the repo in the documented manner, and then just edit the installed plugin.yaml.

[smeierhofer]

Here are the steps I did so that the docker and Kubectl CLI tools running in WSL can talk to Docker running in Docker Desktop:

• Use the Docker Desktop settings to expose the Docker daemon on localhost without TLS.
• To configure docker CLI to talk to the Docker daemon in WSL add following to ~/.bashrc file:
  export DOCKER_HOST=tcp://localhost:2375
• In WSL edit the ~/.kube/config file and copy the docker desktop stuff to it from my Windows %USERPROFILE%\.kube\config file

At this point I can run docker, kubectl, helm, helm secrets, etc. from WSL and talk to the Docker Desktop docker daemon.