This uses a more self-evident breadcrumb to intuitively override
for users not wanting to use the confluent facility for timezone
adjustment.
There are other 'peculiar' substitutions that may prefer a breadcrumb
but they may require structure that would be tricky to implement
while also passing validation.
It's clear that the service will need
to explicitly track subscriptions
to enable rescan, for example,
and thus might as well restructure
the API around this information.
This provides a self-evident entry point from
CLI to extending the discovery to
affluent switches that support it.
This function will work with newer affluent
and Lenovo XCC2 systems.
With significant firstboot output, there was a tendency
for tail to be killed before it relayed all the content.
Change to run the firstboot in a subshell in the background,
and have tail explicitly run until that subshell naturally
exits and then tail will cleanly exit
This allows user to designate certain networks to be treated as
if they were local.
This enables the initial token grant to be allowed to a remote network.
This still requires that the api be armed (which should generally be a narrow window of
opportunity) and that the
request be privileged, it
just allows remote networks to be
elevated to be as trusted as local.
This enables a more manual approach
to indicate the deployment server.
This carries the assumption that a
normal OS autonetwork config
will get the node to the right network.
This is one step toward enabling a scenario where the target is remote and the DHCP is not going to relay, but instead the deployment feeds the DHCP a confluent URL entry point to get going.
Using this parameter precludes:
-Enhanced NIC auto selection. If the OS auto-selection fails to
identify the correct interface, the profile will need nic name baked in.
-Auto-select deployment server from several. This will mean that any
HA will require IP takeover be externally handled
This is of course on top of the manual process of
indicating confluent in kernelargs.