A few days ago we installed RSA IG&L 7.2.0 and we noticed that the internal Linux ID's for the users and groups are not enforced anymore however certain application updates do still assume its using this ID's.
In the past the following requirement was in place:
- Linux User oracle
- Username: oracle
- UID: 500
- Default GID: 500
- Linux Group oinstall
- Groupname: oinstall
- GID: 500
- Linux Group dba
- Groupname: dba
- GID: 501
- Linux Group datadir
- Groupname: datadir
- GID: 502
When applying the oracle patches via the rsaimg_updater packages, on extraction the UID's and GID's are archived and predefined which use the internal id's above making the files being owned by nobody. When limited access rights are assigned, this requires super user access to get it rectified.
The following article explains some information about the UID's and GID's.
The current way users are created, the users are considered regular users. The first available UID and GID is assigned which starts at number 1000. This means that in a standard installation the UIDs and GIDs will always be higher than 1000. When the account would be created as a true service account and not a regular user, numbers below 1000 can be assigned and the user's password will not expire.
Basically I was wondering if the following could be considered as a future improvement:
- Could the oracle account be created as a service account
- When the system has the UID's and GID's not yet assigned to other users, could the installer script claim the UID's and GID's
As far as I understand, you can pre-create those accounts before installation with the required UID/GID.
As for the installation packages, just change ownership of the files once extracted (chown -R oracle:oinstall <path-to-packages>). That shouldn't be a problem.