Opened 8 years ago

Last modified 7 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 8 years ago by chaos@bbn.com

Owner: changed from somebody to ricci@cs.utah.edu

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.

comment:2 Changed 8 years ago by ricci@cs.utah.edu

Keywords: GEC14 added
Status: newassigned

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 8 years ago by jbs@bbn.com

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 8 years ago by chaos@bbn.com

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:

  1. 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.
    
  2. 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 8 years ago by chaos@bbn.com

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 7 years ago by chaos@bbn.com

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 7 years ago by jbs@bbn.com

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 7 years ago by chaos@bbn.com

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:

  1. The control node thinks its own name is <location>.control-nodes.geniracks.net
  2. A PTR lookup on the control node's IP address yields <location>.control-nodes.geniracks.net
  3. There is an A record for <location>.control-nodes.geniracks.net
  4. 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 for utah.control-nodes.geniracks.net, and the PTR record for the IP points to the mismatching name utah.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 7 years ago by chaos@bbn.com

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

Note: See TracTickets for help on using tickets.