volunteers for beta-testing a hot-plug mounter

Would anyone be so nice to test my little helper program?
It's only use is to automatically mount a filesystem that becomes available on line (hot-plugged) on a configurable location.
I did not like the other automounters out there so I whas inspired by the one Slax uses.
It took three rewrites :-) to be more satisfied... Now I need opinions and testing to get the best defaults and recommendations.
[edit]
Seems that I forgot the URl at the end -> If You're fast enough You'll have to repeat.;-)
http://sourceforge.net/project/showf...roup_id=174404
[/edit]

Please don't just flame on me :-D. Be so kind and download and examine and hopefully test this if you are iterested.
Kind regards anyhow.
BTW
Shall the OS, sysadmin or user decide where to mount something on linux?

A Small-time howto:
the package is in slackwares .tgz format:
/etc - goes to /etc
/sbin - goes to /sbin
/install - has information for pkgtool goes nowhere

/etc/rc.d/rc.local - can be appended to existing rc.local it launches the tool

/etc/rc.d/rc.hotmnt - if set executable enables automatic mount

/etc/fstab.conf - the configuration file, read below

/sbin/hotmnt - the bash script that does the 'magic'

usage:
# hotmnt -d
seeks for unmounted filesystems/volumes not already in fstab, decides acording to /etc/fstab.conf what mountpoints to make and where, what actions to take or not and finaly to mount them or not to. The the tool seeks for orphans in fstab and if any, removes them. The -d causes a lot of progres to be revealed to the carying user (root).

/etc/fstab.conf:

# the wildcards for mountpoints:
#
# %l=label ; the fs-label if any
# %u=uid ; of the volume
# %d=device ; node-name (eg. sda1 or hda5)
# %s=size(k, M, G) ; size of the filesystem
# %i=config number of matching device
# %m=mountpoint ; the name of the mount-dir (see examples)
# %n=ocurrence nr. or mached fstab entry

#
# total number of configured devices.
#

_HM_TOT=4

#
# We use this to speed things up. It sufices just to decrease this number
# in order to blank-out remainig device-matches, instead of commenting
# them out. Do take care no to break this ;-)
#
# !!! NOTE: Do update this when done adding new devices !!!
#

# The empty skeleton (indexed as set [0]) 
# use it as an empty template (eg copy + insert it at the end)
# then just renumber the set, sets must not be ordered
# !!! NOTE: set [0] is ignored by HOTMouNT for this purpose !!!


##########################################
#

_HM_PRTPTN[0]="sd[a-z][1-9]|hd[a-z][1-9]|sd[a-z]$|cdrom[0-9]|dvd[0-9]"

    _HM_IGNORE[0]=true|false
    _HM_FSTYPE[0]="vfat|iso9660|ext2|ext3|reiserfs|ntfs"
    _HM_OPTS[0]="umask=0,rw,users,noatime"
    _HM_FSTAB[0]="ignore|update"
    _HM_MNTPNT[0]="{/mnt/%l_removable|/%d}"
    _HM_FSCK[0]="force|check|ignore"
    _HM_MOUNT[0]="true|false"

#
##########################################


_HM_PRTPTN[1]="sd[a-z][1-9]"
# matches all VFAT partitions on any scsi device

    _HM_IGNORE[1]=false
    _HM_FSTYPE[1]="ntfs"
    _HM_OPTS[1]="umask=0,rw,users"
    _HM_FSTAB[1]="update"
    _HM_MNTPNT[1]="/mnt/%l_removable"
    _HM_FSCK[1]="ignore"
    _HM_MOUNT[1]="true"

_HM_PRTPTN[2]="sd[a-z]$"
# matches all scsi (usb-flashdisks too) that
#   are VFAT formatted without a partition table

    _HM_IGNORE[2]=false
    _HM_FSTYPE[2]="vfat"
    _HM_OPTS[2]="umask=0,rw,users"
    _HM_FSTAB[2]="update"
    _HM_MNTPNT[2]="/mnt/%l_removable"
    _HM_FSCK[2]="ignore"
    _HM_MOUNT[2]="false"

