Group ID disparity in NIS domain

[Andrew Kaplan]

Hi there --

We are running an NIS domain where the master server is running on the HP-UX 11.11 operating system, and most of our clients are running on either the Fedora Core 2or SuSE 9.3 distributions. There are four slave NIS servers in use in the domain, and of those one is also running the HP-UX 11.11 operating system, while the other three are running the Fedora Core 2 distribution.

One of our users complained that he is having problems saving data to his home directory while logged into one of our SuSE clients. An investigation revealed a disparity between the GID of the users group on the client, and that of the Master NIS server. The GID on the server is 20, while that of the client is the 100 value. The GID of 20 on the client refers to the group cdrom. No other client appears to be having this problem.

I want to change the GID of the client to match that of the server. My first thought was to go to the client system, make a backup copy of the /etc/group file, and modify the GID of users to match that of the master server.

Is the solution as 'simple' as that, or is there much more involved here?

Thanks.

[klb · Accepted solution]

It's been a while since I wore my NIS hat ( like 10+ years ).

As I recall, a client's local group file is used along with the NIS server group map. So, it would seem that your "cdrom:20:" entry on your client is the culprit. Changing this on the client would probably do the trick, but you'd need to ensure anything that relies on the cdrom group gets changed as well.

so maybe:
find / -group cdrom -print >/tmp/changefile
#make the change in /etc/group changing cdrom #to another unused GID.
# Now remap old GID to new GID
for FILE in `cat /tmp/changefile`;do
chgrp cdrom $FILE
done

Hth,

-klb

[Andrew Kaplan]

Hi there --

Thanks for your reply. I might be able to reboot the system in question, so if I made the change to the /etc/group file and rebooted the client, would that cause the change to go into effect?

[klb]

Changes to /etc/group don't require a reboot generally, however you may have applications and/or other daemons that read the file once and cache it??

A reboot will not fix files on your client that currently have GID=cdrom. When you change /etc/group's cdrom entry to an unused GID number, those files on the client box currently having GID=cdrom, will now show in an ls -l as having GID=users, because there's no longer a 20 in local /etc/group, but the NIS map will have GID=20=users.

It's these files that ~could~ pose an issue and ~should~ be fixed as stated above. Note also that you may have files on the client with GID=20 that really want to be GID=20=users instead of GID=20=cdrom.

Make sense?

-klb

[Andrew Kaplan]

Hi there --

Yes it does. I'll proceed with the reboot, after I run the commands you listed in your previous posting. Once the reboot is complete, I'll stand by to troubleshoot any problems should they occur.