/etc/rc.d/ramdisk script for review
w...@softweyr.com
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.
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
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?
--
Where am I, and what am I doing in this handbasket?
Wes Peters w...@softweyr.com
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
d...@linuxpowered.com
>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?
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)
ma...@wifibsd.org
d...@linuxpowered.com
http://www.wifibsd.org
w...@softweyr.com
> 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?
No, because it can't change the ownership of the mount point after the
mount, which is the point of the whole thing. If you recall from the
original message, this was to create a temporary space for MIMEdefang,
which runs as an untrusted user and so needs the ownership set
appropriately. We use the same mechanism for virus scanning as well.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters w...@softweyr.com