Bugzilla – Bug 1222982
Question: autoyast, how to ask for password
Last modified: 2024-05-02 10:37:24 UTC
Hello, we could not figure out a good way to "ask" for a password. In this case, the user needs to input an existing password, not create a new one. Background information: If our pre-script detects a luks partition, we need to open it, to see if any logical subvolumes exist. On system upgrade, we want to preserve a logical subvolume with a certain label. The other subvolumes of the luks partition will be used for root and swap, so they will be erased. Current workaround (not ideal): Either use a "<password>" or use a basic text "ask". Both are not ideal. With a "<password>" field, the user has to type the password twice, which is unnecessary and confusing for a password input. The "basic text" approach is also not ideal, because the user will see their password on the screen as they type it. Note: We've been using this documentation: https://doc.opensuse.org/projects/autoyast/ We could not find a link to the source repository of the autoyast tool there. Thank you for any suggestions.
Imo, any good idea?
Hi Lars, I am sorry, but I cannot think of a better approach with the current situation to ask for the password at runtime. Regards, Imo
I am quite confused about the whole scenario. "Subvolumes" are something very specific to Btrfs. But swap is something completely different. Or is this about LVM on top of LUKS, i.e. LVM physical volumes inside a LUKS partition? Or really plain filesystems on top of LUKS partitions? And you write about system upgrade and using disk space that does not meet your criteria for root and swap. But our system upgrade (e.g. Leap 15.4 -> Leap 15.5) does not do anything like that; it uses existing filesystems as they are without formatting them (otherwise all data on them would be destroyed), just upgrading RPM packages from the old distro version to the new one, i.e. replacing the files of each old package with files from the new package of the new distro version. Or do you really mean not upgrading, but doing a new installation of the new distro version (e.g. Leap 15.5) on the disk where the old distro version (e.g. Leap 15.4) was, in your case keeping some existing filesystems ("subvolumes")? Please clarify.
This is basically how it's been intended to be used, this is a SLES 15 SP5 documentation which also works for openSUSE 15.5 https://documentation.suse.com/sles/15-SP5/html/SLES-all/cha-configuration-installation-options.html#CreateProfile-Ask password If this boolean is set to true, a password dialog pops up instead of a simple text entry. Setting this to true only makes sense if type is string. The implementation expects that you are actually entering a password that is going to be used, e.g. for root auth or for LUKS encryption or similar. In such case entering it twice makes sense. The use case was not what you use it for - getting into an encrypted volume. Adding another type of password entry would be a feature request and although not being a bad idea, it's not likely to land in self_update soon.
@Stefan We're installing everything (except /boot) in LVM volumes on top of LUKS, because of security requirements. We need autoyast for our "new installation" scenario, not "system upgrade". We want to allow users to keep their home partition in this case. @Lukas Thanks for confirming, it's not very urgent but a feature request sounds good.
Okay, I thought so. But in that case, won't the home directories be in their own LVM LV (logical volume) with a special devicemapper name like /dev/home or /dev/system/home ? Wouldn't that be a sufficient criterion to determine which LVs to keep and which ones to delete?
The lack of any feedback seems to indicate that the question is answered. Closing.
Hello Stefan, thank you for your question. Before unlocking the luks partition, we can indeed see that there is one, using "lsblk --output FSTYPE,KNAME". A luks partition will show up with a string crypto_LUKS. But we cannot see which LVM LVs are contained within this crypto_LUKS partition. That is why we need to get the password from the user, so we have a chance to format only some of the LVM LVs, and not the whole luks partition. Best regards, Lars