Mapping a host to an IP using HostName in ssh/config breaks ssh #78

Closed
tobami opened this Issue Jan 5, 2012 · 11 comments

Comments

Projects
None yet
2 participants
@tobami
Owner

tobami commented Jan 5, 2012

Robin reported a problem on the discussion group.

If the ssh/config contains something like:

Host h1
    HostName <some_ip>
    User root 

fabric will not correctly resolve the host, because it uses host_string which LittleChef sets to h1.

That can be easily solved with the following patch:
https://github.com/tobami/littlechef/blob/1.1.0/littlechef/lib.py#L436

+    if 'hostname' in credentials:
+        credentials['host_string'] = credentials['hostname'] 

The problem is that from then on LittleChef will think that the node is called "some_ip", and will save a node file called "some_ip.json".

A better solution needs to be found to deal with this issue

@rweng

This comment has been minimized.

Show comment Hide comment
@rweng

rweng Jan 10, 2012

Even before that issue I was wondering why we store fqdns instead of IPs in the nodes/ directory. Sure, the IP is not unique either, but right now i have a couple of json files under nodes/ which all refer to the same machine. I probably don't get the concept right, can you enlighten me? What is the problem with the IP being stored in nodes/ instead of the fqdn?

Thanks, Robin

rweng commented Jan 10, 2012

Even before that issue I was wondering why we store fqdns instead of IPs in the nodes/ directory. Sure, the IP is not unique either, but right now i have a couple of json files under nodes/ which all refer to the same machine. I probably don't get the concept right, can you enlighten me? What is the problem with the IP being stored in nodes/ instead of the fqdn?

Thanks, Robin

@tobami

This comment has been minimized.

Show comment Hide comment
@tobami

tobami Jan 11, 2012

Owner

the thing is, the FQDN is unique, that's why Chef itself uses it.

When you say "IP being stored in nodes/", do you mean as the name of the node and its file? Apart from not being unique, that would mean that to configure a node you would have to select it by typing an IP instead of a hostname, which is pretty unconvenient.

If you meant to keep the node names but save the ip in the node file and always use that instead of the fqdn, that is possible. In fact, the IP is saved in the node file the first time it is created. It would only be required that the IP is used for the ssh connection...

Owner

tobami commented Jan 11, 2012

the thing is, the FQDN is unique, that's why Chef itself uses it.

When you say "IP being stored in nodes/", do you mean as the name of the node and its file? Apart from not being unique, that would mean that to configure a node you would have to select it by typing an IP instead of a hostname, which is pretty unconvenient.

If you meant to keep the node names but save the ip in the node file and always use that instead of the fqdn, that is possible. In fact, the IP is saved in the node file the first time it is created. It would only be required that the IP is used for the ssh connection...

@rweng

This comment has been minimized.

Show comment Hide comment
@rweng

rweng Jan 11, 2012

As you guessed I ment that the IP is the filename in the nodes/. If you do the name-resolution before, when you get the arguments, this shouldn't be a problem.

You fix above looks fine to me, I don't mind that in nodes/ the ip is stored, as long as I can continue using ´fix node:h1 ...`.

rweng commented Jan 11, 2012

As you guessed I ment that the IP is the filename in the nodes/. If you do the name-resolution before, when you get the arguments, this shouldn't be a problem.

You fix above looks fine to me, I don't mind that in nodes/ the ip is stored, as long as I can continue using ´fix node:h1 ...`.

@tobami

This comment has been minimized.

Show comment Hide comment
@tobami

tobami Jan 11, 2012

Owner

Bear in mind that the Chef repository in LittleChef is even more central than with a Chef server. It is your infrastructure as code, which means that you should be able to clone the repo and reproduce your infrastructure.

If you resolve the name first, the name of your nodes will depend on what ssh config you have locally on your computer. Another collaborator will "see" different things while using the exact same code, which is not good. That will happen to some degree once we fix this issue, but at least the node name will be independent of the local ssh config, all collaborators will use the same node "name" while referring to a particular node. That it afterwards could be resolved to another IP/Host still remains as a possibility, but it something that should be done with care.

Owner

tobami commented Jan 11, 2012

Bear in mind that the Chef repository in LittleChef is even more central than with a Chef server. It is your infrastructure as code, which means that you should be able to clone the repo and reproduce your infrastructure.

If you resolve the name first, the name of your nodes will depend on what ssh config you have locally on your computer. Another collaborator will "see" different things while using the exact same code, which is not good. That will happen to some degree once we fix this issue, but at least the node name will be independent of the local ssh config, all collaborators will use the same node "name" while referring to a particular node. That it afterwards could be resolved to another IP/Host still remains as a possibility, but it something that should be done with care.

