Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname
On Wed, 3 May 2023 at 04:03, Cyril Brulebois <kibi@debian.org> wrote:
> James Addison <jay@jp-hosting.net> (2023-05-01):
> > On Mon, 1 May 2023 at 17:53, Cyril Brulebois <kibi@debian.org> wrote:
> > I do see that guestfs-tools references[1] them, and I suppose other
> > downstream software could do as well. But within the installer's
> > components, I don't think that they have any special meaning.
>
> Thanks for mentioning guestfs-tools, we have other occurrences of that
> particular setting in various packages:
> https://codesearch.debian.net/search?q=unassigned-hostname
>
> As usual (not the first time you'll see me write this, not the last one):
> a quick glance suggests those are mostly used inside preseed files, not on
> the command line, for netcfg/get_hostname or netcfg/hostname, though.
Agreed, I think.
Rephrasing it, to check: 'unassigned-hostname' (and similarly,
'unassigned-domain') commonly appears as an input to preseed
configuration (usually as a placeholder or sample value). A limited
number of tools may have code that compares against that value, but
those should be rare.
> > > I have some pending yet unrelated things to investigate on the preseed
> > > side; I'm not sure I'll want to be testing each and every possible
> > > combination (esp. tweaking the configuration of the DHCP server behind
> > > the virtualization layer), but I should be able to test the water.
> >
> > Totally reasonable, yep.
>
> OK, thanks for the sanity check.
>
> > Currently I think that a relevant patch should:
> >
> > * Unset the hostname, or set the hostname to '(none)', so that the
> > installer's netcfg ignores[2] and is unaware of an install-time
> > hostname.
>
> Yes.
Thanks - your patch in src:preseed to do that looks good.
> > * Within env2debconf, attempt to find a hostname specified on the
> > kernel command-line:
> > ...
>
> FWIW: This kind of heavy headscratching is exactly why I was wondering
> whether to fix #1031643 in the first place. :) Spoiler alert though, I
> don't think it's actually that complicated, thanks to Andreas and the
> clever side-stepping of the entire problem.
>
>
> Call me an optimist (famous last words…), but isn't that sufficient?
> - hostname=foo case:
> + The kernel consumes the parameter, acts on it.
> + We detect it in env2debconf (the hostname isn't “(none)”) and I
> guess we set the variable as today, but unset the hostname in
> Linux/UTS.
> + We get all the rest of the logic as previously?
> - hostname?=foo case:
> + The kernel doesn't consume the parameter, so there's no change
> from previous situation.
> + Things are as they have always been?
Perfect, I think that's true.
I'd _noticed_ Andi's mention of the 'hostname?=' testing.. hadn't
properly parsed or understood what it meant (rephrasing again: it's
not a recognized kernel parameter, so it's unaffected).
Thanks for the recap, and that reassures me (mostly!) that this is
safe. I'll continue to try to think of edge cases, but hopefully will
only spend my own time by doing that.
A probably-irrelevant thought: the fixes applied for #1031643 and
#1035349 also seem like they should be backwards-compatible with
pre-6.x kernels.
> I don't think before/after --- changes anything there (see my initial
> report, filed on Salvatore's behalf, and the red herring section there)
> and I clearly don't see why one would prefer a specific one anyway.
>
> A bit of warning: if one opens up a shell right after passing the
> bootloader (e.g. the language screen is still shown, and the network
> screen hasn't been reached yet – let's keep things simple), one won't
> see hostname=foo there; but one will see vga=788 (assuming graphical
> installer). That's probably because this particular env is inherited
> from the kernel, who ate the variable away already. That doesn't mean
> it's not taken into account, as can be checked in /var/lib/preseed/log:
>
> d-i netcfg/get_hostname string foo
>
> IOW: It has been created within the env2debconf process, acted on, but
> it's not going to show up in other places, like in a random shell.
Understood.
And in particular: yes, the hostname variable that we're creating (and
then reading-back by invoking 'set') is local to the env2debconf
script, and that's good.
> In summary:
> - It looks to me the first patch did make sure hostname=foo is still
> seen and acted on in userland, using the traditional logic.
> - It looks to me tweaking it to unset the hostname if it's set should
> restore “hostname is only a fallback, not actually taking priority”
> problem, while retaining the “abracadebconf” part.
> - It looks to me the kernel change should have zero impact on the
> hostname?=foo case.
Agreed on all three of these.
> Having performed the quick checking leading to this very mail, I fear
> I might back out of what I thought I was going to do (testing various
> combinations in some systematic manner), and instead: concentrate on
> unsetting hostname in Linux/UTS, run a test or two, upload the
> package, and let the rest of you all check all the combinations you
> want (hostname=foo, hostname?=foo, before/after ---, with or without
> DHCP supplied hostnames, etc.) using daily builds.
>
> And if there are still actual and relevant changes from Bullseye,
> please open up a new bug report detailing the use case, the past
> behaviour (Bullseye) and the new behaviour (latest preseed)?
Will do (both testing, and filing any other behavioural-change
bugreports separately).
Thanks again,
James
Reply to: