Bug 197824 - auto.net requires "showmount" but doesn't Require: it
auto.net requires "showmount" but doesn't Require: it
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-06 13:42 EDT by Nalin Dahyabhai
Modified: 2009-06-09 18:44 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-09 18:44:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nalin Dahyabhai 2006-07-06 13:42:24 EDT
Description of problem:
The autofs package defaults to letting automount manage /net, using the auto.net
script as the map.  This script depends on the "showmount" (or "kshowmount"?)
command to work properly, but the autofs package has no explicit dependency on
either the command or a package which provides it.

Version-Release number of selected component (if applicable):
autofs-5.0.0_beta6-2

How reproducible:
Always

Steps to Reproduce:
1. Install autofs.
2. Remove nfs-utils (rpm -e nfs-utils) if you have nfs-utils installed.
3. Restart autofs.
4. Try to use /net.
  
Actual results:
No joy.  Log messages look like:
Jul  6 13:49:59 axe automount[2519]: lookup_mount: >> /etc/auto.net: line 40:
--no-headers: command not found
Jul  6 13:49:59 axe automount[2519]: lookup_mount: lookup(program): lookup for
qafiler failed
Jul  6 13:49:59 axe automount[2519]: lookup_mount: >> /etc/auto.net: line 40:
--no-headers: command not found
Jul  6 13:49:59 axe automount[2519]: lookup_mount: lookup(program): lookup for
qafiler failed

Expected results:
Step 2 fails due to a dependency error.
Comment 1 Jeffrey Moyer 2006-07-06 13:52:12 EDT
Technically speaking, autofs can operate without NFS.  The auto.net script is
also going the way of the dodo.  So, I'm on the fence on this one.  We could
Require nfs-utils, and that would be right for most everyone.

Ian, what do you think?

