Bug 197824

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.

(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

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).

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?

(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

(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.

nalin, do you have any time to reproduce this and get the requested information?

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.

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.

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?

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

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).

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

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).