Bug 322731

+++ This bug was initially created as a clone of Bug #253870 +++

Escalated to Bugzilla from IssueTracker

-- Additional comment from tao on 2007-08-22 10:43 EST --
Description of problem:
Some of our automount maps contain the $NATISA variable.  On Solaris, this is
filled in with 'isainfo -n'.  On 64-bit RHEL3 and RHEL4, we edit
/etc/sysconfig/autofs and set
   LOCALOPTIONS="-DOSREL=rhel_4.0 -DNATISA=x86_64"
For 32-bit systems, we just leave it blank, i.e., we set
   LOCALOPTIONS="-DOSREL=rhel_4.0"

With 32-bit RHEL5 and the new automounter, this no longer works.  We have to
manually define the $NATISA variable to nothing.  That is, we edit
/etc/sysconfig/autofs and set
   OPTIONS="-DOSREL=rhel_5.0 -DNATISA="

Maybe RHEL3 and RHEL4 were the buggy ones and we should never have relied on
undefined variables.  If the new RHEL5 automounter is doing the right thing with
respect to undefined variables, then please document what the expected behavior
is in the man pages.

How reproducible:
Every time.

Steps to Reproduce:
1. Create an auto.misc map entry like
     foo server:/some/path/$NATISA
   but do NOT define $NATISA and do not create any special
   directories under /some/path.
2. Try to access /misc/foo and it will fail.
     $ cd /misc/foo
     -bash: cd: /misc/foo: No such file or directory
3. Restart the automounter with '-DNATISA=' and it will
   work.

Actual results:
Received an error if trying to access an automounted directory with undefined
variables.

Expected results:
Variable should be replaced by nothing.

Additional info:

This event sent from IssueTracker by jnansi  [Support Engineering Group]
 issue 126762

-- Additional comment from jnansi on 2007-08-22 10:59 EST --
This got escalated early, working on this myself.

-- Additional comment from tao on 2007-08-22 11:08 EST --
OK, so this can be taken as a request to document that all variables need
to be defined.


This event sent from IssueTracker by jnansi 
 issue 126762

-- Additional comment from pm-rhel on 2007-08-22 11:16 EST --
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

-- Additional comment from ikent on 2007-08-22 11:19 EST --
(In reply to comment #1)
> Description of problem:
> Some of our automount maps contain the $NATISA variable.  On Solaris, this is
filled in with 'isainfo -n'.  On 64-bit RHEL3 and RHEL4, we edit
/etc/sysconfig/autofs and set
>    LOCALOPTIONS="-DOSREL=rhel_4.0 -DNATISA=x86_64"
> For 32-bit systems, we just leave it blank, i.e., we set
>    LOCALOPTIONS="-DOSREL=rhel_4.0"
> 
> With 32-bit RHEL5 and the new automounter, this no longer works.  We have to
manually define the $NATISA variable to nothing.  That is, we edit
/etc/sysconfig/autofs and set
>    OPTIONS="-DOSREL=rhel_5.0 -DNATISA="
> 
> Maybe RHEL3 and RHEL4 were the buggy ones and we should never have relied on
undefined variables.  If the new RHEL5 automounter is doing the right thing with
respect to undefined variables, then please document what the expected behavior
is in the man pages.

No, I think we should cope with undefined variables.
Sounds like a bug to me.

> 
> How reproducible:
> Every time.
> 
> Steps to Reproduce:
> 1. Create an auto.misc map entry like
>      foo server:/some/path/$NATISA
>    but do NOT define $NATISA and do not create any special
>    directories under /some/path.
> 2. Try to access /misc/foo and it will fail.
>      $ cd /misc/foo
>      -bash: cd: /misc/foo: No such file or directory
> 3. Restart the automounter with '-DNATISA=' and it will
>    work.
> 
> Actual results:
> Received an error if trying to access an automounted directory with undefined
variables.
> 
> Expected results:
> Variable should be replaced by nothing.

Yep, I'll reproduce and check what's going on.

Ian


-- Additional comment from ikent on 2007-08-22 11:46 EST --
Created an attachment (id=162070)
Patch to ignore undefined macros

Please test this patch.

In v5 there is a deliberate fail return and this
patch reverts this to the v4 behavior. There may
be questions regarding how this should be handled
at some point in the future but for now I want the
same semantics as v4.

Ian

-- Additional comment from ikent on 2007-10-02 03:33 EST --
Has this been tested?
Is there anything I need to do to facilitate
the testing?


-- Additional comment from jnansi on 2007-10-05 03:59 EST --
Sorry for the delay, I will get the patch tested asap.