_HM_PRTPTN[3]="sd[a-z][1-9]"
# matches all VFAT partitions on any scsi device

    _HM_IGNORE[3]=false
    _HM_FSTYPE[3]="vfat"
    _HM_OPTS[3]="umask=0,rw,users"
    _HM_FSTAB[3]="update"
    _HM_MNTPNT[3]="/mnt/%l_removable"
    _HM_FSCK[3]="ignore"
    _HM_MOUNT[3]="false"

_HM_PRTPTN[4]="hd[b-z][1-9]"
# matches (almost) any (IDE/ATA) hd with VFAT partitions

    _HM_IGNORE[4]=false
    _HM_FSTYPE[4]="vfat"
    _HM_OPTS[4]="umask=0,rw,users,noatime,iocharset=iso8859-2"
    _HM_FSTAB[4]="update"
    _HM_MNTPNT[4]="/mnt/%d_%l"
    _HM_FSCK[4]="ignore"
    _HM_MOUNT[4]="false"

#
# NOTE: update the _HM_TOT above ;-)
#

the set-options:
_HM_PRTPTN[0]="sd[a-z][1-9]|hd[a-z][1-9]|sd[a-z]$|cdrom[0-9]|dvd[0-9]"
the partition regexp if a matching partition is found, the set is further examined. No match - no search.

_HM_IGNORE[0]=true|false
is this set ignored by the tool (to quickly switch off or on a set)

_HM_FSTYPE[0]="vfat|iso9660|ext2|ext3|reiserfs|ntfs"
the expected fs-type -one per entry- so the admin can easy configure specific options regarding fs type (locale, quota, commit etc.)

_HM_OPTS[0]="umask=0,rw,users,noatime"
options for the filesystem that go to fstab

_HM_FSTAB[0]="ignore|update"
does fstab get updated? maybe we want only to mount and leave fstab untouched? or only to update fstab and not to mount?

_HM_MNTPNT[0]="{/mnt/%l_removable|/%d}"
the mount point: if we update fstab, the line gets marked for later removal. If we only mount to a mountpoint it gets later removed...
_HM_FSCK[0]="force|check|ignore"
do we fsck the volume and when...
_HM_MOUNT[0]="true|false"
does the volume get mounted or just ready.

Some critique if I may: it is bad style to run a program that is in a endless loop and polls every n seconds. hotplug/udev hooks were made exactly for tasks that should occur when devices are plugged and unplugged. Hotplug hooks are documented here:

http://www.slackbasics.org/html/init...n-init-hotplug

Though it does not describe hooks for udev, though the idea is more or less the same.

Originally Posted by danieldk Some critique if I may: it is bad style to run a program that is in a endless loop and polls every n seconds. hotplug/udev hooks were made exactly for tasks that should occur when devices are plugged and unplugged. Hotplug hooks are documented here: http://www.slackbasics.org/html/init...n-init-hotplug Though it does not describe hooks for udev, though the idea is more or less the same.

Yes indeed
I tried to make the actual script - the manager itself - to be able to react to one-shot call. I aimed to the udev hooks but didn't know how to hook-in, so the script is periodically called from /etv/rc.d/rc.hotmnt but the actual work is allways done one-shot in the /sbin/hotmnt.
The script itself can be called from the command-line:
# hotmnt -d
instead of having it called from a loop...
And of course, a nice howto for hooking to udev would be _imediately_ tested and if clean-coded and reliable included in the next release

Now am off to read Your URL...
Thanks.

Well, the good news is that this has actually been done already:
http://usbmount.alioth.debian.org/

Originally Posted by danieldk Well, the good news is that this has actually been done already: http://usbmount.alioth.debian.org/

did dnld the package to study this nigh over...
But regarding debian I don't know their scripts seem a little cludgy to me: shall I e-mail you my acpi-handler.sh for my laptop so you could run a diff against the debian-ones and see for yourself?

