Bug 1269017 - variable expansion does not occur
variable expansion does not occur
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
22
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-05 21:59 EDT by bpk678
Modified: 2016-07-19 16:14 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 16:14:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
LDIF for automount to test with (5.25 KB, text/plain)
2015-10-05 21:59 EDT, bpk678
no flags Details

  None (edit)
Description bpk678 2015-10-05 21:59:13 EDT
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)
Comment 1 Ian Kent 2015-10-06 03:07:08 EDT
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
Comment 2 bpk678 2015-10-06 07:31:51 EDT
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.
Comment 3 Ian Kent 2015-10-06 09:03:30 EDT
(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
Comment 4 bpk678 2015-10-11 10:43:26 EDT
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.
Comment 5 Ian Kent 2015-10-11 20:24:18 EDT
(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
Comment 6 Fedora End Of Life 2016-07-19 16:14:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.