AutoYaST (SLE-15-SP6): support for advanced LUKS(2) settings #1355
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
AutoYaST does not officially support LUKS2 or setting any of its advanced options.
In fact, preliminary support for LUKS2 was added to YaST at SLE-15-SP4 targeting only the interactive installation. That's explained at the description of #1245. Since there was no feedback about it, the feature was not developed any further.
As a consequence, LUKS2 works partially in AutoYaST if the boot argument
YAST_LUKS2_AVAILABLE
is used during installation. But there is no way to configure via AutoYaST some of the parameters than can be tweaked in the UI (like the PBKDF or the LUKS2 label). LUKS2 support for AutoYaST is not even officially documented.But some SUSE customers want to configure LUKS2 devices during installation using AutoYaST, tweaking some of the luksFormat parameters. Even on already released versions of SLE.
Solution
This pull request removes the need to use
YAST_LUKS2_AVAILABLE
for using LUKS2 with AutoYaST. It's still needed in interactive installation or the UI corresponding to LUKS2 will be hidden.This also adds support for four new attributes in a
<partition>
section of AutoYaST:<crypt_pbkdf>
,<crypt_label>
,<crypt_cipher>
and<crypt_key_size>
.Those new attributes are honored when present in an AutoYaST profile (in those cases that make sense) and are also exported to the generated AutoYaST profile when cloning the system.
This pull request targets SLE-15-SP6.
Extra
This pull request also includes a relatively big commit to refactor a bit the class
Y2Storage::AutoinstProfile::PartitionSection
, encapsulating the logic for exporting (ie. cloning the system) into an new inner classPartitionExporter
.That was triggered by Rubocop complaining about
PartitionSection
being too long and complex.The refactoring is far from being a final solution, but it's likely a step into the right direction without introducing much disruption (despite its size, the commit actually just relocates and reorganizes existing code well covered by unit tests).
Code review
As mentioned, most of the changes correspond to the code reorganization that actually should change nothing. To distinguish the trees from the forest it's highly advised to review commit by commit.
Automated Testing
This pull request includes automated unit tests to verify the following aspects:
<crypt_cipher>
and<crypt_key_size>
are honored for devices encrypted with the LUKS1 and LUKS2 encryption methods.<crypt_pbkdf>
and<crypt_label>
are honored for devices encrypted with the LUKS2 encryption method./boot
partition if LUKS2 is used for root with a password-based key derivation function not supported by Grub2./boot
if root is encrypted with LUKS2 using PBKDF2 as derivation function.Manual Testing
Apart from the mentioned unit tests, this pull request has been successfully tested in a patched SLE-15-SP5 with the following AutoYaST definition. The result looks as expected.
Expand to see the input AutoYaST profile
To complete the manual testing, the system resulting from the previously mentioned autoinstallation was clonned. It resulted in the expected profile (obviously more verbose than the input profile).
Expand to see the cloned AutoYaST profile
Dependencies
This depends on the corresponding updates on two other repositories: