Re: [pve-devel] [PATCH installer v4 00/30] add automated/unattended installation
I've tested mostly the same things as for v3 [0], to confirm nothing broke since that: - Using a few different values for `global` options - Install on ext4, xfs, Btrfs RAID1 and ZFS RAID10 (with different values in multiple runs) - Using DHCP and static IP - Fetching answer from a partition - Fetching answer from a HTTP source, getting the URL through DHCP or DNS - Trying out the `proxmox-autoinst-helper` tool for assembling udev rules and validating files. - Using the `post_command` to create some files in the newly installed system. - Tested with PVE, PMG and PBS, each w/ BIOS & UEFI (latter also w/ SB) One small thing I noticed: unknown/undefined options in the answer file are currently silently ignored - in the installer as well as by `proxmox-autoinst-helper validate-answer`. Something to implement in the future though definitely, but for now IMHO a rather mundane issue. Really just noting it here for reference. I can also confirm now that a small bug I found in [0] is now fixed, such that LVM configurations only allows a single disk now. The other things from [0] (and more) were also talked over again with Aaron directly, off-list. Also quickly skimmed over the actual changes again, looks fine overall. At least nothing to really note of; that would impact functionality and aren't some low-hanging fruit for the future (as e.g. noted above). So please consider this whole series: Tested-by: Christoph Heiss Reviewed-by: Christoph Heiss [0] https://lists.proxmox.com/pipermail/pve-devel/2024-April/062485.html On Thu, Apr 04, 2024 at 04:48:32PM +0200, Aaron Lauterer wrote: > This patch series adds the possibility to do an automated / unattended > installation of Proxmox VE. > > The overall idea is that we will have a dedicated ISO for the unattended > installation. It should be configured in such a way that it will start > the installation without any user interaction. Therefore, the GRUB > config should automatically start it (after a timeout). > > The information for the installer that is usually gathered interactively > from the user is provided via an `answer.toml` file. > > The answer file allows to select disks and the network card via filters. > > The installer also allows to run custom commands pre and post > installation. This should give users plenty of possibilities to either > further customize/prepare the installation or integrate it into a larger > automated installation setup. > For example, one could issue HTTP requests to signal the status and > progress of the installation. > > When the installer is called with 'proxauto' in the kernel cmdline, the > 'proxmox-fetch-answer' binary is called. It tries to find the answer > file and once found, will start the 'proxmox-auto-installer' binary and > pass the contents to it via stdin. > > The auto-installer then parses the answer file and determines what > parameters need to be passed to the low-level installer. For example, > which disks and NIC to use, network IP settings and so forth. > > The current status reporting of the actual installation is kept rather > simple. > > Both binaries log into the tmp directory. > > There is a third binary, the 'proxmox-autoinst-helper'. It provides a > few subcommands, from the help: > answerValidate if an answer file is formatted correctly > device-match Test which devices the given filter matches against > device-info Show device information that can be used for filters > identifiers Show identifiers for the current machine. This information is > part of the POST request to fetch an answer file > > The fetch-answer binary is trying to get an answer file. It does so by > first searching for a partition/FS labeled `proxmoxinst`, or all upper > case, and an `answer.toml` in there. This could be provided by another > USB flash drive. > If that is not successful, the next step is to send an HTTP POST request > to a URL to get the TOML contents in return. A POST request was chosen > because we also send information to identify the host in JSON format. > > The question then is, where to get that URL from. Right now, there are > two options implemented. The first is looking for a custom DHCP option > and the second is querying for a TXT record in the `proxmoxinst` > subdomain of the search domain. > > It is possible to provide a SHA256 fingerprint of the SSL cert used by > the answer server. The safest option is to place a > `cert_fingerprint.txt` file in the same `proxmoxinst` partition as where > you alternatively would place the `answer.toml`. > If that is not found, then it can be provided by a second custom DHCP > option or placed as TXT record in the subdomain `proxmoxinst-fp`. > > This patch series now also separates the 3 binaries into their own > crate. The 'proxmox-fetch-answer' to keep the OpenSSL dependency as > localized as possible, and the 'proxmox-autoinst-helper' to make it easy > to compile just that binary. > > The new `proxmox-chroot` utility helps to
[pve-devel] [PATCH installer v4 00/30] add automated/unattended installation
This patch series adds the possibility to do an automated / unattended installation of Proxmox VE. The overall idea is that we will have a dedicated ISO for the unattended installation. It should be configured in such a way that it will start the installation without any user interaction. Therefore, the GRUB config should automatically start it (after a timeout). The information for the installer that is usually gathered interactively from the user is provided via an `answer.toml` file. The answer file allows to select disks and the network card via filters. The installer also allows to run custom commands pre and post installation. This should give users plenty of possibilities to either further customize/prepare the installation or integrate it into a larger automated installation setup. For example, one could issue HTTP requests to signal the status and progress of the installation. When the installer is called with 'proxauto' in the kernel cmdline, the 'proxmox-fetch-answer' binary is called. It tries to find the answer file and once found, will start the 'proxmox-auto-installer' binary and pass the contents to it via stdin. The auto-installer then parses the answer file and determines what parameters need to be passed to the low-level installer. For example, which disks and NIC to use, network IP settings and so forth. The current status reporting of the actual installation is kept rather simple. Both binaries log into the tmp directory. There is a third binary, the 'proxmox-autoinst-helper'. It provides a few subcommands, from the help: answerValidate if an answer file is formatted correctly device-match Test which devices the given filter matches against device-info Show device information that can be used for filters identifiers Show identifiers for the current machine. This information is part of the POST request to fetch an answer file The fetch-answer binary is trying to get an answer file. It does so by first searching for a partition/FS labeled `proxmoxinst`, or all upper case, and an `answer.toml` in there. This could be provided by another USB flash drive. If that is not successful, the next step is to send an HTTP POST request to a URL to get the TOML contents in return. A POST request was chosen because we also send information to identify the host in JSON format. The question then is, where to get that URL from. Right now, there are two options implemented. The first is looking for a custom DHCP option and the second is querying for a TXT record in the `proxmoxinst` subdomain of the search domain. It is possible to provide a SHA256 fingerprint of the SSL cert used by the answer server. The safest option is to place a `cert_fingerprint.txt` file in the same `proxmoxinst` partition as where you alternatively would place the `answer.toml`. If that is not found, then it can be provided by a second custom DHCP option or placed as TXT record in the subdomain `proxmoxinst-fp`. This patch series now also separates the 3 binaries into their own crate. The 'proxmox-fetch-answer' to keep the OpenSSL dependency as localized as possible, and the 'proxmox-autoinst-helper' to make it easy to compile just that binary. The new `proxmox-chroot` utility helps to prepare everything to chroot into a fresh installation and clean it up once done. This will be useful in the post commands when further customizing the installation. Other plans / ideas for the future: * add option to define remote SSH access (password and,or public key). This could make remote debugging in case of problems easier Regarding the patch series itself: 01-03 are needed to move some code into the common crate and make structs/functions already in the common crate accessible. I did split up the individual parts of the auto installer into their own patches as much as possible, and (hopefully) in the order they depend on each other. Patches after the `unconfigured` one (16), switch the pattern matching to the glob crate, add the helper tool and the fetching via HTTP. Patch 26 factors our the binaries into their own crates. Patches 27-30 are for the 'proxmox-chroot' utility and preparations for it to work. Areas that can be improved/extended: * Testing possibility integrated in the Makefile I did test it with all 3 installers, PVE, PMG and PBS and it worked. WIP: Documentation. A first draft is available in the inernal wiki, as we will most likely keep it in wiki format since it applies for all 3 products, if we provide ISOs for it. since v3: Tested-by: Christoph Heiss Changes since V3: * implement most suggested code changes. Thx @Christoph for reviewing it * reordered patches a little bit. While testing individual changes I realized that some patches needed reordering and rebasing * improved error handling of pre- and post-commands. Errors will now be logged & printed. Changes since v2: * don't use 'dmidecode' but check in the source locations directly for identifiers * fixed
