-hosts and -null enabling for autofs v4.1.x

-hosts and -null enabling for autofs v4.1.x

[Gordon Lack]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

   Here is a simple patch to the system autofs startup script so that
-hosts and -null is enabled in autofs 4.1.x.  This patch is actually
against a RedHat autofs, but the same code is present in
samples/rc.autofs.in.

   For -hosts, it just translates the map name to /etc/auto.net if that
is present and executable.

   For -null, it just adds the mountpoint location to the list of
knownmaps, but doesn't do anything else.


PS:  I see that v5 handles these anyway.  However, this note in
README.v5.release looks ominous...

==========
- a "hosts" map module has been added
  - an entry like "/net -hosts" is now understood and uses the new
    multi-mount semantics for lazy mount/umount of exports from the
host.
  - the implementation is quite simple minded at this stage and will
need
    refinment. It just iterates through the host table and addes any
host
    names it finds to the internal map.
==========

Some of us have thousands of hosts in a host map, eg:

systemx*[1] ypcat -k hosts | wc -l
   30899

[-- Attachment #2: autofs.diffs --]
[-- Type: text/plain, Size: 1094 bytes --]

*** autofs.orig	2006-07-07 08:56:05.000000000 -0400
--- autofs	2006-07-07 09:25:57.000000000 -0400
***************
*** 191,197 ****
  	    dir=`echo "$dir" | sed -e "s/\/*$//"`
  
  	    if [ ! -z "$map" -a "$map" = "-hosts" ] ; then
! 		continue
  	    fi
  	    if [ $DISABLE_DIRECT -eq 1 \
  			-a x`echo $dir | grep -E "^/-"` != 'x' ]
--- 191,201 ----
  	    dir=`echo "$dir" | sed -e "s/\/*$//"`
  
  	    if [ ! -z "$map" -a "$map" = "-hosts" ] ; then
!                 if [ -x '/etc/auto.net' ]; then
!                     map='/etc/auto.net'
!                 else
!                     continue
!                 fi
  	    fi
  	    if [ $DISABLE_DIRECT -eq 1 \
  			-a x`echo $dir | grep -E "^/-"` != 'x' ]
***************
*** 210,215 ****
--- 214,224 ----
  		fi	
  	    done
  
+             if [ "$map" = '-null' ]; then
+ # Just add dir to list of those with a known map, but do nothing else
+                 knownmaps=" $dir/ $knownmaps"
+                 continue
+             fi
  	    if [ ! -z "$dir" -a ! -z "$map" \
  			-a x`echo "$map" | cut -c1` != 'x-' ]
  	    then

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: -hosts and -null enabling for autofs v4.1.x

[Ian Kent]

On Fri, 2006-07-07 at 16:02 +0100, Gordon Lack wrote:

> PS:  I see that v5 handles these anyway.  However, this note in
> README.v5.release looks ominous...
> 
> ==========
> - a "hosts" map module has been added
>   - an entry like "/net -hosts" is now understood and uses the new
>     multi-mount semantics for lazy mount/umount of exports from the
> host.
>   - the implementation is quite simple minded at this stage and will
> need
>     refinment. It just iterates through the host table and addes any
> host
>     names it finds to the internal map.
> ==========
> 
> Some of us have thousands of hosts in a host map, eg:
> 
> systemx*[1] ypcat -k hosts | wc -l
>    30899

The hosts table is only iterated if you also specify --ghost as an
option. The internal program default is ghosting (browsing) enabled but
the installed configuration modifies the default and disables it for
backward compatibility.

So if you've got potentially large maps then the idea is to leave the
installed settings as they are.

Ian

Re: -hosts and -null enabling for autofs v4.1.x

[Jeff Moyer]

==> Regarding [autofs] -hosts and -null enabling for autofs v4.1.x; "Gordon Lack" <gml4410@ggr.co.uk> adds:

gml4410>    Here is a simple patch to the system autofs startup script so that
gml4410> -hosts and -null is enabled in autofs 4.1.x.  This patch is actually
gml4410> against a RedHat autofs, but the same code is present in
gml4410> samples/rc.autofs.in.

gml4410>    For -hosts, it just translates the map name to /etc/auto.net if
gml4410> that is present and executable.

That bit looks sane at first glance.

gml4410>    For -null, it just adds the mountpoint location to the list of
gml4410> knownmaps, but doesn't do anything else.

This isn't exactly right.  It should "nullify" the next occurrence of the
given mount point, and then go away.  Consider a map like this:

/home -null
+auto.master
/home /etc/auto.home

Let's assume that +auto.master reads the master map from nis, and the nis
master map defines /home to point to some nis map.  The above would ignore
the /home entry in the nis master, and allow us to replace it with our own.

-Jeff

Re: -hosts and -null enabling for autofs v4.1.x

[Gordon Lack]

Jeff Moyer wrote:
>
> gml4410>    For -null, it just adds the mountpoint location to the list of
> gml4410> knownmaps, but doesn't do anything else.
> 
> This isn't exactly right.  It should "nullify" the next occurrence of the
> given mount point, and then go away.
 
   That isn't how automount maps are supposed to work (at least not Sun
ones, according to how I read the documentation).  Only the *first*
occurrence of a mountpoint is supposed to be used - that is meant to
override *all* following occurences.


