Re: RFC: live-initramfs 2.x features
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.
> If by nested images you mean something like a full live iso on a http
> server or usb-hdd with supporting kernel/initramfs that loads the
> squashfs from it. This has apparently its limits but is still quite
> useful in many situations. Some of the limits would go away if you
> could kexec the kernel and initramfs included in the image.
with nested images, i ment if someone has an image stored on an image.
e.g. an iso image on another iso image.
>> * Network protocols (http, ftp, rsync)
>
> I don't think rsync or ftp is utterly useful - AFAIK they are wget
> equivalent (which still has its uses, especially with the cheap RAM
> these days).
rsync is nice in cases where you have a rw root medium, and can
basically sync the rootfs image over network.
>> * 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.
>> * One time argument handling (with proper respect of live.conf,
>> also from /live/live.conf)
>> * One time function handling
>
> What is one-time in a live system?
currently, the boot parameters are parsed more than one time in
different places. this should be redone, so that we parse it one and be
done with it.
>> * 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.
>> * Redo login manager support (kdm, gdm, nodm, plain startx on tty1)
>
> You forget the classic: xdm. This one might be incompatible with
> auto-login, though :-(
jup. if you know a way on how to do autologin with xdm, i'd be interested ;)
Regards,
Daniel
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Reply to: