Reply
New Member
Posts: 13
Registered: ‎02-17-2017
Kudos: 1
Solutions: 1
Accepted Solution

CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

I am having a rather interesting problem with our CloudKey.  Obligatory version info below.

 

Firmware: 0.8.9

Controller: 5.6.29.0 (atag_5.6.29_10253)

 

We have a USG-PRO-4, USW switches, XG switches, and UAPs.

 

GOAL: To reach our CloudKey via 'https://foobar.domain.com'.

 

(Of note: I've successfully installed our SSL certificate on to the CloudKey... I think; I can't test it yet, which leads me to this post.  When accessing the Contoller via Chrome--via IP address--Chrome shows the cert, but presents the error that the cert is mismatched to the IP address, of course.)

 

Via the CloudKey web UI, I changed the CloudKey device name from the default 'unifi' to 'foobar'.

The CloudKey is set to a static IP, subnet, DNS, etc., with the primary DNS for the CloudKey set to the IP of the LAN1 native/management interface of the USG).

 

Via the Controller web UI, I have made the following changes in Settings:

- The domain for the network to which the CloudKey is connected (USG LAN1 native / management) is set to 'domain.com'.

- The Controller hostname/IP is set to 'foobar.domain.com'.

 

Enter weird behaviors.  From a management terminal...

- The command 'nslookup foobar.domain.com' returns a stale IP address of the CloudKey.

The command 'nslookup unifi' returns the proper IP address of the CloudKey.

- The command 'nslookup unifi.domain.com' returns 'server can't find unifi.domain.com: NXDOMAIN', with the server being the USG.

 

I have flushed the DNS cache of my management terminal and the USG.  I have power cycled the CloudKey and USG.  Information available via the Controller web UI and CloudKey web UI persists through restarts.

 

Via the CloudKey CLI, running the command 'hostname -f' returns the proper hostname (though not the FQDN) of 'foobar'. 

However, the command 'hostname -A' returns 'unifi'.

 

The CloudKey's /etc/hostname only contains 'foobar'.  I have not modified /etc/init.d/hostname/sh.

 

 

I've been fighting this issue for a couple of days now, and I can't seem to win the game of whack-a-mole.  Does anyone know how i can resolve this issue?


Accepted Solutions
New Member
Posts: 13
Registered: ‎02-17-2017
Kudos: 1
Solutions: 1

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

I solved my own problem, though not via the way I would have preferred.  And I figure I'd post the solution in case anyone else beats their head against a wall trying to tackle the same issue.

 

The USG DNS only works for DHCP clients.  So with the CloudKey set to a static IP, the USG DNS records were never updated with the revised CloudKey hostname.  I had two options: 1) set up our own local DNS or 2) flip the CloudKey back to a dynamicly-assigned IP, and set the CloudKey to receive the same IP from the USG in the Controller settings for the CloudKey.

 

I chose option 2 given that I have more pressing things on my to-do list, though I still plan on implementing our own DNS in the near future.  I would have preferred either to have the USG DNS support clients with static IP addresses or get our own DNS up and running sooner.

 

At any rate, problem solved for now.  

View solution in original post


All Replies
Established Member
Posts: 1,947
Registered: ‎10-26-2013
Kudos: 438
Solutions: 87

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

[ Edited ]

I have no idea why you are messing with the CK's actual name.

 

To get access to th econtroller and be able to have remote APs phone home, all one needs is internal DNS (a server, router, whatever can do it) pointing foobar.domain.com to the CK's LAN IP address, plus public DNS pointing that same foobar.domain.com to the perimeter firewall's WAN IP address, and port forwarding for the desired ports from WAN to LAN IP of the CK. After that, https://foobar.domain.com will resolve to the WAN IP from outside of one's network or to the CK's LAN IP if inside the network.

 

To make it even better, use local DNS to add a "unifi" CNAME and point it to the CK's public FQDN, and a local DNS entry of that public FQDN that points the "A" record to the CK's LAN IPaddress. That way, even a new or factory-reset AP will look for "unifi" and get the FQDN, which then points to the IP of the CK, making it will show up in the controller awaiting adoption (this may require checking "Make controller discoverable on L2 network"). In the controller, set the "Controller Hostname/IP" to the public FQDN. Now, take that same AP off of the LAN, and it will have the public FQDN in its inform URL and be able to phone home from anywhere.

Gregg

Regular Member
Posts: 643
Registered: ‎11-11-2017
Kudos: 148
Solutions: 37

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

Check the hosts file on the CK as it may have created an entry?

 

