From owner-freebsd-current@FreeBSD.ORG Mon Apr 12 14:48:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7C116A4DD for ; Mon, 12 Apr 2004 14:48:53 -0700 (PDT) Received: from avalon.linuxpowered.com (avalon.linuxpowered.com [64.246.60.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05CD843D49 for ; Mon, 12 Apr 2004 14:48:53 -0700 (PDT) (envelope-from diz@linuxpowered.com) Received: from linuxpowered.com (txirvcom-itnfw01.verizon.com [::ffff:192.76.54.20]) (AUTH: CRAM-MD5 diz@linuxpowered.com) by avalon.linuxpowered.com with esmtp; Mon, 12 Apr 2004 16:56:36 -0500 Message-ID: <407B0EA5.7040800@linuxpowered.com> Date: Mon, 12 Apr 2004 16:48:21 -0500 From: masta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Peters References: <200403112047.43739.wes@softweyr.com> In-Reply-To: <200403112047.43739.wes@softweyr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: /etc/rc.d/ramdisk script for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 21:48:53 -0000 Wes Peters wrote: >A question came up on the mimedefang-users mailing list today. One >user who has recently converted from 4.8 to 5.2.1 was lamenting the >fact there is no way to control ownership and permission of memory >disks in 5.x. The MIMEdefang spool area, often placed on a ramdisk >for speed, needs to be owned by the MIMEdefang user and group. > >I poked around at mdmfs, aka mount_mfs, and thought there should be >a more 5.x-ish way to create ramdisks early enough in the boot process >to just put them in /etc/fstab directly. Here's what I came up with. > > I like the notion of having rc.conf nobs to do this stuff with, but we can already use /etc/fstab to configure a ramdisk as such: md /tmp mfs rw,-s3m 0 0 md /var mfs rw,-s7m 0 0 That is how I engineered wifibsd prior to the changes Brooks did to the diskless script of Matt's. It would seem to me that we could have the ownership options next to the "rw,-s7m" options fields which already exists. Something like "rw,-s7m,-Owes:staff", or similare. Since mount_md, or mdmfs, or whatever mount uses to do the task, could be changed to facilitate that one needful thing or using chown/chgrp, right? >This is configured from /etc/rc.conf, as in: > >ramdisk_units="10 11 12" >ramdisk_10_config="-t swap -s 128m" >ramdisk_10_owner="wes:staff" >ramdisk_10_perms="1755" >ramdisk_11_config="-t malloc -s 32m" >ramdisk_11_newfs="-b 4096 -f 1024" > >This results in /dev/md10 (with ownership and permissions as specified) >and /dev/md11 (with default ownership and permissions, 4K/1K block/frag >size), but not a /dev/md12 as its type has not been specified. > >Here is the script: > >---- ramdisk > >#!/bin/sh - ># ># Copyright (c) 2004 The FreeBSD Project ># All rights reserved. ># ># Redistribution and use in source and binary forms, with or without ># modification, are permitted provided that the following conditions ># are met: ># 1. Redistributions of source code must retain the above copyright ># notice, this list of conditions and the following disclaimer. ># 2. Redistributions in binary form must reproduce the above copyright ># notice, this list of conditions and the following disclaimer in the ># documentation and/or other materials provided with the distribution. ># ># THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ># ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE ># IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ># ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE ># FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL ># DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS ># OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) ># HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT ># LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY ># OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF ># SUCH DAMAGE. ># ># $FreeBSD$ ># > ># PROVIDE: ramdisk ># REQUIRE: localswap ># BEFORE: mountcritlocal ># KEYWORD: FreeBSD > >. /etc/rc.subr > >name="ramdisk" >stop_cmd="ramdisk_stop" >start_cmd="ramdisk_start" > >ramdisk_start() >{ > for unit in $ramdisk_units > do > eval mdoptions=\$ramdisk_${unit}_config > if [ "$mdoptions" = "${mdoptions##-t}" ] > then > echo "Type not specified for md$unit" > continue > fi > eval fsoptions=\$ramdisk_${unit}_newfs > eval owner=\$ramdisk_${unit}_owner > eval perms=\$ramdisk_${unit}_perms > > echo Configuring ramdisk /dev/md$unit > > mdconfig -a $mdoptions -u $unit > newfs $fsoptions /dev/md$unit > [ "X$owner" != "X" ] && chown $owner /dev/md$unit > [ "X$perms" != "X" ] && chmod $perms /dev/md$unit > done >} > >ramdisk_stop() >{ > for unit in $ramdisk_units > do > if [ -c /dev/md$unit ] ; then > umount -f /dev/md$unit > /dev/null 2>&1 > mdconfig -d -u $unit > echo Recovered ramdisk /dev/md$unit > fi > done >} > >load_rc_config $name >run_rc_command "$1" > >---- ramdisk > > Brooks already has something like this in rc.subr, we could just alter that, right? I mean there is no need for duplication of the same task, right? Just need the chown parts. >Gordon Tetlow suggested creating a mount_md program instead, which >would probably be a hackup of mdmfs. To some extent, just linking >/sbin/mount_md to /sbin/mdmfs would allow all of the options in mdmfs >to be used in /etc/fstab. Does anyone have strong preferences for >one approach vs. the other? > > I belive both methods have their place, and they do not have to be mutually exlusive. -Jon Disnard (aka masta) masta@wifibsd.org diz@linuxpowered.com http://www.wifibsd.org