Bug 214800

(In reply to comment #0)
> We need a possibility to disable a auto-mount-map. In solaris this is possible
> with the -null option:
> -------------------------------
> /etc/auto.master
>   /usr/local     -null
> ------------------------------------

Sure.
There's been a fair bit of debate about how this is
actually suposed to work, during development of autofs
v5. Even if I got that right my implementation is likely
flawed.

So how do you think the option is suposed to behave?

Ian

(In reply to comment #1)
> (In reply to comment #0)
> > We need a possibility to disable a auto-mount-map. In solaris this is possible
> > with the -null option:
> > -------------------------------
> > /etc/auto.master
> >   /usr/local     -null
> > ------------------------------------
> 
> Sure.
> There's been a fair bit of debate about how this is
> actually suposed to work, during development of autofs
> v5. Even if I got that right my implementation is likely
> flawed.
> 
> So how do you think the option is suposed to behave?

And how about a debug log also.
Setup syslog to send daemon.* to somewhere useful and
set DEFAULT_LOGGING="debug" in /etc/sysconfig/autofs and
restart autofs.

Ian

Created attachment 140795 [details]
patched autofs startup scripts

our patched autofs scripts for fc5 and RHEL4

I have attached our changed autofs startup-scripts for fc5 and RHEL4.
We use them, because we have a nis automap for solaris-clients:
ypcat -k auto.app
* edeacna002:/vol/vol0204/unix-app/$CPU$OSNAME/$OSREL/app/&
but on linux we use /app as link to an afs-path.
Maybe the scripts give you an idea.
But in fc6 all the things are moved to the binary, so we have no chance to use
our solution.

(In reply to comment #4)
> I have attached our changed autofs startup-scripts for fc5 and RHEL4.
> We use them, because we have a nis automap for solaris-clients:
> ypcat -k auto.app
> * edeacna002:/vol/vol0204/unix-app/$CPU$OSNAME/$OSREL/app/&
> but on linux we use /app as link to an afs-path.
> Maybe the scripts give you an idea.
> But in fc6 all the things are moved to the binary, so we have no chance to use
> our solution.

You didn't answer the question or include a debug log.
And I'm well aware of the implementation in v5, I wrote it (or
maybe I shouldn't admit that, oops).

If it needs fixing then please provide approiate information
as requested.

A quick test shows that the "-null" map option functions almost
how I expect it to. So I need to do a litle work on it but the
resulting behaviour pretty much what I expect. I still don't
actually know what problem you are seeing? Can you be a little
more specific.

Ian

(In reply to comment #3)
> Created an attachment (id=140795) [edit]
> patched autofs startup scripts
> 
> our patched autofs scripts for fc5 and RHEL4

If you going to send things like this then send diffs.

I have got no hope of being sure what changes you have
made within the, nearly 700 lines, of the init script.

Ian

Ok,
here is the diff for RHES4: autofs-4.1.3-187
diff autofs /etc/init.d/autofs
192a193,195
>           # [CHANGED]
>           [ -n "$dir" ] || continue
> 
224c227,232
<           if [ ! -z "$dir" -a ! -z "$map" \
---
>           # [CHANGED]
>           knownmaps=" $dir/ $knownmaps"
> 
>           # [CHANGED]
>           #if [ ! -z "$dir" -a ! -z "$map" \
>           if [ -n "$map" \
340c348,349
<           knownmaps=" $dir/ $knownmaps"
---
>           # [CHANGED]
>           #knownmaps=" $dir/ $knownmaps"

ypcat -k auto.app
* edeacna002:/vol/vol0204/unix-app/$CPU$OSNAME/$OSREL/app/&

cat /etc/auto.master
#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/misc  /etc/auto.misc
#/net   /etc/auto.net
/app    -null
------------------------------------------------
So now the problems on fc6:
We have a nis-map for direct mountpoints:
[root@euregio35 ~]# ypcat -k auto.direct
/usr/local -noquota     edeacna002:/vol/vol0204/unix-group/usr/local
/opt/local -noquota     edeacna002:/vol/vol0204/unix-group/opt/local

But /usr/local/should not be mounted via automounter on linux-clients, only on
solaris.
Here is the ouput from df when autofs is disabled:
[root@euregio35 ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       7935392   4543048   2982744  61% /
/dev/sda1               101086     11037     84830  12% /boot
tmpfs                   253472         0    253472   0% /dev/shm
/dev/mapper/VolGroup00-LogVol03
                      28091124    209468  26431672   1% /export
/dev/mapper/VolGroup00-LogVol02
                       1015704    175016    788260  19% /usr/local
edeacna002:/vol/vol0204/unix-group/usr/local/etc/dotfiles
                     610271232 341310528 268960704  56% /usr/local/etc/dotfiles

Now I start autofs:
[root@euregio35 ~]# /etc/init.d/autofs start
Starting automount:                                        [  OK  ]
[root@euregio35 ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       7935392   4543096   2982696  61% /
/dev/sda1               101086     11037     84830  12% /boot
tmpfs                   253472         0    253472   0% /dev/shm
/dev/mapper/VolGroup00-LogVol03
                      28091124    209468  26431672   1% /export

As you can see, /usr/local and /usr/locakl/etc/dotfiles is umounted.
Now I make a cd to /usr/local:
[root@euregio35 usr]# cd /usr/local
[root@euregio35 local]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       7935392   4543100   2982692  61% /
/dev/sda1               101086     11037     84830  12% /boot
tmpfs                   253472         0    253472   0% /dev/shm
/dev/mapper/VolGroup00-LogVol03
                      28091124    209468  26431672   1% /export
edeacna002:/vol/vol0204/unix-group/usr/local
                     610271232 341311296 268959936  56% /usr/local

/usr/local is now mounted viw autofs 
here is my /etc/auto.master
[root@euregio35 local]# cat /etc/auto.master
#
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
/misc   /etc/auto.misc
/net    -hosts
/usr/local      -null
/app            -null
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

I have enable debuging, the log-file was zero before I start the autofs.
I will attach the log-file now.

Hope that this info is useful.

Created attachment 140833 [details]
logfile for debug of autofs

(In reply to comment #7)
> Ok,

Thanks Ralf.

snip ..

> I have enable debuging, the log-file was zero before I start the autofs.
> I will attach the log-file now.
> 
> Hope that this info is useful.

This is much more helpful.

But nevertheless this brings us back to the question of how
the "-null" map option should work.

The Solaris description of how this is supposed to work is
unclear at best. In our case here I believe that your
/etc/nsswitch.conf file will have the "files" source before
the "nis" source. This has the effect of reading the file
entry for the map and nulling any previous map info and
then carrying on to read the "nis" map. So changing the
"automount:" line in nsswitch.conf to use "nis" before
"files" should have the desired affect, as the nis map will
then be nulled by your local file map. If you use this
feature on any Solaris machines I'd be interested to know
what the nsswitch settings are on them.

Ian

rule #1:

mountpoint -null

(always in auto.master map!)
means: mountpoint should be ignored.

mountpoint can be an indirect map in the auto.master, or an entry in a direct 
map.

rule #2:

if mountpoint is defined twice, the first definition (regular or -null) 
applies. The second definition is ignored.
The Solaris man page indicates that even for "nis files" the -null 
in /etc/auto.master would inhibit a setting in NIS. I think this is not 
necessarily true, but definitely for the order "files nis".

Example of a typical use of -null,
just tested on a Solaris client:

NIS auto.master defines a NIS auto.direct map, and the NIS auto.direct map 
defines /usr/local on NFS.
On the client /etc/nsswitch.conf sais:
automount: files nis
If /etc/auto.master has
/usr/local -null
this inhibits the NIS auto.direct setting.
If /etc/auto.master has
/usr/local -null
+auto_master
it still inhibits the NIS auto.direct setting, but
+auto_master
/usr/local -null
will apply the NIS auto.direct setting.

There should also no umount of /usr/local because it is already mounted.
There should be a message /usr/local is busy. This was the behavier in the past.

(In reply to comment #10)

This is very similar to one of the interpretations of the
Solaris man page and seems to be the way most people think
it works and as you demonstarate also appears to be how
it's implemented. So I'll go along with it.

Unfortuneately, what I have at the moment is quite different
and I didn't get the direct mount functionality at all from
the man pages when I read them.

So I'm going to need some time to think about what I need to
change in order to reimplement and a little more time to
do the work.

Sorry.

> rule #1:
> 
> mountpoint -null
> 
> (always in auto.master map!)
> means: mountpoint should be ignored.
> 
> mountpoint can be an indirect map in the auto.master, or an entry in a direct 
> map.
> 
> rule #2:
> 
> if mountpoint is defined twice, the first definition (regular or -null) 
> applies. The second definition is ignored.

And what is the status of a third and subsequent entries, of course
for the case where they correspond to an actual map?

> The Solaris man page indicates that even for "nis files" the -null 
> in /etc/auto.master would inhibit a setting in NIS. I think this is not 
> necessarily true, but definitely for the order "files nis".

Agreed, this is my interpretation of this approach also and is
the way it will be implemented.

> 
> Example of a typical use of -null,
> just tested on a Solaris client:
> 
> NIS auto.master defines a NIS auto.direct map, and the NIS auto.direct map 
> defines /usr/local on NFS.
> On the client /etc/nsswitch.conf sais:
> automount: files nis
> If /etc/auto.master has
> /usr/local -null
> this inhibits the NIS auto.direct setting.
> If /etc/auto.master has
> /usr/local -null
> +auto_master
> it still inhibits the NIS auto.direct setting, but
> +auto_master
> /usr/local -null
> will apply the NIS auto.direct setting.
> 

So, just so I'm completely clear on this, the heart of the
way "-null" maps should work is that any map or direct mount
point that follows a "-null" entry for that mount point must
be ignored.

Ian

> And what is the status of a third and subsequent entries, of course
for the case where they correspond to an actual map?
Every time the first should take affect.
>So, just so I'm completely clear on this, the heart of the
way "-null" maps should work is that any map or direct mount
point that follows a "-null" entry for that mount point must
be ignored.
Yes

Is it possible to have this behavier also for RHEL and fc5?
Another question: In fc5 you see a nice output via /etc/init.d/autofs status
In fc6 there is only the message if autofs is running. Is it possible to have 
some more info like in the past?

(In reply to comment #13)
> > And what is the status of a third and subsequent entries, of course
> for the case where they correspond to an actual map?
> Every time the first should take affect.
> >So, just so I'm completely clear on this, the heart of the
> way "-null" maps should work is that any map or direct mount
> point that follows a "-null" entry for that mount point must
> be ignored.
> Yes

OK.
I finally actually installed Solaris on the weekend and
got the goods on the Solaris behavior and it's pretty much
what we've discussed.

> 
> Is it possible to have this behavier also for RHEL and fc5?

We've (mainly Jeff Moyer and myself) managed to showhorn
a number of missing features into version 4 over time
but, to put it simply, version 5 is the only version that
will be able to do direct mounts properly. So I have to
recommend you look to version 5 to get "drop in" site
functionality.

The only real requirement to run v5 is 2.6.17 or above
although there are several bug fix kernel kernel patches
making their way through the upstream system now. 2.6.19
should have most if not all of them. So FC5 will be (is)
capable of running v5 now.

As far as RHEL is concerned we are working on a backport
of the kernel patches for RHEL4 and that is about to enter
a test phase now. It's not really practicle to backport
the kernel changes to a 2.4 kernel because v5 relies on
some other features only available in 2.6. So RHEL3 is
unlikely to be able to run v5.

> Another question: In fc5 you see a nice output via /etc/init.d/autofs status
> In fc6 there is only the message if autofs is running. Is it possible to have 
> some more info like in the past?

Ya. I know. I knew people would ask for that but I think it
may be difficult to do for v5 so that won't appear in the
first v5 release. I've got my hands full stabilizing the new
stuff in v5 for the moment. It would be good to have though.

Mind you it should be fairly straight forward to write a
perl script to scan /proc/mounts and auto.master and report
most of the information.

I have a first cut patch for the "-null" handling.
I haven't been able to test it much yet but are you
interested in trying it out.

Ian

* For fc5 and RHEL4 we need only the -null feature for inderict-mounts, we have 
disabled direct-mounts on those plattforms.
* A perl-scripts is a good idea, then you should integrate it in start-script 
with an option like status or so.
* Yes, I can try out your updated autofs. Give me a link for the package, 
please.

(In reply to comment #15)
> * For fc5 and RHEL4 we need only the -null feature for inderict-mounts, we have 
> disabled direct-mounts on those plattforms.

I thought we had something in the init script for this already
in v4. If not we can consider adding your patch.

> * A perl-scripts is a good idea, then you should integrate it in start-script 
> with an option like status or so.

I'll see how my time goes.
I've got some urgent, overdue and important things
I realy have to focus on at the moment.

> * Yes, I can try out your updated autofs. Give me a link for the package, 
> please.

I haven't added the patch patch to the Rawhide package yet or
uploaded it to kernel.org. I need to test it some more before
I do that.

But if you could add the patch to autofs-5.0.1-0.rc2.23 from
Rawhide if you have time. I'll post it here.

Ian

Created attachment 141042 [details]
First cut at fixing the "-null" map handling in autofs version 5, please test

Almost certainly needs to be applied to
autofs-5.0.1-0.rc2.23 currently available on the
Rawhide mirrors.

>I thought we had something in the init script for this already
in v4. If not we can consider adding your patch.
Yes, but it dosn'work. That's the reason why we change it.
But we have to change it everytime a new package will come for autofs.
Please test our patch, maybe it will help you to get it running.

I will test autofs-5.0.1-0.rc2.23 

(In reply to comment #18)
> >I thought we had something in the init script for this already
> in v4. If not we can consider adding your patch.
> Yes, but it dosn'work. That's the reason why we change it.
> But we have to change it everytime a new package will come for autofs.
> Please test our patch, maybe it will help you to get it running.
> 

Understood.
Will check it out.

Ian

(In reply to comment #14)
> (In reply to comment #13)

> > Another question: In fc5 you see a nice output via /etc/init.d/autofs status
> > In fc6 there is only the message if autofs is running. Is it possible to have 
> > some more info like in the past?

First off, please debate only ONE problem per bugzilla.  Otherwise, the waters
get quite muddied and we can't track the closure of each individual request. 
Please use this bugzilla henceforth to address *only* the -null map handling. 
If you are interested in the "status" feature, then file an RFE.

> Ya. I know. I knew people would ask for that but I think it
> may be difficult to do for v5 so that won't appear in the
> first v5 release. I've got my hands full stabilizing the new
> stuff in v5 for the moment. It would be good to have though.
> 
> Mind you it should be fairly straight forward to write a
> perl script to scan /proc/mounts and auto.master and report
> most of the information.

This I am almost certainly against.  We finally got rid of split logic between
the init script and the daemon, why reintroduce it?  This can only lead to problems.

My applogies for not getting onto checking you patch
for RHEL4 as you requested.

I see you have logged a seperate bug (228502) regarding
this issue which is probavly what I should have recommended
as well. You also mentioned that this is functioning in ok
in FC6, so I'll close this now.

Once again sorry for the inconvience.

Ian