[patch] progress with autofs.

[David Zeuthen]

Hi,

In my view it would really be better if there was a dedicated callout
modifying /etc/auto.hal rather than putting this functionality into
fstab-sync. Just separating functionality. Btw, fstab-sync is completely
optional since it's enforcing policy. If I understand correctly Ubuntu
doesn't use fstab-sync, rather they rely on pmount (see the utopia-
list at gnome.org archives from July or August for details).

So, what I'm thinking is that this is just a third way to enforce policy
using hal. Hence, why I like the separation. Also, the changes to hald
seems to be pretty minimalistic, if any, given your message below, is
this correct? It would be good to have a configure option to turn this
on and off.

Thanks,
David

On Fri, 2004-09-24 at 01:38 +0100, Luke Kenneth Casson Leighton wrote:
> okay, um, well, i'm making progress.
> 
> i've had to do a few major "if (automount)..." additions and logic
> changes.  um.
> 
> also i think it quite sensible to create a _separate_
> "volume.automount_point" because it allows KVM and GVM to distinguish
> the mount point from an ordinary one.
> 
> plus, you actually _need_ to know where the automount point is _going_
> to be as distinct from where it really is.
> 
> plus, by putting the automount point into a separate HAL database entry,
> the existing logic is not interfered with.
> 
> things to fix:
> 
> fstab-sync [in automount mode] presently exits if it detects
> that the entry in /etc/auto.hal already exists: what _i_ need
> is that the entry "volume.automount_point" be put in the HAL
> database (by fstab-sync) even if that is the case.
> 
> if HAL was terminated with prejudice, leaving behind the entries in
> /etc/auto.hal because fstab-sync was never called with an -r, or for
> any other reason something goes pear-shaped....
> 
> so, the call to add volume.automount_point is done BEFORE the check
> for the entry already being in /etc/auto.hal, which introduces
> a race condition in the unlikely event of someone else modifying
> /etc/auto.hal.
> 
> i just realised that i have a bug in fstab-sync wrt when there already
> exists an entry in /etc/auto.hal - i need to do a lookup of the udi
> being added, see if it's already in /etc/auto.hal, and if so, set the
> matching auto.hal mountpoint as volume.automount_point.
> 
> when i've fixed that i will send in some patches.
> 
> anyway.
> 
> this is a rough guide to the logical sequence of events for
> autofs-enhanced HAL and fstab-sync:
> 
> 1) hal gets hotplug events, adds device, calls fstab-sync
> 
> 2) fstab-sync checks entry in /etc/auto.hal, which places an entry
>    in the DEVICE block "volume.automount_point" maybe this should be
>    called block.automount_point, hm.
> 
> 3) after fstab-sync exits, hal picks up the volume.automount string and
>    sends a VolumeMount notification via dbus WITH THIS STRING.
> 
>    if anyone can think of a better way to do this i'd love to hear it.
> 
>    the mount point information is *not* going to come from /etc/mtab
>    on-demand.
> 
>    and it's also not really going to come from KVM or GDM because, hey,
>    the mountpoint directory doesn't actually exist with autofs, it
>    only exists _after_ you access it!
> 
> 4) polling takes place in hal, hal discovers a volume: it copies the
>    volume.automount_point string FROM THE PARENT into the volume.
> 
>    volume.mount_point and all functionality related to
>    volume.mount_point has NOT BEEN ALTERED IN ANY WAY
>    (including /etc/mtab stuff)
> 
> 5) polling continues to take place, hal finds a volume has gone: it gets
>    deleted, normal manner.
> 
>    parent's volume.automount_point database entry is STILL THERE.
>    so a repeat of 4 will result in the automount point being picked up
>    again.
> 
> 
> the existing functionality and state machine is not altered.
> 
> what i am tying autofs into effectively is the volume discovery and
> removal by HAL.
> 
> l.
> 

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal