Re: Poor Man's XT doc (pre-releace)
In article <[🔎] 9808131144070R.19176@lyta> you write:
>On Thu, 13 Aug 1998, Stephen J. Carpenter wrote:
>>>I have atteched here a document I am writting (mostly for my own interest)
>>This is the "Poor Man's XT". The aim is to be a full doc on how to
>>setup a debian linux system (based on 2.0) and make a working
>>"XTerminal" out of it.
>>The goals:
>>1. Should be able to be diskless, booting wither form boot prom or
>>a boot disk and NFS mounting the base system
>>2. System should be as small as possible.
>>3. Xserver etc should be able to be upgraded from dpkg
>>
>>accepted limitations:
>>1. Assumes XTerminal AND machine hosting its root filesystem via NFS are
>>on the SAME architecture.
>
>That fits 99% of all cases, but I'd love to have some Pentiums as X servers
>to an Alpha server!
I can't see why this is a problem. Unless you do something like share
/usr (my preference, I prefer to mount /usr as RO, as this means only
one copy needs to be kepts, at the expense that I can only update
packages from a given "master" computer, for me this is my NFS server),
I don't see why it should matter if the architecture of the
NFS server or xdm server is different.
Then again, I only have Intel computers and can't test this.
>>I am looking for any thoughts and suggestions on this, both technical and
>>in style of writting. Also...as far as this Doc is written is as far
>>as I have gotten with the project. I still have to work out the boot
>>disk (I don't have the ability to use boot proms..yet..) and all the
>>BOOTP/arp/rarp/NFS stuff....but so far it looks solid.
>>(any suggestions on how to continue with the project will be apriciated
>>too)
>
>Go to ftp://ivanova.coker.com.au/pub/Linux/kern-bin and you'll find some NFS
>packages of the 2.1 series kernels. The .deb files contain very recent
>kernels that don't work properly, and archives such as 2.1.XXXnfs.tar.bz2
>contain older versions that work well.
>To create a kernel for NFS-root operation you just build a recent 2.1.x kernel
>with "IP: Kernel level auto-configuration" enabled in the network options and
>NFS-root enabled in the file systems.
>Now create an nfs device file by:
>mknod /dev/nfs c 0 255 ; chmod 600 /dev/nfs
>
>That makes it possible to do "rdev kernel /dev/nfs" to setup NFS root
>operation, then you can just use "cat" to put the kernel on the disk.
If you use something like the debian package, diskless boot, and
modify the linux kernel with mknbi-linux, then I believe that
"IP: Kernel level auto-configuration" is optional (not tested),
and I have never needed /dev/nfs. I think mknbi-linux adds a header
that passes these parameters to the Linux kernel. It is also required
to make the diskless boot system recognise the image.
>X terminals generally run in insecure places, we don't really want someone to
>use a different kernel and take over the machine to create SUID programs on
>the server. We may be able to run the X terminal with it's root file system
>set up to be "root_squash" and have all files running as non-root. I haven't
>tried this, but it should work (but may take a bit of hackery). Also
>SUID-root programs on the NFS-root would have to be made non-SUID (probably a
>good idea anyway if you want to have only 2 processes running on the machine).
I am confused... How do you intend to run X as non-root? I think it
might be better just to make mount the NFS partitions as read-only,
for normal use.
The real problem I see, security wise, is that /etc cannot be read-only
as it contains files that must be writable (I think), like /etc/mtab. This
is really annoying. It also means that the root filesystem cannot
be shared. The root filesystem must contain /etc, /bin, /sbin, so I seperate
copy of all these files must be kept.
Of course, it may be possible to remount /etc as another writable
filesystem during boot, but this approach still makes me nervous (any
changes made to /etc will come out as errors before /etc is re-mounted).
Otherwise, it might just be possible to mount the entire root filesystem
as read-only except for /tmp and /var. I have heard of schemes where
the /tmp partition is a local harddisk that is formatted on start-up,
removing any long-term security implications. A seperate copy
of /var would be required for each diskless computer.
Reply to: