Carlos Alberto Lopez Perez wrote: > On 20/02/13 03:01, Carlos Alberto Lopez Perez wrote: > > On 06/09/10 19:35, martin f krafft wrote: > >> I have never come across a (Debian) system where /usr/bin/hostid > >> didn't print 007f0101. That is because Debian uses /etc/hosts to map > >> 127.0.1.1 to the hostname(s). > >> > >> Arguably, having a host UUID would be quite nice, but as there is no > >> "one" IPv4 of a host, it's kinda useless to try to go that road.
Agreed. It is the wrong path. Hosts have network devices. In the plural. Network devices have IP addresses. Also plural. Where plural could be any of 0, 1, or many. There isn't any one true IP address. That hostid tries to use one in the way that it does is based upon flawed fundamental assumptions. > >> Unless hostid [well, gethostid()] can be replaced with something > >> sensible, I suggest that it be removed from coreutils, or disabled, > >> vandalised, or otherwise physically harmed. (chuckle) Because otherwise people will try to use it and simply propagate the problem. But I would hate have Debian bear the force the storm for those odd but misguided applications that try to use it. I would vote to go down the path of creating a very likely to be unique identifier for it. > >> Feel free to reassign to glibc, where gethostid() comes from}. Obviously the coreutils hostid is simply an interface to the gethostid() call. But would this be more or less likely to be addressed there? > Here is a great summary from Lennart Poettering about the sources of > unique IDs on a Linux systems: > > http://0pointer.de/blog/projects/ids.html > > He agrees that the current status of hostid is useless on most distros, > and he suggests to symlink /etc/hostid to /var/lib/dbus/machine-id (!!). This sentence is troubling. "On Linux, it is universally available, given that almost all non-embedded and even a fair share of the embedded machines ship D-Bus now." In the same sentence it is declared universially available and then examples are given where it is NOT available! Also, AFAICS gethostid() only reads the first four bytes from the file. Therefore using a symlink to /var/lib/dbus/machine-id would not yield the desired result. It would reduce the entropy there down to the first four characters from it. Mapping from binary data to the character representation of it would be incorrect. > IMHO A more reasonable approach that don't forces a dependency on dbus, > is just to randomize /etc/hostid on the postinst of coreutils as I > suggested previously. Agreed. Let's not use this as an excuse to increase dependencies upon dbus. It would be gratuitous. > > Perhaps a quick and easy solution for this issue will be to check if > > /etc/hostid is already configured on the system, and if not, just set it > > to a random value on the postinst of coreutils. Something like: > > > > if [ ! -f /etc/hostid ]; then > > dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null > > fi > > > > What do you think? In concept I am in agreement with you that Debian should automatically create a randomized id value so that gethostid() and hostid then return something that is not simply the first IP address it associates with the host. In implementation I worry that writing to /etc is not the correct place to put this information. It might be read-only for example. Of course at initial system installation time there is no problem pushing values into /etc and that is the only time it would happen upon new system installations. Perfect is the enemy of good. Therefore I vote to fix /etc/hostid if it does not already exist. Bob
signature.asc
Description: Digital signature
