ascalonx's picture

I'm trying to figure out how to get my appliance to register its hostname with the dns server (much like windows does).  From what I've found online, it appears a standard Ubuntu install uses the dhcp-client3 package for its dhcp client and this has configurations that can be made via /etc/dhcp3/dhclient3.conf to send the hostname when requesting dhcp.

However, it seems that there is no /etc/dhcp3 folder on my appliance, so I can only assume that dhclient3 is not being used as the dhcp client.  Is there another place to make this kind of configuration?

Thanks,

Dusty

Forum: 
Liraz Siri's picture

Sorry its taken this long to get back to you. We're in the middle of a new release (2009.02) and it's been a bit hectic.

Ubuntu comes with dhcp3-client by default, but we've decided to go with udhcpc as our default dhcp client because it is simpler and smaller while still providing most of dhcp3's functionality.

If you like you can remove udhcpc and install dhcp3-client instead:

$ apt-get remove udhcpc
$ apt-get install dhcp3-client
On the other hand, for the purpose of registering/requesting a hostname during dhcp, they are both configured in the same way - in /etc/network/interface. See section "The dhcp method" in the manual page:
$ man interfaces
In a nutshell, you just have to add the hostname parameter to your configuration like this:
$ cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
   hostname myhostname # hostname to be requested

Hope this helps!
Jeremy Davis's picture

This is a really old thread so likely doesn't apply anymore.

After having a quick look on https://packages.debian.org/ I can confirm that the dhcp3-client package no longer exists. The only package with a similar name (and somewhat similar function - at least on face value) is isc-dhcp-client. I haven't looked at it closely though, so I'm not 100% sure if it's the same software (just with a new package name) and/or whether it fulfils the same functionality.

Sorry that I can't provide any more clarity.

Jeremy Davis's picture

DHCP is handy for roaming computers, end-user environments (such as home networks) and developemnt/testing servers but for a static server farm (even if virtual) I prefer to hard code IPs and set those in my nameserver (DNS). Avoiding DHCP (where practical) is a great way of eliminating one potential problem.

Jeremy Davis's picture

Firstly, apologies on the slow response. And thanks for the feedback Aaron. I have opened a new issue on our tracker noting the specific ideas/suggestions that I've extracted from your post. Obviously feel free to further clarify (here and/or over there) if you wish. I did initially pin it to the v17.0 milestone, but I moved it to v17.1 as I think that's more realistic.

To explicitly respond to your points:

I [...] wish that DHCP would advertise the proper HOSTNAME by default [...]

Yep, that would be great. Although it is software dependant. As I noted earlier in this thread, part of this is the tension between all the different users and user environments we have; plus trying to balance functionality against keeping TurnKey as slim, light-weight and performant as possible.

As I hinted previously in this thread, the "proper" way to "fix" this is (particularly in production), is to manually configure DNS. That is seriously the most robust and reliable way to ensure that your server resolves via the desired hostname.

It does seem that including/adding the "hostname" to the relevant interface in the interfaces file "should" (might?) fix this. Although that still depends on your DHCP server, which is obviously outside of the control of Turnkey.

FWIW, a lot of devices these days use zeroconf to broadcast "hostname" info which is (somewhat) independent of DHCP/DNS. We could pre-install something like that, but that would be counter productive for production servers so doesn't really make sense.

Although we could (should!?) document it? This appears to be of interest to you, so doing some research and testing of installing and setting up zeroconf would be really appreciated. FWIW the software to install on Debian is called Avahi. The Debian wiki can be a bit hit and miss (sometimes it's really good info, sometimes really old and out of date) but from a glance, the Avahi page.

Once we have a clear and confirmed path to install and configure this, then perhaps we could even look at implementing a Confconsole plugin to set that up?!

I don't understand why we need to set the hostname in multiple places.

"hostname" has multiple contexts. And there is no reason why you couldn't have an internal hostname, an external hostname, and for example a different mailhost hostname, webserver hostname that matches the external hostname, etc.

In the context that you seem to be using it, it is the network name that can be used to connect to the server. But it is common that the server might use a different hostname internally. It's worth noting here that "localhost' is perhaps the most common hostname used internally on your server. In your use case, you want/need an authoritative source of hostname. That is why I say that explicitly settings it in DNS is the "proper" way in production.

violation of 'Normalization' in my head. Why the redundancy?

It's the result of the fact that Linux is an amalgam of modular components, built by a range of different developers with a range of different end goals; all "glued" together. Lots of the software is built by volunteers who are scratching their own itch and as such prioritise their own needs. It doesn't really have any centralised controller/designer like Windows or Mac OSX do.

Then on the other side (e.g. routers, modems, wifi modules, other computers and IoT devices, etc), most of the services (e.g. DNS, DHCP, etc) have multiple and competing "standards" and implementations of those standards. Some features of one implementation (say the zeroconf/Bonjour stuff by Apple) then goes on to become a defacto standard that others implement. Often unoffical implementations are reverse engineered, so may not even work quite the same as the "official" implementation.

On the downside, that does mean that there may be a multitude of ways to achieve an end. It also means that some scenarios require customisation and/or config tweaks to get to the end goal. It's not uncommon that things don't "just work" OOTB.

On the plus side, there is lots of choice and lots of room for customisation and configuration. It's especially valuable for tinkerers and/or those that wish to configure their systems in a specific way.

In essence TurnKey aims to soften the downsides, whilst not diluting the upsides.

Is it REALLY true that using the confconsole to set 'System Settings' and then 'Hostname' doesn't properly configure the value in /etc/networking/interfaces?

It will update it if it's noted in the interfaces file. It also updates the /etc/hostname file and adds it/updates the /etc/hosts file. It also updates postfix hostname (the local MTA). I t doesn't update it anywhere else or for any other services.

Can we get this fixed?

Well I guess we could preconfigure a hostname in the interfaces file? That's probably not a bad idea...

and MY biggest gripe is this. When I goto SET the hostname in the CONFCONSOLE, it would be REALLY convienent to know what the existing hostname value was. Right now, I have to exit out of the confconsole, and then go lookup the hostname (in multiple places, I guess) and then go back into the confconsole and then set the hostname? It would be SOOOOOOO much nicer if choosing 'System Settings' and then 'Hostname' actually displayed the CURRENT (or should I say PREVIOUS) hostname before needing to set it again? I don't want to change the hostname if it already follows my naming convention (I name all my machines based on the name of the virtual machine in HyperV).

Yep, we could do that too.

Jeremy Davis's picture

You've likely already worked this out by now, but it's /etc/network/interfaces (note network, not networks).

Also, a tip for moving around the file system from the commandline is to use tab complete (i.e. using the Tab key to complete commands and paths). E.g. to view the interfaces file, try this:

cat /e<Tab>/net<Tab>/in<Tab>

Will produce:

cat /etc/network/interfaces

If nothing happens when you hit the Tab key, either type another letter, or hit Tab again to view all possibilities. The tab complete also works for commands.

Add new comment