I have a query in relation to a couple of machines I have set up. We will call them machine SUN and HPUX and they are running those operating systems respectively. The SUN machine is acting as an NIS server and the HPUX machine as an NIS client. Now the HPUX machine also has a an auto mounted file system from a 3rd machine (call it 3SYS). The system of accounts and home directories which have been set up on this is curious. The NIS accounts which have been set up have the home directories located in several places. Some accounts have the home directory located on the NIS server itself ( i.e. on SUN) some have the home directories located on the mounted files system of HPUX ( i.e. on 3SYS). This leads to some fun depending where you log in from and this is where this query is going.
As all of these accounts are NIS accounts the password files will be pushed to all machines which are clients slaves or masters. IN all the cases below I have logged onto the machine in question as root and then tried to su - to an account so when I say log on I really mean su - account.
If you log on to the SUN ( the NIS server) with an account which has a home directory on SUN everything works fine as expected. However if you log onto SUN using an account which has its home directory on SYS3 I get an error message saying "NO directory !" and it kicks me back into the acccount I just tried to change from. This is not unexpected as it can see the password map but not the home directory.
Conversely if I log onto HPUX and try to log onto an account which has it's home directory located on the automounted file system ( i.e. SYS3) everything works OK as you would expect. However if I am on HPUX and I try to log onto an account which has it's home directory on SUN then I am able to log in as that user but I stay in the home directory of the account which I just tried to log in from.
What is causing the discrepancy between these two situations. In summary.
HPUX -> login to account -> home dir on another machine -> login ok but stay in existing directory
SUN -> login to account -> home directory on another machine -> login not ok and kicked out to previous account
Each OS handles things differently. Since SUN is more strict with NIS, if you have no directory or no shell, you can't log in. HP is more forgiving and it gives you a "loaner" shell or directory in some cases. AIX acts differently then either of these. If you mount SYS3 home directories to HPUX and SUN then you should not2have any issues regarding the directory. What entries do you have on both systems in /etc/passwd and /etc/group that start with a +? Some users, groups, or netgroups may be allowed/denied access which can though another wrench into the picture.
I don't know if the "Loaner" shell is configurable or not, I just know the default is different for different OSes.
Since the Sun system is the NIS server, it is likely it is using the /etc/passwd and /etc/group to build the NIS maps which means you wouldn't need the + entries in those files. This can be changed however and point to any location you like.
This has actually made me think a bit more about the passwords situation for NIS on SUN and HPUX. I did a bit of digging and it brought up more questions
From what I could see in the man pages and in some websites the idea for having an nsswitch.conf file was to avoid having the entry "+" in the /etc/passwd and /etc/group files to enable nis and that once you had entries in /etc/nsswitch.conf for passwd and group it overrides the + entries in the /etc/passwd and /etc/group files. I decided to try this out and find out if this was correct (I also wanted to check out what the comport entry in the nsswitch file was for).
What I tried to do is to change the entry in the nsswitch.conf file for passwd from
passwd files nis
to
passwd files
This was to see if I needed to stop and restart the client when changes were made. I tried to log into an nis account subsequant to this change and as expected I couldn't.
I then put the entry back to
passwd files nis
and when I went to log into the nis account everything was now ok.
What I wanted to do next was to disable the entry in the nsswitch.conf by putting # infrom of the passsword entry. The idea was then to check if I could log into the nis account and then if it failed as I expected it to I was going to ad various + type entries to the passwd file. However I found that even if I put a # in front of the passwd entry in the nsswitch.conf file of removed it or even deleted the nsswitch.conf file itself I could log into an nis account I wanted.
I don't know how this is possible if there is no entry or no file anmd there are no + type entries in the passwd file.
Any thoughts ???
P.S. I also noticed when looking into this on HPUX that if you do a man on passwd it gives an example where the entry for nis which is
+:::Guest.
Normally the entry after 3 colons is the group id what is it here. It mentions the pw_gecos of Guest. It says that it contains user info but I am not sure what that is and why it is located where the group id entry should be as there are no man files specifically on it.
When you make changes to /etc/passwd on any platform, you have to map the NIS files again, usually by running a MAKE command. I know in Linux, you can use "make -C /var/yp".
If nothing else, you could just use /usr/lib/yp/ypinit -m to remap the master(or the equivalent directory) and /usr/lib/yp/ypinit -s MASTER SERVER on the slave server to synch it up with the master. Of course, I have always heard that that was not recommended.
You also might have needed to restart ypbind/ypserv.
The nis server (master) is machine 1, the sun client is machine 2, and the hpux client is machine 3. The password file having the entries made to it is on machine 2 so it is the local password files on the client and the clients nsswitch.conf file which is being altered. As there are no changes being made to the master ( i.e. all nis accounts remain unchanged) I don't believe any changes need to be made to remake the nis maps. It is just the clients ability to have access to the name service switch ( and subsequantly the maps) which is being tested.
I think I might know what is happening. After you make changes you should stop/restart the ypbind process on the client machine. If you change /etc/passwd, /etc/group, /etc/nsswitch.conf without stopping and restarting ypbind still has the info in it's memory to get the NIS map info. I ran into this today at work when I was removing a Sun system from NIS. After changing all the files, ypcat passwd still worked. Once I stopped/started ypbind again I could not longer ypcat.
Thanks for the tip Tony but it didn't work. I even went to the point of deleting the nsswitch.conf file and rebooting (which should both kill the ypbind daemon and remove any system state info) and I was still able to access nis acounts on the restart. I think I will send this to sun to see what they come up with