tcsh used for local user but not NIS user

[Douglas McCracken_1]

I have a number of HP-UX 11.0 (N-Class) boxes which have NIS users logging in and set up to use tcsh. Most of these servers start the correct shell (tcsh), whether the users are local or NIS-based. However, two of them use the specified tcsh shell for local users only, and use /bin/csh for NIS-based users (the same NIS-based users that work correctly on the other servers). These two problem servers have tcsh installed and working correctly for those local users. I have set up local users with the exact same entries as the NIS-based users and they get the correct shell. I believe I know which shell is running, by echo $SHELL and by testing the functions available (i.e. with tcsh, the up-arrow gives the previous command, with csh, it gives nothing of any value).
Thanks for any ideas,
Doug

[Sachin Patel]

Hi Doug,

You says " have set up local users with the exact same entries as the NIS-based users and they get the correct shell" how are they look like. Last field on passwd line.

Type
#ps rather then echo $SHELL

We have all nis and local user uses tcsh and it works fine.

Check the link. Is tcsh in path
#which tcsh should return something like

# which tcsh
/usr/bin/tcsh


Sachin

[Shannon Petry]

the $SHELL variable will show you the default/login shell, not your current running shell.

I am root atm, and type $SHELL and it reports /sbin/sh, after typing csh $SHELL is still /sbin/sh and after typing ksh, it is still $SHELL.

If users are getting 2 shells for local and nis use, the one of 2 things is occuring.
1. The nis passwd file and local passwd file dont match
2. you probably have a link to difference in tcsh setup.
I.E. On some systems you replaced the link from /usr/bin/csh to /bin/csh with a link from /usr/local/bin/tcsh to /bin/csh
on others you may have a link from /usr/local/bin/tcsh to /bin/tcsh.

Not many variables to look at, so I hope to hear which one it is?

Regards,
Shannon

[Douglas McCracken_1]

Thanks very much for your helpful responses. First of all, even if echo $SHELL doesn't always show the current shell, I still know that the NIS users on these two problem servers are not getting the tcsh shell, because it doesn't have the tcsh functionality. Secondly, all user accounts, both local and NIS, use the same entry for the tcsh shell, which is /usr/local/bin/tcsh; if I logon to an NIS-based user account (not getting the tcsh shell) and then run /usr/local/bin/tcsh, I get the tcsh shell. Also, I have disabled an NIS account, then created it locally on one of the problem servers, using the output from ypcat passwd | grep for the passwd entry; this local account works as I expect (clearly gives me the tcsh shell). Am I just confused about something here?
Thanks,
Doug

[Shannon Petry]

Hmmm, maybe
first do you have an /etc/shells which contains the valid system shells? I.E.
cat /etc/shells
/sbin/sh
/bin/sh
/usr/bin/sh
/bin/csh
/usr/bin/csh
/bin/ksh
/usr/bin/ksh
/usr/local/bin/tcsh

Next how are you formatting the NIS clients passwd file for NIS?
I use typically an entry like:
+::0:0:::
some people use
+::-1:-1:::
Missing a colon or entry may be causing the system to have difficulties with the shell.

I know the nsswitch.conf is supposed to work so that you dont need the entry +::0:0::: in passwd and +::0: in group, but I have many applications that totally bomb without it (CAD/CAM/FEA/CAE).

Regards,
Shannon

[Douglas McCracken_1]

Thanks very much for the interesting replies. The one that really got me looking in the right place was the last one from Shannon suggesting looking at how NIS is added to the passwd file. I hadn't thought of this, but what we do here is to add specific NIS groups (not just all NIS accounts at once), to restrict access in various ways. When I looked at the passwd file again, I realized that some of the NIS group entries included a shell entry, which of course would over-ride the NIS shell entry. Cute, huh?
Thanks for your help.
Doug

[Misa]

I'm assuming that you did the ypcat (to create the local acct) right there on the machine where you were creating it -- to see that how it's resolving on the problematic host. I'm assuming you've checked to see that it's binding to the right NIS server.

You've done everything I'd do, and I can't think of any more reasons why it wouldn't work. BTW, which shell *do* they get? If it's /sbin/sh (the default), that kind of implies that the shell specification is being ignored.

I guess I'm to that old standby -- have you added all the NIS jumbo patches?