Debian ain't just slacky enough sometimes...

Not that my script is realy clean, but if someone helped clean it up (and maybe translate it to C?)

I found what I needed,
Im up to new code...
udev is to be included in the next release,
I made a mistake above, the loop IS inside the /sbin/hotmnt script , and with udev-hook-in I'll try to get rid of it .
patches are welcome in form of (?)patches to my mail... or rigt to this thread.

A new code is in the early phase of alpha testing, it's ben tested on my laptop and behaves o.k.
the release will be 0.4.2 and will represent the first milestone.
This release is the last one supporting 2.4 series without udev.
the next release will be pure udev, rewriten to be clean and de-cludged again.
the release will be soon (few days from now) on sf.net

@danieldk:
the mentioned project is somewhat young and the code is a bit cludgy IMHO, so I took some of their idea but my rolemodel is the way slackware originaly handles acpi events (one central script, minimum outtside calls).
I would like to see all the action takes place in one shell script, without too much external calls, and preferably with only one config file.

I managed somehow to cut thru sf.net's release system and got the stable release available for download...8)

The release does it with udev now. in the next release I will address documentation for alternate device-links of udev (mounting per uuid, vendor, etc) and hooks to use udev's vendor and model tags in mountpoint-naming.

The main goal now (milestone #2) is to get stable behavior and to fixate the code and options in the manager script (sbin/hotmnt). This would be the rc1 and on.

Then (milestone #3) is to make sane defaults in /etc/fstab.conf that handle most (95%?) scenarios. From that point, only the config file should undergo further development.

And of course it must be able to point all new volumes to /mnt/hd (and eventually mount some of them if desired/ordered by config) in fstab if this is desired.

And didn't I mention? the script IS intended to do a mount WITHOUT updating fstab AT ALL. Please evaluate this if You are interested. One could for example point all hotplugged volumes to, say /mnt/hd/ and once a while a device get's plugged it would simply "over-mount" all existing ones on /mnt/hd

Feedback is welcome

Should there be a additional script to address the unmounting in the event of device removal?
A script that get's launched manually in advance, an depending of environment, put a curses or xmessage dialog on the screen allowing the user to select one or more devices pending for removal.

That script could get invoked automatically too to confirm umount -l after a device got removed forcibly (dirty).

Does ANYone want to test this script?
Has any one downloaded it and at least read it?
C'mon, do you really think newbies know how to mount manually?
The newbies (like we where back then) need this, and we can make this one good.

I downloaded and tried 0.4 and hacked on it some. It was mounting everything under the same mountpoint. Problem with variable expansion. I think I lost the changes though, accidentally.
Once I had it working I checked the resource usage and it wasn't much at all.
I think the constant polling is not too big a problem, though I hope there's a better way to do it than using sleep.
This was about when you released 0.4.2 -I was disappointed that you were going to udev. I'm a mostly-2.4-kernel guy still so I was more interested in usage with hotplug. While I hacking I got distracted with /proc/partitions not updating itself and how to best manage that. I've been playing with hotplug-ng and diethotplug also.
Does autofs not do what you want? What about kudzu?

I downloaded and tried 0.4 and hacked on it some. It was mounting everything under the same mountpoint. Problem with variable expansion. I think I lost the changes though, accidentally.

Thank You very much for your time.
If You could reproduce the problem or explain what did most confuse You (seems You looked at the fstab.conf, right?).
May be I missexplained something?
What are the names of Your volumes?

Once I had it working I checked the resource usage and it wasn't much at all. I think the constant polling is not too big a problem, though I hope there's a better way to do it than using sleep.

The most effort with 0.3.x release was to cut down the overhead in the loop to ~2-5% action and the rest - sleep. I now it's not elegant nor the 'right thing' but it makes the code next to trivial :-/ ...
If someone could provide me examples (or pathes agains the current release ) for hooking up with hotplug (now deprecated in 2.6) this could send the sleep-s in retirement and support for 2.4 would remain...

This was about when you released 0.4.2 -I was disappointed that you were going to udev. I'm a mostly-2.4-kernel guy still so I was more interested in usage with hotplug.

I'm a more 2.6 series guy . I don't mind 2.4 - they are stable, no they are rock-solid, but:
1. I run devices that require patching 2.4 and are supported in 2.6 vanilla...
2. Preemptive kernels run really smooth =) these days
3. 2.6 is considered stable by Linus and Patrick, so why to wait any more? I'm on 2.6 since 2.6.0 all the time, and believe me: they are done by the same old team, but now even better . And if that's not enough, why did You ever abandon 2.2 series? and when? Not that You should switch now, but what IS your reason to stick with 2.4 any way (I'm really interested in a honest answer (mail me private if You want) I feel that I'm missing something regarding 2.4 )

While I hacking I got distracted with /proc/partitions not updating itself and how to best manage that. I've been playing with hotplug-ng and diethotplug also.

Well I did a lot of fiddling around blkid command, parsing /proc/partitions, watching /var/log/messages ... I guess the /proc/partitions is updated for harddisks regularly by 2.6 now, but optical devices are an other story...
You should positively try 0.3 release just to compare the old way (with loop) with the new way (0.4 - without). Of course if You are interested.

Does autofs not do what you want? What about kudzu?

Well, kudzu got me inspired in the first time (around the release of mdk 8.1). I wanted it to detect both partitioned (sda1 type) and raw-formatted (sda-type) filesystems, did some hackin' on 9.0 - 10.2 and left mandrake in the meantime :-/ ... kudzu did work (almost) fine but the scripts were all over the fs-tree and poorly documented... I was anoyed with hanging fstab entries around reboots ...
Then I saw Slack (<-read: the light):
1. Richly commented scripts.
2. All_in_one_place scripts.
3. Easy to configure *.conf-files
4. Easy to understand work-flow and boot-process
5. Easy to maintain system (the easiest on_the_hard_way system ever)
6. Once You done the routine you just make a script by pasting from .bash_history and put it in rc.local or in /etc/cron.*/* ...
Then I missed kudzu ... my users (family, friends, coleges ...) missed it also, then they freaked about manual mounting (average users tend to...), so I had to try Automount...
It's clean, efficient and relyable, except for one thing:
unmounting is not covered at all:
1. Either one has to work in sync_fs-mode or
2. Has to setup a whole bunch of sudo / SUID or whatsoever to make an user able to unmount it (again manually ... :-\ again freeking )
So I was unhappy for that while...
Then I hacked thru Slax-5.x.x: the hotplug of all kind of drives was wokring flawlessly (mr. Thomas? I congratulate You) so my hope arise once again: I just 'port' it to slackware!...
(Please see the 0.2 release)
I did like the action, but I missed the control I had in Slackware, and I wanted NAMES for my volumes, and ways to change them easy...
So I figured out I re-write the whole linux-live thing to my own taste...
Please tell me what did You like most, and the opposite too

I downloaded and tried 0.4 and hacked on it some. It was mounting everything under the same mountpoint. Problem with variable expansion. I think I lost the changes though, accidentally.

Thank You very much for your time.
If You could reproduce the problem or explain what did most confuse You (seems You looked at the fstab.conf, right?).
May be I missexplained something?
What are the names of Your volumes?

Once I had it working I checked the resource usage and it wasn't much at all. I think the constant polling is not too big a problem, though I hope there's a better way to do it than using sleep.

The most effort with 0.3.x release was to cut down the overhead in the loop to ~2-5% action and the rest - sleep. I now it's not elegant nor the 'right thing' but it makes the code next to trivial :-/ ...
If someone could provide me examples (or pathes agains the current release ) for hooking up with hotplug (now deprecated in 2.6) this could send the sleep-s in retirement and support for 2.4 would remain...

This was about when you released 0.4.2 -I was disappointed that you were going to udev. I'm a mostly-2.4-kernel guy still so I was more interested in usage with hotplug.

I'm a more 2.6 series guy . I don't mind 2.4 - they are stable, no they are rock-solid, but:
1. I run devices that require patching 2.4 and are supported in 2.6 vanilla...
2. Preemptive kernels run really smooth =) these days
3. 2.6 is considered stable by Linus and Patrick, so why to wait any more? I'm on 2.6 since 2.6.0 all the time, and believe me: they are done by the same old team, but now even better . And if that's not enough, why did You ever abandon 2.2 series? and when? Not that You should switch now, but what IS your reason to stick with 2.4 any way (I'm really interested in a honest answer (mail me private if You want) I feel that I'm missing something regarding 2.4 )

While I hacking I got distracted with /proc/partitions not updating itself and how to best manage that. I've been playing with hotplug-ng and diethotplug also.

Well I did a lot of fiddling around blkid command, parsing /proc/partitions, watching /var/log/messages ... I guess the /proc/partitions is updated for harddisks regularly by 2.6 now, but optical devices are an other story...
You should positively try 0.3 release just to compare the old way (with loop) with the new way (0.4 - without). Of course if You are interested.

Does autofs not do what you want? What about kudzu?

Well, kudzu got me inspired in the first time (around the release of mdk 8.1). I wanted it to detect both partitioned (sda1 type) and raw-formatted (sda-type) filesystems, did some hackin' on 9.0 - 10.2 and left mandrake in the meantime :-/ ... kudzu did work (almost) fine but the scripts were all over the fs-tree and poorly documented... I was anoyed with hanging fstab entries around reboots ...
Then I saw Slack (<-read: the light):
1. Richly commented scripts.
2. All_in_one_place scripts.
3. Easy to configure *.conf-files
4. Easy to understand work-flow and boot-process
5. Easy to maintain system (the easiest on_the_hard_way system ever)
6. Once You done the routine you just make a script by pasting from .bash_history and put it in rc.local or in /etc/cron.*/* ...
Then I missed kudzu ... my users (family, friends, coleges ...) missed it also, then they freaked about manual mounting (average users tend to...), so I had to try Automount...
It's clean, efficient and relyable, except for one thing:
unmounting is not covered at all:
1. Either one has to work in sync_fs-mode or
2. Has to setup a whole bunch of sudo / SUID or whatsoever to make an user able to unmount it (again manually ... :-\ again freeking )
So I was unhappy for that while...
Then I hacked thru Slax-5.x.x: the hotplug of all kind of drives was wokring flawlessly (mr. Thomas? I congratulate You) so my hope arise once again: I just 'port' it to slackware!...
(Please see the 0.2 release)
I did like the action, but I missed the control I had in Slackware, and I wanted NAMES for my volumes, and ways to change them easy...
So I figured out I re-write the whole linux-live thing to my own taste...
Please tell me what did You like most, and the opposite too

I'm still working on these things. Got something called supermount working for mounting cd's and other single-partition or non-partition devices. It was very easy to get going but it does require entries in fstab and, worse, requires a patch to the kernel.
I also have gotten autofs working, both version 3 and 4. This is much better as it's part of the kernel and relevant for usage with kernel-2.4 or 2.6. it doesn't require entries in fstab but needs configured entries in /etc/auto.*. However it doesn't seem to handle multi-partition devices well with kernel-2.4.

I've been working with hotplug and found out how to hook in for usb devices. I didn't have good luck using the current version of hotplug, but using any of the packages from slack 10, 10.1 or 10.2 seems to work.
I wrote a smal script to verbalize the output which shows where you could hook into the usb system.
Create the directory /etc/hotplug.d/usb and place the following script in there (named 10-stub.hotplug in this case):

#!/bin/sh

cd /etc/hotplug
. ./hotplug.functions

DEBUG=yes export DEBUG

debug_mesg "arguments ($*) env (`env`)"
echo "Hello from 10-stub" >> /var/log/messages
case $ACTION in
add|register)
# Stub
echo "Adding device" >> /var/log/messages
echo "SUBSYSTEM is: $SUBSYSTEM" >> /var/log/messages
echo "DEVPATH is: $DEVPATH" >> /var/log/messages
echo "DEVICE is: $DEVICE" >> /var/log/messages
echo "PHYSDEVDRIVER is: $PHYSDEVDRIVER" >> /var/log/messages
echo "ACTION is: $ACTION" >> /var/log/messages
echo "PRODUCT is: $PRODUCT" >> /var/log/messages
echo "INTERFACE is: $INTERFACE" >> /var/log/messages
echo "TYPE is: $TYPE" >> /var/log/messages
echo "DEVFS is: $DEVFS" >> /var/log/messages
echo "REMOVER is: $REMOVER" >> /var/log/messages

