Add an optional parameter to allow specifying a domain, which will take
precedence over both the DHCP-supplied domain (if any) and the hardcoded
default domain.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
The `NetworkOptions` struct was moved here in
5362c05cd ("common: copy common code from tui-installer")
and
86c48f76f ("tui: switch to common crate")
but the tests were forgotten at the original place.
No functional changes.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
In preparation for fixing #6285 [0].
`0` means to just skip writing the module parameter. But (especially)
with the upcoming change in ZFS 2.3 - which makes the size basically
that of the system memory minus 1 GiB - we want to always write some
value.
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=6285
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
We always want to leave a little bit of extra headroom
for the OS.
This follows commit 91be6a7 [0], which adjusts the clamp calculation.
Reflect that here in the user-facing UI as well.
[0] https://git.proxmox.com/?p=pve-installer.git;a=commitdiff;h=91be6a7
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Now that the value is pre-calculated in the low-level installer and
written to `run-env.json`, use it from there instead of calculating it
separately - thus having a single source of truth.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
The 2024 style guide changed some things, which causes quite some churn. Most of
boils down to the changed import order, now choosing types before function
items - which is the other way round then before.
No functional changes.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
.. in accordance with current NIST recommendations [0].
It's 2024; so reasonable to expect an 8-character-password at the
minimum.
[0] https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
It's more appropriate to use an enum for that type of data, since the
users must set exactly one of both variants. Note that while one could
theoretically have the case where struct members get set to `None`
before this patch, in practice this was already caught by the
`verify_email_and_root_password_settings` function. So the change
makes this invariant more obvious and also a bit more ergonomic to
handle.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
[TL: describe why this change has no semantic user visible effect]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Means that all CLIs will now have the correct version compiled-in.
This is at least very much relevant for
`proxmox-auto-install-assistant`, which we distribute separately as a
normal binary/package.
Currently, `proxmox-auto-install-assistant --version` always reports
'0.1.0', thus users have to effectively fall back to their system
package manager (if installed via such) to identify the correct version.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
We already have `SetupInfo::mocked()` since commit c3c9282 ("common: add
mocked variants for setup and ISO related info structs"), so use that.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Using the previously introduced `pretty_assertions` crates for object
comparisons improves developer UX quite a bit, making failures easier to
observe and quickly reason about.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This can happen if e.g. not all required testdata is available, such as
.cd-info - in which case proxmox-low-level-installer will fail early
with
could not open CD info file '/.cd-info' - No such file or directory at Proxmox/Install/ISOEnv.pm line 95.
Currently, next_msg() would just be recursively called until the stack
overflowed in such a case.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
.. such that receivers can differentiate between these two cases more
clearly.
Sometimes, the `progress` sub does not get passed a text (on purpose!),
just updating the progress ratio. This would cause log messages to be
written out which could indicate missing text and look rather weird.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
.. effectively de-duplicating the struct, which currently is defined in
both the auto-installer and the tui-installer separately.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
.. to enable the setup of the 'proxmox-first-boot' service, as well as
optionally setting the ordering.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Fixes building each crate on their own.
In a full build (e.g. `make deb`), everything pulls in serde with the
`derive` feature anyway and thus does not exihibit any build failures.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This actually broke with commit 723afe2 - this patch was quite old
(18.10.2023) and these tests were introduced some time after sending it,
thus is not adjusted for it.
Fix itself is pretty simple, simply ignore non-JSON/invalid message from
the low-level installer, much like the actual progression code does it.
Fixes: 723afe2 ("run env: always re-create run env file in test mode")
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
For non-PVE products, simply use the ZFS defaults (aka. 50%) and leave
unset, if the user never touches that setting.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Enables to add an optional placeholder value to `NumericEditView`, which
will be displayed in a different (darker) color and not returned by
`.get_content*()`.
Can be used for having default values in the TUI, but with different
handling in the back.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
That regex should be a lot more accurate in what it allows - if it's
good enough for the HTML spec, it should be for us too.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This was missing, as it was only applied for the main installation UI -
the setup error has its own screen setup codepath entirely.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-By: Aaron Lauterer <a.lauterer@proxmox.com>
Development of crossterm seems to be more active, has more frequent
releases and is also the default backend for cursive - so overall also
probably better supported/tested.
Additionally, it feels a bit more snappier/less flickery, probably due
to buffering writes to the TTY layer unlike termion.
As this effects only the way cursive talks to the TTY, this has no
visible change on the TUI itself.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
So we never accidentally show/log the password somewhere. Need to drop
it from `InstallerOptions` in turn too, but it's never used currently
anyway.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-by: Theodor Fumics <theodor.fumics@gmx.net>
It's only used internally there anyway, so make it slightly less
confusing.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-by: Theodor Fumics <theodor.fumics@gmx.net>
As this is an internal option for the low-level installer anyway, no
real functional changes here.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It's currently only activated for small (<=80 columns) displays, to make
disk selection a lot more usable in these cases. This mostly affects
serial console installation, but possibly also installations using a
virtual screen via IPMI/BMC.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
Add a tabbed view component, for usage in the advanced disk options
dialog when selecting ZFS or Btrfs (for now). Works pretty much the same
as its GUI counterpart, as much as that is possible.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
.. thereby, also fixing a accidental shell injection.
Since run_cmd{,s}() is nowhere else used anymore, they can be removed
too.
Also mostly reverts commit
5878dc4ae "auto-installer: handle auto-reboot info messages directly"
in the process too.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This can significantly reduces CPU load and even speed up the
installation a lot on single-core machines. While the latter may not be
a realistic target for obvious reasons, lowering overall CPU usage is
always a good thing.
Also helps with flickering during the installation process quite a bit
too.
E.g. a test installation on a single-core VM goes down from 47:35 min
w/o the patch to 2:26 min w/ the patch, a ~94%(!) decrease in time.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
necessary for the disk selection and network interfaces maps to have
tests with results that can be compared without much additional effort.
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It describes the data structure expected by the low-level-installer.
We do this so we can use it in more than the TUI installer, for example
the planned auto installer.
Make the members public so we can easily implement a custom From method
for each dependent crate.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The low-level installer prints quite a few messages during the install
to its stdout which are not JSON-formatted and thus parseable.
Thus catch them early and write them to `/tmp/install-low-level.log`, to
avoid polluting the log tty at /dev/tty2 with mostly useless parse
errors.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Instead of reading the checkbox when continuing to the next screen, save
its toggle status to the installer state instead on change.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
