Description of problem: We use linux and solaris boxes in our NIS-env. The NIS-servers are solaris and for the workstation we have created a direct-map for /usr/local in NIS. Since we have upgraded a linux-box with fc6 we have a problem with this setup. In fc5 we could disbale the direct-feature in /etc/sysconfig/autofs, and we could also modify the start-script. Now in fc6 all features have moved in the autofs-binary. 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 ------------------------------------ We also need this feature for another indirect mount: /app On linux this should be a link to an afs-path, in solaris it is a normal nfs-point mounted via automounter. But that dosn't work in fedora. Version-Release number of selected component (if applicable): latest autofs rpm How reproducible: everytime Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(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