So one problem that people hit fairly regularly is apps mishaving been hostname changes under their back. This comes up fairly frequently when coming out of resume for instance. One problem with toggling this is some apps may break if hostname is externally resolvable. Anyway, Jeremy and I and a few other people discussed this on the bus one day and we decided it makes sense to make the toggle early in the F-9 cycle and fix anything that breaks. We can't fix the reverse. There isn't a good way to know when your external hostname no longer works. It actually doesn't even make sense, since computers frequently have more than on external hostname and one external hostname is frequently given to more than one machine round robin...
*** Bug 408881 has been marked as a duplicate of this bug. ***
If it's not clear from initial comment, "toggle" means make "enter hostname manually" the default selection and not "determine from dhcp"
Good idea. Not sure why we hadn't done this earlier, but hey, whatever right? I've patched anaconda to do this, so the next build of it in rawhide should contain the fix.
So it looks like this is broken again. irc conversation: <halfline> dcantrell: around? <dcantrell> halfline: yeah, here <dcantrell> what's going on? <halfline> dcantrell: so it seems like HOSTNAME=localhost.localdomain is getting written into /etc/sysconfig/network again <halfline> do you know the scoop there? <dcantrell> yeah, that's still in network.py <halfline> dcantrell: what would be neat is if we asked "What do you want to call your computer?" and then took that string and normalized it for hostnames and volume group names <halfline> and then stuffed it somewhere unnormalized so e.g. gdm could show it <dcantrell> halfline: I've tried to do something like that, but it only works if we get a hostname for your system via DNS <halfline> i don't think using the hostname from dns ever makes sense <halfline> the gethostname() call is something local to the machine <halfline> nothing to do with the outside network <dcantrell> yeah, that's sort of a policy thing that can go either way. I mean, i don't care one way or another. <kiilerix> halfline: isn't the problem that users would expect to be able to change it? They can't if it is used in volume names ... <halfline> kiilerix: that might be a bit of a problem. we wouldn't have a ui to change it (besides anaconda) until that got figured out <halfline> dcantrell: okay i'll open it back up <dcantrell> halfline: asking for a 'computer name' is more appropriate, I think. but I want a way the system can store that without relying on dropping things in to the network config files <halfline> dcantrell: me too <halfline> dcantrell: it sucks to show the hostname in a ui <halfline> since it's limited in what characters you can use <dcantrell> right <halfline> ideally all these gritty things like hostnames and volume group names stay hidden <halfline> and are just derived from the name <halfline> with things like apostraphes and spaces removed <kiilerix> if hostname is hidden then it could just always be localhost <dcantrell> and overriding the hostname can cause other programs to get confused. so I'd really like to see some way to keep track of 'computer name' or 'system name' outside of all that, and like you said, use it to provide hostname, LVM base names, and other stuff <halfline> kiilerix: well it won't be hidden for legacy things <halfline> kiilerix: for instance it's still shown in the shell by default <kiilerix> yes, "custom hostname" is most for display purposes
Anaconda is no longer touching /etc/hosts. The setup RPM owns that. We are still writing out the HOSTNAME variable in /etc/sysconfig/network based on what you put in the entry field in anaconda. I was able to get localhost.localdomain to appear in HOSTNAME when doing a livecd install (bug #492515), but I have a patch for that now. With these fixes in place, that's about as good as things can be for F-11. I would like to raise the issue with FESCo about coming up with a 'system name' that is not necessarily the same as hostname, per the IRC discussion.