Re: Redesign of diskless NFS-root package & ITP diskless-image
On Fri, Oct 01, 1999 at 05:39:15PM +0200, goswin.brederlow@student.uni-tuebingen.de wrote:
> > I have made most of the changed required for my redesign of diskless.
> > Amazingly, it looks like no changed are required for dpkg. I haven't
> > yet tested anything though, and implementing secure mode might be a bit
> > awkward. Currently I am considering the following:
> >
> > 1 installation moves /var, /dev, and /tmp into /rw/
> > 2 symlinks are created: /var --> /rw/var,
> > /dev --> /rw/dev, and
> > /tmp --> /rw/tmp.
> >
> > On startup (non-secure mode) /var, /dev, and /tmp are mounted
> > as usual, over the top of the directories under /rw/
> >
> > (should I do the same thing for /etc too? I inclined not to
> > - I think it should be read-only. Making /etc read-write
> > might make adding extra hosts easier, as all host
> > specific data can be copied and processed on startup)
>
> Do you support multiple clients? I would have a normal /etc that links
> most files to /share/etc and some to /rw/etc (the host specific stuff
> like hostname). /share would be on / and ro so its available on boot.
Yes. However, I don't use symlinks. Note: I think you may possibly
have confused my two (current) modes of operation. You
can either use diskless-image-secure*.deb or diskless-image-simple*.deb.
diskless-image-simple*.deb:
(for example - all directories on right have sample names)
/ is mounted from server:/var/sub/dir/root
This directory is created with my diskless-newimage perl script. The
computer boots. It checks that / is mounted readonly. If it is, then it
assumes that it is not the master system, and continues:
/etc is mounted from server:/var/sub/dir/$IP/etc
where $IP is the IP address of the computer. This subdirectory must
already exist, and is created with my diskless-newhost perl script.
The /etc directory now contains the /etc/fstab file which is
valid for the computer, and continues to boot as per
normal.
> > The result will be that /var, /dev, and /tmp are read-write,
> > but completely refreshed every-time the computer boots.
>
> ??? What do you mean here? Why copy anything at all? How should the
> filesystems be broken? Isn´t it the servers responsibility to keep
> them working? Do I have to copy my 2 GB /rw partition to /copy and
> then back over my 40KB/s plip link?
Question: do you want to run NFS-Root over 40KB/s plip links? I am
not being critical here, just curious.
In this case, you would use the diskless-image-simple*.deb package.
Files are only copied as the client requires them. However, while
/etc can be exported read-only, /var, /dev, and /tmp have to be
exported read/write. That would mean that somebody could break into the
network/computer and wreck the image. Some people I have talked to would
rather have all NFS exports read-only.
Note: Currently, no files under /var are copied, only the directory
structure. I am not yet sure if this will break anything (eg man-db)
which requires index files under /var. I imagine copying the directory
structure shouldn't take too long (not tested yet). The major problem is
/dev which may contain lots of devices.
> Try to install for an m68k/ppc/alpha diskless station on your i386. I
> might test i386/m68k/alpha in any combination for server and client
> if I find the diskspace for it.
That would lead to difficulties. Mainly that I don't have a
m68k/ppc/alpha ;-)
So, while I could test "dpkg --root alpha_image alpha_file.deb", I don't
think this is quite enough.
PS: telnetd doesn't work on my NFS-root computer. After considering the
matter, I realized the problem might be because devices on base2_1.tgz
have group and other write permission disabled. This probably includes
devices that manage /dev/pts.
Could somebody tell my what devices (and other files) *must* have group
and other write permission enabled? So far I have identified /dev/null
/dev/zero and /tmp.
Any reason why these are installed like this? Whats the best way to fix
all the permissions (in one operation prefered)?
--
Brian May <bam@snoopy.apana.org.au>
Reply to: