From owner-freebsd-arch@FreeBSD.ORG Sun Jul 20 05:54:04 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 C758F37B401 for ; Sun, 20 Jul 2003 05:54:04 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 438D743F75 for ; Sun, 20 Jul 2003 05:54:04 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc16o.dialup.mindspring.com ([209.86.4.216] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19eDdo-000029-00; Sun, 20 Jul 2003 05:50:17 -0700 Message-ID: <3F1A8FBE.E0ACB134@mindspring.com> Date: Sun, 20 Jul 2003 05:49:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian Dowse References: <200307200306.aa17802@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44af72e78ed244cb1780ad3a0328a17b9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: arch@freebsd.org Subject: Re: *statfs exposure of file system IDs to non-root users 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: Sun, 20 Jul 2003 12:54:05 -0000 Ian Dowse wrote: > In changing umount(8) to use statfs(2), I just noticed that the > various *statfs calls hide the filesystem IDs from non-root users: > > if (suser(td)) { > bcopy(sp, &sb, sizeof(sb)); > sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0; > sp = &sb; > } > > This was added in vfs_syscalls.c revision 1.61 (March 1997) and > came from OpenBSD. I guess the reason was to hide information that > gets used in NFS filehandles, but it doesn't do us any good now as > you can get the real IDs from getfsstat() as a normal user. Being > able to get and compare file system IDs is useful for umount, and > umount can be used by non-root users when vfs.usermount is set. > > Is there a good reason not to delete this fsid hiding? The real question is "Why do you need this information?". If you can answer that, we can probably tell you a different approach to solving your problem. -- Terry From owner-freebsd-arch@FreeBSD.ORG Sun Jul 20 08:01:03 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 0266C37B401 for ; Sun, 20 Jul 2003 08:01:03 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id E407743F85 for ; Sun, 20 Jul 2003 08:01:01 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Jul 2003 16:01:01 +0100 (BST) To: Terry Lambert In-Reply-To: Your message of "Sun, 20 Jul 2003 05:49:02 PDT." <3F1A8FBE.E0ACB134@mindspring.com> Date: Sun, 20 Jul 2003 16:00:58 +0100 From: Ian Dowse Message-ID: <200307201601.aa07561@salmon.maths.tcd.ie> cc: arch@freebsd.org Subject: Re: *statfs exposure of file system IDs to non-root users 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: Sun, 20 Jul 2003 15:01:03 -0000 In message <3F1A8FBE.E0ACB134@mindspring.com>, Terry Lambert writes: >Ian Dowse wrote: >> In changing umount(8) to use statfs(2), I just noticed that the >> various *statfs calls hide the filesystem IDs from non-root users: >The real question is "Why do you need this information?". > >If you can answer that, we can probably tell you a different >approach to solving your problem. See previous posts here on the subject of unmounting by filesystem ID. The filesystem ID is a way of unambiguously specifying which file system is to be unmounted, whereas the mountpoint or device node may not be unique. The umount utility now passes a filesystem ID to unmount(2), which works fine when run by root and when umount is extracting an entry from the list obtained from getfsstat(2), but it doesn't work as a normal user when the ID comes from statfs(2). Ian From owner-freebsd-arch@FreeBSD.ORG Sun Jul 20 09:37:06 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 0B2BA37B401 for ; Sun, 20 Jul 2003 09:37:06 -0700 (PDT) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AFC443F93 for ; Sun, 20 Jul 2003 09:37:05 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns1.gnf.org (8.12.8p1/8.12.8) with ESMTP id h6KGb4tF034624 for ; Sun, 20 Jul 2003 09:37:04 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Sun, 20 Jul 2003 09:37:04 -0700 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h6KGb4i2000184; Sun, 20 Jul 2003 09:37:04 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h6KGb4iP000183; Sun, 20 Jul 2003 09:37:04 -0700 (PDT) Date: Sun, 20 Jul 2003 09:37:03 -0700 From: Gordon Tetlow To: Ian Dowse Message-ID: <20030720163703.GF12996@roark.gnf.org> References: <200307200306.aa17802@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="14PCYtZiSn5RZRtk" Content-Disposition: inline In-Reply-To: <200307200306.aa17802@salmon.maths.tcd.ie> User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 20 Jul 2003 16:37:04.0746 (UTC) FILETIME=[271D0CA0:01C34EDD] cc: arch@freebsd.org Subject: Re: *statfs exposure of file system IDs to non-root users 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: Sun, 20 Jul 2003 16:37:06 -0000 --14PCYtZiSn5RZRtk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 20, 2003 at 03:06:13AM +0100, Ian Dowse wrote: >=20 > In changing umount(8) to use statfs(2), I just noticed that the > various *statfs calls hide the filesystem IDs from non-root users: >=20 > if (suser(td)) { > bcopy(sp, &sb, sizeof(sb)); > sb.f_fsid.val[0] =3D sb.f_fsid.val[1] =3D 0; > sp =3D &sb; > } >=20 > This was added in vfs_syscalls.c revision 1.61 (March 1997) and > came from OpenBSD. I guess the reason was to hide information that > gets used in NFS filehandles, but it doesn't do us any good now as > you can get the real IDs from getfsstat() as a normal user. Being > able to get and compare file system IDs is useful for umount, and > umount can be used by non-root users when vfs.usermount is set. >=20 > Is there a good reason not to delete this fsid hiding? I guess if > we do want to keep the values used in NFS handles secret while still > exposing useful IDs to userland, we could add a separate user-side > fsid to struct mount and use that instead. The IDs for NFS need to > be persistent across reboots, but the user ones don't. Note that > NFS filesystems use a hidden generation number for each file too, > so just knowing the filesystem ID isn't enough on its own to form > a valid handle. But it's that much less that an attacker needs to guess. Can you make it so a non-root user falls back to the old umount method, thereby not needing the fsid? I think if you have a hung remote NFS server, root probably needs to step in to check on things. -gordon --14PCYtZiSn5RZRtk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/GsUvRu2t9DV9ZfsRAlGyAJ484MRfYlyjLo+WXfugVtxuEA1+eACfSMai 5MhYb0kL15SG94L7cEZ2deU= =/Ml9 -----END PGP SIGNATURE----- --14PCYtZiSn5RZRtk-- From owner-freebsd-arch@FreeBSD.ORG Sun Jul 20 21:46:42 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 3957837B401 for ; Sun, 20 Jul 2003 21:46:42 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B15343FA3 for ; Sun, 20 Jul 2003 21:46:40 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id OAA14851; Mon, 21 Jul 2003 14:46:30 +1000 Date: Mon, 21 Jul 2003 14:46:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ian Dowse In-Reply-To: <200307200306.aa17802@salmon.maths.tcd.ie> Message-ID: <20030721135531.V2911@gamplex.bde.org> References: <200307200306.aa17802@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: *statfs exposure of file system IDs to non-root users 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: Mon, 21 Jul 2003 04:46:42 -0000 On Sun, 20 Jul 2003, Ian Dowse wrote: > In changing umount(8) to use statfs(2), I just noticed that the > various *statfs calls hide the filesystem IDs from non-root users: > > if (suser(td)) { > bcopy(sp, &sb, sizeof(sb)); > sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0; > sp = &sb; > } > > This was added in vfs_syscalls.c revision 1.61 (March 1997) and > came from OpenBSD. I guess the reason was to hide information that > gets used in NFS filehandles, but it doesn't do us any good now as > you can get the real IDs from getfsstat() as a normal user. This seems to be a bug in the import from OpenBSD. OpenBSD changed statfs() and getfsstat() in the same commit (rev.1.22 13-Feb-1997 in this file) to not expose f_fsid to non-root. > Being > able to get and compare file system IDs is useful for umount, and > umount can be used by non-root users when vfs.usermount is set. > Is there a good reason not to delete this fsid hiding? I guess if I never really understood hiding f_fsid for the mount point. In any case, it never actually worked for FreeBSD and doesn't seemed to have been adopted by NetBSD. > we do want to keep the values used in NFS handles secret while still > exposing useful IDs to userland, we could add a separate user-side > fsid to struct mount and use that instead. The IDs for NFS need to > be persistent across reboots, but the user ones don't. Note that > NFS filesystems use a hidden generation number for each file too, > so just knowing the filesystem ID isn't enough on its own to form > a valid handle. We expose part of the vfsid for at least nfs mountpoints via fake (st_dev) device numbers for stat(). See getnewfsid(). The exposed part is a sort of hopefully-unique hash of the fsid. umount could use something similar -- a guaranteed-unique unreversable hash of the fsid -- instead of the fsid if the fsid is considered too sensitive to expose. Guaranteed uniqueness in a snall number of bits (16) wouldn't hurt for getnewfsid() generally, but getnewfsid() has the additional reqirement of giving fairly persistent ids. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jul 21 00:53:49 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 7880C37B401 for ; Mon, 21 Jul 2003 00:53:49 -0700 (PDT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C17D43F93 for ; Mon, 21 Jul 2003 00:53:48 -0700 (PDT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.9/8.12.9) with ESMTP id h6L7rkPh023586; Mon, 21 Jul 2003 08:53:47 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)h6L7rkj9023579; Mon, 21 Jul 2003 08:53:46 +0100 (BST) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])h6L7q3Z2046577; Mon, 21 Jul 2003 08:52:03 +0100 (BST) (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200307210752.h6L7q3Z2046577@grimreaper.grondar.org> To: Terry Lambert In-Reply-To: Your message of "Thu, 17 Jul 2003 10:20:58 PDT." <3F16DAFA.41E237F8@mindspring.com> Date: Mon, 21 Jul 2003 08:52:03 +0100 Sender: mark@grondar.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_NO_LOWER,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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: Mon, 21 Jul 2003 07:53:49 -0000 Terry Lambert writes: > David O'Brien wrote: > > - tar, pax (w/{bz,g}zip) can do everything GNU tar can. > > I agree with everything but this one. Neither of these things can > make sparse files. Incorrect. Both can. M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-arch@FreeBSD.ORG Mon Jul 21 01:08:39 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 3AC8037B401 for ; Mon, 21 Jul 2003 01:08:39 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D20C43F3F for ; Mon, 21 Jul 2003 01:08:38 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h6L8bu6d012496 for ; Mon, 21 Jul 2003 04:37:57 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h6L88aU4026723 for arch@FreeBSD.org; Mon, 21 Jul 2003 01:08:36 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Jul 2003 01:08:36 -0700 From: John-Mark Gurney To: arch@FreeBSD.org Message-ID: <20030721080836.GF917@funkthat.com> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: module opt_* building X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2003 08:08:39 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I recently realized that for kernel module building, we can simply create a symlink pointing to the opt_*.h file created by config. (See attached patch.) This only is part of the work. The problem is that the modules/Makefile's define a target, which needs to be overriden in the case of being built as part of the kernel, and left intact when building standalone. The only thing I can think of is to add a opt_xxx.h_def or something similar to the target in the modules/Makefile, and then add a dependancy on that target in the standalone case. I have thought about a way to automate building of these options. It'd require setting up a file with defaults to build from. Extending options files? Yet another place to list options doesn't seem like a good idea. Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="conf.diff" Index: kern.pre.mk =================================================================== RCS file: /home/ncvs/src/sys/conf/kern.pre.mk,v retrieving revision 1.27 diff -u -r1.27 kern.pre.mk --- kern.pre.mk 2003/07/11 07:13:42 1.27 +++ kern.pre.mk 2003/07/21 08:01:25 @@ -87,7 +87,8 @@ # MKMODULESENV is set here so that port makefiles can augment # them. -MKMODULESENV= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} +MKMODULESENV= MAKEOBJDIRPREFIX=${.OBJDIR}/modules MAKEOBJDIR=${.OBJDIR} \ + KMODDIR=${KODIR} .if (${KERN_IDENT} == LINT) MKMODULESENV+= ALL_MODULES=LINT .endif Index: kmod.mk =================================================================== RCS file: /home/ncvs/src/sys/conf/kmod.mk,v retrieving revision 1.137 diff -u -r1.137 kmod.mk --- kmod.mk 2003/03/03 22:51:22 1.137 +++ kmod.mk 2003/07/21 08:01:25 @@ -240,9 +240,15 @@ .for _src in ${SRCS:Mopt_*.h} CLEANFILES+= ${_src} +.if defined(MAKEOBJDIR) +${_src}: + rm ${.TARGET} && ln -s ${MAKEOBJDIR}/${.TARGET} +.else .if !target(${_src}) +# add code to generate opt_ file from conf. ${_src}: touch ${.TARGET} +.endif .endif .endfor --dDRMvlgZJXvWKvBx-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 21 10:34:44 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 4AEAA37B401 for ; Mon, 21 Jul 2003 10:34:44 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A896143F3F for ; Mon, 21 Jul 2003 10:34:43 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfmrb.dialup.mindspring.com ([165.247.219.107] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19eeYU-0007FE-00; Mon, 21 Jul 2003 10:34:35 -0700 Message-ID: <3F1C23EA.7E06CDA9@mindspring.com> Date: Mon, 21 Jul 2003 10:33:30 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian Dowse References: <200307201601.aa07561@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cb40baf9b8b16471fdd325ebc9837fcc3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: arch@freebsd.org Subject: Re: *statfs exposure of file system IDs to non-root users 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: Mon, 21 Jul 2003 17:34:44 -0000 Ian Dowse wrote: > See previous posts here on the subject of unmounting by filesystem > ID. The filesystem ID is a way of unambiguously specifying which > file system is to be unmounted, whereas the mountpoint or device > node may not be unique. Yes, I'm aware of this facility for breaking sub-mounts. 8-). The implementation of mounts needs to change so that the mounts occur in the higher layers, rather than the lower, for the covered vnode. > The umount utility now passes a filesystem > ID to unmount(2), which works fine when run by root and when umount > is extracting an entry from the list obtained from getfsstat(2), > but it doesn't work as a normal user when the ID comes from statfs(2). Normal users should not be permitted to unmount /. 8-). -- Terry From owner-freebsd-arch@FreeBSD.ORG Mon Jul 21 12:15:42 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 DF32337B401 for ; Mon, 21 Jul 2003 12:15:42 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2ACF43FA3 for ; Mon, 21 Jul 2003 12:15:41 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25231 invoked from network); 21 Jul 2003 19:15:41 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 21 Jul 2003 19:15:41 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6LJFcGI039876; Mon, 21 Jul 2003 15:15:38 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030719171138.GA86442@dragon.nuxi.com> Date: Mon, 21 Jul 2003 15:15:53 -0400 (EDT) From: John Baldwin To: "David O'Brien" cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue 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: Mon, 21 Jul 2003 19:15:43 -0000 On 19-Jul-2003 David O'Brien wrote: > On Thu, Jul 17, 2003 at 02:51:47PM -0400, John Baldwin wrote: >> >> On 17-Jul-2003 David O'Brien wrote: >> > On Thu, Jul 17, 2003 at 09:17:00AM -0700, Luigi Rizzo wrote: >> >> whatever it is, certainly the purpose is not to show how good >> >> a sysadmin is in using a knife's blade as a screwdriver and a fork >> >> and a spoon. Heck, even swiss army knives have these extra >> >> tools. >> >> >> >> I think that if something in /rescue can make the task faster >> >> and less error prone, removing it to save 10-50k of disk space >> >> would be a big mistake. >> > >> > You must not have seen my other email that listed other things than just >> > disk space. If I did need to get to the Internet to get bits, what does >> > ipfw do for me that "sysctl net.inet.ip.fw.enable=0" doesn't? >> >> This doesn't handle ipfilter. You've conveniently ignored that point it >> seems. > > No, I have little ipfilter experience so I didn't speak to it. My > language explicitly mentioned ipfw so I assumed readers would understand > I was only addressing ipfw in that email. You've listed ipfilter tools such as ipnat, etc. on your list, so you have "spoken to it". Perhaps you shouldn't blindly remove tools if you don't know how they work? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Mon Jul 21 13:23:16 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 7C64937B401; Mon, 21 Jul 2003 13:23:16 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD5C243FA3; Mon, 21 Jul 2003 13:23:15 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h6LKNEju021233; Mon, 21 Jul 2003 13:23:15 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h6LKNEsY021232; Mon, 21 Jul 2003 13:23:14 -0700 (PDT) Date: Mon, 21 Jul 2003 13:23:14 -0700 From: "David O'Brien" To: John Baldwin Message-ID: <20030721202314.GC21068@dragon.nuxi.com> References: <20030719171138.GA86442@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2003 20:23:16 -0000 On Mon, Jul 21, 2003 at 03:15:53PM -0400, John Baldwin wrote: > > On 19-Jul-2003 David O'Brien wrote: > > On Thu, Jul 17, 2003 at 02:51:47PM -0400, John Baldwin wrote: > >> > >> On 17-Jul-2003 David O'Brien wrote: > >> > On Thu, Jul 17, 2003 at 09:17:00AM -0700, Luigi Rizzo wrote: > >> >> whatever it is, certainly the purpose is not to show how good > >> >> a sysadmin is in using a knife's blade as a screwdriver and a fork > >> >> and a spoon. Heck, even swiss army knives have these extra > >> >> tools. > >> >> > >> >> I think that if something in /rescue can make the task faster > >> >> and less error prone, removing it to save 10-50k of disk space > >> >> would be a big mistake. > >> > > >> > You must not have seen my other email that listed other things than just > >> > disk space. If I did need to get to the Internet to get bits, what does > >> > ipfw do for me that "sysctl net.inet.ip.fw.enable=0" doesn't? > >> > >> This doesn't handle ipfilter. You've conveniently ignored that point it > >> seems. > > > > No, I have little ipfilter experience so I didn't speak to it. My > > language explicitly mentioned ipfw so I assumed readers would understand > > I was only addressing ipfw in that email. > > You've listed ipfilter tools such as ipnat, etc. on your list, so you > have "spoken to it". Perhaps you shouldn't blindly remove tools if > you don't know how they work? You seem to have another email in mind than the one you've been replying to. Please answer the question asked: If I did need to get to the Internet to get bits, what does ipfw do for me that "sysctl net.inet.ip.fw.enable=0" doesn't? the reader should assume the user is using ipfw and not another packet filter. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 01:31:21 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 69BAB37B401; Tue, 22 Jul 2003 01:31:21 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69A643FAF; Tue, 22 Jul 2003 01:31:19 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.20) id 19esYH-000LuZ-KB; Tue, 22 Jul 2003 10:31:17 +0200 Date: Tue, 22 Jul 2003 10:31:17 +0200 From: Sheldon Hearn To: David O'Brien Message-ID: <20030722083117.GC66789@starjuice.net> Mail-Followup-To: David O'Brien , freebsd-arch@FreeBSD.org References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030721202314.GC21068@dragon.nuxi.com> User-Agent: Mutt/1.5.4i Sender: Sheldon Hearn cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue 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, 22 Jul 2003 08:31:21 -0000 On (2003/07/21 13:23), David O'Brien wrote: > You seem to have another email in mind than the one you've been replying > to. Please answer the question asked: > > If I did need to get to the Internet to get bits, what does ipfw do > for me that "sysctl net.inet.ip.fw.enable=0" doesn't? > > the reader should assume the user is using ipfw and not another packet > filter. What ipfw gives you that sysctl net.inet.ip.fw.enable=0 doesn't is the ability to arrange _limited_ Internet connectivity without opening up a hole so big a truck could drive through it. Ciao, Sheldon. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 02:10:30 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 8DC8E37B409; Tue, 22 Jul 2003 02:10:30 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 609B643FB1; Tue, 22 Jul 2003 02:10:29 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 2702B78D9A; Tue, 22 Jul 2003 11:10:28 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id C0C379605F; Tue, 22 Jul 2003 11:10:27 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id C719195938; Tue, 22 Jul 2003 11:10:22 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 82974B822; Tue, 22 Jul 2003 11:10:22 +0200 (CEST) To: obrien@FreeBSD.org References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 22 Jul 2003 11:10:22 +0200 In-Reply-To: <20030721202314.GC21068@dragon.nuxi.com> (David O'Brien's message of "Mon, 21 Jul 2003 13:23:14 -0700") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-3.0 required=8.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: John Baldwin cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue 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, 22 Jul 2003 09:10:31 -0000 "David O'Brien" writes: > If I did need to get to the Internet to get bits, what does ipfw do > for me that "sysctl net.inet.ip.fw.enable=3D0" doesn't? ipfw -q flush ipfw add pass ip from any to any via lo0 ipfw add check-state ipfw add pass udp from me to any domain,ntp out keep-state ipfw add pass tcp from me to any out setup keep-state ipfw add deny all from any to any DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 03:12:01 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 8976437B401 for ; Tue, 22 Jul 2003 03:12:01 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9C0543FCB for ; Tue, 22 Jul 2003 03:11:59 -0700 (PDT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h6MABvgh027496; Tue, 22 Jul 2003 20:11:58 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h6MABg5Q027495; Tue, 22 Jul 2003 20:11:42 +1000 (EST) Date: Tue, 22 Jul 2003 20:11:42 +1000 From: Peter Jeremy To: Mark Murray Message-ID: <20030722101142.GB4105@cirb503493.alcatel.com.au> References: <3F16DAFA.41E237F8@mindspring.com> <200307210752.h6L7q3Z2046577@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307210752.h6L7q3Z2046577@grimreaper.grondar.org> User-Agent: Mutt/1.4.1i cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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, 22 Jul 2003 10:12:01 -0000 On Mon, Jul 21, 2003 at 08:52:03AM +0100, Mark Murray wrote: >Terry Lambert writes: >> David O'Brien wrote: >> > - tar, pax (w/{bz,g}zip) can do everything GNU tar can. >> >> I agree with everything but this one. Neither of these things can >> make sparse files. > >Incorrect. Both can. Not accurately. They can detect that a file is sparse by comparing the st_size and st_blocks fields returned by stat(). They can't accurately differentiate between a block of NULs and a non-allocated block in a sparse file. AFAIK, the only utility that can exactly reproduce a sparse file is dump/restore. Peter From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 08:11:47 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 1B59437B401; Tue, 22 Jul 2003 08:11:47 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 529B743F3F; Tue, 22 Jul 2003 08:11:46 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h6MFBcju072949; Tue, 22 Jul 2003 08:11:38 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h6MFBcFI072948; Tue, 22 Jul 2003 08:11:38 -0700 (PDT) Date: Tue, 22 Jul 2003 08:11:38 -0700 From: "David O'Brien" To: Dag-Erling Sm?rgrav Message-ID: <20030722151138.GB72888@dragon.nuxi.com> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: John Baldwin cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 15:11:47 -0000 On Tue, Jul 22, 2003 at 11:10:22AM +0200, Dag-Erling Sm?rgrav wrote: > "David O'Brien" writes: > > If I did need to get to the Internet to get bits, what does ipfw do > > for me that "sysctl net.inet.ip.fw.enable=0" doesn't? > > ipfw -q flush > ipfw add pass ip from any to any via lo0 > ipfw add check-state > ipfw add pass udp from me to any domain,ntp out keep-state You need to run NTP to rescue your FUBAR'ed /lib??? If you're this worried about someone breaking into you when you've got *zero* services running, use a 2nd machine to get those magical bits from the Internet that will fix your FUBAR'ed /lib. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 08:31:06 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 1FA0337B401; Tue, 22 Jul 2003 08:31:06 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4315E43F85; Tue, 22 Jul 2003 08:31:04 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.20) id 19ez6P-0001vh-8R; Tue, 22 Jul 2003 17:30:57 +0200 Date: Tue, 22 Jul 2003 17:30:56 +0200 From: Sheldon Hearn To: David O'Brien Message-ID: <20030722153056.GM863@starjuice.net> Mail-Followup-To: David O'Brien , Dag-Erling Sm?rgrav , John Baldwin , freebsd-arch@FreeBSD.org References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030722151138.GB72888@dragon.nuxi.com> User-Agent: Mutt/1.5.4i Sender: Sheldon Hearn cc: Dag-Erling Sm?rgrav cc: John Baldwin cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue 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, 22 Jul 2003 15:31:06 -0000 On (2003/07/22 08:11), David O'Brien wrote: > > ipfw -q flush > > ipfw add pass ip from any to any via lo0 > > ipfw add check-state > > ipfw add pass udp from me to any domain,ntp out keep-state > > You need to run NTP to rescue your FUBAR'ed /lib??? I don't understand why you chopped off the significant rule: > > ipfw add pass tcp from me to any out setup keep-state So let me restate DES case without examples. It may be that someone wishing to recover a hosed box will both a) want access to some network-hosted resource, and b) want to maintain network security while accessing that resource. I don't see this as an unreasonable requirement, and I can't see what great cost it incurs that would motivate us to remove support for it. And remember, this is just one aspect of your "trimming down /rescue". Nobody's insisting that we keep the bath water. :-) Ciao, Sheldon. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 08:31:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 683) id 7A31E37B401; Tue, 22 Jul 2003 08:31:17 -0700 (PDT) Date: Tue, 22 Jul 2003 08:31:17 -0700 From: Eivind Eklund To: arch@FreeBSD.org Message-ID: <20030722083117.A36628@FreeBSD.org> References: <20030721080836.GF917@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030721080836.GF917@funkthat.com>; from gurney_j@efn.org on Mon, Jul 21, 2003 at 01:08:36AM -0700 Subject: Re: module opt_* building 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, 22 Jul 2003 15:31:17 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 21, 2003 at 01:08:36AM -0700, John-Mark Gurney wrote: > I recently realized that for kernel module building, we can simply create > a symlink pointing to the opt_*.h file created by config. (See attached > patch.) > > This only is part of the work. The problem is that the modules/Makefile's > define a target, which needs to be overriden in the case of being built > as part of the kernel, and left intact when building standalone. > > The only thing I can think of is to add a opt_xxx.h_def or something > similar to the target in the modules/Makefile, and then add a dependancy > on that target in the standalone case. > > I have thought about a way to automate building of these options. It'd > require setting up a file with defaults to build from. Extending options > files? Yet another place to list options doesn't seem like a good idea. > > Comments? The attached patch is a year-old attempt to deal with the same case; I had some problems with it, but don't remember what exactly it was (some weird error, I remember...) I'd think the infrastructure should probably be extended so each module can contain a file 'config' which contains suitable kernel config fragments to build that module, and which is run alongside a normal config for that module. Not quite sure what implementation to use for this - possibly a new way of running config(8) to generate a suitable build space for each module? Eivind. --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="modules-with-kernel-options.patch" Index: conf/Makefile.i386 =================================================================== RCS file: /home/ncvs/src/sys/conf/Makefile.i386,v retrieving revision 1.255 diff -u -r1.255 Makefile.i386 --- conf/Makefile.i386 20 Feb 2002 23:35:49 -0000 1.255 +++ conf/Makefile.i386 2 Mar 2002 14:48:10 -0000 @@ -30,7 +30,8 @@ .endif .include "$S/conf/kern.pre.mk" -MKMODULESENV+= MACHINE=i386 +KERNCOMPILEDIR!=pwd +MKMODULESENV+= MACHINE=i386 KERNCOMPILEDIR=${KERNCOMPILEDIR} %BEFORE_DEPEND Index: conf/kmod.mk =================================================================== RCS file: /home/ncvs/src/sys/conf/kmod.mk,v retrieving revision 1.113 diff -u -r1.113 kmod.mk --- conf/kmod.mk 1 Mar 2002 01:21:29 -0000 1.113 +++ conf/kmod.mk 13 Mar 2002 14:13:20 -0000 @@ -93,15 +93,20 @@ .SUFFIXES: .out .o .c .cc .cxx .C .y .l .s .S -CFLAGS+= ${COPTS} -D_KERNEL ${CWARNFLAGS} -CFLAGS+= -DKLD_MODULE # Don't use any standard or source-relative include directories. # Since -nostdinc will annull any previous -I paths, we repeat all # such paths after -nostdinc. It doesn't seem to be possible to # add to the front of `make' variable. _ICFLAGS:= ${CFLAGS:M-I*} -CFLAGS+= -nostdinc -I- ${INCLMAGIC} ${_ICFLAGS} +#CFLAGS= ${COPTFLAGS} -D_KERNEL ${CWARNFLAGS} +CFLAGS+= -D_KERNEL ${CWARNFLAGS} +CFLAGS+= -DKLD_MODULE +CFLAGS+= -nostdinc -I- ${INCLMAGIC} +.if defined(KERNCOMPILEDIR) +CFLAGS+= -I. -I${KERNCOMPILEDIR} -include ${KERNCOMPILEDIR}/opt_global.h +.endif +CFLAGS+=${_ICFLAGS} # Add -I paths for system headers. Individual KLD makefiles don't # need any -I paths for this. Similar defaults for .PATH can't be --WIyZ46R2i8wDzkSu-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 17:25:54 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 E541237B401 for ; Tue, 22 Jul 2003 17:25:54 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-222-108.res.east.verizon.net [141.156.222.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18B9943F3F for ; Tue, 22 Jul 2003 17:25:46 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (grlzmhs21tko6swt@localhost [127.0.0.1]) id h6N0PY49044660 for ; Tue, 22 Jul 2003 20:25:34 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h6N0PWxK044659 for freebsd-arch@FreeBSD.org; Tue, 22 Jul 2003 20:25:32 -0400 (EDT) (envelope-from mtm@identd.net) X-Authentication-Warning: kokeb.ambesa.net: mtm set sender to mtm@identd.net using -f Date: Tue, 22 Jul 2003 20:25:32 -0400 From: Mike Makonnen To: freebsd-arch@FreeBSD.org Message-ID: <20030723002531.GA44452@kokeb.ambesa.net> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030722153056.GM863@starjuice.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 00:25:55 -0000 > So let me restate DES case without examples. > > It may be that someone wishing to recover a hosed box will both > > a) want access to some network-hosted resource, and >From what I can see the only network resource one could access is an nfs mount, since it seems unlikely you could rely on anything outside /rescue (such as ftp or ssh) being available. > b) want to maintain network security while accessing that resource. What security? There are no network services running in single-user, so what is there to secure? > I don't see this as an unreasonable requirement, and I can't see what > great cost it incurs that would motivate us to remove support for it. > > And remember, this is just one aspect of your "trimming down /rescue". > Nobody's insisting that we keep the bath water. :-) I won't complain if it's kept, but I would prefer just the bare minimum be kept in /rescue. Once you go beyond that and into "well s/he might need..." territory then we might as well throw in everything in the base system. IMO, /rescue should be the absolute essentials _only_. Instead of theorizing reasons why someone might need ipfw and friends, why don't we wait until we get a bug report about a specific situation in which it was needed before we put it back in. Also, while you're at it, David, I think you can get rid of rcorder as well. I don't know why one would need it to fix a hosed root, and besides it's staticaly linked to begin with. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 17:31:31 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 B247B37B404 for ; Tue, 22 Jul 2003 17:31:31 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-222-108.res.east.verizon.net [141.156.222.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7012C43F85 for ; Tue, 22 Jul 2003 17:31:22 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (jxrpbnm68d4gjefb@localhost [127.0.0.1]) id h6N0VE49044687 for ; Tue, 22 Jul 2003 20:31:14 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h6N0VEhJ044686 for freebsd-arch@freebsd.org; Tue, 22 Jul 2003 20:31:14 -0400 (EDT) (envelope-from mtm@identd.net) X-Authentication-Warning: kokeb.ambesa.net: mtm set sender to mtm@identd.net using -f Date: Tue, 22 Jul 2003 20:31:14 -0400 From: Mike Makonnen To: freebsd-arch@freebsd.org Message-ID: <20030723003113.GB44452@kokeb.ambesa.net> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723002531.GA44452@kokeb.ambesa.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 00:31:32 -0000 On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: > > Also, while you're at it, David, I think you can get rid of rcorder > as well. I don't know why one would need it to fix a hosed root, > and besides it's staticaly linked to begin with. heh. disregard that last part about it being statically linked. I don't know what i was thinking. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 20:50:07 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 EB22437B401 for ; Tue, 22 Jul 2003 20:50:07 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B77343FB1 for ; Tue, 22 Jul 2003 20:50:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) h6N3o6h5045434; Tue, 22 Jul 2003 20:50:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)h6N3o6km045433; Tue, 22 Jul 2003 20:50:06 -0700 (PDT) Date: Tue, 22 Jul 2003 20:50:06 -0700 From: Steve Kargl To: Mike Makonnen Message-ID: <20030723035006.GA45410@troutmask.apl.washington.edu> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723002531.GA44452@kokeb.ambesa.net> User-Agent: Mutt/1.4.1i cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 03:50:08 -0000 On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: > > So let me restate DES case without examples. > > > > It may be that someone wishing to recover a hosed box will both > > > > a) want access to some network-hosted resource, and > > >From what I can see the only network resource one could access is an > nfs mount, since it seems unlikely you could rely on anything > outside /rescue (such as ftp or ssh) being available. > > > b) want to maintain network security while accessing that resource. > > What security? There are no network services running in single-user, > so what is there to secure? > Don't you need a network connection to use /rescue/rrestore to access the dump of / on a tape drive in a remote system? One may want a secure connection to that remote system. -- Steve From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 21:34:13 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 BAA7C37B401 for ; Tue, 22 Jul 2003 21:34:13 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-222-108.res.east.verizon.net [141.156.222.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98EEF43F93 for ; Tue, 22 Jul 2003 21:34:12 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (ibzt93y9h3wjrefo@localhost [127.0.0.1]) id h6N4YB49045784; Wed, 23 Jul 2003 00:34:11 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h6N4YBu3045783; Wed, 23 Jul 2003 00:34:11 -0400 (EDT) (envelope-from mtm@identd.net) X-Authentication-Warning: kokeb.ambesa.net: mtm set sender to mtm@identd.net using -f Date: Wed, 23 Jul 2003 00:34:11 -0400 From: Mike Makonnen To: Steve Kargl Message-ID: <20030723043410.GA45652@kokeb.ambesa.net> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> <20030723035006.GA45410@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723035006.GA45410@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 04:34:14 -0000 On Tue, Jul 22, 2003 at 08:50:06PM -0700, Steve Kargl wrote: > > Don't you need a network connection to use /rescue/rrestore to access > the dump of / on a tape drive in a remote system? One may want a > secure connection to that remote system. ahh yes, I also missed rcp. But, that doesn't change the situation much. Ipfw is a firewall. I don't see how it can have a useful impact on security in this situation. The point I was trying to make in the email is that there isn't much security that ipfw can offer you in this situation that is a compelling or even "must have" feature of rescue. Like I said, I don't object to having it in /rescue if that's the consensus, but I would much prefer if we left it out and see if any bug reports come in. There is nothing preventing us from including it in the future if it is really needed by our users. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-arch@FreeBSD.ORG Tue Jul 22 23:40:04 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 2E9E337B401 for ; Tue, 22 Jul 2003 23:40:04 -0700 (PDT) Received: from mail.auriga.ru (mail.auriga.ru [80.240.102.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1E6D43F3F for ; Tue, 22 Jul 2003 23:40:00 -0700 (PDT) (envelope-from alex.neyman@auriga.ru) Received: from mail.loopback.interface ([127.0.0.1] helo=vagabond.auriga.ru) by mail.auriga.ru with esmtp (Exim 4.14) id 19fDOs-00085s-0s; Wed, 23 Jul 2003 10:46:58 +0400 From: Alexey Neyman Organization: Auriga, Inc. To: Sheldon Hearn Date: Wed, 23 Jul 2003 10:42:29 +0400 User-Agent: KMail/1.5.1 References: <20030719171138.GA86442@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> In-Reply-To: <20030722153056.GM863@starjuice.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307231042.29371.alex.neyman@auriga.ru> cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 06:40:04 -0000 Hi, there! On Tuesday 22 July 2003 19:30, Sheldon Hearn wrote: > I don't see this as an unreasonable requirement, and I can't see what > great cost it incurs that would motivate us to remove support for it. Can't all this be done in a "user needs it, user adds it" fashion? E.g., to add /etc/rescue.mk that will be .include'd in src/rescue/rescue/Makefile, adding the required binaries to the CRUNCH_PROGS_bin, CRUNCH_PROG_sbin, CRUNCH_LIBS lists? E.g: --- /etc/rescue.mk --- CRUNCH_PROGS_sbin += chown This will allow the "base" list to be trimmed to some minimalist level, and will still allow the users to add whatever they [think they] need to restore their system. Regards, Alexey. -- A quoi ca sert d'etre sur la terre Si c'est pour faire nos vies a genoux? From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 03:02:39 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 576B337B401 for ; Wed, 23 Jul 2003 03:02:39 -0700 (PDT) Received: from gurney.bluecom.no (gurney.bluecom.no [217.118.32.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A38F543FBF for ; Wed, 23 Jul 2003 03:02:38 -0700 (PDT) (envelope-from eirikn@kerneled.com) Received: from eirikn.net (a217-118-47-91.bluecom.no [217.118.47.91]) by gurney.bluecom.no (Postfix) with ESMTP id 06AEEA7AE1 for ; Wed, 23 Jul 2003 12:02:37 +0200 (CEST) Received: by eirikn.net (Postfix, from userid 1001) id 825C456; Wed, 23 Jul 2003 12:04:44 +0200 (CEST) Date: Wed, 23 Jul 2003 12:04:44 +0200 From: Eirik Nygaard To: arch@freebsd.org Message-ID: <20030723100444.GA83571@eirikn.net> Mail-Followup-To: arch@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Re: module opt_* building X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: eirikn@kerneled.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 10:02:39 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2003 at 01:08:36AM -0700, John-Mark Gurney wrote: > I recently realized that for kernel module building, we can simply create > a symlink pointing to the opt_*.h file created by config. (See attached > patch.) >=20 > This only is part of the work. The problem is that the modules/Makefile's > define a target, which needs to be overriden in the case of being built > as part of the kernel, and left intact when building standalone. >=20 > The only thing I can think of is to add a opt_xxx.h_def or something > similar to the target in the modules/Makefile, and then add a dependancy > on that target in the standalone case. I did not come up with another way to do it so I used the described approach. Did not attach the patch, but it can be found at http://kerneled.com/eirikn/freebsd/kmod_modules.diff > I have thought about a way to automate building of these options. It'd > require setting up a file with defaults to build from. Extending options > files? Yet another place to list options doesn't seem like a good idea. >=20 > Comments? The attached a patch symlinks the opt_*.h files and the files created by makeobjops.awk(So they don't have to be created several times in one kernel build). Sent this mail to John-Mark Gurney last night by mistake, hit the wrong replay button. --=20 Eirik Nygaard PGP Key: 83C55EDE --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/Hl281JB0Z4PFXt4RAraVAJwJ3LDEiYSHCKgLQYwFHBG9iD/MWwCeL5/H RPBcXOyxZkxw3Y10/UmW5BM= =GtQb -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 10:56:35 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 D1CA037B405 for ; Wed, 23 Jul 2003 10:56:35 -0700 (PDT) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC0DC43F3F for ; Wed, 23 Jul 2003 10:56:34 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25027 invoked from network); 23 Jul 2003 17:56:34 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 23 Jul 2003 17:56:34 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6NHuWGI046305; Wed, 23 Jul 2003 13:56:32 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030723043410.GA45652@kokeb.ambesa.net> Date: Wed, 23 Jul 2003 13:56:49 -0400 (EDT) From: John Baldwin To: Mike Makonnen cc: Steve Kargl cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 17:56:36 -0000 On 23-Jul-2003 Mike Makonnen wrote: > On Tue, Jul 22, 2003 at 08:50:06PM -0700, Steve Kargl wrote: >> >> Don't you need a network connection to use /rescue/rrestore to access >> the dump of / on a tape drive in a remote system? One may want a >> secure connection to that remote system. > > ahh yes, I also missed rcp. But, that doesn't change the situation > much. Ipfw is a firewall. I don't see how it can have a useful > impact on security in this situation. The point I was trying to > make in the email is that there isn't much security that ipfw > can offer you in this situation that is a compelling or even > "must have" feature of rescue. Like I said, I don't object to > having it in /rescue if that's the consensus, but I would much > prefer if we left it out and see if any bug reports come in. > There is nothing preventing us from including it in the future > if it is really needed by our users. If you prefer to be sitting at a machine's single user prompt one day, going "dang, if only rescue had I wouldn't be totally screwed, and gee, it only cost 5k in disk space as well" rather than resurrecting a dead machine during that time, then I find that rather odd. Didn't the original rescue list come from NetBSD in the first place where it has already gone through one round of revisions? Or do you all just think that NetBSD's rescue is poorly designed and bloated so you need to one-up them for some reason? Maybe NetBSD has ipfw in their rescue because, gee, they've gotten a bug report on it? I wouldn't be so quick to discount the experience put into software that we nab from other places. I also think that there should be some actual size numbers of what we gain by trimming /rescue should be done prior to commit. It can only help to have added functionality for some corner case if it only adds a couple of kb in size. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 12:48:29 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 F1E2D37B401; Wed, 23 Jul 2003 12:48:28 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-222-108.res.east.verizon.net [141.156.222.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFFC543F75; Wed, 23 Jul 2003 12:48:27 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (pca2kiv19cuwkwas@localhost [127.0.0.1]) id h6NJmQ49061441; Wed, 23 Jul 2003 15:48:26 -0400 (EDT) (envelope-from mtm@identd.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h6NJmQFd061440; Wed, 23 Jul 2003 15:48:26 -0400 (EDT) (envelope-from mtm@identd.net) X-Authentication-Warning: kokeb.ambesa.net: mtm set sender to mtm@identd.net using -f Date: Wed, 23 Jul 2003 15:48:26 -0400 From: Mike Makonnen To: John Baldwin Message-ID: <20030723194825.GA60545@kokeb.ambesa.net> References: <20030723043410.GA45652@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: Steve Kargl cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 19:48:29 -0000 On Wed, Jul 23, 2003 at 01:56:49PM -0400, John Baldwin wrote: > > > If you prefer to be sitting at a machine's single user prompt > one day, going "dang, if only rescue had I wouldn't be > totally screwed, and gee, it only cost 5k in disk space as well" > rather than resurrecting a dead machine during that time, then > I find that rather odd. Didn't the original rescue list come > from NetBSD in the first place where it has already gone through > one round of revisions? Or do you all just think that NetBSD's > rescue is poorly designed and bloated so you need to one-up them > for some reason? Maybe NetBSD has ipfw in their rescue because, > gee, they've gotten a bug report on it? I wouldn't be so quick > to discount the experience put into software that we nab from > other places. Actually, now that you mentioned it I took a look at their /rescue and it looks like they don't have any of the ipfilter tools in there. I don't think ipfw was port to NetBSD. So, it looks like they don't think firewalls are necessary in /rescue, either. >I also think that there should be some actual size > numbers of what we gain by trimming /rescue should be done prior > to commit. It can only help to have added functionality for some > corner case if it only adds a couple of kb in size. My only real objection to this issue was that those who wanted to keep ipfw didn't give any reason other than "it might be useful." If so, then _everything_ in /bin, /sbin/, and some in /usr/sbin and /usr/bin fall under this category. This issue is not worth all this argument, so I am simply withdrawing from this discussion. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon! From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 15:03:26 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 830B437B401 for ; Wed, 23 Jul 2003 15:03:26 -0700 (PDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 465A243F3F for ; Wed, 23 Jul 2003 15:03:25 -0700 (PDT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 23 Jul 2003 23:01:32 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 19fRdv-0006Yr-00; Wed, 23 Jul 2003 22:59:27 +0100 Date: Wed, 23 Jul 2003 22:59:27 +0100 (BST) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Alexey Neyman In-Reply-To: <200307231042.29371.alex.neyman@auriga.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jan Grant cc: freebsd-arch Subject: Re: Things to remove from /rescue 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: Wed, 23 Jul 2003 22:03:26 -0000 On Wed, 23 Jul 2003, Alexey Neyman wrote: > Hi, there! > > On Tuesday 22 July 2003 19:30, Sheldon Hearn wrote: > > I don't see this as an unreasonable requirement, and I can't see what > > great cost it incurs that would motivate us to remove support for it. > > Can't all this be done in a "user needs it, user adds it" fashion? E.g., to > add /etc/rescue.mk that will be .include'd in src/rescue/rescue/Makefile, > adding the required binaries to the CRUNCH_PROGS_bin, CRUNCH_PROG_sbin, > CRUNCH_LIBS lists? > > E.g: > --- /etc/rescue.mk --- > CRUNCH_PROGS_sbin += chown > > This will allow the "base" list to be trimmed to some minimalist level, and > will still allow the users to add whatever they [think they] need to restore > their system. What a fantastic suggestion. This really has merit. What's that slogan? "Mechanism, not policy"? The discussion thus far shines new light on the wisdom of such a position. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ I am now available for general use under a modified BSD licence. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 16:03:19 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 04F5F37B401; Wed, 23 Jul 2003 16:03:19 -0700 (PDT) Received: from area51.slashnet.org (area51.slashnet.org [209.150.101.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8139443FB1; Wed, 23 Jul 2003 16:03:18 -0700 (PDT) (envelope-from smkelly@FreeBSD.org) Received: from edgemaster.zombie.org (ip68-13-71-251.om.om.cox.net [68.13.71.251]) by area51.slashnet.org (Postfix) with ESMTP id 57E4E49F33; Wed, 23 Jul 2003 19:03:15 -0400 (EDT) Received: by edgemaster.zombie.org (Postfix, from userid 1001) id 7093239839; Wed, 23 Jul 2003 18:03:16 -0500 (CDT) Date: Wed, 23 Jul 2003 18:03:15 -0500 From: Sean Kelly To: arch@FreeBSD.org Message-ID: <20030723230315.GA12251@edgemaster.zombie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i cc: current@FreeBSD.org Subject: Remove "options HW_WDOG"? 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: Wed, 23 Jul 2003 23:03:19 -0000 While working on my software watchdog, it has come to my attention that the "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually use this code, or can I purge it in favor of the software watchdog? /usr/src/sys$ find . -type f |xargs grep HW_WDOG ./conf/NOTES:options HW_WDOG ./conf/options:HW_WDOG ./kern/kern_shutdown.c:#ifdef HW_WDOG ./kern/kern_shutdown.c:#endif /* HW_WDOG */ All the bit in kern/kern_shutdown.c does is: watchdog_tickle_fn wdog_tickler = NULL; And I can't find that being used anywhere. -- Sean Kelly | PGP KeyID: D2E5E296 smkelly@FreeBSD.org | http://www.sean-kelly.org/ From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 17:38:30 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 E766F37B401; Wed, 23 Jul 2003 17:38:29 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61B3043FB1; Wed, 23 Jul 2003 17:38:29 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc12) with ESMTP id <2003072400382801400amrqte>; Thu, 24 Jul 2003 00:38:28 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA62434; Wed, 23 Jul 2003 17:38:28 -0700 (PDT) Date: Wed, 23 Jul 2003 17:38:26 -0700 (PDT) From: Julian Elischer To: Sean Kelly In-Reply-To: <20030723230315.GA12251@edgemaster.zombie.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Remove "options HW_WDOG"? 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: Thu, 24 Jul 2003 00:38:30 -0000 this code WAS used in the interjet. We had modules that linked in and just needed somewhere to hook into.. the hardware watchdog was held off by our software, but we needed to add code to the core-dump routines to routinely call the watchdog hold-off or we could never get a coredump because the watchdog would always go off before the dump was completed. I doubt it is used by anyone any more but It's good that you asked.. I did notice some people were working on the watchdog support for the chipsets that have a watchdog in them so I guess they wil have all their own entrypoints. Julian On Wed, 23 Jul 2003, Sean Kelly wrote: > While working on my software watchdog, it has come to my attention that the > "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually > use this code, or can I purge it in favor of the software watchdog? > > /usr/src/sys$ find . -type f |xargs grep HW_WDOG > ./conf/NOTES:options HW_WDOG > ./conf/options:HW_WDOG > ./kern/kern_shutdown.c:#ifdef HW_WDOG > ./kern/kern_shutdown.c:#endif /* HW_WDOG */ > > All the bit in kern/kern_shutdown.c does is: > > watchdog_tickle_fn wdog_tickler = NULL; > > And I can't find that being used anywhere. > > -- > Sean Kelly | PGP KeyID: D2E5E296 > smkelly@FreeBSD.org | http://www.sean-kelly.org/ > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 22:57:23 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 0A6A537B401; Wed, 23 Jul 2003 22:57:23 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E2D143F75; Wed, 23 Jul 2003 22:57:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id PAA11086; Thu, 24 Jul 2003 15:57:19 +1000 Date: Thu, 24 Jul 2003 15:57:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Sean Kelly In-Reply-To: <20030723230315.GA12251@edgemaster.zombie.org> Message-ID: <20030724155335.Q2922@gamplex.bde.org> References: <20030723230315.GA12251@edgemaster.zombie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: Remove "options HW_WDOG"? 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: Thu, 24 Jul 2003 05:57:23 -0000 On Wed, 23 Jul 2003, Sean Kelly wrote: > While working on my software watchdog, it has come to my attention that the > "options HW_WDOG" in FreeBSD does absolutely nothing. does anybody actually > use this code, or can I purge it in favor of the software watchdog? > > /usr/src/sys$ find . -type f |xargs grep HW_WDOG > ./conf/NOTES:options HW_WDOG > ./conf/options:HW_WDOG > ./kern/kern_shutdown.c:#ifdef HW_WDOG > ./kern/kern_shutdown.c:#endif /* HW_WDOG */ > > All the bit in kern/kern_shutdown.c does is: > > watchdog_tickle_fn wdog_tickler = NULL; > > And I can't find that being used anywhere. watchdog_tickle_fn wdog_tickler is only used in the wd driver, which is still undead in RELENG_4. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jul 24 11:59:36 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 9721C37B401 for ; Thu, 24 Jul 2003 11:59:36 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE9DF43FB1 for ; Thu, 24 Jul 2003 11:59:34 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h6OIxYju085776; Thu, 24 Jul 2003 11:59:34 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h6OIxXw8085775; Thu, 24 Jul 2003 11:59:33 -0700 (PDT) Date: Thu, 24 Jul 2003 11:59:33 -0700 From: "David O'Brien" To: Mike Makonnen Message-ID: <20030724185933.GC85582@dragon.nuxi.com> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723002531.GA44452@kokeb.ambesa.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@FreeBSD.org Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 18:59:36 -0000 On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: > > b) want to maintain network security while accessing that resource. > > What security? There are no network services running in single-user, > so what is there to secure? I'm glad I'm not the only one seeing things this way. > I won't complain if it's kept, but I would prefer just the bare minimum > be kept in /rescue. Once you go beyond that and into "well s/he might > need..." territory then we might as well throw in everything in the > base system. IMO, /rescue should be the absolute essentials _only_. > Instead of theorizing reasons why someone might need ipfw and friends, > why don't we wait until we get a bug report about a specific situation > in which it was needed before we put it back in. Thank you for expressing this so well. I do think we should wait for PR's telling real experiences rather than theorizing so much in the "what if"'s. > Also, while you're at it, David, I think you can get rid of rcorder > as well. I don't know why one would need it to fix a hosed root, > and besides it's staticaly linked to begin with. Will do! :-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Jul 24 12:01:49 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 6A97A37B401 for ; Thu, 24 Jul 2003 12:01:49 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B428343F3F for ; Thu, 24 Jul 2003 12:01:48 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h6OJ1lju085853; Thu, 24 Jul 2003 12:01:47 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h6OJ1lvO085852; Thu, 24 Jul 2003 12:01:47 -0700 (PDT) Date: Thu, 24 Jul 2003 12:01:47 -0700 From: "David O'Brien" To: Steve Kargl Message-ID: <20030724190147.GD85582@dragon.nuxi.com> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> <20030723035006.GA45410@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723035006.GA45410@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2003 19:01:49 -0000 On Tue, Jul 22, 2003 at 08:50:06PM -0700, Steve Kargl wrote: > Don't you need a network connection to use /rescue/rrestore to access > the dump of / on a tape drive in a remote system? rrestore & rcp are clients in this usage -- what is the firewall protecting when using them in single user? > One may want a secure connection to that remote system. IPFW doesnot offer security connections -- that is what SSH does. So I don't see the need of IPFW in this example. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Jul 24 12:06:52 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 ECEB537B401 for ; Thu, 24 Jul 2003 12:06:52 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66D9F43F75 for ; Thu, 24 Jul 2003 12:06:52 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h6OJ6qkN034118; Thu, 24 Jul 2003 12:06:52 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h6OJ6qBc034117; Thu, 24 Jul 2003 12:06:52 -0700 (PDT) (envelope-from rizzo) Date: Thu, 24 Jul 2003 12:06:52 -0700 From: Luigi Rizzo To: freebsd-arch@freebsd.org Message-ID: <20030724120652.B33961@xorpc.icir.org> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> <20030724185933.GC85582@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030724185933.GC85582@dragon.nuxi.com>; from obrien@freebsd.org on Thu, Jul 24, 2003 at 11:59:33AM -0700 Subject: Re: Things to remove from /rescue 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: Thu, 24 Jul 2003 19:06:53 -0000 On Thu, Jul 24, 2003 at 11:59:33AM -0700, David O'Brien wrote: > On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: ... > > base system. IMO, /rescue should be the absolute essentials _only_. > > Instead of theorizing reasons why someone might need ipfw and friends, > > why don't we wait until we get a bug report about a specific situation > > in which it was needed before we put it back in. > > Thank you for expressing this so well. I do think we should wait for > PR's telling real experiences rather than theorizing so much in the "what > if"'s. then just nuke everything from /rescue and waif for PR's... :) cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Jul 25 13:58:09 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 3B23837B405 for ; Fri, 25 Jul 2003 13:58:09 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5783A43FA3 for ; Fri, 25 Jul 2003 13:58:08 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h6PKw7ju039399; Fri, 25 Jul 2003 13:58:07 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h6PKw7f5039398; Fri, 25 Jul 2003 13:58:07 -0700 (PDT) Date: Fri, 25 Jul 2003 13:58:06 -0700 From: "David O'Brien" To: Luigi Rizzo Message-ID: <20030725205806.GB39268@dragon.nuxi.com> References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> <20030724185933.GC85582@dragon.nuxi.com> <20030724120652.B33961@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030724120652.B33961@xorpc.icir.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2003 20:58:09 -0000 On Thu, Jul 24, 2003 at 12:06:52PM -0700, Luigi Rizzo wrote: > On Thu, Jul 24, 2003 at 11:59:33AM -0700, David O'Brien wrote: > > On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: > ... > > > base system. IMO, /rescue should be the absolute essentials _only_. > > > Instead of theorizing reasons why someone might need ipfw and friends, > > > why don't we wait until we get a bug report about a specific situation > > > in which it was needed before we put it back in. > > > > Thank you for expressing this so well. I do think we should wait for > > PR's telling real experiences rather than theorizing so much in the "what > > if"'s. > > then just nuke everything from /rescue and waif for PR's... :) {\sarcasm Or just go back to /[s]bin being statically linked and create /[s]bin.dynamic and those that want that can put it first in their path. } From owner-freebsd-arch@FreeBSD.ORG Fri Jul 25 16:08:42 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 05EF237B401 for ; Fri, 25 Jul 2003 16:08:42 -0700 (PDT) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0E8343F93 for ; Fri, 25 Jul 2003 16:08:40 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch01.lj.gnf.org [172.25.10.19]) by ns1.gnf.org (8.12.8p1/8.12.8) with ESMTP id h6PN8ctF060659 for ; Fri, 25 Jul 2003 16:08:38 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Jul 2003 16:08:40 -0700 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h6PN8ei2074915 for ; Fri, 25 Jul 2003 16:08:40 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h6PN8eOs074914 for arch@FreeBSD.org; Fri, 25 Jul 2003 16:08:40 -0700 (PDT) Date: Fri, 25 Jul 2003 16:08:39 -0700 From: Gordon Tetlow To: arch@FreeBSD.org Message-ID: <20030725230839.GR12996@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o+XGOUgEmmuBaVbd" Content-Disposition: inline User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 25 Jul 2003 23:08:40.0448 (UTC) FILETIME=[AFB56800:01C35301] Subject: Patch to crunchgen to fix errors using make -P 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: Fri, 25 Jul 2003 23:08:42 -0000 --o+XGOUgEmmuBaVbd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bill Fenner reported a problem with crunchgen relating to the use of make -j # -P when building rescue. By running make -j # -P in src/rescue/rescue you get the following type of error: crunchgen: make error: Remaking `crunchgen_objs' =09 crunchgen: make error: Results of making crunchgen_objs: =09 crunchgen: make error:=20 =09 crunchgen: make error: Remaking `loop' =09 crunchgen: make error: Results of making loop: =09 crunchgen: make error:=20 This stems from the problem that crunchgen itself invokes make(1) to do some work and the extra output generated by the -P flag confuses crunchgen. I have a quick patch that I'd like to commit, but I was wondering if anyone had any objections or reason to keep the MAKEFLAGS environment variable. -gordon --- //depot/vendor/freebsd/src/usr.sbin/crunch/crunchgen/crunchgen.c 200= 3/04/22 21:37:08 +++ //depot/user/gordon/dynamic/src/usr.sbin/crunch/crunchgen/crunchgen.c20= 03/07/25 16:02:35 @@ -700,6 +700,12 @@ =20 fclose(f); =20 + /* + * We need to whack the MAKEFLAGs env variable to protect crunchgen + * from dangerous flags like -P that influence the resulting output. + */ + unsetenv("MAKEFLAGS"); + snprintf(line, MAXLINELEN, "cd %s && make -f %s crunchgen_objs 2>&1= ", p->srcdir, tempfname); if ((f =3D popen(line, "r")) =3D=3D NULL) { --o+XGOUgEmmuBaVbd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/Ibh3Ru2t9DV9ZfsRAuI1AKC54oiWeKjIzqVRTiTDhTOFaummcQCgi8rg HrA9IKkKlrwktHvYHm371xY= =67k0 -----END PGP SIGNATURE----- --o+XGOUgEmmuBaVbd-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 25 16:50:55 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 C42E137B401 for ; Fri, 25 Jul 2003 16:50:55 -0700 (PDT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25B9743F85 for ; Fri, 25 Jul 2003 16:50:55 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h6PNorkM020027; Fri, 25 Jul 2003 19:50:53 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030725230839.GR12996@roark.gnf.org> References: <20030725230839.GR12996@roark.gnf.org> Date: Fri, 25 Jul 2003 19:50:52 -0400 To: Gordon Tetlow , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Patch to crunchgen to fix errors using make -P 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: Fri, 25 Jul 2003 23:50:56 -0000 At 4:08 PM -0700 7/25/03, Gordon Tetlow wrote: >Bill Fenner reported a problem with crunchgen relating to >the use of make -j # -P when building rescue. This is the same problem I ran into when trying to use any kind of debug-flags with 'make buildworld', so it would be good to see some solution committed for it. >I have a quick patch that I'd like to commit, but I was >wondering if anyone had any objections or reason to keep >the MAKEFLAGS environment variable. If it is a problem to NOT pass them through, then I guess crunchgen could have an option so it would send them through. That's probably overkill, though. I'd vote for putting in your patch as is, and implement the overkill if we find some kind of need for it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Jul 25 17:11:05 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 0F62237B401 for ; Fri, 25 Jul 2003 17:11:05 -0700 (PDT) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B6ED43F3F for ; Fri, 25 Jul 2003 17:11:04 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.9/8.12.9) with ESMTP id h6Q0B29t013342; Fri, 25 Jul 2003 20:11:02 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030725230839.GR12996@roark.gnf.org> References: <20030725230839.GR12996@roark.gnf.org> Date: Fri, 25 Jul 2003 20:11:01 -0400 To: Gordon Tetlow , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Patch to crunchgen to fix errors using make -P 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: Sat, 26 Jul 2003 00:11:05 -0000 At 4:08 PM -0700 7/25/03, Gordon Tetlow wrote: >I have a quick patch that I'd like to commit, but I was >wondering if anyone had any objections or reason to keep >the MAKEFLAGS environment variable. Following up on what you figured out, I realized that we could also fix this by changing the line in /usr/src/rescue/rescue/Makefile so it's: MAKEFLAGS= MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m ... A quick test showed that this allowed me to add all the debug flags I wanted to add, without having to change crunchgen. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Jul 25 21:03:25 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 288AC37B427; Fri, 25 Jul 2003 21:03:23 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01B9C43FA3; Fri, 25 Jul 2003 21:03:22 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h6Q43BFL079817; Fri, 25 Jul 2003 22:03:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 25 Jul 2003 22:02:59 -0600 (MDT) Message-Id: <20030725.220259.54450614.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20030725205806.GB39268@dragon.nuxi.com> References: <20030724185933.GC85582@dragon.nuxi.com> <20030724120652.B33961@xorpc.icir.org> <20030725205806.GB39268@dragon.nuxi.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue 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: Sat, 26 Jul 2003 04:03:25 -0000 In message: <20030725205806.GB39268@dragon.nuxi.com> "David O'Brien" writes: : On Thu, Jul 24, 2003 at 12:06:52PM -0700, Luigi Rizzo wrote: : > On Thu, Jul 24, 2003 at 11:59:33AM -0700, David O'Brien wrote: : > > On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: : > ... : > > > base system. IMO, /rescue should be the absolute essentials _only_. : > > > Instead of theorizing reasons why someone might need ipfw and friends, : > > > why don't we wait until we get a bug report about a specific situation : > > > in which it was needed before we put it back in. : > > : > > Thank you for expressing this so well. I do think we should wait for : > > PR's telling real experiences rather than theorizing so much in the "what : > > if"'s. : > : > then just nuke everything from /rescue and waif for PR's... :) : : {\sarcasm : Or just go back to /[s]bin being statically linked and create : /[s]bin.dynamic and those that want that can put it first in their : path. : } cruncgen'd binary uses a lot less space than a static directory full of copies of libc. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Jul 26 06:08:51 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 86EC537B401 for ; Sat, 26 Jul 2003 06:08:51 -0700 (PDT) Received: from phuket.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDF2443F3F for ; Sat, 26 Jul 2003 06:08:49 -0700 (PDT) (envelope-from paul@phuket.psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.12.6p2/8.12.6) with ESMTP id h6QD8mB4042772 for ; Sat, 26 Jul 2003 15:08:48 +0200 (CEST) (envelope-from paul@phuket.psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.12.6p2/8.12.6/Submit) id h6QD8mME042771 for freebsd-arch@freebsd.org; Sat, 26 Jul 2003 15:08:48 +0200 (CEST) Date: Sat, 26 Jul 2003 15:08:48 +0200 From: Paul Schenkeveld To: freebsd-arch@freebsd.org Message-ID: <20030726130847.GA42503@psconsult.nl> Mail-Followup-To: freebsd-arch@freebsd.org References: <20030719171138.GA86442@dragon.nuxi.com> <20030721202314.GC21068@dragon.nuxi.com> <20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <20030723002531.GA44452@kokeb.ambesa.net> <20030724185933.GC85582@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030724185933.GC85582@dragon.nuxi.com> User-Agent: Mutt/1.5.4i Subject: Re: Things to remove from /rescue 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: Sat, 26 Jul 2003 13:08:51 -0000 On Thu, Jul 24, 2003 at 11:59:33AM -0700, David O'Brien wrote: > On Tue, Jul 22, 2003 at 08:25:32PM -0400, Mike Makonnen wrote: > > > b) want to maintain network security while accessing that resource. > > > > What security? There are no network services running in single-user, > > so what is there to secure? > > I'm glad I'm not the only one seeing things this way. I'm not that familiar with -current (still running -stable) but will using /etc/rc.d to initialize your network also enable ipforwarding? In other words, although I'm trying to rescue my firewall, will it act as an open router if /etc/rc.d/* enable forwarding and I can only use a sysctl to open up ipfw so I can reach a remote tape drive? > > I won't complain if it's kept, but I would prefer just the bare minimum > > be kept in /rescue. Once you go beyond that and into "well s/he might > > need..." territory then we might as well throw in everything in the > > base system. IMO, /rescue should be the absolute essentials _only_. > > Instead of theorizing reasons why someone might need ipfw and friends, > > why don't we wait until we get a bug report about a specific situation > > in which it was needed before we put it back in. > > Thank you for expressing this so well. I do think we should wait for > PR's telling real experiences rather than theorizing so much in the "what > if"'s. > > > Also, while you're at it, David, I think you can get rid of rcorder > > as well. I don't know why one would need it to fix a hosed root, > > and besides it's staticaly linked to begin with. > > Will do! :-) Paul Schenkeveld