Re: FQDNs for netbooted hosts via DHCP?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 15 Jul 2018 11:18:22 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <daea4764-15e2-d66e-2462-f0a96f697721%marples.name@localhost>

  | If we're going to test that, then we need to check the converse for 
  | ${hsort} && [ "$hostname" = "${hostname%%.*}" ]

First irrelevant comment, the %%.* instead of #*. is an irrelevant variation,
the only point of this comparison is to see whether there is a '.' in 
${hostname} and both ways modify the expansion if a '.' appears, and
leave it unchanged (and comparing equal) if not, so it makes no difference
which is used (I originally wrote the line using % instead of # but then
saw that you had used # elsewhere, and made it be consistent).   It's
different in the cases where you want to actually use the result of course.

Hmm, now I look closer I see that you have used both forms already,
(though the %%.* form is used where you are actually comparing different
host name varss, so getting the value from it matters) so I guess this is even
less relevant than I thought!

More relevantly, and perhaps showing my extreme bias against short
form hostname settings, but no, I would not do that - the short form can
(and in the case in question, did) get set almost by accident.  If the
FQDN form is preferred, then overriding the "accident" (the kernel needing
to config a name so it can boot over the net) is reasonable.

On the other hand, if a FQDN has been configured, it is almost certainly
deliberate, and probably should not be overridden.

  | The actual change required is a bit more invasive than that line change 
  | though, but it suffices for this discussion.

OK, I was guessing a bit, and I agree with the last sentiment.

  | The only other concern I have with this is that if we have two 
  | interfaces and dhcpcd receives the same short hostname on both but only 
  | a domain on one of them, then the hostname will flip-flop between short 
  | and long hostnames.

I'm not sure I see that (and in any case that kind of server mis-config
is likely to cause issues anyway) but I will accept your more experience
in this area.

And no, we would not want that.

  | This is probably unlikely, but is worth pointing out.

Agreed - in any case this was just a (semi half baked, I certainly
did not consider all of the ramifications) suggestion to see if there
was some easier way to deal with the kernel self-configuring its
hostname in a more automated way than exists now.   It would be
better if only that case was overridden, rather than the
	hostname=short
in rc.conf form as well.

  | You're referring to this?
  | http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
  |
  |  >4 arguments:
  |      The results are unspecified.

Yes.

  | Well, Today I Learned something new I guess.

As I (think) I said, in the script in question there probably is no
issue, the "unspecified results" are because of what can happen
if some of the args happen to look just like test operators.

The test "language" was very badly defined (ie: not at all really.)

To avoid problems with that, there are very specific rules about
where to look for operators depending upon just how many args
exist - with those rules, it is possible to use test safely.   But
when it gets to > 4 args (or even some cases with just 4) it
is just too hard to create meaningful usage rules that anyone would
understand or remember.

  | I suppose my only concern is speed ... that would not produce any more 
  | subshells on NetBSD or any modern shell would it? Guess I should do some 
  | testing around that.

On NetBSD right now it probably would, the NetBSD sh forks itself into
oblivion for the most trivial of excuses...   But that will get fixed sometime
hopefully not too far away (performance improvements are next on the
sh fix agenda once the actual known bugs are all gone...)

Most other shells, no, test (and [ ) is almost universally built in, and most
modern shells do not fork unnecessarily to run benign builtin commands.

But unless you're planning to run the expression in a tight loop, I really
would not worry about it, compared with the cost of starting the shell
to run the script, the cost of an extra fork to run an extra [ is noise
(even when done a few times during the life of the script.)

kre