Opened 12 years ago

Last modified 11 years ago

#23 assigned hostname mismatch

Reported by: Owned by:
Priority: major Milestone: IG-ADM-1
Component: Administration Version: SPIRAL4
Keywords: GEC14 Cc:


In public DNS (testing from BBN internal network), the control host is called

$ host has address

$ host
Host not found: 3(NXDOMAIN)

On the host itself, the hostname is

control,[~],21:48(0)$ hostname

control,[~],21:51(0)$ ifconfig | grep 155
          inet addr:  Bcast:  Mask:

This is likely to cause confusion, and should probably be standardized on either <site> or control.<site>

Change History (9)

comment:1 Changed 12 years ago by

Owner: changed from somebody to

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 11 years ago by

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., 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. '' rather than '' This is a small change, but hopefully, it is harder to mistake for ''.

comment:3 Changed 11 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

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 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 11 years ago by

Rob: the proposed change sounds fine to me. I also don't have a problem with The errors this ticket is reporting are:

  1. The A and PTR records don't match each other, which is now fixed:
    $ host has address
    $ host domain name pointer
  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
    Welcome to Ubuntu precise (development branch) (GNU/Linux 3.2.0-23-generic x86_64)
    $ hostname

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 11 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. 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 11 years ago by

As far as i know, this ticket is still active: still believes its hostname is, and the plan is still to fix that at some point.

comment:7 Changed 11 years ago by

This is still an issue:

[13:29:23] jbs@anubis:/home/jbs
+$ host has address

[13:30:32] jbs@anubis:/home/jbs
+$ host domain name pointer

[13:30:36] jbs@anubis:/home/jbs
+$ ssh hostname

Hmm, it's also a problem for the BBN rack:

[13:31:21] jbs@anubis:/home/jbs
+$ host has address

[13:31:36] jbs@anubis:/home/jbs
+$ host is an alias for 130.129/
130.129/ domain name pointer

[13:31:39] jbs@anubis:/home/jbs
+$ ssh hostname

Note that DNS thinks that it's, but the host thinks that its own name is

Rob, got a timeframe for fixing this?

comment:8 Changed 11 years ago by

Summarizing what i think the desired behavior is here: the point is that the control nodes should have their names in, 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>
  2. A PTR lookup on the control node's IP address yields <location>
  3. There is an A record for <location>
  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, there is no DNS record for, and the PTR record for the IP points to the mismatching name
  • BBN rack: assuming "gpolab" is an okay name for "bbn", only 2 needs to be fixed (the PTR record should point to, not to

comment:9 Changed 11 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> 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.