Actually mentioned this problem, do the system operation and maintenance of people will feel that this problem is very weak, but also very low, but in the system user management, it is often encountered problems, but this problem can be effectively circumvented.
First of all, the problems encountered, the production of the user in the process of creation, not through a unified uid\gid planning, the results of multiple servers exist on the same users have different uid\gid. And these application users have an identical NAS mount point, and the application startup is the user start-stop. Because the same user is different uid\gid, so equal to two different user access, so there must be mutual read and write permission to deny the problem.
Solution:
1. Comb out the list of affected hosts.
2. Identify the application owner in the corresponding host list.
3, negotiate the operation of the Shutdown window.
4. Stop all apps associated with this user.
5, unified User's Uid\gid.
6, the NAS on the re-unification of Uid\gid again.
7. Restart the affected host's operating system.
Speaking of this, it seems that an application user's uid\gid modification, such a small problem, is not to say directly with the Usermod-u UID user name directly modified so simple, is not directly vi/etc/passwd/etc/group so simple. Once the wrong user is responsible for the application's start and stop, its UID is taken up by the process number. So a little careless, will disrupt the continuity of business, the company's revenue has an impact.
The circumvention method can be used to make a unified uid\gid planning for production users through the user management information list of the CMDB. In the user classification, can be divided into real-name users, network users, system maintenance users, application users, FTP users, different users between the GID is not the same. A maintainer can know in the user management interface what category the user is in, and what the next one is in which the UID number already corresponds. This makes it easy to create a user, and it is easy to roll back and trace, even in the course of the operation. However, avoid the creation of arbitrary, unrestrained, so that the production system is a devastating disaster.
Linux same user UID not unified problem solved