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

How do I get access to the IP address of the machine under build? #4993

Closed
sandersaares opened this issue Jun 9, 2017 · 14 comments
Closed

Comments

@sandersaares
Copy link
Contributor

sandersaares commented Jun 9, 2017

To work around #2648 I am considering simply opening up some shared folders (SMB) on the machine being built and uploading files using the local shell provisioner. Alternatively, using PowerShell remoting file transfers. However, I do not seem to find any variables documented that would enable me to obtain the relevant IP address to actually connect to.

I would like to know how I can provide this information to my local shell provisioner and to request that this information be added to the documentation.

@rickard-von-essen
Copy link
Collaborator

The IP is not directly available to the provisioner. Which builder do you use?

@sandersaares
Copy link
Contributor Author

I currently use Azure and Hyper-V and will likely also use VirtualBox and QEMU in the future.

@ladar
Copy link
Contributor

ladar commented Jun 10, 2017

I wrote a shell script that allows me to easily connect up with all my running packer builds, but it's targeting *nix systems, and only looks for qemu, vmware, or virtualbox builds at the moment. See this gist, and feel free to send me any Windows improvements via PR.

That said the theory should work on WIndows. Just use netstat to find the console and connect up. Once your logged in you can look at the machine IP and then ssh in. I've done it many times to troubleshoot installer issues.

You can also set the PACKER_LOG environment variable to any non-zero value. That will write out debug information, which will include a record of the ip/port packer attempts to connect up with using ssh during the provisioning process. Once you have that info, you should be able to ssh into the machine as well. Just make sure your done working on the system before the packer build process completes, because when that happens the box (usually) gets shutdown automatically.

@rickard-von-essen
Copy link
Collaborator

Run a shell provisioner that saves the IP in a file. Use a file provisioner to download it and read it in the shell-local script.

@sandersaares
Copy link
Contributor Author

@rickard-von-essen that's a good idea but this workaround does not necessarily work if the machine under build does not know its own reachable IP address (e.g. it is running in a cloud).

@rickard-von-essen
Copy link
Collaborator

The you probably have a cli that can find the external address.

@sandersaares
Copy link
Contributor Author

Right. The reason I filed this issue was because I was under the impression that Packer was a product designed to make such things easy and if such a feature was missing, its authors might want to add it. Perhaps I am mistaken in the purpose of Packer or the intended use of this issue tracker, as I cannot understand why you would close an issue that points out a missing feature.

@rickard-von-essen
Copy link
Collaborator

Oh sorry I taught I linked to another issue. I closed it since we decided explicitly to not include this feature.

See #3331. (I was mixing this up with the similar request in #4701)

@liberforce
Copy link

One year later, using the ansible provisionner is discouraged in favor of shell-local, so we need the IP address to call ansible by ourselves. #6179 has been implemented to get the WinRM password. I understand people don't want to break the communicator abstraction, but:

  1. Pushing a script on the remote machine
  2. Calling that script to store the ip to a file
  3. Downloading that file

...looks kind of hackish for a piece of information packer knows.

Could this be reopen?

@ladar
Copy link
Contributor

ladar commented Jun 5, 2018

Have you tried running:

 PACKER_LOG=1 packer build template.json

That will force packer to output additional information, including (I believe) the guest IP address (assuming it is able to discover the guest address). You can, of course, write the output to a file, for easier parsing, with:

set PACKER_LOG=1
set PACKER_LOG_FILE=log.txt
packer build template.json

Note, it's been awhile since I looked for this info, and different builders output different information. Not all of them output the guest IP address, but I think the HyperV provider does.

@liberforce
Copy link

liberforce commented Jun 5, 2018

@ladar : Thanks for your proposal, but this won't work in the case you want packer to call ansible so that the final image is generated and provisionned in one step. Doing it in a separate step is doable, and must be possible, but kind of defeats the purpose of packer.

@conradjones
Copy link

I could really use the IP of the guest to run server spec against the build. I don't want to install ruby and all the bits inside the build it's already on the host running the build ,all I need to make this work from a shell_local is the guest IP! Which packer knows! Could it not be exposed for the communicators / builders that it makes sense for and just be empty otherwise.

@ryudice
Copy link

ryudice commented Nov 12, 2018

This is so basic for a tool like packer, cant believe there is no way to do it without using workarounds.

@ghost
Copy link

ghost commented Mar 30, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants