Issues with fetch and PATH

[brikis98]

bootstrap-gruntwork-installer.sh installs fetch into /usr/local/bin. Depending on the OS and the user (e.g., root), this directory is not always on the PATH. As a result, the call to fetch in gruntwork-install may fail.

We should either (1) call fetch from an absolute path in gruntwork-install or (2) install fetch into something more likely to be on the PATH, such as /usr/bin.

[brikis98]

See https://github.com/gruntwork-io/module-security/issues/58#issuecomment-342610450 for context.

[josh-padnick]

My vote is option 1, using an absolute path for fetch. This way, the user is free to use any other version of fetch that they want.

[billmdevs]

Hello @brikis98 . I think the link you posted to provide context is a private link. Maybe I could help on giving my view.

[josh-padnick]

@spiritus72 Here's the comment in question:

When I moved everything to the bootcmd stage, reloading the sshd service actually failed - because it wasn't running yet. So it eliminated that problem. And it also wrote the cron entries before the cron daemon starts up, eliminating that kludge in my user data, too. So basically, the path problems caused me to move everything to runcmd from bootcmd, then when I fixed the path problems there, it caused all these knock-on side effects from running so late in the boot process. Moving everything back to bootcmd stage fixed all that, so the only real problem turned out to be the fact that 'fetch' is called from within the gruntworks installer without an absolute path, so calling /usr/local/bin/gruntwork-installer doesn't work unless you also add that directory to $PATH. Fix that and all the other issues would never have cropped up for me. That should be as simple as replacing fetch with $BIN_DIR/fetch in the installer script.