Re: Proposal: /etc /usr/etc /usr/local/etc
This revisits the transname proposal. It looks to me
as if it was incompletely understood. I've added comments
inline below to clarify my understanding of this proposal.
(Of course, it's always possible that I misunderstand)
As I understand it (see my inline comments) this proposal
sounds workable to me, but it also sounds messy. Is this
proposal still alive, or does everyone consider it dead?
On Sat, 5 Jul 1997, Vadim Vygonets wrote:
> On Fri, 4 Jul 1997, Nils Rennebarth wrote:
> > On Fri, 4 Jul 1997, Yann Dirson wrote:
> > >Nils Rennebarth writes:
> > > > Please read /path_to_kernel-2.1_source/Documentation/transname.txt
> > >File read. Very interesting indeed.
There's been objection to this because 2.1 is a development kernel.
The transname stuff would have to reach a stable kernel to become
eligible for use in a debian release.
> > > > I then suggest to mount /usr and /etc from the central server. /etc could
> > > > overmount an existing /etc with a minimum of files in it needed while /usr
> > > > is not reachable.
Just to highlight this as I understand it --
- On workstations, there would be a minimal local /etc directory
for use during boot and before NFS mounts are done.
- The local /etc would be nfs-overmounted from the server in
Obviously, there's a problem with local machine-specific files
which need to live in /etc. One (the only?) example of this
is /etc/hostname (the local machine needs to know its unique
hostname for this scheme to work). A solution to this
problem might be to have the local hostname file (and other
problem files, if there are any) live in some directory other
than /etc on the local machine, and symlink them from /etc both
in the minimal local copy of /etc and in the nfs-overmounted
copy on the server.
There's also an admin problem maintaining the files in the
nfs-overmounted local copy of /etc. They're difficult to
get to after the nfs-overmount has been done.
> > >Yes, that might solve the problem for /etc. This may cause problems,
> > >though, because it would make the /etc dir on the server writable to
> > >all other systems...
Most (all?) files in /etc are writable only by root. Given
someone on a remote machine with root access, he could munge
files in /etc on the server even without this scheme. He
would, though, be less likely to do such munging by accident
without this scheme.
> > Better mount /etc readonly, and either centrally administer all etc's or
> > create /etc/..#hostname=host_a#'s owned by a the administrator of host_a,
> > that may be changed by him/her loggin onto the central server, by ssh,...
Note: The /etc filesystem on the server is in its own partition,
so it can nfs-overmount the /etc filesystems on the local machines.
It could be mounted read-only.
> /etc is one of the first things you need when booting a Unix box, you
> need it *way* before you mount /usr. And before you can mount
> anything at all.
And, with this scheme, you work with a local copy of /etc which
contains the files needed early-on until you can nfs-overmount it.
> /bin, /sbin, /dev and /etc (did I forget something?)
> _must_ be on the root partition, which can't be mounted read-only for
> various reasons. You just can't do such things.
Those would be truly-local files on all machines. Only /etc
would be nfs-overmounted, not the entire root filesystem.
Only /etc would be mounted read-only on the workstations, not
the entire root filesystem.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .