From owner-freebsd-hackers  Wed Jul  3 22:59:38 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA03335
          for hackers-outgoing; Wed, 3 Jul 1996 22:59:38 -0700 (PDT)
Received: from kropotkin.gnu.ai.mit.edu (kropotkin.gnu.ai.mit.edu [128.52.46.40])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA03330;
          Wed, 3 Jul 1996 22:59:36 -0700 (PDT)
Received: by kropotkin.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id BAA14799; Thu, 4 Jul 1996 01:59:26 -0400
Date: Thu, 4 Jul 1996 01:59:26 -0400
Message-Id: <199607040559.BAA14799@kropotkin.gnu.ai.mit.edu>
To: terry@lambert.org
CC: gpalmer@FreeBSD.ORG, terry@lambert.org, jmb@freefall.freebsd.org,
        tom@sdf.com, jgreco@brasil.moneng.mei.com, root@friday.keanesea.com,
        hackers@FreeBSD.ORG
In-reply-to: <199607040504.WAA12377@phaeton.artisoft.com> (message from Terry
	Lambert on Wed, 3 Jul 1996 22:04:14 -0700 (MST))
Subject: Re: What is the best way to setup a drive
From: Joel Ray Holveck <joelh@gnu.ai.mit.edu>
Reply-to: joelh@gnu.ai.mit.edu
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


 >>> The "/etc" directory is not allowed to be other than on the root
 >>> file system, by definition.  That resolves the symlink problem.
 >> Umm? What was being talked about (if you remember) was having a
 >> read-only root filesystem. Then someone pointed out that that'd
 >> stop you changing passwords, so then a symlink from /etc to a
 >> read-write FS was suggested ... Which makes me wonder where your
 >> FS ``improvements'' fit in? They don't solve the problem of how to
 >> figure out where to get the /etc directory from.
 > I thought that was clear.  That /etc has to be writeable is a
 > bogus assumption.  The NIS suggestion for "where do I get my
 > passwords from" frees up /etc/passwd.

I had been responding to the symlink idea that jmb proposed.

Is there any problem with symlinking /etc/passwd to something on a r/w
filesystem instead of dealing with NIS, to deal with pre-yp programs
that don't think to call getpwent()?  I suppose that the /etc/ptmp
lockfile would have to be dealt with accordingly in that event, but
there should be ways to handle that.

Where are the perms for /dev/tty* stored?

  > What's left is /etc/fstab (dealt with by mount changes, which
  > aren't the same thing as FS changes), /etc/rc* (bogus) and
  > /etc/sysconfig (also bogus).

Hmmm... We may also want to change paths.h (and
src/sbin/nologin/nologin.5; why is it in that directory instead of
shutdown or login?) to take care of /etc/nologin, although shutdown
will work fine without changing it.  (Just be sure to remove it
manually your first attempt to boot with / r/o!)

Should the comment from /etc/rc concern us?: "root must be read/write
both for NFS diskless and for VFS LKMs before proceeding any further."

  > I really don't see where the problem is: throw out your
  > bogositieis and fix the rest to comply with the design documents,
  > and the problems all fade away.

Who said there's a problem?  I can't fix the programs at the current
time (no net connection on my test machine, forgot to pay the phone
bill), so I'm just pointing 'em out.

I'm new at this; what design documents are you referring to?

-- 
http://www.wp.com/piquan --- Joel Ray Holveck --- joelh@gnu.ai.mit.edu

Fourth law of computing:
  Anything that can go wro
.signature: segmentation violation -- core dumped