autofs4 and NIS

autofs4 and NIS

[Dylan]

Hello all,

I'm currently using autofs4 to mount nfs shares. The config files are 
distributed via NIS, which overall is working without a hitch. I have 
two related problems, however...

It is, obviously, necessary to restart the NIS server from time to time, 
in order to take account of config changes (usually changes to user 
accounts.) When I do this, the following occurs:

A: nfs shares which are unmounted become unavailable (cd-ing to the 
directory results in a 'no such file or directory' error)

B: nfs shares which are mounted report stale file handles.

I can understand where problem A comes from - and I figure restarting 
autofs would clear that, but it is not really practical to do on each 
machine. But I'm not sure why B should happen...?

Dylan
-- 
Sweet moderation
Heart of this nation
Desert us not
We are between the wars
- Billy Bragg

Re: autofs4 and NIS

[Ian Kent]

On Thu, 1 Jan 2004, Dylan wrote:

> Hello all,
> 
> I'm currently using autofs4 to mount nfs shares. The config files are 
> distributed via NIS, which overall is working without a hitch. I have 
> two related problems, however...

autofs4 is the kernel module.
What version of the daemon package are you using?
Are you using the unmodified version of the kernel module, autofs4?

> 
> It is, obviously, necessary to restart the NIS server from time to time, 
> in order to take account of config changes (usually changes to user 
> accounts.) When I do this, the following occurs:

Yes, but I fail to see how autofs is part of this unless autofs tries to 
contact the NIS server while NIS is not available? Which should be a few 
seconds at most right?

> 
> A: nfs shares which are unmounted become unavailable (cd-ing to the 
> directory results in a 'no such file or directory' error)

What are you saying here. If the NFS server is not available I would say 
this is firly acurate. We are talking about restarting NIS services 
aren't we?

> 
> B: nfs shares which are mounted report stale file handles.

The client has open files on the NFS server and it has gone bye bye. We 
aren't talking about restarting NIS anymore are we?

> 
> I can understand where problem A comes from - and I figure restarting 
> autofs would clear that, but it is not really practical to do on each 
> machine. But I'm not sure why B should happen...?

You shouldn't need to restart autofs. This nees to be investigated and 
fixed. I'm not seeing this myself but most of my clients have stuff 
mounted for extended time and mostly survive.

Maybe there is more going on here than I can gather from the description 
or maybe the particular setup you have is exposing a problem I am unaware 
of, more info perhaps.

Ian

Re: autofs4 and NIS

[Todd Denniston]

Dylan wrote:
> 
> Hello all,
> 
> I'm currently using autofs4 to mount nfs shares. The config files are
> distributed via NIS, which overall is working without a hitch. I have
> two related problems, however...
> 
> It is, obviously, necessary to restart the NIS server from time to time,
> in order to take account of config changes (usually changes to user
> accounts.) When I do this, the following occurs:
<SNIP>
I am a bit confused here. 
Why do you need to _restart_ the NIS server to push out the changes for USER
ACCOUNTS?

All of the systems I currently work with have have a Makefile in /var/yp, and
you just need to do a cd /var/yp;make (or make PARTICULAR_CONFIG_FILE) and the
updated user data is pushed to the NIS client machines.

Although when I run 'make -n' I do see some "kill -TERM 0" buried in there,
they look to only be ran if the awk commands before them return a non-zero
exit status.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter

Re: autofs4 and NIS

[Michael Blandford]

Dylan wrote:

>Hello all,
>
>I'm currently using autofs4 to mount nfs shares. The config files are 
>distributed via NIS, which overall is working without a hitch. I have 
>two related problems, however...
>
>It is, obviously, necessary to restart the NIS server from time to time, 
>in order to take account of config changes (usually changes to user 
>accounts.) When I do this, the following occurs:
>  
>
I think we need to address this issue in particular.  I can't think of 
any reason you need to restart your NIS master for config changes.  We 
have masters/slaves that have been up for years at a time without 
restarting.  These probably see > 100 map changes/pushes a day.  What 
changes are being made that a 'make' in /var/yp doesnt solve?

Also, you can set up a NIS slave/secondary to handle any connections in 
the event the master is unavailable or to help handle the load.  Then 
you always have NIS coverage.

I think if you solve this problem, the others will become non issues. 

Michael