Hi Managers,
This was my original question:
> A Solaris 2.4 machine (which is also a wu-ftp and an apache server) is
> denying access to only one user (when the user types in his passwd, the
>session hangs). This user is not in the /etc/passwd on this particular machine,
> but he is in the NIS+ database. He can rlogin/telnet normally.
>
> None of my other users seem to have this problem. He's using /bin/csh. This
> happens both with and without /etc/shells, and has started happening only
> recently.
>
> No disk, swap, memory problems.
>
The user could not ftp to only one particular machine. I checked for the
following (which, it turns out, was not his problem):
- /etc/ftpusers: all users in here are denied
- /etc/shells : should have correct paths, no control characters, and ALL
the shells listed.
- the user could ping/telnet/rlogin/rsh normally
- all other users could ping/telnet/rlogin/rsh AND ftp in normally
- this user was not in the local /etc/passwd (but he was in the NIS+ datbase),
like many other users. The other users had no problem though.
- this user could ftp in *some* of the times, so I thought one of the .login,
.cshrc, etc. files had some weird settings that were creating the problem.
Not so.
- I recreated his NIS+ credentials to overrule any possible corruption
using [nispasswd <username>; nisclient -co <username.]
- I deleted and recreated his credentials using nisaddcred
- I deleted and recreated his account
- I used snoop to look at the traffic coming across the wire when the user
attempted to ftp.
- I checked to make sure tcp-wrappers was not causing the problem
- I checked the $HOME/.netrc file
- I changed the user's password to a one containing alphanumeric characters.
- Made sure that the user's shell was listed correctly (path wise and typos)
in NIS+
Thanks to the following for lot of the suggestions above:
From: The Unix Mighty!!! <patel@tum.net>
From: Ian Ashton <i.ashton@Bradford.ac.uk>
From: "Ravindra N Nemlekar" <ravindra@airmail.hobl.lucent.com>
From: Asim Zuberi <asim@psa.pencom.com>
From: Waqar Hafiz <whafiz@london.micrognosis.com>
From: brigjk@aur.alcatel.com (James K Brigman)
From: nsp83273@cae091.ed.ray.com (Neal S. Pressman ex 2317)
From: Marko Djukic <mdjukic@lhr-sys.DHL.COM>
From: Marcelo Maraboli <maraboli@dcsc.utfsm.cl>
From: brian davies <daviesb-cos3@kaman.com>
From: fpardo@tisny.com (Frank Pardo)
My REAL problem:
The problem was not with the user's account after all, but with NFS setup.
Since the 'bad' user did not have a local acccount on the problem machine (he
wasn't listed in the local /etc/passwd), whenever he tried to ftp in, the
program would try to drop him into his home directory indicated by NIS+. This
was where ftp was hanging because the home directory was NFS mounted (and we
were having NFS problems).
The /var/adm/messages on the problem machine was full of:
Jan 22 13:47:59 problem_machine: NFS server machine not responding still trying
Jan 22 13:48:43 problem_machine: NFS server machine ok
Evidently, the NFS problem was intermittent because this particular user could
ftp in some of the time. I was trying to truss ftp from the machine the user
was trying to ftp from. Finally Sun's tech support pointed to me that since
inetd spawns off ftpd, I should be running truss on the pid of inetd on the
*problem* machine (which I am ashamed to say, I did not think off! ;)
On the problem machine I started this:
truss -o output.file -f -p pid_of_inetd
Then I tried to ftp in both as a 'good' user (meaning the guy who had no
problems), and also as the 'bad, bad' user. The truss output showed me that
for the problem user, it tried go to the user's home directory, and then
becuase this directory wasn't accessible, it went to sleep on it.
What threw me off the track was the fact that though the other users who were
able to ftp in all the time were in the NIS+ database (which indicated their
home directory as the NFS mounted one), they also had *different* home
directories listed in the local /etc/passwd on the problem machine. Apparently,
/etc/passwd was overriding NIS+. So I created an entry for him on the problem
machine in the /etc/passwd, and Voila, the bad user could ftp in, no problem!
Would have been as simple as checking /etc/nsswitch.conf. Well, easy to say
now, in hindsight. Whew! ;)
I'm waiting for Sun tech support to get back to me on the NFS issue.
Thank you very much for all the help! It helped me eliminate a lot of
things!!
Gratefully,
Rasana
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Rasana Atreya Voice: (415) 476-3623 ~
~ System Administrator Fax: (415) 476-4653 ~
~ Library & Ctr for Knowledge Mgmt, Univ. of California at San Francisco ~
~ 530 Parnassus Ave, Box 0840, San Francisco, CA 94143-0840 ~
~ Rasana.Atreya@library.ucsf.edu ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:43 CDT