knife ssh using incorrect hostname

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.9.8
  • Fix Version/s: 10.14.0
  • Component/s: Knife
  • Labels:
    None
  • Environment:

    Ubuntu on EC2

Description

I'm using the Opscode Platform with Knife, and the ssh subcommand is broken. Here's an example of the output:

$ knife ssh -l debug name:i-b9e468d3
DEBUG: Using configuration from /Users/bhelmkamp/p/active/e20_chef_repo/.chef/knife.rb
DEBUG: Signing the request as bhelmkamp
DEBUG: Sending HTTP Request via GET to api.opscode.com:443/organizations/efficiency20/search/node
DEBUG: Adding ip-10-204-103-221.ec2.internal
/Users/bhelmkamp/.rvm/gems/ree-1.8.7-2010.01/gems/net-ssh-2.0.23/lib/net/ssh/transport/session.rb:65:in `initialize': getaddrinfo: nodename nor servname provided, or not known (SocketError)

Looks like somewhere along the way it's getting confused and using the EC2 internal hostname instead of the public one. Any ideas? Not sure if this is an issue with Knife or the Opscode Platform.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. CHEF-922 knife ssh should accept -a ec2.public_hostname

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. CHEF-3433 knife ssh does not work

  • Unknown - Issue untriaged, priority unassigned or questioned
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. CHEF-3439 use knife[:ssh_attribute] for override

  • Unknown - Issue untriaged, priority unassigned or questioned
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Michael D. Ivey added a comment -

This is the expected behavior, although it's surprising. EC2 instances use the internal host address as the hostname, which means ohai/node data has the internal address.

You can add '-a ec2.public_hostname' to tell knife which piece of the node data to use as the hostname.

Show
Michael D. Ivey added a comment - This is the expected behavior, although it's surprising. EC2 instances use the internal host address as the hostname, which means ohai/node data has the internal address. You can add '-a ec2.public_hostname' to tell knife which piece of the node data to use as the hostname.
Hide
Permalink
Chris Williams added a comment -

It would be nice if the knife ssh command could handle this automatically. I have a combination of ec2 nodes and regular datacenter nodes that I'd like to be able to run knife ssh on all nodes with one command.

Show
Chris Williams added a comment - It would be nice if the knife ssh command could handle this automatically. I have a combination of ec2 nodes and regular datacenter nodes that I'd like to be able to run knife ssh on all nodes with one command.
Hide
Permalink
Chris Williams added a comment -

for anyone who wants knife to handle it automatically, i ended up patching the knife/ssh.rb file
and added the following to the configure_session method, above the line "i = format_for_display(item)[config[:attribute]]"

if config[:attribute] == "fqdn" && item["ec2"] && item["ec2"]["public_hostname"]
config[:attribute] = "ec2.public_hostname"
end

Show
Chris Williams added a comment - for anyone who wants knife to handle it automatically, i ended up patching the knife/ssh.rb file and added the following to the configure_session method, above the line "i = format_for_display(item)[config [:attribute] ]" if config [:attribute] == "fqdn" && item ["ec2"] && item ["ec2"] ["public_hostname"] config [:attribute] = "ec2.public_hostname" end
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

The initial -a support was added in CHEF-922.

A patch was submitted to add support to use cloud.public_hostname if cloud was populated. The author needs a CLA before we can go much further with it. However, much discussion should be had as to if we want to default to that attribute. We will definitely still want to be able to override it with -a.

https://github.com/opscode/chef/pull/340

Show
Bryan McLellan [Opscode] added a comment - The initial -a support was added in CHEF-922 . A patch was submitted to add support to use cloud.public_hostname if cloud was populated. The author needs a CLA before we can go much further with it. However, much discussion should be had as to if we want to default to that attribute. We will definitely still want to be able to override it with -a. https://github.com/opscode/chef/pull/340
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Resolving for Takeshi Kondo, as he now has a completed CLA.

Show
Bryan McLellan [Opscode] added a comment - Resolving for Takeshi Kondo , as he now has a completed CLA.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

I sent a note to the chef list asking for opinions.

As this is written it will choose node[:cloud][:public_hostname] whenever node[:cloud] is populated and will not allow you to override this setting. This needs to be refactored, probably into #configure_attribute.

A couple rspec unit tests should also be added:

it "should use [:cloud][:public_hostname] if [:cloud] exists"
it "should allow you to specify an attribute even if [:cloud] exists"

Show
Bryan McLellan [Opscode] added a comment - I sent a note to the chef list asking for opinions. As this is written it will choose node [:cloud] [:public_hostname] whenever node [:cloud] is populated and will not allow you to override this setting. This needs to be refactored, probably into #configure_attribute . A couple rspec unit tests should also be added: it "should use [:cloud] [:public_hostname] if [:cloud] exists" it "should allow you to specify an attribute even if [:cloud] exists"
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Consensus on the mailing list was to default to a cloud attribute if available. We should check to make sure that public_hostname is also populated. However, we need to ensure that we can override the value. I'll try work on this later if nobody gets to it.

Show
Bryan McLellan [Opscode] added a comment - Consensus on the mailing list was to default to a cloud attribute if available. We should check to make sure that public_hostname is also populated. However, we need to ensure that we can override the value. I'll try work on this later if nobody gets to it.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Merged. I've modified this to prefer 'knife ssh -a foo' even if a cloud attribute is available, and added an initial set of knife ssh unit tests to cover this code.

Show
Bryan McLellan [Opscode] added a comment - Merged. I've modified this to prefer 'knife ssh -a foo' even if a cloud attribute is available, and added an initial set of knife ssh unit tests to cover this code.

People

  • Assignee:
    Unassigned
    Reporter:
    Bryan Helmkamp
Vote (2)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: