Created
July 30, 2012 00:22
-
-
Save jclouds/3202856 to your computer and use it in GitHub Desktop.
hostname approach
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Here's an approach to ensure at least 2 things are sensible on the host: ${hostname} and ${fqdn} | |
if ${hostname} is not specified via api, it could be set to the same as the node's name | |
in private clouds, ${fqdn} may need to come from a property or a conversion fn (ex. = ${hostname}.mydomain.com) | |
in public clouds, ${fqdn} can be set via api data (ec2.publicDnsName), dns resolution, or x-x-x-x.static.cloud-ips.com | |
on (centos|fedora|rhel|amzn_linux)-based operating systems | |
/etc/sysconfig/network: replace line HOSTNAME=${fqdn} | |
/proc/sys/kernel/hostname: replace w/${fqdn} | |
on (debian|ubuntu)-based operating systems | |
/etc/hostname: replace w/${hostname} | |
exec hostname ${hostname} | |
on all | |
/etc/hosts: add or replace line ^127.0.0.1 localhost.localdomain localhost ${hostname} | |
/etc/hosts: add or replace line ^${public_ip} ${fqdn} ${hostname} | |
/etc/hosts: add or replace line ^${private_ip} ${hostname} | |
before attempting to run this script, the input data should be checked to ensure it is valid: | |
ex. run InternetDomainName.isValid on ${fqdn} | |
A test could be to logon to the machine and make sure ${fqdn} resolves to ${public_ip} and ${hostname} to ${private_ip} |
+1 for implementing this approach
manual dns is a horrible hack, and I will help propagate that hack in tools that desire it, just not as a part of the same script.
remember the sysadmin's decree "do not add hair to the yak! I repeat do not add hair to the yak!"
On the yakkier bit, I'm going to quiz openstack-infra a bit about how they handle this for their jenkins stuff right now. They use puppet, which is pretty fqdn sensitive (ssl certificates and all). Maybe there's an option we can make that doesn't presume tools like whirr know about all machines (ex the puppetmaster) who also need to resolve the new nodes.
On the less yakkier bit, I'll start on it tonight :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't have an aversion to pushing the /etc/hosts fix to tools like Whirr that actually care about it. Seems reasonable.