My question was:
Last weekend I installed part of the C2 security features on our mixed
Sun-3 (4.0.3) Sun-4 (4.1.1) configuration with servers and diskless clients.
Due to space limitations I disabled the auditing (removed the auditd from
rc.local). This way the only action of the C2conv script was the
splitting of passwd and group files. With minor problems
everything was running (NIS maps passwd.adjunct, group.adjunct and the
rpc.pwdauthd daemon).
But every morning, the first user on every workstation has to wait
2-4 login timeouts before he/she can log in. The user is asked for name
and password, and then the login process hangs until timeout.
The console usually displays some 'rpc: RPC: Timed out' messages.
(A ps -aux shows that the first rpc.pwdauthd is present, i.e. one with
low pid)
In average, the third attempt is successful and from then on the problem
disappears for the rest of the day.
Any idea what the problem is, and how it can be fixed?
I have to add that one server per night goes down to singleuser for
automated backups.
------------------------------------------------------------------------------
I received two answers:
- Richard Elling <elling@eng.auburn.edu> pointed out that the culprit is
with the server going down for backups during the night:
> rpc.pwdauthd will bind to it's NIS server differently than other NIS
> clients. Presumably, rpc.pwdauthd has this different mechanism
> to help prevent spoofing. I know of no workaround. A hack would be to
> have cron start a job which would cause rpc.pwdauthd to try to rebind,
> perhaps an rlogin or ftp. Then rpc.pwdauthd will be rebound by the tim
> your users login in the morning.
And in fact, after a night without singleuser backups, the login procedure
succeded at first attempt.
- hal stern <stern@East.Sun.com> indicated that the problem may be caused
by the fact that a 4.0.3 NIS master is serving 4.1.1 slaves and clients:
> if you're mixing 4.1 and 4.0.3 NIS masters, that's probably your
> problem. the 4.1 clients are trying to read 4.1-style NIS files,
> and will fail until they rebind to the 4.1 server. your NIS master
> server should be a 4.1 machine
I didn't try this one, but we plan to upgrade our master server
in a month or two. Looks as if it will be ok then.
Many thanks to all,
Jiri Dvorak
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:09 CDT