$> cat /etc/hosts

 

If there's a line in there, you can edit it out.

New Member
Posts: 13
Registered: ‎02-17-2017
Kudos: 1
Solutions: 1

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values


wrote:

I have no idea why you are messing with the CK's actual name.

 


Simply put: I'd prefer to keep our CloudKey hostname consistent with our network-wide naming convention for hosts.

 

As for /etc/hosts, this is the file:

 

127.0.0.1 localhost
127.0.1.1 foobar

 

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

 

Since we are not using DHCP for the CloudKey, the 127.0.1.1 line should be replaced with the static IP of the CloudKey, yes?

/etc/hostname contains only one line: foobar.

 

To further muddy the waters, here's another command output:

 

root@foobar:~# hostnamectl status
Static hostname: foobar
Icon name: computer
Chassis: n/a
Machine ID: <removed>
Boot ID: <removed>
Operating System: Debian GNU/Linux 8 (jessie)
Kernel: Linux 3.10.20-ubnt-mtk
Architecture: arm

 

Should I either remove or comment out the 127.0.1.1 line from /etc/hosts, or is there anything else that could be hanging me up?

Established Member
Posts: 1,947
Registered: ‎10-26-2013
Kudos: 438
Solutions: 87

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

[ Edited ]

"Simply put: I'd prefer to keep our CloudKey hostname consistent with our network-wide naming convention for hosts."

Ah, that makes sense. I thought you were thinking it was required to be able to get remote access to the CK. I named mine "Sparky" and I still can access it remotely or on the LAN via the public FQDN name and internal DNS that I noted above.

Gregg

New Member
Posts: 13
Registered: ‎02-17-2017
Kudos: 1
Solutions: 1

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

I now have the hostname responses returning the same value of 'foobar', but still the CloudKey shows up on the network with hostname 'unifi'.  I have tried editing some of the UniFi configuration files (e.g. unifi.init) in an attempt to change the advertised hostname on the network, but nothing has worked.

 

The issue continues to persist through power cycles of the CloudKey, and our DNS server (running on the USG-PRO).

 

Any other ideas, or do I need to acquiesce to having our CloudKey having a hostname of 'unifi'?

New Member
Posts: 13
Registered: ‎02-17-2017
Kudos: 1
Solutions: 1

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

I solved my own problem, though not via the way I would have preferred.  And I figure I'd post the solution in case anyone else beats their head against a wall trying to tackle the same issue.

 

The USG DNS only works for DHCP clients.  So with the CloudKey set to a static IP, the USG DNS records were never updated with the revised CloudKey hostname.  I had two options: 1) set up our own local DNS or 2) flip the CloudKey back to a dynamicly-assigned IP, and set the CloudKey to receive the same IP from the USG in the Controller settings for the CloudKey.

 

I chose option 2 given that I have more pressing things on my to-do list, though I still plan on implementing our own DNS in the near future.  I would have preferred either to have the USG DNS support clients with static IP addresses or get our own DNS up and running sooner.

 

At any rate, problem solved for now.  

Established Member
Posts: 1,947
Registered: ‎10-26-2013
Kudos: 438
Solutions: 87

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

[ Edited ]

Thank you for the follow-up. I use static IPs on my firewall, my switches, and my servers. Everything else is DHCP reservations or using plain DHCP. My CK has a reservation, as do my APs. That way, if I ever move the CK or an AP to another subnet, it just works with a simple change of the reservation...usually after the fact because I forget to do so beforehand.

Once you get your own internal DNS server, do my suggested steps and your life will be easier. Plop a new or reset AP onto your network, and it will show up awaiting adoption. Once adopted, it can be taken to a new site and will phone home.

Gregg

New Member
Posts: 7
Registered: ‎03-07-2016

Re: CloudKey CLI: 'hostname -f' and 'hostname -A' return different values

Shows up on network as unifi as its the unifi controller, I may be wrong about this but in the unifi controller settings under the tab "controller" you should be able to override inform host with controller hostname. I know that USG handles DNS, but I also know that if you want something like a "config.yaml" file to be implemented persistently it has to be on the CloudKey(Unifi Controller w/e) Unifi somewhere along the lines (im sure in the cloudkey) automatically points "unifi" to the "unifi controller" for inform purposes. e.g. devices being able to default to "http://unifi:8080/inform" for the SDN, provisioning, etc...

I think if you check the box to override inform host and put your IP directly here it may take care of your issue. I could be totally wrong too so back up your unifi controller before making any changes

Let me know if it works...
Reply