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

[tobami]

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]

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]

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]

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...

[tobami]

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]

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]

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]

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.

[tobami]

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]

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]

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]

ok, I'll give this more thought

[tobami]

ok, I'll give this more thought

[tobami]

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.

[tobami]

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]

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

[rweng]

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

[rweng]

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

[rweng]

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

[tobami]

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]

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]

Closed by e1f53f0

[tobami]

Closed by e1f53f0