a way to include custom parameters/settings in template rpms

[xaki23]

The problem you're addressing (if any)

currently there is a hardcoded on-install script shipped with template rpms. this doesnt work too well for less-than-usual templates like mirage or oversized kali. the first step to pass parameters to that script (or external/custom installers) would be to include a parameter list with the rpm.

The solution you'd like

have a way to include a template.cfg (or so) with the template rpm file that allows the in-rpm script or custom/external template installers to set custom parameters like volume sizes, vm prefs, vm features.

The value to a user, and who that user might be

a reasonable way to install templates that do not fall within the defaults.

Scope / Details

i am mainly looking for some guidance with the interlocking qubes-builder situation for templates here. including a custom/optional file in a template rpm sounds trivial until you try to figure out what even decides which files go into a template rpm. (so far, i failed) bonus would be for such a mechanism to be "flavor aware", as in a "+minimal" might want to include a different parameter set than a "" plain template. to stick with the mirage example, it probably means passing a filename back from mirage-firewall/Makefile.builder via builder-mirage/Makefile.builder to builder-rpm/Makefile.iamsnotsurewhichone? similar to MIRAGE_KERNEL_NAME, except it probably needs to ref the qubes-src pathname for the builder (this example seems to be relative to the builder src name, so this might be a non-issue?), plus flavor awareness? and a way to inject additional dependencies into the rpm, as in, have mirage-firewall (or builder-mirage) say the rpm should dep on grub2-xen-pvh ...

(proactive ping @marmarek because i dont really think anyone else has a reasonable chance at this)

[marmarek]

have a way to include a template.cfg (or so) with the template rpm file that allows the in-rpm script or custom/external template installers to set custom parameters like volume sizes, vm prefs, vm features.

The mechanism itself exists already. It's implementation is here: https://github.com/QubesOS/qubes-core-admin-client/blob/master/qubesadmin/tools/qvm_template_postprocess.py#L334-L400 (which is the only documentation of this thing...).

The thing that is even more hidden is how to provide the file to the builder. The answer is: similar as default appmenus: just put template.conf into builder plugin under one of recognized names: https://github.com/QubesOS/qubes-linux-template-builder/blob/master/qubeize_image#L114-L129.

That said, the whole linux-template-builder repo will soon be obsolete, R4.2 templates will be built using builderv2 and the plugin interface there is significantly different. But the base idea (including qubeize_image script) is similar.

[xaki23]

are there any currently supported templates actualy using this implementation? (as in, can i make larger changes to it or do i have to consider backwards compat? to what? you mentioned arch on irc, so unmans arch template rpms?)

i somewhat dislike how it is a mix of features and prefs/props, and also mixes "-" and "_" variants of keys. so one thing i would like to change is adding an explicit prefix to the keys (to distinguish prefs/props and feats) and make the rest of the keys "canonical" with the way the key appears in other places. as in, change "virt-mode" to "prefs.virt_mode" or so. (yes, that pref ./. prop is a problem to begin with. its --prop on qvm-create, but otoh qvm-prefs...)

the way root_size is handled is "interesting" too. currently it does a "tar tvf $roottar", and then parses the to-be-expected size of root.img out of the output. i would prefer to add something like param.root_size to the conf (and fall back to "try to guess it from the tar" if thats not present).

[xaki23]

there is a template.conf in the arch template on https://qubes.3isec.org/Templates_4.1/ ... ... but it is empty. so i assume there are no current active uses of template.conf-in-template-rpms.

[marmarek]

so i assume there are no current active uses of template.conf-in-template-rpms.

Yes, that's correct. It's okay to still change the format.