From owner-freebsd-arch@FreeBSD.ORG Tue May 6 14:20:32 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA1C37B407 for ; Tue, 6 May 2003 14:20:31 -0700 (PDT) Received: from noisebox.cypherpunks.to (adsl-208-201-229-163.sonic.net [208.201.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D7543FBD for ; Tue, 6 May 2003 14:20:30 -0700 (PDT) (envelope-from shamrock@cypherpunks.to) Received: from VAIO650 (adsl-208-201-229-160.sonic.net [208.201.229.160]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noisebox.cypherpunks.to (Postfix) with ESMTP id 48EEA10E; Tue, 6 May 2003 14:20:29 -0700 (PDT) From: "Lucky Green" To: "'Poul-Henning Kamp'" Date: Tue, 6 May 2003 14:20:27 -0700 Message-ID: <007a01c31415$511623a0$6601a8c0@VAIO650> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <58760.1052253053@critter.freebsd.dk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: "'Geoffrey T. Falk'" cc: freebsd-arch@freebsd.org Subject: RE: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 21:20:32 -0000 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