On Wed, 2019-01-30 at 11:20 +0100, Frank Thommen wrote: > > On 1/30/19 2:42 AM, Ian Kent wrote: > > On Tue, 2019-01-29 at 17:04 +0100, Frank Thommen wrote: > > > Dear all, > > > > > > we mount our homedirectories with wildcard mounts from /etc/auto.home: > > > > > > ------------- > > > * -fstype=nfs,vers=4.0,sec=sys server:/export/home/& > > > ------------- > > > > > > unfortunately due to this > > > [https://bugzilla.redhat.com/show_bug.cgi?id=1437754] issue and badly > > > programmed software, there are too many error messages related to failed > > > mount requests (/home/.hidden, /home/images, /home/srv ecc. ecc.) in the > > > server logs. > > > > I'm aware of this, on the cc of the bug. > > > > > > > > Is there a way to exclude specific keys from the wildcard list? I tried > > > > > > ------------- > > > .hidden :/dev/null > > > src :/dev/null > > > * -fstype=nfs,vers=4.0,sec=sys server:/export/home/& > > > ------------- > > > > > > but that generated too many errors on the client side. I wonder if > > > there is an "official" way to exclude such invalid entries. > > > > There's not, the wildcard key match has always matched anything. > > > > A blacklist implementation would still need some way to specify > > its use on the master map entry and that would be non-standard > > and lead to parse failures on non-Linux platforms and older > > versions of autofs. > > > > And a global blacklist I think would prove to be too general > > leading to false positives. > > I agree > > > > But your suggestion has merit. > > > > I could treat /dev/null local mounts (ie. : escaped ones) as > > no-op mounts and just return success without performing the > > mount. I don't recall any cases where /dev/null can be used in > > an actual mount and the colon escaped location significantly > > restricts possible cases that I'm not aware of. > > > > That wouldn't require syntax that would break existing configs and > > would simply continue to generate errors for older version of autofs > > and non-Linux clients. > > > > But it would mean the exclusions would need to be listed manually > > within the each map although I think the specific case we are > > talking about should only need several commonly use key names that > > form the bulk of the noise. > > > > This would need to be accompanied by a configuration option to > > make it an optional buy-in and it would need to be set to no by > > default to maintain the existing behaviour. > > > > Wouldn't that help your case? > > Would it be sufficient (although I'm not sure we have any other > > options)? > > absolutely yes and absolutely yes ;-) > > > > Does anyone else have any thoughts or suggestions? > > > what about a special automounter option -ignore or -fstype=ignore: I'm not sure about these suggestions. I agree that using /dev/null offends the sensibility of the map syntax and the idea of using either of these suggestions is better from that POV. But the map entry parser has not been converted to use a yacc based parser (mainly because the Sun map format is ambiguous making that conversion rather difficult) so map entry parsing remains somewhat spread throughout the code so map entry syntax changes are a bit difficult and risky. Using an option like -ignore means special case handling of the entry as it doesn't have mount location, only an option and using a special fstype will cause unexpected and unusual error messages for automount versions that don't have the change. Although odd error messages in earlier versions is probably going to happen anyway. So I'm not sure about these. I'll need to think about it for a bit and have a look around. > > ------------- > .hidden -ignore > src -ignore > * -fstype=nfs,vers=4.0,sec=sys server:/export/home/& > ------------- > Ian