@rweng

This comment has been minimized.

Show comment Hide comment
@rweng

rweng Jan 11, 2012

Hm, and here is where we disagree I guess. I am absolutely with you that cloning the repository should enable a collaborateur to reproduce the infrastructure. However, Having the IPs in the nodes/ folder seems to ensure that more than having dynamic names in there. The dynamic resolution can easily be different on different nodes. /etc/hosts could point to a different machine, especially when dealing with private networks. Or the DNS results could be different at a different point in time or place.

Having the static IPs in the nodes/ folder seems better (to me) for reproducing the infrastructure.

But independent of this personal preference: An error message when HostName contains an IP would be enough, I guess. Alternatively, we could maybe utilize reverse address resolution to find an fqdn. But since one IP usually has several fqdn (domain.com, www.domain.com, otherdomain.com), it would be hard to decide which one to use in the nodes folder. So an error message is the only way I see as long as you don't want to have a filename with the IP.

rweng commented Jan 11, 2012

Hm, and here is where we disagree I guess. I am absolutely with you that cloning the repository should enable a collaborateur to reproduce the infrastructure. However, Having the IPs in the nodes/ folder seems to ensure that more than having dynamic names in there. The dynamic resolution can easily be different on different nodes. /etc/hosts could point to a different machine, especially when dealing with private networks. Or the DNS results could be different at a different point in time or place.

Having the static IPs in the nodes/ folder seems better (to me) for reproducing the infrastructure.

But independent of this personal preference: An error message when HostName contains an IP would be enough, I guess. Alternatively, we could maybe utilize reverse address resolution to find an fqdn. But since one IP usually has several fqdn (domain.com, www.domain.com, otherdomain.com), it would be hard to decide which one to use in the nodes folder. So an error message is the only way I see as long as you don't want to have a filename with the IP.

@tobami

This comment has been minimized.

Show comment Hide comment
@tobami

tobami Jan 11, 2012

Owner

ok, I'll give this more thought

Owner

tobami commented Jan 11, 2012

ok, I'll give this more thought

tobami added a commit that referenced this issue Jan 22, 2012

@tobami

This comment has been minimized.

Show comment Hide comment
@tobami

tobami Jan 22, 2012

Owner

In a branch called ssh_hostname_resolution (linked above), I have implemented a fix for this, but I am unsure whether that satisfies your request.

What I did is to add the patch outlined in this issue's description. When configuring a node what happens is the following:

  • The node file is saved/read as nodes/h1.json
  • SSH config is used, name resolution takes place, and the IP is used in place of h1 to connect to the node

The only drawback is that when building the automatic node databag (for node search) the merged attributes of each node will have as FQDN value the name you gave to the node, that is h1.

If that is fine by you then I can merge the branch and close the issue.

Owner

tobami commented Jan 22, 2012

In a branch called ssh_hostname_resolution (linked above), I have implemented a fix for this, but I am unsure whether that satisfies your request.

What I did is to add the patch outlined in this issue's description. When configuring a node what happens is the following:

  • The node file is saved/read as nodes/h1.json
  • SSH config is used, name resolution takes place, and the IP is used in place of h1 to connect to the node

The only drawback is that when building the automatic node databag (for node search) the merged attributes of each node will have as FQDN value the name you gave to the node, that is h1.

If that is fine by you then I can merge the branch and close the issue.

@rweng

This comment has been minimized.

Show comment Hide comment
@rweng

rweng Jan 23, 2012

Sounds like a very acceptable solution to me. Thank you!

rweng commented Jan 23, 2012

Sounds like a very acceptable solution to me. Thank you!

@rweng

This comment has been minimized.

Show comment Hide comment
@rweng

rweng Feb 8, 2012

Can you merge this in? I just stumbled accross the same thing.

rweng commented Feb 8, 2012

Can you merge this in? I just stumbled accross the same thing.

@tobami

This comment has been minimized.

Show comment Hide comment
@tobami

tobami Feb 8, 2012

Owner

yeah, sorry about the delay. I wanted to check it out in an environment where i use ssh config extensively, but I do not seem to find the time

Owner

tobami commented Feb 8, 2012

yeah, sorry about the delay. I wanted to check it out in an environment where i use ssh config extensively, but I do not seem to find the time

@tobami

This comment has been minimized.

Show comment Hide comment
@tobami

tobami Feb 14, 2012

Owner

Closed by e1f53f0

Owner

tobami commented Feb 14, 2012

Closed by e1f53f0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment