Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seperate remote_path into remote_folder and remote_script. #3462

Merged
merged 1 commit into from
Apr 26, 2016
Merged

Seperate remote_path into remote_folder and remote_script. #3462

merged 1 commit into from
Apr 26, 2016

Conversation

imduffy15
Copy link
Contributor

Commonly /tmp is set as noexec, as a result packer scripts
fail to run. In order to get around this one can set a
remote_path, whoever, remote path requires full filename
and path.

By making remote_path a combination of
remote_folder/remote_script we can change remote_folder
and keep the default script_nnn.sh

@imduffy15
Copy link
Contributor Author

Failure on appveyor seems unrelated.

@markpeek @rickard-von-essen @cbednarski does this look OK to you? :)


- `remote_file` (string) - The filename the uploaded script will have on the machine.
This defaults to 'script_nnn.sh'.

- `remote_path` (string) - The filename where the script will be uploaded
Copy link
Contributor

@cbednarski cbednarski Apr 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remote_path now has the same documentation as remote_file, can you include some language to distinguish them ("full path to the file") and also what happens if all three are specified / recommend which ones should be used in which cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback @cbednarski I will update the documentation accordingly.

In the event all three or set the remote_path will overwrite both remote_file and remote_folder. I only kept remote_path in order to not break peoples packer.json files.

@cbednarski
Copy link
Contributor

@imduffy15 Thanks for the PR, and for updating the docs! The change LGTM but would you be able to add a test that verifies the change? I think it's sufficient to provide two configuration blocks that demonstrate each case, parse them, and validate that the expected path comes out. You can move this logic to a new function if that makes it easier to test.

@cbednarski
Copy link
Contributor

Commonly /tmp is set as noexec, as a result packer scripts
fail to run. In order to get around this one can set a
remote_path, whoever, remote path requires full filename
and path.

By making remote_path a combination of
remote_folder/remote_script we can change remote_folder
and keep the default script_nnn.sh

Signed-off-by: Ian Duffy <ian@ianduffy.ie>
@imduffy15
Copy link
Contributor Author

Updated with test cases to ensure the following:

  • remote_file defaults to script_nnnn.sh where n is [0-9]
  • remote_folder defaults to /tmp
  • remote_path defaults to /tmp/script_nnnn.sh
  • remote_file and remote_folder set remote_path
  • remote_path overrides remote_file and remote_path

@cbednarski
Copy link
Contributor

Looks great! Thanks for adding the tests and docs. :)

@cbednarski cbednarski merged commit 7e65337 into hashicorp:master Apr 26, 2016
@sanmai-NL
Copy link

Why is the default directory /tmp/? As pointed out in the first post, that can cause problems. It does for me. Why not default to /?

@imduffy15
Copy link
Contributor Author

In terms of the linux file system and folder structure I feel /tmp is a
sane default for the given use case - Packer wishes to execute some scripts
that will not be stored permanently on the box, /tmp is specifically
designed for handling temporary files created by the system and user, it
also does automatic clean up when the system is reboot, there my, in my
mind making logical sense for a sane default.

In my situtation, /tmp was mounted on the system with noexec for security
reasons, thus causing issues. It wasn't possible to change just the folder
name and keep the random file names, hence this pull request.

I do not believe / would make a sane default, / is generally just
considered as a container for all the other required file system
structures. Placing arbitary temporary files in there is messy and doesn't
give me any logical or compelling reasoning to do so. If you feel it would
make a more sane default I would love to hear why.....

On 20 May 2016 at 18:53, Sander Maijers notifications@github.com wrote:

Why is the default directory /tmp/? As pointed out in the first post,
that can cause problems. It does for me. Why not default to /?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3462 (comment)

@sanmai-NL
Copy link

Assuming Linux, take your pick based on FHS. /opt/ or the user's home directory would be better, but only / can be assumed to exist. The cleanup is already implemented in Packer and enabled by default, and whether or not it is theoretically messy for a one-off provisioning script to be put at a certain path isn't very relevant I think. /tmp/ isn't being cleared upon starting Docker containers when that path wasn't specified explicitly as a mount of tmpfs type during container creation.

watters pushed a commit to watters/packer that referenced this pull request Aug 28, 2016
…#3462)

Commonly /tmp is set as noexec, as a result packer scripts
fail to run. In order to get around this one can set a
remote_path, whoever, remote path requires full filename
and path.

By making remote_path a combination of
remote_folder/remote_script we can change remote_folder
and keep the default script_nnn.sh

Signed-off-by: Ian Duffy <ian@ianduffy.ie>
@ghost ghost locked and limited conversation to collaborators Apr 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants