Can we drop the append domain names to the host setting?

Hello there,

as part of simplifying the Foreman configuration, I’d like to ask whether it would hurt if we remove the “Append domain names to the host” from Settings → General.

The only use of it is in the host form where it automatically appends the selected domain name to the host FQDN. It is known to cause problems with Ansible roles run.I found @James_Shewey is using it according to this, James do you have any insights for the use case and the need? If I’m not missing anything, it’s just about hiding the (potentially made up) domain in the host list, which may be nice in some smaller setups.

Thanks for any comments, if we don’t find a good use, we’d deprecate this in 3.4 and drop in 3.5.

1 Like

First of all, the setting is defined here:

When you say drop the setting, do you mean making the behavior match the current default value (true)?

Then my understanding of the feature: if you set this to false, your database will have hosts only by their short name: myhost instead of myhost.example.com.

Then some more related matters. I know we also have a problem with this in the installer and the host registration (which was introduced in Foreman 3.1 via Feature #33789: Mark host where the installer is running as foreman when deploying foreman - Installer - Foreman). Here it assumes the host is the FQDN but that fails if hosts within Foreman are registered without a domain:
puppet-foreman/register.pp at e0fc1487740d36a5a308498576836525d3e52de1 · theforeman/puppet-foreman · GitHub

A similar problem shows up on the Smart Proxy registration:

We can work around it, but it’d be ugly.

That said, this did show up within Satellite so I believe it was a customer who was using it. Their use case was that they moved systems around and changed their domain names and hosts ended up being duplicated. I think that by having the short name in Foreman, Puppet certificates (and probably others) end up having a short name as well. That was their way to work around it.

IMHO having all hosts properly registered with their FQDN is a good thing, but the use case of changing the domain can be a good one.

In particular for Puppet, there is an option to generate the certificate name as an UUID which removes the hostname from the equation altogether. IMHO that’s a good solution when the hostname is unstable. Perhaps there are more cases that could be solved in a similar manner.

Then there is also the matter of migration. Does it mean all hosts in the existing databases need to be appended a domain? Can we do this automatically? Would things break?

So in short: I’d be in favor of deprecating and removing this setting if we can still account for the use cases (which I believe we can) and have a proper migration strategy.

I would also hope to not need the setting. But I know different environments where the same hostname but a different domainname is used in the different stages, so we should change the behaviour to the same as the setting being true. On the other side I also have environments where in general the FQDN is used, but for some reasons in e.g. VMware not.

So in general I agree with the proposed change and Ewoud’s additions, but I fear we will find someone who is unhappy with it.

Yes, as that’s what most users have.

Not necessarily but very likely. You can still have FQDN in the name, this setting really is about what is stored by default to the host name attribute, whether’s it’s its shortname or FQDN. One can still enter the FQDN into the host name text field.

In case we want to solve the migration, this could be quite straightforward for managed hosts. We’d append the the domain of the primary interface or even better, we’d drop the setting (and make it always on) and refresh host names using the NameSynchronizer. I don’t think it’s ever realistic to list what all may break, important thing is, we still have access to shortname and FQDN. If we need to add additional layer somewhere, we can still do it, e.g. like with the certname attribute for Puppet certificate.

I’d though argue that given we already have this as a setting and user may flip this at any time, it should not be breaking anything dramatically. And also that it’s like we enabled the Setting for everyone and remove the option to drop it. It would be good to test, but new host save should trigger the name synchronizer and that should fix the name according to the new behavior.

Well that’s always a risk, but at this point we don’t know how many such environments/users there are. hence this thread :slight_smile: We may also find out more after it’s in the deprecation list of 3.4. I hope we’ll gather some early user feedback before that though.

Dropping the option to omit the domain name should not be problematic in our experience. Using short names however can create issues. E.g. when pushing facts from an external puppet master used to create an additional host entry with identical hostname used to be created unless using fqdn as apparently the association between the original host in foreman and the incoming facts was not properly done.
Using fqdns only so far created no problems except for come customer’s preference to use short names for “better readability”.

1 Like

Thanks, great feedback!

I can also imagine cutting the domain name in the view layer, e.g. on the host index page, but still storing the FQDN in the database.

1 Like

Sorry I am just now seeing this. In places, we use fqdn domain names programmatically - For example, a host can know what environment it is in by looking at it’s domain:

hostname1.pro.example.com
hostname1.dev.example.com

By parsing the subdomain, I can know what environment I am assigned to. Similarly, we use some crosscheck scripts to generate daily reports for host/hostnames that probably need attention. As much as I want Foreman to be the “book of record” I still find people deploying OVFs directly in VMWare, but forgetting to create a domain name for them or adding them to a few other systems like FreeIPA. (You can’t always get away from this - your hypervisors and networking equipment for example) but by using this setting, I can more easily check for consistency between systems and more easily check in the case of:

hypervisor1.pro.example.com
hypervisor1.dev.example.com

If only the short name is used, I run into problems with these scripts, so keeping the option would be preferable in my opinion. Even if you default to short names. The problem I think arises most when you spider out into other systems that aren’t the foreman/katello core. What happens with IDMs DNS when that gets run through smart proxies? What about PowerDNS? And Infoblox? What happens to things that aren’t puppet like SaltStack (to the extent that’s supported any more), Ansible, Chef, or others?

I think keeping this setting gives the most support to the most systems (even if not “supported” any longer) and allows the customer that freedom of choice with minimal other foul-ups in integrations.

1 Like

Perhaps the proposal wasn’t clear, but we’d keep the domain names appended, in other words, the host name would always contain the domain. If we were to keep the setting, it would only allow to hide the domain in the host list (while internally, it would be still stored as FQDN).

1 Like

Then you are on the safe side.
The proposal goes against shortnames usage.

Yet I like the idea to introduce an option to hide domain from fqdn if needed