;;
remove|unregister)
# Stub
echo "Removing Device" >> /var/log/messages
echo "SUBSYSTEM is: $SUBSYSTEM" >> /var/log/messages
echo "DEVPATH is: $DEVPATH" >> /var/log/messages
echo "DEVICE is: $DEVICE" >> /var/log/messages
echo "PHYSDEVDRIVER is: $PHYSDEVDRIVER" >> /var/log/messages
echo "ACTION is: $ACTION" >> /var/log/messages
echo "PRODUCT is: $PRODUCT" >> /var/log/messages
echo "INTERFACE is: $INTERFACE" >> /var/log/messages
echo "TYPE is: $TYPE" >> /var/log/messages
echo "DEVFS is: $DEVFS" >> /var/log/messages
echo "REMOVER is: $REMOVER" >> /var/log/messages
;;
esac

Then, open a terminal and type 'tail -f /var/log/messages' and connect a USB device. You should see the echoed ouput from the above script. Of course you'd hook your handler script in here, instead of echoing all this, or in addition to it. Then your script can just look for the devices and handle them. I'm still trying to figure out if there's a way to get a hook into optical device events. I placed a similar script in /etc/hotplug.d/pci which is very noisy during bootup, so I know the method is working for other buses.
Turning on verbose debugging in the usb and scsi drivers gives more info -I even had it reporting all the partitions found on my usb hardrive.

