CNAME not added if PXE iface is different from first one in DB

Bug #1116700 reported by Andres Rodriguez on 2013-02-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Jeroen T. Vermeulen
Jeroen T. Vermeulen
Jeroen T. Vermeulen

Bug Description

So on maas 1.2 auto generated hostnames are no longer MAC based. Both when adding a node *without* specifying a hostname through maas-enlist or the WebUI, the hostname generated is in the form of:


where nmewt is a random generated name.

What is even worse, is that no CNAME gets created for such hostname, causing that sthings such as juju, can't address to these nodes.

If we change the hostname to spomething not random... the new hostname does NOT get added as a CNAME on DNS.

However, DNS works by addressing to the hosts in the way of 'X-Y-Z-A.domian' being x.y.z.a the ip.

Some more info (which is additional/complementary to the issues we are seeing):

=== Tue, 05 Feb 2013 22:34:55 +0000: successfully enlisted to 'http://15.126.38.
10/MAAS/api/1.0/nodes/' with hostname '15-126-38-49'
    "status": 0,
    "macaddress_set": [
            "mac_address": "X"
            "mac_address": "Y1"
            "mac_address": "Z
    "netboot": true,
    "hostname": "qgre8.domain",
    "power_type": "ipmi",
    "system_id": "node-3a8865ae-6fe4-11e2-a412-78e7d1248dfd",

So it seems that if it tries to register itself with a hostname equal to a DNS name already in MAAS based on the IP, it will also generate a a random hostname.

Note that the random hostname is also generated if NO hostname is sent during enlistment.

this appears in celery.log don't know if related.

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/celery/execute/", line 47, in trace
    return cls(states.SUCCESS, retval=fun(*args, **kwargs))
  File "/usr/lib/python2.7/dist-packages/celery/app/task/", line 247, in __call__
    return*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/celery/app/", line 175, in run
    return fun(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/provisioningserver/", line 300, in remove_dhcp_host_map
  File "/usr/lib/python2.7/dist-packages/provisioningserver/", line 192, in remove
    raise CalledProcessError(returncode, "omshell", output)

Related branches

Changed in maas:
importance: Undecided → Critical
description: updated
description: updated
description: updated
description: updated
Julian Edwards (julian-edwards) wrote :

This ought to work, I personally tested this (and it was tested in the QA lab). Can you look at the region celery log for errors.

Changed in maas:
status: New → Incomplete
Julian Edwards (julian-edwards) wrote :

(the region worker is responsible for writing DNS entries)

Scott Moser (smoser) wrote :

I've tested locally and not been able to reproduce this. is what I did inside a new ubuntu instance.

After registering a node, I then see:
$ tail -n 4 /etc/bind/maas/zone.master
192-168-77-254 IN A
192-168-77-255 IN A
9cxp7 IN CNAME 192-168-77-6
xrqxm IN CNAME 192-168-77-5

$ host 192-168-77-6.master localhost | tail -n 1
192-168-77-6.master has address
$ host 9cxp7.master localhost | tail -n 2
9cxp7.master is an alias for 192-168-77-6.master.
192-168-77-6.master has address

Just to be clear, though:
$ host 9cxp7 localhost | tail -n 1
Host 9cxp7 not found: 3(NXDOMAIN)

Ie, I wasn't searching '.master' by default.

Searching further on that theme, I booted a new instance and dhcp'd from maas, and my /etc/resolv.conf contains:
   | # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
   | nameserver

sorely lacking there is 'search' entries for 'master'.
Then, checking /etc/maas/dhcpd.conf there is no 'domainname' or 'domain-search' entries.

It seems that we probably need one of those 2 things.

Julian Edwards (julian-edwards) wrote :

Well Andres said that no CNAME was generated, so let's see what logs he comes up with. In any case, yes, you need a "search" config at the least.

Andres Rodriguez (andreserl) wrote :

Ok so thanks to Julian, we found what the issue was. Currently, we were using eth2 for PXE. however, when it registers the node to maas it registers all the network interfaces for the node.

However, MAAS does the CNAME aggregation/mapping based on the first interface registered (this case eth1 - get_hostname_ip_mapping). The work around is to only make maas-enlsit register the interface where it PXE booted from, however, this is just a work around.

Thanks for all the help!

summary: - MAAS 1.2 no longer auto generates a MAC based hostname
+ MAAS doesn't add CNAME if PXE iface is different from first one in DB
summary: - MAAS doesn't add CNAME if PXE iface is different from first one in DB
+ CNAME not added if PXE iface is different from first one in DB
Julian Edwards (julian-edwards) wrote :

The problem exists in get_hostname_ip_mapping() in The SQL statement used restricts the matching MAC address to the first one it finds in the database for the node. JTV says he can fix this, so I'll assign it his way.

Changed in maas:
status: Incomplete → Triaged
assignee: nobody → Jeroen T. Vermeulen (jtv)
Jeroen T. Vermeulen (jtv) wrote :

Here's my impression and suggested solution:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers