gruntwork-installer icon indicating copy to clipboard operation
gruntwork-installer copied to clipboard

Cannot install on a VM

Open rhoboat opened this issue 3 years ago • 4 comments

A user provided this error log to illustrate that they couldn't use the installer to install openvpn-admin on a VM.

gruntwork-install --binary-name openvpn-admin --repo https://github.com/gruntwork-io/terraform-aws-openvpn --tag v0.5.4

Error:

2021-07-02 12:08:08 [INFO] [gruntwork-install] Installing openvpn-admin...

2021-07-02 12:08:09 [INFO] [gruntwork-install] Moving /tmp/gruntwork-script-modules/openvpn-admin_linux_amd64 to /usr/local/bin/openvpn-admin and setting execute permissions

mv: cannot stat '/tmp/gruntwork-script-modules/openvpn-admin_linux_amd64': No such file or directory

We suspect that this has to do with the downloaded file being in the wrong place (i.e., the native system instead of the VM), or something like that. Is this a case we should support?

Workaround: Allow the script to complete and error out. Manually scp or otherwise locate the file and move it to the right place, adding execute permissions.

rhoboat avatar Jul 09 '21 17:07 rhoboat

The script defaults the download dir to /tmp/gruntwork-script-modules. Perhaps there is no /tmp on this VM? Or the user doesn't have permissions to write to /tmp? In either case, I suspect there may have been an error earlier in the log output. Could we see the full logs?

If this indeed the error, the workaround is to override the download dir with the --download-dir param to something writeable. The full fix is likely to also use a function like mktemp to create a temp dir in the right place, rather than assume /tmp.

brikis98 avatar Jul 12 '21 11:07 brikis98

In either case, I suspect there may have been an error earlier in the log output.

This might be true, but I think it's a smell for gruntwork-install to make it this far (moving the file) when there was an error in the download step. It should be exiting out earlier in the process if there was an earlier error. We should definitely comb through the script to make sure it fails fast.

yorinasub17 avatar Jul 13 '21 14:07 yorinasub17

Yes, agreed!

brikis98 avatar Jul 15 '21 10:07 brikis98

I ran into this in a related use case. fetch is not failing under some conditions. I think this is happening at https://github.com/gruntwork-io/gruntwork-installer/blob/main/gruntwork-install#L167

This should fail. You don't have this release in your repo:

$ fetch --log-level debug --repo=https://github.com/gruntwork-io/terraform-aws-security --tag=support_non_commercial_partitions --release-asset=ssh-grunt.\* /tmp/gruntwork-script-modules
$ echo $?
0

But I do...

$ fetch --log-level debug --repo=https://github.com/octo-radiance-iac/terraform-aws-security --tag=support_non_commercial_partitions --release-asset='.*' /tmp/gruntwork-script-modules
[fetch] INFO[2022-08-24T12:36:34-04:00] Downloading release asset ssh-grunt_linux_amd64 to /tmp/gruntwork-script-modules/ssh-grunt_linux_amd64
[fetch] INFO[2022-08-24T12:36:34-04:00] Downloaded /tmp/gruntwork-script-modules/ssh-grunt_linux_amd64
[fetch] INFO[2022-08-24T12:36:34-04:00] Download of release assets complete
$ echo $?
0

fetch should fail in the first case, which would prevent gruntwork-install from continuing on to say it will move a file that was not successfully downloaded.

hammondr avatar Aug 24 '22 16:08 hammondr