You have a persuasive way (perhaps you wear white patent-leather shoes and sell used autos?), so I rolled up a 2.6 kernel the other day to give another go. Still lots of broken stuff in there and out of every 4-5 reboots I'd get a hung computer. Not good... I don't think Pat V's comments equate to the opinion that 2.6 is stable. Trouble is that each version has new features, API changes and bug-fixes all in one. I've yet to hear of a single version that was more dependable than the last. Other distros handle this better because they have 5-20 people who do nothing but fix kernel problems. Otherwise they'd never be ablt to provide backward support or be able to move forward either.
I'd much rather use even 3rd-party patches on a 2.4 kernel than try to cope with the 2.6 mess. Some day they will get most of it ironed out and I'll join the crowd. Actually I love keeping the learning curve high, but I know that I'm not a typical computer *user*. Most of us linux guys are geeky tweakers. About 2 years ago I decided to put most of my work into developing an easy-to use and lightweight desktop for users who are tired of computer lock-ups, constant upgrades and re-installations. I'm sorry every time I upgrade my system as it just deters me from that goal without gaining anything. I love the simplicity of Slackware -both for learning and for add-on development, but frankly, a 6-month release cycle is way too often for a small team to cope with. Trying to maintain a distro without clear goals besides a release schedule is a disaster.
The current development model/philosophy for the kernel has also been a true setback regarding 'world domination'. I'll get lots of flames for saying these things, but I don't care. I now there are lots of people who think the same way and just want the damn thing to *work*. Feature-creep is a dangerous vice and shouldn't be allow to foul up things that worked just fine before. Ditto for needless API changes which only force other developers to rewrite their software just because someone wanted to show off their new coding style.
Back to my hole now, I'm still working on that compact, stable distro which is great for use from external devices or in $100 laptops or on your old PI. Know how many billions of people could use something like that?