Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 May 2003 14:20:27 -0700
From:      "Lucky Green" <shamrock@cypherpunks.to>
To:        "'Poul-Henning Kamp'" <phk@phk.freebsd.dk>
Cc:        freebsd-arch@freebsd.org
Subject:   RE: Putting gbde to use: changes to fstab(5)? 
Message-ID:  <007a01c31415$511623a0$6601a8c0@VAIO650>
In-Reply-To: <58760.1052253053@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning wrote:
> In message <007901c3140b$8ccbad20$6601a8c0@VAIO650>, "Lucky 
> Green" writes:
> 
> >I believe there is a need for a convention specifying where and how
> >gbde(4)(8) encrypted devices should be listed in system 
> configuration 
> >files. I don't hugely care what convention will be chosen is 
> as long as 
> >there exists a clear convention that will enable authors to write 
> >software that will make it easy to deploy gbde.
> 
> I fully agree this far.
> 
> The point where I start to get uneasy is where people think 
> this will only be about GBDE.

[excellent examples illustrating why there is a need to provide for
additional disk-related configuration information elided]

> There got to be some way we can do this in sufficiently 
> general way, that it can be reused for other GEOM classes ?
> 
> I'm sorry I cannot take an active lead in this, but my TODO 
> list has recently eaten my pencil and the judge rule that it 
> was a clear and justified act of self-defence.

Understood, which is one of the reasons why I posted this question to
-arch. Perhaps what is required is a config file format and/or config
file tree for disks and file systems that is aware that disks many come
and go. I just happen to need a determination on a config file format
for gbde devices, because I would like to both deploy and contribute
back gbde automation tools.

Reading PHK's comments, it appears that file systems can perhaps be
categorized based on when they become available after boot. The
following rough list of categories may not be complete, but the total
number of categories may well be manageably small.

Immediately after boot:
/, swap, /usr
[Though some day in my life I would like to see everything in /usr not
required by sshd and gbde to be encrypted].

Some undetermined time after boot:
Encrypted file systems that require a password to be entered by remote
either via sshd or perhaps in the future via a remote authentication
server. Other network- connected storage that requires some type of
interaction.

File systems that may appear and disappear at any time:
Floppies, USB pen drives, etc.

I agree that when looking at the configuration file structure problem
from this perspective, fstab might become too complex should it be
expanded to meet all these needs. However, unless the solution would be
to remove fstab in its entirety, replacing it with "fstab.boot",
"fstab.later", and "fstab.removable" or the like, I believe that the
file systems should still be listed in fstab, which in turn perhaps
could contain one or more options indicating "for more configuration
information, look in [fstab.bde, fstab.removable, etc.] For example, an
option might read "rw,removable".

Whatever the solution might be, I believe determining a config file
structure or hierarchy on which we'll be able to build tools ultimately
comes down to an architectural question.

Thanks,
--Lucky



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007a01c31415$511623a0$6601a8c0>