[patch] progress with autofs.

[Luke Kenneth Casson Leighton]

On Fri, Sep 24, 2004 at 03:28:02PM +0200, David Zeuthen wrote:
> On Fri, 2004-09-24 at 12:27 +0100, Luke Kenneth Casson Leighton wrote:
> > On Fri, Sep 24, 2004 at 02:37:52AM +0200, David Zeuthen wrote:
> > 
> > > 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.
> > 
> > it's going to have to be a bit more than a configure option: certain
> > disks will need to be excluded from the autofs system, and those
> > should go into /etc/fstab instead.
> > 
> 
> Why is that? Of course if a volume is already listed in /etc/fstab it
> shouldn't be autofs managed
 
 ah... precisely :)  

 yes.

 hm.  how am i going to do that.

 i'll have to think about that, by letting fstab-sync read _both_
 fstab _and_ auto.hal.

 some of the global variables will have to become locals... hmmm...
 a struct containing the necessary info....

 yep, i can do that.


> > which is another reason why it might not be sensible to split fstab-sync
> > into a separate version doing autofs.
> > 
> > maybe there are other ways to do this:
> > 
> > 	two programs reading the same conf file, one which says "all
> > 	entries in this conf file, i place in /etc/fstab" and the other
> > 	"all entries NOT in this conf file , i place in /etc/auto.hal".
> > 
> > 	yuk!
> > 
> > at some point i will think about how do do changes in behaviour of
> > HAL depending on whether a volume was managed by fstab-sync in autofs
> > mode or fstab-sy in non-autofs mode.
> > 
> > at the moment, i've put it as a top-level /etc/hal/hald.conf option.
> > 
> 
> I really don't think stuff like this belongs in the hald configuration
> file since it's policy. 

 i assume you are referring to your other email (have to get to it)
 where you suggest a don-trust-mtab config option?


> Ideally hald shouldn't know about whether
> something is autofs managed or not. 

 :)

 i have several answers to that.

 1)

 	the easiest place from here to there.
	
	i know you don't necessarily like it, but if that library existed,
	the one that did mount management, i'd use that instead.

	it doesn't exist, therefore the only remaining option is to hack
	HAL.

 2)

	 unfortunately, as you'll see from the patch i just sent, you
	 do need HAL to know about autofs.

	 you need HAL's cooperation with fstab-sync-in-autofs-mode in
	 passing the location of the automount point.

	 otherwise you'll never get to know where the automount point _is_!!!

	 the reason is because automount doesn't let you _see_ the directory:
	 only if you know it's there and try to access it will it suddenly
	 "appear" as if by magic.

 
 3) 
	 i figured what the hell, if you can update the HAL database to change
	 the block device to point at the real device (/dev/hdc) instead of the
	 symlink (/dev/cdrom) then hey, i'm gonna add a block.automount_point to
	 the block device *Grin*.


 4)

	 the alternative is to hack KDE (and Gnome) to read my "magic
	 /etc/auto.hal" file or to write some special library _just_ to deal
	 with my magic autofs file i happened to scheme up.

	 ... i sincerely doubt _that's_ gonna happen, esp. as a simple
	 intercommunication between HAL and fstab-sync makes it totally
	 unnecessary for KDE or Gnome to _have_ any knowledge of autofs.

     

> However I do think it's sensible to
> tell hald "dont trust the /etc/mtab file for this volume" (property
> volume.is_autofs_managed in my last mail). But that's about it.

 okay, will read that one in a mo (messages arrive in different order)

 l.

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