devd based AUTOMOUNTER

Sun Feb 26 18:48:48 UTC 2012

On Sun, Feb 26, 2012 at 2:18 AM, Ian Smith <smithi at nimnet.asn.au> wrote:
> Ccs mightily trimmed to avoid not-subscribed bounces; readd as desired:
>
> On Mon, 20 Feb 2012 09:43:59 +0100, vermaden wrote:
>  > To: freebsd-hackers at freebsd.org
>  > Cc: matt <sendtomatt at gmail.com>, gleb.kurtsou at gmail.com,
>  >     freebsd-stable at freebsd.org, uffe at uffe.org, joe.culler at gmail.com,
>  >     Hans Petter Selasky <hselasky at c2i.net>, freebsd-current at freebsd.org,
>  >     lars.engels at 0x20.net
>  >
>  > Hi,
>  >
>  > new version with new features (and BUGs ;p)
> [..]
>
> Well, I was busy composing this reply a few days ago when this system
> was taken out by a very near lightning strike .. losing the ADSL modem
> (blown into 4 pieces scattered about the room :), 2 scorched switches,
> the old xe pccard interface feeding the ADSL (its dongle also blown into
> several pieces), and a good deal of travelling - I was 80km remote at
> the time - but very fortunately not the server box itself .. close call!

Wow! Glad you were 80 km away. At least you were not blown into 4 pieces!

>  > Added 'noatime' as a default mount option when possible.
>
> Good idea for many use cases, but could that be optional?

Please make this optional. I have one volume where I depend on atime
for regular operations.  Of course, I can deal with this myself, but
atime is default for a reason, even though its overhead and frequent
lack of use makes me question that, as well.

> [..]
>  > Added config file to be used from /usr/local/etc/automount.conf file, possible options are (these are defaults):
>  >   MNTPREFIX="/media"
>  >   LOG="/var/log/automount.log"
>  >   STATE="/var/run/automount.state"
>  >   ENCODING="en_US.ISO8859-1"
>  >   CODEPAGE="cp437"
>  >   DATEFMT="%Y-%m-%d %H:%M:%S"
>  >   USERUMOUNT="NO"
>  >
>  > Mine config currently has only these:
>  >   ENCODING="pl_PL.ISO8859-2"
>  >   CODEPAGE="cp852"
>  >   USERUMOUNT="YES"
>  >
>  > The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/umount',
>  > so You can click the ^ button on the devices list in NAUTILUS.
>
> Someone might explain why I needn't feel a bit uncomfortable about that
> chmod, even though it is optional, and even though I've been guilty
> myself of a 'chown root:nobody /sbin/tc' on a linux firewall box ..

policykit does the same sort of thing in gnome, but it is VERY fine
grained. It can limit unmounting to certain devices while this give
any user the ability to do `umount \usr'. Rather frightening as a
default. Of course, most desktop systems are single user. And it is
only efective if the system has USERMOUNT enabled.
>
>  > These newly mounted devices appear on NAUTILUS sidebar (only with /media prefix).
>
> I wonder how it goes with KDE4? (still 3.5 here, which wouldn't count)
>
> [..]
>  > /usr/local/sbin/automount.sh
>  > -------------------------------------------------------------------------------
> [..]
>  > [ "${USERUMOUNT}" = "YES" ] && chmod u+s /sbin/umount # /* WHEEL group member */
>  >
>  > __create_mount_point() { # /* 1=DEV */
>  >   MNT="${MNTPREFIX}/$( basename ${1} )"
>  >   mkdir -p ${MNT}
>  >   chown 1000 ${MNT}
>  > }
>
> Er, who's user 1000 ?  Another config item perhaps?  Or should that be
> the particular user currently invoking the script via devd (if that can
> be determined?)?  Also, are you using sysctl vfs.usermount=1 ?
>
>  > case ${2} in
>  >   (attach)
>  >     for I in /dev/${1}*
>  >     do
> [..]
>  >         (*Unix\ Fast\ File*)
>  >           __create_mount_point ${I}
>  >           fsck_ufs -y ${I}
>
> Mmm, fsck on every attachment?  Maybe running fsck should be optional?
> We might be attaching, perhaps, a 2TB backup HD? ..

Ouch! I agree. Why not just fsck_ufs -p. (I realize this is done to
fix systems that were unplugged rather than umounted, but it's a
pretty expensive operation when not needed.

>
>  >           __check_already_mounted ${MNT}
>  >           mount -o noatime ${I} ${MNT}
>
> Again, I'd rather see that optional in an intended system tool, although
> it's an option I'd tend to use myself.
>
>  >           __log "${I}:mount (ufs)"
>  >           ;;
> [..]
>  >   (detach)
>  >     MOUNT=$( mount )
>  >     __state_lock
>  >     grep ${1} ${STATE} \
>  >       | while read DEV PROVIDER MNT
>  >         do
>  >           TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print $3}' )
>  >           [ -z ${TARGET} ] && {
>  >             __state_remove ${MNT} ${STATE} ${LINE}
>  >             continue
>  >           }
>  >           umount -f ${TARGET} &
>  >           unset TARGET
>  >           __state_remove ${MNT} ${STATE} ${LINE}
>  >           __log "${DEV}:umount"
>  >         done
>  >     __state_unlock
>  >     __log "/dev/${1}:detach"
>  >     find ${MNTPREFIX} -type d -empty -delete
>
> I don't see the need to remove all empty subdirs of, say, /media - this
> tool may not be the only thing wanting to manage that space?  Removing
> directories that were added by this tool itself makes sense of course.

This is an interesting one. Gnome and hald have a problem here that
have caused me to add
sudo /bin/rmdir /media/*
to.xinitrc to work around. It's just too easy for 'junk' directories
to live on when the system does not exit everything cleanly and, while
hald tries to keep track, it is very hard to do in the real world. I
suspect it is really needed. And what else is creating directories in
/media?
--
R. Kevin Oberman, Network Engineer
E-mail: kob6558 at gmail.com