[opensuse-factory] /etc/init.d/boot.crypto , LUKS extension, unattached devices
May I suggest a change to /etc/init.d/boot.crypto ? First the "real life context": I prepare my /etc/crypttab and my /etc/fstab for quite a few different external encrypted disks. And I don't attach them all at the same time, esp. not at boot time. /etc/init.d/boot.crypto shouldn't bother attempting to mount disks, that are not currently attached. Now for internals of the script: The test "cryptsetup isLuks ..." should be preceded by a test on the existence of the "device", i.e. the symlink in /dev/disk/by-id/ . So far, if "cryptsetup isLuks ..." returns false, "this is used for things like swap or other temp mappings", as the comment in the "else" branch says. So because that's used already for something meaningful, there should just be another test beforehand. And this is my suggested code: if ! test -L "$device"; then echo -e "device {$device} does not exist currently.\n" ret=1 continue elif cryptsetup isLuks "$device" &> /dev/null; then ---------- Actually there is also something else, I would like to suggest. I really prefer names like "scsi-SATA_FUJITSU_MHT2080_NN5AT43149CP-part4" over names like "sdb4" in /etc/fstab and also in /etc/crypttab . You guess why, don't you? We don't know in advance, in which order we attach / detach / re-attach ... external disks during the weeks and months. And "sdb4" assumes (somehow), that the disk is the 2nd SCSI disk. But maybe "today" we only attach it as the 3rd. And for the same reason names like "sdb4" should also not be used to create names in /dev/mapper/ . The entries with names like "sdb4" in /etc/fstab and in /etc/crypttab get created by yast's "System / Partitioner". It's not really a major effort for me, renaming "sdb4" to something more flexible, everytime we attach yet another external encrypted disk, but I guess I am not the only one doing so. So a few others around this globe might enjoy such an improvement, too. ---------- I would really enjoy seeing the suggested changes in 10.4 or so ... :-) Kind regards, J. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun 29 Apr 2007 09:11:12 NZST +1200, Jochen Hayek wrote:
May I suggest a change to /etc/init.d/boot.crypto ?
Thanks for that, I second your suggestions. A few days ago I had a play with an encrypted removable disk. My comments: 1) The only way to create such a disk, on a removable memory gimmick which are of plentiful supply and very popular, is to go into yast disk partitioner and to click a few dire warnings "this is only for advanced..." out of the way, and going all the way with "custom". Actually same issue with non-encrypted removable storage. Something more user-friendly would be a good idea for 10.4. 2) The only functional fstab entry I found is: /dev/disk/by-id/usb-HTS54104_MPB2LAX2xxxxxx_B26A82xxxxxx-part1 /media/portable2 ext3 loop,encryption=twofish256,acl,user_xattr,user,nosuid,nodev,noexec,noauto 0 0 For the reasons Jochen explained, reference by sdXN is useless. The yast fstab editor (disk partitioner) is unable to create such an entry, because as soon as "encrypt filesystem" is clicked, the button to enter the 4 advanced options disappears from the screen. Of those 4 options (of referencing the partition), only by-ID can work. So the other 3 (but UUID, etc) should be greyed out or disappear, but by-ID must stay, in fact it should be default. 3) The system (tested 10.2) fails to load the cryptoloop module. This must be loaded manually by root first, or the filesystem can never be mounted. One could add it to MODULES_LOADED_ON_BOOT. boot.crypto loads it but *only* if a fixed disk with encrypted fs is also in the system. 4) Optical problem only: If /etc/cryptotab exists, boot.crypto switches to text console, finds it doesn't have to do anything because I commented out the lines but don't want to delete them as it has the info I need for fstab, or because the disk is currently not plugged in, then switches back to graphics boot screen. 5) The removable disk must be mountable by $user, as the other movable storage things. 6) There's no desktop auto-popup asking for the fs crypto password.
I would really enjoy seeing the suggested changes in 10.4 or so ... :-)
Any chance of getting 2-5) into 10.3??? Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Volker Kuhlmann wrote:
On Sun 29 Apr 2007 09:11:12 NZST +1200, Jochen Hayek wrote:
May I suggest a change to /etc/init.d/boot.crypto ?
Thanks for that, I second your suggestions. A few days ago I had a play with an encrypted removable disk. My comments:
1) The only way to create such a disk, on a removable memory gimmick which are of plentiful supply and very popular, is to go into yast disk partitioner and to click a few dire warnings "this is only for advanced..." out of the way, and going all the way with "custom". Actually same issue with non-encrypted removable storage. Something more user-friendly would be a good idea for 10.4.
2) The only functional fstab entry I found is:
/dev/disk/by-id/usb-HTS54104_MPB2LAX2xxxxxx_B26A82xxxxxx-part1 /media/portable2 ext3 loop,encryption=twofish256,acl,user_xattr,user,nosuid,nodev,noexec,noauto 0 0
For the reasons Jochen explained, reference by sdXN is useless. The yast fstab editor (disk partitioner) is unable to create such an entry, because as soon as "encrypt filesystem" is clicked, the button to enter the 4 advanced options disappears from the screen. Of those 4 options (of referencing the partition), only by-ID can work. So the other 3 (but UUID, etc) should be greyed out or disappear, but by-ID must stay, in fact it should be default.
That's unrelated to boot.crypto. Please consider filing a bug for YaST.
3) The system (tested 10.2) fails to load the cryptoloop module. This must be loaded manually by root first, or the filesystem can never be mounted. One could add it to MODULES_LOADED_ON_BOOT. boot.crypto loads it but *only* if a fixed disk with encrypted fs is also in the system.
10.3 boot.crypto will not use cryptoloop so that problem should be obsolete.
4) Optical problem only: If /etc/cryptotab exists, boot.crypto switches to text console, finds it doesn't have to do anything because I commented out the lines but don't want to delete them as it has the info I need for fstab, or because the disk is currently not plugged in, then switches back to graphics boot screen.
Please file a bug and assign it to me.
5) The removable disk must be mountable by $user, as the other movable storage things.
6) There's no desktop auto-popup asking for the fs crypto password.
hal supports both for LUKS volumes at the backend side of things. KDE/GNOME need to implement the UI. On the command line you can mount such volumes with the halmount script (in a still slightly inconvenient way though). cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jochen Hayek wrote:
I prepare my /etc/crypttab and my /etc/fstab for quite a few different external encrypted disks. And I don't attach them all at the same time, esp. not at boot time.
/etc/init.d/boot.crypto shouldn't bother attempting to mount disks, that are not currently attached. [...]
Most current boot.crypto from factory already skips devices that don't exist. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Ludwig Nussel writes:
LN> Jochen Hayek wrote: >> I prepare my /etc/crypttab and my /etc/fstab for quite a few different external encrypted disks. >> And I don't attach them all at the same time, esp. not at boot time. >> /etc/init.d/boot.crypto shouldn't bother attempting to mount disks, >> that are not currently attached. >> [...] LN> Most current boot.crypto from factory already skips devices that don't exist. I had installed (upgraded) SUSE Linux 10.3 from CD-ROMs, then I upgraded certain parts from SUSE Factory, and ... $ rpm --query -f /etc/init.d/boot.crypto aaa_base-10.1-41 In aaa_base-10.3-29.i586.rpm (currently on SUSE Factory) : $ rpm2cpio aaa_base-10.3-29.i586.rpm | cpio -tv | fgrep crypt 630 blocks -rw-r--r-- 1 root root 1232 Apr 27 17:31 ./var/adm/fillup-templates/sysconfig.boot.crypto 1st: I find it a little risky to upgrade esp. aaa_base. 2nd: I cannot find boot.crypto in that package, so I cannot verify, what you're saying, and I would at least like to have a look at the new code in boot.crypto. J. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jochen Hayek wrote:
Ludwig Nussel writes:
LN> Jochen Hayek wrote:
>> I prepare my /etc/crypttab and my /etc/fstab for quite a few different external encrypted disks. >> And I don't attach them all at the same time, esp. not at boot time.
>> /etc/init.d/boot.crypto shouldn't bother attempting to mount disks, >> that are not currently attached. >> [...]
LN> Most current boot.crypto from factory already skips devices that don't exist.
I had installed (upgraded) SUSE Linux 10.3 from CD-ROMs, then I upgraded certain parts from SUSE Factory, and ...
$ rpm --query -f /etc/init.d/boot.crypto aaa_base-10.1-41
In aaa_base-10.3-29.i586.rpm (currently on SUSE Factory) :
$ rpm2cpio aaa_base-10.3-29.i586.rpm | cpio -tv | fgrep crypt 630 blocks -rw-r--r-- 1 root root 1232 Apr 27 17:31 ./var/adm/fillup-templates/sysconfig.boot.crypto
1st: I find it a little risky to upgrade esp. aaa_base.
2nd: I cannot find boot.crypto in that package, so I cannot verify, what you're saying, and I would at least like to have a look at the new code in boot.crypto.
boot.crypto is now in the util-linux-crypto package as it entirely depends on cryptsetup. You also need to upgrade the kernel, the 10.2 one does not support the on disk format you need via dm-crypt. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (3)
-
Jochen Hayek -
Ludwig Nussel -
Volker Kuhlmann