p.s. Nalin, try using "-hosts" as the map name for your /net mount.
Comment 2 Ian Kent 2006-07-06 22:17:46 EDT
(In reply to comment #1)
> Technically speaking, autofs can operate without NFS.  The auto.net script is
> also going the way of the dodo.  So, I'm on the fence on this one.  We could
> Require nfs-utils, and that would be right for most everyone.
> 
> Ian, what do you think?

It's possible that some users don't need nfs-utils to use autofs
so it's probably a good idea not to require this if possible.

> 
> p.s. Nalin, try using "-hosts" as the map name for your /net mount.

Using "-hosts" as a map type should give equivalent function
without requiring showmount.

I'd appreciate it if could give it a try and let us know how
it goes.

Ian
Comment 3 Nalin Dahyabhai 2006-07-07 10:25:43 EDT
That seems to work rather well in some cases.  In others, I get several SELinux
denials, I suspect because autofs didn't previously need to be able to do some
of the things it's trying to do now:

avc:  denied  { create } for  pid=21098 comm="automount"
scontext=root:system_r:automount_t:s0 tcontext=root:system_r:automount_t:s0
tclass=netlink_route_socket
avc:  denied  { bind } for  pid=21098 comm="automount"
scontext=root:system_r:automount_t:s0 tcontext=root:system_r:automount_t:s0
tclass=netlink_route_socket
avc:  denied  { getattr } for  pid=21098 comm="automount"
scontext=root:system_r:automount_t:s0 tcontext=root:system_r:automount_t:s0
tclass=netlink_route_socket
avc:  denied  { write } for  pid=21098 comm="automount"
scontext=root:system_r:automount_t:s0 tcontext=root:system_r:automount_t:s0
tclass=netlink_route_socket
avc:  denied  { nlmsg_read } for  pid=21098 comm="automount"
scontext=root:system_r:automount_t:s0 tcontext=root:system_r:automount_t:s0
tclass=netlink_route_socket
avc:  denied  { read } for  pid=21098 comm="automount"
scontext=root:system_r:automount_t:s0 tcontext=root:system_r:automount_t:s0
tclass=netlink_route_socket

Going to permissive mode doesn't seem to help with this particular host, though
(vader.corp.redhat.com).
Comment 4 Jeffrey Moyer 2006-07-07 10:36:08 EDT
Well, a bug needs filing against SELinux for the avc denied messages.

We'll also need the autofs debug logs for your failure case in permissive mode.
 Do you get mount failures or what?
Comment 5 Ian Kent 2006-07-07 11:37:47 EDT
(In reply to comment #4)
> Well, a bug needs filing against SELinux for the avc denied messages.
> 
> We'll also need the autofs debug logs for your failure case in permissive mode.
>  Do you get mount failures or what?

I'm working to improve my understanding of selinux.
I've seen these messages quite a bit.

The bigger problem is that they obscure the log so it's
hard to work out what's going on.

Nalin, could you create a policy module as a work around
till we get this fixed in the core policy.

Use:

grep automount /var/log/messages|audit2allow -M autofs
semodule -i autofs.pp

The process can be iterative as once avc message are
dealt with other denials can occur. Clearly the
temporary module should be removed (semodule -r autofs)
when the policy is updated to see if things have been
fixed.

Ian
Comment 6 Ian Kent 2006-07-07 11:43:47 EDT
(In reply to comment #4)
> Well, a bug needs filing against SELinux for the avc denied messages.
> 
> We'll also need the autofs debug logs for your failure case in permissive mode.
>  Do you get mount failures or what?

It would be good if we could get a "showmount" of the problem
server as well. This could be due to an error in the access list
pattern matching.
Comment 7 Jeffrey Moyer 2006-08-11 15:55:56 EDT
nalin, do you have any time to reproduce this and get the requested information?
Comment 8 Jeffrey Moyer 2006-09-14 17:09:02 EDT
We have strayed from the original bug on this one.  I vote to either fix nalin's
complaint (and require nfs-utils) or close this bug as wontfix.  Then, open
another bugzilla for the -hosts map problem.
Comment 9 Kostas Georgiou 2006-09-14 21:24:10 EDT
I think it's very unlikely that someone will be using autofs without using NFS,
adding nfs-utils as a requirement is the right way to go.
Comment 10 Curtis Doty 2008-01-10 14:04:15 EST
Please do not require nfs-utils for autofs. Too many of us use autofs for local
filesystem and network filesystems besides NFS.

Look at all the unnecessary deps that nfs-utils drags in:
$ sudo yum -d1 install nfs-utils

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 nfs-utils               x86_64     1:1.1.0-4.fc7    updates           265 k
Installing for dependencies:
 libevent                x86_64     1.3b-1.fc7       fedora             49 k
 libgssapi               x86_64     0.11-1.fc7       updates            23 k
 libtirpc                x86_64     0.1.7-9.fc7      updates            75 k
 nfs-utils-lib           x86_64     1.0.8-10.fc7     updates            61 k
 rpcbind                 x86_64     0.1.4-8.fc7      updates            47 k

Transaction Summary
=============================================================================
Install      6 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 520 k

Oh, and BTW, there is a bug in that /etc/auto.net script (when you don't have
the nfs-utils installed):

$ /etc/auto.net
/etc/auto.net line 40: --no-headers: command not found

Fix is easy:

--- /etc/auto.net.orig	2007-12-21 02:32:33.000000000 -0800
+++ /etc/auto.net	2008-01-10 10:43:50.000000000 -0800
@@ -32,7 +32,7 @@
 	done
 done
 
-[ -x $SMNT ] || exit 1
+[ -x "$SMNT" ] || exit 1
 
 # Newer distributions get this right
 SHOWMOUNT="$SMNT --no-headers -e $key"

But maybe the right solution is to send auto.net out to pasture?
Comment 11 Bug Zapper 2008-05-13 22:11:38 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Jon Stanley 2008-05-14 22:54:08 EDT
So what do to with this?  It's been awhile, is auto.net  going out to pasture
(it's not as of F9), or is autofs going to require nfs-utils (it doesn't as of F9).
Comment 13 Bug Zapper 2009-06-09 18:11:35 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Nalin Dahyabhai 2009-06-09 18:44:23 EDT
It looks like the 'hosts' map type doesn't use the auto.net script -- the daemon's doing the heavy lifting itself rather than calling showmount.  Since that's the default setting for /net now, that's good enough for me.  Marking as closed in the current release (F11).

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