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.