Wider feedback requested on two changes to our base/core defaults

Simo Sorce simo at redhat.com
Tue Sep 10 01:21:43 UTC 2013


On Tue, 2013-09-10 at 00:35 +0200, Lennart Poettering wrote:
> On Mon, 09.09.13 18:30, Simo Sorce (simo at redhat.com) wrote:
> 
> > Kerberos and x509 both require FQDNs.
> > It makes no sense to stick to short names for servers, and having a FQDN
> > on a laptop does not hurt anything (a FreeIPA enrolled laptop must have
> > a FQDN anyway as it uses the keytab to do validation).
> 
> So, which fqdn do I configure my laptop to?

It depends on your environment of course.

My personal laptop is configured with a fqdn in the FreeIPA domain I use
at home. My Red Hat laptop is configured with a domain name under
redhat.com, whatever makes sense.

If you have nothing feel free to go and just put a one component
hostname, or append .localdomain all the same

The point is: do not force the hostname to be one component.

> > So can you please stop breaking servers just to show 'pretty' names ?
> 
> I am breaking anything? That is news to me... The tools allows fqdn, as
> I wrote. 

you said:

> Enforcing a fixed fqdn for a a machine for its entire lifetime is
> like enforcing a single fixed IP address for it -- i.e. a setup that
> certainly makes sense but is probably not the common case for the vast
> majority of modern systems.

First of all, names are abstract and this comparison makes little sense,
a fqdn has no bearing on where a machine is located and its reachability
unlike IP addresses.


> The domain suffix hence is
> frequently something that is more interface or state dependent rather
> than strictly host dependent. For example, the same host might have an
> mdns hostname in .local as well as one ISP assigned hostname on ppp0
> and
> a hand chosen name on the LAN interface eth0.

And even less sense makes changing a machine name just because you are
roaming on some untrusted network. What 'random dhcp server' thinks is
my hostname is totally irrelevant to me, and certainly you do not want
to change the hostname based on what network you are on, as it may
contain anything including offensive names or whatever.
Besides changing the hostname may simply break stuff.
What a PTR resolution say is meaningless in 99% of the cases for roaming
machines, and very often for non-moving servers too, they should just be
completely ignored in most setups.

> Also, the hostname of the system is not only used for IP purposes. For
> example bluetooth uses it too, and the shell displays it and whatnot.

Poor choice on the part of these programs if finding a fqdn there is not
of their liking.

> In systemd's hostname support (as exposed via /etc/hostname,
> hostnamed,
> hostnamectl, ...) we hence generally prefer non-fqdn names, however do
> accept fqdns too.

Windows also prefers non fqdn names ... but for *display* only.
Underneath you find they always have a short machine name and a domain
or workgroup they belong to even if the workgroup is just the default
silly WORKGROUP name.

I am all for showing just the short name in some UI, that's just fine, I
have a bigger problem when I have to jump through hoops to set the fqdn
as the default behavior of the tool that set the hostname when I try to
set my.client.ipa is to turn my fqdn into my_client_ipa which A) is not
what I asked, B) makes no sense and C) is a silly transformation with no
discernible benefit that I can think of, might as well return an error,
it would cause less issues.

> Server centric software like IPA requires FQDNs
> though (which I personally think is a poor choice, but whatever...)

On what ground do you say it is a poor choice ?
Did it ever occur to you that there is *no* choice ?

FreeIPA distributes both keytabs and x509 certs to *clients*, and those
need stable names, it's just how the technology is), but it is not a big
problem because we *also* empower the client to use secure dynDNS to
change their name in the FreeIPA DNS server so that it always point to
whatever IP address they have.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list