Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Feb 1999 13:42:09 -0500 (EST)
From:      Robert Watson <robert@cyrus.watson.org>
To:        "Matthew D. Fuller" <fullermd@futuresouth.com>
Cc:        Matt Dillon <dillon@FreeBSD.ORG>, chat@FreeBSD.ORG
Subject:   Re: cvs commit: src/etc rc
Message-ID:  <Pine.BSF.3.96.990202133601.14384A-100000@fledge.watson.org>
In-Reply-To: <19990125005946.U2971@futuresouth.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Jan 1999, Matthew D. Fuller wrote:

> On Sun, Jan 24, 1999 at 08:40:54PM -0800, a little birdie told me that Matt Dillon remarked
> > dillon      1999/01/24 20:40:54 PST
> > 
> >   Modified files:
> >     etc                  rc 
> >   Log:
> >       Introduce rc script for BOOTP 'diskless' boot.  Well, not quite diskless
> 
> This brings to mind a though that's been perking in my head in various
> incarnations for a while.
> 1) As soon as I aquire some new hardware (primarily motherboard for this
> system), I'm going to be making my home network a lot neater, with
> central fileserver etc.  I was looking at using CODA for filesharing.  I
> have two systems with flaky IDE controllers (well, they're Compaqs), so
> I'm probably going to just run them diskless instead of putzing with
> them.  Now, enter the truely interesting part...
> I have some systems I'd like to keep on -STABLE (3.0 now), like my
> dialup-router, etc.  And I'd like to play with -CURRENT.  Now, here's the
> kicker; using NFS (or perhaps preferably, CODA), set it up so this
> diskless workstation can be booted as either 3.0 or 4.0.  I realize this
> could well involve some truely ugly hackery (or 2 floppies, but that's
> cheating).  Since I'll probably have both trees on the fileserver anyway,
> I wouldn't think it'd be that much trouble to fluctuate.
> 
> Who wants to be the first to shoot it down?  ;>

I don't normally follow -chat regularly, so I didn't see this post before,
or I would have responded.  There are a few weirdo issues to address with
Coda to run diskless.  Some are security related, some are basic
functionality.

1) FIFO's and other wierdo-file-types cannot exist in /coda.  Therefore
you'll need an MFS or two lying around for software that requires this
stuff (probably for a /tmp, and maybe a /var/run or such).

2) Setuid/setgid files should probably not exist in Coda, and largely
don't already.  A cross-architecture file system with a completely
different concept of users and groups shouldn't be burdened with that kind
of thing.  As such, programs that rely on this functionality don't work.
AFS hacks around this by allowing setuid-root binaries to exist in AFS
local realms, but it's not clear that's the right answer.

3) Unkeyed access is insecure.  That is, if you don't have some way of
pre-keying and making all connections via a secure rpc channel, then you
allow things into your cache that aren't cryptographically protected.  So
if the machine boots up unattended and doesn't have a secret, and you're
using lots of stuff out of /coda, you're no better off than with NFS.  And
believe me, it would be nice to be better off than with NFS :).

4) Coda requires a userland daemon and local file space to use as a cache.
The daemon isn't so bad with an rc.diskless, but it does require local
disk space for a cache.  I have never tried the cache on MFS, although I
suppose it could be done.  Similarly, a lot of VM is required for RVM, the
logging system used for transaction support.  This suggests a local disk
layout of:

Some boot stuff
Big swap partition (to back logs and MFS)
Big cache partition

And then the remainder of the system over /cache.  Depending on how nuts
you are, sufficient memory is presumably a reasonable alternative to the
cache and swap partition.

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990202133601.14384A-100000>