Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159726 - NIS maps will not load correctly on a user login
Summary: NIS maps will not load correctly on a user login
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-07 14:48 UTC by David Mullins
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-04-17 19:45:56 UTC


Attachments (Terms of Use)

Description David Mullins 2005-06-07 14:48:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
Upon upgrading from the older autofs in AS3 with no updates the NIS maps no longer mounted when a user logs into the system. If I revert to this older rpm for autofs it returns to fully functional. All versions of autofs-4.* that I have tried showed the same behavior.

The machines in question are Dell 2650s.

Version-Release number of selected component (if applicable):
autofs-4.1.3-130

How reproducible:
Always

Steps to Reproduce:
1. Use an existing fully functioning NIS server and client (AS3)
2. Upgrade the NIS client from AS3 with no updates to autofs-4.1.3-130  

Actual Results:  The NIS maps no longer mount the filesystems.

Expected Results:  It should continue to function as before

Additional info:

even a reboot after loading the new rpm had no effect upon these filesystems loading.

Comment 1 Jeff Moyer 2005-06-07 14:51:20 UTC
Please see the section entitled "Filing bug reports" on the following web page:
  http://people.redhat.com
and provide the information requested.

Comment 2 David Mullins 2005-06-07 16:07:18 UTC
this website is a dead-end link, how am I to provide the information needed?
All this shows is the url, a redhat logo, and a powered by redhat graphic that
links back to redhat.com.


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
	<head>
		<title>people.redhat.com</title>
		<link rel="icon" href="/icons/shadowman-16.png" type="image/png"/>
	</head>
	<body bgcolor="#FFFFFF" text="#000000" link="#000066" vlink="#333399"
alink="#FF0000">
	<br/>
	<div align="center">

	<img src="/icons/people.redhat.com.png" width="374" height="194"
alt="people.redhat.com" />
	</div>
	<br>
	<p align="center">
	<a href="http://www.redhat.com/" align="center"><img src="/icons/poweredby.png"
align="center" alt="[ Powered by Red Hat Linux ]"></a>
	</p>
	</body>
</html>

Comment 3 Jeff Moyer 2005-06-07 16:24:32 UTC
Sorry about that!  That should have read:

  http://people.redhat.com/jmoyer/

Comment 4 David Mullins 2005-06-07 17:29:17 UTC
# autofs rpm version, obtained via 'rpm -q autofs'
it is autofs-4.1.3-130

# kernel version, obtained via 'uname -r'
2.4.21-20.ELsmp

# contents of your autofs maps. This includes auto.master and at least the map
which is problematic for you.
the auto.home file that works with fine with RH 7.3, 9, and AS3(no updates)
clients but not with AS3update3 or AS3update5 clients. The NIS map is formated 
as follows:

user -rw    machine:/export/home/user

The files system is shared and exportfs reports /export/home   <world>
(These machines are not on an outside network.)
(ypcat auto.home does return the correct information)

# debug output.
I will be unable to attach logs as this is not a connected system. here is the
relevant data:

timestamp machine syslogd 1.4.1: restart.
timestamp machine autofs: automount shutdown succeeded
timestamp machine automount[PID]: starting automounter version 4.1.3-130, path =
/home, maptype = yp
, mapname = auto.home
timestamp machine autofs: automount startup suceeded
timestamp machine automount[PID]: mount(bind): bind_works = 1
timestamp machine automount[PID]: mount_autofs: already mounted
timestamp machine automount[PID]: /home: mount failed!
timestamp machine su(pam_unix)[PID]: session opened for user user by root (uid=0)


It is at this point that on a nis login the login succeeds but the home
directory of the user is not loaded.

Comment 5 Chris Feist 2005-06-07 18:58:57 UTC
Could you attach your /etc/auto.master file as an attachment?

Comment 6 Jeff Moyer 2005-06-07 19:15:11 UTC
Please stop the automounter and send the output from the mount command with no
options.  And, as Chris said above, please send the contents of auto.master.

The error message states that the directory '/home' is already mounted.  Are you
trying to automount on top of a mount point?

-Jeff

Comment 7 David Mullins 2005-06-08 11:40:53 UTC
/etc/auto.mater has the one that comes with the distribution. It has no
uncommented lines.

there is a reference to /dev/sda5 mounted to home. I assume this must be the
problem. This is not a problem for the older 3.x version of autofs. 

Comment 8 David Mullins 2005-06-08 12:24:16 UTC
with this entry removed it will now load this map.

Is this the new default behavior for this version of autofs?

Comment 9 Jeff Moyer 2005-06-08 12:29:58 UTC
Yes.  I instituted this change due to several bug reports from users.  If you
did a service autofs restart, and the mount point was busy so didn't unmount,
then autofs would mount over an existing automounted file system.  This made for
interesting inconsistencies that could case side effects such as not being able
to unmount the directory in question.

If this is a problem for you, then it is feasible to change the is_mounted check
to check for a mount point that is of type autofs.  If it isn't an autofs mount
point, then we could succeed.

However, is this really the  behaviour you want?  Why would you mount /home from
a block device, and then just overwrite it?  I can think of maybe one corner
case where you'd want this behaviour.

Comment 10 David Mullins 2005-06-10 19:35:17 UTC
This may not be the behavior I wanted, but it was what I expected. We use a
custom install for everything one size fits all. This then caused some issues
when we upgraded those machines and the few that were on NIS did not behave as
expected. I started to look into it for a solution and a likely cause. I may
have to attempt to institute an is_mounted check similar to what you have mentioned.

Comment 11 Jeff Moyer 2006-04-17 19:45:56 UTC
David,

I'm going to close this as NOTABUG.  The situation you describe is really a
corner case, and an error is logged via syslog when this happens.

Thanks.


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