The original thread is getting rather long and I'd like to attempt to summarize the discussion thus far and see if we can find a way forward from there. First, some clarifications for preconditions that some people were unaware of (either on this thread or the ones that popped up on other lists/forums): 1) Fedora has always allowed the hostname to be changed in Anaconda. It's perhaps not in the most obvious of places (the networking spoke), but it's there. It can also be set via kickstart, of course. 2) The default today is to use a name provided by the DHCP server if it offers a name for that device, otherwise it will fall back to localhost.localdomain (the common case for most personal networks). 3) My original proposal was: change the fallback name to Fedora-XXXXXXXX by default, while of course retaining the ability to set it manually. 4) The specific issue relating to FreeIPA and Active Directory is one of uniqueness: you can only have one machine named "localhost" enrolled in a domain. A user who is unaware of the hostname at all will not know to change it ahead of time. The thread on Fedora Devel revealed some other issues which need to be considered carefully. One of these is that of privacy: for example, the DHCP client will send the machine's hostname as one of the cues to the DHCP server for acquiring a lease. While this is fine on private networks, there's a valid concern that this might be undesirable on a public hotspot. (This is only one such example; there may be other places where the system transmits the hostname). With machines commonly defaulting to localhost.localdomain, getting this information tells the recipient little more than that a Fedora-derived machine is connecting (since it's the only known ecosystem that uses this specific default). However, the more unique we make the name, the easier it becomes to isolate it to a single system (such as for tracking purposes). It is an open question whether this is an actual problem to worry about or whether it's a drop in the proverbial bucket. It's also worth noting of course that any manually-chosen hostname will have this same problem, which begs the question of whether it's worthwhile to do anything about it at all. (Or perhaps that the focus should be on not leaking the hostname itself elsewhere, regardless of how it was created). I hope this frames the discussion better. My thoughts from here: The hostname may always be set manually and the result will (for the vast majority of people) be unique within their environment. This means that if we are concerned with hostname leakage being a privacy issue, we need to address that at the leakage point, not at the hostname point. Also, there are cases where hostname leakage may be used specifically *because* it may be unique, such as one of several cues to the DHCP server. Unfortunately, we cannot know in advance whether a DHCP server is going to be on a trusted or untrusted network (we might be able to guess from the SSID of a WiFI connection, but those are remarkably easy to fake). In short, I really don't think that the hostname is the right place to solve this problem. If transmission of individually-identifying information is a concern, then we really have to solve it at the transmission points and not at the source. Yes, an argument could be made that a user who sets her own hostname is "opting-in" to that uniqueness, but I think that's setting an unrealistic expectation on all of our users that they fully understand the consequences of that action. Further, from a purely technical perspective, I think I've been swayed by arguments around the generation of the hostname: * I'm fine with the lowercase "fedora-" prefix. It makes sense since hostnames are generally normalized to lower-case in common usage. * I like Zbigniew and Lennart's thoughts on how to generate the "random" suffix. the implementation I'd likely use is to take the first eight characters of an md5 (or SHA) hash of /etc/machine-id and use those. That should make it both repeatable and unique. For Anaconda folks: would it be possible to have the currently-selected hostname be visible next to the "Networking" spoke on the main hub page? You show the selected environment group beside the "Software Selection" spoke and the connected network device, so it might be useful to let people know what the hostname is as well. (This would also be handy if it turns out that DHCP is trying to assign a hostname; the user may not want or expect that)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