>  Consider a map like this:
> 
> /home -null
> +auto.master
> /home /etc/auto.home
> 
> Let's assume that +auto.master reads the master map from nis, and the nis
> master map defines /home to point to some nis map.  The above would ignore
> the /home entry in the nis master, and allow us to replace it with our own.

   If you want to replace an entry in NIS you add your entry *before*
loading the NIS maps.  So to set your own /home to override the NIS one
you use:

 /home /etc/auto.home
 +auto.master

   The -null map is so that you may wipeout *all* occurrences of a
mountpoint that you would otherwise have.  At least that's how I've
always read it.  In that respect it is no different to something like:

 /amp auto.map1
 /amp auto.map2
 /amp auto.map3

where I would expect to see auto.map1 used on /amp, since once there is
a map on a mountpount it won't be overridden.

Also note - we're talking about Sun-style automounts here.  Anyone with
OSF1 would (might) know they do everything backwards (the *last* map
wins...)

Re: -hosts and -null enabling for autofs v4.1.x

[Jeff Moyer]

==> Regarding Re: [autofs] -hosts and -null enabling for autofs v4.1.x; "Gordon Lack" <gml4410@ggr.co.uk> adds:

gml4410> Jeff Moyer wrote:
>> 
gml4410> For -null, it just adds the mountpoint location to the list of
gml4410> knownmaps, but doesn't do anything else.
>> 
>> This isn't exactly right.  It should "nullify" the next occurrence of the
>> given mount point, and then go away.
 
gml4410>    That isn't how automount maps are supposed to work (at least
gml4410> not Sun ones, according to how I read the documentation).  Only
gml4410> the *first* occurrence of a mountpoint is supposed to be used -
gml4410> that is meant to override *all* following occurences.

Yes, you are correct.  This line in the man page is what confused me:

     The -null map cancels a previous map for the directory indi-
     cated.

Thanks!

Jeff

Re: -hosts and -null enabling for autofs v4.1.x

[Gordon Lack]

Jeff Moyer wrote:
>
> Yes, you are correct.

   Thanks.

>                       This line in the man page is what confused me:
> 
>      The -null map cancels a previous map for the directory indi-
>      cated.

   Yes, it's an interesting interpretation of "previous" since the end
of that paragraph is:

>                             To be effective, the -null entries must
>     be inserted before the included map entry.

Re: -hosts and -null enabling for autofs v4.1.x

[Ian Kent]

On Fri, 2006-07-14 at 16:58 +0100, Gordon Lack wrote:
> Jeff Moyer wrote:
> >
> > Yes, you are correct.
> 
>    Thanks.
> 
> >                       This line in the man page is what confused me:
> > 
> >      The -null map cancels a previous map for the directory indi-
> >      cated.
> 
>    Yes, it's an interesting interpretation of "previous" since the end
> of that paragraph is:
> 
> >                             To be effective, the -null entries must
> >     be inserted before the included map entry.

Indeed.

I found it confusing as well.

Ian

Bug (and patch) in autofs init.d script (v4.1.4)

[Gordon Lack]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

    When comparing the running vs. expected commands for "autofs reload"
