Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marten opened this issue Mar 20, 2013 · 3 comments
Labels

Comments

@marten
Copy link

marten commented Mar 20, 2013

$  ~/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
Copy link
Owner

tobami commented Mar 28, 2013

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
Copy link
Author

marten commented Mar 28, 2013

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
Copy link
Owner

tobami commented Mar 28, 2013

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.

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

No branches or pull requests

2 participants