Re: RFC: live-initramfs 2.x features

[Michal Suchanek <hramrach@centrum.cz>]

2010/1/20 Daniel Baumann <daniel@debian.org>:
> Michal Suchanek wrote:
>>> Hi,
>
> Hi,
>
> as implied in the mail, some things are more important than others. this
> was a list without priorities, so e.g. while booting over iscsi is
> certainly nice to have, it will not happen that fast as other things are
> more important. however, it's good to keep it in mind right from the
> beginning, which is why it's on the list. similar with other things, so
> i'm not commenting on all the 'down-priorizing' comments of yours, which
> i mostly see the same way too anyway.

Yes, it makes sense to design the support functions generic enough to
support any of the methods without the need to actually have them
implemented all from the start.

>>>  * Allow tunneling (ssh, openvpn, ike) when network is needed to access
>>>    the root filesystem.
>>
>> Perhaps adding ssl to httpfs would be the simplest way. I wonder which
>> of these would run in the limited initramfs environment.
>
> at least ssh and openvpn are easy to use in initramfs, no idea about ike.
>
>> Also consider the security of the vmlinux/initramfs. Is adding more
>> security later really useful?
>
> if you can't trust the kernel and initrd, you're almost lost anyway.

That's the point I am making. When you question how the squashfs image
gets to the machine you should also question how the kernel and
innitramfs gets there which is much harder to secure in any meaningful
way.

>
>>>  * persistency layer on network shares, global and per user.
>>
>> GFS or other distributed fs?
>
> global as in live-rw, per user as in home-rw but only for the particular
> users home (some more like a home-rw-$user). fedora does this and it's
> an excellent feature.

Ah, that's separating different parts of the fs tree into different
persistency images.

I was just wondering what would happen when you boot 100 d-ls that use
the same network persistency location.

Thanks

Michal