I've quoted my earlier post, but I'm making progress on this image. My
target so far has been a 16MB image, but I can go lower (or higher).
Some of these questions were fairly well answered by Warren, but I'm
curious if there is any other commentary regarding them (or even any
interest)?
I also have a few additional questions:
1) Will any client side authentication be desired? If so, what should
the client authenticate against?
2) Never any answer on how they are networked (it doesn't even have to
be ethernet, I could do a serial console thing too, but then you might
as well buy Wyse terminals...)
3) Basic utils once again?
Any other suggestions are of course appreceiated.
--MonMotha
I looked through the description of your project, and I have a few questions,
then I can get started building a floppy for you:
1) Do you want X11 or just a text console? If X11, what video hardware will be
on these (both monitor and video card)?
2) What kernel do you prefer? 2.0, 2.2, or 2.4. Older kernels tend to be
smaller, newer kernels support more nifty features. I'm opposed to 2.0
kernels, but will do either 2.2 or 2.4, whichever you prefer.
3) What kind of basic utils will you want? I use busybox, so you can check out
their site as to what is available, but I can also compile some stuff on my own
(though space is limited of course) provided the app can be compiled against
uClibc fairly easily.
4) I know you will be needing SSH, and I assume OpenSSH most recent unless you
want otherwise. The SSH needs to compile against uClibc.
5) How will these systems be networked (need to know the exact network cards,
or I can modularize it and write up a script to let you customize the disk)?
Will they be static IP, or dynamic? via DHCP, BOOTP, RARP?
A normal compressed ramdisk is 4MB once decompressed off the floppy into ram, but
obviously how much stuff can actually be fit onto it varies depending on the
compression level achieved. See my floppies I've already made for some hints as to
how much space the bare minimum takes up at
<http://videl.ics.hawaii.edu/~monmotha/hddlesslinux>. Obviously using a
ramdisk uses up valuable system ram to hold the filesystem.
Another option is to skip the ramdisk completely and go with an NFS mounted
root filesystem. This has the advantages that you obviously have a lot more
space as you don't have to cram everything onto the floppy and also allows the
filesystem to be changed centrally without having to even reboot the machines,
let alone update every single floppy. However, it also requires a lot more
network bandwidth as everything that touches the filesystem has to go over the
network. You also need to run NFS, which has been noted to have some security
flaws (good ol' SUNRPC) in the past.
Yet another option is a hybrid; this is where initrd really shines. I can have a tiny
root filesystem load up off the floppy into an initrd, then load a root filesystem image
into a larger ramdisk (size limited only by the amount of RAM in the machine really) by
downloading it from the central server by, say, tftp before handing control off to this
newly downloaded "real" root filesystem. This method is really cool because it
allows things like 20MB root filesystems (which you'd have trouble fitting on a floppy,
even gzip compressed) without any of the overhead from running live via NFS. The
downsides are that is uses a lot of RAM (32MB MINIMUM for this) and that if you update
the image on the server, the clients will need to be rebooted for the changes to take
effect.
For an example of how initrd can be used, RedHat uses one to load up a minimum
system to load kernel modules for bare minimum system hardware before actually
booting the rest of the system. This allows them to keep their kernels small
and generic by modularizing almost everything and keeping the modules your
system needs in an initrd image.
Depending on how much I need to do (X will take a while and I'll have major
trouble fitting it on a floppy!), I might be able to get a basic working disk
done in a day or so for you to start playing with.
--MonMotha
