When no DHCP server is configured on the network and/or no DHCP lease
is received, the auto-installer falls back to Ipv4Addr::UNSPECIFIED -
which resolves to `0.0.0.0/0` - for the interface address, gateway and
DNS server. This is then written to /etc/network/interfaces and could
cause further issues after the installation.
At the same time, this also means that no interface name will be set,
which causes the low-level installer to write out an invalid
/etc/network/interfaces entry.
Reported-by: Christian Ebner <c.ebner@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Link: https://lore.proxmox.com/20250407154810.1565150-1-c.heiss@proxmox.com
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>
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>
As the initial use case for the first boot feature request [0] was for
running shell scripts, the auto installer retrieved the binary as a
`String`. Unfortunately, this tries to interpret binary data as UTF-8
and will transform 'invalid' characters to replacement characters [1].
This causes the auto-installer to create an invalid binary when fetching
from an URL, and error with a `stream did not contain valid UTF-8` error
when fetching from the ISO image.
To allow binary executables to be used as a first boot executable, this
commit changes the fetching from being read as a `String` to being read
as a `Vec<u8>` to not interfere with the content of the executable.
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=5579
[1] https://doc.rust-lang.org/src/alloc/string.rs.html#635
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Extends our test runner for the parse-answer tests to also run some
tests which are expected to fail, with a pre-determined error message
given in the accompanying json.
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>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Now that we have a pre-generated `locale-info.json` available, skip
generating one on-the-fly and just read that one.
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>
As XFS and ZFS are spelled in uppercase letters in the installer UI and
BTRFS is usually written in this way too, make the BTRFS string
uppercase too for consistency wrt to the other options.
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
Allows the BTRFS RAID levels to be either lowercase or uppercase when
deserializing them from string values, i.e. currently only the config
value of `btrfs.raid` in auto-installer answer files.
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
Allows the ZFS RAID levels to be either lowercase or uppercase when
deserializing them from string values, i.e. currently only the config
value of `zfs.raid` in auto-installer answer files.
This partly fixes a regression, where deserializing the `zfs.raid`
property in answer files were only possible with uppercase values for
the ZFS RAID Z-levels, opposed to only lowercase as in previous
versions. This breaks the user API, as users cannot use the same answer
files as before for ZFS RAID Z-levels (the prepare-iso command fails).
Fixes: 510b0c008f ("common: simplifying filesystem type serializing & Display trait impl")
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
We serialize it as an integer for perl compatibility, so we need to also
deserialize it as such .. the latter is used in proxmox-chroot.
Otherwise, an auto-installation will fail at the end, when a
post-installation webhook is configured, while trying to run the
proxmox-chroot tool.
Reported-by: Timothy Nicholson <t.nicholson@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Adds a new parameter `--on-first-boot` to the `prepare-iso` command, to
specify a file to bake into the ISO.
To later use it with the auto-installer, the following must be set in
the answer file:
[first-boot]
source = "from-iso"
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>
Factors out the user-agent building into a separate function and then
re-uses that for get().
This has the side-effect that now for all requests issued by post() a
timeout of 60s is applied. Previously, this was only done when an
explicit fingerprint was given. Minute change and shouldn't effect
anything.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@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 utility can be called with the low-level install config after a
successful installation to send a notification via a HTTP POST request,
if the user has configured an endpoint for that in the answer file.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This functionality will be reused by the post-hook, which sends this
data as part of its information set.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This enable reusage of this code in other crates. Needed esp. by the
upcoming post-installation notification hook functionality.
No functional changes overall.
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>
Implements the proper de-/serializer directly on the type and then
use serde_plain::derive_display_from_serialize where applicable, instead
of separate serializer functions somewhere else.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Needed for the post-hook functionality, which sends this information as
part of its information set.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This allows re-using this piece of code in e.g. the post hook, instead
of having to open-code it there.
No functional changes.
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>
We do that check already in the GUI, so add it for TUI (and by
extension, the auto-installer) too.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-By: Aaron Lauterer <a.lauterer@proxmox.com>
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>
No functional changes.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-By: Stefan Hanreich <s.hanreich@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>
and add necessary derives for debug and serialize so that we can use
this for the auto-installer HTTP payload that gets send to the client
to be able to determine a dynamic answer file.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
