Opened 13 years ago
Last modified 12 years ago
#23 assigned
utah.control.geniracks.net hostname mismatch
Reported by: | chaos@bbn.com | Owned by: | ricci@cs.utah.edu |
---|---|---|---|
Priority: | major | Milestone: | IG-ADM-1 |
Component: | Administration | Version: | SPIRAL4 |
Keywords: | GEC14 | Cc: | |
Dependencies: |
Description
In public DNS (testing from BBN internal network), the control host is called utah.control.geniracks.net
:
$ host utah.control.geniracks.net utah.control.geniracks.net has address 155.98.34.2 $ host control.utah.geniracks.net Host control.utah.geniracks.net not found: 3(NXDOMAIN)
On the host itself, the hostname is control.utah.geniracks.net
:
control,[~],21:48(0)$ hostname control.utah.geniracks.net control,[~],21:51(0)$ ifconfig | grep 155 inet addr:155.98.34.2 Bcast:155.98.34.255 Mask:255.255.255.0
This is likely to cause confusion, and should probably be standardized on either <site>.control.geniracks.net
or control.<site>.geniracks.net
.
Change History (9)
comment:1 Changed 13 years ago by
Owner: | changed from somebody to ricci@cs.utah.edu |
---|
comment:2 Changed 12 years ago by
Keywords: | GEC14 added |
---|---|
Status: | new → assigned |
The issue here is that we *do* need hostnames that resolve to these nodes that are outside of the rack's domain (eg. utah.geniracks.net), since boss VM is the nameserver for the rack, and we need to be able to resolve them for maintenance purposes even when the boss VM isn't up.
What we will do is change those 'outside' hostnames slightly to try to reduce confusion - eg. 'utah-control-node.geniracks.net' rather than 'utah.control.geniracks.net' This is a small change, but hopefully, it is harder to mistake for 'control.utah.geniracks.net'.
comment:3 Changed 12 years ago by
Rob, a general question about this: Are you expecting that all of the hosts on the racks, at places other than Utah, will be in subdomains of geniracks.net?
I think that isn't what we'd been expecting; I think we'd been expecting that the rack at Clemson would have hostnames in clemson.edu. Optionally with whatever CNAMEs you like, but that site admins would put them within their site's namespace, in general. (Into a subdomain, presumably, so that the subdomain can be delegated to the boss node.)
comment:4 Changed 12 years ago by
Rob: the proposed change sounds fine to me. I also don't have a problem with utah.control.geniracks.net. The errors this ticket is reporting are:
- The A and PTR records don't match each other, which is now fixed:
$ host utah.control.geniracks.net utah.control.geniracks.net has address 155.98.34.2 $ host 155.98.34.2 2.34.98.155.in-addr.arpa domain name pointer utah.control.geniracks.net.
- The PTR record doesn't match what the host thinks its own name is, which i think is still an issue, albeit a more minor one:
$ ssh utah.control.geniracks.net Welcome to Ubuntu precise (development branch) (GNU/Linux 3.2.0-23-generic x86_64) $ hostname control.utah.geniracks.net
We like standardization because it makes it easier for the uninitiated to find things, but don't feel strongly about what you standardize on.
That said, one nice thing about 'utah-control-node' as the name part, is that it puts more information into a default shell prompt.
comment:5 Changed 12 years ago by
I had forgotten about the state of this, which is that Rob does plan to have a canonical name for each control node. He points out that this canonical name needs to be outside of the rack's domain (e.g. utah.geniracks.net in this case) because the nameserver for the rack's domain is boss (which depends on the control node).
Anyway, he is actively working on cleaning this up, both in the case of having a general naming plan, and in the specific case of the Utah rack. So it is fine for this ticket to remain open.
comment:6 Changed 12 years ago by
As far as i know, this ticket is still active: utah.control.geniracks.net still believes its hostname is control.utah.geniracks.net, and the plan is still to fix that at some point.
comment:7 Changed 12 years ago by
This is still an issue:
[13:29:23] jbs@anubis:/home/jbs +$ host utah.control.geniracks.net utah.control.geniracks.net has address 155.98.34.2 [13:30:32] jbs@anubis:/home/jbs +$ host 155.98.34.2 2.34.98.155.in-addr.arpa domain name pointer utah.control.geniracks.net. [13:30:36] jbs@anubis:/home/jbs +$ ssh utah.control.geniracks.net hostname control.utah.geniracks.net
Hmm, it's also a problem for the BBN rack:
[13:31:21] jbs@anubis:/home/jbs +$ host control.instageni.gpolab.bbn.com control.instageni.gpolab.bbn.com has address 192.1.242.130 [13:31:36] jbs@anubis:/home/jbs +$ host 192.1.242.130 130.242.1.192.in-addr.arpa is an alias for 130.129/25.242.1.192.in-addr.arpa. 130.129/25.242.1.192.in-addr.arpa domain name pointer control.instageni.gpolab.bbn.com. [13:31:39] jbs@anubis:/home/jbs +$ ssh control.instageni.gpolab.bbn.com hostname gpolab.control-nodes.geniracks.net
Note that DNS thinks that it's control.instageni.gpolab.bbn.com, but the host thinks that its own name is gpolab.control-nodes.geniracks.net.
Rob, got a timeframe for fixing this?
comment:8 Changed 12 years ago by
Summarizing what i think the desired behavior is here: the point is that the control nodes should have their names in control-nodes.geniracks.net, because they should still work fine if the boss VM (which hosts the DNS server) is down. So the desired outcome is:
- The control node thinks its own name is
<location>.control-nodes.geniracks.net
- A PTR lookup on the control node's IP address yields
<location>.control-nodes.geniracks.net
- There is an A record for
<location>.control-nodes.geniracks.net
- There may or may not also be a DNS record for
control.<location_fqdn>
. IMO, it should be a CNAME (rather than an A record) for maximum DNS cleanliness, but that's really minor, and not worth keeping this ticket over either way.
If that's the desired outcome, then the current state is:
- Utah rack: 1, 2, and 3 need to be fixed: the host thinks its name is
control.utah.geniracks.net
, there is no DNS record forutah.control-nodes.geniracks.net
, and the PTR record for the IP points to the mismatching nameutah.control.geniracks.net
. - BBN rack: assuming "gpolab" is an okay name for "bbn", only 2 needs to be fixed (the PTR record should point to gpolab.control-nodes.geniracks.net, not to control.instageni.gpolab.bbn.com.
comment:9 Changed 12 years ago by
Just to clarify, i was proposing a concrete plan because i thought we sort of had one in mind and hadn't written it down. More generally than the above, i think what we'd like to see is:
- The self-configured naming scheme (what "hostname" returns) for the control node is consistent across racks: if the Utah control node thinks its name is "FOOutahBAR" then the BBN control node thinks its name is "FOObbnBAR" (or "FOOgpolabBAR")
- The DNS PTR record for the IP points to same name as what "hostname" returns
- There is a DNS A record from the name "hostname" returns, which points to the IP
Basically that just amounts to "the hostname should be defined consistently". Any name spec that meets that is fine with us --- i just mentioned <location>.control-nodes.geniracks.net
because it's what i thought Utah had settled on (via e-mail; this ticket doesn't say).
Update: this came up in Wednesday's call, and we think it's on Rob's plate. It should be easy to resolve, and there is no rush on it.