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_at_wifibsd.org diz_at_linuxpowered.com http://www.wifibsd.orgReceived on Mon Apr 12 2004 - 12:48:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:50 UTC