Running deploy_chef on a node which cannot resolve its own hostname sets up wrong apt source

[marten]

$  ~/rgoc/chef git:(2409m|littlechef✗) fix node:10.210.100.23 deploy_chef                                                                     Are you sure you want to install Chef 0.10 on node 10.210.100.23, using "sudo: unable to resolve host stag-test1.roqua.nl
lucid" packages? [Y/n] y
Setting up Opscode repository...
Error while executing 'apt-get install chef':

Fatal error: sudo: unable to resolve host stag-test1.roqua.nl
E: Type 'lucid-0.10' is not known on line 2 in source list /etc/apt/sources.list.d/opscode.list

Which is because it set up this as the apt source:

root@stag-test1:/etc/apt/sources.list.d# cat opscode.list
deb http://apt.opscode.com/ sudo: unable to resolve host stag-test1.roqua.nl
lucid-0.10 main

[tobami]

Is a node which cannot resolve its own hostname in a useful state at all?

What is happening is that the distro name is set to "sudo: unable to resolve host stag-test1.roqua.nl", which happens when executing lsb_release -cs

So how should we solve this in a way that is not a hack?

[marten]

Well sure, we need to look at our provisioning scripts to make sure the hostname for the new node gets added to the hosts file so it can resolve itself. That said, I assume the sudo warning is being written to STDERR, in which case passing combine_stderr=False to the call to sudo might fix it?

[tobami]

We could do that, then examine stderr, and if it's not empty we abort. Problem would be if it is a warning going to stdout.