Often during migration from a local to a global authentication mechanism system administrator discovers that the same user group has a different numerical GID on one or more hosts. To change it system administrator either edits the file /etc/group or he/she could executes the command called chgroup.
The results of this action are quickly apparent as immediately after such change every file object which belongs to the group will show instead of the group name its previous GID value.
Now, system administrator has to comb through the file systems looking for each file/directory showing the old GID and replace it with group name.
Another AIX administrator, before the change of the group GID may collect the /path/file_name of every file owned by the group in a text file (find / -group Group_Name -ls >> FileList.txt) and use its contents after the GID change as follows:
for myFile in `cat FileList.txt | awk '{print $11}'`
do
chgrp GROUP_NAME $myFile
done
One may quickly find out that if there is a substantial amount of files to process and the length of the command arguments list (ncargs) is not adequate the AIX shell fill refuse to execute these directives responding with the messages of “Not enough memory to execute“.
Before you start looking into one of my earlier posts suggesting how to deal with such outcome, you could try to replace the for loop with its while equivalent.
cat FileList.txt | while read line
do
myFile=`echo $line | awk '{print $11}'`
chgrp GROUP_NAME $myFile
done
You might be surprised but this time it may work like a charm.
Before we call it a day, we have to remember that any user defined in /etc/passwd whose primary group GID was modified still shows the “old” GID! So any users whose primary group was the one you modified will not be allowed to login!
We could use vi to open the /etc/passwd file and execute (for example) %s/333/335/g. If we did just that, what would happened to the group with GID od 2333 that is also present in this file? Its GID equals now 2335 which is not what it should be, right? So the “proper” way to change GUID is to execute %s/:333:/:335:/g instead.
Finally, I was really surprised when I noticed that GID change “sometimes” remove the
lsuser -R files .... you may not find pgrp= in the output. Fortunately, the chuser -R files pgrp=......... resolves this one and everything is back to normal.
Jim
I know about “-exec” but this still may fail if “nargs” is not “large” enough. In such case, one could use “xargs -L###” where the “XXX” is number setting the number of arguments to process at “a time”.
This evening, I have to process another batch of hosts so I will have opportunity to use what you suggest.
Thanks for your comment,
MarkD
One thing I like with find is that -group will take a numerical argument as well as a text group, in case you need to do it after you change the group number. (Ah, experience.)
Also you can leverage the -exec part of the find command and not have to worry about having too many arguments for your shell:
find /path/ -group oldgroup -print -exec chgrp newgroup {} \;
The -print is just so you see what’s going on, you can exclude it for quiet changes. Though often when running a command like that, I’ll first throw in an echo like:
find /path/ -group oldgroup -exec echo chgrp newgroup {} \;
So it will print out all the commands instead of running them and I can give them a sanity scan. You’ve already got that built in by collecting to a file first you can check. Once that passes I’ll run it to actually make the changes.