The autofs init script argument parsing algorithm used to fix bug 82086 is too "linux-centric". We use autofs with NIS, and on Solaris platforms -nosuid is a valid argument, for example: /home auto.home -nosuid Unfortunately, the new argument parsing algorithm pulls out each individual letter as an argument, which is causing the 'd' in nosuid to trigger the --debug option. This is resulting in an insane amount of logging when this occurs.
your line in auto.master is wrong. See automount(8). Any remaining command line arguments without leading dashes (-) are taken as options (-o) to mount. Arguments with leading dashes are considered options for the maps. nosuid is a mount parameter, so it should not have a leading dash.
it's not a line in auto.master it's a line in an automount map file loaded in NIS. The syntax is perfectly valid on Solaris as well as HP. As I said, the fix you used is too "linux-centric" especially with regards to maps that are many times loaded from NIS.
fyi, from solaris' automount man page: key [ -mount-options ] location ... Also, I disagree with your interpretation of the automount man page. The automount man page describes the syntax of the arguments to the automount command. As far as I can tell, it does not describe the syntax to the map. The auto.master man page describes the syntax of the master map file. Reading the automount page more thoroughly shows that it supports the sun map format by default (admittedly it takes a subset of the sun map format). The sun map format as documented on Sun's man page is what I posted above.
one more comment. if you read the automount man page, supposedly -strict and -Dwhatever are supported as arguments to the map. If that's the case, and the autofs script is strictly following the construct you described, -strict wouldn't work either. The other confusing thing is this: /usr/sbin/automount --timeout 60 --debug --pid-file /var/run/autofs.home.pid /home yp auto.home -nosuid That's the ps output for the command. -nosuid is being correctly passed as a map argument, yet it's still parsed for automount arguments? There's some inconsistency here.
Any chance we can revisit this ? If you read my past few notes, I believe it can be argued that gentoo is out of spec with how autofs maps are supposed to be read? At the very least, shouldn't this bug be made into an enhancement rather than resolved as invalid? Or are you trying to say it's invalid to expect gentoo to be able to co-exist in heterogenous environments?
I don't understand why this was closed as "resolved invalid", unless the point is that Gentoo's autofs supports only Gentoo-dialected mount points... I haven't read the specs, I don't understand the issues, but I do know the following: o IT (at my company) has, for years now, used "-nosuid" on certain mount points o -nosuid is acceptable for Unix and non-Gentoo linux distributions o Suddenly, I'm looking at multi-gigabyte log files because Gentoo has decided to treat "-nosuid" as "-n -o -s -u -i -d", has chosen to ignore arguments it doesn't understand, and has chosen to treat "-d" as being "--debug" o Given as I don't like multi-gigabyte log files, I commented out "-d|--debug) opt_debug="--debug" ; shift ;;" Mind you, I don't mind commenting out the line. But why close it as INVALID?
re-opening for additional consideration based on info I've provided.
I too am dealing with a building-wide setup that's worked for more than a decade, containing things in the maps like: rfaustin -nosuid,intr cragganmore:/volume1/users/students/& * -nosuid,intr lesse:/volumeC/students/& I'm having other problems with the autofs-initscript as well, but I'll put it in another bug-report as I'm not sure it's related...
New maintainer, net-fs/autofs-5.0.3-r1 is now in the tree.
At least on my system this doesn't seem to give any problems anymore with autofs-5, but this could also be caused by a change in the maps (which are not mine to edit). Please test autofs-5, any feedback is appreciated. (If there's a compelling reason to review this for autofs-4, please also let me know)
No feedback in well over a month, closing bug.
