Skip to content
This repository has been archived by the owner on Feb 11, 2022. It is now read-only.

Avoid connection with AWS for SSH shell vagrant provision #551

Open
jacace opened this issue Aug 8, 2018 · 2 comments
Open

Avoid connection with AWS for SSH shell vagrant provision #551

jacace opened this issue Aug 8, 2018 · 2 comments

Comments

@jacace
Copy link

jacace commented Aug 8, 2018

Hello colleagues,

For some reason the command below connects with AWS to execute a SSH direct command:
vagrant provision --provision-with shell
I believe this is to retrieve the public hostname.

I believe this is not really necessary since the hostname could be retrieved from the Vagrantfile param config.vm.hostname or even from a input command line param e.g.:
vagrant provision --provision-with shell --hostname=abc

This has the benefits below:

  • Faster command execution.
  • Connectivity to existing instances not created with vagrant.
  • Not need to know the AWS access and secret keys since no connectivity to AWS would be needed.

I did a quick test unsuccessfully (due to the fact that connection information it seems to be all around the place) by commenting out the ruby source code line where the AWS creds are tested in file .vagrant.d\gems\2.4.4\gems\fog-aws-2.0.1\lib\fog\aws\compute.rb as follows:
@host = "host name or IP address"
#Fog::AWS.validate_region!(@region, @host)

But it later breaks in line 103 in function of file \.vagrant.d\gems\2.4.4\gems\excon-0.62.0\lib\excon\socket.rb when it tried to translate the hostname to IP address info
addrinfo = ::Socket.getaddrinfo(*args)

So having that said, may I ask?

  1. Could an AWS-less vagrant provision be considered for a potential new feature?
  2. Whether the answer to the previous ask is yes or not, how can currently hack it to be able to provide the hostname to avoud any connectivity with AWS?

Thanks,

Javier Caceres

@jacace
Copy link
Author

jacace commented Aug 8, 2018

Just to mention that another benefit (if request here is possible) is that one could give a user a local username and password of an existing VM instead of sharing keys, etc.

@naviat
Copy link

naviat commented Jan 8, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants