Prompt for LUKS password at first boot

[kylerankin]

This set of changes modifies existing Anaconda scripts related to the
user dialog to add prompts to set a LUKS passphrase. This approach
allows us to re-use some of the same kind of code and structure from the
user module which already shows up at first boot in the OEM image.

I didn't create an additional add-on and instead opted to modify the
existing user script, because I didn't find a good way to register a new
add-on in the post-install section of the kickstart. Copying files in
the addons directory wasn't sufficient, and adding an %addons section
to the ks.cfg only takes effect during the install. It sees the
referenced add-on is missing (because it gets copied in post-install)
and skips it.

Note that this change also sets the initial encryption password to be
empty, so the user doesn't have to know about a hard-coded password
ahead of time and can just hit Enter instead, since that has the same
security value as a hard-coded password in this case.

[jans23]

@marmarek Any suggestion regarding registering a new add-on in the post-install section of the kickstart?

[marmarek]

I don't remember any troubles in this area, it was enough to copy appropriate files into the plugin directory.
Here you can find some resources:

• official docs: https://rhinstaller.github.io/anaconda-addon-development-guide/
• our working addon: https://github.com/QubesOS/qubes-anaconda-addon/
• hello-world example addon: https://github.com/rhinstaller/hello-world-anaconda-addon

Maybe some __init__.py was missing? You've copied it into /usr/share/anaconda/addons, right?

Take a look at initial-setup logs, it should show each plugin it considers (and if rejects - then why).

[kylerankin]

@marmarek The issue was that using this method, we modify the ISO image and not the installer filesystem, so like with the nitrokey additions, we are left with what we can do in the post-install section. During my testing I started with copying the basic hello world add-on and copied it to the appropriate directory as part of the post-install, and referenced it in the %addons section in the kickstart file, but because it didn't get copied until after the install, it wasn't picked up on the next reboot.

This is why I took the approach I did, of live-modifying the user plugin. That approach worked and allowed me to re-use similar components for user password for LUKS password.

[marmarek]

During my testing I started with copying the basic hello world add-on and copied it to the appropriate directory as part of the post-install, and referenced it in the %addons section in the kickstart file, but because it didn't get copied until after the install, it wasn't picked up on the next reboot.

But we are talking about addons running during initial setup, right? Those should be enumerated when the initial setup is called (at the first boot). It may be confusing, since the same addons can be used during installation itself (you can configure user either during install or first boot for example) - but you don't need to worry about the installation, since you want addons only for initial setup.

For debugging this, I recommend taking installed system, copying addon manually into the right location, and starting sudo /usr/lib/initial-setup/initial-setup-graphical (from a normal xfce session). Once it works this way, you can simply package it into post-install kickstart section.

BTW, if you want, we can package this addon in default install image too, but that will be available only in a future release.

[kylerankin]

But we are talking about addons running during initial setup, right? Those should be enumerated when the initial setup is called (at the first boot). It may be confusing, since the same addons can be used during installation itself (you can configure user either during install or first boot for example) - but you don't need to worry about the installation, since you want addons only for initial setup.

I also thought it should work this way, but in my experimentation what happened was that the installer saw the addon be referenced in %addons but because it didn't see the addon in the add-on directory during the install (because it gets copied post-install) it didn't register it as an addon to run during initial setup. That is, at least, what the logs showed--that it looked for the addon, didn't see it, and so didn't add it. Just copying it to the addons directory in the post-install step doesn't appear to be sufficient enough to trigger anaconda to run it.

For debugging this, I recommend taking installed system, copying addon manually into the right location, and starting sudo /usr/lib/initial-setup/initial-setup-graphical (from a normal xfce session). Once it works this way, you can simply package it into post-install kickstart section.

BTW, if you want, we can package this addon in default install image too, but that will be available only in a future release.

It would take quite a bit of effort at this point to rewrite this modification of the existing user plugin into a standalone add-on. You can get a sense of what's involved by looking at the changes I make within the pyanaconda and anaconda directories just to re-use what's already there.

That said, having the ability to change the LUKS password at first boot would be very valuable, in particular for an OEM install, which is why I went to the trouble to implement what I did--we want to start offering Qubes pre-installed and having this feature is a requirement. What I implemented so far works well enough that we will probably start using it internally. If someone has a better solution they want to implement upstream I certainly welcome it!

[daringer]

personally I do not have much of an opinion about the realization, also like the feature/outcome.
@kylerankin could you link the original sources you've used here? How much are they changed actually? Would it make sense to have you changes as a patch and pull in the sources (during the iso build) to patch them. This would avoid redundancy and might also be better to maintain on the long term...

[kylerankin]

personally I do not have much of an opinion about the realization, also like the feature/outcome.
@kylerankin could you link the original sources you've used here? How much are they changed actually? Would it make sense to have you changes as a patch and pull in the sources (during the iso build) to patch them. This would avoid redundancy and might also be better to maintain on the long term...

The changes are rather significant. I don't know where a proper online source would be for the original files but you can perform a diff against the corresponding files in /usr/lib64/python3.5/site-packages/pyanaconda/ and /usr/share/anaconda/ respectively from dom0.