Re: [pve-devel] applied: [PATCH installer] run env: do not store emtpy hostname

[Christoph Heiss <c.heiss@proxmox.com>]

On Fri, Nov 17, 2023 at 06:37:08AM +0100, Thomas Lamprecht wrote:
>
> Am 16/11/2023 um 20:59 schrieb Stoiko Ivanov:
> > without this patch the hostname ends up as the empty string in
> > run-env-info.json, which results in a parse-error in the TUI code
> > (an empty string is not None, but still too short as hostname)
> >
> > Minimally tested on a VM.
> >
> > Fixes: bda1cdf699a3fcfc1cf3cfa446b1493689fc8eb8
> > Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> > ---
> >  Proxmox/Install/RunEnv.pm | 4 +++-
> >  Proxmox/Sys/Net.pm        | 2 +-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> >
> >
>
> applied, with some code/naming (style) clean up done in a follow-up, thanks!
>
> E.g., the method is now named get_dhcp_fqdn, as it doesn't parses out the
> first part (sometimes also just named hostname) anymore, but rather passes
> along the full FQDN, be it just the local part or a full host.domain one.
>
> @christoph: please give this another sanity check.

One thing - and why this only took the actual hostname in the first
place - was that if the DHCP `host-name` is indeed fully-qualified and
`domain-name` is set too (which is allowed by the spec), we end up with
a duplicate domain name. E.g. if the DHCP server sends

  `host-name` => "foo.bar"     `domain-name` => "bar"

would show up in the network setup screen in both UIs as "foo.bar.bar"
as the hostname/FQDN. (Tested this case just now FWIW)

Not breaking, but I'll send a follow-up patch to strip out the
domain-name from the FQDN hostname as needed.

Other than that; LGTM.