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>
Currently, we generate a custom-format `country.dat` at build time,
which we then ship with the installer. In the live environment, this
then gets parsed (via regexes) into another format and is finally
written out as JSON for e.g. the TUI and auto-installer to consume.
Instead, skip the intermediate format completely and just generate the
final data structure as JSON at build time.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
While there is the `systemd-first-boot.service`, it uses the
non-existence of `/etc/machine-id` as condition to run. As we already
set up that file in the installer ourselves, we cannot use that.
Instead our service depends on a custom flag file in
/var/lib/proxmox-first-boot and will only run if that is present.
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>
it is meant as a helper utility to prepare an installation for chroot
and clean up afterwards
It tries to determine the used FS from the previous installation, will
do what is necessary to mount/import the root FS to /target. It then
will set up all bind mounts.
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>
Putting proxmox-fetch-answer into it's own crate, will keep the use of
OpenSSL localized to where we need it. Otherwise building other binaries
will always depend on OpenSSL as well, even without actually needing it.
Having a dedicated crate for the proxmox-autoinst-helper should make it
easier to build it independently to have it available outside of the
install environment.
The fetch plugins have been moved to the proxmox-fetch-answer crate,
except for the 'get_nic_list' function and 'sysinfo.rs'. Since both are
also needed by the proxmox-autoinst-helper, they are kept in the
proxmox-auto-installer crate.
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 can parse an answer file to check against syntax errors, test match
filters against the current hardware and list properties of the current
hardware to match against.
Since this tool should be able to run outside of the installer
environment, it does not rely on the device information provided by the
low-level installer. It instead fetches the list of disks and NICs by
itself.
The rules when a device is ignored, should match how the low-level
installer handles it.
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 is supposed to be run first and fetch an answer file.
The initial implementation searches for a partition/filesystem called
'proxmoxinst' or 'PROXMOXINST' with an 'answer.toml' file in the root
directory.
Once it has an answer file, it will call the 'proxmox-auto-installer'
and pipe in the contents via stdin.
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 expects the contents of an answer file via stdin. It will then be
parsed and the JSON for the low level installer is generated.
It then calls the low level installer directly.
The output of the installaton progress is kept rather simple for now.
If configured in the answer file, commands will be run pre and post the
low level installer.
It also logs everything to the logfile, currently
'/tmp/auto_installer.log'.
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>
The new auto-installer is intended for unattended installations and
should be especially helpful for users with frequent and/or big
installations.
The main idea is that a answer file is provided by some mechanism,
e.g., on the ISO itself, on a separate (USB pen drive) partition, or
the network, which holds a somewhat generic config in form of a TOML
file that also supports wildcard glob'ing for selecting, e.g., target
disks for flexibility.
This is a initial implementation that will be improved and extended
over the next commits.
The installation config is currently generated through a dedicated
function (parse_answer) instead of a From implementation. This is
because for now the source data is spread over several other structs
in comparison to one in the TUI installer.
Logging is done to both stdout and a dedicated log file.
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>
[ TL: Squash initial "build-up" patches ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Especially unconfigured.sh is worth checking consistently.
Running shellcheck also does not really have any notable impact on build
time, so no downside there either.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Some test to come will need a proper environment.
`prepare-test-env` can also be generally useful while developing to
quickly set up a new test environment as needed.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
.. in exactly the same way GUI and TUI installer do, streamlining them.
Up until now, testing the TUI installer often involved hand-editing the
`run-env-info.json` to put some proper disk sizes > 0 in place. This
makes this process a lot easier.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
It will be used for code shared among the different crates in the
installer. For now between the TUI installer and the upcoming auto
installer.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
[TL: fold in Christoph's buildsys fix ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since we now have a test suite (or, at least the TUI installer in this
case), we can enable dh_auto_test so that it will be run on package
builds.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Faster as lintian isn't called on the resulting package and
incremental, as the no-pre-clean (-nc) flag is passed to build
package.
This is mostly relevant since the rust based TUI prototype got added
to packaging, as those needs quite a bit longer compared to copying
perl module files.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
basically only used for change-tracking on what targets to rebuild,
so avoid the need to have the list here duplicated, most files known
to git are installer files
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
placing the common stuff top-level and the per-product stuff one
directory-level down allows to access all used resources (css,
images) from a common base path without hacking to much around.
Per-product files are always preferred.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
