On Tue, 2013-09-10 at 00:35 +0200, Lennart Poettering wrote: > On Mon, 09.09.13 18:30, Simo Sorce (simo@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
