If you use Novell Storage Services™ (NSS) on OES Linux, after installing the first OES Linux server in a tree, you should check every subsequent server to see whether the /opt/novell/oes_install/nssid.sh file exists.
If this script file exists, you must run it on the server to synchronize the file ownership information for specific system users.
The following sections explain why.
As explained in Section F.0, OES System Users and Groups, having NSS volumes on OES Linux servers requires certain system-level modifications, most of which are automatic. The following logic applies.
By default, Web services, such as Apache and Tomcat, and certain OES services, such as NetStorage, run on an OES Linux server as system-created POSIX users.
These system-created users must be able to read data on all volume types that exist on the OES Linux server.
Data on NSS volumes can be accessed only by eDirectory™ users.
Therefore, when NSS volumes are created on the server, the system-created users must be enabled for Linux User Management (LUM) so that they can function as both POSIX and eDirectory users.
For more information on LUM, see Linux Access for eDirectory Users (LUM).
When NSS is installed on an OES Linux server, the system-created users that must be able to access NSS data are automatically created as LUM-enabled eDirectory users and then removed from the local server. For more information, see Section F.1, System Users Created on Linux and Section F.3, System Groups Created on Linux.
For example, the Apache Web server runs on all OES Linux servers as user wwwrun. If you install the first server in an eDirectory tree, the system-created wwwrun user might be assigned a UID of 6.
If you install NSS on the server, either during the initial install or later, the wwwrun user is automatically created in eDirectory with its UID (6) stored as an attribute, and the local wwwrun user is removed from the server.
Each time the Apache Web server starts, it runs as the wwwrun user account that is actually stored in eDirectory but also functions as a local user due to LUM. All files created and used by the wwwrun user show that the file owner has a UID of 6. Because wwwrun in eDirectory has a UID of 6, the Apache Web server can start and run.
For each additional OES Linux server installed into the tree, when NSS is installed (either initially or later), the installation checks to see whether the system-created user UIDs match the information stored for each user in eDirectory. If subsequent servers are installed in the same way as the first server, the UIDs usually match. However, this is not guaranteed, and when OES services are added to an existing SLES 9 server, the UIDs usually do not match.
For example, the wwwrun user created on a subsequently installed OES Linux server might have a UID of 7. As long as the wwwrun user exists on the local system, Apache is able to run because the wwwrun user’s UID matches the owner information for each Apache file. However, when NSS is installed and the local users are removed, the affected services must run using the information stored in eDirectory.
If the UID of the user that is removed doesn’t match the UID stored in eDirectory, then the eDirectory user can’t access the files on the server and the affected services (Apache, Tomcat, NetStorage) do not load.
For example, if the wwwrun user that has a UID of 7 is removed and the wwwrun user in eDirectory that has a UID of 6 is supposed to replace it, then Apache cannot load and run on the server because the Apache files on the server are expecting their owner to have 7 as its UID.
The OES Linux installation checks for conflicts between the UID of the local system-created user and the same user stored in eDirectory. When it discovers a conflict, it creates a shell script file in /opt/novell/oes_install named nssid.sh for the express purpose of synchronizing all system files on the server that have mismatched UIDs.
The installation analyzes each system-created user separately and places an entry in the script only when a conflict exists.
Because there are four system-created users that could be affected, the script file can potentially contain four lines.
The installation program doesn’t run the nssid.sh automatically, because it can take from 10 minutes to a number of hours (if the file system is very large) to synchronize the file UIDs for each affected user.
Also, the installation program does not warn that a potential UID conflict exists.
For this reason, if you use NSS on your OES Linux servers, it is imperative that you complete the instructions in the following section for each second, third, etc., OES Linux server that you install.
If you install NSS volumes on your OES Linux servers, then for each additional OES Linux server (after the first) installed into a tree, you must do the following:
Log in to the server as the root user.
Check to see whether the following file exists:
/opt/novell/oes_install/nssid.sh
If the file exists, run it from a shell prompt on the server to synchronize UID information in system files by entering the following command:
/opt/novell/oes_install/nssid.sh
If the file doesn’t exist, no action is required.