This article describes the need to consolidate UID and GID for user accounts and Unix groups when implementing BoKS in your organization and offers some examples of how you can do this.

Consolidating UID/GID

For BoKS to function as designed and to be sustainable from a management standpoint, usernames/UID's and groupnames/GID's should be as consistent as possible across the enterprise. This is especially true for human accounts, but all efforts should be made to do the same for functional accounts if at all possible.

This means that the same username should have the same UID everywhere, and no other username should have that UID. Equally, no other UID should have that username. A username/UID pair should be unique.

Same goes for group names and GID's. Keep the pairing the same, and unique everywhere.

As you start your BoKS deployment, you're going to want to clean up any UID/GID inconsistencies. This means picking your username/UID and groupname/GID pairings and then fixing the hosts you will add to the BoKS domain to be compliant.

In most cases, we would suggest that you allow BoKS to be the source of authority for these values. Consider the BoKS database to be "the gospel" and force all client hosts ("Server Agents") to be cleaned up and made compliant.

The gospel can be defined as you move throughout your environment. For example, one approach is to make the user accounts on the first host where you want to install BoKS the gospel definitions. Import them into BoKS. From then on, any other host with the same users and groups must match. Do the same for the next host and the next. As you move along, the database will grow with authoritative entries and system administrators will have a list they can use to clean up their hosts.

The basic cleanup process is a find/chown cycle where file ownerships and password/group files are made compliant. Make sure this is done BEFORE you attempt to install BoKS on the host and you'll find that installations go much more smoothly.

A simple example might be:

BoKS has the following definition:

username = oracle

UID = 101

groupname = dba

GID=101

On a host, you find that oracle exists, but the UID is set to 54321 and the group is "staff".

First, make sure no other users on the host are using UID 101 and that the group dba isn't being used; but if it is, that its GID is 101. If those conditions aren't met, you'll have to clear those up first.

Once you're sure there are no other conflicts:

Correct the file ownerships:

find / -user 54321 -exec chown 101:101 {} \;

Edit the passwd file and set oracle's UID=101.

Edit the group file and create the dba group as 101.

Be sure to also look at things such as home directory, shell, etc. These should all be the same across the enterprise, so make sure they are considered when you do your planning.

NOTE! This is an example. The number of variations here are too vast to document. For instance, in the example above, the assumption was made that all oracle files should be group dba. This may not always be the case. You will need to do the proper research and discovery before making any changes.

We recommend backups before any find/chown operation.

If you choose to use another source of authority rather than BoKS, that's ok. The same basic principles apply. Usernames/UID's and groupnames/GID's need to be consistently defined across the enterprise and unique if at all possible.


Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: May 25, 2018