Created attachment 1080131 [details] LDIF for automount to test with Description of problem: using $USER in automountKey values does not expand on target system, and literal path of $USER is created Version-Release number of selected component (if applicable): autofs-5.1.0-12.fc22.x86_64 How reproducible: very Steps to Reproduce: 1. load automountMap schema into LDAP 2. populate LDAP with automountMapName and automountKey entries and values 3. use autofs via LDAP (or SSSD pointed to LDAP) to mount NFS shares (automount -dfvvv) 4. find $USER references in output and in filesystem Actual results: mountpoints for expanded variable do not exist Expected results: mountpoints for expanded variable should exist Additional info: attached LDIF includes automountMapName and automountKey entries and values that work (auto.shares, auto.direct) as well as entries and values that dont work (auto.indirect)
I'm afraid I'm struggling to work out what it is your trying to say here. The ldap ldif you've provided looks like it has a number of entries that are invalid for a couple of different reasons so maybe you should start by describing what you're trying to achieve and how you expect this to function. Basically, I think you've made a number of assumptions that aren't right. Ian
the ldif provided is intended to provide working and non-working mappings. by simply changing a few minor details, i am able to demonstrate the variable expansion issue or have my automounts work. the desired result is to have automount mappings use variables such as $USER, so that /home/user1/Music, or /home/user2/Music for example is mounted without having to be hardcoded or a direct mapping. i intend on having the $USER variable expanded so the mapping correlates to the value of the variable, and is not taken literally.
(In reply to bpk678 from comment #2) > the ldif provided is intended to provide working and non-working mappings. > by simply changing a few minor details, i am able to demonstrate the > variable expansion issue or have my automounts work. > > the desired result is to have automount mappings use variables such as > $USER, so that /home/user1/Music, or /home/user2/Music for example is > mounted without having to be hardcoded or a direct mapping. i intend on > having the $USER variable expanded so the mapping correlates to the value of > the variable, and is not taken literally. That's one of the problems with the ldif. It's not possible to use variables in the key and never has been. It doesn't make sense to use this in indirect maps as this is meant to done using the standard wildcard substitution. For example an indirect map that provides /home/$USER mount points would have a master map entry like (and as this is an example you will need to translate it ldap, where the wildcard is usually / not *, although IIRC * should work too, not sure): /home /etc/auto.home and /etc/auto.home would have: * server:/path/& where & requests the key that has matched the wildcard be used as its replacement. Ian
your example does not make sense. * and & refer to each other, per the man page. if you wildcard the key with a *, and use & in the location, then both are substituted with the same value. i dont see how this relates to what i am trying to accomplish. moreover, the man page explicitly indicates that variable substitution works in both the key and location fields. the $USER variable is expected to expand based on the user requesting the mount when used in either the key or the location field, when it does not actually do so. i dont want to mount a users home dir with this configuration. i want to mount a directory under a users home dir, regardless of anything to do with where or how the users home dir is mounted, etc.
(In reply to bpk678 from comment #4) > your example does not make sense. * and & refer to each other, per the man > page. if you wildcard the key with a *, and use & in the location, then > both are substituted with the same value. i dont see how this relates to > what i am trying to accomplish. Then I don't understand what it is your trying to accomplish. You can use the macros in the location field, just not the key field. The keys of an indirect map are a single directory component, not absolute or relative paths. If you use the multi-mount syntax you can do things like: * / server:/path/& \ /Music server:/path/&/Music /${other} server2:/other/${other_val} and the offsets under the root offset ("/") would be mounted on access. > > moreover, the man page explicitly indicates that variable substitution works > in both the key and location fields. the $USER variable is expected to > expand based on the user requesting the mount when used in either the key or > the location field, when it does not actually do so. The man page of F22 doesn't say that, it says: Variable Substitution The following special variables will be substituted in the location field of an auto‐mounter map entry if prefixed with $ as customary from shell scripts (curly braces can be used to separate the field name): ARCH Architecture (uname -m) CPU Processor Type HOST Hostname (uname -n) OSNAME Operating System (uname -s) OSREL Release of OS (uname -r) OSVERS Version of OS (uname -v) autofs provides additional variables that are set based on the user requesting the mount: USER The user login name UID The user login ID GROUP The user group name GID The user group ID HOME The user home directory SHOST Short hostname (domain part removed if present) Additional entries can be defined with the -Dvariable=Value map-option to automount(8). Map entries consist of <key, location> pairs so that says that macro translation will be done only on the location field and not the key field. The problem with using map keys with macro substitution in indirect mount maps is that to do it the entire map would need to be scanned for every lookup and each key checked to see if it's a macro then translated if it is before attempting to match the key to the requested mount. Scanning the entire map is a performance killer for maps that have a large number of keys and can be a problem or maps with even a relatively small number of entries if there are frequent lookups. For direct mount maps the keys are absolute paths and each key in a direct map must be mounted as an automount trigger before any mount requests are received. That means that direct map keys could not have macros that don't have a known value at the time the trigger is mounted. Given that the user id that is making the mount request is set at the time the trigger mount is accessed it's not possible for autofs to know how to translate $USER in these keys when the trigger mount is mounted. > > i dont want to mount a users home dir with this configuration. i want to > mount a directory under a users home dir, regardless of anything to do with > where or how the users home dir is mounted, etc. Perhaps you should consider using amd. You would need to build it yourself on the target machine to enable the regular expression key matching feature as it too comes with warnings about requiring full map scans on every lookup. But it might do what you require. Ian
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.