conf/164048: /etc/rc.d/hostid is not symlink aware

Matthew Story matthewstory at gmail.com
Thu Jan 12 20:51:50 UTC 2012


On Thu, Jan 12, 2012 at 2:47 PM, Dirk-Willem van Gulik <dirkx at webweaving.org
> wrote:

>
> On 12 jan. 2012, at 17:48, Matthew Story wrote:
>
> > On Thu, Jan 12, 2012 at 3:15 AM, Dirk-Willem van Gulik <
> dirkx at webweaving.org> wrote:
>
[...snip]

> Totally understood - but wanted to stay close to the behavior of
> dhclient-script as I understand it.  And this happens to also make the
> behavior of /etc/rc.d/sshd on first run the same. Keep in mind that one can
> always set the rc variable.
>

it makes sense to test for existence (and not readability) for rc.d/sshd,
as it goes on to create files if they do not exist:

    if [ -f /etc/ssh/ssh_host_key ]; then
        echo "You already have an RSA host key" \
            "in /etc/ssh/ssh_host_key"
        echo "Skipping protocol version 1 RSA Key Generation"
    else
        /usr/bin/ssh-keygen -t rsa1 -b 1024 \
            -f /etc/ssh/ssh_host_key -N ''
    fi

in the existing implementation of rc.d/hostid, it does not create the file
on ``start'' if it does not exist, so detection of readability is more
correct (although in the typical use-case e.g. running as root, existence
and readability are ostensibly synonymous).


> [...snip]
>
> Agreed - as _set is better.
> [...snip]
>

So the question is not about respecting symlinks, but wether or not a
``host_id_file'' should be created if one does not exist, for the ``start''
command.  I'm not sure if this behavior is desirable, considering that the
de facto behavior is to respect hardware derived ``smbios.system.uuid'',
and writing that value to disk would potentially require an additional
reset on hardware change.

As you can easily generate a ``host_id_file'' if one does not exist by
invoking the ``reset'' command, and the sysctl is set at start properly,
either from ``host_id_file'', hardware or via the ``uuidgen'' program, this
seems superfluous to me ... but I defer to the maintainer.

-- 
regards,
matt


More information about the freebsd-bugs mailing list