Common Connect - 2012 Buyers Guide

in your environment, UID and GID numbers can quickly become inconsistent between servers. What this means is that the “brian” user might have a UID of 404 on Server1, a UID of 406 on Server2, and a UID of 402 on Server3.

This can be problematic for a couple of reasons. One of the biggest reasons to standardize consistently UID and GID numbers across all servers is so that you can move to a central authentication system, such as LDAP. Central authentication systems, like LDAP, generally require that LDAP enabled users and groups have consistent UIDs and GIDs across all servers that are LDAP connected.

Even if you are not looking to utilize central authentication such as LDAP, you can still run in to problems with having inconsistent UID and GID numbers. For example, suppose you have a SAN LUN mapped to ServerA. This LUN might have thousands of files stored on it. Each file stored on the LUN has the file owner and group stored as UID and GID numbers. So if you take this LUN and unmap it from ServerA and map it to ServerB, you will have issues if the UID and GID numbers are not consistent between ServerA and ServerB. In this scenario, you could have a couple of problems. If user brian was UID 404 on ServerA, and user bob is UID 404 on ServerB, after moving the LUN user bob now owns all of user brian’s files. If there is no UID 404 on ServerB, then the file does not have an owner on ServerB, and you simply see “404” as the owner when you run a ls –al command.

You might also have issues with inconsistent UID/GID
numbers across servers when you are exporting NFS
shares between servers.

Steps to manually change a GID and UID
number

In this example, you will change a single UID for a user (brian) and a GID for a group (testgroup). The “brian” users original UID is 404, and the new UID will be 3504. The “testgroup” groups original GID is 402, and the new GID will be 5001. Changing a GID or UID number is a multi-step process.

Step 1. Stop applications and have users log off Before changing GID or UID numbers, it is important to stop all running applications and have all users log off of the server. The process table keeps track of running processes based on UID and GID numbers. So, if users have running processes while these numbers are changed, unpredictable results occur. Also, until the file ownership is fixed in a later step, the users temporarily loses access to their files.

Step 2. Find users who have the group as their primary group Each user on the system has a primary group defined in the /etc/passwd file. When you change the GID number in Step 3, AIX prints a warning message that it does not update the /etc/passwd file with the new GID. So before you change the GID, you first want to get a listing of all users that have the group you are changing as their primary group. There might not be any users with this as their primary group, or there might be multiple users. To find out, run the command in Listing 3 below:

Listing 3. lsuser output
lsuser -a pgrp ALL | grep
pgrp=testgroup
brian pgrp=testgroup

This command shows that there is one user (brian) on
the system with testgroup as their primary group. Make a
note of the users that this command displays as you will
need to run a command to fix them in a later step.
Step 3. Change the GID number
Use the chgroup command to change the GID of
testgroup to 5001 (originally it was GID 402).

Listing 4. chgroup output
chgroup id=5001 testgroup
3004-719 Warning: /usr/bin/chgroup does
not update /etc/passwd with the new gid.

The chgroup prints a warning message letting you know that it does not update the /etc/passwd with the new GID. This warning applies to any users that have this group as their primary group. You collected a list of these users in Step 2, and in the next step you will fix this.

Step 4. Fix users primary group For each user that you noted in Step 2, run the following command to fix their primary group. Note that there might not be any users with the group as their primary group, or there might be multiple users.