RFC: writing kernel cmdline options to grub.conf for dracut

Hi,

This morning I've been talking to Harald Hoyer about what sort of commandline options dracut will be needing to find the / filesystem beside root=UUID=1234567890 .

In most cases (normal disks, dmraid, mdraid, lvm, dmcrypt) root=UUID=1234567890 should suffice.

However in certain cases for example dracut will need additional info to find the disks.

We've come to the following plan for iscsi targets:
1) Extend the dhcp_root dhcp variable iscsi syntax to
be able include a username password, so:
iscsi:192.168.50.2::::iqn.2009-06.dracut:target66
Can become:
iscsi:user:[email protected]::::iqn.2009-06.dracut:target66
Or:
iscsi:user:pass:reverse_user:[email protected]::::iqn.2009-06.dracut:target66

2) Pass root-path=iscsi:... on the kernel cmdline, for each needed iscsi target, so if necessary this will be passed multiple times, dracut will be modified to be able handle multiple root-path arguments being passed in

3) chmod /proc/cmdline 400, so that it cannot be read by ordinary users, plugging the passwork leak problem

Now the remaining question is how to implement the adding of the needed cmdline options to grub.conf.

For the iscsi case (and atleast fcoe will be similar) I see the following 2 options, both of which are feasible:
1) Add code to iscsi.py to get the needed cmdline options

2) Add a dracutCmdlineOptions property to all Device classes, which will return the needed options (if any) to make the device in question available inside dracut.

One of the issues here is that onlining an iscsi target, may get us multiple disks as the target may have multiple LUN's. If more then one LUN of the same target is needed we might end up with having the same root-path=iscsi:... option twice on the cmdline, filtering this will be is easy though so this is not really an issue.

Looking at this from the iscsi pov, doing this from iscsi.py is easier, as that already has a list of targets instead of a list of disks (so LUN's) as the rest of the storage code has. Looking at this from the pov of the rest of the code it might be cleaner in the long run to make this a device property though.

So I'm not sure what to do, advice is / ideas are very welcome ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

This does not really plug the leak. Just boot until initramfs is loaded, pull the network plug and wait until dracut drops us to a (root-)shell.

Question: Is it really necessary to provide username/password to dracut? Wouldn't it be better to ask the user? I mean if a mount is password protected, be it cryptroot, nfs4 or whatever, shouldn't the user enter the data?

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Ah, which reminds me, that we should have an option to turn that off.

username/password for iSCSI disks entered by a normal user every day he boots his diskless client?

If a user has physical access to the machine, and the passwords are not encrypted with some key which has to be entered manually (which would be really awkward for say a headless server in a datacenter booting from an iSCSI SAN LUN) you've already lost.

Yes, in the case of machines booting of iSCSI it is, this is not a passphrase for encryption, this is authentication information to connect to an iSCSI target (one or more disks).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html