the autofs init.d script dosn't correctly handle changes to options. 
eg: If the LOCALOPTIONS have been extended it will not issue a Stop for
a running automount point, but will issue a Start for the new command
(which will fial, as the current process hasn't been stopped).  This is
because it is just doing a start-of-line anchored grep for a command.

    The attached patch fixes this by obtaining the full runnning command
for the particular mountpoint of interest and comparing this (verbatim)
against what it is expecting to see.  This allows for changes to the
options.

    It does assume that the automount point will be the second token
starting with a '/' in a full automount command line (the automount
command being the first such token).  I believe this will always be the
case.

[-- Attachment #2: bug.patch --]
[-- Type: text/plain, Size: 1281 bytes --]

--- autofs-4.1.4/samples/rc.autofs.in	2006-08-22 14:48:51.000000000 +0100
+++ autofs.bug	2006-08-22 14:52:02.000000000 +0100
@@ -562,7 +562,14 @@
 	ps axwww|grep "[0-9]:[0-9][0-9] $DAEMON " | (
 	    while read pid tt stat time command; do
 		echo "$command" >>$TMP2
-		if ! grep -q "^$command" $TMP1; then
+#   In order to check for changes we need to find the line, if any,
+# corresponding to this mountpoint with *any* options and see whether
+# it is what we want...this allows for changing options.
+# 
+#		if ! grep -q "^$command" $TMP1; then
+                mpoint=`get_fpath2 $command`
+                mpoint_com=`grep " $mpoint " $TMP1`
+                if [ "$command" !=  "$mpoint_com" ]; then
 		    if ! echo "$command" | grep -q -e --submount; then
 			kill -USR2 $pid 2> /dev/null
 			echo $"Stop $command"
@@ -574,7 +581,14 @@
 	    done
 	)
 	cat $TMP1 | ( while read x; do
-		if ! grep -q "^$x" $TMP2; then
+#   Again - we can't rely on the options being unchanged, so get the
+# command for this mountpoint and check it is there verbatim
+#
+#		if ! grep -q "^$x" $TMP2; then
+#
+                mpoint=`get_fpath2 $x`
+                mpoint_com=`grep " $mpoint " $TMP2`
+                if [ "$x" !=  "$mpoint_com" ]; then
 			$x
 			echo $"Start $x"
 		fi

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Enhancement patch for autofs v4.1.4 init.d script

[Gordon Lack]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

   The init.d autofs script runs a check for "maps within maps"
(actually mountpoints within mountpoints) which it does by looping over
all knownmaps and grepping for a start-of-line match in both directions
(ie: 2 greps).

   I was testing some things on a system with 39 maps and was surprised
to find the autofs script took 38 seconds to report on required
reloads.  Testing showed that there were ~3000 runs of grep called by
this piece of code.

   It is possible to do the same test with internal case statements. 
This removes ~3000 calls to grep (I have another system with 49 map, so
it gets nearly 5000...).  With this fix applied the autofs script ran in
one quarter of the time.

[-- Attachment #2: enhance.patch --]
[-- Type: text/plain, Size: 943 bytes --]

--- autofs-4.1.4/samples/rc.autofs.in	2006-08-22 14:48:51.000000000 +0100
+++ autofs.enhance	2006-08-22 14:49:51.000000000 +0100
@@ -233,11 +233,21 @@
 	    # another map or another map, maps on top of it.
 	    for knownmap in $knownmaps
 	    do	
-		if [ "`echo $dir/ | grep ^$knownmap`" != "" \
-			-o "`echo $knownmap | grep ^$dir/`" != "" \]
-		then 
-		    continue 2
-		fi
+# This gets run for all maps on all maps, so is O(n^2)
+# This means 3500 external grep calls for 38 map entries,
+# which is slow.  case statements make it much faster.
+#
+#		if [ "`echo $dir/ | grep ^$knownmap`" != "" \
+#			-o "`echo $knownmap | grep ^$dir/`" != "" \]
+#		then 
+#		    continue 2
+#		fi
+                case "$dir/" in
+                $knownmap*)   continue 2 ;;
+                esac
+                case "$knownmap" in
+                $dir/*)   continue 2 ;;
+                esac
 	    done
 
 	    if [ ! -z "$dir" -a ! -z "$map" \

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Bug in autofs v4.1.4 init.d script (and fix)

[Gordon Lack]

   In the getfilemounts() function when the code comes acros a line
which starts with a "+" (include an NIS map here) instead of just
including that map it cats the entire /etc/auto.master file again and
actually include *all* NIS maps which are mentioned.  This means that if
you have n (> 1) NIS map inclusions then the inclusions are done <n>
times,and it also means that the inclusion for all maps is first done
when the first NIS map inclusion is found. 

   It is perfectly legitimate to have an /etc/auto.master file like
this:

+auto.master-TEST
/home   /etc/my-home-override.amap
+auto.master

   whereby the /home setting is meant to override the stanmdrad one in
auto.master.  The bug in the getfilemounts() function stops this
happening as auto.master will be included when +auto.master-TEST is
seen.

   The fix for this is to change the "while read auto_master_in" loop to
be:

        while read auto_master_in
        do
            case "$auto_master_in" in
            +*)
                nismap=`echo $auto_master_in | sed -e 's/^\+//'`
                catnismap $nismap
                ;;
            *)
                echo $auto_master_in
                ;;
            esac
        done

Bug in autofs v4.1.4 init.d script for reload (and fix)

[Gordon Lack]

   The init.d script when asked to reload compares the list of required
mount commands (in TMP1) against the list of currently-running automount
processes (in TMP2).

   However, automount fork()s as it runs, so the process list in TMP2
will, potentially, contain these child processes.  The result of this is
(conter-intuitively) that thescript tries to start *another* process. 
(The reason is that when you grep TMP2 for the mountpoint of the TMP1
entry you get 2 lines, which doesn't match the one line, so the code
thinks it isn't there).

   There is a simple fix for this - change the process-finding command
to include the ppid (using Unix, rather than BSD options) and only
select the lines with ppid==1.

   ie: replace:

        ps axwww|grep "[0-9]:[0-9][0-9] $DAEMON " | (
            while read pid tt stat time command; do

 with

# Remove duplicates (which happen transiently on fork()ing?)
# Only need the pid, but also match against ppid, so we only get
# "parent" automount processes not forked ones.
# (The [1] in the grep is so that the grep command doesn't match)
#
        ps -e -opid=,ppid=,command= | grep " [1] $DAEMON " | (
            while read pid ppid command; do

Re: Bug in autofs v4.1.4 init.d script for reload (and fix)

[Gordon Lack]

Gordon Lack wrote:
> 
>    The init.d script when asked to reload compares the list of required
> mount commands (in TMP1) against the list of currently-running automount
> processes (in TMP2).
>... 
>    ie: replace:
> 
>         ps axwww|grep "[0-9]:[0-9][0-9] $DAEMON " | (
>             while read pid tt stat time command; do
>...
>         ps -e -opid=,ppid=,command= | grep " [1] $DAEMON " | (
>             while read pid ppid command; do


   Make that ps -we -opid=............

   The -w is needed for older versions of procps (eg: 2.0.7)

autofsv5 bug. Non-existent dirs get "mounted"!

[Gordon Lack]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

    If you have a wildcard entry in an automount map and refer to an 
entry which does not exist on the NFS server the entry actually appears 
within the autofs tree (but with nothing mounted on it).

    This causes havoc if you are testing for the existence of a 
directory in an automount point.

    It took a while to track it down, since all of the code to remove 
the locally-created dir if the mount failed was in place.  I eventually 
found an incorrect reuse of a status variable, which is overwriting the 
return code from the mount (failed), with that of a mutex unlock (which 
must succeed, or the process dies..).

    This happens in daemon/spawn.c

    Patch (against distro as on 10 Nov 2006) attached.

[-- Attachment #2: spawn.c.patch --]
[-- Type: text/plain, Size: 858 bytes --]

--- daemon/spawn.c.orig	2006-11-10 10:28:47.270474000 +0000
+++ daemon/spawn.c	2006-11-10 10:11:22.917315000 +0000
@@ -202,11 +202,25 @@
 		if (waitpid(f, &status, 0) != f)
 			status = -1;	/* waitpid() failed */
 
-		if (use_lock) {
+/* GML - Bug.
+ *  This code used status, hence wiping out the result of the mount!
+ *  Hence we always return from here with success, even when the
+ *  mount actually fails, meaning we get directories created for
+ *  non-existent entries...
+ */
+#if 0 
+ 		if (use_lock) {
 			status = pthread_mutex_unlock(&spawn_mutex);
 			if (status)
 				fatal(status);
 		}
+#endif
+		if (use_lock) {
+                        int lstatus;
+			lstatus = pthread_mutex_unlock(&spawn_mutex);
+			if (lstatus)
+				fatal(lstatus);
+		}
 		pthread_sigmask(SIG_SETMASK, &oldsig, NULL);
 		pthread_setcancelstate(cancel_state, NULL);
 

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

autofsv5 enhancement - map names in /proc/mounts

[Gordon Lack]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

    The current entry which ends up in /proc/mounts for autofs entries 
looks like:

  automount /home autofs rw,fd=170,......

Other autofs implementations (Solaris, Irix, OSF1, ...) have the 
map-name which is being used as the first token.

The attached patch to daemon/indirect.c adds this (for indirect maps - I 
don't have any other kind...).

The result is lines like:

  auto.home /home autofs rw,fd=170,......


This does means that kernel mount entries (eg: those added under 
SElinux?) need to ignore the device name passed in, but they should be 
doing that for autofs file systems anyway.

NOTE: The ap->entry->first->argv[0] seems a contrived way to get a map 
name, but is all I could see looking through the code.

[-- Attachment #2: indirect.c.patch --]
[-- Type: text/plain, Size: 513 bytes --]

--- daemon/indirect.c.orig	2006-11-10 10:29:18.716266000 +0000
+++ daemon/indirect.c	2006-11-10 10:06:21.726654000 +0000
@@ -183,7 +183,11 @@
 		ap->dir_created = 1;
 	}
 
+/* GML - Enhancement
+ *   Put map name into /proc/mounts, as Solaris, Irix, OSF1, do
 	ret = mount("automount", ap->path, "autofs", MS_MGC_VAL, options);
+ */
+	ret = mount(ap->entry->first->argv[0], ap->path, "autofs", MS_MGC_VAL, options);
 	if (ret) {
 		crit(ap->logopt, "failed to mount autofs path %s", ap->path);
 		goto out_rmdir;

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

autofsv5 - mouting files (not dirs)

[Gordon Lack]

    The automount code (at least for indirect mounts) will not mount an 
entry which is a file - it has to be a directory.

    The reason behind this is that the code first creates the directory 
then tries to mount the remote object on it.

    In order to mount a remote file you need to mount it over a file, 
not a directory.  (As far as I can tell, mounting a file on a file works 
OK in Linux).

    Would it be possible to get automount to retry on a file if it gets 
ENOTDIR from the remote end?

Re: autofsv5 - mouting files (not dirs)

[Ian Kent]

On Fri, 2006-11-10 at 17:33 +0000, Gordon Lack wrote:
>     The automount code (at least for indirect mounts) will not mount an 
> entry which is a file - it has to be a directory.
> 
>     The reason behind this is that the code first creates the directory 
> then tries to mount the remote object on it.
> 
>     In order to mount a remote file you need to mount it over a file, 
> not a directory.  (As far as I can tell, mounting a file on a file works 
> OK in Linux).
> 
>     Would it be possible to get automount to retry on a file if it gets 
> ENOTDIR from the remote end?

You got me there. I'm not sure about mounting on files at this stage.

I think there's probably a bit more to change than just the create
directory function.

Ian

Re: autofsv5 enhancement - map names in /proc/mounts

[Ian Kent]

On Fri, 2006-11-10 at 12:05 +0000, Gordon Lack wrote:
>     The current entry which ends up in /proc/mounts for autofs entries 
> looks like:
> 
>   automount /home autofs rw,fd=170,......
> 
> Other autofs implementations (Solaris, Irix, OSF1, ...) have the 
> map-name which is being used as the first token.
> 
> The attached patch to daemon/indirect.c adds this (for indirect maps - I 
> don't have any other kind...).
> 
> The result is lines like:
> 
>   auto.home /home autofs rw,fd=170,......

I thought about doing this but how do you handle

/home	/etc/auto.server1.home
/home	/etc/auto.server2.home

What map name will you use?

or

/home	/a very long path/map.map

etc. ...

> 
> This does means that kernel mount entries (eg: those added under 
> SElinux?) need to ignore the device name passed in, but they should be 
> doing that for autofs file systems anyway.
> 
> NOTE: The ap->entry->first->argv[0] seems a contrived way to get a map 
> name, but is all I could see looking through the code.
> plain text document attachment (indirect.c.patch)
> --- daemon/indirect.c.orig	2006-11-10 10:29:18.716266000 +0000
> +++ daemon/indirect.c	2006-11-10 10:06:21.726654000 +0000
> @@ -183,7 +183,11 @@
>  		ap->dir_created = 1;
>  	}
>  
> +/* GML - Enhancement
> + *   Put map name into /proc/mounts, as Solaris, Irix, OSF1, do
>  	ret = mount("automount", ap->path, "autofs", MS_MGC_VAL, options);
> + */
> +	ret = mount(ap->entry->first->argv[0], ap->path, "autofs", MS_MGC_VAL, options);
>  	if (ret) {
>  		crit(ap->logopt, "failed to mount autofs path %s", ap->path);
>  		goto out_rmdir;
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: autofsv5 enhancement - map names in /proc/mounts

[Gordon Lack]

Ian Kent wrote:
> 
> I thought about doing this but how do you handle
> 
> /home	/etc/auto.server1.home
> /home	/etc/auto.server2.home
> 
> What map name will you use?

    Given that there can only be one map active at a mountpoint, and the 
first one wins (which is why the -null map works) that would be 
/etc/auto.server1.home,

> /home	/a very long path/map.map
> 
> etc. ...

    Yes - perhaps more of a problem, but:

a) is there any limit to the line length?
b) can you actually get space-containing paths into use through the parser?

   For b), if you can't it's not an issue, if you can you could URI 
encode it?

Re: autofsv5 enhancement - map names in /proc/mounts

[Ian Kent]

On Mon, 2006-11-13 at 10:09 +0000, Gordon Lack wrote:
> Ian Kent wrote:
> > 
> > I thought about doing this but how do you handle
> > 
> > /home	/etc/auto.server1.home
> > /home	/etc/auto.server2.home
> > 
> > What map name will you use?
> 
>     Given that there can only be one map active at a mountpoint, and the 
> first one wins (which is why the -null map works) that would be 
> /etc/auto.server1.home,

Ya but for some reason I believed that I was able to do this with the
Solaris automounter and so v5 now will merge each map.

> 
> > /home	/a very long path/map.map
> > 
> > etc. ...
> 
>     Yes - perhaps more of a problem, but:
> 
> a) is there any limit to the line length?
> b) can you actually get space-containing paths into use through the parser?

An individual file name can be up to 255 characters alone.
They don't have to have spaces to be long.

How do you use this feature?

Ian

Re: autofsv5 enhancement - map names in /proc/mounts

[Gordon Lack]

Ian Kent wrote:
>>     Given that there can only be one map active at a mountpoint, and the 
>> first one wins (which is why the -null map works) that would be 
>> /etc/auto.server1.home,
> 
> Ya but for some reason I believed that I was able to do this with the
> Solaris automounter and so v5 now will merge each map.

    Just tried it on Solaris8:

Added these to /etc/auto_master:

  /local/AM /etc/auto.AM1
  /local/AM /etc/auto.AM2

/etc/mntab now has *just* this 1 line at the end:

  /etc/auto.AM1   /local/AM       autofs  indirect,..........

and only the entries in /etc/auto.AM1 work.

This is what I would expect.  eg: -null is there so that you can 
"remove" an entry from an included NIS  auto.master (or equiv).  If the 
code is merging then this won't work, and its supposed to.

It's also perfectly reasonable to have, say, a standard auto.master map, 
and a smaller auto.master.wizards map, with maps in it which are meant 
to *override* the standard ones.

I can't see any benefit in merging things here - only confusing 
complexity.  On Solaris and Irix (and Linux up to autofsv4) I've only 
ever seen the first map mentioned be used (OSF1 uses the last, which is 
truly bizarre, as it creates mountpoints then has to immediately rip 
them out in order to replace them...)

> An individual file name can be up to 255 characters alone.
> They don't have to have spaces to be long.

    Agreed - but is there a limit to the line lengths or total size of 
/proc/mounts?

> How do you use this feature?

    I have a script which reads it and prints the actual mounts that 
exists at a given automount point.  It means I don't need to find out 
which map is handling a particular automount point, nor do I have to 
type in the map name, and I get the keys sorted for me.

Re: autofsv5 enhancement - map names in /proc/mounts

[Ian Kent]

On Mon, 2006-11-13 at 16:58 +0000, Gordon Lack wrote:
> Ian Kent wrote:
> >>     Given that there can only be one map active at a mountpoint, and the 
> >> first one wins (which is why the -null map works) that would be 
> >> /etc/auto.server1.home,
> > 
> > Ya but for some reason I believed that I was able to do this with the

"believed", past tense.

> > Solaris automounter and so v5 now will merge each map.
> 
>     Just tried it on Solaris8:
> 
> Added these to /etc/auto_master:
> 
>   /local/AM /etc/auto.AM1
>   /local/AM /etc/auto.AM2
> 
> /etc/mntab now has *just* this 1 line at the end:
> 
>   /etc/auto.AM1   /local/AM       autofs  indirect,..........
> 
> and only the entries in /etc/auto.AM1 work.
> 
> This is what I would expect.  eg: -null is there so that you can 
> "remove" an entry from an included NIS  auto.master (or equiv).  If the 
> code is merging then this won't work, and its supposed to.
> 
> It's also perfectly reasonable to have, say, a standard auto.master map, 
> and a smaller auto.master.wizards map, with maps in it which are meant 
> to *override* the standard ones.
> 
> I can't see any benefit in merging things here - only confusing 
> complexity.  On Solaris and Irix (and Linux up to autofsv4) I've only 
> ever seen the first map mentioned be used (OSF1 uses the last, which is 
> truly bizarre, as it creates mountpoints then has to immediately rip 
> them out in order to replace them...)

I did this because I believed I had used this in Solaris previously.
I'm still deciding whether to change the semantics.

The "-null" handling is incorrect atm as well.
I'm fixing that now.

And as far as allowing multiple maps per indirect mount point goes,
there was another reason for this. In autofs v4 there is a map type
called "milti-map" where multiple map names can be given and this allows
such maps to be migrated to v5. The "-null" map handling will now be
setup to white-out all further occurrences of the nulled mount point. 

As far as adding the map name goes I haven't finished checking the
Solaris behavior yet.

> 
> > An individual file name can be up to 255 characters alone.
> > They don't have to have spaces to be long.
> 
>     Agreed - but is there a limit to the line lengths or total size of 
> /proc/mounts?

Not sure. I'd have to refer to the source.

> 
> > How do you use this feature?
> 
>     I have a script which reads it and prints the actual mounts that 
> exists at a given automount point.  It means I don't need to find out 
> which map is handling a particular automount point, nor do I have to 
> type in the map name, and I get the keys sorted for me.

I'd like to find a simple way to accommodate this while retaining the
multiple map functionality.

Ian

Re: autofsv5 enhancement - map names in /proc/mounts

[Gordon Lack]

Ian Kent wrote:
> 
> I'd like to find a simple way to accommodate this while retaining the
> multiple map functionality.

    Fine by me.  Bear in mind that the map-name (the bit I'm suggesting 
should be added to /proc/mounts) will be different.  eg: from your 
original example:

  /home	/etc/auto.server1.home
  /home	/etc/auto.server2.home

So we'd end up with 2 lines in /proc/mounts:

  /etc/auto.server1.home /home autofs ....
  /etc/auto.server2.home /home autofs ....

(I think...although whether the patch I sent is sufficient to achieve 
that I don't know)

Re: autofsv5 enhancement - map names in /proc/mounts

[Ian Kent]

On Tue, 2006-11-14 at 10:00 +0000, Gordon Lack wrote:
> Ian Kent wrote:
> > 
> > I'd like to find a simple way to accommodate this while retaining the
> > multiple map functionality.
> 
>     Fine by me.  Bear in mind that the map-name (the bit I'm suggesting 
> should be added to /proc/mounts) will be different.  eg: from your 
> original example:
> 
>   /home	/etc/auto.server1.home
>   /home	/etc/auto.server2.home
> 
> So we'd end up with 2 lines in /proc/mounts:
> 
>   /etc/auto.server1.home /home autofs ....
>   /etc/auto.server2.home /home autofs ....

We would need to do something different as there will only ever be one
mount and so only one line in /proc/mounts.

Perhaps something like:

/etc/auto.server1.home,/etc/auto.server2.home	/home	autofs ....

and that could be further simplified by using nsswitch with "files" as a
source (you know they will be in /etc if not otherwise specified):

auto.server1.home,auto.server2.home	/home	autofs ....

> 
> (I think...although whether the patch I sent is sufficient to achieve 
> that I don't know)
> 

Well no, but it's fairly straight forward.

Ian