On Fri, 11.11.16 13:23, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote: > > I still believe we should stick to a generic hostname by default, > > (though I'd rather use "localhost" than "localhost.localdomain" in > > order to drop the redhatism that "localdomain" is), and make the IPA > > client-side enrollment code automatically update to a more "unique" > > hostname if the hostname is found to be unset or be "localhost". > > > > I am also pretty sure that DHCP clients should suppress sending local > > hostname information if the local hostname is unset or "localhost". > > > I realize that some of this is coming from my old-school sensibilities, but I > still remember a time when changing the hostname of a running system caused lots > of things to fail, including NFS and sendmail. Well, we support changing hostnames dynamically through DHCP just fine these days. The kernel has a proper API to be notified about hostname changes these days (just poll() on /proc/sys/kernel/hostname), and because of nss-myhostname it always stays resolvable, instantaneously when you change it. I am pretty sure most things should work just fine, at least in the base OS. Sure, some higher level services might be broken still, but I'd suggest to fix that instead of never changing the hostname... > Changing the enrolling code to modify the machine's hostname would be very > unexpected from an end-user perspective, don't you think? I don't think so... I mean, enrollment is interactive anyway, no? it could display a warning "your hostname is crap, will now change it for you to xyz, unless you have something better which you can type in here"... or so? > See child reply. I was trying to spare us some entropy during early setup, but I > can't think of any reason this needs to be any more complicated than something > fed from /dev/random if we aren't going to try to generate it early in the > install process. Well, deriving this from the machine ID automatically has the benefit that you don't have to store your ID anywhere. And that's actually a very important property if you want your stuff to work properly in environments where systems are installed via disk images instead of anaconda (which I'd claim is pretty often done in the wild these days, and is the basic concept up container bundles after all): many provisioning tools these days are smart enough to reset the machine ID before deploying an image, but patching through all of them to also reset the IPA ID is going to be hard (and honestly: I doubt this would even be desirable). I am pretty sure: if local services need unique IDs somewhere, then please base them on /etc/machine-id, so that resetting the machine-id will reset them too, and knowing the machine-id is enough to know all app-specific IDs of the system too. However, never expose /etc/machine-id as-is on any untrusted place, please always derive the ID you use in a cryptographically secure way from it, which cannot be reversed... Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
