Bug 222777

I'm getting rummy from too much banging on the keyboard. I just dropped to
permissive and the automount still fails. But I do not know whether I would need
to restart autofs or do something else.

After several more hours of testing I do not believe the issue I'm having with
the automounter is related to labeling. But it is still not working and I have
had several other very good system administrators go over the checks I have done
and look at the issue but we still have not found the root cause of the problem.

After installing audit and retesting I see this information in the
/var/log/audit.log file:
type=USER_LOGIN msg=audit(1169096567.183:84): user pid=3629 uid=0 auid=429496729
5 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 msg='acct=dhighley: exe="/u
sr/sbin/sshd" (hostname=?, addr=10.2.2.7, terminal=sshd res=failed)'

I get this information from /var/log/messages:
Jan 17 20:18:43 redwood automount[14151]: mount_autofs_indirect: failed
 to read map for /home
Jan 17 20:18:43 redwood automount[14151]: handle_mounts: mount of /home
 failed!
Jan 17 20:18:43 redwood automount[14151]: master_do_mount: failed to st
artup mount

Switching ownership to autofs in order to get their imput on this bugzilla.

Please provide your autofs maps.  If they live in NIS, be sure to pass the "-k"
option to ypcat.  We'll also need to see the automount: line from
/etc/nsswitch.conf.

That first log message from the automounter indicates that automount was not
able to even read your map file for the mount point /home.  Are you sure *that*
is labeled properly?

Taken from the client that has the issue. But I do not think this is an NIS
issue. If you look at the /var/log/audit/audit.log information above you will
find that the /usr/sbin/sshd entry has the hostname=?. Note, that all map
information, local files, and DNS show no problems. Login completes if I type in
a password and the automounter maps an empty home directory for the user. I can
manually mount the NFS share to the automounter created location. Selinux is in
enforcing mode and iptables is disabled on the client. I have tested with
Selinux in permissive mode and it made no difference.

-bash-3.1$ ypcat -k auto.master
/net -hosts
/misc /etc/auto.misc
/home /etc/auto.home
+auto.master

-bash-3.1$ ypcat -k auto.home
* douglas.highley-recommended.com:/export/home/&

-bash-3.1$ ypmatch -k spruce hosts
spruce 10.2.2.2 spruce.highley-recommended.com  spruce internal ftp-i

/etc/nsswitch.conf:
hosts:      files dns nis
automount:  files nis

/etc/hosts
-bash-3.1$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1             localhost.localdomain localhost
10.2.2.9        redwood.highley-recommended.com redwood

/etc/auto.master:
-bash-3.1$ cat /etc/auto.master
#
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
/misc   /etc/auto.misc
/net    -hosts
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

Server /etc/exports file:
/export/home    *.highley-recommended.com(rw)

[root@redwood ~]# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100007    2   udp    648  ypbind
    100007    1   udp    648  ypbind
    100007    2   tcp    651  ypbind
    100007    1   tcp    651  ypbind
    100024    1   udp    622  status
    100024    1   tcp    628  status
    100021    1   udp  32771  nlockmgr
    100021    3   udp  32771  nlockmgr
    100021    4   udp  32771  nlockmgr
    100021    1   tcp  58162  nlockmgr
    100021    3   tcp  58162  nlockmgr
    100021    4   tcp  58162  nlockmgr


-bash-3.1$ dig spruce.highley-recommended.com

; <<>> DiG 9.3.3rc3 <<>> spruce.highley-recommended.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15621
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;spruce.highley-recommended.com.        IN      A

;; ANSWER SECTION:
spruce.highley-recommended.com. 86400 IN A      10.2.2.2

;; AUTHORITY SECTION:
highley-recommended.com. 86400  IN      NS      hemlock.highley-recommended.com.
highley-recommended.com. 86400  IN      NS      spruce.highley-recommended.com.

;; ADDITIONAL SECTION:
hemlock.highley-recommended.com. 86400 IN A     10.2.2.3

;; Query time: 4 msec
;; SERVER: 10.2.2.3#53(10.2.2.3)
;; WHEN: Thu Jan 18 19:24:58 2007
;; MSG SIZE  rcvd: 116

(In reply to comment #6)
> 
> -bash-3.1$ ypcat -k auto.master
> /net -hosts
> /misc /etc/auto.misc
> /home /etc/auto.home

What's in "/etc/auto.home" on the client machine?

> +auto.master
> 
> -bash-3.1$ ypcat -k auto.home
> * douglas.highley-recommended.com:/export/home/&

If you don't have an "/etc/auto.home" on the client then
create one with the above line in it and see what happens.

Ian

Ian

Creating a local /etc/auto.home file with the same information fixes the login
automount issue. So where does that leave us. If I can use the ypcat commands to
dump the map files on the client and the passwd map file must be present or the
user would not exist for the login is the auto.home file not present?

Because your master map points explicitly to /etc/auto.home, you need to provide
that map.  You can include the NIS auto.home by creating /etc/auto.home with the
single entry:

+auto.home

This sounds like it would be the most sane configuration.

The last sentence in your update is a bit difficult to follow (pesky English). 
I believe you want to know if the problem is that there is no /etc/auto.home
file present.  This is the case.  Autofs was complaining because the map pointed
at /etc/auto.home, and that file dose not exist.  You may want to see how the
other systems that work are configured in this regard.

If you agree with this diagnosis, then please close the bug at your convenience.

Thanks!

(In reply to comment #9)
> Because your master map points explicitly to /etc/auto.home, you need to provide
> that map.  You can include the NIS auto.home by creating /etc/auto.home with the
> single entry:
> 
> +auto.home
> 
> This sounds like it would be the most sane configuration.

And don't forget that for autofs to look for a map in NIS
/etc/nsswitch.conf must contain "nis" as a source (sorry but
I have to say this for completeness). 
For example:
automount: files nis

Aditionally, if you feel that it won't cause a problem for the
other systems you could change your master map /home entry to
/home   auto.home
and ensure nsswitch is setup as above.

Ian

Yes, I believe the best solution is to change the auto.master file to be:
/home auto.master

I think it was my mistake but very confusing that two of the clients would work
without the existence of a /etc/auto.home file but the third system would not.
So is it a bug, probably but also not worth wasting bandwitdth on chasing
although I probably have 15-20 hours lost in debugging the issue. Thanks

The bug is with your other systems.  What operating system are they running
(older RHEL, maybe)?  I'm changing the status here to NOTABUG, because for the
system you described, it was a configuration error.

All four systems are Fedora core 6 with the latest updates; not kernel 2.6.19
until tonight.