Red Hat Bugzilla – Bug 1509043
[RFE] "automount / amd: file system type program is not yet implemented" (Implement AMD program maps
Last modified: 2018-04-10 14:18:00 EDT
Created attachment 1347101 [details] Example map setup Description of problem: Currently, the AMD map parser for autofs doesn't handle program maps and we'd like to request that "type:=program" be implemented/ This is a simple example that we'd like to work: - /etc/auto.master.d/amd.autofs contains /amd file,amd:/etc/amd.map - /etc/amd.map contains linux1 sublink:=linux;rhost:=host5;rfs:=/d/d2 linux2 type:=program;mount:="/usr/local/sbin/program.sh ${rhost} ${opts} ${rfs} ${fs}";opts:=ro;rhost:=host5;rfs:=/d/d1/linux /amd/linux1 is mounted regularly but /amd/linux2 reports that "file system type program is not yet implemented" (if it worked, it would call that external program with appropriate parameters to perform the mount) <snip> Version-Release number of selected component (if applicable): autofs-5.0.7-69.el7.x86_64
Attached is an extract (and edited) version of some config and maps of amd that we'd like to be able to use via autofs. /etc/amd.conf: defines two mount points /u and /v for which there are two separate maps /etc/amd.map: defines /u mount points and: - /u/ammlinux works correctly - /u/ammprod doesn't work (it's the "link" problem logged in 01937545) /etc/maps/toplvl.map: defines submaps (in other files) and: /etc/maps/global.map: - /v/global/user/m/ma/macchia works correctly - /v/campus/ln/appl/abc/v1/data/abcdefghij doesn't work (it's the "program" problem described in this ticket) You will notice that "program" entry calls "${nfs4mount}" that is a variable defined in /etc/sysconfig/amd. This is a relatively simple script that invokes a mount for nfs4 with the parameters that are provided by amd.
Created attachment 1350301 [details] Patch - improve debug logging of lookup key Series 1 - bug fixes
Created attachment 1350302 [details] Patch - fix cachefs parse message not being logged Series 1 - bug fixes
Created attachment 1350303 [details] Patch - fix typo in amd_parse.c Series 1 - bug fixes
Created attachment 1350304 [details] Patch - add missing MODPREFIX to logging in amd parser Series 1 - bug fixes
Created attachment 1350305 [details] Patch - fix symlink false negative in umount_multi() Series 1 - bug fixes
Created attachment 1350306 [details] Patch - remove expand_selectors() call on amd parser entry Series 2 - fix "cannot mount or symlink <path> to itself"
Created attachment 1350307 [details] Patch - fix amd defaults map entry handling Series 2 - fix "cannot mount or symlink <path> to itself"
Created attachment 1350309 [details] Patch - refactor amd_parse.c Series 3 - add support for mount type program
Created attachment 1350310 [details] Patch - fix amd parser double quote handling Series 3 - add support for amd mount type program
Created attachment 1350311 [details] Patch - fix expandamdent() quote handling Series 3 - add support for amd mount type prograam
Created attachment 1350312 [details] Patch - fix possible memory leak during amd parse Series 3 - add support for amd mount type program
Created attachment 1350313 [details] Patch - remove path restriction of amd external mount Series 3 - add support for amd mount type program
Created attachment 1350314 [details] Patch - add function umount_amd_ext_mount() Series 3 - add support for amd mount type program
Created attachment 1350316 [details] Patch - add function ext_mount_inuse() Series 3 - add support for amd mount type program
Created attachment 1350317 [details] Patch - add function construct_argv() Series 3 - add support for amd mount type program
Created attachment 1350318 [details] Patch - add amd mount type program mount support Series 3 - add support for amd mount type program
A test package with the above changes is available at: http://people.redhat.com/~ikent/autofs-5.0.7-77.bz1509043.1.el7/ For me it resolves the macro translation problem that caused the "cannot mount or symlink <path> to itself" problem. The the mount type program implementation also seems to work ok. I've done only limited testing so lets see how it goes. Ian
Created attachment 1365809 [details] Patch - fix memory leak in umount_amd_ext_mount() Coverity identified fix.
Created attachment 1365810 [details] Patch - fix strerror_r() parameter declaration in do program_mount() Coverity identified fix.
Created attachment 1365811 [details] Patch - fix incorrect check in validate_program_options() Coverity identified fix.
<item two that they'd noted in testing> I think I might have found a regression problem in the test package that you provided (http://people.redhat.com/~ikent/autofs-5.0.7-77.bz1509043.1.el7/): - the current RHEL 7.4 version of autofs (5.0.7-70.el7_4.1) seems to handle correctly a config like the following: $ grep tmp_ns /etc/auto.master.d/amd.autofs /tmp_ns file,amd:/etc/maps/toplvl.map $ grep -E '^global(/user(/m(/ma(/macchia)?)?)?)?[[:blank:]]' /etc/maps/*.map /etc/maps/toplvl.map:global type:=auto;fs:=${map/}/global.map;pref:=${key}/;opts:=browsable;cache:=all,sync /etc/maps/global.map:global/user type:=auto;fs:=${map};pref:=${key}/;opts:=browsable /etc/maps/global.map:global/user/m type:=auto;fs:=${map};pref:=${key}/;opts:=browsable /etc/maps/global.map:global/user/m/ma type:=auto;fs:=${map};pref:=${key}/;opts:=nobrowsable /etc/maps/global.map:global/user/m/ma/macchia type:=nfs;rhost:=lnn62f2;rfs:=/vol/lnn62f2v20/u_t1446798181;sublink:=macchia $ cd /tmp_amd/global/user/m/ma/macchia [ working as expected ] - but the BZ version (same config as above), can't handle "user" and you get the following error when trying to "cd": $ cd /tmp_amd/global/user/m/ma/macchia -bash: cd: /tmp_amd/global/user/m/ma/macchia: No such file or directory $ tail -f /var/log/messages [...] Jan 23 11:34:39 ferrari3 automount[1047]: key "user" not found in map source(s). Please let me know if you need more info to debug this. Also, I might have found other "incompatibilities" for these amd-compatible maps, but I'll log them in a separate ticket and let you know. </item 2>
Created attachment 1388796 [details] Patch - dont use array for path when not necessary
Created attachment 1388798 [details] Patch - fix prefix option handling in expand_entry()
Created attachment 1388800 [details] Patch - fix sublink option not set from defaults
Created attachment 1388801 [details] Patch - fix error return in do_nfs_mount()
Please give this package a try: http://people.redhat.com/~ikent/autofs-5.0.7-77.bz1509043.4.el7/ Also please set autofs_use_lofs = no in the autofs configuration to get behaviour as close as it can be to amd, described above.
Preliminary feedback: <snip> Hi Frank, it looks like all reported problems are resolved! I'll run some extensive checks tomorrow but definitely all the test cases now work. Thank you, Leonardo. </snip> I'll await followup from the client, but we're looking good. Thanks for the work!
The routine tests for test package in comment 58 is ongoing.
<client feedback update> I've run some tests and all the issues that I presented to you in this ticket (and the other about program mounts) are resolved with autofs-5.0.7-77.bz1509043.4.el7. A couple of points: - our amd maps are quite big and there's a chance I might hit some more incompatibilities in the future, if that's the case I'll open separate tickets - there might be something with nfs4 and Kerberos that is not working as expected (when /etc/krb5.keytab is populated), but I haven't been able to fully understand that problem yet and also I'm not sure it's connected to autofs anyway </feedback> If QA testing doesn't show issues, are we in good shape for 7.5 inclusion?
We're going to need the blocker or exception flag set in order to commit this late bug fix change for the customer reported problem. Steven, who should I contact to ask about this please.
This needs a doc_text!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0977