On 12 Jan 2023, at 18:25, Rick Macklem wrote:
> On Thu, Jan 12, 2023 at 12:24 AM Baptiste Daroussin <[email protected]> wrote:
>>
>> On Wed, Jan 11, 2023 at 07:08:39PM -0800, Rick Macklem wrote:
>>> On Mon, Jan 9, 2023 at 6:40 AM Matteo Riondato <[email protected]> wrote:
>>>>
>>>> On 2022-12-24 at 03:39 EST, Tobias C. Berner <[email protected]> wrote:
>>>>
>>>>> Moin moin
>>>>>
>>>>> I think it tries to solve the same problem of giving the machine a unique
>>>>> id.
>>>>>
>>>>> From the linux man page [1]
>>>>>
>>>>> The machine ID does not change based on local or network
>>>>> configuration or when hardware is replaced. Due to this and its
>>>>> greater length, it is a more useful replacement for the
>>>>> gethostid(3) call that POSIX specifies.
>>>>>
>>>>
>>>> Does this make or should it make hostid obsolete?
>>> I hope not, since the NFSv4 client uses /etc/hostid.
>>>
>>>> If yes, then changes are needed to deorbit hostid. If not, why not?
>>> If this is somehow a better algorithm than the one used by uuidgen(1)
>>> then I would prefer seeing that utility improved instead of a new one
>>> being added.
>>
>> This is exactly what has been done. Here we are speaking a rc script to
>> generate
>> the file expected by userland software (from the ports tree).
>>
>> https://cgit.freebsd.org/src/commit/bin/uuidgen/uuidgen.c?id=f176fe8e7f638e585afcd2f4dd52a522c4648f63
>>
> Oops, sorry about that. From the original commit log, I thought that the
> commit
> added a new utility, so that there were now two utilities in the source tree.
>
>>>
>>> If software needs to acquire the host uuid, the code can simply
>>> get the sysctl kern.hostuuid.
>>
>>>
>>> Unless there is a really good reason to have this one in the
>>> system as well as uuidgen(1), I'd suggest you revert this commit.
>>>
>>> rick
>>
>> I don't see why it should be reverted. more and more of the package ecosystem
>> requires this feature (and it what is provided by dbus is not sufficient
>> anymore), this is what those changes (addition to uuidgen(1) and rc script to
>> generate the machine-id file) is addressing.
>>
> I agree. I mistakenly thought a new utility had been added. Now I see it is
> a noew option on uuidgen(1), which seems fine to me.
>
> Sorry for the noise, rick
>
>> Now can we reuse part of the changes to improve/replace hostid, this is a
>> complerly unrelated study that could (should?) be done by whom is willing to
>> have a look and knowledgeable enough in this area.
I think this would be a good idea. It seems strange to have two uuids for a
host, although the two clearly differ in several ways. It would also be nice
to have documentation that cross-referenced the two and explained them.
I’m not sure where that should be; maybe hostuuid and machine-id should
have man pages. All I see now is the gethostid/sethostid(3) man page, all
of which is historical.
Mike
>> Best regards,
>> Bapt
