Bug 1509043
| Summary: | [RFE] "automount / amd: file system type program is not yet implemented" (Implement AMD program maps | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Frank Hirtz <fhirtz> |
| Component: | autofs | Assignee: | Ian Kent <ikent> |
| Status: | CLOSED ERRATA | QA Contact: | xiaoli feng <xifeng> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | dwysocha, fhirtz, ikent, rhandlin, swhiteho, xifeng, xzhou |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | autofs-5.0.7-83.el7 | Doc Type: | Enhancement |
| Doc Text: |
Feature: The am-utils amd program provides a mount type of program (ie. map entry option "type:=program") so that special types of mounts may be done using a user specified program for mounts that aren't possible using the standard mount types.
Reason: This was difficult to do during the initial amd format map implementation within autofs and was deferred to be implemented once the initial implementation had stabilized, and to be done only if it was needed by customers.
Result: This RFE shows that this amd map feature is needed by customers so it has been implemented. It is now possible to use the mount type program in amd format maps with autofs in the same way this is provided by the amd program.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 18:17:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
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 |
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